¿Qué tal el evento de desplazamiento para admitir encabezados de paralaje?

Hay mucho que amar sobre esto.

FontIconSource

Sin embargo, para FontIconSource, realmente necesitamos una forma de no usar el valor Unicode (si no queremos). Si está viendo un FontIconSource con un valor f370 no tiene ni idea de lo que se supone que es.

Por otro lado, si puedo elegir qué fuentes de iconos estoy usando y darle a Forms una forma de convertir fa-app-store-ios en su equivalente Unicode de f370 , ahora puedo saber de un vistazo que el ícono que estoy usando es de Font Awesome y es el ícono de la App Store de iOS. De ninguna manera estoy diciendo que los formularios deberían tener ese conocimiento para cada fuente disponible incorporada (o cualquier otra para el caso), que puede provenir de algunas esencias públicas o agregarse al Kit de herramientas de la comunidad, etc. De cualquier manera, necesitamos una forma de utilizar nombres significativos.

Por último, espero que podamos obtener una extensión XAML horneada para esto para que tenga algo como:

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

Menús

Como estuve discutiendo con @davidortinau anteriormente, sería particularmente ideal si pudiéramos mezclar y combinar en los menús contextuales para lograr los resultados adecuados. Un buen contexto para esto sería pensar en un cliente de correo electrónico en el que puede obtener un menú cuando desliza el dedo hacia la izquierda y otro hacia la derecha. Otro escenario que me encantaría ver compatible sería el enfoque del menú de celda como se muestra en los documentos para iOS CollectionView .

Eventos

Creo que es seguro decir que soy parcial, pero una gran parte de la comunidad sigue un patrón de diseño MVVM. Tener los eventos SelectionChanged & RemainingItemsThresholdReached son importantes para la API, pero sería fantástico si pudiéramos encontrar una manera de admitir estos OOB con una versión de ViewModel de un controlador de eventos ... Yo ordeno.

Dado que RemainingItemsThresholdReached solo envía un EventArgs antiguo simple, creo que podemos asumir con seguridad que pasar nulo al comando debería estar bien, ya que solo necesitamos ejecutar el comando. Para SelectionChanged, tendería a pensar que sería más vital conocer los nuevos elementos que los elementos antiguos, por lo que simplemente pasar los nuevos elementos OOB a SelectionChangedCommand debería estar bien. Es posible que esto no afecte a todos los casos de uso, pero al menos proporciona una cantidad mínima de sobrecarga que un desarrollador debe agregar con algo de EventToCommandBehavior.

La muestra perfecta que mata la vista de lista actual es hacer que el control de Calendario donde:
-días (celdas) pueden tener muchos estilos:
como día de promoción, cumpleaños, discapacitados / día sin venta / festivo ...
iconos incrustados con diferentes fuentes personalizadas, la celda tiene sombras si se selecciona, otro estilo cuando está en r
rabia, otros cuando al principio y al final del rango
-es posible seleccionar rangos de fechas
-encabezado de mes y estilo de encabezado personalizado
-Los encabezados de mes tienen botones que permiten algunas vistas / acciones / visualización especiales en el mes actual

¿Qué tal si agregas también una GroupFooterTemplate?

Esto es muy necesario en Forms :-) CollectionView eliminaría costosas soluciones alternativas, resolvería limitaciones y probablemente mejoraría el rendimiento en casi todas las aplicaciones de Forms que hice en los últimos 5 años. También es exactamente el enfoque correcto: aprovechar y exponer el poder de las plataformas nativas.

Si solo hubiera UNA mejora que pudiera solicitar para Formularios, sería esta.
(de hecho, lo hice en 2017 en respuesta a @davidortinau)

¡Esto es realmente asombroso y muy esperado! La API es limpia y sencilla (¡gracias por cambiar el nombre de HasUnevenRows!).

Los eventos de desplazamiento son muy necesarios, como sugiere @dhaligas. Para animaciones de paralaje, pero también para ocultar el botón de acción flotante mientras se desplaza, por ejemplo.

FontIconSource es una buena idea. Puede ser fantástico proporcionar una lista predeterminada de iconos, con unicode mapeado para cada plataforma (similar a iOS o UWP).

Esto suena exactamente como lo que se necesita. La API se ve mucho más limpia, tener múltiples vistas / contenedores estructurados de esta manera debería ayudar a mantener el código más limpio y simple.

Mis comentarios hasta ahora:

@dansiegel Un comando cuando se

Desplazamiento: Estoy completamente de acuerdo con el evento de desplazamiento. Podemos obtenerlo en este momento para Android, pero para iOS debe ajustar UITableViewSource y secuestrar el método Scrolled.

Lo más importante para mí sería la extensibilidad. Por favor, no use clases internas para adaptadores y TableViewSources, y en los renderizadores nativos exponga los métodos "CreateAdapter" y "CreateViewSource" (y similares para otras plataformas) donde podemos crear nuestro propio tipo si queremos. Tenemos un ListAdapter personalizado para el soporte de arrastrar y soltar en Android, y como se mencionó anteriormente, un UITableViewSources personalizado para desplazarse y arrastrar y soltar. Sin embargo, no es el código lo que me gusta porque hay un ajuste de clases internas, etc.

Esto no solo se aplica a adaptadores / fuentes de visualización. En general, en la nueva API, agregue puntos en los que podamos extender el comportamiento si es necesario.

¡Creo que esta es una característica realmente genial e importante!
iOS ya está usando el nombre UICollectionView, lo que podría generar confusión y resultados incorrectos de Google al buscar CollectionView. ¿Es esto un problema?

Solo para sacarlo del camino, me encanta básicamente todo lo relacionado con CollectionView spec. Sin embargo, podría valer la pena dividir algunas de las cosas en temas separados, ya que tengo pensamientos sobre ellos, como estoy seguro de que muchos otros lo hacen y puedo ver que las conversaciones se vuelven difíciles de seguir. Por ejemplo:

Esto podría agregarse más tarde, pero algo como:

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

sería útil, para admitir iconos de apilamiento: https://fontawesome.com/how-to-use/on-the-web/styling/stacking-icons

Mi retroalimentación:

1. No pondría las capacidades de selección de elementos en la clase CollectionView. En su lugar, agregaría una clase base abstracta ListCollectionView derivada de CollectionView que tiene capacidades específicas:

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

Mi idea es tener un CollectionView similar al ItemsControl en Windows XAML. ItemsControl toma una instancia de Panel que coloca los elementos. En Forms, tendremos CollectionView y IItemsLayout.
De forma predeterminada, si no se proporciona IItemLayout, el diseño predeterminado podría ser un diseño de pila. De esta manera, básicamente podríamos tener ItemsSource combinado con StackPanel de Windows XAML, o en otras palabras, ¡un StackLayout enlazable!

Además de la selección de elementos, hay otras capacidades que no pondría en CollectionView, las agregaría a ListCollectionView. Por ejemplo, CollectionView no debería tener desplazamiento. De esta forma cubrirá este hilo

1. Cambiaría el nombre de la interfaz IItemsLayout a ICollectionViewLayout. El marco ya tiene Layout y ItemsView . Sería un nombre más largo, pero ICollectionViewLayout es una fuerte indicación de para qué sirve, es específico de CollectionView, no una forma general de mostrar elementos.

2. Cambiaría el nombre de la clase ItemsLayout a OrientedCollectionViewLayout. Es una fuerte indicación de para qué es realmente la clase base abstracta, todas las clases derivadas distribuyen los elementos de forma orientada. Además, el uso de "Orientado" en el nombre da la opción en el futuro de agregar una clase base abstracta llamada simplemente "CollectionViewLayout". si se requiere alguna nueva funcionalidad común para todas las clases de diseño de vista de colección, no solo las que tienen orientación.

3. Eliminar ViewCell y simplemente usar DataTemplate es muy bienvenido, mejora la reutilización.

1. ¿Puede compartir más detalles sobre RefreshView?
   Supongo que RefreshView de alguna manera debería asignarse a UIRefreshControl en iOS. ¿Cómo funcionará en Android y UWP?

En caso de que alguien esté interesado, hice algunas actualizaciones a mi primer comentario anterior.

Estoy de acuerdo con @andreinitescu en que sería bueno tener una forma de tener una colección sin desplazamiento. Soy neutral sobre si eso significa dividirlo en varias clases o posiblemente tener algo como una propiedad ScrollMode. Me referiré a aquellos con mucha más experiencia en diseño de API que yo en eso. Pero es bastante trivial implementar su propia lista de elementos basada en StackLayout con un selector de plantilla o DataTemplate, por lo que tal vez no sea necesario.

Si bien me gusta la idea de controlar la función de desplazamiento, tampoco se me ocurre ningún caso de uso convincente para una "Colección" sin desplazamiento que incluya todas las funciones avanzadas de ListView o el CollectionView propuesto en la parte superior de mi cabeza. Mi caso de uso para una lista sin desplazamiento siempre ha sido resuelto por la lista de elementos trivial. Mi razón normal para no usar un ListView es porque no quiero selección o quiero diseñar la lista horizontalmente. Ambos casos parecían estar cubiertos por la especificación propuesta. Me interesaría cualquier ejemplo de uso que alguien más tenga para ningún pergamino.

