This book is intended as a step-by-step guide to guide developers well versed in the arts of iOS into the realm of Android mobile application development.

The author assumes that the reader has never written Android applications before; at most, maybe, she or he has played with an Android device at some point, but nothing else. If you are already familiar with Android, you can skip directly to chapter 2, and start creating apps right away.

If you are not familiar with the Android developer tools, it is strongly recommended to read this book linearly, and to build the sample applications one after the other. This will help you build your skills step by step.

This book assumes that the reader is using a Mac – after all, the reader is supposed to be an iOS developer!

It also assumes working programming knowledge in Objective-C or Swift, and of the most common iOS frameworks, such as Foundation, UIKit, Core Location, Core Data and others.

Most importantly, it is also assumed that the reader already knows Java; if not, please be aware that you might have a hard time understanding the code snippets shown in this book. The Bibliography section at the end of the book provides a few useful titles for starting your exploration of Java. In particular I’d recommend reading [Bloch] own "Effective Java" to help you take your Java skills to the next level.

In terms of software requirements, this book assumes that the latest copy of Android Studio is installed in the development machine, as well as Homebrew.

The code bundled with the book has been prepared and tested with the latest version of Android Studio; make sure to download and install it in your system before starting.

All applications use the same baseline: API 16, also known as Jelly Bean 4.1. This version of Android was released in July 2012, and at the time of this writing, 97.3% of all Android devices in the wild run a version equal or older to Jelly Bean. This should hopefully give this book the widest possible reach.

Every time that the text of the book references some sample code, a "Follow Along" callout section will appear with the path of the project, which you can open on Android Studio to run the project directly on your device or the emulator:

Each application is as simple as possible, but not simpler. All the applications are working examples, tested at least in four environments:

Given the large variety of the Android market, it is possible that some bits and pieces of the source code will not work in some devices; I remember having trouble with some Android devices during my career, so I would not be surprised if some of you encounter difficulties. I will not be able to provide support for your particular device, but I guarantee that the code should work in the environments enumerated above.

This book is structured around code. The chapters are meant to be read with Android Studio open, in the order they have been written; I have reused bits and pieces of knowledge from previous chapters in many others, so you should be better served by reading them in order.

To help readers get up and running as fast as possible, every chapter features a section called "TL;DR" at its very beginning, including a handy summary of the most important similarities and differences between Android and iOS. You can use the tables in this section as a reference, and if you find them useful you can print a copy of the Appendix C, which contains all the TL;DR tables together in the same place.

The source code included in the book points directly to the applications available in the code folder, which contains all the sample applications bundled as part of this training.

As an introduction, these are the most important differences that distinguish the iOS developer experience from that of Android.

Android applications are primarily written in Java, a language that shares a lot of features and commonalities with Objective-C and Swift. After all, many Java engineers working for Sun in the nineties came from NeXT, the computer company founded by Steve Jobs that ultimately merged with Apple in 1996, bringing the Objective-C language to the Apple ecosystem.

Both Java and Objective-C share lots of commonalities, such as protocols (called "interfaces" in the realm of Java) or primitive boxing types such as NSNumber (represented by the family of Number subclasses in Java.) They also represents two opposite views in terms of compile-time checks; Objective-C delegates most method and type resolutions to runtime, while Java performs rather strict type checking. In this respect, Swift is much more close to Java than Objective-C will ever be.

Java has the following characteristics:

Of all the items above, the most important is the "Strongly and statically typed" one. This means that method calls in Java are bound at compile time, instead of being dispatched dynamically at runtime like in Objective-C. In spite of this, Java resolves polymorphic methods at runtime using a "vtable," just like in C++ or C#.

The table "Comparison of Java 1.7, Objective-C 2.0 and Swift 3" provides a comparison between these three languages.

When a user taps on the icon of an Android application a whole series of events happen in the device. Many of these events are very similar to those in iOS, and it turns out that, quite unsurprisingly, both operating systems use a very similar architecture, but with quite different class structures backing them.

Let us create a small project in Android Studio. In that project, add a subclass of the android.app.Application class, and register that class as the main application class in your AndroidManifest.xml file. Add two breakpoints in the source code, one in the Application.onCreate() method, and another in the MainActivity.onCreate() method.

