Toolbox of the modern Android developer — 2020 — PART 1
What libraries and tools are widely used in professional Android app development?
When I say professional, I mean the companies that invest thousand / millions of £s into their mobile app businesses.
Where does that money go? From a technical perspective (means ignore the obvious sales, marketing and operational costs), it’s mostly used to make sure that the apps are scalable and maintainable. These two are probably the most vital among the other must-haves aspects of a professional mobile app.
What tools and libraries do most professionals use?
In this article I’ll list the libraries and the tools that me and my colleagues use (meaning the list is subjective) when designing and developing a mobile app.
Obviously there can (and are) other tools that other professionals use, these are just my personal preferences and observations watching other professionals.
Let’s start with the obvious one: Kotlin
Your chances of getting a nice job at a good company without the knowledge of Kotlin is… getting slim. Day by day. I’m sure there are several companies that still employ people with Java skills only, depending on their requirements but the power and the advantages of Kotlin is so obvious now that most companies are moving on to it.
So if you didn’t have the chance of getting your hands dirty with Kotlin yet, start today. Simple home-made practice apps will do it.
Architectural Components
Android architectural components are a bunch of libraries to help us developers to write stable code and apply the ‘best practices’ of the industry to our code.
This is the page you need to start from for more details and here are the most widely used libraries of the pack:
LiveData and Lifecycle-aware components
LiveData and Lifecycle-aware components help us to write more stable code (i.e. less crashing), thanks to the caring nature of the LiveData. What LiveData simply does is to notify its listeners (usually views like Fragments and Activities) only when they’re ready to receive the data, i.e. they are not being destroyed.
It’s like talking to your kid only when she’s listening. That way you make sure she at least hears you and you don’t waste your energy when she is not listening.
Before LiveData, trying to notify a stopping view was one of the top reasons for app-crash. Now it simply is not.
MVVM and ViewModel
There are several different architecture models that you can build your app with and MVVM is one of them — probably the most popular one this days (MVI: “Dude, what?”)
ViewModel is a useful component that out-scopes the views, fragments and the activities. That means ViewModels live longer than the views and that enables us to store view-related data in the ViewModel and use it even after the view is stopped.
Room, SQLite and the Kotlin data classes
These 3 go together, most of the time. Most modern apps use SQLite as it is the primary way of data persistence and Room is the library we use to retrieve data from SQLite, easily. I mean very easily, compared to how it was before Room.
If SQLite were a vault, then the cashier would be the Room(makes accessing the money — aka data — super easy) and the money bags would be the Kotlin data classes, where the actual data is hold.
Dependency Injection: Hilt or Koin
Dependency injection is a vast topic. Think of it as a way to keep our application testable, maintainable and flexible enough to make changes without re-writing the entire app.
Dagger 2 has been the de-facto solution for dependency injection in Android. It was a pain though, for most.
Luckily we have 2 better alternatives these days: Hilt and the Koin. Koin is a third-party dependency injection library whereas Hilt is an improved version of Dagger 2, by Google.
You can read an introduction to both here.
Network communication: Retrofit and Volley
Very few applications these days are isolated from the rest of the world. Almost all consumes some sort of data from a remote resource, like cloud through the Internet.
Android has an HTTP library to create and manage this connection with the outer-world but again, it isn’t very straightforward and needs considerable boiler-plate code.
Retrofit and Volley are the two popular libraries we use to manage our network communication, easily, in a stable and testable way. Almost all companies use one of these two.
Image loading framework: Glide
There are more than one really good image loading libraries for Android and Glide is one of them. It’s my favourite library as well, as it never disappointed before.
There have been times when we used to download images ourselves, byte by byte but these days Glide and similar tools do everything for us under the hood.
For another good alternative, check Picasso.
Logging: Timber
Logging for debugging is vastly undervalued and neglected by many, IMHO. We normally use Android Log class to log events — or whatever we want- happening the app.
Timber is a small library helping us to do this boring job in a (much) better way. With Timber, we don’t need to worry about removing our logs or adding tags to our logs. We can also easily change the way we’re logging, like instead of logging to the console, we can send logs to a 3rd party API, like Firebase Crashlytics.
Also here is a nice article about the advantages of using Timber.
Part 2: To be continued…
After I wrote this much, I realized there are still a lot more libraries to talk about, like Android WorkManager, Gson, Unit test frameworks, Firebase APIs, RxJava, animation frameworks, UI / UX tools and MORE. Yes, more. Feels like there is no end to it(but there is, don’t worry!).
And more…
When I find some time, the second part of this article will be the tools at our disposal to spot potential issues in our code, measure the performance and debug the the app, like: LeakCanary, Android studio profiler, Postman, Charles / Fiddler (HTTP proxy tools), the Profile GPU Rendering tool, Facebook Stetho and some old-school guerrilla techniques for spotting errors. Stay tuned!
