Windowscommunitytoolkit: Bagaimana saya bisa menangani MasterDetail Back dengan NavigationView BackButton?

@skendrot mungkin bisa membantu disini

sepertinya @skendrot sedang sibuk, bisakah orang lain melihatnya? @nmetulev ?

Hei, sedang berlibur, terima kasih atas ping tambahannya. Saya tidak berpikir kami saat ini menangani ini, tetapi itu adalah sesuatu yang telah kami bicarakan untuk dilakukan. Kami telah berbicara tentang cara untuk mematikan menampilkan/menyembunyikan/menggunakan tombol kembali sistem. Tapi saya juga bisa melihat bahwa mungkin kita bisa berintegrasi dengan tampilan navigasi baru juga.
Apa pendapat Anda tentang hal berikut:

• Default untuk menggunakan tombol kembali sistem. Jika tampilan Navigasi baru ada, gunakan itu sebagai gantinya
• Miliki opsi untuk mematikan tombol kembali sepenuhnya dan biarkan pengembang memutuskan bagaimana ini harus ditangani

Kami juga dapat memiliki enum untuk mengontrol tombol kembali
Sistem, Tampilan Navigasi, Mati

Saya suka memiliki enum untuk mengontrol perilaku, yang sepertinya cara paling ramah pengembang untuk menanganinya. Memiliki cara untuk mematikannya sepenuhnya dan membiarkan pengembang menangani navigasi kembali juga masuk akal untuk skenario masa depan yang tidak dapat kami dukung segera

bagaimana kalau memiliki enum untuk ini dan juga mematikan tombol kembali sistem secara default dan kemudian pengembang dapat menyalakannya jika mereka mau? Karena navigasi tombol kembali yang baru dalam NavigationView sedang didorong dalam dokumen selanjutnya.

IMO, itu akan membuat perubahan perilaku untuk pengguna yang ada kecuali kami dapat mendeteksi tampilan navigasi baru. @skendrot , bagaimana menurutmu?

ya itu poin yang adil, menjaga pengguna yang ada tetap di cek juga sangat penting, saya setuju.

Itu disebutkan di komentar pertama. Pertahankan hal-hal sebagaimana adanya, tetapi lihat apakah kita memiliki NavigationView baru sebagai induk visual. Jika demikian, kita harus menggunakannya untuk tombol kembali alih-alih tombol kembali sistem. Saya pikir kami masih harus menyediakan cara untuk mematikannya sepenuhnya jika pengembang ingin mengontrol semuanya sendiri

ya opsi @skendrot selalu fleksibel dan selalu bagus untuk dimiliki khususnya saat membuat transisi besar. Jadi bagaimana ini harus bergerak maju sekarang?

Opsi apa pun yang diputuskan, saya akan mengendalikannya. Kita perlu memutuskan, apakah kita akan

1. Gunakan tombol kembali standar dan "menyala" jika tampilan navigasi baru ada DAN menawarkan cara untuk mematikan tombol kembali sepenuhnya
2. Tawarkan opsi enum baru yang memungkinkan pengembang untuk memilih antara tombol kembali standar, tombol kembali tampilan navigasi, dan mati

Pilih 👍 untuk 1 dan untuk 2

Saya akan menggabungkan keduanya dan menggunakan enum untuk mengontrol bagaimana tombol kembali menyala dengan memberikan tiga nilai:

• Otomatis - default (ini mencari tahu sendiri bagaimana menangani navigasi kembali)
• Warisan
• Mati

Saya akan menyarankan, daripada Otomatis, Legacy dan Off, Anda memberikan opsi enum yang jelas dalam apa yang akan mereka lakukan. Sebagai contoh

KembaliButtonPerilaku:

• Tampilan Sebaris
• Gunakan Eksternal
• KembaliDinonaktifkan

DisplayInline akan menjadi default, mengikuti panduan menampilkan tombol kembali bergaya standar di dalam kontrol. Ini juga dapat bekerja dengan tombol B pada gamepad, atau tombol spasi mundur pada keyboard saat kontrol memiliki fokus.

UseExternal akan memungkinkan Anda untuk mengatur kode, kontrol tombol kembali yang Anda tempatkan sendiri, kontrol shell (di bilah judul untuk jendela standar, atau di bilah bawah untuk jendela Set) atau dari kontrol lain. Saya kira Anda dapat memungkinkan untuk memberikan nama kontrol di XAML yang akan memicu dan menimpa acara yang ditekan tombol kembali untuk kontrol itu.

BackDisabled akan menonaktifkan navigasi kembali sepenuhnya.

Pengembang dan proyek seperti Template 10, kemudian dapat membuat halaman atau halaman template dengan pengaturan yang memungkinkan mereka mengontrol penggunaan tombol kembali.

Setuju dengan @mdtauk!

@mdtauk ya pasti saran ini lebih masuk akal dan sepertinya lebih kuat.

Saya sepenuhnya setuju dengan membuat tombol kembali di dalam kontrol, yang cocok dengan panduan tombol kembali saat ini .

Namun, kami juga harus menyediakan penanganan otomatis untuk tombol kembali NavigationView juga. Saya pikir tidak masuk akal untuk menonaktifkan navigasi kembali juga, itu harus menjadi sesuatu yang harus ditangani pengguna

Ini saran saya yang diperbarui

Enum: BackButtonHandling

• Otomatis (default) - menggunakan tombol sebaris kecuali jika NavigationView adalah induknya, lalu gunakan navigasi kembali NavigationView

• Sebaris - gunakan tombol sebaris

• Legacy - perlu memastikan bahwa kami mendukung tombol kembali shell untuk para pengembang yang belum pindah dari itu

• Manual - biarkan pengguna menggambar tombol kembali mereka sendiri dan melakukannya sesuka mereka

Alih-alih Legacy bagaimana dengan System atau SystemAppViewBackButton atau AppView atau yang lainnya

Selain itu, untuk mempertahankan kompatibilitas mundur, dan tidak memiliki perubahan yang mengganggu, seharusnya default tidak menjadi opsi lama. Kemudian di versi utama berikutnya kita dapat mengubah default menjadi otomatis

Saya suka Sistem lebih baik daripada warisan, itu jauh lebih baik

Saya tidak terlalu menyukai nilai default karena versi berikutnya adalah pembaruan besar (5.0). Saya setuju dengan menjaganya tetap default ke Sistem dan kemudian mengubah default ke Otomatis di 6.0.

dan mungkinkah ada pemberitahuan sebagai peringatan bahwa tombol kembali Sistem akan ditinggalkan dalam rilis mendatang ( 6.0 ) sesuatu seperti itu? atau akankah tombol kembali sistem selalu menjadi opsi, bahkan setelah set dirilis (mungkin rilis april 2019)?

Kami mungkin tidak akan menghentikan tombol kembali Sistem sampai tidak digunakan lagi dari platform.

Bahkan dengan Sets, tombol kembali sistem tidak ditinggalkan. Itu hanya akan menempatkannya di bilah di bawah tab dengan tombol kembali di atasnya. Tetapi jika Set ada, Anda harus benar-benar beralih ke tombol dalam aplikasi

Benar, saya harus mengklarifikasi: Kami hanya boleh menghentikan opsi dari enum jika itu juga akan dihentikan dari platform (saya tidak percaya ada rencana untuk melakukannya)

jadi ternyata ada seluruh toolbar hanya untuk 1 backbutton ( dalam kasus set ) ? atau akankah ada lebih banyak kontrol platform di atasnya?

jadi ternyata ada seluruh toolbar hanya untuk 1 backbutton ( dalam kasus set ) ? atau akankah ada lebih banyak kontrol platform di atasnya?

Saya tidak tahu ada kontrol tambahan yang akan ditambahkan shell. Tetapi karena ini jauh dari solusi elegan untuk Navigasi Kembali - panduannya adalah untuk menanganinya di aplikasi.

Jika Anda memikirkannya, tombol kembali dicakup dalam Tab Sets. Itu tidak akan muncul di samping tab, jadi tidak bisa muncul di Titlebar.

ya itu hanya terlihat terlalu banyak ruang UI yang terbuang di sana, hanya 1 tombol di sana.

@touseefbsb Sampai sekarang, itulah perilaku standar jika Anda memilih untuk membiarkan Shell menangani Tombol Kembali dengan jendela Sets. Karena Sets masih belum disertakan dalam build Windows, ini dapat berubah, tetapi lebih baik untuk mengaktifkan kontrol/aplikasi shell untuk menangani menggambar tombol kembali, dan menjauh dari Titlebar yang menanganinya.

Saya setuju, itu sebabnya saya juga berpikir menjauh dari hal-hal bilah judul dan bahkan tidak memperluas aplikasi ke bilah judul sama sekali akan membantu aplikasi digunakan dengan benar dengan set.

Set bahkan mungkin tidak sampai ke rilis 19H1, jadi untuk saat ini, penting bagi aplikasi untuk terlihat bagus dan diperluas ke bilah judul jika memungkinkan. Pengembang juga dapat memilih untuk tidak mengizinkan aplikasi mereka bekerja dengan Set, jadi memiliki fleksibilitas dengan kontrol, dan mengubah/mengganti default saat berjalan di tab Set, masuk akal. Setidaknya itu berlaku untukku lol

