Xamarin.forms: Uwp Xamarin.Forms.Shell

O suporte Shell é fornecido apenas para Android e iOS no momento. Estamos avaliando continuamente os comentários sobre o possível suporte UWP futuro e forneceremos mais informações no futuro, assim que estiverem disponíveis.

Eu normalmente uso iOS e Android para meus usuários de telefone e UWP para meus usuários de tablet e desktop. Portanto, ter suporte UWP será muito importante para manter os usuários do Windows engajados.

O que?? A MS está realmente abandonando sua própria plataforma. É triste ouvir isso!

Não há visibilidade de quando o suporte UWP será fornecido? Ou a decisão já foi tomada?

Suporte shell para UWP - por favor!

Também gostaria de ver o suporte UWP para o Shell.

Para minha empresa, o UWP é muito importante porque nossos clientes usam tablets Windows em combinação com alguns telefones Android para realizar seu trabalho. Não poderemos migrar para o Shell se o suporte UWP estiver ausente.

Concordado - a compatibilidade com UWP permite que eu aproveite a capacidade do tablet do Windows com minha implementação móvel. Eu teria que codificar isso completamente separadamente sem ele. Que nojo! A compatibilidade com UWP é obrigatória!

Não sei se faz sentido, porque ainda não usei o Shell. Mas talvez haja uma maneira de usar todos os outros elementos do aplicativo (além do Shell) para uma implementação UWP. Afinal, usar TabbedPage e MasterDetailPage resultaria na mesma coisa, ao que parece.

Eu também votaria pela capacidade de usar UWP com Shell.

UWP, por favor ... ou pelo menos algum sabor da API UX da Microsoft da qual podemos depender por alguns anos. Essa abordagem de "avisaremos se pudermos oferecer suporte mais tarde" é apenas maldosa.

Então, sim, UWP ou qualquer outra coisa irá apoiá-lo, mas o mais importante: UM COMPROMISSO DE QUANDO SABEREMOS SE OU QUANDO.

Não posso mudar para a Shell sem essa certeza.

Não apenas UWP, mas também MacOS, por favor.

Não sei se você percebeu que UWP não é apenas uma plataforma que ainda é amplamente usada por desenvolvedores, mas também a maneira mais rápida de colocar aplicativos XF baseados em Android e iOS em funcionamento. Porque - em comparação - os emuladores fornecidos para o Android e o mundo do Mac são extremamente lentos, propensos a problemas e não vamos falar sobre a experiência de certificação horrível ou ainda sendo forçados a ter um Mac de verdade por perto, certo? Portanto, embora não possa substituir o desenvolvimento na realidade, um aplicativo UWP aumenta a produtividade do desenvolvedor, oferecendo uma maneira rápida, fácil e abrangente de fazer ... as coisas ... serem feitas. E então: Faça o que for necessário para colocar seu aplicativo em execução no iOS e Android também.

Então, você pode adicionar suporte a shell para UWP?

https://github.com/xamarin/Xamarin.Forms/pull/6015

Concordo com @Mephisztoe , é realmente uma ótima ferramenta de produtividade e, claro, a opção de disponibilizar o aplicativo para Windows também é uma boa vantagem :)

Por favor, não relegue Xamarin.Forms apenas para plataformas móveis. Eu gostaria de ver o suporte continuado especialmente para UWP, mas também para WPF e GTK #.

Então, basicamente, qualquer pessoa que tenha um aplicativo que é multiplataforma para todas as três plataformas no Xamarin Forms no momento não pode atualizar e usar esses recursos. Se o desenvolvimento futuro no Xamarin Forms para UWP não acontecerá, por que não apenas remover o UWP da lista de plataforma cruzada?

Plataformas diferentes sempre terão prioridades diferentes. Afinal, você disse "todas as três plataformas", não "todas as sete plataformas".

@GalaxiaGuy isso mesmo, eu disse todas as três plataformas, considerando que se eu dissesse sete plataformas, estaria criando plataformas imaginárias. De acordo com a documentação do Xamarin.Forms:

