To be fair, no one should be taking any advice about Android programming from a 6 year old blog!
Just don't use unOnUiThread if it doesn't suit the situation. I have no explanation why it's not fully deprecated, but the fact is that there are so many other recent techniques for managing background work. I teach them in my class at AnDevCon, and they have better support on the official Android documentation and tutorials. Doug On Wednesday, June 10, 2015 at 5:59:39 AM UTC-7, Sam Duke wrote: > > 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 [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.