The stack traces when hitting both breakpoints is shown below:

There are several interesting bits of information in the stack traces above. First of all, the android.os.Looper class, which as the name suggests provides the main run loop of the application. Most GUI toolkits include a similar construction, created at application runtime, holding an event queue and routing events from the operating system to the different activities and components of the application.

If you click on the name of a class in Android Studio while holding down the Cmd key, the IDE will open the corresponding class file; if you do not have the Android source code available in your local workstation the IDE will simply decompile the code from the local SDK and show a stub implementation of the corresponding class, with most of its methods.

By doing this repeatedly, from both the MainActivity and the Application subclass you created previously, you are going to arrive to the android.content.Context class, which is arguably the most important class in the Android SDK. The Context class includes many different methods, ranging from file management to database creation to inter-process communication, and it also holds a reference to the underlying Looper class.

The diagram "The android.content.Context class" shows a simplified class hierarchy of the Activity and Application classes and its relationship with the Looper class.

Another important element in the stack trace above is Zygote; this piece of software, named after a fertilized living cell, is the application launcher of the Android operating system. To ensure fast application startup, Zygote loads a copy of the ART virtual machine and when a new application launches, forks this VM to sandbox the process in it. If you want to know more about Zygote, this answer in Stack Overflow provides an excellent summary.

Android Studio is a free IDE provided by Google to develop Android applications. It replaced the venerable Eclipse Android Developer Tools, historically the first official IDE for Android software development for many years. It was announced for the first time in May 2013 at the Google I/O conference. The first stable release was in December 2014. It is available for Windows, macOS and Linux, and is now considered the official IDE for Android development.

Android Studio is powered by IntelliJ IDEA, a popular IDE for Java development for the past 15 years. It has a solid reputation, and is particularly appreciated by its advanced support for refactoring, code generation and project navigation features.

Android Studio is available from the Android Studio website. The current version at the time of this writing is 2.2.2; version 2.2 was a major milestone released September 19th, 2016. Android Studio is, by far, the most important piece in the daily workflow of an Android Developer, and includes many different features targeted to simplify the development of Android apps, which like all software development can be quite a complex endeavour sometimes.

Once downloaded and launched, Android Studio will launch a configuration wizard, as shown in Android Studio Setup Wizard – Step 1.

Most developers will choose the standard settings, as shown in image Android Studio Setup Wizard – Step 2.

Finally, Android Studio will automatically download all the elements required for it to work properly, as shown in image Android Studio Setup Wizard – Step 3.

Once Android Studio is ready to go, it will display some tips and tricks every day – something you can easily dismiss if you want, as shown in Android Studio Tips.

At the beginning of this chapter I mentioned that Java is the only programming language supported by Google for Android development. The ecosystem, however, includes many other possibilities; at the end of this book, the appendix "Third Party Android Developer Tools" contains a list of other environments and programming languages available to create Android applications. As you will see there, there are lots of different possibilities out there.

In this section we are going to explore one of those options: Kotlin. This programming language was created by the same engineers that created IntelliJ IDEA and Android Studio, and it is uncannily similar to Swift in many ways. Kotlin might be an interesting choice for Swift developers looking to write Android applications using a safe, fast and modern programming language.

Using Kotlin in your Android project requires adding a small library used at runtime for interoperability with Java; this library increases the size of the final application in around one megabyte.

We are going to create a small application using Kotlin, to show how easy it is to integrate and how similar it is to Swift.

Kotlin is available as a plugin for Android Studio. You can manage plugins in Android Studio by opening the Preferences ▸ Plugins menu, as shown in figure "Browsing plugin repositories"

Once the Kotlin plugin is installed, you should restart Android Studio for it to be loaded in memory. After relaunching, create a simple Android application and open the MainActivity class. Select the Code ▸ Convert Java File to Kotlin File… menu entry and watch Android Studio transform the standard Java code of your project into Kotlin.

The listing "Simple activity in Kotlin" shows the resulting code in a very simple application, with a lambda set as the event callback for button clicks.

Kotlin not only has a syntax that looks a lot like that of Swift, it shares many features with Apple’s new language:

Kotlin compiles its code to native Android bytecode, which means that setting the small overhead of the runtime library aside, an application created with Kotlin behaves and is distributed exactly like one created with Java.

As the name implies, the SDK Manager allows the developer to install, manage and uninstall different versions of the Android Software Development Kit (SDK) in the local workstation. Figure Android SDK Manager shows the default state after launching Android Studio and installing the latest available version of Android at the time of this writing, 7.1.1 (also known as Nougat.)

The Android Virtual Device or AVD manager allows you to create emulators for your debugging sessions.

It is safe to assert that Android Studio is, under the hood, just a visual environment built around Gradle, an open source build tool created with the Groovy programming language. You can think of Gradle as a tool similar to Maven or Make, but specifically taylored for the task of building and deploying Android applications.

Every Android Studio project includes three default Gradle build files:

The latter one specifies compilation parameters, build types, dependencies and many other parameters. The listing The app/build.gradle file shows a typical Gradle build file.

Gradle can be invoked from the command line, using the following command:

The output of running Gradle on the command line looks like this:

To discover the various predefined tasks available in Gradle, just run

This will yield a long lists of tasks.

The Android developer life is filled with various tools, each with a specific task. This section will give an overview of the most important of them.

Google provides a solid set of tools for Android development, including most if not all the tools required to get the job done. Some commercial tools exist as well, and they provide a certain added value to the equation.

Developers spend most of their time in Android Studio, editing and debugging code, both in emulators and on a device. Devices must have "developer mode" enabled in order to enable debugging via USB.

The Android SDK Manager is in charge of the installation and removal of different versions of the Android SDK in the workstation. The Android Virtual Device Manager is used to create emulators with different versions of Android. The Genymotion emulator is a commercial option to the standard Android emulator, offering several functionalities and better performance.

With the knowledge gained during this chapter, we are going to start writing some Android applications, in order to learn how to tie all these tools together.

For those of you in a hurry, the table below summarizes the most important pieces of information in this chapter.

The first thing that I recommend you to do is to enable exception breakpoints, either caught or uncaught. This will enable Android Studio to stop the execution of the application in case an Exception occurs, and given the wide range of possibilities for errors, this can be a handy measure before any debugging session starts.

To do that, just open the Run ▸ View Breakpoints… (or hit the Shift+Cmd+F8 keyboard shortcut) and check the "Java Exception Breakpoint" and the "Any Exception" checkboxes, as shown in image "Breakpoints Window in Android Studio."

If you have reached this point in the book one could imagine very well that you have been able to successfully run code in your device; but for those readers who have jumped directly to this section, here is a quick recap of the steps required to debug applications in your device.

First, you must enable "Developer mode" in your device. Open the Settings application and scroll to the "About phone" section. In that screen you should see a "Build number" entry, which you must tap seven times. If you try to do it again, you should see a "toast" message just like the one shown in image Developer mode already active.

After you have done that, the Settings application will display a new "Developer" item. Select it, scroll down and you will see a toggle switch to enable USB debugging in the device, as shown in image USB Debugging switch.

The Android debugger can also be used via a standard WiFi connection, although this can be a security problem and you should remember to disable this capability when you are done.

First connect your device with the USB cable and make sure that ADB is running in a specific port:

To enable WiFi debugging, then issue the following command, to retrieve the IP address of the device:

The common output of the ifconfig command returns information for each of the interfaces available in the device; normally the one labeled wlan0 is the one you are looking for. Write down the IP address, disconnect the USB cable and then run the next command:

The adb devices command should show something similar to the following now:

If you see the above, you can now use the device from Android Studio or any other IDE, and you will be able to debug your application just as if it were running tethered through the standard USB cable.

At the end of your debugging session, make sure to type the command to disable wifi debugging in your device.

This is a security measure, to disable any attempts in any network to debug and inspect applications in your device. After running this command, any attempt to connect to your device should print the following output:

I am a bit of a command line junkie, and I like being able to perform as many tasks as possible using my preferred macOS terminal tools: iTerm 2, zsh and tmux. In this section we are going to see how easy it is to leave Android Studio aside for a while, and use command line tools to create, build and debug Android applications.

