7

@RomainGuy によるメモリ リークの回避の記事を読んだ後、現在の Android アプリケーションが、アプリケーションのメイン アクティビティを渡すという間違いに悩まされていることに気付きました。そのため、いつでもそのアクティビティ パラメータをActivity.getApplicationContext()に置き換えることができます。

しかし、私のアプリケーションには、アプリケーションのメイン アクティビティのメンバーにしかできないメソッドを実行する必要がある特定のクラスがあります。

したがって、コマンド パターンを使用してこの制限を回避することを考えていました。

問題は、その例を見ると、次のことです。

public class SomeCommandExecuableOnlyByActivity implements Command 
{
    public void execute(Object data) 
    {
        doIt( ((MyActivity)data).getWindow() );
    }    
}

私は再びアクティビティの周りのパスを必要とする行き止まりに直面しています (今回はObjectデータとして偽装されています)。

この「鶏が先か卵が先か」の状況から抜け出すにはどうすればよいでしょうか。

この問題にアプローチするより良い方法はありますか?

4

1 に答える 1

4

ここで見逃しているのは、懸念事項の適切な分離だと思います。何らかの機能を呼び出すために、メイン アクティビティを他のアクティビティに渡す必要があると言う場合、アプリのアーキテクチャには根本的な設計上の欠陥があるように思えます。

ここでコマンド パターンを使用するかどうかはわかりませんが、一般的に行うことは、共有アクセスを必要とするメソッドを特定し、それらを別のクラスに移動してから、これを必要とするすべてのアクティビティでそのクラスの別のインスタンスを保持することです。機能、またはインスタンスの状態を共有する必要がある場合は、グローバル アプリケーション コンテキストでインスタンスを作成し、グローバル アクセス パスを提供します (望ましいことではありませんが、RoboGuice のような DI フレームワークがなければ、コンストラクターがレンダリングされるため、Android で DI を実装することは非常に困難です)空所。）

私の意見では、適切に設計された Android アプリケーションでは、Activity にはビジネス ロジックがなく、UI の状態を変更する操作のみを提供します。ユーザー インターフェイスやその他の計算の流れは、他のクラスに任せられます。Model-View-Presenter パターンは、責任によってコードを構造化するのに非常に役立ちます。

あなたが何を達成しようとしているのかについてより多くの洞察を私たちに与えなければ、具体的なアドバイスを与えることは困難です.

于 2012-09-27T12:07:10.000 に答える