How Java and Android work together
Before we start our Android quest, we need to understand how Android and Java work together. After we write a program in Java for Android, we click a button and our code is transformed into another form, the form that is understood by Android. This other form is called Dalvik Executable, or DEX code, and the transformation process is called compiling.
Note
We will see this process in action right after we set up our development environment later in the chapter.
Android is a complex system, but you do not need to understand it in depth to be able to make amazing apps.
Tip
Full understanding will come after using and interacting with it over time.
To get started, we only need to understand the basics. The part of the Android system that executes (runs) the compiled DEX code is called the Dalvik Virtual Machine (DVM).
The DVM itself is a piece of software written in another language that runs on a specially adapted version of the Linux operating system. So, what the user sees of Android is itself just an app running on yet another operating system.
Android is a system within a system. The typical Android user doesn't see the Linux operating system and most probably doesn't even know it is there.
The purpose of the DVM is to hide the complexity and diversity of hardware and software that Android runs on, but, at the same time, exposing all its useful features. This exposing of features works in two ways:
- First, the DVM itself must have access to the hardware, which it does.
- Second, this access must be programmer friendly and easy to use, and it is because of the Android Application Programming Interface or API.
Let's continue by talking more about the Android API.
The Android API
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.
Note
There are many different estimates to the number of lines of code that has gone into Android. Some estimates are as low as 1 million, some as high as 20 million. What might seem surprising is that despite this vast amount of code, Android is known in programming circles for being.
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 object-oriented
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.
Note
Objects in short
We could go on making analogies all day long. As far as we care at this point:
Java is a language that allows us to write code once that can then be used repeatedly.
This is very useful because it saves us time and allows us to use other people's code to perform tasks we might otherwise not have the time or knowledge to write for ourselves.
Most of the time, we do not even need to see this code or even know how it does its work!
One last analogy: We just need to know how to use that code just as we need to learn to drive a car.
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.
Tip
If the fact you don't have to see all the code is a disappointment to you, then I understand how you feel. Some of us, when we learn about something, want to learn every intricate detail. If this is you, then be reassured that the best place to start learning how the Android API works internally is to use it as the API programmers intended. And, throughout the book, I will regularly point out further learning opportunities in which you can find out the inner workings of the Android API. Also, we will be writing classes that are themselves reusable, kind of like our own API, except that our classes will focus on what we want our app to do.
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.
Run that by me again – What exactly is Android?
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:
Tip
It is not necessary to remember the details of the steps that our code goes through when it interacts with the hardware. It is enough just to understand that our Java code goes through some automated processes to become the apps that we will publish to the Google Play Store.
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.
Android Studio
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.
- We talked a fair bit about compiling our Java code, as well as other people's Java code, into DEX code that will run on the DVM on the user's Android device. To use Java code, we need some free software called the Java Development Kit (JDK). The JDK also includes even more code from other people that is separate from the Android API.
- There is an entire range of tools needed to develop for Android, and we also need the Android API, of course. This whole suite of requirements is collectively known as the Android Software Development Kit (SDK). Fortunately, downloading and installing a single application will give us these things all bundled together. The application is called Android Studio.
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.
Tip
Over time, these complexities will become like second nature. It is not necessary to master them to make further progress.
So we had better get our hands on Android Studio.
