Software scalability from android perspective
By: Ashutosh Jha
Tags: Android, Scalable Applications, Software Development

There are thousands of line of codes we go through everyday. And every line changes our perspective to write code one by one. Writing a code does not mean anything until we convert it into a product. A product is something which can sustain for so long. For this purpose we try to make our product efficient and scalable.

Let’s start writing our code with whole new perspective.

For our better understanding we will take reference of a news app and will also see some paradigms of few well known apps.

Few things on which our project should be come out clean:

Data loading issue. Data rendering issue. Memory utilization.

Most of the social networking apps such as Facebook, Instagram, Twitter are using few of the pro ways while writing their software which makes it more reliable, easy to use and more scalable.

Here are the few steps to keep in mind while writing code:

Memory efficiency

For an object-oriented programming, we need to create new instances of objects, taking reference of it. But in that process it’s also necessary for us to reuse already created objects whenever it is needed. Some solutions are singleton classes (Java) or object classes (Kotlin).

Let’s talk about the same problem on project level. We don’t want to create more than one instance of an object of Activity or fragment (Android). For this purpose we use dependency injection (DI). Dependency injection plays an important role when it comes to modular code writing. In simpler word, we create instance of an object and inject it whenever it needs without creating instance again.

In android there are number of DI libraries such as Koin (Kotlin), Dagger (Java) etc. Here is the simple implementation of Koin in our project.

Data persistence

Try not to wait for network response to show it in your app. To solve this issue we use the technique called data persistence or in a more simpler word, caching. Caching is a technique which is used to increase the speed, balances the load, increase data retrieval performance etc. Some common tools are Redis etc.

While talking about mobile, we call it data persistence. There are number of libraries in android such as Realm, Room etc. We have used Room in our project for this purpose due to its life-cycle awareness and easy to use. For image caching we can use Glide or Fresco.

Thread safe

Let’s divide our operations into two threads i.e. main thread and background thread. All the heavy operations such as network call, media downloading, long calculations etc. should always be on background thread. And the UI rendering parts such as Data rendering, image rendering etc. should be on main thread. By following this we can utilize our CPU and prevent our app from ANR (App not responding) issue.

In kotlin library, we have co-routine to deal with it. Co-routine handles all the asynchronous or non-blocking operations on IO thread and synchronous or blocking operations on MAIN thread.

Life cycle awareness

For an app, it is important to be life-cycle aware to prevent crashes while rotating screen or while going app in background. Suppose a case on slow internet, you sent a network call but due to slow internet it took some time to send response. During this, you exit the app and it is in background now. After sometime app got the network response and tried to render it on UI. But our app cannot perform this because it is not visible currently and it got crashed.

For this purpose, there is a life-cycle aware architecture component of android, Live Data. Live Data has an observer which observe for changes and render it on UI if and only if it is okay to render.

Let’s code it — News App

By keeping all the above points in our mind, we have written a project for a News Application. Before going further, let’s understand the flow.

We have a data source on server. We fetch it and store it into the persistent database (Room). There is an observer which observes for the data on room. And render it on screen.

Click here to go to the project

Architecture understanding

Few points to understand:

UI interacts with Room and not directly to the server. Server response get stored in Room db and not in any list initially. Room emits LiveData object which is observed by UI. We initially show data from our persistent db and it prevents the reliability of app on the network call.

Thanks for reading this article. Feel free to ask any query or suggestion.

Also read:

I ♥️ EventBus

Response Handler (Retrofit + Co-routine)