On Friday, January 16, 2015 at 8:30:18 AM UTC+11, Nathan Barraille wrote: > > - Go the way I think the Android framework is supposed to work, and > notify change on all content URIs whenever a track has changed. This will > force the loader to re-run and refresh data from the database. >
This is often a bad idea, especially if there is remote data. > - Have my Adapter or fragment subscribe to the event bus and update the > model from the list when something changes. This can work, but means I > can’t use Cursors and CursorLoaders anymore, as I can’t change a cursor’s > data. Plus it’s not really DRY because I have to implement this in all the > fragments/adapters that handle list of tracks. An option that would work > with cursors is to keep a map of changes since the data was loaded in the > fragment/adapter, and override the stale data with this when creating the > views. But that seems hacky > Depending on the nature of your data, consider creating an abstract class based on an Adapter that handles the subscription. This can restore DRY-ness. I have also used bare-bones cursors that retrieve rowid and a couple of other things, then filled in extra details from the DB when the row is displayed. Again, not good if data is remote, but perhaps you just cache the remote components of the data. > - Have a model manager that keeps track of all the models in use. This > manager can subscribe to the event bus and update the models as needed. > Because all the components of the app are getting their models through this > manager, they will all share the same instance of the model and the data > will always be up to date. This seems complex to get right, as I need to > implement reference counting and concurrent thread access/modification. > This is my favorite solution so far, but it feels like their should be an > easier answer to such a common problem. > This seems pretty robust once you get the base class(es) working, but you will still have to inform the relevant views to refresh themselves. > I'm sure some of you have been confronted to a similar problems already, > how did you solve this? > In these situations I suspect the actual solution should be based on what you think you will be doing with the app in future. Lots of remote data suggests the manager option because you will want async updates with a local cache. Mainly local data with static remote data suggests the base-bones adapter. And other solutions become relevant in other circumstances: eg. if remote data is highly dynamic, and/or dynamic data is only ever local etc etc -- 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.
