Geek Answers Handbook

GWT - Separating the role of the speaker from the activity

What benefits can be achieved as a result of the abandonment of the role of leader in the activity?

What are the roles / challenges that can be shared in order to separate the activity from the lead?

Why do you want to divide them into two different problems?

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

Give examples, pros or cons.

+6
source share
2 answers

I see two main reasons to separate speakers from actions: reuse and verifiability.

A real use case for reuse: we have an illustration object with properties such as a photographer, copyright, and the shooting date that may be associated with documents. The legend of the relationship between the document and the illustration. You can edit both the illustration and the legend on your own screen, but we also wanted the illustration to be edited on the legend screen. Therefore, we made a presenter for the illustration screen. The activity of the illustration is really a thin wrapper around this host, and the activity of the legend is a little more complicated, but it repeats the presentation and presentation. Responsibility for the actions is to provide RequestContext and << 21> (the save / cancel buttons are in another action, similar to the actions in Google Groups).

Hypothetical reuse options:

  • for different form factors, you want to aggregate things on one screen or separate them on your own screen (for example, a master / part), and when you combine them, having two actions may not be ideal. Using subtle actions in the phone's form factor allows you to reuse components (presenter / view) as part of one action in the tablet or desktop form factors.
  • reuse of the same presenter on different platforms: you can use the same presenter in an Android application and a web application (and maybe even an iOS application via java2objc ), the view would be a native Android view or a GWT based view , and Android actions and / or fragments, as well as GWT actions and locations, will handle navigation.

On testability (this is theoretically), you could then test your speaker without any problems in the life cycle of the activity (mocking the presentation), and then separately check the life cycle (whether it initializes and clears the delivery of the presentation, retrieves / caches data, etc. mocking the lead).

See also commit message https://code.google.com/p/google-web-toolkit/source/detail?r=10185
Ray's idea was to make MVP a widget implementation part, just like the cell widgets that internal presenters use today. From the outside, they are just widgets that you can create as you want; internally they use MVP so that you can test them unnecessarily <<22>.

+7
source

First of all, thanks for the question that pushes me to the longest research. :)

According to Thomos Broyer here .

Activity cannot talk to widgets that the presenter can perform.

Two main concerns:

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

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

here, RequestFactory passes the data to the Activity , which then gives the Presenter which subsequently passes its widget .

2- getting data from widgets to server

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

More articles:


All Articles