Windowscommunitytoolkit: Wie kann ich MasterDetail Back mit NavigationView BackButton handhaben?

@skendrot kann hier vielleicht helfen

@skendrot scheint beschäftigt zu sein, kann sich jemand anders das ansehen? @nmetulew ?

Hey, war im Urlaub, danke für den zusätzlichen Ping. Ich glaube nicht, dass wir derzeit damit umgehen, aber wir haben darüber gesprochen. Wir hatten über eine Möglichkeit gesprochen, das Anzeigen/Ausblenden/Verwenden der System-Zurück-Taste einfach zu deaktivieren. Aber ich konnte auch sehen, dass wir uns vielleicht auch in die neue Navigationsansicht integrieren könnten.
Was denkst du über Folgendes:

• Standardmäßig wird die Zurück-Taste des Systems verwendet. Wenn die neue Navigationsansicht vorhanden ist, verwenden Sie sie stattdessen
• Sie haben die Möglichkeit, die Zurück-Schaltfläche vollständig auszuschalten und dem Entwickler zu überlassen, wie dies gehandhabt werden soll

Wir könnten auch eine Aufzählung haben, um die Zurück-Taste zu steuern
System, NavigationAnsicht, Aus

Ich mag es, die Aufzählung zu haben, um das Verhalten zu steuern, das scheint die entwicklerfreundlichste Art zu sein, damit umzugehen. Eine Möglichkeit zu haben, es vollständig abzuschalten und dem Entwickler die Rücknavigation zu überlassen, ist auch für zukünftige Szenarien sinnvoll, die wir nicht sofort unterstützen können

Wie wäre es, wenn Sie dafür eine Aufzählung haben und auch die Zurück-Schaltfläche des Systems standardmäßig deaktivieren und Entwickler sie dann aktivieren können, wenn sie möchten? Weil die neue Zurück-Button-Navigation in NavigationView in den zukünftigen Dokumenten gefördert wird.

IMO, das würde zu einer Verhaltensänderung für bestehende Benutzer führen, es sei denn, wir können die neue Navigationsansicht erkennen. @skendrot , was denkst du?

Ja, das ist ein fairer Punkt, es ist auch sehr wichtig, bestehende Benutzer in Schach zu halten, da stimme ich zu.

Das wurde im ersten Kommentar erwähnt. Behalten Sie die Dinge bei, wie sie sind, aber sehen Sie, ob wir eine neue NavigationView als visuelles übergeordnetes Element haben. Wenn ja, sollten wir das einfach für den Zurück-Button anstelle des System-Zurück-Buttons verwenden. Ich denke, wir sollten immer noch eine Möglichkeit bieten, es vollständig abzuschalten, wenn ein Entwickler alles selbst kontrollieren möchte

ja @skendrot- Optionen sind immer flexibel und immer gut zu haben, besonders wenn Sie einen größeren Übergang machen. Wie soll es nun weitergehen?

Welche Option auch immer entschieden wird, ich werde das in die Hand nehmen. Wir müssen uns entscheiden, gehen wir?

1. Verwenden Sie die Standard-Zurück-Taste und "leuchten", wenn die neue Navigationsansicht vorhanden ist UND bieten Sie eine Möglichkeit, die Zurück-Taste vollständig auszuschalten
2. Bieten Sie eine neue Aufzählungsoption an, mit der der Entwickler zwischen der Standard-Zurück-Schaltfläche, der Navigationsansicht-Zurück-Schaltfläche und Aus wählen kann

Stimme 👍 für 1 und 🎉 für 2

Ich würde diese beiden kombinieren und die Aufzählung verwenden, um zu steuern, wie die Zurück-Taste aufleuchtet, indem ich drei Werte bereitstelle:

• Automatisch - Standard (es findet selbst heraus, wie die Rückwärtsnavigation gehandhabt wird)
• Erbe
• aus

