メソッドのオーバーライドでデータの監視を停止していないことに気付いたかもしれません。ライフサイクルを認識するため、こうした処理は必要ありません。コールバックは呼び出されません。よってオブザーバーが自動的に削除されます。設定の変更(ユーザーによるデバイスの画面の回転など)に対処するためのロジックは何も追加していません。同じインスタンスを受け取ります。現在のデータを使用してコールバックが直ちに呼び出されます。オブジェクトを直接参照しないでください。ライフサイクルに関する説明をご覧ください。プロフィールのデータを取得するにはどうすればよいでしょうか。提供することを前提としています。ライブラリを使用しますが、同じ目的を果たす別のライブラリを使用しても構いません。オブジェクトに割り当てる方法かもしれません。その方法を使用することもできますが、アプリが拡大するにつれて管理が困難になります。クラスの責任が非常に大きくなり、関心の分離の原則に反します。ライフサイクルに関連付けられます。オブジェクトのライフサイクルの終了時に失われてしまいます。エクスペリエンスを損ねます。実装では、上記の方法を使用する代わりに、データ取得プロセスを新しいモジュールであるリポジトリに任せています。呼び出すかを把握しています。リポジトリは各種のデータソース(永続モデル、ウェブサービス、キャッシュなど)間の仲介役と見なすことができます。インスタンスを使用してユーザーのデータを取得します。タスクの実行に関するガイドをご覧ください。モジュールは不要に見えますが、アプリの他の部分からデータソースを抽象化するという重要な目的を果たしています。データの取得方法を認識しないので、複数の異なるデータ取得実装から取得されたデータをビューモデルに提供できます。エラーのケースは省略しています。ステータスの公開をご覧ください。インスタンスが必要になります。クラスの依存関係について把握する必要もあります。このような場合、コードの複製が必要になります。参照を必要とする各クラスがインスタンスの作成方法や依存関係を把握する必要があるためです。作成すると、アプリで大量のリソースを消費することになるおそれがあります。パターンを使用できます。依存性の注入を利用すると、クラスの依存関係を構築することなく定義できます。ランタイムには、別のクラスがこの依存関係を提供します。パターンでは、クラスが依存関係を作成せずに取得できるレジストリが提供されます。上記のパターンでは、コードが重複することも煩雑になることもなく依存関係を明確に管理できるので、コードの拡張が可能になります。テスト版と製品版のデータ取得プロセスの実装を簡単に切り替えることができます。ライブラリを使用することをおすすめします。依存関係ツリーをたどって自動的にオブジェクトが構築され、コンパイル時の依存関係が保証されます。クラスの依存関係コンテナが作成されます。オブジェクトの依存関係を管理します。つのデータソースのみに依存するため、あまり柔軟ではありません。実装に関する主な問題は、バックエンドから取得したデータをどこにも保存しないことです。離れた後に戻ってきたときに、データが変更されていなくてもアプリで再び取得する必要があります。次の理由により、この設計は最適とは言えません。貴重なネットワーク帯域幅を浪費する。新しいクエリが完了するまでユーザーが待機せざるを得ない。オブジェクトをメモリにキャッシュします。これは、リポジトリがメモリ内キャッシュからデータを取得するためです。プロセスを強制終了した後)に戻ってきた場合はどうなるでしょうか。現在の実装では、ネットワークからデータを再取得する必要があります。エクスペリエンスに悪影響を及ぼすだけでなく、貴重なモバイルデータを消費するため、無駄が多くなります。リクエストをキャッシュすることによって解決できますが、重要な問題が新たに発生します。同じユーザーデータが別のタイプのリクエスト(友だちリストの取得など)から表示される場合はどうなるでしょうか。その場合、アプリで矛盾するデータが表示されることになり、混乱が生じます。つの異なるバージョンが表示される可能性があります。この矛盾するデータを統合する方法を見つける必要があります。この問題に適切に対処するには、永続モデルを使用します。