168 CHAPTER 6: Android Screen Design: Writing to the Display Using Activity and View
Finally, we will put all of this newfound knowledge to use, and will create your first custom Hello
Universe UI design, so that you get some hands-on experience in creating your own UI designs. We
will create a Galaxy object using your code from the previous chapter, and populate an information
screen for that object.
How Activity, View, and ViewGroup Relate
Before we look at the Android Activity, View, and ViewGroup superclasses and the functional
subclasses (those classes that you will actually utilize to construct your apps) that are created with
them over the next couple of chapters, it is important to understand how they all relate to each other
within the context of your application.
The reason I’m not including the Menu superclass and its functional subclasses in this chapter
is because menus in Android are “handled” separately from UI widgets (View) and UI layouts
(ViewGroup), in as much as they pop up over the screen triggered by a hardware MENU button or
the ActionBar Overflow menu. For this reason we are going to cover Menu objects separately, in the
next chapter. The one similarity is that each Activity subclass also has its own Menu system, as you
can see in Figure 3-8, set up via the second method, called .onCreateOptionsMenu( ).
As you have learned already, the Android runtime environment resides on top of the Linux operating
system (OS) kernel, and forms what is essentially the Android OS, under which your application
executes (runs). Your application defines itself to the Android RunTime (ART, for Android 5.0 and
later) or to the Android Dalvik Virtual Machine (DVM, for Android 4.4 and earlier OS versions) using
the AndroidManifest.xml application definition XML file that we looked at in detail during Chapter 4.
For each functional display screen in your app, which will generally contain some sort of UI design,
as well as related content, your application will define an Activity subclass. Your Hello Universe
application currently has one of these Activity subclasses already, as you saw in Chapter 3 in
Figure 3-8, with your MainActivity.java class, which as you now know from what you learned in
Chapter 5 on Java is actually an Activity subclass, due to the public class MainActivity extends
Activity declaration at the top of the class.
Each Activity subclass in your Android application will be required to have an .onCreate( ) method
defined, and this method will in turn be required to contain a setContentView( ) method call, whose
parameter list contains a reference to that Activity’s UI layout XML definition. For the MainActivity.
java class, this reference is R.layout.activity_main, which is Android “shorthand” to reference the
/res/layout/activity_main.xml file, as you can see in Figure 3-8, which after our Java primer chapter
should be making a whole lot more sense to you!
Android’s shorthand resource “path” definition starts with an “R,” which stands for “resources,” and
uses period characters (instead of slash characters) to reference the “layout” folder, and then the
“activity_main.xml” XML file. Notice that Android references do not include any file extension, so
R.layout.activity_main equates to your full Android project folder path as follows:
/workspace/HelloUniverse/res/layout/activity_main.xml.
The parent tag in this UI layout XML definition will generally reference a ViewGroup subclass,
such as the RelativeLayout class, which in the activity_main.xml file is represented by a
custom layout container classes in Android, which we will be covering in detail in Chapters 7 and 8.
There are a large number of custom layout container classes in Android, because these UI layout
classes provide the foundation of UI design in Android.