Que tal evento de rolagem para suportar cabeçalhos de paralaxe

Há muito o que amar sobre isso.

FontIconSource

Para FontIconSource, embora realmente precisemos de uma maneira de não usar o valor Unicode (se não quisermos). Se você está olhando para um FontIconSource com um valor f370 você não tem nenhuma pista do que isso deveria ser.

Por outro lado, se eu puder escolher quais fontes do ícone estou usando e fornecer ao Formulários uma maneira de converter fa-app-store-ios em seu equivalente unicode de f370 , agora posso saber rapidamente que o ícone que estou usando é do Font Awesome e é o ícone da App Store do iOS. De forma alguma estou dizendo que o Formulários deve ter essa compreensão para cada fonte disponível incluída (ou qualquer outra), que pode vir de alguns pontos públicos ou ser adicionada ao Kit de ferramentas da comunidade, etc. De qualquer maneira, precisamos de um maneira de usar nomes significativos.

Por último, espero que possamos criar uma extensão XAML para isso, para que você possa ter algo como:

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

Menus

Como eu estava discutindo com @davidortinau anteriormente, seria particularmente ideal se pudéssemos misturar e combinar os menus de contexto para obter os resultados apropriados. Um bom contexto sobre isso seria pensar em um cliente de e-mail no qual você pode obter um menu ao deslizar para a esquerda e outro ao deslizar para a direita. Outro cenário que eu adoraria ver suportado seria a abordagem do menu de células, como mostrado nos documentos do iOS CollectionView .

Eventos

Acho que é seguro dizer que sou tendencioso, mas uma grande parte da comunidade está seguindo um padrão de design MVVM. Ter os eventos SelectionChanged & RemainingItemsThresholdReached são importantes para a API, mas seria fantástico se pudéssemos encontrar uma maneira de oferecer suporte a esses OOB com uma versão ViewModel de um manipulador de eventos ... um Eu mando.

Como RemainingItemsThresholdReached apenas envia um antigo EventArgs, acho que podemos assumir com segurança que passar null para o comando deve ser adequado, pois só precisamos executar o comando. Para o SelectionChanged, eu tenderia a pensar que seria mais vital conhecer os novos itens, em vez dos itens antigos, então simplesmente passar os novos itens OOB para um SelectionChangedCommand deve ser suficiente. Isso pode não atingir todos os casos de uso, mas pelo menos fornece uma quantidade mínima de sobrecarga que um desenvolvedor precisa adicionar com algum EventToCommandBehavior.

A amostra perfeita que mata a exibição de lista atual é fazer o controle do Calendário onde:
-days (células) podem ter muitos estilos:
como dia da promoção, aniversário, desativado / dia sem venda / feriado ...
ícones incorporados com diferentes fontes personalizadas, a célula tem sombras se selecionada, outro estilo quando em r
raiva, outro quando no início e no final do intervalo
-selecionar fúrias de encontro é possível
cabeçalho de mês e estilo de cabeçalho personalizado
- cabeçalhos de meses têm botões que permitem algumas visualizações / ações / exibições especiais no mês atual

Que tal adicionar um GroupFooterTemplate?

Isso é muito necessário no Forms :-) CollectionView eliminaria soluções dispendiosas, resolveria limitações e provavelmente melhoraria o desempenho em quase todos os aplicativos de Formulários que fiz nos últimos 5 anos. Também é exatamente a abordagem certa - aproveite e exponha o poder das plataformas nativas.

Se houvesse apenas UM aprimoramento que eu pudesse solicitar para o Formulários, seria esse.
(na verdade, fiz isso em 2017 em resposta a @davidortinau)

Isso é realmente incrível e muito esperado! A API é limpa e direta (obrigado por renomear HasUnevenRows!).

Os eventos de rolagem são muito necessários, conforme sugerido por @dhaligas. Para animações de paralaxe, mas também para ocultar o botão de ação flutuante durante a rolagem, por exemplo.

FontIconSource é uma boa ideia. Pode ser ótimo fornecer uma lista padrão de ícones, com unicode mapeado para cada plataforma (semelhante ao iOS ou UWP).

Isso soa exatamente como é necessário. A API parece muito mais limpa, ter várias visualizações / contêineres estruturados dessa forma deve ajudar a manter o código mais limpo e simples.

Meus comentários até agora:

@dansiegel Um comando quando o Limite de Itens Remanescentes for atingido seria bem-vindo. No entanto, não tenho certeza se é necessário para SelectedItems - tudo o que você disser (notificado das alterações, o que mudou e até por quê) é tratado automaticamente, desde que SelectedItems seja um ObservableCollection (ou qualquer coisa que implemente INotifyCollectionChanged). Eu prefiro ter o mínimo de código possível em CollectionView para manter a complexidade baixa.

Rolagem: concordo totalmente com o evento de rolagem. Podemos obtê-lo no momento para o Android, mas para o iOS, você precisa envolver o UITableViewSource e sequestrar o método Scrolled.

O mais importante de tudo para mim seria a extensibilidade. Não use classes internas para adaptadores e TableViewSources e, nos renderizadores nativos, exponha os métodos "CreateAdapter" e "CreateViewSource" (e semelhantes para outras plataformas) onde podemos criar nosso próprio tipo se quisermos. Temos um ListAdapter personalizado para suporte de arrastar e soltar no Android e, como mencionado antes, um UITableViewSources personalizado para rolar e arrastar e soltar. Não é um código que eu goste porque há empacotamento de classes internas etc.

Isso não se aplica apenas a adaptadores / viewsources. Em geral, na nova API, adicione pontos onde podemos estender o comportamento, se necessário.

Acho que esse é um recurso realmente ótimo e importante!
O iOS já está usando o nome UICollectionView, o que pode causar confusão e resultados incorretos no Google ao pesquisar por CollectionView. Isso é um problema?

Só para tirar isso do caminho, eu amo basicamente tudo sobre CollectionView spec. Pode valer a pena dividir algumas das coisas em questões diferentes, já que tenho pensamentos sobre elas, como tenho certeza de que muitos outros fazem e posso ver as conversas ficando difíceis de acompanhar. Por exemplo:

Isso pode ser adicionado mais tarde, mas algo como:

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

seria útil para oferecer suporte a ícones de empilhamento: https://fontawesome.com/how-to-use/on-the-web/styling/stacking-icons

Meu feedback:

1. Eu não colocaria os recursos de seleção de item na classe CollectionView. Em vez disso, eu adicionaria uma classe base abstrata ListCollectionView derivada de CollectionView que tem recursos específicos:

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

Minha ideia é ter um CollectionView semelhante ao ItemsControl no Windows XAML. O ItemsControl usa uma instância de Panel que posiciona os itens. No Forms, teremos CollectionView e IItemsLayout.
Por padrão, se nenhum IItemLayout for fornecido, o layout padrão pode ser um layout de pilha. Dessa forma, poderíamos basicamente ter ItemsSource combinado com StackPanel do Windows XAML, ou em outras palavras, um StackLayout vinculável!

Ao lado da seleção do item, existem outros recursos que eu não colocaria no CollectionView, mas os adicionaria ao ListCollectionView. Por exemplo, o CollectionView não deve ter rolagem. Desta forma, ele irá cobrir este tópico

1. Eu renomearia a interface IItemsLayout para ICollectionViewLayout. O framework já possui Layout e ItemsView . Seria um nome mais longo, mas ICollectionViewLayout é uma forte indicação para que serve, é específico para CollectionView, não uma forma geral de exibir itens.

2. Eu renomearia a classe ItemsLayout para OrientedCollectionViewLayout. É uma forte indicação para que realmente serve a classe base abstrata, todas as classes derivadas fazem o layout dos itens de maneira orientada. Além disso, o uso de "Oriented" no nome oferece a opção no futuro de adicionar uma classe base abstrata chamada apenas "CollectionViewLayout". se alguma nova funcionalidade comum for necessária para todas as classes de layout de visualização de coleção, não apenas para aquelas que possuem orientação.

3. Remover ViewCell e apenas usar DataTemplate é muito bem-vindo, pois melhora a capacidade de reutilização.

1. Você pode compartilhar mais detalhes sobre RefreshView?
   Presumo que RefreshView de alguma forma deve mapear para UIRefreshControl no iOS? Como funcionará no Android e UWP?

Caso alguém esteja interessado, fiz algumas atualizações no meu primeiro comentário acima.

Eu concordo com @andreinitescu que seria bom ter uma maneira de ter uma coleção sem rolagem. Eu sou neutro se isso significa dividi-lo em várias classes ou possivelmente ter algo como uma propriedade ScrollMode. Vou adiar para aqueles com muito mais experiência em design de API do que eu nisso. Mas é bastante trivial implementar sua própria lista de itens baseada em StackLayout com um DataTemplate ou seletor de modelo, então talvez não seja necessário.

Embora eu goste da ideia de controlar a função de rolagem, também não estou apresentando nenhum caso de uso convincente para uma "Coleção" sem rolagem que inclua todos os recursos avançados de ListView ou a CollectionView proposta logo de cara. Meu caso de uso para uma lista não rolável sempre foi resolvido pela lista de itens triviais. Meu motivo normal para não usar um ListView é porque não quero a seleção ou quero fazer o layout da lista horizontalmente. Ambos os casos pareciam estar cobertos pela especificação proposta. Eu estaria interessado em qualquer exemplo de uso que outra pessoa tenha para nenhum pergaminho.

