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:
- Buggy IDEs – have you ever tried to repair your car with a shovel? Or tried to pick up girls while driving your grandfather’s 40-year old Yugo? In the Android world, we had an official IDE for Android development – Eclipse, which had a ton of problems and could drive you mad in 10 minutes. The Eclipse ADT plugin was just buggy, slow and unfriendly for more complex projects. We quickly got sick of it and were praying for a miracle.
- OS fragmentation – Gingerbread (2.3.7) occupied quite a market share (at least 15-20 percent) of Android OS versions. As you already know, Android underwent complete overhaul with the version 4.0 (Ice Cream Sandwich) – we got new UI elements, new APIs for device hardware, new screen densities… This resulted in us having to be careful to optimize and program our apps to work well on the new as well ancient versions of Android. All this greatly affected our development process and resulted in prolonged development time with more bugs and crashes.
- Slow emulators – We need to test our apps on different Android OS versions and screen dimensions, so we have to buy at least 20 different Android devices. Sounds crazy? OK, so we can use emulators. But have you ever tried to use the default Android emulator? It’s so painfully slow that you’ll soon catch yourself counting cars parked in front of your office while your app is being deployed to your emulator.
- UI – Android apps were boring. If you commit blasphemy and take a look at iOS apps, you will see that they are full of life and colors. Everything is animated, transforming, going from left to right, right to left and so on… Our apps were static, and if we wanted to enrich our UX, the old Gingerbread would have soon killed all our hopes and wishes.
But that was like so 2013!
A fresh start
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:
1. Android Studio
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.
4. Lollipop on the outside – material design
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.
5. Lollipop on the inside – ART
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:
- It uses AOT (ahead-of-time) compilation, which means that it compiles the intermediate language (Dalvik bytecode) into a system-dependent binary. This results in shorter execution time of our apps, less CPU usage and less battery drain. On the other hand, the installation process is quite longer.
- It provides multidex support out of the box. Dalvik dex files had one major flaw – they could contain only 65,356 methods. We had to organize our Android applications in a way that the method count doesn’t exceed this limitation. Although this number may seem quite big, if you take into account Google Play services (which are needed in almost every application) and a few external libraries, you could easily exceed this limit. ART organizes your application in a way that it breaks byte-code in multiple dex files which are packaged together in one single APK.
4. Android is everywhere
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.
5. Increased quality of smartphones
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.
Moving away from Java
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)?
Getting better at DB management
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.