Why learn java.util.concurrent if you are writing for Android?

Question

Java

I recently had an interview for the position of Team Lead for Android. There were two technical interviews with different people who were actively interested in knowledge of Java Concurrency. I immediately honestly said that I had not even considered java.util.concurrent and had a very vague idea of ​​​​its contents (I passed the interview, but this is not about that).
Why would I, as an application developer (specifically applications, not general-purpose libraries), need knowledge of this package?
Need to run some heavy task in the background? Service+HandlerThread.
Need to fire multiple REST requests? Let's connect Robospice+Retrofit, everything is already written there. Or we will learn RxJava, and we will scatter tasks across different threads using subscribeOn()/observeOn().
And so on and so forth.
Of course, I decided to get a general idea, for which I read the first volume of Core Java (with a close study of the last chapter), next in line - "Java Concurrency in Practice", and, to a heap, "7 Concurrency Models in 7 Weeks" ( it's not really about Java, it's more for the big picture), but the question remains. How often do tasks arise in Android applications that require good knowledge of standard Java parallel programming techniques and primitives - volatile, ReentrantLocks, syncronizers, concurrent collections, ExecutorServices, and so on? Maybe it's me sitting in my swamp doing very simple tasks without knowing it?
PS Even in Core Java, Kay Horstmann writes that many tasks can be reduced to using concurrent collections, and tricks with volatile/implicit locks/etc are very rarely useful.
PPS I'm not interested in general answers like: "It is used often, let's learn", or: "It is rarely used, quit this business, go get better unit-testing", but examples of tasks in which you needed to use the package mentioned above.

Answer 1

1 BlockingQueue music player, there is a queue from which tracks are played, the player takes the track from below, the user puts new tracks into the queue from above. work with queue goes from different flows.
2 file downloader, queue of files for downloading, settings can adjust the number of simultaneously downloading streams
3 CountDownLatch is an excellent tool for counting the remaining time
4 CyclicBarrier is a crazy mechanism for waiting for the completion of several threads, site parsing,
downloading files, word processing, counting data or games
5 I use Executors and ExecutorService to quickly organize a pool of threads for working with sqlite,
as well as ScheduledExecutorService to organize a timer to check if something has changed on the user's device
6 useful thing Exchanger, instant implementation of the task producer - consumer
7 ConcurrentHashMap is generally a classic for organizing hashes, it now has LRU, but it didn’t exist before. And there was WeakReference and experiments with WeakHashMap
8 Atomic queues and hashes, they easily allow you to create thread-safe variables, used AtomicBoolean as an inter-thread state.
I know that there are offices, both large and small, do not use Retrofits, robospics, DI frameworks, and so on.
Given the problems with 65k dex, due to the cloud of third-party and especially play services, it is already difficult to assemble.
And for a small task, is it worth dragging a lib with you, the question is holy
And it's worth knowing java.util.concurrent because it's used in libs. The same volley, there are three pure Thread threads for doing http, and in ui it is forwarded through the handler and Executor

Answer 2

like AsyncTask, it's built on FutureTask and other classes from juconcurrent , and might not suffice.

Answer 3

I'm sorry, but... I don't know... But I want to ask... Purely out of selfishness)))) a person with what skills would you like to see in your team? It's just, excruciatingly painful to look at the huge variety of technologies in job openings (beyond sdk/ndk)

Answer 4

Learn, because knowing how the same Services works and dispatching in Rx will greatly help if you encounter a situation in which the use of one or another element that is not described in the User Guide is required.

Answer 5

Such questions tormented me for a long time (some even still).
In Android, all asynchronous mechanisms are based on Thread. However, it is highly desirable (all practitioners talk about this) to use higher-level "native" Android mechanisms.
And yet, with all the desire, it will not work to avoid a collision with java-concurrency.
Service - which is always in operation (for example, stream video, vpn, etc.) and you also need to manage this process on the fly (suspend / interrupt / continue, etc.)
If you carefully study the ServiceHandler - you will understand that this is not appropriate solution in this case. Here only from Service to be inherited - well, further along the chain -
- in the main thread (onStartCommand) - you can't, you need a Thread, and if another command comes, then don't spawn threads - it's better to have an Executor, and so on. etc.
Further - Content Provider , which does not go to the database, but to the network (here a big bummer was waiting for me)
It turns out that NetworkOnMainThreadException is not only about the network in the activity,
it is generally about the network in the main (even if not the UI thread) - therefore, in any case (at least Service, at least Content Provider, etc.) - you have to get away from the main thread (at least for requests to the network)
Regarding the Content Provider - you can’t go to the network directly in the method (qeury/openFile/etc) ( NetworkOnMainThreadException) but you also need to wait for the response right here (synchronously) - these are the dances of Callable's, Future's
So with all your (and mine too) desire to act at a high level, without bicycles - alas, it is not always possible