@bmacombe Estoy de acuerdo con usted en que es "simple" implementar un StackLayout enlazable, pero ese no es el punto, creo. Es una funcionalidad muy común, ¿por qué no tenerla en el marco? Y con un poco de planificación, creo que se puede hacer. Como ya dije anteriormente, se puede resolver simplemente extendiendo la funcionalidad en dos clases, una clase base (similar a ItemsControl en Windows XAML) y CollectionView (ListView). Idealmente, debería haber una clase Selector en la jerarquía (consulte https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.controls.primitives.selector)

Yo diría que la razón trivial para tener una opción sin desplazamiento es que algunas páginas deben tener un ScrollView para toda la página y una lista de elementos.

Si hace eso, en este momento no se recomienda colocar un ListView en un ScrollView. Un CollectionView enlazable que podría poner allí, que todavía tiene potencialmente todas las características de un ListView, es algo que he necesitado varias veces.

Escribí lo mismo BindableStack que todos los demás, pero sería mucho más agradable trabajar con uno horneado.

@adammeaney Eso tiene sentido y he hecho algo similar ahora que lo pienso.

@andreinitescu No estoy en desacuerdo, sería genial tenerlo integrado. Creo que todos están en la misma página sobre lo que se necesita, solo cuál es la mejor manera de hacerlo. Estoy de acuerdo con cualquiera de los enfoques siempre que haya una opción de "no desplazamiento" de algún tipo.

En mis propios marcos, siempre voy y vengo en la construcción de muchas características en un solo control o tengo muchas clases similares con funciones incrementales. Seré bueno con cualquier cosa que el equipo de Forms decida implementar de la mejor manera, especialmente considerando las implementaciones de la plataforma subyacente.

@bmacombe Con algo de planificación, espero que podamos conseguir dos pájaros de un tiro.
Por ejemplo, una instancia de la clase CollectionView que funciona de la manera que mencioné, si no tiene un conjunto de IItemLayout, el mecanismo del renderizador podría asignarla a un UIStackView nativo en iOS o StackPanel en UWP o LinearLayout en Android. O, para que sea más fácil de implementar, podría usar el StackLayout existente para organizar las vistas.

Mi impresión fue que un nuevo ListView debería apuntar tanto a solucionar desafíos con ListView existente como también proporcionar una solución al hilo "RepeatableBinder" aquí

Queremos ver dónde aterriza ListView2 antes de impulsar esta especificación. Contiene muchos de los mismos componentes necesarios y sería mejor evitar duplicarlos.

No veo cómo poner toda la funcionalidad en CollectionView como sugiere la especificación aquí haría bien el trabajo.

2680 ¿Podría añadirse a esta especificación? Con respecto a la habilitación de ScrollBar.

@andreinitescu

¿Puede compartir más detalles sobre RefreshView?
Supongo que RefreshView de alguna manera debería asignarse a UIRefreshControl en iOS. ¿Cómo funcionará en Android y UWP?

En UWP, probablemente usaremos RefreshContainer . En Android, probablemente SwipeRefreshLayout .

@krdmllr

iOS ya está usando el nombre UICollectionView, lo que podría generar confusión y resultados incorrectos de Google al buscar CollectionView. ¿Es esto un problema?

Es un problema, pero no uno nuevo. Tenemos el mismo problema con GestureRecognizer, ListView, Grid y muchas otras cosas en Forms. Luchamos un poco con esto internamente; hay un número limitado de nombres posibles para "un montón de elementos en una pantalla".

"CollectionView" no entra en conflicto con nada que tengamos actualmente en Forms, no entra en conflicto con ningún nombre de control de UWP (como lo hace "ListView") y no es _exactamente_ como UICollectionView (debido al prefijo "UI"). No es 100% ideal para fines de búsqueda, pero creemos que es la mejor expresión de la intención del control.

Dicho esto, si alguien propone un nombre alternativo del que nos enamoramos de inmediato, estaré feliz de buscar y reemplazar.

(Quería llamarlo "ListView2ColonRevengeOfTheListView", pero

@dansiegel

Un buen contexto para esto sería pensar en un cliente de correo electrónico en el que puede obtener un menú cuando desliza el dedo hacia la izquierda y otro hacia la derecha.

Eche un vistazo a la especificación SwipeView : eso es precisamente lo que buscamos.

@GalaxiaGuy

Apoyar los iconos de apilamiento

Ese es un gran punto, deberíamos apoyarlo si es posible. Sé que funciona con los glifos integrados de UWP; Tendría que investigar un poco para asegurarme de que ese tipo de apilamiento funcionaría en las otras plataformas (sospecho que la respuesta es "sí").

Actualización: la parte FontIconSource de esta especificación se ha movido a su propia especificación .

Sería un escenario de usuario para la selección múltiple de elementos de una selección, por ejemplo, la selección de una o más fotos de un álbum. Un escenario bastante común en aplicaciones como OneDrive o WhatsApp.

@hartez

Dicho esto, si alguien propone un nombre alternativo del que nos enamoramos de inmediato, estaré feliz de buscar y reemplazar.

Ya sugerí un nuevo nombre por diferentes razones.

¿Cuál será el valor de SelectedItem cuando SelectionMode sea Multiple ? Hay 5 opciones en las que puedo pensar:

1. El último artículo seleccionado por orden de selección.
   
2. El último elemento seleccionado por orden de origen.
   
3. El último artículo seleccionado / deseleccionado por orden de selección.
   
4. El último artículo seleccionado / deseleccionado por orden de origen.
   
5. nulo
   
   
   
   (2), (3) y (4) no son muy útiles. Los agregué solo para cubrir todas las opciones. (1) parece ser la opción más lógica. (5) si no desea admitir SelectedItem en absoluto si SelectionMode es Multiple .

@ AmrAlSayed0

¿Cuál será el valor de SelectedItem cuando SelectionMode sea Multiple?

Ahora mismo la respuesta es "lo que fuera antes de cambiar SelectionMode a Multiple ".

@rogihee

Me gustaría un escenario de usuario para la selección múltiple de elementos de una selección

¿Está preguntando si este escenario de selección es compatible? AFAIK, todos los controles nativos que pretendemos usar lo admiten, por lo que _debería_ ser compatible con CollectionView.

Un estilo enlazable para SelectionMode sería útil, si SelectionMode = Ninguno, Transparente, etc., esto es algo que Radlist hace y es una forma muy útil y fácil de manejar el estado visual basado en enlaces. Un estilo para cada modo de selección cubriría estos escenarios.

@andreinitescu

Respondiendo a sus comentarios de https://github.com/xamarin/Xamarin.Forms/issues/3172#issuecomment -401015625 (y en otros lugares):

Estás mencionando muchos puntos buenos y quiero asegurarme de que sabes que no los estamos ignorando. Simplemente no conocemos todas las respuestas todavía. Estamos en el proceso de aumentar esta API para que podamos ver dónde funciona y dónde se desmorona; Sospecho que el desglose de clases que estás sugiriendo está bastante cerca de donde tendremos que terminar.

Reconocemos que usted (y varios otros) está muy interesado en que esas clases intermedias se puedan representar como StackLayouts y Grids de elementos con plantilla (es decir, el "BindableRepeater"), y ese es uno de los casos de uso que estamos explorando.

@alexhardwicke

En general, en la nueva API, agregue puntos en los que podamos extender el comportamiento si es necesario.

Los métodos UpdateX en los renderizadores serán protected virtual . :)

Con toda seriedad, somos conscientes de que este ha sido un punto débil en el pasado, y lo tenemos en cuenta al escribir CollectionView .

1. Pensándolo bien, realmente no creo que CollectionView sea una buena opción para el nombre de clase de esta vista.
   En Windows XAML, CollectionView es la clase base para una fuente de datos de elementos que se utilizan para filtrar agrupaciones; consulte https://msdn.microsoft.com/en-us/library/system.windows.data.collectionview (v = vs. 110) .aspx
   Tal vez en algún momento Xamarin Forms obtenga una clase para el mismo propósito, y creo que tendrá sentido si tiene el mismo nombre (CollectionView), especialmente cuando se piensa en XAML Standard (¿todavía está planeado?)

   Por feo y divertido que parezca, ListView2 es una buena opción :) Es la práctica recomendada en .NET usar el sufijo para el control de versiones cuando el nombre existente es el único nombre que tiene sentido:

   USE un sufijo numérico para indicar una nueva versión de una API existente, particularmente si el nombre existente de la API es el único nombre que tiene sentido (es decir, si es un estándar de la industria) y si agrega algún sufijo significativo (o cambia el name) no es una opción adecuada.

   _Directrices de diseño de marcos: convenciones, modismos y patrones para bibliotecas .NET reutilizables, segunda edición_
   https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/general-naming-conventions

   En algún momento más adelante, todos usarán el nuevo, brillante. ListView2 estable y eficaz :). Avance rápido, cambiar el nombre de ListView2 a ListView, aunque sea un cambio importante, será una refactorización simple (y bienvenida) para todos.

2. En Xamarin Forms ya hay un ItemsViewque se parece mucho a ItemsControl en Windows XAML, excepto que no tiene una propiedad de diseño de elementos.
   En lugar de crear una nueva clase CollectionView, ¿sería posible utilizar ItemsView existentes?también como una clase base para el nuevo ListView?