@bmacombe Concordo com você que é "simples" implementar um StackLayout vinculável, mas acho que não é esse o ponto. É uma funcionalidade muito comum, por que não tê-la no framework? E com algum planejamento, acho que pode ser feito. Como já disse acima, isso pode ser resolvido apenas espalhando a funcionalidade em duas classes, uma classe base (semelhante ao ItemsControl no Windows XAML) e CollectionView (ListView). O ideal é que haja uma classe Selector na hierarquia (consulte https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.controls.primitives.selector)

Eu diria que a razão trivial para ter uma opção sem rolagem é que algumas páginas precisam ter um ScrollView para a página inteira e uma lista de itens.

Se você fizer isso, agora não é recomendado colocar um ListView em um ScrollView. Um CollectionView vinculável que você poderia colocar lá, que ainda tem potencialmente todos os recursos de um ListView, é algo que precisei várias vezes.

Eu escrevi o mesmo BindableStack que todo mundo faz, mas um cozido em um seria muito mais agradável de se trabalhar.

@adammeaney Isso faz sentido e eu fiz o mesmo agora que penso sobre isso.

@andreinitescu Não discordo, seria ótimo tê-lo integrado. Acho que todos estão na mesma página para o que é necessário, apenas como fazer da melhor forma. Estou bem com qualquer uma das abordagens, desde que haja uma opção "sem rolagem" de algum tipo.

Em meus próprios frameworks, eu sempre vou e voltarei na construção de muitos recursos em um controle ou tenho muitas classes semelhantes com funções incrementais. Serei bom se a equipe de formulários decidir implementá-lo da melhor maneira, especialmente considerando as implementações de plataforma subjacentes.

@bmacombe Com algum planejamento, espero conseguir dois coelhos com uma cajadada só.
Por exemplo, uma instância da classe CollectionView funcionando da maneira que mencionei, se não tiver um conjunto IItemLayout, ela pode ser mapeada pelo mecanismo de renderização para um UIStackView nativo no iOS ou StackPanel no UWP ou LinearLayout no Android. Ou, para ser mais fácil de implementar, ele poderia apenas usar o StackLayout existente para organizar as visualizações.

Minha impressão era que um novo ListView deveria ter como objetivo corrigir os desafios do ListView existente, mas também fornecer uma solução para o thread "RepeatableBinder" aqui

Queremos ver onde o ListView2 chega antes de levar essa especificação adiante. Ele contém muitos dos mesmos componentes necessários e seria melhor evitar sua duplicação.

Não vejo como colocar toda a funcionalidade em CollectionView, como a especificação aqui sugere, faria o trabalho certo.

2680 Pode ser adicionado a esta especificação? Com relação à ativação do ScrollBar.

@andreinitescu

Você pode compartilhar mais detalhes sobre RefreshView?
Presumo que RefreshView de alguma forma deve mapear para UIRefreshControl no iOS? Como funcionará no Android e UWP?

No UWP, provavelmente usaremos RefreshContainer . No Android, provavelmente SwipeRefreshLayout .

@krdmllr

O iOS já está usando o nome UICollectionView, o que pode causar confusão e resultados incorretos no Google ao pesquisar por CollectionView. Isso é um problema?

É um problema, mas não é novo. Temos o mesmo problema com GestureRecognizer, ListView, Grid e muitas outras coisas no Forms. Lutamos um pouco com isso internamente; existem tantos nomes possíveis para "um monte de itens em uma tela".

"CollectionView" não entra em conflito com nada que temos atualmente no Forms, não entra em conflito com nenhum nome de controle UWP (da mesma forma que "ListView" faz) e não é _exatamente_ como UICollectionView (por causa do prefixo "UI"). Não é 100% ideal para fins de pesquisa, mas sentimos que é a melhor expressão da intenção do controle.

Dito isso, se alguém propõe um nome alternativo pelo qual nos apaixonamos imediatamente, fico feliz em fazer a busca e substituir.

(Eu queria chamá- lo de "ListView2ColonRevengeOfTheListView", mas dispensou :))

@dansiegel

Um bom contexto sobre isso seria pensar em um cliente de e-mail no qual você pode obter um menu ao deslizar para a esquerda e outro ao deslizar para a direita.

Dê uma olhada nas especificações do

@GalaxiaGuy

suporta ícones de empilhamento

Esse é um ótimo ponto, devemos apoiá-lo, se possível. Eu sei que funciona com os glifos UWP integrados; Eu teria que fazer uma pequena pesquisa para ter certeza de que esse tipo de empilhamento funcionaria nas outras plataformas (suspeito que a resposta seja "sim").

Atualização: A parte FontIconSource desta especificação foi movida para sua própria especificação .

Eu usaria um cenário de usuário para escolher vários itens de uma seleção, por exemplo, a seleção de uma ou mais fotos de um álbum. Cenário bastante comum em aplicativos como OneDrive ou WhatsApp.

@hartez

Dito isso, se alguém propõe um nome alternativo pelo qual nos apaixonamos imediatamente, fico feliz em fazer a busca e substituir.

Já sugeri um novo nome por diferentes razões

Qual será o valor de SelectedItem quando SelectionMode for Multiple ? Posso pensar em 5 opções:

1. O último item selecionado por ordem de seleção.
   
2. O último item selecionado por ordem de fonte.
   
3. O último item selecionado / desmarcado por ordem de seleção.
   
4. O último item selecionado / desmarcado por ordem de fonte.
   
5. nulo
   
   
   
   (2), (3) e (4) não são muito úteis. Eu os adicionei apenas para cobrir todas as opções. (1) parece ser a escolha mais lógica. (5) se você não quiser apoiar SelectedItem alguma, se SelectionMode for Multiple .

@ AmrAlSayed0

Qual será o valor de SelectedItem quando o SelectionMode for Multiple?

No momento, a resposta é "o que quer que fosse antes de você trocar SelectionMode por Multiple ".

@rogihee

Gostaria de um cenário de usuário para multi-picking de itens de uma seleção

Você está perguntando se este cenário de seleção é compatível? AFAIK, todos os controles nativos que pretendemos usar oferecem suporte a ele, portanto _deve_ ser compatível com CollectionView.

Um estilo vinculável para SelectionMode seria útil, se SelectionMode = None, Transparent etc, isso é algo que o Radlist faz e é uma maneira muito útil e fácil de lidar com o estado visual baseado em vínculos. Um estilo para cada modo de seleção cobriria esses cenários.

@andreinitescu

Respondendo aos seus comentários de https://github.com/xamarin/Xamarin.Forms/issues/3172#issuecomment -401015625 (e em outros lugares):

Você está mencionando muitos pontos positivos e quero ter certeza de que não os estamos ignorando. Ainda não sabemos todas as respostas. Estamos no processo de aumentar esta API para que possamos ver onde ela funciona e onde se desintegra; Suspeito que a divisão de classes que você está sugerindo está bem próxima de onde devemos chegar.

Reconhecemos que você (e vários outros) deseja que essas classes intermediárias possam ser renderizadas como StackLayouts e Grids de itens modelados (ou seja, o "BindableRepeater"), e esse é um dos casos de uso que estamos explorando.

@alexhardwicke

Em geral, na nova API, adicione pontos onde podemos estender o comportamento, se necessário.

Os métodos UpdateX nos renderizadores serão protected virtual . :)

Com toda a seriedade, estamos cientes de que isso tem sido um ponto problemático no passado e o mantemos em mente ao escrever CollectionView .

1. Pensando bem, realmente não acho que CollectionView seja uma boa escolha para o nome de classe desta visualização.
   No Windows XAML, um CollectionView é a classe base para uma fonte de dados de itens usados ​​para filtrar agrupamento, consulte https://msdn.microsoft.com/en-us/library/system.windows.data.collectionview (v = vs. 110) .aspx
   Talvez em algum momento os Formulários Xamarin recebam uma classe para o mesmo propósito, e acho que fará sentido se ela tiver o mesmo nome (CollectionView), especialmente quando se pensa no XAML Standard (isso ainda está planejado?)

   Por mais feio e engraçado que pareça, ListView2 é uma boa escolha :) É a prática recomendada em .NET usar sufixo para controle de versão quando o nome existente é o único nome que faz sentido:

   USE um sufixo numérico para indicar uma nova versão de uma API existente, especialmente se o nome existente da API for o único que faz sentido (ou seja, se for um padrão da indústria) e se adicionar qualquer sufixo significativo (ou alterar o nome) não é uma opção apropriada.

   _Diretrizes de design de framework: convenções, expressões idiomáticas e padrões para bibliotecas .NET reutilizáveis, 2ª edição_
   https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/general-naming-conventions

   Em algum momento, mais tarde, todos usarão o novo e brilhante. ListView2 estável e de alto desempenho :). Avançar rapidamente, renomear ListView2 para ListView, embora seja uma alteração importante, será uma refatoração simples (e bem-vinda) para todos.

