After downloading Android Studio, install it and go through the setup wizards. The wizard checks for some requirements, whether the Java Development Kit (JDK) is available, and other important elements that the installation wizards guide you through.

Once the installation is complete, it is time to develop your first Android app using Android Studio, just to check whether everything has been installed correctly and works the way it should. It probably will be no surprise that this is where the Hello Android Studio recipe comes in.

Android Studio uses Gradle build scripts. It is a project automation tool and uses a Domain-specific Language (DSL) instead of the more common XML form to create the configuration of a project.

Projects come with a top-level build file and a build file for each module. These files are called build.gradle. Most of the time, it is only the build file for the app module that needs your attention.

A typical build.gradle file may look like this:

applylugin: 'com.android.application'
android {
  compileSdkVersion 21
  buildToolsVersion "21.0.0"
  defaultConfig {
  minSdkVersion 8
  targetSdkVersion 21
  versionCode 1
  versionName "0.1"
  } 
}
dependencies {
  compile fileTree(dir: 'libs', include: ['*.jar'])
}

The Gradle build system is not something that you need to worry too much about right now. In later recipes, we will see what the real power of it will be. The system is also designed to support complex scenarios that may be faced while creating Android applications, such as handling customized versions of the same app for various customers (build flavors) or creating multiple APK files for different device types or different Android OS versions.

For now, it is ok just to know that this is the place where we will define compileSdkVersion, targetSdkVersion, and minSdkVersion, just like we did in the manifest file previously in case you have been using Eclipse.

Also, this is the place where we define versionCode and versionName, which reflect the version of your app that is useful if someone is going to update the app you wrote.

Another interesting key element of the Gradle functionality is that of dependencies. Dependencies can be local or remote libraries and JAR files. The project depends on them in order to be able to compile and run. In the build.gradle file that you will find in the previous folder the app folder you will find the defined repository in which the libraries reside. jCenter is the default repository.

If for example you wish to add the Parse functionality, which is something that we will do in the recipes found in the next chapter, the following dependency declaration will add the local Parse library to your project:

dependencies {
compile fileTree(dir: 'libs', include: 'Parse-*.jar')compile project(':Parse-1.9.1')
}

Using external libraries has become much easier. For example, if you want to add UniversalImageLoader, a well-known library to load images from the Internet, or if you want to use the functionality from the Gson library, which basically is an object wrapper for JSON data, to your app, the following dependency declaration will make these libraries available to the project:

dependencies {
compile 'com.google.code.gson:gson:2.3+'
compile 'com.nostra13.universalimageloader:universal-image-loader:1.9.3'
}

The best way to test your app is by using a real device. The Android emulator is pretty slow and does not provide you with all the features that come with a real device, such as a camera and all kinds of sensors.

I can image that you do have just one or perhaps a few devices. With thousands of Android devices being available and many brands and models that run on a customized (for example, the Samsung devices) or a plain (like the Nexus devices) flavor of the Android OS and on any Android version that you can think of, testing on real devices only would become pretty expensive.

If, for example, you are creating an app that should run well on Android 2.3, Android 4.x, and Android 5.x, using emulated devices can be handy. Unfortunately, the default emulator is terribly slow. It takes ages to start Android on the emulator, and debugging can be very slow on it as well. To make the emulator a little bit faster, you could try to install Hardware Accelerated Execution Manager (HAXM). There are some topics on the Internet that tell you how to do this; however, there is a much better solution, Genymotion.

Genymotion is a real, fast, and easy-to-use emulator and comes with many real-world device configurations. You can read more about Genymotion on its website at www.genymotion.com. It is available as a free or paid solution. The free one will be all right to start with.

How to do it...

Let's install Genymotion to prepare Android Studio to work with smoothly running emulated devices:

1. Both Oracle's VirtualBox and the Genymotion app need to be installed. This is because Genymotion virtualizes various Android operating systems using the virtualization techniques of Oracle Virtual Machine (VM) VirtualBox in the background. If you do not already have Oracle VM VirtualBox installed on your computer (or if you have a version of VirtualBox that is below 4.1.1 which is not compatible with Genymotion), you need to install it first.

   Download VirtualBox for OS X hosts (or for Windows) from the VirtualBox download page at https://www.virtualbox.org/wiki/Downloads.

   Install VirtualBox, and after that, reboot your computer.

   Download Genymotion from its web page at https://www.genymotion.com/#!/download.