Xamarin.Forms
O Xamarin.Forms expõe um kit de ferramentas de interface do usuário de plataforma cruzada completo para desenvolvedores .NET. Crie aplicativos totalmente nativos para Android, iOS e plataforma universal do Windows usando C # no Visual Studio.

E no leia-me diz:

O Xamarin.Forms fornece uma maneira de construir rapidamente aplicativos nativos para iOS, Android, Windows e macOS, completamente em C #.

Isso não significa que também não suporte GTK, WPF e Tizen.

Concordo que essas plataformas são provavelmente menos importantes do que UWP, mas há muitas pessoas que pensam que UWP é menos importante do que iOS e Android.

No entanto, geralmente concordo com o sentimento e estou tendo que ignorar os recursos mais recentes porque eles não estão no UWP.

Para sua informação, a menos que eu esteja lendo as notas de lançamento incorretamente, parece que há uma implementação ShellRenderer para o Tizen na versão 4.1. Nenhuma menção de UWP.

Se a solicitação pull de @dotMorten demorar um pouco para se fundir, talvez alguém possa pegar essa implementação e movê-la para um pacote NuGet de "pré-lançamento" separado gerenciado pela comunidade até / se obtermos suporte oficial. Dessa forma, podemos usá-lo sem usar um pré-lançamento completo ou uma compilação personalizada do Xamarin.Forms. Se não tivermos suporte oficial, o repo já estará configurado e a comunidade poderá assumir o controle.

Lamento que isso não tenha sido mais rápido. Eu cheguei a algumas regressões ao sincronizar com o master, e estou completamente atolado com coisas relacionadas ao trabalho e à família, então simplesmente não tive muito tempo para sentar e tentar resolver isso. No entanto, estou mais do que feliz em fazer relações públicas para o meu ramo.

Também usaremos o shell assim que estiver disponível no UWP. Temos o mesmo problema acima. Temos um mix de tablets, telefones e notebooks com android e windows. E também achamos que o melhor ambiente de desenvolvimento é UWP

Esse problema é um dos principais motivos pelos quais desisti do XF. Para nossos clientes, desktop e mobile têm a mesma prioridade.

O que posso dizer que ainda não foi dito ..

então CONTINUE COM ISSO!
O suporte UWP não é opcional para a Microsoft - você realmente precisa saber disso?

@papiermache , observe que o código de conduta se aplica a todas as comunicações, questões e comentários sobre este projeto

Também tratar isso como um teste do compromisso do MS Xamarin com os desenvolvedores. Alguém do lado da MS está pronto para pesar?

Desculpe a todos, vai moderar mais pensamentos ... mas eu fiquei totalmente pasmo ao descobrir a falta de suporte UWP - nunca me ocorreu que UWP não seria uma plataforma incluída desde o início. Rick.

De: Jeremy [email protected]
Enviado: 16 de agosto de 2019 14h28
Para: xamarin / Xamarin.Forms [email protected]
Cc: Rick Piovesan [email protected] ; Mencione mençã[email protected]
Assunto: Re: [xamarin / Xamarin.Forms] Uwp Xamarin.Forms.Shell (# 5593)

@papiermache https://github.com/papiermache observe que o código de conduta se aplica a todas as comunicações, questões e comentários sobre este projeto

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, vê-lo no GitHub https://github.com/xamarin/Xamarin.Forms/issues/5593?email_source=notifications&email_token=ABJC5GJKYHEGIOR3P2UIKX3QE4EVLA5CNFSM4G7ANE7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4PT3PQ#issuecomment-522141118 , ou silenciar o fio https://github.com/ notificações / unsubscribe-auth / ABJC5GKCHSPBRJ5JNNEVD5LQE4EVLANCNFSM4G7ANE7A .

Olá @dotMorten , pode dar alguma atualização? Você ainda está planejando tentar fazer o UPW + Shell funcionar? Entenda que é um ato de gentileza e comunidade :) Apenas me perguntando, já que seus esforços parecem estar mais próximos de fazer o Shell + UWP funcionar. Ainda completamente perplexo com o que parece ser um pivô da Microsoft longe do suporte do Windows com o Xamarin. Grato por todas as outras bondades, mas ainda perplexo e frustrado.

