Group items tagged

An activity in GWT 2.1 is analogous to a presenter in MVP terminology. It contains no Widgets or UI code. Activities are started and stopped by an ActivityManager associated with a container Widget. A powerful new feature in GWT 2.1 is that an Activity can automatically display a warning confirmation when the Activity is about to be stopped (such as when the user navigates to a new Place). In addition, the ActivityManager warns the user before the window is about to be closed.

A place in GWT 2.1 is a Java object representing a particular state of the UI. A Place can be converted to and from a URL history token (see GWT's History object) by defining a PlaceTokenizer for each Place, and the PlaceHistoryHandler automatically updates the browser URL corresponding to each Place in your app.

A key concept of MVP development is that a view is defined by an interface.

How I understand things, a display region is a dynamic part of a webpage; Depending on the place you're at, a display region is populated with a specific activity. A activity manager is the manager of a display region and decides the right activity to show up for a given display region when a certain page is showing. So, in terms of your question : a display region can be a dynamic menu, a sidebar, a logout/login link.... not the entire group. An example page with menu displayregion, maincontent displayregion, sidebar displayregion example page #ContactDetailsPage:FooBar +> sidebar display region will be instructed by the sidebar- activitymanager to start the activity GrandChildrenActivity (display grandchildren in side bar) +> maincontact display region will be instructed by the maincontentarea-activitymanager to start the activity ContactDetailsActivity (display contact details in main content area) +> menu display region will be instructed by the menu-activitymanager to start the activity MenuActivity (show the menu) example page #Login +> sidebar display region will be instructed by the sidebar- activitymanager to display nothing (NULL) +> maincontact display region will be instructed by the maincontentarea-activitymanager to start the activity LoginActivity (display login page) +> menu display region will be instructed by the menu-activitymanager to start the activity WelcomeActivity (show a welcome msg) etc etc.

places and activities are orthogonal to each other a webpage consists of many display regions every display region is managed by a activity manager when a place change occurs, the activity managers are notified and they decide the activity to live inside the display region

Actually HelloMVP is a really confusing example, because - the activities are called HelloActivity and GoodbyeActivity - the places are called HelloPlace and GoodbyePlace but the activities and places are orthogonal to each other. That doesn't help to get a clearer understanding.

Ray Ryan - These posts are right on the money, Thomas. I think you hit the problem with this approach too: you still need nested Place objects, and those are a nuisance to make. E.g., in a master detail you might need to record both the page of the master list that is showing as well as which detail set. Maybe the thing to do is add a CompositePlace to GWT?Sep 14

Ray Ryan - The idea is that parents are an optical illusion. There is an activity that knows how to show lists of things. There is another that knows how to show details. In one arrangement of your app they may be on the screen at the same time. In another (*cough* mobile *cough*), they aren't. They really shouldn't know about each other.Sep 14

the key concept here is that an Activity can be a Presenter but a Presenter is not necessarily an activity.Oct 26DeleteUndo deleteReport spamNot spamRay Ryan - Exactly: not every presenter needs to bother being an activity.Oct

there's absolutely nothing in GWT proper related to MVP actually; I refuse to call Activities an "MVP framework", it has nothing to do with MVP in my opinion

try to disconnect activities from MVP: Activities don't force you to do MVP, and you'll use MVP beyond Activities.

I think the overall idea of activities is that they are short-lived instances, so they're effectively "lazily created" (actually, a new instance is created each time one is needed) and they don't need to be "awoken" because if they're not currently in use they're already "dead" and garbage collected. The ActivityManager (actually its associated ActivityMapper) will decide whether a particular activity is needed (and then instantiate it, possibly going through a GWT.runAsync for code splitting); the activity will listen to events its interested in *during its lifetime* (e.g. whether some object has changed or has been added or deleted, so it can update its view); but when it's done (stopped or cancelled), it's simply thrown away (the event bus passed to the start() method is a ResettableEventBus so all handlers have been automatically unregistered for you, which as a side effect allows the activity to be garbage collected). This is the (AIUI) intended use, but nothing forces you to write such short-lived instances: you can very well use singletons, but then you'll have the additional task of maintaining state between "runs" (start/stop or start/cancel), in which case your activity can listen to events from the event bus after being stopped/cancelled (just use the "real" event bus instead of the ResettableEventBus passed to the start() method); but it won't "ask to be revealed": navigation is handled at another layer, triggered on the PlaceController and handled by ActivityManagers.

I think the overall idea of activities is that they are short-lived instances, so they're effectively "lazily created" (actually, a new instance is created each time one is needed) and they don't need to be "awoken" because if they're not currently in use they're already "dead" and garbage collected. The ActivityManager (actually its associated ActivityMapper) will decide whether a particular activity is needed (and then instantiate it, possibly going through a GWT.runAsync for code splitting); the activity will listen to events its interested in *during its lifetime* (e.g. whether some object has changed or has been added or deleted, so it can update its view); but when it's done (stopped or cancelled), it's simply thrown away (the event bus passed to the start() method is a ResettableEventBus so all handlers have been automatically unregistered for you, which as a side effect allows the activity to be garbage collected). This is the (AIUI) intended use, but nothing forces you to write such short-lived instances: you can very well use singletons, but then you'll have the additional task of maintaining state between "runs" (start/stop or start/cancel), in which case your activity can listen to events from the event bus after being stopped/cancelled (just use the "real" event bus instead of the ResettableEventBus passed to the start() method); but it won't "ask to be revealed": navigation is handled at another layer, triggered on the PlaceController and handled by ActivityManagers.

your ChatBoxPresenter isn't related to a "place", i.e. it's "awoken" based on a "business event", not a navigation event; and in other words, it's not an Activity: case made. Activities (ActivityManager) is limited in scope to reacting to place changes and navigation (not that you couldn't use the Activity "contract" in other scenarios, such as your "chat box", but the ActivityManager wouldn't be the right tool for the job, you'd have to find/write another "activity manager" for your different use case). In other words: GWT 2.1 Activities won't replace GWTP as a whole (and I believe, as I already said in the past, that it's not its goal either).

