Also, this paragraph from Code Splitting wiki<http://code.google.com/p/google-web-toolkit/wiki/CodeSplitting>may be useful -
A less common example is that you expected an item to be exclusive to some > split point, but actually it's only included in leftover fragments. In this > case, browse to the item via the "total program" code subset. You will then > get a page describing where the code of that item ended up. If the item is > not exclusive to any split point, then you will be shown a list of all split > points. If you click on any of them, you will be shown a dependency chain > for the item that does not include the split point you selected. To get the > item exclusive to some split point, choose a split point, click on it, and > then break a link in the dependency chain that comes up. > --Sri 2009/10/25 Sripathi Krishnan <[email protected]> > Maybe somebody from google will confirm this, but I doubt you are going to > achieve code splitting by using proxies or interfaces, or by using any > generic parameterized approach. > > A piece of code will end up in split-point-1.js *only if* it is always > being used from within GWT.runAsync(). If a class can be used from two > separate GWT.runAsync() method blocks, it is going to end up in the > left-overs block. > > Now here is my understanding of the situation (of course I may be wrong) - > > - You have two instances of the class AsyncLoader, say LoaderA and > LoaderB, with two unique providers - say ProviderA and ProviderB > - GWTC recognizes that there will be two GWT.runAsync() blocks, which > is why it creates two split points > - But it cannot guarantee that LoaderA will always get ProviderA, and > so it should put the code for ProviderA in split-point1.js > - So, it knows that the entry point is not using ProviderA or ProviderB > - which is why it is not in the initial download fragment. But it cannot > guarantee it will always be used from a unique code fragment, which is why > it ends up in the left-over fragment. > - When you use the inline implementation, you will hard-code the actual > provider - and hence things will work. > > > The only pattern that works well is Googles recommended "Async Package > Patter". See this > presentation<http://dl.google.com/io/2009/pres/Th_1045_TheStoryofyourCompile-ReadingtheTeaLeavesoftheGWTCompilerforanOptimizedFuture.pdf>. > > > --Sri > > > 2009/10/25 skrat <[email protected]> > > >> I'm trying to split my code using sort of proxies, where I reuse >> parametrized RunAsyncCallback class. This class has basically just >> reference to Gin Provider of the real module class. When I use this >> for loading one module, it works perfectly, and I'm getting nice and >> correct location of split point in report. When I use this second >> time, loading different module proxy which uses the same >> RunAsyncCallback class, both split points happen to be in Leftovers >> code. Yet, split point on my proxies are still listed in report, but >> with the same minimal (386) size. >> >> I tried to use inline implementation of RunAsyncCallback instead, and >> surprise! Split points worked correctly again. >> >> Here is my parametrized RunAsyncCallback class: >> >> class AsyncLoader implements RunAsyncCallback { >> >> private ProjectPresenter parent; >> private PlaceManager placeManager; >> private Provider<? extends AbstractLabeledPresenter> real; >> >> AsyncLoader( ProjectPresenter parent, >> Provider<? extends AbstractLabeledPresenter> real, >> PlaceManager placeManager ) { >> >> this.placeManager = placeManager; >> this.parent = parent; >> this.real = real; >> } >> >> @Override >> public void onFailure(Throwable reason) { >> // TODO Auto-generated method stub >> >> } >> >> @Override >> public void onSuccess() { >> AbstractLabeledPresenter mod = real.get(); >> parent.addModule( mod ); >> >> if ( mod.hasToken( History.getToken() ) ) { >> mod.revealDisplay(); >> parent.show(mod); >> placeManager.fireCurrentPlace(); >> } >> >> } >> } >> >> This is inner class defined in AbstractLabeledPresenter, that's the >> same one I'm proxying and loading with GWT.runAsync. @Inject >> annotation is not present because injection is done on proxy class >> which in turn instatiates AbstractLabeledPresenter$AsyncLoader. >> >> Not sure whether this is bug, but I can't see any linking or any other >> rason why that code should end up in Leftovers and have empty, zero >> size split points. >> >> >> >> > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
