Combining ReST and Context for Killer iPhone Apps

1,452 views

Published on

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

Published in: Technology, News & Politics
1 Comment
4 Likes
Statistics
Notes
No Downloads
Views
Total views
1,452
On SlideShare
0
From Embeds
0
Number of Embeds
62
Actions
Shares
0
Downloads
0
Comments
1
Likes
4
Embeds 0
No embeds

No notes for slide

Combining ReST and Context for Killer iPhone Apps

  1. 1. Combining REST and Context for Killer iPhone Apps Iphone Developer Summit 22.June.2009 Jason Hayes Christensen jasonc411.com
  2. 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. 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. 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.
  5. 5. 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
  6. 6. ● 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.
  7. 7. ● 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
  8. 8. ● 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.
  9. 9. 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
  10. 10. 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.
  11. 11. Simpler and Simpler ● Apple has started wrapping Google APIs for geocoding with MKReverseGeocoder. - Switching to XCode...
  12. 12. 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.
  13. 13. 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
  14. 14. 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)
  15. 15. 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
  16. 16. Example from Geocoding
  17. 17. 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.
  18. 18. 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, …
  19. 19. 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.
  20. 20. Questions? THANKS FOR ATTENDING Source code available at http://jasonc411.com

×