6

アプリ内の他の (フラグメント) アクティビティによって共有される一時的な状態と共通コードを格納する場所として、Android Applicationクラスを使用することを検討しています。

次の場所に適しているかどうかについて、さらにフィードバックをお寄せください。

  1. ID、設定キー名などの共有定数。
  2. 現在の UI 状態、ナビゲーション、選択されたフラグメント、および一般的に永続化する必要のない一時データを反映するグローバル変数 (つまり、セッター/ゲッター)。
  3. 特定の条件がトリガーされたときにデータを永続化するためのフック。
  4. 設定変更後の UI の更新。
  5. アプリのどこからでもコンテキストにアクセスする簡単な方法を提供します。getApplication()たとえば、MyApp.getApp().
  6. グローバルな状態変数の可視性を必要とし、専用クラスに移行するには煩雑になる一般的なメソッド。

アクティビティクラスで他に適切/便利/便利なものは何ですか? そのままにしておくのが得策ではないものは何ですか?また、最良の代替案は何ですか? 最後に、アプリでアプリケーションを使用するのに最適な理由は何でしょうか?

4

2 に答える 2

2

ID、設定キー名などの共有定数。

読みやすくするために、通常は C という名前の定数ファイルを作成します。C.SHARED_PREFSIMHOの方が理解しやすいですApplication.SHARED_PREFS。

現在の UI 状態、ナビゲーション、選択されたフラグメント、および一般的に永続化する必要のない一時データを反映するグローバル変数 (つまり、セッター/ゲッター)。

これは、関連するアクティビティまたはコンポーネントで行う方が適切です (たとえば、アクティビティの UI 状態は、おそらくつららバンドルまたはアクティビティのインスタンス内に格納する必要があります)。

特定の条件がトリガーされたときにデータを永続化するためのフック。

これで問題ないはずです。

設定変更後の UI の更新。

繰り返しますが、これはそれぞれのコンポーネントの方が良いと思います。

MyApp.getApp() などの静的ゲッターを介して getApplication() が使用できないコードを含め、アプリ内のどこからでもコンテキストにアクセスする簡単な方法を提供します。

これは機能しますが、メモリ リークに注意してください。アクティビティやサービスなどからメソッドを呼び出すときは、通常、コンテキストをパラメーターとして渡す必要があります。メモリ リークの可能性が低くなります。

グローバルな状態変数の可視性を必要とし、専用クラスに移行するには煩雑になる一般的なメソッド。

アプリの機能やサイズが大きくなるとメンテナンスが難しくなるので、専用のクラスを作ったほうがいいと思います。

于 2013-01-07T14:40:21.060 に答える
2

おそらく特定のフックを取り付けることができる場所です。

たとえば、ACRAクラッシュ レポート ライブラリを使用する場合は、ACRA がアタッチされている Application クラスを使用するだけで済みます。これが、私がこのクラスを使い始めた理由です。以前は必要ありませんでした。

于 2013-01-07T14:40:55.723 に答える