4

It finally occurred to me that you are supposed to code up an ActivityMapper to parse/inspect the Place subclass that its getActivity(Place) method is passed, and to return the appropriate Activity to present to the user.

So this got me thinking: it makes sense that you need many different Place subclasses in your app, each representing a different bookmarkable URL/state.

But why would an app ever need more than 1 ActivityManager and Activity Mapper? It seems that there is no GWT-imposed restriction as to which Place gets mapped to which Activity...

I've heard some strategies where each display region gets its own ActivityManager. It seems too me like this just makes your project more complicated without providing any real benefits. Thanks in advance!

2 Answers2

7

Having coded an app with 10 such display regions, I can assure you it made our project much less complicated than what it'd have been with a single one (we could have removed a couple regions, then handled without activities, but still).

It proves the most useful when your display regions don't all change at the same time (generally, your main content changes more often than your peripheral or aside content): let's say you're editing a very complex entity and splitting this in tens of screens and there are things on the screen that are always the same (e.g. a summary of the top entity, to give context to the user).

It's also great to specialize your activities (separation of concerns, one concern per activity). For instance, on stackoverflow (if were a GWT app), the sidebar on the right could be in the same activity as the question and its answers, but if you separate things into distinct activities, each one becomes simpler and thus easier to maintain.

Finally, specialized activities can more easily be reorganized. E.g. a master-detail that's split into 2 activities can easily be changed from "master/child on the same screen" (same as most mail clients that display both the list of mails and the selected message) to "master to child and back to master" (like GMail by default, like most mobile apps). And this reorganization is not about changing the way you navigate within your app, its about reusing the same activities for different navigations depending on the form-factor (and with MVP, you can also adapt the views without changing the presenters).

That being said, there indeed are many apps where this isn't needed/required. It doesn't mean it's not useful.

Thomas Broyer
  • 64,353
  • 7
  • 91
  • 164
  • I just don't understand how multiple Activities can exist on the same page/screen, but boomark to the same URL inside the browser's address bar. For instance, if the sidebar on the right was a different activity than the question, that means you'd have two Places getting mapped to those 2 Activities, all at the same URL. How could we update the `SidebarActivity` while keeping the `QuestionActivity` the same, and at the same time, change the URL (and thus allowing it to be bookmarked inside the same state)? –  Nov 11 '12 at 00:37
  • Places/Activities don't require that the browser history be updated - each individual PlaceController/ActivityManager can just govern its own state. Think of several open browser windows at once - is there one history to rule them all? In the same way, you could have a specialized PlaceHistoryHandler that reads each Place in order and joins them somehow: "`page.html#place1:data|otherplace:|somethingoverhere:id123`". – Colin Alworth Nov 11 '12 at 00:57
  • @orionTurtle One single place maps to several activities. On StackOverflow (if it were a GWT app), a `QuestionPlace` (with an `id` property; for this question, that would be `#QuestionPlace:13326657` for instance) maps to a) the question and its answers, b) the "tagged" section in the sidebar, c) the "related" section on the sidebar. Each mapping is done in a different `ActivityMapper`, each one used by a distinct `ActivityMapper` instance governing the various _display regions_. I won't link again to my blog, but really go read it again, and again, and again until everything's clear for you. – Thomas Broyer Nov 11 '12 at 04:01
  • @ColinAlworth: while that indeed works, I'd however say that if you think you need something like that, then you have a UX and navigation problem. Framesets are deprecated for good reasons, let's not resurrect them through JS (minus the bookmarkability issue). YMMV – Thomas Broyer Nov 11 '12 at 04:03
  • Certainly - I was trying to outline an example of how A/P could be used to build existing apps that need such a state idea, not to suggest that embedding a browser in a browser would be a good idea. – Colin Alworth Nov 11 '12 at 05:45
  • @orionTurtle perhaps what you're missing here is that it isn't by accident that you're injecting the same `EventBus` into both your app's `PlaceHistoryHandler` and all your `ActivityManager`s. The History Handler fires `PlaceChangeEvent`s on the Event Bus which all your Activity Managers are registered with to listen and react to place changes. Thats how one place change affects multiple activities and screen regions. – Boris Brudnoy Nov 12 '12 at 20:45
2

Have a look to Thomas Broyer article on the subject http://blog.ltgt.net/gwt-21-activities-nesting-yagni/

I tried to implement his idea in a github project : https://github.com/ronanquillevere/GWT-Multi-Activities

Ronan Quillevere
  • 3,699
  • 1
  • 29
  • 44