Как насчет события Scrolling для поддержки заголовков параллакса

В этом есть что любить.

FontIconSource

Для FontIconSource нам действительно нужен способ не использовать значение Unicode (если мы не хотим). Если вы смотрите на FontIconSource со значением f370 вы понятия не имеете, что это должно быть.

С другой стороны, если я могу выбрать, какой шрифт значков я использую, и дать Forms способ преобразовать fa-app-store-ios в его Unicode-эквивалент f370 , теперь я могу сразу узнать что я использую значок из Font Awesome, а это значок в iOS App Store. Я ни в коем случае не говорю, что формы должны иметь это понимание для каждого доступного шрифта (или любого другого, если на то пошло), которое может исходить либо из каких-то общедоступных источников, либо быть добавлено в Community Toolkit и т. Д. В любом случае нам нужен способ использования значимых имен.

Наконец, я хотел бы надеяться, что мы сможем запечь расширение XAML для этого, чтобы у вас могло быть что-то вроде:

<Image Source="{FontIcon fa-app-store-ios,Color={StaticResource primaryColor}}" />

Меню

Как я обсуждал с @davidortinau ранее, было бы особенно идеально, если бы мы могли смешивать и сочетать в контекстных меню для достижения соответствующих результатов. Хорошим контекстом для этого было бы подумать о почтовом клиенте, в котором вы можете получить одно меню, когда проведете пальцем влево, а другое - если проведете пальцем вправо. Еще один сценарий, который я хотел бы видеть поддерживаемым, - это подход с использованием меню ячеек, как показано в документации для iOS CollectionView .

События

Я думаю, можно с уверенностью сказать, что я предвзят, но очень большая часть сообщества следует шаблону проектирования MVVM. Наличие событий SelectionChanged & RemainingItemsThresholdReached важно для API, но было бы фантастически, если бы мы смогли найти способ поддержки этих OOB с помощью ViewModel версии обработчика событий ... ICommand.

Поскольку RemainingItemsThresholdReached просто отправляет простой старый EventArgs, я думаю, мы можем с уверенностью предположить, что передача команды null должна быть в порядке, поскольку нам просто нужно выполнить команду. Что касается SelectionChanged, я бы склонен думать, что было бы более важно знать новые элементы, а не старые элементы, поэтому простая передача новых элементов OOB в SelectionChangedCommand должна быть хорошей. Это может не подходить для всех вариантов использования, но, по крайней мере, обеспечивает минимальный объем накладных расходов, который разработчик должен добавить с помощью некоторого EventToCommandBehavior.

Идеальный пример, который убивает текущее представление списка, - это управление календарем, где:
-days (ячейки) могут иметь много стилей:
как день акции, день рождения, отключение / день без распродажи / праздничный день ...
встроенные значки с различными настраиваемыми шрифтами в нем, ячейка имеет тени, если выбрана, другой стиль, когда в r
ярость, другое в начале и конце диапазона
-выбор свиданий возможен
-месячный заголовок и индивидуальный стиль заголовка
-месячные заголовки имеют кнопки, которые позволяют особый просмотр / действия / отображение в текущем месяце

Как насчет добавления шаблона GroupFooterTemplate?

Это так необходимо в Forms :-) CollectionView устранит дорогостоящие обходные пути, устранит ограничения и, возможно, повысит производительность практически во всех приложениях Forms, которые я создал за последние 5 лет. Точно так же правильный подход - использовать и раскрыть мощь нативных платформ.

Если бы было только ОДНО улучшение, которое я мог бы запросить для Форм, это было бы оно.
(собственно, я сделал это в 2017 году в ответ на @davidortinau)

Это действительно круто и долгождано! API чистый и простой (спасибо за переименование HasUnevenRows!).

Как предлагает @dhaligas, очень необходимы события прокрутки. Для параллаксной анимации, а также для скрытия кнопки с плавающим действием, например, при прокрутке.

FontIconSource - хорошая идея. Было бы неплохо предоставить список значков по умолчанию с отображением юникода для каждой платформы (аналогично iOS или UWP).

Похоже, это именно то, что нужно. API выглядит намного чище, наличие нескольких представлений / контейнеров, структурированных таким образом, должно помочь сохранить код более чистым и простым.

Мои комментарии на данный момент:

@dansiegel Команда при достижении порога оставшихся элементов будет приветствоваться. Не уверен, что это необходимо для SelectedItems - все, что вы говорите (уведомление об изменениях, что изменилось и даже почему), обрабатывается автоматически, если SelectedItems является ObservableCollection (или чем-либо, что реализует INotifyCollectionChanged). Я бы предпочел иметь как можно меньше кода в CollectionView, чтобы снизить сложность.

Прокрутка: я полностью согласен с прокруткой. На данный момент мы можем получить это для Android, но для iOS вам нужно обернуть UITableViewSource и перехватить метод Scrolled.

Для меня важнее всего была бы расширяемость. Пожалуйста, не используйте внутренние классы для адаптеров и TableViewSources, и, пожалуйста, во встроенных средствах визуализации предоставьте методы CreateAdapter и CreateViewSource (и аналогичные для других платформ), где мы можем создать наш собственный тип, если захотим. У нас есть настраиваемый ListAdapter для поддержки перетаскивания на Android и, как упоминалось ранее, настраиваемый UITableViewSources как для прокрутки, так и для перетаскивания. Но это не код, который мне нравится, потому что есть обертка внутренних классов и т. Д.

Это относится не только к адаптерам / источникам просмотра. В общем, в новом API добавьте точки, в которых мы можем расширить поведение, если это необходимо.

Я считаю, что это действительно отличная и важная функция!
iOS уже использует имя UICollectionView, что может привести к путанице и неправильным результатам Google при поиске CollectionView. Это проблема?

Просто чтобы не мешать, мне нравится практически все, что касается CollectionView spec. Возможно, стоит разделить некоторые вещи на отдельные вопросы, поскольку у меня есть мысли по ним, как, я уверен, и многие другие, и я вижу, что за разговорами становится все труднее следить. Например:

Это можно было бы добавить позже, но примерно так:

public class MultipleFontIconsSource : ImageSource
{
    public List<FontIconSource> Icons { get; set; }
}

было бы полезно для поддержки наложения значков: https://fontawesome.com/how-to-use/on-the-web/styling/stacking-icons

Мой отзыв:

1. Я бы не стал помещать возможности выбора элемента в класс CollectionView. Вместо этого я бы добавил абстрактный базовый класс ListCollectionView, производный от CollectionView, который имеет определенные возможности:

public class CollectionView : View
{
   // Common capabilities related to a view capable of displaying a list of items
    public static readonly BindableProperty ItemsLayoutProperty;
    public IItemsLayout ItemsLayout { get; set; }

    public static readonly BindableProperty ItemsSourceProperty;
    public IEnumerable ItemsSource { get; set; }
}

public class ListCollectionView : CollectionView
{
     // Item selection capabilities and other capabilities 

    public static readonly BindableProperty SelectionModeProperty;
    public SelectionMode SelectionMode { get; set; }

    public static readonly BindableProperty SelectedItemProperty;
    public object SelectedItem { get; set; }

    public static readonly BindableProperty SelectedItemsProperty;
    public IList<object> SelectedItems { get; set; }

    public static readonly BindableProperty SelectedItemsProperty;
    public IList<object> SelectedItems { get; set; }
}

Моя идея - иметь CollectionView, похожий на ItemsControl в Windows XAML. ItemsControl принимает экземпляр Panel, который позиционирует элементы. В Forms у нас будут CollectionView и IItemsLayout.
По умолчанию, если IItemLayout не указан, макет по умолчанию может быть макетом стека. Таким образом, мы могли бы объединить ItemsSource со StackPanel из Windows XAML или, другими словами, связать StackLayout!

Помимо выбора элементов, есть и другие возможности, которые я бы не использовал в CollectionView, я бы добавил их в ListCollectionView. Например, в CollectionView не должно быть прокрутки. Таким образом он закроет эту ветку

1. Я бы переименовал интерфейс IItemsLayout в ICollectionViewLayout. Во фреймворке уже есть Layout и ItemsView . Это было бы более длинное имя, но ICollectionViewLayout - четкое указание на то, для чего он нужен, он специфичен для CollectionView, а не какой-то общий способ отображения элементов.

2. Я бы переименовал класс ItemsLayout в OrientedCollectionViewLayout. Это явное указание на то, для чего на самом деле предназначен абстрактный базовый класс, все производные классы ориентированно размещают элементы. Более того, использование "Oriented" в названии дает возможность в будущем добавить абстрактный базовый класс, называемый просто "CollectionViewLayout". если некоторые новые общие функции требуются для всех классов макетов представления коллекции, а не только для тех, которые имеют ориентацию.

3. Удаление ViewCell и использование DataTemplate только приветствуется, это улучшает возможность повторного использования.

1. Не могли бы вы поделиться более подробной информацией о RefreshView?
   Я предполагаю, что RefreshView каким-то образом должен соответствовать UIRefreshControl на iOS? Как это будет работать на Android и UWP?

Если кому-то интересно, я внес некоторые изменения в свой первый комментарий выше.

Я согласен с @andreinitescu, что было бы хорошо иметь возможность иметь коллекцию без прокрутки. Я нейтрально отношусь к тому, означает ли это разбиение его на несколько классов или, возможно, наличие чего-то вроде свойства ScrollMode. Я полагаюсь на тех, у кого гораздо больше опыта в разработке API, чем у меня. Но довольно просто реализовать собственный список элементов на основе StackLayout с помощью DataTemplate или селектора шаблонов, поэтому, возможно, это не нужно.

Хотя мне нравится идея управления функцией прокрутки, я также не придумываю каких-либо убедительных вариантов использования для «Коллекции» без прокрутки, которая включает в себя все расширенные функции ListView или предлагаемого CollectionView из моей головы. Мой вариант использования списка без прокрутки всегда решался с помощью тривиального списка элементов. Обычно я не использую ListView потому, что мне не нужен выбор или я хочу расположить список по горизонтали. Оба этих случая, по-видимому, охватываются предложенной спецификацией. Мне были бы интересны любые примеры использования, которые есть у кого-то еще без прокрутки.

