Reading from the database does not happen immediately. Because access can take so long, Room disallows all database operations on the main thread. If you try to violate this rule, Room will throw the IllegalStateException you have just seen.

Why? To understand that, you need to understand what a thread is, what the main thread is, and what the main thread does.

A thread is a single sequence of execution. Code running within a single thread will execute one step after another. Every Android app starts life with a main thread. The main thread, however, is not a preordained list of steps. Instead, it sits in an infinite loop and waits for events initiated by the user or the system. Then it executes code in response to those events as they occur (Figure 11.6).

Figure 11.6  Regular threads vs the main thread

Imagine that your app is an enormous shoe store and that you only have one employee – The Flash. (Who hasn’t dreamed of that?) There are a lot of things to do in a store to keep the customers happy: arranging the merchandise, fetching shoes for customers, wielding the Brannock device. The Flash is so fast that everyone is taken care of in a timely fashion, even though there is only one guy doing all the work.

For this situation to work, The Flash cannot spend too much time doing any one thing. What if a shipment of shoes goes missing? Someone will have to spend a lot of time on the phone straightening it out. Your customers will get mighty impatient waiting for shoes while The Flash is on hold.

The Flash is like the main thread in your application. It runs all the code that updates the UI. This includes the code executed in response to different UI-related events – activity startup, button presses, and so on. (Because the events are all related to the UI in some way, the main thread is sometimes called the UI thread.)

The event loop keeps the UI code in sequence. It makes sure that none of these operations step on each other, while still ensuring that the code is executed in a timely fashion. So far, all of the code you have written has been executed on the main thread.

Background threads

Database access is a lot like a phone call to your shoe distributor: It takes a long time compared to other tasks. During that time, the UI will be completely unresponsive, which might result in an application not responding, or ANR.

An ANR occurs when Android’s watchdog determines that the main thread has failed to respond to an important event, like pressing the Back button. To the user, it looks like Figure 11.7.

Figure 11.7  Application not responding

In your store, you would solve the problem by (naturally) hiring a second Flash to call the shoe distributor. In Android, you do something similar – you create a background thread and access the database from there.

There are two important rules to consider when you start adding background threads to your apps:

• All long-running tasks should be done on a background thread. This ensures that your main thread is free to handle UI-related tasks to keep the UI responsive for your users.

• The UI can only be updated from the main thread. You will get an error if you try to modify the UI from a background thread, so you need to make sure any data generated from a background thread is sent to the main thread to update the UI.

There are many ways to execute work on a background thread on Android. You will learn how to make asynchronous network requests in Chapter 24, use Handlers to perform many small background operations in Chapter 25, and perform periodic background work with WorkManager in Chapter 27.

For CriminalIntent, you will use two options to execute your database calls in the background. In this chapter you will use LiveData to wrap your query data. In Chapter 12 and Chapter 14 you will use Executor to insert and update data.