interoperability in cloud and mobile apps

1. Doh! interoperabilityin cloud and mobile apps http://www.flickr.com/photos/johanl/4934459020

2. What is interoperability? • The software can exchange data with other systems to provide benefits to users. • Examples: • Your app consumes data from other servers • Your app sends data to other servers • Your app does the same with other mobile apps

3. Limited standards are available • Recurring theme throughout this lecture • Most "standards" are actually ad hoc: one system did it a certain way, and others copy that way of doing it, for compatibility • For the most part, interoperability requires integration through platform-specific APIs • But expect more standards over time!

4. Example of such a standard: CDMI • Cloud Data Management Interface (CDMI) • Specifies an API that a server must implement so that remote clients can store, retrieve, and manage data via web services (http calls) • Conceptually fairly similar to S3 (though S3 doesn't currently implement CDMI per se)

5. Example of a CDMI callNotice the JSON & special headers PUT /MyContainer/MyDataObject.txt HTTP/1.1 Host: cloud.example.com Accept: application/cdmi-object Content-Type: application/cdmi-object X-CDMI-Specification-Version: 1.0.2 { "mimetype" : "text/plain", "metadata" : { }, "value" : "This is the Value of this Data Object" }

6. CDMI status • Proposed by Storage Networking Industry Association (an industry consortium) • Approved by International Organization for Standardization (ISO), as of 10/2012 • Not currently provided by GAE or AWS • Probably could implement it yourself • Which would be a ton of work • You could probably import their "reference implementation" as a 3rd party library. • You'd still need to implement a bunch of Java interfaces.

7. Even worse situation in mobile… • There is no platform-independent standard for interoperating with other apps • E.g., for sending an email or text message, regardless of whether you're on iOS or Android • E.g., for retrieving the list of contacts in a person's contact-management app • E.g., for creating and reading events from the user's favorite calendar app

8. What to expect • Widely-adopted standards only cover a small slice of app functionality • E.g., authentication or data transfer • When no standards exist, interoperability requires sacrificing some portability

9. Examples of "narrow-slice" standards for interoperability • oAuth: a standard for authenticating users • JSON: a standard for formatting data • http multipart/form-data post: for uploading binary data

10. oAuth overview http://upload.wikimedia.org/wikipedia/commons/3/32/OpenIDvs.Pseudo-AuthenticationusingOAuth.svg

11. Example: Flickr • Authenticating with oAuth • You get an app id; your app directs user to log into Flickr; Flickr provides your app with a token • Data are exchanged in a JSON format • Posting images • File upload (multipart/form-data) • Retrieving images • Send a query, receive and parse JSON, do a GET for the actual image • http://www.flickr.com/services/api/

12. Example: Facebook • Authenticating with oAuth • You get an app id; your app directs user to log into Facebook; user reviews permissions requested by the app; Facebook grants your app a token • Data are exchanged in a JSON format • Posting to Facebook • Post to a specific URL corresponding to user's wall; pass a JSON object • Retrieving data about users • Perform a get request, parse the JSON reply • https://developers.facebook.com/docs/reference/api/

13. Example: Twitter • Authenticating with oAuth • You get an app id; your app directs user to log into Twitter; Twitter provides your app with a token • Data are exchanged in a JSON format • Posting a tweet • Yep, JSON • Retrieving tweets • Yep, JSON • https://dev.twitter.com/docs/api

14. A few of the current oAuth service providers (from Wikipedia) • AllPlayers.com, Bitbucket, bitly, ciValidator, cosm, Deviantart, Dropbox, Evernote, Facebook, Flickr, Formstack, Foursquare, GitHub, Google, Google App Engine, HnyB.me, Huddle, Instagram, LinkedIn, Microsoft (Hotmail, Windows Live, Messenger, Xbox), Mixi, MySpace, Netflix, OpenLink Data Spaces, OpenTable, PayPal, Plurk, RealPeepz, Reddit, Salesforce.com, SinaWeibo, StatusNet, Stripe.com, Tent.io, Tumblr, Twitter, Ubuntu One, Veevop, Viadeo, Vimeo, VK, Xero, XING, Yahoo!, Yammer, Yandex, Yelp

15. But where is oAuth going? • oAuth 1.0 is widely deployed, oAuth 2.0 is standardized and now deploying • But oAuth 2.0 is more complicated • Takes a long series of steps to complete • And is a hassle to implement (as a client) unless you're creating a web app (e.g., mobile web app)

16. And it wouldn't be surprising to see if a new standard takes oAuth's place • EranHammer (one of the oAuth 1.0 spec authors): "They say the road to hell is paved with good intentions. Well, that’s OAuth 2.0." • Tim Bray (one of the XML spec authors): "oAuth2 and friends is way too hard for developers; there need to be better tools and services." • Ian Hickson (one of the CSS 2.1 spec authors): "I ended up getting my name removed from that spec [oAuth 2.0] too. What a disaster" http://news.cnet.com/8301-1023_3-57481166-93/oauth-2.0-leader-resigns-says-standard-is-bad/ http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/

17. What can we take away from this? • Something like oAuth is likely to remain • Your app will need to have a registered id • Your user will need to authenticate • The remote service will grant your app a token • JSON will likely be the dominant way to exchange data for years to come

18. Shifting focus to integration with other mobile functionality (apps & operating sys) • No cross-platform standards • Options: • Use a platform-independent approach such as Titanium, and accept limited integration • Use a platform-specific approach such as Java/Android SDK, and accept limited portability • Since you know about Option 1 already, let's focus for a while on Option 2.

19. Android "Intent": The intention to do something • Examples: • The intent to send an email • The intent to show an activity (window), particularly in another application • The intent to retrieve a contact from a contacts book app • Etc

20. Example: Sending an email • Basic steps • Construct an Intent object • Fill in the extra parameters of the Intent • Tell the operating system to handle the Intent • Potentially let the user choose among different apps, if multiple apps are installed that can handle the Intent (such as multiple email programs)

21. Example: Sending an email // Note: Intent.ACTION_SEND is a string that indicates to the // Android operating system that we want to send an email Intent emailIntent = new Intent(Intent.ACTION_SEND); emailIntent.setType(HTTP.PLAIN_TEXT_TYPE); emailIntent.putExtra(Intent.EXTRA_EMAIL, new String[] {"to@example.com"}); emailIntent.putExtra(Intent.EXTRA_SUBJECT, "Subject"); emailIntent.putExtra(Intent.EXTRA_TEXT, "My message"); startActivity(Intent.createChooser(emailIntent, "Email"));

22. Example: Posting to a calendar Intent calIntent= new Intent(Intent.ACTION_INSERT, Events.CONTENT_URI); Calendar beginTime = Calendar.getInstance().set(2013, 0, 12, 7, 15); Calendar endTime = Calendar.getInstance().set(2013, 0, 12, 8, 30); calIntent.putExtra(CalendarContract.EXTRA_EVENT_BEGIN_TIME, beginTime.getTimeInMillis()); calIntent.putExtra(CalendarContract.EXTRA_EVENT_END_TIME, endTime.getTimeInMillis()); calIntent.putExtra(Events.TITLE, "The title"); calIntent.putExtra(Events.EVENT_LOCATION, "The place"); startActivity(Intent.createChooser(intent , "Calendar"));

23. Example: Placing a phone call • Very similar but simpler: Uri number = Uri.parse("tel:8885551212"); Intent intent = new Intent(Intent.ACTION_DIAL, number); startActivity(Intent.createChooser(intent , "Phone"));

24. Handling intents in your own app • You can declare that your app is willing to handle Intents started by other apps • Basic steps: • In your AndroidManifest.xml file, declare what intents you can handle (identified with a string) • In your code, implement the code to handle the intent • Optionally, return a result to the caller (depending on what kind of Intent you want to implement) • See Chapter 2 of your textbook for details

25. What about iOS • There is no "Intent" in iOS • Instead, URL Schemes are used • For example, apps are registered as being able to handle specific URLs (e.g., "readtext://…" or "mailto://...") • Other apps can then open those URLs • Some support for passing data between apps • For Titanium tips, see https://developer.appcelerator.com/question/120393/

26. Bottom line • Integration with remote servers • Primarily with JSON + oAuth or something similar • And/or XML-based schemes for a while • Integration with other mobile apps • Primarily through a string-based naming scheme (Intent identifier or URL scheme)