Windowscommunitytoolkit: Comment puis-je gérer MasterDetail Back avec NavigationView BackButton ?

@skendrot pourrait peut-être vous aider ici

semble @skendrot est occupé, quelqu'un d'autre peut-il y jeter un œil ? @nmetulev ?

Hé, j'étais en vacances, merci pour le ping supplémentaire. Je ne pense pas que nous nous en occupions actuellement, mais c'est quelque chose dont nous avons parlé. Nous avions parlé d'un moyen de simplement désactiver l'affichage/le masquage/l'utilisation du bouton de retour du système. Mais je pouvais aussi voir que nous pourrions peut-être également intégrer la nouvelle vue de navigation.
Que pensez-vous des éléments suivants :

• Par défaut, utilisez le bouton de retour du système. Si la nouvelle vue de navigation est présente, utilisez-la à la place
• Avoir une option pour désactiver complètement le bouton de retour et permettre au développeur de décider comment cela doit être géré

Nous pourrions également avoir une énumération pour contrôler le bouton de retour
Système, NavigationView, Désactivé

J'aime avoir l'énumération pour contrôler le comportement, cela semble être le moyen le plus convivial pour les développeurs de le gérer. Avoir un moyen de le désactiver complètement et de laisser le développeur gérer la navigation arrière est également logique pour les futurs scénarios que nous ne pouvons pas prendre en charge immédiatement

que diriez-vous d'avoir une énumération pour cela et également de désactiver le bouton de retour du système par défaut, puis les développeurs peuvent l'activer s'ils le souhaitent? Parce que la nouvelle navigation du bouton de retour dans NavigationView est encouragée dans les documents à venir.

OMI, cela créerait un changement de comportement pour les utilisateurs existants à moins que nous ne puissions détecter la nouvelle vue de navigation. @skendrot , qu'en pensez-vous ?

oui, c'est un point juste, garder les utilisateurs existants sous contrôle est également très important, je suis d'accord.

Cela a été mentionné dans le premier commentaire. Gardez les choses telles qu'elles sont, mais voyez si nous avons un nouveau NavigationView en tant que parent visuel. Si c'est le cas, nous devrions simplement l'utiliser pour le bouton de retour au lieu du bouton de retour du système. Je pense que nous devrions toujours fournir un moyen de le désactiver complètement si un développeur veut tout contrôler lui-même

oui, les options @skendrot sont toujours flexibles et toujours

Quelle que soit l'option choisie, je la contrôlerai. Nous devons décider, allons-nous

1. Utilisez le bouton de retour standard et "éclairer" si la nouvelle vue de navigation est en place ET offrez un moyen d'éteindre complètement le bouton de retour
2. Offre une nouvelle option d'énumération qui permet au développeur de choisir entre le bouton de retour standard, le bouton de retour de la vue de navigation et désactiver

Votez 👍 pour 1 et 🎉 pour 2

Je combinerais ces deux éléments et utiliserais l'énumération pour contrôler la façon dont le bouton de retour s'allume en fournissant trois valeurs :

• Automatique - par défaut (il découvre par lui-même comment gérer la navigation arrière)
• Héritage
• Désactivé

Je suggérerais, plutôt que Automatic, Legacy et Off, que vous fournissiez des options d'énumération qui soient claires dans ce qu'elles feront. Par exemple

Comportement du bouton de retour :

• AfficherInline
• UtiliserExterne
• RetourDésactivé

DisplayInline serait par défaut, suivant les instructions d'affichage d'un bouton de retour de style standard dans le contrôle. Cela pourrait également fonctionner avec le bouton B de la manette de jeu ou la touche de retour arrière d'un clavier lorsque le contrôle a le focus.

UseExternal vous permettrait de définir dans le code, un contrôle de bouton retour que vous placez vous-même, le contrôle shell (dans la barre de titre pour les fenêtres standard, ou dans la barre inférieure pour une fenêtre Sets) ou depuis un autre contrôle. Je suppose que vous pourriez permettre de fournir un nom de contrôle en XAML qui déclencherait et remplacerait l'événement appuyé sur le bouton de retour pour ce contrôle.

BackDisabled désactiverait complètement la navigation arrière.

Les développeurs et les projets comme le modèle 10 pourraient alors créer une page ou une page de modèle avec les paramètres en place qui leur permettent de contrôler l'utilisation du bouton de retour.

D'accord avec @mdtauk !

@mdtauk oui, définitivement, cette suggestion a plus de sens et semble plus puissante.

Je suis tout à fait d'accord avec la création d'un bouton de retour à l'intérieur du contrôle, qui correspond au guidage actuel

Cependant, nous devrions également fournir une gestion automatique pour le bouton de retour de NavigationView. Je ne pense pas qu'il soit logique de désactiver également la navigation arrière, cela devrait être quelque chose que l'utilisateur devrait gérer

Voici ma suggestion mise à jour

Énumération : BackButtonHandling

• Automatique (par défaut) - utilise le bouton en ligne à moins qu'un NavigationView ne soit le parent, puis utilise la navigation arrière NavigationView

• En ligne - utilisez le bouton en ligne

• Héritage - nous devons nous assurer que nous prenons en charge le bouton de retour du shell pour les développeurs qui ne s'en sont pas éloignés

• Manuel - laissez l'utilisateur dessiner son propre bouton de retour et le faire comme il le souhaite

Au lieu de Legacy que diriez-vous de System ou SystemAppViewBackButton ou AppView ou autre chose

De plus, pour maintenir la compatibilité descendante et ne pas avoir de changement majeur, la valeur par défaut ne devrait pas être l'option héritée. Ensuite, dans la prochaine version majeure, nous pouvons changer la valeur par défaut pour être automatique

J'aime mieux le système que l'héritage, c'est bien mieux

Je ne suis pas particulièrement satisfait de la valeur par défaut de toute façon puisque la prochaine version est une mise à jour majeure (5.0). Je suis d'accord pour garder la valeur par défaut sur Système, puis changer la valeur par défaut en Automatique dans 6.0.

et il peut y avoir un avis comme avertissement que le bouton de retour du système sera obsolète dans une future version (6.0) quelque chose comme ça? ou le bouton de retour du système sera-t-il toujours une option, même après la sortie des ensembles (probablement dans la version d'avril 2019) ?

Nous ne déprécierons probablement pas le bouton Retour du système tant qu'il ne sera pas déprécié de la plate-forme.

Même avec les ensembles, le bouton de retour du système n'est pas obsolète. Il le placera simplement dans une barre sous les onglets avec un bouton de retour dessus. Mais si Sets est là, vous devez absolument passer à un bouton dans l'application

Bon, je dois préciser : nous ne devrions déprécier l'option de l'énumération que si elle le sera également de la plate-forme (je ne pense pas qu'il soit prévu de le faire)

donc apparemment il y a toute une barre d'outils juste pour 1 backbutton (en cas de sets) ? ou y aura-t-il plus de contrôles de plate-forme dessus ?

donc apparemment il y a toute une barre d'outils juste pour 1 backbutton (en cas de sets) ? ou y aura-t-il plus de contrôles de plate-forme dessus ?

Je ne connais aucun contrôle supplémentaire que le shell ajouterait. Mais c'est parce qu'il s'agit d'une solution loin d'être élégante pour la navigation arrière - que le guide consiste à la gérer dans l'application.

Si vous y réfléchissez, le bouton de retour est situé dans un onglet Ensembles. Il n'apparaîtrait pas à côté des onglets et ne peut donc pas apparaître dans la barre de titre.

oui, il semble juste trop d'espace d'interface utilisateur gaspillé là-bas, juste 1 bouton là-bas.

@touseefbsb Pour le moment, c'est ce que sera le comportement standard si vous choisissez de laisser le Shell gérer le bouton Précédent avec une fenêtre Ensembles. Comme Sets n'est toujours pas inclus dans les versions de Windows, cela peut changer, mais il est préférable de permettre au shell de contrôle/application de gérer le dessin d'un bouton de retour et de s'éloigner de la barre de titre pour le gérer.

Je suis d'accord, c'est pourquoi je pense aussi que s'éloigner de la barre de titre et ne même pas étendre l'application dans la barre de titre du tout aidera l'application à être utilisée correctement avec les ensembles.

Les ensembles peuvent même ne pas arriver à la version 19H1, donc pour le moment, il est important que les applications aient une belle apparence et s'étendent dans les barres de titre lorsque cela est possible. Les développeurs peuvent également choisir de ne pas autoriser leur application à fonctionner avec des ensembles, il est donc logique d'avoir la flexibilité avec le contrôle et de modifier / remplacer la valeur par défaut lors de l'exécution dans un onglet Ensembles. Au moins ça me fait lol

@mdtauk si les développeurs retirent leurs applications des ensembles, cela signifie-t-il que leur application ne sera pas ouverte dans les ensembles ?

@touseefbsb C'est comme ça que je le comprends. Lorsqu'il est ouvert à partir d'un autre onglet, il apparaîtra dans sa propre fenêtre et ne pourra pas non plus être stocké avec d'autres onglets.

Petite complication pour prendre en charge le nouveau NavigationView. Le gestionnaire d'événements BackRequested ne contient aucun moyen d'annuler l'événement ou de marquer qu'il a été géré. Sans cette capacité, MasterDetailsView gérerait le passage des vues Détails aux vues Maître, puis le développeur gérerait également le retour à l'état.
Nous pouvons prendre en charge IFF, une trame est également utilisée pour faciliter la navigation.

@mvegaca , utilisez-vous un cadre pour héberger le contrôle ? Et si au lieu d'essayer de gérer le retour sur le NavView, nous nous occupions d'un cadre (qui devrait également gérer les scénarios en dehors du NavView) ?

Nous gérons déjà la navigation par cadre, ce qui est déjà intégré. Nous ne pouvons tout simplement pas compter sur l'utilisation du nouveau NavigationView à moins qu'il n'y ait également un cadre.

Donc, si WTS utilise un Frame pour sa navigation à l'intérieur de NavView, cela devrait déjà fonctionner ?

Oui, avec des extras indésirables. Le MasterDetailsView activera le bouton de retour du système, ce que WTS ne veut pas. Mais, s'ils gèrent le bouton Précédent de NavigationView en naviguant dans un cadre, le MasterDetailsView interceptera cet événement et, s'il s'agit de l'état Détails réduit, le marquera comme annuler et reviendra à la vue principale.

Nous (WTS) utilisons un cadre à l'intérieur du NavView. Le bouton de retour de navview fonctionne déjà, mais un bouton de retour système supplémentaire s'affiche. Pour gérer la navigation en arrière, nous faisons Frame.GoBack, mais notre problème est le bouton de retour du système affiché avant de revenir en arrière. Donc, je ne sais pas si nous allons bien. Y a-t-il un moyen de tester cela?

Oui, c'est le problème que le PR de

Salut @nmetulev J'essaie de tester le nouveau BackButtonBehaviorProperty dans un clone de référentiel git de @skendrot mais je ne peux pas compiler l'application ciblant directement la bibliothèque.
Pouvez-vous approuver le PR pour tester ces changements dans les packages MyGet CI ?

Merci

@mvegaca J'ai eu le même problème en essayant de tester. Je n'ai pas pu référencer ma copie locale des assemblys. Nous devons comprendre ce qui se passe ici car cela rend les problèmes de test beaucoup plus difficiles

Quels sont les problèmes que vous rencontrez lors du test des assemblages ?

Nous avons ajouté une application PoC dans la solution WCT, supprimé la référence du package nuget et fait référence directement aux projets.
Lorsque je compile le projet, j'ai l'erreur suivante dans tous les fichiers 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.

Cela se produit également si j'ajoute une nouvelle UWP App1 vide à la solution.
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

Merci @nmetulev ;)

Je recommande de construire les nugets localement et de les référencer. Vous pouvez le faire en utilisant le script build\build.ps1 qui devrait générer les nuges dans le dossier bin.

@mvegaca Mêmes problèmes que je voyais

Les projets ne peuvent malheureusement pas être référencés directement car ils dépendent de la configuration de la solution. Pour le développement, j'ai tendance à lier les fichiers source directement dans un nouveau projet car cela semble fonctionner beaucoup mieux et plus rapidement que le développement dans l'exemple d'application. Pour les tests, je construis toujours les nugets localement et je les référence

Nous l'avons testé localement et cela fonctionne bien
Vous pouvez fusionner le PR si tout vous convient.

Merci à tous les gars

RP fusionné

Salut @nmetulev

J'ai essayé de l'utiliser dans la version préliminaire 5.0.0-preview.gb86cb1c4cb mais la propriété BackButtonBehavior n'est pas disponible.

Quand pensez-vous que ce correctif sera disponible sur la version préliminaire et sera disponible sur la version stable ?

Merci

Oui, il sera disponible dans la version 5.0.0 la semaine prochaine. Il est également disponible en pré-version sur MyGet : https://dotnet.myget.org/gallery/uwpcommunitytoolkit