11 Things You Should Know When Starting Android Development

In this article, I’m going give you exactly what you should know when starting Android development.

These tips will help you learn Android development much faster than if you were floundering around trying to understand what to learn first.

So let’s get right into it!

1. Java vs Kotlin — Which Should I Learn First?

One of the first dilemmas you’ll be faced with as a beginner is whether you should learn Java or Kotlin first.

First of, you can ease your mind by realizing that this question isn’t actually all that important in the long run.

Both Java and Kotlin can be used to develop Android apps. Both languages are easy to learn, and once you know one language, it’s trivial to learn the other.

However, there are benefits and drawbacks to each language. I’ll list those and let you decide on which one you want to learn first.

Java

First up, I’ll discuss Java. Here are its benefits:

1. Java is a very well known and widely used object-oriented programming language. As such, knowing Java will not only help you to understand many applications, not just Android apps.
2. Java is pretty straightforward to understand, and is probably a great choice for your first programming language.
3. Java has been around for a very long time, so the language is a lot more mature than Kotlin.
4. Java is the de-facto standard for learning OOP (object-oriented programming). Learning design patterns will be very simple if you know Java.
5. Java will give you a better understanding of the JVM (the Java Virtual Machine).

But as with anything, there are downsides to Java. Here’s a few of those:

1. A lot of Java code is “boilerplate” code; in other words, it’s code that’s necessary for your code to work, but has little to do with the actual logic of your code. This results in duplication and hard-to-change code if you aren’t careful.
2. Related to the last point, Java is a rather “verbose” language. Most of your code needs to be explicit, which is what causes boilerplate.

Here is a simple code example to show what I mean in point #2. This is how you declare an object variable in Java. Let’s say it’s a car object:

Car myCar = new Car();

Doesn’t seem like a lot of code, I know. But here’s the same thing in Kotlin:

val myCar = Car();

There is very slightly less code in the Kotlin version, so you may not think this is a big deal. But there are a lot more different scenarios where Kotlin’s code is more expressive and leaner than Java’s code. After a while, these differences add up.

So that’s pretty much it on Java. Now let’s discuss Kotlin.

Kotlin

So as I’ve said, Kotlin code is more compact and less verbose than Java code. That’s just one advantage of Kotlin over Java. Let’s look at the others:

• Kotlin is now the language that most new apps are being developed in and that Google themselves recommend. Knowing it means you’ll be up-to-date. This is the primary reason you might want to learn Kotlin first.
• In my opinion, Kotlin is somewhat easier to learn than Java, though Java is pretty easy to learn too. However, I knew Java before Kotlin, so switching was very trivial for me.
• Kotlin has a lot of syntax sugar to decrease verbosity — we already delved into this somewhat.
• Kotlin seamlessly integrates with Java so you don’t have to learn Java to use Kotlin.
• Standard Kotlin has more helper classes and an overall easier-to-use structure than Java .
• Kotlin does a pretty great job at eliminating null values and null checks from your code. This is probably one of its biggest advantages.

My Opinion on What You Should Learn First

So what is my opinion on which to learn first? Keep in mind, this opinion really has rather little effect on your long term success.

But if I had to pick one, I’d say Java. Java is simply so well-known and widely used, you’ll appreciate that you learned it when you see code samples.

And plus, once you do grasp a good understanding of Java, you should be able to learn Kotlin in less than a week. I can’t say the same for learning Kotlin first.

And on a side note, one of Kotlin’s biggest advantages — decreased boilerplate and verbosity, is also one of its biggest disadvantages. Why?

You might think decreased verbosity is always great, but if you learn Kotlin first, the problem comes when you don’t understand why Kotlin was invented.

In other words, you won’t understand the downfalls of Java’s old boilerplate and verbosity that lead to the creation of Kotlin — if you learn Kotlin first. This may lead to you doing things improperly if you learn Kotlin first.

Learning Java first establishes a great base for you to build your knowledge from. Learning Kotlin first ensures you’ll be up-to-date.

But in the end, it really doesn’t matter all that much. I think Android developers should be fluent in both languages.

2. Learn From the Right Sources — Preferably Paid