2. No Xamarin Forms já existe um ItemsViewque se parece muito com ItemsControl no Windows XAML, exceto por não ter uma propriedade de layout de itens.
   Em vez de criar uma nova classe CollectionView, seria possível usar ItemsView existentestambém como uma classe base para o novo ListView?

3. Há um desafio óbvio no design e implementação da API, com o uso de controles da plataforma nativa que exibem uma lista de itens, mas ainda têm a flexibilidade de ter algo como o "BindableRepeater", que se destina a exibir um simples, mais leve, não rolável e não - lista selecionável de itens.
   Parece que Uno conseguiu:

   • 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

Em vez de criar uma nova classe CollectionView, seria possível usar ItemsView existente também como uma classe base para o novo ListView?

Há ItemsView<T> , mas não queremos usar isso. Ele usa TemplatedItemsList , que é parte do problema que estamos tentando evitar com este novo controle.

Em algum momento, mais tarde, todos usarão o novo e brilhante. ListView2 estável e de alto desempenho :). Avançar rapidamente, renomear ListView2 para ListView, embora seja uma alteração importante, será uma refatoração simples (e bem-vinda) para todos.

Seu otimismo é encantador, mas temos que trabalhar sob a suposição de que ListView (1) é para sempre e que uma mudança significativa como uma renomeação de ListView2 não será permitida.

Achei que estar no mesmo nível do Windows XAML fazia sentido, mas ok, use o nome que quiser, desde que o novo controle cumpra sua promessa. O framework Uno parece ter conseguido fazer isso, então agora estou ansioso para ver o que vocês estão trazendo no Xamarin Forms.

@gmwilhelm

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

Bom ponto. Eu temporariamente adicionei isso à API. Digo provisoriamente, porque posso ver totalmente como podemos implementá-lo no iOS e Android, mas UWP pode ser um desafio.

Mas não posso negar que é razoável e agradavelmente simétrico.

Que tal adicionar GroupItemsBinding ?

Isso permitiria que um Grupo contivesse uma propriedade de tipo de coleção, em vez de exigir que um grupo fosse derivado de uma coleção, como o ListView faz. Essa limitação existente do ListView me forçou a fazer uma duplicação dispendiosa de desempenho de estruturas de dados agrupadas em várias ocasiões. Adicionar GroupItemsBinding evitaria isso e permitiria um mapeamento mais flexível para estruturas de dados agrupadas.

Ou seja, o exemplo usado na

`` `C #
class Group // Observe que Group não precisa derivar de ObservableCollection
{
Grupo público (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 = nova vinculação (nameof (Group.Persons))
// ...
};
// ...
}

`` `

Dado que este é um subconjunto do que UICollectionView faz em termos de layout, acho que devemos escolher um nome diferente para evitar confusão com os recursos no controle.

Só para ficar claro, esse controle ainda não está disponível para ser usado correto? Tentei fazer referência, mas meu projeto não consegue encontrar

@titonton Este é um problema apenas para discutir a especificação para CollectionView, a implementação ainda nem começou, e eu não acho que isso acontecerá até que a especificação seja finalizada.

@ AmrAlSayed0 Na verdade, deveria ter iniciado porque foi movido para "Em andamento na Sprint 139" 11 dias atrás.

Não está claro como isso foi iniciado, pois não está claro qual é a decisão sobre a API

@opcodewriter Isso é o que eu estava pensando. @ AmrAlSayed0 Obrigado pelo esclarecimento.

Alguém poderia esclarecer qual é o estado atual desta especificação? Está faltando algo onde a comunidade pode ajudar?

@migueldeicaza @hartez Nomear isso vai ser difícil se você não quiser que seja nomeado CollectionView . Que tal CatalogView ?

Os catálogos são frequentemente projetados em uma ou mais colunas e com várias linhas de itens com fontes, textos, layouts semelhantes, etc.

Amostra:

@hartez Você acha que as APIs estão quase completas agora? Quanto trabalho foi feito até agora? Muitos de nós adoraríamos colocar as mãos neste controle o mais rápido possível. :)

@ adrianknight89 Eu acredito que este é o ramo de trabalho. https://github.com/xamarin/Xamarin.Forms/tree/lv2spike

Não esperamos que ele esteja pronto para visualização por enquanto, mas irei apresentar / demonstrar os resultados do esforço atual nas próximas semanas para validar o progresso e solicitar feedback.

Estou confuso. Como você já teve algumas demos internas, parece que você já está bem avançado na implementação.
Isso não deveria significar que muitas das APIs foram definidas? Você está seguindo as especificações da API aqui?
Não consigo ver como a especificação atual será capaz de resolver o que foi discutido aqui e no outro tópico aqui https://github.com/xamarin/Xamarin.Forms/issues/1718
Para ser mais preciso, a API não é flexível o suficiente para permitir, por exemplo, um controle simples do tipo StackLayout não rolável e vinculável.

O novo controle permite colocar itens vinculados em uma pilha, sem barra de rolagem, assim como StackLayout?

Obrigado, muito esperado por isso 👍

Depois de muita discussão interna e tentativas de desenvolver uma arquitetura adequada, decidimos que CollectionView _não_ lidará com os cenários de layout discutidos em # 1718. Em outras palavras, ele não lidará com a vinculação de uma coleção de objetos a itens em qualquer Xamarin.Forms Layouts.

O objetivo original do CollectionView era permitir que os usuários usassem facilmente os vários controles nativos modernos de lista / grade (UICollectionView, RecyclerView, ListView / GridView, etc.).

Foi tentador tentar fazer de CollectionView um controle único para as necessidades de "renderizar e organizar este modelo com dados" de todos, incluindo todos os cenários em que a etapa de "organizar" foi tratada por Forms Layouts (FlexLayout, StackLayout, etc. ) E há algumas sobreposições óbvias de funcionalidade (por exemplo, ambos os cenários usam DataTemplates). Mas no final, eles têm uma grande diferença fundamental de arquitetura, e tentar juntá-los resultaria em algo mais difícil de manter e confuso do que simplesmente deixá-los como controles separados. Não queríamos criar algo tão complexo a ponto de ter que implementar ListView3 em alguns anos. Vou elaborar mais sobre isso abaixo.

O resultado disso é que CollectionView permanecerá focado no problema de permitir que os usuários do Forms utilizem os controles de lista / grade nativos e se beneficiem de seus mecanismos de layout e virtualização. E # 1718 será atualizado para refletir uma API que permitirá aos usuários de Formulários vincular ItemsSource e ItemTemplate aos vários mecanismos de Layout de Formulários.

Para os interessados ​​no _porque_ de dois controles versus um:

A diferença fundamental entre o que foi delineado aqui (como CollectionView) e a proposta em # 1718 é _onde_ o layout ocorre.

CollectionView visa usar os motores de layout nativos (que foram amplamente otimizados pelos desenvolvedores da plataforma) para lidar com o layout. Algum código personalizado do Forms é envolvido (por exemplo, no fornecimento de coisas como a lógica SnapPoints no Android e iOS), mas na maior parte os mecanismos de layout nativo (e implementações de virtualização nativa) estão fazendo o trabalho pesado. Isso faz uma grande diferença no que diz respeito ao desempenho.

Portanto, qualquer informação de layout que o desenvolvedor forneça ao CollectionView é meramente repassada ao renderizador em cada plataforma para interpretação; é efetivamente uma especificação traduzida para o idioma local (LinearLayoutManager / GridLayoutManager no Android, UICollectionViewFlowLayout no iOS, etc.). Além do DataTemplate, o Forms não faz nenhum trabalho de layout.

Em contraste, um Layout de Formulários (FlexLayout, StackLayout, AbsoluteLayout, etc.) é totalmente disposto na camada Formulários. Os renderizadores para um Layout de Formulários fazem muito pouco. E não há virtualização ocorrendo; todos os itens são criados e colocados no layout desde o início.

Tentar juntar essas duas coisas leva a algumas perguntas difíceis, incluindo:

1. Como funciona o mapeamento do renderizador? Uma CollectionView usando um StackLayout tem um renderizador muito diferente de uma CollectionView que precisa usar uma RecyclerView. Nós os misturamos e ocultamos o RecyclerView quando não precisamos dele? O renderizador deriva de DefaultRenderer? Se fizermos isso, sempre teremos uma camada ViewGroup extra de que realmente não precisamos ...

2. Como lidamos com ScrollViews? UICollectionView lida com sua própria exibição de rolagem, mas se um StackLayout precisa de rolagem, o usuário normalmente o adiciona manualmente no Forms. Adicionamos outra camada para inserir a rolagem automaticamente, se necessário? Desabilitamos / removemos um ScrollView adicionado manualmente se o layout chama um UICollectionView?

3. Por falar nisso, para onde vão os métodos ScrollTo?

... e assim por diante. Todos esses problemas são _solucionáveis_, mas cada solução adiciona _complexidade_. E como foi apontado em # 1718, adicionar ItemsSource e ItemsTemplate a um Layout de Formulários não é tão difícil ou complexo. Tornar complexo apenas juntar esses dois cenários distintos não compensa os benefícios.

Estou confuso. Como você já teve algumas demos internas, parece que você já está bem avançado na implementação. Isso não deveria significar que muitas das APIs foram definidas? Você está seguindo as especificações da API aqui?

