GWT - Separating role of presenter from activity
Asked Answered
G

2

6

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.

Gauleiter answered 8/3, 2013 at 17:6 Comment(0)
T
7

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.

Tedi answered 9/3, 2013 at 12:34 Comment(1)
Someone had told me the same thing before I had read your answer but not as detailed. This is the answer I am looking for to help me devise my coding strategy. Thk u.Gauleiter
C
0

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) 
Cockatiel answered 9/3, 2013 at 8:54 Comment(4)
In the link you give, an activity is simply a presenter linked to a place whereas the widgetpresenters are presenters with no associated place. Place and Presenters are separated topics. Nothing prevent you from having a Presenter which has sub-presenters inside. Now you can decide to handle all communications in you superpresenter but I believe it makes the widgetpresenter not reusable elsewhere which is a bad point.Throw
That means Activity is underlying the Presenter(Nothing stops you to say as an filter) or either i misunderstood the question :)Cockatiel
And one thing is sure that The Activities are just one step top on the layer to the presenters ,Which i came to know today.Correct me if I am wrong.Cockatiel
"Activity cannot talk with widgets,which presenter can do" - Could you please elaborate because a presenter should speak thro the view interface without managing the widgets in the view directly. The presenter should decouple itself from addressing widgets directly.Gauleiter

© 2022 - 2024 — McMap. All rights reserved.