3. Existe un desafío obvio en el diseño y la implementación de la API, con el uso de los controles de la plataforma nativa que muestran elementos de una lista pero aún tienen la flexibilidad de tener algo como el "BindableRepeater", que está destinado a mostrar un simple, más ligero, no desplazable y no -Lista de elementos seleccionables.
   Parece que Uno logró hacerlo:

   • 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

En lugar de crear una nueva clase CollectionView, ¿sería posible usar ItemsView existente también como una clase base para el nuevo ListView?

Hay ItemsView<T> , pero no queremos usar eso. Utiliza TemplatedItemsList , que es parte del problema que estamos tratando de evitar con este nuevo control.

En algún momento más adelante, todos usarán el nuevo, brillante. ListView2 estable y eficaz :). Avance rápido, cambiar el nombre de ListView2 a ListView, aunque sea un cambio importante, será una refactorización simple (y bienvenida) para todos.

Su optimismo es encantador, pero tenemos que trabajar bajo el supuesto de que ListView (1) es para siempre y que no se permitirá un cambio rotundo como un cambio de nombre de ListView2.

Pensé que estar a la par con Windows XAML tiene sentido, pero está bien, use el nombre que desee, siempre que el nuevo control cumpla con su promesa. El marco de Uno parecía haber tenido éxito en hacer eso, así que ahora estoy ansioso por ver lo que están trayendo ustedes en Xamarin Forms.

@gmwilhelm

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

Buen punto. Tentativamente lo agregué a la API. Digo tentativamente, porque puedo ver totalmente cómo podríamos implementarlo en iOS y Android, pero UWP podría ser un desafío.

Pero no puedo negar que es razonable y agradablemente simétrico.

¿Qué tal agregar GroupItemsBinding ?

Eso permitiría que un grupo contenga una propiedad de tipo de colección, en lugar de requerir que un grupo se derive de una colección, como lo hace ListView. Esta limitación existente de ListView me ha obligado a realizar una costosa duplicación de estructuras de datos agrupadas en varias ocasiones. Agregar GroupItemsBinding evitaría esto y permitiría una asignación más flexible a las estructuras de datos agrupadas.

Es decir, el ejemplo utilizado en la documentación de GroupDisplayBinding podría ser:

`` C #
class Group // Tenga en cuenta que Group no tiene que derivar de ObservableCollection
{
Grupo público (cadena 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 = nuevo enlace (nombre de (Grupo.Personas))
// ...
};
// ...
}

''

Dado que este es un subconjunto de lo que hace UICollectionView en términos de diseño, creo que deberíamos elegir un nombre diferente para evitar confusiones con las capacidades del control.

Para que quede claro, este control aún no está disponible para su uso, ¿es correcto? Traté de hacer referencia a él, pero mi proyecto no puede encontrarlo.

@titonton Este problema es solo para discutir la especificación de CollectionView, la implementación aún no ha comenzado y no creo que lo haga hasta que se finalice la especificación.

@ AmrAlSayed0 En realidad, debería haber comenzado porque se movió a "En progreso en Sprint 139" hace 11 días.

No está muy claro cómo se inició esto, dado que no está claro cuál es la decisión sobre la API.

@opcodewriter Eso es lo que estaba pensando. @ AmrAlSayed0 Gracias por la aclaración.

¿Alguien podría aclarar cuál es el estado actual de esta especificación? ¿Falta algo donde la comunidad pueda ayudar?

@migueldeicaza @hartez Nombrar esto será difícil si no quieres que se llame CollectionView . ¿Qué tal CatalogView ?

Los catálogos a menudo se diseñan en una o más columnas y con varias filas de elementos con fuentes, textos, diseños, etc. similares.

Muestra:

@hartez ¿Sientes que las API están casi completas ahora? ¿Cuánto trabajo se ha realizado hasta ahora? A muchos de nosotros nos encantaría tener en nuestras manos este control lo antes posible. :)

@ adrianknight89 Creo que esta es la rama de trabajo. https://github.com/xamarin/Xamarin.Forms/tree/lv2spike

No anticipamos que esté listo para la vista previa por un tiempo todavía, pero mostraré / demostraré los resultados del esfuerzo actual en las próximas semanas para validar el progreso y recibir comentarios.

Estoy confundido. Como ya ha tenido algunas demostraciones internas, parece que ya ha avanzado bastante en la implementación.
¿No debería esto significar que muchas de las API han sido definidas? ¿Estás siguiendo las especificaciones de la API aquí?
No veo cómo la especificación actual podrá abordar lo que se ha discutido aquí y en el otro hilo aquí https://github.com/xamarin/Xamarin.Forms/issues/1718
Para ser más precisos, la API no es lo suficientemente flexible como para permitir, por ejemplo, un simple control tipo StackLayout enlazable y no desplazable.

¿El nuevo control permite colocar elementos encuadernados en una pila, sin barra de desplazamiento, al igual que StackLayout?

Gracias, esperado mucho por esto 👍

Después de una gran cantidad de discusiones internas e intentos de encontrar una arquitectura adecuada, hemos decidido que CollectionView _no_ manejará los escenarios de diseño discutidos en # 1718. En otras palabras, no controlará el enlace de una colección de objetos a elementos en ningún diseño de Xamarin.Forms.

El objetivo original de CollectionView era permitir a los usuarios aprovechar fácilmente los diversos controles de cuadrícula / lista nativos modernos (UICollectionView, RecyclerView, ListView / GridView, etc.).

Fue tentador intentar hacer de CollectionView un control integral para las necesidades de "renderizar y organizar esta plantilla con datos" de todos, incluidos todos los escenarios en los que el paso de "organizar" fue manejado por Forms Layouts (FlexLayout, StackLayout, etc. ). Y hay algunas superposiciones obvias de funcionalidad (por ejemplo, ambos escenarios usan plantillas de datos). Pero al final, tienen una gran diferencia de arquitectura fundamental, y tratar de atornillarlos juntos resultaría en algo más difícil de mantener y confuso que simplemente dejarlos como controles separados. No queríamos crear algo tan complejo que acabáramos teniendo que implementar ListView3 en un par de años. Lo explicaré más a continuación.

El resultado de esto es que CollectionView permanecerá enfocado en el problema de permitir que los usuarios de Forms utilicen los controles nativos de lista / cuadrícula y se beneficien de sus motores de diseño y virtualización. Y # 1718 se actualizará para reflejar una API que permitirá a los usuarios de Formularios vincular un ItemsSource y ItemTemplate a los distintos motores de diseño de formularios.

Para aquellos interesados ​​en el _por qué_ de dos controles versus uno:

La diferencia fundamental entre lo que se describe aquí (como CollectionView) y la propuesta en # 1718 es _donde_ ocurre el diseño.

CollectionView tiene como objetivo utilizar los motores de diseño nativos (que han sido optimizados en gran medida por los desarrolladores de la plataforma) para manejar el diseño. Se involucra algo de código personalizado de Forms (por ejemplo, al proporcionar cosas como la lógica de SnapPoints en Android e iOS), pero en su mayor parte, los motores de diseño nativos (y las implementaciones de virtualización nativas) están haciendo el trabajo pesado. Esto marca una gran diferencia con respecto al rendimiento.

Por lo tanto, cualquier información de diseño que el desarrollador proporcione a CollectionView simplemente se transmite al renderizador en cada plataforma para su interpretación; es efectivamente una especificación que se traduce al idioma local (LinearLayoutManager / GridLayoutManager en Android, UICollectionViewFlowLayout en iOS, etc.). Más allá de DataTemplate, Forms no hace nada del trabajo de diseño.

Por el contrario, un diseño de formularios (FlexLayout, StackLayout, AbsoluteLayout, etc.) se presenta completamente en la capa de formularios. Los renderizadores de un diseño de formularios hacen muy poco. Y no se está produciendo ninguna virtualización; todos los elementos se crean y colocan en el diseño desde el principio.

Tratar de unir estas dos cosas conduce a algunas preguntas difíciles, que incluyen:

1. ¿Cómo funciona el mapeo del renderizador? Un CollectionView que usa un StackLayout tiene un renderizador muy diferente al de un CollectionView que necesita usar un RecyclerView. ¿Los mezclamos y ocultamos RecyclerView cuando no lo necesitamos? ¿Tenemos el renderizador derivado de DefaultRenderer? Si hacemos eso, siempre tendremos una capa adicional de ViewGroup que realmente no necesitamos ...

2. ¿Cómo manejamos ScrollViews? UICollectionView maneja su propia pantalla de desplazamiento, pero si un StackLayout necesita desplazarse, el usuario normalmente lo agrega manualmente en Forms. ¿Agregamos otra capa para insertar el desplazamiento automáticamente si es necesario? ¿Deshabilitamos / eliminamos un ScrollView agregado manualmente si el diseño requiere un UICollectionView?

3. De hecho, ¿a dónde van los métodos ScrollTo?

... y así. Todos estos problemas se _solucionan_, pero cada solución agrega _complejidad_. Y como se ha señalado en el n. ° 1718, agregar ItemsSource y ItemsTemplate a un diseño de formularios no es tan difícil o complejo. Hacer que sea complejo simplemente atornillar estos dos escenarios distintos juntos no vale los beneficios.

Estoy confundido. Como ya ha tenido algunas demostraciones internas, parece que ya ha avanzado bastante en la implementación. ¿No debería esto significar que muchas de las API han sido definidas? ¿Estás siguiendo las especificaciones de la API aquí?

Seguimos la API publicada aquí. "Bastante lejos" es probablemente una exageración; Hasta ahora, hemos implementado algunas de las partes no controvertidas de la especificación para verificar que sean posibles y que no vayamos por ningún callejón sin salida. Suponiendo que no tengamos ningún problema, es probable que gran parte de lo que hemos implementado hasta este punto esté en la versión publicada. Pero todo en la especificación aún está sujeto a cambios, al igual que todo lo que hemos implementado hasta ahora.

No veo cómo la especificación actual podrá abordar lo que se ha discutido aquí y en el otro hilo aquí # 1718. Para ser más precisos, la API no es lo suficientemente flexible como para permitir, por ejemplo, un simple control tipo StackLayout enlazable y no desplazable.

Es cierto, y parte de lo que hemos estado trabajando es determinar si CollectionView _podría_ cubrir razonablemente esos casos de uso. Hemos tomado una decisión al respecto; ver https://github.com/xamarin/Xamarin.Forms/issues/3172#issuecomment -424413234.

Dado que este es un subconjunto de lo que hace UICollectionView en términos de diseño, creo que deberíamos elegir un nombre diferente para evitar confusiones con las capacidades del control.

Como he dicho (https://github.com/xamarin/Xamarin.Forms/issues/3172#issuecomment-401186893), estoy abierto a otros nombres.

¿Qué tal CatalogView?

Los catálogos a menudo se diseñan en una o más columnas y con varias filas de elementos con fuentes, textos, diseños, etc. similares.

Esta es una idea interesante. Definitivamente no entra en conflicto con ningún nombre de control existente.

@hartez Como un tipo aleatorio en Internet, que se está familiarizando con los aspectos internos de Xamarin Forms (y ya estaba bastante familiarizado con UITableView y UICollectionView), creo que este es el movimiento correcto.

¿Seguirá siendo posible proporcionar un diseño personalizado (incluso si eso significa proporcionar implementaciones separadas por plataforma)?

¿Seguirá siendo posible proporcionar un diseño personalizado (incluso si eso significa proporcionar implementaciones separadas por plataforma)?

Absolutamente. Puede proporcionar su propio diseño marcado con IItemsLayout y su renderizador personalizado puede interpretarlo como desee.

Por ejemplo, como prueba de concepto, subclasé el renderizador de Android para CollectionView y agregué la capacidad de interpretar una clase FlexLayout : IItemsLayout que incluía un montón de propiedades Flex Layout. Pasa esas propiedades al FlexBoxLayoutManager de Google y usa ese administrador de diseño con RecyclerView. Una vez que hagamos disponible una vista previa pública, probablemente lanzaré ese ejemplo en GitHub para que la gente tenga una referencia fácil sobre cómo hacer ese tipo de cosas.

El objetivo es hacer que esto sea muy, muy flexible.

@hartez
¿Se solucionó el problema descrito en https://github.com/xamarin/Xamarin.Forms/issues/3749 con CollectionView?
Porque aquí veo que CollectionView solo tiene la propiedad ItemTemplate , que parece que tendrá el mismo problema que ListView .

@hartez
¿Se ha solucionado el problema descrito en el n. ° 3749 con CollectionView?
Porque aquí veo que CollectionView solo tiene la propiedad ItemTemplate , que parece que tendrá el mismo problema que ListView .

@andreinitescu Gracias por señalar esa discusión, no estaba al tanto de este problema con DataTemplate.

Voy a dedicar algo de tiempo la semana que viene a investigar el historial de DataTemplate: por qué está diseñado de esta manera y si hay algún problema de compatibilidad con versiones anteriores al arreglar CreateContent para hacer automáticamente lo correcto (tanto en ListView y CollectionView).

@hartez Solo como un ejemplo de cómo

// Verificamos si tenemos un selector de plantilla o solo una plantilla
var templateToUse = itemTemplate es DataTemplateSelector templateSelector? templateSelector.SelectTemplate (elemento, nulo): itemTemplate;

Entonces, en un caso como ese, simplemente arreglar CreateContent no lo rompería, simplemente lo haría innecesario. Pero estoy de acuerdo con @andreinitescu en que separar ItemTemplate y ItemTemplateSelector como propiedades separadas sería ideal ... probablemente debido a mi experiencia en WPF y SL.

@bmacombe En mi

@andreinitescu Crea confusión :) Créame, al principio estaba confundido cuando intentaba admitir DataTemplate y DataTemplateSelector en mi repetidor. Especialmente cuando tuvo un error cuando asigné un DateTemplateSelector a mi propiedad DataTemplate cuando funcionó en todos los lugares XF que lo usaron. Tomó algo de código fuente para averiguarlo. Probablemente no sea un problema para alguien que solo usa los controles XF incorporados, pero tratar de hacerlo usted mismo y usarlo ... realmente confuso.

¿Podemos tener un evento de desplazamiento en CollectionView? Hasta que se publique CollectionView, tengo una sugerencia para ListView https://github.com/xamarin/Xamarin.Forms/issues/4323

Y, ¿será posible crear diseños irregulares y dinámicos, como PInterest por ejemplo?

Verás, cada imagen tiene su propia altura :-)

¿No estás seguro de que se pueda admitir este tipo de diseño?

Actualización: de la lista de propuestas de nombres, lo más cercano que hemos encontrado es "ItemsView", esto es para evitar el uso del término "CollectionView" que da a la gente la impresión de que es tan completo como el "UICollectionView" de iOS

Hola, todavía soy nuevo en Xamarin, pero he estado trabajando con ListView usando DataTemplateSelector.
Cuando intenté probar usando CollectionView con DataTemplateSelector, arroja un error

Excepción no controlada:

System.InvalidOperationException: LoadTemplate no debería ser nulo ocurrió

¿Existe un error conocido relacionado con DataTemplateSelector?
Podría estar implementándolo incorrectamente. ¿Hay algún ejemplo sobre el uso de DataTemplateSelector con CollectionView?

@hartez @davidortinau ¿ alguna razón por la que KeepItemsInView no se nombra KeepFirstItemInView para alinearse con KeepLastItemInView ? El nombre actual es plural (es decir, sugiere varios elementos) mientras que la descripción dice que solo mantiene el primer elemento visible en la ventana gráfica.

Además, ¿hay alguna forma de exponer una API para obtener la lista de vistas que se encuentran actualmente en la ventana gráfica? La otra noche, estaba trabajando en la creación de una vista de video para incrustarla en una celda ListView y reproducir / pausar automáticamente según la visibilidad de la ventana gráfica, pero era casi imposible con los ItemAppearing y ItemDisappearing actuales ItemDisappearing especialmente cuando siguieron disparando de todo tipo de formas inesperadas con reciclaje de células y / o desplazamiento rápido. Tengo muchas ganas de que CollectionView admitan este tipo de funcionalidad de una manera más confiable.

Otra cosa que sería genial tener es la capacidad de crear una vista minimizada dependiente que se separe del padre mientras el usuario tiene el lujo de desplazarse por el feed actual. He visto esto en YouTube, ya que ahora podemos seguir viendo el video actual mientras tenemos la capacidad de seguir navegando. No estoy seguro de si esto es algo que CollectionView puede o debería admitir por cierto, pero es algo en lo que pensar.

Así que jugué un poco con la compilación nocturna actual (4.0.1.43780-nightly) que resolvió algunos problemas de cambio de tamaño en comparación con la compilación de vista previa actual.

Una sugerencia que tengo es agregar algo como RowSpacing / ColumnSpacing o GridSpacing a los diseños de cuadrícula, ya que eso hace que sea mucho más fácil espaciar sus elementos correctamente sin usar margen / relleno en los elementos individuales.
Otra cosa sería agregar Padding o tal vez EdgeOffset a CollectionView o Layout para evitar usar Margin, que corta los elementos como se muestra aquí:

El margen también recorta la animación de "arrastrar" en Android, como puede ver aquí:

Una sugerencia que tengo es agregar algo como RowSpacing / ColumnSpacing o GridSpacing a los diseños de cuadrícula, ya que eso hace que sea mucho más fácil espaciar sus elementos correctamente sin usar margen / relleno en los elementos individuales.

De acuerdo, y eso está en nuestro radar; consulte el n. ° 4681.

Actualización: de la lista de propuestas de nombres, lo más cercano que hemos encontrado es "ItemsView", esto es para evitar el uso del término "CollectionView" que da a la gente la impresión de que es tan completo como el "UICollectionView" de iOS

¿qué pasa con "FloatView"?

Además de los eventos de aparición / desaparición de artículos mencionados anteriormente, cualquier plan sobre las formas de obtener la vista de un artículo:
View GetView(object item)
Si el artículo no se materializa, debería devolver un valor nulo, supongo.

Estoy usando una lista vertical y parece haber inconstancias en cómo se representa en iOS frente a Android.

En iOS, con la etiqueta ocupará el 100% del ancho.

En Android, solo ocupará el ancho del contenido.

Solo pude hacer que se distribuyera correctamente con una definición de ancho estático.
¿Existe una solución alternativa de Android que respete la propiedad Grid Width="Auto" ?

Estoy usando una lista vertical y parece haber inconstancias en cómo se representa en iOS frente a Android.

@shwanton Por favor, abra una edición separada para este error y le echaré un vistazo.

