Incorporating Web Services in Mobile Applications.ppt

Document Sample
Incorporating Web Services in Mobile Applications.ppt Powered By Docstoc
Web Services in
April 3, 2009 – San Francisco
Slides available at
Web services and APIs of third parties referenced in this presentation
 are owned by the third parties and governed by their agreements.
 Before using any of the APIs or code referenced in this presentation
 review the terms of use by the third party providing the API.

These slides are available under the Creative Commons Attribution-
  Noncommercial-Share Alike 3.0 License. You can blog, photograph,
  and share this information with others.
Trademarks and brands are the property of their respective
                      Introduction - Convergence
‣ Available APIs are growing daily
 - Currently 1229 (and growing) APIs registered at Programmable Web
‣ Shifts in Consumer Expectations
 - Consumers now expect mobile devices to be connected to Internet
   Sites and Services
‣ Platform Development becoming easier and more standardized
 - iPhone SDK – Greater than 50,000 registered developers
 - Android – 5% of smart phone web usage in just three months1
‣ Seeing extension of enterprise applications to mobile devices

 1 Techcrunch, March 24, 2009, Erick Schonfeld
‣ Many Web Services and APIs were originally developed with server
  to server or server to browser in mind, not mobile applications
‣ Mobile platforms have their own set of challenges given:
 - Bandwidth
 - Memory and CPU Availability
                                            Web Service
 - Storage Capacity
 - Connectivity Options and Issues
 - Security
 - User Interaction and Display
                   API Developer Programs
‣ Is mobile access allowed?

        “5.1.5. Unless we have provided you our express written
        consent in advance, you are not permitted to use Amazon
        Associates Web Service in connection with any handheld,
        mobile or mobile phone application.”
                           From the Amazon Web ServicesTM Customer Agreement

