EigenDaksh: Modules

PART 6. ADVANCED ANDROID TUTORIAL - Implementing MVP

Read

Unfortunately, there is no “standard” way to implement MVP for Android apps 😐. There are many variations of MVP and developers adjust this pattern idea to their own style and needs. And since this is my blog, it's my way or highway 👹. My style of MVP implementation is more focused on testability rather than ease of implementation. It is based on two principles:

The View should be dumb: Reduce the functionality of the View to the absolute minimum. The View should only be responsible for rendering the screen and should have no data contained in it. This improves the testability dramatically.
The Presenter should be framework-independent: Presenter should not depend on Android classes. This part can be tricky sometimes. But do not worry, there are plenty of examples online and with practice, you would get better at it.

For looking at my way of implementing MVP, go to the addnotes section of the screens module in the sample application. Here the Fragment AddNoteFragment is our View. This View implements a simple interface which are the methods related to rendering something on the screen. This ensures that our View is dumb or passive.

Make your Presenter implement an interface which should contain the methods it needs to act as a communicator between the Model and the View. As you can see, this Presenter is handling the responsibility of adding a new note to the the database (our Model) and informing the Fragment (our View) about the state of the application. There is no direct communication between the Model and the View.

The only part remaining now is to provide the "Presenter" to our View. The best way to do that is by dependency injection. In the AddNoteFragment you can see an example of that. In our sample application there is a separate module for injecting the presenters wherever required.

@Module
public class PresenterModule {

    private final Context mContext;

    public PresenterModule(Context mContext) {
        this.mContext = mContext;
    }

    @Provides
    @Singleton
    public WeatherPresenter provideWeatherPresenter() {
        return new WeatherPresenterImpl(mContext);
    }

    @Provides
    @Singleton
    public WeatherDetailPresenter provideWeatherDetailPresenter() {
        return new WeatherDetailPresenterImpl(mContext);
    }

    @Provides
    @Singleton
    public NotesListPresenter provideNotesListPresenter() {
        return new NotesListPresenterImpl(mContext);
    }

    @Provides
    @Singleton
    public AddNotePresenter provideAddNotePresenter() {
        return new AddNotePresenterImpl(mContext);
    }

    @Provides
    @Singleton
    public NoteDetailPresenter provideNoteDetailPresenter() {
        return new NoteDetailPresenterImpl(mContext);
    }

}

In the next lesson of the series, we will discuss how to implment a RecyclerView without breaking the MVP principle.

Part 3. Advanced Android Tutorial - Dependency Injection

By apurushottam

Read

0 Comments

What is Dependency Injection?

First of all the term sounds frightening 😛. When I heard the term first, I thought it must be some very difficult design pattern meant only for very advanced developers. Now I can't imagine writing applications without it. So let's see a nice video about Dependency Injection and then we will discuss it further.

Let me bore you at the outset! These are some theories associated with dependency injection which you will find a bit easier to grasp because of the video you just watched. If you have not watched it, please go back and watch it.

Dependency Injection is a specific form of Inversion of Control. I know you feel like it, but do not pull your hair out yet. Have some patience and read on. So what is Inversion of Control? Inversion of Control has two principles which should not be violated.

The modules of top levels shouldn’t depend on modules of the lower levels. The modules of all levels should depend on abstractions.
The abstractions shouldn’t depend on details. The details should depend on abstractions.

In summary, you should avoid hard dependencies. A dependency is a coupling between two modules or classes of code. This leads to problems because if we make any change in one module, we must make corresponding changes in the coupled module as well. For example, let us look at this code:


public class Scooter {

   private Indicator indicator;

   public Scooter(){
      scooter = new Scooter();
   }
 
   public void turn(){
     .........
      indicator.switchOn();
   } 
}

Now how can we test 'turn' without testing ‘switchOn’? If the test fails, which method is failing? And things get worse if the method saves something in the database or performs an API call. Therefore, a class should not initiate a dependency by itself because it creates a high coupling that will be quite difficult to test. Whenever we create a new instance we introduce a hard dependency. Hard dependency should be avoided if we want to write testable and configurable code.

Solving Hard Dependency

To solve the problem of hard dependency we should make sure that these dependency objects should be “injected” from outside components like factories or builders. Basically, we need a Dependency Injector. Dependency Injector is a special module in our app that is in charge of providing instances of the rest of modules and "inject" their dependencies. So inside a module, we are not creating instances and we can follow the Single Responsibility Principle.

Dependency Injection in Android

All this sounds very nice. But how do we take advantage of Dependency Injection in Android? Dagger2 is an open-source framework for that purpose. The framework removes a lot of the boilerplate code and also provides a systematic way to apply dependency injection across our Android app. Dagger2 has some advantages which I would like to mention here. Do not worry if you do not understand every point. Once you have an understanding of Dagger2, you can come here and look at these points and agree or disagree with me.

Simple handling of complex dependencies: The big applications have several dependencies. Dagger2 makes it easier to handle dependency injections.
Code generation through annotations: Dagger2 generates codes required for Dependency Injection through simple annotations. The generated codes are concise and readable.
Small size of the library

I will discuss Dagger2 in detail in next lesson. But just as a preview of the goodies that Dagger2 offers, look at an example where I inject three dependencies in a Fragment. Once I have object injected in my class, I can use it for making API calls which are defined in one place. (Don't worry if you do not understand the above line. It is only an example.)


public class MobileVerificationProgressFragment extends RxFragment {


 @Inject
 UserPreferenceStore _mPreferenceStore;
 @Inject
 DeviceStore _mDeviceStore;
 @Inject
 IDFCUPIStore _mIDFCStore;

 private SendSMSIfc mActivity;

 BroadcastReceiver mDeliverReceiver;
 BroadcastReceiver mSentReceiver;
        ...............................
}

private void generateOtp() {
     _mIDFCStore.generateOTP(generateOTPReq)
     .compose(this.bindToLifecycle())
     .observeOn(AndroidSchedulers.mainThread())
     .subscribe(new Consumer() 
     .....................
}

EigenDaksh

PART 6. ADVANCED ANDROID TUTORIAL - Implementing MVP

Part 3. Advanced Android Tutorial - Dependency Injection

What is Dependency Injection?

Solving Hard Dependency

Dependency Injection in Android

Follow Us

Recent Posts

Facebook

Search This Blog

Labels

Social Media Icons 2

Report Abuse

About Me

Facebook