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.

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.

David

-- 
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.

Reply via email to