Estamos seguindo a API postada aqui. "Muito longe" é provavelmente um exagero; até agora, implementamos algumas das partes não polêmicas das especificações para verificar se elas são possíveis e se não vamos por nenhum beco sem saída. Supondo que não tenhamos problemas, muito do que implementamos até este ponto provavelmente estará na versão lançada. Mas tudo nas especificações ainda está sujeito a alterações, assim como tudo o que implementamos até agora.

Não consigo ver como a especificação atual será capaz de resolver o que foi discutido aqui e no outro tópico aqui # 1718. Para ser mais preciso, a API não é flexível o suficiente para permitir, por exemplo, um controle simples do tipo StackLayout não rolável e vinculável.

É verdade, e parte do que estamos trabalhando é determinar se CollectionView _pode_ cobrir razoavelmente esses casos de uso. Chegamos a uma decisão sobre isso; consulte https://github.com/xamarin/Xamarin.Forms/issues/3172#issuecomment -424413234.

Dado que este é um subconjunto do que UICollectionView faz em termos de layout, acho que devemos escolher um nome diferente para evitar confusão com os recursos no controle.

Como já disse (https://github.com/xamarin/Xamarin.Forms/issues/3172#issuecomment-401186893), estou aberto a outros nomes.

Que tal CatalogView?

Os catálogos são frequentemente projetados em uma ou mais colunas e com várias linhas de itens com fontes, textos, layouts semelhantes, etc.

Esta é uma ideia interessante. Definitivamente, não entra em conflito com nenhum nome de controle existente.

@hartez Como um cara aleatório na internet, que está se tornando mais familiarizado com o interior do Xamarin Forms (e já estava bastante familiarizado com UITableView e UICollectionView), acho que essa é a atitude certa.

Ainda será possível fornecer um layout personalizado (mesmo que isso signifique fornecer implementações separadas por plataforma)?

Ainda será possível fornecer um layout personalizado (mesmo que isso signifique fornecer implementações separadas por plataforma)?

Absolutamente. Você pode fornecer seu próprio layout marcado com IItemsLayout e seu renderizador personalizado pode interpretá-lo como você quiser.

Por exemplo, como uma prova de conceito, criei uma subclasse do renderizador Android para CollectionView e adicionei a capacidade de interpretar uma classe FlexLayout : IItemsLayout que incluía várias propriedades do Flex Layout. Ele passa essas propriedades para o FlexBoxLayoutManager do Google e usa esse gerenciador de layout com o RecyclerView. Assim que disponibilizarmos uma visualização pública, provavelmente irei colocar esse exemplo no GitHub para que as pessoas tenham uma referência fácil sobre como fazer esse tipo de coisa.

O objetivo é tornar isso muito, muito flexível.

@hartez
O problema descrito em https://github.com/xamarin/Xamarin.Forms/issues/3749 foi corrigido com CollectionView?
Porque aqui eu vejo que CollectionView tem apenas a propriedade ItemTemplate , que parece ter o mesmo problema de ListView .

@hartez
O problema descrito em # 3749 foi corrigido com CollectionView?
Porque aqui eu vejo que CollectionView tem apenas a propriedade ItemTemplate , que parece ter o mesmo problema de ListView .

@andreinitescu Obrigado por apontar essa discussão, eu não estava ciente desse problema com o DataTemplate.

Vou passar algum tempo na próxima semana examinando a história do DataTemplate - por que ele foi projetado dessa maneira e se há algum problema de compatibilidade com versões anteriores de CreateContent para fazer a coisa certa automaticamente (ambos em ListView e CollectionView).

@hartez Apenas como um exemplo de como contornei esse problema ao criar meu próprio controle de repetidor.

// Verifique se temos um seletor de modelo ou apenas um modelo
var templateToUse = itemTemplate é DataTemplateSelector templateSelector? templateSelector.SelectTemplate (item, null): itemTemplate;

Então, em um caso como esse, apenas corrigir CreateContent não iria quebrá-lo, apenas torná-lo desnecessário. Mas eu concordo com @andreinitescu que separar ItemTemplate e ItemTemplateSelector como propriedades separadas seria ideal ... provavelmente por causa de meu histórico em WPF e SL.

@bmacombe IMHO, Não é apenas uma questão de preferência alinhá-lo ao WPF / SL, é realmente um problema, cria confusão. Veja # 3544

@andreinitescu Isso cria confusão :) Acredite, eu fiquei confuso no início quando estava tentando oferecer suporte a DataTemplate e DataTemplateSelector em meu repetidor! Especialmente quando houve um erro ao atribuir um DateTemplateSelector à minha propriedade DataTemplate quando ele funcionou em todos os locais do XF que o usaram. Foi preciso cavar um pouco do código-fonte para descobrir isso. Provavelmente não é um problema para alguém apenas usando os controles XF embutidos, mas tentar fazer seus próprios e usá-los ... realmente confuso.

Podemos ter um evento de rolagem, por favor, em CollectionView? Até que CollectionView seja lançado, tenho uma sugestão para ListView https://github.com/xamarin/Xamarin.Forms/issues/4323

E será possível criar layouts irregulares e dinâmicos, como o PInterest por exemplo:

Veja, cada imagem tem sua própria altura :-)

Não tem certeza de que esse tipo de layout é compatível?

Atualização: da lista de propostas de nomes, o mais próximo que chegamos é "ItemsView", para evitar o uso do termo "CollectionView", que dá a impressão de que é tão completo quanto o iOS "UICollectionView"

Oi, eu ainda sou novo no Xamarin, mas tenho trabalhado com ListView usando DataTemplateSelector.
Quando tentei testar usando CollectionView com DataTemplateSelector, gerou um erro

Exceção não tratada:

System.InvalidOperationException: LoadTemplate não deve ser nulo ocorreu

Existe um bug conhecido relacionado ao DataTemplateSelector?
Eu poderia estar implementando de forma errada. Existe algum exemplo de uso de DataTemplateSelector com CollectionView?

@hartez @davidortinau alguma razão pela qual KeepItemsInView não é nomeado KeepFirstItemInView para alinhar com KeepLastItemInView ? O nome atual é plural (ou seja, sugere vários itens), enquanto a descrição diz que ele mantém apenas o primeiro item visível na janela de visualização.

Além disso, há uma maneira de expor uma API para obter a lista de visualizações atualmente na janela de visualização? Outra noite, eu estava trabalhando na criação de uma exibição de vídeo para ser incorporada em uma célula ListView e reproduzida / pausada automaticamente com base na visibilidade da janela de visualização, mas era quase impossível com os atuais ItemAppearing e ItemDisappearing Eventos CollectionView apoiar este tipo de funcionalidade de uma forma mais confiável.

Outra coisa que seria ótimo é a capacidade de criar uma visualização dependente e minimizada que é separada do pai enquanto o usuário tem o luxo de rolar no feed atual. Já vi isso no YouTube, pois agora podemos continuar assistindo ao vídeo atual e, ao mesmo tempo, continuar navegando. Não tenho certeza se isso é algo que CollectionView pode ou deve oferecer suporte, mas é algo para se pensar.

Então, brinquei um pouco com a compilação noturna atual (4.0.1.43780-nightly) que resolveu alguns problemas de redimensionamento em comparação com a compilação de visualização atual.

Uma sugestão que tenho é adicionar algo como RowSpacing / ColumnSpacing ou GridSpacing aos layouts de grade, pois isso torna muito mais fácil espaçar seus itens corretamente sem usar margem / preenchimento nos itens individuais.
Outra coisa seria adicionar Padding ou talvez EdgeOffset ao CollectionView ou Layout para evitar o uso de Margin, que corta os itens como mostrado aqui:

Margin também corta a animação "arrastar" no Android, como você pode ver aqui:

Uma sugestão que tenho é adicionar algo como RowSpacing / ColumnSpacing ou GridSpacing aos layouts de grade, pois isso torna muito mais fácil espaçar seus itens corretamente sem usar margem / preenchimento nos itens individuais.

Concordo, e isso está em nosso radar - consulte # 4681.

Atualização: da lista de propostas de nomes, o mais próximo que chegamos é "ItemsView", para evitar o uso do termo "CollectionView", que dá a impressão de que é tão completo quanto o iOS "UICollectionView"

que tal "FloatView"?

Além dos eventos ItemAppearing / Disappearing mencionados acima, quaisquer planos para formas de obter a visualização de um item:
View GetView(object item)
Se o item não for materializado, ele deve retornar nulo, eu acho.

Estou usando uma lista vertical e parece haver inconstâncias em como ela é renderizada no iOS versus Android.

No iOS, com o rótulo ocupará 100% da largura.

No Android, ele só vai ocupar a largura do conteúdo.

Eu só consegui fazer o layout corretamente com uma definição de largura estática.
Existe uma solução alternativa para o Android que respeite a propriedade da grade Width="Auto" ?

Estou usando uma lista vertical e parece haver inconstâncias em como ela é renderizada no iOS versus Android.

@shwanton Abra um problema separado para este bug e eu darei uma olhada.

@shwanton, tive problemas semelhantes que foram corrigidos quando mudei para o feed noturno

