I agree. The method has no real business being on an activity though right? 
It only promotes bad code.

How would you end up on a background thread on an activity? Perhaps you are 
using your activity to ferry calls from model object A to model object B 
and object B requires you to be on the main thread. Wouldn't you be better 
gluing them together with another component. I would assert this is a rare 
case and runOnUiThread is a convenience method for this case, but how 
convenient is it really compared to the inconvenient mistakes it causes 
people to make.

At the very least, why is it not a method on Context? I would say its 
presence on Activity does imply it is intended for making changes to views. 
In fact, here's a blog from 2009 telling you to do just 
that: http://android-developers.blogspot.co.uk/2009/05/painless-threading.html


On Wednesday, 10 June 2015 08:24:27 UTC+1, Doug wrote:
>
> Calling runOnUiThread doesn't necessarily imply that you need to make 
> changes to an activity or its views.  If you just need to make sure some 
> code is executed on the main thread for whatever reason, then it's OK to 
> use this.  It's morally equivalent to scheduling a Runnable on a Handler 
> attached to the main thead, and there could be any number of reasons why 
> you need to use the main thread instead of another thread.
>
> However, if you do need to make changes to an activity or its views, this 
> is not the best method to call.  There are other mechanisms like Loaders 
> that are probably better solutions for the particular problem.
>
> If you just need to schedule a unit of work to run on the main thread 
> without respect to any activity or view, I think this should be seen as a 
> reasonable convenience to do so.  It's just too bad that runOnUiThread this 
> is a method on Activity because that could be misleading to the caller.
>
> Doug
>
>
> On Tuesday, June 9, 2015 at 11:39:13 AM UTC-7, Sam Duke wrote:
>>
>> Due to the nature of config changes, the runnable submitted to 
>> runOnUiThread may be executed after an activity has been destroyed (i.e. on 
>> a stale activity). Therefore this API can cause all sorts of subtle bugs 
>> with config changes and events never reaching the UI. I can't think of a 
>> single case where it would be safe to use this. You should already have hit 
>> the main thread by the time you are doing anything inside the runnable... I 
>> think all it does is encourage poor patterns...
>>
>> Given this, is it not time to deprecate this API?
>>
>>
>>

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to