Maui: Sobre os 1675 bugs abertos em Xamarin.Forms

Criado em 25 mai. 2020  ·  52Comentários  ·  Fonte: dotnet/maui

Por favor, leia este comentário de @davidortinau

https://github.com/dotnet/maui/issues/109#issuecomment -635078640

Lendo aqui estou me perguntando o que posso aprender aqui para melhorar a qualidade do Xamarin.Forms. Eu adoraria retornar à pergunta original de @ Happypig375 :

Alguma ideia de como melhorar?

Um dos nossos principais objetivos entre agora e o lançamento do .NET MAUI é melhorar a base, o ponto de partida. Por esse motivo, estamos gastando muito de nossos sprints atuais em problemas de CollectionView e estamos propondo pausar o desenvolvedor de recursos no Xamarin.Forms 5, portanto, temos de setembro de 2020 a novembro de 2021 para mudar mais o foco para a resolução de problemas.

Tudo isso é visível em nossos painéis de projetos de sprint.

Descrição Original

Xamarin.Forms é conhecido por ter erros. Atualmente, ele tem 1675 bugs abertos, que estão a caminho de superar os 1676 problemas abertos do mono. Ao comparar os números, é fácil ver que o Xamarin.Forms tem mais bugs do que o framework mono "historicamente cheio de bugs".

Agora que o código-fonte do MAUI foi copiado do Xamarin.Forms, isso significa que o MAUI começa a ser tão problemático quanto o Xamarin.Forms. Todos parecem se concentrar em tornar a arquitetura MAUI o mais livre de bugs possível, seguindo o Flutter , mas o fato de que os bugs do Xamarin.Forms são corrigidos muito lentamente, mesmo para bugs de alto impacto, parece ser ignorado. por exemplo

E abrir uma solicitação pull ainda pode fazer com que a solicitação fique presa no limbo até que um oficial do Xamarin reserve tempo para dar uma olhada nos arquivos alterados.

Conforme o tempo passa, as pessoas começarão a depender do bug, resultando na correção do bug sendo percebida como a introdução de um novo bug.

O Xamarin.Forms tinha bugs em 2015 , o Xamarin.Forms tinha bugs em 2018 e o Xamarin.Forms ainda terá bugs em 2021 quando o MAUI for lançado se os bugs forem corrigidos lentamente.

Isso é simplesmente inaceitável para aqueles que trabalham com um prazo apertado e precisam perder tempo para encontrar soluções alternativas e aplicá-las.

Com o MAUI, devemos ter um processo de correção de bugs o mais rápido possível. Alguma ideia de como melhorar?

Comentários muito úteis

De comum acordo, a qualidade sempre foi um problema para todos os aspectos do desenvolvimento do Xamarin. Muitas vezes fico frustrado por causa de incompatibilidades entre os componentes, não funcionar no VS ou meu aplicativo travar após uma atualização para a nova versão do Forms. As coisas devem funcionar. Não devo ser forçado a reconstruir meu layout pela terceira vez porque alguns controles ou layouts simplesmente não funcionam bem juntos.

Eu vejo alguns pontos relacionados

1) Não sei quantas pessoas trabalham no Formulários, mas para mim parece que a equipe é muito pequena para acompanhar o ritmo de crescimento rápido de novos bugs ou PRs. Isso só vai piorar, pois eles terão que dividir a atenção entre o Forms e o Maui. Eu realmente espero que a equipe receba um impulso substancial em breve.

2) Ajudaria muito se a Microsoft começasse a realmente usar o Forms em seus próprios aplicativos. E não me refiro a aplicativos simples de demonstração ou conferência. Refiro-me a aplicativos reais como Teams ou Outlook. Eu ficaria feliz se eu estivesse errado neste, mas não consegui encontrar nenhum aplicativo MS Forms nas lojas e de acordo com alguma fonte como este tweet https://twitter.com/safaiyeh/status/1219294459298344961 eles usam principalmente reagir nativo.

  • isso realmente não envia um bom sinal, porque se a MS não usa sua própria tecnologia (XF), por que usaríamos?

  • usar formulários internamente em aplicativos complexos pode ser uma camada extra de teste e pode reduzir o número de problemas que atingem o lançamento público. Além disso, eles perceberam que trabalhar com formulários não é tão fácil quanto nos dizem

3) Vejo outro problema no fato de que o MS tenta constantemente reinventar a roda em uma forma de XF Xaml em vez de usar soluções já comprovadas e existentes como Win UI Xaml. Eles precisam investir tempo no desenvolvimento de recursos já existentes e na correção de bugs que são introduzidos por causa disso, e então sobra menos tempo para outros recursos e correções de bugs.

Todos 52 comentários

7049 levou mais de 1 mês para ser implementado, mesmo quando o PR foi mesclado 7 dias após o relatório de bug

E abrir uma solicitação pull ainda pode fazer com que a solicitação fique presa no limbo até que um oficial do Xamarin reserve tempo para dar uma olhada nos arquivos alterados.

Esperançosamente, a equipe tem um plano para remover alguns dos gargalos em torno do processo de lançamento do PR +.

E abrir uma solicitação pull ainda pode fazer com que a solicitação fique presa no limbo até que um oficial do Xamarin reserve tempo para dar uma olhada nos arquivos alterados.

E veja só, depois de ser mencionado em um problema de alta visibilidade, alguém da equipe Xamarin.Forms finalmente respondeu a xamarin / Xamarin.Forms # 7728 .

Tenho empatia com a equipe. Muitos problemas não são fáceis de fazer a triagem / gerenciar / corrigir. Dito isso, definitivamente precisa haver um foco na remoção de gargalos e na redução das questões em aberto e PRs.

De comum acordo, a qualidade sempre foi um problema para todos os aspectos do desenvolvimento do Xamarin. Muitas vezes fico frustrado por causa de incompatibilidades entre os componentes, não funcionar no VS ou meu aplicativo travar após uma atualização para a nova versão do Forms. As coisas devem funcionar. Não devo ser forçado a reconstruir meu layout pela terceira vez porque alguns controles ou layouts simplesmente não funcionam bem juntos.

Eu vejo alguns pontos relacionados

1) Não sei quantas pessoas trabalham no Formulários, mas para mim parece que a equipe é muito pequena para acompanhar o ritmo de crescimento rápido de novos bugs ou PRs. Isso só vai piorar, pois eles terão que dividir a atenção entre o Forms e o Maui. Eu realmente espero que a equipe receba um impulso substancial em breve.

2) Ajudaria muito se a Microsoft começasse a realmente usar o Forms em seus próprios aplicativos. E não me refiro a aplicativos simples de demonstração ou conferência. Refiro-me a aplicativos reais como Teams ou Outlook. Eu ficaria feliz se eu estivesse errado neste, mas não consegui encontrar nenhum aplicativo MS Forms nas lojas e de acordo com alguma fonte como este tweet https://twitter.com/safaiyeh/status/1219294459298344961 eles usam principalmente reagir nativo.

  • isso realmente não envia um bom sinal, porque se a MS não usa sua própria tecnologia (XF), por que usaríamos?

  • usar formulários internamente em aplicativos complexos pode ser uma camada extra de teste e pode reduzir o número de problemas que atingem o lançamento público. Além disso, eles perceberam que trabalhar com formulários não é tão fácil quanto nos dizem

