Before the Kotlin era of Android, the development ecosystem was completely different. Not only with the overhaul of a new fresher language to build for the platform with, but with ever evolving libraries as well, some of which have become mainstream in recent years.
If you were an excellent Android Developer in 2017, you’d be fairly average by 2020’s standard (bar your excellent problem solving skills of course). Things are different now.
Whether you’re a rookie in the art and looking to truly step into finding that first job or you’re a returning veteran, here you’ll find the libraries and technologies you need to know to be a strong Android Developer in 2020.
If you gain a good understanding of all of the topics here, even if you’re new to Android Development, you’ll have the skillset to outright skip the junior phase and get a mid-level job straight off the bat. Just make sure you back up your experience with an app of your own 😉
Language: Java and Kotlin
Yes, Kotlin is the new era, but we’re still in the transition phase. Knowing just Java is no longer enough, but neither is knowing just Kotlin. Most codebases out there, especially those that have been around since before the Kotlin era, still have much of their codebase written in Java. You will have to both maintain this Java code, add new features / fixes to existing Java classes, or refactor those classes to Kotlin.
And don’t think it’s enough to use Android Studio’s “Convert Java class to Kotlin” function. It’s great but you need to understand what the initial Java class was trying to achieve before you refactor it. You’ll run into problems otherwise.
Why is Kotlin so great though? There are probably a million articles out there singing the praises the language deserves, but to put it here briefly, it’s much cleaner, you can perform much more with less code, less boilerplate, and it’s more null-safe and type-safe so you’ll not only be spending less time developing but less time debugging too.
Android Support Libraries: AndroidX (aka Android Jetpack)
Gone are the days of the old Android Support Libraries. The Android Team have rebuilt many of their core components in a package known as AndroidX. Like the Support Libraries, these are libraries that aren’t bundled in with the core Android SDK and have to be imported separately via Gradle.
These AndroidX libraries cover pretty much everything from Activity, Fragment, Camera, DataBinding, ConstraintLayout, RecyclerView, you name it fam.
Unlike the Support Libraries however, the different AndroidX libraries are separately maintained and update so you can update your libraries independently.
Not to mention, there’s a group of components called the Android Architecture Components that act as building blocks for making a solid app, which you could very well make use of in pretty much any app.
Building Lists and Grids: RecyclerView
Gone too are the days of ListViews and GridViews. RecyclerView handles pretty much anything you need when it comes to building layouts with a dynamic number of items.
RecyclerViews are much more flexible, powerful, and a huge enhancement to ListViews and GridViews. The name comes from the fact that it ‘recycles’ views as you scroll past so items that are no longer visible past the upper edge of the screen get reused as the next item on the bottom edge.
Image courtesy of WiselTeach
On top of this obvious performance enhancement, RecyclerView offers much more flexibility when it comes to dynamic view types and bindings, animations, item click events, and item decorations. There’s simply no reason to use the old ListViews and GridViews anymore.
Making API Calls: Retrofit (+ either Gson, Jackson, or Moshi)
Retrofit has stood the test of time and has been to de facto way of making API calls for a while. Looking for a job without having Retrofit under your toolbelt is like putting your job search on Ultra Hard difficulty. It’s that important.
Why is that? It turns your api calls from fat chunks of code to a nice interface full of simple abstract functions that handle the api call for you.
@GET("repos")
fun getRepositories(): Call<List<RepositoryDataModel>>
Not only that, but it integrates well with pretty much any other Android technology that has anything to do with the API side of making the app work, including RxJava, Coroutines, and the numerous converter factories you’ll see around, which by the way, let’s talk about.
Gson, Jackson, and Moshi are all converter factories you’ll see being used around. Which one is the best one to go for is still an ongoing argument. While the most ideal situation of course would be to know at least a little about how to use each one of them, knowing at least one will do you enough good.
Oh and if you don’t know what a converter factory does, these allow you to receive your API calls and parse them directly as POJO’s (or Kotlin data classes). These offer the ability to deserialise API calls manually for more complex use-cases, and equivalently so, serialise data into JSON or XML for making POST API calls and the like.
Asynchronous Code: RxJava (Coroutines is a big plus)
Most apps will have the majority of their codebase filled with asynchronous code for making network calls, fetching from the local db, memory intensive tasks, and any function that requires a callback.
RxJava is still the most popular way to handle this with its use of easy-to-dispose observable streams to replace callback hell, and for the longest time, it was undoubtedly the best at its job.
But very recently, a new contender has come to the fray and is now gaining traction, and that’s Kotlin’s Coroutines.
Unlike RxJava that uses observable streams, Coroutines uses suspend functions to write asynchronous code as if it were synchronous code. Mad, innit?
Because it can be written like synchronous code, you have much more flexibility than you would with RxJava, and the learning curve isn’t so steep.
That being said, while it’s being increasingly adopted, most codebases still run on RxJava so unless you want to hold off on being an Android Developer until 2022, you will still have to know your way around RxJava.
Both RxJava and Coroutines work excellently with Retrofit as well. Take your pick.
App Architecture: MVP and MVVM
When it comes to app architecture, both the MVP (Model-View-Presenter) and MVVM (Model-View-ViewModel) are being used widely. You will quite likely qualify for most jobs by knowing one or the other, as once you know one, the other isn’t too hard to learn, but that should also be good reason to know both to begin with.
Going forward, I see less apps using MVP and more apps using MVVM, backed by the fact that the Android Team does recommend using MVVM in most situations, and the fact that many of the Android Architecture Components are based off of the MVVM pattern, but hey that’s just my opinion. Don’t @ me. (My very extensively argued opinion).
Image Loading: Glide or Fresco
After mastering the big stuff like architecture, asynchronous code, api calls and language, we can’t forget the little things that comprise our app. One such little thing is how we load images.
Picasso is pretty much a ghost town, but Glide and Fresco both have great traction around them and it’s arguable which one is better. Both offer easy-to-use functions for loading images with options that include fallback images, placeholder images, memory optimisations and the like. Learn one or the other, or in an ideal world, both.
Dependency Injection: Dagger or Koin
Effective use of dependency injection is one of the major things that separates mediocre Android devs from good Android devs. It is a heavily complex topic and what doesn’t help is there is no one right way to set up every app’s dependency injection structure, but knowing how to set up and maintain a structure is a strong skill to have as an Android dev.
Dagger comes up more often, so personally this is what I would recommend, but Koin is also gaining popularity. I’m not going to the intricacies of each one here, but there is no shortage of articles on them both online.
Testing: JUnit, Espresso, Mockito, Robolectric (TDD is a +)
It is IMPORTANT to know how to write both unit tests and UI tests. Pretty much every job wants to see good tests with your code, and again, this is one of the things that separate the bad from the better devs.
Unit testing in Android consists of the standard JUnit assert statements and using Mockito to mock objects so you can test components in isolation.
Use Robolectric to do your integration tests. There are devs that stand by the principle of using Robolectric for ‘standard unit tests’, and I have my strong negative opinions on this, but hey, don’t take my word for it. Try it out for yourself and take your own stance on it.
Image courtesy of official Android Docs
As for UI tests, absolutely do know your way around Espresso… that’s all I can really say about that. Espresso makes effective UI tests. UI tests are good, but don’t forget the testing pyramid. Unit tests plenty more than integration tests, and those more than UI tests.
Now simply writing tests isn’t as far into testing you can go. One approach loved by many is the TDD (Test-Driven-Development) approach. To explain this in a nutshell, this means writing your tests before writing your code. There are different ways about this, I’m not gonna talk about them here, but what I will say is if you have the time on your hands, to definitely try to get some TDD experience in. It’s a very strong and attractive skill to have.
Non-Android Skills
Must-know: Git
You can’t really do your work as a developer in any field without knowing Git. It’s how you manage your codebase versions. It’s how you work in teams. It’s how you fallback to working code when new changes destroy your app. Learn at least the basics of Git.
Good-to-know: Continuous Integration (Fastlane, Jenkins, etc.)
Automating your deployment process saves both you and your company for plenty of time. This does fall into the more senior/lead type of role, so it probably won’t be at the forefront of your mind, and among this entire list, this should be the lowest of your priorities. But if you do know your way around setting up continuous integration, you can easily make a case for why you should progress further up in the company ladder.
Conclusion
Yeah it takes a lot to be an Android Developer in 2020, and you may not necessarily need to know all of these skills for your first job. That being said, knowing all of these, there is absolutely no way an employer can justify you as a junior developer. You can easily make your case as a strong mid-level Android dev, and with a little experience and soft skills on top of that, a senior dev just like that.
I hope this article helped, if you liked it, please do feel free subscribe to the blog for more content like this. Share it around, idk, just give my blog some kind of traction. Happy coding ༼ つ ◕_◕ ༽つ