The most basic way to handle multiple threads is to use the standard Java threads.  I won’t cover those in detail in this series; however, there are some good docs and examples online to help with those.

By default, Android apps run solely in a single thread – the UI Thread.  For most applications, this is perfectly fine.  There are, however, some good reasons that your application needs to be multithreaded.  For example -

• lots of data access – reading/writing to a database is slow
• download information from the internet – mobile networks can be spotty, or slow
• sync with other components – for example, performing Bluetooth pairing or communicating with a service

If you want your thread to be able to interact with the UI and still perform operations in the background, then you’ll need to use some Android specific classes.  The simplest form in Android is the Handler.  A Handler allows you to send/queue messages, execute Runnable objects, and even perform some fine grained scheduling.

One of the best uses for a Handler is for displaying progress.  When communicating progress via a dialog, or progress bar, or whatever, it is good to use a Handler because the user can still interact with your UI.  For example, if the user decides they don’t want to wait, they could press the back button.  Or, perhaps the operation you’re doing doesn’t require the user to wait, they can continue to use your app while information gets updated asynchronously.

Thinking of the G+, FB, or TweetDeck apps that try to backfill your stream…if those apps blocked your UI, and made you wait, you’d most likely never use those apps again.  Or worse, you might go as far as leaving negative feedback in the app store!

So, MaTT, how do we do this?

The example below uses a Handler to set the progress on the UI.  So while the Thread is doing some lengthy operation (mProgressStatus = doWork();), the Handler is able to update the UI by calling the Post method, and setting the progress.

The reason you NEED a Handler here, is because you can’t access the UI from the Thread object.  The Android UI toolkit is not threadsafe by default.  If you try to access the View to update it, there is a good chance you’ll get some amazing Null Reference exceptions.

Each Activity only needs one handler, so you can use that Handler for different tasks or for updating multiple UI components.

So, MaTT, when do we use this?

This approach is great for simple, yet long, operations.  You are still able to show progress to your user and you don’t block the UI while it happens.  Using Handlers won’t give you 5 stars in the market, but it can help keep you from getting 1 star.  Handlers are ideal for one-off situations where you need to do something, but don’t want to interrupt the user.  The other beautiful part about using a Handler is, you don’t have to worry about creating some complex messaging architecture that takes a week to develop and test.

If you find yourself putting Handlers all over the place, consider using a more robust solution like AsyncTasks which I will cover in more detail in my next post.

Android Thread Series:

1. Overview
2. Handlers
3. AsyncTasks
4. Services and Messengers
5. Conclusion