There are many ways that Android Studio differs from other IDEs and development tools. Some of these differences are quite subtle, such as the way support libraries are installed, and others, for instance the build process and the UI design, are profoundly different.

Before taking a closer look at the IDE itself, it is a good idea to first understand what some of these important differences are. The major ones are listed here:

• UI development: The most significant difference between Studio and other IDEs is its layout editor, which is far superior to any of its rivals, offering text, design, and blueprint views, and most importantly, constraint layout tools for every activity or fragment, an easy-to-use theme and style editors, and a drag-and-drop design function. The layout editor also provides many tools unavailable elsewhere, such as a comprehensive preview function for viewing layouts on a multitude of devices and simple-to-use theme and translation editors.
• Project structure: Although the underlying directory structure remains the same, the way Android Studio organizes each project differs considerably from its predecessors. Rather than using workspaces as in Eclipse, Studio employs modules that can more easily be worked on together without having to switch workspaces.

This difference in structure may seem unusual at first, but any Eclipse user will soon see how much time it can save once it becomes familiar.

• Code completion and refactoring: The way that Android Studio intelligently completes code as you type makes it a delight to use. It regularly anticipates what you are about to type, and often a whole line of code can be entered with no more than two or three keystrokes. Refactoring too, is easier and more far-reaching than alternative IDEs, such as Eclipse and NetBeans. Almost anything can be renamed, from local variables to entire packages.
• Emulation: Studio comes equipped with a flexible virtual device editor, allowing developers to create device emulators to model any number of real-world devices. These emulators are highly customizable, both in terms of form factor and hardware configurations, and virtual devices can be downloaded from many manufacturers. Users of other IDEs will be familiar with Android AVDs already, although they will certainly appreciate the preview features found in the Design tab.
• Build tools: Android Studio employs the Gradle build system, which performs the same functions as the Apache Ant system that many Java developers will be familiar with. It does, however, offer a lot more flexibility and allows for customized builds, enabling developers to create APKs that can be uploaded to TestFlight, or to produce demo versions of an app, with ease. It is also the Gradle system that allows for the modular nature discussed previously. Rather than each library or a third-party SDK being compiled as a JAR file, Studio builds each of these using Gradle.

These are the most far-reaching differences between Android Studio and other IDEs, but there are more as well as many features that are unique. Studio provides the powerful JUnit test facility and allows for cloud platform support and even Wi-Fi debugging. It is also considerably faster than Eclipse, which, to be fair, has to cater for a wider range of development needs, as opposed to just one, and it can be run on less powerful machines.

Android Studio also provides an amazing time-saving device in the form of Instant Run. This feature cleverly only builds the part of a project that has been edited, meaning that developers can test small changes to code without having to wait for a complete build to be performed for each test. This feature can bring these waiting times down from minutes to almost zero.

Whether you are new to Android Studio or want to gain more from it, the first step is to take a broad look at its most prominent structures.

The overall structure of Android Studio is not dissimilar to other IDEs. There are windows for editing text and screen components, others for navigating project structures, and others still for monitoring and debugging. The IDE is highly flexible and can be configured to suit many specific needs and preferences. A typical layout might look like this:

Although these windows can be arranged in any way we please, generally speaking, in the previous screenshot, the four panes might have the following functions:

1. Navigating a project, module, or library
2. Editing text and designing layouts
3. Defining component properties or screen previews
4. Monitoring and debugging

There are many different perspectives we can take on our projects and many ways to organize them. The best way to see how is to take a look at each in turn.

Naturally, the most important of all the windows in an IDE are those where we create and modify the code that underlies all our apps. Not only do we use editors for our XML and Java, there are, among others, editors for simplifying other resources, such as translations and themes. However graphical the editor may be, all Android resources end up as XML files in the res directory.

It is quite possible to create most Android resources without ever having to write any code at all. Themes can be created with the corresponding editor with nothing more than a few clicks of a mouse. Nevertheless, if we are to consider ourselves as experts, it is important that we have a good understanding of the underlying code and how and where Studio stores these resources. The following example demonstrates how to create a new Android theme using the theme editor:

1. Start or open an Android Studio project.
2. Open the theme editor from Tools | Android | Theme Editor.

3. From the Theme drop-down in the top right corner of the editor, select Create New Theme and enter a name in the New Theme dialog.
4. Leave the Theme parent field as-is.
5. Click on the colorPrimary thumbnail.
6. Choose a color you like from the resultant swatch with a weight of 500.
7. In the same manner, select the same color with a weight of 700 for the secondary color.
8. Select a color with a weight of 100 that contrasts nicely with your primary colors for the accent.
9. Open a preview or the design editor to view these changes.

In the preceding example, we created a new theme that will be automatically applied throughout the application. We could have simply edited the default AppTheme, but this approach will simplify matters if we later decide to employ more than one theme. The IDE applies these changes straightaway by adding something like the following line to the res/values/styles.xml file:

<style name="MyTheme" parent="AppTheme" /> 

The actual color changes can be found in the res/values/colors.xml file.

The theme editor demonstrates rather nicely how Studio editors can create and modify code after little more than a few mouse clicks from us.

It is also possible to change the theme of the IDE itself by selecting Settings | Editor | Colors and Fonts from the File menu, as displayed in the following image:

Android Studio comes equipped with just one alternative color scheme, Darcula. This theme presents light text on a dark background and, as such, is far easier on the eye than the default settings, especially for those long, late night development sessions. There are other schemes available online and it can be a lot of fun to design one's own. However, for the purposes of producing printed material, we will stick with the default IDE theme here.

Another good example of a subsidiary editor is the Translations editor, which is also a good way to demonstrate how the project structure differs from other IDEs. The following steps show how this is achieved:

1. Open the Translations editor by right-clicking on the res/values/strings.xml file and selecting it from the menu. This can also be found from the Language drop-down in the design XML editor.
2. Click on the globe icon near the top left corner of the editor and select a language from the list.

3. Select the string you want to translate in the top pane and enter the value in the lower pane, as shown:

This is a remarkably simple exercise, the point of it being to demonstrate how Android Studio stores such resources and how it displays them. The editor has created a new strings.xml file, identical to our original in every way apart from the string values of our translated text. This file will be referred to automatically by any device that has that language set as the default by the user.

Judging by the Project Explorer, one might think that there was a project directory called strings.xml in the values directory and that it contained two strings.xml files. This, in fact, is presented this way only to help us organize our resources. An examination of the project folder on disk will show that there are in fact two (or more) folders inside the res directory named values and values-fr. Not only does this help organize our work but it also helps minimize the space our apps take up on a device, as only the resource folders that are needed are installed on an end device.

Themes and Translations are two of the least significant editors but make a good introduction to how Android Studio manages app resources. The majority of a developer's time is spent using code editors and these will, of course, be covered in depth throughout the book. However, although editors make up the core of the IDE, there are many other useful, and even vital, tools available to us, and the most commonly used of these are available from the tools margin.

There are at least a dozen tool windows available to us, more if you have installed plugins. They can be accessed via the View | Tools Windows menu, the tools icon on the far left-hand side of the status bar at the bottom of the workspace, or by pressing Alt and the corresponding number key to open a specific tool window.

Tool Windows are highly configurable, and each window can be set as docked, floating, or contained in its own window.

This is particularly useful when working with more than one screen, as follows:

A docked, floating, and windowed tool window

We will be covering all these tools in depth throughout the course of the book. For now though, the following is a brief introduction to the most commonly used tools:

• Messages: Alt + 0. This tool produces a paired-down version of the Gradle build process. A more detailed output can be found within the Gradle Console.
• Project: Alt + 1. Usually docked to the left of the workspace, this tool is our main navigational tool.
• Favorites: Alt + 2. This is a very handy organizational tool, providing quick access to commonly used classes and components. To add any file to the Favorites list, simply right-click on it in the project window and select Add to Favorites from the drop-down menu.
• Run: Alt + 3. A powerful diagnostic tool that becomes available when an application is running on a device or emulator.
• Android: Alt + 4. This is Studio's main debugging window and is used to monitor log output from a running application and take screenshots.
• Memory Monitor: Alt + 5. This incredibly useful tool produces a live graph of memory usage as an application is running.
• Structure: Alt + 6. This tool produces detailed information about the current editor, showing a hierarchical view of classes, variables, and other components contained in that particular file.

One of the most useful Tool Windows is the Device File Explorer tool. This allows us to browse the filesystem of any connected device or emulator.

Tool windows are fantastically useful and enable us to configure the IDE to suit the particular task we are working on. Being able to select appropriate tools like this is one of Android Studio's most useful features. Of course, Android Studio is nothing more than a frontend interface that allows us to connect with the real power behind Android, the SDK.

Technically speaking, it is quite possible to describe the Software Development Kit(SDK) as not being a part of Android Studio, as it is used by other IDEs. However, the IDE would be useless without it, and now is as good a time as any to take a quick look at it and its manager.

The Android SDK is a huge collection of APIs, consisting of Java classes and interfaces organized into complex but logical hierarchies along with other utilities, such as USB drivers and hardware accelerators.

The SDK and its components update far more frequently than the operating system itself, a setup that users should be blissfully unaware of. Android users think in terms of Lollipop or Honeycomb; as developers, we see the Android world in terms of SDK levels.

The SDK is controlled with SDK Manager, which can be accessed via the main toolbar or from Settings | Appearance & Behavior | System Settings | Android SDK from the File menu. There is also a standalone SDK Manager, which can be run without Android Studio. This can be found in the following directory: \AppData\Local\Android\sdk.

There are three sections to the SDK manager: tools, platforms, and extras. At the very minimum, you will need to install the latest SDK tools, platform tools, and build tools. You will also need to install the most recent platform and any other platform you intend to target directly. You will also need system images for any virtual devices you wish to create as well as the Google USB driver and HAXM hardware accelerator.

The easiest way to manage the various updates is to set them to be installed automatically, and this can be done from the Settings dialog (Ctrl + Alt + S) under Appearance and Behavior | System Settings | Updates.

