The main XAML based Microsoft technologies such as Silverlight, WPF, and UWP have a class called CollectionViewSource. Xamarin Forms does not. The INotifyCollectionChanged interface is a very important interface between models and the user interface. The interface enables the UI to refresh without completely clearing the elements of a list of items and rebuilding those elements from scratch every time an item is added or removed. This improves performance and responsiveness.
CollectionViewSource is aimed at providing a common implementation of INotifyCollectionChanged across technologies, and also at providing common filtering and sorting functionality across controls via the INotifyCollectionChanged interface. When CollectionViewSource is not available, a control must implement filtering and sorting by itself which is more or less a hack. For example, ListView has this property (https://developer.xamarin.com/api/property/System.Windows.Forms.ListView.Sorting/).
CollectionViewSource providers a layer of abstraction for filtering, grouping and sorting so that any control that implements does not need to re-implement the functionality that already exists in the CollectionViewSource class. It also means that filtering and sorting can be applied at a level that does not affect the model. For example, if the sorting of a given list may cause some side affect if the underlying model is changed, sorting can still be achieved with CollectionViewSource because CollectionViewSource does not change the underlying model.
Many of the controls in the XF toolkit like ListView and Picker and so on will probably need to implement the functionality in some way. The most common use for the class on other platforms was for DataGrids but this does not exist in the standard XF toolkit. However, 3rd party controls like the SyncFusion DataGrid could be brought in to line with the standard Microsoft standards if those standards existed for Xamarin Forms.
MSDN Article
https://msdn.microsoft.com/en-us/library/system.windows.data.collectionviewsource(v=vs.110).aspx
WPF Samples
https://github.com/Microsoft/WPF-Samples/tree/master/Data%20Binding/CollectionViewSource
ListViews, Pickers and some more controls already listen to INCC events
@StephaneDelcroix , that's fair enough - as they should. But, what's required is well above what standard INotifyCollectionChanged functionality provides. As a basic point, INCC is not very useful without inline sorting of lists. If you bind to an ObservableCollection<> , how are you supposed to sort the contents? Well, you can do a manual bubble sort, but calling Enumerable.OrderBy(TSource, TKey) won't help because you'll end up with a new IEnumerable which will cause a full refresh anyway.
CollectionViewSource has always been a big part of XAML technologies to provide a solution to the problem I've just mentioned. Without it, we'd need to write code to sort lists like ObservableCollection<> to fire off sorting. But even then, the problem of side effects comes in. Without CollectionViewSource, XF is missing a huge chunk of functionality that comes standard with other XAML technologies.
This isn't even touching on filtering and grouping... Without this, all the XF controls, including 3rd party controls like SyncFusion will go off on their own tangent, and then none of them will be compatible with the standard system that has been a part of the XAML ecosystem since WPF.
As an aside, my bosses constantly put pressure on me to deliver configurable sorting, filtering, grouping and so on. So, we've delivered them partial solutions in our app with our own code. But, it doesn't provide anything like what used to be available in Silverlight, and WPF. We've been forced to use SyncFusion controls in places which deviate from the Microsoft paradigm completely to get the functionality. Time and time again, we experienced crashes and so on because of these controls so we cannot rely on them.
CollectionViewSource is a fundamental requirement of the XAML technology space.
INCC != CollectionViewSource
is there anything preventing you from writing your own CollectionViewSource
?
the only part I see missing is the ability for bindable objects in ResourceDictionaries to get an inherited binding context. This could be fixed, but it's very easy to workaround it by binding with a Source
none of them will be compatible with the standard system
What compatibility are you referring to? Just the general syntax that XAML has taken for CollectionViewSources ?
What size of collections are you operating against?
If you bind to an ObservableCollection<> , how are you supposed to sort the contents?
Most implementation I've seen use a ReadOnly proxy list.. ReactiveList, DynamicData, and I'm pretty sure CollectionViewSource does this as well with the ICollectionView it exposes. It doesn't operate against the Source list it projects the Source list to a readonly view. Small updates just get synced but then larger updates just cause a reset and refresh.
I realize if you're not a reactive fan this is a non starter but
https://github.com/RolandPheasant/DynamicData
Is amazing and I've never had an issue with it handling larger data sets
I marked this is proposal open cause I am a little curious about this one.
@StephaneDelcroix
is there anything preventing you from writing your own CollectionViewSource ?
There are implementations to consider on both sides of the class. I.e. the class itself needs to do sorting, filtering, and grouping, which yes, we could write ourselves. But, that's only a part of the equation. Controls need to implement logic to direct the sorting, filtering and so on. For example, in WPF, and Silverlight, DataGrids would interact with the CollectionViewSource when you click on the header of a given column. This would cause a resort by column. Xamarin Forms doesn't currently have an official DataGrid. But, a side effect of not having a DataGrid means that 3rd parties like SyncFusion have written their own DataGrid. There's nothing wrong with their DataGrid per se, but they have not decoupled their control with a standard Microsoft CollectionViewSource. All of their sorting logic is built in to their control and is not shared with any other controls. So, if we want their sorting functionality, we have to use their control, or nothing at all. Even if we did write our own full version of CollectionViewSource, we would still need to create something like their DataGrid in order to capture the column header click event, and set the sort column on the CollectionViewSource.
Xamarin Forms doesn't need to create a DataGrid for this to be useful. It can be useful for ListViews and Pickers etc. But, other controls and functionality need to be implemented. For example, in our app we have created something very similar to a CollectionViewSource on a basic level (intermediate class). We have created ButtonBehaviors that when attached, set the sort column on the intermediate class and allow for sorting independent of the base level collection.
This is a much larger piece of infrastructure than just one class. In the other XAML platforms, CollectionViewSource is not an isolated class. It interacts with other classes in specific ways. There needs to be a suite of controls, behaviors, commands and so on for this functionality. For example, there may be a, Action Sheet which displays a list of property names (by alias), and when the user selects an item from the list, the CollectionViewSource triggers a sort by that property.
If this isn't implemented soon, 3rd party controls etc. will further go off on their own tangent and pour more and more work in to hacky sorting/filtering functionality that is specific to each control. Code will not be shared across List type controls and this will be generally bad for Xamarin Forms in the long run.
Here is an example of sorting functionality that has been implemented for a specific control, but that functionality is not shared with other similar controls: https://developer.xamarin.com/api/property/System.Windows.Forms.ListView.Sorting/
@PureWeen , what about this issue needs info? CollectionViewSource is a Microsoft standard across XAML based technologies. What more info do you need?
Sorry, I must have missed your question here.
What compatibility are you referring to? Just the general syntax that XAML has taken for CollectionViewSources ?
Across WPF, Silverlight, and UWP, controls that implement CollectionViewSource work in the same way. When a 3rd party control (e.g. SfDataGrid) is introduced to fill in the hole of the missing CollectionViewSource, it brings with it sorting, filtering and grouping that is not compatible with standard Microsoft XAML based CollectionViewSource functionality. It will always be peculiar to the 3rd party that builds the control
This is absolutely needed.
@jassmith thanks!
Come on guys, this is so needed. Rebuild a list because a filter or order has changed is so clunky.
See here: Not really the best solution.
https://forums.xamarin.com/discussion/32481/observablecollection-with-filter
Definitely needed, this is a very useful item in WPF that is painfully missing in Xamarin.
How does this feature request interfere with the new Xamarin Forms 4.0 CollectionView control, which is not at all the same thing as the WPF System.Windows.Data.CollectionView or System.ComponentModel.ICollectionView?
I am just starting to work with Xamarin Forms after years of experience with WPF. And I am very disappointed that there is no implementation of CollectionViewSource in Xamarin.
Came here because I was wondering if there is something like CollectionViewSource. Such features are crucial when considering which technology (like Xamarin.Forms) to use for building mobile apps.
As long as there is no built in support, I'll have to stick with my own implementation.
Unless I'm missing something, UWP's CollectionViewSource also lacks built-in sorting.
There is a UWP add-on AdvancedCollectionView in WindowsCommunityToolkit, that adds grouping and sorting.
I'm not familiar with the details; I just mention in case there is benefit in seeing what has been done there and/or coordinating a standard solution with people working on UWP.
Also, SO discussion of this UWP missing feature and some some attempts at enhancement..
Came here to throw my virtual hat in the "we need this" ring. Automatic filtering, sorting, and grouping are such a fundamental part of the WPF/XAML experience that I'm scratching my head wondering why it's even a question of whether or not it's needed here in Xamarin.
@jbhaywood It's totally needed, like a lot of other stuff.
Unfortunately something like a CollectionViewSource is not sexy enough so a Microsoft employee can brag about it in a blog post or at a conference. And since Microsoft doesn't even use Xamarin.Forms themselves for their products, they don't even feel the pain points of us developers.
Most helpful comment
This is absolutely needed.