ステータスを表示する場合に適しています。テストのしやすさであることを説明しました。モジュールをテストする方法を示します。ライブラリを使用することをおすすめします。十分にテストできます。テストを使用してテストできます。クラスをモックするだけで済みます。テストを使用してテストできます。モックする必要があります。これらのテストでは、以下の動作を確認します。リポジトリがウェブサービスの呼び出しを適切に行っている。リポジトリが結果をデータベースに保存している。データがキャッシュされて最新の状態である場合、リポジトリが不要なリクエストを行わない。どちらもインターフェースなので、これらをモックするか、より複雑なテストケースではフェイク実装を作成します。コンポーネントを必要としないため、すぐに実施できます。ファイルの変更など)が発生しないようにしてください。テストすることが可能です。バージョンと異なる可能性があるため、この方法はおすすめしません。このテストでは、バックエンドへのネットワーク呼び出しを行わないようにします。すべてのテスト(特にウェブベースのテスト)を外部から切り離して行うことが重要です。サーバーを作成できます。コンポーネントから提供されます。このルールを使用すると、呼び出し元のスレッドに対するバックグラウンド処理を即座に実行できます。コンポーネントのバックグラウンド処理を待つことができます。関連付けることもできます。アプリの作成も例外ではありません。問題の解決方法は数多くあります。モード用にローカルで永続化するなど、重要なアプリで対処する一般的なシナリオにはさまざまなものがあります。以下の推奨事項は必須ではありませんが、経験上これに沿うことで、コードベースの堅牢性を高め、テストとメンテナンスを長期にわたって容易に実施できるようになります。レシーバなど)をデータソースとして指定しないでください。ポイントに関連するデータのサブセットを取得する他のコンポーネントとの調整のみを行う必要があります。コンポーネントの生存期間がかなり短くなります。アプリの各種モジュール間の責任の境界を明確に定義します。ネットワークからデータを読み込むコードを、コードベース内の複数のクラスやパッケージに散在させないでください。バインディングなど)を同じクラスで定義しないでください。各モジュールからの公開はできるだけ行わないでください。あるモジュールの内部実装の詳細を公開する「ここだけ」のショートカットを作成しようとしないでください。短期的には時間を少し節約できるかもしれませんが、コードベースが発展するにつれて何倍もの技術的負債を負うことになります。各モジュールを個別にテストできるようにする方法を検討します。データベースに永続化するモジュールを簡単にテストできるようになります。か所に混在させたり、ネットワーク用のコードをコードベース全体に分散させたりすると、不可能ではないにしても、テストが極めて困難になります。アプリの特別な部分に焦点を当てて、他のアプリとの差別化を図ります。コードを何度も書いてすでにあるものを作り直すのではなく、アプリを特別なものにすることに時間とエネルギーを集中させましょう。コンポーネントやその他の推奨ライブラリを利用してください。データの関連性と新鮮さをできる限り維持します。モードのときでも、ユーザーがアプリの機能を利用できるようになります。すべてのユーザーが常時高速接続を利用できるわけではないことを忘れないでください。アプリがアクセスする必要があるデータは常に、信頼できる唯一の情報源から取得されるものにする必要があります。エラーと状態の読み込みを省略しました。ステータスを公開する方法を説明します。実装サンプルを示します。message)}ネットワークからのデータの読み込みとそのデータのディスクコピーの表示を同時に行うことはよくあるので、さまざまな場面で再利用可能なヘルパークラスを作成することをおすすめします。いうクラスを作成します。意思決定ツリーを示します。リソース用のデータベースの監視から始めます。送信するのに十分な結果であるか、あるいはネットワークから再び取得する必要があるかを確認します。データを表示する一方で、ネットワークからデータを更新したい場合、この両方が同時に行われる可能性があります。ネットワークの呼び出しが正常に完了したら、応答をデータベースに保存してストリームを再初期化します。エラーを直接送信します。新しいデータをディスクに保存した後、データベースからのストリームを再初期化します。変更の送信はデータベース自体が行うため、通常はこの操作を行う必要はありません。変更の送信をデータベースに頼るということは、関連する副作用に頼ることを意味します。これは適切ではありません。データが変更されなかったという理由でデータベースが変更の送信を行わなかった場合、その副作用に基づく未定義の動作が行われる可能性があるためです。信頼できる唯一の情報源の原則に反するため、ネットワークから届いた結果は送信しないでください。結局のところ、データベースには、「保存」処理中にデータの値を変更するトリガーが含まれている可能性があります。同様に、新しいデータなしで「SUCCESS」を送信しないでください。クライアントが誤ったバージョンのデータを受け取ることになるからです。{}}クラスの定義について、以下の重要な点に注意してください。RequestType)を定義しています。返されるデータ型がローカルで使用されているデータ型と一致しない可能性があるためです。いうクラスを使用しています。クラスの単純なラッパーです。プロジェクトの一部として示されています。クラス内に作成できます。ライセンスに記載のライセンスに従います。関連会社の商標または登録商標です。