Programming Android – Part 2 – Objects and Handlers

After the general introduction to the programming environment used for Android App development, the second part of this series now focuses on two major concepts every Android App is based on. This is the basis for the details I’ll then describe about what my experimental app does and how.

The first concept of every Android App is that it is programmed in an object oriented language, namely Java. The core of object orientation can be described in two parts:

First, object orientation means that every line of code of an app is part of a class. On the highest level of abstraction, every app has at least one class and one method in the class that contains the code. This method is called when the app is started by the user. That method then creates what the user sees, i.e. it arranges text, buttons and other things on the display. If things start to get complicated a good approach is to put parts of the code into other methods which are then called by the main method. These methods then do their specific work and then return to the original method with a result that can be further processed.

The question that arises at this point is how Android knows which method to call when the App is launched. This can be answered by looking at the second idea of object orientation. Classes are a kind of blueprint if you will, and to make them come alive, they have to be instantiated. Think of the abstract term “car” as an example and what it represents. Your own (physical) car is an instantiation of the abstract term car. There can be several instances of a car, like for example, your car and my car. In object orientation, an instance is called an object. And to bring the three words together: An object is an instance of a class. What Android does with object orientation is describing the basic principles of how an app is supposed to work and defines the names and parameters of the methods that are called by the OS when specific things happen.

When the app is started, a specific method of an object is called. To make this approach useful the app uses the method definition, i.e. how the method looks to the outside but defines what is inside the method itself. This is called “overriding”. So if there are two apps running they both have the same method that is called by the OS when the app is launched. The content of that method, however, is defined by the programmer of each app.

The method that is called when the app is started is only one of many that are already contained in the basic app class and the application programmer is free to either use methods and variables as they are or override them and do their own things with it. What remains the same in all apps are the method names and the parameters the method exchanges with the external word. Thus, there is a uniform way for the OS to interact with an app as will be discussed in the next paragraph.

Object orientation is a means to an end. How the app interacts with the world is a different matter. For that purpose, the OS needs to provide an Application Programming Interface, an API. Apple’s iOS also offers an object oriented interface to programming but the API is quite different to that of Android. If you want to display an “OK” button on the screen for example, an object of the type “button” is instantiated from the button class. The text displayed on the button and many other things are then defined by the app by calling methods of that object that then do their job inside the class to bring the button to live.

The second major concept of Android app programming is call back methods. Whenever something happens that the app should become aware of, such as for example the user clicking on a button on the screen, the user pressing a hardware button, the app being sent to the background because the user starts another app, data arriving from the network for the app, etc., a callback method is called by the OS. But how can the OS know which method of the app to call? If the callback method is part of the general app class described above then there is nothing special to do because the callback methods are predefined and the programmer can simply override the existing methods for the different events. Most elements a user interacts with such as buttons for example are not part of the general Android app class. As described above, the user instantiates a button object from the button class and then the app object contains a button object. To be informed about the user clicking on the button, the programmer needs to define a method in the app class to receive the event. A reference to that method is then given to the button object. When the user then clicks on the button, the button object calls the given method.

Most apps that interact with the user are fully call-back controlled. When the app starts, everything is put on the screen and callback methods are put in place. Then, while nothing more happens for the moment, no further processing power is needed for the app and no code is executed. Only once the user interacts with the app by, for example, clicking on a button, a callback method is called. The callback method can then perform an action that is supposed to happen when the button is clicked, e.g. a calculation is made and an output is made to the screen, and then go back to sleep until a new event arrives.

And finally, in addition to call-back methods, an app can also spawn background threads for actions that are continuously performed without user interaction or for actions that take a long time to complete. A separate execution thread has to be used for this so the main thread with the callback methods can be called by the OS at any time the user interacts with the app.

There we go, so much for the theory. In part 3, I’ll put the stuff described above into practice.