Using otto for inter fragment communication - dependency injection confusing

Question

I wish to use Otto for inter-fragment communication. I want to do this using best practices if I can help it. The Otto example on Github uses a singleton for the Bus object, but recommends using dependency injection. I'm new to both of these concepts, although the former appears to be easier to implement. I'm struggling to see how I would do the latter without considerable effort, despite reading around.

There are the OS dependency injectors dagger, guice and a few others, but they seem like they would be fairly heavy going for a relative newbie like myself to pick up. I'm wondering if it is really worth it learning to use one of these for seemingly minor gains in efficiency/code conventionality. Not to mention that they will bloat my project.

Is it really worth it to implement Otto using DI, when I am only going to be using it to replace a few interfaces and listeners here and there? I'll only really be registering the Bus in a few fragment-containing activities

I won't be unit testing, and I can live with two or three activities (out of ten) being tightly coupled to their fragments. I can't see anything really bad in doing this, much as it is ill advised, especially if it is relatively easy to switch to dependency injection later on.

Lastly, do I need separate Bus instances for seperate activity-fragment groups, where communication will only occur within said groups? Its not clear to me from reading whether I need to do this for best practice/efficiency or safety?

Answer 1

I imagine you might get different opinions on this, but having used Otto and dagger myself, and considering the information you provided, I don't think the cost/benefit of implementing DI (with dagger, guice, or something else) would be worth it for you. This is not a knock on dagger - I like it and am using it successfully, but there's a learning curve, and if you're not doing unit testing, I don't know that it would provide much value to you.

If you begin to do unit testing later, then adding DI would be a good move.

Regarding the question of separate Bus instances for separate activity-fragment groups, that may not be necessary if those activities-fragment groups are not publishing and subscribing to the same kinds of events. That is, if activity-fragment group A only cares about Foo events, and activity-fragment group B only cares about Bar events, then I think a single Application-scope Bus might meet your needs.