First, open your preferred terminal and make sure that you have all the required tools on your system:

If you do not have ant installed, you can easily install it using Homebrew: brew install ant.

Now, let us create a simple Android application:

This command creates a project named CommandLineApp, targeting API 16 or later (the same baseline API level we have been using for this whole book) in the folder CommandLineApp, using the ID training.akosma.commandline and including a default activity class named MainActivity.

After running the project, inspecting the contents will show you the structure of the generated code:

The build.xml file is a standard ant build file, so we can start issuing commands to build and install the application as required.

This last command builds the application in "debug" mode; as you might expect, the ant release command does the same in "release" mode, ready to be signed and deployed to the Play Store. Finally, ant clean removes all built binaries and other compilation products.

Let us edit the code of the application first. You can use any editor you want, of course, but in my case I will stick to my beloved vim editor, which does a great job as far as I am concerned.

Open the CommandLineApp/res/layout/main.xml file and edit the android:text property of the autogenerated TextView instance inside of the main layout, until the code looks like the listing Layout of a command line app.

Let us also enable debugging in the application, by adding the android:debuggable="true" attribute to the application tag in the AndroidManifest.xml file at the root of the project:

Let us install the application in the device. First, connect your Android device to your Mac and run the following command to verify that ADB is connected to it:

Of course, in your case the output will be different; this is what I see when I connect my own OnePlus 3 device with the USB cable.

To install the debug build in my device, I just have to run the following command:

The -Dadb.device.arg parameter requires the device ID seen in the adb devices -l command output.

Alternatively, you can also install your application using the adb command:

Once the application is installed, how about debugging it? The Android toolkit allows you to debug applications entirely through the command line. The ADB process can bridge debugger commands to the Android Runtime, by the means of port forwarding. Let us see how to do that.

Launch the application in your device and then retrieve the process ID in your device:

JDWP stands for Java Debug Wire Protocol, a standard defined for Java debuggers, and which the Android platform implements, albeit in limited form. The technique we are going to use basically uses ADB to connect a local instance of jdb (the standard Java debugger distributed with the Java SDK) to the process running in the device.

The last command we ran returns the number of the process in the Android Runtime of the device. We are going to use that number to connect all the pieces together.

First, let us set a debug bridge between jdb and the device:

Then, launch the Java debugger and start a debugging session:

A short debugger session then looks more or less like this:

The previous listing shows several debugger commands:

Finally, you can import projects created with the command line from Android Studio; just select the File ▸ New ▸ Import Project and follow the instructions on screen. At the end of the migration procedure, Android Studio will include (and display) a file named import-summary.txt with details about the import process.

If you use the command line frequently, you will start missing the logcat output displayed by Android Studio at the bottom of the IDE. If that is the case, and you are using (as you should) logcat commands in your application, you should install then PID Cat, a logging tool that provides color output in the terminal, and which can be restrained to only display the logs for the application you are interested in.

PID Cat fulfills the same role as libimobiledevice or deviceconsole for iOS.

You can install it very easily using Homebrew: brew install pidcat. Once installed, just call it using this command:

The console should display something similar to the screenshot Example output with PID Cat.

The PID Cat help text shows that the tool allows to filter entries by verbosity level or by device or emulator, among other options.

This is an invaluable tool to be able to quickly scan for specific values in the logger output of your applications. A similar tool, but this time with a graphical user interface for macOS is LogCat.

Although PID Cat is useful, sometimes it is not possible or desirable to debug application instances individually using the USB cable. For more complex debugging scenarios, NSLogger is a useful option.

NSLogger allows developers to gather logging information from running applications in the local network. To do that, developers must include the NSLogger NSLogger Android client in their applications. When the application runs, the code automatically tries to send all of its logging information to an application running on a Mac on the same local network as the devices. Developers can then watch live the updates of their applications and thus to troubleshoot problems in specific devices.

To install NSLogger in your own app, at the time of this writing there is no simple mechanism (like, for example, using Gradle.) The code of NSLogger must be included in the application, but since the linkage is done through static methods and properties, the Java compiler can strip the code out of the application if not used (for example, in Release builds.)

