Just in case someone reads through this issue later - there is an
interesting discussion on using GIN with runAsync() over here -
http://code.google.com/p/google-gin/issues/detail?id=61


On Oct 30, 8:34 pm, Sripathi Krishnan <sripathi.krish...@gmail.com>
wrote:
> I haven't tried it out with GIN / DI.
> I am 'guessing' that it won't work , but I could be wrong.
>
> --Sri
>
> 2009/10/29 skrat <dusan.malia...@gmail.com>
>
>
>
> > Okay, that's kind of clear. Async Package (gateway class) looks nice,
> > but how does it fit within Gin and DI?
>
> > On Oct 26, 4:24 am, Sripathi Krishnan <sripathi.krish...@gmail.com>
> > wrote:
> > > 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-Readi...>.
>
> > > --Sri
>
> > > 2009/10/25 skrat <dusan.malia...@gmail.com>
>
> > > > 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 google-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=.


Reply via email to