Places
These are classes that encode information about where your program is located. You can do Place , which means: “I am on the main screen,” and the other means “I’m editing a user with identifier 52384. I think that the best name for them would be PlaceTag s, because they really don’t place themselves - they simply indicate where your program is located. The URL is bound to "Places" in PlaceHistoryMapper , in which you can say: "hey, #home should generate HomeScreenPlace and #edituser: 52384 should generate a EditUserPlace (possibly with a field set at 52384).
Activities
They start and stop your code. Each Activity has a start method, which is called when necessary. You define what “when necessary” means by creating an ActivityMapper that has a function called getActivity . getActivity accepts Place , and you need to decide which Activity to return. If Place is what you encoded to indicate “I am on the main screen,” you can return HomeScreenActivity , and if Place means “I am editing the client with identifier 523584,” you can return EditClientActivity . You can add methods or a constructor to an action to pass in an identifier of type 523584.
Eventbus
This is an object that different parts of your program use to communicate. If you don’t want it, you don’t need to know a lot about it - you can just connect it to where indicated in the Google documentation (with which you are connected)
ClientFactory
This is a centralized facility whose sole responsibility is to create other facilities. You can also skip this concept if you want to simplify the situation - you just miss the central organization of your facilities. The advantage is that if you want to disable them later, say, in the mobile version or in the testing version, you can do it right away in one place, and the rest of your program won’t have to change at all. You can also easily use the same objects when coordinating from a central location, so you don’t need to re-create the entire main screen every time someone moves to #home.
Your actual program
All this is just for navigation. Your models, views and presenters are configured in each Activity start() method, which the infrastructure creates when your application needs to move to a new location. In the start method, you must start your presenter (usually using a new instance) and start your screen (usually reusing the instance - the factory client is good for this). When you created your screen, you let the framework know by setting it as a widget for AcceptsOneWidget , which the infrastructure passed into your start method.
This is an incomplete but good addition to the above documents: http://code.google.com/intl/de-DE/webtoolkit/doc/latest/DevGuideMvpActivitiesAndPlaces.html