1

これの違い（パフォーマンスとその他）は何ですか：

public class MyPlaceMapper implements PlaceHistoryMapper {
    @Override
    public String getToken(Place place) {
        if(place instanceof HomePlace)
            return "home";
        else
            return null;
    }

    @Override
    public Place getPlace(String token) {
        if(token.equals("home"))
            return new HomePlace();
        else
            return null;
    }
}

と：

public class MyPlaceMapper implements PlaceHistoryMapper {
    // Singleton HomePlace to inject and reuse over and over again
    private HomePlace homePlace;

    // Getter/setter for homePlace...

    @Override
    public String getToken(Place place) {
        if(place instanceof HomePlace)
            return "home";
        else
            return null;
    }

    @Override
    public Place getPlace(String token) {
        if(token.equals("home"))
            return homePlace;
        else
            return null;
    }
}

つまり、同じ「シングルトン」Placeを何度も再利用し続けるか、要求されるたびに新しいシングルトンをインスタンス化するかの違いは何ですか。

Activityまた、の中から sに対して同じ質問をしActivityMapperます。再度、感謝します！

4

2 に答える 2

6

経験則：場所は不変でなければなりません。そのことを念頭に置いて、シングルトンの場所の使用は、その場所にデータが添付されていない場合にのみ実行できます（HomePlace例のように）。場所は非常に軽量であるため、シングルトンを使用することと新しいインスタンスを作成することの影響はごくわずかです。

アクティビティは値オブジェクトではないため、これはまったく別の話です。

シングルトンアクティビティを使用することは何を意味しますか？

  • との状態をクリアする必要があります。そうしないonStopとonCancel、アクティビティの以前の使用からの状態が、後の使用にリークする可能性があります。場合によっては便利ですが、キャッシュの動作を分離（関心の分離）にしておく方がよいと思います。
  • シングルトンは、定義上、アプリケーションの存続期間中、ユーザーが一度だけ表示/使用するものであっても、メモリに保持されます。たとえば、Googleグループのウェルカム画面は、アプリケーションの実行ごとに1回だけ表示される可能性が高いのに、なぜそれをメモリに保持するのでしょうか。
  • 両方が同じアクティビティにマップされている2つの場所間を移動すると、アクティビティは再開されないため（これはの機能ですActivityMapper）、場所が変更されたことをアクティビティに通知する必要があります（もちろん必要な場合） 。これは、ActivityMapperまたはでアクティビティにsをリッスンさせることで実行できますPlaceChangeEvent。

MVP（アクティビティからビューを分割する）を使用する場合、アクティビティは一般に軽量であるため、短期間のアクティビティを使用すると、上記から解放され、すべてをクリアしてonStoponCancel、場所が変更され、全体的に物事が簡単になることをアクティビティに伝えることができます。 ：アクティビティが作成され、開始され、キャンセルまたは停止されて終了し、ガベージコレクションの準備が整います。一部のデータまたは計算結果のキャッシュを保持する必要がある場合は、すべてのアクティビティインスタンスが共有する明示的なキャッシュオブジェクトを使用します。それは物事をより明確にします。

MVPとビューのライフサイクルに関する補足：ビュー（ウィジェット）は一般に重量があるため、頻繁に使用されるビューの場合は、シングルトンにすることをお勧めします。この場合、アクティビティはそのstartメソッド（または場合によってはonStopとonCancel）でビューの状態（フィールド値など）をクリアする必要があり、短期間のアクティビティの使用をなんとか無効にします。ビューのキャッシュ（シングルトンを使用せず、インスタンスをしばらくメモリに保持し、しばらくしてから削除することを検討する場合があります）は、ここでの最適化と見なす必要があります。新しいビューの構築には、アクティビティでクリアするよりもはるかにコストがかかります。始める。これはトレードオフです。

私がMVPにアプローチする方法は、ビュー自体に状態がないことです。つまり、プレゼンターがビューの表示/認識などを実際に制御します。したがって、ビューをクリアすることstartはフローの一部です。プレゼンター（多くの場合アクティビティ）は、それがどのような状態にあるかを知っており、その状態をビューに反映します。そしてstart、それがビューの制御を与えられた時です。このアプローチは、 GWTテストのベストプラクティスセッションでのGoogle I / O 2010中に、Waveの作成時にGoogleによって説明されました。

于 2012-11-23T13:54:48.253 に答える
1

トーマスによる素晴らしい答え。もう少し情報を追加するだけです。

Google から提供されたオブジェクトのデフォルトの実装をオーバーライドすることができます。たとえば、特定のタイプの場所に対して常に同じアクティビティのインスタンスを返す独自のアクティビティ マッパーを作成することができます。トーマスが言ったように、場所は実際には重要なオブジェクトではありません. 重要なのは、アクティビティ マッパーを介してその場所にリンクされたアクティビティです。それにもかかわらず、ライフサイクルの問題が発生する可能性があり、開始および停止メソッドのコーディングは非常に困難になります。

必要に応じて、アクティビティ マネージャーを再コーディングし、更新メソッドをパターンに追加して、既存のアクティビティを更新することをお勧めします。

ブラウザで前方または後方に押したときにアプリケーションがどのように動作するかを自問してください。詳細については、こちらのアクティビティと場所について書いた記事をご覧ください。

それが役立つことを願っています。

于 2013-03-08T20:35:24.487 に答える