{"id":690,"date":"2011-07-17T22:50:35","date_gmt":"2011-07-18T05:50:35","guid":{"rendered":"http:\/\/wiebe-elsinga.com\/blog\/?p=690"},"modified":"2011-07-17T22:50:35","modified_gmt":"2011-07-18T05:50:35","slug":"handlers-and-asynctasks-android-doing-multithreading","status":"publish","type":"post","link":"http:\/\/wiebe-elsinga.com\/blog\/handlers-and-asynctasks-android-doing-multithreading\/","title":{"rendered":"Handlers and AsyncTasks, Android doing multithreading"},"content":{"rendered":"
\n<\/div>\n\n

Multithreading is always tricky. On any platform and in any language, when not implemented properly you will get unexpected behavior sooner or later.<\/p>\n

In the process of making an Android application suitable for Honeycomb, a colleague of mine ran into the NetworkOnMainThreadException<\/em>, which is new in Honeycomb. On earlier Android versions, doing heavy operations on the main thread was strongly discouraged, but still possible. Now, the OS is forcing the developer to implement a proper application structure. Which isn’t a bad thing at all.<\/p>\n

So, to solve the NetworkOnMainThreadException<\/em>, network and other heavy operations needed to move to a background thread. Considering the structure of the application, the most logical choice was to use the Handler<\/em> in combination with a Thread<\/em>.
\n<\/p>\n

Basic setup HandlerThread<\/em><\/h4>\n

Here is an example:<\/p>\n

public<\/span> class<\/span> MBOutcomeHandlerThread extends<\/span> Thread<\/span><\/a>
\n{<\/span>
\n  public<\/span> MBOutcomeHandlerThread(<\/span>String<\/span><\/a> name)<\/span>
\n  {<\/span>
\n    super<\/span>(<\/span>name)<\/span>;<\/span>
\n  }<\/span>
\n
\n  private<\/span> MBOutcomeHandler _outcomeHandler;<\/span>
\n
\n  @Override
\n  public<\/span> void<\/span> run(<\/span>)<\/span>
\n  {<\/span>
\n    try<\/span>
\n    {<\/span>
\n      Looper.prepare<\/span>(<\/span>)<\/span>;<\/span>
\n
\n      _outcomeHandler =<\/span> new<\/span> MBOutcomeHandler(<\/span>)<\/span>;<\/span>
\n
\n      Looper.loop<\/span>(<\/span>)<\/span>;<\/span>
\n    }<\/span>
\n    catch<\/span> (<\/span>Throwable<\/span><\/a> e)<\/span>
\n    {<\/span>
\n      Log.e<\/span>(<\/span>"Log"<\/span>, "Thread stopped due to error"<\/span>, e)<\/span>;<\/span>
\n    }<\/span>
\n  }<\/span>
\n
\n  public<\/span> MBOutcomeHandler getOutcomeHandler(<\/span>)<\/span>
\n  {<\/span>
\n    return<\/span> _outcomeHandler;<\/span>
\n  }<\/span>
\n}<\/span><\/div><\/div>\n

Looper.prepare<\/em><\/strong> creates a new Looper instance for this thread, which then creates a new MessageQueue<\/em> that Handlers<\/em> can use to post messages on.<\/p>\n

MBOutcomeHandler<\/em> is a subclass of Handler<\/em>, which implements the handleMessage<\/em><\/strong> method. The constructor of the Handler<\/em> class associates with the Looper.<\/p>\n

Looper.loop<\/em> starts the Looper and keeps the thread alive. The Looper can be stopped by invoking Looper.quit<\/em><\/strong>. This will end run method of the Thread, hence, the Thread is finished.<\/p>\n

It is also possible to use the HandlerThread<\/em> class. This class does the Looper setup for you. It doesn’t really matter which one you choose, as long as you don’t forget to instantiate the Handler<\/em> inside the run method. When using the HandlerThread<\/em> you must instantiate the Handler<\/em> in the onLooperPrepared<\/em><\/strong> method.<\/p>\n

public<\/span> class<\/span> MBOutcomeHandlerThread extends<\/span> HandlerThread
\n{<\/span>
\n  private<\/span> MBOutcomeHandler _outcomeHandler;<\/span>
\n
\n  public<\/span> MBOutcomeHandlerThread(<\/span>String<\/span><\/a> name)<\/span>
\n  {<\/span>
\n    super<\/span>(<\/span>name)<\/span>;<\/span>
\n  }<\/span>
\n
\n  @Override
\n  public<\/span> void<\/span> run(<\/span>)<\/span>
\n  {<\/span>
\n    super<\/span>.run<\/span>(<\/span>)<\/span>;<\/span>
\n    _outcomeHandler =<\/span> null<\/span>;<\/span>
\n  }<\/span>
\n
\n  @Override
\n  protected<\/span> void<\/span> onLooperPrepared(<\/span>)<\/span>
\n  {<\/span>
\n    _outcomeHandler =<\/span> new<\/span> MBOutcomeHandler(<\/span>)<\/span>;<\/span>
\n  }<\/span>
\n
\n  public<\/span> MBOutcomeHandler getOutcomeHandler(<\/span>)<\/span>
\n  {<\/span>
\n    return<\/span> _outcomeHandler;<\/span>
\n  }<\/span>
\n}<\/span><\/div><\/div>\n

Now that we have a HandlerThread<\/em> running, we can use the Handler<\/em> to send messages to the Looper.<\/p>\n

Please be aware, that the HandlerThread<\/em> keeps looping until the quit method is invoked. It doesn’t really matter if you use the instance of the HandlerThread<\/em>, the Handler<\/em> or the Looper. After the quit method is invoked, the HandlerThread<\/em> is finished and cannot be started again. For example, if the HandlerThread<\/em> has been quit because the Activity was pushed to the background, you need to clean up the HandlerThread<\/em> in an onPause<\/em><\/strong> or onStop<\/em><\/strong>. When the Activity comes to the foreground again, a new HandlerThread<\/em> must be created. Of course, the starting and stopping of the HandlerThread<\/em> depends on what kind of operations are performed in the Handler. Then again, I think it is good practice to do a little clean up, instead of Android doing all the work.<\/p>\n

AsyncTasks<\/h4>\n

After the new Handler<\/em> was created, the next problem occurred. After pushing the application to the background and let it come to the foreground again, the application crashed because of the following error: Handler{4062bc78}<\/em> sending message to a Handler<\/em> on a dead thread. Because I was implementing a Handler, I assumed the exception had something to do with the Handler I created. After a lot of searching and debugging, the cause of the exception were the AsyncTasks<\/em> that are used inside the Handler. Then, after reading the documentation of AsyncTask<\/em>, Android is very clear that AsyncTasks<\/em> must be created and started on the UI thread. But, in the process of moving code to the handler, that was overlooked. After creating and starting the AsyncTasks<\/em>, everything worked fine!<\/p>\n

Recap<\/h4>\n

HandlerThreads<\/em> and Handlers<\/em> are a great way to handle heavy or long during operations on a separate thread. When using AsyncTasks<\/em> in your Handler, make sure that they’re created on the UI thread. <\/p>\n","protected":false},"excerpt":{"rendered":"

Multithreading is always tricky. On any platform and in any language, when not implemented properly you will get unexpected behavior sooner or later. In the process of making an Android application suitable for Honeycomb, a colleague of mine ran into the NetworkOnMainThreadException, which is new in Honeycomb. On earlier Android versions, doing heavy operations on the main thread was strongly discouraged, but still possible. Now, the OS is forcing the developer to implement a proper application structure. Which isn’t a bad thing at all. So, to solve the NetworkOnMainThreadException, network and other heavy operations needed to move to a background thread. Considering the structure of the application, the most logical choice was to use the Handler in combination with a Thread.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[7],"tags":[154,69,56,70,71],"_links":{"self":[{"href":"http:\/\/wiebe-elsinga.com\/blog\/wp-json\/wp\/v2\/posts\/690"}],"collection":[{"href":"http:\/\/wiebe-elsinga.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/wiebe-elsinga.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/wiebe-elsinga.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/wiebe-elsinga.com\/blog\/wp-json\/wp\/v2\/comments?post=690"}],"version-history":[{"count":0,"href":"http:\/\/wiebe-elsinga.com\/blog\/wp-json\/wp\/v2\/posts\/690\/revisions"}],"wp:attachment":[{"href":"http:\/\/wiebe-elsinga.com\/blog\/wp-json\/wp\/v2\/media?parent=690"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/wiebe-elsinga.com\/blog\/wp-json\/wp\/v2\/categories?post=690"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/wiebe-elsinga.com\/blog\/wp-json\/wp\/v2\/tags?post=690"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}