@shwanton tuve problemas similares que se solucionaron cuando

@krdmllr Puedo confirmar, se ha corregido en la última versión. Gracias.

Hola. ¿Habrá un evento ItemTapped en CollectionView similar al ItemTapped de ListView? No lo veo en la especificación. Gracias.

@uvirra Hay un problema existente para su consulta DataTemplateSelector . Ver # 4826.

@hartez ¿Alguna vez habrá necesidad de una estrategia de reciclaje de artículos como las tres que existen por ListView ? Mencionaste varias veces la virtualización nativa que CollectionView aprovecha. Solo quiero obtener más aclaraciones sobre esto.

También tengo curiosidad por saber cómo se verá RefreshView en iOS. El repaso actual de ListView requiere UITableView 's Bounces propiedad para ser encendido mientras que, en Android, la vista de actualización se tira en la parte superior de la parte superior elemento más visible (que Yo personalmente prefiero).

@hartez ¿Alguna vez habrá necesidad de una estrategia de reciclaje de artículos como las tres que existen por ListView ? Mencionaste varias veces la virtualización nativa que CollectionView aprovecha. Solo quiero obtener más aclaraciones sobre esto.

El diseño actual no requiere nada parecido a una estrategia de reciclaje. En este momento, simplemente estamos utilizando la virtualización proporcionada por los controles nativos, que hacen un muy buen trabajo desde el primer momento.

¿Habrá alguna vez una necesidad? Mi esperanza es "no", y haremos todo lo posible para evitarlo porque agrega mucha complejidad (tanto para los usuarios como para el mantenimiento). Si finalmente llegamos a la conclusión de que necesitamos algo así, abordaremos el diseño con mucho, mucho cuidado.

¿Qué pasa con el evento desplazado? La mayoría de UI / UX modernas proporcionan encabezado de paralaje, mostrar / ocultar elementos (botones, encabezados, filtros, ecc ..) en el desplazamiento y similares.
Creo que un control nuevo y sorprendente como este debería admitir escenarios modernos.

no debería ser un problema, tanto recyclingview como UICollectionview admiten el evento desplazado de fábrica.

Incluso Carouselview (basado en collectionview) admite el evento desplazado con dirección, valor de desplazamiento y delta: https://github.com/xamarin/Xamarin.Forms/issues/4996

Para continuar con el comentario de @Evolutionlab sobre este nuevo y sorprendente control que debería admitir escenarios modernos, me gustaría ver un soporte de virtualización aún mejor.

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

Si esto es demasiado para comprender, me gustaría tener acceso a VisibleItems para poder hacer la virtualización en mi ViewModel.

¡Mantener el buen trabajo!

@hartez Estaba pensando que sería genial dejar que los desarrolladores definan un umbral mínimo / máximo en la cantidad de elementos seleccionados. Actualmente estoy creando una galería de fotos personalizada que no debería permitir que se seleccionen más de 5 fotos. Cuando se alcanza el umbral, los eventos de toque en las celdas deben ignorarse a menos que estén deseleccionando elementos.

Esto también se puede hacer configurando SelectedItems (que aún no se ha implementado) en el evento SelectionChanged basado en el recuento de CurrentSelection , pero esto va a activar SelectionChanged dos veces. En mi opinión, deberíamos tener una forma de controlar proactivamente el comportamiento de selección antes de que algo llegue al Core.

Jugando un poco con CollectionView hoy, noté que UWP está mucho más atrasado que Android e iOS, lo cual explica por qué.

¿Solo desea confirmar que se planea tener soporte completo para UWP cuando esté finalizado?

Además de los eventos de aparición / desaparición de artículos mencionados anteriormente, cualquier plan sobre las formas de obtener la vista de un artículo:
View GetView(object item)
Si el artículo no se materializa, debería devolver un valor nulo, supongo.

¿Qué pasa con ItemAppearing? No veo ninguna noticia al respecto

Estaba jugando con el CollectionView y tenía problemas con la altura desigual de las filas. Vi que había un ItemSizingStrategy introducido últimamente, pero todavía se comporta de manera extraña.

Jugué con el DataTemplateGallery y al cambiar a MeasureAllItems obtengo el siguiente resultado (iPhone 6, iOS 12.1.4):

Después de deslizar el dedo hacia la derecha y regresar, el resultado cambia a:

@hartez ¿Se espera que esto funcione o aún está en progreso (no se pudo encontrar ningún problema para eso)?

¿Se ha implementado RemainingItemsThresholdReached todavía?

No está disponible en el control XAML CollectionView en 4.0.0.169046-pre5.

¿Alguien puede decirme que RemainingItemsThresholdReached es parte de la versión 4.0? En caso afirmativo, ¿puede proporcionar un código de muestra sobre cómo utilizar esa función?

@Dresel ¿Puedes abrir un nuevo ticket si crees que se trata de un error? Es mejor si se rastrea.

@melucas @chandrubk No creo que se esté trabajando en RemainingItemsThresholdReached todavía.

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

A mí también me gustaría ver esta función (junto con la vista Actualizar) implementada pronto, ya que no puedo tocar CollectionView sin ella.

4323

Necesitamos el evento desplazado como lo hace ScrollView

Saludos,

4323

Necesitamos el evento desplazado como lo hace ScrollView

Saludos,

Yo apoyo esto.
Además, sería increíble obtener un evento cuando el desplazamiento se detenga / finalice.

En IOS, UICollectionview es una subclase de UIScrollview, por lo que podemos obtener scrollViewDidEndDecelerating de UIScrollViewDelegate

En Android, creo que podemos extender el RecyclerView.OnScrollListener ?

Esto abrirá escenarios más avanzados y pulidos para actualización personalizada, paralaje, elementos de desplazamiento sincronizados, etc.

¿Alguna posibilidad de que haya una animación lista para usar para Android, como la de Recycler View?

¿Alguna posibilidad de que haya una animación lista para usar para Android, como la de Recycler View?

¿A qué animaciones te refieres? El renderizador de Android para esto está construido en RecyclerView, por lo que ya usa las animaciones predeterminadas para cosas como agregar / eliminar elementos.

Hola,

Estoy usando 4.0.0.304370-pre8.
El ejemplo de (enlace a continuación) no muestra nada en UWP, cuando se usa CarouselView.
Pero CollectionView muestra la lista. ¿Se necesita alguna configuración específica para habilitar CarouselView para UWP?

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

Gracias.

Hola @noypi ,

Si bien CollectionView técnicamente puede "funcionar" en un grado bastante pequeño en UWP, la implementación completa de CollectionView y CarouselView se está realizando estrictamente en Android e iOS para empezar. No se ha programado ningún trabajo oficial para UWP en este momento, pero estamos recopilando comentarios continuamente. Si desea discutir qué tipo de trabajo está haciendo en UWP en particular, puede enviarme un correo electrónico a paul. [email protected].

De acuerdo con la especificación, ¿TableView será reemplazado por CollectionView por completo?

Otra pregunta: dado que ya no hay celdas, ¿cómo agregar un indicador de disclorure para iOS? Con ListView fue posible a través de un renderizador personalizado.

De acuerdo con la especificación, ¿TableView será reemplazado por CollectionView por completo?

TableView seguirá existiendo. No eliminaremos ningún control existente.

Otra pregunta: dado que ya no hay celdas, ¿cómo agregar un indicador de disclorure para iOS? Con ListView fue posible a través de un renderizador personalizado.

En iOS, CollectionView se renderiza utilizando UICollectionView, lo que significa que sus celdas son UICollectionViewCells. Y UICollectionViewCells no tiene vistas accesorias (como indicadores de divulgación). Por lo tanto, para cualquier elemento de la interfaz de usuario, como indicadores de divulgación o marcas de verificación, deberá crearlos en su ItemTemplate.

¿Cómo deshabilitar la selección en ciertos tipos de elementos? Tengo varias plantillas de datos y quiero deshabilitar la selección en algunas de ellas.

@hartez Al configurar ItemTemplate en DataTemplateSelector, obtengo una excepción: System.InvalidOperationException: LoadTemplate should not be null

Pensé que las plantillas serían compatibles desde el primer momento.

@hartez Al configurar ItemTemplate en DataTemplateSelector, obtengo una excepción: System.InvalidOperationException: LoadTemplate should not be null

Pensé que las plantillas serían compatibles desde el primer momento.

Ellos deberían ser; tal vez te encuentres con un error. Abra un problema para que podamos investigarlo.

@toomasz Antes de abrir un problema, ¿puede actualizar su Nuget a la versión preliminar más reciente (o la versión nocturna) y probar el selector nuevamente? El problema que está viendo estaba presente cuando no había soporte para DataTemplateSelector .

@hartez ¿ realizando algún trabajo en el encabezado y pie de página, así como en la vista de actualización? Si puedo liberar tiempo, podría mirar en cualquiera de los dos, pero quiero asegurarme de no pisarle los dedos de los pies.

@ adrianknight89 ¡Funciona en 4.0! Impresionante

@hartez ¿ realizando algún trabajo en el encabezado y pie de página, así como en la vista de actualización? Si puedo liberar tiempo, podría mirar en cualquiera de los dos, pero quiero asegurarme de no pisarle los dedos de los pies.

