If you have been thinking about learning Android development but just haven’t got around to start the process yet, now is the time. Perfect time. Let me explain why. :)

Android has been around for 10 years. The framework and working methods have expanded and grown over that time into a huge framework that needs to be understood at least on some level by anyone willing to work with the system.

However, in the last year or so many of the core pillars of the daily Android developer’s work have been pretty much reset and everyone have been starting from the beginning again.

Programming language — Kotlin

Kotlin isn’t a brand new language but as a first class citizen on Android it’s been around only a bit over a year. While some customers still insist working in Java a huge majority is thinking forwards and migrating either all code or all new code to Kotlin only.

I have argued that “starting a new Android project with Java is a bad idea”:

Why starting a new Android project with Java is a bad idea

For some more scientific poll numbers take a look at the Pusher’s State of Kotlin survey results.

The State of Kotlin survey findings

At the beginning of the year, we ran a survey on the State of Kotlin, asking developers for their thoughts, opinions…

For a new developer this means that the people who have been around for longer no longer have a huge head start. There were some brave early adopters but a huge portion of Android devs have been working in Kotlin only for a year or so. You won’t be seeing requirements for years of experience in this language in job adverts.

Swiftiness

If you happen to have iOS background learning Kotlin won’t take long. The languages are very similar in syntax but even more in programming paradigms. Any Swift developer will feel right at home in Kotlin.

Even if you don’t have Swift background Swiftiness of Kotlin (or Kotliness of Swift) has huge benefits in app development environment. Android teams are able to fluently read iOS team’s pull requests and vice versa. You will effectively be learning 1.8.toFloat() languages with price of one.

Layouts — ConstraintLayout

Building scalable screens has been one of the most important skills of an Android developer since the early days. The way screens were built evolved and new ideas were experimented. Some survived and some died.

In early 2017 Google introduced the first stable release of a new layout, ConstraintLayout. As an idea this way of defining layouts isn’t exactly new. The layout is based on Cassowary algorithm from 1990s. However, in Android it was a natural evolution of the slow and clunky RelativeLayout.

Learning ConstraintLayout is easy. You won’t have to know all the bells and whistles to be able to use it. Just start and you will find yourself replacing nearly all other layouts with this new one.

AutoLayoutiness

Again, if you’re coming from the iOS world you will recognise similarities between the iOS AutoLayout and Android ConstraintLayout. However, be careful not to bring the strict screen size limitations with you. Android has infinite screen sizes that must be supported and that’s what it was built for!

Way to put apps together — Architecture Components

For a long time Google’s Android team refused to recommend architectures to use in building Android apps. Their approach was that the framework is the tool and how you use it is up to you. Now, I don’t blame them. Actually, I think it was a great way to let design patterns rise and evolve naturally.

However, that said, it also lead into huge diversity of approaches in different companies. When joining a new company the first question always was: “what kind of architecture and tools you use?”. The answer varied from simple to event bus implementations and RX and beyond. This also created strange limitations or issues when looking for a job. Some companies preferred tools you hated (RX) and some were more suitable. While this is still true partially, things are changing.

Google introduced Architecture Components. This is a set of components and libraries that guide developers to right direction when defining how, for example, data should flow through the application. Things like LiveData and ViewModels are some of the core ways to handle common data related issues. They’re simple and commonly used. You no longer have to prepare for a job interview by memorising multitude of 3rd party libraries and the latest “hip frameworks” but instead studying the Arch Components will suffice. When asked about Android background tasking WorkManager is very rarely a wrong answer.

The benefit of standard Architecture Components naturally goes beyond job interviews. Joining Open Source projects is easier, starting your own projects is faster as you can simply go with LiveData for most use cases when dealing with reactive UIs.

All the other stuff

OK, just learning the above 3 things won’t make you a ready Android developer. You’ll still need to learn the framework APIs and Android Studio tools etc. However, once you have started the rest will come over time. Reaching a solid basic knowledge is now easier than before.