Tải bản đầy đủ
5 Layout, views, and widgets

5 Layout, views, and widgets

Tải bản đầy đủ



Android application fundamentals

A layout file is an XML file. It’s a different set of elements, but the concept is similar to
the kind of HTML that would be used to create a web page. Whereas HTML elements
tend to be low-level, Android’s layout elements are more sophisticated. The root element of this layout file is a container of View classes known as a LinearLayout B.
LinearLayout puts all of its child views into either a single row or column. Other layout types are provided, such as FrameLayout, RelativeLayout, and TableLayout, and
you can create your own, but for now we’re going to stick to LinearLayout and we’ll
meet the other types in chapter 4.
In our example, the orientation of our LinearLayout (defined as an attribute of
the element) is vertical. This means all of the child views will be laid out in a single column, top-to-bottom in the same order as they are specified in the layout file. Inside
the layout, we include two child elements: a ListView with a special reserved ID of
list C, and a Spinner D. We can also see that we’re defining attributes for these elements, such as layout_width, layout_height, and layout_weight. These control the
size and positioning of the view elements, and again we’ll get to the specifics surrounding these and other layout attributes
in chapter 4.
As seen in the screenshot in figure 2.5,
which our deallist layout produces, a ListView is a widget that shows a list of items,
and a Spinner is a widget that displays a
selection of choices with one element at a
time showing (we’ll learn more about each
of these when we see the code that corresponds to this layout in the next few sections). Going back to listing 2.4, note how
both widgets have resource IDs, like you’d
assign to an HTML element.
One thing you may have noticed is that
the Spinner resource ID is declared with a +
sign in front of it: @+id/section_spinner.
This special notation means go ahead and
create the resource ID in the resource table
(and R.java file) if it doesn’t already exist. If
Figure 2.5 This DealDroid DealList
you reuse a resource ID, or otherwise refer
screen shows the two components, a
ListView and a Spinner,defined in
to one that already exists, you don’t need to
the deallist.xml layout.
include the plus.
XML-based layouts are convenient and
arguably a solid design choice that separate responsibilities, but it’s important
to note that you don’t have to use XML at all. Layouts, other XML resources,
and all other views and widgets can also be defined within Java code. All of the
XML layouts that Android uses are representations of framework Java classes



that are parsed and inflated into Java objects. We’ll learn more about writing
raw views later in the book, and more about layout inflation later in this chapter, but keep in mind that XML isn’t the only way to define UI components in
your Android application.
IDs in XML layouts let us refer to widgets in code, so we can populate them with data,
attach event listeners, and so on. Also note that the elements’ XML layouts correspond
to much richer components than the low-level elements in HTML.
We aren’t done with our discussions of layouts yet, because we have one more screen
(the detail screen) to build for DealDroid, and we’ll focus on the UI in chapter 4. Nevertheless, this gives us a good foothold into what they are; now we need to define the
other terms we are bandying about: views and widgets.


Views and widgets
As we touched on in chapter 1, the class android.view.View is the base class for UI
objects in Android. This is where every onscreen element in any Android application
begins. There are three major types of views:


The first and most basic view type is SurfaceView, which provides a direct drawing surface. We won’t deal with these directly in this chapter, but you’ll learn more about
them when we talk about drawing and graphics in later chapters. The next view type is
ViewGroup. These are an abstraction of layouts and other view containers (views that
contain other views). We’ve already seen a few simple layouts, and we’ll learn more
about them and how they relate to view hierarchies and groups coming up. Finally,
the last view type is Widget. These are the classic UI components you’ll use most often.
Widgets, which are part of the android.widget package, are views that often interact with the user and can be backed by a data source. This means simple form elements such as text input boxes and buttons are widgets, and are more involved
components like ListView and Spinner, as we’ve seen.
Now that we’ve declared views and widgets in layouts and touched on what these
terms mean (knowing there’s more to come), the next thing we need to do is link to
these components in code and bring them to life with activities.