@krdmllr Posso confirmar, foi corrigido na última compilação. Obrigada.

Oi. Haverá um evento ItemTapped em CollectionView semelhante ao ItemTapped de ListView? Eu não vejo isso nas especificações. Obrigada.

@uvirra Existe um problema para sua consulta de DataTemplateSelector . Veja # 4826.

@hartez Haverá necessidade de uma estratégia de reciclagem de itens como as três que existem por ListView ? Você mencionou várias vezes a virtualização nativa que CollectionView potencializa. Eu só quero obter mais esclarecimentos sobre isso.

Também estou curioso para saber como RefreshView ficará no iOS. A atualização atual para ListView requer UITableView da propriedade Bounces a ser ativada, enquanto no Android, a visualização de atualização é puxada para cima do item mais visível (que Eu pessoalmente prefiro).

@hartez Haverá necessidade de uma estratégia de reciclagem de itens como as três que existem por ListView ? Você mencionou várias vezes a virtualização nativa que CollectionView potencializa. Eu só quero obter mais esclarecimentos sobre isso.

O design atual não exige nada como estratégia de reciclagem. No momento, estamos simplesmente utilizando a virtualização fornecida pelos controles nativos, que fazem um ótimo trabalho fora da caixa.

Haverá uma necessidade? Minha esperança é "não", e faremos o possível para evitá-lo, pois adiciona muita complexidade (tanto para usuários quanto para manutenção). Se finalmente concluirmos que precisamos de algo assim, estaremos abordando o design com muito, muito cuidado.

E sobre o evento rolado? A maior parte da UI / UX moderna fornece cabeçalho de paralaxe, exibe / esconde itens (botões, cabeçalhos, filtros, ecc ..) na rolagem e semelhantes.
Acho que um controle novo e incrível como esse deve suportar cenários modernos.

não deve ser um problema, tanto o recyclerview quanto o UICollectionview suportam o evento rolado fora da caixa.

Até mesmo o Carouselview (baseado em collectionview) suporta o evento rolado com direção, valor de rolagem e delta: https://github.com/xamarin/Xamarin.Forms/issues/4996

Para acompanhar o comentário de @Evolutionlab sobre este ser um novo controle incrível que deve oferecer suporte a cenários modernos, gostaria de ver um suporte de virtualização ainda melhor.

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

Se isso for demais para entender, gostaria de obter acesso a VisibleItems para poder fazer virtualização em meu ViewModel.

Continue com o ótimo trabalho!

@hartez Eu estava pensando que seria legal deixar os desenvolvedores definirem um limite mínimo / máximo para o número de itens selecionados. No momento, estou fazendo uma galeria de fotos personalizada que não deve permitir que mais de 5 fotos sejam selecionadas. Quando o limite é atingido, os eventos de toque nas células devem ser ignorados, a menos que estejam desmarcando itens.

Isso também pode ser feito definindo SelectedItems (que ainda não foi implementado) em SelectionChanged evento com base em CurrentSelection count, mas isso irá acionar SelectionChanged duas vezes. Em minha opinião, devemos ter uma maneira de controlar proativamente o comportamento de seleção antes que algo chegue ao Core.

Brincando um pouco com o CollectionView hoje, percebi que o UWP está muito mais atrasado do que o Android e o iOS, e eu entendo o porquê.

Quer apenas confirmar se está planejado para ter suporte UWP completo quando finalizado?

Além dos eventos ItemAppearing / Disappearing mencionados acima, quaisquer planos para formas de obter a visualização de um item:
View GetView(object item)
Se o item não for materializado, ele deve retornar nulo, eu acho.

E sobre ItemAppearing? Não vejo nenhuma notícia sobre isso

Eu estava brincando com CollectionView e estava enfrentando problemas com altura de linha irregular. Eu vi que um ItemSizingStrategy introduzido recentemente, mas ainda está se comportando de forma estranha.

Eu brinquei com DataTemplateGallery e ao mudar para MeasureAllItems obtenho o seguinte resultado (iPhone 6, iOS 12.1.4):

Depois de deslizar para a direita e voltar, o resultado muda para:

@hartez Espera-se que funcione ou ainda está em andamento (não foi possível encontrar nenhum problema para isso)?

RemainingItemsThresholdReached já foi implementado?

Não está disponível no XAML de controle CollectionView em 4.0.0.169046-pre5.

Alguém pode me dizer que RemainingItemsThresholdReached faz parte da versão 4.0? Em caso afirmativo, você pode fornecer um código de exemplo sobre como usar esse recurso.

@Dresel Você pode abrir um novo tíquete se achar que isso é um bug? É melhor se for rastreado.

@melucas @chandrubk Não acho que RemainingItemsThresholdReached esteja sendo trabalhado ainda.

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

Eu também gostaria de ver esse recurso (junto com a visualização Atualizar) implementado logo, pois não posso tocar em CollectionView sem ele.

4323

Precisamos do evento Scrolled como o ScrollView faz

Saudações,

4323

Precisamos do evento Scrolled como o ScrollView faz

Saudações,

Eu apoio isso.
Além disso, seria incrível obter um evento quando a rolagem for interrompida / concluída.

No IOS, o UICollectionview é uma subclasse de UIScrollview, então podemos obter scrollViewDidEndDecelerating do UIScrollViewDelegate

No Android, acho que podemos estender o RecyclerView.OnScrollListener ?

Isso abrirá cenários mais avançados e polidos para atualização personalizada, paralaxe, elementos de rolagem sincronizados, etc.

Alguma chance de haver animação fora da caixa para Android, como a do Recycler View?

Alguma chance de haver animação fora da caixa para Android, como a do Recycler View?

A quais animações você está se referindo? O renderizador Android para isso é construído no RecyclerView, então ele já usa as animações padrão para coisas como adicionar / remover itens.

Oi,

Estou usando o 4.0.0.304370-pre8.
O exemplo de (link abaixo) não exibe nada no UWP, ao usar o CarouselView.
Mas CollectionView exibe a lista. Há alguma configuração específica necessária para habilitar o CarouselView for UWP?

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

Obrigado.

Olá @noypi ,

Enquanto CollectionView pode tecnicamente "funcionar" em um grau bastante pequeno em UWP, a implementação completa de CollectionView e CarouselView está sendo feita estritamente no Android e iOS para começar. Nenhum trabalho oficial para UWP está programado no momento, mas estamos continuamente coletando comentários. Se você quiser discutir que tipo de trabalho está fazendo no UWP em particular, pode me enviar um e-mail para paul. [email protected].

De acordo com as especificações, TableView será totalmente substituído por CollectionView?

Outra pergunta: já que não há mais células, como adicionar um indicador de disclorure para iOS? Com ListView, isso foi possível por meio de um renderizador personalizado.

De acordo com as especificações, TableView será totalmente substituído por CollectionView?

O TableView ainda existirá. Não removeremos nenhum controle existente.

Outra pergunta: já que não há mais células, como adicionar um indicador de disclorure para iOS? Com ListView, isso foi possível por meio de um renderizador personalizado.

No iOS, CollectionView renderiza usando um UICollectionView, o que significa que suas células são UICollectionViewCells. E UICollectionViewCells não tem visualizações acessórias (como indicadores de divulgação). Portanto, para quaisquer elementos da IU, como indicadores de divulgação ou marcas de verificação, você precisaria criá-los em seu ItemTemplate.

Como desabilitar a seleção de certos tipos de itens? Tenho vários modelos de dados e desejo desabilitar a seleção de alguns deles.

@hartez Ao definir ItemTemplate para DataTemplateSelector, estou recebendo uma exceção: System.InvalidOperationException: LoadTemplate should not be null

Achei que os modelos seriam suportados fora da caixa

@hartez Ao definir ItemTemplate para DataTemplateSelector, estou recebendo uma exceção: System.InvalidOperationException: LoadTemplate should not be null

Achei que os modelos seriam suportados fora da caixa

Eles deveriam ser; talvez você esteja encontrando um bug. Abra um problema para que possamos investigar.

@toomasz Antes de abrir um problema, você pode atualizar seu Nuget para o pré-lançamento mais recente (ou noturno) e testar o seletor novamente? O problema que você está vendo estava presente quando não havia suporte para DataTemplateSelector .

@hartez Há algum trabalho sendo feito no cabeçalho e rodapé, bem como na visualização de atualização? Se eu conseguir liberar tempo, posso procurar qualquer um, mas quero ter certeza de que não estou pisando em seus pés.

@ adrianknight89 Funciona no 4.0! Impressionante

@hartez Há algum trabalho sendo feito no cabeçalho e rodapé, bem como na visualização de atualização? Se eu conseguir liberar tempo, posso procurar qualquer um, mas quero ter certeza de que não estou pisando em seus pés.

Nada está sendo feito no momento - se você quiser tentar, isso seria ótimo.
Apenas para alertar, depois de alguma discussão hoje, adicionamos duas novas propriedades relacionadas ao cabeçalho e rodapé - IsHeaderSticky e IsFooterSticky , para especificar se eles rolam com os itens ou permanecem no lugar. Se você quiser lidar com eles junto com o cabeçalho / rodapé, seria ótimo, mas também seria ótimo se os tivéssemos trabalhando de uma forma ou de outra e pudéssemos implementar essas propriedades mais tarde.

