Reducing the number of event classes when using EventBus or Otto

Question

I am going to start development in an Android application. I am interested in using Otto or EventBus in my application to help with asynchronous REST network calls and notifying the main thread when calls are returned. One of the main drawbacks with using these buses that I found during my research is that there are usually too many classes of events that need to be created. Are there any patterns or approaches to reducing the number of event classes that need to be used?

Answer 1

Concept

The best way to solve the problem of too many event classes is to use Static Nested Classes . You can learn more about them here .

Now, using the above concept, you can solve the problem:

Basically, suppose you have a class called "Doctor" that you use to create an object that you are viewing with your application. However, you want to send the same object over the network and receive JSON in the context of the same object and pass it to the subscriber to do something. Maybe you will create 2 classes

• DoctorJsonObject.java , which contains information about the returned JSON data and
• DoctorObject.java , which has data that you are viewing in your application.

You do not need to do this. Instead, do the following:

public class Doctor{ static class JSONData{ String name; String ward; String id; //Add your getters and setter } static class AppData{ public AppData(String username, String password){ //do something within your constructor } String username; String password; //Add your getters and setters } } 

You now have one class of doctors that encapsulates both events for messages on the network and messages from the network.

• Doctor.JSONData strong> represents data returned from the network in Json format.

• Doctor.AppData strong> represents the "model" data transmitted in the application.

To use an object of the AppData class, then for the post event:

 /* You would post data from a fragment to fetch data from your server. The data being posted within your app lets say is packaged as a doctor object with a doctors username and password. */ public function postRequest(){ bus.post(new Doctor.AppData("doctors_username","doctros_password")); } 

The subscriber in your implementation that listens for this object and makes an HTTP request and returns Doctor.JSONData:

 /* retrofit implementation containing the listener for that doctor post */ @Subscribe public void doctorsLogin(Doctor.AppData doc){ //put the Doctor.JSONObject in the callback api.getDoctor(doc.getDoctorsName(), doc.getPassWord(), new Callback<Doctor.JSONObject>() { @Override public void success(Doctor.JSONObject doc, Response response) { bus.post(doc); } @Override public void failure(RetrofitError e) { //handle error } }); } } 

In the above implementation, you encapsulated all the objects associated with the Doctor in the class ONE Doctor and gained access to various types of objects that you need at different times using static inner classes. Less classes have more structure.