An Activity is a single focused thing that the user can do. Typically each screen in
your application will be defined with a layout, and made up of views and widgets that
are controlled by a corresponding Activity. Each Activity creates a window for UI,
manages lifecycle and state, provides an endpoint for intents (which we’ll learn about
in section 2.8), handles interface events, controls menus, and more.



Android application fundamentals

A SINGLE FOCUSED THING Typically an Activity will correspond to a screen in
an application, but note the careful wording of the definition from the documentation. A “single focused” thing isn’t a screen. The screen abstraction
works most of the time, and it’s a useful analogy, but keep in mind that an
Activity can also be a floating window on top of another Activity.

To create an Android screen in an application you’ll extend the Activity class or one
of its specialized subclasses (and you’ll usually define the UI for that screen with a layout resource, as we’ve seen). We’ll cover some of the trickier parts of dealing with the
Activity class, including lifecycle subtleties and how activities relate to tasks, in
chapter 3. Here we’ll address the basics of working with the Activity class, and we’ll
see our first use of a specialized Activity subclass for dealing with lists, ListActivity. We’ll start with the most important parts of the Activity class, the methods that
you’ll implement often.


Activity basics
The Android platform performs an intricate juggling act to manage resources. With
limited CPU power and memory available, Android uses a stack of activities that the
system controls to try to keep the most relevant things a user is interested in running,
and push other things into the background.
What’s most relevant, and how does the system perform this juggling act? Most relevant is any application the user is using. An application is typically composed of a set
of components, including activities, services, and broadcast receivers, that are run
using the same user ID and process on the platform (as we noted in chapter 1). As
users click on buttons or respond to notifications to open new activities, the system
shuffles existing activities to the background. To do this, the system pushes activities
through their lifecycle methods. The most common Activity lifecycle methods are:

onCreate—Called when an Activity is first created
onPause—Called when an Activity is going into the background
onResume—Called when an Activity is being resumed after having been in the

There are more lifecycle methods (we’ll discuss all of them in the next chapter), but
onCreate is where things are initiated, onPause is where they should be cleaned up or
persisted, and onResume is where things are reloaded or reset. You’ll override onCreate with every Activity you build, and in most (but not all) onPause and onResume.
In addition to the lifecycle phase hooks, Activity also extends Context and provides a host of event, state, menu, and other helper methods. The lifecycle methods of
Activity are essential to understand and use correctly. Using these methods properly
will result in a responsive and error-free application. Because these methods and the
related concepts are important, we’ll focus on this topic and related things such as
managing state and using some of the other Activity methods in the next chapter.
Before we get into those details, we’re first going to look at the Activity implementation to create the deal list screen for DealDroid.




List-based activities
Lists in Android are a great place to start digging into views and activities, and a good
example of the Model-View-Controller (MVC) design pattern. It’s important to understand how data and its representation are decoupled from each other and how this is
reflected in the framework interfaces.
Recall from figure 2.6 that DealDroid displays lists of deal data using a ListView.
ListView is a scrolling container that may have an arbitrary number of child views,
which we call list items. A list item can be any kind of view, and not all list items have to
be of the same kind, which enables you to create lists of varied complexity. ListView
does all the heavy lifting for you: it takes care of recycling and redrawing all visible list
items if the underlying data changes, it handles touch events, and so on.
Even though it’s perfectly fine to use ListView directly (and sometimes you need
to), it’s typically used indirectly by going through Android’s ListActivity class. What
ListActivity does is manage a ListView for you, and hence saves you from writing
the boilerplate code required for setting it up and responding to events, and so on.
Here we’ll take the ListActivity approach and build out the code that provides
the ListView for DealDroid. The DealList class is our first nontrivial piece of code.
We’re going to break it into separate sections to discuss, starting with the biggest part:
the declaration and onCreate method, as shown in the following listing.
Listing 2.5

