Que diriez-vous de l'événement de défilement pour prendre en charge les en-têtes de parallaxe

Il y a beaucoup à aimer à ce sujet.

FontIconSource

Pour FontIconSource, nous avons vraiment besoin d'un moyen de ne pas utiliser la valeur Unicode (si nous ne le voulons pas). Si vous regardez une FontIconSource avec une valeur f370 vous n'avez aucune idée de ce que c'est censé être.

D'un autre côté, si je peux choisir la police d'icône que j'utilise et donner à Forms un moyen de convertir fa-app-store-ios en son équivalent unicode de f370 , maintenant je peux savoir en un coup d'œil que l'icône que j'utilise provient de Font Awesome et qu'il s'agit de l'icône iOS App Store. Je ne dis en aucun cas que Forms devrait avoir cette compréhension pour chaque police disponible intégrée (ou toute autre d'ailleurs), qui peut provenir de certains éléments publics ou être ajoutée à la boîte à outils communautaire, etc. De toute façon, nous avons besoin d'un façon d'utiliser des noms significatifs.

Enfin, j'espère que nous pourrions obtenir une extension XAML pour cela afin que vous puissiez avoir quelque chose comme :

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

Menus

Comme je discutais plus tôt avec @davidortinau , ce serait particulièrement idéal si nous pouvions mélanger et assortir les menus contextuels pour obtenir les résultats appropriés. Un bon contexte à ce sujet serait de penser à un client de messagerie dans lequel vous pouvez obtenir un menu lorsque vous balayez vers la gauche et un autre lorsque vous balayez vers la droite. Un autre scénario que j'aimerais voir pris en charge serait l'approche du menu des cellules, comme indiqué dans les documents pour iOS CollectionView .

Événements

Je pense qu'il est prudent de dire que je suis partial, mais une très grande partie de la communauté suit un modèle de conception MVVM. Avoir les événements SelectionChanged & RemainingItemsThresholdReached sont tous deux importants pour l'API, mais ce serait fantastique si nous pouvions trouver un moyen de prendre en charge ces OOB avec une version ViewModel d'un gestionnaire d'événements... un Je commande.

Étant donné que RemainingItemsThresholdReached envoie simplement un ancien EventArgs simple, je pense que nous pouvons supposer en toute sécurité que le passage de null à la commande devrait être correct car nous avons juste besoin d'exécuter la commande. Pour le SelectionChanged, j'aurais tendance à penser qu'il serait plus vital de connaître les nouveaux éléments que les anciens éléments, donc le simple fait de transmettre les nouveaux éléments OOB à un SelectionChangedCommand devrait convenir. Cela peut ne pas toucher tous les cas d'utilisation, mais cela fournit au moins une surcharge minimale qu'un développeur doit ajouter avec un certain EventToCommandBehavior.

L'échantillon parfait qui tue la liste actuelle fait le contrôle du calendrier où :
-days (cells) peuvent avoir plusieurs styles :
comme jour de promotion, anniversaire, handicapé / jour de non-vente / jour férié ...
icônes intégrées avec différentes polices personnalisées, la cellule a des ombres si elle est sélectionnée, autre style lorsqu'elle est en r
rage, autre au début et à la fin de la plage
-la sélection de tranches de date est possible
-en-tête du mois et style d'en-tête personnalisé
-les en-têtes de mois ont des boutons qui permettent des vues/actions/affichages spéciaux sur le mois en cours

Que diriez-vous d'ajouter également un GroupFooterTemplate ?

C'est tellement nécessaire dans Forms :-) CollectionView éliminerait les solutions de contournement coûteuses, résoudrait les limitations et améliorerait probablement les performances dans à peu près toutes les applications Forms que j'ai créées au cours des 5 dernières années. Exactement la bonne approche également : exploitez et exposez la puissance des plates-formes natives.

S'il n'y avait qu'UNE amélioration que je pouvais demander pour les formulaires, ce serait celle-ci.
(en fait, je l'ai fait en 2017 en réponse à @davidortinau)

C'est vraiment génial et tant attendu ! L'API est propre et simple (merci d'avoir renommé HasUnevenRows !).

Les événements de défilement sont très nécessaires, comme suggéré par @dhaligas. Pour les animations de parallaxe mais aussi pour masquer le bouton d'action flottant lors du défilement par exemple.

FontIconSource est une bonne idée. Il peut être intéressant de fournir une liste d'icônes par défaut, avec Unicode mappé pour chaque plate-forme (similaire à iOS ou UWP).

Cela ressemble exactement à ce qui est nécessaire. L'API a l'air beaucoup plus propre, le fait d'avoir plusieurs vues/conteneurs structurés de cette manière devrait aider à garder le code plus propre et plus simple.

Mes commentaires pour l'instant :

@dansiegel Une commande lorsque le seuil des éléments restants est atteint serait la bienvenue. Pas sûr que cela soit nécessaire pour SelectedItems - tout ce que vous dites (notifié des changements, ce qui a changé et même pourquoi) est géré automatiquement tant que SelectedItems est une ObservableCollection (ou tout ce qui implémente INotifyCollectionChanged). Je préfère avoir le moins de code possible dans CollectionView pour réduire la complexité.

Défilement : je suis tout à fait d'accord sur l'événement de défilement. Nous pouvons l'obtenir pour le moment pour Android, mais pour iOS, vous devez envelopper le UITableViewSource et détourner la méthode Scrolled.

Le plus important pour moi serait l'extensibilité. Veuillez ne pas utiliser de classes internes pour les adaptateurs et les TableViewSources, et s'il vous plaît, dans les moteurs de rendu natifs, exposez les méthodes "CreateAdapter" et "CreateViewSource" (et similaires pour d'autres plates-formes) où nous pouvons créer notre propre type si nous le souhaitons. Nous avons un ListAdapter personnalisé pour la prise en charge du glisser-déposer sur Android, et comme mentionné précédemment, un UITableViewSources personnalisé pour le défilement et le glisser-déposer. Ce n'est pas du code que j'aime bien parce qu'il y a un emballage de classes internes, etc.

Cela ne s'applique pas seulement aux adaptateurs/sources de visualisation. En général, dans la nouvelle API, veuillez ajouter des points où nous pouvons étendre le comportement si nécessaire.

Je pense que c'est une fonctionnalité vraiment géniale et importante!
iOS utilise déjà le nom UICollectionView, ce qui peut entraîner une confusion et des résultats Google incorrects lors de la recherche de CollectionView. Est-ce un problème?

Juste pour m'en débarrasser, j'aime fondamentalement tout ce qui concerne les spécifications CollectionView . Cela pourrait valoir la peine de diviser certaines choses en problèmes distincts, car j'ai des réflexions à leur sujet, comme je suis sûr que beaucoup d'autres le font et je peux voir que les conversations deviennent difficiles à suivre. Par example:

Cela pourrait être ajouté plus tard, mais quelque chose comme :

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

serait utile, pour prendre en charge les icônes d'empilement : https://fontawesome.com/how-to-use/on-the-web/styling/stacking-icons

Mes commentaires:

1. Je ne mettrais pas les capacités de sélection d'éléments dans la classe CollectionView. Au lieu de cela, j'ajouterais une classe de base abstraite ListCollectionView dérivée de CollectionView qui a des capacités spécifiques :

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; }
}

Mon idée est d'avoir un CollectionView similaire à ItemsControl dans Windows XAML. Le ItemsControl prend une instance de Panel qui positionne les éléments. Dans Forms, nous aurons CollectionView et IItemsLayout.
Par défaut, si aucun IItemLayout n'est fourni, la disposition par défaut pourrait être une disposition en pile. De cette façon, nous pourrions essentiellement combiner ItemsSource avec StackPanel de Windows XAML, ou en d'autres termes, un StackLayout pouvant être lié !

En plus de la sélection d'éléments, il existe d'autres fonctionnalités que je n'aurais pas mises dans CollectionView, je les ajouterais à ListCollectionView. Par exemple, le CollectionView ne doit pas avoir de défilement. De cette façon, il couvrira ce fil

1. Je renommerais l'interface IItemsLayout en ICollectionViewLayout. Le framework a déjà Layout et ItemsView . Ce serait un nom plus long, mais ICollectionViewLayout est une indication forte à quoi il sert, il est spécifique à CollectionView, pas à une manière générale d'afficher des éléments.

2. Je renommerais la classe ItemsLayout en OrientedCollectionViewLayout. C'est une indication forte à quoi sert réellement la classe de base abstraite, toutes les classes dérivées disposent les éléments de manière orientée. De plus, l'utilisation de "Oriented" dans le nom donne la possibilité à l'avenir d'ajouter une classe de base abstraite appelée simplement "CollectionViewLayout". si une nouvelle fonctionnalité commune est requise pour toutes les classes de disposition de vue de collection, pas seulement celles qui ont une orientation.

3. Supprimer ViewCell et utiliser simplement DataTemplate est le bienvenu, cela améliore la réutilisation.

1. Pouvez-vous partager plus de détails sur RefreshView ?
   Je suppose que RefreshView devrait en quelque sorte correspondre à UIRefreshControl sur iOS ? Comment cela fonctionnera-t-il sur Android et UWP ?

Au cas où quelqu'un serait intéressé, j'ai apporté quelques mises à jour à mon premier commentaire ci-dessus.

Je suis d'accord avec @andreinitescu qu'il serait bon d'avoir un moyen d'avoir une collection sans défilement. Je suis neutre si cela signifie le diviser en plusieurs classes ou éventuellement avoir quelque chose comme une propriété ScrollMode. Je m'en remettrai à ceux qui ont beaucoup plus d'expérience en conception d'API que moi à ce sujet. Mais il est assez trivial d'implémenter votre propre liste d'éléments basée sur StackLayout avec un DataTemplate ou un sélecteur de modèle, donc ce n'est peut-être pas nécessaire.

Bien que j'aime l'idée de contrôler la fonction de défilement, je ne propose pas non plus de cas d'utilisation convaincants pour une "Collection" sans défilement qui inclut toutes les fonctionnalités avancées de ListView ou de la CollectionView proposée du haut de ma tête. Mon cas d'utilisation d'une liste non défilante a toujours été résolu par la liste d'éléments triviaux. Ma raison normale pour ne pas utiliser ListView est que je ne veux pas de sélection ou que je veux disposer la liste horizontalement. Ces deux cas semblaient être couverts par la spécification proposée. Je serais intéressé par tous les exemples d'utilisation que quelqu'un d'autre a pour aucun parchemin.

@bmacombe Je suis d'accord avec vous pour dire qu'il est "simple" d'implémenter un StackLayout pouvant être lié, mais ce n'est pas le point je pense. C'est une fonctionnalité très courante, pourquoi ne pas l'avoir dans le framework ? Et avec un peu de planification, je pense que cela peut être fait. Comme je l'ai déjà dit ci-dessus, il peut être résolu en répartissant simplement la fonctionnalité dans deux classes, une classe de base (similaire à ItemsControl dans Windows XAML) et CollectionView (ListView). Idéalement, il devrait y avoir une classe Selector dans la hiérarchie (voir https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.controls.primitives.selector)

Je dirais que la raison triviale d'avoir une option sans défilement est que certaines pages doivent avoir un ScrollView pour toute la page et une liste d'éléments.

Si vous faites cela, il n'est pas recommandé pour le moment de mettre un ListView dans un ScrollView. Un CollectionView pouvant être lié que vous pourriez y mettre, qui a toujours potentiellement toutes les fonctionnalités d'un ListView, est quelque chose dont j'ai eu besoin à plusieurs reprises.

J'ai écrit la même chose BindableStack que tout le monde fait, mais un cuit dans un serait beaucoup plus agréable de travailler avec.

@adammeaney Cela a du sens et j'ai fait la même chose maintenant que j'y pense.

@andreinitescu Je ne suis pas en désaccord, ce serait formidable de l'avoir intégré. Je pense que tout le monde est sur la même

Dans mes propres frameworks, je fais toujours des allers-retours pour construire de nombreuses fonctionnalités dans un seul contrôle ou j'ai beaucoup de classes similaires avec des fonctions incrémentielles. Je serai bon avec, mais l'équipe Forms décide de l'implémenter au mieux, en particulier compte tenu des implémentations de la plate-forme sous-jacente.

@bmacombe Avec un peu de planification, j'espère que nous pourrons faire d'une pierre deux
Par exemple, une instance de la classe CollectionView fonctionnant comme je l'ai mentionné, si elle n'a pas de IItemLayout défini, elle pourrait simplement être mappée par le mécanisme de rendu à un UIStackView natif sur iOS ou StackPanel sur UWP ou LinearLayout sur Android. Ou, pour être plus facile à implémenter, il pourrait simplement utiliser le StackLayout existant pour organiser les vues.

Mon impression était qu'un nouveau ListView devrait viser à la fois à résoudre les problèmes avec ListView existant mais également à fournir une solution au fil "RepeatableBinder" ici

Nous voulons voir où ListView2 atterrit avant de faire avancer cette spécification. Il contient bon nombre des mêmes composants nécessaires et il serait préférable d'éviter de les dupliquer.

Je ne vois pas comment mettre toutes les fonctionnalités dans CollectionView comme le suggère la spécification ici ferait le travail correctement.

2680 Pourrait-il être ajouté à cette spécification ? En ce qui concerne l'activation de ScrollBar.

@andreinitescu

Pouvez-vous partager plus de détails sur RefreshView ?
Je suppose que RefreshView devrait en quelque sorte correspondre à UIRefreshControl sur iOS ? Comment cela fonctionnera-t-il sur Android et UWP ?

Sur UWP, nous utiliserons probablement RefreshContainer . Sur Android, probablement SwipeRefreshLayout .

@krdmllr

iOS utilise déjà le nom UICollectionView, ce qui peut entraîner une confusion et des résultats Google incorrects lors de la recherche de CollectionView. Est-ce un problème?

C'est un problème, mais pas nouveau. Nous avons le même problème avec GestureRecognizer, ListView, Grid et bien d'autres choses dans Forms. Nous avons lutté un peu avec cela en interne; il n'y a qu'un nombre limité de noms possibles pour "un tas d'éléments sur un écran".

"CollectionView" n'entre pas en conflit avec tout ce que nous avons actuellement dans Forms, il n'entre en conflit avec aucun nom de contrôle UWP (comme le fait "ListView") et ce n'est pas _exactement_ comme UICollectionView (à cause du préfixe "UI"). Ce n'est pas 100 % idéal à des fins de recherche, mais nous pensons que c'est la meilleure expression de l'intention du contrôle.

Cela dit, si quelqu'un propose un autre nom dont nous tombons immédiatement amoureux, je suis heureux de faire la recherche et le remplacement.

(Je voulais l' appeler "ListView2ColonRevengeOfTheListView", mais

@dansiegel

Un bon contexte à ce sujet serait de penser à un client de messagerie dans lequel vous pouvez obtenir un menu lorsque vous balayez vers la gauche et un autre lorsque vous balayez vers la droite.

Jetez un œil à la spécification SwipeView - c'est précisément ce que nous

@GalaxiaGuy

prendre en charge les icônes d'empilage

C'est un excellent point, nous devrions soutenir cela si possible. Je sais que cela fonctionne avec les glyphes UWP intégrés ; Je devrais faire une petite recherche pour m'assurer que ce type d'empilement fonctionnerait sur les autres plates-formes (je suppose que la réponse est "oui").

Mise à jour : la partie FontIconSource de cette spécification a été déplacée dans sa propre spécification .

Je ferais un scénario utilisateur pour le multi-picking des éléments d'une sélection, par exemple la sélection d'une ou plusieurs photos d'un album. Un scénario assez courant dans des applications comme OneDrive ou WhatsApp.

@hartez

Cela dit, si quelqu'un propose un autre nom dont nous tombons immédiatement amoureux, je suis heureux de faire la recherche et le remplacement.

J'ai déjà suggéré un nouveau nom pour différentes raisons

Quelle sera la valeur du SelectedItem quand le SelectionMode est Multiple ? Il y a 5 options auxquelles je peux penser:

1. Le dernier élément sélectionné par ordre de sélection.
   
2. Le dernier élément sélectionné par ordre de source.
   
3. Le dernier élément sélectionné/désélectionné par ordre de sélection.
   
4. Le dernier élément sélectionné/désélectionné par ordre de source.
   
5. nul
   
   
   
   (2), (3) et (4) ne sont pas très utiles. Je les ai ajoutés juste pour couvrir toutes les options. (1) semble être le choix le plus logique. (5) si vous ne voulez pas du tout prendre en charge SelectedItem si le SelectionMode est Multiple .

@AmrAlSayed0

Quelle sera la valeur de SelectedItem lorsque SelectionMode est Multiple ?

À l'heure actuelle, la réponse est "ce que c'était avant de passer de SelectionMode à Multiple ".

@rogihee

Je ferais un scénario utilisateur pour la sélection multiple d'articles à partir d'une sélection

Vous demandez-vous si ce scénario de sélection est pris en charge ? AFAIK, tous les contrôles natifs que nous avons l'intention d'utiliser le prennent en charge, il devrait donc être pris en charge dans CollectionView.

Un style pouvant être lié pour SelectionMode serait utile, si SelectionMode=None, Transparent etc, c'est quelque chose que Radlist fait qui est un moyen très utile et facile de gérer l'état visuel basé sur les liaisons. Un style pour chaque mode de sélection couvrirait ces scénarios.

@andreinitescu

En réponse à vos commentaires de https://github.com/xamarin/Xamarin.Forms/issues/3172#issuecomment-401015625 (et ailleurs) :

Vous soulevez de nombreux points positifs et je veux m'assurer que vous sachiez que nous ne les ignorons pas. Nous ne connaissons pas encore toutes les réponses. Nous sommes en train de développer cette API afin que nous puissions voir où elle fonctionne et où elle s'effondre ; Je soupçonne que la répartition des classes que vous proposez est assez proche de l'endroit où nous devrons nous retrouver.

Nous reconnaissons que vous (et plusieurs autres) êtes très désireux que ces classes intermédiaires soient rendues en tant que StackLayouts et Grids d'éléments modélisés (c'est-à-dire le "BindableRepeater"), et c'est l'un des cas d'utilisation que nous explorons.

@alexhardwicke

En général, dans la nouvelle API, veuillez ajouter des points où nous pouvons étendre le comportement si nécessaire.

Les méthodes UpdateX dans les moteurs de rendu seront protected virtual . :)

Plus sérieusement, nous sommes conscients que cela a été un problème dans le passé, et nous le gardons à l'esprit en écrivant CollectionView .

1. À la réflexion, je ne pense vraiment pas que CollectionView soit un bon choix pour le nom de classe de cette vue.
   Dans Windows XAML, une CollectionView est la classe de base pour une source de données d'éléments utilisée pour filtrer le regroupement, voir https://msdn.microsoft.com/en-us/library/system.windows.data.collectionview (v=vs. 110).aspx
   Peut-être qu'à un moment donné, Xamarin Forms obtiendra une classe dans le même but, et je pense que cela aura du sens s'il porte le même nom (CollectionView), en particulier lorsque l'on pense à XAML Standard (est-ce toujours prévu ?)

   Aussi moche et drôle que cela puisse paraître, ListView2 est un bon choix :) C'est la pratique recommandée dans .NET d'utiliser le suffixe pour la gestion des versions lorsque le nom existant est le seul nom qui a du sens :

   UTILISEZ un suffixe numérique pour indiquer une nouvelle version d'une API existante, en particulier si le nom existant de l'API est le seul nom qui a du sens (c'est-à-dire s'il s'agit d'une norme de l'industrie) et si vous ajoutez un suffixe significatif (ou modifiez le nom) n'est pas une option appropriée.

   _Consignes de conception de cadres : conventions, expressions idiomatiques et modèles pour les bibliothèques .NET réutilisables, 2e édition_
   https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/general-naming-conventions

   Plus tard, tout le monde utilisera le nouveau, brillant. ListView2 stable et performant :). Avance rapide, renommer ListView2 en ListView, bien qu'il s'agisse d'un changement radical, sera une refactorisation simple (et bienvenue) pour tout le monde.

2. Dans Xamarin Forms, il existe déjà un ItemsViewqui ressemble beaucoup à ItemsControl dans Windows XAML, sauf qu'il n'a pas de propriété de disposition des éléments.
   Au lieu de créer une nouvelle classe CollectionView, serait-il possible d'utiliser les ItemsView existantségalement comme classe de base pour le nouveau ListView ?