Desculpe. Meio que queimado agora, então não visitei isso novamente. Lembro-me de que a fusão com o mais recente causou muitas regressões e simplesmente não tive tempo nem energia para trazê-lo de volta à velocidade. Também identifiquei várias coisas que precisariam ser alteradas e exigiriam uma aceitação mais ampla da equipe do XF, mas não obteve muito suporte além de "com certeza, vamos dar uma olhada nisso" e então morreu. Geralmente, o suporte e feedback que recebi da equipe do XF foram apenas incentivos, mas com um pouco de falta de seguimento. Ainda estou esperando por feedback sobre o trabalho que fiz, mas neste ponto provavelmente está muito desatualizado. Espero ter algum tempo e energia em breve para voltar a fazer isso.

Este problema está atualmente entre os 10 itens abertos mais comentados, mas não está no roteiro para ser concluído.

@pauldipietro podemos obter uma atualização sobre isso? Parece-me estar enviando um sinal de que o suporte UWP não é mais uma prioridade para a equipe do XF. Se isso for verdade, diga-nos para que possamos fazer planos em relação a isso.

Obrigado

Concordo, eu só quero saber se o XF não incluirá suporte para Windows. Se não, também quero saber porque não? Eles sabem qual será a "próxima" pilha do UX do Windows além de UWP e não querem desperdiçar ciclos? Alguma coisa do Blazor / HTML será a próxima peça? Em caso afirmativo, deixe-me saber para que eu possa fazer a transição ... Talvez para a plataforma uno?

De: Scott Kuhl [email protected]
Enviado: quinta-feira, 22 de agosto de 2019 13h21:22
Para: xamarin / Xamarin.Forms [email protected]
Cc: David Gerding [email protected] ; Comentário [email protected]
Assunto: Re: [xamarin / Xamarin.Forms] Uwp Xamarin.Forms.Shell (# 5593)

Este problema está atualmente entre os 10 itens abertos mais comentados, mas não está no roteiro para ser concluído.

@pauldipietro https://github.com/pauldipietro podemos obter uma atualização sobre isso? Parece-me estar enviando um sinal de que o suporte UWP não é mais uma prioridade para a equipe do XF. Se isso for verdade, diga-nos para que possamos fazer planos em relação a isso.

Obrigado

-
Você está recebendo isto porque comentou.
Responda a este e-mail diretamente, vê-lo no GitHub https://github.com/xamarin/Xamarin.Forms/issues/5593?email_source=notifications&email_token=AAD7YD4EYE5XBBSXIR6MGV3QF3KKFA5CNFSM4G7ANE7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD456VUI#issuecomment-524020433 , ou silenciar o fio https://github.com/ notificações / unsubscribe-auth / AAD7YD42CJSV4KS5ZFWWJU3QF3KKFANCNFSM4G7ANE7A .

Francamente, me parece que a melhor aposta seria substituir o XF pela plataforma Uno ...

Xamarin deixou claro que seu alvo são principalmente dispositivos móveis (telefones, tablets, relógios), não desktops ou laptops.

Eles não têm interesse em apoiar e manter o UWP por conta própria, de modo que não é bom recomendar aos meus clientes.

Quero esclarecer minha necessidade: não preciso do _UWP_ para o Xamarin Forms. Preciso de _algumas unidades de destino do Windows_ para o Xamarin Forms. UWP parece ser o candidato mais viável. Se eu tivesse que adivinhar, a Microsoft acabaria mudando para o cliente HTML e Blazor para desktops, pois isso poderia dar a eles o mais amplo alcance de experiência do usuário em um mundo pós-Windows. Isso também pode se encaixar melhor com um caminho de shell combinável (não shell xf). Na ausência de qualquer roteiro coerente para o lado do Windows de UX, não posso imaginar o que mais eles podem estar planejando.

Mas, para ser claro, abandonar o suporte do Windows para Xamarin sem anunciar em grandes letras em negrito, "NÃO FAZEMOS E NÃO FAREMOS WINDOWS", é, no mínimo, muito, muito cruel. Soa da "velha Microsoft".

@davidortinau et al: Por favor, faça algo mais do que apontar para os agora efetivamente mortos (veja a última postagem de @dotMorten ) "suporte da comunidade para XF Shell + Windows".

Estou muito grato por todas as coisas novas e legais em Xamarin. Mas preciso de uma resposta mais honesta sobre a viabilidade futura, se houver, dos alvos do Windows usando o Xamarin.

várias coisas que precisariam mudar e exigir uma aceitação mais ampla da equipe do XF

Eu sei que um deles tem a ver com WinUI, que esperamos puxar como uma dependência com este PR
https://github.com/xamarin/Xamarin.Forms/pull/7214

Esse PR mantém a compatibilidade de 16299 e, pelos meus testes, funciona muito bem quando está incluído com um nuget e não exige que o usuário instale o WinUI. Eu ainda preciso ter 16299 rodado em uma VM para ter certeza, mas estou otimista. Eu sei, @dotMorten, que você expressou algumas preocupações sobre como puxar no WinUI, então se eu os ignorei totalmente, por favor me avise :-)