There are a lot of Android developers out there — and not all of them do it right. It’s crucial you learn from the right sources, or you could actually be learning detrimental material.

My favorite platform for learning Android related content is Udemy. You may prefer something like Pluralsight, Skillshare, or Udacity.

Whichever platform you prefer, I recommend you do find some high-quality paid material. When you find a highly-rated course on the subject you want to learn, I recommend you check its release date and make sure it is recent.

Many times we don’t value free courses as much as paid courses, so we never finish the free courses. That’s why I say to take paid courses if you’re serious about this.

I know these are obvious tips, but there are a lot of highly-rated courses on say, Udemy, for example, that are outdated but highly-rated because of their age.

Don’t go for those. Make sure you are learning up-to-date, relevant material. And if you need to learn Kotlin first to do that, then go right ahead.

I don’t have much experience with platforms other than Udemy, so I can’t really comment on the best practices for those platforms. I will simply insert a list of my favorite instructors on Udemy and YouTube so you can start learning quality content fast.

• Vasiliy Zukanov
• Mitch Tabian
• Coding in Flow

Check these guys out — you won’t regret it.

3. Learn With the Latest Version of Android

As I’ve stated before, it’s important you’re learning about the latest version of Android. Why am I emphasizing this simplistic “duh, of course I should do that” tip?

The main reason is simple. Only in the latest versions of Android have Google finally been pushing good (should I say, better) design practices, such as MVVM architecture and databinding.

These technologies and architectures are not new, but traditionally they have been tricky or even impossible to implement in Android.

As such, many old courses will teach you old technologies and therefore bad practices, hacks, and work-arounds that dirty up your code.

And whatever you do, don’t even start learning AsyncTask.

In all seriousness, try to be aware of what you should be learning and avoid those old practices as much as possible.

To help you, I’ll give you a guide as to what Android technologies you should be learning in 2020 later in this article.

I know that in the future, these technologies won’t be as relevant. But the concept is the same — always learn to use the latest version.

For an example, in the not-so-distant past, I paid for an old, highly-rated course on Udemy that taught me an old version of Android (it was actually just Android Oreo, but technology flies).

Guess what? After that course, I immediately wound up spending a lot more wasted time learning the latest version of Android.

If I would have chosen an up-to-date course to begin with, I would have moved much faster.

4. Make Sure You Understand Lifecycles

After you learn your language of choice and understand the basic components of the Android framework, you need to start learning lifecycles and how they work.

There are three main lifecycles you should concern yourself with — app lifecycles, activity lifecycles, and fragment lifecycles.

Knowing these lifecycles helps you in two ways:

1. Lifecycles are fundamental to everything in Android development.

You’ll use onCreateView() in every fragment, and onCreate() in every activity. But onCreate() for a fragment and onCreate() for an activity are very different. These kinds of nuances you will only know by learning how fragment and activity lifecycles work.

2. You’ll have fewer memory leaks and bugs.

A classic example is where an observer outlives its listeners, resulting in accidental NullPointerExceptions. This happens when you forget to unregister your listeners in onStop() or you use things like LiveData (which manages its lifecycle automatically) improperly.

These bugs can wreak havoc on your codebase and cause many hours of cursing at the screen and wanting to smash your computer to bits on the spot (don’t do that by the way).

5. Know SOLID Principles

If you’re an absolute beginner, you can safely ignore this section. But if you know Java and can create a few simple apps, these are what you’ll want to learn next.

Not long ago, I didn’t think knowing SOLID principles and design patterns was all that important or beneficial. Boy was I wrong.

A lot of self-taught programmers (which I assume you are, or wish to be) think that the technology they are using is the most important thing to learn. They aren’t far wrong — you do need to know your tools.

But what do tools and libraries actually do for you?

They speed up your development, that’s all. They do not introduce new concepts of software design.

Simply put, you should know why the tools you use exist. I’d say this is even more important than learning the tool itself.

For instance, you shouldn’t be learning Dagger 2 without first learning about inversion of control, dependency injection, and maybe even doing some dependency injection by hand.

