7.

Networking
and web services
With the ubiquity of high-speed networking, mobile devices are now expected to perform
many of the same data-rich functions of traditional computers such as email, providing
web access, and the like. Furthermore, because mobile phones offer such items as GPS,
microphones, CDMA/GSM, built in cameras, accelerometers, and many others, user
demand for applications that leverage all the features of the phone continues to increase.

You can build interesting applications with the open Intent- and Service-based approach
you learned about in previous chapters. That approach combines built-in (or custom)
intents, such as fully capable web browsing, with access to hardware components, such
as a 3D graphics subsystem, a GPS receiver, a camera, removable storage, and more.
This combination of open platform, hardware capability, software architecture, and
access to network data makes Android compelling.

This doesn’t mean that the voice network isn’t important—we’ll cover telephony explicitly
in chapter 8—but we admit that voice is a commodity—and data is what we’ll focus on
when talking about the network.

Android provides access to networking in several ways, including mobile Internet Protocol
(IP), Wi-Fi, and Bluetooth. It also provides some open and closed source third-party
implementations of other networking standards such as ZigBee and Worldwide
Interoperability for Microwave Access (WiMAX). In this chapter, though, we’ll concentrate
on getting your Android applications to communicate using IP network data, using several
different approaches. We’ll cover a bit of networking background, and then we’ll deal with
Android specifics as we explore communication with the network using sockets and
higher-level protocols such as Hypertext Transfer Protocol (HTTP).
An overview of networking

A group of interconnected computers is a network. Over time,

networking has grown from something that was available only to
governments and large organizations to the almost ubiquitous and truly
amazing internet. Though the concept is simple—allow computers to
communicate—networking does involve advanced technology.

Networking basics
A large percentage of the time, the APIs you use to program Android
applications abstract the underlying network details. This is good. The
APIs and the network protocols themselves are designed so that you can
focus on your application and not worry about routing, reliable packet
delivery, and so on.
Clients and servers
Anyone who’s ever used a web browser is familiar with
the client/server computing model. Data, in one format or another, is
stored on a centralized, powerful server. Clients then connect to that
server using a designated protocol, such as HTTP, to retrieve the data
and work with it.

Checking the network status

Android provides a host of utilities that determine the device configuration and the
status of various services, including the network. You’ll typically use the
ConnectivityManager class to determine whether network connectivity exists and to
get notifications of network changes. The following listing, which is a portion of the
main Activity in the NetworkExplorer application, demonstrates basic usage of the
ConnectivityManager.
Communicating with a server socket

A server socket is a stream that you can read or write raw bytes to, at a
specified IP address and port. You can deal with data and not worry about
media types, packet sizes, and so on. A server socket is yet another network
abstraction intended to make the programmer’s job a bit easier. The philosophy
that sockets take on—that everything should look like file input/output (I/O) to
the developer—comes from the Portable Operating System Interface for UNIX
(POSIX) family of standards and has been adopted by most major operating
systems in use today.
To run the server, you need to invoke it locally with Java. The server has a main
method, so it’ll run on its own; start it from the command line or from your IDE.
Be aware that when you connect to a server from the emulator (this one or any
other), you need to connect to the IP address of the host you run the server
process on, not the loopback (not 127.0.0.1). The emulator thinks of itself as
127.0.0.1, so use the nonloopback address of the server host when you attempt
to connect from Android. (You can find out the IP address of the machine you’re
on from the command line by entering ifconfig on Linux or Mac and ipconfig on
Windows.)
Working with HTTP
You can use a raw socket to transfer IP data to and from a server with Android. This
approach is an important one to be aware of so that you know you have that option
and understand a bit about the underlying details. Nevertheless, you might want to
avoid this technique when possible, and instead take advantage of existing server
products to send your data. The most common way to do this is to use a web server
and leverage HTTP.

