Fast, user-friendly and power-efficient network communication on Android

Transcription

1 Fast, user-friendly and power-efficient network communication on Android Erik Hellman Research Engineer - Sony Mobile

2 What can developers do? HTTP client handling Background Network I/O Playing server

3 Do not re-invent the wheel! I invented this new protocol that is much better than HTTP (or TCP/IP, GSM, Ethernet, , UMTS etc.)... - Random developer I meet at almost every conference Always do a proper investigation (Google, developer forums etc.) to check if there is an existing software component or library that you can use for your project!

4

5 Buffering The input and output streams returned by this class are not buffered. Most callers should wrap the returned streams with BufferedInputStream or BufferedOutputStream. Callers that do only bulk reads or writes may omit buffering. - Android JavaDoc for HttpURLConnection

6 Reading streams By default, this implementation of HttpURLConnection requests that servers use gzip compression. Since getcontentlength() returns the number of bytes transmitted, you cannot use that method to predict how many bytes can be read from getinputstream(). Instead, read that stream until it is exhausted: when read() returns Android JavaDoc for HttpURLConnection

7 Reading streams the wrong way The above is a typical example of how I see developers reading from a stream.

8 Reading streams - still doing it wrong... The example from Android developer docs are still not perfect. The read() method doesn t always fill the entire buffer but will return the exact number of bytes read!

9 Safe stream reading

10 Caching Caching of HttpURLConnection calls are built-in in Android. You should always make sure you enable this for your networked apps. See for details.

11 Sending data For best performance, you should call either setfixedlengthstreamingmode(int) when the body length is known in advance, or setchunkedstreamingmode(int) when it is not. Otherwise HttpURLConnection will be forced to buffer the complete request body in memory before it is transmitted, wasting (and possibly exhausting) heap and increasing latency. - Android JavaDoc for HttpURLConnection

12 When to disconnect and keep-alive? More than one request needed? System.setProperty( http.keepalive, true false ); Always call InputStream.close() AND HttpURLConnection.disconnect()!

13 All network I/O should be done on a dedicated thread(s)!

14 AsyncTask The Google recommendation

15 AsyncTask - Drawbacks Must be started on the UI thread Not reusable - new allocation on every run

16 Service + Handler (1/2)

17 Service + Handler (2/2)

18 Poll or Push? Is background data required? New data every 15 minute or less? Can the user wait 15 minutes? Do we need to notify the user?

19 Google Cloud Messaging is usually a very good solution to reduce unnecessary network calls. However, if there are more updates from the server than the user need to be aware of, background polling could be a better solution.

20 Optimized polling

21 AlarmManager.setInexactRepeating(); Trigger AlarmManager inexact repeating

22 Android as a Server It is all about discovery! Running a server in your Android app can often be required for things like multiplayer games, ad-hoc chat or file-sharing. The most complicated thing to solve efficiently is usually how a client device can discover the address of the server device. Solving this should be your first task.

23 netty.io - Just use it! Instead of trying to implement your own server code you should pick a library that will provide as much functionality as you need without being to large in memory consumption or download size. Netty is a great component that is well tested and works very well on Android. You can find Netty at

24 Multicast Multicasting is usually the easiest way to enable adhoc discovery from the servers point-of-view. However, this technology is usually not optimal for mobile devices as it drains battery faster than normal network I/O and it can often be blocked on public WiFi. Avoid using UDP Multicast if possible.

25 Multicast - Still doing it? Only for discovery on local network! WifiManager.MulticastLock Keep it short! May often be blocked on public WiFi!

26 Cloud-based discovery 1. Register device 2. Lookup 3. Setup communication

27 Key points for devs Read the JavaDoc for HttpURLConnection! Beware of the GC - avoid new Service + Handler = WIN! Consider when to push or poll Keep-alive only for multiple requests Close and disconnect properly! Servers drains battery fast!

28 What can designers do? Application startup Showing progress and being responsive Handling network errors

29 BAD GOOD When your application starts up you should display all the functions that the user can use even if your app haven t downloaded everything needed from the servers. Avoid showing a splash screen or blocking progress dialogs.

30 Interrupted startup... How will your app react if the user interrupts the startup of your app by pressing home or back before you have finished loading data from the server? This is one of the reasons your app should always do network I/O away from the activity and the UI.

31 The only splash screen you need... Instant access to user controls

32 VERY BAD!

33 VERY GOOD :)

34 Conclusions Network I/O is hard but well worth the extra effort!