[Proposal] Implement CollectionViewSource

[MelbourneDeveloper]

Description

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

An article: https://www.hanselman.com/blog/CollectionViewSourceIsCrazyUsefulForBindingToFilteredObservableCollectionsOnWindowsPhone8.aspx

[StephaneDelcroix]

ListViews, Pickers and some more controls already listen to INCC events

[MelbourneDeveloper]

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

[MelbourneDeveloper]

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.

[AceCoderLaura]

INCC != CollectionViewSource

[StephaneDelcroix]

is there anything preventing you from writing your own CollectionViewSource ?

[StephaneDelcroix]

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

[PureWeen]

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.

[MelbourneDeveloper]

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

[MelbourneDeveloper]

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/

[MelbourneDeveloper]

@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

[Sasino97]

This is absolutely needed.

[MelbourneDeveloper]

@jassmith thanks!

[andrewjehome]

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

[RPHEngineering]

Definitely needed, this is a very useful item in WPF that is painfully missing in Xamarin.

[larthallor]

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?

[GlebObodovsky]

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.

[JunkyXL86]

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.

[MappingSteve]

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

[jbhaywood]

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.

[acuntex]

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

[nk54]

I would love to see that class available. Like @MelbourneDeveloper said, each control provider (SyncFusion, Telerik, DevExpress, etc) will provide their own implementation and own control. It means that if you use one, you are locked with it otherwise you might lose some features etc. Having a standard CollectionViewSource will help us to reduce the dependency to a provider. It will be easier to migrate from one to another. Moreover, it will be possible to share the CollectionViewSource between several project (assembly ViewModel being shared by Xamarin.Forms and other platform such as WPF, etc). My team had to create our own implementation, but IMHO, we sometimes face crash hard to repro or to debug because of it.

I know, adding this class won't make a "woaw" effect when released (compared to Shapes or CarouselView or CollectionView etc) but it will be loved by those who work on B2B app where a lot of filter/grouping are needed.

Thanks for your time !

[greatoceansoftware]

LINQ sorting, filtering and grouping on the underlying model collection is definitely not the answer. CollectionViewSource allows you to have multiple views of the same underlying collection, all sorted, grouped and filtered in different ways. And each can be bound to a WPF view, and the view responds to all changes to the underlying collection OR the grouping, sorting, filtering changes on the top-layered CollectionViewSource. It's feels very much like working with SQL views instead of tables. Sooooo nice to have. Please implement an equivalent for Xamarin. I'm hoping it's also available in MAUI.

[jfversluis]

Thanks for this suggestion! As Xamarin.Forms is now in maintenance mode, this will not happen anymore for Xamarin.Forms. We're only adding bugfixes and stability fixes.

If this is still important to you, make sure to check the .NET MAUI repo and see if it's already on the roadmap. If not, feel free to open a discussion to discuss a change first or open an issue with a detailed feature request. Thanks!

[AceCoderLaura]

MAUI issue here: https://github.com/dotnet/maui/issues/3837