he generally adopted way of doing things in GWT is to have custom events go through the event bus. In this case, you're talking about "navigation", so maybe the concept of "place" would be better than "just" some custom event. I encourage you to look at gwt-platform, gwt- presenter and other MVP frameworks for GWT, and/or look at the Activity concept from the upcoming GWT 2.1. Using actvities, you'd have an ActivityManager managing your "center". The tree would use the PlaceController.goTo to navigate to a new "place". An ActivityMapper (that you passed to the ActivityManager in the constructor) would map the place to an Activity (a presenter), and the ActivityManager will manage the current Activity for the display it manages, i.e.it will stop() the current activity if its ok (willStop returns true) and then only start the new Activity, which will call the Display back to show its view. The tree would probably also listen to PlaceChangeEvent on the event bus to update the selected item depending on the current place (in case some other component calls the PlaceController.goTo)

he generally adopted way of doing things in GWT is to have custom events go through the event bus. In this case, you're talking about "navigation", so maybe the concept of "place" would be better than "just" some custom event. I encourage you to look at gwt-platform, gwt- presenter and other MVP frameworks for GWT, and/or look at the Activity concept from the upcoming GWT 2.1.

Using actvities, you'd have an ActivityManager managing your "center". The tree would use the PlaceController.goTo to navigate to a new "place". An ActivityMapper (that you passed to the ActivityManager in the constructor) would map the place to an Activity (a presenter), and the ActivityManager will manage the current Activity for the display it manages, i.e.it will stop() the current activity if its ok (willStop returns true) and then only start the new Activity, which will call the Display back to show its view. The tree would probably also listen to PlaceChangeEvent on the event bus to update the selected item depending on the current place (in case some other component calls the PlaceController.goTo)

* I notice that you're injecting instances of your activities into your activity mapper. Activities are meant to be fairly lightweight objects, as opposed to the views that represent them, so they don't need to be singletons (which they effectively are since you have a single app with a single injected activity mapper). It's probably not necessarily a problem unless your activities have state associated with them (such as the entity that the user is currently working with), which you have to be careful to clear out between uses with different data. The same can be said about places.

