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 [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.
