3

多くの Android アプリには独自の BaseActivity クラスが含まれており、アプリ内のすべてのアクティビティが拡張されます。これは、ほとんど/すべてのアクティビティに共通する機能を配置するための中心的な場所を提供するため、便利です。BaseActivity を持つことの主な欠点は、Activity サブクラス (ListActivity など) を使用できないことです。

1 つの代替手段は、ActivityDelegate を使用することです。これにより、Activity サブクラスを使用できるようにしながら、機能の中心的な場所が提供されます。また、継承の代わりに構成を使用するため、間違いなくよりテストしやすくなっています。

これらのソリューションはどちらも、BaseActivity/ActivityDelegate が大きくなりすぎて複雑になると、大量のスパゲッティ コードになる可能性があります。これに対する考えられる解決策は、デリゲート パターンを使用することですが、機能を多くの異なるデリゲートに分割します。これにより、デリゲートのスパゲッティ コードが削減されますが、アクティビティはより複雑になります。現在、on* メソッドを 1 つだけではなく、さまざまなデリゲートに転送しようとしています。

これらすべての問題に対する可能な解決策は、デリゲート マネージャーを使用することです。デリゲート マネージャーは、アプリ内のすべての小さなデリゲートを追跡します。アクティビティは on* メソッドを Delegate Manager に転送し、Delegate Manager はそれらを個々のすべての Delegates に転送します。これにより、次のすべてが達成されます。

  • コードの重複排除 - すべての一般的な機能がいずれかのデリゲートに配置されます
  • Activity サブクラスの使用を許可します
  • すべてのアクティビティのシンプルなコード - すべての on* メソッドが 1 つのクラスに転送されます
  • 簡単にテスト可能 - 単体テスト用にデリゲートとデリゲート マネージャーの周りのすべてを簡単にモックアウトできます

このパターンを使ってみた人はいますか？もしそうなら、それはどうなりましたか？

4

1 に答える 1

2

私が理解している限りでは、アプリケーション全体に対して 1 つの DelegateManager オブジェクトについて話しているのです。この場合、registerActivityLifecycleCallbacksを使用できます。 http://developer.android.com/reference/android/app/Application.html#registerActivityLifecycleCallbacks%28android.app.Application.ActivityLifecycleCallbacks%29を参照してください。

API レベル 14 未満の場合は、https ://github.com/BoD/android-activitylifecyclecallbacks-compat を確認する必要があります。

registerActivityLifecycleCallbacksアクティビティ onXXX ライフサイクル メソッドにフックできます。

これを行うと、あなたが説明したすべての利点が確実に得られます。

  • デカップリングは、実際に動作を繰り返す必要がある場合にのみ使用できます。これは、アクティビティが機能する方法で結び付けられたコントローラーとビューのロジックではめったにありません。
  • 再利用できるアクティビティがある場合、継承を削除するのは良いことですが、私はこれまでそれを行う必要がありませんでした。しかし、良いユースケースは、設定を処理するための家庭料理のアクティビティや、アプリ全体の L&F と動作を必要とするようなものだと思います。

頭のてっぺんに、これらの欠点を考えることができます。

  • あらゆる場所でリスナーを使用すると、アプリケーションのアクティビティ/呼び出し階層のパスが曖昧になり、コードが理解しにくくなる可能性があります。これは、すべてのリスナー/ディスパッチャー タイプのプログラミングに当てはまります。強力なツールですが、取り扱いには注意してください。
  • ライフサイクルリスナー/デリゲートに渡すだけの場合、(あなたが言及したように) 多くのボイラープレート/スパゲッティコードを導入できます。
  • アプリケーションから自分自身を登録解除するのは、あなたの責任Application.unregisterActivityLifecycleCallbacksです。良い方法は無いと思いますが、

個人的には、このデザイン パターンをライフサイクルにあまり使用していませんが、ユース ケースによっては価値があるかもしれません。例えば：

  • ApplicationLifecycleLogger: アクティビティを作成/再開/一時停止するたびに、logcat などでライフサイクルのデバッグを少し簡単にします。
  • たとえば、誰かが何らかのモデル状態のために入ることが許可されていないアクティビティに入った場合 (たとえば、アラームが鳴っている -> AlarmEditActivity に入ることができない)、そこで finish() を実行できます。
  • Parcelable:s や画面の回転を変更せずに、アクティビティの境界を越えてオブジェクトの状態を渡します。通常、これは Map in Application またはどこかの静的フィールドで実装されます。委任者に状態を保持させることでこれを行うことができます。

また、以下もご覧ください: Is there a design pattern to cut down on code duplicate when subclassing Activities in Android?

これがお役に立てば幸いです=）

于 2013-11-18T16:50:53.323 に答える