Where Do Threads Come From? Um, Besides From Me?

In this sample, we created our own thread, by means of Executors.newSingleThreadExecutor(). This will be needed in some situations, where you are using a synchronous API, one that offers no sort of callback or other asynchronous option.

However, frequently, something else might create the threads for you.

Threads from Reactive Frameworks

As mentioned earlier, RxJava is the most popular reactive framework for Java development. With RxJava, you indicate what work you want done and what RxJava-supplied thread pool that you want that work to be done on (e.g., “use the thread pool dedicated for I/O”). RxJava takes care of allocating the threads and using them as appropriate.

In Kotlin, coroutines are gaining in popularity. Coroutines, along with other Kotlin language and standard library features, offer a lot of the same capabilities as does RxJava. Kotlin coroutines, though, can support Kotlin’s array of platform targets (e.g., JavaScript) in addition to Android, while RxJava is tied to Java-based apps. On the other hand, coroutines are fairly new to Kotlin overall, whereas RxJava has been around longer. But, if you use coroutines, once again you will not need to create threads yourself — you describe where you want work to be done, and the coroutines engine handles the actual threading.

Threads from Data Sources

Many libraries that support database and network I/O offer their own thread pools for performing that I/O. They offer either a true reactive API or a classic callback-based system for getting the I/O results asynchronously.

Room, mentioned earlier in this chapter, is the Jetpack solution for on-device database access. Room wraps Android’s SQLite support in an API that, among other things, supports both synchronous and reactive access. If you prefer, you can call synchronous APIs and handle the threading yourself. Or, you can have Room respond with LiveData, interact with RxJava, or support Kotlin coroutines. We will explore Room more later in the book.

There are a massive number of third-party libraries available for Internet access. Some are general-purpose for accessing data over HTTPS, such as OkHttp. Others are optimized for specific types of Web access:

• Images (e.g., Glide, Picasso)
• REST Web services (Retrofit)
• GraphQL Web services (Apollo-Android)

All offer asynchronous APIs. In some cases, they offer integration with reactive frameworks like RxJava. In others, they just allow you to supply a callback function to be invoked when the I/O is completed.

Threads from Background Processing

Some work needs to be done in the background as a result of the user doing something in your UI. For example, a Twitter client needs to refresh the timeline when the user clicks a refresh button or performs a pull-to-refresh gesture. In those cases, using threads and LiveData, RxJava, or Kotlin coroutines are recommended.

In other cases, the work may need to happen somewhat later, even if the user is no longer interacting with the app. For example, you may have a business requirement to check a server once per hour, every hour. Here, the user is not triggering the need for background work — the passage of time is.

WorkManager is the Jetpack solution for this problem. It handles threading for you; your work will be performed on a background thread automatically. We will explore WorkManager more later in the book.