/** * mainActivity interactor implementation */ public class MainActivityInteractorImpl implements MainActivityContract.Interactor {
@Nullable MainActivityContract.View view;
@NonNull final AuthManager authManager;
/** * constructor * * @param authManager used to get token */ public MainActivityInteractorImpl(AuthManager authManager) { this.authManager = authManager; }
@Override public void onAttachView(MainActivityContract.View view) { this.view = view; }
@Override public void onDetachView() { this.view = null; }
@Override public void login(String userName, String password) { authManager.login(userName, password, EnumSet.noneOf(AuthScope.class), new Listener() { @Override public void onSuccess() { view.loginSuccess(); }
Dagger Inject for android component(ex. activity, fragment, application etc ) and for java class(or interface) is different. Cause for android, with FSM activity’s construction function is implicit. So we use @inject or @module and some dagger 2 Android annotation to realise injection. It seems simple and easy. But for other our custom classes, we need to do in common ways, like add dependencies as parameters in construction functions.
GO BACK TO Dagger
The simplest concept:
First we need to know the importance and usage of DI and Constructor Injection. You pass the dependencies of a class to its constructor.
Here explains why we need another way for injection.
Constructor Injection. This is the way described above. You pass the dependencies of a class to its constructor.
Field Injection (or Setter Injection). Certain Android framework classes such as activities and fragments are instantiated by the system, so constructor injection is not possible. With field injection, dependencies are instantiated after the class is created. The code would look like this:
Why we need auto Injection framework?
For big apps, taking all the dependencies and connecting them correctly can require a large amount of boilerplate code. In a multi-layered architecture, in order to create an object for a top layer, you have to provide all the dependencies of the layers below it. As a concrete example, to build a real car you might need an engine, a transmission, a chassis, and other parts; and an engine in turn needs cylinders and spark plugs.
When you’re not able to construct dependencies before passing them in — for example when using lazy initializations or scoping objects to flows of your app — you need to write and maintain a custom container (or graph of dependencies) that manages the lifetimes of your dependencies in memory.
You create a class known as the service locator that creates and stores dependencies and then provides those dependencies on demand.
Compare
The collection of dependencies required by a service locator makes code harder to test because all the tests have to interact with the same global service locator.
Dependencies are encoded in the class implementation, not in the API surface. As a result, it’s harder to know what a class needs from the outside. As a result, changes to Car or the dependencies available in the service locator might result in runtime or test failures by causing references to fail.
Managing lifetimes of objects is more difficult if you want to scope to anything other than the lifetime of the entire app.