3) Vejo outro problema no fato de que o MS tenta constantemente reinventar a roda em uma forma de XF Xaml em vez de usar soluções já comprovadas e existentes como Win UI Xaml. Eles precisam investir tempo no desenvolvimento de recursos já existentes e na correção de bugs que são introduzidos por causa disso, e então sobra menos tempo para outros recursos e correções de bugs.

Eu concordo 100% com @Reveon
ah, e devo dizer que usar o VisualStudio para Windows com o Xamarin é uma experiência super frustrante.

Eles continuam a adicionar erros, bloqueios, pendentes ... eu nem sei como isso é possível (coisas como quebrar TODAS as compilações de dispositivos ios, quebrar perfis de provisionamento, quebrar o reconhecedor de gestos ... como podem bugs como esses entrar em produção e então leva semanas ou meses para ser corrigido na versão de lançamento? Não sei ....)

Mudei para o Rider para isso e agora estou usando o produto Jetbrains em todos os lugares :) Pelo menos posso usar um IDE que é exatamente o mesmo no iOS e no Windows e continuar a trabalhar de forma produtiva.

Tenho certeza de que com o MAUI essas coisas mudarão e, mais cedo ou mais tarde, a Microsoft começará a usar o MAUI internamente para projetos sérios

Outro depoimento:
https://github.com/xamarin/Xamarin.Forms/issues/10482#issuecomment -633730446
@EmilAlipiev :

Estou esperando que meu PR seja mesclado por 1,5 mês para esse problema. Já existe um problema para iOS e o Android foi corrigido em julho de 2019 e ninguém mexeu no uwp. Fixei em abril e solicitei várias vezes para revisão e fusão. É realmente irritante como as equipes xamarin estão trabalhando. Você pode ver que eles revisam apenas 1-2 PRs por dia.
# 10316

Embora muitas vezes me sinta frustrado, "Xamarin tem erros" é uma afirmação dura. Mais de 2.000 questões em aberto hoje, se você marcar o flutter, tem mais de 5.000 questões em aberto. Os números não são tão importantes. Xamarin.forms oferece mais do que outras plataformas cruzadas como uwp (incluindo xbox), wpf, mac, gtk, tizen. Portanto, há muitos problemas em aberto para o Wpf, por exemplo, que é de baixa prioridade para a maioria de nós.
O núcleo do Xamarin.forms deve ser ios, android e uwp, embora a equipe do Xamarin frequentemente negligencie o uwp.

  1. Deve haver elementos centrais como layouts, listviews, carrossel, collectionview, imagens, mapas, rótulo, editor, etc. Esses devem estar livres de erros. se você fizer uma nova versão ou atualização nelas, deve garantir que não haja nenhum bug showstopper. Se houver um bug, você deve resolvê-lo em no máximo uma semana. Mas a equipe Xamarin está lançando aquele "4.5-4.6" bacana com recursos bacanas (quem precisa dessa ferramenta extravagante de 10% da comunidade?) E o controle de imagem está quebrado. O problema foi relatado no início de março e ainda não foi resolvido até hoje. O mesmo "Pacote em assemblies nativos" está quebrado. Por essas razões cruciais, não posso atualizar para 4.5 e 4.6. Eles continuam desenvolvendo com 4.7 adicionando novos recursos. Eu e a maioria de nós ficamos de olho nas notas de lançamento para ver se nossos bugs foram resolvidos, eu nem mesmo leio mais qual recurso foi adicionado.
  2. A equipe Xamarin tem que entender isso. O maior motivo pelo qual muitas pessoas escolhem o Xamarin é "UWP". Sou freelancer. Eu pergunto ao meu cliente por que não agita ou reage de forma nativa? Ele diz porque Xamarin tem UWP. Eu quero UWP também. Mas o Uwp apresenta muitos bugs com o Xamarin.forms. eles introduziram o CollectionView, é realmente ótimo, mas há um ano esse bug não foi resolvido. Eu consertei, ninguém está revisando. Eu estava desanimado de fazer qualquer outra contribuição.
  3. O Hotreload não está funcionando de jeito nenhum. Eu li no twitter tudo "beijo, beijo" como é legal o hotreaload. Estou pensando que deve haver algo errado comigo ou eles usam alguma outra ferramenta. Porque muitas vezes o hotreload não está atualizando. Ainda estou usando ferramentas de terceiros como livexaml etc. Até criei um aplicativo de console simples para fazer meu próprio hotreload. isso me custa 1 dia. Funciona muito melhor do que o do Xamarin e funciona até mesmo para uwp. Como eles podem não entregá-lo? Eles tinham carga de fígado estava funcionando.
  4. Ponto mais importante; o que @Reveon mencionou. eles precisam de um aplicativo corporativo real que funcione com xamarin.forms e devem atualizá-lo com novos lançamentos para detectar problemas reais. Eles reclamam que "não é tão difícil fazer a reprodução". Sim, é muito difícil se esse problema ocorrer apenas em seu aplicativo empresarial, não em um aplicativo de tarefas. Você precisa tentar replicar a mesma interface do usuário. pode custar seus dias até você descobrir. É por isso que é muito importante que haja alguém com um aplicativo grande. Eu estou me perguntando se algum desses devs Xamarin que vemos no twitch, youtube, twitter etc, eles já desenvolveram um grande aplicativo com xamarin.forms.

  5. Tenho que admitir uma coisa, embora não goste de usar ferramentas de código aberto, mais de 50% dos meus aplicativos são com ferramentas de sincronização. Sem o Syncfusion, acho que é muito difícil fazer um aplicativo corporativo funcionar. Eles têm tudo o que xamarin não tem ou o que é buggy xamarin. Por exemplo, eu procurei por sfListView substituto por anos tendo drag and drop, swipe view, layout linear e de grade, melhor virtualização etc. é bugado. Não funciona para Uwp. muitos recursos ausentes. Basta pesquisar por CollectionView dentro dos fascículos, você encontrará dezenas deles.

Ainda acredito que o Xamarin é a melhor ferramenta para plataformas cruzadas e espero que eles considerem esse problema como um feedback construtivo.

Comentários excelentes e construtivos até agora. Eu estava lendo a lista e sentindo o mesmo que os outros desenvolvedores. Os problemas são comuns entre aqueles de nós que usam o Xamarin.Forms para desenvolver aplicativos corporativos. O rastreamento e correção de bugs precisam de mais atenção, mas especialmente, um ponto que é claro, e muitas vezes eu me perguntei, é por que não existe um aplicativo MS corporativo construído com Xamarin.Forms. MS Teams ou qualquer outro. Se a resposta for: muito complicado ou impossível de fazer com o Xamarin.Forms, há um grande insight interno para melhorar a plataforma como um todo e tentar consertar esses problemas. O Xamarin / MAUI certamente ganhará com mais desenvolvedores testando, contribuindo e divulgando, mas esta deve ser uma via de mão dupla. Novamente, não estou reclamando, mas seria ótimo ver, neste ano, no próximo ano, um grande lançamento MS de um aplicativo móvel construído com MAUI ou Xamarin. Verifique também se os desenvolvedores estão frustrados ou possíveis melhorias e leve o desenvolvimento de plataforma cruzada a um novo nível.

