The document discusses design patterns for distributed mobile applications, particularly focusing on iPhone development for enterprise use. It covers key patterns like simple and authenticated REST consumers, lightweight network status monitoring, remote invocation with push responses, and an XMPP coordinator stream. The presentation emphasizes the need for these patterns to address current enterprise features and enhance mobile application enablement.

1. Design Patterns For Distributed
Mobile Applications
Jason H Christensen
Intelligence In Motion Partners, LLC
iPhone Developer Summit West, 2009

2. What We’ll Cover

Why Distributed Mobile Patterns

Simple REST Consumer

Authenticated REST Consumer

Key Handling Pattern

XMPP Coordinator Stream Pattern

Remote Invocation Push Response Pattern

3. Enterprise Mobile Architectures Timeline

4. Why Distributed Mobile Architectures
Corporateers are leaving their laptops at their desk.
iPhone in the Enterprise has made some noise, but
Blackberry is entrenched due to existing apps.
iPhone has to create key advantages to become more
competitive in the enterprise space.
iPhone has some key disadvantages, limited carrier
options, new programming language, “data walking
off”

5. Which Distributed Mobile Architectures
Some key areas to target for Mobile Enterprise
Applications
 Sales Force/Remote Management
 Sales, Store Mgr, Distribution
 Executive Information Systems
 Dashboard and Alerts
 Workflow Engagement
 Legal, Purchasing, Receiving
 Customer Issue Resolution
 Escalations/Technical Support

6. Enter Distributed Mobile Patterns
The First Five Distributed Mobile Patterns address
some hot button current enterprise features:
 Connecting to internal services
 Simple REST Consumer
 Connecting to cloud
 Secure Key Handling Pattern
 Authenticated REST Consumer
 Workflow Integration
 Remote Invocation/Push Response
 XMPP Coordinator Stream Pattern

7. Simple REST Consumer Pattern
Intent
To provide a quick and easy mobile REST implementation
Motivation:
There are numerous requests where we create a proof of concept.
The motivation is to keep the client and server as simple as
possible to show we can deliver on the crux of a given need.
Consequences:
Ideal for getting a RESTful system setup quickly, but…

Does not handle custom headers, or authentication

Trivial Systems only, Systems that contain sensitive functionality
or information should use the “Authenticated REST Consumer”
pattern.

8. Simple REST Consumer(iPhone)
KeyStrings
enum ExpectedTags +kElementName1,…
From didStartElement:
SimpleRESTCall if(currentElement == kElementName){
-initWithFormattedURL:(NSString*)fUrl currentTag = enumForThatTag;
andParameters:(NSDictionary*)params
}
- parser:didStartElement:
- parser:didEndElement:
- parser:foundCharacters:
- (NSObject*)getData
MyRESTCall
Concrete Consumer

9. Authenticated REST Consumer Pattern
Intent
To provide a common framework for federated identity RESTful
services.
Motivation:
This pattern is used in systems that require manipulation of the
“Authorization” request header, based on headers. Eg:

Amazon AWS based invocations,

OAUTH invocations, and custom implementations
Consequences:
This is a generalized pattern, most systems use similar methods, but
the header combination or method for acquiring the token may
differ. To handle this, TokenManager and StringToSign are
implementation specific.

10. Authenticated REST Consumer(iPhone)
enum ExpectedTags AuthTokenGenerator
- TokenManager* request
KeyStrings - StringToSign* signatureString
+kElementName1,… -initWithRequest:(NSURLRequest*)fUrl;
- (NSString*)getAuthString
AuthenticatedRESTCall
- NSMutableURLRequest* request
- NSHTTPURLResponse* response
-AuthTokenGenerator* authTokenGen;
-initWithFormattedURL:(NSString*)fUrl TokenManager StringToSign
andParameters:(NSDictionary*)params -initWithRequest:
- parser:didStartElement: (NSURLRequest*)fURL
- parser:didEndElement:
- parser:foundCharacters:
- (NSObject*)getData
AuthSpecific AuthSpecific
TokenMgr StringToSign
MyAuthenticatedRESTCall

11. Lightweight Network Status Monitor
Intent:
Provide a lightweight status mechanism to all applications in a
standard fashion
Motivation:
A mobile application can have a number of connection types, not
connected, keeping note of this status allows communication to
the user when connectivity changes.
Consequences:
This is a very simple pattern, and probably could be implemented
inline just as easily. The goal of this pattern is the use of a
delegate pattern to notify application when statuses change.

12. Lightweight Network Status Pattern
enum
ConnectionType LwNetStatusDelegate
-notify:(enum ConnectionType) presentType;
NetworkStatusMonitor
- ConnectionType* ct
- NSArray* delegates
-checkNetStatusAndTypeFor:(NSString*) net
- notifyDelegates
AppDelegate

13. Remote Invocation Push Resopnse
Intent
To provide notifications from workflow systems to a mobile user
Motivation:
Needed to provide a workflow step an acknowledgement, response,
or notification.
Push notification is more resilient for verifications, app can close or
be interrupted and the push will still be received.
Consequences:
There is additional cost and security considerations with this over a
traditional email response. Email is a valid alternative, but does
not notify the user directly.

14. Remote Invocation/Push Response (iPhone)
iPhone Application sendDeviceToken Web Application
initPushFunctions newDeviceListener
HTTP Request
AuthenticatedRESTAsynch
HTTP Response
ServerListener
QueueRequest
ProcessingQueue

15. Remote Invocation/Push Response (iPhone)
iPhone Application Web Application
ServerProcess
Processing
Complete
didFinishLaunchingWithOptions sendResponseID
pushBinaryResponse
didReceiveRemoteNotification
HTTP Request
AuthenticatedRESTPayload
HTTP Response
ServerListener

16. XMPP Coordinator Stream Pattern
Intent
Utilize a standard messaging protocol as a baseline for higher level
messaging functionality
Motivation:
This was kind of a eureka moment, but we were stuck trying to find
a way to bridge between J2EE based MOM and our Mobile Apps.
We decided to create a listener on the XMPP port and to use that
to bridge with the phone.
Consequences:
There is additional cost and security considerations with this over a
traditional email response. Email is a valued alternative, but does
not notify the user directly.

17. XMPP Coordinator Stream Pattern
iPhone XMPP
presence:
Application show Server
initXMPP xmppListener
group invite xmppListener
Group::init rsrc1@coordsvr
Group:<coordid>
Activity::Enlist CoordMsg xmppListener
Activity::Perform CheckStatus xmppListener
Activity::Complete Close xmppListener

18. XMPP Coordinator Notes

Each resource enlists on it’s own

We create a group for a set of resources

Messages and responses are sent to the
group

Any phase can fail causing a compelete
failure

Since group, all failures are seen by each resource

19. Distributed Mobile Design Patterns

What we covered:
 Enterprise Mobile History
 What spaces are hot for enterprise mobile
 Five patterns for Mobile App enablement
 XMPP Coordinator Stream
 Remote Invocation/Push Response
 Lightweight Network Status
 Authenticated REST Requests
 Simple REST Request

20. Questions?

Feel free to contact me:
Jason H Christensen
jason_h_christensen@jasonc411.com
Slideshare: jasonc411
Twitter: jasonc411
http://jasonc411.com