Then, and only then, should you learn Dagger 2. Once you know why Dagger 2 exists and the concepts it’s based on, you’ll be able to learn it much faster.

Getting to the point, SOLID design principles are the underlying principles for pretty much everything that modern software developers do.

For instance, dependency inversion — the “D” in solid — is the entire reason Dagger 2 exists. If you didn’t know SOLID and you were using Dagger 2, you’d have no clue what the framework is actually doing.

So I’d highly recommend you learn the basics of SOLID design principles. If you don’t do it right now, you’ll definitely be learning it later. Every software developer should know these principles.

Shameless plug — I’ve written a series of articles on SOLID and I’d love for you to check them out:

• S — Single responsibility principle
• O — Open/closed principle
• L — Liskov substitution principle
• I — Interface segregation principle
• D — Dependency inversion principle

6. Know Basic Design Patterns

Once again, if you’re a total beginner, you can feel free to skip this section.

As you get more experience writing code, you’ll see that there are certain patterns that come up a lot.

This isn’t a coincidence. There are about twenty-three primary design patterns that have been constructed from countless hours of experience and failures from thousands of programmers over the years.

The main benefit of these design patterns is communication. These patterns are well-known, so it’s easy to say “oh yeah, I could do that in 10 minutes with an observer pattern,” and everyone should understand your meaning.

Here are the design patterns you should probably know:

• Observer pattern (because it’s everywhere. When you need to communicate from one object to another, this is your go-to pattern)
• Adapter pattern (for understanding RecyclerView adapters, ListView adapters, ViewHolders, etc)
• Facade pattern (for understanding third-party APIs and why they are structured like they are)

7. MVVM, MVC, MVP, or MVI — What’s the Best Architecture?

One question I struggled with when I first started learning Android development is “Which architecture should I use for my apps? Which is best?” I had soon realized that putting everything into MainActivity wasn't going to work for long.

The short answer is: MVC or MVVM. But hear me out.

The long answer is basically that these patterns consist of nearly the exact same ideas. They are just implemented in slightly different ways. The best architecture is the one that’s right for your app and how your users will interact with your app.

Before I go any further, I have to shout out my favorite instructor here — Vasiliy Zukanov.

His content on this subject is top-notch, and it would be unfair to talk about this concept without mentioning him.

You can check out his course on Android Architecture if you really want to understand the underlying principles of good architecture.

Anyways, if you really want to know what you should learn first right now, here are my recommendations. But since these are so similar, it really matters rather little which one you learn first.

I personally now think MVC is what you should probably learn first — simply because it’s so widely known and it lays the foundation for the other architectures.

But if you’re short on time for learning new stuff, MVVM is Google’s recommended architecture and it is similar to MVC, with a few changes. Learning it will let you dive right into the Android documentation and understand a lot of the code there.

Until recently, MVVM was my go-to architecture. I’m now favoring MVC for a number of reasons. Let me know if you want to know my thoughts on this.

Then there are the lesser known architectures.

• MVP is essentially MVC with a couple minor differences.
• MVI is another spin on MVC architecture, but can be complex — not recommended to learn first. But in the end, it matters rather little.
• Any other architectural pattern is probably something you shouldn’t concern yourself with. These 4 patterns are well established and if implemented well, will result in clean code.

8. Which Technologies Should I Actually Know as an Android Developer?

This was one other question that plagued me when I first started. After you know the basic Android framework, what technologies should you learn?

After developing apps for a little while, I’ve come to the conclusion that you should probably focus learning these specific technologies I’m going to show you here.

Keep in mind that pretty much all of these libraries are widely used by the Android community, and you’ll likely run across them at one point or another. It’s good to know what you need to know right here.

• Basic AndroidX libraries (which constitute Android Jetpack)
  These libraries are the core of Android functionality, and most of the things you’ll use from here will be UI components. Keep in mind, AndroidX is actually a re-write of the Android support library.
• Room Persistance Library
  When you need offline storage, you typically use SQL to get stuff from the offline database. The Room persistence library will help you do this much faster, by helping you create entities, DAOs, and all kinds of neat technical stuff.
