On 18 nov, 22:40, david <[email protected]> wrote:
> On Nov 18, 12:42 pm, Thomas Broyer <[email protected]> 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 from
> > within your activities:
> > final SimplePanel realDisplay = new SimplePanel();
> > myActivitymanager.setDisplay(new AcceptsOneWidget {
> > public void setWidget(IsWidget w) {
> > if (w == null) {
> > // show a glass panel
> > } else {
> > // hide the glass panel, then:
> > realDisplay.setWidget(x);
> > }
> > }
>
> > });
>
> This looks like a good example for a basic dialog not a separate
> activity that needs to be render its view in a glasspanel. So let me
> try an give a better example.
>
> There are actually two scenarios which I believe the invocation of
> showWidgetr(null) in myActivityManager.onPlaceChange(.. ) trips me
> up.
>
> Scenario 1) Consider an app with a dozen or more independent
> Activities. Let's say one of these independent activities will
> manifest in a popup ( layer.. glasspanel... ). This is not a simple
> dialog but an independent activity and it may appear above any of the
> other activity places in the app. Using the pattern described in MVP
> part I or part II this was fairly straightforward because the widget
> representing the container was not touched until the Presenter
> responsible for rendering itself as a glass panel was ready to
> initialize its view. However with the latest mcv 2.1 framework ,
> the container is cleared as a result of the request to go to the new
> place . See show showWidgetr(null) in
> myActivityManager.onPlaceChange(.. ) . As a result, the glasspanel
> renders over a blank page.
If you ActivityManager's Display always displays a glasspanel over the
previous activity when called as setWidget(null), then I guess you
won't have the problem.
You could have a problem however if this ActivityManager's could
receive 'null' values because there's no activity returned by the
associated ActivityMapper; but I'm pretty sure that wouldn't happen in
your case, and you could workaround this by having your ActivityMapper
return a NullActivity instead that calls setWidget(new IsWidget()
{ public Widget asWidget() { return null; }) (because in the code I
gave, you only test w==null, not Widget.asWidgetOrNull(w)==null, so
there's a difference between a null IsWidget and an IsWidget that
returns a null Widget).
> Scenario 2) Consider View1 in Activity1 with a goToActivity2
> button. Activity2 makes a fairly long , albeit async, rpc call so
> a progress indicator is required. In addition , the View2 served by
> Activity2 has nothing interesting on it except for the data coming
> back from the async rpc call. Therefore it would be better to show
> the progress indicator on View1's goToActivity2 button. Using the
> pattern described in MVP part I or part II one would simply call the
> container.setWigdet(view2) in the onSuccess method of the RPC
> call. However with the latest mcv 2.1 framework , the container
> is cleared as a result of the request to go to the new place . See
> show showWidgetr(null) in myActivityManager.onPlaceChange(.. ) . As a
> result, View1 clears immediately and an blank page is shown until
> the rpc comes back in Activity2.
Again, using the code I gave (minus the glass panel, but still special-
casing 'null'), you wouldn't have the problem, and it's the
responsibility of Activity1/View1 to display the indicator in the
button.
--
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.
