Thanks Thomas. This is clear now.
On Nov 19, 9:20 am, Thomas Broyer wrote:
> On 18 nov, 22:40, david wrote:
>
>
>
> > On Nov 18, 12:42 pm, Thomas Broyer wrote:
>
> > > If I understand you correctly, you'd like to have a glasspanel above
> > > the "previous activity" while the "new one" starts?
On 18 nov, 22:40, david wrote:
> On Nov 18, 12:42 pm, Thomas Broyer wrote:
>
> > If I understand you correctly, you'd like to have a glasspanel above
> > the "previous activity" while the "new one" starts? (until it calls
> > AcceptsOneWidget#setWidget to "reveal" itself) ?
> > IMO you should d
On Nov 18, 12:42 pm, Thomas Broyer wrote:
> If I understand you correctly, you'd like to have a glasspanel above
> the "previous activity" while the "new one" starts? (until it calls
> AcceptsOneWidget#setWidget to "reveal" itself) ?
> IMO you should do this on your AcceptsOneWidget itself, not
On 18 nov, 16:42, david wrote:
> "ActivityManager always calls setWidget(null) in between activities,
> but just in
> case...)"
>
> Its great that 2.1provides this intercept capability however I'm now
> unclear as how to present a glass panel in the new activity if the
> dom is already cleared
"ActivityManager always calls setWidget(null) in between activities,
but just in
case...)"
Its great that 2.1provides this intercept capability however I'm now
unclear as how to present a glass panel in the new activity if the
dom is already cleared before I get there. Am I missing something
ab
On 17 nov, 09:23, Baloe wrote:
> Thanks for the tips!! I'll look into the EagerSingleton.
>
> However, regarding the class Root: I don't really want to change it, I
> want to remove it completely. It's not necessary for anything at all,
> it's just because we need to start the code. This program
Thanks for the tips!! I'll look into the EagerSingleton.
However, regarding the class Root: I don't really want to change it, I
want to remove it completely. It's not necessary for anything at all,
it's just because we need to start the code. This program goes to our
default Place (see getDefaultP
Why make the Root a inner class? I think it should be either a static
nested class or a top-level class.
Also, you can remove a lot of your boilerplate and ugly news there
using GIN and binding asEagerSingleton. In this way you could bind:
- Root
- PlaceController
- ActivityMapper
- MyActivityMana
Hi all,
We are using MVP as much as possible, but it has been a pain so far,
not a lot of documentation. There is one thing that we really couldn't
get right. Please see how much boilerplate blabla this application
needs, and see how ugly the class at the end is. We don't want the
class near the e
