Preparing your web services for Android and your Android app for web services @Droidcon Bucharest 2012

  • Published on
    07-May-2015

  • View
    8.926

  • Download
    0

DESCRIPTION

Presented by Auras Dumanovschi

Transcript

<ul><li>1.PREPARING YOUR WEBSERVICES FOR ANDROID AND THE OTHER WAY AROUNDSPEAKER: AURAS DUMANOVSCHI</li></ul> <p>2. OVERVIEW Web services: play nice with others Response formats Optimization Tips Android: using the web data Increasing the speed of your app 3. WEB SERVICES?WHY 4. WEB SERVICES?{ Offloads the data gathering,transformation and storage to apowerful server. Can do a lot of things in a veryshort time Its connected to a large internetWHY pipe 5. IS THERE A 2ND CHOICE? 6. IS THERE A 2ND CHOICE?Yes! 7. IS THERE A2ND CHOICE? Yes!Where else can you get data from? 8. IS THERE A2ND CHOICE? Yes!Where else can you get data from?Web pages 9. IS THERE A2ND CHOICE?Yes!Where else can you get data from? Web pages That means parsing HTML client side. 10. YEAH, SO? { It takes a lot of bandwidth to downloadBIGa fewsome web pages Mobile devices are usually connected to high latency networks: cell towers. Not even wi- is as reliable as ber optic.PROBLEMS You may have to do this a lot of times just for all the data needed for a single screen 11. OKYou can do all that on a web server in less than thetime* for a request from a 3G Galaxy Nexus toreach the web server.*thats if you dont have the data stored in a DB andyou have to fetch it from one or more sources. 12. SO, WEB SERVICES Just like Q &amp; A 13. SO, WEB SERVICES Just like Q &amp; A{ Q: THE REQUEST 14. SO, WEB SERVICES Just like Q &amp; A{ Q: THE REQUESTA: THE RESPONSE 15. SO, WEB SERVICES Just like Q &amp; A{ Q: THE REQUESTA: THE RESPONSE Types: REST &amp; SOAP; 16. SOAP REQUEST: XML, specic format; RESPONSE: XML, specic format; 17. REST REQUEST: HTTP or other*; RESPONSE: XML or JSON; any type ofdocument you like;*HTTP is the norm. But you can alsohave XML or JSON requests. 18. XML VS JSON XML: human readable and compatiblewith most platforms; JSON: compact and quick to parse; 19. NO DATA ON YOUR SERVER? Scrape it; Cache it and/or store it; Serve the data later from the local cache; 20. SIMPLE PLAN OF A PARSER Start point; Data gathering points; End point ; Regular expressions; 21. START, DATA, END 22. FEROVIAR 23. STRUCTURING DATA Try and return only one type of object perAPI call For every object type use the sameschema everywhere. In some cases you can return less dataper object, but where you have more datareturn it in the same format 24. STRUCTURING DATA If your objects have many-to-manyrelationships with other objects removeredundanciesI.e : use person_id to identify a person andat the end of the response return all theunique persons in the current call 25. STRUCTURING DATA Use pagination! 26. BUT IF YOU CANT Add an API call that tells you if the datahas been changed (timestamp, hash,integer, etc) At least make sure you compress theresponse 27. ANDROID SUPPORTS GZIP,DEFLATE// REQUESTHttpUriRequest request = new HttpGet(url);request.addHeader("Accept-Encoding", "gzip");// ...httpClient.execute(request);// RESPONSEInputStream instream = response.getEntity().getContent();Header contentEncoding = response.getFirstHeader("Content-Encoding");if (contentEncoding != null &amp;&amp;contentEncoding.getValue().equalsIgnoreCase("gzip")) {instream = new GZIPInputStream(instream);} 28. TIPS Build an API call that returns images in the requestshape &amp; size; Less bandwidth required, less memory used andless CPU time spent on rendering (no morestretching/shrinking, positioning and cropping); 29. TIPS Never trust the client; Do your security and policy checks server sidealso; Secure every call with a signature: callparameters, private key, timestamp or uniquecall id per session hashed; 30. ANDROID SIDE OF THINGS Parsing JSON: JSONObject or Jackson Objects vs Streaming 31. ANDROID SIDE OF THINGS Generate objects from the data only if you need them right then; In some cases (loading screens) you may need to load a lot of data for later use; Throw lots of data straight to a SQLite DB using TRANSACTIONS 32. WHY TRANSACTIONS? Not just a concept borrowed from traditional*SQL databases Uses less I/O. A whole lot less I/O. Like 100x faster than saving each data line byline 33. REDESCOPERA ROMANIA 34. SAVING To SQLite Databases: persistent objects with lateruse To static objects: volatile objects that will only beused just this session To parcelable objects: even more volatile objects To SharedPreferences: persistent key-value data orsingleton objects 35. CACHING Always cache to the lesystem the images youdownload from the web; Thats what the ~/cache dir is for; Limit your bitmap memory cache and make sureyou also recycle the bitmaps when you clear themfrom the cache; 36. PLAYING NICE WITH THE WEB SERVICE Detect unique install id: generate a GUID SharedPreferences prefs = context.getDefaultSharedPreferences(); String uniqueGUID = prefs.getString("install_guid", null); if (uniqueGUID == null) { ! uniqueGUID = UUID.randomUUID().toString() ! prefs.edit().putString("install_guid", uniqueGUID).commit(); } 37. PLAYING NICE WITH THE WEB SERVICE Detect unique device id: use ANDROID_ID String deviceId = Settings.Secure.getString(contentResolver,Settings.Se cure.ANDROID_ID); 38. PLAYING NICE WITH THE WEB SERVICE Send debugging and app identication data in HTTPheader App Name/Version Device manufacturer/Model/IDHelps debugging issues remotely andAllows web admins to control access to their web service 39. THANKSemail: auras@wip.rotwitter: @aurasThis presentation is available at:http://wip.ro/droidcon/auras.pdf </p>