Communication between Presenters - New feature proposal for GWTP 2.0

[Danilo Reinert]

As a background, consider the following situation: There is a UsersPresenter responsible for presenting all Users. It has a link for AddUserPresenter, responsible for adding a new user. Whenever the UsersPresenter calls the AddUserPresenter, it wish to execute some logic when the AddUserPresenter is done (for instance, get all users from the server or get this recently created user and add to the users grid).

As you can see, we have some points to consider.

1) A Presenter has a purpose. Having a purpose, it should have some method that would finish its cycle.

2) A Presenter can return a result and some data.

These exposed situation and considerations reminds us the Activity concept used in Android.

If you're not familiar with Android, please consider reading this article (link), which will briefly explain the Result mechanism into Activities. Also see this post for understanding how an Activity finishes passing a result.

If you find these ideas reasonable, I propose two alternative solutions for promoting this new Presenter communication feature.

1) Use the same solution adopted by Android.

Basically we could apply this "Activity design pattern" into GWTP Presenters. So every Presenter would have a method called "onResult(...)" and another called "finish()". Additionaly, the reveal process would have an additional "revealWithResult(...)" mechanism. Finally, GWTP could add a new component similar to the "Bundle" used in Android for transporting data.

2) Use a more appropriated solution for the GWT nature.

Instead of implementing this bunch of changes and make GWTP similar to Android, we could just add two new methods to the Presenter and fill this need. Presenter would have a protected no-argument "finish()" method informing that the Presenter finished its cycle. Additionally, the Presenter would allow a public registration of a disposable callback. Whenever the finish method is called inside the Presenter, it executes the registered callback. After the callback execution, it is deregistered from the Presenter. For starting this cycle, one Presenter would reveal another passing a callback as an argument. This callback can expose the target Presenter, so the revealing one can access its properties and retrieve desired data.

this second solution is fully backwards compatible, it would require few changes and they would only be additions.

Note that this exposed situation could not be satisfactorily resolved using only Presenter's lifecycle methods. (Android Activities also have lifecycle methods, but they are not used with this intent).

So, that's my main suggestion for the 2.0 roadmap. I'm here for further clarification.

--

D. Reinert

[Danilo Reinert]

Sorry, I forgot the links.

http://developer.android.com/training/basics/intents/result.html

http://tylenoly.wordpress.com/2010/10/27/how-to-finish-activity-with-results/

--

D. Reinert

[Julien Ortega]

Hi Danilo,

I understand the need and the concept. My only question would be, why not using the eventbus to register theses events between presenters ? I think it would be the way for inter presenter communication ?

I understand it would add a lot of new event/handlers, but it would keep a common and simple way to comunicate during or after the execution of a presenter.

I think it could be a useful addition, my question is only to be sure I got the big picture.

Regards

Julien

[Danilo Reinert]

Weel appointed Julien.

In fact, that's the way I'm doing right now. But the reason I'm suggesting it, you already realized.

I have to implement a lot of code for establishing this communication between inter-related Presenters. Events, Handlers (sometimes third part handlers because Popup Presenters cannot reveal themselves). I end-up with too many classes to do this simple thing.

Additionally, the main point I'm focusing with this communication pattern is the ability to directly grab data from the target Presenter. Other way, we have to pass data within the Events.

Also think about when we have two or more Presenters that calls the same target Presenter. When the target Presenter finishes, it fire an close event. It happens that there are more than one Presenter listening to this event. Who should the target Presenter redirect? Who called him? How can I ensure that just one listener Presenter listen to this specific event?

We ended up having to implement laborious logic just to ensure that only intended Presenter is treating the target return on your time.

Can you see how complex this can become, as more Presenter listen the finishing of one target Presenter?

--

D. Reinert

[Julien Ortega]

OK, good point.

It clarify the need.

Thanks. 

[Kevin Smit]

If events are too much boilerplate for you, check out gwteventbinder (https://github.com/google/gwteventbinder) created by Erik Kuefler and introduced at I/O this year. You can check out the presentation here: https://developers.google.com/events/io/sessions/331474237

[Asier]

On Viernes 14 junio 2013 07:16:19 Kevin Smit escribió:

Nice addition that GWT Event Binder but with PresenterWidgets there are some problems.

The event binding performed by that library doesn't fit well with gwtplatform's handler
registration inners; the automatically-registered handlers aren't cleared when the PW is
unbinded so each time the PW is created the "onEventLaunched" @EventHandler anotated
methods will be executed again and again.

Regards

[Danilo Reinert]

As I stated before, Events are not the problem. 

The main issue is the flux of information and the concept of finishing a Presenter's cycle of use.

Instead of grabbing the intended result from the EventBus (for this specific case of a Presenter returning some information), the Presenter could provide some feature for achieve this. Executing a disposable callback when the Presenter finishes would be a good workflow.

--

D. Reinert

[Danilo Reinert]

I made a pull request in order to clarify how would function the disposable callback along with the finish method.

My idea is that the finish method would trigger the closing lifecycle methods, but I can't see in what level yet (maybe until the onHide).

--

D. Reinert

[Christian Goudreau]

I Invite everyone to jump into the discussion on the pull request as well.

https://github.com/ArcBees/GWTP/pull/273

--
You received this message because you are subscribed to the Google Groups "GWTP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gwt-platform...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Christian Goudreau

www.arcbees.com

[Danilo Reinert]

It would be great to have more support in this discussion.

Unfortunately, I had no time to finish the initial proposal yet. In the meanwhile, more ideas are welcome.

--

D. Reinert

[Danilo Reinert]

For those interested, there are updates on this PR.

https://github.com/ArcBees/GWTP/pull/273

--

D. Reinert

[Drew Spencer]

This seems like a great idea. Did it go anywhere in the end? Is it still on the back burner or has it been scrapped?

Drew

[Christian Goudreau]

Neither, design decisions like these are just slow to adopt since they require a lot of changes, but not only code changes, habit changes for the user. 

Before doing anything, we need to agree on the appropriate behaviour, have a proof of concept, then promote it.

I didn't want to discourage you Danilo at the time and would have loved for you to continue on that road until we all agree on the appropriate pattern to implement :D

For more options, visit https://groups.google.com/d/optout.

--

Christian Goudreau | CEO - Président

M: 1.877.635.1585 | S: christian.goudreau

ArcBees | Blog | Facebook | LinkedIn