The Past, Present and Future of Android Development

With more than 80 percent market share, Android is the dominant mobile operating system today. It’s running on countless models of smartphones and tablets, as well as many other devices. Judging by this, one would think that programming for Android is simple and easy. Or is it?

A few years ago, Miley Cyrus was still singing country music, Justin Bieber wore his famous “Bieber” haircut, Malcolm still played in AC/DC and Android development was quite complex. Android developers had a lot of problems with developing even the simplest possible applications for Android OS.

Why? Well, my dear reader, problems were everywhere:

But that was like so 2013!

Everything changed last year, and changes were happening so fast that you could easily lose track of them and ask yourself, “When did this happen???” What’s even more important is the fact that the whole Android ecosystem underwent many improvements – we got new hardware (smartwatches), new software (Gradle, Android Studio), new OS (Android 5.0 Lollipop).

Everybody contributed – Google, device manufacturers, developers. Everybody had the same goal and asked themselves the same question: “OK, now we have stable OS, billions of apps with billions of users – how can we further simplify and improve Android? How can we make the development process better?” This is where open access and open source principles have shown their true potentials – everybody can make a change. An improvement. Something new.

It’s hard to summarize all the changes, but I’ve made a list of things which are (in my opinion) the most important:

Our favorite IDE for Android development finally became stable with the version 1.0. I won’t go into too much detail about why AS is great for the development process because we have already covered this topic in two of our blog posts (first and second). I’ll just say that the Eclipse ADT plugin is officially deprecated and I strongly advise you to migrate all your apps to Android Studio. Hail to the king!

Gradle is a project automation tool which has replaced Apache Ant as a primary build system for Android applications. It has gained huge popularity among Android developers because we can pretty much automate everything with it – from dividing our apps into different flavors, signing with correct configuration, incrementing our build numbers, defining external dependencies and much more.

Because of that, it has become a sort of an “administration” tool, with which we define and maintain our project settings. Gradle is also one of the main reasons for the increasing number of test automation libraries and automate build servers, which have brought the continuous integration (CI) development process to Android OS. But not everything is so rosy – Gradle is also heavily criticized for its speed of execution. It can be really slow on complex projects, but we hope that this problem will be fixed in the upcoming versions and releases.

Google said that Lollipop was the biggest improvement of Android OS since the beginning of mankind, and they were right. Every part of Android has undergone some modifications and improvements, but we are yet to see how users will react to the changes. We had a lot of problems with upgrading older devices to Lollipop, but we hope that this will be fixed in the upcoming versions.

A lot has been written about bright new Android UI, called Material Design. It’s one of the most important innovations on Android OS in the last few years, which has completely changed the look and feel of our applications. What I like the most about Material Design is the complete change of UX principles – everything is important. There is no such thing as tiny details which can be ignored. We have to respond to every user interaction, click, touch, etc. Because, as Google says, motion provides meaning. We have to be bold, embrace new vivid colors, use animations at every step, large fonts – simply said – we add life to our applications. Also, Material Design is completely adjusted to the Android ecosystem and it adapts to different screen sizes. That’s why our apps have a similar but not the same look on different platforms.

Everybody’s talking about design, UI components, animations, colors… But we are developers and we’re interested in what is under the hood. And, oh boy, the engine is pure beauty: a brand new runtime system, called ART. Just for the record, Android ART is not a new thing – it was introduced as a secondary runtime system on Kitkat. With the introduction of Lollipop, it became the primary system that has completely replaced Dalvik. ART is great because of several things, but I’ll mention only two of them:

We have started to develop apps for smartwatches, TVs and cars, but why stop there? If you are sitting in your room and having a cup of hot coffee, take a minute and look around yourself. You will probably see at least five things which will run Android OS in the next few years – the TV, laptop, tablet, camera, bicycle, kitchen appliances, thermostats, cars, etc. Android started as an experiment and it has proven that it can be run on every item which can hold a small microprocessor.

Smartphones are still core devices for Android OS. For a long time, we had problems with their overall quality. Older Android devices were much uglier and slower than older iPhones – iOS always felt more fluid. This was especially true for cheaper devices produced by a multitude of Chinese manufacturers.

Luckily, the quality and speed of Android smartphones have steadily increased, so today we have a plethora of new devices that are suitable for everyone’s budget and needs. It doesn’t matter if you want a mobile phone with great camera resolution, design, processor or battery – we have it all.

My personal favorite is Motorola Mobility (nowadays a subsidiary of the Chinese computer technology company Lenovo) with their great line of smartphones – Moto X, Moto G and Moto E, which indeed have a really good price/quality ratio. Also, a team at Google is working on a modular smartphone. Project Ara aims to completely shake the Android world and, if all goes well, it probably will.

As we have finally fixed most of our problems with IDEs and OS versions, we can shift our focus to other Android problems.

IMHO, the most important problem is the core problem of Android development – Java. Sorry, Java Harmony. Which is basically Java 7. Or Java 6. But is not Java. Don’t get me wrong – I strongly believe that Java is a good programming language, but I also think that it’s the right time to think outside of the box. We need to start looking for other programming languages that will replace Java as the primary language for Android development.

Just look at our most important competitor – Apple. They have introduced a completely new language called Swift which combines the best features of several other languages (like Python, Ruby or C#). We already need considerably more time than iOS developers to develop the same app, and now we’ll be even slower.

That’s why we need something new. We already a have few ideas about which language could replace Java. My eyes are set on Groovy. Its syntax is quite similar to Java (actually, it’s built upon Java) and we already have some working prototypes. Also, don’t forget that it is the primary language for Gradle – so why not use it in Android development? Or maybe Scala (which is quickly gaining new users) or Kotlin (Jake Wharton recently wrote a great overview of Kotlin for Android)?

I would also like to point out one more problem – database management API. If you commit blasphemy once again and take a look at our competitors – iOS (Core Data, to be more precise) – you’ll see that they have really nice methods and GUI for creating database objects, CRUD methods, database change listeners. But if you look at the default Android API – we still haven’t gotten far from writing SQL commands which greatly affects our development process.

Debugging SQL errors is not so easy – it’s time consuming, and we have no GUI for looking at our database data. Although there are some good ORM libraries (like GreenDAO, ActiveAndroid or SugarORM), they all have their own problems. I have never been completely satisfied with them – they have been either complex to use or something has been missing (like database change listeners). My mind is set on Realm for Android and DBFlow, which I’m hoping will solve all of my problems and will also have shorter execution times.

A lot has changed in the past few years for Android. It has evolved from a simple OS for smartphones and is now powering many other devices. Time will tell what will become of it. Who knows, maybe we’ll even program nuclear fusion reactors with it. Or Terminators. Terminators are more fun.