A solution for propagating SQLite data changes to UI during sync?

We have a background process that runs every 5 minutes to keep data in sync with SQLite, the problem I'm running into is propagating those changes to the UI.

I can't imagine I'm the first one to try and solve this, so I'm curious how other people are solving this?

My current thought it to fire an "Invalidate" message via MessagingCenter. My ViewModels are subscribed to this message and requery SQLite for their data upon receiving. The only issue with this is with the ListView and the user experience when the list refreshes out from under them. Is anyone doing any sort of deep comparison between the stale data the UI is bound to and the fresh data that is coming from the database?

Answers

  • JohnHardmanJohnHardman GBUniversity mod
    edited January 2018

    @EricWalter - Assuming you are using MVVM, when your background process updates SQLite, have that happen by having the background process update your Model (which then updates SQLite). When a value in the Model is changed, the Model should raise PropertyChanged for the property that changed. Any ViewModels that use that property should be watching for the PropertyChanged event. When the ViewModels see the event raised, they should update themselves with the new value and then raise PropertyChanged on any of their own properties that change as a result. Any Views using properties of the ViewModel(s) should be updated as a result of binding the Views with the ViewModel's properties.

    As always, there are variations on this, but that will work.

  • EricWalterEricWalter USMember ✭✭

    @JohnHardman Here's the tricky part, this is an app that is designed to go offline, so we pull the entire "blob" of data, delete everything out of the database, and insert the new data that came from the API. So I need a way to only add, delete, or update models that have actually changed.

  • JohnHardmanJohnHardman GBUniversity mod

    @EricWalter - If using a Model layer, I would expect the setters to only do anything if the new value is different to the current value. The same would apply with collections in the Model layer, with CollectionChanged only being fired if something has changed.

    If you have access to Xamarin University, checkout the class "Data Caching + Synchronization" [ENT410]. If you haven't got access, sign up for a month.

Sign In or Register to comment.