No se está haciendo nada en este momento; si quieres intentarlo, sería genial.
Solo un aviso, después de un poco de discusión hoy, hemos agregado dos nuevas propiedades relacionadas con el encabezado y el pie de página: IsHeaderSticky y IsFooterSticky , para especificar si se desplazan con los elementos o permanecen en su lugar. Si desea abordarlos junto con el encabezado / pie de página, sería genial, pero también sería genial si los tuviéramos funcionando de una forma u otra y pudiéramos implementar esas propiedades más adelante.

¿Existe un plan para admitir la vista de colección en UWP?

Si. La implementación está un poco por detrás de las otras plataformas en este momento, pero el plan es respaldarla por completo. Puede seguir el progreso de la función en https://gist.github.com/hartez/7d0edd4182dbc7de65cebc6c67f72e14

¿Alguna información sobre RefreshView?
Tengo la última versión beta de Xamarin 4 y no se puede encontrar el tipo RefreshView

¿Alguna información sobre RefreshView?
Tengo la última versión beta de Xamarin 4 y no se puede encontrar el tipo RefreshView

RefreshView aún no se ha implementado. Puede seguir el progreso de la función aquí .

¿Agregar GroupItemsBinding ?

¿Qué tal agregar una propiedad GroupItemsBinding para especificar qué propiedad contiene los elementos secundarios de un grupo? Eso permitiría incrustar una propiedad de colección secundaria en lugar de obligar a los grupos a heredar de una colección.

Ventajas:

• Capacidad para (des) serializar la colección agrupada a / desde JSON.
  La herencia de grupos de una colección bloquea la (des) serialización de JSON (porque las matrices JSON solo admiten un rango de valores y no propiedades). Se necesita (des) serializar modelos de vista para preservar el estado del modelo de vista cuando la aplicación pasa a segundo plano, o si la API de su aplicación le envía modelos de vista. La solución actual es tener una segunda estructura de datos y realizar una costosa duplicación + transformación en cada actualización de datos.
• Posibilidad de usar su propia clase base para elementos de grupo (por ejemplo, ViewModelBase )
• Evite contaminar los objetos de grupo con todas las propiedades heredadas de una colección

Por ejemplo, podría escribir este ejemplo de agrupación de docs.microsoft.com :
`` C #
PageTypeGroup de clase pública: Lista
{
Título de cadena pública {get; colocar; }
// Más propiedades ...
}

like this instead:

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

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

con XAML:

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

No especificar GroupItemsBinding sería compatible con la implementación existente, equivalente a GroupItemsBinding="{Binding .}"

PD: Presenté esta propuesta anteriormente, en julio de 2018 .

Actualización 23 de agosto de 2019: se implementó la agrupación pero sin esta corrección; ver datos del grupo

Espero que no sea demasiado tarde para agregar esto.

¿Qué tal si se admiten varios niveles de agrupación?
Permitiría mostrar árboles .

Por ejemplo, Flutter tiene ExpansionTile ( ejemplo )

Con respecto a CollectionView, me encontré con un problema que creo que sería una gran característica para agregar.

En una Lista Horizontal, con scroll, típicamente los diseñadores, agregan un efecto de "sombra" sobre los elementos que no son totalmente visibles en la pantalla. Actualmente (que yo sepa) no hay forma de hacer esto en Xamarin.Forms. ¿No pensarías que esto sería un niec para tener una función? Podría ser tan simple como un booleano, que aplicaría una "sombra paralela" al elemento que es visible solo en un porcentaje X, por ejemplo.

Propongo una propiedad de posición. Esta propiedad contendría el índice del elemento actual. Esto permitiría una fácil integración de ViewPagerIndicator e indicadores similares.

Entiendo que determinar el "elemento actual" puede ser complicado. Si el ajuste está activado, debería ser bastante fácil determinar a qué elemento se ajusta la vista. Sin ajustar, la elección correcta dependería del caso de uso: quizás sería el elemento que ocupa el inicio o el punto medio de la vista.

Esta propiedad también podría permitir un fácil acceso bidireccional como alternativa a ScrollTo ().

@hartez Esperábamos que esto estuviera listo para la versión 4.0, pero nos sorprendió ver que aún no está terminado. No podemos probar CollectionView sin la funcionalidad de desplazamiento y actualización. ¿Puede decirnos cuántos sprints debemos esperar antes de que se implementen? Hemos decidido no enviar nada con ListView en el futuro y nos gustaría que este control esté disponible lo antes posible.

@hartez Necesitamos una forma para que CollectionView con diseño de lista se

En este ejemplo, los botones deben estar directamente debajo de la vista de colección. Creo que debería funcionar de esta manera cuando VerticalOptions es Start

cuando el umbral de elementos restantes alcanzó la prueba de propiedad

Tengo preguntas sobre si el flujo de CollectionView de un comportamiento de elemento individual imita el comportamiento nativo de iOS cuando se trata de cambios en el tamaño de la pantalla. Te daré un ejemplo:

Se crea una celda de la galería de imágenes en iOS con CollectionView y usted define una celda individual. El comportamiento listo para usar es que la cantidad de celdas que se dibujan en una sola fila es dinámica en función del tamaño de la pantalla. En un teléfono podría caber 4 artículos, pero en una tableta podría caber quizás 8 o 9.

¿La versión Forms también ofrecerá esto? Hasta ahora, el ejemplo que he leído solo he visto dónde establece la propiedad GridItemsLayout Span. Esto da como resultado un valor codificado de la cantidad de elementos que se pueden dibujar y, en realidad, en el mundo de varios tamaños de pantalla, la codificación dura parece tan 2014. :-P

UWP tiene cuatro estados de modo de selección
{
Ninguna,
Único
Múltiple,
Ampliar,
}

Creo que cuatro estados en Android e IOS también son útiles
Solo eche un vistazo al Explorador de archivos

¿Hay planes para una propiedad de relleno simple? # 6605 Para mi caso de uso particular, probablemente podría usar un encabezado y pie de página en blanco del tamaño adecuado (una vez que se hayan desarrollado esas características), pero eso sería un poco complicado y no adecuado para un diseño de cuadrícula donde el relleno en los cuatro lados puede ser requerido.

Cualquier plan para reorganizar el elemento de la lista en la vista de colección.

¿La especificación cubre cómo deshabilitar la selección para elementos particulares en CollectionView?

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

Actualmente lo soluciono, pero esto no impide que se aplique el VisualState seleccionado.

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

¡El color de la barra de desplazamiento vertical y el color de la barra de desplazamiento horizontal serían geniales!

¿Qué pasa con la dirección de desplazamiento? Me refiero a empezar a desplazarse de derecha a izquierda, no al contenido en sí.

Me gustaría tener separadores ...

Sería genial tener la posibilidad de "memorizar" y aplicar la posición de desplazamiento.

Lo que sería tan sorprendente sería la posibilidad de usar diferentes plantillas de elementos para cada segundo o X elemento. Esto permitiría crear un fondo gris para cada segundo elemento y muchas otras posibilidades de estilo.

¿No puedes hacer eso con el selector de plantillas ya? Usando posición con
operador de módulo?

El martes 13 de agosto de 2019 a las 16:53, Legacyorder [email protected] escribió:

Lo que sería tan asombroso, sería la posibilidad de usar diferentes elementos
plantillas para cada segundo o X elemento. Esto permitiría crear
un fondo gris para cada segundo elemento y muchos otros estilos
posibilidades.

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/xamarin/Xamarin .
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AC4YCKHXX5YSR7M3S4VU5QLQELDE3ANCNFSM4FHJRXPA
.

Desplazamiento circular sería bueno. Supongo que es fácil de implementar.

Me gustaría tener un "AbsoluteItemsLayout" como ItemsLayout para CollectionView para que sea posible establecer posiciones absolutas en una lista, por el momento no veo otra solución en lugar de hacerlo en el código subyacente.

¿Es posible, cuando se usa GridItemsLayout, permitir que los elementos se distribuyan en varias filas o columnas? Definitivamente sería una característica que valdría la pena tener.

¿Pueden ustedes también exponer el evento Scrolled a este control? El propósito de eso es que cuando llegue al final de la lista, quiero volver a cargar elementos adicionales. No sé si CollectionView detecta si está dentro de ScrollView y deshabilita la capacidad de desplazamiento.

¿Pueden ustedes también exponer el evento Scrolled a este control? El propósito de eso es que cuando llegue al final de la lista, quiero volver a cargar elementos adicionales. No sé si CollectionView detecta si está dentro de ScrollView y deshabilita la capacidad de desplazamiento.

¡Tu deseo es concedido! Verifique la versión 4.2 :)
https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/collectionview/scrolling

No debe incluir un CollectionView dentro de un ScrollView, o la virtualización no funcionará.

¿Pueden ustedes también exponer el evento Scrolled a este control? El propósito de eso es que cuando llegue al final de la lista, quiero volver a cargar elementos adicionales. No sé si CollectionView detecta si está dentro de ScrollView y deshabilita la capacidad de desplazamiento.

¡Tu deseo es concedido! Verifique la versión 4.2 :)
https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/collectionview/scrolling

No debe incluir un CollectionView dentro de un ScrollView, o la virtualización no funcionará.

Estoy en 4.2.0.709249
¿Me estoy perdiendo de algo?

Tengo el evento Scrolled con 4.2.0.709249.
Intente eliminar las carpetas bin / obj y verifique la consolidación de NuGet para asegurarse.