• Google Firebase
  Firebase (particularly Realtime Database) is simply my favorite cloud database at the moment, so this will likely change. But if you want a solid cloud database, you can’t beat Realtime Database or Firestore for Android in my opinion.
• Retrofit 2
  Nearly every developer will need to work with RESTful APIs at some point in their career. Retrofit 2 is the standard library for everything REST in Android. If you’re writing networked applications, knowing Retrofit — and consequently REST — is pretty much a requirement on many apps.
• Dagger 2
  Dependency injection is a vital principle to constructing good Android apps. Dagger 2 is the standard way of doing this more quickly than creating your own dependency injection component. It’s widely used and you’ll probably encounter it soon. Learn it.
• RxJava 2 or at the time of writing, RxJava 3 might be worth checking out.
  RxJava is an interesting library. It’s primary purpose is to help you more easily create asynchronous code that runs on background threads and returns asynchronous results. It’s used in many Android apps, so you’ll need to know the basics of RxJava before reading the code of these apps.
• Glide
  Glide is a popular image loading library, complete with built-in caching. It’s pretty easy to use and it’s used by plenty of Android developers.
• Mockito, MockK or some mock injection service for unit testing.
  I’ll make this more clear in tip #10.
• Gradle/Maven build automation systems
  The reasoning behind this is simple. You don’t have to know a lot about Gradle or Maven, but you should know enough to throw in libraries and dependencies as needed. Just search anything you don’t know on Google and you’ll probably get a good answer.

9. When Can I Call Myself a “Good” Android Developer?

This question I’ve struggled with for a long time. I figure I will for a long time more.. I still feel imposter syndrome, and I picture myself as being much worse than I actually am. After some time, I do hope that I’ll feel more confident as a programmer.

But if you want it, in my opinion, a competent Android developer understands the following:

• Importance of architecture and good design that works for your problems.
• Importance of TDD as shown below.
• The technologies I mentioned in the previous tip.
• Data structures and algorithms
• How to communicate your problems clearly and the importance of communicating often.
• How crucial it is to always be learning and interacting with other Android developers.

Anything else is icing on the cake! Let me know if you have another thing you want to add this list. I’d love to hear your opinions.

10. After Learning the Basics, Start Unit Testing

Finally, I want to leave you with one of the best practices you can start after you’ve learned Java, Kotlin, the Android framework, and the technologies in tip #8 — unit testing.

Unit testing has plenty of benefits. I’ll outline a few of those.

• Single responsibility principle (first letter of SOLID) is enforced when you’re unit testing properly.
• You can change your code more confidently because you are protected against “regressions” or the quality of your code decreasing as you change it.
• You validate that your code does what it’s supposed to do.

Nearly always, you’ll unit test using TDD, test driven development. This is a technique that “Uncle Bob” Martin is a big advocate for, and his book, Clean Code, will help you understand why you should be using it.

Once again I will credit Vasiliy Zukanov for his insight on this topic as well. I know I sound like a salesman for him, but there is a reason his courses are ranked so highly. They are very professional and polished courses, and any Android developer would benefit from them. His course on unit testing is something you should absolutely “test out” :)

Lastly, once you understand unit testing fundamentals, you should be trying to learn Mockito for Java unit tests, or MockK for Kotlin unit tests.

These libraries help you create “mocks” for testing that can speed up your development time drastically. While this is awesome, you’ll understand the concepts of TDD much better if you get some experience doing tests without them.

Conclusion

And as anyone in tech would tell you, just have fun with it! It’s important to enjoy learning all of this interesting stuff. Don’t stress over it or try to go too fast. You won’t retain the information very well if you do so.

Lastly, it’s vital to AAB — always be building (you can thank Danny Thompson for this :))

And finally, it’s probably a good idea to start and consistently update a blog where you talk about what you’ve learned.

This is the classic rubber-ducky method, and it will help you solidify your communication skills in addition to your technical skills. It will also help you interact with other developers.

All of that is exactly what I do here :), so leave your thoughts and opinions in the comments below. Happy coding!

(This article comes from my blog at https://darrenfinch.com/11-things-you-should-know-when-starting-android-development)