0

In android, some codes, such as updating UI buttons, needs to be called in UI thread, however, before UI update, some task, such as getting response from internet, need to be done on another thread, here is the most common form of response callback I see:

public void httpResponseCallback(String responseString){ MyFragment.this.getActivity().runOnUiThread(new Runnable(){ @Override public void run(){ if(responseString==null || responseString.isEmpty()){ showErrorDialog(); }else{ List<String> nameList=this.parse(responseString); if(nameList==null){ showErrorDialog(); }else{ updateUI(nameList); } } } }); }

But I think this callback is not good enough, because some codes doesn't require to place inside runOnUiThread, so I think the following form is better:

public void httpResponseCallback(String responseString){ if(responseString==null || responseString.isEmpty()){ MyFragment.this.getActivity().runOnUiThread(new Runnable(){ @Override public void run(){ showErrorDialog(); } }); }else{ final List<String> nameList=this.parse(responseString); if(nameList==null){ MyFragment.this.getActivity().runOnUiThread(new Runnable(){ @Override public void run(){ showErrorDialog(); } }); }else{ MyFragment.this.getActivity().runOnUiThread(new Runnable(){ @Override public void run(){ updateUI(nameList); } } } }

After refactoring, at start, I think it would be more logical because:

  1. It reduce unnecessary workload on UI thread
  2. It give hints to other teammates that which functions or codes need to run on UI thread

But later when I read the code again, I found the code is far longer than the original one because of extra runOnUiThread to type, so my question is, is wrapping all codes into runOnUiThread better than using runOnUiThread only on UI related code?

Improve this question
3
  • 2
    Where do you stop? What if showErrorDialog or updateUI also contain code that doesn't need to execute in the UI thread? Commented May 16, 2017 at 6:21
  • If you use lambdas it's likely to look a lot less horrible Commented Feb 6, 2024 at 16:53
  • If you push the null / empty checking into this.parse, then you can lift that out of the UI thread, and then there is less reason to split up the UI work. I might rearrange that into Either<List<String>, Error> parse(String response) and void Display(Either<List<String>, Error>), which starts to have the benefits of your option 2 Commented Oct 7, 2024 at 9:43

2 Answers 2

Reset to default
1

Based on my experience you shouldn't put the codes that are irrelevant to UI inside the runOnUiThread {} block. for example when you need to check the MediaPlayer status (playing or stopped) inside a thread, if you put the MediaPlayer.isPaying() statement within a runOnUiThread{} block you will be encountered with a not responsible behavior in your android application.

Improve this answer
2
  • It's unlikely MediaPlayer.isPlaying will block the ui thread. Commented Sep 8, 2023 at 20:14
  • @Ccm i tested it and it is responsible Commented Sep 8, 2023 at 20:17
0

Never, ever, ever wait for anything on a UI thread. You call an asynchronous method to read data from the internet, which might take some time, pass a callback method, and that method runs the rest of your code on the ui thread.

Improve this answer
1
  • Where in the snippet do they call an api? (Its implied to happen before the call, but that's not on the UI thread either way) Commented Feb 6, 2024 at 16:52

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.