Porque, eu fui mencionado ...

Liderei um pequeno projeto para um aplicativo multiplataforma entre Android e Windows Desktop (WPF).

Encontramos muitos bugs, que tivemos que trabalhar uma rodada ou consertar. Atualmente, inicio um projeto interno para os consertos e melhorias de performance, pois compartilhar nossas soluções com esse lento andamento é impossível. Também temos prazos.

Trazer bugs no pipeline oficial é muito caro para nossa pequena equipe, então seria bom receber mais atenção, talvez você obtenha mais da comunidade.

Na parte wpf do xamarin há muito o que fazer. O desempenho é ruim e é um inferno de bugs simples . Mas a ideia por trás e a base estão definidas. É triste ver o estado atual, porque poderia ser bem melhor ...

De comum acordo, a qualidade sempre foi um problema para todos os aspectos do desenvolvimento do Xamarin. Muitas vezes fico frustrado por causa de incompatibilidades entre os componentes, não funcionar no VS ou meu aplicativo travar após uma atualização para a nova versão do Forms. As coisas devem funcionar. Não devo ser forçado a reconstruir meu layout pela terceira vez porque alguns controles ou layouts simplesmente não funcionam bem juntos.

Eu vejo alguns pontos relacionados

  1. Não sei quantas pessoas trabalham no Formulários, mas para mim parece que a equipe é muito pequena para acompanhar o ritmo de crescimento rápido de novos bugs ou PRs. Isso só vai piorar, pois eles terão que dividir a atenção entre o Forms e o Maui. Eu realmente espero que a equipe receba um impulso substancial em breve.
  2. Realmente ajudaria se a Microsoft começasse a realmente usar Formulários em seus próprios aplicativos. E não me refiro a aplicativos simples de demonstração ou conferência. Refiro-me a aplicativos reais como Teams ou Outlook. Eu ficaria feliz se eu estivesse errado neste, mas não consegui encontrar nenhum aplicativo MS Forms nas lojas e de acordo com alguma fonte como este tweet https://twitter.com/safaiyeh/status/1219294459298344961 eles usam principalmente reagir nativo.
  • isso realmente não envia um bom sinal, porque se a MS não usa sua própria tecnologia (XF), por que usaríamos?
  • usar formulários internamente em aplicativos complexos pode ser uma camada extra de teste e pode reduzir o número de problemas que atingem o lançamento público. Além disso, eles perceberam que trabalhar com formulários não é tão fácil quanto nos dizem
  1. Eu vejo outro problema no fato de que o MS constantemente tenta reinventar a roda em uma forma de XF Xaml em vez de usar soluções já comprovadas e existentes como Win UI Xaml. Eles precisam investir tempo no desenvolvimento de recursos já existentes e na correção de bugs que são introduzidos por causa disso, e então sobra menos tempo para outros recursos e correções de bugs.

Eu concordo com muitas das questões que você mencionou. A Microsoft definitivamente precisa fazer um aplicativo corporativo usando Formulários Xamarin ou iOS ou Android. Assim que eles tiverem um exemplo de aplicativo corporativo funcionando, não podemos reclamar que fazer aplicativos profissionais é frustrante.

O Xamarin Forms é um ótimo framework multiplataforma para quem deseja fazer um aplicativo uma vez e funcionar em qualquer lugar. Funciona muito bem se você criar aplicativos simples. Mas quando você começa a fazer um aplicativo mais profissional com mais recursos como animações, guias segmentadas, virtualização de dados, layouts complexos, etc., você se vê lutando cada vez mais contra a estrutura para fazer um recurso funcionar. Acho que coisas simples que deveriam funcionar não são óbvias ou requerem hacks para que funcionem.

Recursos como o Xamarin Hot Reload ainda são prematuros em seu estágio de desenvolvimento. Por exemplo, se eu fizer uma mudança de estilo no App.xaml ou em um dicionário de recursos referenciado no App.xaml, que é onde armazeno meus estilos e recursos, o Hot Reload bagunçará o layout do aplicativo no simulador ou causará o aplicativo para travar.

Acho que o Visual Studio é incrivelmente bugado no desenvolvimento de aplicativos Xamarin. Por exemplo, se meu projeto Android foi selecionado como projeto de inicialização, teste com ele e, em seguida, mude para meu projeto iOS como meu projeto de inicialização, ele mostrará todos os tipos de erros falsos. Destruir as pastas bin ou obj não ajuda. Requer que eu reinicie o VS. Em outro exemplo, o VS perderá aleatoriamente sua conexão com meu Mac enquanto estou depurando meu aplicativo. Isso fará com que meu VS congele. Vou ter um acesso de raiva, questionar meu hobby e minha vida como um desenvolvedor móvel e forçar a matar o VS usando o Gerenciador de Tarefas. Além disso, descobri que as versões futuras do Visual Studio reintroduzem bugs que foram corrigidos nas versões anteriores. Não conheço nenhuma maneira de como instalar uma versão anterior do VS depois que a versão mais recente é lançada e eu a instalo. Posso desinstalá-lo e tentar reinstalar usando o instalador, mas sempre instalará a versão mais recente. Não é como um pacote NuGet onde você pode instalar qualquer versão.

Por último, por que um controle de guia segmentado ainda não faz parte do kit de ferramentas Xamarin? As guias segmentadas são usadas em quase todos os lugares. Eu não deveria ter que usar o kit de ferramentas Syncfusion ou outro kit de ferramentas para usar um controle que é tão comum.

Estou nervoso em adotar o MAUI quando for lançado em qualquer aplicativo profissional que desenvolvo até que muitas dessas frustrações do desenvolvedor com o Xamarin e o Visual Studio sejam resolvidas. Vou brincar e experimentar quando for lançado. Mas terei mais confiança se a Microsoft vier e fizer um aplicativo corporativo usando MAUI em vez de fazer aplicativos de demonstração simples.

Alguém pode nos esclarecer sobre os formulários Xamarin e os roadmaps do MAUI? Eles serão mantidos em paralelo? Existe uma parada difícil para o suporte do Xamarin Forms e a Microsoft vai empurrar o MAUI em nossas gargantas em uma atualização futura do Visual Studio?

Obrigado

@SunnyMukherjee no FAQ,

Qual é o futuro do Xamarin.Forms?

A próxima versão principal do Xamarin.Forms será em torno de setembro de 2020 e continuará a ser atualizada através do lançamento do .NET MAUI com .NET 6. Depois disso, o Xamarin.Forms continuará a receber atendimento prioritário por 12 meses.

Basicamente, o Xamarin.Forms será encerrado após a versão 5.

@SunnyMukherjee no FAQ,

Qual é o futuro do Xamarin.Forms?

