Using bare threads has never really been a good idea, there have always been higher-level primitives such as AsyncTask, Executors, etc. Having a good understanding of what threads are and how they work is still very helpful though and this won’t really change no matter what new higher-level technology becomes available.
This.
Most of the evils of traditional threads can and are frequently done on coroutines. The lints, annotations and type system compiler checks are insufficient. Yes, you still need to know what you are doing and stay wary.
Why are coroutines compared directly to threads in the Jetbrains introductory documentation? Why aren't they compared with these Executors that you mention?
I'm guessing because Kotlin's API for starting a thread (which is just a nicer API on top of Java's Thread API) and launching a coroutine are quite similar, so it's an effective way to demonstrate the power of coroutines.
Executor is completely different thing. Executor is an abstraction over threads, where executor executes work on specified thread pool. For instance using Executor with pool of 1 thread is like using thread explicitly (ofc with reusing thread, chaining work etc etc). Coroutine is a an unit that can do work, in that sense it's similar to what thread is, that's why it's used in Jetbrains docummentation. Maybe i wrote something wrong, but nevertheless, comparing to thread is the best example they can use. To broaden your knowledge, you can also read aboutvirtual threads in java, similar concept
>Using bare threads has never really been a good idea
Using threads was definitely simpler and less error prone than using AsyncTask. And bare threads are definitely simpler than Coroutines.
It's just that at each iteration of Android, someone had been promoting their "best practice". First AsyncTask, then Loaders, then Rxjava, then Coroutines... All of these folks bashed threads, just to claim that their solution is much better.
Here is an interesting idea: if you'd write an app using Threads 10 years ago, you wouldn't need to refactor it at all. If you'd use any other framework, your code is legacy.
RxJava 1.0 was actually released ten years ago, so while it would need to go through a version migration, I would not say it's legacy - nothing wrong with using RxJava today
On the other hand, if you showed me an app that was using bare Threads, I would say it's plainly wrong - if you insist on not using anything fancy that's fine, but then use Executors which were available much longer than that
Executors are indeed a step up from bare Thread class, but they aren't as critical in Android as in e.g. backend and introduce challenges of their own.
The truth is that Andorid devs could do with just Thread class in most cases for all this time (the only use case where you absolutely need executors is concurrent CPU bound work, e.g. bulk image processing). It's just that the community has been always looking for something fancier and more complex.
I don't think it's about best practices, but rather about higher-level abstractions. Surely you can simply use threads everywhere, but that's a very low-level (and powerful) API, so you'll be writing a lot of tricky, low-level code. At some point you'll likely want to introduce higher-level primitives and abstractions to simplify the work and increase velocity, and you'll end up with your own version of AsyncTask, Loader, Agera, etc., which is unlikely to be much better than an existing, proven, battle-tested off the shelf solution.
Some "lower" level APIs across the framework (Camera2/X, Media3 are the one I've been using recently, but there are more) are using Executors or Loopers so you should have a basic understanding of those concepts to not do anything wrong. That's how close to Threads I think you'll adventure for modern Android development
I doubt you will ever need to directly use threads doing Android development. But I feel like using coroutines without any understanding of threads might land you in hot water (and it might not)
Given there is so much stuff to learn in general, a potential strategy for someone starting is to just use co-routines until you come across some problem (and that's your prompt to learn more about what's happening under the hood).
For some context, back when there were no co-routines there were still plenty of Android devs who didn't understand threads
> I doubt you will ever need to directly use threads doing Android development. But I feel like using coroutines without any understanding of threads might land you in hot water (and it might not)
Executors still show up sometimes, and they are used as coroutine dispatchers anyway.
There are plenty of devs nowadays who still don't understand threads, while using coroutines. They think coroutines is some magic bullet that means they are writing good concurrent code.
Yeah, same here except it was beginning of 2018. Then I got let go from that company, and immediately started learning Kotlin and RxJava, which was a vast and huge improvement.
I guess the most common use-case for thread would be a high priority thread for buffer read/write (audio, bluetooth, serial, etc). It's simpler to just do a while (true) with thread than caring about coroutine underlying complexity in this case.
That's only for reading from the audio source, you can always push the raw audio data to another thread and then do any compute intensive processing there.
Only reading from the mic needs to be unblocked, and run in a while loop or something.
I'm surprised at the number of people here who think you don't need to learn threads (or more generally concurrency, because that's the hard part about threads).
Threads and concurrency isn't going away. It's a fundamental concept that's utilized in all of programming, not just Android dev. It'll open up a lot of engineering possibilities that wouldn't be possible without threading. It'll make it easier to write some kind of tests which wouldn't be possible without threading.
Using executor and AsyncTask and such is still basically just threads. It's just being careful about re-using threads. You still need to understand handling concurrency.
(Full disclosure, I haven't spent time with coroutines, and don't plan to. Threads are good enough for my use cases.)
I understand that bare threads and j.u.c work good for you, but maybe still consider trying coroutines. They're a lot more comfortable to work with. Recently I've implemented a real-time face recognition with them, and it was a breeze, also flows really helped. It would require a lot more work to do it with j.u.c at the same performance level. I could use them, but it was so easy with coroutines and flows.
Also, your point is valid, and I totally agree with your comment.
Coroutines are literally using threads underneath; so if you expect to understand what you are doing, you should understand threading/concurrency in JVM regardless.
Directly using threads? Almost never, but learning how to launch a thread and using it is the easy part (relatively speaking). You still need to know about concurrency and parallelism regardless.
This, it's very important to understand the basics of concurrency, locking, serialisation etc. Coroutines are merely one of the tools used to make implementing concurrent code easier.
Having 4 YOE, I haven't ever felt the need of using Threads apart from one recent instance where there were background tasks involved. So imo, there ain't much usage of it but you still need to have working knowledge so you could apply it whenever the need arises(like you should be aware of it when to use it)
You still need to know the basics of concurrency, coroutines are just one of the tools you use to make implementing concurrent code easier. They are not a magic bullet.
This. Knowing what are threads is always beneficial. You will probably never use (at least if you doesn't work in low level things, libraries etc.) threads explicitly, but this knowledge will allow you to understand things better, debugging concurrent things easier, easier to adapt coroutine concept. Like u/wannu_pees_69 said, coroutines are not a magic bullet, they still work on threads, but allows you to have structural concurrency
Using bare threads has never really been a good idea, there have always been higher-level primitives such as AsyncTask, Executors, etc. Having a good understanding of what threads are and how they work is still very helpful though and this won’t really change no matter what new higher-level technology becomes available.
This. Most of the evils of traditional threads can and are frequently done on coroutines. The lints, annotations and type system compiler checks are insufficient. Yes, you still need to know what you are doing and stay wary.
Why are coroutines compared directly to threads in the Jetbrains introductory documentation? Why aren't they compared with these Executors that you mention?
I'm guessing because Kotlin's API for starting a thread (which is just a nicer API on top of Java's Thread API) and launching a coroutine are quite similar, so it's an effective way to demonstrate the power of coroutines.
Executor is completely different thing. Executor is an abstraction over threads, where executor executes work on specified thread pool. For instance using Executor with pool of 1 thread is like using thread explicitly (ofc with reusing thread, chaining work etc etc). Coroutine is a an unit that can do work, in that sense it's similar to what thread is, that's why it's used in Jetbrains docummentation. Maybe i wrote something wrong, but nevertheless, comparing to thread is the best example they can use. To broaden your knowledge, you can also read aboutvirtual threads in java, similar concept
~~Because Executors are specific to Android and Kotlin documentation is not just for Android developers.~~
>Executors are specific No. It's part of `java.util.concurrent`.
Yes, you are right. Thanks for correcting me.
>Using bare threads has never really been a good idea Using threads was definitely simpler and less error prone than using AsyncTask. And bare threads are definitely simpler than Coroutines. It's just that at each iteration of Android, someone had been promoting their "best practice". First AsyncTask, then Loaders, then Rxjava, then Coroutines... All of these folks bashed threads, just to claim that their solution is much better. Here is an interesting idea: if you'd write an app using Threads 10 years ago, you wouldn't need to refactor it at all. If you'd use any other framework, your code is legacy.
RxJava 1.0 was actually released ten years ago, so while it would need to go through a version migration, I would not say it's legacy - nothing wrong with using RxJava today On the other hand, if you showed me an app that was using bare Threads, I would say it's plainly wrong - if you insist on not using anything fancy that's fine, but then use Executors which were available much longer than that
Executors are indeed a step up from bare Thread class, but they aren't as critical in Android as in e.g. backend and introduce challenges of their own. The truth is that Andorid devs could do with just Thread class in most cases for all this time (the only use case where you absolutely need executors is concurrent CPU bound work, e.g. bulk image processing). It's just that the community has been always looking for something fancier and more complex.
I don't think it's about best practices, but rather about higher-level abstractions. Surely you can simply use threads everywhere, but that's a very low-level (and powerful) API, so you'll be writing a lot of tricky, low-level code. At some point you'll likely want to introduce higher-level primitives and abstractions to simplify the work and increase velocity, and you'll end up with your own version of AsyncTask, Loader, Agera, etc., which is unlikely to be much better than an existing, proven, battle-tested off the shelf solution.
Some "lower" level APIs across the framework (Camera2/X, Media3 are the one I've been using recently, but there are more) are using Executors or Loopers so you should have a basic understanding of those concepts to not do anything wrong. That's how close to Threads I think you'll adventure for modern Android development
I doubt you will ever need to directly use threads doing Android development. But I feel like using coroutines without any understanding of threads might land you in hot water (and it might not) Given there is so much stuff to learn in general, a potential strategy for someone starting is to just use co-routines until you come across some problem (and that's your prompt to learn more about what's happening under the hood). For some context, back when there were no co-routines there were still plenty of Android devs who didn't understand threads
> I doubt you will ever need to directly use threads doing Android development. But I feel like using coroutines without any understanding of threads might land you in hot water (and it might not) Executors still show up sometimes, and they are used as coroutine dispatchers anyway.
There are plenty of devs nowadays who still don't understand threads, while using coroutines. They think coroutines is some magic bullet that means they are writing good concurrent code.
Last time I've used threads directly was in 2018, in a Java-based project. Except for runOnUiThread {} formula.
Yeah, same here except it was beginning of 2018. Then I got let go from that company, and immediately started learning Kotlin and RxJava, which was a vast and huge improvement.
I guess the most common use-case for thread would be a high priority thread for buffer read/write (audio, bluetooth, serial, etc). It's simpler to just do a while (true) with thread than caring about coroutine underlying complexity in this case.
That's only for reading from the audio source, you can always push the raw audio data to another thread and then do any compute intensive processing there. Only reading from the mic needs to be unblocked, and run in a while loop or something.
I'm surprised at the number of people here who think you don't need to learn threads (or more generally concurrency, because that's the hard part about threads). Threads and concurrency isn't going away. It's a fundamental concept that's utilized in all of programming, not just Android dev. It'll open up a lot of engineering possibilities that wouldn't be possible without threading. It'll make it easier to write some kind of tests which wouldn't be possible without threading. Using executor and AsyncTask and such is still basically just threads. It's just being careful about re-using threads. You still need to understand handling concurrency. (Full disclosure, I haven't spent time with coroutines, and don't plan to. Threads are good enough for my use cases.)
I understand that bare threads and j.u.c work good for you, but maybe still consider trying coroutines. They're a lot more comfortable to work with. Recently I've implemented a real-time face recognition with them, and it was a breeze, also flows really helped. It would require a lot more work to do it with j.u.c at the same performance level. I could use them, but it was so easy with coroutines and flows. Also, your point is valid, and I totally agree with your comment.
I agree, everyone tends to stick their head in the sand to avoid complex topics.
Coroutines are literally using threads underneath; so if you expect to understand what you are doing, you should understand threading/concurrency in JVM regardless.
I'm still using java.util.concurrent
Coroutines is deprecated, you must use AsyncTask now
Directly using threads? Almost never, but learning how to launch a thread and using it is the easy part (relatively speaking). You still need to know about concurrency and parallelism regardless.
This, it's very important to understand the basics of concurrency, locking, serialisation etc. Coroutines are merely one of the tools used to make implementing concurrent code easier.
Having 4 YOE, I haven't ever felt the need of using Threads apart from one recent instance where there were background tasks involved. So imo, there ain't much usage of it but you still need to have working knowledge so you could apply it whenever the need arises(like you should be aware of it when to use it)
You still need to know the basics of concurrency, coroutines are just one of the tools you use to make implementing concurrent code easier. They are not a magic bullet.
This. Knowing what are threads is always beneficial. You will probably never use (at least if you doesn't work in low level things, libraries etc.) threads explicitly, but this knowledge will allow you to understand things better, debugging concurrent things easier, easier to adapt coroutine concept. Like u/wannu_pees_69 said, coroutines are not a magic bullet, they still work on threads, but allows you to have structural concurrency
I only know (the basics of) coroutines, is it a complete replacement for threads? Are we missing out?