Heterogeneity,

the quality or state of being diverse in character or content.”

One thing every native android developer can actually agree on is the fact that we’ve got options for virtually every operation we may want to perform while building our apps. Whether they are third party libraries or android “recommended” libraries, they have been a source of fun arguments in the android space as the devs at the top never seem to agree on which one is better. In this article, we’re going to look at various aspects of android and some of the numerous libraries that can be used to perform their respective operations. DISCLAIMER: This article is not a review of which library or mode is better than the other, it’s always advisable to use whichever option you prefer and are most comfortable with. So let’s go!

The Language:

Lol, yeah, we even have options when it comes to the programming language we use to build our apps. Up until 2011, android developers used only Java (and C++?) to build apps, people say it was (and still is) a thorn in the flesh and it made Android development difficult compared to other stacks who had “easier” languages like python or JavaScript. Then Kotlin came along and changed the game, a statistically typed, cross-platform language that runs on the Java virtual machine, making it fully interoperable with the Java language. Kotlin made life easier for android developers, but this doesn’t rule out Java which is still in use to date.

Dependency Injection:

“Dependency injection in software engineering is a technique in which an object receives other objects that it depends on

In android, we have a couple of libraries that do exactly this, each boasting of their own unique features that “supposedly” makes them better than the other, here they are:

Dagger:

The android world first heard of Dagger in 2012, a Java library created by Square, it was the plug for dependency injection for a long time. Dagger 2 was an improvement to Dagger 1 and there is also a Dagger-android and most recently, Hilt.

Koin:

Created sometime around 2017/18, Koin was introduced as a “pragmatic lightweight dependency injection framework” strictly for Kotlin. It was the first dagger competition.

Kodein:

Another “painless” Kotlin dependency injection library, the least popular of the 3 in my opinion but it’s still widely used.

Asynchronous Operations:

There are also a few libs in android used for Async calls, here are some:

AsyncTask:

This is the traditional Java library for running tasks in the background, has been there since the inception I bet, it may just be the most complicated concurrency pattern to use.

RxJava:

A lightweight concurrency library that supports JVM based languages like Java, Kotlin, Scala, and Groovy

Coroutines:

The latest concurrency library in android. It is specifically for Kotlin and is relatively easier to implement. It is also Google recommended library for concurrency, but we all know that could change any time.

Network Calls:

Fetching and posting data to and fro an API is an operation that all android developers have (or would) perform. There are a handful of libraries that help us achieve this:

OkHttp:

Developed by Square 6 -8 years ago, this has been a very helpful library for network calls, it is also relatively easy to use

Volley:

Volley was developed by google some 6 years ago and it was intended to make network operations “easier and faster”. It was widely used too up until the advent of the next library we’re going to look at.

Retrofit:

Another square library that, since its inception, has become the go-to library for network-based operations for most android developers. Retrofit is very easy to use and blends really well with android architectural patterns.

Data Persistence:

The libraries we’re going to talk about in this section are not necessarily used interchangeably, this is because they all have a certain amount of data that they can persist ideally and in this case, each of them has their preferred use cases. Let’s dig in:

Shared Preferences:

This android library is used to store “relatively small” collections of key-value pairs. Data like strings, or integers that you would like to persist in your application can be stored easily and effectively with shared prefs. There are workarounds to store bigger data like objects, but then again, it may not be the best practice.

SQLite:

“SQLite is a C-language library that implements a small, fast, self-contained, high-reliability, full-featured, SQL database engine”. I don’t think any android developer uses SQlite purely again, but it was the in thing just a few years back. Before the inception of…

Room:

Room is a Google library that provides an abstraction layer over SQLite, make its operations easier to use and understand. Announced in 2018, as part of the jetpack libraries, Room has been the number 1 choice for in-app data persistence for android developers.

Architecture:

Even though architectural patterns are not unique to android developers, they still are a hot topic of discussion and arguments as to which is better in what scenario. Here are a few of them:

Model-View-Intent(MVI):

This is the newest among the architectural patterns for android, it uses reactive programming to build android apps and was stimulated by the nature of the cycle.js framework.

Model-View-Controller(MVC):

MVC was intended to introduce clear segregation between the data and the presentation layer. The Model is the data layer, responsible for the business logic, the view is the widgets that we can see, and the controller handles user interactions and inputs like keyboard events for a view.

Model-View-Presenter(MVP):

This pattern was derived from the MVC pattern, the only major difference is the fact that the data layer doesn’t interact directly with the view, rather all data is passed to a “presenter” which serves as an intermediary between the Model and View.

Model-View-ViewModel(MVVM):

Probably the most popular and widely used architectural pattern, the MVVM has since proved to be very effective when building applications. ViewModels are responsible for providing data to views without actually holding a direct reference to the view, this makes them lifecycle aware and makes sure that the views and data don’t even know each other.

Recap:

As I said at the beginning of the article, it is always better to use whichever library you feel most comfortable with or the one that is being used by the organization you work for. Though there are endless arguments as to which is better than the other, it is always advisable to enjoy the banter and make a decision for yourself in the end. Having many options is a good thing after all.

I hope you enjoyed the article, leave a like, and comment if you may. Merci! 😇