Now let's cover some of the technical terminology used for Java objects. First, objects have fields and methods, as follows:

One of the key concepts of OOP is data encapsulation, where the object's fields are allowed to be modified directly only through that same object's methods. This allows the object to be self-sufficient. For example, to turn the car, you use the steering method, which positions the wheels in the desired direction.

With data encapsulation, each object that is part of a larger construct can be built and tested individually, without requiring accessing data from other objects or modules of the application (which can translate into bugs). Without data encapsulation, people could simply access any part of your object's data and use it however they pleased. This could introduce bugs, affecting the methods you have perfected to manipulate your object and provide your solution.

Data encapsulation promotes the core concept in OOP of modularity. Once an object is created and tested, it can be used by other objects without worrying about its integrity. Data encapsulation thus allows code reuse, so programmers can develop libraries of useful objects that do not need to be rewritten or retested by other programmers. You can see how this can save developers money by structuring only the work that needs to be done and avoiding redundant work processes.

Data encapsulation also allows developers to hide the data and the internal workings of the object if desired.

Finally, objects make debugging easier because they can be removed modularly during testing to ascertain where bugs are located in the overall code. In our car object example, the attributes of our car are encapsulated inside the car object, and can be changed only via the methods that surround them in the diagram. For instance, use the Shift Gears method to change the Gears=1 attribute to Gears=2.

In real life, there is seldom just a single kind of object. Usually, there are a number of different types and variations. For instance, for a car object, there are many different manufacturers, sizes, shapes, seating capacity, engine types, fuel types, transmission types, and so on.

In Java SE, we write something called a class to define what an object can do (its methods) and the fields it has. Once this class has been coded in Java, we can then create an instance of each object that we wish to use by referencing the class definition. In architectural terms, the class is a kind of blueprint as to what the object is, what states it contains, and what it can do (what methods it has).

To illustrate this further, let's construct a basic class for our car object example. To create a car class, you use the Java keyword class, followed by your name for the new class that you are writing, and then curly brackets to hold your code definition, like so:

class Car {Code definition for a car class goes in here. We will do this next}

The first thing that we usually put inside our class (inside the curly {} brackets) is the data fields (variables) that will hold the states, or attributes, of our car. In this case, we have six fields that define the car's gear, speed, direction, fuel type, color, and drivetrain (two- or four-wheel drive), as specified in the basic diagram shown earlier in Figure 5-1.

To define a variable in Java, you first declare its data type (int means a whole number, and string means text), followed by your variable name. You can also (optionally) set a default, or starting, value by using an equal sign and a data value. The variable definition ends with a semicolon.

So, with our six variables from our anatomy of an object diagram in place, our class definition looks like this:

class Car {
    int speed = 15;
    int gear = 1;
    int drivetrain = 4;
    String direction = "N";
    String color = "Red";
    String fuel = "Gas";
}

Remember that these are all the default values—the ones each object instance will have when we create it.

Notice how the example spaces out the curly braces ({}) on their own lines and indents lines, so that you can see what is contained within those braces more easily.

The next part of the class file will contain the methods that define how the car object will operate on the variables that define its current state of operation. Methods can also return a value to the calling entity, such as values that have been successfully changed or even answers to an equation. For instance, there could be a method to calculate distance that multiplies speed by time and returns a distance value.

To declare a method that does not return any value to the calling entity, you use the void keyword. A good example of using void is a method that triggers something—the method is used to invoke a change in the object, but does not need to send a value back to the calling function.

If your method or function returns a value, instead of using the void keyword, you use the data type of the data that is to be returned, say int or string. For example, an addition method would return a number after finishing its calculation, so you would use int.

After the void keyword comes a name for the method (say, shiftGears). This is followed by the type of data (in this case, an int) and variable name (newGear) in parentheses.