We’ll retrieve data using HTTP GET requests to a simple HTML page, using the
standard java.net API. From there, we’ll look at using the Android-included Apache
HttpClient API. After we use HttpClient directly to get a feel for it, we’ll also make a
helper class, HttpRequestHelper, that you can use to simplify the process and
encapsulate the details. This class—and the Apache networking API in general—has
a few advantages over rolling your own networking with java.net, as you’ll see.
When the helper class is in place, we’ll use it to make additional HTTP and HTTPS
requests, both GET and POST, and we’ll look at basic authentication.
Simple HTTP and java.net
The most basic HTTP request method is GET. In this type of request, any
data that’s sent is embedded in the URL, using the query string. The
next class in our Network-Explorer application, which is shown in the
following listing, has an Activity that demonstrates the GET request
method.

Robust HTTP with HttpClient

To get started with HttpClient, we’re going to look at using core classes to
perform HTTP GET and POST method requests. We’re going to concentrate on
making network requests in a Thread separate from the UI, using a combination
of the Apache ResponseHandler and Android Handler (for different but related
purposes, as you’ll see). The following listing shows our first example of using
the HttpClient API.
Creating an HTTP and HTTPS helper

The next Activity in our NetworkExplorer application, is a lot more straightforward and
Android-focused than our other HTTP-related classes up to this point. We’ve used the helper
class we mentioned previously, which hides some of the complexity. We’ll examine the helper
class itself after we look at this first class that uses it.

Web services
The term web services means many different things, depending on the source and the audience. To
some, it’s a nebulous marketing term that’s never pinned down; to others, it’s a rigid and specific set of
protocols and standards. We’re going to tackle it as a general concept, without defining it in depth, but
not leaving it entirely undefined either.
POX, REST, and SOAP are by far the most common web services around, so they’re what we’ll focus on in
this section. Each provides a general guideline for accessing data and exposing operations, each in a
more rigorous manner than the previous. POX basically exposes chunks of XML over the wire, usually
over HTTP. REST is more detailed in that it uses the concept of resources to define data and then
manipulates them with different HTTP methods using a URL-style approach (much like the Android Intent
system in general, which we explored in previous chapters). SOAP is the most formal of them all,
imposing strict rules about types of data, transport mechanisms, and security.

All these approaches have advantages and disadvantages, and these differences are amplified on a
mobile platform like Android. Though we can’t possibly cover all the details here, we’ll touch on the
differences as we discuss each of these concepts. We’ll examine using a POX approach to return recent
posts from the Delicious API (formerly del.icio.us), then we’ll look at using REST with the Google GData
AtomPub API. Up first is probably the most ubiquitous type of web service in use on the internet today,
and therefore one you’ll come across again and again when connecting Android applications—POX.
POX—Putting it together with HTTP and XML

To work with POX, we’re going to make network calls to the popular
Delicious online social bookmarking site. We’ll specify a username and
password to log in to an HTTPS resource and return a list of recent posts,
or bookmarks. This service returns raw XML data, which we’ll parse into
a JavaBean-style class.
REST
While we look at REST, we’ll also try to pull in another useful concept in terms of
Android development: working with the various Google GData APIs. We used the
GData APIs for our app's review information, but there we didn’t authenticate, and
we didn’t get into the details of networking or REST. Authenticate and retrieve a
Google ClientLogin token and retrieve the Google Contacts data for a specified user.
Keep in mind that as we work with the GData APIs in any capacity, we’ll be using a
REST-style API.
To SOAP or not to SOAP, that is
the question
SOAP is a powerful protocol that has many uses. We would be remiss if
we didn’t at least mention that though it’s possible to use SOAP on a
small, embedded device such as a smartphone, regardless of the
platform, it’s not recommended. The question within the limited
resources environment Android inhabits is really more one of should it be
done rather than can it be done.
Summary
In this chapter, we started with a brief background of basic networking
concepts, from nodes and addresses to layers and protocols. With that
general background in place, we covered details about how to obtain
network status information and showed several different ways to work with
the IP networking capabilities of the platform.

In terms of networking, we looked at using basic sockets and the java.net

package. Then we also examined the included Apache HttpClient API. HTTP
is one of the most common—and most important—networking resources
available to the Android platform. Using HttpClient, we covered a lot of
territory in terms of different request types, parameters, headers,
authentication, and more. Beyond basic HTTP, we also explored POX and
REST, and we discussed a bit of SOAP—all of which use HTTP as the
transport mechanism.