This slide deck was presented at iPhone Developer Summit East on June 22, 2009. It covers a new archetype that uses ReSTful Web-Services and Cloud Computing to extend the functionality of Context-Aware mobile applications. Enjoy! Jason http://jasonc411.com On twitter: http://www.twitter.com/jasonc411

1. Combining REST and Context for
Killer iPhone Apps
Iphone Developer Summit
22.June.2009
Jason Hayes Christensen
jasonc411.com

2. Intro
● Mobile Applications Entered a New
Frontier
● New Platforms like the iPhone are:
● ALWAYS Connected
– 3G, WiFi, Bluetooth
● ALWAYS On
– Very rarely do I shut my phone off
● ALWAYS Around
– I almost always have my phone with me, can't say
the same for my laptop.

3. Outline
● Technical Convergence
● REST,Cloud,3G
● Mobile Apps Tetrahedron
● With Cloud Enhancements
● Whats in the cloud
● Get Some “Good REST”
● Context And the iPhone
● An iPhone in the Cloud
● Code Examples throughout
● Summary

4. Technical Convergence
● What happened In the last few Years
Opened up a new software archetype.
1. The advent of continuous connectivity
using 3G and WiFi
2. The advent of easily invoked and
consumed RESTful web-services
3. the ability to leverage off-device
processing, storage, and security through
cloud computing.
● this convergent set of technologies
becomes a novel, powerful archetype
for mobile architectures.

6. Protect User-Info
● RESTful web-
services over SSL
● No Clear Text
Passwords
● Security is the ● OpenID in the
base of the Cloud as Best
Tetrahedron Practice
● Security touches ● Limit On-Device
all other aspects. User Data

7. ● Variable in a number of ways
● Connected?
● Speed?
● Program Defensively for the
Network(especially for REST)
● Check Connectivity & Speed.
● Have a Local Option.
● Make sure to Balance
– Request Frequency/Payload
Size.

8. ● Cloud Options for
Processing
● Custom(your own),
i.e. intelligent mobile
game engine scenario
stack.
● Amazon EC2
● Processing is ● Amazon Elastic
Constrained MapReduce intensive
processes.
● Perfect for Cloud ● Others...
● Off-host analytical or
intensive tasks

9. ● Consider:Memory or Storage?
● Memory is an on-device issue
● Storage can be augmented
with cloud
● Database: Amazon SimpleDB,
Google Database, Apple Mobile
Me, …
● Content: Amazon S3, Amazon
Cloudfront, Mobile Me, …
● Synchronization: Amazon SQS,
Asynchronous Process then
Push technologies.

11. Get Some “Good REST”
● What is “Good REST”?
● balance Request Frequency and Payload
● Request Frequency
● Make requests infrequently
– Extends battery life
– Minimizes network exposure
● Payload
● Large requests are hard to process
– Memory is only so large
– Processing takes time and battery

12. Rest Simple to Complex
● Google Apps for the most part have
simple REST APIs
● No Authentication or Simple Authentication
● Apple is providing wrappers for exposed
services such as geocaching.
● Simple REST Services are GREAT look at this
invocation for Geocoding.

13. Simpler and Simpler
● Apple has started wrapping Google APIs
for geocoding with MKReverseGeocoder.
- Switching to XCode...

14. On the Other Side we have
Amazon Web-Services
● Has a complex authentication scheme.
● Request dependent
● Involves hashing(HMAC-SHA1) and
encoding headers, then adding
additional headers to the request.

15. Creating the Authorization
Token
● Sign up for S3, you will get a public and
private key.
● Create a string from the following
headers, then create and encode hash:
StringToSign = HTTP-VERB + "n" +
Content-MD5 + "n" +
Content-Type + "n" +
Expires + "n" +
CanonicalizedAmzHeaders +
CanonicalizedResource; // /bucket/resource

16. Processing the Response
● REST is nice because each response is
discrete(unlike streaming socket as in
XMPP)
● NSXMLParser is lightweight
● Can initialize with the data from a request,
or with the request directly.(note S3ListBucketsResponse
extends NSXMLParser)

17. Managing State
● didStartElement
● Set fags if you want to gather data
● Grab any attributes from the
attributeDictionary
● didEndElement
● Reset fags as necessary
● foundCharacters
● Grab any enclosed text as necessary

18. Example from Geocoding

19. Context and the iPhone
● Iphone has three sensors that can be
used for context:
● GPS/Core Location
● Accelerometer
● Proximity Sensor
● A Context-Aware Application will use
those sensors to minimize user input.
● Additional context can be ascertained
from your present activity.
● Upcoming, audio and visual contexts are
coming. Think augmented spatial reality.

20. The future of Contexts
● We looked at this earlier in the simple
example of MKReverseGeocode.
● Location is low hanging fruit, that is
why there is SO much focus on LBS.
● LBS is a context aware application
● Future contexts include activity
analysis using bluetooth, camera, …

21. What We Looked At
● Amazon S3 using rest based web-services
to store fles(menus, photos.)
● Location information from the iPhone.
● REST for geocoded context(GPS<-
>Street Address)
● No expensive servers because of cloud
computing.
● This archetype can be solved for
numerous apps.

22. Questions?
THANKS FOR ATTENDING
Source code available at
http://jasonc411.com