Windowscommunitytoolkit: Como posso lidar com MasterDetail Back com NavigationView BackButton?

@skendrot pode ser capaz de ajudar aqui

parece que @skendrot está ocupado, alguém pode dar uma olhada nisso? @nmetulev ?

Ei, estava de férias, obrigado pelo ping adicional. Não acho que lidamos com isso atualmente, mas é algo sobre o qual temos conversado. Havíamos conversado sobre uma maneira de simplesmente desligar mostrar / ocultar / usar o botão Voltar do sistema. Mas também pude ver que talvez pudéssemos integrar com a nova visualização de navegação também.
O que você acha sobre o seguinte:

• O padrão é usar o botão Voltar do sistema. Se a nova visualização de navegação estiver presente, use-a
• Tem a opção de desligar o botão Voltar completamente e permitir que o desenvolvedor decida como isso deve ser tratado

Também poderíamos ter um enum para controlar o botão Voltar
Sistema, NavigationView, Off

Eu gosto de ter o enum para controlar o comportamento, que parece ser a maneira mais amigável para o desenvolvedor lidar com isso. Ter uma maneira de desligá-lo completamente e deixar o desenvolvedor lidar com a navegação de volta também faz sentido para cenários futuros que não podemos oferecer suporte imediatamente

que tal ter um enum para isso e também desligar o botão Voltar do sistema por padrão e, em seguida, os desenvolvedores podem ligá-lo se quiserem? Porque a nova navegação do botão Voltar em NavigationView está sendo incentivada nos documentos daqui para frente.

IMO, isso criaria uma mudança de comportamento para os usuários existentes, a menos que possamos detectar a nova visualização de navegação. @skendrot , o que você acha?

sim, isso é um ponto justo, manter os usuários existentes sob controle também é muito importante, eu concordo.

Isso foi mencionado no primeiro comentário. Mantenha as coisas como estão, mas veja se temos um novo NavigationView como pai visual. Nesse caso, devemos apenas usá-lo para o botão Voltar, em vez do botão Voltar do sistema. Acho que ainda devemos fornecer uma maneira de desligá-lo completamente se um desenvolvedor quiser controlar tudo sozinho

sim as opções do

Seja qual for a opção decidida, eu colocarei isso no controle. Precisamos decidir, vamos

1. Use o botão Voltar padrão e "acender" se a nova visualização de navegação estiver no lugar E ofereça uma maneira de desligar o botão Voltar completamente
2. Oferece uma nova opção de enum que permite ao desenvolvedor escolher entre o botão Voltar padrão, o botão Voltar de visualização de navegação e desligar

Vote 👍 para 1 e 🎉 para 2

Eu combinaria esses dois e usaria o enum para controlar como o botão Voltar acende, fornecendo três valores:

• Automático - padrão (ele descobre por conta própria como lidar com a navegação traseira)
• Legado
• Desligado

Eu sugeriria que, em vez de Automático, Legado e Desativado, você forneça opções de enum que sejam claras quanto ao que farão. Por exemplo

BackButtonBehaviour:

• DisplayInline
• UseExternal
• BackDisabled

DisplayInline seria o padrão, seguindo a orientação de exibir um botão Voltar com estilo padrão dentro do controle. Isso também pode funcionar com o botão B no gamepad ou a tecla backspace em um teclado quando o controle está em foco.

UseExternal permitiria a você definir no código, um controle de botão Voltar que você mesmo coloca, o controle do shell (na barra de título para janelas padrão ou na barra inferior para uma janela Conjuntos) ou de outro controle. Acho que você poderia tornar possível fornecer um nome de controle em XAML que acionaria e substituiria o evento pressionado do botão Voltar para esse controle.

BackDisabled desabilitaria totalmente a navegação de volta.

Desenvolvedores e projetos como o Modelo 10, podem então criar uma página ou página de modelo com as configurações no local que lhes permitem controlar o uso do botão Voltar.

Concordo com @mdtauk!

@mdtauk sim, definitivamente essa sugestão faz mais sentido e parece mais poderosa.

Estou completamente ok com a criação de um botão Voltar dentro do controle, que combina com a orientação do botão Voltar atual.

