RunAsyncCallback

[skrat]

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.

[Sripathi Krishnan]

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.

--Sri

2009/10/25 skrat <dusan.m...@gmail.com>

[Sripathi Krishnan]

Also, this paragraph from Code Splitting wiki 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 <sripathi...@gmail.com>

[skrat]

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>

[Sripathi Krishnan]

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.m...@gmail.com>

[Sri]

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>