- 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
Handler
message (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 theHandler
.
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
-
blog moved
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…
-
dremel
They published a paper on Dremel, my favorite previously-unpublished tool from the Google toolchest. Greg Linden discusses it: "[...] it is capable…
-
treemaps
I finally wrote up my recent adventures in treemapping, complete with nifty clickable visualizations.
- Post a new comment
- 5 comments
- Post a new comment
- 5 comments