Thomas, For clarity purpose, in this mail: - a "synchronous Activity" is an activity where the code of the start() method runs directly - an "asynchronous Activity" is an activity where the code of the start() method runs through GWT.runAsync.
I think there are 2 points. The first one is whether or not it is useful be able to convert (through proxies, providers, ...) a synchronous Activity into an asynchronous one. I don't think of a use case where it can be useful. You either want your activity to run as a sync one or a async one, not both. If it's not used then why providing a proxy, provider, ... It only requires a single class with a starts() that performs a GWT.runAsync and 2 abstract methods: doStart() and onFailure() The second one is whether or not it is useful to prevent the doStart() method from starting if the onCancel() method was called. IMO, this is not useful. As of today a synchronous Activity should check if the onCancel() was called in order to stop further initialization, there is no built-in control. As for the asynchronous activity: - the onCancel() method won't prevent from downloading the JS file - the developer is still required to check if onCancel() is called in order to prevent further initialization I don't see the benefits of adding an extra layer of control that doesn't exist in synchronous activities. Antoine. 2011/3/25 Thomas Broyer <[email protected]> > On Fri, Mar 25, 2011 at 9:09 AM, Antoine DESSAIGNE wrote: > > In fact, i don't see a single case where I would want to run the same > > Activity sometime in runAsync and sometime directly. > > It's more that if you change your mind about what should run sync and > async, you shouldn't have to change your activity, because the > activity should still work the same. > > I've attached my own, never-tested, attempt. Note that it assumes > you'll the methods in"the right order", but that can be changed > easily. It also switches to a permanent "failed" state if the runAsync > failed, but maybe it should re-attempt the runAsync in this case. > Finally, it was written before the AsyncProvider made it into GWT (and > GIN); the idea was that every subclass would implement doAsync as a > simple GWT.runAsync call (to create a split-point specific to the > subclass) and the createInstance() as a javax.inject.Provider::get(). > The advantage compared to AsyncProvider is that you don't even create > the instance if the activity was cancelled before the fragment > finished loading. > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
