私は自分の活動が読みやすく維持するのが難しい大規模な広大なクラスに変わるという問題にしばしば遭遇します。たとえば、検索フォームアクティビティがある場合、多くのことが行われています。一部のフィールドにはWebサービス呼び出しからのデータが入力され、一部のフィールドは他のフィールドのアクションに応答し、状態の保存、状態の復元、ユーザー入力の処理などを行います。
私が見ているように、これを改善するためのいくつかのオプションがあります：
アクティビティをいくつかのフラグメントに分割し、各フラグメントが関連フィールドのグループを制御します。このアプローチにはいくつかの利点があります。フラグメントは、他のアクティビティで簡単に再利用できます。たとえば、基本的な検索アクティビティと高度な検索アクティビティがある場合、基本的な検索フラグメントを高度な検索アクティビティで再利用できます。また、ライフサイクルフックを取得するため、フラグメントは、自身の状態の保存と復元、およびサーバー呼び出しの一時停止と再起動などを担当できます。このアプローチの欠点は、フラグメント内にフラグメントを含めることができないことです。たとえば、フラグメントビューページャーを使用する場合、これらの小さなフラグメントを大きなコンテナーフラグメントにネストしてビューページャーに入れることができなかったとします。また、これがフラグメントの設計哲学に適合するかどうかもわかりません。
関連フィールドのグループを制御するカスタムビューグループを実装します。繰り返しますが、これには、アクティビティからこれらのフィールドに関連する多くのコードを削除するという利点があり、再利用可能なUIコンポーネントになります。また、自身の状態を保存および復元する機能もあります。これの不利な点は、ライフサイクルイベントを制御するためのアクティビティに関連付けられていることです。また、これらのカスタムビューグループがWebサービスやデータベース呼び出しから独自のデータを取得したり、ユーザー入力を処理したりすることが適切かどうかもわかりません。私にとって、カスタムビューグループはUIでのデータの表示のみを担当する必要があります。
アクティビティがレイアウトからビューを取得し、フィールドへの入力、Webサービスとデータベース呼び出しの実行、およびユーザー入力の処理を担当するPOJOコントローラーのコレクションを作成する、特注のMVCタイプのフレームワークを実装します。この場合も、このアプローチの欠点は、コントローラーが状態などを保存および復元するために、アクティビティがライフサイクルイベントの伝播を引き続き担当することです。
他の人がこの問題にどのように取り組み、解決するかに非常に興味がありますか？
ありがとう