1) In the comment to your code, it's said that a Scheduler must be also managed by GIN. Therefore, the question if it is a bad practice to use Scheduler.get(), while the rest of the project is managed by GIN? How about RootPanel.get() (or RootLayoutPanel.get()) factory calls? Seems like one must replace all no-parameter calls of that kind with injections. Correct me if I'm wrong.
Depends on your testing strategy. GWTs Scheduler uses GWT.create and JSNI so if you use it inside a presenter/activity you must test it with GWTTestCase (slow) or use a library like gwtmockito which does some heavy magic to disable GWT.create() calls. If you inject your Scheduler you can use JUnit directly as you can just pass in a fake Scheduler implementation.
So it is not a must, but IMHO a good idea to do so.
2) Back to the main subject about EventBus. Actually I tried scheduler.scheduleDeferred()before I started looking for solutions. Seems like only scheduler.scheduleFinally() defers the event firing long enough to give other activities time to append their handlers withing start() method. At least in my particular case I encountered the "racing" condition between activities for header, content and other sections of my layout. Therefore, while there's no parallel computation in browser, GWT approach with deferred tasks adds some unexplainable magic to the process of debugging. I'm not even sure if I ever gonna prefer scheduleDeferred() to scheduleFinally() from now on.
Actually it is the other way around: scheduleDeferred() delays the code longer than scheduleFinally(). scheduleFinally() is executed right after your normal code but before the browser gets control again, while a deferred command is executed via a JS timeout so the browser had control for some time before the command executes.
3) I still need to fire events manually sometimes. Therefore I do inject EventBus instance to some of the activities. Despite the fact start() method uses different instance of EventBus, the code still works fine like if it's all one single instance. This discovery confuses me a lot, because buses are clearly different. How is it it even possible? And what might be the best practice of using EventBus with Activities&Places + GIN?
Normally in GIN your EventBus is a singleton and you use it to initialize the activity/places framework. In your Activity.start() method you get a special ResettableEventBus which wraps the singleton EventBus you passed into the activity framework. This ResettableEventBus clears all handlers an activity has added automatically once the activity is stopped.
Thats why you should prefer storing the EventBus provided by the start method in a field instead of injecting an EventBus again. I have often seen code where people have injected an EventBus and then forgot to cleanup the handlers which results in a memory leak as the singleton EventBus lives to the entire app lifetime.
-- J.
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment