A colleague of mine, Jack Cox, wrote an article recently about managing complex mobile transactions.  The article is written with an iOS slant but I found it very interesting and wondered if the paradigm could be implemented in Android and whether it could be effective.  After sitting down and doing some brain storming, I realized the pattern lent itself very well to Android.

In conversations with clients, we continue to hear how important single sign-on is to their enterprise mobile application strategy. According to a study earlier this year by Kelton Research 250 IT Managers, 21% of respondents indicated that they plan to deploy 20, or more, enterprise applications to their organization this year.

In order for enterprises to realize the productivity gains factored into the investment decisions for those applications, IT Managers must explore options for enabling single sign-on for their users. In this post, we'll outline a mobile single sign-on (mSSO) pattern for enterprise iOS applications.

When Apple added cut/copy/paste support in iOS 3.0, it also provided developers the ability to customize the popover menu via UIMenuController. Unfortunately, that initial implementation required non-trivial preparations by developers just to change the menu:

JSON has taken the data-interchange world by storm with its' lightweight, easy to understand format. The explosion of mobile apps, and their consumption of network based data, helped fuel JSON's growth. CapTech's recommended approach for web services utilizes JSON as the interchange format.

While JSON has been around for several years - RFC4627 was published in July of 2006 - working with JSON in an iOS project required that you download one of the many frameworks and integrate it into your project. My personal choice has been SBJSON - https://github.com/stig/json-framework.

Every iOS app should be thoroughly tested in a variety of network conditions, from a high-bandwidth WiFi connection down to a data connection with a single measly bar of Edge or GPRS coverage. Finding a good connection is usually the easiest, you're almost guaranteed to have one at work or home, but reliably testing an intermittent or poor connection is much harder. The obvious way to do this is to take note of coverage dead spots as you go about your day and return to those locations to test the app, but that can be time consuming and unreliable. However, if you have Max OS X 10.7 you can simulate any network connection without even leaving your desk.

One of the really neat things that Google has done with all of its Android applications is that they all share a common authentication mechanism in Accounts and Sync. There is no need to enter your Google credentials for each Google based application on your device, which centralizes password changes to a single location. It also groups those common authentication applications together in the Accounts and Sync settings activity, as I'm sure everyone is familiar with:

After a couple of weeks organizing my thoughts, here’s my attempt to string together, in one run-on sentence, my key takeaways from the 2011 Forrester Content & Collaboration Forum:

Organizations should be striving to create an engaged workforce – which generates collaborative content containing mission critical knowledge worthy of harvesting – by strategically implementing an information workplace that seamlessly integrates the right combination of email, calendaring, intranet content, instant messaging, web conferencing, video conferencing, team sites, document management, wikis, blogs, microblogs, and the enterprise social network… and for the love of God, it better be mobile-enabled, and all else being equal, let’s put it in the cloud.

Now you know what you’re doing in 2012.

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. 

Abstract

Many enterprises are creating mobile applications for their internal staff, for their customers, or both.  These applications need access to data, business rules, and business processes.  For architectural and security reasons these applications are typically built to access remotes services that provide the data and functionality that are required by the users. 

Because many web applications have been built over the last decade using SOAP-based web services, many architects have made the assumption that these same SOAP-based services are the best choice for mobile applications.  We believe that the use of RESTful services, with data in JSON format is a better choice for mobile applications whether the client device technology is iOS, Android, Blackberry, or even Mobile Web.

In this white paper we look at the differences between SOAP and REST for use by mobile applications, analyze typical assumptions about them, and offer an a