No entanto, também devemos fornecer tratamento automático para o botão Voltar NavigationView. Não acho que faça sentido desabilitar a navegação de volta também, isso deve ser algo que o usuário deve fazer

Aqui está minha sugestão atualizada

Enum: BackButtonHandling

• Automático (padrão) - usa o botão embutido, a menos que NavigationView seja o pai e, em seguida, usa a navegação de volta de NavigationView

• Inline - use o botão inline

• Legado - precisamos ter certeza de que oferecemos suporte ao botão de retorno do shell para os desenvolvedores que não se afastaram dele

• Manual - permite que o usuário desenhe seu próprio botão Voltar e faça-o como quiser

Em vez de Legacy que tal System ou SystemAppViewBackButton ou AppView ou algo mais

Além disso, para manter a compatibilidade com versões anteriores, e não ter uma alteração significativa, o padrão não deve ser a opção legada. Então, na próxima versão principal, podemos alterar o padrão para ser automático

Eu gosto mais do sistema do que do legado, é muito melhor

Não estou particularmente preocupado com o valor padrão de qualquer forma, já que a próxima versão é uma atualização principal (5.0). Não há problema em manter o padrão do sistema e, em seguida, alterar o padrão para automático no 6.0.

e pode haver um aviso como um aviso de que o botão Voltar do sistema será descontinuado em uma versão futura (6.0) algo assim? ou o botão Voltar do sistema sempre será uma opção, mesmo depois que os conjuntos forem lançados (provavelmente no lançamento de abril de 2019)?

Provavelmente, não descontinuaremos o botão Voltar do sistema até que ele seja descontinuado na plataforma.

Mesmo com o Sets, o botão Voltar do sistema não está sendo descontinuado. Ele apenas o colocará em uma barra abaixo das guias com um botão Voltar. Mas se Sets estiver lá, você deve absolutamente mudar para um botão no aplicativo

Certo, devo esclarecer: só devemos descontinuar a opção do enum se ela também for descontinuada da plataforma (não acredito que haja planos para fazer isso)

então, aparentemente, há uma barra de ferramentas inteira apenas para 1 backbutton (no caso de conjuntos)? ou haverá mais controles de plataforma nele?

então, aparentemente, há uma barra de ferramentas inteira apenas para 1 backbutton (no caso de conjuntos)? ou haverá mais controles de plataforma nele?

Não conheço nenhum controle adicional que o shell adicionaria. Mas é porque se trata de uma solução longe de ser elegante para Back Navigation - que a orientação é lidar com ela no aplicativo.

Se você pensar sobre isso, o botão Voltar tem como escopo uma guia Conjuntos. Ele não apareceria ao lado das guias e, portanto, não poderia aparecer na barra de título.

sim, parece muito espaço de interface desperdiçado ali, apenas 1 botão ali.

@touseefbsb A partir de agora, esse é o comportamento padrão se você decidir deixar o Shell lidar com o Botão Voltar com uma janela Conjuntos. Como Sets ainda não está incluído nas compilações do Windows, isso pode mudar, mas é melhor habilitar o shell de controle / aplicativo para lidar com o desenho de um botão Voltar e deixar de ter a Barra de Título para lidar com ele.

Eu concordo, é por isso que eu também acho que afastar-se das coisas da barra de título e nem mesmo estender o aplicativo para a barra de título ajudará o aplicativo a ser usado corretamente com conjuntos.

Os conjuntos podem nem chegar ao lançamento do 19H1, então, por enquanto, é importante que os aplicativos tenham uma boa aparência e se estendam para as barras de título, quando possível. Os desenvolvedores também podem optar por não permitir que seu aplicativo funcione com conjuntos, portanto, ter a flexibilidade com o controle e alterar / substituir o padrão ao executar em uma guia Conjuntos faz sentido. Pelo menos faz para mim lol

@mdtauk se os desenvolvedores optam por seus aplicativos fora dos conjuntos, isso significa que o aplicativo não será aberto em conjuntos?

@touseefbsb É assim que eu entendo. Quando aberto a partir de outra guia, ele aparecerá em sua própria janela, não podendo ser armazenado junto com outras guias.

