- App does a blocking network call in the UI thread, causing it to hang if the network is slow. (Implemented while testing, never released.)
- App spawns a thread in the background to make the network call. Results/exceptions from the background thread are proxied back to the foreground thread via a
Handlermessage (which, if you're not familiar with Android, basically lets you pass data via the implicit per-thread message loop).
- App spawns a
Service, conceptually a separate process that can run on without UI present, then serializes its request over AIDL (an Android-specific IDL and serialization library) to the service. The service then does the #2 pattern to run the network request on a background thread, and serializes its response via AIDL back to the IPC thread of the application, which then proxies it back to the foreground again via the
This design allows the Service to keep running even after the app closes -- allowing my phone to buzz me when my train is about to arrive -- along with allowing the app, when foregrounded, to get in on the same updates that are being computed in the background.
evolution of an android developer
As described elsewhere, I've quit LiveJournal. If you're interested in my continuing posts, you should look at one of these (each contains feed…
They published a paper on Dremel, my favorite previously-unpublished tool from the Google toolchest. Greg Linden discusses it: "[...] it is capable…
I finally wrote up my recent adventures in treemapping, complete with nifty clickable visualizations.