Thanks for your answer Grunthos. I thought about using an abstract Adapter and inheritance to be as DRY as possible, but more than DRYness I guess, I'm just thinking that I shouldn't have to worry about this when writing the adapter, and this is a common problem that should be handled by the framework (or another component of the app, as there is no way to handle this properly with the Android framework). I thought about your bare-bones cursor that just return the ids, and I don't think this is recommended to access the database in your Adapter#getView() method, as this will make scrolling slow and not smooth.
I was also looking at ORMs that provide a Cache functionality that reuse models instances and auto-refresh the objects when they are updated. ORMLite and GreenDAO support this but only for objects that are inserted in the DB: http://ormlite.com/javadoc/ormlite-core/doc-files/ormlite_5.html#Object-Caches http://greendao-orm.com/documentation/sessions/ On Thursday, January 15, 2015 at 1:30:18 PM UTC-8, Nathan Barraille wrote: > > Hi > > I’m working on a fairly big Android app with a lot of fragments and > activities. > These fragments and activities present views that are representing the > state of models. Whenever the state of a model instance changes, I need to > reflect that change on all the views that represent this model. > > Let’s say for example I’m coding a music App, and I have a > TrackListFragment that is a list of all the tracks, and a > PlayerFragment which displays a single track. When I click the “Like” > button on the player, I want the view of the player to reflect that change, > but also the view of that track in the tracklist to update. > > For this, I have an event bus where I post a message, and I have both > views (or their controllers) subscribe to that bus, receive this message > and update their state. This works, but doesn’t handle the case where the > view is out of the scrolled area in the list view, and when scrolling back > to it, the adapter is gonna re-create the view with stale data and won’t > reflect the change. > The options I’ve thought about are: > - 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. I don’t like > this because refreshing the whole list for a change on a single track seems > like overkill. Plus that assumes that my data is always loaded from the > local database, which is not always true. > - 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 > - 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. > > I'm sure some of you have been confronted to a similar problems already, > how did you solve this? > > Thanks! > Nathan > -- 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.
