Thread by @ErikHellman

This weeks @androidweekly included a post by @VasiliyZukanov that unfortunately perpetuates a myth in programming; it's ok to use threads.

Before I explain why this is myth that we need to kill, you should read the post: techyourchance.com/concurrency-fr…

#Androidev #Development

1/x

There are a number of problems with the solution in this post, but I'm just going to focus on one; using low-level concurrency APIs (i.e., java.lang.Thread).

With very few exceptions (we'll get to those), this is always a bad thing.

2/x

One simple argument against the use of using threads directly (regardless of language, platform or OS) is that we don't do it for other things.

You're not implementing your own HTTP client, UI framework, or database engine. So why would it be right for concurrency?

3/x

Another, more important, argument is that concurrency is _really hard_. Most of us get it wrong, it is really difficult to write tests for threads, and it is historically very hard to maintain.

This post by @davidbaron is a great read on this; bholley.net/blog/2015/must…

4/x

I can't say why the author would argue that using bare threads would be a good thing, but I have heard similar arguments from other before and have my own idea of why:

It is really exciting to write concurrent code!

5/x

Some types of programming are boring and these are areas that are among the first to see high-level abstraction that reduces the amount of time we need to spend there. Databases, testing, and build scripts are all examples of these.

6/x

There are several types of programming that are really fun. Writing UI code is one of those. So why don't we hear developers arguing that OpenGL is all you need?

It's all about the complexity of the low-level APIs. OpenGL is neither fun nor easy.

7/x

Working with threads in Java is nowhere near as complicated as OpenGL. The API is fairly straightforward and you don't have to be an expert in concurrency to write code using java.lang.Thread. But just because the API is simple doesn't mean using it is.

8/x

As have been shown repeatedly in the history of software development, writing multithreaded code is really hard. The best thing is if we can remove the need consider this for most developers. Luckily for us, this has been done with things like RxJava and Kotlin Coroutines.

9/x

Just like you're not writing your UI in OpenGL (or even using a custom View and a Canvas to draw your Android UI for everything), you shouldn't use java.lang.Thread directly to perform any background work. This is an anti-pattern.

10/x

Other successful platforms have adopted the principle of removing low-level concurrency from the developers toolkits. Apple have deprecated threads, JavaScript has never had the concept, and in Flutter you have very limited ways of controlling what thread you run on.

11/x

Threads is not a bad thing in itself, but it's not something we should use in apps or even in most libraries we produce. The only exception where using threads directly is acceptable is when building higher level concurrency frameworks.

12/x

This doesn't mean you should never learn about threads and how they work. I've spent way too much time reading about OpenGL, but I almost never use it when building an app. It has helped me to understand graphics in a better way and make my UI more efficient.

13/x

Even with higher level frameworks, knowledge about concurrency is important. The difference is that these frameworks makes it easier to test your code and it also makes it easier for the next developer to understand what is happening.

14/x

Our minds can't deal well with asynchronous flows. Keeping track of what's happening in code that is async is very difficult for us. This is one of the reasons why we have the term "callback hell", which is just another aspect of this.

15/x

A good framework for dealing with concurrency is one that lets you write code that can be read like synchronous code. async/await in JavaScript is an excellent example of this. Compared to the old way of using promises with callbacks (Promise.then), we're much better of.

16/x

So to sum things up: never use bare threads in your code, unless you're maintainer of Kotlin Coroutines or RxJava.

Always use a high-level abstraction that you're comfortable with and focus on writing code that is easy to read.

17/x

So what should have been use for the example in the original blog post?

I would have gone with AndroidX WorkManager, perhaps using CoroutineWorker. That way it would work across process death and other tricky corner cases.

developer.android.com/topic/librarie…

18/x

Besides using high-level concurrency frameworks, you should also learn about concurrency and multi-threading in general. These are still important things to know, even when using something like RxJava or Coroutines.

19/x

For instance, every developer should understand the difference between CPU and I/O bound threads, which I wrote about a while back: hellsoft.se/understanding-…

20/x

So stay safe everyone, including when writing concurrent code! :)

21/21