A próxima versão principal do Xamarin.Forms será em torno de setembro de 2020 e continuará a ser atualizada através do lançamento do .NET MAUI com .NET 6. Depois disso, o Xamarin.Forms continuará a receber atendimento prioritário por 12 meses.

Basicamente, o Xamarin.Forms será encerrado após a versão 5.

Em meados de 2021. . . se Covid não me matar antes disso, o Maui ou o Xamarin Forms farão o trabalho.

@SunnyMukherjee Eu ouço sua dor. Tenho usado o Xamarin.Forms desde que foi lançado e tem vindo a evoluir desde então. Lembre-se de que a Microsoft não criou o Xamarin.Forms, eles apenas compraram o Xamarin em 2018. Portanto, o MAUI é o projeto da Microsoft para reescrevê-lo para ser melhor e fazê-lo funcionar perfeitamente com todo o .net. Trabalhar com o Xamarin.Forms não é trivial porque o que ele tem a fazer não é trivial. Muitas pessoas estão dizendo que eles deveriam apenas fazer o que o Uno ou o Flutter fizeram e fazer os controles sozinhos - mas isso é contra o que o Xamarin.Forms é. É uma estrutura de desenvolvimento nativa - expondo os controles nativos de uma maneira comum. Esta não é uma tarefa pequena. Eu também tive muitos problemas com o Xamarin.Forms, mas no geral, o tempo economizado usando-o em vez de escrever o mesmo aplicativo em vários idiomas supera em muito os problemas. Além disso, ser capaz de compartilhar 90% do código com os projetos principais do ASP.Net de back-end torna ainda mais valioso.
Embora seja importante que a Microsoft saiba o que queremos no MAUI, temos que entender que não é uma tarefa fácil para eles, e espero que o MAUI seja um grande passo na direção certa.
Assista a este vídeo da versão recente do MAUI de demonstração e explica como ele se encaixa nos roteiros e também o que eles farão e oferecerão suporte no Xamarin.Forms enquanto isso:
https://channel9.msdn.com/Events/Build/2020/BOD106?ocid=AID3012654&WT.mc_id=Build2020_pmmsocialblog

Lendo aqui estou me perguntando o que posso aprender aqui para melhorar a qualidade do Xamarin.Forms. Eu adoraria retornar à pergunta original de @ Happypig375 :

Alguma ideia de como melhorar?

Um dos nossos principais objetivos entre agora e o lançamento do .NET MAUI é melhorar a base, o ponto de partida. Por esse motivo, estamos gastando muito de nossos sprints atuais em problemas de CollectionView e estamos propondo pausar o desenvolvedor de recursos no Xamarin.Forms 5, portanto, temos de setembro de 2020 a novembro de 2021 para mudar mais o foco para a resolução de problemas.

Tudo isso é visível em nossos painéis de projetos de sprint.

Resumidamente:

  • Seja mais rápido na solicitação de pull da comunidade.

Eu rebasei a árvore de solicitação de pull dias atrás. Por que a revisão está demorando tanto?

WPF-Renderer, pontos de bugs em potencial:

  • Medir / organizar os controles
  • Logical / Visual-Childtree está quebrado
  • atuação

Olá @davidortinau , acho que uma boa maneira de lidar com isso é dedicar publicamente alguém para estar totalmente envolvido em:

  • triagem de problemas de bug
  • gerenciar, despachar e empurrar para revisão e fusão de relações públicas.

Ele / ela seremos nosso ponto de contato se algo correr muito devagar e ele / ela pode explicar o que está acontecendo.
Além disso, se houver impedimentos não legais, será fantástico se pudermos ter um canal Twitch onde, por sua vez, alguém conserta um bug ou analisa um PR online. IHMO, isso poderia ter um tremendo impacto no interesse e colaboração de desenvolvedores externos.
Isso é válido para .NET MAUI e Xamarin Forms. Mas talvez eu seja apenas um sonhador 😄

Não estou realmente surpreso que o Xamarin.Forms tenha muitos bugs considerando o número de plataformas em que está rodando e as mudanças nas plataformas ou por seu próprio desenvolvimento.

O que é surpreendente para mim, porém, é o número de bugs de regressão, coisas que funcionaram antes ou foram corrigidas antes e que quebram com a próxima versão.
Para mim, este é um sinal claro de não testar o suficiente. Um regime de teste mais rígido pode fazer com que algumas mudanças não estejam no próximo lançamento, mas detectá-las logo é realmente necessário para evitar o estigma de um produto que não é confiável, para dizer isso sem rodeios.

Mais testes é algo que eu gostaria de ver como lição tirada do Xamarin.Forms for MAUI. Isso poderia evitar muitos problemas relatados e desperdício de recursos porque o código com erros demorou muito em vez de ser imediatamente resolvido com o PR criado.

Quando eu disse "principais recursos" e "bugs críticos". Isso é o que quero dizer com um problema como este . Isso é super irritante agora. Eu fiz um lançamento de uma semana sem realmente saber desse problema. Eu estava me perguntando por que a retenção de aplicativos caiu drasticamente. Imagine que a maioria das pessoas não falam inglês e um usuário espanhol ou alemão abre o aplicativo e ele é inglês por causa desse bug. Ele irá desinstalá-lo imediatamente, embora meu aplicativo esteja traduzido para esse idioma. Este bug pode acontecer, mas foi relatado há uma montagem atrás? por que não foi corrigido. Até o Appcenter e o Azure Pipelines têm esse bug.

Para melhorar a estrutura. Eu gostaria de adicionar:

Melhore a possibilidade de escrever seu próprio renderizador. Evite a palavra-chave internal .

Em vez de apenas postar projetos de amostra no GitHub, a Microsoft pode criar um aplicativo profissional e empresarial como o OneDrive ou o aplicativo Xbox com Xamarin Forms, iOS ou Android e publicá-lo na App Store para que outras pessoas além dos desenvolvedores possam usá-lo. A Microsoft fez isso antes, migrando o Visual Studio de C ++ para C # e WPF (desde que o cliente seja o desenvolvedor, nesse caso). Isso dirá à Microsoft sobre nossos pontos fracos e, se tiver sucesso, dará uma enorme confiança à comunidade de desenvolvedores de que tudo é possível com o Xamarin.

Estou feliz que haja uma postagem sobre isso e gostaria de avaliar minha frustração. Muitas vezes sou passivo ao postar respostas para um problema existente, mas o que me desencadeia é esse problema em relação aos BundleAssemblies ; depois de mais de 2 meses com esse problema de alto impacto, ainda não tenho uma indicação clara de qual é a solução, o status ou o caminho a seguir dos membros do Xamarin.

Eu executo a equipe Agile Scrum, e muitas vezes o KPI é a Velocidade (a quantidade de trabalho realizado). Às vezes, quando temos um problema escalado para um certo nível de aquecimento, minha declaração final sempre será "... Estou me perguntando o que posso aprender aqui para melhorar a qualidade de" [nosso produto]. Sem ofensa (realmente), mas isso é apenas para patrocinar meu chefe ou nosso cliente. Quando eu digo isso durante esse tipo de contexto de discussão, significa apenas que eu ou meu Product owner não estamos à altura do trabalho ou estamos em estado de negação ou pior ainda, realmente não sabemos o que está acontecendo. (Parabéns para um de nossos stakeholders, que me deu um tapa na cara)

