ガイドこのガイドでは、製品版の品質を備えた堅牢なアプリを作成するためのおすすめの方法と推奨アーキテクチャを紹介します。フレームワークの基本について熟知していることを前提としています。ガイドでアプリの開発の基本を学習したうえで、このガイドで取り上げているコンセプトの詳細を確認してください。アプリの開発をご利用ください。プロセスとして実行されます。アプリとは異なり、構造が非常に複雑です。レシーバなど)で構成されています。マニフェストで宣言しておきます。エクスペリエンスにアプリをどのように組み込むかを決定します。アプリにはさまざまなコンポーネントが含まれており、ユーザーは多くの場合、短時間のうちに複数のアプリを操作することから、アプリにはユーザー主導のさまざまなワークフローやタスクに適応することが求められます。アプリで写真を共有する場合に何が起こるかを考えてみましょう。カメラアプリを起動します。アプリから離れますが、この処理はユーザーから見てシームレスに行われます。カメラアプリが他のインテントをトリガーし(ファイル選択機能を起動するなど)、そのインテントがさらに別のアプリを起動する場合もあります。アプリに戻り、写真を共有します。途中で電話がかかってきたり通知を受信したりして、処理が中断されることもあり得ます。ユーザーは、こうした中断に対処した後、写真共有プロセスに戻って処理を再開できることを期待します。デバイスでは、このようなアプリの頻繁な切り替えはよくあることです。そのため、こうしたフローをアプリで正しく処理する必要があります。システムが新たなアプリのリソースを確保するために、アプリプロセスを強制終了する場合があります。システムやユーザーによって随時破棄される可能性があります。コンポーネント内に保存しないでください。コンポーネントは互いに依存してはなりません。コンポーネントを使用できないとなると、アプリをどのように設計すればよいのでしょうか。重要な原則は、関心の分離です。記述するのはよくある間違いです。システムとのやり取りを処理するロジックのみを含めます。これらのクラスをできる限りシンプルに保つことで、ライフサイクルに関連する多くの問題を回避することができます。実装はデベロッパーが管理するものではないことにご注意ください。アプリ間のコントラクトを体現する単なる結合クラスです。ユーザーの操作に基づいて、またはシステムの状態(メモリ不足など)を理由として、いつでもこれらのクラスを破棄することができます。ユーザーの便宜を十分に図り、アプリを管理しやすくするため、こうしたクラスへの依存を最小限に抑えることをおすすめします。モデルで操作することです。おすすめは永続モデルです。モデルとは、アプリのデータを処理するコンポーネントです。コンポーネントから独立しているため、アプリのライフサイクルや関連する問題の影響を受けません。永続モデルが望ましい理由として、次の点が挙げられます。アプリを破棄してリソースを解放しても、ユーザーのデータが失われない。ネットワーク接続が不安定または利用不可の場合でもアプリが動作し続ける。データの管理責任が明確に定義されたモデルクラスを基盤としてアプリを作成することで、アプリのテストのしやすさと一貫性を向上させることができます。コンポーネントを使用したアプリの構築方法について説明します。種類のアプリ構築方法であらゆる開発ニーズに応じることは不可能です。ここで紹介する推奨アーキテクチャは、幅広いニーズやワークフローにとって優れた出発点になります。アプリの優れた開発手法をすでに実践している場合は、それを変える必要はありません。