¿Tendremos soporte RTL pronto con 4.2 para Android e iOS?

¿Tendremos soporte RTL pronto con 4.2 para Android e iOS?

Ya hay algo de apoyo; La compatibilidad con FlowDirection ya debería estar funcionando dentro de los elementos de CollectionView. Lo que todavía está incompleto es la dirección de desplazamiento para los diseños de CollectionView horizontales. La dirección de desplazamiento debería coincidir con FlowDirection en Android, pero todavía tenemos trabajo por hacer en eso para las otras plataformas; ese trabajo está previsto para completarse en 4.3.

Si encuentra algún error al usar FlowDirection con CollectionView, abra un problema y lo revisaremos.

¿Puede describir lo que no se hace con el soporte RTL?
Porque en las especificaciones, ni siquiera está marcado como en progreso o completo.

El jueves 5 de septiembre de 2019 a las 2:19 am, EZ Hart, [email protected] escribió:

¿Tendremos soporte RTL pronto con 4.2 para Android e iOS?

Ya hay algo de apoyo; El soporte de FlowDirection ya debería ser
trabajando dentro de los elementos CollectionView. Lo que todavía está incompleto es el pergamino
dirección para diseños de CollectionView horizontales. La dirección de desplazamiento
debería coincidir con FlowDirection en Android, pero todavía tenemos algo de trabajo para
haz eso para las otras plataformas.

Si encuentra algún error al usar FlowDirection con CollectionView,
por favor abra un problema y le echaremos un vistazo.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/xamarin/Xamarin .
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ACDWB3HMFCHBRZWD5AJMXH3QIANMNANCNFSM4FHJRXPA
.

No hecho: dirección de desplazamiento para diseños horizontales.

Si configura FlowDirection = RightToLeft en un CollectionView de desplazamiento horizontal, la dirección de desplazamiento no será de derecha a izquierda en iOS y UWP en este momento (creo que _funciona_ en Android).

¿Qué tal un LoadingDataTemplate?

Según mi experiencia, al cargar datos de forma asíncrona en ListView / CollectionView, a veces puede haber un espacio vacío hasta que se complete la vista de lista / vista de colección.

Agregar LoadingDataTemplate puede proporcionar una capacidad de respuesta adicional cuando se llenan grandes datos y la página ya ha aparecido.

Creo que hay dos formas de utilizar un indicador de carga. Uno es cuando se muestra inicialmente CollectionView . Se muestran varias celdas de marcador de posición hasta que los datos se agregan a la colección ItemsSource . El segundo es cuando se agregan más datos al final de la lista. Para el segundo, creo que podemos aprovechar el pie de página.

El primero requiere más trabajo (por ejemplo, cargue inicialmente la fuente con 3-5 elementos que tengan la misma plantilla de datos de marcador de posición y luego elimine esos elementos y agregue los datos reales cuando se recuperen). Otro enfoque es colocar una vista esquemática encima de CollectionView y ocultarla cuando los datos estén listos. Actualmente sigo este enfoque con ListView .

No he probado esto, pero podríamos configurar EmptyView en la vista de carga primero y si no hay resultados, cambiar la plantilla para que EmptyView muestre un mensaje de "nada encontrado".

@ adrianknight89

Otro enfoque es poner una vista esquemática encima de CollectionView y ocultarla cuando los datos estén listos. Actualmente sigo este enfoque con ListView .

Esto suena como el mismo método que sigo también, es decir, poner un indicador de actividad arriba. Establezca ListView en IsVisible = false y ActivityIndicator IsVisible = true, luego invierta ambos valores después de completar la vista de lista.

@ adrianknight89

No he intentado esto, pero podríamos configurar EmptyView en la vista de carga primero y si no hay resultados, cambiar la plantilla para que EmptyView muestre un mensaje de "nada encontrado".

¡Hay una idea! Si bien eso podría funcionar, creo que sería mejor simplificar tener propiedades de plantilla separadas en CollectionView con respecto a LoadingDataTemplate y EmptyView.

Estoy de acuerdo en que sería mejor tener dos propiedades diferentes. Aparte del aspecto de la simplicidad, usar una sola propiedad para dos propósitos diferentes no tiene mucho sentido. Quizás EmptyView debería haber sido nombrado BackgroundView para que podamos usarlo para cualquier propósito. (Editar: A BackgroundView es algo completamente diferente).

@LeoJHarris Agregué # 7447 por BackgroundView soporte. Podríamos usar EmptyView y BackgroundView para admitir los dos escenarios anteriores, aunque esto todavía no es 100% lo que desea, pero debería ser mejor que usar EmptyView para admitir ambos escenarios. Puede usar BackgroundView como pantalla de carga y anularla cuando los datos estén listos.

@ adrianknight89 sería genial si CollectionView manejara el '

Al desplazarse rápidamente por una página que utiliza RemainingItemsThreshold de CollectionView, estamos experimentando dos problemas diferentes.

1. La aplicación se congela y se debe forzar su cierre.
2. Los elementos de CollectionView se apilan uno encima del otro (ver imagen )

No he podido encontrar a nadie más que tenga este problema. ¿Lo has visto reportado?

@ Bronson15 ¿Cómo está manejando el evento RemainingItemsThresholdReached ? El desplazamiento rápido lo activará varias veces, por lo que debe ignorar las llamadas de eventos mientras espera actualizar su fuente de datos, de lo contrario, se acumularán. Además, intente actualizar su interfaz de usuario en el hilo principal.

Si sigues teniendo problemas, puedes abrir un nuevo problema con una reproducción para investigar.

@ Bronson15 ambos números.
Intenté con ObservableRangeCollection y se corrigió # 2.
Todavía tengo problemas con las congelaciones / lista en blanco: cuando se ejecuta en el emulador, veo un pico de cpu, parece un bucle infinito.

Editar: solo se rompe en iOS, en Android funciona bien.

Hola equipo,
Incluso intenté usar RemainingItemsThreshold y RemainingItemsThresholdReachedCommand y noté que la función asignada a RemainingItemsThresholdReachedCommand se llama varias veces secuencialmente (la primera vez se llama dos veces, la próxima vez 4 veces, etc.) incluso si no me desplazo rápidamente. También puedo reproducirlo con un proyecto nuevo de Xamarin Forms (v.4.2.0.778463).
¿Puedes intentar reproducirlo al final? Aquí está el fragmento de código simple a continuación:

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>

Ver modelo:

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 Dado que no RemainingItemsThresholdReachedCommand , es normal seguir presionando el comando varias veces debido a sus patrones de desplazamiento. Vea cómo manejo el problema con un mecanismo de bloqueo: https://github.com/xamarin/Xamarin.Forms/pull/7516/files#diff -2be3eff4d53f761cd581cca1d2ec3bc0R48

Otras formas de hacer esto son habilitar / deshabilitar su comando o cancelar la suscripción / suscripción del evento mientras se realiza la búsqueda remota. En mi experiencia, tener un semáforo funcionó mejor porque a veces se activan múltiples invocaciones en el momento en que intenta habilitar / deshabilitar o cancelar / suscribir la devolución de llamada.

@hartez @samhouts @davidortinau Creo que este problema surgirá con bastante frecuencia en el futuro. ¿Debería la sugerencia anterior formar parte de la documentación para los elementos restantes? Haría que el equipo de documentación creara una fuente remota para realizar pruebas y recomendaría un patrón de codificación como referencia para que la gente no siguiera pidiendo ayuda.

@techduggu Hay diferentes problemas (menores) con su código. Lo revisaría con el código en Stack Exchange. Este no es el lugar para eso ahora.

@ adrianknight89 Gracias por destacar el término "debido a sus patrones de desplazamiento". Esto desencadenó mi inquietud por encontrar más información al respecto. Después de revisar la documentación oficial de RecyclerView y algunos otros recursos, Sí, puedo confirmar que se llama varias veces debido a patrones de desplazamiento y esos patrones son SCROLL_STATE_IDLE, SCROLL_STATE_DRAGGING o SCROLL_STATE_SETTLING dependiendo de nuestro estado de desplazamiento.
https://developer.android.com/reference/android/support/v7/widget/RecyclerView.OnScrollListener

Su código y esta guía de Android (https://github.com/codepath/android_guides/wiki/Endless-Scrolling-with-AdapterViews-and-RecyclerView) también confirma lo mismo que deberíamos manejar el desplazamiento infinito ya sea mediante bloqueo o haciendo uso de los estados de desplazamiento anteriores (que en su mayoría requieren un renderizador personalizado). Por lo tanto, con Xamarin.Forms, probé su código y funcionó a la perfección. :) Recomendaría y apoyaría su opinión para incluir esta sugerencia como parte de los documentos para evitar los problemas planteados por personas (con medio conocimiento) como yo. :)

Además, reg. los problemas menores que mencionó para el fragmento de código anterior: bueno, este es solo un proyecto de POC para probar la carga infinita con la vista de colección, sin embargo, me encantaría saber su entrada si ha notado algo además de una verificación nula tonta, etc.

¡Gracias!

@ adrianknight89 Ah, sí. Faltaba nuestro cheque de Ocupado y eso ayudó con el problema de apilamiento.

También implementé el semáforo como sugirió y parece haber mitigado un problema en el que al agregar nuevos elementos a ItemsSource, la vista restablecía la posición de desplazamiento al principio. Curiosamente, agregando la llamada en un intento; por fin; como hiciste en tu archivo de prueba, este problema volvió a aparecer.

Todavía tengo un problema de congelación al desplazarse hasta el final de la lista. La vista se queda en blanco y la aplicación se congela.

Editar: el restablecimiento de la posición de desplazamiento sigue estando ahí, pero no con tanta frecuencia. La representación de cargar más elementos también es muy entrecortada en el dispositivo.

@techduggu No tengo VS conmigo, pero solo mirando el código, deberías esperar RemainingStories() , mover la llamada remota dentro del intento y usar un uso para HttpClient (idealmente usa una sola instancia estática en su aplicación y nunca la deseche), pero me detendré aquí. :)

