In addition to these resources, it is worth noting that Java as used in Android has a structure to its code. There are many millions of lines of code that we can take advantage of. This code will obviously need to be organized in a way that makes it easy to find and refer to. It is organized into packages that are specific to Android.
Whenever we create a new Android app, we will choose a unique name known as a package. We will see how we do this in the section "Our first Android app". Packages are often separated into sub-packages, so they can be grouped together with other similar packages. We can simply think of these as folders and sub-folders, which is almost exactly what they are.
We can think of all the packages that the Android API makes available to us as code from a code library. Some common Android packages that we will use include the following:
android.graphicsandroid.databaseandroid.view.animation
As you can see, they are arranged and named to make what is in them as obvious as possible.
Note
If you want to get an idea of the sheer depth and breadth of the Android API, then look at the Android package index: https://developer.android.com/reference/packages
Earlier, we learned that the reusable code blueprints that we can transform into objects are called classes. Classes are contained in these packages. We will see in our very first app how we can easily import other people's packages, along with specific classes from those packages for use in our projects. A class will almost always be contained in its own file with the same name as the class, and it will also have the .java file extension.
In Java (and therefore Android), we further break up our classes into sections that perform the different actions of our class. We call these action-oriented sections methods. It is most often the methods of the class that we will use to access the functionality provided within all those millions of lines of code.
We do not need to read the code. We just need to know which class has what we need, which package it is in, and which methods from within the class give us precisely the result we are after.
The following diagram shows a representation of the Android API. We can think of the structure of the code we will write ourselves in the same way, although we will usually have just one package per app.
Of course, because of the object-oriented nature of Java, we will only be using selected parts from this API. Notice also that each class has its own distinct data. Typically, if you want access to the data in that class, you need to have an object of that class:
You do not need to memorize this as we will constantly be returning to this concept throughout the book.
By the end of this chapter, we will have imported multiple packages, as well as dozens of classes from them, and we will have used many of their methods as well. By the end of Chapter 2, First Contact: Java, XML and the UI Designer we will have even written our very own methods.