- 3.1. Introduction
- 3.2. Test-Driving the Tip Calculator App
- 3.3. Technologies Overview
- 3.4. Building the App's GUI
- 3.6. AndroidManifest.xml
- 3.7. Wrap-Up
This chapter is from the book
This chapter is from the book
This chapter is from the book
3.3. Technologies Overview
This section introduces the IDE features and Android technologies you’ll use to build the Tip Calculator app. We assume that you’re already familiar with Java object-oriented programming. You’ll:
- use various Android classes to create objects
- call methods on Android classes and objects
- define and call your own methods
- use inheritance to create a subclass of Android’s Activity class that defines the Tip Calculator’s functionality
- use event handling, anonymous inner classes and interfaces to process the user’s GUI interactions
3.3.1. Class Activity
Unlike many Java apps, Android apps don’t have a main method. Instead, they have four types of executable components—activities, services, content providers and broadcast receivers. In this chapter, we’ll discuss activities, which are defined as subclasses of Activity (package android.app). Users interact with an Activity through views—that is, GUI components. Before Android 3.0, a separate Activity was typically associated with each screen of an app. As you’ll see, starting in Chapter 5, an Activity can manage multiple Fragments. On a phone, each Fragment typically occupies the entire screen and the Activity switches between the Fragments based on user interactions. On a tablet, activities often display multiple Fragments per screen to take better advantage of the larger screen size.
3.3.2. Activity Lifecycle Methods
Throughout its life, an Activity can be in one of several states—active (i.e., running), paused or stopped. The Activity transitions between these states in response to various events:
- An active Activity is visible on the screen and “has the focus”—that is, it’s in the foreground. This is the Activity the user is interacting with.
- A paused Activity is visible on the screen but does not have the focus—such as when an alert dialog is displayed.
- A stopped activity is not visible on the screen and is likely to be killed by the system when its memory is needed. An Activity is stopped when another Activity becomes active.
As an Activity transitions among these states, the Android runtime calls various Activity lifecycle methods—all of which are defined in the Activity class
http://developer.android.com/reference/android/app/Activity.html
You’ll override the onCreate method in every activity. This method is called by the Android runtime when an Activity is starting—that is, when its GUI is about to be displayed so that the user can interact with the Activity. Other lifecycle methods include onStart, onPause, onRestart, onResume, onStop and onDestroy. We’ll discuss most of these in later chapters. Each activity lifecycle method you override must call the superclass’s version; otherwise, an exception will occur. This is required because each lifecycle method in superclass Activity contains code that must execute in addition to the code you define in your overridden lifecycle methods.
3.3.3. Arranging Views with LinearLayout and GridLayout
Recall that layouts arrange views in a GUI. A LinearLayout (package android.widget) arranges views either horizontally (the default) or vertically and can size its views proportionally. We’ll use this to arrange two TextViews horizontally and ensure that each uses half of the available horizontal space.
GridLayout (package android.widget) was introduced in Android 4.0 as a new layout for arranging views into cells in a rectangular grid. Cells can occupy multiple rows and columns, allowing for complex layouts. In many cases, GridLayout can be used to replace the older, and sometimes less efficient TableLayout, which arranges views into rows and columns where each row is typically defined as a TableRow and the number of columns is defined by the TableRow containing the most cells. Normally, GridLayout requires API level 14 or higher. However, the Android Support Library provides alternate versions of GridLayout and many other GUI features so that you can use them in older Android versions. For more information on this library and how to use it in your apps, visit:
http://developer.android.com/tools/support-library/index.html
A GridLayout cannot specify within a given row that the horizontal space should be allocated proportionally between multiple views. For this reason, several rows in this app’s GUI will place two TextViews in a horizontal LinearLayout. This will enable you to place two TextViews in the same GridLayout cell and divide the cell’s space evenly between them. We’ll cover more layouts and views in later chapters—for a complete list, visit:
http://developer.android.com/reference/android/widget/ package-summary.html
3.3.4. Creating and Customizing the GUI with the Graphical Layout Editor and the Outline and Properties Windows
You’ll create TextViews, an EditText and a SeekBar using the IDE’s Graphical Layout editor (that you used in Chapter 2) and Outline window, then customize them with the IDE’s Properties window—which is displayed at the bottom of the Outline window when you’re editing a GUI in the Graphical Layout editor. You’ll do this without directly manipulating the XML stored in the files of the project’s res folder.
An EditText—often called a text box or text field in other GUI technologies—is a subclass of TextView (presented in Chapter 2) that can display text and accept text input from the user. You’ll specify an EditText for numeric input, allow users to enter only digits and restrict the maximum number of digits that can be entered.
A SeekBar—often called a slider in other GUI technologies—represents an integer in the range 0–100 by default and allows the user to select a number in that range by moving the SeekBar’s thumb. You’ll customize the SeekBar so the user can choose a custom tip percentage only from the more limited range 0 to 30.
In the Properties window, a view’s most commonly customized properties typically appear at the top with their names displayed in bold (Fig. 3.2). All of a view’s properties are also organized into categories within the Properties window. For example, class TextView inherits many properties from class View, so the Properties window displays a TextView category with TextView-specific properties, followed by a View category with properties that are inherited from class View.
)
Fig. 3.2 | Properties window showing a TextView’s most commonly customized properties.
3.3.5. Formatting Numbers as Locale-Specific Currency and Percentage Strings
You’ll use class NumberFormat (package java.text) to create locale-specific currency and percentage strings—an important part of internationalization. You could also add accessibility strings and internationalize the app using the techniques you learned in Sections 2.7–2.8, though we did not do so in this app.
3.3.6. Implementing Interface TextWatcher for Handling EditText Text Changes
You’ll use an anonymous inner class to implement the TextWatcher interface (from package android.text) to respond to events when the user changes the text in this app’s EditText. In particular, you’ll use method onTextChanged to display the currency-formatted bill amount and to calculate the tip and total as the user enters each digit.
3.3.7. Implementing Interface OnSeekBarChangeListener for Handling SeekBar Thumb Position Changes
You’ll implement the SeekBar.OnSeekBarChangeListener interface (from package android.widget) to respond to the user moving the SeekBar’s thumb. In particular, you’ll use method onProgressChanged to display the custom tip percentage and to calculate the custom tip and total as the user moves the SeekBar’s thumb.
3.3.8. AndroidManifest.xml
The AndroidManifest.xml file is created by the IDE when you create a new app project. This file contains many of the settings that you specify in the New Android Application dialog, such as the app’s name, package name, target and minimum SDKs, Activity name(s), theme and more. You’ll use the IDE’s Android Manifest editor to add a new setting to the manifest that forces the soft keyboard to remain on the screen. You’ll also specify that the app supports only portrait orientation—that is, the device’s longer side is vertical.