@ Bronson15 Hubo un problema con CollectionView que restableció la posición de desplazamiento y provocó que la interfaz de usuario se congelara. Creo que se solucionó con el # 7285, pero eso es solo para iOS. ¿Puedes probar el último Nuget nocturno y ver si todavía tienes problemas? La URL del feed nocturno está en la página de inicio de GitHub para Formularios. Si el problema persiste, abre un problema con el código de reproducción para que podamos echarle un vistazo.

@ adrianknight89 Desplazarse con la compilación nocturna. Parece que el problema está resuelto en su mayor parte (vi que sucedió una vez). Sin embargo, parece que la lista está en un bucle sin fin ahora, en lugar de tener un final. AFAIK, ¿no hay propiedad en la especificación para evitar que eso suceda?

@ Bronson15 El bucle sin fin no debería ocurrir. ¿Lo ves en iOS o Android? Debe finalizar el ciclo cuando llegue al final de su alimentación remota (es decir, regresar desde RemainingItemsThresholdReachedCommand inmediatamente sin emitir otra llamada DB).

Una vez que se detiene el desplazamiento de la vista, el comando ya no debería activarse. Utilizo Azure Cosmos que devuelve un token de continuación. Cuando el token es nulo, sé que no hay más contenido para cargar, por lo que mi RemainingItemsThresholdReachedCommand funciona en función de ese token. Deberías implementar algo similar.

@ adrianknight89 Ahhh. Interesante. Se agregó una verificación para el recuento de resultados y la devolución si es 0. Se corrigió el desplazamiento infinito. ¡Gracias por la ayuda!

@ adrianknight89 probado casi por problemas de bloqueo de iOS, finalmente funciona. sigue siendo "mucho" más lento que Android.
con 1000 elementos en Android es casi en tiempo real, en iOS hay que esperar de 5 a 7 segundos para que se renderice la vista. ambos debug, iPhone Xs y Redmi Note 7

@andreabalducci ¿Estás en el simulador XS? ¿Cómo es el comportamiento en un dispositivo físico? Si el procesamiento de la vista es lento, este puede ser otro problema con iOS que debe investigarse. Una vez más, sería genial ver una reproducción.

@ adrianknight89 @andreabalducci sí, se necesitan entre 1 y 5 segundos en mi Xs Max para cargar más elementos. La vista borra y vuelve a cargar todos los elementos en lugar de agregar elementos a la lista ya renderizada.

@ adrianknight89 ambos dispositivos físicos, el emulador de iOS tiene los mismos problemas.

Eliminamos todo el diseño de pila de las plantillas de datos y obtuvimos algo de velocidad en el cambio a FormattedString, habilitamos los enlaces compilados, antes de que iOS durara más de 20 segundos.

En iOS, la vista se oscurece y se vuelve a dibujar todo al agregar ObservableRangeCollection (de los ayudantes de mvvm), en Android funciona bien.

Esto me suena a un tema aparte. No creo que estén relacionados los elementos restantes.

¿Es posible, cuando se usa GridItemsLayout, permitir que los elementos se distribuyan en varias filas o columnas? Definitivamente sería una característica que valdría la pena tener.

¿Alguna información sobre esto?

@LynoDesu Se está https://github.com/xamarin/Xamarin.Forms/issues/6357

@LynoDesu Se está

¡Ah, genial! Gracias. ¿Por dónde empiezo si quiero contribuir a esto?

Lea la wiki de la página de inicio y Contributing.md .

@ adrianknight89 encontró el espacio en blanco + volver a empezar, reprodúzcalo aquí https://github.com/andreabalducci/XamarinCollectionView/blob/b186e563ff8391dfb473e62e5a4c4587e8d4e9da/cvrepro/cvrepro/ListViewModel.cs#L46

Comenzar con una colección vacía desencadena el problema, si la colección tiene algún elemento antes de vincular todo funciona como se esperaba.

probado en el emulador de iPhone.

Veo el problema. Probablemente sea lo mismo que el # 7548. Es posible que desee publicar su repro allí.

CollectionView parece tener errores en Android cuando se usa IsGrouped.

CollectionView.GroupHeaderTemplate no se procesa en absoluto. En iOS funciona bien. Puede usar el ejemplo de agrupación del sitio de Microsoft para probarlo.

    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

Importante

La agrupación de datos con CollectionView actualmente solo se admite en iOS.

Ops, me perdí esa parte. Gracias.

Para aquellos de nosotros que queremos mostrar una lista agrupada tanto en iOS como en Android, pero queremos evitar ListView, ¿hay algo más que podamos usar que sea tan flexible como CollectionView por ahora? ¿O estamos atrapados con ListView?

Espero que este sea el lugar adecuado para preguntar. Veo que en la especificación publicada original hay propiedades para IsHeaderSticky y IsFooterSticky , pero no veo ninguna mención adicional de ellas en ninguna parte de la discusión o el código fuente implementado. ¿Están todavía en la hoja de ruta para esta vista?

En vista de colección necesitamos ItemAppeared, ITemDisappeared.
¿Hay alguna forma de lograrlo?

@IosDeveloperHarsh El Scrolled proporciona mucha información útil en los argumentos del evento. Mire el primer y último índice de elementos visibles allí.

@ rafiwardak2003 Las muestras de la galería con grupos CollectionView funcionan en Android a partir de hoy, aunque no he ejecutado la muestra que proporcionaste. ¿Qué Nuget estabas usando? Prueba con el último lanzamiento previo o todas las noches.

@ cabal95 No estoy calificado para responder esto, pero si tuviera que adivinar, eventualmente se implementarán. Quizás, necesitamos tener un problema activo para rastrear esto. Sé que el trabajo inicial de encabezado / pie de página excluyó las cosas pegajosas.

Creo que SelectionChangedCommandParameter debería eliminarse y, en su lugar, tendremos el elemento seleccionado configurado automáticamente como parámetro.

Si es posible, sería bueno usar la propiedad de esta manera.

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

Pero esto también debería estar bien:

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

Creo que SelectionChangedCommandParameter debería eliminarse y, en su lugar, tendremos el elemento seleccionado configurado automáticamente como parámetro.

Si es posible, sería bueno usar la propiedad de esta manera.

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

Pero esto también debería estar bien:

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

¿Qué pasa si el usuario quiere usar algo que no sea SelectedItem como parámetro para su comando?

Creo que SelectionChangedCommandParameter debería eliminarse y, en su lugar, tendremos el elemento seleccionado configurado automáticamente como parámetro.
Si es posible, sería bueno usar la propiedad de esta manera.
public ICommand => new Command<MySelectedItemModel>((item) => {}
Pero esto también debería estar bien:
public ICommand => new Command<object>((item) =>{ var selectedItem = item as MySelectedItemModel;}

¿Qué pasa si el usuario quiere usar algo que no sea SelectedItem como parámetro para su comando?

Tiene un punto, pero es difícil ver un caso de uso para eso porque está configurando el parámetro en el nivel CollectionView. Esperaba que fuera el elemento seleccionado la primera vez que lo usé. ¿Pero tal vez puedas configurar el elemento seleccionado como predeterminado? Si usa el evento, lo obtendrá, así que creo que muchos desarrolladores también lo esperan para el comando.

También me gustaría solicitar una función para que este CollectionView no se extienda en toda la pantalla y solo use la altura según la cantidad de elemento.

Estoy tratando de tener varias listas a la vista.
es decir
Compras

Deducciones

Total
total
nene

pero los elementos 1 y 2 (una vista de colección) simplemente tomaron demasiada altura, incluso si solo tengo 3 o 4 elementos y hay un espacio BIIIIIIIIIIIIIIIG debajo antes de que pueda ver la sección de deducciones

Terminé haciendo mi propio control de ItemsCollection basado en StackLayout

También me gustaría solicitar una función para que este CollectionView no se extienda en toda la pantalla y solo use la altura según la cantidad de elemento.
Terminé haciendo mi propio control de ItemsCollection basado en StackLayout

Creo que lo que está buscando pueden ser diseños enlazables .

También me gustaría solicitar una función para que este CollectionView no se extienda en toda la pantalla y solo use la altura según la cantidad de elemento.
Terminé haciendo mi propio control de ItemsCollection basado en StackLayout

Creo que lo que está buscando pueden ser diseños enlazables .

¡Oye! Exactamente lo que necesito. ¿Desde cuando existió BindableLayouts?

¡Gracias a todos por la discusión sobre este tema! Si tiene solicitudes de funciones adicionales o informes de errores, abra nuevos problemas para cada uno. Ahora cerramos este tema.