Download the zip from the main Github repository of NSLogger and copy the folder inside of the Client Logger/Android/client-code/src into the app/src/main/java folder of your own application. Android Studio should detect the new code automatically.

Copy the files in the Client Logger/Android/example/com/example/ folder using Finder and paste them in Android Studio as part of your application.

Add the following permissions to your application in the AndroidManifest.xml file:

Include your logging code, either in your custom subclass of the Application class in your project, or in your activity, to activate logging, as shown in Sending NSLogger calls.

Before launching your application in Android Studio, make sure to download and launch the NSLogger desktop viewer application in your Mac. You should configure so that the port used by the client code is the same as the one used in the desktop viewer, as shown in image NSLogger desktop viewer configuration.

Having done this, and after adding some logging calls in your code, launching and using the application should automatically open a new NSLogger window in your Mac, displaying something similar to the contents of image NSLogger application running.

Android applications can not only be debugged on the Android Studio IDE, but also on the command line; remember that Android Studio can be seen as a huge user interface built on top of Gradle and ADB.

Other open source libraries, such as NSLogger and PID Cat, provide additional services for inspecting the behavior of applications in different devices.

For those of you in a hurry, the table below summarizes the most important pieces of information in this chapter.

Material Design is the current visual language that Google has created to unify the visuals and interactions throughout their complete suite of products, on the web, on the desktop and of course on mobile devices.

This book is definitely not a book about visual design (and if you can tell through my UML diagrams, I can say that design in general is not one of my strenghts!) but it is important to understand the underlying principlies behind Material Design.

Google created Material Design with the following principles in mind:

Of course, this should come as no surprise to any seasoned iOS developer; Apple itself is well known for having created visual guidelines for their own operating systems (starting with macOS and following with iOS, watchOS and tvOS) for a long time.

These guidelines, as the name suggest, provide designers and developers with a common language, enabling teams to discuss and elaborate visual architectures for their applications.

I strongly suggest the reader of these lines to spend some time browsing the Google Material Design website in order to understand the paradigms and the ideas behind the different visual elements that make up an Android application.

Historically, the characteristic of Android that frightens most iOS developers is the sheer diversity of devices and versions of Android available in the wild. The technical press usually refers to this issue as the "fragmentation" of the Android world… but as with many things in the press these days, it is safe to say that these claims (and the fears generated as a consequence) are overrated.

Early in the development of Android, Google realized that application developers should be able to support lots of different devices, with different screen sizes (such as tablets and smartphones of all sizes) and resolutions. This situation led to two very important additions to the Android toolkit back in 2011:

The Support Library, initially known as the Android Compatibility Package, allows applications running in older versions of Android to enjoy the UI paradigms and the features brought to the system in new versions of Android.

This library is available to Android developers through the Android SDK, and is distributed to users through the Play Store; this means that Android devices that include the standard Google Play Store will always have the Support Library installed, and this enables all applications to run seamlessly in all devices, starting in Android 2.3 (API level 9) and higher.

Throughout this book, we are going to use this library extensively. The package is named android.support and all of our applications will inherit from android.support.v7.app.AppCompatActivity instead of the standard Activity class provided by Android.

By far, the most important building block of Android applications are activities. They fulfill a similar role to that of UIViewController instances in iOS, that is, to manage the display of a screenful of data at any single time.

Android Studio allows developers to build applications around the Activity paradigm, creating and removing activities for each of the specific tasks that are required by the application. Activities are a powerful architectural mechanism for organizing and encapsulating your code.

The basic communication mechanism between activities is the android.content.Intent class. Whenever an activity wants to start another activity, or to communicate with another process in the device, it will always use an instance of the Intent class.

This architecture has no equal in the world of iOS applications, where the communication between view controllers is usually strongly coupled; this has the advantage of a simpler programming model, relatively easier to understand for newcomers, but it also leads to tangled architectures, where it is almost impossible to reuse controllers in different contexts.

Thanks to intents, Android activities can truly be independent from each other at every time, which helps in the creation of decoupled architectures, with high degrees of testability and reuse.

There are three use cases for intents in Android:

Let us learn now how to use Intent instances to open other activities.