O que realmente me incomoda são os bugs de regressão e a falta de qualquer resposta / explicação concisa para o problema. Cada lançamento do XF está sujeito a quebrar alguma coisa; e quebra algo que é óbvio - alinhamento incorreto, imagem não exibida, truncamento de texto não funcionando e etc. Metade de nossos casos de teste são apenas para verificar essas regressões XF; é ridículo. Obviamente, há algo errado com os testes internos do XF. Mesmo quando um bug bloqueador é reconhecido, ainda pode haver vários novos lançamentos subsequentes; qual é o sentido desses novos lançamentos quando não podemos usá-lo? Esses novos lançamentos não deveriam ir para o seu Beta?

Dito tudo isso, eu e nossos stakeholders estamos muito cansados ​​da "cultura tóxica" do XF. É como o Windows 10 pode lançar uma atualização que exclui os arquivos do usuário ou o sistema do usuário brick (mas pelo menos a resposta e o hotfix são rápidos). Acredito que nossa frustração aqui não seja pela falta de recursos no XF, mas pela qualidade do lançamento. E como o XF pode melhorar a qualidade? Você pode pesquisar online e obter milhões de resultados; e nem mesmo tenho certeza por onde começar aqui, sem ser arrogante para minar o entendimento da Microsoft sobre "garantia de qualidade". Tenho certeza que a Microsoft sabe fazer garantia de qualidade (ei, eu li os white-papers da Microsoft sobre isso). Tudo se resume à pessoa responsável; ele / ela precisa da responsabilidade, prestação de contas e compromisso para melhorar (ou implementar) a verificação de qualidade.

Acho que a coisa mais frustrante em relação ao XF é quando nossa contribuição (seja um novo PR, um novo problema ou mesmo uma simples pergunta ou feedback) é simplesmente ignorada pela equipe.
A equipe provavelmente é muito pequena. Mas ter uma pessoa dedicada a fornecer respostas em um tempo razoável definitivamente ajudaria.

Um bom exemplo é essa regressão em relação a BundleAssemblies (ela já foi mencionada várias vezes).
Outro bom exemplo é esse problema com relação ao CollectionView.

Outra preocupação para mim é que um aplicativo XF é impactado por mudanças no XF, é claro, mas também no Mono, Visual Studio, Xamarin Framework, DotNet e até mesmo em algumas bibliotecas da Microsoft.
Tenho a sensação de que essas equipes não se comunicam bem internamente.
Na minha opinião, fazer com que a Microsoft use o XF internamente em seus aplicativos definitivamente ajudaria.

Novamente, um bom exemplo é essa regressão , para a qual a causa raiz está, na verdade, no Mono e no AndroidX.
Mas também posso mencionar esse problema nas extensões dotnet que afetam os aplicativos iOS, ou mesmo esse problema no msal.
E, claro, esse problema no Visual Studio , em relação ao link da fonte.

As pessoas aqui fizeram um ótimo trabalho dizendo a maior parte do que eu ia dizer em detalhes, então vou ser rápido

Problemas técnicos

  • O Visual Studio trava mais de 3 vezes / minuto ao trabalhar com o XF.
  • Muitos controles básicos estão faltando, ou é preciso muito para moldá-los como deveriam ser.
  • Quando você diz XF, está apenas dizendo a estrutura de plataforma cruzada de pior desempenho, e deixe-me ser claro para as pessoas que dizem que o XF lida com android / ios nativos ... e isso é difícil. Apenas olhe! por favor olhe! pelo amor de Deus! at flutter, RN, NativeScript ... Todos eles têm o mesmo objetivo, mas o XF está muito atrás
  • O hot reload funciona bem apenas quando você cria um novo projeto e torna o texto padrão no lado esquerdo e pronto, então você mesmo!
  • Todos na comunidade do flutter, por exemplo, em cada lançamento, ficam tipo: Oh, meu Deus, é tão legal o que eles fizeram, Por outro lado, o com do XF é assim: Vamos ver o que eles quebraram ou o que adicionaram que apenas 10% do com precisa!
  • Uma jornada inicial usando o XF é uma série de contratempos, um exemplo seria: recentemente eu tive que fazer um dos controles comuns em todos os aplicativos no Playstore que é apenas um ícone de guia inferior simples. Usar o shell com o ícone só tem uma grande margem na parte inferior que parece feia e igual a todos, eu criei um problema, apenas para notar que um problema semelhante foi abordado há mais de 6 meses ... E nenhuma correção no caminho
  • Pense em um app, certo? Qualquer app? Ele tem uma compra no aplicativo ou algum tipo de serviço premium? Claro que sim. Então você começa a procurar um plugin para o google pay e apple pay, certo? Ou mesmo paypale certo? Deixe-me dizer uma coisa, não há !!! Quando você pergunta para a equipe oficial do XF, sabe o que eles vão responder? Eles enviam um link para um plugin desatualizado não oficial criado por um homem (que eu respeito) 2 anos atrás sem atualização, WTF (desculpe) !!

Não técnico

  • Oh, comme ooon, mesmo a documentação oficial é muito pobre, eles abordam recursos de nível de aplicativo de tarefas e tutoriais de instruções
  • Eu odiava o XF antes mesmo de usá-lo, sabe por quê? Todo mundo diz que nem mesmo o MS usa, então por que o F você o usaria?
  • Uma resposta muito lenta para questões e PRs que a comunidade faz no seu tempo e despesas para ajudar a equipe do XF !!!

Soluções

  • A equipe do XF é muito pequena. Como uma empresa grande se a Microsoft não contrata pessoas suficientes para fazer seu próprio produto melhor? Existem talentos em todo o mundo que amam a Microsoft tanto quanto eu!
  • O XF deve resolver problemas de alto nível antes de lançar, ele só mostra o quão imaturo a equipe é, como apenas um navio quem se importa ...
  • A Microsoft é obrigada a usar o XF em seus produtos! Se não é apenas uma maneira de dizer que o XF é bom, mas nah eu não gosto disso yukh
  • Faça uma documentação muito rica! Um médico que é o primeiro a recorrer na maioria das situações, contrate mais gente! é tão fácil quanto isso, há muitos desenvolvedores experientes que fazem um blog com que você pode trabalhar
  • XF não é tão conhecido quanto Flutter, Faça parcerias com os grandes influenciadores de programação no youtube, mesmo uma simples menção ajuda o XF
  • Também é bom olhar para outros produtos e ver o que o desenvolvedor gosta neles e fazer sua própria versão. Flutter, por exemplo.
  • Não tenha medo de perguntar à comunidade o que ela quer, não more debaixo de uma pedra e faça o que ninguém vai usar!

Sinto muito pelo meu comportamento agressivo e meu inglês ruim, eu realmente gosto do XF!
Maui é um novo ponto de partida, por favor, faça dela a nova revolução, todos esperam ser algo grande, então, por favor, não nos decepcione, temos grandes esperanças.