2. Now, open and install the downloaded file.
3. Run Genymotion. A dialog box then asks you whether you want to create a new device. Click on the Yes button to do so. Later, you can create additional devices by clicking on the + (plus) button on the main screen.
4. Select the Android OS version from the drop-down list on the left-hand side of dialog box.
5. Select a virtual device (brand and model) from the drop-down list on the center and click on the Next button.
6. Name your device. It's recommended that you include both the device and the OS version in your device name so what you are testing on can be easily recognized when you want to use it later.
7. Click on the Next button to confirm the name. Your virtual device will be created, and it will appear in the list on the main screen of Genymotion. Create as many virtual devices as you need.
8. To run a virtual device, select it and click on the Play button. It will launch the Genymotion emulator so that you can use it together with Android Studio. When it is launched, you can unlock the device so that it is ready to use.
9. If you hit the Run button in Android Studio again, you will notice that the running virtual device is shown in the list of available devices in the Choose Device dialog box. Just click on the OK button to let the magic begin. Your Android app will be launched on the emulator.

And it is running fast and smooth! Pretty cool, isn't it?

The following is an example of the main screen of Genymotion listing a couple of virtual devices that have been created:

There's more...

Genymotion comes with emulated front and/or backend cameras, depending on the chosen configuration. To enable them, click on the camera icon. A new dialog box appears in which you can change the slider to On and choose a real camera for the front and backend camera of your virtual device.

After selecting a camera, you can close the dialog box. A green checkbox will now appear next to the Camera button. Now, whenever an app needs to use a camera, it will use the selected camera, which in my case is the webcam on the laptop. To check whether this is working, choose the Camera app on the virtual device.

The paid version of Genymotion has additional features available, including emulated sensors such as GPS and accelerometers. If you like, you can check out the differences at https://www.genymotion.com/#!/store.

Remember that although using virtual devices for testing purposes works really great with Genymotion, it is important to always test it on multiple real devices. Some issues, in particular the ones that are related to memory management that we will see later in this book, are easy to reproduce on real devices, but may be somewhat harder to reproduce on virtual devices.

In addition to this, real devices are much more pixel perfect and some issues may appear only on a particular device so when it comes to see how the artwork looks, you are going to need a couple of them.

By the time your app is nearly complete, you might be interested in the (paid) services from Testdroid, a cloud-based service that allows to run (automated) tests on many real devices. Visit www.testdroid.com to learn more about this great service!

The following screenshot provides an example of the Hello Android Studio app running on a virtual Nexus 5 device using Genymotion:

Good software engineers refactor their work continuously. Names of methods and members should always indicate what they are doing. Since business requirements often change during the development process, in particular when agile methodologies come in, so do your apps.

If you choose the right names and stick to the rule that the length of methods must be limited to, well let's say, scrolling one page at most to view the whole method, often you do not need many comments to explain what your code is doing. If it is hard to come up with a good name for a particular method, then it is probably doing too much.

Since changing names could be scary, as it could break your code, developers often choose not to do so. Or, they decide to do it later. You save yourself a few minutes by doing so in advance. Your code could be hard to understand if some one else has a look at your code or if you have a look at your code one year later. Going through the code to find out what a method does can be very time consuming. A descriptive name for your method can solve this.

The good news is that using Android Studio, refactoring is painless and pretty easy. Just highlight the name of a member or method, right-click on it, and pick the Refactor item from the context menu that pops up.

In the Refactor submenu that appears when you choose the Refactor item, you will find many interesting options. The one option that you will use here and which you will be using the most is the Rename… option.

How to do it…

The following steps describe how to rename a method in the Refactor submenu:

1. Highlight the name of the method you would like to rename.
2. From the context menu, choose Refactor.
3. From the submenu, choose Rename (or use the shortcut Shift + F6).
4. Now, you can rename your method or member in place and apply the changes by hitting the Enter button. Android Studio provides you with some suggestions that you can accept or you can type the name you want.

   Tip

   If you repeat step 2 and 3, a dialog box appears in which you can edit the name. (Or use the shortcut Shift + F6 twice).

5. Click on the Preview button to see what the effect of the renaming will be.
6. At the bottom of your screen, a new view appears, which shows you the impact of the renaming in each file (class, resource, or otherwise).
7. Click on the Do refactor button in that view to apply all the changes.

The following screenshot shows an example of an in-place refactoring (renaming).