Remember iOS "Universal Applications"? These are, according to Apple, iOS applications that can run both in the "form factor" of the iPhone or on that of the iPad. They are usually quite easy to create on iOS; just create different storyboards for each device, wire the scenes in your storyboards accordingly, and iOS takes care of the rest. If the application is running on an iPhone, then the iPhone storyboard will be displayed; if it is on an iPad, then the iPad storyboard will be taken into account.

Android works in pretty much the same way; the difference is that Android applications can have different layout files for different screen sizes, and even for different resolutions, orientations, and many other factors!

However, no matter how many layout files you have in your projects, Activities still take all the available screen space, every single time. Android does not allow many activities to share the current screen. Hence, a different solution was required. And this solution is called fragments.

Fragments are one of the most fundamental visual building blocks in Android. They allow developers to create flexible user interfaces that work differently in different devices, yet they are distributed as the same application in the Play Store.

Fragments are, in a sense, like small UIViewController instances that are children of a bigger, "container" UIViewController. You can compose complex user interfaces in iOS by nesting controllers inside of other controllers. Each contains its own view logic, and talks to other controllers using well-defined interfaces (like notifications, delegate protocols or other mechanisms.)

In Android, Fragments always exist inside an Activity. Activities can have one or many fragments, each containing its own view logic.

We are going to create now a small application that displays the same data in different ways depending on whether it is running on a tablet or on a smartphone; we are actually going to create something similar to a UISplitViewController!

The first step consists in creating the individual fragments for our application. We need a fragment that displays a list of items, and another fragment that displays just one of the items; the classical "master & detail" user interface paradigm.

We are also going to need two activities; one is the MainActivity, the root activity of the application, whether it is running on a smartphone or a tablet. If the application is running on a tablet, it will display both fragments at the same time. If it is running on a smartphone, that means that the "detail" fragment will not be visible, and then the DetailActivity, itself containing the DetailFragment will be called using an intent.

These are the layouts we need for both activities; as you can see, there are two layouts for the MainActivity, which has two different "look & feels":

The DetailActivity class only needs one layout:

In terms of code, the most complex class in the project is the ListFragment class, which actually uses a android.support.v7.widget.RecyclerView instance to display a list of strings. The RecyclerView class is the closest thing in Android to an iOS UITableView, and we are going to learn more about it in the next few chapters. For the moment you only need to know that the Adapter class inside of it is used as a data source, just as you would do it in iOS.

The ListFragment class also defines a "callback protocol" so that users of that fragment are notified of events on the RecyclerView. The root activity of the project is responsible for the coordination of the work between the fragments, and we can see that at work in listing "The MainActivity class coordinating the fragments".

As you can see, here we check for the existence of the detail fragment in the layout of the activity; if we are running the app in a smartphone, then the layout will not include that fragment, and the check will yield a falsy value; hence, we just create an Intent and ask the operating system for a new activity, in order to display the value that the user selected on the list.

On the other hand, if the app is running on a tablet, then the layout file that has been loaded by the operating system already includes that fragment, and thus the only thing we need to do is to simply update its value.

Activities are the basic building block of Android applications. Every activity manages a screenful of information, just like UIViewController instances would on iOS. The UI of activities can be designed visually, just like with Interface Builder in Xcode.

Developers can attach event handlers to UI widgets directly using anonymous classes, which are the Java 1.7 equivalent of Lambdas, which have only been introduced in Java 1.8, and are not yet available in Android for the time being.

Intents are objects used to launch other activities, either in this application or in any other application in the system. They provide the glue that allow applications to talk to each other.

Applications should be built around Fragments, to ensure their adaptation to other device sizes, such as tablets. In that sense, Activities should be seen as containers for fragments, allowing them to collaborate and to share information at runtime.

Finally, the whole operating system works like a giant UINavigationController instance, onto which Activity instances are constantly pushed and popped, and this explains the importance of the back button in Android devices.

As usual, for those readers in a hurry, the table below summarizes the most important pieces of information in this chapter.

Let us begin our discussion about drawing on Android devices with a little bit of theory. This section will explain the coordinate system used in Android graphics, the units, the variety of screen densities, and will provide some background about how to solve some common memory problems that arise when handling large amounts of data.

