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