Start of the DealList.java Activity class, from declaration through onCreate

public class DealList extends ListActivity {


private static final int MENU_REPARSE = 0;


DealDroidApp app;
List items;
DealsAdapter dealsAdapter;
Spinner sectionSpinner;
int currentSelectedSection;
ProgressDialog progressDialog;


public void onCreate(Bundle savedInstanceState) {



Set layout as
content view

progressDialog = new ProgressDialog(this);
getString(R.string.deal_list_retrieving_data) );
app = (DealDroidApp) getApplication();
items = new ArrayList();
dealsAdapter = new DealsAdapter(items);


Set up Collection
and Adapter

if (app.getSectionList().isEmpty()) {


Set Adapter
for ListView





Android application fundamentals

if (app.connectionPresent()) {
new ParseFeedTask().execute();
Parse data from
} else {
the network
Toast.makeText(this, getString(
Show quick
message with Toast
} else {



sectionSpinner = (Spinner) findViewById(R.id.section_spinner);
spinnerAdapter =
new ArrayAdapter
android.R.layout.simple_spinner_item, app.getSectionList());
Set up Spinner
and Adapter
new OnItemSelectedListener() {
public void onItemSelected(AdapterView parentView,
View selectedItemView, int position, long id) {
if (currentSelectedSection != position) {
currentSelectedSection = position;
app.getSectionList().get(position).getItems() );


public void onNothingSelected(AdapterView parentView) {
// do nothing


for Spinner


React to

// … continued in subsequent listings

The first thing to note with listing 2.5 is that, as promised, we’re extending ListActivity B. From there, we see what almost every Activity will start out with, overriding onCreate C. This is part of the all-important Activity lifecycle that we’ll focus on
in chapter 3. For now, we need to understand that onCreate is where we set things up
when our Activity is created. Inside of onCreate, we associate the layout file we built
in listing 2.4 as the content view using setContentView D. We’ll learn more about
what exactly this is doing when we talk about inflating layouts in chapter 4. For now,
keep in mind that this method is how we associate our XML layout with our Activity.
After the initial setup, we’re instantiating an Application object E, which we’ll use
later to store some global state and define some utility methods. The code for this class,
and more discussion about Application objects in general, will be in section 2.9. Next,
we get to the heart of the ListView matter, using an Adapter to provide data for our list.
In this case, we’re using a regular Java Collection (a List), and passing it into a
DealsAdapter class F. The DealsAdapter is a custom class that extends Adapter and



supplies the deal items for our list. In general terms, this is what adapters do: they provide data. Adapters come in various forms. They can be backed by arrays, collections,
or even files or database cursors, and they can be trivial or complex. We’ll learn more
about adapters, and see the code for DealsAdapter, in section 2.7. For now, trust that
the adapter will supply deal items to the ListView. We make the association between
the Adapter and the ListView with setListAdapter G.
One important thing to note is that we haven’t directly referenced a ListView anywhere. This is one of the conveniences ListActivity provides. We can imagine you
frowning. How does this work, considering we haven’t done any additional setup? We
did, but it was subtle. Remember how we passed a reserved ID to the element in the layout in listing 2.4? The trick is that whenever you inherit from ListActivity, it’ll look for a declaration in the activity’s layout that carries the
android:id/list resource ID. It’ll then automatically connect this widget with the
operations in the setListAdapter method (and other helper methods, such as
getListView). No rocket science involved.
RESERVED RESOURCE IDS Android uses predefined reserved IDs not only for
lists, but also in some other places. One other example of this is TabActivity,
which will look for the tabhost, tabcontent, and tabs IDs in your layout. You
can also use them to access views defined in some of Android’s predefined
layouts. For instance, Android ships with default layouts for list items, such as
simple_list_item_1 and simple_list_item_2 for single- and two-line textbased list items.

Getting past the adapter setup for our ListView, we then come to a method call that
checks whether the current deal section list of items is already populated. If it’s not,
we check whether the network is available, and we then issue a mysterious call to
ParseFeedTask.execute H. This is an invocation of an AsyncTask implementation.
An AsyncTask lets us perform a long-running operation on a separate Thread from
the UI (in this case, make a network call and parse the eBay deals RSS feed). We aren’t
going to step into this code here because it’s off the fundamentals track, but don’t
worry; we’ll cover threading, and AsyncTask in detail, in chapter 6 (and if you’re
interested in jumping ahead now, you can see this code in the download for the DealDroid project). The takeaway here is that we don’t want to do any long-running and/
or blocking work in our onCreate method (or anywhere on the main UI Thread for
that matter). Also, if we can’t run our AsyncTask because we can’t connect to the network, we show the user a pop-up message on the screen using a Toast I.
After our data retrieval is out of the way, we then get to our Spinner widget J. As
we saw in figure 2.6, the Spinner provides a stacked list of choices, much like an
HTML select tag. The Spinner also uses an Adapter as a data source. This time it’s a
standard ArrayAdapter that gets data from our Application object (again, we’ll get
into the adapter details in the next section).
After the data is set up via the Adapter, we’re then attaching an OnItemSelectedListener to our Spinner 1). This allows us to receive an event anytime an item in the



Android application fundamentals

Spinner is selected. For this case, we get the clicked item, determine whether it’s different than what we’re already working with, and if so, call resetListItems with the
selection 1!. We’ll see what this method does in our next listing; first let’s expand on
how an Android View component reacts to an event. There are many listeners like this
in the Android framework for all kinds of events: items being clicked, items being
long clicked, scrolling, flinging, focus changes, and more. Listeners are interfaces.
Here we’ve created an in place implementation of the OnItemSelectedListener
interface with an anonymous inner class.
ANONYMOUS INNER CLASSES You could define a class in a separate file that
implements a listener interface when you need it, then create an instance of
that class, and then use it for the adapter’s listener. Alternatively you could
declare that the current class you’re working on implements the interface
and you could include the required method locally (and if you have multiple
listeners, you can use the same method and filter for the correct component
within it). There are several approaches to dealing with this situation, and
which one to choose depends on the situation to some degree, and your personal preference. We find anonymous inner classes convenient and capable,
and that’s why we’ve chosen them, although they aren’t easy to understand at
first. One of the advantages of anonymous inner classes is that they have variable scope access to the enclosing method and class variables through a feature known as lexical closure.

That’s it for the onCreate method of DealList. It’s not trivial, so don’t worry if you
don’t completely understand it yet. As we flesh out the details of the Adapters and
work through the remaining listings, things will come into focus. We’ll start with what
happens when we have a new list of items to display in our ListView, such as when a
selection is made from the Spinner. This takes us into the aforementioned resetListItems method, which is seen in the following listing.
Listing 2.6

Resetting the ListView adapter in the DealList.java Activity class

private void resetListItems(List newItems) {


Reset member

Notify Adapter that
data set has changed

The resetListItems method is short and sweet. In it, we take in a new List of Item,
and we use it to repopulate the class member variable we’ve assigned for items B.
Recall that this same instance of items is what we passed into DealsAdapter when we
constructed it. It’s the same instance, and after we change it, we call notifyDataSetChanged C on DealsAdapter, and our list is updated and the views are
redrawn. We’ll see the code for our custom adapter, and learn more about adapters in
general, coming up.
Now that we’ve seen how our ListView will get updated when we want to reset the
data, the next thing we need to handle is how to respond when a user clicks a specific



item in the list. This is done with the aptly named onListItemClick method in the following listing.
Listing 2.7

Handling a click event for an item in the ListView of DealList.java Activity

protected void onListItemClick(ListView listView,
View view, int position, long id) {
Intent dealDetails = new Intent(DealList.this, DealDetails.class);
Respond with Intent



The onListItemClick method, which is part of ListActivity, is an event-handling
callback. If a user selects an item in a ListView, this method is fired, and we override
it B to do whatever we want C. Within it we set some global application state on the
previously noted Application object, and then we launch the DealDetails Activity
using an Intent. As we’ve touched on, intents are the wiring of Android applications;
we’ll learn more about them in section 2.8.
THE POWER OF LISTVIEW As we’ve seen, ListView presents a scrollable list of
selectable items. ListView is one of the most useful and powerful widgets
Android provides. Though we aren’t using more advanced features here, you
should know that ListView could also support filtering, sorting, complex
item views, custom layouts, headers, footers, and more. We’ll see ListView
again in many later examples in the book, and we’ll exercise more of it as we
go, but check the documentation for a comprehensive outline of the capabilities: http://mng.bz/2LZM.

After the ListView and the Spinner, we need to expand on one more aspect to the
DealList screen: the options menu. The options menu is shown if the user presses
the device’s Menu button. For this version of DealDroid, our options menu only has
one choice: reparse the data feed (because we aren’t using a Service to do that for
us, we have a menu choice to do it). Setting the options menu up, and reacting to
menu events, are both accomplished in the following listing.
Listing 2.8

Setting up the menu for the DealList.java Activity class

public boolean onCreateOptionsMenu(Menu menu) {
menu.add(0, DealList.MENU_REPARSE, 0,
return true;
public boolean onOptionsItemSelected(MenuItem item) {
switch (item.getItemId()) {




Add MenuItem
to Menu


Override onOptionsItemSelected



Android application fundamentals

if (app.connectionPresent()) {
new ParseFeedTask().execute();
} else {
return true;
return super.onOptionsItemSelected(item);

Any Activity can choose whether to include an options menu. To create one, you can
override onCreateOptionsMenu B and then append MenuItems to the passed-in Menu,
as we’ve done here. The Menu.add method lets us specify a group ID, item ID, order, and
a String to display C (among other options, although we aren’t using anything else
here). The options menu can hold as many items as you want, although only the first
six can be shown on what’s called the Icon Menu. Beyond six, the Expanded Menu can be
accessed by selecting More from the Icon Menu. Because we only have one item here,
we aren’t too worried about the group and item IDs, but they’re useful when you have
more items. We return true in onCreateOptionsMenu because we want the menu to be
displayed (you can return false if you don’t want the menu to be displayed).
To respond when a user selects an item from the options menu, we’ve also overridden the onOptionsItemSelected method D. Here, the selected MenuItem is passed
in, and we use the item ID to tell which one we’re dealing with. Once we have the specific MenuItem we’re concerned with, we can perform whatever action we need to (in
our case, reparse the daily deals feed, again using the AsyncTask).
OPTIONS MENU AS AN XML RESOURCE You can define your options menu in
code, as we’ve done for DealList, or you can use an XML menu resource (/res/
menu). There are many possibilities and options; for complete details on the
options menu, see the current documentation: http://mng.bz/h8c0.

With the menu out of the way, the final piece of main Activity code we need to
address for DealList is the all-important onPause method, which is shown in the next
Listing 2.9

The onPause method in the DealList.java Activity class

public void onPause() {
if (progressDialog.isShowing()) {

The Activity lifecycle, which we’ve already mentioned and will cover in detail in
chapter 3, is managed by overriding lifecycle methods, such as onCreate and onPause.



onCreate was where we built up the components our Activity needs, and onPause is
where we need to perform any necessary cleanup. For DealDroid we’re using a ProgressDialog to indicate to users that something is happening at certain points (such
as when we make the network call to get deal data). A ProgressDialog is an interac-

tive pop-up dialog that can show progress, such as a horizontal bar filling up, or a spinning circle. If this dialog is showing when our Activity is stopped, it’ll effectively be
leaked, and that can cause force close (FC) errors. This is why we need to dismiss it, if
it’s showing, within onPause.
Now that we’ve touched on how Activity lifecycle methods are used (as a primer
to chapter 3), and seen how a ListActivity works, the next step is to finish up and
see how the adapters backing our views are implemented.


When you have to feed data from a data source to a view, you’ll use an Adapter, as
we’ve seen. As the name suggests, an Adapter adapts a certain data source and hence
lets you plug in different kinds of data sources into a view (an AdapterView) that can
then render this data to the screen. ListView and Spinner are AdapterView views.
Android ships with several predefined adapters, most notably ArrayAdapter, for serving data from a Java array object or Collection, and CursorAdapter for fetching data
from a SQLite database (we’ll learn more about databases and cursors in chapter 7).
You’re by no means restricted to the built-in adapters; you can, for instance, implement an adapter that wraps a web service and fetches data from the Internet directly
into your views. Anything’s possible!


Adapter basics
The most basic way to use an adapter is to leverage one of the existing implementations Android provides, such as ArrayAdapter (which, despite the name, also works
with collections). To see how this works, let’s take a quick look back at how we provided data for our Spinner in listing 2.5:
spinnerAdapter =
new ArrayAdapter
android.R.layout.simple_spinner_item, sectionList);

To instantiate this ArrayAdapter, we’re using DealList.this for the Context, then a
layout resource to tell the Adapter how to display each item, and finally the data itself
in the form of a List of Section objects. Section is a simple JavaBean-style class (getters and setters) with a title and a collection of Items that comes from our own model.
Item is another simple bean that represents a particular deal with an ID, title, price,
location, and so on (for the complete source on these classes, see the code download
for this project). The layout we’re using for the Spinner item is set using the reserved
ID android.R.layout.simple_spinner_item. By default, ArrayAdapter expects a layout that represents a single TextView. As we can tell by the android name prefix, we’re
using a layout provided by the framework for this purpose. Our Spinner is simple, so



Android application fundamentals

we’ll use this built-in layout. If we wanted, we could change this layout and define our
own. The default behavior of an ArrayAdapter is to call the toString method on each
piece of data it has and render it using the specified layout. If you want to do something
different, you can override the getView method of ArrayAdapter as we’ll see in the
next section.
If you look through the various Android APIs, you’ll
notice that many of them take an android.content.Context object as a
parameter. You’ll also see that an Activity or a Service is usually used as a
Context. This works because both of these classes extend from Context.
What’s Context exactly? Per the Android reference documentation, it’s an
entity that represents various environment data. It provides access to local
files, databases, class loaders associated to the environment, services including system-level services, and more. Throughout this book, and in your day-today coding with Android, you’ll see the Context passed around frequently.

A basic adapter provides a quick way to pour data into a view, but what if we need to
customize the views, or moreover, what if we need to reflect changes in the data to the
view, or vice versa? To deal with either or both of those conditions, we often need a
custom adapter.


Custom adapters
Creating your own adapter means creating a class that implements the Adapter interface. There are several convenience classes such as ArrayAdapter or BaseAdapter
from which you can inherit, and you need to override or add those parts that are relevant to you. The getView method is called whenever a list item must be (re)drawn.
This happens frequently, for example when scrolling through the list. If the list data
changes, you must tell the list view that it should redraw its children by calling
Adapter.notifyDataSetChanged, as we saw in listing 2.6.
The DealsAdapter we referenced in listing 2.5 is a custom adapter that extends
ArrayAdapter. In listing 2.5 we instantiated this Adapter and set it as the backing for
the entire ListActivity using setListAdapter(dealsAdapter). The DealsAdapter
code is shown in this next listing.
Listing 2.10 The DealsAdapter.java custom Adapter for supplying views to the DealList
private class DealsAdapter extends ArrayAdapter {

public DealsAdapter() {
R.layout.list_item, new ArrayList());





public View getView(int position,
View convertView, ViewGroup parent) {
if (convertView == null) {

Override getView