Skip to content

Instantly share code, notes, and snippets.

@kpgalligan
Last active August 29, 2015 14:02
Show Gist options
  • Save kpgalligan/7471a646e97a0a038ec0 to your computer and use it in GitHub Desktop.
Save kpgalligan/7471a646e97a0a038ec0 to your computer and use it in GitHub Desktop.

Threading patterns

To understand mobile, you need to understand threading. If you don't really get that, you'll wind up in various worlds of hurt.

Methods

AsyncTask

AsyncTask is probably the first thing everybody uses. Its all over the early examples in Android. Its pretty basic, assuming you don't hit the methods nobody ever uses. Just "doInBackground" and "postExecute". The idea is that you do something in "doInBackground", in a background thread, and in "postExecute", you do something in the main thread. Generally, tweak your UI.

AsyncTask has some benefits.

  1. Its simple. Do something in background, do something in foreground.
  2. You can do things in place, so what you're doing is close to your other code. This is sometimes a benefit, sometimes bad practice, but you don't need to chase down through deep levels of code to see what's happening.

Cons

  1. Context is attached to the Activity/Fragment you're in. Your context can get changed easily, so AsyncTask can be dangerous.
  2. Code may get executed in the foreground at unfortunate times.
  3. The generic model can get bulky. It expects a type for passed in args, progress args, and a return arg. Syntactically ugly at times.
  4. Using inline can make for some messy code, and warnings if you don't bother filling in generics (which are a PITA).

By far the biggest issue is #1. You can code screens with little trouble if you're careful with threading rules, but the most important rule of threading is this.

The best multi-threaded code isn't

AsyncTask forces you to be more aware of the sharp edges of multithreading, so we'll almost always avoid them. When are they useful? Sometimes you want to grab a quick piece of info. Like you're in a screen and want to grab some data based off something a user entered on a form. Sometimes you just need to bang out screens, and this is OK. Mostly, though, don't do this.

Event Bus

This is basically a background thread, out of the Fractivity context, which communicates back to the main thread through one of several mechanisms. That's the basic model, though:

  1. Background thread
  2. Push to main thread

Until recently the model has been a hand rolled background thread, usually a single executor from standard Java, and LocalBroadcastManager sending something to the front end. This works, but is a little clunky. Currently evaluating EventBus from greenrobot. Will update soon on this, but the basic concepts are the same.

The main benefit of an event bus is getting the background task into a context that doesn't rely on the Fractivity lifecycle.

As an example, save a value to the db, then tell the front end to finish the Activity. If you've rotated while the save is processing, you'll lose your context after the rotate.

With background and LBM, you can register to listen for the return value and finish the activity. Sweet!

Sweet?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment