Android Development and Threads

Android Development and Threads


While I am writing a post about how to write an Android application with a portrait camera, I have figured that my knowledge about Android threads is lacking some important information, therefore I have decided to read and summarize some of this information.



  • The Main thread is also called the UI thread.
  • User interface cannot be updated by non UI threads.
  • Updating UI from a non UI thread will cause a CalledFromWrongThreadException to be thrown while the application will pass compilation!.


  • (+) Very simple to implement.
  • (+) The AsyncTask is better used for light operations which take up to few seconds, otherwise one should consider the use of java.util.concurrent package or using Broadcasts (see below).
  • (+) Beside doInBackground(Params...) all other AsyncTask's methods are executed on the UI thread.
  • (+) It is very easy to update the UI thread from within the non UI thread using AsyncTaks's onProgressUpdate by calling the publishProgress from within the doInBackground method.
  • (+) Keeps the code decoupled so that the non UI thread is not exposed to any UI components.
  • (-) AsyncTask and configuration changes require special treatment. There are different approaches which are worth reading about, make sure you go over the configuration changes section below and read this post.
  • (-) When using HTTP requests it might be better to consider the use of IntentService and BroadcastReceiver.

Broadcast and Broadcast Receiver

  • Broadcasts do not use the message event queue but just the Intent and the Intent listener.
  • (+) Can carry quite a bit of data between the threads (which might be more relevant if compared to AsyncTask).
  • (+) Broadcasts can be used locally or globally.
  • (+) Keeps the code decoupled so that the non UI thread is not exposed to any UI components.
  • (-) The global use of broadcasts might be risky both security and performance wise.
  • (-) Don't forget to unregister the broadcast onDestroy.


  • (+) Allows more control/flexibility.
  • (+) Generic for any type of thread communication.
  • (+) Keeps the code decoupled so that the non UI thread is not exposed to any UI components.
  • (-) A bit more complex than using Activity.runOnUiThread and

Activity.runOnUiThread &

  • Uses a Runnable object.
  • Uses the UI event queue by publishing a message.
  • (+) Simple to implement.
  • (-) Couples the non UI thread to the UI components.

Note that the main difference between runOnUiThread and post is that when running them on the UI thread (for any reason) they first will execute directly while the later will publish a message to the UI event queue.

Configuration Changes

  • (-) Destroy & create events might be unpredictable.
  • (-) AsyncTask must communicate with the current/latest Activity.
  • (-) Configuration changes might start a new AsyncTask while the old one is still working.
  • (-) Disabling the default destroy and create events by using android:configChanges is a bad practice.
  • (-) Configuration changes may occur as a result of more than one value in the android:configChanges attribute.
  • (-) onRetainNonConfigurationInstance is deprecated in favor or Fragments.
  • (+) Retained Fragments were introduced on Android 3.0.
  • (+) Fragments are destroyed and recreated along with their parent Activity.
  • (+) Fragments support a way to retain an instance of an object while configuration change occur.
  • (+) Fragments are very useful when used with Threads/AsyncTask.
  • (!) Passing additional arguments to the Fragment should be done using the setArguments(Bundle) and not by a custom constructor.


2012/03/17 - androidresearch - Understanding AsyncTask once and forever

2013/05/10 - androidresearch - Dealing with AsyncTask and screen orientation

Android non UI to UI Thread Communications: part 1 part 2 part 3 part 4 part 5

Stackoverflow questions Android whats the difference between activity runOnUiThread and view post

Is main thread the same as UI thread while I would take a look at this answer as well.

Retaining Objects Across Config Changes


I hope this information helps. In case you have any good insights feel free to leave a comment!

Work In Progress 🚧