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 [email protected] To unsubscribe from this group, send email to [email protected] 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
