Is there anyway to don't go to a place until a rpc is done?

[nacho]

For example, let's say that I have this dummy menu [ Goto Activity Foo | Goto Activity Bar ]

When I click on [ Goto Activity Foo ] I go to the the Foo Activity, and in the start() method I call to a rpc, let's say dummyService.fetchData().

And, then I click on the [ Goto Acitivity Bar ] before that the rpc that the rpc call dummyService.fetchData() finished. Is there anyway to don't go to Bar Activity if the previous rpc is still undone?

Thanks.

[Jens]

Why would you want to wait? Seems like the user isn't interessted anymore in Activity/Place Foo. If you force the user to wait, your app may feel unresponsive and slow.

But if your really want to, just disable the menu while the activity loads the data and re-enable it when the data is loaded.

[nacho]

For example, let's say I have a menu option "List Users", and I have a button in the List Users view that removes a User.

Then a user of my app clicks in the "Delete User" button, and inmediately clicks in "List Users" option in the menu. This RPC goes to the server before that the deleteUser RPC is done. And maybe also the fetchUsers RPC is back before the deleteUser RPC efectively deleted the user, so in the list will come the deleted user.

So I was looking a way to don't allow the user to go to the Users Lists activity before the deleteUser rpc is done.

[Thomas Broyer]

This is what the mayStop() method of Activity is for. As Jens said, you can also somehow disable navigation until your app is in a state that "allows" it (but beware that if the user refreshes the page, the app won't have any way to know that a previous call was issued → implement mayStop anyway, to warn users).

As an alternative, implement your navigation as events on the event bus, and a central listener maps them to PlaceController.goTo calls, possibly swallowing or deferring them, possibly loading required data before actually navigating, etc.

Oh, and of course, you could also display a "glass panel" with a progress bar or spinner arrows (or just a message) –e.g. in the form of a PopupPanel with setGlassEnabled(true)– that makes all interaction with the app impossible until the RPC response is back (but the "refresh page" scenario is still to be considered).

Web apps are not like desktop apps: you cannot "lock" users in until something is done. They can open the app in another tab/window/browser, they can "unload" the app at any time, and possibly reload it while some action started by the "previous load" is still being done on the server-side.

[Jens]

Also keep in mind that the user can simply hit the back/forward button of the browser to switch places. In that case it would not really help to disable the view/navigation or using a PopupPanel with active glass panel because the user can still navigate using the browsers buttons. You would have to disable these buttons as well (not quite sure if its possible).

So I would say in some cases its just better to assume that the UI in some rare cases may show wrong data. In your case its maybe not a big deal if a user is shown in a list that is already deleted. If your app user selects this deleted user from the list and you are trying to load it from your database you could tell the app user that its not there and then remove it from the list. So basically you would "repair" the UI state if the app user really requests that deleted user from the list. But it depends on your app if its a good solution or not.

If you really have to solve this problem then you probably have to make sure that the server executes the requests from the client in the exact same order as the client sends them. So you might have to implement some sort of a sequence number. Using a sequence number you could reorder the server requests on server side so that they will be executed in the exact same order as they are executed on the client. That way you could make sure that DELETE is always executed before LIST gets executed. 

-- J.