3. Il y a un défi évident dans la conception et la mise en œuvre de l'API, avec l'utilisation des contrôles de plate-forme natifs qui affichent des éléments de liste mais qui ont toujours la possibilité d'avoir quelque chose comme le "BindableRepeater" qui est censé afficher un simple, plus léger, non défilable et non -liste sélectionnable d'articles.
   On dirait qu'Uno a réussi à le faire :

   • 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

Au lieu de créer une nouvelle classe CollectionView, serait-il possible d'utiliser les ItemsView existants également comme classe de base pour le nouveau ListView ?

Il y a ItemsView<T> , mais nous ne voulons pas l'utiliser. Il utilise TemplatedItemsList , ce qui fait partie du problème que nous essayons d'éviter avec ce nouveau contrôle.

Plus tard, tout le monde utilisera le nouveau, brillant. ListView2 stable et performant :). Avance rapide, renommer ListView2 en ListView, bien qu'il s'agisse d'un changement radical, sera une refactorisation simple (et bienvenue) pour tout le monde.

Votre optimisme est charmant, mais nous devons travailler en supposant que ListView (1) est éternel et qu'un changement de rupture comme un renommage de ListView2 ne sera pas autorisé.

Je pensais qu'être à égalité avec Windows XAML était logique, mais d'accord, utilisez le nom que vous voulez, tant que le nouveau contrôle tient ses promesses. Le framework Uno semble avoir réussi à le faire, alors maintenant j'ai hâte de voir ce que vous apportez dans Xamarin Forms.

@gmwilhelm

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

Bon point. J'ai provisoirement ajouté cela à l'API. Je dis provisoirement, car je peux tout à fait voir comment nous pourrions l'implémenter sur iOS et Android, mais UWP pourrait être un défi.

Mais je ne peux pas nier que c'est à la fois raisonnable et agréablement symétrique.

Que diriez-vous d'ajouter GroupItemsBinding ?

Cela permettrait à un groupe de contenir une propriété de type collection, au lieu d'exiger qu'un groupe soit dérivé d' une collection, comme le fait ListView. Cette limitation ListView existante m'a forcé à faire une duplication coûteuse en performances de structures de données regroupées à plusieurs reprises. L'ajout de GroupItemsBinding empêcherait cela et permettrait un mappage plus flexible aux structures de données regroupées.

C'est-à-dire que l'exemple utilisé dans la documentation GroupDisplayBinding pourrait être :

```C#
class Group // Notez que Group n'a pas à dériver de ObservableCollection
{
public Group (string 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 = new Binding (nameof(Group.Persons))
// ...
} ;
// ...
}

```

Étant donné qu'il s'agit d'un sous-ensemble de ce que fait UICollectionView en termes de mise en page, je pense que nous devrions choisir un nom différent pour éviter toute confusion avec les capacités du contrôle.

Juste pour être clair, ce contrôle n'est pas disponible pour être utilisé mais correct ? J'ai essayé de le référencer mais mon projet ne le trouve pas

@titonton Ce problème est juste pour discuter de la spécification de CollectionView, la mise en œuvre n'a même pas encore commencé, et je ne pense pas qu'elle le sera tant que la spécification ne sera pas finalisée.

@AmrAlSayed0 En fait, cela aurait dû commencer car il a été déplacé vers "En cours dans le Sprint 139" il y a 11 jours.

On ne sait pas trop comment cela a commencé étant donné qu'on ne sait pas quelle est la décision concernant l'API

@opcodewriter C'est ce que je pensais. @AmrAlSayed0 Merci pour la clarification.

Quelqu'un pourrait-il préciser quel est l'état actuel de cette spécification? Manque-t-il quelque chose où la communauté peut aider ?

@migueldeicaza @hartez Nommer cela va être difficile si vous ne voulez pas qu'il soit nommé CollectionView . Que diriez-vous de CatalogView ?

Les catalogues sont souvent conçus dans une ou plusieurs colonnes et avec plusieurs rangées d'articles avec des polices, des textes, des mises en page, etc. similaires.

Goûter:

@hartez Avez-vous l'impression que les API sont presque terminées maintenant ? Combien de travail a été fait à ce sujet jusqu'à présent? Beaucoup d'entre nous aimeraient mettre la main sur ce contrôle dès que possible. :)

@ adrianknight89 Je crois que c'est la branche de travail. https://github.com/xamarin/Xamarin.Forms/tree/lv2spike

Nous ne prévoyons pas qu'il soit prêt pour la prévisualisation avant un certain temps, mais je présenterai/démonstrerai les résultats de l'effort actuel dans les semaines à venir pour valider les progrès et obtenir des commentaires rapides.

Je suis confus. Puisque vous avez déjà eu quelques démos internes, il semble que vous soyez déjà assez avancé dans la mise en œuvre.
Cela ne devrait-il pas signifier qu'une grande partie de l'API a été fixée ? Suivez-vous les spécifications de l'API ici ?
Je ne vois pas comment la spécification actuelle pourra répondre à ce qui a été discuté ici et sur l'autre fil ici https://github.com/xamarin/Xamarin.Forms/issues/1718
Pour être plus précis, l'API n'est pas assez flexible pour permettre par exemple un simple contrôle de type StackLayout non défilant et liant.

Le nouveau contrôle permet-il de placer des éléments liés dans une pile, sans barre de défilement, tout comme StackLayout ?

Merci tant attendu pour cela

Après de nombreuses discussions internes et des tentatives pour élaborer une architecture appropriée, nous avons décidé que CollectionView _pas_ gérera les scénarios de mise en page discutés dans #1718. En d'autres termes, il ne gérera pas la liaison d'une collection d'objets à des éléments dans les mises en page Xamarin.Forms.

L'objectif initial de CollectionView était de permettre aux utilisateurs d'exploiter facilement les divers contrôles de liste/grille natifs modernes (UICollectionView, RecyclerView, ListView/GridView, etc.).

Il était tentant d'essayer de faire de CollectionView un contrôle unique pour tous les besoins de "rendu et d'organisation de ce modèle avec des données", y compris tous les scénarios où l'étape "organiser" était gérée par Forms Layouts (FlexLayout, StackLayout, etc. ). Et il existe des chevauchements de fonctionnalités évidents (par exemple, les deux scénarios utilisent des DataTemplates). Mais en fin de compte, ils ont une grande différence d'architecture fondamentale, et tenter de les assembler entraînerait quelque chose de plus difficile à maintenir et de plus déroutant que de simplement les laisser en tant que contrôles séparés. Nous ne voulions pas créer quelque chose de si complexe au point de devoir implémenter ListView3 en quelques années. Je développerai cela plus en détail ci-dessous.

Le résultat de ceci est que CollectionView restera concentré sur le problème de permettre aux utilisateurs de Forms d'utiliser les contrôles de liste/grille natifs et de bénéficier de leurs moteurs de mise en page et de leur virtualisation. Et #1718 sera mis à jour pour refléter une API qui permettra aux utilisateurs de Forms de lier un ItemsSource et un ItemTemplate aux différents moteurs de Forms Layout.

Pour ceux qui s'intéressent au _pourquoi_ de deux contrôles contre un :

La différence fondamentale entre ce qui a été décrit ici (comme CollectionView) et la proposition dans #1718 est _où_ la mise en page se produit.

CollectionView vise à utiliser les moteurs de mise en page natifs (qui ont été fortement optimisés par les développeurs de la plate-forme) pour gérer la mise en page. Certains codes personnalisés de Forms sont impliqués (par exemple, en fournissant des éléments tels que la logique SnapPoints sur Android et iOS), mais pour la plupart, les moteurs de mise en page natifs (et les implémentations de virtualisation natives) font le gros du travail. Cela fait une énorme différence en ce qui concerne les performances.

Ainsi, toute information de mise en page que le développeur donne à CollectionView est simplement transmise au moteur de rendu sur chaque plate-forme pour interprétation ; c'est effectivement une spécification qui est traduite dans la langue locale (LinearLayoutManager/GridLayoutManager sur Android, UICollectionViewFlowLayout sur iOS, etc.). Au-delà du DataTemplate, Forms ne fait aucun travail de mise en page.

En revanche, une disposition de formulaires (FlexLayout, StackLayout, AbsoluteLayout, etc.) est entièrement présentée dans la couche Forms. Les moteurs de rendu pour une mise en page de formulaires font très peu. Et il n'y a pas de virtualisation en cours ; tous les éléments sont créés et placés dans la mise en page dès le départ.

Essayer de fusionner ces deux éléments soulève des questions difficiles, notamment :

1. Comment fonctionne le mappage du moteur de rendu ? Un CollectionView utilisant un StackLayout a un rendu très différent d'un CollectionView qui doit utiliser un RecyclerView. Les mélangeons-nous ensemble et masquons-nous le RecyclerView lorsque nous n'en avons pas besoin ? Avons-nous le moteur de rendu dérivé de DefaultRenderer ? Si nous faisons cela, nous avons toujours une couche ViewGroup supplémentaire dont nous n'avons pas vraiment besoin ...

2. Comment traitons-nous les ScrollViews ? UICollectionView gère son propre affichage de défilement, mais si un StackLayout doit défiler, l'utilisateur l'ajoute normalement manuellement dans Forms. Ajoutons-nous une autre couche pour insérer le défilement automatiquement si nécessaire ? Désactivons-nous/supprimons-nous un ScrollView ajouté manuellement si la mise en page appelle un UICollectionView ?

3. D'ailleurs, où vont les méthodes ScrollTo ?

... etc. Tous ces problèmes sont _résolus_, mais chaque solution ajoute de la _complexité_. Et comme cela a été souligné dans #1718, ajouter ItemsSource et ItemsTemplate à une mise en page de formulaire n'est pas si difficile ou complexe. Rendre complexe le simple fait de fusionner ces deux scénarios distincts ne vaut pas les avantages.

Je suis confus. Puisque vous avez déjà eu quelques démos internes, il semble que vous soyez déjà assez avancé dans la mise en œuvre. Cela ne devrait-il pas signifier qu'une grande partie de l'API a été fixée ? Suivez-vous les spécifications de l'API ici ?