The SDK forms the backbone of our development environment, but however well we master it, we still need some way to test our creations, and in the absence of a large number of real devices, this depends on creating virtual devices with the Android device emulator.

There are so many Android devices available on the market that it would be an impossibility to thoroughly test our apps on very many real devices . It is for this reason that the system allows us to create emulated devices using the virtual device manager.

The AVD Manager allows us to create both form factor and hardware profiles from scratch and to provide several ready-made virtual devices and system images that can be downloaded from various manufacturers' websites.

Android emulators can be notoriously slow, even on very powerful machines, and this is to be expected, as creating a fully functioning virtual device is a remarkably complex task. There are, however, a few things that can be done to speed things up a little by designing each virtual device to match the particular tasks of the app we are developing. For example, if your app does not make use of the device camera, then do not include it in the configuration. Likewise, do not allocate much more memory than the app itself requires.

Android virtual devices are not the only option available to us, and there are a small but growing number of third-party emulators. Many of these are designed with gamers rather than developers in mind; although Genymotion is specifically a development tool, it contains more functions and is generally faster than the native emulators. Its only drawbacks are that is only free for personal use and only provides system images for phones and tablets and not wearables or large screen devices, such as TVs.

Real-world devices naturally respond far faster than any emulator and, when it comes to testing basic functionality, using our own devices will provide swifter results. This approach is great for testing the fundamentals of an app but provide little to no feedback on just how our apps will look on the wide variety of screen sizes, shapes, and densities that Android devices can have.

Using real devices is a fast way to test application logic but developing apps for specific models or even generic size and shapes will inevitably require the creation of virtual devices. Fortunately, Android Studio comes equipped with an accelerated build process: Instant Run.

In earlier versions of Android Studio, each time a project was run on any kind of device, a full build had to be performed. Even if we made only tiny changes to our code, we would still have to wait for the entire app to be rebuilt and reinstalled. This could prove very time-consuming, especially on less powerful machines. This slowness often resulted in having to test several modifications at once, leading to a more complex debugging process than is ideal.

Instant Run attempts to build only those classes or activities that have been changed since the last build, and providing the manifest file has not been edited, the app is not even reinstalled, and in some cases, the launch activity is not even restarted.

As Instant Run is a recent innovation, it is unfortunately not available on all versions of Android and, to take full advantage of it, you will need to set the minimum SDK level to API 21 or higher, although elements of it will work with API level 15 and higher. In Android Studio, this level is set from the build.gradle (Module: app) file, as follows:

android { 
    compileSdkVersion 25 
    buildToolsVersion "25.0.1" 
    defaultConfig { 
        applicationId "com.mew.kyle.chapterone" 
        minSdkVersion 21 
        targetSdkVersion 25 
        versionCode 1 
        versionName "1.0" 
        testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner" 
    } 

More often than not, we try to make our apps as backward-compatible as possible and developing an app that only works with API level 21 or higher would seriously limit the number of users we can reach. However, the time Instant Run saves us makes it worthwhile to test and debug an app API 21 or higher and then, later, reassemble it to match the versions we wish to target.

Moving from another IDE to Android Studio need not be a difficult transition and will prove invaluable once complete. However, it may be that you have projects developed in other IDEs that you wish to continue developing using Studio. Fortunately, this is a simple task, as the following section demonstrates.

Eclipse is, without question, one of the finest development tools around and, after 15 years, many of us have become very familiar with it. When it comes to developing for a variety of platforms, Eclipse is a fantastic tool but cannot compete with Android Studio when it comes to developing Android applications.

If you are migrating from Eclipse, you will more than likely have projects you have been working on that you wish to import into Studio. The following steps demonstrate how this is done:

1. First ensure that your Eclipse ADT root directory contains both the src and res directories and the AndroidManifest.xml file.
2. Make a note of any Eclipse third-party plugins you have used as you will need to install equivalents into Studio.
3. Open Android Studio and select Import Project from the welcome screen or from File | New | Import Project.
4. Select the folder that contains the manifest and prepare a destination folder, then follow the prompts to complete the import.

The import process makes a complete copy of the project, leaving the original untouched, meaning it can still be worked on in Eclipse if you wish. Unfortunately, it is not possible to import third-party plugins but a large and growing number of plugins are available for Studio, and it is more than likely that you will be able to find equivalents. These can be browsed from File | Settings | Plugins.

We will look again at this process when we come to project configuration, but otherwise, from here on in, we will be assuming that all projects are begun in Android Studio.

This chapter has served as a brief but complete introduction to Android Studio for those readers who are unfamiliar with it. We explored how the workspace is structured and the various flavors of editor available to us. This exploration led us to create a Material Design theme, use tool windows to perform a variety of useful tasks, as well as apply Instant Run to speed up the otherwise time-consuming build process.

The chapter concluded with a quick look at virtual devices and how we can import our projects from other IDEs. With this introduction complete, the following chapters will delve into the layout editor itself, as we see how to design application interfaces that work across the widest number of form factors.