Aqui está essa pepita.

Xamarin.Forms.4.3.0.1853.zip

Se mais alguém quiser testá-lo para nós, informe-nos se houver algum problema que possa ser realmente útil. Eu testei com o modelo UWP básico e funciona bem para mim, sem travamentos.

O caminho que vejo para isso atualmente é

• obter # 7214 mesclado para que possamos cuidar da dependência WinUI
• obter a base de PR do UWP Shell (temos isso agendado para um sprint futuro, então faremos isso então ou se outra pessoa nos antecipar)
• O Morten já o tem funcionando com Gastropods, então só queremos testá-lo com mais alguns exemplos (principalmente Xaminals), uma vez que estiver funcionando e fizermos qualquer alteração de limpeza de código necessária, iremos mesclar

Se estiver faltando alguma coisa com esse caminho, me avise e tentaremos resolver o problema, então tudo o que precisa ser feito é um rebase e uma verificação contra Xaminals.

@PureWeen ,
Posso executar o App132.zip com o Nuget Xamarin que você forneceu. O aplicativo parece funcionar bem ... presumindo que ele deve adicionar elementos com carimbo de data / hora ao controle da lista. Tanto o botão na parte superior quanto o comportamento Puxar para atualizar adicionam elementos.

Não tenho certeza do que estou procurando, mas agradeço seus esforços e tentarei ajudar como puder.

Dave G

@PureWeen Ótimo ver que você está avançando com o WinUI. A dependência do WinUI estava criando comportamentos de quebra para mim, pois o WinUI estava adicionando uma dependência que não era adicionada transitivamente. Isso pode ser corrigido se você usar o VS2019, mas não tenho certeza se o WinUI já tirou proveito desse recurso (e ainda afetará os usuários do VS2017, mas pelo menos tem uma solução alternativa).
Além disso, havia bugs no WinUI que me causaram muitas dores de cabeça, mas notei recentemente que alguns dos que registrei foram corrigidos, o que é encorajador. Envie-me um ping assim que o 7214 entrar e tentarei iniciar esse esforço.
Também adoraria ajudar com a rebase. Da última vez que fiz isso, baguncei totalmente essa RP :-)

@dotMorten Parece bom !!

Eu testei o aplicativo que incluí acima no VS 2017 e funcionou para mim, então acho que estamos bem nesse aspecto

Não tenho certeza do que estou procurando, mas agradeço seus esforços e tentarei ajudar como puder.

O principal seria adicionar o nuget ao seu projeto UWP principal e apenas garantir que todos pareçam compilar e executar bem.

Apenas tentar verificar se a adição de uma dependência WINUI não vai causar nenhuma dor de cabeça :-)

Eu testei o aplicativo que incluí acima no VS 2017

Sem também adicionar WinUI ao cabeçalho do projeto? Este é o problema que encontrei: se as pessoas atualizassem para uma versão do XF que dependa do WinUI, isso não funcionaria sem adicionar manualmente uma dependência ao WinUI. IMHO isso é uma mudança significativa. O WinUI pode alterar seu pacote para que funcione implicitamente, mas exigiria o VS2019, pois depende de um recurso do NuGet 5.0 (e, afaik, eles não fizeram essa alteração, então não funcionará em nenhum deles agora).

