Asynchronism in mobile

In Android, asynchronous tasks are done to avoid long operations in the main thread. Android documentation gives a good advice to the community to avoid ANR (Android Not Responding):

Therefore, any method that runs in the UI thread should do as little work as possible on that thread. In particular, activities should do as little as possible to set up in key life-cycle methods such as onCreate()and onResume(). Potentially long running operations such as network or database operations, or computationally expensive calculations such as resizing bitmaps should be done in a worker thread (or in the case of databases operations, via an asynchronous request).

Keeping Your App Responsive – How to Avoid ANRs

The point is that long operations like network, file system or database can freeze the UI, and that these kinds of operations must be done in a worker thread rather than in the main thread.

What is often misunderstood here is where to put asynchronism. The most current pattern is to protect the UI from long operations. Thus, long operations are wrapped with AsyncTask, Service, Thread, Executor or libraries which can be called asynchronously.

Link to octo’s blog: https://blog.octo.com/en/asynchronism-in-mobile/