@bmacombe Я согласен с вами, что реализовать привязываемый StackLayout «просто», но я думаю, что не в этом суть. Это очень распространенная функция, почему бы не включить ее во фреймворк? И я думаю, что при некотором планировании это можно сделать. Как я уже сказал выше, это можно решить, просто разделив функциональность на два класса: базовый класс (аналогичный ItemsControl в Windows XAML) и CollectionView (ListView). В идеале в иерархии должен быть класс Selector (см. Https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.controls.primitives.selector)

Я бы сказал, что тривиальная причина использования опции без прокрутки заключается в том, что на некоторых страницах должен быть ScrollView для всей страницы и список элементов.

Если вы это сделаете, прямо сейчас не рекомендуется помещать ListView в ScrollView. Привязываемый CollectionView, который вы могли бы поместить туда, который потенциально обладает всеми функциями ListView, - это то, в чем я нуждался несколько раз.

Я написал то же самое, что и все остальные, BindableStack, но с встроенным было бы намного приятнее работать.

@adammeaney В этом есть смысл, и теперь, когда я думаю об этом, я сделал то же

@andreinitescu Я не

В моих собственных фреймворках я всегда иду туда и сюда, встраивая множество функций в один элемент управления или создавая множество похожих классов с инкрементными функциями. Я буду в порядке, однако команда Forms решит реализовать его наилучшим образом, особенно с учетом реализаций базовой платформы.

@bmacombe Если немного спланировать, я надеюсь, что мы сможем
Например, экземпляр класса CollectionView, работающий так, как я упоминал, если у него нет набора IItemLayout, он может быть просто сопоставлен механизмом рендеринга с собственным UIStackView в iOS или StackPanel в UWP или LinearLayout в Android. Или, чтобы упростить реализацию, можно просто использовать существующий StackLayout для упорядочивания представлений.

У меня сложилось впечатление, что новый ListView должен быть направлен как на устранение проблем с существующим ListView, так и на решение темы «RepeatableBinder» здесь.

Мы хотим увидеть, где находится ListView2, прежде чем продвигать эту спецификацию. Он содержит много одинаковых необходимых компонентов, и было бы лучше избегать их дублирования.

Я не понимаю, как размещение всей функциональности в CollectionView, как предлагает здесь спецификация, сделало бы эту работу правильно.

2680 Можно ли добавить в эту спецификацию? Что касается включения полосы прокрутки.

@andreinitescu

Не могли бы вы поделиться более подробной информацией о RefreshView?
Я предполагаю, что RefreshView каким-то образом должен соответствовать UIRefreshControl на iOS? Как это будет работать на Android и UWP?

В UWP мы, скорее всего, будем использовать RefreshContainer . На Android, вероятно, SwipeRefreshLayout .

@krdmllr

iOS уже использует имя UICollectionView, что может привести к путанице и неправильным результатам Google при поиске CollectionView. Это проблема?

Это проблема, но не новая. У нас такая же проблема с GestureRecognizer, ListView, Grid и многими другими вещами в Forms. Мы немного боролись с этим внутренне; существует очень много возможных названий для «группы элементов на экране».

«CollectionView» не конфликтует ни с чем, что у нас есть в настоящее время в Forms, он не конфликтует ни с какими именами элементов управления UWP (как это делает «ListView») и не _ точно_ как UICollectionView (из-за префикса «UI»). Он не на 100% идеален для целей поиска, но мы считаем, что это лучшее выражение цели элемента управления.

Тем не менее, если кто-то предлагает альтернативное имя, в которое мы сразу влюбляемся, я буду рад провести поиск и заменить.

(Я хотел назвать его ListView2ColonRevengeOfTheListView, но @davidortinau меня сбил :))

@dansiegel

Хорошим контекстом для этого было бы подумать о почтовом клиенте, в котором вы можете получить одно меню, когда проведете пальцем влево, а другое - если проведете пальцем вправо.

Взгляните на спецификацию SwipeView - это именно то, к чему мы стремимся.

@GalaxiaGuy

поддержка значков стекирования

Это замечательный момент, мы должны поддержать его, если возможно. Я знаю, что это работает со встроенными глифами UWP; Мне пришлось бы провести небольшое исследование, чтобы убедиться, что этот тип стекирования будет работать на других платформах (я подозреваю, что ответ - «да»).

Обновление: часть FontIconSource этой спецификации перемещена в отдельную спецификацию .

Я бы использовал пользовательский сценарий для множественного выбора элементов из выборки, например, выбор одной или нескольких фотографий из альбома. Довольно распространенный сценарий в таких приложениях, как OneDrive или WhatsApp.

@hartez

Тем не менее, если кто-то предлагает альтернативное имя, в которое мы сразу влюбляемся, я буду рад провести поиск и заменить.

Я уже предлагал новое имя по разным причинам

Каким будет значение SelectedItem , когда SelectionMode равно Multiple ? Я могу придумать 5 вариантов:

1. Последний выбранный элемент в порядке выбора.
   
2. Последний выбранный элемент по порядку источника.
   
3. Последний выбранный / удаленный элемент в порядке выбора.
   
4. Последний выбранный / удаленный элемент в порядке их источника.
   
5. нулевой
   
   
   
   (2), (3) и (4) не очень полезны. Я добавил их, чтобы охватить все варианты. (1) кажется наиболее логичным выбором. (5) если вы вообще не хотите поддерживать SelectedItem если SelectionMode равно Multiple .

@ AmrAlSayed0

Каким будет значение SelectedItem, если для SelectionMode установлено значение Multiple?

Прямо сейчас ответ - «все, что было до того, как вы переключили SelectionMode на Multiple ».

@rogihee

Я бы использовал пользовательский сценарий для множественного выбора элементов из выбранной

Вы спрашиваете, поддерживается ли этот сценарий выбора? AFAIK, все встроенные элементы управления, которые мы собираемся использовать, поддерживают его, поэтому _должен_ поддерживаться в CollectionView.

Привязываемый стиль для SelectionMode был бы полезен, если SelectionMode = None, Transparent и т. Д., Это то, что делает Radlist, что является очень полезным и простым способом обработки визуального состояния на основе привязок. Стиль для каждого режима выбора будет охватывать эти сценарии.

@andreinitescu

Отвечая на ваши комментарии с https://github.com/xamarin/Xamarin.Forms/issues/3172#issuecomment -401015625 (и в других местах):

Вы поднимаете много хороших моментов, и я хочу убедиться, что вы знаете, что мы их не игнорируем. Мы просто еще не знаем всех ответов. Мы находимся в процессе доработки этого API, чтобы мы могли видеть, где он работает, а где разваливается; Я подозреваю, что предлагаемая вами разбивка классов довольно близка к той, в которой нам нужно закончить.

Мы понимаем, что вы (и некоторые другие) очень заинтересованы в том, чтобы эти промежуточные классы отображались как StackLayouts и Grids шаблонных элементов (то есть «BindableRepeater»), и это один из вариантов использования, который мы изучаем.

@alexhardwicke

В общем, в новом API добавьте точки, в которых мы можем расширить поведение, если это необходимо.

Методы UpdateX в средствах визуализации будут protected virtual . :)

Если серьезно, мы осознаем, что это было болезненной точкой в ​​прошлом, и помним об этом при написании CollectionView .

1. Если подумать, я действительно не думаю, что CollectionView - хороший выбор для имени класса этого представления.
   В Windows XAML CollectionView является базовым классом для источника данных элементов, используемых для группировки фильтрации, см. Https://msdn.microsoft.com/en-us/library/system.windows.data.collectionview (v = vs. 110) .aspx
   Возможно, в какой-то момент Xamarin Forms получит класс для той же цели, и я думаю, что будет иметь смысл, если у него будет такое же имя (CollectionView), особенно если подумать о XAML Standard (это все еще планируется?)

   Как бы уродливо и смешно это ни звучало, ListView2 - хороший выбор :) В .NET рекомендуется использовать суффикс для управления версиями, когда существующее имя - единственное имя, которое имеет смысл:

   ОБЯЗАТЕЛЬНО используйте числовой суффикс для обозначения новой версии существующего API, особенно если существующее имя API - единственное имя, которое имеет смысл (т. Е. Если оно является отраслевым стандартом), и если добавляется какой-либо значимый суффикс (или изменяется name) не подходит.

   _Руководство по проектированию фреймворков: условные обозначения, идиомы и шаблоны для многоразовых библиотек .NET, 2-е издание_
   https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/general-naming-conventions

   В какой-то момент позже все будут пользоваться новым, блестящим. стабильный и производительный ListView2 :). Быстро переименовав ListView2 в ListView, пусть это и критическое изменение, будет простым (и желанным) рефакторингом для всех.

2. В Xamarin Forms уже есть ItemsViewкоторый очень похож на ItemsControl в Windows XAML, за исключением того, что у него нет свойства макета элементов.
   Можно ли вместо создания нового класса CollectionView использовать существующий ItemsViewтакже как базовый класс для нового ListView?

3. Существует очевидная проблема в дизайне и реализации API с использованием встроенных элементов управления платформы, которые отображают элементы списка, но при этом имеют гибкость, позволяющую иметь что-то вроде «BindableRepeater», который предназначен для отображения простого, более легкого, не прокручиваемого и не прокручиваемого -выбираемый список предметов.
   Похоже, Уно это удалось:

   • https://github.com/nventive/Uno/blob/master/doc/articles/ListViewBase.md#internal -implementation
   • ListViewBase: https://github.com/nventive/Uno/blob/master/src/Uno.UI/UI/Xaml/Controls/ListViewBase/ListViewBase.cs
   • ItemsControl: https://github.com/nventive/Uno/blob/master/src/Uno.UI/UI/Xaml/Controls/ItemsControl/ItemsControl.cs

Можно ли вместо создания нового класса CollectionView использовать существующий ItemsView в качестве базового класса для нового ListView?

Есть ItemsView<T> , но мы не хотим это использовать. Он использует TemplatedItemsList , что является частью хлама, которого мы пытаемся избежать с помощью этого нового элемента управления.

В какой-то момент позже все будут пользоваться новым, блестящим. стабильный и производительный ListView2 :). Быстро переименовав ListView2 в ListView, пусть это и критическое изменение, будет простым (и желанным) рефакторингом для всех.

Ваш оптимизм очарователен, но мы должны работать, исходя из предположения, что ListView (1) - это навсегда, и что критические изменения, такие как переименование ListView2, не будут разрешены.

