GWT - Separating role of presenter from activity

Question

What advantages could be gained from divesting the role of presenter from an activity?

What are the roles/concerns that could be separated in order to dissect an activity from being a presenter?

Why would you want to separate them into two distinct concerns?

Under what circumstances would it make sense not to unify them?

Give examples, pros or cons.

Answer 1

I can see two main reasons to separate presenters from activities: reusability and testability.

Real use case for reusability: we have an illustration entity with properties like the photographer, copyright and date of shooting, which can be linked to documents. The legend of is on the relationship between the document and the illustration. You can edit both the illustration and the legend on their own screen, but we also wanted that the illustration could be edited from the legend screen. So we made a presenter for the illustration screen. The illustration activity is a really thin wrapper around that presenter, and the legend activity is a bit more complex, but reuses the presenter and view. The activities' responsibility is to provide the RequestContexts and do the fire() (the save/cancel buttons are on another activity, similar to the actions on Google Groups).

Hypothetical use cases for reusability:

• for different form-factors, you want to aggregate things on the same screen or separate them on their own screen (e.g. master/detail), and when you aggregate them, having two activities might not be ideal. Using thin activities in the phone form-factor allows you to reuse the components (presenter/view) within a single activity in the tablet or desktop form factors.
• reusing the same presenter on different platforms: you could possibly use the same presenter on an Android app and a web app (and even possibly an iOS app through java2objc), the view would be a native Android view or a GWT-based view, and the navigation would be handled by Android activities and/or fragments vs. GWT activities and places.

About testability (this is theoretical), you could then test your presenter without the hassle of the activity lifecycle (mocking the view), and then separately test the lifecycle (whether it correctly initializes and cleans up the presenter, fetches/caches the data, etc. mocking the presenter).

See also the commit message of https://code.google.com/p/google-web-toolkit/source/detail?r=10185
Ray's idea was to make MVP an implementation detail of widgets, just like cell widgets use internal presenters today. From the outside they're just widgets that you can compose tha way you want; on the inside they use MVP so you can test them without the need for a GWTTestCase.

Answer 2

First of all two Thanks for question which pushes me in to the longest research ever . :)

According to Thomos Broyer here.

Activity cannot talk with widgets,which presenter can do.

Two main areas of concern:

1- getting the data into the widgets: how can this design be improved ?

Server (RequestFactory) ---> Activity ---> WidgetPresenter ---> Widget

here, RequestFactory hands in data to Activity, which then gives it to the Presenter which subsequently hands it to the widget.

2- getting the data from the widgets to the server

widget ---> WidgetPresenter ---> Activity ---> Server(RequestFactory)