We've just finished adding a playlist to our app, and

we're even making sure to download one song at a time.

What else could we want?

Well, unfortunately we really shouldn't be using the playlist

inside our download thread.

If this were a larger app that had more than one developer, it wouldn't be too

hard to imagine someone else modifying our playlist outside of our download thread.

And if our playlist changes for any reason,

all of a sudden we'd be downloading the wrong songs.

What we need is a queue for the songs we want to download.

Once one song finishes, the next song in the queue would start downloading.

We can implement this by adding something called a message queue to our thread.

And in order to use a message queue,

we'll also need to be aware of handlers, loopers, and messages.

It's a lot to cover, but the following examples should help elucidate

the role each of these objects plays in the bigger picture.

Imagine a fully stocked burrito truck.

This burrito truck represents our thread.

Just like a thread is a place where we can execute our code,

the burrito truck is a place where we can execute making burritos.

In this example a runnable would be a recipe.

Something like, take one tortilla add a quarter pound of shredded chicken and

a half cup of shredded cheese, mix and fold into the shape of a burrito.

So before, when we were just using a runnable and a thread,

that would be like if we just showed up at the burrito truck with our own recipe and

then we just went inside and made the burrito ourselves.

But now we'd like our thread, burrito truck,

to have a queue of what it should be working on.

The first change we're going to make,

is we're going to hire someone to work in the burrito truck.

We'll call him Tim, and he represents the handler object.

In Android each handler is associated with only one thread.

And that handler is responsible for sending and

processing messages and runnables for the thread.

So Tim, our handler, only works at this burrito truck, our thread.

And he's responsible for taking and preparing the orders,

messages and runnables.

We're already familiar with runnables, but what's a message?

A message is just a way for us to send some arbitrary data to our handler.

It's then up to the handler how it will handle the message.

If we wanted to order a burrito, we could give Tim a recipe, or

we could order off the menu.

One breakfast burrito please.

When we order off the menu, that's an example of using a message.

We don't need to know how to make a breakfast burrito

because Tim knows how to handle it.

Once Tim takes our order, he's going to put it at the end of the list of orders.

This is the message queue.

It contains all the runnables and messages that our thread still needs to handle.

Now Tim's daughter Looper is too young to help with most of the burrito truck work.

But she's still eager to help out.

So when Looper notices her dad is about to finish an order,

she grabs the next order from the message queue and gives it to her dad.

Way to help out Looper.

All right, let's walk through an example to see how all these pieces work together.

A man walks up to the burrito truck with the recipe for a burrito he'd like.

Tim takes the order and adds it to the message queue.

Then Tim gets back to working on a previous order.

When Tim finishes the previous order, Looper grabs the next

order from the message queue and Tim starts working on this new order.

Then another guy walks up and places an order for a breakfast burrito.

Tim takes the order and adds it to the message queue.

Then Tim gets back to working on a previous order.

When Tim finishes the previous order Looper grabs the next order from

the message queue and Tim starts working on this new order.

Looks like Tim's an awfully busy guy.

Let's take a short break and then we'll see how to implement this in code.