Windowscommunitytoolkit: NavigationView BackButton으로 MasterDetail Back을 어떻게 처리할 수 있습니까?

@skendrot 이 여기에서 도움이 될 수 있습니다.

@skendrot 이 바쁜 것 같습니다. 다른 사람이 볼 수 있습니까? @nmetulev ?

헐 휴가중이었는데 추가핑 감사합니다. 현재 우리가 이 일을 처리하고 있다고 생각하지 않지만, 우리가 하려고 하는 것에 대해 이야기하고 있습니다. 우리는 시스템 뒤로 버튼 표시/숨기기/사용을 끄는 방법에 대해 이야기했습니다. 그러나 새로운 탐색 보기와도 통합할 수 있다는 것도 알 수 있었습니다.
다음에 대해 어떻게 생각하십니까?

• 기본값은 시스템 뒤로 버튼을 사용하는 것입니다. 새 탐색 보기가 있는 경우 대신 사용하십시오.
• 뒤로 버튼을 완전히 끄고 개발자가 이를 처리하는 방법을 결정할 수 있는 옵션이 있습니다.

뒤로 버튼을 제어하는 ​​열거형을 가질 수도 있습니다.
시스템, NavigationView, 끄기

저는 동작을 제어하기 위해 열거형을 사용하는 것을 좋아합니다. 이것이 개발자에게 가장 친숙한 처리 방법인 것 같습니다. 이 기능을 완전히 끄고 개발자가 뒤로 탐색을 처리하도록 하는 방법은 우리가 즉시 지원할 수 없는 미래 시나리오에도 의미가 있습니다.

이것에 대한 열거형을 갖고 기본적으로 시스템 뒤로 버튼을 끄고 개발자가 원할 경우 켤 수 있는 것은 어떻습니까? NavigationView 내의 새로운 뒤로 버튼 탐색이 앞으로 문서에서 권장되기 때문입니다.

IMO, 새 탐색 보기를 감지할 수 없는 경우 기존 사용자의 동작 변경을 생성합니다. @skendrot , 어떻게 생각하세요?

네 맞습니다. 기존 사용자를 확인하는 것도 매우 중요합니다. 저도 동의합니다.

첫 댓글에서 언급한 내용입니다. 있는 그대로 유지하되 시각적 부모로 새 NavigationView가 있는지 확인하십시오. 그렇다면 시스템 뒤로 버튼 대신 뒤로 버튼에 이를 사용해야 합니다. 개발자가 모든 것을 스스로 제어하려는 경우 완전히 끌 수 있는 방법을 제공해야 한다고 생각합니다.

예 @skendrot 옵션은 항상 유연하며 주요 전환을 할 때 특별히 사용하는 것이 좋습니다. 그렇다면 지금은 어떻게 나아가야 할까요?

어떤 선택이 결정되든 나는 그것을 통제할 것이다. 우리는 결정해야 합니다.

1. 새 탐색 보기가 있는 경우 표준 뒤로 버튼과 "밝기"를 사용하고 뒤로 버튼을 완전히 끄는 방법을 제공합니다.
2. 개발자가 표준 뒤로 버튼, 탐색 보기 뒤로 버튼 및 끄기 중에서 선택할 수 있는 새로운 열거형 옵션 제공

1에 👍, 2에 🎉 투표

이 두 가지를 결합하고 열거형을 사용하여 세 가지 값을 제공하여 뒤로 버튼이 켜지는 방식을 제어합니다.

• 자동 - 기본값(뒤로 탐색을 처리하는 방법을 자체적으로 파악함)
• 유산
• 끄다

자동, 레거시 및 끄기보다는 그들이 수행할 작업에 대해 명확한 열거형 옵션을 제공하는 것이 좋습니다. 예를 들어

BackButton동작:

• 디스플레이 인라인
• 외부 사용
• 뒤로 비활성화

DisplayInline 은 컨트롤 내에 표준 스타일의 뒤로 버튼을 표시하는 지침에 따라 기본값이 됩니다. 이것은 게임패드의 B 버튼이나 컨트롤에 포커스가 있을 때 키보드의 백스페이스 키와 함께 작동할 수도 있습니다.

UseExternal 을 사용하면 코드에서, 사용자가 직접 배치한 뒤로 버튼 컨트롤, 셸 컨트롤(표준 창의 경우 제목 표시줄, 집합 창의 경우 하단 표시줄) 또는 다른 컨트롤에서 설정할 수 있습니다. 해당 컨트롤에 대해 뒤로 버튼 누름 이벤트를 트리거하고 재정의하는 XAML에서 컨트롤 이름을 제공할 수 있다고 생각합니다.

BackDisabled 는 뒤로 탐색을 완전히 비활성화합니다.