Aqui está o problema que registrei no WinUI: https://github.com/microsoft/microsoft-ui-xaml/issues/596#issuecomment -524187369

Eu poderia apenas fazer um PR rápido para pelo menos abordar isso para que os usuários do VS2019 não precisem adicionar manualmente a dependência extra.

Só adicionando isso quando testei o app123, ele estava com o VS2019.

Sem também adicionar WinUI ao cabeçalho do projeto?

Sim, o projeto que vinculei acima posso abrir dentro do VS2017 e ele compila e funciona bem. Não tenho o nuget WinUI adicionado ao cabeçote UWP, ele só é indicado como uma dependência dentro do nuspec

Eu realmente não entendo como isso funciona. Há um estilo que precisa ser adicionado e um pacote de estrutura appx extra que precisa ser instalado com o pacote, e tudo é feito por .targets. O pacote do framework já está instalado em sua máquina?

A Visual Studio Magazine apenas abordou esse problema em particular. Microsoft, é hora de uma resposta oficial.

https://visualstudiomagazine.com/articles/2019/08/23/xamarin-forms-4-2.aspx

@dotMorten Estou fora por alguns dias, mas vou cuidar disso quando voltar. Também entrei em contato com a equipe WinUI para revisar

Este alvo funciona bem transitivamente quando testei no VS 2017
https://github.com/microsoft/microsoft-ui-xaml/blob/8f8cd0fe32754cfcd83dafb2fc8539703b6aec26/build/NuSpecs/MUXControls-Nuget-Common.targets#L6

Aqui está um nuget atualizado que permite sobrescrever a configuração em seu projeto de formulários local
Xamarin.Forms.4.3.0.1853.zip

<SkipMicrosoftUIXamlCheckTargetPlatformVersion>false</SkipMicrosoftUIXamlCheckTargetPlatformVersion>

No projeto de formulários, forçamos isso a ser verdadeiro para não surpreender as pessoas.

https://github.com/xamarin/Xamarin.Forms/pull/7214/files#diff -5e6292d5925c776aa9aa6d6f8c63ddf6R19

@PureWeen Esta é a parte que deve funcionar sem adicionar essas linhas explicitamente (já que todos os usuários teriam que atualizar seus cabeçalhos de projeto também):

Acho que você está dizendo que funciona, mas certifique-se de que estamos na mesma página.

Pode ser que você considere esta uma alteração de interrupção aceitável, mas lembro que isso aconteceu recentemente com outra dependência e confundiu muitas pessoas, já que o caminho de atualização não é tão limpo quanto apenas escolher uma nova versão do XF.

Re: a necessidade de um alvo desktop / laptop / tablet para o Xamarin Forms

Para aqueles de nós que estão criando aplicativos móveis em ambientes corporativos, a capacidade de produzir um executável de desktop / laptop "semelhante ao trabalho" a partir da mesma base de código básica do Android / iOS é essencial. Não precisa ser apenas Windows (um destino baseado em navegador, como HTML / JS seria tão bom), mas a grande maioria de nossos usuários tem um desktop / laptop Windows + iPhone / telefone Android, então um executável Windows é bem na maior parte.

Descobrimos que, quando disponibilizamos um aplicativo móvel dentro da organização, a maioria dos nossos usuários deseja experimentá-lo em seus laptops / desktops primeiro - e apenas se o acharem útil ou adequado às suas necessidades, eles se dignarão a colocá-lo em seus telefones. Além disso, obter a adesão (e feedback) do usuário funciona significativamente melhor se eles puderem inserir dados ou resultados de consulta de desktop ou dispositivo, dependendo de onde estão trabalhando naquele momento específico.

O Xamarin Forms funciona bem para esses cenários e realmente gostaríamos de usar o Shell e o CollectionView, mas eles são de uso prático para nós até que possam ser usados ​​para produzir um desktop / laptop semelhante ...

@dotMorten, então o motivo pelo qual não estou vendo a exceção é que tenho o WinUI como uma dependência do nuget, portanto, se você instalar o XF no cabeçote UWP, o WinUI virá comigo e aplicará seus alvos.

