The Android API is code that makes it easy to do exceptional things. A simple analogy could be drawn with a machine, perhaps a car. When you press on the accelerator, a whole bunch of things happen under the hood. We don't need to understand about combustion or fuel pumps because some smart engineer has made an interface for us; in this case a mechanical interface—the accelerator pedal.

For example, the following line of Java code probably looks a little intimidating at this stage in the book, but it serves as a good example of how the Android API helps us:

locationManager.getLastKnownLocation(LocationManager.GPS_PROVIDER)

Once you learn that this single line of code searches for available satellites in space, then communicates with them in their orbits around the Earth, and then retrieves your precise latitude and longitude on the surface of the planet, it becomes easy to begin to glimpse the power and depth of the Android API in conjunction with the DVM.

For sure, that code does look a little challenging, even mind boggling at this stage of the book, but imagine trying to talk to a satellite some other way!

The Android API has a whole bunch of Java code that has already been written for us to use as we like.

The question we must ask, and the one this book tries to answer, is as follows:

How do we use all this code to do cool stuff? Or, to frame the question to fit the earlier analogy: How do we find and manipulate the pedals, steering wheel, and sunroof of the Android API?

The answer to this question is the Java programming language and the fact that Java was designed to help programmers handle complexity. Let's talk a bit about Java and object-oriented programming (OOP).

Java is a programming language that has been around a lot longer than Android. It is an object-oriented language. This means it uses the concept of reusable programming objects. If this sounds like technical jargon, another analogy will help. Java enables us and others (like the Android development team) to write Java code that can be structured based on real-world things, and here is the important part: it can be reused.

So, using the car analogy, we could ask the following question: if a manufacturer makes more than one car in a day, do they redesign every part for each and every car?

The answer, of course, is no. They get highly skilled engineers to develop exactly the right components, honed, refined, and improved over years. Then that same component is reused again and again, as well as being occasionally improved.

If you are going to be fussy about my analogy, then you can point out that each of the car's components still has to be built from the raw materials using real-life engineers or robots.

This is true. What the software engineers do when they write their code is build a blueprint for an object. We then create an object from their blueprint using Java code, and once we have that object we can configure it, use it, combine it with other objects, and more besides.

Furthermore, as well as this, we can design blueprints ourselves and make objects from them as well. The compiler then transforms (manufactures) our bespoke creation into DEX code. Hey presto! We have an Android app.

In Java, a blueprint is called a class. When a class is transformed into a real working "thing", we call it an object or an instance of the class.

So, some smart software engineer up at Android HQ writes a desperately complex Java program that can talk to satellites. He then considers how he can make this code useful to all the Android programmers who want to make amazing apps that use users' locations to do cool things. One of the things he will do is make features such as getting the device's location in the world into a simple one-line task.

So, the single line of code we saw previously sets in action many more lines of code that we don't see and don't need to see. This is an example of using somebody else's code to make our code infinitely simpler.

Welcome to the world of object-oriented programming (OOP). I will constantly refer to OOP in every chapter and there is the big reveal in Chapter 10, Object Oriented Programming.

To get things done on Android, we write Java code of our own, which also uses the Java code of the Android API. This is then compiled into DEX code and run by the DVM, which in turn has connections to an underlying operating system called Linux that handles the complex and extremely diverse range of hardware that are the different Android devices.

The manufacturers of the Android devices and of the individual hardware components obviously know this too, and they write advanced software called drivers that ensure that their hardware (for example, CPU, GPU, GPS receivers, memory chips, and hardware interfaces) can run on the underlying Linux operating system.

The DEX code (along with some other resources) is placed in a bundle of files called an Android application PacKage (APK), and this is what the DVM needs to run our app:

The next question is where exactly does all this Java coding and compiling into DEX code, along with APK packaging, take place? Let's look at the development environment we will be using.

A development environment is a term that refers to having everything you need to develop, set up, and be ready to go in one place. We need two things to get started.

Android Studio is an integrated development environment (IDE) that will take care of all the complexities of compiling our code and linking with the JDK and the Android API. Once we have installed Android Studio, we can do everything we need inside this single application and put to the back of our minds many of the complexities we have been discussing.

So we had better get our hands on Android Studio.