Ich würde vorschlagen, dass Sie anstelle von Automatisch, Legacy und Aus Aufzählungsoptionen bereitstellen, deren Funktionsweise klar ist. Zum Beispiel

ZurückButtonVerhalten:

• AnzeigeInline
• VerwendenExtern
• ZurückDisabled

DisplayInline wäre die Standardeinstellung und folgt der Anleitung zum Anzeigen einer standardmäßigen Zurück-Schaltfläche im Steuerelement. Dies könnte auch mit der B-Taste auf dem Gamepad oder der Rücktaste auf einer Tastatur funktionieren, wenn das Steuerelement den Fokus hat.

UseExternal würde es Ihnen ermöglichen, in Code, ein Back-Button-Steuerelement, das Sie selbst platzieren, das Shell-Steuerelement (in der Titelleiste für Standardfenster oder in der unteren Leiste für ein Sets-Fenster) oder von einem anderen Steuerelement aus zu setzen. Ich denke, Sie könnten es ermöglichen, einen Steuerelementnamen in XAML anzugeben, der das Ereignis "Zurück-Schaltfläche gedrückt" für dieses Steuerelement auslöst und überschreibt.

BackDisabled würde die Rückwärtsnavigation vollständig deaktivieren.

Entwickler und Projekte wie Template 10 könnten dann eine Seite oder Vorlagenseite mit den Einstellungen erstellen, die es ihnen ermöglichen, die Verwendung der Zurück-Schaltfläche zu steuern.

Stimme @mdtauk zu!

@mdtauk ja definitiv ist dieser Vorschlag sinnvoller und scheint mächtiger zu sein.

Ich bin völlig in Ordnung mit dem Erstellen einer Zurück-Schaltfläche innerhalb des Steuerelements, die mit der aktuellen Anleitung für die

Wir sollten jedoch auch eine automatische Behandlung für die NavigationView-Zurück-Schaltfläche bereitstellen. Ich denke nicht, dass es sinnvoll ist, auch die Rückwärtsnavigation zu deaktivieren, das sollte der Benutzer handhaben

Hier ist mein aktualisierter Vorschlag

Aufzählung: BackButtonHandling

• Automatisch (Standard) - verwendet die Inline-Schaltfläche, es sei denn, eine NavigationView ist die übergeordnete, und verwenden Sie dann die NavigationView-Rücknavigation

• Inline - Verwenden Sie die Inline-Schaltfläche

• Legacy - Wir müssen sicherstellen, dass wir die Shell-Zurück-Schaltfläche für diejenigen Entwickler unterstützen, die sich nicht davon entfernt haben

• Manuell - Lassen Sie den Benutzer seinen eigenen Zurück-Button zeichnen und tun Sie es, wie er möchte

Anstelle von Legacy wie wäre es mit System oder SystemAppViewBackButton oder AppView oder etwas anderem?

Um die Abwärtskompatibilität aufrechtzuerhalten und keine bahnbrechenden Änderungen vorzunehmen, sollte nicht die Standardoption die Legacy-Option sein. Dann können wir in der nächsten Hauptversion die Standardeinstellung auf automatisch ändern

Ich mag System besser als Legacy, das ist viel besser

Ich bin nicht besonders gespannt auf den Standardwert, da die nächste Version ein größeres Update (5.0) ist. Ich bin damit einverstanden, die Standardeinstellung auf System beizubehalten und dann die Standardeinstellung in 6.0 auf Automatisch zu ändern.

und es kann einen Hinweis als Warnung geben, dass die System-Zurück-Schaltfläche in einer zukünftigen Version (6.0) veraltet sein wird. oder wird der System-Zurück-Button immer eine Option sein, auch nach der Veröffentlichung der Sets (wahrscheinlich in der Veröffentlichung im April 2019)?

Wir werden die System-Zurück-Schaltfläche wahrscheinlich nicht verwerfen, bis sie von der Plattform veraltet ist.