Nous suivons l'API publiée ici. « Assez loin » est probablement une exagération ; jusqu'à présent, nous avons implémenté certaines des parties non controversées de la spécification pour vérifier qu'elles sont possibles et que nous n'allons pas dans des impasses. En supposant que nous ne rencontrions aucun problème, une grande partie de ce que nous avons implémenté jusqu'à présent sera probablement dans la version publiée. Mais tout dans la spécification est encore sujet à changement, tout comme tout ce que nous avons mis en œuvre jusqu'à présent.

Je ne vois pas comment la spécification actuelle pourra répondre à ce qui a été discuté ici et sur l'autre fil ici #1718. Pour être plus précis, l'API n'est pas assez flexible pour permettre par exemple un simple contrôle de type StackLayout non défilant et liant.

C'est vrai, et une partie de ce sur quoi nous avons travaillé consiste à déterminer si CollectionView _pourrait_ couvrir raisonnablement ces cas d'utilisation. Nous avons pris une décision à ce sujet ; voir https://github.com/xamarin/Xamarin.Forms/issues/3172#issuecomment -424413234.

Étant donné qu'il s'agit d'un sous-ensemble de ce que fait UICollectionView en termes de mise en page, je pense que nous devrions choisir un nom différent pour éviter toute confusion avec les capacités du contrôle.

Comme je l'ai dit (https://github.com/xamarin/Xamarin.Forms/issues/3172#issuecomment-401186893), je suis ouvert à d'autres noms.

Qu'en est-il de CatalogView ?

Les catalogues sont souvent conçus dans une ou plusieurs colonnes et avec plusieurs rangées d'articles avec des polices, des textes, des mises en page, etc. similaires.

C'est une idée intéressante. Il n'entre certainement pas en conflit avec les noms de contrôle existants.

@hartez En tant que type aléatoire sur Internet, qui se familiarise de plus en plus avec les composants internes de Xamarin Forms (et était déjà assez familier avec UITableView et UICollectionView), je pense que c'est la bonne décision.

Sera-t-il toujours possible de fournir une mise en page personnalisée (même si cela signifie fournir des implémentations distinctes par plate-forme) ?

Sera-t-il toujours possible de fournir une mise en page personnalisée (même si cela signifie fournir des implémentations distinctes par plate-forme) ?

Absolument. Vous pouvez fournir votre propre mise en page marquée avec IItemsLayout et votre moteur de rendu personnalisé peut l'interpréter comme vous le souhaitez.

Par exemple, en tant que preuve de concept, j'ai sous-classé le moteur de rendu Android pour CollectionView et ajouté la possibilité d'interpréter une classe FlexLayout : IItemsLayout qui comprenait un tas de propriétés Flex Layout. Il transmet ces propriétés au FlexBoxLayoutManager de Google et utilise ce gestionnaire de mise en page avec RecyclerView. Une fois que nous aurons rendu un aperçu public disponible, je lancerai probablement cet exemple sur GitHub afin que les gens aient une référence facile sur la façon de faire ce genre de chose.

Le but est de rendre cette chose très, très flexible.

@hartez
Le problème décrit dans https://github.com/xamarin/Xamarin.Forms/issues/3749 est-il résolu avec CollectionView ?
Parce qu'ici, je vois que CollectionView n'a que la propriété ItemTemplate , qui semble avoir le même problème que ListView .

@hartez
Le problème décrit dans #3749 est-il résolu avec CollectionView ?
Parce qu'ici, je vois que CollectionView n'a que la propriété ItemTemplate , qui semble avoir le même problème que ListView .

@andreinitescu Merci d'avoir signalé cette discussion, je n'étais pas au courant de ce problème avec DataTemplate.

Je vais passer un peu de temps la semaine prochaine à examiner l'historique de DataTemplate - pourquoi il est conçu de cette façon, et s'il y a des problèmes de compatibilité descendante avec la correction de CreateContent pour faire automatiquement la bonne chose (à la fois dans ListView et CollectionView).

@hartez Juste à titre d'exemple de la façon dont j'ai contourné ce problème lors de la création de mon propre contrôle de répéteur.

//Vérifiez si nous avons un sélecteur de modèle ou juste un modèle
var templateToUse = itemTemplate is DataTemplateSelector templateSelector ? templateSelector.SelectTemplate(item, null) : itemTemplate;

Donc, dans un cas comme celui-ci, le simple fait de réparer CreateContent ne le briserait pas, le rendrait simplement inutile. Mais je suis d'accord avec @andreinitescu pour

@bmacombe À mon humble avis , ce n'est pas seulement une question de préférence de l'aligner sur WPF/SL, c'est vraiment un problème, cela crée de la confusion. Voir #3544

@andreinitescu Cela crée de la confusion :) Croyez-moi, j'étais confus au début lorsque j'essayais de prendre en charge DataTemplate et DataTemplateSelector dans mon répéteur ! Surtout quand il y avait une erreur lorsque j'ai affecté un DateTemplateSelector à ma propriété DataTemplate alors qu'il fonctionnait dans tous les emplacements XF qui l'utilisaient. Il a fallu creuser du code source pour comprendre cela. Ce n'est probablement pas un problème pour quelqu'un qui utilise simplement les commandes XF intégrées, mais essayer de vous en approprier et de l'utiliser... vraiment déroutant.

Pouvons-nous organiser un événement de défilement s'il vous plaît sur CollectionView ? Jusqu'à ce que CollectionView soit publié, j'ai une suggestion pour ListView https://github.com/xamarin/Xamarin.Forms/issues/4323

Et, sera-t-il possible de créer des mises en page irrégulières et dynamiques, comme PInterest par exemple :

Vous voyez, chaque image a sa propre hauteur :-)

Vous n'êtes pas sûr qu'un tel type de mise en page puisse être supporté ?

Mise à jour : dans la liste des propositions de noms, le plus proche que nous avons trouvé est "ItemsView", c'est pour éviter d'utiliser le terme "CollectionView" qui donne aux gens l'impression que c'est aussi complet que l'iOS "UICollectionView"

Salut, je suis encore nouveau sur Xamarin, mais j'ai travaillé avec ListView en utilisant DataTemplateSelector.
Lorsque j'ai essayé de tester à l'aide de CollectionView avec DataTemplateSelector , une erreur s'est produite

Exception non-gérée:

System.InvalidOperationException : LoadTemplate ne doit pas être null s'est produit

Existe-t-il un bogue connu lié à DataTemplateSelector ?
Je pourrais mal l'appliquer. Existe-t-il un exemple d'utilisation de DataTemplateSelector avec CollectionView ?

@hartez @davidortinau une raison pour laquelle KeepItemsInView n'est pas nommé KeepFirstItemInView pour s'aligner sur KeepLastItemInView ? Le nom actuel est au pluriel (c'est-à-dire qu'il suggère plusieurs éléments) alors que la description indique qu'il ne conserve que le premier élément visible dans la fenêtre.

De plus, existe-t-il un moyen d'exposer une API pour obtenir la liste des vues actuellement dans la fenêtre ? L'autre soir, je travaillais sur la création d'une vue vidéo à intégrer dans une cellule ListView et à lire/mettre en pause automatiquement en fonction de la visibilité de la fenêtre, mais c'était presque impossible avec les ItemAppearing et ItemDisappearing actuels ItemDisappearing , en particulier lorsqu'ils se déclenchaient de toutes sortes de manières inattendues avec le recyclage des cellules et/ou le défilement rapide. J'ai vraiment hâte que CollectionView prennent en charge ce type de fonctionnalité de manière plus fiable.

Une autre chose qui serait formidable est la possibilité de créer une vue dépendante et minimisée qui est détachée du parent pendant que l'utilisateur a le luxe de faire défiler le flux actuel. J'ai vu cela sur YouTube car nous pouvons maintenant continuer à regarder la vidéo en cours tout en ayant la possibilité de continuer à naviguer. Je ne sais pas si c'est quelque chose que CollectionView peut ou devrait prendre en charge d'ailleurs, mais c'est quelque chose à quoi penser.

J'ai donc joué un peu avec la version nocturne actuelle (4.0.1.43780-nightly), ce qui a résolu certains problèmes de redimensionnement par rapport à la version de prévisualisation actuelle.

Une suggestion que j'ai serait d'ajouter quelque chose comme RowSpacing/ColumnSpacing ou GridSpacing aux dispositions de grille car cela facilite beaucoup l'espacement correct de vos éléments sans utiliser de marge/remplissage sur les éléments individuels.
Une autre chose serait d'ajouter Padding ou peut-être EdgeOffset à CollectionView ou Layout pour éviter d'utiliser Margin, qui coupe les éléments comme indiqué ici :

Margin recadre également l'animation "glisser" sur Android comme vous pouvez le voir ici :

Une suggestion que j'ai serait d'ajouter quelque chose comme RowSpacing/ColumnSpacing ou GridSpacing aux dispositions de grille car cela facilite beaucoup l'espacement correct de vos éléments sans utiliser de marge/remplissage sur les éléments individuels.

D'accord, et c'est sur notre radar - voir #4681.

Mise à jour : dans la liste des propositions de noms, le plus proche que nous avons trouvé est "ItemsView", c'est pour éviter d'utiliser le terme "CollectionView" qui donne aux gens l'impression que c'est aussi complet que l'iOS "UICollectionView"

qu'en est-il de "FloatView" ?

À côté des événements ItemAppearing/Disappearing mentionnés ci-dessus, tous les plans pour obtenir la vue d'un élément :
View GetView(object item)
Si l'élément n'est pas matérialisé, il devrait renvoyer null, je suppose.

J'utilise une liste verticale et il semble y avoir des incohérences dans la façon dont elle est rendue sur iOS par rapport à Android.

Sur iOS, avec l'étiquette occupera 100% de la largeur.

Sur Android, il n'occupera que la largeur de son contenu.

Je n'ai pu le mettre en page correctement qu'avec une définition de largeur statique.
Existe-t-il une solution de contournement Android qui respecte la propriété Grid Width="Auto" ?

J'utilise une liste verticale et il semble y avoir des incohérences dans la façon dont elle est rendue sur iOS par rapport à Android.

@shwanton Veuillez ouvrir un problème séparé pour ce bogue, et j'y jetterai un coup d'œil.

@shwanton, j'ai eu des problèmes similaires qui ont été résolus lorsque je suis passé au flux nocturne

@krdmllr Je peux confirmer, cela a été corrigé dans la dernière version. Merci.

