Reducing number of event classes when using EventBus or Otto

Question

I am about to start development on an Android app. I am interested in using Otto or EventBus in my app to assist with making asynchronous REST network calls and notifying the main thread when the calls have returned.The one major flaw with the use of these busses that I have found during research is that there are typically too many event classes that have to be created. Are there any patterns or approaches to reduce the number of event classes that have to be used?

Answer 1

The concept

The best way i have solved the issue of too many event classes is by using Static Nested Classes You can read up more about them here.

Now using the above concept here is how you would solve the problem:

So basically suppose you have a class called Doctor that you are using to create an object you are passing around with your application. However you want to send the same Object over the network and retrieve JSON in the context of that same object and feed it back to a subscriber to do something with. You would probably create 2 classes

1. DoctorJsonObject.java that contains information about the returned JSON data and
2. DoctorObject.java that has data you are passing around in your app.

You don't need to do that. Instead do this:

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
    }
}

Now you have one Doctors Class that Encapsulates both the events for the post to the network and the post back from the network.

1. Doctor.JSONData represents data returned from the network in Json format.

2. Doctor.AppData represents "model" data being passed around in the app.

To use the class' AppData object 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 within you implementation that listens for this object and makes an http request and returns the Doctor.JSONData:

/*
retrofit implementation containing
the listener for that doctor's 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
            }
        });
    }
}

With the above implementation you have encapsulated all Doctor Object related events within ONE Doctor class and accessed the different types of objects you need at different times using static inner classes. Less classes more structure.