This chapter is an introduction to Android Studio and provides a helicopter view of the different tools that come with this Integrated Development Environment (IDE). In addition to this, some other important tools will be discussed here, such as Genymotion, the emulator that I highly recommend you to use to test your app on different kinds of devices.
Using Android Studio, you can create any app you like. Apps for phones, phablets, tablets, watches and other wearables, Google Glass, TV apps, and even auto apps.
If you already have mobile programming experience or even have worked with Android apps and Eclipse before and you want to discover how to create apps that take pictures, play media, work on any device, connect to a cloud, or anything else that you can think of, then this book is for you!
All recipes described in this book are based on Android Studio for Mac; however, it is not a problem at all if you are using Android Studio for Windows or Linux instead. The terminology is the same for all platforms. Just the screenshots provided with each recipe may look a little bit different, but I am pretty sure you can figure that out with a little effort. If there are any significant differences for Windows, I will let you know.
Android Studio is the recommended IDE to develop Android apps and is available for free for anyone who develops professional Android apps. Android Studio is based on the JetBrains IntelliJ IDEA software, which might explain why even the preview and beta versions of Android studio were already better than Eclipse and why many Android developers were using it as their IDE from the beginning.
The first stable build of Android Studio was released in December 2014 and has replaced Eclipse (with Android Development Tools) as the primary IDE for Android development. Now, with Android Studio, we do not just have a more stable and faster IDE, but it also comes with cool stuff such as Gradle, better refactoring methods, and a much better layout editor to name just a few of them.
Okay, I still have some weird issues every now and then (I guess that is what life as a mobile developer is all about sometimes) but I certainly do not feel the frustration that I had felt when I was working with Eclipse. If you are using Eclipse for plain Java development, it is just fine I guess; however, it does not play nicely with Android. If you have been using IntelliJ IDEA for Java development tasks before, then Android Studio will look pretty familiar to you.
Android Studio really brought back the fun of mobile development. If you are using Eclipse currently, then you should switch to Android Studio instantly! To see it for yourself, get it from https://developer.android.com/sdk/index.html and start building cool apps using Android Studio right away.
What has remained is the fragmentation challenge that you need to deal with when it comes to Android development. There are many devices running on many Android flavors and versions.
There are a lot of Android versions, resulting in fragmentation. Because of this, you cannot expect that all devices will run on the latest Android version. In fact, most do not. Many devices still run on Android 4.x (or even older versions), for example.
Here, you can see a table with all the relevant Android versions and distribution numbers. The numbers in this table indicate that if you decide to support Android 4.0 and later releases, you will reach 88.7 percent of all Android users. In this example, the numbers for Q2 2015 are shown, which explains why Android Marshmallow (6.0) is not being listed here. If you create a new project in Android Studio, you can get the actual numbers by clicking on a Help me Choose link in the Create New project wizard dialog, as we will find out in the next chapters.
Let's have a look at the following screenshot which describes the cumulative distribution of different Android platform version along with their API level:
In addition to software fragmentation, there is also a lot of hardware fragmentation that you should be aware of. Writing an Android app is not that hard but writing an app that functions well on any Android device actually is.
A good app should be able to run on as many different devices as possible. For example, think of an app that takes pictures. Android devices do have a camera or multiple ones or no camera at all. Depending on other functionalities that your app provides, you might need to worry about other things as well, such as whether a device is able to record sound or not.
I can imagine you want to reach an audience as large as possible so you should always ask yourself which of your app feature demands will or will not have to be mandatory. If a device does not have a camera, the user might not be able to take pictures, but should that really be a reason for not allowing the user to use the app at all?
The introduction of runtime permissions in Android Marshmallow (6.0) makes it even more important for you to provide some kind of a fallback functionality in your app. At least you need to explain why a particular functionality is not available in your app. For example, the user device does not support it or the user did not gave permission for it.
This book is going to help you deal with Android fragmentation and other issues.