템플릿 10과 같은 개발자 및 프로젝트는 뒤로 버튼 사용을 제어할 수 있는 설정이 있는 페이지 또는 템플릿 페이지를 만들 수 있습니다.

@mdtauk에 동의하십시오!

@mdtauk 네 확실히 이 제안이 더 합리적이고 더 강력해 보입니다.

현재 뒤로 버튼 안내 와 일치하는 컨트롤 내부에 뒤로 버튼을 만드는 데 완전히 문제가 없습니다.

그러나 NavigationView 뒤로 버튼에 대한 자동 처리도 제공해야 합니다. 뒤로 탐색도 비활성화하는 것이 합리적이지 않다고 생각합니다. 사용자가 처리해야 하는 부분입니다.

다음은 업데이트된 제안입니다.

열거형: BackButtonHandling

• 자동 (기본값) - NavigationView가 부모가 아닌 경우 인라인 버튼을 사용하고 NavigationView 뒤로 탐색을 사용합니다.

• 인라인 - 인라인 버튼 사용

• 레거시 - 아직 벗어나지 않은 개발자를 위해 셸 뒤로 버튼을 지원해야 합니다.

• 수동 - 사용자가 자신의 뒤로 버튼을 그리고 원하는 대로 하도록 합니다.

Legacy 대신 System 또는 SystemAppViewBackButton 또는 AppView 또는 기타

또한 이전 버전과의 호환성을 유지하고 주요 변경 사항이 없도록 하려면 기본값이 레거시 옵션이 되어서는 안 됩니다. 그런 다음 다음 주요 버전에서 기본값을 auto로 변경할 수 있습니다.

나는 레거시보다 시스템이 더 좋아, 그게 훨씬 낫다

나는 다음 버전이 주요 업데이트(5.0)이기 때문에 어느 쪽이든 기본값에 대해 특별히 관심을 두지 않습니다. 기본값을 시스템으로 유지한 다음 6.0에서 기본값을 자동으로 변경해도 괜찮습니다.

시스템 뒤로 버튼이 향후 릴리스(6.0)에서 더 이상 사용되지 않을 것이라는 경고로 알림이 있을 수 있습니까? 아니면 세트가 출시된 후에도(아마도 2019년 4월 출시) 시스템 뒤로 버튼이 항상 옵션이 될 것입니까?

플랫폼에서 더 이상 사용되지 않을 때까지 시스템 뒤로 버튼을 사용하지 않을 것입니다.

세트를 사용하더라도 시스템 뒤로 버튼은 더 이상 사용되지 않습니다. 뒤로 버튼이있는 탭 아래의 막대에 배치됩니다. 그러나 세트가 있는 경우 앱 내 버튼으로 절대 전환해야 합니다.

맞습니다. 분명히 해야 합니다: 열거형 옵션이 플랫폼에서도 사용되지 않는 경우에만 사용하지 않아야 합니다(그렇게 할 계획은 없다고 생각합니다).

그래서 분명히 1 backbutton ( 세트의 경우 ) 에 대한 전체 도구 모음이 있습니까 ? 아니면 더 많은 플랫폼 컨트롤이 있습니까?

그래서 분명히 1 backbutton ( 세트의 경우 ) 에 대한 전체 도구 모음이 있습니까 ? 아니면 더 많은 플랫폼 컨트롤이 있습니까?

쉘이 추가할 추가 컨트롤에 대해 알지 못합니다. 그러나 이것은 Back Navigation에 대한 우아한 솔루션과 거리가 멀기 때문입니다. 지침은 앱에서 처리하는 것입니다.

생각해보면 뒤로 버튼의 범위는 세트 탭 내에 있습니다. 탭 옆에 표시되지 않으므로 제목 표시줄에 표시되지 않습니다.

예, 거기에는 너무 많은 UI 공간이 낭비되는 것처럼 보입니다. 거기에는 버튼이 1개뿐입니다.

@touseefbsb 현재

동의합니다. 그래서 제목 표시줄에서 벗어나 앱을 제목 표시줄로 확장하지 않는 것이 앱이 세트와 함께 적절하게 사용되는 데 도움이 될 것이라고 생각하는 이유이기도 합니다.

세트는 19H1 릴리스에 도달하지 못할 수도 있으므로 당분간은 앱이 보기 좋게 표시되고 가능한 경우 제목 표시줄로 확장되는 것이 중요합니다. 개발자는 또한 앱이 세트와 함께 작동하지 않도록 선택할 수 있으므로 컨트롤을 유연하게 사용하고 세트 탭에서 실행할 때 기본값을 변경/재정의하는 것이 합리적입니다. 적어도 나에게 그것은 롤

@mdtauk 개발자가 앱을 세트에서 제외하면 앱이 세트로 열리지 않는다는 의미인가요?

@touseefbsb 그렇게 이해합니다. 다른 탭에서 열면 자체 창에 나타나며 다른 탭과 함께 저장할 수도 없습니다.