Pequena complicação para suportar o novo NavigationView. O manipulador de eventos BackRequested não contém uma maneira de cancelar o evento ou marcar que ele foi manipulado. Sem essa capacidade, o MasterDetailsView lidaria com a mudança das visualizações Detalhes para as visualizações Mestre e, em seguida, o desenvolvedor lidaria com o retorno ao estado também.
Podemos oferecer suporte a IFF - um quadro também está sendo usado para auxiliar a navegação.

@mvegaca , você usa frame para hospedar o controle? E se, ao invés de tentar manipular de volta no NavView, nós manipularmos de volta em um Frame (que deve lidar com cenários fora do NavView também)?

Já lidamos com a navegação de quadros, então ela já está embutida. Simplesmente não podemos contar com o uso da nova NavigationView, a menos que haja um quadro também

Então, se o WTS estiver usando um Frame para sua navegação dentro do NavView, ele já deve funcionar?

Sim, com extras indesejados. O MasterDetailsView habilitará o botão Voltar do sistema, o que o WTS não deseja. Mas, se eles manipularem o botão Voltar NavigationView navegando em um quadro, o MasterDetailsView capturará esse evento e, se for o estado de Detalhes recolhido, o marcará como cancelado e voltará para a visualização principal.

Nós (WTS) estamos usando um quadro dentro do NavView. O botão de fundo do navview já está funcionando, mas um botão de voltar do sistema extra está aparecendo. Para lidar com a navegação de volta, fazemos Frame.GoBack, mas nosso problema é o botão de voltar do sistema mostrado antes de voltar. Então, não tenho certeza se estamos bem. Existe uma maneira de testar isso?

Sim, esse é o problema que o PR do @skendrot está corrigindo (# 2561). Seria incrível se você pudesse testá-lo também.

Olá @nmetulev , estou tentando testar o novo BackButtonBehaviorProperty em um clone do repositório git do @skendrot, mas não consigo compilar o aplicativo direcionado diretamente para a biblioteca.
Você pode aprovar o PR para testar essas mudanças nos pacotes MyGet CI?

Obrigado

@mvegaca Tive o mesmo problema ao tentar testar. Não consegui fazer referência à minha cópia local das assembleias. Precisamos descobrir o que está acontecendo aqui porque torna os problemas de teste muito mais difíceis

Quais são os problemas que você está tendo ao testar os assemblies?

Adicionamos um aplicativo PoC à solução WCT, removemos a referência do pacote nuget e referenciamos diretamente aos projetos.
Ao compilar o projeto, recebo o seguinte erro em todos os arquivos XAML:

xml C:\dev\skendrot\UWPCommunityToolkit\Issue2475PoC\Issue2475PoC.csproj : XamlCompiler error WMC1013: XAML files 'App.xaml' and 'App.xaml' have the same project path 'App.xaml'. Each file must have a unique project path.

Isso também acontece se eu adicionar um novo UWP App1 vazio à solução.
xml XAML files 'App.xaml' and 'App.xaml' have the same project path 'App.xaml'. Each file must have a unique project path. App1 C:\dev\skendrot\UWPCommunityToolkit\App1\App1.csproj

Obrigado @nmetulev ;)

Eu recomendo construir os nugets localmente e referenciá-los. Você pode fazer isso usando o script build\build.ps1 que deve gerar os nuges na pasta bin.

@mvegaca Mesmos problemas que eu estava vendo

Infelizmente, os projetos não podem ser referenciados diretamente, pois dependem da configuração da solução. Para o desenvolvimento, tendo a vincular os arquivos de origem diretamente no novo projeto, pois isso parece funcionar muito melhor e mais rápido do que o desenvolvimento no aplicativo de amostra. Para testar, eu sempre construo os nugets localmente e faço referência a eles

Testamos localmente e funciona bem 😄
Você pode mesclar o PR se tudo estiver ok para você.

Obrigado a todos galera

PR mesclado

Oi @nmetulev

Tentei usá-lo na versão de pré-lançamento 5.0.0-preview.gb86cb1c4cb, mas a propriedade BackButtonBehavior não está disponível.

Quando você acha que essa correção estará disponível na versão de pré-lançamento e na versão estável?

Obrigado

Sim, ele estará disponível na versão 5.0.0 na próxima semana. Também está disponível em pré-lançamento em MyGet: https://dotnet.myget.org/gallery/uwpcommunitytoolkit