必要に応じて、コンテンツの保存と分類を行います。このガイドでは、品質の高い堅牢なアプリを作成するためのおすすめの方法と推奨アーキテクチャを紹介します。フレームワークの基本について熟知していることを前提としています。基本コースでアプリの開発の基本を学習したうえで、このガイドで取り上げているコンセプトの詳細を確認してください。レシーバなど)で構成されています。マニフェストで宣言しておきます。エクスペリエンスにアプリをどのように組み込むかを決定します。アプリには複数のコンポーネントが含まれており、ユーザーが短時間に複数のアプリを頻繁に操作することを考慮すると、アプリはユーザー主導のさまざまなワークフローとタスクに適応する必要があります。システムは新たなアプリのリソースを確保するために、アプリプロセスを任意のタイミングで強制終了する場合があります。システムやユーザーによって随時破棄される可能性があります。コンポーネント内に保存したり、メモリ内に保持したりしないでください。コンポーネントは互いに依存してはなりません。コンポーネントを使用できないとなると、アプリをどのように設計すればよいのでしょうか。アプリのサイズが大きくなるにつれ、アプリを拡張し、堅牢性を高め、アプリをテストしやすくするアーキテクチャを定義することが重要になります。アーキテクチャは、アプリの各部分の境界と、各部分が担う役割を定義します。アーキテクチャを設計する必要があります。重要な原則は関心の分離です。記述するのはよくある間違いです。システムとのやり取りを処理するロジックのみを含めます。これらのクラスをできる限りシンプルに保つことで、コンポーネントのライフサイクルに関連する多くの問題を回避し、クラスのテストのしやすさを向上させることができます。実装はデベロッパーが管理するものではないことにご注意ください。アプリの間のコントラクトを体現する単なる結合クラスです。ユーザーの操作に基づいて、またはシステムの状態(メモリ不足など)を理由として、いつでもこれらのクラスを破棄できます。エクスペリエンスを実現し、アプリを管理しやすくするために、クラスへの依存を最小限に抑えることをおすすめします。データモデルで操作することです(永続モデルをおすすめします)。要素やその他のコンポーネントから独立しています。アプリのプロセスをメモリから削除することを決定したときは、破棄されます。永続モデルが望ましい理由として、次の点が挙げられます。アプリを破棄してリソースを解放してもデータが失われない。ネットワーク接続が不安定または利用不可の場合でもアプリが動作し続ける。クラスに基づいて構築すると、アプリのテストのしやすさと堅牢性を高めることができます。信頼できる唯一の情報源アプリ内で新しいデータ型を定義するときは、信頼できる唯一の情報源(SSOT)を割り当てる必要があります。そのデータを変更またはミューテーションできます。不変の型を使用してデータを公開します。データを変更するには、関数を公開するか、他の型が呼び出すことができるイベントを受け取ります。このパターンには、次のようないくつかのメリットがあります。他の型によって改ざんされないようにデータを保護できる。データに対する変更が追跡しやすくなり、それによりバグを見つけやすくなる。ファーストのアプリでは、アプリデータの信頼できる情報源は、通常はデータベースです。信頼できる情報源になります。ガイドでは、信頼できる唯一の情報源の原則がよく使用されます。状態は一方向にのみ流れます。データを変更するイベントはその反対方向に流れます。一般的に状態またはデータは、上位スコープの階層の型から下位スコープの階層の型に流れます。到達するまで流れます。アプリデータが変更されて、不変の型で公開されます。このパターンにより、データの整合性の保証が向上し、間違いの発生が減り、デバッグが簡単になります。パターンのすべてのメリットが実現されます。プラクティスに沿ってアプリを構築する方法について説明します。プラクティスは、さまざまなアプリに適用できます。それにより、アプリのスケーリングを可能にし、品質と堅牢性を高め、テストを容易にすることができます。これらはガイドラインとみなし、必要に応じて各自の条件に適応させる必要があります。つのレイヤが必要です。ロジックを含み、アプリデータを公開するデータレイヤ。レイヤとデータレイヤの間のやり取りを簡素化でき、再利用できます。このガイドの図にある矢印は、クラス間の依存関係を表しています。クラスに依存しています。アーキテクチャでは、特に次の手法の使用が推奨されています。リアクティブで階層的なアーキテクチャ。アプリのすべてのレイヤにおける単方向データフロー(UDF)。