The single thread game !!

(By Mario Linares-Vásquez)

(Free photo by amirali mirhashemian on Unsplash)

---

A recipe for a very bad bad ...bad....bad user experience is to design apps that get blocked while the user is waiting for a response. So, how to avoid this? Easy cake... use asynchronous programming in your apps; it does not matter whether it is a web, desktop, or mobile app, use asynchronous programming. The good news is that there are different approaches and libraries available for implementing asynchronous programming such as multi-threading, callbacks, promises, reactive extensions, and coroutines. However, in the case of mobile apps we must be specially careful because current mobile operating systems and frameworks enforce the single-thread policy for mobile apps and are very conservative in terms of the time that a process is run on the main/GUI thread. Not all the asynchronous programming techniques allow for offloading work from the main thread.

Dude, what does it mean? It means that mobile apps, by default, are executed in only one thread. When a mobile app is launched, it is done on a sandboxed process that is provided with a main thread. There is also a work queue in which all the events generated by the user (e.g., a tap) and the system, and the code of you app are queued to be retrieved and executed by the app main thread. Thus, every task in your app is executed on the main thread, by default, including GUI painting and events handling. So, what is wrong with this? Well, no big deal, but, the things get complicated when you overload the main thread with long-running tasks.

Let us explain you the problem with a simple game: the single-thread game: you are an app and one of your friends is the user; the purpose of the app (i.e., you) is to answer any type of question or execute an action (as in a normal conversation); the user writes the requests in cards (one request per card) and put the cards in a box that allows you to retrieve the cards in a FIFO way (first-in-first-out), i.e., the cards are in a queue and you always get the first in the queue. Once you (the app) gets a card, you read it, and then you answer/execute the question/action in a time lower than 5 seconds; remember that you can execute only one action at a time, because you only have a thread. If you do not provide any type of feedback to the user in a time before 5 seconds, then you lose brownie points with your friend. Your goal is not to lose your user; you must give her a very good experience during the conversation. This is a first batch of requests you got in the list, each card has the order in the queue (assume there is an interdelay time of 4 secs between each request):

So, are you ready to play the single-thread-game? Let´s say you can serve the first three requests in the list without any issue. The fourth one, we trust you know how to dance Macarena. But starting on task 5, probably you will lose your friend because each task from 5 to 8 will take more than 5 seconds to get done, you will suffer of GUI lags because you are not giving feedback to your user quickly and by the time you serve the last request...you will need to find one more friend because you have suffered of an embarrassing ANR.

Dude what is wrong with that user !!! La macarena ? Teddy Bear ? Who is Osvaldo Farrés? What !!!

How could you improve your single-thread-based performance to avoid losing your user? The answer is in combining asynchronous workers with GUI feedback. Take a look to the next section.