void shiftGears (int newGear) {

The variable contains a data parameter that will be passed to the method, so the method now has this variable to work with.

Some methods are called without variables, as follows:

methodSample();

To call the shiftGears() method, you would use the following format:

shiftGears(4);

This passes 4 into the shiftGears() method's newGear variable, which sets its value. This value then is passed into the interior of the shiftGears() method logic (the part inside the curly braces), where it is finally used to set the object's gear (internal) field to the new gear shift value of 4, or fourth gear.

A common reason to use a method without any parameters is to trigger a change in an object that does not depend on any data being passed in. So, we could code an upShift() method and a downShift() method that would upshift and downshift by one gear level each time they were called, rather than change to a gear selected by the driver. We then would not need a parameter to shift gears on our car; we would just call upShift() or downShift() whenever gear shifting was needed.

After the method declaration, the method's code procedures are contained inside the curly braces. In this example, we have four methods:

The methods go inside the class and after the variable declarations, as follows:

class Car {
    int speed = 15;
    int gear = 1;
    int drivetrain = 4;
    String direction = "N";
    String color = "Red";
    String fuel = "Gas";

    void shiftGears (int newGear) {
        gear = newGear;
    }

    void accelerateSpeed (int acceleration) {
        speed = speed + acceleration;
    }

    void applyBrake (int brakingFactor) {
        speed = speed - brakingFactor;
    }

    void turnWheel (String newDirection) {

direction = newDirection;
  }
}

This Car class allows us to define a car object, but it can't do anything until we use it to instantiate an object. In other words, it does not do anything until it is called.

To create an instance of an object, we instantiate it. Here's the onCreate() method of an Android application, where we instantiate two cars and use them (refer to the example in Chapter 4 to see how to create an onCreate() method in an Android app):

public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.main);

    Car carOne = new Car();           // Create Car Objects
    Car carTwo = new Car();

    carOne.shiftGears(3);
    carOne.accelerateSpeed(15);       // Invoke Methods on Car 1
    carOne.turnWheel("E");

    carTwo.shiftGears(2);             // Invoke Methods on Car 2
    carTwo.applyBrake(10);
    carTwo.turnWheel("W");
}

Upon launch or creation of our Android application, we now have two empty car objects. We have done this using the Car() class constructor, along with the new keyword, which creates a new object for us, like so:

Car carOne = new Car();

The syntax for doing this is very similar to what we used to declare our variables:

To invoke our methods using our new car objects requires the use of something called dot notation. Once an object has been created and named, you can call methods by using the following code construct:

bjectName.methodName(variable);

So, to shift into third gear on car object number one, we would use this:

carOne.shiftGears(3);

So, as you can see in the final six lines of code in the onCreate() method, we set carOne to third gear, accelerate it from 15 to 30 mph by accelerating by a value of 15, and turn east by using the turnWheel() method with a value of "E" (the default direction is north, or "N"). Car two we shift into second, applyBrake() to slow it down from 15 to 5 mph, and turn the car west by using the turnWheel("W") method via our dot notation.

There is also support in Java for developing different types of car objects by using a technique called inheritance, where more specific car classes (and thus more uniquely defined objects) can be subclassed from a more generic car class. Once a class is used for inheritance by a subclass, it becomes the super class. There can be only one super class and an unlimited number of subclasses. All the subclasses inherit the methods and fields from the super class.

For instance, from our Car class, we could subclass an Suv class that extended the Car class to include those attributes that would apply only to an SUV type of car, in addition to the methods and states that apply to all types of cars. An SUV car class could have onStarCall() and turn TowLightOn() methods, in addition to the usual car operation methods. Similarly, we could generate a subclass for sports cars that includes an activateOverdrive() method to provide faster gearing and an openTop() method to put down the convertible roof. You can see these subclasses in the extension of our car object diagram shown in Figure 5-2.

Figure 5.2. Inheritance of a Car object

To create a subclass from a super class, you extend the subclass from the super class using the extends keyword in the class declaration, like this:

class Suv extends Car { New Fields and Methods Go Here }

This extends to Suv all of the fields and methods that Car features, so that the developer can focus on just the new or different fields and methods that relate to the differentiation of the SUV from the regular car definition. Since the original core fields and methods come from the Car class, it becomes the super class, and the Suv class becomes the subclass. Suv is said to be subclassed from the Car super class.