Auch bei Sets ist die Zurück-Schaltfläche des Systems nicht veraltet. Es wird es einfach in eine Leiste unter den Registerkarten mit einer Zurück-Schaltfläche platzieren. Aber wenn Sets da ist, solltest du unbedingt auf einen In-App-Button umsteigen

Richtig, ich sollte klarstellen: Wir sollten die Option aus der Enumeration nur dann verwerfen, wenn sie auch von der Plattform verworfen wird (ich glaube nicht, dass dies geplant ist).

Also gibt es anscheinend eine ganze Symbolleiste nur für 1 Backbutton (bei Sets)? oder wird es mehr Plattformkontrollen geben?

Also gibt es anscheinend eine ganze Symbolleiste nur für 1 Backbutton (bei Sets)? oder wird es mehr Plattformkontrollen geben?

Ich kenne keine zusätzlichen Steuerelemente, die die Shell hinzufügen würde. Aber es liegt daran, dass dies eine alles andere als elegante Lösung für die Rückwärtsnavigation ist - die Anleitung besteht darin, sie in der App zu handhaben.

Wenn Sie darüber nachdenken, befindet sich die Zurück-Schaltfläche innerhalb einer Registerkarte "Sets". Es würde nicht neben Registerkarten angezeigt und kann daher nicht in der Titelleiste angezeigt werden.

Ja, es sieht einfach zu viel verschwendeter UI-Platz aus, nur 1 Taste dort.

@touseefbsb Ab sofort ist dies das Standardverhalten, wenn Sie die Shell die Zurück-Schaltfläche mit einem Sets-Fenster behandeln lassen. Da Sets immer noch nicht in Windows-Builds enthalten ist, kann sich dies ändern, aber es ist besser, die Control- / App-Shell zu aktivieren, um das Zeichnen einer Zurück-Schaltfläche zu verarbeiten und sich von der Titelleiste zu entfernen.

Ich stimme zu, deshalb denke ich auch, dass die Abkehr von Titelleisten-Zeug und die Erweiterung der App in die Titelleiste überhaupt nicht dazu beitragen, dass die App mit Sets richtig verwendet wird.

Sets schaffen es möglicherweise nicht einmal bis zum 19H1-Release, daher ist es vorerst wichtig, dass Apps gut aussehen und sich nach Möglichkeit in Titelleisten erstrecken. Entwickler können auch entscheiden, dass ihre App nicht mit Sets arbeiten darf. Daher ist es sinnvoll, die Flexibilität bei der Steuerung zu haben und die Standardeinstellung bei der Ausführung auf einer Registerkarte "Sets" zu ändern / zu überschreiben. Zumindest tut es mir das lol

@mdtauk Wenn Entwickler ihre Apps aus Sets entfernen, bedeutet dies, dass ihre App nicht in Sets geöffnet wird?

@touseefbsb So verstehe ich das. Wenn es von einem anderen Tab geöffnet wird, erscheint es in einem eigenen Fenster und kann auch nicht zusammen mit anderen Tabs gespeichert werden.

Kleine Komplikation zur Unterstützung des neuen NavigationView. Der Ereignishandler BackRequested enthält keine Möglichkeit, das Ereignis abzubrechen oder zu markieren, dass es behandelt wurde. Ohne diese Fähigkeit würde die MasterDetailsView das Wechseln von Details zu Master-Ansichten handhaben, und dann würde der Entwickler auch das Zurückkehren in den Zustand übernehmen.
Wir können auch IFF unterstützen, wenn ein Frame verwendet wird, um die Navigation zu erleichtern.

@mvegaca , verwenden Sie einen Frame, um das Steuerelement zu hosten? Was ist, wenn wir stattdessen versuchen, auf dem NavView zurück zu handeln, sondern auf einem Frame (der auch Szenarien außerhalb des NavView verarbeiten sollte)?

