EigenDaksh: Android

Showing posts with label Android. Show all posts

PART 5. ADVANCED ANDROID DEVELOPMENT - MVP ARCHITECTURE

Read

Maintaining a clean architectural pattern is imperative for project maintenance and ensuring that it is clean, testable, and expandable. In Android domain, the classic Model View Controller pattern is no longer the default choice for developers. More and more developers are shifting their loyalty to Model View Presenter pattern (including me 😝).

Watch the two videos about the MVC and MVP patterns before proceeding.

Why MVP is being preferred over MVC?

While using Android SDK and Google documentation, you will get the impression that the Android ecosystem is tailor-made for MVC. But as your project grows more in complexity and size, it quickly becomes clear that this pattern is not ideal for writing tests. It does not offer the same level of separation of concerns as MVP. Some of the benefits that MVP pattern offers us over MVC can be summarized as follows:

The user interface can be unit tested. Inside the unit test, we replace the view with a test driver that makes calls to the presenter.
The user interface is developed completely isolated from the application logic. They can be developed independently of each other.

It can't be all good. There must be some catch here 😈. Yes of course. There are certain drawbacks to the MVP approach too.

It requires more effort 😕.
For every screen or window, we require separate presenters and contracts, which may ultimately complicate our project.

In spite of these potential problems, I am a strong advocate of MVP, because if you adhere to it strictly, even for very complex projects, you can successfully avoid spaghetti code situation.

Differences Between MVP and MVC?

The important differences between the two patterns are:

In MVP, there is one to one mapping between View and Presenter (for example, one presenter for every fragment). For a complex View, we can even have more than one presenter! In MVC, the Controller can share multiple views.
In MVP, the View is totally stupid 😂. It only knows how to render a screen on the device. It does not know anything about the model (not even it's existence!). In MVC, the View can directly communicate with the model. Hence, the big problem! How to test them separately?

Now that I have again convinced (coerced 😈) you to believe that MVP is better, in the next article of this series I will discuss MVP in more detail. I have used MVP pattern in the sample application and I will use its code to demonstrate implementation of MVP pattern for Android projects.

Read More Add comment

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() 
     .....................
}

Read More Add comment

Part 2. Advanced Android Tutorial - Setup Application Class

By apurushottam

Read

2 Comments

Getting Started

The first step should be to clone the sample app repository and build the application in your own Android Studio. I would also suggest that you should simultaneously code your own app which is very similar to it. Like, for your entry screen you can use Github API and display most popular Android repositories! You will find Jake Wharton several times there. That guy is a genius! Now coming back to the point. Start by creating your own project and with the sample app code downloaded to your computer so that you can refer it, whenever required.

Manage Gradle Dependencies

Generally, in an Android project, we end up with 10 or more libraries (support and third-party libraries like Glide). It is a good practice to manage the versions of the libraries using variables names. Use ext variables in your Gradle so that all your version numbers are in one place.

ext {
    minSDKVersion = 21
    targetSDKVersion = 26
    supportLibraryVersion = "26.1.0"
    constraintLayoutVersion = "1.0.2"
    junitVersion = "4.12"
    testRunnerVersion = "1.0.1"
    espressoVersion = "3.0.1"
    daggerVersion = "2.11"
    guavaVersion = "18.0"
    roomVersion = "1.0.0"
    retrofitVersion = "2.3.0"
    googlePlayServiceVersion = "11.6.0"
    rxVersion = "2.2.1"
    timberVersion = "4.6.0"
    roomVersion = "1.0.0"
    stethoVersion = "1.5.0"
}

Then in your app module build.gradle file you can declare dependencies like this:

implementation "com.google.dagger:dagger:$rootProject.ext.daggerVersion"

Timber Logging Library

Timber is an abstraction over the native logging interface. It is a lightweight library to write logs in different places and control how it's done in a centralized manner. It has a very small and extensible API. Yes, this library belongs to Jake Wharton!

Setting up Timber is pretty straightforward. The first step is to just add a dependency to your app's module-level Gradle file.


implementation "com.jakewharton.timber:timber:
           $rootProject.ext.timberVersion"

In Application class plant a "Tree" which would create logs in the debug mode only. You can refer to the Application Class of the accompanying application to see how logging with Timber is set up. Here a custom Debug tree has been defined to print line numbers in the log which helps a lot in debugging. Similar to Debug Tree, you can define Release Tree as well. This 6 minutes YouTube video explains it really well. Why we went through all this trouble to set up timber? Because it is very handy when you are debugging your code. I recommend using Timber in all Android applications.

Advantages of Timber

No tags: The library automatically assigns a TAG to log statements. By default, the TAG is the filename, but Timber can provide a custom tag if required.
Integration with Crashlytics: Timber can be used with Crashlytics to report crashes in production. Refer to this tutorial for a simple example.
Extensible: It is easy to configure logging with timber so that we have complete information of an application crash or its erroneous behavior. We can have the tag which gives context, its stack trace and any additional information that we may want, both in development and production.

Stetho

