Introduction

In this blog article I follow-up a previous article on Managing Complex Mobile Transactions with a simple working example written in Objective-C for the iPhone. 

The previous article describes a pattern for managing the complex error conditions that may occur.  This article provides an example of calling an authenticated service from YouTube.  In this type of communication there are a number of failure modes that need to be considered. 

Problem statement 

Network communications from an iOS device are easy, but handling errors on those connections is not. As an app developer I like to see results quickly and leave the edge condition details till later so I quickly wire in network operations and plan on handling all of the error conditions later. For web applications I can usually get away with this approach because the network connectivity from a stationary laptop is mostly reliable.  In a mobile app this approach will get me in trouble. When I do get around to adding exception handling routines I end up in a situation where I need to refactor my network code significantly or hack in less than optimal approaches to handle exceptions. 

Gartner predicts that 30% of all BI will be consumed on mobile devices by 2013.  With the amount of interest in mobile BI and those kinds of bold predictions you would think it would be easy to understand the options available.  It is not.  There are a lot of things to consider when deciding what mobile BI tool and operating system fits for your organization:

A few months ago I attended a presentation at MicroStrategy which focused on their Mobile product.  The class highlighted how information can be presented on iPhones and iPads in very useful and flexible ways, but one section of the presentation really sparked my interest.  It showed the usage growth of the various technologies as they become current: 

If these figures are to be believed, and I suspect they’re pretty close, then the evolution is continuing and rapidly expanding towards less expensive, more portable and easy to use devices.  For our discussion, let’s assume that Mobile Internet computing consists of phones (iPhone, Android, Blackberry, etc.) and tablets (iPad almost exclusively at this time).

Lately, there has been a rush of activity around building native applications for the various mobile devices.  The latest explosion of activity started in 2008 with two events: Apple opened-up the iPhone to 3rd party development by releasing the iPhone SDK,  and Google released Android as open-source software.  In 2010, of course, Apple fanned the flames with the release of the iPad, and Microsoft Windows Phone 7 looks like it will be a strong platform for mobile device custom development.  But even before these events, there had been waves of popularity of mobile development coinciding with the rise of Blackberry and before that, Palm devices.  It even used to be the case that something didn't have to be a phone to be a mobile device.  But now that most mobile devices are network-capable and the bandwidth available to them has expanded dramatically, the question becomes, "Do we need discreet native mobile applications, or can a single web a

With the release of the Apple iPad and the associated iPhone SDK 3.2 there are a number of new features of the SDK.  This article provides a high level overview of those features.  At the current time, iPhone OS 3.2 is only available on the iPad, iPhone developers will have to wait for these features..

Google co-founder Sergey Brin was quoted (off the record) last fall as saying that “Android and Chrome will likely converge over time”.  (cnet)

Eric Schmidt (Google CEO) put it a little “differently” in an interview about the same time.  To paraphrase – Android is for phones and Chrome is for PC’s and netbooks and they don’t completely overlap. (phandroid)

So, let see here…

Introduction

This article follows previous articles on components for a RESTful iPhone application and an example RESTful service using Jersey (http://blogs.captechventures.com/blog/jack-cox/implementing-iphone-friendly-rest-service-jersey-spring-and-jaxb). This article walks through the iPhone application to display the data provided by the REST service.

This article provides a specific example, with code, of using Jersey and JAXB to implement a REST service suitable for consumption by an iPhone application.  It follows an earlier article (http://blogs.captechventures.com/blog/jack-cox/components-enterprise-iphone-restful-applications) in which I surveyed the components that can be used to create an iPhone application that consumes a REST service.

Components

Jersey

Jersey is an open source reference implementation of the JSR-311 (JAX-RS) specification provided by Sun.  In my client work with Jersey, it has proven to be a reliable and lightweight framework for providing REST endpoints and it integrates well with Spring, which will be shown later. 

Jersey is available from Sun at https://jersey.dev.java.net