Skip to content
Related Articles
Get the best out of our app
Open App

Related Articles

Why Only the Original Thread that Created a View Hierarchy can Touch its Views in Android?

Improve Article
Save Article
Like Article
Improve Article
Save Article
Like Article

Firstly, we need to know about the properties of threads. Threads are nothing but different paths available to our android application to go through and complete a process. Threads are used to implement different processes at the same time inside an android application, you might have heard about it as concurrency. To understand this better let us take an example. If the main thread is fetching data from the server/online database it requires some time for this process, hence the main UI screen gets frozen. And if the waiting time is above 5 seconds, it will show the message: “The application has stopped working”. To avoid this error we carry out long-running tasks on threads other than the main UI thread. This makes the UI look smooth and untampered.

The issue with concurrent data modification

Android Studio has specifically denied the presence of race conditions by not allowing the altering of UI with the use of another thread. Many times you might have come across this error as well. Due to this error, the application shuts down abruptly when the task of the main UI thread is over.

android.view.ViewRootImpl$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views.
       at android.view.ViewRootImpl.checkThread(

What are Race conditions?

Now the example mentioned above is an example of a race condition where two threads race against each other to finish a task which results in bugs that cannot be anticipated and this results in a delay in production. 

If the main UI thread gets assigned a particular task and another thread is also assigned a task at the same time but both of them are carrying it out for the UI, here comes the catch, if the other thread completes its task before the main UI thread then it will alter the changes in the UI component which were meant for later. Still, due to the time taken by the UI thread to carry out its task, the UI gets updated at the wrong time and after that when the UI thread completes its task, it will mess up the configuration of UI components.

Solution to the issue

To rule this out there is a process carried out called Synchronization in JAVA. It uses a synchronized keyword to implement the same. In Kotlin we use synchronized methods as well. If the use of threads is unsynchronized, then the system depends on uncontrollable events that can occur anytime. This makes the code quite risky and hard to debug when we see it at the production level. This also makes the program thread unsafe as multiple threads are accessing the data at the same time.

We use many implementations like the above-mentioned synchronized method to avoid this condition. You might ask if there is a method defined as good as synchronization then what is the need for other methods? That is synchronization can lead to deadlocks in the code. 

Deadlock: It is a condition when two threads are waiting for each other, resulting in the UI being frozen and a deadlock.

To escape from this we use immutable datatypes such as “Val” in Kotlin, this leads to a reduction in the risk of concurrent data modification. But for Java this implementation is difficult. So we need to rely on different implementations for different languages as the last resort. You can also implement your thread inside the runOnUiThread() method in Kotlin/Java. Handlers framework can also be used to tackle this issue.

My Personal Notes arrow_drop_up
Last Updated : 03 Feb, 2023
Like Article
Save Article
Similar Reads
Related Tutorials