Isso faz com que o próprio pacote XF tenha que ser instalado no projeto principal UWP para funcionar. Testei meu exemplo acima tendo o XF instalado apenas no projeto netstandard e fui capaz de recriar sua exceção.

Já falamos um pouco sobre isso nesta edição
https://github.com/xamarin/Xamarin.Forms/issues/4126

Isso é rompido se as pessoas só tiverem o XF instalado na biblioteca compartilhada e não no projeto principal UWP. Precisamos discutir isso um pouco para ver o que queremos fazer a respeito

@pureween ok bom. Ainda bem que estamos vendo a mesma coisa então. Algumas coisas a serem consideradas em suas discussões:

• Se meu PR no WinUI for mesclado, afetará apenas os usuários do VS2017 (o que, entretanto, pode ficar estranho se uma equipe usar ambos e só afetar alguns usuários).
• Você pode detectar isso durante Init () e lançar um erro que informa aos usuários exatamente o que fazer para que a dor não seja tão ruim.
• Eu estava brincando com a ideia de que o XF tem um arquivo de destino que adiciona a dependência ao projeto de referência se ainda não estiver presente, mas poderia
  crie uma experiência de desenvolvimento estranha.
• Todos os projetos UWP sempre usarão essa dependência quando o WinUI for separado da plataforma (mas, a essa altura, o VS2017 provavelmente não terá mais suporte).
  
  
  
  • Você será capaz de oferecer suporte a versões anteriores do Win10 com esta mudança, criando um valor agregado que pode justificá-lo.
  
  
  • Ninguém vai notar porque, de acordo com sua equipe, ninguém realmente usa UWP de qualquer maneira 😜 j / k
  
  

Mais uma abordagem possível: Detectar se o WinUI é referenciado durante a inicialização, mas deixe o aplicativo rodar. Em vez disso, qualquer renderizador que dependa do WinUI lançaria, portanto, isso afetará apenas os usuários desses novos recursos. Portanto, a história se torna "Se você deseja usar Shell ou PullToRefresh, você também deve adicionar uma referência ao WinUI (se estiver no VS2017)".

@dotMorten Obrigado por todos os seus esforços em trazer a Shell para a UWP! Isso é muito necessário e deveria ser tratado pela equipe principal do Xamarin.

Aqui está uma amostra do Xaminals rodando em UWP com CV e Shell !!!

Ótimo trabalho!

Trabalho fantástico. Iremos incluí-lo em nossa estrutura para a construção de aplicativos de nível empresarial assim que for lançado

Bom trabalho, vou tentar em uma versão futura do meu aplicativo ;)

Sim, Xamarin conseguiu! Li um cara dizendo que mudamos para Uno. Não!!!! Xamarin tem sido ótimo para nós e nos poupou muito tempo para ter que aprender swift + java. Vamos ser pacientes com a equipe e apoiá-los

fechado por # 6015

Bom trabalho, obrigado por toda equipe <3, vou virar 💃

Ótimo trabalho, muito obrigado!

OK algo estranho está acontecendo, eu atualizei meu projeto para usar o 4.3.0.947036, agora o projeto falha ao chamar forms.init com
'Não foi possível encontrar o tipo do Windows Runtime' Microsoft.UI.Xaml.Controls.XamlControlsResources

O que é muito estranho é a quantidade de código agora encontrada no XamlTypeInfo.g.cs, na versão anterior do Xamarin tínhamos apenas 13 entradas, agora temos mais de 43. Instalei o Win.UI Nuget no projeto e ainda está não ajuda. Alguma ideia

@ abrantie1z - (embora fora do tópico, pensei em mencionar) Os formulários Uno e Xamarin não precisam mais ser uma escolha mutuamente exclusiva - consulte https://platform.uno/xamarin-forms/ e https: / /visualstudiomagazine.com/articles/2019/09/19/uno-platform-2.aspx Advertência: Eu não usei o Uno, então não tenho ideia de quão robusto é esse suporte. Mas qualquer coisa que faça com que mais pessoas se interessem pelo XF em navegadores é uma coisa boa.