@ Amine-Smahi Entre em contato por e-mail com mais informações sobre o comportamento que leva a travamentos ([email protected]).

Eu concordo totalmente que a correção de bugs e o processo de teste de novos recursos são horríveis.

Por exemplo:
https://github.com/xamarin/Xamarin.Forms/issues/3335 - deixa de usar ListView.RecycleElement
https://github.com/xamarin/Xamarin.Forms/issues/4168 - interrompe o uso de CompressedLayout

Quando você adiciona novos recursos que melhoram o desempenho - isso é ótimo! Mas quando esses recursos estão inutilizáveis, isso é muito decepcionante.

E alguns dos problemas que afetam meus aplicativos e não são corrigidos por muito tempo:
https://github.com/xamarin/AndroidX/issues/64
https://github.com/xamarin/Xamarin.Forms/issues/5087
https://github.com/xamarin/Xamarin.Forms/issues/5127
https://github.com/xamarin/Xamarin.Forms/issues/3168
https://github.com/xamarin/Xamarin.Forms/issues/8058 https://github.com/xamarin/Xamarin.Forms/issues/10055
https://github.com/xamarin/xamarin-android/issues/3341
https://github.com/xamarin/xamarin-android/issues/3480

A equipe deve assumir a responsabilidade pelos recursos que implementam. Por exemplo, @StephaneDelcroix implementou https://github.com/xamarin/Xamarin.Forms/pull/1136. Acho que ele é a pessoa que deve ser designada para https://github.com/xamarin/Xamarin.Forms/issues/4168 e corrigir bugs relacionados ao CompressedLayout.

Sobre a documentação: eu pessoalmente acho que está tudo bem, exceto pelas notas de lançamento, que estão totalmente f * d up;) (sempre atrasadas ou incompletas)
Novamente, não estou falando especificamente sobre o XF, mas de maneira mais geral, toda a estrutura xamarin (xamarin.android, xamarin.ios, visual studio, mono, componentes ...).

Aqui está um exemplo: notas de lançamento do ios xamarin

@melimion

Quando você adiciona novos recursos que melhoram o desempenho - isso é ótimo! Mas quando esses recursos estão inutilizáveis, isso é muito decepcionante.

