CODEWITHSUNDEEP
android
Pankaj Zanzane
Pankaj Zanzane

Reputation: 1242

Why UI operation must be performed on main thread in Android

AFAIK, android uses Single thread architecture, where all UI components event are dispatched,i.e. main thread or UI thread. But why we cannot perform UI operations on separate thread other than main thread?

Upvotes: 2

Views: 1460

Answers (2)

La Machine
La Machine

Reputation: 363

Well, first of all I need to state that this is a design level problem that has been discussed by many generations of programmers :)

Now technical details:

A GUI framework is a very complex thing. A GUI framework needs to display (draw) certain views (or windows) and route external (mostly user) inputs to the view that the input is targeted to. Now, to manage the screen with views with proper event dispatch to each view, all views shall be part of a graph and the simplest form of such a graph is a tree. So, you essentially have a tree of views to manage - where information should be fed to a root view from where your whole event routing takes place to child views.

Naturally, one dedicated thread to do manage this view hierarchy and event routing by monitoring a message queue to which all these drawing and input events are posted - by itself or any other threads - is a neat and simple solution. Any other solution that involves more than a thread will make the already complex view management and event routing code prone to dead/live locks.

Along with these technical details, you need to keep it in mind that you are trying to do business with a framework which is going to be used by other people who usually don't have faintest idea about the inner details of your architecture. Introduce threading support in such a framework is an open invitation for synchronization bugs (read: deadlocks, grumpy end users who are programmers AND ultimately bad business).

Android (and 99% other GUI toolkits) adopts this method. Simply because it makes things simpler and less error prone to have one main thread to deal with all error prone processing. All other threads are free to request it to do things by posting messages to the main thread's message queue. It is a balance between complexity and stability.

The only drawback of this approach is smooth updates of views - if you have many views to update simultaneously, OR your view hierarchy itself is really nested and complex. This drawback of this single threaded architecture manifest itself in pretty obvious forms in Android like:

  1. Animating multiple views simultaneously is never smooth - unlike iOS where they have taken the pains to move certain parts of this operation to more than one threads of execution.

  2. Android documentation need to remind the programmer all the time not to do lengthy operations in main thread AND to avoid deeply nested view hierarchies.

Upvotes: 2

GGC
GGC

Reputation: 100

The main problem is related to the context. In a background thread you could update some UI stuff which is not in the current context. This is one of the reason.

UPDATE:

From the Android developer guide:

Additionally, the Andoid UI toolkit is not thread-safe. So, you must not manipulate your UI from a worker thread—you must do all manipulation to your user interface from the UI thread. Thus, there are simply two rules to Android's single thread model:

Do not block the UI thread
Do not access the Android UI toolkit from outside the UI thread

You can read more on thread safety from [1] [2] and you can read even [3] with a small exmaple and explenation! Hope that now it is more clear sorry for the short and quick answer before :)

Upvotes: 2

Related Questions