To refer to one of the super class methods from within the subclass you are writing, you can use the super keyword. For example, in the Suv class, we may want to use a generic car's applyBrake() method, and then apply some other factor to the brakes that is specific to SUVs. The following code does this:

class Suv extends Car {
    void applyBrake (int brakingFactor) {
        super.applyBrake(brakingFactor);
        speed = speed - brakingFactor;
   }
}

This means the SUV's brakes are twice as powerful as a generic car's brakes.

Be sure to use good programming practices and document the super class fields and methods within each subclass. This documentation lets the users know that the super class's fields and methods are available, since they do not explicitly appear in the code for the subclass.

In many Java applications, the classes conform to a certain pattern, so that the rest of the application knows what to expect of those classes when they are instantiated as objects. This is especially common when using a framework like Android.

The public interface that the classes present to the rest of the application makes using them more predictable and allows you to use them in places where any class of that pattern is suitable. In other words, the public interface is a label that tells the application what this class can do, without the application needing to test its capabilities.

In Java terms, making a class conform to a pattern is done by implementing an interface. The following is an ICar interface that forces all cars to have the methods defined in the interface. This also means that the rest of the application knows that each car can do all of these actions, because the ICar interface defines the public interface of all cars.

public interface ICar {
    void shiftGears (int newGear);
    void accelerateSpeed (int acceleration);
    void applyBrake (int brakingFactor);
    void turnWheel (String newDirection);
}

So, a car is not a car unless it contains these particular methods.

To implement an interface, use the implements keyword as follows, and then define all the methods as before, except they must be public.

class Car implements ICar {
    int speed = 15;
    int gear = 1;
    int drivetrain = 4;
    String direction = "N";
    String color = "Red";
    String fuel = "Gas";

public void shiftGears (int newGear) {
    gear = newGear;
}

public void accelerateSpeed (int acceleration) {
    speed = speed + acceleration;
}

public void applyBrake (int brakingFactor) {
    speed = speed - brakingFactor;
}

public void turnWheel (String newDirection) {
    direction = newDirection;
   }
}

The public keyword allows other classes to call these methods, even if those classes are in a different package (packages are discussed in the next section). After all, this is a public interface, and anyone should be able to use it.

Each time you start a new project in Android, the Eclipse IDE will create a package to contain your own custom classes that you define to implement your application's functionality. In the Hello World application we created in the previous chapter, our package was named Hello.World. In fact, the New Android Project dialog asked us for this package name.

The package declaration is the first line of code in any Android application, or in any Java application for that matter. The package declaration tells Java how to package your application. Recall the first line of code in our Hello World application:

package hello.world;

After the package keyword and declaration come import statements, which import existing Java classes and packages into your declared package. So, a package is not only for your own code that you write yourself, but also for all code that your application uses, even if it is open source code written by another programmer or company.

Basically, the package concept is similar to the folder hierarchy on your computer. A package is just a way of organizing your code by its functionality. Android organizes its classes into logical packages, which we will routinely import and use throughout this book.

In our Hello World application in the previous chapter, we needed two import statements in our MyHelloWorld.java file to support class functions in our application:

import android.app.Activity;
import android.os.Bundle;

These are basically addresses to where the code for each import statement is located. Here is a generalization of how an import statement follows a path to the class:

import platform.functionality.classname;

This applies to our two statements as follows:

Thus, the Activity class, which is the super class for any activity that you create, is found within the android.app package. This app part says that this package logically contains classes that are necessary for the creation of Android applications, and one of these is the Activity class, which allows us to define UIs.

The android.os package we referenced in our import statement contains classes that are operating system utilities. One of these is Bundle, which allows us to create bundles of variables for convenience and organization.

You might be wondering if the package is the highest level of organization in Java. The answer is no, there is one higher level. This level is sometimes called a platform or application programming interface (API). This is a collection of all the core packages for a given language, such as Java SE or Java ME, or all the packages of a specialized product, such as Android.

An Android activity contains a UI construct that accomplishes a given user-input task via the smartphone display screen.