Я думал, что быть на одном уровне с Windows XAML имеет смысл, но хорошо, используйте любое имя, какое хотите, пока новый элемент управления соответствует своему обещанию. Платформа Uno, похоже, преуспела в этом, поэтому теперь мне не терпится увидеть, что вы, ребята, вносите в Xamarin Forms.

@gmwilhelm

https://github.com/xamarin/Xamarin.Forms/issues/3172#issuecomment -400925994

Хорошая точка зрения. Я предварительно добавил это в API. Я говорю ориентировочно, потому что я полностью понимаю, как мы могли бы реализовать это на iOS и Android, но UWP может оказаться сложной задачей.

Но я не могу отрицать, что это одновременно разумно и приятно симметрично.

Как насчет добавления GroupItemsBinding ?

Это позволит группе содержать свойство типа коллекции вместо того, чтобы требовать, чтобы группа была производной от коллекции, как это делает ListView. Это существующее ограничение ListView вынудило меня несколько раз выполнять дорогостоящее дублирование сгруппированных структур данных. Добавление GroupItemsBinding предотвратит это и обеспечит более гибкое сопоставление с сгруппированными структурами данных.

Т.е. пример, использованный в документации GroupDisplayBinding, может быть:

`` С #
class Group // Обратите внимание, что Group не обязательно быть производным от ObservableCollection
{
общедоступная группа (строка firstInitial) {FirstInitial = firstInitial; }

public string FirstInitial { get; private set; }

public ObservableCollection<Person> Persons { get; set; } // We use a property for the group items instead

}

ListView CreateListView ()
{
var listView = new ListView {
GroupItemsBinding = новая привязка (nameof (Group.Persons))
// ...
};
// ...
}

`` ''

Учитывая, что это подмножество того, что UICollectionView делает с точки зрения макета, я чувствую, что мы должны выбрать другое имя, чтобы избежать путаницы с возможностями элемента управления.

Чтобы было ясно, этот элемент управления еще не доступен для использования, верно? Я пытался сослаться на него, но мой проект не может его найти

@titonton Это проблема только для обсуждения спецификации CollectionView, реализация еще даже не началась, и я не думаю, что она начнется, пока спецификация не будет завершена.

@ AmrAlSayed0 На самом деле он должен был начаться, потому что 11 дней назад он был перемещен в «

Довольно непонятно, как это было начато, учитывая, что неясно, какое решение будет принято по API.

@opcodewriter Вот о чем я подумал. @ AmrAlSayed0 Спасибо за разъяснения.

Может кто-нибудь прояснить, каково текущее состояние этой спецификации? Не хватает чего-то там, где сообщество может помочь?

@migueldeicaza @hartez Назвать это будет CollectionView . Как насчет CatalogView ?

Каталоги часто состоят из одного или нескольких столбцов и нескольких строк элементов с одинаковыми шрифтами, текстами, макетами и т. Д.

Образец:

@hartez Вы чувствуете, что API почти завершены? Сколько работы было проделано на данный момент? Многие из нас хотели бы как можно скорее заполучить этот элемент управления. :)

@ adrianknight89 Я считаю, что это рабочая ветка. https://github.com/xamarin/Xamarin.Forms/tree/lv2spike

Мы не ожидаем, что он будет готов к предварительному просмотру в ближайшее время, но я продемонстрирую / продемонстрирую результаты текущих усилий в ближайшие недели, чтобы проверить прогресс и получить обратную связь.

Я смущен. Поскольку у вас уже есть некоторые внутренние демонстрации, похоже, что вы уже довольно далеко от реализации.
Разве это не должно означать, что многие API-интерфейсы не работают? Соблюдаете ли вы здесь спецификацию API?
Я не вижу, как текущая спецификация сможет решить то, что обсуждалось здесь и в другом потоке здесь https://github.com/xamarin/Xamarin.Forms/issues/1718
Чтобы быть более точным, API недостаточно гибок, чтобы позволить, например, простой не прокручиваемый и привязываемый элемент управления, подобный StackLayout.

Позволяет ли новый элемент управления помещать связанные элементы в стек без полосы прокрутки, как StackLayout?

Спасибо, долго этого ждали 👍

После большого внутреннего обсуждения и попыток разработать подходящую архитектуру мы решили, что CollectionView _не_ будет обрабатывать сценарии макета, обсуждаемые в # 1718. Другими словами, он не будет обрабатывать привязку коллекции объектов к элементам в любых макетах Xamarin.Forms.

Первоначальная цель CollectionView заключалась в том, чтобы позволить пользователям легко использовать различные современные собственные элементы управления списками / сетками (UICollectionView, RecyclerView, ListView / GridView и т. Д.).

Было заманчиво попытаться сделать CollectionView универсальным средством управления для всех потребностей «визуализировать и упорядочить этот шаблон с данными», включая все сценарии, в которых этап «упорядочивания» выполнялся с помощью макетов форм (FlexLayout, StackLayout и т. Д.) ). И есть некоторые очевидные совпадения функций (например, в обоих сценариях используются шаблоны данных). Но, в конце концов, у них есть большая фундаментальная разница в архитектуре, и попытка соединить их вместе приведет к чему-то более сложному в обслуживании и запутанному, чем просто оставить их как отдельные элементы управления. Мы не хотели создавать что-то настолько сложное, что нам пришлось реализовать ListView3 через пару лет. Я подробнее остановлюсь на этом ниже.

Результатом этого является то, что CollectionView будет по-прежнему сосредоточен на проблеме предоставления пользователям Forms возможности использовать собственные элементы управления списками / сетками и извлекать выгоду из своих механизмов компоновки и виртуализации. И # 1718 будет обновлен, чтобы отразить API, который позволит пользователям форм связывать ItemsSource и ItemTemplate с различными механизмами макета форм.

Для тех, кто интересуется _why_ двух элементов управления по сравнению с одним:

Фундаментальная разница между описанным здесь (как CollectionView) и предложением в # 1718 заключается в том, _ где_ находится макет.

CollectionView стремится использовать собственные механизмы компоновки (которые были сильно оптимизированы разработчиками платформы) для обработки компоновки. Некоторый пользовательский код из Forms участвует (например, в предоставлении таких вещей, как логика SnapPoints на Android и iOS), но по большей части тяжелую работу берут на себя собственные механизмы компоновки (и собственные реализации виртуализации). Это имеет огромное значение с точки зрения производительности.

Таким образом, любая информация о макете, которую разработчик передает в CollectionView, просто передается модулю визуализации на каждой платформе для интерпретации; фактически это спецификация, переведенная на местный язык (LinearLayoutManager / GridLayoutManager на Android, UICollectionViewFlowLayout на iOS и т. д.). Помимо DataTemplate, Forms не выполняет никакой работы с макетом.

Напротив, макет форм (FlexLayout, StackLayout, AbsoluteLayout и т. Д.) Полностью размещается на слое форм. Рендереры для макета форм делают очень мало. И никакой виртуализации не происходит; все элементы создаются и размещаются в макете с самого начала.

Попытка связать эти две вещи вместе приводит к ряду сложных вопросов, в том числе:

1. Как работает отображение рендерера? CollectionView, использующий StackLayout, имеет совершенно иное средство визуализации, чем CollectionView, которому необходимо использовать RecyclerView. Можем ли мы смешать их вместе и скрыть RecyclerView, когда он нам не нужен? У нас есть рендерер, производный от DefaultRenderer? Если мы это сделаем, у нас всегда будет дополнительный слой ViewGroup, который нам действительно не нужен ...

2. Как мы обрабатываем ScrollViews? UICollectionView обрабатывает свое собственное отображение с прокруткой, но если StackLayout требуется прокрутка, пользователь обычно добавляет его вручную в формы. Добавим ли мы еще один слой для автоматической прокрутки при необходимости? Отключаем / удаляем добавленный вручную ScrollView, если макет требует UICollectionView?

3. В таком случае, куда деваются методы ScrollTo?

... и так далее. Все эти проблемы разрешимы, но каждое решение добавляет сложности. И, как было указано в # 1718, добавление ItemsSource и ItemsTemplate в макет формы не так уж и сложно. Сложность всего лишь объединения этих двух различных сценариев не стоит преимуществ.

Я смущен. Поскольку у вас уже есть некоторые внутренние демонстрации, похоже, что вы уже довольно далеко от реализации. Разве это не должно означать, что многие API-интерфейсы не работают? Соблюдаете ли вы здесь спецификацию API?

Мы следим за API, размещенным здесь. «Довольно далеко» - это, наверное, преувеличение; до сих пор мы реализовали некоторые не вызывающие споров части спецификации, чтобы убедиться, что они возможны, и что мы не идем в тупик. Если предположить, что мы не столкнемся с какими-либо проблемами, большая часть того, что мы реализовали до этого момента, скорее всего, будет в выпущенной версии. Но все в спецификации все еще может быть изменено, как и все, что мы реализовали до сих пор.

Я не понимаю, как текущая спецификация сможет решить то, что обсуждалось здесь и в другом потоке здесь # 1718. Чтобы быть более точным, API недостаточно гибок, чтобы позволить, например, простой не прокручиваемый и привязываемый элемент управления, подобный StackLayout.

Верно, и часть того, над чем мы работаем, - это определение того, может ли CollectionView разумно охватывать эти варианты использования. Мы пришли к решению по этому поводу; см. https://github.com/xamarin/Xamarin.Forms/issues/3172#issuecomment -424413234.

Учитывая, что это подмножество того, что UICollectionView делает с точки зрения макета, я чувствую, что мы должны выбрать другое имя, чтобы избежать путаницы с возможностями элемента управления.

