Windowscommunitytoolkit: ¿Cómo puedo manejar MasterDetail Back con NavigationView BackButton?

@skendrot podría ayudar aquí

Parece que @skendrot está ocupado, ¿puede alguien más echarle un vistazo? @nmetulev ?

Oye, estaba de vacaciones, gracias por el ping adicional. No creo que actualmente manejemos esto, pero es algo de lo que hemos estado hablando. Habíamos hablado sobre una forma de simplemente desactivar mostrar / ocultar / usar el botón de retroceso del sistema. Pero también pude ver que quizás también podríamos integrarnos con la nueva vista de navegación.
¿Qué opinas sobre lo siguiente?

• De forma predeterminada, se utiliza el botón de retroceso del sistema. Si la nueva vista de navegación está presente, úsela en su lugar
• Tener la opción de apagar el botón de retroceso por completo y permitir que el desarrollador decida cómo se debe manejar.

También podríamos tener una enumeración para controlar el botón de retroceso.
Sistema, NavigationView, desactivado

Me gusta tener la enumeración para controlar el comportamiento, que parece la forma más amigable para el desarrollador de manejarlo. Tener una forma de apagarlo por completo y dejar que el desarrollador maneje la navegación hacia atrás también tiene sentido para escenarios futuros que no podemos admitir de inmediato.

¿Qué tal tener una enumeración para esto y también desactivar el botón de retroceso del sistema de forma predeterminada y luego los desarrolladores pueden activarlo si lo desean? Porque la nueva navegación con el botón Atrás dentro de NavigationView se recomienda en los documentos en el futuro.

En mi opinión, eso crearía un cambio de comportamiento para los usuarios existentes a menos que podamos detectar la nueva vista de navegación. @skendrot , ¿qué te parece?

sí, ese es un punto justo, mantener a los usuarios existentes bajo control también es muy importante, estoy de acuerdo.

Eso fue mencionado en el primer comentario. Mantenga las cosas como están, pero vea si tenemos un nuevo NavigationView como padre visual. Si es así, deberíamos usarlo para el botón de retroceso en lugar del botón de retroceso del sistema. Creo que aún deberíamos proporcionar una forma de desactivarlo por completo si un desarrollador quiere controlar todo por sí mismo.

sí, las opciones de tenerlas , especialmente cuando se hace una transición importante. Entonces, ¿cómo debería avanzar esto ahora?

Cualquiera que sea la opción que se decida, la controlaré. Necesitamos decidir, vamos a

1. Utilice el botón de retroceso estándar y "enciéndalo" si la nueva vista de navegación está en su lugar Y ofrezca una forma de apagar el botón de retroceso por completo
2. Ofrece una nueva opción de enumeración que permite al desarrollador elegir entre el botón de retroceso estándar, el botón de retroceso de la vista de navegación y desactivar

Vote 👍 por 1 y 🎉 por 2

Combinaría estos dos y usaría la enumeración para controlar cómo se ilumina el botón de retroceso al proporcionar tres valores:

• Automático: predeterminado (descubre por sí mismo cómo manejar la navegación hacia atrás)
• Legado
• Apagado

Sugeriría que, en lugar de Automático, Heredado y Desactivado, proporcione opciones de enumeración que sean claras en lo que harán. Por ejemplo

BackButtonBehaviour:

• DisplayInline
• UseExternal
• AtrásDiscapacitado

DisplayInline sería el predeterminado, siguiendo la guía de mostrar un botón de retroceso con estilo estándar dentro del control. Esto también podría funcionar con el botón B en el gamepad o la tecla de retroceso en un teclado cuando el control tiene el foco.

UseExternal le permitiría establecer en código, un control de botón de retroceso que coloque usted mismo, el control de shell (en la barra de título para ventanas estándar, o en la barra inferior para una ventana de Conjuntos) o desde otro control. Supongo que podría hacer posible proporcionar un nombre de control en XAML que desencadenaría y anularía el evento de botón de retroceso presionado para ese control.

BackDisabled deshabilitaría la navegación hacia atrás por completo.

Los desarrolladores y proyectos como la Plantilla 10 podrían crear una página o una página de plantilla con la configuración establecida que les permita controlar el uso del botón Atrás.

¡De acuerdo con @mdtauk!

@mdtauk sí, definitivamente esta sugerencia tiene más sentido y parece más poderosa.

Estoy completamente de acuerdo con la creación de un botón de retroceso dentro del control, que coincide con la guía actual del

Sin embargo, también deberíamos proporcionar manejo automático para el botón de retroceso de NavigationView. No creo que tenga sentido deshabilitar la navegación hacia atrás también, eso debería ser algo que el usuario debería manejar

Aquí está mi sugerencia actualizada

Enum: BackButtonHandling

• Automático (predeterminado): usa el botón en línea a menos que un NavigationView sea el principal, y luego use la navegación hacia atrás NavigationView

• En línea : use el botón en línea

• Legacy : debemos asegurarnos de que admitimos el botón de retroceso del shell para aquellos desarrolladores que no se han alejado de él.

• Manual : permite que el usuario dibuje su propio botón de retroceso y lo haga como quiera

En lugar de Legacy ¿qué tal System o SystemAppViewBackButton o AppView o algo más?

Además, para mantener la compatibilidad con versiones anteriores y no tener un cambio importante, la opción predeterminada no debería ser la heredada. Luego, en la próxima versión principal, podemos cambiar el valor predeterminado para que sea automático

Me gusta más el sistema que el legado, eso es mucho mejor

No estoy particularmente interesado en el valor predeterminado de ninguna manera, ya que la próxima versión es una actualización importante (5.0). Estoy de acuerdo con mantener el valor predeterminado en Sistema y luego cambiar el valor predeterminado a Automático en 6.0.

y puede haber un aviso como advertencia de que el botón Atrás del sistema quedará obsoleto en una versión futura (6.0) ¿algo así? ¿O el botón de retroceso del sistema siempre será una opción, incluso después de que se publiquen los conjuntos (probablemente en la versión de abril de 2019)?

Probablemente no desaprovechemos el botón Atrás del sistema hasta que esté desaprobado en la plataforma.

Incluso con Sets, el botón de retroceso del sistema no está en desuso. Simplemente lo colocará en una barra debajo de las pestañas con un botón de retroceso. Pero si Sets está allí, definitivamente debería cambiar a un botón en la aplicación

Bien, debo aclarar: solo deberíamos desaprobar la opción de la enumeración si también se desaprobará en la plataforma (no creo que haya planes para hacerlo)

entonces, aparentemente, hay una barra de herramientas completa solo para 1 botón trasero (en el caso de conjuntos). ¿O habrá más controles de plataforma?

entonces, aparentemente, hay una barra de herramientas completa solo para 1 botón trasero (en el caso de conjuntos). ¿O habrá más controles de plataforma?

No conozco ningún control adicional que agregaría el shell. Pero es porque esta es una solución lejos de ser elegante para la navegación hacia atrás, que la guía es manejarla en la aplicación.

Si lo piensa, el botón de retroceso tiene como alcance una pestaña de conjuntos. No aparecería junto a las pestañas, por lo que no puede aparecer en la barra de título.

sí, parece demasiado espacio de interfaz de usuario desperdiciado allí, solo 1 botón allí.

@touseefbsb A partir de ahora, ese es el comportamiento estándar si eliges dejar que el Shell maneje el Botón Atrás con una ventana Conjuntos. Como Sets aún no está incluido en las compilaciones de Windows, esto puede cambiar, pero es mejor habilitar el control / shell de la aplicación para manejar el dibujo de un botón de retroceso y dejar de tener la barra de título que lo maneje.

Estoy de acuerdo, es por eso que también creo que alejarse de las cosas de la barra de título y ni siquiera extender la aplicación a la barra de título ayudará a que la aplicación se use correctamente con los conjuntos.

Es posible que los conjuntos ni siquiera lleguen a la versión 19H1, por lo que, por el momento, es importante que las aplicaciones se vean bien y se extiendan a las barras de título cuando sea posible. Los desarrolladores también pueden optar por no permitir que su aplicación funcione con Conjuntos, por lo que tiene sentido tener la flexibilidad con el control y alterar / anular el valor predeterminado cuando se ejecuta en una pestaña Conjuntos. Al menos a mi me hace lol

@mdtauk si los desarrolladores optan por excluir sus aplicaciones de los conjuntos, ¿significa eso que su aplicación no se abrirá en conjuntos?

@touseefbsb Así es como lo entiendo. Cuando se abre desde otra pestaña, aparecerá en su propia ventana, y tampoco podrá almacenarse junto con otras pestañas.

Pequeña complicación para admitir el nuevo NavigationView. El controlador de eventos BackRequested no contiene una forma de cancelar el evento o marcar que se ha manejado. Sin esta capacidad, MasterDetailsView manejaría el movimiento de las vistas Detalles a las vistas Maestras y luego el desarrollador también se encargaría de volver al estado.
Podemos admitir IFF. También se está utilizando un marco para ayudar a la navegación.

@mvegaca , ¿usas un marco para alojar el control? ¿Qué pasa si, en cambio, intentamos volver a manejar en NavView, lo hacemos en un Frame (que también debería manejar escenarios fuera de NavView)?

Ya manejamos la navegación por marcos, por lo que ya está integrada. No podemos confiar en el uso de la nueva NavigationView a menos que también haya un marco

Entonces, si WTS está usando un marco para su navegación dentro de NavView, ¿ya debería funcionar?

Sí, con extras no deseados. MasterDetailsView habilitará el botón de retroceso del sistema, que WTS no quiere. Pero, si manejan el botón de retroceso de NavigationView navegando en un marco, MasterDetailsView detectará ese evento y, si es el estado de Detalles contraído, lo marcará como cancelado y volverá a la vista maestra.

Nosotros (WTS) estamos usando un marco dentro de NavView. El botón de retroceso de navview ya está funcionando, pero se muestra un botón de retroceso adicional del sistema. Para manejar la navegación hacia atrás, hacemos Frame.GoBack, pero nuestro problema es el botón de retroceso del sistema que se muestra antes de volver. Entonces, no estoy seguro de si estamos bien. ¿Hay alguna forma de probar esto?

Sí, ese es el problema que las relaciones públicas de @skendrot están solucionando (# 2561). Sería asombroso si pudieras probarlo también.

Hola @nmetulev Estoy tratando de probar el nuevo BackButtonBehaviorProperty en un clon del repositorio de git de @skendrot pero no puedo compilar la aplicación dirigida directamente a la biblioteca.
¿Puede aprobar el PR para probar estos cambios en los paquetes de MyGet CI?

Gracias

@mvegaca Tuve el mismo problema al intentar probar. No pude hacer referencia a mi copia local de los ensamblajes. Necesitamos averiguar qué está pasando aquí porque hace que los problemas de prueba sean mucho más difíciles.

¿Cuáles son los problemas que tiene al probar los ensamblajes?

Hemos agregado una aplicación PoC en la solución WCT, eliminamos la referencia del paquete nuget y la referencia directamente a los proyectos.
Cuando compilo el proyecto, recibí el siguiente error en todos los archivos 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.

Esto también sucede si agrego una nueva UWP App1 vacía a la solución.
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

Gracias @nmetulev ;)

Recomiendo construir los nugets localmente y hacer referencia a ellos. Puede hacerlo usando el script build\build.ps1 que debería generar los nuges en la carpeta bin.

@mvegaca Los mismos problemas que estaba viendo

Desafortunadamente, los proyectos no pueden ser referenciados directamente, ya que dependen de la configuración de la solución. Para el desarrollo, tiendo a vincular los archivos de origen directamente en un nuevo proyecto, ya que parece funcionar mucho mejor y más rápido que el desarrollo en la aplicación de muestra. Para las pruebas, siempre construyo los nugets localmente y hago referencia a esos

Lo hemos probado localmente y funciona bien 😄
Puede fusionar el PR si todo está bien para usted.

Gracias a todos chicos

PR fusionado

Hola @nmetulev

Intenté usarlo en la versión preliminar 5.0.0-preview.gb86cb1c4cb pero la propiedad BackButtonBehavior no está disponible.

¿Cuándo cree que esta corrección estará disponible en la versión preliminar y estará disponible en la versión estable?

Gracias

Sí, estará disponible en la versión 5.0.0 la próxima semana. También está disponible en versión preliminar en MyGet: https://dotnet.myget.org/gallery/uwpcommunitytoolkit