I could not find my answer in this thread:
The GWT Scheduler class has scheduleDeferred API which executes after the browser event loop returns. The scheduleFinally API allows me to execute code before the control returns to the browser event loop.
How do I decide whether I should use scheduleDeferred or scheduleFinally? Is there a code example which shows the difference in behavior?
To understand this, you need to first get the basic idea of an event loop. When you write code to run in the browser, you don't write this loop - it lives in the browser, waiting for the user to do something. When that something happens (mouse event, keyboard event, AJAX call returns, setTimeout goes off), the loop calls into your code, and lets you handle it however you would like to.
So first, we have scheduleDeferred, which is a way to notify the browser that we have some code to run soon, but not in this loop. This is a handy way to let the browser regain control, render some content, and then give you control again. This can be helpful to break up calculations into several chunks to avoid any "long running script" errors, or can be an early attempt at animation (Note: use the actual requestAnimationFrame api from the browser, or AnimationScheduler.get().requestAnimationFrame in GWT instead for this).
Next, there are two interesting places in the loop where you might have code that you would like to run - either right as the browser transfers control to you, or right before you return control back again. Of these two, the end is usually more interesting: scheduleFinally. This lets you run some code inside the current event loop, but not until the very end of it. CssResource uses this strategy in its ensureInjected() method - when you run several different calls to this method, rather than poking the DOM several times, it batches them all up and runs them at the end of the event loop, using scheduleFinally.
The last one, the beginning of each event loop is managed by another method - scheduleEntry. In theory, this could be used in conjunction with finally to reimplement a simple version of AngularJS's binding wiring.
//event comes in to GWT from the $entry method, and follows these steps
try {
// 1. run registered scheduleEntry calls
// 2. run the current event or callback that the browser called us for
} finally {
// 3. run registered scheduleFinally calls
}
Any call to scheduleDeferred during those steps has added a call to the next event loop, to run as part of #2.