This part of the book is the one that I like the most: we are going to learn how to draw anything on the screen of an Android device by creating a simple drawing application. This application will have two very simple features:

The most important point in this whole application is that the final code will be very small – no more than 100 lines of code for the View class where the drawing takes place!

You can see a screeshot of the application in action in figure "Drawing application on a tablet."

The application consists of a single Activity which does not do anything else than wiring events to the different components in the UI; we have a Button, a SeekBar to select sizes, and a couple of RadioButton instances to select the color of the brush.

The core of the application is undoubtedly the DrawableCanvas class, itself a subclass of android.view.View.

DrawableCanvas is a subclass of android.view.View, the most important class in the drawing system of Android. Every single component you can see on most Android apps (with the exception of those apps drawing their own widgets, like OpenGL games for example) is an instance of a subclass of View.

And the good news for iOS developers is that View is very similar to UIView in many ways. The biggest similarity is the fact that both include an overridable method that can be used to perform custom drawing on the screen; in the case of iOS it’s the UIView.draw() method; in the case of Android is the View.onDraw() method. Even the names are similar!

Listing "[src-draw-ondraw]" shows how we are going to draw lines on the screen, using the android.graphics.Path, which is in many ways the same thing as a UIBezierPath on iOS.

As you can see, the onDraw() method shares many points in common with its iOS counterpart:

Of course, the lines must be drawn by the user, and the DrawableCanvas class should react to the touch events generated by the user. We are going to override yet another method, in this case View.onTouchEvent() which reminds us of similar methods in the UIResponder class.

The code above is quite straightforward, but there is one very interesting method called inside of that switch statement: the View.invalidate() method is the exact equivalent of setNeedsDisplay() in iOS. It tells the operating system that the current instance is "dirty" and that it should be redrawn as soon as possible, usually at the end of the current Looper iteration.

In chapter User Interface, more exactly in section "Handling Orientation Changes" we talked about how Android activities must save their state when the orientation of the screen changes; and that this is actually a very good idea for dealing with low memory situations, in which your application might be killed to free memory for other processes.

It turns out that this requirement applies not only to activities, but also to all the views contained in that activity. The View.onSaveInstanceState() and View.onRestoreInstanceState() are called automatically in all views, so that their state can be safely restored in the case of an orientation change or an application restart.

Listing "Saving the state of views" shows how our DrawableCanvas class is able to save and restores its own state whenever the hosting activity suffers from some kind of destruction event.

The most important concept of saving application state revolves around the android.os.Parcelable interface. Parcelable specifies the methods to implement to make any object subject to serialization and deserialization in the case of a destruction event.

The most common class implementing Parcelable is the android.os.Bundle class, which is simply a bag of string keys and Parcelable values.

In our drawing application we have implemented the Parcelable interface in our Line and Point classes; these are used by the DrawableCanvas class to store the information about the lines created by the user as the finger moved around on the screen.

Listing "Implementing the Parcelable interface" shows how the Line class implements Parcelable, which involves overriding two methods and adding one public static final field called CREATOR (this might be the most puzzling fact about the Parcelable interface, by the way.)

Thanks to this system, the MainActivity can be destroyed at wish, and if this happens the state of the DrawingCanvas will be restored without problem.

Let us be very clear from the beginning; Android does not include anything remotely similar to the beloved UIGestureRecognizer family. This means that all interactions on the screen must be managed manually, a situation somewhat similar to the world of iPhone development before iPhone OS 3.2 (released together with the first iPad, and which included gesture recognizers for the first time.)

Having to deal with multiple touch patterns in code is not simple, but listing "Multi-touch in Android" shows one possible way to do this. The activity must keep track at all times of the state of the touches, and using this information it builds an instance of android.graphics.Matrix, which in many ways is the Android equivalent of CGAffineTransform matrices.

Another thing that Android makes as easy to use as in iOS are animations. All classes inheriting from View have a set of "animatable properties" that can be… well, animated! We are going to learn how to do this in this section.

There are basically two main APIs that allow you to animate views on the screen, and they happen to be extremely similar to their counterparts in UIKit.