Как я уже сказал (https://github.com/xamarin/Xamarin.Forms/issues/3172#issuecomment-401186893), я открыт для других имен.

Как насчет CatalogView?

Каталоги часто состоят из одного или нескольких столбцов и нескольких строк элементов с одинаковыми шрифтами, текстами, макетами и т. Д.

Это интересная идея. Это определенно не конфликтует с существующими именами элементов управления.

@hartez Как случайный парень в Интернете, который все больше знакомится с внутренним устройством Xamarin Forms (и уже хорошо знаком с UITableView и UICollectionView), я думаю, что это правильный шаг.

Можно ли будет по-прежнему предоставлять собственный макет (даже если это означает предоставление отдельных реализаций для каждой платформы)?

Можно ли будет по-прежнему предоставлять собственный макет (даже если это означает предоставление отдельных реализаций для каждой платформы)?

Абсолютно. Вы можете предоставить свой собственный макет, помеченный IItemsLayout, и ваше настраиваемое средство визуализации может интерпретировать его так, как вы хотите.

Например, в качестве доказательства концепции я выделил подкласс средства визуализации Android для CollectionView и добавил возможность интерпретировать класс FlexLayout : IItemsLayout который включает набор свойств Flex Layout. Он передает эти свойства в FlexBoxLayoutManager Google и использует этот диспетчер компоновки с RecyclerView. Как только мы сделаем общедоступную предварительную версию, я, вероятно, выложу этот пример на GitHub, чтобы у людей была легкая справка о том, как делать такие вещи.

Наша цель - сделать эту вещь очень и очень гибкой.

@hartez
Устранена ли проблема, описанная в https://github.com/xamarin/Xamarin.Forms/issues/3749, с помощью CollectionView?
Потому что здесь я вижу, что CollectionView имеет только свойство ItemTemplate , что звучит так, как будто у него будет та же проблема, что и у ListView .

@hartez
Устранена ли проблема, описанная в # 3749, с помощью CollectionView?
Потому что здесь я вижу, что CollectionView имеет только свойство ItemTemplate , что звучит так, как будто у него будет та же проблема, что и у ListView .

@andreinitescu Спасибо, что указали на это обсуждение, я не знал об этой проблеме с DataTemplate.

На следующей неделе я собираюсь потратить некоторое время на изучение истории DataTemplate - почему он разработан таким образом, и есть ли какие-либо проблемы с обратной совместимостью с исправлением CreateContent чтобы просто автоматически делать правильные вещи (как в ListView и CollectionView).

@hartez Это просто пример того, как я

// Проверяем, есть ли у нас селектор шаблонов или просто шаблон
var templateToUse = itemTemplate - это DataTemplateSelector templateSelector? templateSelector.SelectTemplate (элемент, ноль): itemTemplate;

Так что в таком случае простое исправление CreateContent не сломает его, а просто сделает ненужным. Но я согласен с @andreinitescu, что разделение ItemTemplate и ItemTemplateSelector как отдельных свойств было бы идеальным ... вероятно, из-за моего фона WPF и SL.

@bmacombe IMHO, это не только вопрос предпочтений, если он согласован с WPF / SL, это действительно проблема, это создает путаницу. См. № 3544

@andreinitescu Это действительно создает путаницу :) Поверьте, я сначала был сбит с толку, когда пытался поддерживать DataTemplate и DataTemplateSelector в моем репитере! Особенно, когда у меня была ошибка, когда я назначил DateTemplateSelector своему свойству DataTemplate, когда он работал во всех местах XF, которые его использовали. Потребовалось немного покопаться в исходном коде, чтобы понять это. Вероятно, это не проблема для кого-то, просто использующего встроенные элементы управления XF, но попытка сделать это самостоятельно и использовать ... действительно сбивает с толку.

Можно ли провести событие прокрутки в CollectionView? Пока не будет выпущен CollectionView, у меня есть предложение для ListView https://github.com/xamarin/Xamarin.Forms/issues/4323

И можно ли будет создавать нерегулярные и динамические макеты, например, PInterest:

Понимаете, у каждого изображения своя высота :-)

Не уверены, что такая раскладка может поддерживаться?

Обновление: из списка предложений по названию самое близкое, что мы придумали, - это «ItemsView», это сделано для того, чтобы избежать использования термина «CollectionView», который создает у людей впечатление, что это так же полно, как iOS «UICollectionView».

Привет, я все еще новичок в Xamarin, но работаю с ListView, используя DataTemplateSelector.
Когда я пытался протестировать использование CollectionView с DataTemplateSelector, он выдает ошибку

Необработанное исключение:

System.InvalidOperationException: LoadTemplate не должно иметь значения NULL.

Есть ли известная ошибка, связанная с DataTemplateSelector?
Я мог неправильно это реализовать. Есть ли какой-либо пример использования DataTemplateSelector с CollectionView?

@hartez @davidortinau какая-либо причина, по которой KeepItemsInView не назван KeepFirstItemInView для согласования с KeepLastItemInView ? Текущее имя имеет множественное число (т.е. предполагает несколько элементов), тогда как в описании говорится, что в области просмотра сохраняется только первый видимый элемент.

Кроме того, есть ли способ предоставить API для получения списка представлений, находящихся в настоящее время в области просмотра? На днях я работал над созданием представления видео, которое будет встроено в ячейку ListView и автоматически воспроизведено / приостановлено в зависимости от видимости области просмотра, но это было почти невозможно с текущими ItemAppearing и ItemDisappearing События CollectionView поддерживающего такую ​​функциональность более надежным способом.

Еще одна вещь, которую было бы здорово иметь, - это возможность создавать зависимое минимизированное представление, которое отделено от родительского, в то время как пользователь может прокручивать текущий канал. Я видел это на YouTube, так как теперь мы можем продолжить просмотр текущего видео, имея возможность продолжить просмотр. Я не уверен, что CollectionView может или должен поддерживать, кстати, но об этом стоит подумать.

Поэтому я немного поигрался с текущей ночной сборкой (4.0.1.43780-nightly), которая решила некоторые проблемы с изменением размера по сравнению с текущей предварительной сборкой.

У меня есть предложение добавить что-то вроде RowSpacing / ColumnSpacing или GridSpacing в макеты сетки, поскольку это значительно упрощает правильное размещение элементов без использования полей / отступов для отдельных элементов.
Еще одна вещь - добавить Padding или, возможно, EdgeOffset в CollectionView или Layout, чтобы избежать использования Margin, которое сокращает элементы, как показано здесь:

Margin также обрезает анимацию перетаскивания на Android, как вы можете видеть здесь:

У меня есть предложение добавить что-то вроде RowSpacing / ColumnSpacing или GridSpacing в макеты сетки, поскольку это значительно упрощает правильное размещение элементов без использования полей / отступов для отдельных элементов.

Согласен, и это на нашем радаре - см. №4681.

Обновление: из списка предложений по названию самое близкое, что мы придумали, - это «ItemsView», это сделано для того, чтобы избежать использования термина «CollectionView», который создает у людей впечатление, что это так же полно, как iOS «UICollectionView».

как насчет "FloatView"?

Помимо упомянутых выше событий ItemAppearing / Disappearing, любые планы относительно способов получить представление для элемента:
View GetView(object item)
Если элемент не материализован, он должен вернуть null, я думаю.

Я использую вертикальный список, и, похоже, есть несоответствия в том, как он отображается на iOS и Android.

В iOS метка будет занимать 100% ширины.

На Android он будет занимать только ширину содержимого.

Я мог только правильно разметить его со статическим определением ширины.
Есть ли обходной путь для Android, учитывающий свойство Grid Width="Auto" ?

Я использую вертикальный список, и, похоже, есть несоответствия в том, как он отображается на iOS и Android.

@shwanton Пожалуйста, откройте отдельную проблему для этой ошибки, и я посмотрю.

@shwanton У меня были похожие проблемы, которые были исправлены, когда я переключился на ночную ленту

@krdmllr Могу подтвердить, в последней сборке это исправлено. Спасибо.

Привет. Будет ли в CollectionView событие ItemTapped, аналогичное ItemTapped в ListView? Я не вижу этого в спецификации. Спасибо.

@uvirra Существует проблема с вашим запросом DataTemplateSelector . См. № 4826.

@hartez Возникнет ли когда-нибудь необходимость в стратегии утилизации предметов, подобных тем, что существуют за ListView ? Вы несколько раз упоминали встроенную виртуализацию, которую использует CollectionView . Я просто хочу получить больше разъяснений по этому поводу.

Мне также любопытно узнать, как RefreshView будет выглядеть на iOS. Текущее обновление для ListView требует, чтобы свойство UITableView Bounces было включено, тогда как на Android представление обновления вытягивается поверх самого верхнего наиболее видимого элемента (который Я лично предпочитаю).

@hartez Возникнет ли когда-нибудь необходимость в стратегии утилизации предметов, подобных тем, что существуют за ListView ? Вы несколько раз упоминали встроенную виртуализацию, которую использует CollectionView . Я просто хочу получить больше разъяснений по этому поводу.

Текущий дизайн не требует ничего подобного стратегии утилизации. Прямо сейчас мы просто используем виртуализацию, обеспечиваемую собственными элементами управления, которые отлично справляются с этой задачей прямо из коробки.

Будет ли когда-нибудь необходимость? Я надеюсь на «нет», и мы сделаем все возможное, чтобы этого избежать, потому что это значительно усложняет работу (как для пользователей, так и для обслуживания). Если мы в конце концов придем к выводу, что нам нужно что-то подобное, мы будем подходить к дизайну очень и очень осторожно.

А как насчет прокрученного события? Большинство современных UI / UX предоставляют заголовок параллакса, отображение / скрытие элементов (кнопки, заголовки, фильтры и т. Д.) При прокрутке и тому подобное.
Я думаю, что новый замечательный элемент управления, подобный этому, должен поддерживать современные сценарии.

это не должно быть проблемой, и recyclerview, и UICollectionview поддерживают прокручиваемое событие из коробки.

Даже Carouselview (на основе collectionview) поддерживает прокрученное событие с указанием направления, значения прокрутки и дельты: https://github.com/xamarin/Xamarin.Forms/issues/4996

В продолжение комментария @Evolutionlab о том, что это новый потрясающий элемент управления, который должен поддерживать современные сценарии, я хотел бы видеть еще лучшую поддержку виртуализации.

https://docs.microsoft.com/en-us/windows/uwp/debug-test-perf/listview-and-gridview-data-optimization

Если это слишком сложно понять, я хотел бы получить доступ к VisibleItems, чтобы вместо этого я мог выполнять виртуализацию в своей ViewModel.

Продолжайте в том же духе!

@hartez Я просто подумал, что было бы здорово позволить разработчикам определять минимальный / максимальный порог количества выбранных элементов. В настоящее время я создаю собственную фотогалерею, в которой не должно быть выбрано более 5 фотографий. При достижении порога события касания в ячейках следует игнорировать, если только они не отменяют выбор элементов.

Это также можно сделать, установив SelectedItems (который еще не реализован) для события SelectionChanged на основе CurrentSelection count, но это вызовет SelectionChanged дважды. На мой взгляд, у нас должен быть способ проактивно контролировать поведение выбора, прежде чем что-либо достигнет Core.

Немного поиграв сегодня с CollectionView, я заметил, что UWP намного отстает от Android и iOS, и я понимаю, почему.

Просто хотите подтвердить, что после завершения планируется полная поддержка UWP?

Помимо упомянутых выше событий ItemAppearing / Disappearing, любые планы относительно способов получить представление для элемента:
View GetView(object item)
Если элемент не материализован, он должен вернуть null, я думаю.

А как насчет ItemAppearing? Я не вижу новостей об этом

Я играл с CollectionView и столкнулся с проблемами с неравномерной высотой строк. Я видел, что недавно появился ItemSizingStrategy , но он все еще ведет себя странно.

Я поигрался с DataTemplateGallery и при переключении на MeasureAllItems получил следующий результат (iPhone 6, iOS 12.1.4):

После смахивания вправо и возврата результат изменится на:

@hartez Ожидается, что это сработает или все еще продолжается (не удалось найти для этого никаких проблем)?

Реализован ли RemainingItemsThresholdReached?

Он недоступен в XAML элемента управления CollectionView в версии 4.0.0.169046-pre5.

Может ли кто-нибудь сказать мне, что RemainingItemsThresholdReached является частью выпуска 4.0? Если да, не могли бы вы привести пример кода, как использовать эту функцию.

@Dresel Можете ли вы открыть новый билет, если считаете, что это ошибка? Лучше, если его отследят.

@melucas @chandrubk Я не думаю, что над RemainingItemsThresholdReached еще работают.

https://github.com/xamarin/Xamarin.Forms/branches/all

Я тоже хотел бы, чтобы эта функция (вместе с представлением «Обновить») была реализована в ближайшее время, поскольку без нее я не могу коснуться CollectionView .

4323

Нам нужно событие Scrolled, например ScrollView do

С уважением,

4323

Нам нужно событие Scrolled, например ScrollView do

С уважением,

Я поддерживаю это.
Более того, было бы здорово получить событие и событие, когда прокрутка остановлена ​​/ завершена.

В IOS UICollectionview является подклассом UIScrollview, поэтому мы можем получить scrollViewDidEndDecelerating из UIScrollViewDelegate

В Android, я думаю, мы можем расширить RecyclerView.OnScrollListener ?

Это откроет более продвинутые и отточенные сценарии для настраиваемого обновления, параллакса, синхронизированных элементов прокрутки и т. Д.

Есть ли шанс, что для Android будет готовая анимация, например, в Recycler View?

Есть ли шанс, что для Android будет готовая анимация, например, в Recycler View?

Какие анимации вы имеете в виду? Средство визуализации Android для этого построено на RecyclerView, поэтому оно уже использует анимацию по умолчанию для таких вещей, как добавление / удаление элементов.

Привет,

Я использую 4.0.0.304370-pre8.
Пример из (ссылка ниже) ничего не отображает в UWP при использовании CarouselView.
Но CollectionView отображает список. Требуется ли какая-либо конкретная конфигурация для включения CarouselView для UWP?

https://devblogs.microsoft.com/xamarin/xamarin-forms-4-0-feature-preview-an-entirely-new-point-of-collectionview/

Спасибо.

Привет @noypi!

Хотя CollectionView технически может «работать» в довольно небольшой степени на UWP, полная реализация CollectionView и CarouselView с самого начала строго выполняется на Android и iOS. В настоящее время официальная работа по UWP не запланирована, но мы постоянно собираем отзывы. Если вы хотите обсудить, какой именно вид работы вы выполняете в UWP, вы можете отправить мне электронное письмо на адрес paul. [email protected].

Согласно спецификации, будет ли TableView полностью заменен на CollectionView?

Другой вопрос: раз уж ячеек больше нет, как добавить индикатор дисклора для iOS? С ListView это стало возможным с помощью настраиваемого средства визуализации.

Согласно спецификации, будет ли TableView полностью заменен на CollectionView?

TableView по-прежнему будет существовать. Мы не будем удалять существующие элементы управления.

Другой вопрос: раз уж ячеек больше нет, как добавить индикатор дисклора для iOS? С ListView это стало возможным с помощью настраиваемого средства визуализации.

В iOS CollectionView визуализируется с использованием UICollectionView, что означает, что его ячейки являются UICollectionViewCells. А UICollectionViewCells не имеет дополнительных представлений (например, индикаторов раскрытия информации). Поэтому для любых элементов пользовательского интерфейса, таких как индикаторы раскрытия или галочки, вам нужно будет создать их в своем ItemTemplate.

Как отключить выделение для определенных типов предметов? У меня есть несколько шаблонов данных, и я хочу отключить выбор для некоторых из них.

@hartez При установке ItemTemplate в DataTemplateSelector я получаю исключение: System.InvalidOperationException: LoadTemplate should not be null

Думал, что шаблоны будут поддерживаться из коробки

@hartez При установке ItemTemplate в DataTemplateSelector я получаю исключение: System.InvalidOperationException: LoadTemplate should not be null

Думал, что шаблоны будут поддерживаться из коробки

Они должны быть; возможно, вы столкнулись с ошибкой. Пожалуйста, откройте проблему, чтобы мы могли ее изучить.

@toomasz Прежде чем открывать проблему, не могли бы вы обновить свой Nuget до последней предварительной версии (или ночной версии) и снова протестировать селектор? Проблема, которую вы видите, возникла, когда не было поддержки для DataTemplateSelector .

@hartez Выполняется ли какая-либо работа над

@ adrianknight89 Работает на 4.0! Потрясающий

@hartez Выполняется ли какая-либо работа над

В данный момент ничего не делается - было бы здорово, если вы хотите попробовать себя в этом.
Напоминаем, что после сегодняшнего обсуждения мы добавили два новых свойства, связанных с верхним и нижним колонтитулами - IsHeaderSticky и IsFooterSticky , чтобы указать, будут ли они прокручиваться вместе с элементами или оставаться на месте. Если вы хотите решить их вместе с верхним / нижним колонтитулом, это было бы здорово, но также было бы здорово, если бы они работали так или иначе и могли бы реализовать эти свойства позже.

Есть ли план поддержки представления коллекции в UWP?

да. Реализация на данный момент немного отстает от других платформ, но мы планируем полностью ее поддерживать. Вы можете следить за развитием функции на https://gist.github.com/hartez/7d0edd4182dbc7de65cebc6c67f72e14.

Есть информация о RefreshView?
У меня последняя бета-версия Xamarin 4, и тип RefreshView не может быть найден

Есть информация о RefreshView?
У меня последняя бета-версия Xamarin 4, и тип RefreshView не может быть найден

RefreshView еще не реализован. Вы можете отслеживать прогресс функции здесь .

Добавить GroupItemsBinding ?

Как насчет добавления свойства GroupItemsBinding, чтобы указать, какое свойство содержит дочерние элементы группы? Это позволит встроить свойство дочерней коллекции вместо того, чтобы заставлять группы наследовать от коллекции.

Преимущества:

• Возможность (де) сериализации сгруппированной коллекции в / из JSON.
  Наследование групп из коллекции блокирует (де) сериализацию JSON (поскольку массивы JSON поддерживают только диапазон значений, а не свойства). (Де) сериализация моделей просмотра необходима для сохранения состояния модели просмотра, когда приложение переходит в фоновый режим или если API вашего приложения отправляет вам модели просмотра. Текущий обходной путь - иметь вторую структуру данных и выполнять дорогостоящее дублирование + преобразование при каждом обновлении данных.
• Возможность использовать свой собственный базовый класс для элементов группы (например, ViewModelBase )
• Избегайте загрязнения групповых объектов всеми унаследованными свойствами коллекции.

Например, вы можете написать этот пример группировки с docs.microsoft.com :
`` С #
открытый класс PageTypeGroup: List
{
общедоступная строка Заголовок {получить; набор; }
// Дополнительные свойства ...
}

like this instead:

