Push events in the data layer to the presentation layer

[risayew]

What about update events in the data layer and how to notify about them the presentation layer? Let's suppose, that some third party service has updated some user data in the data base.

Is event bus approach good for that?
For example, we will define some event class in the domain layer: UserUpdatedEvent. Some presenter in the presentation can subscribe/unsubscribe for this event on the event bus. Data layer can post the UserUpdatedEvent on event bus ...

[erikash]

+1 on the question.
I would like to add that the current implementation creates a new "UserListSubscriber" for example for each call to the UseCaseLayer.
How would you like to handle common data (let's say that we show the UserList in another screen/widget as well)?
A UserListFetchedEvent could be broadcasted to more than "one" subscriber.

[Trikke]

A possibility is to implement an Event Bus or Event Aggregator in the Data Layer. That Bus can be injected via Dagger in a Presenter. That Presenter would then subscribe (and also unsubscribe on destruct) to certain types of Events, which are pushed up from the Data Layer.

Be aware that Event Busses come with their own downsides, as this allows loose coupling between layers and in larger apps can quickly result in event spaghetti. Also, events indicate that something has happened, not that something should happen. So a UserUpdatedEvent means that the Presenter knows a User is updated and make a call to the Repository ( through a UseCase ) to get the new user.

[erikash]

@Trikke, thats where I was going.. so why not make it a standard?
Use UseCases for invoking/triggering actions and subscribe to results/data via bus events?

[spirosoik]

@Trikke I will absolutely agree with you dude for the spaghetti. Here we have a big event spaghetti that's why in the new version we removed the event bus.

[Trikke]

@erikash i wouldn't make it a standard because of my reasons against it. This repository is implemented in such a way now that allows tight coupling between components in layers and the flow of data is also tight and easy to follow from Presentation down to Data and up again.

Event busses are used for a specific set of problems and people are quick to use them to solve any of their problems since they are easy to implement.

[Trikke]

So Event busses can be useful in the case of "Data layer lets the Presentation layer know a User was updated in a background service to we can show a toast". But they are not to be used in case of Commands, eg: "User clicks on a button to update a user". As said, events indicate that something has happened, not that something should happen.

[erikash]

@Trikke , I agree with you events should be in the past tense.
You contradicted yourself with the example you provided...
"When a user clicks on a button to update a user" should be handled via a Use Case class.
The response of the updated user should be agnostic to the trigger, whether its a users "click" or a background service or another platform altogether...

[Trikke]

Explain why the response of an action should be separated from the action itself?

The way i see it there is a difference between Events and Actions. An Event for me is just something that is thrown up to indicate a state change and notifies listeners, it is usually triggered externally. An Action is something entire different and encapsulates an entire flow of information. In the case of the button click, it is logic to have all components tightly coupled and expect a result back after an Action has happened.

So for a User clicking on a button, you would have :
GUI -> domain -> data -> cloud service -> callback -> data -> domain -> GUI

If you would have a background service that polls you cloud service for updates, then Events makes sense.
Background service -> cloud service -> callback -> push event -> listeners are notified

[erikash]

An action response most of the time would be an "event".
For example, if your product has multiple platforms : web, ios, android.
The used can take most of the actions on any of the platforms, those actions trigger events (state changes) which should be handled in all platforms.
That's why i'm suggesting that all action "events" should be handled the same way...
If you have two handlers for a user update "click" callback from:
GUI -> domain -> data -> cloud service -> callback -> data -> domain -> GUI

and another for a "click" in another platform:
Background service -> cloud service -> callback -> push event -> listeners are notified

Then your risking duplication bugs and other technical difficulties...
Does the things i'm saying make sense?

[Trikke]

@erikash i understand what you are trying to say, and in the end it all depends on your implementation and requirements ( and mostly, how you view it ).

But I advocate that there is a difference between Events and Actions; and that a Response is not "an event", but actually just that, a Response. Data that is returned ( be it immediately or later ) because an Action requires it to finish. A Response could hold the same information as an Event, but both are used differently.

I perfectly understand the reasons why you would architect it that way, i'm just concerned that after some time and as the project grows you'll have a hard time to figure out where and when events happened and even who triggered them. ( in my case, the external cloud service triggers it. In your case, it is buttons, external cloud service, anything actually because it is not restrictive and loose )

The architecture in this repository is implemented by Uncle Bob's clean architecture vision, so coupling is different to what you would want to achieve. I do recommend reading up on what Uncle Bob has to say.

[erikash]

You're right.. it all depends on the use case... all I said earlier is that the use case you pointed out is a bad example.
The response callback could be "200", but I suggest that state change handler for UserUpdatedEvent should be the same regardless of the trigger.
This case is actually very common for applications spanning multiple platforms.. that's why I suggest adding a solution for it in Android-CleanArchitecture.

[Trikke]

@erikash You keep commenting that my Use Case is a bad example without ever explicitly explaining why it is so. I feel you are calling it that because it doesn't fit in your architectural plans. In my example there are certainly no duplication bugs or anything. Of course you would never just copy paste code around. Just because you have 2 separate ways to call a Cloud Service to get an updated user, this wouldn't mean that there is duplicate code anywhere. But structuring it like this, with Actions and Events, you are certain that, if something happens, you can more easily debug and find out where the problem came from, be it a button press or an event triggered from a background service. In a completely event-driven situation, this becomes much harder, since your event wouldn't be coupled to any origin.

There is no "solution" required in this repository as you suggested, as the architectural changes you suggest do not fit in the ideologies presented in this repository. I think the author ( @android10 ) can chime in on this.

You are looking to create an "event-driven" architecture, which comes with its own set of problems.

[risayew]

I'm completely agree with @Trikke. Actually, i meant exactly the same way of the event bus usage. And the example about external service which is scheduled in order to fetch new updates from the server is exactly my case. So, makes sense for me.