@mdtauk jika

@touseefbsb Begitulah cara saya memahaminya. Ketika dibuka dari Tab lain itu akan muncul di jendelanya sendiri, tidak akan dapat disimpan bersama dengan tab lain juga.

Komplikasi kecil untuk mendukung NavigationView baru. Event handler BackRequested tidak berisi cara untuk membatalkan event atau menandai bahwa event tersebut telah ditangani. Tanpa kemampuan ini, MasterDetailsView akan menangani perpindahan dari Detail ke tampilan Master dan kemudian pengembang akan menangani kembali ke status juga.
Kami dapat mendukung IFF sebuah frame sedang digunakan juga untuk membantu navigasi.

@mvegaca , apakah Anda menggunakan bingkai untuk meng-host kontrol? Bagaimana jika alih-alih mencoba menangani kembali di NavView, kami menangani kembali di Frame (yang juga harus menangani skenario di luar NavView)?

Kami sudah menangani navigasi bingkai jadi itu sudah ada di dalamnya. Kami tidak bisa mengandalkan penggunaan NavigationView baru kecuali ada bingkai juga

Jadi jika WTS menggunakan Frame untuk navigasi mereka di dalam NavView, seharusnya sudah berfungsi?

Ya, dengan tambahan yang tidak diinginkan. MasterDetailsView akan mengaktifkan tombol kembali sistem, yang tidak diinginkan WTS. Namun, jika mereka menangani tombol kembali NavigationView dengan menavigasi dalam bingkai, maka MasterDetailsView akan menangkap peristiwa itu, dan jika itu adalah status Detail yang diciutkan, akan menandainya sebagai batal dan kembali ke tampilan master.

Kami (WTS) menggunakan bingkai di dalam NavView. Tombol kembali navview sudah berfungsi, tetapi tombol kembali sistem tambahan ditampilkan. Untuk menangani navigasi kembali kami melakukan Frame.GoBack, tetapi masalah kami adalah tombol kembali sistem yang ditampilkan sebelum kembali. Jadi, saya tidak yakin apakah kami baik-baik saja. Apakah ada cara untuk menguji ini?

Ya, itulah masalah yang sedang diperbaiki PR

Hai @nmetulev Saya mencoba menguji BackButtonBehaviorProperty baru dalam klon repositori git dari @skendrot tetapi saya tidak dapat mengkompilasi aplikasi yang menargetkan langsung ke perpustakaan.
Bisakah Anda menyetujui PR untuk menguji perubahan ini dalam paket MyGet CI?

Terima kasih

@mvegaca Saya memiliki masalah yang sama ketika mencoba menguji. Saya tidak dapat mereferensikan salinan majelis lokal saya. Kita perlu mencari tahu apa yang terjadi di sini karena itu membuat masalah pengujian jauh lebih sulit

Apa masalah yang Anda alami dengan pengujian rakitan?

Kami telah menambahkan aplikasi PoC dalam solusi WCT, menghapus referensi paket nuget dan referensi langsung ke proyek.
Ketika saya mengkompilasi proyek saya mendapatkan kesalahan berikut di semua file 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.

Ini juga terjadi jika saya menambahkan UWP App1 baru yang kosong ke solusi.
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

Terima kasih @nmetulev ;)

Saya merekomendasikan membangun nuget secara lokal dan merujuknya. Anda dapat melakukannya dengan menggunakan skrip build\build.ps1 yang seharusnya menghasilkan nuges di folder bin.

@mvegaca Masalah yang sama yang saya lihat

Sayangnya, proyek tidak dapat dirujuk secara langsung karena bergantung pada konfigurasi solusi. Untuk pengembangan, saya cenderung menautkan file sumber secara langsung di proyek baru karena tampaknya bekerja jauh lebih baik dan lebih cepat daripada yang berkembang di aplikasi sampel. Untuk pengujian, saya selalu membuat nuget secara lokal dan merujuknya

Kami telah mengujinya secara lokal dan berfungsi dengan baik
Anda dapat menggabungkan PR jika semuanya baik-baik saja untuk Anda.

Terima kasih teman-teman semua

PR digabungkan

Hai @nmetulev

Saya sudah mencoba menggunakannya dalam versi pra-rilis 5.0.0-preview.gb86cb1c4cb tetapi properti BackButtonBehavior tidak tersedia.

Menurut Anda kapan perbaikan ini akan tersedia pada versi pra-rilis dan akan tersedia pada versi stabil?

Terima kasih

Ya, itu akan tersedia dalam rilis 5.0.0 minggu depan. Ini juga tersedia di pra-rilis di MyGet: https://dotnet.myget.org/gallery/uwpcommunitytoolkit