```C#
public class PageTypeGroup
{
    public string Title { get; set; }
    // More properties ...

    public List<PageModel> Children { get; set; }
}

с XAML:

C# <CollectionView GroupItemsBinding = "{Binding Children}" ...> </CollectionView>

Отсутствие указания GroupItemsBinding будет совместимо с существующей реализацией, что эквивалентно GroupItemsBinding="{Binding .}"

PS Это предложение я подавал ранее, в июле 2018 года .

Обновление 23 августа 2019 г .: группировка реализована, но без этого исправления; см. Групповые данные

Надеюсь, еще не поздно добавить это.

Как насчет поддержки нескольких уровней группировки?
Позволил бы отображать деревья .

Например, у Flutter есть ExpansionTile ( пример )

Что касается CollectionView, я столкнулся с проблемой, которую, как мне кажется, было бы неплохо добавить.

В горизонтальном списке с прокруткой дизайнеры обычно добавляют эффект «тени» к элементам, которые не полностью видны на экране. В настоящее время (насколько мне известно) в Xamarin.Forms нет возможности сделать это. Вы бы не подумали, что это было бы здорово, если бы у вас была особенность? Это может быть простое логическое значение, которое, например, применяет «падающую тень» к элементу, который виден только на X процентов.

Предлагаю свойство Position. Это свойство будет содержать индекс текущего элемента. Это позволит легко интегрировать ViewPagerIndicator и аналогичные индикаторы.

Я понимаю, что определить «текущий элемент» может быть непросто. Если привязка включена, будет довольно легко определить, к какому элементу привязано представление. Без привязки правильный выбор будет зависеть от варианта использования: возможно, это будет элемент, занимающий начало или середину представления.

Это свойство также может обеспечить простой двусторонний доступ в качестве альтернативы ScrollTo ().

@hartez Мы ожидали, что это будет готово к выпуску 4.0, но были удивлены, увидев, что он еще не закончен. Мы не можем протестировать CollectionView без функциональности прокрутки и обновления. Можете ли вы сказать нам, сколько спринтов нам нужно подождать, прежде чем они будут запущены? Мы решили не выпускать ничего с ListView в будущем и хотели бы, чтобы этот элемент управления был доступен как можно скорее.

@hartez Нам нужен способ для CollectionView с макетом списка, чтобы размер соответствовал его содержимому. я думаю, что это обычный вариант использования:

В этом примере кнопки должны быть прямо под представлением коллекции. Я думаю, это должно работать, когда VerticalOptions запускается

при достижении порога оставшихся элементов проверка свойств

У меня есть вопросы о том, имитирует ли поток CollectionView поведения отдельного элемента поведение iOS Native при изменении размера экрана. Приведу пример:

Ячейка галереи изображений в iOS создается с помощью CollectionView, и вы определяете отдельную ячейку. Стандартное поведение заключается в том, что количество ячеек, отображаемых в одной строке, зависит от размера экрана. На телефоне я могу разместить 4 предмета, а на планшете - 8 или 9.

Будет ли это предлагать версия Forms? Пока что в примере, который я читал, я видел только то, где вы устанавливаете свойство GridItemsLayout Span. Это приводит к жестко запрограммированному значению того, сколько элементов можно рисовать, и на самом деле в мире экранов различных размеров жесткое кодирование кажется таким 2014. :-P

UWP имеет четыре состояния режима выбора
{
Никто,
Одинокий
Несколько,
Продлевать,
}

Я думаю, что четыре состояния в Android и IOS тоже полезны
Просто взгляните на проводник файлов

Есть ли какие-нибудь планы относительно простого свойства заполнения? # 6605 Для моего конкретного случая использования я, вероятно, мог бы использовать пустой верхний и нижний колонтитулы подходящего размера (после того, как эти функции будут разработаны), но это будет немного хитростью и не подходит для макета сетки, где отступы со всех четырех сторон могут быть обязательным.

Любой план по перегруппировке элемента списка в представлении коллекции.

Охватывает ли спецификация, как отключить выбор для определенных элементов в CollectionView?

// Any possible API could be helpful
private void OnSelectionChanging(object sender, SelectionChangingEventArgs e)
{
  if (...)
      e.Cancel = true;
 }

В настоящее время я работаю над этим, но это не мешает применению Selected VisualState.

void OnCollectionViewSelectionChanged(object sender, SelectionChangedEventArgs e)
{
    // Deselect the item.
    if (sender is CollectionView cv && e.CurrentSelection...)
    {
        cv.SelectedItem = null;
    }
}

Цвет вертикальной полосы прокрутки и цвет горизонтальной полосы прокрутки были бы замечательными!

Что касается направления прокрутки, я имею в виду начать прокрутку справа налево, а не сам контент

Я бы хотел разделители ...

Было бы здорово иметь возможность «запоминать» и применять положение прокрутки.

Что было бы такого удивительного, так это возможность использовать разные шаблоны элементов для каждой секунды или X элемента. Это позволит создать серый фон для каждого второго элемента и многие другие возможности стилизации.

Разве вы уже не можете сделать это с помощью селектора шаблонов? Использование позиции с
оператор по модулю?

Во вторник, 13 августа 2019 г., 16:53 Legacyorder [email protected] написал:

Что было бы такого удивительного, была бы возможность использовать другой предмет
шаблоны для каждой секунды или X элемента. Это позволило бы создать
серый фон для каждого второго предмета и многие другие стили
возможности.

-
Вы получаете это, потому что подписаны на эту беседу.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/xamarin/Xamarin.Forms/issues/3172?email_source=notifications&email_token=AC4YCKDFCH3WFENRCLPWEC3QELDE3A5CNFSM4FHJRXPKYY3PNVWWK3TUL52XG43LVMVWK3TUL52XG4DFVQ2VWWK3TUL52XG4DFVQ8C08BWMX6DVMX5VMWM8
или отключить поток
https://github.com/notifications/unsubscribe-auth/AC4YCKHXX5YSR7M3S4VU5QLQELDE3ANCNFSM4FHJRXPA
.

Круговая прокрутка было бы неплохо. Думаю, это легко реализовать.

Я хотел бы иметь «AbsoluteItemsLayout» в качестве ItemsLayout для CollectionView, чтобы можно было устанавливать абсолютные позиции в списке, на данный момент я не вижу другого решения, а не делаю это в коде позади.

Возможно ли при использовании GridItemsLayout разрешить элементам занимать несколько строк или столбцов? Это определенно была бы функция, которую стоило бы иметь.

Можете ли вы, ребята, также предоставить этому элементу управления событие Scrolled? Цель этого состоит в том, что когда я дойду до конца списка, я хочу перезагрузить дополнительные элементы. Я не знаю, определяет ли CollectionView, находится ли он внутри ScrollView, и отключает ли возможность прокрутки.

Можете ли вы, ребята, также предоставить этому элементу управления событие Scrolled? Цель этого состоит в том, что когда я дойду до конца списка, я хочу перезагрузить дополнительные элементы. Я не знаю, определяет ли CollectionView, находится ли он внутри ScrollView, и отключает ли возможность прокрутки.

Ваше желание исполнено! Проверьте версию 4.2 :)
https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/collectionview/scrolling

Вы не должны включать CollectionView в ScrollView, иначе виртуализация не будет работать.

Можете ли вы, ребята, также предоставить этому элементу управления событие Scrolled? Цель этого состоит в том, что когда я дойду до конца списка, я хочу перезагрузить дополнительные элементы. Я не знаю, определяет ли CollectionView, находится ли он внутри ScrollView, и отключает ли возможность прокрутки.

Ваше желание исполнено! Проверьте версию 4.2 :)
https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/collectionview/scrolling

Вы не должны включать CollectionView в ScrollView, иначе виртуализация не будет работать.

Я в 4.2.0.709249
я что-то упускаю?

У меня есть событие Scrolled с 4.2.0.709249.
Попробуйте удалить папки bin / obj и обязательно проверьте консолидацию NuGet.

Получим ли мы скоро поддержку RTL с 4.2 для Android и iOS?

Получим ли мы скоро поддержку RTL с 4.2 для Android и iOS?

Некоторая поддержка уже есть; Поддержка FlowDirection уже должна работать в элементах CollectionView. Что еще не окончено, так это направление прокрутки для горизонтальных макетов CollectionView. Направление прокрутки должно соответствовать FlowDirection на Android, но нам еще предстоит поработать над этим для других платформ; эта работа планируется завершить в 4.3.

Если вы столкнетесь с какими-либо ошибками при использовании FlowDirection с CollectionView, пожалуйста, откройте вопрос, и мы рассмотрим.

Не могли бы вы описать, что не сделано с поддержкой RTL?
Потому что в спецификации он даже не отмечен как выполняющийся или завершенный.

В четверг, 5 сентября 2019 г., 2:19 EZ Hart, [email protected] написал:

Получим ли мы скоро поддержку RTL с 4.2 для Android и iOS?

Некоторая поддержка уже есть; Поддержка FlowDirection уже должна быть
работа с элементами CollectionView. Что еще не закончено, так это свиток
направление для горизонтальных макетов CollectionView. Направление прокрутки
должно соответствовать FlowDirection на Android, но у нас еще есть работа, чтобы
сделайте это для других платформ.

Если вы столкнетесь с какими-либо ошибками при использовании FlowDirection с CollectionView,
пожалуйста, откройте вопрос, и мы рассмотрим.

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/xamarin/Xamarin.Forms/issues/3172?email_source=notifications&email_token=ACDWB3GSYAQSADERHWVTJX3QIANMNA5CNFSM4FHJRXPKYY3PNVWWK3TREX63-5VLVDNVWWK3TREXX5C05VWWGNVWWK4FHJRXPKYY3PNVWWK3TREXXXX4DVWW2
или отключить поток
https://github.com/notifications/unsubscribe-auth/ACDWB3HMFCHBRZWD5AJMXH3QIANMNANCNFSM4FHJRXPA
.

Не выполнено: направление прокрутки для горизонтальных макетов.

Если вы установите FlowDirection = RightToLeft для горизонтальной прокрутки CollectionView, направление прокрутки не будет прямо сейчас на iOS и UWP (я считаю, что это _работает_ на Android).

Как насчет шаблона LoadingDataTemplate?

По моему опыту асинхронной загрузки данных в ListView / CollectionView, иногда может оставаться пустое пространство, пока не будет заполнено listview / collectionview.

Добавление LoadingDataTemplate может обеспечить дополнительную скорость отклика, когда заполняются большие данные и страница уже появилась.

Я думаю, что есть два способа использования индикатора загрузки. Первый - когда изначально отображается CollectionView . Отображается несколько ячеек-заполнителей, пока данные не будут добавлены в коллекцию ItemsSource . Второй - когда в конец списка добавляются дополнительные данные. Что касается второго, я думаю, мы можем использовать нижний колонтитул?

Первый требует дополнительной работы (например, сначала загрузите источник с 3-5 элементами, имеющими один и тот же шаблон данных-заполнителей, а затем удалите эти элементы и добавьте фактические данные при их извлечении). Другой подход - разместить скелетный вид поверх CollectionView и скрыть его, когда данные будут готовы. В настоящее время я использую этот подход с помощью ListView .

Я не пробовал это, но мы могли бы сначала установить EmptyView в представление загрузки, а если результатов нет, изменить шаблон для EmptyView чтобы отображалось сообщение «ничего не найдено».

@ adrianknight89

Другой подход - поместить скелетный вид поверх CollectionView и скрыть его, когда данные будут готовы. В настоящее время я использую этот подход с помощью ListView .

Это похоже на тот же метод, которым я следую, то есть поставил какой-то индикатор активности выше. Установите для ListView значение IsVisible = false и ActivityIndicator IsVisible = true, затем инвертируйте оба значения после заполнения списка.

@ adrianknight89

Я не пробовал это сделать, но мы могли бы сначала установить EmptyView в режим загрузки, а если результатов нет, изменить шаблон для EmptyView, чтобы отображалось сообщение «ничего не найдено».

Есть идея! Хотя это может сработать, я считаю, что было бы проще иметь отдельные свойства шаблона в CollectionView, касающиеся LoadingDataTemplate и EmptyView.

Я согласен, что лучше иметь два разных свойства. За исключением аспекта простоты, использование одного свойства для двух разных целей не имеет большого смысла. Возможно, EmptyView следовало назвать BackgroundView чтобы мы могли использовать его для любых целей. (Изменить: BackgroundView - это совсем другое.)

@LeoJHarris Я добавил # 7447 для поддержки BackgroundView . Мы могли бы использовать EmptyView и BackgroundView для поддержки двух вышеупомянутых сценариев, хотя это еще не на 100% то, что вы хотите, но это должно быть лучше, чем использование EmptyView для поддержки обоих. сценарии. Вы можете использовать BackgroundView в качестве экрана загрузки и обнулить его, когда данные будут готовы.

@ adrianknight89 было бы здорово, если бы CollectionView обрабатывал «

При быстрой прокрутке страницы, использующей RemainingItemsThreshold CollectionView, мы сталкиваемся с двумя разными проблемами.

1. Приложение зависает, и его необходимо принудительно закрыть
2. Элементы в стеке CollectionView друг над другом (см. Изображение )

Не удалось найти кого-нибудь еще, у кого возникла эта проблема. Вы видели это в отчете?

@ Bronson15 Как вы справляетесь с событием RemainingItemsThresholdReached ? Быстрая прокрутка вызовет его несколько раз, поэтому вам нужно игнорировать вызовы событий, пока вы ждете обновления источника данных, иначе они будут накапливаться. Также попробуйте обновить свой пользовательский интерфейс в основном потоке.

Если у вас все еще возникают проблемы, вы можете открыть новую проблему с репродукцией для расследования.

@ Bronson15 оба вопроса.
Пробовал с ObservableRangeCollection и исправил # 2.
По-прежнему возникают проблемы с зависанием / пустым списком: при запуске на эмуляторе я вижу всплеск процессора, кажется, бесконечный цикл.

Edit: ломается только на iOS, на Android работает нормально.

Привет, команда,
Даже я пытался использовать RemainingItemsThreshold и RemainingItemsThresholdReachedCommand и заметил, что функция, назначенная RemainingItemsThresholdReachedCommand, вызывается несколько раз последовательно (первый раз вызывается дважды, в следующий раз 4 раза и т. Д.), Даже если я не прокручиваю быстро. Я также могу воспроизвести его с помощью свежего проекта Xamarin Forms (v.4.2.0.778463).
Можете ли вы попытаться воспроизвести это со своей стороны? Вот простой фрагмент кода ниже:

XAML:

<CollectionView
        x:Name="StackLayout"
        ItemsSource="{Binding LatestStories}"
        RemainingItemsThreshold="10"
        RemainingItemsThresholdReachedCommand="{Binding RemainingStoriesCommand}">
        <CollectionView.ItemTemplate>
            <DataTemplate>
            <Grid
                                ColumnSpacing="16"
                                HeightRequest="110"
                                RowSpacing="0">

                    <Grid.RowDefinitions>
                        <RowDefinition Height="*" />
                        <RowDefinition Height="Auto" />
                        <RowDefinition Height="Auto" />
                    </Grid.RowDefinitions>
                    <Grid.ColumnDefinitions>
                        <ColumnDefinition Width="Auto" />
                        <ColumnDefinition Width="*">
                        </ColumnDefinition>
                        <ColumnDefinition Width="Auto" />
                    </Grid.ColumnDefinitions>

                    <!--  Blog title  -->
                    <Label
                                    Grid.Column="1"
                                    Margin="0,8"
                                    FontSize="14"
                                    LineBreakMode="TailTruncation"
                                    LineHeight="{OnPlatform Default=-1,
                                                            Android=1.25,
                                                            iOS=1.25}"
                                    MaxLines="2"
                                    Text="{Binding Title}" />

                    <!--  Author name  -->
                    <Label
                                    Grid.Row="1"
                                    Grid.Column="1"
                                    Margin="0,8,0,0"
                                    FontSize="12"
                                    LineHeight="{OnPlatform Default=-1,
                                                            Android=1.5}"
                                    Text="{Binding Author}" />

                </Grid>
            </DataTemplate>
        </CollectionView.ItemTemplate>
</CollectionView>

Просмотреть модель:

public class ArticleListViewModel
    {
        public ObservableRangeCollection<FeedItem> LatestStories { get; } = new ObservableRangeCollection<FeedItem>();
        public Command RemainingStoriesCommand => new Command(() => RemainingStories());

        public ArticleListViewModel()
        {
            RemainingStories();
        }

        private async void RemainingStories()
        {
            var feeds = await GetRemoteFeedsAsync();
            try
            {
                Device.BeginInvokeOnMainThread(() =>
                {
                    LatestStories.AddRange(feeds);
                });

            }
            catch (Exception ex)
            {
                Debug.WriteLine(ex, "");
            }
        }

        private async Task<List<FeedItem>> GetRemoteFeedsAsync()
        {
            try
            {
                Stopwatch watch = new Stopwatch();
                watch.Start();
                var allItems = new List<FeedItem>();
                HttpResponseMessage response;
                var httpClient = new HttpClient();
                response = await httpClient.GetAsync("https://jsonplaceholder.typicode.com/photos").ConfigureAwait(false);
                if (response.IsSuccessStatusCode)
                {
                    var data = await response.Content.ReadAsStringAsync().ConfigureAwait(false);
                    var testData = JsonConvert.DeserializeObject<List<TestJson>>(data);
                    if (LatestStories.Count == 0)
                    {
                        testData = testData.Take(20).ToList();
                    }
                    else
                    {
                        testData = testData.Skip(LatestStories.Count).Take(20).ToList();
                    }

                    foreach (var item in testData)
                    {
                        var newItem = new FeedItem
                        {
                            Title = item.id.ToString(),
                            Description = item.title,
                            ImagePath = item.thumbnailUrl,
                            Link = item.url,
                            PublishDate = "2019-09-11",
                            Category = ""
                        };
                        allItems.Add(newItem);
                    }
                }
                watch.Stop();
                Debug.WriteLine("TPL Total Time: " + watch.ElapsedMilliseconds);
                return allItems;
            }
            catch (Exception ex)
            {
                Debug.WriteLine(ex, "");
                throw;
            }

        }
    }

@ Bronson15 @andreabalducci @techduggu Поскольку мы не блокируем пользовательский интерфейс во время обработки RemainingItemsThresholdReachedCommand , это нормально, если команда будет нажиматься несколько раз из-за ваших шаблонов прокрутки. Посмотрите, как я справляюсь с проблемой с помощью механизма блокировки: https://github.com/xamarin/Xamarin.Forms/pull/7516/files#diff -2be3eff4d53f761cd581cca1d2ec3bc0R48

Другие способы сделать это - включить / отключить вашу команду или отменить подписку / подписаться на событие, пока выполняется удаленная выборка. По моему опыту, семафор работал лучше всего, потому что иногда несколько вызовов запускаются к тому моменту, когда вы пытаетесь включить / отключить или отменить подписку / подписаться на обратный вызов.

@hartez @samhouts @davidortinau Думаю, в будущем эта проблема будет

@techduggu В вашем коде есть разные (незначительные) проблемы. Я бы отправил его код на рассмотрение на Stack Exchange. Сейчас не место для этого.

@ adrianknight89 Спасибо, что выделили термин «из-за ваших шаблонов прокрутки». Это вызвало у меня зуд узнать больше об этом. После ознакомления с официальной документацией RecyclerView и нескольких других ресурсов, да, я могу подтвердить, что он вызывается несколько раз из-за шаблонов прокрутки, и эти шаблоны - SCROLL_STATE_IDLE, SCROLL_STATE_DRAGGING или SCROLL_STATE_SETTLING в зависимости от нашего состояния прокрутки.
https://developer.android.com/reference/android/support/v7/widget/RecyclerView.OnScrollListener

Ваш код и это руководство по Android (https://github.com/codepath/android_guides/wiki/Endless-Scrolling-with-AdapterViews-and-RecyclerView) также подтверждает то же самое, что мы должны обрабатывать бесконечную прокрутку либо с помощью блокировки, либо с использованием из приведенных выше состояний прокрутки (что в основном требует настраиваемого средства визуализации). Следовательно, с Xamarin.Forms я попробовал ваш код, и он работал отлично. :) Я бы порекомендовал и поддержал ваше мнение, чтобы включить это предложение как часть документации, чтобы избежать таких вопросов, которые поднимают такие люди (с полусведущими), как я. :)

Также рег. незначительные проблемы, о которых вы упомянули для приведенного выше фрагмента кода - ну, это просто проект POC для тестирования бесконечной загрузки с помощью Collection View, однако я хотел бы знать ваш ввод, если вы заметили что-либо, кроме глупой нулевой проверки и т. д.

Спасибо!

@ adrianknight89 Ах да. Наша проверка занятости отсутствовала, и это помогло решить проблему стекирования.

Я также реализовал семафор, как вы предложили, и, похоже, это уменьшило проблему, когда при добавлении новых элементов в ItemsSource представление сбрасывало положение прокрутки в начало. Как ни странно, добавив вызов в попытке; наконец-то; как вы это делали в своем тестовом файле, вернул эту проблему.

По-прежнему возникает проблема с зависанием при прокрутке до конца списка. Вид становится пустым, и приложение зависает.

Изменить: сброс позиции прокрутки все еще существует, но не так часто. Рендеринг загрузки дополнительных элементов также очень прерывистый на устройстве.

@techduggu У меня нет VS со мной, но просто глядя на код, вы должны дождаться RemainingStories() , переместить удаленный вызов внутрь try и использовать using для HttpClient (в идеале используйте один статический экземпляр в вашем приложении и никогда не удаляйте его), но я остановлюсь на этом. :)

@ Bronson15 Возникла проблема с CollectionView, которая сбрасывала положение прокрутки и вызывала зависание пользовательского интерфейса. Я думаю, что это было исправлено с помощью # 7285, но это только для iOS. Можете ли вы протестировать последнюю версию Nuget и посмотреть, остались ли у вас проблемы? URL-адрес ночной ленты находится на главной странице GitHub для форм. Если проблема не исчезнет, ​​откройте проблему с кодом воспроизведения, чтобы мы могли проверить.

@ adrianknight89 Прокрутка с помощью ночной сборки. Похоже, проблема в основном решена (однажды я видел, что такое случалось). Похоже, что список сейчас просто зациклен, а не имеет конца. AFAIK в спецификации нет свойства, чтобы этого не произошло?

@ Bronson15 Бесконечного зацикливания быть не должно. Вы видите это на iOS или Android? Вам нужно завершить цикл, когда вы дойдете до конца вашего удаленного фида (т.е. немедленно вернетесь из RemainingItemsThresholdReachedCommand не выполняя другого вызова БД).

После остановки прокрутки просмотра команда больше не должна запускаться. Я использую Azure Cosmos, которая возвращает токен продолжения. Когда токен равен нулю, я знаю, что больше нет содержимого для загрузки, поэтому мой RemainingItemsThresholdReachedCommand работает на основе этого токена. Вам следует реализовать нечто подобное.

@ adrianknight89 Аааа. Интересный. Добавлена ​​проверка количества результатов и возврат, если он равен 0. Исправлена ​​бесконечная прокрутка. Спасибо вам за помощь!

@ adrianknight89 протестирован почти на предмет сбоя iOS, наконец-то работает. все равно "намного" медленнее, чем Android.
с 1000 элементами на Android почти в реальном времени, на iOS нужно подождать 5-7 секунд, чтобы отобразить представление. обе отладки, iPhone Xs и Redmi Note 7

@andreabalducci Ты на симуляторе XS? Как поведение на физическом устройстве? Если рендеринг представления выполняется медленно, это может быть еще одна проблема с iOS, которую необходимо изучить. Опять же, было бы здорово увидеть репродукцию.

@ adrianknight89 @andreabalducci да, на моем Xs Max требуется около 1-5 секунд, чтобы загрузить больше предметов. Представление очищается и повторно загружает все элементы, а не добавляет элементы в уже созданный список.

@ adrianknight89 оба физических устройства, эмулятор iOS имеет те же проблемы.

Мы удалили весь стек из шаблонов данных и немного повысили скорость переключения на FormattedString, включили скомпилированные привязки, прежде чем iOS превысила 20 секунд.

На iOS все отображается черным и перерисовывается при добавлении ObservableRangeCollection (из помощников mvvm), на Android работает нормально.

Для меня это звучит как отдельная проблема. Я не думаю, что это связанные с остальными предметами.

Возможно ли при использовании GridItemsLayout разрешить элементам занимать несколько строк или столбцов? Это определенно была бы функция, которую стоило бы иметь.

Есть информация по этому поводу?

@LynoDesu Для этого отслеживается проблема: https://github.com/xamarin/Xamarin.Forms/issues/6357

@LynoDesu Для этого отслеживается проблема: # 6357

Ах, отлично! Спасибо. С чего мне начать, если я хочу внести в это свой вклад?

Прочтите wiki домашней страницы, а также Contributing.md .

@ adrianknight89 обнаружил пробел + вернуться к началу, воспроизведите здесь https://github.com/andreabalducci/XamarinCollectionView/blob/b186e563ff8391dfb473e62e5a4c4587e8d4e9da/cvrepro/cvrepro/ListViewModel.cs#

Запуск с пустой коллекцией вызывает проблему, если в коллекции есть какие-либо элементы до привязки, все работает должным образом.

протестирован на эмуляторе iPhone.

Я вижу проблему. Вероятно, это то же самое, что и # 7548. Возможно, вы захотите разместить там свое изображение.

CollectionView, похоже, ошибается на Android при использовании IsGrouped.

CollectionView.GroupHeaderTemplate вообще не отображается. На iOS работает нормально. Вы можете просто использовать пример группировки с сайта Microsoft, чтобы проверить это.

    public class AnimalGroup : List<Animal>
    {
        public string Name { get; private set; }

        public AnimalGroup(string name, List<Animal> animals) : base(animals)
        {
            Name = name;
        }
    }

    public class Animal
    {
        public string Name { get; set; }
        public string Location { get; set; }
        public string Details { get; set; }
        public string ImageUrl { get; set; }
    }

    public List<AnimalGroup> Animals { get; private set; } = new List<AnimalGroup>();

    Animals.Add(new AnimalGroup("Bears", new List<Animal>
        {
            new Animal
            {
                Name = "American Black Bear",
                Location = "North America",
                Details = "Details about the bear go here.",
                ImageUrl = "https://upload.wikimedia.org/wikipedia/commons/0/08/01_Schwarzbär.jpg"
            },
            new Animal
            {
                Name = "Asian Black Bear",
                Location = "Asia",
                Details = "Details about the bear go here.",
                ImageUrl = "https://upload.wikimedia.org/wikipedia/commons/thumb/b/b7/Ursus_thibetanus_3_%28Wroclaw_zoo%29.JPG/180px-Ursus_thibetanus_3_%28Wroclaw_zoo%29.JPG"
            },
        }));

<CollectionView ItemsSource="{Binding Animals}"
                        IsGrouped="true">
            <CollectionView.GroupHeaderTemplate>
                <DataTemplate>
                    <Label Text="Header"
                           BackgroundColor="LightGray"
                           FontSize="Large"
                           FontAttributes="Bold" />
                </DataTemplate>
            </CollectionView.GroupHeaderTemplate>
            <CollectionView.ItemTemplate>
                <DataTemplate>
                    <Grid Padding="10">
                        <Image Grid.RowSpan="2"
                               Source="{Binding ImageUrl}"
                               Aspect="AspectFill"
                               HeightRequest="60"
                               WidthRequest="60" />
                        <Label Grid.Column="1"
                               Text="{Binding Name}"
                               FontAttributes="Bold" />
                        <Label Grid.Row="1"
                               Grid.Column="1"
                               Text="Child"
                               FontAttributes="Italic"
                               VerticalOptions="End" />
                    </Grid>
                </DataTemplate>
            </CollectionView.ItemTemplate>
        </CollectionView>

https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/collectionview/grouping

Важный

Группирование данных с помощью CollectionView в настоящее время поддерживается только в iOS.

Упс, я пропустил эту часть. Спасибо.

Для тех из нас, кто хочет отображать сгруппированный список как на iOS, так и на Android, но не хочет использовать ListView, есть ли что-нибудь еще, что мы можем использовать так же гибко, как CollectionView на данный момент? Или мы застряли на ListView?

Надеюсь, это правильное место, чтобы спросить. Я вижу, что в исходной опубликованной спецификации есть свойства для IsHeaderSticky и IsFooterSticky , но я не вижу дальнейшего упоминания о них нигде в обсуждении или реализованном исходном коде. Они все еще в планах для этого представления?

В collectionview нам нужны ItemAppeared, ITemDisappeared.
есть ли способ добиться?

@IosDeveloperHarsh Событие Scrolled предоставляет много полезной информации в аргументах событий. Посмотрите там индексы первого и последнего видимых элементов.

@ rafiwardak2003 Образцы галереи с группами CollectionView на сегодняшний день работают на Android, хотя я не запускал образец, который вы предоставили. Какой Nuget вы использовали? Попробуйте использовать последнюю предварительную версию или каждую ночь.

@ cabal95 Я не могу ответить на этот вопрос, но если бы мне пришлось догадываться, они в конечном итоге будут реализованы. Возможно, нам нужно иметь активный выпуск, чтобы отслеживать это. Я знаю, что первоначальная работа с верхним и нижним колонтитулами исключила липкие материалы.

Я думаю, что SelectionChangedCommandParameter следует удалить, и вместо этого мы автоматически установим выбранный элемент в качестве параметра.

Если возможно, было бы неплохо использовать это свойство

public ICommand => new Command<MySelectedItemModel>((item) => {}

Но это тоже должно быть нормально:

public ICommand => new Command<object>((item) =>{ var selectedItem = item as MySelectedItemModel;}

Я думаю, что SelectionChangedCommandParameter следует удалить, и вместо этого мы автоматически установим выбранный элемент в качестве параметра.

Если возможно, было бы неплохо использовать это свойство

public ICommand => new Command<MySelectedItemModel>((item) => {}

Но это тоже должно быть нормально:

public ICommand => new Command<object>((item) =>{ var selectedItem = item as MySelectedItemModel;}

Что, если пользователь хочет использовать что-то другое, кроме SelectedItem, в качестве параметра своей команды?

Я думаю, что SelectionChangedCommandParameter следует удалить, и вместо этого мы автоматически установим выбранный элемент в качестве параметра.
Если возможно, было бы неплохо использовать это свойство
public ICommand => new Command<MySelectedItemModel>((item) => {}
Но это тоже должно быть нормально:
public ICommand => new Command<object>((item) =>{ var selectedItem = item as MySelectedItemModel;}

Что, если пользователь хочет использовать что-то другое, кроме SelectedItem, в качестве параметра своей команды?

Вы правы, но мне трудно найти вариант использования для этого, потому что вы устанавливаете параметр на уровне CollectionView. Я ожидал, что это будет выбранный элемент при первом использовании. Но, может быть, можно установить выбранный элемент по умолчанию? Если вы воспользуетесь этим событием, вы получите его, поэтому я думаю, что многие разработчики ожидают его и от команды.

Я также хотел бы запросить функцию, чтобы этот CollectionView не растягивался на весь экран, а просто использовал высоту, зависящую от количества элементов.

Я пытаюсь иметь в виду несколько списков
т.е.
Покупки

Отчисления

Всего
Всего
малыш

но элементы 1 и 2 (CollectionView) просто заняли слишком большую высоту, даже если у меня есть только 3 или 4 элемента, и есть пробел BIIIIIIIIIIIIIIIG ниже, прежде чем я смогу увидеть раздел Deductions

В итоге я создал свой собственный элемент управления ItemsCollection на основе StackLayout

Я также хотел бы запросить функцию, чтобы этот CollectionView не растягивался на весь экран, а просто использовал высоту, зависящую от количества элементов.
В итоге я создал свой собственный элемент управления ItemsCollection на основе StackLayout

Я думаю, что то, что вы ищете, может быть привязанными макетами .

Я также хотел бы запросить функцию, чтобы этот CollectionView не растягивался на весь экран, а просто использовал высоту, зависящую от количества элементов.
В итоге я создал свой собственный элемент управления ItemsCollection на основе StackLayout

Я думаю, что то, что вы ищете, может быть привязанными макетами .

Привет! Именно то, что мне нужно. С каких пор существует BindableLayouts?

Всем спасибо за обсуждение этого вопроса! Если у вас есть какие-либо дополнительные запросы функций или отчеты об ошибках, открывайте новые проблемы для каждого из них. Сейчас мы закрываем этот вопрос.