Android applications can have more than one activity. In fact, more complex applications usually have one activity for each UI screen implementation. For example, if you are programming a game, you might have the following activities:

If an application has more than one activity, one is marked as the activity that is presented when the application is launched. In our game example, that is the splash screen (although it could be the instructions screen). This activity has an onCreate() method that calls the main.xml file, as you saw in the Hello World application we created in the previous chapter.

Here is the code for the onCreate() method from the Activity base, or super, class (note the super keyword) and sets the content View to the main.xml UI definition:

public class MyHelloWorld extends Activity {
    /** Called when the activity is first created. */
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
    }
}

An activity can be full screen, or it can be part of a screen, allowing for floating windows on top of other windows. An activity can also make use of other windows. For instance, an activity might show a pop-up dialog requesting that the user enter information, or it could display a product information window when a user clicks a product name or SKU.

We will get into Activity class creation in all of the following chapters, and cover it specifically in Chapters 6 and 7,

Unlike activities, services do not have any visual UI (that's what an activity is for). Services handle the processing or heavy lifting for your application. They are often used for doing things that need to be done in the background or back end of the application, while the user works with your UI in the foreground or front end of your application.

Here are some examples of what service components can do:

Services handle calculations or processing that needs to be done in the background while the user is busy looking at the results of this processing on the activity-generated UI screen elements.

Not surprisingly, you create your own services in Android by subclassing the Android Service class. Services can run in the background, even after an activity UI screen is no longer visible, such as when a user picks an MP3 audio file to play, and then does something else with the phone while listening to the music. We will take a look at using services in Chapter 11. There, you'll learn how to use a MediaPlayer to play audio and video streams in the background of your applications.

Broadcast receivers are communication components that receive messages that are sent between the Android operating system and other application components, or between Android application components themselves.

The Android operating system often sends out messages regarding the status of what is going on in real time with the Android phone itself. These are statuses that any Android application may want or even need to know about in order to protect the application integrity, such as if the phone is about to lose power and your app needs to save files.

The following are some examples of Android operating system-initiated broadcast messages:

And here are a couple examples of application-to-application broadcast messages:

Your application can implement as many broadcast receivers as you like, in order to intercept any of the types of messages that need to be monitored for your application's operation.

Like Android services, broadcast receivers operate in the background, and thus do not have any associated UI elements. However, this does not mean that the broadcast receivers cannot trigger or invoke a UI activity in response to the messages that they carry. In fact, it is common practice to have broadcast receivers trigger UI elements that alert the user as to what is going on within the application.

Broadcast receivers can also use the Android NotificationManager class to alert the user via built-in phone notification methods, such as flashing the screen backlight, playing a sound, triggering phone vibrations, and placing a persistent alert icon on the smartphone status bar.

Broadcast receivers are created by extending the Android BroadcastReceiver class. We will look at using them in Chapter 11.

Content providers in Android provide a way to make data available to your application and to other applications, if that is desired. This can be data that is created in and for your own application, or it can be data that can be accessed by your application, but that is created by other applications, or even by the Android phone utilities themselves. It can also be data that is created by your application and is made accessible to other applications. The content provider component is both powerful and flexible.

For example, an Android phone utility uses a content provider to access the phone number database that is kept within your smartphone. Android comes with a number of built-in content provider databases, including contacts, images, audio, and video. These can be accessed via phone system utilities, as well as by your applications through coding.

Content data can be stored in a file system on your SD card in your smartphone, off-phone in a remote HTTP server, or in a proper database. The latter is the preferred method for storing and accessing data within Android, and you'll see that in action in Chapter 10, which covers using content providers.

To create your own content provider, you extend the ContentProvider base class, which implements a standard set of methods that are used to store and retrieve data. Applications access the methods defined by your ContentProvider class with a ContentResolver object, which is used to talk to any content provider, in order to navigate the data that is needed by the application.

A content provider is activated when it receives a request for data from a content resolver. The other three components—activities, services, and broadcast receivers—are activated via asynchronous messages called intents, which we'll look at next.