Add a INotifyCollectionChanged adapter around RealmResults

[fealebenpae]

No description provided.

[AndyDentFree]

Why is this called Reset? Is that a convention for this kind of messaging? It doesn't make sense to me but I'm far from being a Reactive Thinker

[fealebenpae]

I'm not sure what you mean - NotifyCollectionChangedAction is a framework enum.

[AndyDentFree]

The naming as Reset sounds weird, found a reference which explains it "The content of the collection changed dramatically". and I accept it's MS weirdness rather than yours, so no problem.

[nirinchev]

While I can see the reasoning behind resetting the collection on remove, it appears to be kind of restricting. In a hypothetical scenario, where I have bound a UITableView to the observable collection, to remove a row with a nice animation, only the index of the deleted item would suffice. With the current implementation, I would imagine the removing will be instantaneous at best and flickering at worst.

Obviously this will break the expectations of classic CollectionChanged subscribers, so it could be an opt-in behaviour, similar to coalesceMultipleChangesIntoReset.

[fealebenpae]

@nirinchev oddly enough the Xamarin.Forms ListView does not (noticably) repaint when a CollectionChanged event is raised with a Reset action.

Right now the Xamarin.Forms ListView is the only consumer of INotifyCollectionChanged that is likely to use this adapter, so its functionality is sort of tailor-fit. However, in the UITableView scenario you should use the RealmResults<T>.SubscribeForNotifications API directly which gives you a changeset with the indices that have been added and/or removed which is exactly what UITableView needs.

I'm wary of making ToNotifyCollectionChanged too configurable. I believe SubscribeForNotifications is what developers should use in scenarios outside Xamarin.Forms.

[nirinchev]

Makes sense. I was thinking about MVVMLight's ObservableTableViewController - if Realm's adapter were to emit delete events, consumers of the MVVMLight toolkit would be able to bind directly to it. As for SubscribeForNotifications, it is aligned with the classic Obj-C way of doing things, but I don't think it fits very well with MVVM where the iOS ViewControllers are dumbed down to views (although I don't know if that's the cool way of doing Xamarin.iOS/Android development).

Anyway, if you're primarily targeting Forms currently, it doesn't make a lot of sense to go out of your way and pollute the API to support a scenario of questionable business value, just wanted to give you some food for thought for future developments :)

[fealebenpae]

@nirinchev thanks, your input is much appreciated.

Personally I hope that the base API provides the tools others would need to come up with specialized adapters for various scenarios, such as when targetting MVVMLight or RxUI.

[kristiandupont]

👍