Wir handhaben die Frame-Navigation bereits, also ist sie bereits integriert. Wir können uns einfach nicht darauf verlassen, die neue NavigationView zu verwenden, es sei denn, es gibt auch einen Frame

Wenn WTS also einen Frame für die Navigation innerhalb des NavView verwendet, sollte es bereits funktionieren?

Ja, mit unerwünschten Extras. Die MasterDetailsView aktiviert die Zurück-Schaltfläche des Systems, die WTS nicht möchte. Wenn sie jedoch die NavigationView-Zurück-Schaltfläche durch Navigieren in einem Frame verarbeiten, fängt die MasterDetailsView dieses Ereignis ab, und wenn es sich um den minimierten Details-Zustand handelt, markiert sie es als Abbrechen und wechselt zurück zur Master-Ansicht.

Wir (WTS) verwenden einen Rahmen im NavView. Die Navview-Zurück-Schaltfläche funktioniert bereits, aber eine zusätzliche System-Zurück-Schaltfläche wird angezeigt. Um die Rückwärtsnavigation zu handhaben, verwenden wir Frame.GoBack, aber unser Problem ist die System-Zurück-Schaltfläche, die vor dem Zurückgehen angezeigt wird. Ich bin mir also nicht sicher, ob es uns gut geht. Gibt es eine Möglichkeit das zu testen?

Ja, das ist das Problem, das die PR von @skendrot behebt (#2561). Wäre toll, wenn du es auch testen könntest.

Hallo @nmetulev Ich versuche, die neue BackButtonBehaviorProperty in einem Git-Repository-Klon von @skendrot zu testen, aber ich kann die App nicht kompilieren, die direkt auf die Bibliothek
Können Sie den PR genehmigen, um diese Änderungen in MyGet CI-Paketen zu testen?

Vielen Dank

@mvegaca Ich hatte das gleiche Problem beim Testen. Ich konnte nicht auf meine lokale Kopie der Assemblys verweisen. Wir müssen herausfinden, was hier vor sich geht, weil es das Testen viel schwieriger macht

Welche Probleme haben Sie beim Testen der Baugruppen?

Wir haben der WCT-Lösung eine PoC-App hinzugefügt, die Nuget-Paketreferenz entfernt und direkt auf die Projekte verwiesen.
Beim Kompilieren des Projekts habe ich in allen XAML-Dateien folgenden Fehler erhalten:

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.

Dies geschieht auch, wenn ich der Lösung eine leere neue UWP App1 hinzufüge.
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

Danke @nmetulev ;)

Ich empfehle, die Nugets lokal zu erstellen und darauf zu verweisen. Sie können dies tun, indem Sie das Skript build\build.ps1 verwenden, das die Nuges im bin-Ordner generieren soll.

@mvegaca Dieselben Probleme, die ich gesehen habe

Die Projekte können leider nicht direkt referenziert werden, da sie von der Lösungskonfiguration abhängen. Für die Entwicklung neige ich dazu, die Quelldateien direkt in neue Projekte zu verlinken, da dies viel besser und schneller zu funktionieren scheint als die Entwicklung in der Beispiel-App. Zum Testen baue ich die Nugets immer lokal und verweise auf diese

Wir haben es vor Ort getestet und es funktioniert einwandfrei 😄
Sie können die PR zusammenführen, wenn alles in Ordnung für Sie ist.

Danke an alle Jungs

PR fusioniert

Hallo @nmetulev

Ich habe versucht, es in der Vorabversion 5.0.0-preview.gb86cb1c4cb zu verwenden, aber die Eigenschaft BackButtonBehavior ist nicht verfügbar.

Wann wird dieser Fix Ihrer Meinung nach in der Vorabversion und in der stabilen Version verfügbar sein?

Vielen Dank

Ja, es wird nächste Woche in der Version 5.0.0 verfügbar sein. Es ist auch als Vorabversion auf MyGet verfügbar: https://dotnet.myget.org/gallery/uwpcommunitytoolkit