Asynctask vs Thread vs Services vs Loader
Threads: Same as Java threads, use it to do heavy operations but you have to manage it on your own and it can also cause synchronization problems and you can't update UI from it until you are running it on the UI thread.
AsyncTask: A great threading library available in Android for doing background task. It is managed by the android OS itself, you can update the UI from it. It runs in parallel or serially depending upon the version of android. It can be messy sometimes to use it as in the cases of orientation changes and now for making network calls you can use volley which is better than AsyncTask. AsyncTasks do not bother about their parent activity is running or not and it can be quite tedious to sometimes cancel that. So, I would suggest you if you are using AsyncTask to make rest API calls better use RETROFIT or VOLLEY and if you choose RETROFIT between the two I would recommend you to have a look at PICASSO another awesome library from square for image loading.
Service: For doing long-term background tasks you should use services. You can bound the services to your activity if you need. You can define that they run in the same thread or a different thread and you need to declare it in manifest or you can use IntentService - a variant of service which runs in its own thread but be careful before using it, don't use it for long running tasks. It's a single time operator. If you are going to use service evaluate the case that which one suits your requirement better a normal Service or IntentService
Loaders: this is same as AsyncTask in many ways, it is advised to use loaders with the fragments and it solves the orientation problem of the asynctasks.
If you have already moved to kotlin I would suggest you to have a look at Coroutines.These are very lightweight and quite effective for threading and provide you a lot of control over the lifecycle.I hope this helped.
AysncTasks are not 'outdated' as much as they are incomplete.Among other things async tasks do not bother if their parent activity is currently running or not. For the same reason why you include checks for verify the context to be null or not. Besides, unless you are using your own Thread Pool Executor these tasks execute serially.
Volley tries to fill in those gaps, mainly concerning syncing up with the main thread and thread pooling. It behaves optimal if you wish to do stuff that requires average network requests; like some meta data list and images(picture the youtube app requests and facebook app requests for posts).
Typically few advantages of Volley are as follows
- It keeps the worker thread informed about the activity(Main thread)
- Easier resource prioritization you could provide priority to your download requests.A typical scenario would involve you giving priority to text over image.
- Effective request cache and memory management.
- Extensible
- It provides you an option to discard your request in-case your activity was shutdown or restarted.
- Simpler patterns for data retrieval as opposed to AsyncTasks.
Volley fares badly when it comes to streaming requests/video as mentioned at Google I/O.
I'm not exactly aware of robospice.Ps: If you have time on your hand see https://www.youtube.com/watch?v=yhv8l9F44qo
Here's a further read if you wish to go into other libraries with benchmarks for the same.Comparison of Android networking libraries: OkHTTP, Retrofit, and Volley
It doesn't really matter, what abstraction you use, it boils down to a Thread. So each of Android's async/parallel classes are using Thread/Executor behind the scenes, and have exactly the same potential problems, like locking, that the threads have.
The difference between then lies in its' usage. AsyncTask for example, defines a handy completion-callback - onPostExecute(). A CountDownTimer allows you to control the time and so on.
You can use a plain Thread of course, but in this case you have to invest more time in catching possible problems yourself.
So, Android provides you with a couple of right tools for right jobs.