Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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


Published on

Presented by Auras Dumanovschi

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

  2. 2. OVERVIEW● Web services: play nice with others● Response formats● Optimization● Tips● Android: using the web data● Increasing the speed of your app
  4. 4. WEB SERVICES?{ ● Offloads the data gathering, transformation and storage to a powerful server. ● Can do a lot of things in a very short time ● It’s connected to a large internetWHY pipe
  6. 6. IS THERE A 2ND CHOICE? Yes!
  7. 7. IS THERE A 2ND CHOICE? Yes! Where else can you get data from?
  8. 8. IS THERE A 2ND CHOICE? Yes! Where else can you get data from? Web pages
  9. 9. IS THERE A 2ND CHOICE? Yes! Where else can you get data from? Web pages That means parsing HTML client side.
  10. 10. YEAH, SO? { ● It takes a lot of bandwidth to downloadBIGa few some web pages ● Mobile devices are usually connected to high latency networks: cell towers. Not even wi-fi is as reliable as fiber optic.PROBLEMS ● You may have to do this a lot of times just for all the data needed for a single screen
  11. 11. OK…You can do all that on a web server in less than thetime* for a request from a 3G Galaxy Nexus toreach the web server.*that’s if you don’t have the data stored in a DB andyou have to fetch it from one or more sources.
  12. 12. SO, WEB SERVICES…● Just like Q & A
  13. 13. SO, WEB SERVICES…● Just like Q & A { Q: THE REQUEST
  15. 15. SO, WEB SERVICES…● Just like Q & A { Q: THE REQUEST A: THE RESPONSE● Types: REST & SOAP;
  16. 16. SOAP● REQUEST: XML, specific format;● RESPONSE: XML, specific format;
  17. 17. REST● REQUEST: HTTP or other*;● RESPONSE: XML or JSON; any type of document you like; *HTTP is the norm. But you can also have XML or JSON requests.
  18. 18. XML VS JSON● XML: human readable and compatible with most platforms;● JSON: compact and quick to parse;
  19. 19. NO DATA ON YOUR SERVER? ● Scrape it; ● Cache it and/or store it; ● Serve the data later from the local cache;
  20. 20. SIMPLE PLAN OF A PARSER ● Start point; ● Data gathering points; ● End point ; ● Regular expressions;
  21. 21. START, DATA, END
  22. 22. FEROVIAR
  23. 23. STRUCTURING DATA● Try and return only one type of object per API call● For every object type use the same schema everywhere.● In some cases you can return less data per object, but where you have more data return it in the same format
  24. 24. STRUCTURING DATA● If your objects have many-to-many relationships with other objects remove redundanciesI.e : use person_id to identify a person andat the end of the response return all theunique persons in the current call
  25. 25. STRUCTURING DATA Use pagination!
  26. 26. BUT IF YOU CAN’T…● Add an API call that tells you if the data has been changed (timestamp, hash, integer, etc)● At least make sure you compress the response
  27. 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 &&contentEncoding.getValue().equalsIgnoreCase("gzip")) { instream = new GZIPInputStream(instream);}
  28. 28. TIPS● Build an API call that returns images in the request shape & size;● Less bandwidth required, less memory used and less CPU time spent on rendering (no more stretching/shrinking, positioning and cropping);
  29. 29. TIPS● Never trust the client;● Do your security and policy checks server side also;● Secure every call with a signature: call parameters, private key, timestamp or unique call id per session ➔ hashed;
  30. 30. ANDROID SIDE OF THINGS ● Parsing JSON: JSONObject or Jackson ● Objects vs Streaming
  31. 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. 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 by line
  34. 34. SAVING● To SQLite Databases: persistent objects with later use● To static objects: volatile objects that will only be used just this session● To parcelable objects: even more volatile objects● To SharedPreferences: persistent key-value data or singleton objects
  35. 35. CACHING● Always cache to the filesystem the images you download from the web;● That’s what the ~/cache dir is for;● Limit your bitmap memory cache and make sure you also recycle the bitmaps when you clear them from the cache;
  36. 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. 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. 38. PLAYING NICE WITH THE WEB SERVICE● Send debugging and app identification data in HTTP header● App Name/Version● Device manufacturer/Model/ID Helps debugging issues remotely and Allows web admins to control access to their web service
  39. 39. THANKSemail: auras@wip.rotwitter: @aurasThis presentation is available at: