-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Xamarin.Forms.CollectionView Spec #3172
Comments
How about Scrolling event to support parallax headers |
There's a lot to love about this. FontIconSourceFor the FontIconSource though we really do need a way to not use the Unicode value (if we don't want to). If you're looking at a FontIconSource with a value On the other hand, if I can pick and choose what Icon Font's I'm using and give Forms a way to convert Lastly I would hope we could get a baked in XAML Extension for this so you might have something like: <Image Source="{FontIcon fa-app-store-ios,Color={StaticResource primaryColor}}" /> MenusAs I was discussing with @davidortinau earlier, it would be particularly ideal if we can mix and match on the Context Menus to achieve the appropriate results. Some good context on this would be to think of an email client in which you may get one menu when you swipe left and another when you swipe right. Another scenario I would love to see supported would be the cell menu approach like shown in the docs for the iOS CollectionView. EventsI think it's safe to say I'm biased, but a very large portion of the community is following an MVVM design pattern. Having the Since RemainingItemsThresholdReached just sends a plain old EventArgs I think we can safely assume passing null to the command should be fine since we just need to execute the command. For the SelectionChanged, I would tend to think it would be more vital to know the new items, vs the old items so simply passing the new items OOB to a SelectionChangedCommand should be fine. This may not hit every use case, but it at least provides a minimum amount of overhead that a developer needs to add with some EventToCommandBehavior. |
Perfect sample that kills current listview is making Calendar control where: |
How about also adding a GroupFooterTemplate? |
This is so much needed in Forms :-) CollectionView would eliminate expensive workarounds, solve limitations and probably improve performance in just about every Forms app I made in the past 5 years. Exactly the right approach too - leverage and expose the power of the native platforms. If there was only ONE enhancement I could request for Forms, this would be it. |
This is truly awesome and long awaited! The API is clean and straightforward (thanks for renaming HasUnevenRows !). Scrolling events are very much needed, as suggested by @dhaligas. For parallax animations but also to hide floating action button while scrolling for example. FontIconSource is a good idea. It might be great to provide a default list of icons, with unicode mapped for every platform (similar to iOS or UWP). |
This sounds like exactly what's needed. The API looks much cleaner, having multiple views/containers structured this way should help keep the code cleaner and simpler. My comments so far: @dansiegel A command when the Remaining Items Threshold is met would be welcome. Not sure it's needed for SelectedItems though - everything you say (notified of changes, what has changed, and even why) is handled automatically as long as SelectedItems is an ObservableCollection (or anything that implements INotifyCollectionChanged). I'd rather have as little code as possible in CollectionView to keep complexity down. Scrolling: I completely agree about the scrolling event. We can get it at the moment for Android, but for iOS you have to wrap the UITableViewSource and hijack the Scrolled method. Most important of all for me would be extensibility. Please don't use internal classes for adapters and TableViewSources, and please in the native renderers expose "CreateAdapter" and "CreateViewSource" methods (and similar for other platforms) where we can create our own type if we want to. We have a custom ListAdapter for drag and drop support on Android, and as mentioned before, a custom UITableViewSources for both scrolling and drag and drop. It's not code I like though because there's wrapping of internal classes etc. This doesn't just apply to adapters/viewsources. In general in the new API, please add points where we can extend behaviour if we need to. |
I think this is a really great and important feature! |
Just to get it out of the way, I love basically everything about This could be added later, but something like: public class MultipleFontIconsSource : ImageSource
{
public List<FontIconSource> Icons { get; set; }
} would be useful, to support stacking icons: https://fontawesome.com/how-to-use/on-the-web/styling/stacking-icons |
My feedback:
My idea is to have a CollectionView similar to the ItemsControl in Windows XAML. The ItemsControl takes a Panel instance which positions the items. In Forms, we'll have CollectionView and IItemsLayout. Beside item selection, there are other capabilities which I'd not put in the CollectionView, I'd add these to the ListCollectionView. For example, the CollectionView should not have scrolling. This way it will cover this thread
|
|
In case anyone is interested, I made some updates to my first comment above. |
I agree with @andreinitescu that it would be good to have a way to have a non-scrolling collection. I'm neutral on if that means breaking it into multiple classes or possibly having something like a ScrollMode property. I'll defer to those with a lot more API design experience than myself on that. But it is fairly trivial to implement your own StackLayout based item list with a DataTemplate or template selector, so maybe it's not needed. While I like the idea of controlling the scroll function, I'm also not coming up with any compelling use cases for a non-scrolling "Collection" that includes all the advanced features of ListView or the proposed CollectionView off the top of my head. My use case for a non scrolling list has always been solved by the trivial item list. My normal reason for not using a ListView is because I don't want selection or I want to horizontally layout the list. Both of those cases appeared to be covered by the proposed spec. I would be interested in any use examples anyone else has for no scroll. |
@bmacombe I agree with you that it's "simple" to implement a bindable StackLayout, but that's not the point I think. It's a very common functionality, why not have it in the framework? And with some planning, I think it can be done. Like I already said above, it can be solved by just spreading the functionality in two classes, a base class (similar to ItemsControl in Windows XAML) and CollectionView (ListView). Ideally there should be a Selector class in the hierarchy (see https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.controls.primitives.selector) |
I would say the trivial reason to have a non-scrolling option is that some pages need to have a ScrollView for the whole page, and a list of items. If you do that, right now it is not recommended to put a ListView in a ScrollView. A bindable CollectionView that you could put in there, that still potentially has all the features of a ListView, is something I have had a need for multiple times. I wrote the same BindableStack thing that everyone else does, but a baked in one would be much nicer to work with. |
@adammeaney That makes sense and I've done similar now that I think about it. |
@andreinitescu I don't disagree it would be great to have it built in. I think everyone is on the same page for what is needed, just how to best do it. I'm ok with either approach as long as there is a "no scroll" option of some type. In my own frameworks I always go back and forth in build lots of features into one control or have lots of similar classes with incremental functions. I'll be good with however the Forms team decides to implement it the best, especially considering the underlying platform implementations. |
@bmacombe With some planning, I'm hoping we can get two birds with one stone. |
My impression was that a new ListView should aim both fix challenges with existing ListView but also provide a solution to the "RepeatableBinder" thread here
I don't see how putting all the functionality in the CollectionView like the spec here suggests would do the job right. |
#2680 Could be added to this spec? With regards to ScrollBar enablement. |
On UWP, we'll likely be using RefreshContainer. On Android, probably SwipeRefreshLayout. |
It's a problem, but not a new one. We have the same issue with GestureRecognizer, ListView, Grid, and many other things in Forms. We struggled with this a bit internally; there are only so many possible names for "a bunch of items on a screen". "CollectionView" doesn't conflict with anything we currently have in Forms, it doesn't conflict with any UWP control names (the way "ListView" does), and it's not exactly like UICollectionView (because of the "UI" prefix). It's not 100% ideal for search purposes, but we feel like it's the best expression of the intent of the control. That said, if someone proposes an alternate name that we immediately fall in love with, I'm happy to do the search and replace. (I wanted to name it "ListView2ColonRevengeOfTheListView", but @davidortinau shot me down :) ) |
Take a look at the SwipeView spec - that's precisely what we're aiming for. |
That's a great point, we should support that if possible. I know it works with the built-in UWP glyphs; I'd have to do a little research to make sure that type of stacking would work on the other platforms (I suspect the answer is "yes"). |
CollectionView seems to be bugged on Android when using IsGrouped.
https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/collectionview/grouping |
|
Ops, I missed that part. Thanks. For those of us who want to display a grouped list on both iOS and Android, but want to avoid ListView, is there anything else that we can use that’s as flexible as the CollectionView for now? Or are we stuck with ListView? |
I hope this is the right place to ask. I see in the original posted spec there are properties for |
In collectionview we need ItemAppeared, ITemDisappeared. |
@IosDeveloperHarsh The |
@rafiwardak2003 Gallery samples with CollectionView groups work on Android as of today though I haven't run the sample you've provided. Which Nuget were you using? Try with the latest pre-release or nightly. |
@cabal95 I'm not qualified to answer this, but if I had to guess they will eventually be implemented. Perhaps, we need to have an active issue to track this. I do know that the initial header/footer work excluded sticky stuff. |
I think that SelectionChangedCommandParameter should be removed and instead we will have the selected item automatically set as a parameter. If it is possible it would be nice to use the property like this
But this should be ok as well:
|
What if the user wants to use something other than the SelectedItem as the parameter to their Command? |
You have a point, but I have hard to see a use case for that because you are setting the parameter on CollectionView level. I expected that it to be the selected item the first time I used it. But you maybe can set the selected item as default? If you use the event you will get so I think many developers expect it for the command as well. |
I'd like to also request for a feature that this CollectionView does not stretch up on the entire screen and just use the height depends on the number of item. I am trying to have a multple lists in view but Items 1 and 2 (a CollectionView) just took too much height even if the I only have 3 or 4 items and there is a BIIIIIIIIIIIIIIIG gap below before I can see the Deductions section I ended up making my own ItemsCollection control based on StackLayout |
I think what you are looking for may be Bindable Layouts. |
Hey! Exactly what I need. Since when BindableLayouts existed? |
* Move all the header/footer adjustment to IItemsViewSource fixes xamarin#7121 fixes xamarin#7102 partially implements xamarin#3172 fixes xamarin#7243 * Fix selection bugs introduced by header/footer on Android * Implement grouping for CollectionView on Android * Enable grouping tests for Android * Naming and comment cleanup * Update Xamarin.Forms.Platform.Android/CollectionView/ListSource.cs Co-Authored-By: Gerald Versluis <gerald.versluis@microsoft.com> * Update Xamarin.Forms.Platform.Android/CollectionView/ObservableGroupedSource.cs
…) partially implements xamarin#3172 * Finish ScrollTo implementations for CollectionView on UWP * Fix NRE when attempting to scroll to index greater than source length
* Move all the header/footer adjustment to IItemsViewSource fixes xamarin#7121 fixes xamarin#7102 partially implements xamarin#3172 fixes xamarin#7243 * Fix selection bugs introduced by header/footer on Android * Implement grouping for CollectionView on Android * Enable grouping tests for Android * Naming and comment cleanup * Update Xamarin.Forms.Platform.Android/CollectionView/ListSource.cs Co-Authored-By: Gerald Versluis <gerald.versluis@microsoft.com> * Update Xamarin.Forms.Platform.Android/CollectionView/ObservableGroupedSource.cs
…) partially implements xamarin#3172 * Finish ScrollTo implementations for CollectionView on UWP * Fix NRE when attempting to scroll to index greater than source length
Thank you everyone for the discussion on this issue! If you have any additional feature requests or bug reports, please open new issues for each one. We are now closing this issue. |
CollectionView
The current Forms ListView design and implementations are very complex and challenging to maintain, while often not providing the flexibility that users would like. Because of the complexity of the implementations and the backward compatibility requirements, ListView bugs can be difficult to find and fix.
The goal of the CollectionView effort is to address these problems by simplifying the API and embracing the capabilities of the native platforms' list-building controls. To that end:
CollectionView removes the concept of Cells entirely. While convenient in some cases, the Cell concept introduces a great deal of complexity into the native implementations of ListView. Everything that is possible with Cells can be accomplished with reusable DataTemplates.
CollectionView reduces the API surface. Several properties and events from ListView are not available in CollectionView. Several of these are easily replaceable within DataTemplates; others were very specific to particular platforms and never really belonged in the first place. A list of these changes can be found below.
CollectionView aims to be more flexible by not baking in assumptions about layout. This allows us to support layouts which users have long been asking for (e.g., a HorizontalListView) and which the native implementations already provide.
Note: Nothing in this document should be taken as an indication that the current ListView will be removed or will cease to be maintained. This effort is simply aiming to provide an alternative control which will more easily serve the needs of many Forms users.
Note: Nothing in this specification is guaranteed to be final; all features, implementations, and interfaces are subject to change.
Current completion status of the features specified below
Supporting APIs
In order to provide users with a more modern list, the CollectionView effort will include a some supporting APIs:
FontIconSource - using scalable glyphs as icons; the intent is to support glyphs whereever Forms currently supports images. This is obviously a desirable feature in many parts of Forms, but it's also absolutely essential to support contextual swipe gestures in CollectionView (see the FontIconSource spec).
SwipeView - Provides support for swiping on an element to execute or reveal further actions (see the SwipeView spec).
Layout Specification
This spec provides for the developer to specify whether items to be laid out in a vertical list, horizontal list, or a grid. The underlying native classes all support these layout types. (Note that on iOS, this spec assumes the use of UICollectionView rather than UITableView.)
The specifications given to the CollectionView are mapped to native layouts in each renderer. For example, if a grid layout is specified, on iOS the renderer will (by default) use a UICollectionViewFlowLayout. On Android, the default will be GridLayoutManager; on UWP, GridView.
Forms does not participate in the layout of the items in the repeater (beyond generating the items Views themselves); this portion of the layout is entirely native.
The selection of layout methods to use in each renderer will be user-modifiable; if a user would rather use StaggeredGridLayoutManager on Android, this could be achieved by modifying the selection method and returning the desired layout manager.
ListView API Removals
API
ContextItem
ContextItem provides a way to specify a contextual interaction, often displayed as part of a context menu.
Properties
Events
ContextMenu
Provides a way to specify a set of interactions to be displayed in a context menu. A ContextMenu can be provided for any VisualElement, and is activated/displayed according to the native platform conventions.
RefreshView
Moved to #5882
SelectionMode
Provides the selection mode behaviors for a CollectionView.
SelectionChangedEventArgs
Properties
IItemsLayout
Marker interface to indicate that the implementing class specifies a layout used by CollectionView to arrange its items.
ItemsLayoutOrientation
Enumerates the possible orientations for an
ItemsLayout
. As items are added, the CollectionView expands in the orientation direction.ItemsLayout
Base class for Forms-provided items layouts.
Properties
ListItemsLayout
Static Members
GridItemsLayout
Defines a multi-row or multi-column layout.
SnapPointsAlignment
Enumerates the possible alignments for snap points in a
ListItemsLayout
.Enum Values
SnapPointsType
Enumerates the possible behaviors for snap points in a
ListItemsLayout
.Enum Values
Properties
ItemSizingStrategy
Provides the possible item measurement strategies to be used by the CollectionView.
Enum Values
ItemsUpdatingScrollMode
Defines constants that specify the scrolling behavior of items while updating.
Enum Values
CollectionView
Displays a list of items.
Properties
MeasureAllItems
(the default), each item will be measured individually. In situations where the item size is intended to be uniform, this value can be set toMeasureFirstItem
; only the first item will be measured, and all subsequent items will be given the same size as the first.True
True
SelectionMode
ofSingle
. If the selected item is removed from the items source,SelectedItem
will be set tonull
.SelectionMode
ofMultiple
. If selected items are removed from the items source, they will be removed fromSelectedItems
andSelectionChanged
will be raised.RemainingItemsThresholdReached
event will be raised. The default value is -1, meaning the event will never be raised. A 0, the event will be raised when the final item currently in theItemsSource
is displayed. At values greater than 0, the event will be raised when theItemsSource
currently contains that number of items not yet scrolled to.Methods
Events
SelectedItem
orSelectedItems
properties change. This includes changes which occur as a result of changing theSelectionMode
property.RemainingItemsThreshold
items have not been displayed. This event can be handled to load more items.Scenarios
Chat Application
The developer has an app which has a chat client. Messages appear at the bottom of the list and scroll up off the screen. How can the developer achieve this UI with the proposed API?
In order to achieve this behavior, the developer should set the
CollectionView.ItemsUpdatingScrollMode
property toKeepLastItemInView
. If the user's scroll position is at the end of the CollectionView, the new items will appear at the bottom and will be scrolled into view. If the user's scroll position is elsewhere, the new items will appear at the bottom but the scroll position will remain unchanged.Snap to closest
The developer's app shows a list of real estate listings. As the user scrolls through the list the scrolling should be smooth until the user stops. When scrolling stops the app's interface should snap the scroll (animated) so that the top most listing is perfectly aligned with the top of the page. The snap should always be in the direction that produces the least amount of motion.
In order to achieve this behavior, the developer should use a
ListItemLayout
with the following settings:Orienation
:Vertical
SnapPointsAlignment
:Start
SnapPointsType
:Mandatory
TableView
The developer wishes to recreate a settings page using a TableView like appearance.
The developer will want to use a ListItemsLayout with a Vertical Orientation. The ItemsTemplate should be set to a DataTemplate which recreates the look and feel of a table cell. If the "settings" interface is meant to address more than one type of setting (e.g., if some cells are meant to toggle a setting on/off and others are meant to navigate to a secondary settings screen), then the developer may wish to create a DataTemplateSelector which implements a DataTemplate for on/off settings (with a toggle switch) and a DataTemplate for navigation (with a TapGesture which pushes the secondary settings page onto the navigation stack).
Infinite Scroll
The developer has an app which shows a "news" feed. The "news" feed has an infinite number of potential items so when the user nears the end of the current loaded set of data the app needs to make an asynchronous call to the server to load more data. It is critical to the app that data be loaded before the user would see either blank space or be stopped from scrolling within the limits of network latency/bandwidth. How can the developer achieve this with the proposed API?
To achieve this, the developer should set the
RemainingItemsThreshold
property and handle theRemainingItemsThresholdReached
event. When the event is raised, the handler can make the asynchronous call to the server to load more data into the underlyingItemsSource
.The text was updated successfully, but these errors were encountered: