CHAPTER 3: An Introduction to the Android Application Development Platform 81(if there is no hardware MENU button) is called the Options Menu. The Status Bar is always at the
very top of every Android device, and holds the battery power indicator, network mode (3G, 4G, 4G
LTE, and so forth) indicator, signal strength indicator, and similar hardware operation indicators.
The Action Bar is located just underneath the Android Status Bar, which is the top-most OS bar
containing your signal meter and the like. In addition to the options menu, accessed by those
three vertical dots on the right end of the Action Bar, the Action Bar contains your application icon,
application title, and if you code it correctly, either icons or text tabs that can access areas of your app.
The /res/menu/ folder contains XML definitions of the menu structures that you create for your
application, as you may have imagined. Notice in Figure 3-9 that Eclipse ADT created a default menu
XML definition for you, in a file called main.xml. Notice the file naming convention here; the main.xml
menu XML definition, and the MainActivity.java and activity_main.xml layout XML definition all
match up, so you know they are related!
Android Values: Assets Defining App Constants
A “value” in the Android project folder hierarchy is what is known in Java programming as a
“constant.” Values in Java code are different than Java constants, as they are meant to change,
whereas constants are meant to stay the same (that’s why they’re called constants). We will be
getting into this distinction as far as Java goes soon, in Chapter 5, when we look at the Java
programming language specifically. You will, of course, be required to understand exactly how Java
works before we get much further into the book, as things will get more and more complicated with
each chapter.
Android values (constants) are a bit more flexible than Java constants are, as Java constants
define fixed (known as immutable) data values that cannot be changed, whereas Java values can
be changed at runtime. The Android values we are talking about in this section also cannot be
changed (they are actually constants, but are called values). So make sure not to get confused by
semantics here. Of course, once your Java code places these initial constant values into memory,
the application code (logic) may change them!
Let’s examine the /res/values folder from the current application bootstrap project in more detail.
This is where you (or Eclipse, in the case of the New Android Application Project series of dialogs)
will place any predefined application values. These exist inside of (underneath) the /res/values/
folder in the form of XML files. These XML files contain constant definitions that define constant
names (x or y, for instance) and their data values.
The value constants that are defined inside of these XML files will later be referenced inside of your
Java code, or via your XML markup. For example, these values might be strings (a collection of text
characters), styles (how you want a UI design to be formatted throughout your app), dimensions
(numeric size specifications), or other constants that need to be “hard-coded” values that your Java
code or XML markup uses in your program logic or UI design that you do not want to change.
The logic behind having a /res/values/ folder involves holding all of your constant values for your
application in one place. This is a similar concept to the repository we used in Chapter 2 to update
Eclipse ADT, only the /res/values is a resource repository for value constants which are used in your
Android application. The /res/values/ folder is therefore your application constants repository data
(folder) structure, and its usage allows you to make your application constant changes in one single
location. In this way, if you need to adjust your constant values during application development or
testing, you can do this using XML files.