Salut. Y aura-t-il un événement ItemTapped dans CollectionView similaire à ItemTapped de ListView ? Je ne le vois pas dans les spécifications. Merci.

@uvirra Il existe un problème pour votre demande de DataTemplateSelector . Voir #4826.

@hartez Y aura-t-il un jour besoin d'une stratégie de recyclage d'articles comme les trois qui existent pour ListView ? Vous avez mentionné à plusieurs reprises la virtualisation native que CollectionView exploite. Je veux juste avoir plus de précisions à ce sujet.

Je suis également curieux de savoir à quoi ressemblera RefreshView sur iOS. L'actualisation actuelle pour ListView nécessite l'activation UITableView propriété Bounces UITableView alors que, sur Android, la vue d'actualisation est tirée au-dessus de l'élément le plus visible (qui Je préfère personnellement).

@hartez Y aura-t-il un jour besoin d'une stratégie de recyclage d'articles comme les trois qui existent pour ListView ? Vous avez mentionné à plusieurs reprises la virtualisation native que CollectionView exploite. Je veux juste avoir plus de précisions à ce sujet.

La conception actuelle n'appelle rien de tel qu'une stratégie de recyclage. À l'heure actuelle, nous utilisons simplement la virtualisation fournie par les commandes natives, qui font un très bon travail dès la sortie de la boîte.

Y aura-t-il jamais un besoin ? Mon espoir est "non", et nous ferons de notre mieux pour l'éviter car cela ajoute beaucoup de complexité (à la fois pour les utilisateurs et pour la maintenance). Si nous concluons finalement que nous avons besoin de quelque chose comme ça, nous aborderons la conception très, très attentivement.

Qu'en est-il de l'événement scrollé ? La plupart des UI/UX modernes fournissent un en-tête de parallaxe, afficher/masquer des éléments (boutons, en-têtes, filtres, etc.) lors du défilement et similaires.
Je pense qu'un nouveau contrôle étonnant comme celui-ci devrait prendre en charge les scénarios modernes.

cela ne devrait pas être un problème, recyclerview et UICollectionview prennent en charge l'événement de défilement prêt à l'emploi.

Même le Carouselview (basé sur collectionview) prend en charge l'événement de défilement avec direction, valeur de défilement et delta : https://github.com/xamarin/Xamarin.Forms/issues/4996

Pour faire suite au commentaire de lequel il s'agit d'un nouveau contrôle étonnant qui devrait prendre en charge les scénarios modernes, j'aimerais voir une prise en charge encore meilleure de la virtualisation.

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

Si cela est trop difficile à comprendre, j'aimerais avoir accès à VisibleItems afin de pouvoir effectuer la virtualisation dans mon ViewModel à la place.

Continuez ce bon travail!

@hartez Je pensais juste que ce serait cool de laisser les développeurs définir un seuil minimum/maximum sur le nombre d'éléments sélectionnés. Je suis en train de créer une galerie photo personnalisée qui ne devrait pas permettre de sélectionner plus de 5 photos. Lorsque le seuil est atteint, les événements de pression sur les cellules doivent être ignorés, sauf s'ils désélectionnent des éléments.

