Androidアプリでのアクティビティコミュニケーションのアーキテクチャ上の問題
私はAndroid用のオープンソースのFlickrアプリ Glimmr を維持しています。現在、ページネーションに関するアーキテクチャ上の問題があり、私はかなり長い間解決しようとしてきました。アイデアをいただければ幸いです。
関連するコンポーネントは次のとおりです。
タスク-ユーザーのフォトストリーム（LoadPhotoStreamTask）、フォトセット（LoadPhotoSetTask）などのソースから写真をフェッチするAsyncTaskのさまざまなサブクラス。
PhotoGridFragment-タスクによってフェッチされた写真をグリッドに表示するフラグメント。このサブクラスは、各タスクに一致して存在します。 PhotoStreamGridFragment、PhotoSetGridFragmentなど。グリッドはページ付けされているため、ユーザーが写真の最後までスクロールすると、タスクがトリガーされて写真の次のページに移動してフェッチします。
PhotoViewerActivity-グリッドからの写真のリストをフルスクリーンで表示する役割を果たします。これは、PhotoGridFragmentsから開始され、a）現在グリッドにある写真のリスト、およびb）表示を開始するインデックスの2つの情報が含まれます。
この問題は、ユーザーがリストの最後に到達したときに発生しますPhotoViewerActivity内から。このアクティビティには、正しいタスクを開始し、渡された写真のリストを更新するために必要な情報がありません。
PhotoGridFragmentとPhotoViewerActivityの間の結合をできるだけ低く保ちながら、これを行う方法を見つけたいと思います。 Androidに精通している人は、2つの別々のアクティビティを扱っているため、それらの間のすべての通信は、データを永続化またはシリアル化する必要があるインテントを介して行われる必要があることを知っています。AfaikthePhotoViewerActivity canグリッドに簡単にコールバックして、さらに写真を要求することはできません。
タスクごとに異なる状態と情報が必要になるため、状況は複雑になります。例えばLoadPhotosetTaskにはセットIDが必要であり、LoadPhotoStreamTaskには特定のユーザーが必要ですが、セットなどは関係ありません。したがって、より多くの写真をフェッチするために必要なタスク名をビューアアクティビティに渡すだけでは不十分です。
別の解決策は、PhotoViewerの一般的な機能を抽象クラスに抽象化し、ソースごとに特定のPhotoGridFragmentsを使用するのと同じように、ソースごとに特定のフォトビューアーを作成することです。これはやり過ぎだと感じますが、おそらく今の私の頭の中にある解決策です。
これをどのように解決しますか？
データの管理を担当するモデル/ businscomponent/serviceがありますか？私にとって、あなたの説明は、あなたのGUI要素（アクティビティ/フラグメント）が仕事をしているように聞こえます。
通常の方法は、データを処理し、さまざまなGUIコンポーネントによって使用されるモデル/ビジネスコンポーネント/サービスを用意することです。