Thanks Lex Spoon, your explanation is really useful to my project. On Thursday, November 6, 2008 5:16:38 AM UTC+7, Lex Spoon wrote: > > On Fri, Oct 31, 2008 at 11:50 AM, Ian Petersen > <[email protected]<javascript:>> > wrote: > > The compiler already analyzes your code to do things like dead code > > removal. In other words, it already removes code from the output that > > it can prove will never be invoked. The support for runAsync is > > similar in that the compiler constructs some kind of call graph of > > your code and any subgraph that's entirely behind a call to runAsync > > gets broken out into a separate "fragment". Each fragment is then > > separately downloadable. > > That's it exactly. > > > > Any > > code that's called from startWorking and nowhere else should also be > > separated from the main module, but anything that's called from > > method2 would necessarily be included with the main module. The > > analysis gets more complicated as you add calls to runAsync, but the > > traffic I've seen describing the design of runAsync makes it sound > > like the compiler should be able to handle any combination (barring, > > of course, any bugs that might still be lingering). > > It's a new tool, so we'll have to figure out the best coding idioms to > use it. I believe, though, that you're best off if you can factor > your code so that you don't have much of the same code reachable via > two runAsync calls. Instead, make one runAsync call, but let it take > a callback as a parameter. > > That is, don't do this: > > void method1() { > GWT.runAsync(/* ..method1 stuff.. */); > } > void method2() { > GWT.runAsync(/* ..method2 stuff, similar to method1 stuff.. */); > } > > Instead, do it like this: > > class MyModule { > interface Callback { ... } > static void runAsync(final Callback cb) { > GWT.runAsync(new RunAsyncCallback() { > void onSuccess() { cb.onSuccess(); } > void onFailure() { Window.alert("doh!"); } > } > } > > void method1() { > MyModule.runAsync(new Callback() { /*..method1 stuff..*/ }); > } > void method2() { > MyModule.runAsync(new Callback() { /*..method2 stuff..*/ }); > } > > > The compiler associates code fragments with calls to runAsync. So, > the idea here is that you help the compiler identify a good chunk of > stuff to associate with the runAsync call in MyModule.runAsync. If > you instead had method1 and method2 each call runAsync individually, > then the compiler would not be able to assign code to each of those > calls. > > > If you try this idiom, do make sure that you make your own callback > interface rather than usingRunAsyncCallback directly. You want the > compiler to know that, within MyModule.runAsync, the call to > cb.onSuccess() will only call the callbacks related to MyModule, not > to any other callback in the system. > > > Lex Spoon > >
-- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