My understanding is that you only want a single area of the shell to be managed by one ActivityManager. So if you have an entire shell/layout with more than one area that changes, let's say a main content area as well as a context menu (If I have MainAppPlace and SettingsAppPlace and OtherAppPlace both of which extend MainAppPlace, and you want to show a different context menu for Place of type SettingsAppPlace and places of type OtherAppPlace) I would just have main Shell that has a SimplePanel for content and Simplepanel for context_menu I just use an ActivityManager to control one spot of the main layout. is this not right? do you want your activitymanager controlling more than one area??

the MVP pattern has nothing in common with GWT's Place/History management framework (often referred to as GWT MVP). If you use GWT places/activities your app will gain bookmarkable urls that represent a place/application state and whenever such a url is visited a corresponding activity will be started. This activity is then responsible for attaching some UI/widgets to an area of your webpage. If this UI is complex and has user interaction elements then you could implement this UI with the MVP pattern to separate the UI from the logic that will be performed when the user interacts with this UI. And once you decide to use the MVP pattern then its in most cases easier to let the activity be the presenter. But its also possible to implement a separate presenter and let the activity hold a reference to it.

PlaceHistoryHandler has been split into a concrete PlaceHistoryHandler and the PlaceHistoryMapper interface, which you're free to implement yourself or use as before, giving your sub-interface to GWT.create() so that it generates the implementation from the @WithTokenizers annotation (and/or factory if you're using PlaceHistoryMapperWithFactory); this approach is similar to the ActivityManager vs. ActivityMapper, with the added generator for the mapper based on PlaceTokenizers and @Prefix.

Activity.Display now is com.google.gwt.user.client.ui.AcceptsOneWidget, which is implemented by SimplePanel (showActivityWidget is thus renamed as setWidget). IsWidget has been moved to com.google.gwt.user.client.ui and is now implemented by Widget (which returns itself); this means that if your view classes extends Widget (most views extend it through Composite) you no longer have to implement the asWidget method. In addition, all widgets now accept IsWidget as argument where they already accepted Widget.

How to navigate To navigate to a new Place in your application, call the goTo() method on your PlaceController. This is illustrated above in the goTo() method of HelloActivity. PlaceController warns the current Activity that it may be stopping (via a PlaceChangeRequest event) and once allowed, fires a PlaceChangeEvent with the new Place. The PlaceHistoryHandler listens for PlaceChangeEvents and updates the URL history token accordingly. The ActivityManager also listens for PlaceChangeEvents and uses your app's ActivityMapper to start the Activity associated with the new Place. Rather than using PlaceController.goTo(), you can also create a Hyperlink containing the history token for the new Place obtained by calling your PlaceHistoryMapper.getToken(). When the user navigates to a new URL (via hyperlink, back button, or bookmark), PlaceHistoryHandler catches the ValueChangeEvent from the History object and calls your app's PlaceHistoryMapper to turn the history token into its corresponding Place. It then calls PlaceController.goTo() with the new Place. What about apps with multiple panels in the same window whose state should all be saved together in a single URL? GWT 2.1 does not attempt to provide a generic implementation of a composite Place; however, your app could create a CompositePlace, CompositeActivity, and CompositePlace.Tokenizer classes that delegate to the constituent members. In this case, only the composite objects would need to be registered with your app's ActivityMapper and PlaceHistoryMapper.

although we can't map a 1-Many relationship between a Place and an Activity, you can in fact map multiple places to the same activity and differentiate between the place with multiple init() methods in the activity.

've started prototyping with Activities and can now give some more feedback on how it compares to my previous own implementation of a PlaceManager and how I used it with MVP.

often your places are "parameterized", think of a detail/edit screen for example that needs the model's id. The token is a generic way to provide additional information (via the URL) to the place (i.e. the activity/-ies), i.e. "#editFoo:42". You can of course re-use one place to dispatch to several activities based on the token. See the (currently not used) for ProxyPlace and ProxyListPlace in the Expenses sample for an example.

The kinds of changes to Activities and Places we're contemplating for future versions of GWT are primarily along the lines of using annotations and generators to automate the creation of PlaceTokenizers and ActivityMappers, for example. We're not talking about wholesale replacement, as we strive for API backward compatibility with each release.