Stetho is an open source debugging platform developed by Facebook. It allows you to use Google Chrome’s developer tools to perform various debugging activities, such as view hierarchy inspection, network inspection, SQLite database management, and more. Refer to this tutorial for a more detailed explanation. The accompanying application also integrates Stetho in the debug mode. It takes only one line of code to integrate it into the application after you have added it to your dependencies. Stetho is very useful when you want to debug your app database. Just type chrome://inspect in your browser and you can see everything inside your app database. We all know how reading application DB otherwise is a time taking process. So, I recommend it for every project. If you want you can remove it later when you no longer need to debug your DB.

if(BuildConfig.DEBUG) {
     Stetho.initializeWithDefaults(this);
}

Strict Mode

StrictMode is used to set up virtual machine and thread policies for the application and report such violations. You can configure Android to crash your application with the alert or you can just log the alert and let your application carry on. It is most commonly used to catch accidental disk or network access on the application's main thread. I recommend developing all applications in StrictMode so that you adhere to correct structure and coding practices right from the beginning. The sample application enforces strict mode and you can see the code in the Application Class to find how the strict mode is set up for your application.

private void setupStrictMode() {
        if (BuildConfig.DEBUG) {
            StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
                    .detectDiskReads()
                    .detectDiskWrites()
                    .detectAll()
                    .penaltyLog()
                    .build());
            StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
                    .detectLeakedSqlLiteObjects()
                    .detectLeakedClosableObjects()
                    .penaltyLog()
                    .build());
        }
}

In the next lesson, we will discuss Dependency Injection.

Read More Add comment

Part 1. Advanced Android Tutorial - Introduction

By apurushottam

Read

0 Comments

What this tutorial expects you to know

So let's set out the pre-requisites before we proceed together on this journey. Something like a prenuptial agreement 😛. You should know Java (stuff like OOP, Inheritance, Interface etc.) and should have developed some Android app, even if as a hobby or learning exercise. In summary, you should have at least 1-2 years of Java experience, and some prior experience of developing Android apps. The sample application that I have written for this tutorial extensively uses Retrofit library for fetching data from an API. In this tutorial, I will not teach Retrofit library and so the tutorial assumes you are familiar with it. If that is not the case, you can still follow this tutorial. Go through this tutorial and write a simple app with Retrofit and you will be good to go!

What I do not expect you to know

I assume no previous exposure to Dependency Injection, RxJava or MVP. If you are just familiar with these concepts, this tutorial would give you an opportunity to deepen your understanding. If you are an expert, don't waste your time! No need to follow this tutorial. Make your own tutorial, publish it so that I can learn something from you 😜. The tutorial will explain these topics in connection with the Android domain only. These concepts are applicable to other domains as well, but those are not discussed here. Now, the most important part. The code of the application can be found in this Github repository.

The Sample Application

The sample application uses Java 7. Initially, I wanted to write the application in Kotlin. But still very few people use Kotlin for Android. Also, handling both Kotlin and concepts introduced in this tutorial would have been extremely difficult. I don't want you to pull your hair out while reading this tutorial So, I stuck with Java and also avoided Retrolambda.

The sample app is a very silly app with no real world use in my opinion. The entry screen shows you weather information after reading your location. It uses OpenWeatherMap API and RxJava for fetching weather information and presenting it on the screen. The second screen displays the notes that you have added. There is a button at the bottom right which you can click to open a screen and add a new note. Who would want that kind of an app! So it is not released on the Play Store. It only lives in Github hidden from the world and protected from all the mockings that it would surely get if it ventures out 😪.

After reading this tutorial, you may not become a fan of MVP and Dependency Injection, but you would surely love RxJava! It makes handling asynchronous calls very easy compared to AsyncTask or other mechanisms.

Though AsyncTask was introduced as "Painless threading", but nothing can be farther from the truth. There is hardly any situation where you should use it in any application.

While AsyncTask is surely "Painful threading", handling network calls with Handlers and Runnables is not that bad. But the main risk of Handlers is memory leakage. To avoid it, programmers create handlers statically so that it does not hold a reference to the activity. Then they use WeakReference to update the user interface without creating a memory leak. But handling multiple network calls using this approach is very difficult. You would appreciate how RxJava makes it easier to handle multiple network calls and its implementation is far simpler and less bug-prone than using handlers.

Read More Add comment

Subscribe to: Posts ( Atom )

EigenDaksh

PART 5. ADVANCED ANDROID DEVELOPMENT - MVP ARCHITECTURE

Why MVP is being preferred over MVC?

Differences Between MVP and MVC?

Part 3. Advanced Android Tutorial - Dependency Injection

What is Dependency Injection?

Solving Hard Dependency

Dependency Injection in Android

Part 2. Advanced Android Tutorial - Setup Application Class

Getting Started

Manage Gradle Dependencies

Timber Logging Library

Stetho

Strict Mode

Part 1. Advanced Android Tutorial - Introduction

What this tutorial expects you to know

What I do not expect you to know

The Sample Application

Follow Us

Recent Posts

Facebook

Search This Blog

Labels

Social Media Icons 2

Report Abuse

About Me

Facebook