Existe um plano para oferecer suporte à visualização de coleção na UWP?

sim. A implementação está um pouco atrás das outras plataformas no momento, mas o plano é dar suporte total. Você pode acompanhar o progresso do recurso em https://gist.github.com/hartez/7d0edd4182dbc7de65cebc6c67f72e14

Qualquer informação sobre RefreshView?
Eu tenho a última versão beta do Xamarin 4 e o tipo RefreshView não pode ser encontrado

Qualquer informação sobre RefreshView?
Eu tenho a última versão beta do Xamarin 4 e o tipo RefreshView não pode ser encontrado

RefreshView ainda não foi implementado. Você pode acompanhar o progresso do recurso aqui .

Adicionar GroupItemsBinding ?

Que tal adicionar uma propriedade GroupItemsBinding para especificar qual propriedade contém os itens filho de um grupo? Isso permitiria incorporar uma propriedade de coleção filho em vez de forçar grupos a herdar de uma coleção.

Vantagens:

• Capacidade de (des) serializar a coleção agrupada de / para JSON.
  Herdar grupos de uma coleção bloqueia a (des) serialização JSON (porque os arrays JSON suportam apenas um intervalo de valores e não propriedades). A (des) serialização de modelos de visualização é necessária para preservar o estado do modelo de visualização quando o aplicativo vai para o segundo plano ou se a API do seu aplicativo enviar modelos de visualização. A solução alternativa atual é ter uma segunda estrutura de dados e fazer uma duplicação + transformação dispendiosa em cada atualização de dados.
• Capacidade de usar sua própria classe base para itens de grupo (por exemplo, ViewModelBase )
• Evite poluir objetos de grupo com todas as propriedades herdadas de uma coleção