The first API is the View.animate() method, which is analogue to the animate(withDuration:animations:) method of UIView. Using this method you just specify the duration and the transitions that you require, and you can attach a callback object (implementing the Animator.AnimatorListener interface) to be notified of different events in the life of the animation.

Listing "Simple animations using View.animate()" shows how to animate a simple TextView instance.

The second API is the family of android.animation.Animator classes, which is extremely similar to the CAAnimation family of classes in the Core Animation framework of iOS; for example, ObjectAnimator is similar to CAPropertyAnimation; AnimatorSet is similar to CAAnimationGroup and so on.

Diagram "Animator Hierarchy Diagram" shows the class hierarchy of the Animator family of classes.

Listing "More complex animations using Animator" shows how to use the Animator classes in your code.

But, what is animatable in a View? Well, just like with iOS, there is a defined set of "animatable properties" that can be… well, animated! These are the properties:

Finally, you can be notified of the end of an animation, whether it is a simple or a complex one, by passing an object implementing the Animator.AnimatorListener interface and providing a suitable implementation of its methods, as shown in listing "Notification after the end of an animation"

To close this chapter, I wanted to provide all mobile developers out there with a closer look at an amazing commercial application called PaintCode. Originally targeting only iOS developers, version 3 (released during the writing of this book) included the possibility to generate Java code, helping designers and developers to work closer when creating cross-platform user interfaces.

PaintCode generates code for Android, iOS (both in Swift and in Objective-C), macOS (in Swift and in Objective-C) the web (generating JavaScript Canvas, CSS and SVG code) and even in C# for the Xamarin application programming environment. It can generate "stylesheets" in the shape of classes, including all the required resources such as colors, gradients, shadows and images, so that your application shares common design elements throughout platforms.

Figures "The PaintCode application in action" and "[img-paintcode-device]" show how an admittedly bad design is translated faithfully from the designer application to the device.

I can only recommend downloading the trial and giving it a shot; you might be surprised of the possibilities. But please make sure to have a designer in the team, or at least do not hire me to do your designs!

Android provides a fully fledged set of APIs, ready to bring you craziest user interfaces to life. The variety of devices and resolutions available in the market, however, require you to pay attention and to make sure that your designs will scale gracefully in all kinds of hardware.

Drawing custom views in Android is very similar to using Core Graphics in iOS, including the existence of a "context" object onto which all drawing is performed. Similarly, developers must not call the onDraw() method themselves, as this is the job of the operating system.

Views can save their state automatically whenever their container activity is being destroyed. They should do this to ensure that the user experience they provide stays untouched by device orientation changes, memory warnings or other situations.

Finally, Android has full support for animations, and once again this subsystem is incredibly similar to that of iOS. Developers can use applications such as PaintCode to help them create their designs with greater fidelity accross platforms.

For those of you in a hurry, the table below summarizes the most important pieces of information in this chapter.

We are going to start this chapter by creating a very simple application that performs a network request to a free API provided by the GeoNames geographical database. The data of this database is freely available, and it is licensed under a Creative Commons Attribution 3.0 License.

In particular, we are going to use a very nice API they offer, called "findNearbyWikipedia" which returns items of interest located in a geographical region. This API returns data in both JSON and XML formats, which we will use to show how to parse data in these two different formats.

First we are going to use the default HTTP libraries offered by Android, and later in this chapter we are going to use Retrofit, a third party open source library created by the team of Square.

The result of our call is a long string containing a certain amount of information codified in the venerable JSON format. This format has become a de facto standard for web APIs, and as such we are going to see how to convert this JSON code into native data structures that we can manipulate with Java. This process is called parsing and deserializing the JSON string.

We are going to create a new project now, using the default parameters as usual, in we are going to reuse our APIConnector class from our previous project.

This time we are going to create a POJO (also known as "Plain Old Java Object") that we will call PointOfInterest – it will hold the information returned by the JSON returned from the API call.

The same web service we have used so far can return XML data; the only difference is that we have to remove the "JSON" word from the URL, and just by using the same parameters, we will have a simple XML output.

In this section we are going to learn how to use the standard "SAX-style" XML parser functionality built-in into Android.