Cela pourrait également être fait en définissant SelectedItems (qui n'a pas encore été implémenté) sur l'événement SelectionChanged basé sur le nombre de CurrentSelection , mais cela va déclencher SelectionChanged deux fois. À mon avis, nous devrions avoir un moyen de contrôler de manière proactive le comportement de sélection avant que quoi que ce soit n'atteigne Core.

En jouant un peu avec CollectionView aujourd'hui, j'ai remarqué que UWP est beaucoup plus en retard qu'Android et iOS, ce que je comprends pourquoi.

Vous voulez juste confirmer qu'il est prévu d'avoir un support UWP complet une fois finalisé ?

À côté des événements ItemAppearing/Disappearing mentionnés ci-dessus, tous les plans pour obtenir la vue d'un élément :
View GetView(object item)
Si l'élément n'est pas matérialisé, il devrait renvoyer null, je suppose.

Qu'en est-il de ItemAppearing ? je n'en vois pas de nouvelles

Je jouais avec le CollectionView et je faisais face à des problèmes de hauteur de rangée inégale. J'ai vu qu'il y avait un ItemSizingStrategy introduit récemment, mais il se comporte quand même bizarrement.

J'ai joué avec le DataTemplateGallery et en passant à MeasureAllItems j'obtiens le résultat suivant (iPhone 6, iOS 12.1.4):

Après avoir balayé vers la droite et être revenu, le résultat devient :

@hartez Cela devrait-il fonctionner ou est-il toujours en cours (je

RemainingItemsThresholdReached a-t-il déjà été implémenté ?

Il n'est pas disponible sur le contrôle XAML CollectionView dans 4.0.0.169046-pre5.

Quelqu'un peut-il me dire que RemainingItemsThresholdReached fait partie de la version 4.0 ? Si oui, pouvez-vous s'il vous plaît donner un exemple de code sur la façon d'utiliser cette fonctionnalité.

@Dresel Pouvez-vous ouvrir un nouveau ticket si vous pensez qu'il s'agit d'un bug ? C'est mieux s'il est suivi.

@melucas @chandrubk Je ne pense pas que RemainingItemsThresholdReached soit encore en cours de travail.

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

Moi aussi, j'aimerais voir cette fonctionnalité (avec la vue Actualiser) implémentée dès que je ne peux pas toucher CollectionView sans elle.

4323

Nous avons besoin de l'événement Scrolled comme ScrollView

Cordialement,

4323

Nous avons besoin de l'événement Scrolled comme ScrollView

Cordialement,

Je soutiens cela.
De plus, ce serait génial d'obtenir un événement lorsque le défilement est arrêté/fini.

Dans IOS, UICollectionview est une sous-classe de UIScrollview, nous pouvons donc obtenir scrollViewDidEndDecelerating partir du UIScrollViewDelegate

Dans Android, je pense que nous pouvons étendre le RecyclerView.OnScrollListener ?

Cela ouvrira des scénarios plus avancés et raffinés pour le rafraîchissement personnalisé, la parallaxe, les éléments de défilement synchronisés, etc.

Y a-t-il une chance qu'il y ait une animation prête à l'emploi pour Android, comme celle de Recycler View ?

Y a-t-il une chance qu'il y ait une animation prête à l'emploi pour Android, comme celle de Recycler View ?

De quelles animations parlez-vous ? Le moteur de rendu Android pour cela est construit sur RecyclerView, il utilise donc déjà les animations par défaut pour des choses comme l'ajout/la suppression d'éléments.

Salut,

J'utilise 4.0.0.304370-pre8.
L'exemple de (lien ci-dessous) n'affiche rien sur UWP, lors de l'utilisation de CarouselView.
Mais CollectionView affiche la liste. Une configuration spécifique est-elle nécessaire pour activer CarouselView pour UWP ?

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

Merci.

Salut @noypi ,

Alors que CollectionView peut techniquement "fonctionner" dans une assez faible mesure sur UWP, la mise en œuvre complète de CollectionView et CarouselView est strictement effectuée sur Android et iOS pour commencer. Aucun travail officiel pour UWP n'est prévu pour le moment, mais nous recueillons continuellement des commentaires. Si vous souhaitez discuter du type de travail que vous effectuez sur UWP en particulier, vous pouvez m'envoyer un e-mail à l'adresse paul. [email protected].

Selon les spécifications, TableView sera-t-il entièrement remplacé par CollectionView ?

Autre question : puisqu'il n'y a plus de cellules, comment ajouter un indicateur de décoloration pour iOS ? Avec ListView, c'était possible via un moteur de rendu personnalisé.

Selon les spécifications, TableView sera-t-il entièrement remplacé par CollectionView ?

TableView existera toujours. Nous ne supprimerons aucun contrôle existant.

Autre question : puisqu'il n'y a plus de cellules, comment ajouter un indicateur de décoloration pour iOS ? Avec ListView, c'était possible via un moteur de rendu personnalisé.

Sur iOS, CollectionView est rendu à l'aide d'un UICollectionView, ce qui signifie que ses cellules sont des UICollectionViewCells. Et les UICollectionViewCells n'ont pas de vues accessoires (comme les indicateurs de divulgation). Ainsi, pour tous les éléments de l'interface utilisateur tels que les indicateurs de divulgation ou les coches, vous devrez les créer dans votre ItemTemplate.

Comment désactiver la sélection sur certains types d'articles ? J'ai plusieurs modèles de données et je souhaite désactiver la sélection sur certains d'entre eux.

@hartez Lors de la définition de ItemTemplate sur DataTemplateSelector, je reçois une exception : System.InvalidOperationException: LoadTemplate should not be null

Je pensais que les modèles seraient pris en charge hors de la boîte

@hartez Lors de la définition de ItemTemplate sur DataTemplateSelector, je reçois une exception : System.InvalidOperationException: LoadTemplate should not be null

Je pensais que les modèles seraient pris en charge hors de la boîte

Ils devraient être; peut-être que vous rencontrez un bug. Veuillez ouvrir un problème afin que nous puissions enquêter.

@toomasz Avant d'ouvrir un problème, pouvez-vous s'il vous plaît mettre à jour votre Nuget vers la dernière pré-version (ou la nuit) et tester à nouveau le sélecteur ? Le problème que vous voyez était présent lorsqu'il n'y avait pas de support pour DataTemplateSelector .

@hartez Des travaux sont-ils actuellement en cours sur l'en-tête et le pied de page ainsi que sur la vue d'actualisation ? Si je peux libérer du temps, je pourrais examiner l'un ou l'autre, mais je veux m'assurer que je ne vous marche pas sur les pieds.

@adrianknight89 Cela fonctionne sur 4.0 ! Impressionnant

@hartez Des travaux sont-ils actuellement en cours sur l'en-tête et le pied de page ainsi que sur la vue d'actualisation ? Si je peux libérer du temps, je pourrais examiner l'un ou l'autre, mais je veux m'assurer que je ne vous marche pas sur les pieds.

Rien n'est fait pour le moment - si vous voulez essayer, ce serait génial.
Juste un avertissement, après une discussion aujourd'hui, nous avons ajouté deux nouvelles propriétés liées à l'en-tête et au pied de page - IsHeaderSticky et IsFooterSticky , pour spécifier s'ils défilent avec les éléments ou restent en place. Si vous voulez les aborder avec l'en-tête/le pied de page, ce serait génial, mais ce serait aussi bien si nous les faisions fonctionner d'une manière ou d'une autre et pouvions implémenter ces propriétés plus tard.

Existe-t-il un plan pour prendre en charge la vue de la collection sur UWP ?

Oui. La mise en œuvre est actuellement un peu en retard par rapport aux autres plates-formes, mais le plan est de la prendre pleinement en charge. Vous pouvez suivre la progression de la fonctionnalité sur https://gist.github.com/hartez/7d0edd4182dbc7de65cebc6c67f72e14

Des infos sur RefreshView ?
J'ai la dernière version bêta de Xamarin 4 et le type RefreshView est introuvable

Des infos sur RefreshView ?
J'ai la dernière version bêta de Xamarin 4 et le type RefreshView est introuvable

RefreshView n'a pas encore été implémenté. Vous pouvez suivre la progression de la fonctionnalité ici .

Ajouter GroupItemsBinding ?

Que diriez-vous d'ajouter une propriété GroupItemsBinding pour spécifier quelle propriété contient les éléments enfants d'un groupe ? Cela permettrait d' incorporer une propriété de collection enfant au lieu de forcer les groupes à hériter d'une collection.

Avantages :

• Possibilité de (dé)sérialiser la collection groupée vers/depuis JSON.
  L'héritage des groupes d'une collection bloque la (dé)sérialisation JSON (car les tableaux JSON ne prennent en charge qu'une plage de valeurs et non des propriétés). La (dés)sérialisation des modèles de vue est nécessaire pour préserver l'état du modèle de vue lorsque l'application passe en arrière-plan ou si l'API de votre application vous envoie des modèles de vue. La solution de contournement actuelle consiste à avoir une deuxième structure de données et à effectuer un duplicata + une transformation coûteux à chaque mise à jour des données.
• Possibilité d'utiliser votre propre classe de base pour les éléments de groupe (par exemple ViewModelBase )
• Évitez de polluer les objets de groupe avec toutes les propriétés héritées d'une collection

Par exemple, vous pouvez écrire cet exemple de regroupement à partir de docs.microsoft.com :
```C#
classe publique PageTypeGroup : Liste
{
chaîne publique Titre { get; ensemble; }
// Plus de propriétés ...
}

like this instead:

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

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

avec XAML :

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

Ne pas spécifier GroupItemsBinding serait compatible avec l'implémentation existante, équivalent à GroupItemsBinding="{Binding .}"

PS J'ai soumis cette proposition plus tôt, en juillet 2018 .

Mise à jour du 23 août 2019 : le regroupement a été implémenté mais sans ce correctif ; voir les données du groupe

J'espère qu'il n'est pas trop tard pour ajouter ceci.

Que diriez-vous de prendre en charge plusieurs niveaux de regroupement ?
Permettrait d'afficher des arbres .

Par exemple, Flutter a ExpansionTile ( exemple )

En ce qui concerne CollectionView, j'ai rencontré un problème qui, je pense, serait une excellente fonctionnalité à ajouter.

Dans une liste horizontale, avec scroll, typiquement les designers, ajoutent un effet "d'ombre" sur les éléments qui ne sont pas totalement visibles à l'écran. Actuellement (pour autant que je sache), il n'y a aucun moyen de le faire dans Xamarin.Forms. Ne pensez-vous pas que ce serait un niec d'avoir une fonctionnalité? Cela pourrait être aussi simple qu'un booléen, qui appliquerait une "ombre portée" à l'élément qui n'est visible que par un pourcentage X, par exemple.

Je propose une propriété Position. Cette propriété contiendrait l'index de l'élément actuel. Cela permettrait une intégration facile de ViewPagerIndicator et d'indicateurs similaires.

Je comprends que déterminer "l'élément actuel" peut être délicat. Si la capture est activée, il devrait être assez facile de déterminer sur quel élément la vue est capturée. Sans accrochage, le choix correct dépendrait du cas d'utilisation : ce serait peut-être l'élément occupant le début ou le milieu de la vue.

Cette propriété pourrait également permettre un accès bidirectionnel facile comme alternative à ScrollTo().

@hartez Nous nous attendions à ce que ce soit prêt pour la version 4.0 mais surpris de voir qu'il n'est pas encore terminé. Nous ne pouvons pas tester CollectionView sans la fonctionnalité de défilement et d'actualisation. Pouvez-vous nous dire combien de sprints nous devons attendre avant de les déployer ? Nous avons décidé de ne rien expédier avec ListView à l'avenir et aimerions que ce contrôle soit disponible dès que possible.

@hartez Nous avons besoin d'un moyen pour CollectionView avec une disposition de liste de dimensionner le contenu de ses éléments. Je pense que c'est un cas d'utilisation courant :

Dans cet exemple, les boutons doivent se trouver directement sous la vue de la collection. Je pense que cela devrait fonctionner de cette façon lorsque VerticalOptions est Start

lorsque le seuil des éléments restants atteint le test de propriété

J'ai des questions pour savoir si le flux CollectionView d'un comportement d'élément individuel imite le comportement natif d'iOS en ce qui concerne les changements de taille d'écran. Je vais vous donner un exemple :

Une cellule de galerie d'images dans iOS est créée avec un CollectionView et vous définissez une cellule individuelle. Le comportement prêt à l'emploi est que le nombre de cellules dessinées dans une seule ligne est dynamique en fonction de la taille de l'écran. Sur un téléphone, je pourrais contenir 4 articles, mais sur une tablette, je pourrais peut-être en contenir 8 ou 9.

La version Forms offrira-t-elle également cela ? Jusqu'à présent, l'exemple que j'ai lu, je n'ai vu que l'endroit où vous définissez la propriété GridItemsLayout Span. Cela se traduit par une valeur codée en dur du nombre d'éléments pouvant être dessinés et, dans le monde des différentes tailles d'écran, le codage en dur semble ainsi 2014. :-P

UWP a quatre états de mode de sélection
{
Rien,
Seul
Plusieurs,
Étendre,
}

Je pense que quatre états dans Android et IOS sont également utiles
Jetez un œil à l'explorateur de fichiers

Existe-t-il des plans pour une propriété de rembourrage simple? #6605 Pour mon cas d'utilisation particulier, je pourrais probablement utiliser un en-tête et un pied de page vierges de taille appropriée (une fois ces fonctionnalités développées), mais ce serait un peu un hack et ne conviendrait pas à une disposition en grille où le rembourrage sur les quatre côtés peut être requis.

Tout projet de réorganiser l'élément de liste dans la vue de la collection.

La spécification explique-t-elle comment désactiver la sélection d'éléments particuliers dans CollectionView ?

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

Actuellement, je le contourne, mais cela n'empêche pas l'application de l'état visuel sélectionné.

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

La couleur de la barre de défilement verticale et la couleur de la barre de défilement horizontale seraient formidables !

Qu'en est-il du sens de défilement, je veux dire commencer à faire défiler de droite à gauche, pas le contenu lui-même

J'aimerais avoir des séparateurs...

Ce serait formidable d'avoir la possibilité de « mémoriser » et d'appliquer la position de défilement.

Ce qui serait si étonnant, ce serait la possibilité d'utiliser différents modèles d'éléments pour chaque seconde ou X élément. Cela permettrait de créer un fond gris pour chaque deuxième élément et de nombreuses autres possibilités de style.

Ne pouvez-vous pas déjà le faire avec le sélecteur de modèle ? Utilisation de la position avec
opérateur modulo ?

Le mardi 13 août 2019, 16:53 Legacyorder [email protected] a écrit :

Ce qui serait si incroyable, ce serait la possibilité d'utiliser un article différent
modèles pour chaque seconde ou X élément. Cela permettrait de créer
un fond gris pour chaque deuxième élément et de nombreux autres styles
possibilités.

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/xamarin/Xamarin.Forms/issues/3172?email_source=notifications&email_token=AC4YCKDFCH3WFENRCLPWEC3QELDE3A5CNFSM4FHJRXPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXWWH2ZLOZGO28
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AC4YCKHXX5YSR7M3S4VU5QLQELDE3ANCNFSM4FHJRXPA
.

Le défilement circulaire serait sympa. Je suppose que c'est facile à mettre en œuvre.

Je voudrais avoir un "AbsoluteItemsLayout" comme ItemsLayout pour la CollectionView pour permettre de définir des positions absolues dans une liste, pour le moment je ne vois pas d'autre solution plutôt que de le faire dans le code derrière.

Est-il possible, lors de l'utilisation de GridItemsLayout, de permettre aux éléments de s'étendre sur plusieurs lignes ou colonnes ? Ce serait certainement une fonctionnalité qui vaudrait la peine d'avoir.

Pouvez-vous également exposer l'événement Scrolled à ce contrôle ? Le but est que lorsque j'arrive en bas de la liste, je souhaite recharger des éléments supplémentaires. Je ne sais pas si CollectionView détecte si elle se trouve à l'intérieur de ScrollView et désactive la capacité de défilement.

Pouvez-vous également exposer l'événement Scrolled à ce contrôle ? Le but est que lorsque j'arrive en bas de la liste, je souhaite recharger des éléments supplémentaires. Je ne sais pas si CollectionView détecte si elle se trouve à l'intérieur de ScrollView et désactive la capacité de défilement.

Votre souhait est accordé! Vérifiez la version 4.2 :)
https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/collectionview/scrolling

Vous ne devez pas inclure une CollectionView dans une ScrollView, sinon la virtualisation ne fonctionnera pas.

Pouvez-vous également exposer l'événement Scrolled à ce contrôle ? Le but est que lorsque j'arrive en bas de la liste, je souhaite recharger des éléments supplémentaires. Je ne sais pas si CollectionView détecte si elle se trouve à l'intérieur de ScrollView et désactive la capacité de défilement.

Votre souhait est accordé! Vérifiez la version 4.2 :)
https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/collectionview/scrolling

Vous ne devez pas inclure une CollectionView dans une ScrollView, sinon la virtualisation ne fonctionnera pas.

Je suis en 4.2.0.709249
est-ce que je rate quelque chose ?

J'ai l'événement Scrolled avec 4.2.0.709249.
Essayez de supprimer les dossiers bin/obj et vérifiez la consolidation NuGet pour être sûr.

Bénéficions-nous bientôt du support RTL avec 4.2 pour Android et iOS ?

Bénéficions-nous bientôt du support RTL avec 4.2 pour Android et iOS ?

Un certain soutien est déjà là ; La prise en charge de FlowDirection devrait déjà fonctionner dans les éléments CollectionView. Ce qui est encore incomplet, c'est le sens de défilement des mises en page CollectionView horizontales. Le sens de défilement doit correspondre au FlowDirection sur Android, mais nous avons encore du travail à faire pour les autres plates-formes ; ce travail doit être achevé en 4.3.

Si vous rencontrez des bogues en utilisant FlowDirection avec CollectionView, veuillez ouvrir un problème et nous y jetterons un coup d'œil.

Pouvez-vous s'il vous plaît décrire ce qui n'est pas fait avec le support RTL ?
Parce que dans les spécifications, il n'est même pas marqué comme en cours ou terminé.

Le jeu. 5 septembre 2019, 02h19, EZ Hart, [email protected] a écrit :

Bénéficions-nous bientôt du support RTL avec 4.2 pour Android et iOS ?

Un certain soutien est déjà là ; La prise en charge de FlowDirection devrait déjà être
travailler dans les éléments CollectionView. Ce qui est encore incomplet, c'est le parchemin
direction pour les mises en page CollectionView horizontales. Le sens de défilement
devrait correspondre au FlowDirection sur Android, mais nous avons encore du travail à faire
faire sur cela pour les autres plates-formes.

Si vous rencontrez des bogues en utilisant FlowDirection avec CollectionView,
s'il vous plaît ouvrez un problème et nous allons jeter un oeil.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/xamarin/Xamarin.Forms/issues/3172?email_source=notifications&email_token=ACDWB3GSYAQSADERHWVTJX3QIANMNA5CNFSM4FHJRXPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXWWHJ88ZGOD54LNMVXWWHJ88ZDN
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ACDWB3HMFCHBRZWD5AJMXH3QIANMNANCNFSM4FHJRXPA
.

Non effectué : sens de défilement pour les mises en page horizontales.

Si vous définissez FlowDirection = RightToLeft sur une CollectionView à défilement horizontal, le sens de défilement ne sera pas de droite à gauche sur iOS et UWP pour le moment (je pense que cela fonctionne sur Android).

Que diriez-vous de certains LoadingDataTemplate ?

D'après mon expérience de chargement de données asynchrone dans ListView/CollectionView, il peut parfois y avoir un espace vide jusqu'à ce que la listview/collectionview soit remplie.

L'ajout de LoadingDataTemplate peut fournir une réactivité supplémentaire lorsque des données volumineuses sont remplies et que la page est déjà apparue.

Je pense qu'il y a deux façons d'utiliser un indicateur de chargement. L'un est lorsque le CollectionView est initialement affiché. Plusieurs cellules d'espace réservé sont affichées jusqu'à ce que les données soient ajoutées à la collection ItemsSource . Le second est lorsque plus de données sont ajoutées au bas de la liste. Pour le second, je pense que nous pouvons tirer parti du pied de page ?

Le premier nécessite plus de travail (par exemple, chargez initialement la source avec 3 à 5 éléments qui ont le même modèle de données d'espace réservé, puis supprimez ces éléments et ajoutez les données réelles lorsqu'elles sont récupérées). Une autre approche consiste à placer une vue squelette au-dessus de CollectionView et à la masquer lorsque les données sont prêtes. Je suis actuellement cette approche avec ListView .

Je n'ai pas essayé cela, mais nous pourrions d'abord définir EmptyView sur la vue de chargement et s'il n'y a aucun résultat, modifier le modèle du EmptyView pour afficher un message "rien trouvé".

@adrianknight89

Une autre approche consiste à placer une vue squelette au-dessus de CollectionView et à la masquer lorsque les données sont prêtes. Je suis actuellement cette approche avec ListView .

Cela ressemble à la même méthode que je suis également, c'est-à-dire mettre un indicateur d'activité ci-dessus. Définissez ListView sur IsVisible = false et ActivityIndicator IsVisible = true, puis inversez les deux valeurs une fois listview renseignée.

@adrianknight89

Je n'ai pas essayé cela, mais nous pourrions d'abord définir EmptyView sur la vue de chargement et s'il n'y a pas de résultats, modifier le modèle pour EmptyView pour afficher un message "rien trouvé".

Il y a une idée ! Bien que cela puisse fonctionner, je pense qu'il serait préférable d'avoir des propriétés de modèle distinctes sur CollectionView concernant LoadingDataTemplate et EmptyView.

Je suis d'accord qu'il vaudrait mieux avoir deux propriétés différentes. Mis à part l'aspect simplicité, utiliser une seule propriété à deux fins différentes n'a pas beaucoup de sens. Peut-être que EmptyView aurait dû être nommé BackgroundView afin que nous puissions l'utiliser à quelque fin que ce soit. (Edit : BackgroundView est une chose entièrement différente.)

@LeoJHarris J'ai ajouté #7447 pour le support BackgroundView . Nous pourrions utiliser EmptyView et BackgroundView pour prendre en charge les deux scénarios ci-dessus bien que ce ne soit pas encore à 100% ce que vous voulez, mais cela devrait être mieux que d'utiliser EmptyView pour prendre en charge les deux scénarios. Vous pouvez utiliser BackgroundView comme écran de chargement et l'annuler lorsque les données sont prêtes.

@ adrianknight89 ce serait formidable si CollectionView gérait le « null it out » une fois que les données sont prêtes plutôt que de les contrôler manuellement (à moins que vous ne le sous-entendiez déjà).

Lorsque vous faites défiler rapidement une page qui utilise le RemainingItemsThreshold de CollectionView, nous rencontrons deux problèmes différents.

1. L'application se bloque et doit être fermée de force
2. Les éléments de la CollectionView s'empilent les uns sur les autres (voir image )

Je n'ai trouvé personne d'autre ayant ce problème. L'avez-vous vu signalé?

@Bronson15 Comment gérez-vous l'événement RemainingItemsThresholdReached ? Le défilement rapide le déclenchera plusieurs fois et vous devez donc ignorer les appels d'événements pendant que vous attendez de mettre à jour votre source de données, sinon ils s'accumuleront. Essayez également de mettre à jour votre interface utilisateur sur le fil principal.

Si vous rencontrez toujours des problèmes, vous pouvez ouvrir un nouveau problème avec une reproduction pour enquête.

@ Bronson15 les deux problèmes.
Essayé avec ObservableRangeCollection et corrigé #2.
J'ai toujours des problèmes de blocage/liste vierge : lors de l'exécution sur un émulateur, je vois un pic de processeur, cela semble une boucle infinie.

Edit: pauses uniquement sur iOS, fonctionne bien sur Android.

Salut l'équipe,
Même si j'ai essayé d'utiliser RemainingItemsThreshold et RemainingItemsThresholdReachedCommand et j'ai remarqué que la fonction attribuée à RemainingItemsThresholdReachedCommand est appelée plusieurs fois de manière séquentielle (la première fois, elle est appelée deux fois, la prochaine fois 4 fois, etc.) même si je ne fais pas défiler rapidement. Je suis également en mesure de le reproduire avec le nouveau projet Xamarin Forms (v.4.2.0.778463).
Pouvez-vous essayer de le reproduire de votre côté ? Voici l'extrait de code simple ci-dessous :

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>

Voir le modèle :

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 Étant donné que nous ne bloquons pas l'interface utilisateur pendant le traitement de RemainingItemsThresholdReachedCommand , il est normal de continuer à appuyer plusieurs fois sur la commande en raison de vos modèles de défilement. Veuillez voir comment je gère le problème avec un mécanisme de verrouillage : https://github.com/xamarin/Xamarin.Forms/pull/7516/files#diff -2be3eff4d53f761cd581cca1d2ec3bc0R48

D'autres façons de le faire sont d'activer/désactiver votre commande ou de vous désabonner/s'abonner à l'événement pendant que la récupération à distance est en cours. D'après mon expérience, avoir un sémaphore fonctionnait le mieux car parfois plusieurs invocations sont déclenchées au moment où vous essayez d'activer/désactiver ou de vous désabonner/souscrire le rappel.

@hartez @samhouts @davidortinau Je pense que ce problème reviendra assez souvent à l'avenir. La suggestion ci-dessus devrait-elle faire partie de la documentation pour les éléments restants ? Je demanderais à l'équipe de documentation de créer un flux à distance pour les tests et de recommander un modèle de codage à titre de référence afin que les gens ne continuent pas à demander de l'aide.

@techduggu Il existe différents problèmes (mineurs) avec votre code. Je ferais réviser le code sur Stack Exchange. Ce n'est pas l'endroit pour ça maintenant.

@adrianknight89 Merci d'avoir souligné le terme "en raison de vos motifs de défilement". Cela a déclenché ma démangeaison d'en savoir plus à ce sujet. Après avoir parcouru la documentation officielle de RecyclerView et de quelques autres ressources, Oui, je peux confirmer qu'il est appelé plusieurs fois en raison de modèles de défilement et que ces modèles sont SCROLL_STATE_IDLE, SCROLL_STATE_DRAGGING ou SCROLL_STATE_SETTLING en fonction de notre état de défilement.
https://developer.android.com/reference/android/support/v7/widget/RecyclerView.OnScrollListener

Votre code et ce guide Android (https://github.com/codepath/android_guides/wiki/Endless-Scrolling-with-AdapterViews-and-RecyclerView) confirme également que nous devrions gérer le défilement infini soit via le verrouillage, soit en utilisant des états de défilement ci-dessus (qui nécessitent principalement un moteur de rendu personnalisé). Par conséquent, avec Xamarin.Forms, j'ai essayé votre code et cela a fonctionné à merveille. :) Je recommanderais et soutiendrais votre opinion d'inclure cette suggestion dans les documents pour éviter de tels problèmes soulevés par des personnes (avec une demi-connaissance) comme moi. :)

Aussi, rég. les problèmes mineurs que vous avez mentionnés pour l'extrait de code ci-dessus - Eh bien, il ne s'agit que d'un projet POC pour tester le chargement infini avec Collection View, mais j'aimerais connaître votre contribution si vous avez remarqué autre chose qu'une vérification nulle stupide, etc.

Merci!

@adrianknight89 Ah oui. Notre chèque Occupé manquait et cela a aidé à résoudre le problème d'empilement.

J'ai également implémenté le sémaphore comme vous l'avez suggéré et il semble avoir atténué un problème où, lors de l'ajout de nouveaux éléments à ItemsSource, la vue réinitialisait la position de défilement au début. Curieusement, ajouter l'appel dans un essai ; finalement; comme vous l'avez fait dans votre fichier de test a ramené ce problème.

Toujours un problème de gel lors du défilement jusqu'à la fin de la liste. La vue devient vide et l'application se bloque.

Edit : la réinitialisation de la position de défilement est toujours là, mais pas aussi souvent. Le rendu du chargement de plusieurs éléments est également très instable sur l'appareil.

@techduggu Je n'ai pas de VS avec moi, mais en regardant simplement le code, vous devriez attendre RemainingStories() , déplacer l'appel à distance à l'intérieur de l'essai et utiliser un pour HttpClient (idéalement utiliser une seule instance statique dans votre application et ne la supprimez jamais), mais je m'arrêterai ici. :)

@ Bronson15 Il y avait un problème avec CollectionView qui réinitialisait la position de défilement et provoquait le blocage de l'interface utilisateur. Je pense que cela a été corrigé avec #7285, mais c'est uniquement iOS. Pouvez-vous tester le dernier Nuget nocturne et voir si vous rencontrez toujours des problèmes ? L'URL du flux nocturne se trouve sur la page d'accueil GitHub pour les formulaires. Si les problèmes persistent, veuillez ouvrir un problème avec le code de reproduction afin que nous puissions y jeter un œil.

@ adrianknight89 Défilement avec la construction nocturne. On dirait que le problème est en grande partie résolu (je l'ai vu se produire une fois). Il semble que la liste soit maintenant dans une boucle sans fin, au lieu d'avoir une fin. AFAIK, il n'y a aucune propriété dans la spécification pour empêcher cela de se produire?

@ Bronson15 La boucle sans fin ne devrait pas se produire. Le voyez-vous sur iOS ou Android ? Vous devez terminer la boucle lorsque vous atteignez la fin de votre alimentation à distance (c'est-à-dire revenir de RemainingItemsThresholdReachedCommand immédiatement sans émettre un autre appel DB).

Une fois le défilement de la vue arrêté, la commande ne devrait plus être déclenchée. J'utilise Azure Cosmos qui renvoie un jeton de continuation. Lorsque le jeton est nul, je sais qu'il n'y a plus de contenu à charger, donc mon RemainingItemsThresholdReachedCommand fonctionne en fonction de ce jeton. Vous devriez implémenter quelque chose de similaire.

@adrianknight89 Ahhh. Intéressant. Ajout d'une vérification du nombre de résultats et retour s'il est à 0. Correction du défilement infini. Merci pour l'aide!

@ adrianknight89 testé de près pour le problème de crash iOS, cela fonctionne enfin. toujours "beaucoup" plus lent qu'Android.
avec 1000 éléments sur Android est presque en temps réel, sur iOS, il faut attendre 5 à 7 secondes pour que la vue soit rendue. à la fois débogage, iPhone Xs et Redmi Note 7

@andreabalducci Vous êtes sur le simulateur XS ? Comment se passe le comportement sur un appareil physique ? Si le rendu de la vue est lent, cela peut être un autre problème avec iOS qui doit être étudié. Encore une fois, ce serait formidable de voir une reproduction.

@adrianknight89 @andreabalducci ouais, il faut environ 1 à 5 secondes sur mon Xs Max pour charger plus d'articles. La vue vide et recharge tous les éléments plutôt que d'ajouter des éléments à la liste déjà rendue.

@ adrianknight89 les deux appareils physiques, l'émulateur iOS a les mêmes problèmes.

Nous avons supprimé tous les stacklayout des modèles de données et avons gagné en vitesse de commutation vers FormattedString, activé les liaisons compilées, avant qu'iOS ne dépasse 20 secondes.

Sur iOS, la vue noircit et redessine tout lors de l'ajout sur ObservableRangeCollection (à partir des assistants mvvm), sur Android fonctionne bien.

Cela ressemble à un problème distinct pour moi. Je ne pense pas que ce soit les éléments restants liés.

Est-il possible, lors de l'utilisation de GridItemsLayout, de permettre aux éléments de s'étendre sur plusieurs lignes ou colonnes ? Ce serait certainement une fonctionnalité qui vaudrait la peine d'avoir.

Des informations à ce sujet ?

@LynoDesu Un problème est suivi pour cela : https://github.com/xamarin/Xamarin.Forms/issues/6357

@LynoDesu Un problème est en cours de suivi pour cela : #6357

Ah super ! Merci. Par où commencer si je veux y contribuer ?

Lisez le wiki de la page d'accueil ainsi que Contributing.md .

@ adrianknight89 a trouvé le https://github.com/andreabalducci/XamarinCollectionView/blob/b186e563ff8391dfb473e62e5a4c4587e8d4e9da/cvrepro/cvrepro/ListViewModel.cs#L46

Commencer avec une collection vide déclenche le problème, si la collection contient des éléments avant de lier tout fonctionne comme prévu.

testé sur émulateur iPhone.

Je vois le problème. C'est probablement le même que #7548. Vous voudrez peut-être poster votre repro là-bas.

CollectionView semble être buggé sur Android lors de l'utilisation d'IsGrouped.

CollectionView.GroupHeaderTemplate n'est pas rendu du tout. Sur iOS ça marche bien. Vous pouvez simplement utiliser l'exemple de regroupement du site Microsoft pour le tester.

    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

Important

Le regroupement de données avec CollectionView n'est actuellement pris en charge que sur iOS.

Ops, j'ai raté cette partie. Merci.

Pour ceux d'entre nous qui souhaitent afficher une liste regroupée sur iOS et Android, mais qui souhaitent éviter ListView, y a-t-il autre chose que nous pouvons utiliser qui soit aussi flexible que CollectionView pour le moment ? Ou sommes-nous coincés avec ListView ?

J'espère que c'est le bon endroit pour demander. Je vois dans la spécification publiée d'origine qu'il existe des propriétés pour IsHeaderSticky et IsFooterSticky , mais je n'en vois aucune mention supplémentaire dans la discussion ou dans le code source implémenté. Sont-ils toujours sur la feuille de route pour cette vue ?

Dans collectionview, nous avons besoin d'ItemAppeared, ItemDisappeared.
y a-t-il un moyen d'y parvenir ?

@IosDeveloperHarsh L' Scrolled fournit de nombreuses informations utiles dans les arguments de l'événement. Regardez le premier et le dernier index d'éléments visibles.

Les exemples de la galerie n'aie pas exécuté l'exemple que vous avez fourni. Quel Nuget utilisiez-vous ? Essayez avec la dernière pré-version ou tous les soirs.

@cabal95 Je ne suis pas qualifié pour répondre à cela, mais si je devais deviner, ils finiront par être mis en œuvre. Peut-être avons-nous besoin d'un problème actif pour suivre cela. Je sais que le travail initial d'en-tête/pied de page excluait les éléments collants.

Je pense que SelectionChangedCommandParameter devrait être supprimé et à la place, nous aurons l'élément sélectionné automatiquement défini en tant que paramètre.

Si c'est possible, ce serait bien d'utiliser la propriété comme celle-ci

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

Mais cela devrait être ok aussi :

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

Je pense que SelectionChangedCommandParameter devrait être supprimé et à la place, nous aurons l'élément sélectionné automatiquement défini en tant que paramètre.

Si c'est possible, ce serait bien d'utiliser la propriété comme celle-ci

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

Mais cela devrait être ok aussi :

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

Que se passe-t-il si l'utilisateur souhaite utiliser autre chose que SelectedItem comme paramètre de sa commande ?

Je pense que SelectionChangedCommandParameter devrait être supprimé et à la place, nous aurons l'élément sélectionné automatiquement défini en tant que paramètre.
Si c'est possible, ce serait bien d'utiliser la propriété comme celle-ci
public ICommand => new Command<MySelectedItemModel>((item) => {}
Mais cela devrait être ok aussi :
public ICommand => new Command<object>((item) =>{ var selectedItem = item as MySelectedItemModel;}

Que se passe-t-il si l'utilisateur souhaite utiliser autre chose que SelectedItem comme paramètre de sa commande ?

Vous avez raison, mais j'ai du mal à voir un cas d'utilisation pour cela car vous définissez le paramètre au niveau CollectionView. Je m'attendais à ce que ce soit l'article sélectionné la première fois que je l'ai utilisé. Mais vous pouvez peut-être définir l'élément sélectionné par défaut ? Si vous utilisez l'événement, vous obtiendrez donc je pense que de nombreux développeurs l'attendent également pour la commande.

J'aimerais également demander une fonctionnalité selon laquelle cette CollectionView ne s'étend pas sur tout l'écran et utilise simplement la hauteur en fonction du nombre d'éléments.

J'essaie d'avoir plusieurs listes en vue
c'est à dire
Achats

Déductions

Le total
le total
tot

mais les éléments 1 et 2 (une CollectionView) ont juste pris trop de hauteur même si je n'ai que 3 ou 4 éléments et qu'il y a un écart BIIIIIIIIIIIIIIIG en dessous avant que je puisse voir la section Déductions

J'ai fini par créer mon propre contrôle ItemsCollection basé sur StackLayout

J'aimerais également demander une fonctionnalité selon laquelle cette CollectionView ne s'étend pas sur tout l'écran et utilise simplement la hauteur en fonction du nombre d'éléments.
J'ai fini par créer mon propre contrôle ItemsCollection basé sur StackLayout

Je pense que ce que vous recherchez peut être des mises en page pouvant être

J'aimerais également demander une fonctionnalité selon laquelle cette CollectionView ne s'étend pas sur tout l'écran et utilise simplement la hauteur en fonction du nombre d'éléments.
J'ai fini par créer mon propre contrôle ItemsCollection basé sur StackLayout

Je pense que ce que vous recherchez peut être des mises en page pouvant être

Hey! Exactement ce dont j'ai besoin. Depuis quand BindableLayouts existe-t-il ?

Merci à tous pour la discussion sur cette question! Si vous avez des demandes de fonctionnalités supplémentaires ou des rapports de bogues, veuillez ouvrir de nouveaux problèmes pour chacun. Nous clôturons maintenant ce problème.