2

メソッドの重要なユースケースがあるかどうか疑問に思っていますcom.google.gwt.activity.shared.Activity#mayStop。

  1. はブロックするものであるため、コールバックをcom.google.gwt.place.shared.PlaceController.Delegate#confirm使用している別の を使用することはできません。Delegateなぜこれがブロック方式で実装されているのか、私にはよくわかりません。なぜなら、GWT 関係者は、ユーザーとの対話は非同期で処理する必要があるといつも言っているからです。
  2. mayStopメソッドは常に呼び出されます。ActivityManagerが同じものを返しActivity、UI が変更されない場合でも。したがって、アクティビティは、たとえば、ユーザーが変更を保存していないかどうか、および場所の変更によって保存されていないデータが実際に破棄されるかどうかを確認する必要があります。を呼び出す前に、このチェックをより簡単に行うことができると思いますplaceController.goTo(new Place())。

どう思いますか？

4

1 に答える 1

4

  1. http://code.google.com/p/google-web-toolkit/issues/detail?id=6228#c1 を参照してくださいTL;DR:非同期処理は、あまりにも多くのエッジ ケース、バグ、混乱、および異なるニーズへの扉を開きます/それがどのように機能するかについての願い。

  2. を実行するアクティビティが、goToでチェックを実行する必要があるとは限りませんmayStop。その場合、 を実行する前にチェックを行うと(その後、が戻るgoTo状態に遷移します)、変更が保存されていない別のアクティビティがある場合、に 2 つの確認が求められます。ユーザー。をチェックインする代わりに、 をリッスンして条件付きで を呼び出すこともできます。そうすれば、ナビゲートしている場所にアクセスできます。ただし、アクティビティを場所およびアクティビティへのマッピングと結合します (たとえば、リスト アクティビティは詳細な場所に表示される場合があります)。mayStopnull
    PlaceChangeRequestEventsetWarningmayStopデスクトップでは可能ですが、モバイルでは不可能です); それはSの責任ですActivityMapper。
    また、ブラウザによってナビゲーションがトリガーされる可能性があることも忘れないでください (ユーザーはブラウザの履歴をナビゲートします)。問題は、Web 上ではユーザーがコントロールできるということです。全体として、単に s を実行し、確認を求めることに頼る
    方がおそらく良い (そして簡単) でしょう。(アクティビティは、保存されていない変更がある場合にボタン/リンクのトリガーを無効にすることもできるため、ナビゲーションは他のアクティビティによってのみトリガーされる可能性があります)。goTomayStopgoTo

于 2012-03-08T12:32:27.067 に答える