2

I'm try to use event bus lib, I could not understand it's functionality and see multiple examples. Is it use only services class or use activity and fragment then is use activity what situation we use event bus in activity or fragment.

Vadivel
  • 780
  • 1
  • 6
  • 21
Android
  • 141
  • 1
  • 3
  • 8
  • I just understand concept but i dont which situation use that – Android Dec 06 '16 at 04:23
  • 2
    You should check SO documentation of [Greenrobot eventBus](http://stackoverflow.com/documentation/android/3551/greenrobot-eventbus#t=201612060424588957703) and [Otto eventbus](http://stackoverflow.com/documentation/android/6068/otto-event-bus#t=201612060425047440724), also check [this](http://www.androidgig.com/eventbus-library-in-android/) link – Ravi Dec 06 '16 at 04:27

4 Answers4

4

Instead of interface we can simply use EventBus .we can pass messages from one class to one or more classes. EventBus in 3 steps

  • Define
  • Register and unregister
  • Post Event

Define events:

public static class MessageEvent { /* your getter and setter */   }

Prepare subscribers: Declare and annotate your subscribing method, optionally specify a thread mode:

@Subscribe(threadMode = ThreadMode.MAIN)  
public void onMessageEvent(MessageEvent event) {
   /* event fire here when you post event from other class or fragment */
  };

Register and unregister your subscriber. For example on Android, activities and fragments should usually register according to their life cycle:

@Override
public void onStart() {
super.onStart();
EventBus.getDefault().register(this);//Register 
 }

unRegister

@Override
public void onStop() {
super.onStop();
EventBus.getDefault().unregister(this);//unregister
}

Post events:

EventBus.getDefault().post(new MessageEvent());//post event
sasikumar
  • 12,540
  • 3
  • 28
  • 48
3

You can consider EventBus as a lightweight communication channel for passing data within activities, or services, or fragments or between any of them.

Think of EventBus as an underlying layer in your app which is independent of any active activities or services or fragments and their lifecycle.

How an EventBus works

The main concept on which an EventBus works is that you subscribe to events in either an activity or fragment or service or any components like that and whenever the EventBus has a specific event of the type you subscribed, it notifies your subscribed method in that component and you can perform any task there based on the event that you have received.

Triggering an event is easy and you can do it from any area of your app by just passing a specific event (which is basically a POJO class, let's say MyEvent) to the EventBus, and the bus will handle the rest and correctly deliver it to the appropriate receiver/s.

I would recommend you to try out EventBus 3 from GreenRobot, and go through their documentation here to incorporate their library n your code. I have been using the same without any problems.

EventBus 3 by GreenRobot

Hope this helps.

Rahul Chowdhury
  • 1,110
  • 12
  • 23
2

Mostly you shouldn't. In general its a hack for when you misarchitected your program and can't easily pass data from one point to another due to how your app is encapsulated and what objects are known at what levels. It can cause real spaghetti code where its difficult to figure out what code will actually be called when an event occurs. You shouldn't be writing your code around having an event bus, it should be a last resort if you can't refactor things to work the correct way.

Gabe Sechan
  • 90,003
  • 9
  • 87
  • 127
  • I think this is a little harsh. Android's framework makes some interactions and coupling very difficult, and EventBus helps deal with these shortcomings in a reasonable way. It's not the right solution for every problem and you can certainly get yourself into a mess if you are not disciplined about its usage, but that doesn't mean it's not acceptable or an automatic signal that your architecture is flawed. I've used EventBus in professional apps without turning into spaghetti code. – Karakuri Dec 06 '16 at 04:48
  • 1
    I don't think its harsh. The ratio of abuse:actual need I see of event bus is about 10:1. Its at the point where if I see an event bus in the code I double my time estimates for any maintenance work. – Gabe Sechan Dec 06 '16 at 04:49
  • @GabeSechan So basically, you're saying that EventBuses shouldn't exist. –  Feb 10 '18 at 23:40
  • @docatseatbats I'm saying 90 percent of their use shouldn't. There's occasional places it's useful, but it normally means a flaw in program architecture – Gabe Sechan Feb 10 '18 at 23:49
  • @GabeSechan If you're saying all it's good for is to work around bad code, you're saying that EventBus is at best a necessary evil. I disagree. –  Feb 11 '18 at 00:00
  • @docatseatbats You can disagree all you want, you're just probably writing spaghetti code. Especially if you're using a single global event bus, which is the worst abuse of this pattern. – Gabe Sechan Feb 11 '18 at 00:01
  • @GabeSechan I wonder what kind of code you read to be so badly scarred like this. EventBus is just like any other pattern, if used incorrectly, it will lead to spaghetti code, bugs, pain and suffering. I made sure to use the pattern correctly, thus, it is testable and readable. Don't do a disservice to people just because you don't enjoy the pattern. –  Feb 11 '18 at 00:10
  • @docatseatbats When a pattern is serially overused by people who use it as a magic bandaid, its a disservice to not warn people of its bad sides. And at least 90% of the time I see it used, its the wrong solution, used because people couldn't figure out a clean way to pass data around. If you feel the need to use one, you should be looking for ANY other solution to see why your code needed it. You're the one performing a disservice, by not providing the negatives of a tool that's usually bad. You are actively making the software world worse by doing so. – Gabe Sechan Feb 11 '18 at 00:13
  • @GabeSechan A tool has no bad sides. A screwdriver is not bad because it is not fit to put nails. When it comes to programming, every tool can lead to untestable, hard to maintain and bug prone code. I don't feel the need to state that using EventBus incorrectly will break your program, because if you misuse anything, even the programming language built in features, your program will break. Back to the screwdriver analogy, if you misuse the tool, you will strip the screw. It's not a problem with the tool, it's a problem in the usage. –  Feb 11 '18 at 00:19
  • @docatseatbats Of course tools have bad sides. That is the stupidest thing I've ever heard of. If you had a knife with a second blade instead of a handle, would you say it had no bad sides to it? I can't even understand what kind of lack of understanding would even bring someone to say something like that. But if you actually believe that we can end this discussion, because you aren't actually capable of having one where we discuss the negatives of something if you think something can't have a negative. Just please, never work with me. – Gabe Sechan Feb 11 '18 at 00:22
  • @docatseatbats No, don't backtrack like that. It's a tool and a tool has no bad sides. – Gabe Sechan Feb 11 '18 at 00:25
  • @GabeSechan You can't deform the tool like that. If you're taking away a component of a tool, then you are turning that tool into something completely different. I just said I agree that poor use of a tool will turn the program into a mess, but I do not agree that EventBus is a useless tool. I can agree that the built in global instance in GreenRobot's EventBus is a mistake, for example. Guess what, just avoid using global instances. Form relationships between events and subscribers. It's a useful tool, as proven by apps like Twitter and Snapchat. –  Feb 11 '18 at 00:30
  • @docatseatbats Yeah, you totally lost all ability to make a credible argument the moment you said tools don't have downsides. You're just wasting your time here. – Gabe Sechan Feb 11 '18 at 00:50
  • 1
    @GabeSechan All I really wanted was to provide discussion useful to people having trouble deciding on whether or not to try the library. I'll let these people decide if I have credible arguments or not. Good luck on your endeavors. –  Feb 11 '18 at 00:57
1

One of the advantages of events is that you can pass objects around to 'somewhere', and you don't need to know where it is picked up. This makes it easy to push your activity or fragment state to a controller class, and then use events sent from this controller back to the activity or fragment.

Because of events, the controller doesn't need to know if the receiving end is an activity or a fragment. This makes it very easy to switch one for the other. On the other hand this also makes it easy to put the controller somewhere else. Like first you have it as an instance in the application class, and then you move it to a service.

I wrote an article with a very concrete example on how you can use events to deal with the Android life cycle as described above: https://medium.com/@JuliusHuijnk/beating-the-android-life-cycle-d00a2f3ed88

Julius
  • 159
  • 1
  • 1
  • 13
  • Thanks buddy.one more question - If user logout from app then the values is removed from event bus then how we can remove values from Event bus – Android Dec 23 '16 at 04:41