Por exemplo, você pode escrever este exemplo de agrupamento em docs.microsoft.com :
`` `C #
public class PageTypeGroup: List
{
public string Title {get; definir; }
// Mais propriedades ...
}

like this instead:

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

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

com XAML:

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

Não especificar GroupItemsBinding seria compatível com a implementação existente, equivalente a GroupItemsBinding="{Binding .}"

PS Eu enviei esta proposta antes, em julho de 2018 .

Atualização de 23 de agosto de 2019: o agrupamento foi implementado, mas sem essa correção; ver os dados do grupo

Espero que não seja tarde demais para acrescentar isso.

Que tal oferecer suporte a vários níveis de agrupamento?
Permitiria exibir árvores .

Por exemplo, Flutter tem ExpansionTile ( exemplo )

Em relação ao CollectionView, me deparei com um problema que acho que seria um ótimo recurso a ser adicionado.

Em uma Lista Horizontal, com rolagem, normalmente designers, adicionam um efeito de "sombra" aos elementos que não são totalmente visíveis na tela. Atualmente (até onde eu sei) não há como fazer isso no Xamarin.Forms. Você não acha que isso seria uma niec para ter recurso? Poderia ser tão simples como um booleano, que aplicaria uma "sombra projetada" ao elemento que é visível apenas por uma porcentagem X, por exemplo.

Eu proponho uma propriedade Position. Esta propriedade manteria o índice do item atual. Isso permitiria uma fácil integração de ViewPagerIndicator e indicadores semelhantes.

Eu entendo que determinar o "item atual" pode ser complicado. Se o ajuste estiver ativado, deve ser muito fácil determinar para qual item a visualização é ajustada. Sem encaixar, a escolha correta dependeria do caso de uso: talvez fosse o item ocupando o início ou o ponto médio da visualização.

Essa propriedade também pode permitir acesso fácil nos dois sentidos como uma alternativa para ScrollTo ().

@hartez Esperávamos que ele estivesse pronto para o lançamento 4.0, mas ficamos surpresos ao ver que ainda não foi concluído. Não podemos testar CollectionView sem a funcionalidade de rolagem e atualização. Você pode nos dizer quantos sprints precisamos esperar antes de serem lançados? Decidimos não enviar nada com ListView daqui para frente e gostaríamos que esse controle estivesse disponível o mais rápido possível.

@hartez Precisamos de uma maneira para CollectionView com layout de lista se

Neste exemplo, os botões devem estar diretamente abaixo da visualização da coleção. Acho que deve funcionar assim quando VerticalOptions for Start

quando o limite de itens restantes atingiu o teste de propriedade

Tenho dúvidas se o fluxo de CollectionView de um comportamento de item individual imita o comportamento nativo do iOS quando se trata de mudanças no tamanho da tela. Vou te dar um exemplo:

Uma célula da galeria de imagens no iOS é criada com um CollectionView e você define uma célula individual. O comportamento imediato é que o número de células desenhadas em uma única linha é dinâmico com base no tamanho da tela. Em um telefone, posso caber 4 itens, mas em um tablet caberia talvez 8 ou 9.

A versão do Forms também oferece isso? Até agora, o exemplo que li, só vi onde você definiu a propriedade GridItemsLayout Span. Isso resulta em um valor codificado de quantos itens podem ser desenhados e, realmente, no mundo de vários tamanhos de tela, a codificação permanente parece tão 2014. :-P

UWP tem quatro estados de modo de seleção
{
Nenhum,
Solteiro
Múltiplo,
Ampliar,
}

Acho que quatro estados no Android e IOS também são úteis
Basta dar uma olhada no Explorador de arquivos

Existem planos para uma propriedade de preenchimento simples? # 6605 Para meu caso de uso específico, provavelmente poderia usar um cabeçalho e rodapé em branco de tamanho apropriado (uma vez que esses recursos foram desenvolvidos), mas isso seria um pouco um hack e não adequado para um layout de grade onde o preenchimento em todos os quatro lados pode é preciso.

Qualquer plano para reorganizar o item da lista na visualização da coleção.

A especificação cobre como desabilitar a seleção de itens específicos em CollectionView?

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

Atualmente, estou trabalhando para contornar isso, mas isso não impede que o VisualState selecionado seja aplicado.

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

A cor da barra de rolagem vertical e a cor da barra de rolagem horizontal seriam ótimos!

E quanto à direção da rolagem, quero dizer, comece a rolar da direita para a esquerda, não o conteúdo em si

Eu gostaria de ter separadores ...

Seria ótimo ter a possibilidade de "memorizar" e aplicar a posição de rolagem.

O que seria tão incrível seria a possibilidade de usar diferentes modelos de itens para cada segundo ou X item. Isso tornaria possível criar um fundo cinza para cada segundo item e muitas outras possibilidades de estilo.

Você já não pode fazer isso com o seletor de modelos? Usando a posição com
operador de módulo?

Na terça, 13 de agosto de 2019, 16:53 Legacyorder [email protected] escreveu:

O que seria tão incrível seria a possibilidade de usar um item diferente
modelos para cada segundo ou X item. Isso tornaria possível criar
um fundo cinza para cada segundo item e muitos outros estilos
possibilidades.

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/xamarin/Xamarin.Forms/issues/3172?email_source=notifications&email_token=AC4YCKDFCH3WFENRCLPWEC3QELDE3A5CNFSM4FHJRXPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4F5IQA#issuecomment-520868928 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AC4YCKHXX5YSR7M3S4VU5QLQELDE3ANCNFSM4FHJRXPA
.

A rolagem circular deveria ser legal. Acho que é fácil de implementar.

Eu gostaria de ter um "AbsoluteItemsLayout" como ItemsLayout para o CollectionView para tornar possível definir posições absolutas em uma lista, no momento não vejo outra solução além de fazê-lo no código por trás.

É possível, ao usar GridItemsLayout, permitir que os itens se estendam por várias linhas ou colunas? Esse seria definitivamente um recurso que valeria a pena ter.

Vocês também podem expor o evento Scrolled para este controle? O objetivo disso é quando eu chegar ao fim da lista, quero recarregar itens adicionais. Não sei se CollectionView detecta se está dentro de ScrollView e desativa a capacidade de rolagem.

Vocês também podem expor o evento Scrolled para este controle? O objetivo disso é quando eu chegar ao fim da lista, quero recarregar itens adicionais. Não sei se CollectionView detecta se está dentro de ScrollView e desativa a capacidade de rolagem.

O seu desejo está garantido! Verifique a versão 4.2 :)
https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/collectionview/scrolling

Você não deve incluir um CollectionView dentro de um ScrollView, ou a virtualização não funcionará.

Vocês também podem expor o evento Scrolled para este controle? O objetivo disso é quando eu chegar ao fim da lista, quero recarregar itens adicionais. Não sei se CollectionView detecta se está dentro de ScrollView e desativa a capacidade de rolagem.

O seu desejo está garantido! Verifique a versão 4.2 :)
https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/collectionview/scrolling

Você não deve incluir um CollectionView dentro de um ScrollView, ou a virtualização não funcionará.

Estou em 4.2.0.709249
estou esquecendo de algo?

Eu tenho o evento Scrolled com 4.2.0.709249.
Tente excluir as pastas bin / obj e verifique a consolidação do NuGet para ter certeza.

Teremos suporte RTL em breve com 4.2 para Android e iOS?

Teremos suporte RTL em breve com 4.2 para Android e iOS?

Algum suporte já existe; O suporte a FlowDirection já deve estar funcionando nos itens CollectionView. O que ainda está incompleto é a direção de rolagem para layouts horizontais de CollectionView. A direção de rolagem deve corresponder a FlowDirection no Android, mas ainda temos algum trabalho a fazer nisso para as outras plataformas; esse trabalho está planejado para conclusão em 4.3.

Se você encontrar algum bug usando FlowDirection com o CollectionView, abra um problema e nós daremos uma olhada.

Você pode descrever o que não é feito com o suporte RTL?
Porque nas especificações, nem mesmo é marcado como em andamento ou completo.

Em quinta-feira, 5 de setembro de 2019, 2h19, EZ Hart, [email protected] escreveu:

Teremos suporte RTL em breve com 4.2 para Android e iOS?

Algum suporte já existe; O suporte para FlowDirection já deve ser
trabalhando nos itens CollectionView. O que ainda está incompleto é o pergaminho
direção para layouts horizontais de CollectionView. A direção de rolagem
deve corresponder a FlowDirection no Android, mas ainda temos algum trabalho para
fazer isso para as outras plataformas.

Se você encontrar algum bug usando FlowDirection com o CollectionView,
por favor, abra um problema e nós daremos uma olhada.

-
Você está recebendo isto porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/xamarin/Xamarin.Forms/issues/3172?email_source=notifications&email_token=ACDWB3GSYAQSADERHWVTJX3QIANMNA5CNFSM4FHJRXPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5455TA#issuecomment-528080588 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ACDWB3HMFCHBRZWD5AJMXH3QIANMNANCNFSM4FHJRXPA
.

Não feito: direção de rolagem para layouts horizontais.

Se você definir FlowDirection = RightToLeft em uma CollectionView de rolagem horizontal, a direção de rolagem não será da direita para a esquerda no iOS e UWP agora (eu acredito que _funciona_ no Android).

Que tal alguns LoadingDataTemplate?

De acordo com minha experiência no carregamento assíncrono de dados em ListView / CollectionView, às vezes pode haver espaço vazio até que o listview / collectionview seja preenchido.

Adicionar LoadingDataTemplate pode fornecer capacidade de resposta adicional quando grandes dados estão sendo preenchidos e a página já apareceu.

Acho que há duas maneiras de usar um indicador de carregamento. Uma é quando CollectionView é inicialmente exibido. Múltiplas células de espaço reservado são mostradas até que os dados sejam adicionados à coleção ItemsSource . O segundo é quando mais dados são adicionados na parte inferior da lista. Para o segundo, acho que podemos alavancar o rodapé?

O primeiro requer mais trabalho (por exemplo, carregue inicialmente a fonte com 3-5 itens que têm o mesmo modelo de dados de espaço reservado e, em seguida, remova esses itens e adicione os dados reais quando forem buscados). Outra abordagem é colocar uma visão do esqueleto em cima de CollectionView e ocultá-la quando os dados estiverem prontos. Atualmente, sigo essa abordagem com ListView .

Eu não tentei isso, mas poderíamos definir EmptyView para a visualização de carregamento primeiro e se não houver resultados, altere o modelo para EmptyView para mostrar uma mensagem "nada encontrado".

@ adrianknight89

Outra abordagem é colocar uma visão do esqueleto em cima de CollectionView e ocultá-la quando os dados estiverem prontos. Atualmente, sigo essa abordagem com ListView .

Isso soa como o mesmo método que eu sigo, ou seja, coloque algum indicador de atividade acima. Defina ListView como IsVisible = false e ActivityIndicator IsVisible = true e, em seguida, inverta ambos os valores após listview preenchido.

@ adrianknight89

Eu não tentei fazer isso, mas poderíamos definir EmptyView para a visualização de carregamento primeiro e, se não houver resultados, alterar o modelo do EmptyView para mostrar uma mensagem "nada encontrado".

Tem uma ideia! Embora isso possa funcionar, eu sinto que seria melhor simplificado ter propriedades de modelo separadas em CollectionView relacionadas a LoadingDataTemplate e EmptyView.

Concordo que seria melhor ter duas propriedades diferentes. Além do aspecto da simplicidade, usar uma única propriedade para duas finalidades diferentes não faz muito sentido. Talvez EmptyView devesse ter sido nomeado BackgroundView para que possamos usá-lo para qualquer propósito. (Editar: A BackgroundView é uma coisa totalmente diferente.)

@LeoJHarris Eu adicionei # 7447 para suporte de BackgroundView . Poderíamos usar EmptyView e BackgroundView para oferecer suporte aos dois cenários acima, embora isso ainda não seja 100% o que você deseja, mas deve ser melhor do que usar EmptyView para oferecer suporte a ambos cenários. Você poderia usar BackgroundView como uma tela de carregamento e anulá-la quando os dados estiverem prontos.

@ adrianknight89 seria ótimo se CollectionView

Ao rolar rapidamente por uma página que utiliza RemainingItemsThreshold de CollectionView, estamos enfrentando dois problemas diferentes.

1. O aplicativo congela e deve ser encerrado à força
2. Os itens na pilha CollectionView uns sobre os outros (veja a imagem )

Não consegui encontrar mais ninguém com esse problema. Você já viu isso relatado?

@ Bronson15 Como você está lidando com o evento RemainingItemsThresholdReached ? A rolagem rápida o acionará várias vezes e, portanto, você precisa ignorar as chamadas de evento enquanto espera para atualizar sua fonte de dados, caso contrário, eles se acumularão. Além disso, tente atualizar sua IU no thread principal.

Se ainda estiver tendo problemas, você pode abrir um novo problema com um repro para investigação.

@ Bronson15 ambos os problemas.
Tentei com ObservableRangeCollection e corrigiu o número 2.
Ainda tendo problemas de congelamentos / lista em branco: ao executar no emulador vejo pico de cpu, parece um loop infinito.

Editar: pausas apenas no iOS, no Android funciona bem.

Oi equipe,
Até eu tentei usar RemainingItemsThreshold e RemainingItemsThresholdReachedCommand e percebi que a função atribuída a RemainingItemsThresholdReachedCommand é chamada várias vezes sequencialmente (na primeira vez é chamada duas vezes, na próxima 4 vezes etc.), mesmo se eu não rolar rapidamente. Também consigo reproduzi-lo com o novo projeto Xamarin Forms (v.4.2.0.778463).
Você pode tentar reproduzi-lo no seu final? Aqui está o snippet de código simples abaixo:

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 Visto que não bloqueamos a IU enquanto RemainingItemsThresholdReachedCommand está sendo processado, é normal continuar pressionando o comando várias vezes devido aos seus padrões de rolagem. Veja como lido com o problema com um mecanismo de bloqueio: https://github.com/xamarin/Xamarin.Forms/pull/7516/files#diff -2be3eff4d53f761cd581cca1d2ec3bc0R48

Outras maneiras de fazer isso são habilitar / desabilitar seu comando ou cancelar a inscrição / inscrição no evento enquanto a busca remota está em andamento. Na minha experiência, ter um semáforo funcionou melhor porque às vezes várias chamadas são disparadas no momento em que você tenta ativar / desativar ou cancelar a assinatura / assinatura do retorno de chamada.

@hartez @samhouts @davidortinau Acho que esse problema aparecerá com frequência no futuro. A sugestão acima deve fazer parte da documentação dos demais itens? Eu faria com que a equipe de documentos criasse um feed remoto para teste e recomendasse um padrão de codificação para referência para que as pessoas não continuassem pedindo ajuda.

@techduggu Existem diferentes (menores) problemas com o seu código. Eu faria com que o código fosse revisado no Stack Exchange. Este não é o lugar para isso agora.

@ adrianknight89 Obrigado por destacar o termo "devido aos seus padrões de rolagem". Isso disparou minha ânsia de descobrir mais sobre o assunto. Depois de passar pela documentação oficial do RecyclerView e alguns outros recursos, sim, posso confirmar que ele é chamado várias vezes devido aos padrões de rolagem e esses padrões são SCROLL_STATE_IDLE, SCROLL_STATE_DRAGGING ou SCROLL_STATE_SETTLING dependendo do nosso estado de rolagem.
https://developer.android.com/reference/android/support/v7/widget/RecyclerView.OnScrollListener

Seu código e este guia do Android (https://github.com/codepath/android_guides/wiki/Endless-Scrolling-with-AdapterViews-and-RecyclerView) também confirmam que devemos lidar com a rolagem infinita por meio de bloqueio ou fazendo uso dos estados de rolagem acima (que geralmente requerem um renderizador personalizado). Conseqüentemente, com o Xamarin.Forms, experimentei seu código e funcionou perfeitamente. :) Eu recomendaria e apoiaria a sua opinião incluir esta sugestão como parte dos documentos para evitar tais questões levantadas por pessoas (com conhecimento parcial) como eu. :)

Além disso, reg. os pequenos problemas que você mencionou para o trecho de código acima - Bem, este é apenas um projeto POC para testar o carregamento infinito com o modo de exibição de coleção, no entanto, adoraria saber sua entrada se você notou algo além da verificação de nulo boba, etc.

Obrigado!

@ adrianknight89 Ah, sim. Nossa verificação de ocupado estava faltando e isso ajudou com o problema de empilhamento.

Também implementei o Semaphore como você sugeriu e parece ter atenuado um problema em que, ao adicionar novos itens ao ItemsSource, a visualização redefinia a posição de rolagem para o início. Curiosamente, adicionar a chamada em uma tentativa; finalmente; como você fez em seu arquivo de teste, trouxe esse problema de volta.

Ainda está tendo um problema de congelamento ao rolar para o final da lista. A exibição fica em branco e o aplicativo congela.

Editar: a redefinição da posição de rolagem ainda está lá, mas não com tanta frequência. A renderização do carregamento de mais itens também é muito instável no dispositivo.

@techduggu Eu não tenho VS comigo, mas apenas olhando o código, você deve aguardar RemainingStories() , mover a chamada remota dentro da tentativa e usar um usando para HttpClient (de preferência, use uma única instância estática em seu aplicativo e nunca descartá-la), mas vou parar por aqui. :)

@ Bronson15 Havia um problema com o CollectionView que redefinia a posição de rolagem e causava o congelamento da IU. Acho que foi corrigido com o # 7285, mas isso é apenas para iOS. Você pode testar o Nuget noturno mais recente e ver se ainda está tendo problemas? O URL do feed noturno está na página inicial do GitHub para formulários. Se o problema persistir, abra um problema com o código de reprodução para que possamos dar uma olhada.

@ adrianknight89 Percorrendo com a compilação noturna. Parece que o problema está quase totalmente resolvido (eu vi isso acontecer uma vez). Parece que a lista está em um loop infinito agora, em vez de ter um fim. AFAIK não há propriedade na especificação para impedir que isso aconteça?

@ Bronson15 O loop infinito não deve acontecer. Você está vendo no iOS ou Android? Você precisa finalizar o loop quando chegar ao final de seu feed remoto (ou seja, retornar de RemainingItemsThresholdReachedCommand imediatamente sem emitir outra chamada DB).

Depois que a rolagem da visualização parar, o comando não deve mais ser disparado. Eu uso o Azure Cosmos que retorna um token de continuação. Quando o token é nulo, eu sei que não há mais conteúdo para carregar, então meu RemainingItemsThresholdReachedCommand funciona com base nesse token. Você deve implementar algo semelhante.

@ adrianknight89 Ahhh. Interessante. Adicionada uma verificação para contagem de resultados e retorno se for 0. Corrigida a rolagem infinita. Obrigado pela ajuda!

@adrianknight89 testado
com 1000 itens no Android é quase em tempo real, no iOS tem que esperar 5 a 7 segundos para ter a visualização renderizada. ambos depuração, iPhone Xs e Redmi Note 7

@andreabalducci Você está no simulador XS? Como é o comportamento em um dispositivo físico? Se a renderização da visualização estiver lenta, esse pode ser outro problema com iOS que precisa ser investigado. Novamente, seria ótimo ver uma reprodução.

@ adrianknight89 @andreabalducci sim, leva cerca de 1-5 segundos no meu Xs Max para carregar mais itens. A visualização apaga e recarrega todos os itens em vez de adicionar itens à lista já renderizada.

@ adrianknight89 ambos os dispositivos físicos, o emulador de iOS tem os mesmos problemas.

Removemos todo o stacklayout das placas de dados e ganhamos alguma velocidade ao mudar para FormattedString, habilitamos as ligações compiladas antes que o iOS ultrapassasse 20 segundos.

No iOS, a visualização escurece e redesenha tudo ao adicionar no ObservableRangeCollection (de ajudantes mvvm), no Android funciona bem.

Isso soa como um problema separado para mim. Não acho que sejam os itens restantes relacionados.

É possível, ao usar GridItemsLayout, permitir que os itens se estendam por várias linhas ou colunas? Esse seria definitivamente um recurso que valeria a pena ter.

Alguma informação sobre isso?

@LynoDesu Um problema está sendo rastreado para isso: https://github.com/xamarin/Xamarin.Forms/issues/6357

@LynoDesu Um problema está sendo rastreado para este: # 6357

Ah, ótimo! Obrigado. Por onde devo começar se quiser contribuir para isso?

Leia o wiki da página inicial, bem como Contributing.md .

@ adrianknight89 encontrou o problema em branco + voltar ao início, reproduza aqui https://github.com/andreabalducci/XamarinCollectionView/blob/b186e563ff8391dfb473e62e5a4c4587e8d4e9da/cvrepro/cvrepro/ListViewModel.cs#L46

Começar com uma coleção vazia aciona o problema, se a coleção tiver algum item antes de vincular todos os trabalhos conforme o esperado.

testado no emulador do iPhone.

Eu vejo o problema. Provavelmente é o mesmo que # 7548. Você pode querer postar sua reprodução ali.

CollectionView parece estar bugado no Android ao usar IsGrouped.

CollectionView.GroupHeaderTemplate não é renderizado de forma alguma. No iOS funciona bem. Você poderia simplesmente usar o exemplo de agrupamento do site da Microsoft para testá-lo.

    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

O agrupamento de dados com CollectionView é atualmente compatível apenas com iOS.

Ops, eu perdi essa parte. Obrigado.

Para aqueles de nós que desejam exibir uma lista agrupada no iOS e no Android, mas desejam evitar ListView, há algo mais que possamos usar que seja tão flexível quanto o CollectionView por enquanto? Ou estamos presos com ListView?

Espero que este seja o lugar certo para perguntar. Vejo que na especificação original postada há propriedades para IsHeaderSticky e IsFooterSticky , mas não vejo nenhuma outra menção a elas em qualquer lugar da discussão ou do código-fonte implementado. Eles ainda estão no roteiro para esta visualização?

Na visão da coleção, precisamos ItemAppeared, ITemDisappeared.
existe alguma maneira de conseguir?

@IosDeveloperHarsh O Scrolled fornece muitas informações úteis nos argumentos do evento. Veja o primeiro e o último índice de item visível.

@ rafiwardak2003 Amostras de galeria com grupos CollectionView funcionam no Android a partir de hoje, embora eu não tenha executado a amostra que você forneceu. Qual Nuget você estava usando? Experimente com o pré-lançamento mais recente ou todas as noites.

@ cabal95 Não estou qualificado para responder isso, mas se eu tivesse que adivinhar, eles eventualmente serão implementados. Talvez precisemos ter um problema ativo para rastrear isso. Eu sei que o trabalho inicial de cabeçalho / rodapé excluía coisas pegajosas.

Acho que SelectionChangedCommandParameter deve ser removido e, em vez disso, teremos o item selecionado definido automaticamente como um parâmetro.

Se for possível, seria bom usar a propriedade desta forma

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

Mas também deve estar tudo bem:

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

Acho que SelectionChangedCommandParameter deve ser removido e, em vez disso, teremos o item selecionado definido automaticamente como um parâmetro.

Se for possível, seria bom usar a propriedade desta forma

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

Mas também deve estar tudo bem:

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

E se o usuário quiser usar algo diferente de SelectedItem como parâmetro para seu comando?

Acho que SelectionChangedCommandParameter deve ser removido e, em vez disso, teremos o item selecionado definido automaticamente como um parâmetro.
Se for possível, seria bom usar a propriedade desta forma
public ICommand => new Command<MySelectedItemModel>((item) => {}
Mas também deve estar tudo bem:
public ICommand => new Command<object>((item) =>{ var selectedItem = item as MySelectedItemModel;}

E se o usuário quiser usar algo diferente de SelectedItem como parâmetro para seu comando?

Você tem razão, mas é difícil ver um caso de uso para isso porque você está definindo o parâmetro no nível de CollectionView. Eu esperava que fosse o item selecionado da primeira vez que o usei. Mas você pode definir o item selecionado como padrão? Se você usar o evento, vai conseguir, então acho que muitos desenvolvedores também esperam isso para o comando.

Também gostaria de solicitar um recurso que este CollectionView não estique na tela inteira e use apenas a altura depende do número do item.

Estou tentando ter várias listas à vista
ie
Compras

Deduções

Total
total
tot

mas os itens 1 e 2 (uma CollectionView) tomam muita altura, mesmo se eu tiver apenas 3 ou 4 itens e houver uma lacuna BIIIIIIIIIIIIIIIG abaixo antes que eu possa ver a seção de deduções

Acabei fazendo meu próprio controle ItemsCollection baseado em StackLayout

Também gostaria de solicitar um recurso que este CollectionView não estique na tela inteira e use apenas a altura depende do número do item.
Acabei fazendo meu próprio controle ItemsCollection baseado em StackLayout

Acho que o que você está procurando podem ser layouts vinculáveis .

Também gostaria de solicitar um recurso que este CollectionView não estique na tela inteira e use apenas a altura depende do número do item.
Acabei fazendo meu próprio controle ItemsCollection baseado em StackLayout

Acho que o que você está procurando podem ser layouts vinculáveis .

Ei! Exatamente o que preciso. Desde quando BindableLayouts existia?

Obrigado a todos pela discussão sobre este assunto! Se você tiver solicitações de recursos adicionais ou relatórios de bug, abra novos problemas para cada um. Agora estamos encerrando esta questão.