새로운 NavigationView를 지원하는 작은 복잡성. BackRequested 이벤트 핸들러에는 이벤트를 취소하거나 처리되었음을 표시하는 방법이 없습니다. 이 기능이 없으면 MasterDetailsView는 세부 정보에서 마스터 보기로의 이동을 처리한 다음 개발자는 상태로 돌아가는 것도 처리합니다.
우리는 탐색을 돕기 위해 프레임이 사용되는 IFF를 지원할 수 있습니다.

@mvegaca , 프레임을 사용하여 컨트롤을 호스팅합니까? NavView에서 다시 처리하려고 하는 대신 Frame에서 다시 처리하면(NavView 외부의 시나리오도 처리해야 함) 어떻게 될까요?

우리는 이미 프레임 탐색을 처리하므로 이미 내장되어 있습니다. 프레임이 없으면 새 NavigationView 사용에 의존할 수 없습니다.

따라서 WTS가 NavView 내부의 탐색에 프레임을 사용하는 경우 이미 작동해야 합니까?

예, 원치 않는 추가 기능이 있습니다. MasterDetailsView는 WTS가 원하지 않는 시스템 뒤로 버튼을 활성화합니다. 그러나 프레임에서 탐색하여 NavigationView 뒤로 버튼을 처리하는 경우 MasterDetailsView는 해당 이벤트를 포착하고 축소된 세부 정보 상태인 경우 취소로 표시하고 마스터 보기로 다시 이동합니다.

우리(WTS)는 NavView 내부의 프레임을 사용하고 있습니다. navview 뒤로 버튼이 이미 작동하고 있지만 추가 시스템 뒤로 버튼이 표시됩니다. 뒤로 탐색을 처리하기 위해 Frame.GoBack을 수행하지만 문제는 뒤로 돌아가기 전에 표시되는 시스템 뒤로 버튼입니다. 그래서 우리가 괜찮은지 잘 모르겠습니다. 이것을 테스트하는 방법이 있습니까?

네, @skendrot 의 PR이 수정하고 있는 문제입니다(#2561). 당신도 그것을 테스트 할 수 있다면 그것은 놀라운 것입니다.

안녕하세요 @skendrot의 자식 저장소 복제의 새로운 BackButtonBehaviorProperty을 테스트하기 위해 노력하고있어 @nmetulev 그러나 나는 도서관에 직접 대상 응용 프로그램을 컴파일 할 수 없습니다.
MyGet CI 패키지에서 이 변경 사항을 테스트하기 위해 PR을 승인할 수 있습니까?

감사 해요

@mvegaca 테스트하려고 할 때 동일한 문제가 발생했습니다. 어셈블리의 로컬 복사본을 참조할 수 없습니다. 테스트 문제를 훨씬 더 어렵게 만들기 때문에 여기서 무슨 일이 일어나고 있는지 알아내야 합니다.

어셈블리를 테스트할 때 어떤 문제가 있습니까?

WCT 솔루션에 PoC 앱을 추가하고 nuget 패키지 참조를 제거하고 프로젝트에 직접 참조를 추가했습니다.
프로젝트를 컴파일할 때 모든 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.

이는 솔루션에 빈 새 UWP App1을 추가하는 경우에도 발생합니다.
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

@nmetulev 감사합니다 ;)

로컬에서 너겟을 빌드하고 참조하는 것이 좋습니다. bin 폴더에 nuges를 생성해야 하는 build\build.ps1 스크립트를 사용하여 이를 수행할 수 있습니다.

@mvegaca 내가 본 것과 동일한 문제

불행히도 프로젝트는 솔루션 구성에 의존하기 때문에 직접 참조할 수 없습니다. 개발을 위해 샘플 앱에서 개발하는 것보다 훨씬 더 빠르고 빠르게 작동하는 것처럼 보이기 때문에 소스 파일을 새 프로젝트에 직접 연결하는 경향이 있습니다. 테스트를 위해 항상 로컬에서 너겟을 빌드하고 참조합니다.

우리는 그것을 로컬에서 테스트했고 잘 작동합니다 😄
괜찮다면 PR을 병합할 수 있습니다.

감사합니다 여러분

PR 병합

안녕하세요 @nmetulev

시험판 버전 5.0.0-preview.gb86cb1c4cb에서 사용해 보았지만 BackButtonBehavior 속성을 사용할 수 없습니다.

언제 이 수정 사항이 시험판 버전에서 제공되고 안정적인 버전에서 제공될 것이라고 생각하십니까?

감사 해요

예, 다음 주에 5.0.0 릴리스에서 사용할 수 있습니다. MyGet의 시험판에서도 사용할 수 있습니다. https://dotnet.myget.org/gallery/uwpcommunitytoolkit