gwtgwt-activities

How meaningfull is Activity.mayStop()?

I am wondering if there is any non trivial use case for the com.google.gwt.activity.shared.Activity#mayStop method.

  1. The com.google.gwt.place.shared.PlaceController.Delegate#confirm is a blocking one, so you cannot use a different Delegate, that is using callbacks. I really do not know why this is implemented in a blocking manner because the GWT guys always say that user interactions should be handled asynchronously.
  2. The mayStop method is always called. Even if the ActivityManager would return the same Activity and the UI would not change. So the activity has to check for instance if the user has unsaved changes and if a place change whould really result in discarding the unsaved data. I think this check could be done more easily before calling placeController.goTo(new Place()).

What do you think?

Solution

    1. see http://code.google.com/p/google-web-toolkit/issues/detail?id=6228#c1 TL;DR: asynchronous handling opens the door to too many edge cases, bugs, confusion, and differing needs/wishes as to how it should work.

    2. The activity that does the goTo is not necessarily the one that needs to do checks in mayStop. In the case it is, then if it does the check before doing the goTo (and then transit to a state where the mayStop will return null), then in the case there is another activity with unsaved changes, this will result in two confirmations being asked to the user.
      It's also possible to listen to PlaceChangeRequestEvents and conditionally call setWarning, instead of doing the check in mayStop. That way you have access to the place you're navigating to; but it couples your activity with the places and their mapping to activities (e.g. a list activity might be displayed on a details place on the desktop, but not on mobile); that's the responsibility of the ActivityMappers.
      Also, don't forget navigation can be triggered by the browser (user navigating in the browser's history). The thing is: on the web, the user is in control.
      All in all, it's probably better (and simpler) to simply do the goTos and rely on mayStop to ask for confirmation. (the activity could also disable the buttons/links triggering goTo in the case there are unsaved changes, so navigation could only be triggered by other activities).