‣ Other considerations:
 ‣ Call Limitations (# per second, total per hour/day, pricing above)
 ‣ Caching and Storage of Data
  ‣ Persistence of Data – Length of time stored
  ‣ Freshness of Data – Length of time before refreshing
                 Caching and Storage Limits
‣ Persistence Limitations

        -You may otherwise store Amazon Properties generally (other than
        pricing or availability information) for caching purposes for up to 24
        hours. However, you may store the following Amazon Properties for
        caching purposes for up to 1 month:…
                                      From the Amazon Web Services User Agreement

‣ Refreshing Requirements

         You must refresh and re-display any Amazon Properties (other than
         pricing or availability information) at least once every 24 hours or
         once every month, as applicable, by making a call to AWS and
         refreshing your Application’s contents immediately after the call.
                                       From the Amazon Web Services User Agreement
                       Application Verification
‣ Certification of your Mobile Application
         “If any of your Facebook Platform Applications are client-resident
         (including on a mobile device), you agree to furnish a copy of such
         Facebook Platform Applications and any supporting documentation
         upon request for the purpose of verifying your compliance with this
         Agreement; and …”
                                       From the Facebook Developer Terms of Service

‣ Some API sets require certification on top of distributor certification
 ‣ Determine Costs / Timeframe / Effort given a mobile app
 ‣ Prepare for testing – typically looking for error handling, API abuse
‣ Certification is a positive!
 ‣ Credibility, validation, marketing
 ‣ Keeps the neighborhood safe
            Authentication vs. Authorization
‣ The Difference
     Authentication from the API provider – API Key
     Authorization from the user – authToken
‣ Session Key
 - By providing combination of API Key and authToken can then
   receive the session key
 - What is the shelf life of the session key

‣ Authorization will commonly
  affect user’s experience on
  - eBay authentication and
    authorization screens
            - Sample Flow
‣ Get an API key
‣ Request auth – auth.getMobileSession
 - Inputs:
  - username
  - authToken (md5(username + md5(password)))
  - api_key
  - api_sig
‣ Returns session key
‣ Make API call with sk (session key)

‣ Note: Try to keep credentials in one area to facilitate later changes
‣ auth.getmobilesession

‣ Result with new session key

          <lfm status="ok”>

                             username (Required) : The username.
                             authToken (Required) : A 32-byte ASCII
                             hexadecimal MD5 hash of the user's
                             api_key (Required) : A API key.
                             api_sig (Required) : A method signature.
               – Call Execution
‣ Now we can make the call with our sk (session key) – user.getinfo…&sk=142c0…&api_sig=ccbd1
‣ Response             <lfm status="ok”>

        sk (Required) : The session key returned by auth.getMobileSession
        api_key (Required) : Your 32-character API key.
        api_sig (Required) : Your API method signature
                              Speed Traps
‣ Could be on wifi, 3G or 1G based signal and bandwidth
‣ Segment functionality / calls to prevent issues
 - Standard Apple test for approval is bandwidth usage when on cell
‣ Polling
 - Create subset of calls and functionality when on slower bandwidth
 - Use notifications if possible
 - Modify polling interval based on need
‣ Recovery from intermittent or lost connections
‣ Test the use of APIs via public vendor API test tools on various
                   Large Data Set Handling
‣ Decreasing returns for XML with large data sets and repetitive XML
‣ Even more the case with mobile devices given:
 - Communication challenges
 - Memory and processing limitations
‣ Minimize large data sets:
 - Use Just-in-Time (JIT) methodology
 - Ask for only those elements that you require
 - Ask for only those items that you require
 - Store what you can locally instead of requesting the same data
                         Response Processing
‣ Leverage Stream Parsing for mobile environments
- Provides low memory overhead
- But, requires more heavy lifting
‣ iPhone SDK based on stream parsing – NSXMLParser class
‣ Android has Xstream as the streaming parser

  Response                  Parse Stream            Display / Store

    • Minimize to just       • Stream Element         • Cache what
      what is needed           Based                    will be reused
                             • Sub parsing for          (file, db,
                               specific items           memory)
                                    iPhone Parsing
‣ NSXMLParser delegate methods
- 5 key methods

          Method                       Purpose
          parser:didStartElement:      Start of element tag occurred with attributes
          parser:foundCharacters:      Element data located which may be all or some
          parser:didEndElement:        End of element tag located
          parser:didEndDocument:       End of XML document occurred
          parser:parseErrorOccurred:   Unrecoverable parsing error occurred

  - Parser:didStartElement:
  - Parser:foundCharacters:
  - Parser:didEndElement:
  - Parser:didEndDocument:
  - Parser:parseErrorOccurred:
‣ Typical didStartElement, foundCharacters, and didEndElement
‣ In long parsing streams provide feedback
  when available
‣ Example: Control4 My House
 - Home control from your iTouch/iPhone
 - During initial project load describes the
   sections being processed
 - Stores those items that will not change
   including house devices
 - But when providing current data,
   requests from server current state
 - Blends stored information with real time
   status information to provide display
- Types of Request Filtering
 - Selection criteria for narrowing data set returned
- In general determine how efficient are the calls – reduce data waste
 - How much extra data, streaming, parsing is happening to access
   the data you use? How much data is being dropped on the floor?

            <?xml version="1.0" encoding="utf-8"?>
            <FindItemsAdvancedRequest xmlns="urn:ebay:apis:eBLBaseComponents">
             <!-- Standard Input Fields -->
             <MessageID> string </MessageID>
             <!-- Call-specific Input Fields -->
             <BidCountMax> int </BidCountMax>
             <BidCountMin> int </BidCountMin>
             <CategoryHistogramMaxChildren> int </CategoryHistogramMaxChildren>
             <CategoryHistogramMaxParents> int </CategoryHistogramMaxParents>
             <CategoryID> string </CategoryID>
             <CharityID> int </CharityID>
             <Condition> ItemConditionCodeType </Condition>
             <Currency> CurrencyCodeType </Currency>
             <ShippingLocation> CountryCodeType </ShippingLocation>
             <ShippingPostalCode> string </ShippingPostalCode>
             <SortOrder> SortOrderCodeType </SortOrder>
             <StoreName> string </StoreName>
             <StoreSearch> StoreSearchCodeType </StoreSearch>
‣ Provide paging functionality to users
‣ Not all calls have paging available
‣ Inform user of current location in set, easy access to next and
  previous if applicable
‣ Cache key information depending on
 - The user flow (detail page from results page)
 - The aging of the information (when does it expire)
                            Page Requests
  Specify the page that you are requesting
‣ How many items are on a page
 - Set the number of entries per page returned


     <?xml version="1.0" encoding="utf-8"?>
                           List Paging Example
‣ Must cache of course the
  current page
                                 <?xml version="1.0" encoding="utf-8"?>
‣ Remember though the              <FindItemsAdvancedResponse
  total pages can change         06T00:51:05.250Z</Timestamp>
  dynamically so check total        <Build>e525_core_APILW_4863605_R1</Build>
  pages after subsequent              <ItemArray>
  requests                               <ItemID>123000268897</ItemID>
<TotalItems> int </TotalItems>         <Item>
<TotalPages> int </TotalPages>           <EndTime>2009-07-
‣ Caching of information for future retrieval and navigation
 - Be careful of data aging depending on what is being shown
‣ Execute web service parsing and display in background when
  possible to prevent UI blocking
 - example – eBay item description and images
‣ When parsing large data blocks, progress indications can be provided
  from element name (sections of the XML)
‣ Synchronous versus Asynchronous calls
‣ Use JIT and Information on Demand to maximize small layouts and
  minimize web service calls
                         Caching Options
‣ To minimize API round trips leverage caching and storage
 - Cache in memory
 - Cache in onboard light weight database or file
 - Off device persistence

 Memory Cache                   Onboard                 Off Device
 • Memory Intensive         • Space Limitations     • Requires
 • Non-persistent           • Persistence             Connection
 • Eg. Data key for           across sessions       • Reuse across
   last viewed item         • Eg. User                users
                              Information           • Eg. Statistics,
                                                      look up tables
Expanding Your
                  Blending Multiple Results
‣ What if you have to:
                                        Mobile View      Mobile App       API Service
 - Blend results from multiple calls           Trigger
   in the same API
                                                                Request 1
 - Blend results from multiple API                                               Fulfill
‣ This could take the form of:                                        Result 1

 - Extra item information on top of
                                                                Request 2
   item details call

                                                                      Result 2

‣ Note this is simplified so does not
  show authentication and                             Outlet

  authorization checking, encoding,
  or the like.
                Blending Multiple Services
‣ Multiple Services
                           Mobile View      Mobile App     API Service      API Service
 - Dependent on multiple                                        1                2
                                                   Request 1
‣ Example:                                                        Fulfill

 - Weather request from
   additional WS based                               Result 1

   on zip code returned
   by latitude and                                 Request 2
   longitude from a                                                                Fulfill
   geoposition service
                                                     Result 2


                     Proxy Server Solution
‣ Provides layer of abstraction to consolidate or manage web services
‣ Proxy Server retrieves data on demand or on scheduled basis
‣ Allows for single consolidated call from the mobile device
‣ Processes data and returns subset or stores data for retrieval later

‣ Can also reduce API calls by caching similar results across user
‣ Allows for extending business logic layer
                            Proxy Flow
‣ Provides for single
                            Mobile View      Mobile App       Proxy           API
  round trip for mobile                                       Server        Services
  application                      Trigger

‣ Provides easy
  maintenance of web                                              Request
  services business logic                                                        Fulfill
‣ Easily modify                                                    Result

 - Business logic                                                                Fulfill
 - API credentials

         Proxy Landscape

Web Service            Web Service

              Proxy Server
Designing your
WS/API Destiny
                      Creating Web Services
‣ Try to serve lowest common device
‣ Balance flexibility with overhead in calls:
 - Filtering of criteria and paging of data functionality
 - Split out high traffic calls versus critical requests
 - Easy but secure authentication and authorization for both the
   consumer and application
‣ Benefit for mobile consumers, application programmers and web
  service providers
 - Decreased round trips
 - Increased efficiency of calls and applications
 - Better use of call volume restrictions
 - User experience improves
                                   Wrap Up
Provide user preference options that translate into better tuned API calls
   - number of items to show on a page as an example
 This will translate to data efficiency, fewer callers and greater use of
   data retrieved
 Minimize the number of trips, combine in single calls when possible
 Leverage caching and data storage when allowed
 Balance data granularity with length of returns for parsing

Final thought to ponder
  The mobile device that is typically serving as a web service client
  could in the now or future be a web service provider…
Thank you
Slides available at:

                   Chuck Hudson

                 Appendix A - Resources
‣ API / Web Service Online Catalogues

- Programmable Web

- Web Service List
                 Appendix B – Code Resources
-       iPhone URL Connections
-       iPhone Rest Wrapper
    -    i
-       iPhone XML Parsing – Cocoa Stream Parser
-       SOAP with iPhone examples
-       Façade Server landscape – O’REILLY – Windows platform
-       Connecting to Web Services – Sean Sullivan
               Appendix C - Efficient XML Interchange (EXI)

‣ W3C Working Draft 19 September 2008 -
‣ “EXI is a very compact representation for the Extensible Markup
  Language (XML) Information Set that is intended to simultaneously
  optimize performance and the utilization of computational resources.”
‣ Components of XML Complexity
     1. size
     2. total number of elements
     3. number of unique elements
     4. tree-height (nesting)
     5. number of unique external references
     6. total number of attributes
     7. number of unique attributes
     8. regularity, or "self-similarity"
             Appendix D - Other Auth Examples
‣ Facebook
- Notice the session key expiration

    <?xml version="1.0" encoding="UTF-8"?>
    <auth_getSession_response xmlns=""

‣ Oauth
 ‣ MPOAuthMobile – compiled in project library - Karl Adam

Shared By:
censhunay censhunay http://