Using XML and JSON with Android, Part 1: Explore the benefits of JSON and XML in Android applications

Consider both XML and JSON data-interchanges formats for use on the Android platform

In this two-part article, explore techniques for handling two of the most common data formats used on the Internet—XML and JavaScript Object Notation (JSON)—on the Android platform. This first part covers the basics of XML and JSON and shows you how to build an Android application that parses and displays a Twitter status-update feed provided in both formats.

W. Frank Ableson is an entrepreneur living in northern New Jersey with his wife Nikki and their children. His professional interests include mobile software and embedded design. He is the author of Unlocking Android (Manning Publications, 2010), and he is the mobile editor for Linux Magazine.

Other articles in this series

Mobile devices and platforms boast more features and functionality with each new
release, and often mere months separate significant announcements from the leading
mobile vendors. The headlines are mostly about UI features (such as advanced
multitouch capabilities and Adobe® Flash® technology) and hardware
enhancements (such as processor speed and storage capacity). But the crucial fact
remains that content is king. Content—or, more generally, data—is
exchanged constantly among applications, servers, mobile devices, and users. Without
being able to work with it, smartphones such as Apple's iPhone and Google's Android simply become overpriced and underperforming cell phones.

Frequently used acronyms

API: Application Programming Interface

DOM: Document Object Model

HTML: HyperText Markup Language

IDE: Integrated development environment

SAX: Simple API for XML

SDK: Software Developer Kit

UI: User Interface

XML: Extensible Markup Language

Consider the phenomenal success of social-networking platforms such as Facebook, LinkedIn, and Twitter. From a pure feature-and-function perspective, these platforms are largely pedestrian. They are popular because members and site visitors derive value from the content published there. And that content is accessed increasingly by mobile devices.

This article demonstrates the use of XML and JSON data-interchange formats on the Android platform. The source of the data for the example application is a status-update feed for a Twitter account. The feed data is available from Twitter in both XML and JSON formats. As you'll see, the programming approach to manipulating the data varies significantly between the two formats.

I suggest you have the Android SDK version 1.5 or later installed along with Eclipse to run the example code that accompanies this article. To learn more about setting up your environment, visit the Android Developers website. It is also helpful, but not required, to have an active Twitter account to follow along with the example. See Resources for relevant links.

I'll begin with a brief look at both data formats, starting with XML. If you're already familiar with XML and JSON, you can safely skip to Application opportunity: Twitter feeds to start working with them on Android.

XML: An old friend

No more hard labor

The value of XML's self-describing nature is clear when you contrast it to the state of the art before XML's general adoption. Then, data-interchange exercises included laborious data-description documents, often written and maintained by hand in a word processor or spreadsheet application. These documents, commonly known as interface specifications, depicted field names, lengths, delimiters, hierarchies, and so on. Users followed practices as they saw fit; the closest thing to a standard was the familiar comma-separated-value (CSV) format. Even CSV files vary a good deal. If you doubt it, try to import one into a spreadsheet program and notice all of the options available.

Virtually anyone who has done programming for the enterprise, web, or mobile markets in recent years has encountered XML. It is just about everywhere you look.

An XML document has a recognizable structure: a series of elements that can optionally contain attributes and child elements. Every valid XML document begins with a declaration on the first line: <?xml version="1.0" encoding="utf-8"?>. What comes after the first line is application-dependent. The beauty of XML is that it is self-describing.

XML schemas

Although XML documents are self-describing, they must follow certain rules and guidelines. This is where the XML schema comes in. It is a document that describes the structure of a particular XML file. Such structures are often verbose and complex. (Arguably, XML's worst contribution to the IT field is the data explosion that took place once the idea of highly descriptive data structures came into fashion, fueled in part by the greatly reduced cost of disk-storage technology in the past decade.)

As these large and complex files became more the norm, the art of working on them manually was often a nonstarter for programmers and analysts. To address this issue, XML editors and validating tools became available to aid in the management of the files and the tasks relating to them, such as documentation and conversion to legacy formats.

In addition to general text data, XML can also be used to store binary data through a special set of tags known as CDATA. CDATA tags within an XML document can contain any kind of data, including other mark-up text, provided that text does not contain CDATA itself.

It's not uncommon for APIs to leverage this capability by using XML as a structure for performing request/response queries. Often the response data contains an XML structure contained within a CDATA tag. For example, an API call might request a customer record with a last name equaling Mott. When the data is found, it is packaged into an XML structure and placed within the response element, as in Listing 1:

Listing 1. Packaging data into an XML structure and placing it within the response element

XML in the workplace

Today XML is the default, expected data format. Although the same data might be available in other formats too, it is a safe bet to plan on the availability of an XML structure.

Enterprise Resource Planning (ERP) packages use XML heavily for data import and export
tasks. Internet news sites often make data available as Really Simple Syndication
(RSS) feeds—XML documents with a predefined format that news readers are set
up to process. Even word-processing applications such as OpenOffice.org and
Microsoft® Office use XML.

Today's Microsoft Office documents are PKZIP-compatible files containing multiple XML documents.
Each XML file shares the common declaration in the first line. As you can see in Listing 2, the attributes can be somewhat hard to follow:

XML is self-describing, but that doesn't mean that the tags are necessarily easy to decipher. This cryptic example also demonstrates the use of multiple XML namespaces, which can make XML documents even more challenging to follow without specialized tools.

XML is everywhere, but it can often be a poor choice for an Android programmer, particularly if the data structure has fallen victim to the data explosion often associated with XML structures. A resource-constrained platform such as Android, which is usually working on a cellular data network, cannot store and parse massive amounts of XML data. However, if a particular programming task requires the interchange of both text and binary data, XML can be a solid choice.

JSON: New kid on the Net

More and more Internet API providers are offering JSON as a data-format option. JSON
made a name for itself in the Ajax (Asynchronous JavaScript and XML) web-programming community. Ajax technology enables web pages to update dynamically by refreshing data in selected pockets rather the entire page. Because less data is transferred—and, more important, because much less data is parsed and drawn to the browser window—an Ajax-enabled application can provide a much better user experience than a traditional web application. In fact, a well-written Ajax application can rival smart- or fat-client applications in user experience.

When an Ajax application exchanges data with a web server, it is often requesting a refresh of some kind of data, but ideally without the formatting. It is generally considered poor practice for a web server to serve up preformatted HTML. Instead, a well-written application should send data content to the browser and apply a Cascading Style Sheets (CSS) file to provide visual effects such as colors and font particulars.

Suppose an application wants to request a contact record for our mythical Mr. Mott. The
application has more than one data element to send back to the browser. So how does it
get packaged? In the Listing 1 example, you might use a simple request/response structure in XML. This is perfectly adequate; however, it requires that you parse each response from the server, store the data in a structure of some sort (a DOM), and then update the web-page content.

Alternatively, you can simply get some JavaScript back from the server and work directly with it. Here is a sample response from a hypothetical application responding to a query (http://<yourserver/app/searchcontact?Mott) for a man named Mott. The response is a string representation of a JavaScript object—that is, a JSON string (split into two lines here to fit this article's page width):

Whereas XML is known for its verbosity, JSON has a reputation for being somewhat hard to read. JSON objects are constructed in a key:value pair format. The object's elements are separated by commas, and each object is contained within curly braces {}. An array of objects is contained within square brackets. This is a common approach to transferring a series of rows from a database to an array of objects in which each array element corresponds to a database row, and each property of the object represents a column of data.

Listing 3 shows an example of using this kind of object within an HTML page. For simplicity, the server communications are not included; instead, the JSON data is provided as a string variable named serverresponse.

Note that this example uses the JavaScript function named eval() to turn a string into a JavaScript array. JSON libraries are available to provide faster and more secure methods of performing this step. The approach in Listing 3 is not a best practice. I provide it here to give some context to how a JSON object can be used in an Ajax application: The JSON structure is exchanged, parsed, and manipulated by the client code.

In summary, JSON is:

A data-interchange format.

A means to encode JavaScript objects as strings.

Limited to text and numeric values. Binary values are explicitly not permitted. JSON has no CDATA equivalent.

More economical than XML in terms of data size, at the expense of readability.

Increasingly available as an option from API providers such as Twitter.

In Listing 3 the client is a web browser running client-side scripting. Returning to this article's focus, next you'll examine the use of XML and JSON in an Android application.

Application opportunity: Twitter feeds

Twitter has become an international force, providing updates on everything from what people are having for breakfast and how their kid's sports team is faring at the ballpark, to serious topics such as street-level updates on political revolts in closed nations or a play-by-play of an organ transplant.

The easiest way to get to get the XML and JSON documents to use with the sample code accompanying this article is through the URL http://twitter.com/statuses/user_timeline/userid.format, where userid is your own Twitter user ID and format is either XML or JSON.

You can also find a link to this page directly on your Twitter page, as in Figure 1. You can see your Twitter user ID there.

Figure 1. Link to feeds page on your Twitter page

The complete feed files are very verbose, so the next two listings show only the first entry of the feed (from my own Twitter account). Listing 4 contains the XML snippet:

Notice how much extra data is included in both listings beyond the mere status update. All you need to care about is the date/time when the post was made and the text from the post itself. Next I'll show you the pertinent portions of an Android application that parses this data. The full project is available for download.

The XMLvsJSON application

Real-world real-time updates

Note that the sample application does not pull the data in real time from the web, though that would be the expectation for a real-world application. The data feeds are taken out of the raw resources folder so the application can focus on the parsing aspects. See Resources for links to information on making network connections with Android.

The Android application is simple. It contains full copies of the XML and JSON data
feeds and gives the user the option of parsing either one. Figure 2
shows the structure of the project files within Eclipse. (View a text-only version of Figure 2.)

Figure 2. File structure of the Eclipse project

Figure 3 shows the application's UI prior to the selection of a parsing option:

Figure 3. The application's UI prior to selection of a parsing option

The application UI shows two buttons, Parse XML and Parse JSON file, followed by
default text. Listing 6 contains the layout for this UI, found in
the main.xml file in the res/layout folder of the project:

The Parse XML and Parse JSON file buttons are defined above a ScrollView, which in turn contains a TextView control. The idea here is that you want the user to be able to scroll through the resulting data.

Note the use of multiple LinearLayout structures. The first is a vertical alignment, and it contains both a LinearLayout with a horizontal structure and a ScrollView. The inner LinearLayout contains the two Button widgets. This layout is inflated and wired up in the onCreate() method, in Listing 7:

XML parsing

SAX versus DOM

Android also supports a DOM parser, which requires a larger memory footprint but reduces some of the complexity found in the SAX parser. For an application such as XMLvsJSON, which is only interested in a very small subset of a large data feed, the SAX approach is likely the better tool for the job.

Parsing of XML data is often done with a SAX-style parser. With this style of parser, you set up an InputSource pointing to the source XML data and provide a handler that receives certain events as the document is "walked." Listing 8 shows the examineXMLFile() method, which takes care of the following tasks:

Sets up the InputSource with the XML file from the raw resources

Creates a SAXParser, associated with a handler named twitterFeedHandler ( in Listing 9)

Invokes the parser and displays the results in a TextView widget identified in the layout file as R.id.txtData and referenced in the code as tvData

Whereas examineXMLFile() sets things up, the real parsing
work from the perspective of the application takes place in the handler that's implemented in the twitterFeedHandler.java file. This class, which implements the DefaultHandler interface, is in Listing 9:

Listing 9 contains some noteworthy items. The first thing to consider is that the SAX parser is an event-based parser, which means that you build the actual document as it is parsed. Events are fired whenever the document starts, the document ends, a tag starts, a tag ends, and data is found. This implies that you must define a data structure to keep the data of interest and discard the rest.

Note the StringBuilder and the appending of data, used because a particular data element can be processed across multiple reads on the InputSource. Never assume that all of the data is provided in any given call to the characters() method.

This application collects the data into a simply formatted string. An alternative example might include putting these entries into a collection class or database instead, particularly if a great deal of manipulation were to take place after the parse.

The getResults() method is custom to this class. It's used to gather the assembled representation of this data and provide it to the application. It is not part of the DefaultHandler's interface.

Figure 4. The parsed XML data

Although parsing XML with the SAX parser is nontrivial in terms of building up, managing, and navigating the resulting structure, its main advantages are speed and the opportunity to reduce significantly the amount of RAM required both during and after the parsing step.

JSON parsing

Parsing JSON data in the application starts when the user selects the JSON button. This invokes the examineJSONFile() method, in Listing 10. No additional handler class is required, because all parsing and document management take place within the Android-supplied libraries, and all JSON-related code is contained in this method.

Like the XML routine shown previously, this code reads in a file from the raw resources. The data is read into memory in its entirety, converted to a java.lang.String, and then parsed into a JSONArray. Note that a particular string can be parsed directly into an array, as in this example, or the string can be parsed into a JSONObject. Because the Twitter data is an array of objects, it makes sense to parse the entire string into an array and then access the object individually by ordinal position.

This method's flow is straightforward; once the data is parsed, the code builds up a
string representation that's similar to the approach of the XML parser handler. Of interest here is that the data is managed for you; you don't need to build up additional memory structures to contain the data. Likewise, the application knows up front just how many entries are in the JSONArray (20 in this example).

Although JSON parsing is much more simple programmatically, it is not cost-free. It adds the burden of memory consumption for reading in the entire data stream before it can be worked on, and for storing all of the data. In contrast, the SAX XML approach uses only the data of interest. That caveat aside, if memory for parsing a particular JSON object is ample, this approach can be favorable for many applications, particularly if working with the DOM is of little interest.

Conclusion

Other articles in this series

This article introduced XML and JSON data-interchange formats in the context of an Android application. Compared to the JSON approach, the XML approach is somewhat faster and less memory-constrained—at the expense of additional complexity. In Part 2, I'll introduce some advanced techniques combining JSON data, WebKit-based WebView widgets, and custom dynamic application logic for Android applications.

The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.