Android event-driven programming – I may have logged on to a fake EventBus

I’m sure everyone has used EventBus, because it’s designed to be so easy to use that you can easily get started by reading the documentation

Before looking at things about it are basically introduced + analysis source code + Hello World demo

• For example, passing events before fragments and activities (but with less boilerplate code,as Callback or Lisenter)

• For example, send events where the UI is difficult to control and then update them in the View layer (usually in Controller,Presenter,Adapter).

  ​

🤔 feels like few people have told me before what is event bus, event driven?

I found ThreadPoolExecutor in Android-CleanArchitecture earlier

Stunned, I reviewed the EventBus document and took notes.

Then learning a little bit about event-driven programming,🙄 discovered that all along, I might have been on a fake 🚍

It’s a cliche to talk about decoupling and modularity.

Mostly because the code is written for people… It’s fucking awkward when you don’t even want to touch it

• Why am I writing this code twice in different places?
• Why am I good at 10WcodeI’m going to have 3w rowsrefactorandrewritting? And of course the 6w row is.xml, 😄

And the event-driven programming paradigm is actually quite common… Draw a map (there’s no free mind map on MAC)

• Outside is the view layer

  Different user actions (such as up, down, left, left, right, ABAB) may represent the same event (the business logic behind it), send and then wait for a callback to respond.

• In the middle is the event handler

  In many cases, the event handler can handle the event itself, so it may also send an event (callback)

  • It could be amain loop, constantly detecting and processing events
  • It could be oneThreadPoolExecutor, inject different threads, process and send events

Unlike software architecture (for decoupling and modularity), event-driven design focuses on elasticity and asynchronism, and modeless as much as possible: no forced waiting for callbacks and then responding

But since you’re using EventBus, you don’t have to worry about some of the underlying implementations

Write a class that acts as both Observer and Subscriber, inject it when needed, and process and send events there

So for example, a comment 🌰

Event Handler

public class CommentBus implements CommentContact.Bus { @NotNull private final RemoteDataSource remoteDataSource; private final CompositeSubscription mCompositeSubscription; @Inject public CommentBus(@NotNull RemoteDataSource remoteDataSource) { this.remoteDataSource = remoteDataSource; mCompositeSubscription = new CompositeSubscription(); } @Inject @Override public void register() { // do register } @Override public void unregister() { // do unregister and unsubscribe } @Subscribe(threadMode = ThreadMode.MAIN) public void onPostComment(final CommentPostEvent event) { postComment(event.getExecutionScope()); } @Override public void postComment(Object scope) { mCompositeSubscription.add(remoteDataSource.postComment() .subscribe(new Action<Comment>() { @Override public void onNext(Comment comment) { CommentPostCallback callback = new CommentPostCallback(comment); callback.setExecutionScope(scope); EventBus.getDefault().post(callback); }})); }}Copy the code

CommentBus is injected when required, and its Scope is generally the same as an Activity/Fragment, because we do not always need to listen for such events.

PS: useDagger2And then I feel like I can sort through each instanceScopeIt’s great because ourContextThey all have their own life cycle

For example, you might want to include a Scope in the Event (for example, 🌰)

Event

public class CommentPostEvent implements HasExecutionScope { private Object executionScope; @Override public Object getExecutionScope() { return executionScope; } @Override public void setExecutionScope(Object executionScope) { this.executionScope = executionScope; }}Copy the code

HasExecutionScope

Stir-fried chicken is a useful interface because subscriptions and registrations can sometimes get messy and unwieldy.

For example, page ABCD is subscribed to event E, instances of page ABCD are all on the stack, and then you just want page A to respond to its own event callback.

When I didn’t know about this interface, I foolishly added a TAG😅 to each Event

Now all you need to do is set a Scope when you send the event

CommentPostEvent event = new CommentPostEvent();
event.setExecutionScope(PostCommentActivity.class);
EventBus.getDefault().post(event);
Copy the code

Then check whether it is the same Scope in Subscriber

@Subscribe
public void onPostCommentCallback(CommentPostCallback callback) {
    if (PostCommentActivity.class.equals(callback.getExecutionScope())) {
       // do something 
    }
}
Copy the code

Priorities

@Subscribe(priority = 1);
public void onEvent(CommentPostCallback callback) {
    ...
}
Copy the code

FAQs

Water so many words, in fact, I have a lot of why… Who takes me to the car 🙏

Q1:

Because EventBus is just a tool for decoupling components, we still need to choose the appropriate software architecture (such as MVP) during development. Should we use one event bus or multiple event buses at View,Usecase, and Data levels?

If it’s one, the complexity obviously increases a lot; If there are multiple, we may have to send many of the same events repeatedly between different levels.

Q1.1:

Then there is the problem of how to better manage messy code when the project is full of events.

If any one give me a working example much appreciated,thanks in advance

Q2:

Now that we have event-driven, we don’t need presenters. Because presenters are sometimes hard to reuse, they can’t avoid a lot of boilerplate code or empty interfaces

Of course you can subdivide presenters into multiple presenters on a single page. But it feels less cool than post(Event Event), and more convenient to collaborate on the development of the upper code

Is that so…