Isso é absolutamente verdade.
Você adicionou um CollectionView. O resultado é um monte de erros no Android, no iOS geralmente é inutilizável (exceção descartada, exceção NSinconsistency e assim por diante. E isso se você fizer tudo de acordo com os guias oficiais (!).
Você adicionou CarouselView - os erros são os mesmos.
Temos que usar um Listview desatualizado, mas mais estável.

Agora, quando vejo o título "nós adicionamos", imediatamente rolar mais adiante.
E você também tem outros elementos, por exemplo
Swipeview, Expander, que também tem muitos erros.
E há, como a pessoa escreveu acima, estúdio visual mono com seus próprios bugs.

Cancele os novos recursos em 4.7-4.8, preste atenção para correções de bugs.
O desenvolvimento no Xamarin é como encontrar soluções alternativas, soluções temporárias.
Peço desculpas pelo meu pobre inglês

Ontem eu verifiquei. Existem mais de 200 questões marcadas com alto impacto. Não adianta lançar novos recursos, quando bugs críticos ainda não foram resolvidos. Eu concordo com a sugestão anterior. Pare de novos recursos. Reserve um tempo para corrigir e diminuir o número de problemas. Estou preso em 4,4, por exemplo, por causa de um problema. Imagine muito mais pessoas nesta situação. Estabilidade e desempenho vêm em primeiro lugar, se não houver mão de obra para ter IMHO inovação e manutenção.

Eu me pergunto se poderia haver algum tipo de pesquisa entre os desenvolvedores do XF para ver se preferíamos ver um esforço de engenharia indo para limpar os bugs existentes ou adicionar os recursos planejados para 4.7 e posteriores. Quero dizer, os novos recursos por si só adicionarão mais novos bugs, causando mais retrabalho e mais atrasos ... às vezes, um bom e antigo congelamento de recursos é necessário.

Para mim, pessoalmente, gostaria de ver mais esforço indo para o MAUI, que parece uma reconfiguração sensata da arquitetura XF, com o segundo maior esforço indo para limpar bugs de alto impacto. Adicionar novos recursos nem entraria na minha lista - prefiro adicioná-los quando temos uma plataforma melhor para adicioná-los.

@freever concordo totalmente!
Isso não apenas deixará os desenvolvedores atuais do Xamarin mais felizes, mas também resolverá os bugs do MAUI!

Não sei se esses bugs serão realizados para serem corrigidos aqui no MAUI, ou serão corrigidos no Xamarin.Forms.

Acho que @davidortinau abordou o espírito desta questão aqui

https://github.com/dotnet/maui/issues/109#issuecomment -635078640

Eu atualizei a descrição com o comentário dele

Eu realmente quero destacar esta parte do que ele disse novamente para todos

estamos gastando grande parte de nossos sprints atuais em problemas de CollectionView e estamos propondo pausar o desenvolvedor de recursos no Xamarin.Forms 5, portanto, temos de setembro de 2020 a novembro de 2021 para mudar mais o foco para a resolução de problemas.

PureWeen fechou 10 horas atrás

Dezenas de desenvolvedores do xamarin expressaram suas opiniões neste tíquete, e não tenho a sensação de que foram ouvidos.
Infelizmente, você acabou de provar meu ponto de vista

@PureWeen Este problema cobre muito mais do que apenas o número de bugs. Eles são até listados na forma de pontos.

@ tranb3r

Acho que a coisa mais frustrante em relação ao XF é quando nossa contribuição (seja um novo PR, um novo problema ou mesmo uma simples pergunta ou feedback) é simplesmente ignorada pela equipe.

Como o comentário de @davidortinau é insuficiente para você? O ponto principal que estou destacando é que estamos retardando o desenvolvimento de novos recursos para que possamos nos concentrar mais em RPs abertos e bugs e, em seguida, chegar ao .net maui, que será nosso novo produto baseado em .net 6

@ Happypig375

@pauldipietro entrou em contato com a pessoa que postou esse problema para que ele possa começar a abordar essas questões mais diretamente com eles.

O espírito desse problema é que o XF tem muitos bugs e ignora a comunidade. Portanto, estamos desacelerando o novo desenvolvimento para nos concentrar mais nos bugs existentes e nos PRs abertos

Se houver outros problemas fora dos bugs abertos, vamos abrir os problemas deles. Mas esse problema é sobre eles serem muitos bugs abertos e temos um plano para resolver isso.

Com o MAUI, devemos ter um processo de correção de bugs o mais rápido possível. Alguma ideia de como melhorar?

Estamos eliminando vários aspectos legados do Form com .NET Maui e vamos passar este ano antes disso nos concentrando fortemente em bugs e PRs abertos para que possamos ser mais produtivos com .NET Maui

Este é o nosso painel de projeto

https://github.com/xamarin/Xamarin.Forms/projects

Você pode ver o que estamos adicionando a cada sprint
https://github.com/xamarin/Xamarin.Forms/projects/70

Aqui está nosso roteiro
https://github.com/xamarin/Xamarin.Forms/wiki/Feature-Roadmap
Tentamos ser o mais transparentes possível com o que estamos trabalhando

Se os problemas nesses repos forem corrigidos ou tiverem um grande foco, tentamos colocá-los no topo, mas às vezes esses algoritmos não são perfeitos.

@ Amine-Smahi aqui está o painel do projeto para shell e o que vemos como bloqueadores
https://github.com/xamarin/Xamarin.Forms/projects/54

Você pode me apontar o problema ao qual está se referindo para que eu possa dar uma olhada nele?

@PureWeen

Como o comentário de @davidortinau é insuficiente para você? O ponto principal que estou destacando é que estamos retardando o desenvolvimento de novos recursos para que possamos nos concentrar mais em RPs abertos e bugs e, em seguida, chegar ao .net maui, que será nosso novo produto baseado em .net 6

Como mencionado antes, esse problema cobre muito mais do que apenas o número de bugs no XF.

Se houver outros problemas fora dos bugs abertos, vamos abrir os problemas deles. Mas esse problema é sobre eles serem muitos bugs abertos e temos um plano para resolver isso.

Já existem muitos problemas em aberto !!! De que adianta abrir novos se você simplesmente os ignorar ...

Por exemplo, um dos pontos importantes mencionados antes é que as equipes da Microsoft devem usar o xamarin ao desenvolver aplicativos.
Você ouve este feedback? O que devemos fazer para convencê-lo de que esta é uma boa ideia? Devemos abrir uma edição para isso ???

Como mencionado antes, esse problema cobre muito mais do que apenas o número de bugs no XF.

Vamos criar problemas diferentes para eles. Tratar de várias coisas em um único problema não vai ser produtivo.

Que outros comentários aqui que não têm nada a ver com problemas de bugs / prs / fragilidade abertos em torno do XF você deseja esclarecer?

Por exemplo, um dos pontos importantes mencionados antes é que as equipes da Microsoft devem usar o xamarin ao desenvolver aplicativos.
Você ouve este feedback? O que devemos fazer para convencê-lo de que esta é uma boa ideia? Devemos abrir uma edição para isso ???

Sim, tentamos convencer literalmente todos a usar o Xamarin

Conversamos muito com as equipes internas sobre as opções de aplicativos e é uma discussão contínua. Muitas dessas discussões internas também orientarão a direção do .NET Maui.

Não tenho certeza sobre o que mais posso comentar sobre isso. Não há muito que possa ser acionado aqui que eu possa fazer para ajudá-lo especificamente como usuário.

@PureWeen O espírito deste problema é que o XF tem muitos bugs e ignora a comunidade. Portanto, estamos desacelerando o novo desenvolvimento para nos concentrar mais nos bugs existentes e nos PRs abertos

Portanto, esperamos uma taxa um pouco mais rápida de correções de bugs por um tempo. Isso é bom, mas não resolve totalmente esse problema. Levar o XF da qualidade beta para o estável é uma tarefa muito grande e nenhuma solução rápida ou estratégia única conseguirá isso. Serão necessárias grandes mudanças organizacionais, filosóficas e arquitetônicas. Eu sugeriria:

  1. Simplifique o repositório para facilitar a contribuição e a revisão das contribuições. A nova arquitetura de renderizador pode ajudar se deslocar o XAML do núcleo e fornecer uma abordagem mais segura de tipo para os renderizadores.
  2. Priorize as correções de bugs e limpe o código sobre os recursos. Dado que a cultura do Xamarin é adicionar novos recursos enquanto ignora bugs, a melhor maneira é proibir totalmente os novos recursos até que um limite de qualidade seja alcançado para os recursos existentes.
  3. Permitir alterações interrompidas que corrigem bugs e limpam o código.
  4. Faça pleno uso do .Net para reduzir os bugs. Mantenha tudo dentro do sistema de tipos sempre que possível e adote NRTs C # 8.
  5. Fixe os controles mais básicos primeiro , depois os controles restantes.
  6. Elimine os sistemas operacionais de destino antigos e os editores antigos para limpar o repo, agilizar os testes e liberar recursos para correções de bugs.
  7. Relatório sobre uma métrica de bugs pubicly. Isso ajudará a concentrar a organização nos bugs. Coloque o progresso nos bugs como a primeira seção em qualquer blog sobre uma atualização.
  8. Remova recursos para reduzir o tamanho do repositório, para torná-lo mais sustentável.

Nossa experiência: usamos apenas visualizações XF básicas porque não confiamos em nada mais para ser usado. Rótulo, entrada, botão, seletor, switch, DatePicker, controle deslizante, StackLayout, ScrollView, ContentView, Grid, ContentPage. Mas mesmo assim, os insetos aparecem e permanecem por meses. É tão difícil obter correções no XF que, em vez disso, apenas copiamos e colamos os renderizadores em nosso código.

Simplifique o repositório para facilitar a contribuição e a revisão das contribuições. A nova arquitetura de renderizador pode ajudar se deslocar o XAML do núcleo e fornecer uma abordagem mais segura de tipo para os renderizadores.

Esse é o nosso plano. Eu criei um problema de marcador de posição aqui que você pode seguir ou oferecer suas sugestões https://github.com/dotnet/maui/issues/147

Priorize as correções de bugs e limpe o código sobre os recursos. Dado que a cultura do Xamarin é adicionar novos recursos enquanto ignora bugs, a melhor maneira é proibir totalmente os novos recursos até que um limite de qualidade seja alcançado para os recursos existentes.

Este é principalmente o nosso plano.

Permitir alterações interrompidas que corrigem bugs e limpam o código.
Faça pleno uso do .Net para reduzir os bugs. Mantenha tudo dentro do sistema de tipos sempre que possível e adote NRTs C # 8.

Este é lentamente o nosso plano. Mas é importante entender o escopo completo de usuários que usam nossos produtos. Por exemplo, uma vez que quebramos o suporte do vs2017, esse problema apareceu aqui e recebeu muitos comentários de usuários
https://github.com/xamarin/Xamarin.Forms/issues/7602

Portanto, não podemos simplesmente dar o salto. Eu adoraria dar esse salto, mas não podemos simplesmente quebrar as pessoas.

Mas sempre tomamos medidas para estarmos preparados para esse salto. Por exemplo, o PR aqui
https://github.com/xamarin/Xamarin.Forms/pull/10937

Permitirá que eu execute o processo de CI interno para testar o C # 8 e outros recursos beta para que, assim que possamos dar o salto, seja fácil dar o salto.

Fixe os controles mais básicos primeiro, depois os controles restantes.
Elimine os sistemas operacionais de destino antigos e os editores antigos para limpar o repo, agilizar os testes e liberar recursos para correções de bugs.

Esse é o nosso plano, como mencionei acima

Relatório sobre uma métrica de bugs pubicly. Isso ajudará a concentrar a organização nos bugs. Coloque o progresso nos bugs como a primeira seção em qualquer blog sobre uma atualização.

Olhando para isso. @samhouts executa muitos desses relatórios para nós a cada sprint, então temos uma perspectiva de tudo, mas veremos isso melhor para a comunidade.

Remova recursos para reduzir o tamanho do repositório, para torná-lo mais sustentável.

Este é o nosso plano com .net MAUI. Antes de lançarmos nosso plano .NET MAUI, preparamos listas de áreas que podemos reduzir para ser mais eficazes. Uma grande parte disso será o trabalho de renderização.

Olá, além dos problemas mencionados, há muitos bugs relacionados aos idiomas da direita para a esquerda. Parece que esses bugs são de menos importância do ponto de vista da equipe de formulários do Xamarin (provavelmente devido ao menor uso de idiomas da direita para a esquerda do que o inglês ou outros da esquerda para Idiomas corretos), mas a falta de suporte completo para culturas da direita para a esquerda, é desanimador e decepcionante e, na verdade, impede os desenvolvedores de usar o XF em aplicativos internacionais / multilíngues / da direita para a esquerda.
Obrigado.

Próximo problema de dois meses: https://github.com/xamarin/Xamarin.Forms/issues/11166
Bug criado em 22 de junho.
PR foi inaugurado em 25 de junho.
Status do bug 17 de agosto: Ainda não foi fundido. Porque? ; (

@PawKanarek bem-vindo ao Xamarin. geralmente eles mesclam apenas correções ou Prs feitos pela equipe. é por isso que é desanimador contribuir para o Xamarin. Eu acho que eles reduziram a capacidade da equipe. apenas 2-3 pessoas trabalhando ativamente no projeto. se você precisar de uma solução rápida, crie seus próprios pacotes nuget xamarin.

@EmilAlipiev Mas desta vez o PR (para # 11166) foi aberto por um membro da equipe Xamarin e ainda não foi fundido xD

Se você der uma olhada em nossas notas de lançamento e nos insights do GitHub, reunimos toneladas de PRs da comunidade. Na verdade, vejo seu nome na lista mais recente , @EmilAlipiev :)

Você pode ver que, no último mês, 40 novas solicitações pull foram abertas por 18 pessoas diferentes . As solicitações pull devem ser totalmente testadas e revisadas e, com a quantidade que recebemos, temos que priorizar problemas de bloqueio e regressões principais sem soluções alternativas.

Sei que nem sempre somos perfeitos, mas trabalhamos para melhorar a cada dia. Obrigado por sua paciência e por permanecer conosco. Podemos fazer isso juntos!

@ hamiddd1980 Você ficará feliz em saber que temos trabalhado bastante em RTL nos últimos meses. Espero que melhore sua experiência!

@samhouts Lembre-se de que você não é um produto final do Xamarin. Precisamos não apenas de paciência, mas também de muitos recursos humanos e dinheiro. Qualquer bug aberto e verificado no github deve ser consertado o mais rápido possível, pois cria um efeito de bola de neve na forma de dívida técnica, raiva e tensões desnecessárias com nossos clientes.

Corrija mais bugs, não adicione mais recursos. Estabilidade em relação à funcionalidade. Você ainda tem 1.590 bugs verificados https://github.com/xamarin/Xamarin.Forms/issues?q=is%3Aopen+is%3Aissue+-label%3As%2Funverified+label%3A%22t%2Fbug+%3Abug%3A% 22

@samhouts obrigado pela sua resposta. Uma fusão de 1 a 2 por dia é extremamente menor. Eu trabalho em outra ferramenta de plataforma cruzada e eles têm 15 mesclagens por dia 455 mesclagens no mês passado. Eu ainda amo o Xamarin como ferramenta mais e estou disposto a contribuir sempre, mas minha fusão demorou mais de 2 meses e eu tive que criar esta fusão 3 vezes com rebase de um branch diferente.
Ao lado disso, há priorização de questões do seu lado. As pessoas estão procurando desesperadamente por correções para ferramentas essenciais, como bug como Device.Idiom .. ou CollectionView, etc.
Hoje houve um grande progresso, de fato, 8 fusões totais até agora. Mas, para ser honesto, abaixo das mesclagens, menos pessoas estão interessadas no modo de exibição deslizante, pincéis gradientes ou temas, etc. quando há tais PRs críticos na fila por meses. Esta é a maior frustração que eu acredito

image

Qualquer bug aberto e verificado no github deve ser corrigido o mais rápido possível

Isso é obviamente irreal; mesmo que a Microsoft tenha aumentado drasticamente o tamanho da equipe do Xamarin.Forms.
Trabalhe de maneira mais inteligente, não mais difícil, dizem eles (neste caso, isso deve significar exigir que os PRs incluam testes de regressão para garantir que os bugs não reapareçam; no entanto, como com qualquer coisa, isso também é uma compensação, porque as revisões de contribuições PRs ficarão mais longos e mais difíceis).

Corrija mais bugs, não adicione mais recursos

Esta é uma opinião que compartilho também. No entanto, estritamente falando, o plano de transição do MAUI <> Xamarin.Forms já cobre isso: o Xamarin.Forms fará a transição apenas para o modo de correção de bugs, enquanto os novos recursos só chegarão ao Maui.

(neste caso, isso deve significar exigir que os PRs incluam testes de regressão para garantir que os bugs não reapareçam; no entanto, como com qualquer coisa, isso também é uma compensação, porque as revisões dos PRs contribuídos ficarão mais longas e mais difíceis).

Absolutamente. Essa é uma troca com a qual também temos lutado. Temos milhares (!) De testes automatizados e os executamos em vários dispositivos. O problema é que leva horas (atualmente, cerca de 4 horas por execução por dispositivo) para que eles sejam concluídos e, às vezes, infelizmente, um pouco instáveis ​​por uma série de razões. Por exemplo, acabei de enviar um ping a um colaborador ontem sobre um teste que achei que estava falhando legitimamente, apenas para perceber que estava falhando porque o Chrome estava nos pedindo para aceitar os novos termos de serviço. 🤦

Isso leva a muitos atrasos e significa que os RP às vezes podem levar dias apenas para passar nos testes. Isso é por nossa conta e é um problema que precisamos resolver.

Felizmente, _estamos_ trabalhando neste problema. Estamos desenvolvendo um novo método de teste de renderizadores de plataforma mais parecido com testes de unidade do que realmente automatizando a IU, que é muito mais confiável e rápido.

No que diz respeito a adicionar novos recursos versus corrigir bugs ... como diz @knocte , o plano de transição é projetado com isso em mente. Nosso objetivo para o .NET MAUI é ser enxuto, rápido e confiável. Como parte disso, estamos avaliando quais recursos realmente pertencem ao projeto principal e quais recursos são mais adequados para o novo Community Toolkit - que ainda tem o apoio da Microsoft, mas é amplamente suportado pela comunidade.

Saiba que sempre temos você e seus clientes em mente quando fazemos qualquer alteração e estamos ouvindo seus comentários.

Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

jsuarezruiz picture jsuarezruiz  ·  7Comentários

jsuarezruiz picture jsuarezruiz  ·  6Comentários

qcjxberin picture qcjxberin  ·  5Comentários

4creators picture 4creators  ·  31Comentários

ghost picture ghost  ·  7Comentários