Mari kita serukan percakapan ini, karena kami benar-benar perlu mendengar dari Anda, komunitas pengembang kami!

PERTAMA, terima kasih @jassmith telah bekerja keras untuk menangkap ini dan membuat proposal untuk kami diskusikan secara terbuka di sini.

Saya akan membagikan beberapa pemikiran saya, mengajukan beberapa pertanyaan bodoh, dan mengajukan beberapa pertanyaan yang mudah-mudahan tidak terlalu mengarah. Sebagai Manajer Program untuk Xamarin.Forms, saya sering harus mengajukan pertanyaan sedemikian rupa sehingga seolah-olah saya tidak memiliki petunjuk (kadang-kadang saya tidak tahu), tetapi sebenarnya saya hanya perlu mendengar sesuatu dari ANDA tanpa memasukkan kata-kata ke dalam mulut Anda.

Ada hal-hal yang saya suka dalam proposal ini, karena saya dapat melihat bagaimana mereka dapat mengatasi beberapa masalah yang telah saya bicarakan dengan banyak, banyak dari Anda, dan kami sedang berusaha untuk memecahkannya.

Saya juga memiliki reservasi.

Saya akan memulai di sini dengan beberapa pemikiran umum tentang konsep Shell dan pengalaman pengembang.

Pengalaman Aplikasi

untuk mendapatkan pengalaman aplikasi lengkap yang terstruktur dengan baik, menggunakan elemen yang tepat, dengan sedikit usaha dan jalur yang jelas untuk menjadi baik secara default.

Jika saya menggunakan pendekatan ini untuk menggambarkan aplikasi saya di tingkat atas, saya mendapatkan:

• aplikasi bertema agar terlihat sama di setiap platform
• desain material (dalam hal ini) pola secara default
• pola navigasi terbaru diaktifkan dengan konfigurasi
• Saya tidak perlu bekerja untuk menyesuaikan Entri atau Tombol agar terlihat sama di iOS dan Android dan UWP?

Apakah itu akurat? Manfaat lain yang harus saya soroti?

Alih-alih App Saya punya MaterialShell . Saya perlu mempelajari/mengadopsi paradigma aplikasi tingkat atas baru untuk mendapatkan manfaat dari ini?

Setelah saya masuk ke aplikasi saya, saya kembali ke tanah ContentPage , benar? Tapi semua Button s dan Entry adalah materi dan cantik. Bisakah saya tetap OnPlatform dan sejenisnya untuk mengubah tampilan (atau perilaku) menjadi berbeda di platform lain?

Seperti apa jalur migrasi saya dari aplikasi yang ada ke menggunakan "shell" ini? Saya memperkenalkan MaterialShell , menjelaskan bagaimana saya ingin aplikasi saya menjadi terstruktur dan terlihat, dan jalankan saja untuk melihat kebaikan baru?

Menyesuaikan

Apa pilihan saya jika saya menyukai tampilan Flyout atau item menu, tetapi saya perlu mengubahnya agar sesuai dengan desain desainer saya? Pada titik apa saya mengatakan "Ugh, saya seharusnya menggulung ini semua sendiri" dan memindahkan apa yang saya miliki ke struktur aplikasi Xamarin.Forms standar?

Jika saya harus benar-benar meninggalkan MaterialShell , apakah saya kehilangan semua kebaikan penataan itu dan saya kembali ke tempat saya memulai (seperti hari ini) dengan Entry terlihat sangat berbeda antara iOS dan Android dan UWP ? Saya ingin tidak.

Ada titik kritis yang saya antisipasi. Setelah saya menggunakan pendekatan ini untuk memulai dengan cepat, saya akan mencapai beberapa batasan dan perlu menjelajahi opsi saya. Apa itu dan pada titik apa saya lebih baik tidak menggunakan MaterialShell ?

Masalah

Saya akan menutup komentar pertama ini dengan beberapa pertanyaan untuk semua orang yang membaca.

• Apakah masalah yang coba diatasi oleh proposal ini didefinisikan dengan baik?
• Apakah itu masalah yang Anda bagikan?
• Saat Anda membaca spesifikasi ini, masalah apa yang Anda hadapi pada proyek sebelumnya yang menurut Anda akan diselesaikan untuk Anda?

Jika memungkinkan, tangkapan layar / gambar desain akan menjadi lebih baik.

Lihat juga ini:

http://www.noesisengine.com/webgl/Samples.Buttons.html

@jassmith Akan sangat bagus jika seluruh ide disajikan sebagai gambar. Kudos untuk upaya memasang spesifikasi. Pertanyaan saya mungkin tidak benar.

Pertanyaan saya adalah

• Dukungan Tablet, Responsivitas aplikasi yang beradaptasi dengan tata letak yang berbeda tidak dibahas.
• Akankah migrasi dari model saat ini ke model baru menjadi tantangan? Dari perspektif pengembang aplikasi dan perspektif kontributor Xamarin Forms.
• Saya setuju sebagian besar aplikasi membutuhkan UI tunggal (karena jumlah penyaji khusus yang harus kami tulis kadang-kadang untuk mencapai konsep UI yang sama) tanpa menghormati spesifikasi platform, apakah arah baru akan menghapus semua fitur yang ada, seperti apakah kami masih mengembangkan Xamarin.Forms aplikasi dengan UI khusus platform, atau semua orang akan dipaksa ke Standar baru.
• Akankah konsep penyaji masih ada di dalam MaterialShell
• Bisakah kita benar-benar mengatakan, di iOS, kita ingin ini dirender dengan cara ini? Flutter memiliki Cupertino Styles (apple UI) yang berfungsi di Android, dan Android UI yang berfungsi di iOS. Ke arah mana Xamarin Forms akan bergerak. Akankah pengembang memiliki kemampuan seperti itu yang ditawarkan flutter sekarang.

Apakah ini juga akan menyertakan sesuatu yang mirip dengan TextInputLayout untuk mendukung label/placeholder mengambang serta pesan kesalahan? Jika ya, maka saya pikir Binding harus diperluas untuk menyertakan 'ValidateOnDataErrors` mirip dengan wpf.

Lihat implementasi saya ini di sini
https://github.com/XamFormsExtended/Xfx.Controls/blob/develop/src/Xfx.Controls/XfxBinding.cs

Juga, saya bertanya-tanya apakah MaterialShell harus memperluas Shell sehingga seseorang dapat membuat HumanInterfaceShell untuk tampilan dan nuansa iOS.

@ChaseFlorell yang akan menjadi komentar saya juga. Bahannya bagus, tapi itu hal lain jika kita ingin menulis shell kita sendiri agar sesuai dengan kebutuhan UI tertentu.

@davidortinau , @jassmith ,

Terima kasih telah menyusun spesifikasi ini dan mengizinkan kami memberikan umpan balik.

Apakah masalah yang coba diatasi oleh proposal ini didefinisikan dengan baik?

Ya. Sistem navigasi tidak sepenuhnya dikembangkan dalam Formulir Xamarin sehingga ada masalah terbuka tentang bagaimana menyelesaikannya, atau menghindarinya sama sekali.

Apakah itu masalah yang Anda bagikan?

Ya.

Saat Anda membaca spesifikasi ini, masalah apa yang Anda hadapi pada proyek sebelumnya yang menurut Anda akan diselesaikan untuk Anda?

Saya akan menjawab pertanyaan ini dengan mengatakan bahwa menurut saya itu tidak akan menyelesaikan masalah. Masalah khusus kami adalah bahwa sistem navigasi saat ini terlalu kaku, bukan karena tidak cukup kaku. Contoh paling jelas bagi kami adalah TabbedPage. Tidak ada tampilan TabbedView, jadi jika kita ingin tab di aplikasi kita, kita harus menggunakan TabbedPage. Jadi, seluruh layar harus diambil oleh TabbedPage dan kami tidak dapat menggunakan real estat untuk tombol sendiri, atau kontrol lain yang mungkin ingin kami letakkan di layar. Rekomendasi saya adalah memindahkan lebih banyak fungsionalitas _keluar dari_ Halaman dan turun ke Tampilan daripada memindahkan fungsionalitas di Halaman ke lapisan yang lebih tinggi lagi.

Hal-hal seperti FloatingMenu, dan FlyoutBehavior membuat saya takut karena mereka menyiratkan bahwa navigasi akan lebih sulit dikodekan ke dalam sistem Xamarin.Forms dan kontrol lebih lanjut akan diambil dari pengembang perangkat lunak. Saya dapat melihat beberapa nilai dalam memiliki pendekatan yang lebih standar, tetapi itu pasti akan dikenakan biaya.

Kami selalu bekerja di teknologi berbasis XAML lainnya seperti Silverlight, WPF, dan UWP. Dalam teknologi tersebut, kami memiliki pendekatan yang jauh lebih terbuka di mana kami dapat mendefinisikan lebih banyak tentang cara kerja navigasi. Baru-baru ini, kami melibatkan konsultan UI/UX. Dia tidak menyadari kebiasaan XF. Kami hanya memintanya untuk membuatkan kami beberapa layar berdasarkan fungsionalitas perangkat lunak kami. Sebagian besar dari apa yang dia rekomendasikan tidak dapat diimplementasikan karena hal-hal seperti tidak memiliki TabbedView. Saya khawatir alih-alih membuat navigasi menjadi lebih mudah, yang akan terjadi adalah framework ini justru akan mempersulit implementasi desain yang diberikan kepada kita oleh desainer UX/UI.

Hal lain yang akan saya katakan adalah bahwa kerangka kerja ini terlihat belum pernah terjadi sebelumnya di platform XAML lainnya, dan saya akan mengatakan bahwa prioritasnya adalah menyediakan standarisasi di seluruh platform daripada menyediakan kerangka kerja baru yang tidak akan kompatibel dengan platform lain. Saat ini kami sedang membangun untuk tiga platform sekarang: Silverlight, Xamarin.Forms, dan WPF. Yang kami butuhkan adalah standarisasi di seluruh platform tersebut untuk menciptakan lebih sedikit penyimpangan, tidak lebih.

@dylanberry ,

itu hal lain jika kita ingin menulis shell kita sendiri agar sesuai dengan kebutuhan UI tertentu.

Ya. Ini adalah keprihatinan saya. Setiap aplikasi memiliki kasus penggunaan khusus, dan kekakuan yang lebih mungkin akan mempersulit - bukan lebih mudah untuk mengimplementasikannya.

Ada juga kekhawatiran ini: https://github.com/xamarin/Xamarin.Forms/issues/2452#issuecomment -380991817

Saya akan mengulangi hal di atas, serta bertanya bagaimana gerakan dan pointer akan berfungsi irt bentuk primitif?

Komentar umum adalah bahwa untuk setiap baris kode yang ditambahkan ke sistem, ada 3+ kemungkinan kode kereta ditambahkan. Sudah banyak bug di Xamarin Forms yang perlu diperbaiki. Lebih banyak kode berarti kemungkinan bug yang ditambahkan meningkat secara eksponensial. Akan ada lebih banyak bug. Saya merasa bahwa tim XF harus bekerja untuk mengurangi ukuran basis kode daripada meningkatkannya. Mengurangi basis kode adalah satu-satunya cara untuk mengurangi kemungkinan munculnya bug.

Mengapa menciptakan hal baru lagi alih-alih memperbaiki bug yang ada dan pertama-tama memastikan semuanya solid?

Bagi saya, itu telah disentuh tetapi navigasi adalah satu-satunya batu sandungan terbesar di Xamarin Forms dan telah menyebabkan saya paling sakit hati selama tiga tahun terakhir.

Navigasi tidak konsisten di ketiga platform dengan pola MasterDetail yang menyebabkan banyak masalah dengan hamburger yang memaksa Anda untuk mendorong modal halaman, Anda kemudian harus menerapkan bilah navigasi khusus karena Anda tidak dapat menambahkan kembali tetapi animasinya terlihat buruk di Android (bahkan di MD).

• Idealnya Anda harus dapat menyisih dan mengganti konten bilah navigasi dengan ContentView Anda sendiri dalam banyak kasus. PlatformSpecifics awalnya diperdebatkan sebagai sesuatu yang memungkinkan penempatan item bilah alat (jauh ketika saya berbicara dengan Bryan) tetapi ternyata penggunaannya terbatas.

• Kemampuan untuk mengganti hal-hal kerangka kerja seperti animasi yang muncul di halaman

Banyak dari apa yang diusulkan tampaknya sangat berguna, Selama Anda dapat menggunakan shell material di halaman tertentu dan itu tidak mencakup seluruh aplikasi, kode itu akan sangat berguna. Itu pasti sesuatu yang akan kami gunakan karena saat ini saya terus mengatakan "Ini adalah batasan Xamarin Forms" kepada orang UX kami (seperti yang saya lakukan dalam peran saya sebelumnya). Berani saya mengatakannya, kita harus mendapatkan umpan balik dari perspektif UX yang sebelumnya telah menata aplikasi Formulir. Itu harus opt-in seperti XamlC.

Tidak yakin tentang namanya, FlexShell akan lebih masuk akal...tetapi kami sekarang memiliki Flexbox (walaupun kami tidak pernah memintanya...maaf David, tidak dapat menahan diri )

Juga, apakah ini berarti tema sudah mati? tidak pernah menggunakannya.

@mackayn

Itu pasti sesuatu yang akan kami gunakan karena saat ini saya terus mengatakan "Ini adalah batasan Xamarin Forms" kepada orang UX kami (seperti yang saya lakukan dalam peran saya sebelumnya).

Oke, tetapi, tidakkah lebih masuk akal untuk memperbaiki atau meningkatkan implementasi saat ini daripada membuat yang benar-benar baru, yang akan disertai dengan bug dan batasan juga? Dikatakan di sana bahwa:

MaterialShell adalah API berpendirian pada poin"

Serius, dalam berapa banyak arah yang berbeda Xamarin Forms dapat pergi? Tim XF hampir tidak dapat terus memperbaiki implementasi XF saat ini setidaknya untuk Android dan iOS, dan sekarang ini? Bagaimana dengan perbaikan bug, perbaikan pratinjau XAML, bagaimana dengan kinerja?

Ada tiket yang dibuka oleh seseorang dengan proposal untuk menambahkan dukungan sederhana namun sangat berguna untuk kuas solid dan gradien lintas platform, tetapi tanggapan @jassmith adalah bahwa itu akan bermasalah. Tapi sekarang tiket ini mengusulkan hal yang sama.... Bagaimana itu tidak bermasalah lagi? Pergi figur

@opcodewriter

Ya, saya telah mengatakan bahwa selama setahun terakhir, ada keanehan navigasi yang menahan tim Prism misalnya dan mereka tidak pernah bisa menyelesaikan masalah.

Saya hanya mencoba menawarkan umpan balik yang konstruktif untuk saat ini, Xamarin Forms berada pada titik kritis dalam evolusinya, API ini dapat mengatasi banyak masalah jika diterapkan dengan cara yang fleksibel dan bukan pendekatan aplikasi yang luas.

@jassmith apakah ini berarti bahwa XF akan mengambil pendekatan Flutter (menggunakan mesin rendering alih-alih kontrol asli) untuk Shell?

Teman-teman, kemarin Jason dan saya sendiri berdiskusi tentang cara meningkatkan spesifikasi ini dan kami akan melakukan pembaruan besar-besaran, kami membagi ini menjadi masalah yang berbeda.

Saya ingin menggemakan beberapa sentimen di atas: tolong mari kita perbaiki apa yang kita miliki, kecuali tentu saja Anda memiliki sumber daya yang tidak terbatas, maka lakukanlah

Ada banyak hal yang masih tertinggal: memperbaiki ListView (sulit dipercaya bahwa ini masih tidak berfungsi dengan baik), menerapkan kontrol seperti Kotak Centang, RadioButton, menerapkan dukungan kuas (SolidColorBrush, GradientBrush), kemampuan untuk menampilkan Popup berdasarkan Halaman atau ContentView, memperbaiki bug (lihat bug terbaru yang dilaporkan tentang tampilan transparan), kinerja, perkakas, dan banyak lagi....

Mengapa Anda ingin memulai hal baru?????

@TonyHenrique Ya gambar akan sangat bagus. Sayangnya saya bukan seniman dan tidak memiliki hak atas gambar yang saya gunakan untuk referensi saya sendiri. Saya berharap beberapa anggota tim desain akan memiliki waktu untuk membantu saya menghasilkan gambar yang tepat untuk spesifikasi tersebut.

@muhaym

• Dukungan tablet. Hal ini dimaksudkan untuk memastikan tata letaknya adaptif dengan tablet. Ini tidak akan mencakup kasus untuk tata letak di dalam halaman konten Anda tentu saja, itu akan menjadi fitur yang berbeda. Sebagian besar saya akan menanganinya dengan VSM baru.
• Sebagian besar hanya menempatkan Halaman Konten Anda di tempat yang tepat dan beradaptasi dengan konsep navigasi baru. Saya tidak akan mengatakan itu akan selalu sepele tetapi juga tidak boleh melemahkan.
• Sama sekali tidak akan menghapus fitur apa pun. Sebenarnya saya sedang berupaya memperbarui spesifikasi untuk memasukkan kelas dasar Shell yang melewatkan beberapa fitur MaterialShell tetapi sebaliknya merupakan versi UI khusus platform Shell.
• Ya. Menambahkan Gambar hanya mengubah penyaji mana yang Anda dapatkan menjadi sesuatu yang diketahui cara menangani gambar.
• Ya. Anda dapat menukar penyaji mana yang digunakan di tingkat hierarki mana pun. Penyaji baru saja diubah oleh templat yang disetel dengan kunci khusus di kamus sumber daya. Anda dapat mengubah template ini menjadi apa pun yang Anda inginkan atau menonaktifkannya dengan menyetel null ke template tersebut.

@ChaseFlorell tidak, tapi saya terbuka untuk saran jika Anda ingin melampirkan amandemen spesifikasi. Adapun hal Shell vs MaterialShell, saya membahasnya di atas. Langkah 1 memastikan MaterialShell masuk akal kemudian memecahnya ke kelas dasar adalah langkah 2.

@dylanberry kelas dasar tidak akan membuatnya lebih mudah. Ini tidak sesederhana mengubah DrawingTemplates. Saya bermaksud untuk mengimplementasikan aspek MaterialShell ini dalam kode khusus platform untuk kinerja yang optimal.

@RichiCoder1 gerakan akan datang di sini tapi intinya adalah pandangan dengan gerakan subregion datang sebagai bagian dari CommandableSpan API dan itu akan diperluas untuk mendukung gambar dengan gerakan juga. Namun secara umum disarankan untuk TIDAK menggunakan gerakan dan membiarkan backend asli menangani input. Ini tidak terkait dengan spesifikasi MaterialShell pada saat ini sekarang dan termasuk dalam spesifikasi Gambar di mana saya senang untuk membahas lebih detail. Panjang dan pendeknya adalah alasan DrawingTemplate adalah sesuatu yang kami dapat menyertakan SliderDrawingTemplate yang memiliki banyak Gambar yang perendernya tahu cara membuat slider dan memungkinkan penanganan input untuk terus ditangani di backend asli. Ini tidak berarti Anda akan dipaksa untuk melakukan ini, itu hanya akan menjadi hal opsional untuk membuat penyaji secepat mungkin.

@mackayn a Transitions/Segue API akan datang dan akan segera mendarat di sini. Saya masih mengerjakan beberapa penamaan proposal awal saya. Ini pasti akan menjadi sesuatu yang datang secara bertahap dengan hanya Transisi Halaman yang berada di fase 1. Itu akan membiarkan Anda mengesampingkan animasi kerangka kerja. Adapun keikutsertaan. Shell harus menjadi root aplikasi Anda dan tidak dapat membuat sarang apa pun kecuali milik TemplatedPage. Yang mengatakan tema kontrol internal adalah 100% dalam kendali Anda. Ini lebih dari sekadar sakelar ajaib untuk menghidupkan/mematikan templat baru dan Anda dapat mengontrol sakelar itu dengan cara yang sama seperti yang kami lakukan. Ini memungkinkan Anda memilih masuk dan keluar dari tema di halaman, tata letak, atau bahkan tingkat kontrol.

@encrypt0r tidak persis. Anggap saja sebagai hibrida. Ini akan memungkinkan untuk rendering tetapi di bawah tenda semua kontrol khusus platform hanya bertema dengan kode gambar. Namun ada jalan keluar untuk Skia yang dapat dengan mudah ditambahkan (meskipun saya ragu itu membuatnya mendekati v1).

@opcodewriter ListView2 (jelas itu sebenarnya tidak akan disebutkan namanya) ada di peta jalan tahun ini pada akhirnya. Mengapa ListView baru? Yah, API asli mengarah ke jumlah bug dan masalah yang hampir tak terbatas yang tidak dapat kami perbaiki secara efektif tanpa benar-benar merusak kompatibilitas ke belakang. Hal-hal seperti Cell/ViewCell dan ItemsViewdan TemplatedItemsList sementara mereka bekerja dengan baik untuk apa yang dimaksudkan untuk 1.0, sama sekali tidak mampu melakukan apa yang mereka butuhkan untuk penggunaan modern API.

Sayangnya saya tidak dapat memikirkan cara apa pun untuk menyelesaikan ini dalam tipe ListView itu sendiri, dan sayangnya saya tidak berpikir komunitas dapat melakukannya. Pilihan terbaik saat ini adalah mempertahankan ListView apa adanya, dan kemudian membuat sesuatu yang jauh lebih ramping dengan overhead yang lebih sedikit, pembukuan yang lebih sedikit, jenis yang tidak terlalu aneh yang tidak perlu ada dan memercayai kerangka kerja target untuk melakukan yang terbaik.

Hanya menghapus strategi daur ulang lama, yang akan menjadi perubahan besar yang melanggar backcompat yang tidak dapat kami lakukan, akan menghapus sebagian besar basis kode Xamarin.Forms. ListView2 akan membawa Anda lebih dekat ke logam dengan menghapus barang-barang ini yang dimaksudkan sebagai pagar pengaman (atau dalam kasus Cell, penggabungan tidak suci dari 2 proyek internal yang berbeda) dan sekarang hanya merugikan semua orang.

Strategi caching lama berdampak pada SETIAP penyaji yang ada saat ini. Ini adalah alasan mengapa setiap penyaji mendukung untuk mengubah Elemennya. Jika itu hilang dengan perkiraan terbaik saya, sekitar 10% dari semua kode dalam proyek hilang. Ini benar-benar kanker terbesar dari proyek ini.

@davidortinau Anda mendapatkan komentar Anda sendiri hanya karena Anda memiliki begitu banyak format yang indah!

Jika saya menggunakan pendekatan ini untuk menggambarkan aplikasi saya di tingkat atas, saya mendapatkan:

• aplikasi bertema agar terlihat sama di setiap platform
• desain material (dalam hal ini) pola secara default
• pola navigasi terbaru diaktifkan dengan konfigurasi
• Saya tidak perlu bekerja untuk menyesuaikan Entri atau Tombol agar terlihat sama di iOS dan Android dan UWP?

Apakah itu akurat? Manfaat lain yang harus saya soroti?

Ya itu benar. Ada banyak manfaat lain yang dapat Anda soroti tetapi itu akan menjadi jelas setelah Anda mulai mengacaukannya. Seperti yang dapat Anda lakukan di lembar bawah, memiliki FAB, menavigasi menggunakan URL (pembaruan masih datang) dan banyak lagi.

Alih-alih App saya punya MaterialShell. Saya perlu mempelajari/mengadopsi paradigma aplikasi tingkat atas baru untuk mendapatkan manfaat dari ini?

Salah. Halaman Utama aplikasi Anda adalah MaterialShell. Aplikasi masih root aplikasi Anda.

Setelah saya masuk ke aplikasi saya, saya kembali ke halaman ContentPage, benar? Tapi semua Tombol dan Entri saya cukup material dan cantik.

Dengan pengecualian di mana Anda salah di atas, ya ini benar.

Bisakah saya tetap OnPlatform dan sejenisnya untuk mengubah tampilan (atau perilaku) menjadi berbeda di platform lain?

Ya.

Seperti apa jalur migrasi saya dari aplikasi yang ada ke menggunakan "shell" ini?

Lihatlah kasus repro Google Play Store, bayangkan menempatkan semua halaman aplikasi Anda saat ini di sana. Ini hanya menggantikan area-area di aplikasi Anda di mana Anda secara langsung menggunakan halaman Nav/Tab/MD. Itu tidak berdampak pada Halaman Konten Anda.

Saya memperkenalkan MaterialShell baru, menjelaskan bagaimana saya ingin aplikasi saya menjadi terstruktur dan terlihat, dan jalankan saja untuk melihat kebaikan baru?

Bingo

Apa saja pilihan saya jika saya menyukai tampilan Flyout atau item menu, tetapi saya perlu mengubahnya agar sesuai dengan desain desainer saya?

Anda sepenuhnya mengontrol tajuk, bagaimana tajuk diciutkan dan disembunyikan. Anda sepenuhnya mengontrol tampilan/rasa dari masing-masing "Sel" (mereka tidak akan menjadi sel) di flyout. Anda sepenuhnya mengontrol tajuk untuk setiap grup di sana juga. Akibatnya Anda mengontrol "tampilan" segalanya, namun kami masih perlu menambahkan beberapa tempat tambahan bagi Anda untuk menempatkan konten tambahan.

Pada titik apa saya mengatakan "Ugh, saya seharusnya menggulung ini semua sendiri" dan memindahkan apa yang saya miliki ke struktur aplikasi Xamarin.Forms standar?

Jika flyout tata letak fisik Google Play Store terlihat sangat berbeda dari yang Anda inginkan. Tidak jauh berbeda, sama sekali berbeda.

Jika saya harus benar-benar meninggalkan MaterialShell, apakah saya kehilangan semua kebaikan gaya dan saya kembali ke tempat saya memulai (seperti hari ini) dengan Entri yang terlihat sangat berbeda antara iOS dan Android dan UWP? Saya ingin tidak.

Tidak ada MaterialShell yang hanya mengatur beberapa sumber daya default sehingga anak-anaknya mendapatkannya. Anda akan dapat melakukannya sendiri. Anda mungkin harus tetap melakukannya, kami belum benar-benar berkomitmen untuk membuat MaterialShell melakukannya secara default. Jika kami membuatnya ikut serta alih-alih memilih keluar, itu akan menjadi panggilan API tunggal untuk subpohon apa pun.

Ada titik kritis yang saya antisipasi. Setelah saya menggunakan pendekatan ini untuk memulai dengan cepat, saya akan mencapai beberapa batasan dan perlu menjelajahi opsi saya. Apa itu dan pada titik apa saya lebih baik tidak menggunakan MaterialShell?

Tujuannya adalah Anda TIDAK PERNAH lebih baik menjadi non-Shell. Anda mungkin tidak menginginkan Material tetapi Anda harus selalu menginginkan Shell (sekali lagi kelas dasar Shell akan datang). Mengapa? Tampilan/rasa shell akan jauh lebih dapat dikonfigurasi, cerita navigasi akan jauh lebih terpadu, seharusnya tidak ada yang waras yang dapat Anda lakukan dengan halaman lain yang tidak dapat Anda lakukan dengan Shell.

Lebih baik, tujuannya adalah untuk memastikan perender Shell benar-benar mudah dikonfigurasi dan waras. Tidak ada kelas tersembunyi yang ajaib, bukan subkelas tampilan asli khusus yang kami gunakan dengan susah payah. Sebisa mungkin setiap komponen penyaji akan disusun dan dapat ditukar. Dengan begitu, jika tidak berfungsi seperti yang Anda inginkan, Anda sebenarnya bisa memperbaikinya...

Mengapa kita tidak melakukannya pada awalnya? Itu bukan tujuan desain di hari-hari awal dan kemudian kami akhirnya menikah dengan itu ... Ini cukup besar dan cukup baru sehingga kami tidak perlu membawa kesalahan itu bersama kami.

@opcodewriter

Serius, dalam berapa banyak arah yang berbeda Xamarin Forms dapat pergi? Tim XF hampir tidak dapat terus memperbaiki implementasi XF saat ini setidaknya untuk Android dan iOS, dan sekarang ini?

Bagaimana dengan perbaikan bug, perbaikan pratinjau XAML, bagaimana dengan kinerja?

^^ Ini

@migueldeicaza

Teman-teman, kemarin Jason dan saya sendiri berdiskusi tentang cara meningkatkan spesifikasi ini dan kami akan melakukan pembaruan besar-besaran, kami membagi ini menjadi masalah yang berbeda.

Miguel, ini jelas akan menjadi pekerjaan besar. Saya tidak dapat berbicara atas nama semua pengembang, tetapi saya dapat memberi tahu Anda bahwa tim saya menginginkan tiga hal: stabilitas, kinerja, dan fleksibilitas. Kami ingin bug diperbaiki. Kami ingin aplikasi kami berjalan dengan lancar, dan kami ingin dapat mengimplementasikan desain yang diberikan oleh desainer UI/UX kami tanpa berbalik dan berkata "Maaf, itu tidak mungkin di platform kami". Spesifikasi ini tampaknya bertentangan dengan tujuan itu. Ini akan membutuhkan lebih banyak sumber daya yang dilemparkan ke pekerjaan yang berarti bahwa sumber daya Anda tidak dibebaskan untuk bekerja pada stabilitas, kinerja, dan fleksibilitas.

Apakah ini akan menjadi perilaku/cara default baru untuk berkembang dalam bentuk xamarin? Atau apakah kami masih memiliki opsi untuk membuat aplikasi kami dengan tampilan dan nuansa khusus setiap platform?

@DanielCacer sementara saya curiga dalam jangka panjang ini mungkin menjadi cara "default", ini sama sekali tidak akan menggantikan cara saat ini. Ini hanya akan menjadi cara yang lebih terintegrasi dan modern yang akan menyediakan lebih banyak shell yang saat ini sedang dibangun secara manual oleh orang-orang. Selain itu karena kami akan menyediakan shell sebagai kontrol tunggal, kami dapat mengoptimalkan banyak hal tentang cara menggambar dan menatanya. Anda tidak lagi memiliki 3 kartu gambar hanya untuk cangkang Anda.

Saya dengan hati-hati mendukung ide ini, asalkan perbaikan yang diusulkan dilakukan melalui perbaikan dalam kode Xamarin Forms yang mendasarinya. Jika ini menambah lebih banyak kerumitan di atas Formulir, saya tidak akan menggunakannya.
Untuk uang saya, saya lebih suka memiliki sumber daya pengembang yang diarahkan untuk membuat Formulir lebih fleksibel, lebih cepat, dan selesai daripada saat ini. Jika itu terjadi, saya bisa membuat semua fitur baru yang diusulkan di sini untuk diri saya sendiri. DIY dalam hal ini hampir pasti cocok untuk saya dan klien saya lebih baik daripada toolkit generik yang disediakan oleh Xamarin, betapapun bagusnya itu. Dengan beberapa pengecualian, proposal ini tidak menyelesaikan masalah yang saya hadapi saat ini.

@jassmith

1. Ada lebih dari 500 masalah terbuka.
2. Xamarin Forms berusia 3 tahun dan masih ada bug dalam kontrol dan fungsionalitas dasar, fitur-fitur penting masih kurang dan kinerja belum sepenuhnya dipaku (saya tahu beberapa perbaikan telah dilakukan, tetapi kinerja di Android terlihat di bawah standar).
3. Tim pengembang Xamarin Forms masih terlalu kecil.

Mengapa Anda ingin mulai mengerjakan fitur baru ini sekarang? Tidakkah lebih masuk akal untuk fokus pada hal di atas terlebih dahulu?

Tentang komentar Anda di atas yang terkait dengan ListView: Saya menghargai setiap tindakan berani yang diambil, termasuk mendesain ulang\menggantinya sepenuhnya. Ini tidak seperti semuanya begitu hebat di Xamarin Forms hal-hal yang tidak boleh disentuh\diubah.

@opcodewriter

1) Ya ada. Saya setuju ini masalah dan akan terus menjadi item pekerjaan prioritas yang saya dorong secara pribadi.

2) Kinerja di Android adalah bagian dari alasan pendorong untuk ini. Ini memberi kerangka waktu lebih banyak untuk transisi halaman sehingga kami dapat menyembunyikan hal-hal seperti waktu JIT. Kami dapat memuat dan menyimpan halaman secara proaktif dengan jauh lebih cerdas. Apa yang tidak dapat diperbaiki oleh tim XF adalah waktu JIT secara keseluruhan. Jika Anda menjalankan aplikasi Anda di Android dengan AOT diaktifkan dan jauh lebih cepat, tidak ada yang bisa saya lakukan untuk membantu Anda.

3) Tidak ada argumen di sini.

Mengapa Anda ingin mulai mengerjakan fitur baru ini sekarang? Tidakkah lebih masuk akal untuk fokus pada hal di atas terlebih dahulu?

Pekerjaan ini tidak dijadwalkan, kami hanya membahas spesifikasi di sini. Manajemen saya akan menjadwalkannya ketika mereka merasa sesuai dengan saran saya.

Tentang komentar Anda di atas yang terkait dengan ListView: Saya menghargai setiap tindakan berani yang diambil, termasuk mendesain ulang\menggantinya sepenuhnya. Ini tidak seperti semuanya begitu hebat di Xamarin Forms hal-hal yang tidak boleh disentuh\diubah.

ListView benar-benar adalah beruang bug dari Xamarin.Forms. Dari 500 masalah tersebut, 220 di antaranya ditandai sebagai bug (ada banyak masalah pembersihan atau peningkatan juga), 25% di utara hanya berkaitan dengan ListView. Sebagai perbandingan, itu kira-kira persentase yang sama yang berkaitan dengan seluruh platform UWP. Lebih buruk lagi, cukup banyak crasher di Android yang pada dasarnya digambarkan sebagai perender yang digunakan setelah dibuang juga merupakan bug ListView namun tidak mungkin muncul dalam pencarian saya karena ListView tidak akan muncul di mana pun dalam permintaan pencarian.

@jassmith selain memperbaiki masalah yang ada (selain ListView, ada hal-hal lain yang masih tidak selalu berfungsi dengan baik), ada juga fitur penting yang ditinggalkan (urutan acak):
- Dukungan popup sejati (fitur dasar dan umum masih belum ada)
- Batalkan navigasi halaman saat menavigasi kembali (masalah lama yang belum terselesaikan)
- Kontrol dasar hilang (tidak ada Kotak Centang, RadioButton, dan lainnya)
- Gambar lintas platform (Kontrol kanvas atau cara lain)
- Dukungan untuk menggambar lintas platform dari kuas padat\gradien (SolidColorBrush, GradientBrush)

Saya berharap lebih banyak pekerjaan dilakukan untuk membuat kerangka kerja benar-benar lebih kaya, dan tidak menambahkan hal-hal seperti gaya CSS atau Flexbox (yang datang dengan masalah mereka sendiri).

@opcodewriter

Dukungan popup sejati (fitur dasar dan umum masih belum ada)

Adil, sepertinya tidak pernah diprioritaskan cukup tinggi untuk menjadi nyata. Ini sebenarnya sudah cukup jauh pada satu titik.

Batalkan navigasi halaman saat menavigasi kembali (masalah lama yang belum terselesaikan)

Ini sebenarnya adalah sesuatu yang dimaksudkan MaterialShell untuk diatasi. Ada alasan yang cukup kuat mengapa ini tidak dapat dilakukan di NavigationPage.

Kontrol dasar tidak ada (tidak ada Kotak Centang, RadioButton, dan lainnya)

Beberapa di antaranya adalah bagian dari inisiatif F100 yang sedang berlangsung sekarang.

Gambar lintas platform (Kontrol kanvas atau cara lain)

Itu akan menjadi API saudara untuk ini seperti yang ditentukan dalam #2452

Dukungan untuk menggambar lintas platform dari sikat gradien padat (SolidColorBrush, GradientBrush)

Jawaban yang sama seperti di atas.

@jassmith

Adil, sepertinya tidak pernah diprioritaskan cukup tinggi untuk menjadi nyata. Ini sebenarnya sudah cukup jauh pada satu titik.

Oke, ditunggu prioritasnya di akhir 2018 :)

Ini sebenarnya adalah sesuatu yang dimaksudkan MaterialShell untuk diatasi. Ada alasan yang cukup kuat mengapa ini tidak dapat dilakukan di NavigationPage.

Bisakah Anda memberikan detail lebih lanjut mengapa ini tidak dapat dilakukan dalam implementasi saat ini?

Beberapa di antaranya adalah bagian dari inisiatif F100 yang sedang berlangsung sekarang.

Jadi begitu. Jari disilangkan..

Bisakah Anda memberikan detail lebih lanjut mengapa ini tidak dapat dilakukan dalam implementasi saat ini?

Saya tidak akan membahas ini lebih lanjut di sini karena kita keluar jalur secara besar-besaran tetapi intinya adalah sebagai berikut:

• Anda tidak dapat membatalkan gerakan gesek ke belakang di iOS secara reaktif. Karena ini adalah metode utama yang digunakan orang untuk menavigasi kembali dengan ponsel yang lebih besar, ini menjadi kelalaian yang mencolok.
• Meskipun secara teknis mungkin untuk mengganti perilaku ini di iOS, itu membutuhkan cukup jauh ke dalam internal UINavigationController dengan cara yang kami tidak yakin akan benar-benar didukung atau berfungsi ketika versi baru iOS keluar. Singkatnya Apple tampaknya tidak terlalu menikmati orang yang melakukan ini.

Ada beberapa masalah kecil lainnya di sana juga mengenai bagaimana hal itu memengaruhi gaya. Thats cerita panjang pendek namun. Jika Anda masih ingin mendiskusikan fitur khusus ini, saya sarankan untuk membuka edisi baru :)

@jassmith
Saya pikir hanya menangani gestureRecognizerShouldBegin dan memanggil sesuatu seperti OnBackButtonPressed sudah cukup.

Secara keseluruhan saya sangat menyukai banyak dari apa yang saya baca, namun ini tidak terasa seperti sesuatu yang harus dilakukan di inti Xamarin Forms nuget/repo.

Ini adalah pendekatan berpendirian yang harus dibangun di atas Formulir Xamarin, bukan dibangun di dalamnya. Saya melihat ini sebagai perpustakaan terpisah yang memungkinkan pengembang untuk mengambil pendekatan yang berbeda. Bagian yang diperlukan dari Formulir Xamarin yang perlu diekspos harus, dan ini harus dibangun di atas bit tersebut.

Sama seperti ketika pengembang membuat keputusan untuk menggunakan Xamarin Classic/Native atau Xamarin Forms, saya dapat melihat keputusan serupa untuk menggunakan Xamarin Forms atau Xamarin Forms dengan Shell.

Formulir Xamarin harus fokus pada pembuatan kerangka UI lintas platform terbaik tanpa mencoba menyesuaikan platform agar terlihat seperti satu sama lain. Hari ini Xamarin Forms melakukan pekerjaan yang baik untuk memastikan nuansa platform dihormati.

Saya bisa melihat Shell dasar berada di repo Xamarin Forms dan beberapa kode di sekitar penanganan Shells, tetapi Material Shell tampaknya terlalu erat digabungkan dengan bahasa desain dan pola navigasi tertentu bagi saya untuk berpikir itu harus di repo Xamarin Forms.

@MisterJimson
Terima kasih atas tanggapan Anda. Penempatan yang tepat dari area permukaan API publik belum diputuskan. Ada pro dan kontra dari kedua pendekatan tersebut.

Spesifikasi akan diperbarui (semoga segera) untuk memiliki kelas Shell dan MaterialShell. Kelas MaterialShell akan menjadi bagian yang kami pertimbangkan untuk keluar dari inti. Shell akan menjadi apa yang telah Anda jelaskan.

Diperbarui dengan terobosan Shell dan pembaruan spesifikasi navigasi

Saya sangat suka jika implementasi XF yang ada dibuat... lebih kuat dan lebih baik untuk memungkinkan sesuatu seperti ini ada sebagai addon, bukan sebagai bagian dari BCL. Jadi memiliki platform dasar yang kuat yang benar dan stabil akan menguntungkan aplikasi yang ada dan lapisan baru seperti ini.

Menantikan evolusi hal ini.

@jassmith @brianlagunas

Hanya beberapa pengamatan.

• BackButtonBehavior, tentunya harus ada properti visibilitas jika Anda tidak menginginkannya sama sekali?
• Skema navigasi materialshell seperti Prism, apakah akan berfungsi dengan kerangka kerja yang ada ini? (Prisma, FreshMVVM, MVVMCross)
• Bisakah Anda mengesampingkan sepenuhnya tata letak di bilah navigasi? seperti yang ada, Formulir sangat terbatas dalam hal ini dan Anda berakhir dengan bilah navigasi yang tampak kikuk yang memaksa Anda menyusuri rute customrenderer, aman karena mengetahui bahwa versi baru Formulir kemungkinan besar akan merusak kode khusus Anda.
• MasterDetail tidak banyak disentuh, apakah Anda dapat menyesuaikan menu flyout?
• Kontrol apa yang akan kita miliki atas hamburger?

Saya hanya ingin memastikan titik nyeri dan batasan yang ada diatasi serta kemampuan baru yang baru.

Kedengarannya bagus.

Saya sangat baru di XF tetapi kerangka kerja ini memiliki sedikit reputasi karena agak rapuh, meskipun tentu saja ini meningkat pesat berkat upaya Anda.

Jadi untuk apa nilainya, ini adalah pendapat saya :-)

Sangat bagus bahwa Xamarin mendapatkan banyak cinta saat ini, tetapi saya setuju dengan @opcodewriter , baik perkakas maupun kerangka kerja dapat dilakukan dengan pembayaran utang teknis.

Saya juga menyukai pemikiran dari @MisterJimson bahwa ini harus menjadi lapisan yang berbeda - tetapi Anda harus jujur ​​pada diri sendiri tentang kapasitas Anda dan berapa banyak kerangka kerja yang dapat Anda dukung. Kita semua cenderung untuk mengkodekan hal-hal baru yang menarik, dan menghindari keputusan yang sulit, tetapi kami mengandalkan Anda untuk mengembangkan dasar yang kuat untuk kode kami.

Saya memiliki cukup banyak masalah untuk membuat kode saya berfungsi tanpa khawatir tentang orang lain :-)

XF berada di tempat yang baik saat ini, ia memiliki potensi untuk menjadi perangkat yang sangat solid.

Terima kasih atas semua kerja keras Anda dalam hal ini, itu memang terlihat.

@mackayn

BackButtonBehavior, tentunya harus ada properti visibilitas jika Anda tidak menginginkannya sama sekali?

Setel perintah dengan CanExecute mengembalikan false. Saya memilih untuk tidak menambahkan metode sekunder untuk saat ini.

Skema navigasi materialshell seperti Prism, apakah akan berfungsi dengan kerangka kerja yang ada ini? (Prisma, FreshMVVM, MVVMCross)

Saya yakin berharap begitu! Saya tidak yakin tetapi saya memikirkan mereka dan semua masalah mereka. Itu sebabnya semua navigasi terjadi melalui satu peristiwa misalnya.

Bisakah Anda mengesampingkan sepenuhnya tata letak di bilah navigasi? seperti yang ada, Formulir sangat terbatas dalam hal ini dan Anda berakhir dengan bilah navigasi yang tampak kikuk yang memaksa Anda menyusuri rute customrenderer, aman karena mengetahui bahwa versi baru Formulir kemungkinan besar akan merusak kode khusus Anda.

Bagian ini lebih sulit. Saya ingin mengizinkan ekstensibilitas sebanyak mungkin di sini, tetapi saya sangat terbuka untuk saran tentang cara meningkatkan ini dengan cara yang waras dan masuk akal.

MasterDetail tidak banyak disentuh, apakah Anda dapat menyesuaikan menu flyout?

Anda dapat mengatur header ke tampilan sembarang, Anda mengontrol template yang digunakan untuk header dan item grup, dan Anda dapat menambahkan item menu. Anda mengontrol beberapa aspek tata letak tetapi tidak 100%. Sekali lagi akan lebih baik untuk mendapatkan beberapa pemikiran tentang apa lagi yang Anda pikir Anda butuhkan. Saya jelas melihat kebutuhan akan footer dengan properti perilaku footer.

Kontrol apa yang akan kita miliki atas hamburger?

BackButtonBehavior juga menimpa hamburger. Mungkin harus diganti namanya. Sekali lagi saya terbuka untuk saran di sini. Awalnya saya menyebutnya LeftBarButton, tetapi dalam situasi RTL itu tidak di sebelah kiri ...

@stevehurcombe pengembalian teknis terus dan berkelanjutan. Ini akan dijalankan secara paralel oleh kontingen tim yang jauh lebih kecil. Sayangnya kenyataannya banyak dari spesifikasi ini adalah tentang pengembalian teknis dengan cara yang aneh. Xamarin.Forms mengeluarkan sejumlah besar hutang API dengan rilis 1.0-nya, dan telah membawa hutang itu sejak saat itu. Hal-hal tertentu di XF sangat sulit untuk membuat pekerjaan menjadi benar, atau bahkan tidak mungkin untuk membuat pekerjaan menjadi benar, hanya karena cara API mengekspresikannya.

Interaksi ketat antara tabbar dan navbar adalah salah satu area tersebut, memastikan navigasi antar tab atau item di MDP bebas kesalahan adalah area lain. Ada banyak area di mana cegukan kecil akan terjadi karena setiap elemen tidak dapat mengambil tampilan holistik dari shell aplikasi Anda.

Adapun perkakas, ada tim yang sepenuhnya terpisah yang didedikasikan untuk ini dan mereka membuat langkah besar. Perkakas internal telah meningkat secara besar-besaran dalam 6 bulan terakhir dan saya sangat menantikan Anda untuk mencobanya!

@mackayn

Skema navigasi materialshell seperti Prism, apakah akan berfungsi dengan kerangka kerja yang ada ini? (Prisma, FreshMVVM, MVVMCross)

Jangan takut, @jassmith membawa ini ke perhatian saya sebelum komunitas menyadari bahwa masalahnya ada di sini... jadi saya dapat mengatakan dengan yakin, ini adalah masalah yang pasti dia pedulikan sama seperti kita. Anda dapat yakin bahwa itu akan menjadi sesuatu yang kami ingin dukung. Sesuatu sebesar ini tentu akan membutuhkan banyak dialog lintas tim untuk memastikan bahwa itu memenuhi kebutuhan pengembang Formulir secara luas, serta memenuhi kebutuhan kerangka kerja MVVM seperti Prism.

@dansiegel

Senang mengetahui kedua tim sedang berdialog, itu saja yang perlu saya ketahui 👍

@jassmith Sudah jelas sekarang cara beberapa hal berjalan atau berarsitektur di XF bukan yang terbaik. Jadi, alih-alih mengoleskan lipstik pada babi (tidak ingin bersikap kasar di sini), mengapa tidak membuat ulang kerangka kerja baru dari awal atau memfaktorkan ulang kerangka kerja yang sudah ada secara besar-besaran. Saya tahu, kedengarannya sangat menakutkan, tetapi saya cukup yakin sebagian besar pengembang Xamarin Forms tidak akan keberatan, kita semua akan senang untuk memperbaiki aplikasi kita atau apa pun hanya agar kita memiliki aplikasi yang berjalan jauh lebih baik.
Saya telah melihat PR ditolak dengan refactoring yang baik karena "kami tidak menginginkan perubahan seperti ini". Saya tidak yakin siapa yang membuat aturan itu, tetapi dia harus mengambil napas dalam-dalam, rileks dan mungkin mempertimbangkan kembali "aturan".
Apa yang terbaik: Tetap membuat pengembang frustrasi menggunakan kerangka kerja yang tidak dapat mempertahankannya atau membuat pengembang frustrasi yang perlu melakukan pekerjaan refactoring? Hanya 2 sen saya...

@opcodewriter Anda dan saya setuju tetapi ini di luar topik untuk spesifikasi ini.

Baca saja materi baru seputar navigasi dan saya sangat menyukainya. Senang memiliki tangan yang baik untuk mengikat perintah navigasi, dan mengarahkan navigasi di sekitar URL (seperti dan saya berasumsi dipengaruhi oleh Prism) adalah cerdas.

Ironisnya skema navigasi URI adalah sesuatu yang ingin kami lakukan di masa lalu dan mulai mendorong Prism untuk mengimplementasikannya karena kami tidak dapat memasukkannya ke dalam kerangka kerja. Tidak untuk mengambil kredit mereka, mereka layak mendapatkan 100% dari itu :)

Semantik yang tepat dari steno masih diperebutkan.

Saya pikir itu kemungkinan akan berakhir lebih seperti:

<Button Command="{segue:Uri}" CommandParameter="app://Foo/Bar/Baz" />

atau

<Button Command="{segue:Push}" CommandParameter="{DataTemplate local:MyPage}" />

Jadi ekstensi bisa lebih tepat tentang parameter apa yang mereka ambil. Namespace digunakan sebagian besar untuk menjaga hal-hal mudah ditemukan dengan intellisense.

@jassmith Saya sangat suka hal segue ini. Bisakah saya bertanya bagaimana Anda ingin mendukung modal push?

Saya tidak memiliki semua detailnya, tetapi saya dapat membayangkan url nav seperti prisma, terbungkus dalam ekstensi markup.

<!-- push -->
<Button Command="{segue:Uri}" CommandParameter="path/to/page" />

<!-- push modal -->
<Button Command="{segue:Uri Modal='true'}" CommandParameter="path/to/page" />

<!-- reset stack -->
<Button Command="{segue:Uri}" CommandParameter="app://root/path/to/page" />

Hal pertama yang perlu diperhatikan adalah bahwa navigasi URI hanya akan bekerja dengan Shell. Ini adalah satu-satunya tempat kami dapat secara konsisten memahami tumpukan tanpa memiliki kasus tepi yang aneh dan kami dapat merancang interaksi navigasi untuk mendukung konsep tersebut.

Untuk saat ini kami hanya mendukung URI penuh. Sebagian jauh lebih sulit untuk ditangani karena bersifat kontekstual.

3 contoh Anda adalah, dengan asumsi lokasi saat ini adalah: app://Shell/Apps/Games/Details

Khususnya ini berarti Anda berada di Shell, yang ShellItemnya saat ini memiliki Rute Aplikasi, yang ShellTabItemnya saat ini memiliki rute Game, yang memiliki ContentPage yang didorong ke tumpukannya yang memiliki Detail Rute.

<!-- push -->
<Button Command="{segue:Uri}" CommandParameter="app://Shell/Apps/Games/Details/page" />

<!-- push modal -->
<Button Command="{segue:Uri}" CommandParameter="app://page" />

<!-- reset stack -->
<Button Command="{segue:Uri}" CommandParameter="app://Shell/Apps/Games" />

Dalam shell uri, lokasi pertama selalu merupakan Shell. Jika tidak, itu dianggap sebagai dorongan modal. Berikutnya adalah ShellTab, lalu ShellTabItem. Setelah itu ikuti tumpukan navigasi ShellTabItem. Saya tidak berniat untuk mem-backport nav URI ke semua kontrol halaman yang mungkin saat ini. Ini menjadi BENAR-BENAR berbulu dengan orang-orang yang menggunakan MasterDetailPage ...

Dengan registrasi Rute dan properti Rute, tidak diperlukan perutean berbasis tipe. Saya akan menghapusnya dari spesifikasi.

@jassmith lebih memikirkan hal-hal navigasi ini, dan saya punya beberapa pertanyaan

1. bagaimana Anda bisa menangani CanExecute
2. bagaimana Anda bisa memberi pengguna kontrol atas (baca mencegah) beberapa ketukan?
3. bagaimana Anda menangani navigasi relatif? IE Anda 3 halaman dalam dan harus maju, tetapi tumpukannya sepenuhnya dinamis?
4. prisma memiliki gagasan fantastis tentang NavigationParameters dimana kita tidak hanya dapat meneruskan nilai dasar melalui querystring /Navigation/MyPage/MyPageDetails?id=33 , tetapi juga objek kompleks new NavigationParameters {{nameof(MyObject), MyObject}} . Apakah Anda berencana untuk mendukung sesuatu yang serupa?

@ChaseFlorell

1) Dengan segues? Anda tidak bisa saat ini. Pasti perlu dipikirkan lebih lanjut. Ada cara untuk membuat perintah segue tapi ... menyebalkan. Itu akan membiarkan Anda menanganinya tetapi pada saat itu BENAR-BENAR tidak sepadan.

2) Segue akan menonaktifkan dirinya sendiri sampai push selesai. Upaya lebih lanjut untuk mengaktifkan perintah no-op hingga tugas navigasi sebelumnya selesai.

3) Anda dapat menggunakan navigasi tradisional seperti push/pop dengan segues. Ini adalah tindakan relatif.

4) [QueryParameterAttribute] mungkin sudah ada atau belum, saya tidak bisa mengonfirmasi atau menyangkal. ;)

Tidak mungkin kami akan menambahkan dukungan objek kompleks. Idenya adalah Anda menggunakan konverter untuk mengambil nilai sederhana Anda dan mengubahnya menjadi objek yang kompleks.

Dari pengalaman sebelumnya membangun navigasi aplikasi berbasis URI (kembali ke Blok Aplikasi UI Komposit CAB untuk p&p), saya sangat menyarankan Anda untuk tidak menggunakan tipe System.Uri dan sebagai gantinya hanya membuat semuanya terlihat seperti URI, tetapi tidak menggunakan implementasi URI itu sendiri. @pprovost dapat bersaksi tentang bekas luka seumur hidup yang harus ditinggalkan oleh pekerjaan dalam dirinya. Saya ingat menghadapi banyak masalah saat kami menghadapi batasan dan kesalahan URI internet (yaitu pada nama host) yang kami tidak pedulikan dengan hal-hal dalam aplikasi.

Sebagian dari kerusakan sudah terjadi , kurasa.

Sebenarnya System.Uri adalah pilihan terbaik saat mendukung skema navigasi berbasis URI. Meskipun CAB memang menggunakan navigasi URI, CAB juga melakukan seperti yang Anda katakan dan membuatnya "terlihat seperti" URI dengan mengizinkan Anda menggunakan string alih-alih objek System.Uri. Nama host tidak pernah diperlukan.

Apa yang Anda minta adalah API berbasis string yang sangat longgar yang dapat menerima sintaks string apa pun yang Anda masukkan ke dalamnya, yang bukan sesuatu yang akan menghasilkan hasil yang dapat diprediksi. Harus ada aturan agar skema navigasi berbasis URI/string berfungsi.

URI arbitrer juga tidak akan berfungsi di XF. Daftar karakter yang tidak valid dalam URL tetapi valid dalam sistem file tidak terlalu kecil. Itu semua adalah kasus di mana string akan berfungsi, dan URI tidak akan dan perlu melarikan diri atau meminta pengguna mencari tahu mengapa sesuatu tidak berfungsi (atau gagal?) Dan mengganti nama barang menjadi "URI aman".

Anda dapat membuat abstraksi Anda sendiri jika Anda ingin lebih membatasi (atau semantik/parsing/validasi yang lebih baik?), tetapi IMHO, System.Uri membawa banyak bagasi internet yang tidak gratis. Ini mirip dengan bagaimana Mono/MonoDevelop membuat FilePath sendiri untuk mewakili jalur, yang biasanya hanya berupa string.

Setidaknya, tampaknya semua URI dianggap relatif, yang menyederhanakan banyak hal. Di CAB kami menggunakan uris absolut dengan bagian skema dan nama host juga, yang bermasalah.

Saya lebih suka sesuatu seperti ResoucePath , katakanlah, daripada Uri . Tapi di akhir permainan ini, saya cukup yakin itu sudah selesai.

Saya tidak yakin menurut Anda apa hubungannya jalur sistem file dengan apa pun ...

Bagaimana Anda menggunakan URI untuk membingungkan sistem? Ini akan mengabaikan skema dan nama host dan mulai mencari rute (yang terbatas hanya untuk [az]). Jika karakter aneh apa pun yang Anda masukkan tidak dapat ditemukan, itu akan berhenti. Dan string kueri yang Anda masukkan harus berupa pengidentifikasi C# yang valid atau tidak akan cocok. Data yang lolos dalam data string kueri tidak akan lolos.

@ kzu URI berfungsi dengan baik di XF, dan lebih cocok untuk XF daripada skema sistem file. Bahkan URI diharapkan saat meluncurkan aplikasi Anda dari situs web. Anda harus memeriksa seberapa kuat navigasi berbasis URI dengan melihat implementasi Prism. Dari semua aplikasi di luar sana yang dibangun dengan Prism menggunakan skema navigasi berbasis URI, tidak pernah ada masalah yang dikirimkan terkait dengan karakter yang tidak valid. Saya yakin kekhawatiran Anda tentang skema berbasis URI untuk platform XF tidak akan menjadi masalah.

Masuk akal. Terima kasih atas info latar belakang Prism @brianlagunas! Sekarang saya harus hati-hati membaca spesifikasi dan memberikan beberapa umpan balik yang benar-benar berguna ;)

Inisiatif yang sangat bagus, tetapi saya harap ekstensibilitas dan penyesuaian diperhitungkan dengan menciptakan metode virtual yang tepat atau cara lain untuk melakukan hal "khusus" kami bagi pelanggan kami.

Misalnya apakah mungkin / bagaimana:

1. Ekstensibilitas tab misalnya menampilkan lencana dengan ikon. Atau menampilkan laci popup di atas laci seperti tombol "lebih" atau " * ".
2. Snackbar khusus (misalnya dengan tombol "Batalkan" untuk tindakan yang baru saja Anda lakukan dengan warna latar/latar depan khusus)
3. Fragment mendorong di Android menggunakan animasi yang berbeda dari default yang diprogram di Shell, seperti tidak ada animasi untuk memberikan navigasi secepat mungkin.

Pada catatan teknis: akankah shell mendaur ulang halaman sehingga sekali bernavigasi dua kali ke halaman, elemen asli akan digunakan kembali dengan vm berbeda di bawahnya?

Hai @rogihee

Saya menyambut umpan balik Anda tentang implementasinya. Saya pikir itu gila extensible: https://github.com/xamarin/Xamarin.Forms/blob/9558f2837280e02b41848d3a3c3213d49a664751/Xamarin.Forms.Platform.iOS/Renderers/ShellRenderer.cs

Android masih dalam pengembangan yang berat saat ini, namun menggunakan pendekatan yang sama.

@rogihee untuk daur ulang halaman, saya mencoba mencari metode yang waras untuk membuatnya layak. Secara umum saat ini tidak karena perlu secara eksplisit ikut serta.

Terlihat bagus opsi "Buat*" ini. Senang melihat kemajuan pesat dalam hal ini!

Saya ingin tahu apakah ada implikasi kinerja dengan menggunakan kembali elemen. Secara pribadi, saya akan memprioritaskan kecepatan dan nuansa "cair" aplikasi daripada penggunaan Mem/CPU yang lebih tinggi (walaupun ada korelasi di suatu tempat di akhir tentu saja). Dan prioritaskan iOS / Android daripada yang lain :-).

Shell sangat terfokus pada persepsi fluiditas. Itu belum ada di mana-mana tapi sudah menyatu.

Saya benar-benar perlu menempatkan beberapa pengguna awal yang mencoba melakukan hal-hal gila dengan Shell untuk memastikannya dapat menangani beban yang dirancang untuknya.

@jassmith mig baru saja menyebutkan shell selama 3 menit di Build.....

aku bukan ayahnya

+1

API yang diperbarui agar sesuai dengan keadaan dunia saat ini, masih perlu memperbarui sampel.

Menambahkan beberapa sampel yang diperbarui, masih perlu melakukan banyak pekerjaan untuk memperbaiki sampel lain dan memperbarui deskripsi rute saat menggunakan sintaks steno (saat Anda mendapatkan rute steno!)

Astaga, aku merasa sangat terlambat ke pesta. Tulisan dan diskusi yang bagus. Saya membaca sekilas semuanya (maaf di bandara) dan punya saran sendiri. Maaf jika ini disebutkan di tempat lain.

@jassmith @migueldeicaza Bisakah Anda menambahkan perilaku ke bilah navigasi sehingga dapat digulir ketika ListView bergulir dan ditampilkan ketika digulir ke arah yang berlawanan. Hampir semua aplikasi profesional di luar sana melakukan ini untuk menunjukkan lebih banyak real estat. Ini akan sangat berguna pada perangkat kecil.

Satu lagi adalah mengapa Anda tidak mengganti nama tag XAML agar lebih mudah dipahami? Mungkin menggunakan Tab alih-alih ShellSection? Ada banyak tag ShellX sekarang.

Untuk iOS, saya yakin ada properti untuk mengaktifkan/menonaktifkan untuk mengaktifkan mode gulir di bilah navigasi. Untuk Android, Anda harus mulai menggunakan tata letak baru (CoordinatorLayout, AppBarLayout, dll.). Implementasi Android XF cukup ketinggalan jaman dalam hal ini karena masih menggunakan RelativeLayout sebagai wadah utama. Saya pikir ada tiket Peningkatan di suatu tempat tentang masalah khusus ini. Saya ingin melihat Shell mendukung mode gulir yang berbeda.

Selain itu, kami sering kali harus menerapkan perilaku khusus untuk menampilkan kesalahan/jenis sembulan lainnya di laman. Shell harus mendukung fungsi ini secara langsung sehingga kita tidak perlu menggunakan plugin pihak ketiga atau membuat hierarki UI yang rumit.

@adrianknight89

Bisakah Anda menambahkan perilaku ke bilah navigasi sehingga dapat digulir saat ListView bergulir dan ditampilkan saat digulir ke arah yang berlawanan. Hampir semua aplikasi profesional di luar sana melakukan ini untuk menunjukkan lebih banyak real estat. Ini akan sangat berguna pada perangkat kecil.

Itu adalah sesuatu yang saya benar-benar mencoba untuk mencari cara yang tepat untuk dilakukan. Sayangnya tidak semua platform mendukung fitur ini sehingga mungkin akan menjadi kesepakatan khusus platform. Android setidaknya dibangun untuk mendukung ini, saya menyalakannya sesekali untuk memastikannya masih berfungsi.

Satu lagi adalah mengapa Anda tidak mengganti nama tag XAML agar lebih mudah dipahami? Mungkin menggunakan Tab alih-alih ShellSection? Ada banyak tag ShellX sekarang.

Penamaan di sini BENAR-BENAR sulit. ShellTab agak membingungkan untuk bagian atas vs. bawah. Saya malah memilih nama hierarki yang lebih umum, namun saya harus mengakui bahwa saya tidak senang dengan penamaan. Saran diterima 100% ... tidak sepenuhnya berharap untuk refactoring nama mereka LAGI tapi apa yang bisa Anda lakukan ...

Untuk iOS, saya yakin ada properti untuk mengaktifkan/menonaktifkan untuk mengaktifkan mode gulir di bilah navigasi. Untuk Android, Anda harus mulai menggunakan tata letak baru (CoordinatorLayout, AppBarLayout, dll.). Implementasi Android XF cukup ketinggalan jaman dalam hal ini karena masih menggunakan RelativeLayout sebagai wadah utama. Saya pikir ada tiket Peningkatan di suatu tempat tentang masalah khusus ini. Saya ingin melihat Shell mendukung mode gulir yang berbeda.

Shell menggunakan CoordinatorLayout + AppBarLayout dan pada dasarnya "menonaktifkan" dukungan gulir untuk saat ini, namun tetap berfungsi. Pengguliran iOS juga mudah diterapkan. Sayangnya NavigationView UWP tidak memiliki dukungan untuk fitur ini.

Selain itu, kami sering kali harus menerapkan perilaku khusus untuk menampilkan kesalahan/jenis sembulan lainnya di laman. Shell harus mendukung fungsi ini secara langsung sehingga kita tidak perlu menggunakan plugin pihak ketiga atau membuat hierarki UI yang rumit.

Contoh, saya butuh contoh :)

@jassmith

Saya menggunakan plugin konektivitas James Montemagno untuk mendengarkan perubahan status koneksi data. Saat koneksi Internet terputus, praktik yang baik adalah menampilkan pemberitahuan yang meluncur/memudar keluar-masuk atau tetap diam hingga Internet kembali online.

Di Instagram, notifikasi ini ditempatkan tepat di bawah bilah navigasi. Di Tumblr, itu tepat di atas bilah navigasi bawah. Di YouTube, anehnya itu ada di bawah bilah navigasi bawah. Mungkin sesuatu seperti ini bisa menjadi bagian dari Shell?

Kontrol Popup yang diusulkan, sejauh yang saya tahu, melapisi jendela yang ada meskipun dapat diabaikan. Pemberitahuan yang baru saja saya sebutkan dan kemungkinan jenis pemberitahuan lainnya tidak perlu menutupi jendela induknya (yaitu pohon visual induk masih responsif terhadap gerakan), jadi saya tidak yakin apakah Popup cocok.

Shell dapat memiliki properti bagi kita untuk menentukan bagaimana Tampilan ini (sebut saja Notification[View]) akan terlihat serta penempatan dan perilaku animasi masuk/keluarnya. Jadi pada dasarnya implementasi cross-platform toast/snackbar built-in ke Shell, INavigation, atau yang lainnya. Ini tidak akan dipaksa untuk terlihat asli per platform tetapi sama di semua.

Sehubungan dengan argumen yang dibuat seputar stabilitas, fleksibilitas, dll., Tanpa menghilangkan arsitektur usang yang berasal dari 1.0, saya rasa tidak layak untuk mencapai hal-hal itu. Saya sangat mendukung ListView2.

@jassmith

• Apakah Anda sudah memiliki tiket peningkatan untuk ListView baru?
• Menurut Anda kapan v1.0 akan keluar? Adakah kemungkinan kita bisa melihatnya dengan EOY?

Juga, saya memiliki kekhawatiran yang sama tentang tim yang terlalu kecil. Sebenarnya, saya sudah membicarakan ini sebelumnya di masa lalu. Saya berharap tim dapat tumbuh jauh lebih besar di masa depan. 🙏 @davidortinau @migueldeicaza

@jassmith Saya sudah percaya untuk sementara waktu sekarang bahwa jika kami memiliki Renderer untuk kelas Aplikasi, kami dapat melakukan banyak hal yang saat ini membutuhkan peretasan pihak ke-3 untuk dicapai. Misalnya, plugin RgPopups mengambil tampilan utama aplikasi dan menyuntikkan tampilan yang dirender ke dalamnya untuk memberikan tampilan popup seluruh layar. Ini saat ini tidak mungkin dicapai dengan Formulir Xamarin "murni". Namun jika App memiliki Renderer, kami dapat melakukannya sendiri.

Saya siap menambahkan pemberitahuan roti panggang semacam ini ke Shell, hanya mencoba mencari tahu bagaimana hal itu harus dilakukan.

Bisakah Anda membuatnya sehingga Anda dapat meletakkan halaman secara sewenang-wenang di mana pun Anda inginkan di dalam aplikasi? Ini sangat penting pada tablet/desktop/laptop (perangkat layar yang lebih besar), di mana Anda ingin beberapa halaman di layar secara bersamaan, dan tidak perlu mengaturnya menggunakan tampilan terpisah (halaman detail master). Contoh, lihat Google Maps:

Perhatikan bagaimana konten "mengambang" di atas peta (tidak ada tampilan terpisah). Jika Anda ingin menggunakan hal-hal seperti tab, atau navigasi di dalam area mengambang, maka Anda tidak dapat menyelesaikan hal semacam ini dengan Xamarin Forms, di luar kotak, karena hierarki yang sangat terbatas dengan halaman (tidak dapat membuat sarang halaman di dalam tampilan). Kami sebenarnya mengembangkan tampilan kustom kami sendiri yang menyediakan kemampuan yang mirip dengan NavigationPage tetapi merupakan tampilan, hanya agar kami dapat menyelesaikan tata letak semacam ini, tetapi banyak pekerjaan/sulit yang harus dilakukan.

Seharusnya dimungkinkan untuk menempatkan konten (termasuk halaman) di mana pun Anda inginkan di dalam aplikasi.

Bisakah Anda membuatnya sehingga Anda dapat meletakkan halaman secara sewenang-wenang di mana pun Anda inginkan di dalam aplikasi?

Saya agak penasaran @jsiemens karena tampilan ini kemungkinan tidak akan terlihat tepat di Ponsel, tetapi terlihat bagus di Desktop dan Tablet. Bisakah Anda memperluas tentang bagaimana Anda mungkin mengharapkannya bekerja. Pada akhirnya saya akan tergoda untuk mengatakan Anda membawa konsep Wilayah ke dalam Formulir dari Wpf. Reaksi spontan saya adalah bahwa meskipun saya menyukai konsepnya, kami berisiko membuat API Navigasi yang sudah rumit memerlukan gelar PhD atau setidaknya IQ tingkat jenius yang tidak akan menjadi hal terbaik untuk diadopsi pengguna.

@dansiegel Setidaknya secara pribadi, saya mungkin akan menggunakan VSM atau yang setara untuk memindahkan dan memadatkan tampilan gulir di bagian bawah ketika di bawah ambang batas viewport tertentu (seperti yang dilakukan GMaps saat ini). Akan penasaran untuk melihat bagaimana navigasi dan manajemen negara akan bekerja untuk itu.

Navigasi: Saya yakin itu bukan masalah yang tidak dapat diatasi jika Anda memulai dari perspektif perjalanan pengguna dan kemudian melihat bagaimana pengguna mengharapkannya bekerja. Navigasi harus responsif terhadap sifat layar penuh ponsel vs tampilan yang lebih kecil di layar yang lebih besar misalnya.

Pengguna akan 'melihat' tablet dan tampilan yang lebih kecil sebagai tonggak navigasi tunggal. Di layar kecil mungkin ada dua tonggak sejarah. Navigasinya, entah bagaimana, harus responsif.

Sebagai developer tentunya kita harus menangani sifat responsif tersebut karena merupakan hal yang kontekstual. Kami tidak dapat mengandalkan kerangka kerja untuk menangani itu bagi kami, tetapi kerangka kerja perlu mendukungnya.

@jsiemens @dansiegel Cara saya menangani ini saat ini menggunakan ControlTemplate s. Saya membuat konten tipe "halaman" saya sebagai ContentView s dan menyimpannya dalam ContentPage (di dalam NavigationPage ) yang sesuai dengan platform. Menggunakan ControlTemplates berarti saya dapat memiliki banyak ikatan ContentViews (biasanya dalam Grid sehingga saya dapat melapisi barang-barang) yang diaktifkan/dinonaktifkan berdasarkan properti yang dapat diikat di ControlTemplate itu sendiri (Anda juga dapat menggunakan DynamicResource s). Hasil akhirnya bekerja sedikit seperti panel CSS di situs web, di mana semua konten ada di halaman tetapi tidak semuanya terlihat setiap saat. ControlTemplate s ajaib untuk ini dan saya ingin kemampuan mereka dipertahankan di Shell.

@dansiegel Saya hanya akan mengkodekannya untuk memuat shell yang berbeda tergantung pada apakah aplikasi berjalan di ponsel vs tablet/laptop/desktop.

@jsiemens tidak apa-apa, komentar saya hanya dimaksudkan untuk memacu percakapan lebih lanjut dan pemikiran kritis untuk lebih menyempurnakan ide Anda. Dalam beberapa hal saya hampir mengatakan mengingat konsep Anda di sini, bahwa setiap halaman pada dasarnya bisa menjadi MultiPage di mana Halaman dapat dilampirkan ke kontrol yang diberikan dan diperlakukan lebih hanya sebagai Tampilan lain vs navigasi normal.

@dansiegel Ya, saya pikir itulah yang saya cari untuk dapat menambahkan halaman ke mana saja di dalam aplikasi. Sungguh aneh bahwa Xamarin Forms memberlakukan batasan ini ketika platform yang mendasarinya tidak (mis. iOS hanyalah hierarki tampilan hierarki - Anda dapat menambahkan tampilan NavigationController secara harfiah di mana saja dalam aplikasi). Juga, komentar saya dimaksudkan untuk menunjukkan bahwa spesifikasi Shell tidak perlu membahas ini - saya tidak berpikir bahwa tata letak "responsif" perlu menjadi perhatian. Saya pikir selama mungkin untuk membangun tata letak, maka kita dapat menangani pemuatan shell secara kondisional tergantung pada faktor bentuk, dan itu cukup baik.

Saya kira itu tidak sepenuhnya pada topik untuk spesifikasi ini, tetapi saya menyebutkannya di sini karena kita berbicara tentang bagaimana membangun tata letak yang kompleks (misalnya. Prioritas ke-3

Saya tidak tahu bagaimana ini akan diselesaikan menggunakan Shell, tetapi reaksi awal saya terhadap Shell adalah tampaknya tidak melakukan apa pun yang belum dapat saya lakukan. Saya biasanya merasa seperti tim Xamarin Forms terus membangun fitur yang memungkinkan saya melakukan hal-hal yang sudah dapat saya lakukan, tetapi hanya dengan cara yang berbeda (mis. CSS, Visual State Manager, dan sekarang spesifikasi Menggambar dan Shell). Jadi itu tidak membawa banyak nilai bagi saya. Saya lebih suka memiliki fitur baru yang memungkinkan saya melakukan hal-hal yang sebelumnya tidak dapat saya lakukan (di luar kontrol dan/atau perender khusus). Jika shell adalah jawaban untuk mencapai itu karena sintaksnya lebih elegan, maka saya setuju, tetapi pada akhirnya saya ingin itu menjadi lebih kuat dan lebih ekspresif daripada hierarki Halaman/Tampilan saat ini karena itu benar-benar membawa nilai.

Bisakah Anda memisahkan dari membuat tampilan asli per tampilan xamarin jika semua subview dalam tata letak dapat dirender tanpa menggunakan widget asli? Jenis pendekatan flutter/xamarin hibrida otomatis di mana kelompok tampilan XF dirender ke satu permukaan dan hanya dihapus ke satu tampilan asli. Menghindari pembuatan/tata letak tampilan Android c# -> biaya interop java akan berguna.

sedang berlangsung!!

@jassmith setelah shell selesai, apakah undian akan valid bersama?

apakah shell akan mendukung macos dan wpf?

@juepiezhongren target awalnya adalah iOS dan Android. Platform lain akan diprioritaskan setelah itu.

Menggambar saat ini tidak sedang dikembangkan. Dalam spesifikasinya saat ini, itu akan valid dengan Shell. Sama seperti hari ini Anda dapat menggunakan kontrol berbasis SkiaSharp dan Skia dalam Xamarin.Forms.

Kami sedang mengerjakan strategi asli lainnya untuk mendukung desain yang konsisten untuk material dan gaya desain lainnya.

@davidortinau Apakah shell membuat dukungan RTL lebih baik?

Lebih baik dengan cara apa? Apa yang Anda lewatkan dari dukungan RTL hari ini? Kita harus mengatasinya di mana-mana.

Sejujurnya, saya sudah lama tidak melakukan pengembangan XF, tetapi sebagian besar batasannya diketahui: Lihat #1222 dan #2448

Mungkin Shell dapat membantu dengan batasan umum ini:

• Lokasi tombol NavigationPage, lokasi item toolbar, dan animasi transisi saat ini dikendalikan oleh lokal perangkat, bukan pengaturan FlowDirection.
• Pengaturan aplikasi global untuk FlowDirection

Dan beberapa batasan khusus platform lainnya

Fitur paling penting dari Xamarin.Forms. Seharusnya dibangun seperti ini di tempat pertama.

tanpa menggambar, xf masih banyak kekurangan

@juepiezhongren

Cukup gunakan Skiasharp

@mackayn saya sering menggunakannya
https://github.com/xamarin/Xamarin.Forms/issues/1789
tampilan universal adalah suatu keharusan

adam pergi ke flutter, itu benar-benar pertanda sedih untuk xf, di mana xamarin awalnya dapat dengan mudah mencapai reputasi yang jauh lebih baik

xamarin.native jauh lebih solid untuk xf, daripada solusi lintas platform lainnya, apa pun reaksi asli atau flutter. Sebagai pecinta dotnet, situasi xf saat ini selalu sedikit mengecewakan bagi saya.

@juepiezhongren

Diskusi ini tidak ada gunanya, jika tidak memenuhi kebutuhan Anda menggunakan Flutter, ini memungkinkan kami untuk memberikan aplikasi di berbagai platform (iOS dan Android hanya dengan Flutter dll), perubahan ini akan membuat tampilan dan nuansa yang konsisten lebih dapat dicapai.

mengeluh kecil sederhana, hanya begitu banyak. Masih hore untuk shell!

Saya setuju akan lebih baik jika Skia lebih banyak dipanggang ke dalam api Formulir (seperti yang telah dilakukan Telerik). Saya setuju.

Saya senang mereka menginvestasikan upaya ke Shell & CollectionView sekalipun.

hai, tolong semua orang berkata, bagaimana saya bisa menggunakan flayout di kanan, untuk bahasa kanan ke kiri.

Hai,

Saya suka idenya, tetapi saya hanya punya beberapa masukan kecil.
Saya kira saya agak terlambat, tetapi penamaannya agak membingungkan, saya pikir.

1. Item, Bagian, dan Konten semuanya, nama yang sangat umum. Tidak segera jelas dalam hubungan apa itu. Apakah itu Konten => Bagian => Item atau Bagian => Konten => Item, atau Item => Bagian => Konten.
   Jadi kita mungkin bisa menentukan sedikit lebih banyak tentang "hal-hal" yang berbeda itu, dengan mencari nama yang lebih spesifik.

2. Itu membawa saya ke masukan berikutnya. Kami memiliki Shell sebagai wadah untuk semua item dalam. Jadi tidak bisakah kita menggunakan nama langsung seperti "Item" alih-alih "ShellItem" di dalamnya. Sepertinya saya agak tidak perlu memanggil semua "hal" Shelltem, ShellSection dll. Tapi ok. itu bisa diperdebatkan.

Aduh

Apakah masih akan dirilis pada 2018?

Kami memiliki rilis pratinjau yang tersedia SEKARANG! Lihatlah https://blog.xamarin.com/connect-2018-xamarin-announcements/ untuk beberapa contoh yang bagus.

Apakah kita benar-benar membutuhkan Android 9? Itu tampaknya menjadi sedikit batasan.

Semuanya terdengar cukup bagus, tetapi tampaknya murni berdasarkan interaksi UI.
Saya kira saya akan mengetahuinya ketika saya mencobanya, tetapi perhatian awal saya adalah bagaimana cara mengarahkan navigasi dari logika bisnis atau kode misalnya pesan yang diterima dari perangkat yang terhubung Bluetooth memicu perubahan halaman, sambil mempertahankan pemisahan masalah yang layak?

@hassanrahimi

hai, tolong semua orang berkata, bagaimana saya bisa menggunakan flayout di kanan, untuk bahasa kanan ke kiri.

Sementara RTL didukung, menu flyout masih muncul di sebelah kiri. Ini adalah batasan saat ini.

Apakah mungkin untuk menyesuaikan ui tabbar bawah?

Apakah mungkin untuk menambahkan kontrol ke Shell yang tidak dimuat ulang saat bernavigasi di dalam Shell? Misalnya FAB..

@stfnilsson UI tabbar bawah dapat disesuaikan melalui gaya dan kemudian perender khusus. Kami akan memberikan contoh di masa depan.

Menambahkan kontrol yang bersifat global seperti yang Anda gambarkan seperti FAB direncanakan untuk MaterialShell. Bisakah Anda memberikan skenario tambahan yang akan mendapat manfaat dari ini selain FAB?

Pertama: Saya telah menggunakan shell saya sendiri sebelumnya, sekarang saya dapat dengan mudah mengganti shell saya sendiri dengan shell Anda dan itu jauh lebih baik. Aku benar-benar menyukainya.

Mungkin kasus saya cara kustom dan tidak terkait dengan Shell tetapi:

Kasus satu:
Jika saya ingin membuat aplikasi dengan menu yang sangat khusus, satu tombol menu di setiap sudut aplikasi, bagaimana cara menambahkan tombol sehingga menjadi bagian dari shell (seperti overlay atau billboard). Tidak ingin itu dirender setiap kali saya menavigasi.

Kasus dua:
Saya ingin menggunakan Shell tetapi ingin menyesuaikan tabbar bawah sehingga tombol tengah lebih tinggi (disebut tombol tengah terangkat). Haruskah saya menggunakan perender dan menyesuaikan Tampilan Navigasi Bawah?

Apakah menurut Anda saya harus menggunakan shell untuk kasus khusus seperti ini?

Tentu saja saya mempertimbangkan untuk melakukannya di setiap platform tetapi menunya harus terlihat sama di semua platform jadi ingin membagikan kodenya..

Inilah tanggapan saya. Saya melakukan tes ini ( Xamarin.Forms 4.0.0.8055-pre1 ):

   <Shell.FlyoutHeader>
        <local:FlyoutHeader />
    </Shell.FlyoutHeader>

    <ShellItem Title="Home" Icon="home.png">
        <ShellSection>
            <ShellContent>
                <local:MainPage />
            </ShellContent>
        </ShellSection>
    </ShellItem>

    <ShellItem Title="Notifications" Icon="notification.png">
        <ShellSection>
            <ShellContent Title="Recent">
                <local:NotificationPage />
            </ShellContent>
        </ShellSection>
    </ShellItem>

    <ShellItem Title="Test" Icon="icon.png">
        <ShellSection Title="Home" Icon="home.png">
            <ShellContent>
                <local:MainPage />
            </ShellContent>
        </ShellSection>

        <ShellSection Title="Notifications" Icon="notification.png">
            <ShellContent Title="Recent">
                <local:NotificationPage />
            </ShellContent>

            <ShellContent Title="Settings">
                <local:SettingsPage />
            </ShellContent>
        </ShellSection>
    </ShellItem>

Semua berfungsi saat kita mengetuk menu hamburger. Namun, jika kita pergi ke menu Test dan mengetuk Home dan Notifications bolak-balik dan memilih antara Recent atau Settings , halaman akan terbuka masing-masing. Tapi kemudian, ketika kami mengetuk menu hamburger lagi, aplikasi macet.

Bagaimana kita bisa menggunakan GroupHeaderTemplate untuk menampilkan judul untuk grup ShellContent di ShellItem ?

Jelas bagi banyak pengguna bahwa Xamarin Forms tidak dapat dipertahankan pada ukuran dan kompleksitasnya saat ini, jadi apa pun yang baru harus mengurangi kompleksitas daripada meningkatkannya.

@jassmith Tujuannya adalah Anda TIDAK PERNAH lebih baik pergi non-Shell. ... Tujuannya adalah untuk memastikan perender Shell benar-benar mudah dikonfigurasi dan waras.

Jika Shell selesai, apa di masa depan yang dapat disusutkan, dan ketika itu selesai, kompleksitas keseluruhan Formulir Xamarin berkurang? Apakah semua Halaman lain kecuali Halaman Konten akan disusutkan?

Strateginya adalah mengeluarkan sebanyak mungkin dari repo. Stabilitas dan pemeliharaan dari repo inti adalah hal yang paling penting.

Juga jika ada alasan Shell tidak disebut ShellPage? Kelas Halaman lain memiliki nama yang diakhiri dengan "Halaman".

Iklan Shell saat ini (dalam https://blog.xamarin.com/xamarin-forms-4-0-preview/ ) tidak menjanjikan.

1. Cara sederhana untuk mengekspresikan arsitektur aplikasi tingkat tinggi

Ini membawa Xamarin melampaui tujuan sebenarnya. Xamarin tidak diperlukan untuk arsitektur aplikasi. Ini harus tentang tata letak saja.

1. Hirarki pola navigasi UI umum yang sesuai dengan platform seluler target Anda

Saya harap "seluler" salah cetak di sini karena Xamarin.Forms juga mencakup desktop.

1. Layanan navigasi yang tangguh

Xamarin.Forms tidak membutuhkan navigasi. Jika navigasi saat ini tidak berfungsi, itu hanya dapat disusutkan karena ada banyak pendekatan bagus untuk navigasi yang tidak memerlukan apa pun untuk dibangun.

Hai @charlesroddie , terima kasih atas umpan baliknya.

Sepertinya Shell mungkin tidak tepat untuk Anda saat ini, dan tidak apa-apa. Anda tidak perlu menggunakan Shell jika tidak memberikan nilai pada aplikasi Anda. Karena itu, spesifikasi Shell sangat diinformasikan oleh umpan balik pengembang, dan melayani komunitas pengembang kami adalah inti dari tujuan kami.

Di Xamarin.Forms hari ini Anda sudah menjelaskan arsitektur aplikasi Anda, hierarki konten, menggunakan TabbedPage, MasterDetailPage, dengan tab dan item menu, dan kombinasi yang berbeda. Inilah yang saya maksud di sini dengan "arsitektur". Shell menyederhanakan dan mengganti pola tersebut (jika Anda memilih untuk menggunakan Shell).

"Ponsel" bukanlah kesalahan cetak dan digunakan dengan sangat sengaja. Shell ditargetkan untuk iOS dan Android. Jika Anda menargetkan desktop, Anda tidak akan menggunakan Shell. Saya telah mendengar minat dari kontributor tentang menambahkan dukungan Shell ke backend desktop, dan PR tersebut akan diterima dengan baik. Saya percaya Shell berada di posisi yang sangat baik untuk membawa aplikasi ke platform apa pun, dan fleksibel (tangguh) untuk beradaptasi bahkan dengan perubahan pola UI yang radikal (siapa yang tahu apa yang akan diadopsi oleh antarmuka masa depan). Untuk hari ini tempat pembuktiannya adalah iOS dan Android.

Seperti yang telah kami bicarakan dengan pengembang tentang Shell, saya terkejut mengetahui bahwa navigasi Shell berada di urutan teratas daftar fitur yang mereka hargai. Perutean, penautan dalam, kemampuan untuk mengganggu navigasi, mendeskripsikan back-stack secara instan, meneruskan data, dan pemuatan halaman yang lambat adalah atribut yang sangat menarik bagi pengembang yang memecahkan masalah yang mereka alami saat ini.

Jika Anda menargetkan desktop, Anda tidak akan menggunakan Shell... Saya yakin Shell berada di posisi yang sangat baik untuk membawa aplikasi ke platform apa pun

Saya hanya tidak ingin Xamarin runtuh karena beratnya sendiri. Sampai Shell mencapai semua platform, Anda memiliki masalah pemeliharaan, karena ini merupakan tambahan, bukan pengganti Halaman lain. Anda juga memiliki masalah perpesanan untuk pengembang desktop, pada saat banyak yang jelas ingin mengadopsi kerangka kerja lintas platform.

Xamarin menampilkan banyak fitur creep, misalnya css. Ini dapat mengancam keseluruhan proyek dan saya berharap beberapa pengambil keputusan di organisasi memahami hal ini.

Saya hanya tidak ingin Xamarin runtuh karena beratnya sendiri. Sampai Shell mencapai semua platform, Anda memiliki masalah pemeliharaan, karena ini merupakan tambahan, bukan pengganti Halaman lain. Anda juga memiliki masalah perpesanan untuk pengembang desktop, pada saat banyak yang jelas ingin mengadopsi kerangka kerja lintas platform.

Xamarin menampilkan banyak fitur creep, misalnya css. Ini dapat mengancam keseluruhan proyek dan saya berharap beberapa pengambil keputusan di organisasi memahami hal ini.

Saya setuju. Jika suatu fitur tidak didukung di desktop (UWP), maka tidak ada gunanya bagi kami. Saya juga setuju tentang CSS - sepertinya banyak kerumitan tambahan, dan biaya pemeliharaan untuk fitur yang tidak memungkinkan saya melakukan apa pun yang belum bisa saya lakukan sebelumnya. Yang kami butuhkan jauh lebih dari apa pun hanyalah lebih banyak kontrol - untuk semua platform, dan lebih banyak kemampuan untuk kontrol yang ada. Shell masih memiliki keterbatasan yang sama dengan infrastruktur Halaman yang harus Anda adopsi sepenuhnya atau Anda tidak dapat menggunakannya sama sekali, dan Shell hanya dapat hidup di tingkat akar aplikasi Anda. Tidak hanya itu, tetapi sekarang Anda memiliki dua cara untuk melakukan hal yang sama, dan itu rumit dan membingungkan. Jadi jika saya hanya ingin memiliki menu flyout tanpa menggunakan shell, saya tidak bisa melakukannya. Dan itu sangat terbatas dalam jumlah kontrol yang dipetakan oleh item shell - tab, halaman navigasi, dan flyout tidak cukup bagi kami. Jika Xamarin Forms dapat menawarkan luasnya kontrol yang dimiliki kerangka kerja seperti UWP, diekspos sebagai satu set kontrol, seperti di UWP, dan tanpa pengasapan yang tidak berguna (mis. css), maka saya akan senang.

Saya pikir kalian mengangkat beberapa poin yang valid, tetapi sebagai seseorang yang memelihara aplikasi UWP/iOS/Android dan sedikit kecewa ketika saya mengetahui Shell tidak mendukung UWP, dengan hanya "mungkin" di masa depan. Kemudian saya menyadari bahwa saya kehilangan inti dari Shell. Ini adalah cara mudah yang bagus bagi seseorang untuk membuat aplikasi untuk dua platform seluler utama. Sebagai pengembang perusahaan ... saya butuh UWP, saya menunggu sampai ada dukungan UWP bahkan untuk mempertimbangkan XF ... tapi saya curiga banyak pengembang tidak membutuhkannya ... Saya juga butuh navigasi yang jauh lebih kompleks, dll. Shell menyediakan.

Tapi saya juga ingat menghabiskan banyak waktu mencoba untuk memulai dengan navigasi dan halaman ... yang dapat memakan waktu untuk mencari tahu. Tapi saya juga membuat aplikasi bisnis yang sangat kompleks, ada banyak sekali aplikasi sederhana yang tidak membutuhkan tingkat kerumitan itu. XF perlu berevolusi untuk menyelesaikan hal-hal seperti Flutter, dll. XF juga perlu terus mendapatkan pengembang baru untuk mengadopsinya. Dan menurut saya penggunaan platform akan membantu mengamankan sumber daya yang dibutuhkan untuk memelihara platform.

Saya juga memiliki beberapa proyek masa depan di mana saya tidak memerlukan UWP dan saya berharap dapat menggunakan Shell pada mereka karena saya pikir itu akan membuat saya lebih cepat untuk memproduksinya.

Saya hanya menggunakan XF sejak sekitar rilis 2.3 dan sementara pasti ada lebih banyak pekerjaan yang harus dilakukan...platform seperti yang ada sekarang telah sangat stabil...setidaknya untuk saya...jadi saya tidak peduli dengan pemeliharaan tambahan dan menurut saya tim XF sangat sadar akan beban pemeliharaan...jadi saya percaya mereka mengendalikannya.

Terima kasih atas tambahan yang bagus untuk platform ini!

Menambahkan cara baru untuk melakukan sesuatu akan membingungkan pengembang baru hingga cara lama disusutkan dan dokumen lama dihapus.

Flutter jauh lebih sederhana. Tidak ada bahasa markup, semuanya dalam kode. Xamarin tidak akan bersaing dengan menjadi lebih kompleks dan buggy. Ini akan bersaing dengan melakukan lebih dari Flutter (lebih banyak platform), dengan fokus yang sama.

Sampai pada titik kita membutuhkan Xamarin.Core, tidak termasuk XAML atau CSS atau pengikatan properti, tidak termasuk Halaman atau Shell di luar kelas dasar, dengan fokus pada kinerja dan stabilitas untuk Core ini. Jika beberapa pengembang menginginkan fitur ini dengan biaya menerima tingkat bug saat ini, mereka dapat menggunakan Xamarin.Extensions di mana semua hal itu akan hidup.

Menambahkan cara baru untuk melakukan sesuatu akan membingungkan pengembang baru hingga cara lama disusutkan dan dokumen lama dihapus.

Flutter jauh lebih sederhana. Tidak ada bahasa markup, semuanya dalam kode. Xamarin tidak akan bersaing dengan menjadi lebih kompleks dan buggy. Ini akan bersaing dengan melakukan lebih dari Flutter (lebih banyak platform), dengan fokus yang sama.

Sampai pada titik kita membutuhkan Xamarin.Core, tidak termasuk XAML atau CSS atau pengikatan properti, tidak termasuk Halaman atau Shell di luar kelas dasar, dengan fokus pada kinerja dan stabilitas untuk Core ini. Jika beberapa pengembang menginginkan fitur ini dengan biaya menerima tingkat bug saat ini, mereka dapat menggunakan Xamarin.Extensions di mana semua hal itu akan hidup.

@charlesroddie Tidak ada yang mereka lakukan di atas, Anda terpaksa menggunakan XAML. XAML di Xamarin.Forms adalah opsional - selalu begitu. Saya selalu melakukan UI aplikasi Xamarin.Forms saya hanya menggunakan kode - setiap "tag" yang Anda lihat di atas adalah kelas yang dapat dipasang dan ditambahkan ke induk yang relevan.
Jika UI yang dikodekan tidak dimungkinkan dengan Xamarin.Forms, saya tidak akan menggunakannya - titik!

Re Flutter secara umum - sangat bagus, tetapi masalahnya adalah hanya iOS dan Android - yang juga tidak berfungsi untuk saya karena saya perlu menargetkan macOS, Windows 7/8.1, dan Linux. Tidak ada yang mengalahkan Xamarin.Forms dalam hal ini!

dapatkah saya mengatur tampilan khusus sebagai halaman master, ini sangat penting untuk disertakan, kami tidak akan memilih hanya MenuItem atau halaman

Dukungan Xamarin Mac dan uwp?

Bagaimana Anda akan terhubung ke proses navigasi? Saya kira Anda menyadarinya tetapi jika Anda mengambil Prism misalnya, model tampilan dibuat oleh wadah DI dan secara otomatis ditetapkan sebagai BindingContext untuk halaman yang diminta.

Anda juga dapat mengimplementasikan INavigatedAware untuk model tampilan dan menangani kasus penggunaan tertentu seperti memuat data, mengaktifkan/menonaktifkan layanan, dll.

Saya ingin menambahkan sesuatu yang serupa jadi tebakan pertama saya adalah acara Shell OnNavigating dan OnNavigated tetapi Current dan Target tidak mengekspos ShellItem sehingga tidak mungkin untuk mengatur BindingContext dengan konvensi atau memicu peristiwa model tampilan?

Ada saran untuk ini?

EDIT: Dilacak oleh #5166.

Untuk ikon di shell ini, apakah mungkin menggunakan "Font Ikon" alih-alih gambar? Sulit untuk mengubah warna selama runtime untuk gambar dan juga sulit untuk mengaturnya untuk resolusi yang berbeda pada platform yang berbeda. Bisakah saya menyarankan untuk membuat kelas ikon menggunakan font Desain Material yang dirender dengan pustaka SkiaSharp? Kelasnya relatif mudah dan akan membuat banyak ikon siap digunakan di shell.

@vincentwx saya setuju. Font ikon jauh lebih mudah digunakan dan juga familiar.

@vincentwx @stevehurcombe benar-benar. Saya melakukan ini di aplikasi sekarang:

<ShellItem>
    <ShellContent Title="Upcoming" 
                      ContentTemplate="{DataTemplate pages:UpcomingPage}">
            <ShellContent.Icon>
                <FontImageSource Glyph="{x:Static local:IconFont.Rocket}" 
                                 FontFamily='{OnPlatform iOS="Font Awesome 5 Free", Android="fa-solid-900.ttf#Font Awesome 5 Free"}'
                                 Size="18"/>
            </ShellContent.Icon>
        </ShellContent>

        <ShellContent Title="Latest" 
                      ContentTemplate="{DataTemplate pages:LatestPage}">
            <ShellContent.Icon>
                <FontImageSource Glyph="{x:Static local:IconFont.Book}" 
                                 FontFamily='{OnPlatform iOS="Font Awesome 5 Free", Android="fa-solid-900.ttf#Font Awesome 5 Free"}'
                                 Size="18"/>
            </ShellContent.Icon>
        </ShellContent>

        <ShellContent Title="Company" 
                      ContentTemplate="{DataTemplate pages:CompanyPage}">
            <ShellContent.Icon>
                <FontImageSource Glyph="{x:Static local:IconFont.Building}" 
                                 FontFamily='{OnPlatform iOS="Font Awesome 5 Free", Android="fa-solid-900.ttf#Font Awesome 5 Free"}'
                                 Size="18"/>
            </ShellContent.Icon>
        </ShellContent>
    </ShellItem>

Saya menggunakan ini untuk membuat kelas statis dari semua mesin terbang: https://andreinitescu.github.io/IconFont2Code/

Ada bug dengan warna iOS yang perlu diperbaiki. #5071

Dukungan Xamarin Mac dan uwp?

Tidak saat ini @mdonogma. Kami mengumpulkan minat/permintaan untuk mendukung platform tambahan, tetapi saat ini hal itu tidak ada dalam peta jalan kami.

@davidortinau Terima kasih atas kode dan tautannya.

Di Android 8.0, saya tidak dapat menggulir halaman web di elemen WebView yang di-host di Konten Shell. Tapi itu berfungsi dengan baik tanpa Xamarin Shell.

Formulir Xamarin 4.0.0.135214-pre4

Apakah ada cara mudah untuk mengubah FontFamily dari tab bawah dan tampilan judul?

@varyamereon saya melakukan itu kemarin. Perpanjang Shell untuk dapat mengatur FontFamily.
Saya akan segera menerbitkan Shell saya yang diperluas di GitHub tetapi:

Buat Shell khusus:

<Shell
    x:Class="X.Mobile.App.Features.AppShell.AppShell"

Kemudian buat perender khusus Shell:

[assembly: ExportRenderer(typeof(AppShell), typeof(AppShellRenderer))]

namespace X.Mobile.App.iOS.Renderers
{
    [Preserve(AllMembers = true)]
    public class AppShellRenderer : ShellRenderer
    {
        protected override IShellItemRenderer CreateShellItemRenderer(ShellItem item)
        {
            return new CustomMenuRenderer(this)
            {
                ShellItem = item
            };
        }

Kemudian:

 namespace X.Mobile.App.iOS.Renderers
 {
     [Preserve(AllMembers = true)]
     public class CustomMenuRenderer : ShellItemRenderer
     {
         private SKCanvasView _skiaSharpPaintView;
         public CustomMenuRenderer(IShellContext context) : base(context)
         {
         }

public override void ViewDidLoad()
{
}           
public override void ViewWillLayoutSubviews()
{
{

Kemudian untuk mengatur keluarga font: _(jangan terlalu sering)_

var txtAttributes = new UITextAttributes
            {
                Font = UIFont.FromName("MyriadPro-Semibold", 12.0F)
            };
            foreach (var uiTabBarItem in TabBar.Items)
            {
                uiTabBarItem.SetTitleTextAttributes(txtAttributes, UIControlState.Normal);
            }

Siapa saja yang telah memperluas Shell dengan dukungan untuk popup dari bawah (bottomsheet)?

Saya telah memindahkan banyak kode dari Shell lama saya ke yang baru (tentu saja komposisi), saya sangat menyukainya. Saya bahkan menggunakannya untuk aplikasi yang akan dirilis pada bulan Mei :-) (Saya bahkan men-debug kode Xamarin)

Apakah ada dukungan untuk mengikat daftar ke Shell.MenuItems? Atau haruskah saya menggunakan BindableLayout? Terkadang saya perlu memuat daftar dari database dan menggunakannya sebagai menu. Mereka memiliki tampilan yang sama, tetapi memuat data yang berbeda tergantung pada menu yang dipilih.

Apakah ada cara untuk mengubah OffscreenPageLimit di Android saat menggunakan shell? Sayangnya ini sangat penting untuk aplikasi saya dan mencegah saya untuk maju dengan Shell.

Terima kasih!

Beberapa permintaan fitur:

1. Di tingkat shell, atur FontFamily untuk semua judul halaman.
   misalnya

2. Pada tingkat shell, atur gambar latar belakang Judul/Nav untuk semua judul halaman/bilah navigasi, dll.
   misalnya

GroupBehavior tidak berfungsi untuk saya di pre4:

<ShellItem GroupBehavior="ShowTabs" FlyoutIcon="stuff.png" Title="Discussion">...
menghasilkan:

xxx/Shell/Shell.xaml(14,14): Kesalahan: Posisi 108:14. Tidak ada properti, properti yang dapat diikat, atau peristiwa yang ditemukan untuk 'GroupBehavior', atau jenis ketidakcocokan antara nilai dan properti.

dan GroupHeaderTemplate tampaknya tidak melakukan apa-apa, tetapi, tidak yakin bagaimana itu digunakan, atau diaktifkan.

Saya mencoba menambahkan/menghapus MenuItems, yang berhasil menambahkan item melalui MenuItems.Add(item), tetapi, tidak ada hasil yang ditampilkan saat flyout ditampilkan lagi. Apakah ini pendekatan yang benar untuk melakukan ini?

Saya tidak melihat ada penyebutan tentang memanipulasi MenuItems, tetapi, Shell hampir tidak berguna bagi saya (dan saya memikirkan banyak hal lainnya, termasuk @puppetSpace di atas) kecuali item ini dapat dipertahankan secara dinamis berdasarkan logika bisnis Anda.

Saya setuju dengan dbwelch bahwa kemampuan untuk mengubah shell secara terprogram dalam file cs sangat penting. Tidak hanya untuk item menu, tetapi juga ShellItems & ShellSections.

Ketika saya menyalakan Flyout, dan menambahkan item menu, saya mendapatkan menu hamburger di Android, dan di iOS jika saya mengklik di tempat itu berfungsi, namun tidak ada ikon. Ada ide?

@KyleTraynor ada masalah terbuka di suatu tempat untuk itu. Anda harus menyalin gambar 3bar.png dan [email protected] secara manual ke folder Sumber Daya iOS Anda dan memastikan mereka disertakan dalam proyek sebagai item bundel.

Gambar yang saya temukan di sumber terlampir:

@melucas Terima kasih atas bantuannya! Aku akan gila mencoba untuk memperbaikinya. Bekerja dengan baik.

Apakah Anda tahu bagaimana saya bisa mengatur OffscreenPageLimit untuk Android saat menggunakan Shell?

Saya memiliki halaman tab teratas yang dibuat dengan memiliki 4 ShellContents di dalam 1 ShellSection, dan itu berfungsi dengan baik di iOS, tetapi di Android halaman dimuat ulang ketika bertukar di antara mereka yang tidak saya inginkan. Biasanya dengan halaman tab saya sendiri, saya dapat mengatur OffscreenPageLimit untuk memperbaiki masalah ini, tetapi saya tidak dapat menemukan cara untuk melakukannya dengan Shell.

@davidortinau bisakah kita memiliki opsi untuk mengatur keluarga font pada judul halaman, tab bawah dan atas? Di setiap proyek saya harus membuat penyaji khusus untuk ios dan Android untuk mengubah font.

Jadi, mengingat bahwa karena tidak ada tanggapan terhadap posting saya tentang kemampuan untuk benar-benar mengubah item di flyout Shell, mungkin fungsi ini tidak dalam cakupan, atau mungkin, semoga dianggap sebagai bug ?

Tidak yakin bagaimana aplikasi yang serius dapat menggunakan Shell ini tanpa fungsi ini. Hanya aplikasi yang sangat sederhana yang tidak memerlukan kemampuan untuk menambah/mengubah/menghapus/menonaktifkan item pada menunya berdasarkan a) konteks pengguna (yaitu diautentikasi/tidak diautentikasi), atau b) berbagai status aplikasi yang akan membutuhkannya.

Hanya ingin tahu @jassmith , apakah orang-orang yang membuat spesifikasi dimasukkan ke forum ini atau ini hanya untuk umpan balik pengembang?

Btw, selain satu item utama ini, saya telah menerapkan Shell ke dalam kode saya untuk satu aplikasi dan itu bekerja dengan sangat baik, terima kasih! Tetapi, sayangnya, harus menariknya keluar dan mengimplementasikan flyout saya sendiri jika Shell tidak memiliki fungsi ini yang berfungsi/diimplementasikan.

@dbwelch , beberapa hal.
Anda memposting spesifikasi, jadi Anda mungkin tidak akan mendapatkan respons seperti yang Anda tulis saat membuka edisi baru. Juga, Jason tidak lagi mengerjakan Formulir, jadi memanggilnya agak tidak ada gunanya.

Intinya, ajukan masalah

@dbwelch @ChaseFlorell Saya membuka masalah di sini: https://github.com/xamarin/Xamarin.Forms/issues/5428

@davidortinau bisakah kita memiliki opsi untuk mengatur keluarga font pada judul halaman, tab bawah dan atas? Di setiap proyek saya harus membuat penyaji khusus untuk ios dan Android untuk mengubah font.

@jamiewest Kirim permintaan fitur! Terima kasih! https://github.com/xamarin/Xamarin.Forms/issues/new?assignees=&labels=t%2Fenhancement+%E2%9E%95&template=feature_request.md&title=%5BEnhancement%5D+YOUR+IDEA%21

Bisakah fitur UseSwipeGesture diterapkan?
Sepertinya sekarang kelas ShellItem tidak memiliki properti ShellAppearance ke opera.
Tapi sekarang Di Android, Tab Shell tidak seperti TabPage (TabPage dapat menggesek sebagai default.)

    <ShellItem.ShellAppearance>
      <MaterialShellAppearance NavBarCollapseStyle="Full" TabBarCollapseStyle="Full" UseSwipeGesture="false">
    </ShellItem.ShellAppearance>

@jingliancui , Saudara Cui, apakah ada qq atau WeChat?

@juepiezhongren Hai, Anda dapat bergabung ke grup qq ini untuk mengobrol dengan saya 313308215

Akankah kita melihat Shell dan dukungan visual datang untuk UWP pada RTM?

Saya menyambut ide ini - terlepas dari apa pun yang membuatnya lebih sulit karena bekerja dengan halaman navigasi, halaman master-detail, dll. terasa berbelit-belit. Mungkin ini karena saya berasal dari latar belakang web (belum banyak bekerja dengan API asli). Menyesuaikan bilah navigasi, judul halaman, tombol kembali, item bilah alat, header dan footer (ListView), dll. muncul di sini.

Saya kira yang saya minta adalah fitur baru, seperti *Shell, dikirimkan dengan mempertimbangkan penyesuaian dan perluasan. Ada sangat sedikit situasi yang pernah kita alami di mana kita tidak perlu membuat serangkaian penyaji, perilaku, pemicu, dll. untuk melakukan hal-hal yang tampaknya sederhana.

Apa pun yang kalian buat, tolong lakukan apa pun yang Anda bisa untuk mempermudah kami membuat aplikasi Xamarin.Forms kami terlihat sebagus aplikasi asli lainnya! Sepertinya fitur ini akan memberi kita landasan peluncuran yang lebih baik untuk aplikasi XForms yang tampak modern!

Apakah ada kode sumber yang tersedia untuk melihat cara kerja Shell ini, daripada harus menebak-nebak spesifikasinya? Misalnya, gaya apa yang digunakan untuk mewarnai ikon hamburger, jika tersedia. Maaf, baru di C#/Xamarin, tetapi, jika kode dapat dilihat di suatu tempat, akan sangat membantu.

@dbwelch Anda dapat menelusuri kode sumber di sini di GitHub. Tekan "T" dan ketik Shell untuk melihat kelas terkait. Itu mungkin bukan titik awal terbaik jika Anda baru mengenal C#/Xamarin. Saya sarankan untuk memeriksa beberapa sampel saya sampai kami mendapatkan lebih banyak dokumentasi:

https://github.com/davidortinau/Gastropods
https://github.com/davidortinau/ShellGallery
https://github.com/davidortinau/TheLittleThingsPlayground

Dokumen: https://docs.microsoft.com/en-us/xamarin/xamarin-forms/app-fundamentals/shell?tabs=android
Artikel MSDN: https://msdn.microsoft.com/en-us/magazine/mt848639
Blog: https://blog.xamarin.com/xamarin-forms-4-0-preview/

@davidortinau terima kasih, tapi, saya pikir itu baru saja merilis kode yang tersedia, di mana kode Shell? Saya telah mencari di bawah cabang untuk 4.0, Shell, yang lain, tetapi, itu bersembunyi dari saya! Terima kasih!

@dbwelch https://github.com/xamarin/Xamarin.Forms/search?q=shell&unscoped_q=shell

Shell.cs misalnya ada di sini

@pauldipietro Terima kasih, lihat sekarang. @davidortinau Saya sebenarnya telah menghabiskan banyak waktu untuk semua tautan (kecuali LittleThings, yang baru saja saya unduh), tetapi, tidak melihat cara mengubah hal sederhana seperti warna ikon hamburger. Itu muncul sebagai ungu di aplikasi saya, tetapi, saya tidak memiliki warna ungu yang ditentukan di mana pun (yang bisa saya lihat). Sedikit frustasi ;-).

UPDATE: Saya baru saja menemukan masalahnya, dan, tentu saja, ini adalah beberapa kode yucky yang ada di FinishedLaunching untuk menambahkan TintColor. DOH!

Terima kasih tuan-tuan, hargai bantuannya!

Saya memiliki beberapa item yang ditampilkan di panel flyout yang baik-baik saja. Namun, saat ini sudah ada cara untuk menyembunyikan/tidak menampilkan item Shell (bukan konten item). Contoh, saya memiliki ContentPage dan saya hanya ingin memiliki navigasi di dalam Shell.

<local:DetailPage />

Tampaknya selalu menambahkan item di panel/daftar Flyout. Dan jika tidak ada Judul, maka akan ada tumpukan/penampung item yang kosong. Saya telah mencoba banyak cara untuk menyembunyikan barang itu tetap tidak berhasil. Mungkin ada yang bisa membantu atau fiturnya masih belum tersedia.

Kata Pengantar: Saya seorang atm pemula. Mencoba untuk tidak menjadi.

@davidortinau Jadi, saya sudah mencoba mempelajari fitur Shell ini untuk menambahkan navigasi, dll. ke dalam proyek Xamarin.Forms pertama kami untuk perusahaan kami (woot!) atau lebih params dari ShellItem ke bagian lain dari aplikasi melalui fungsi perutean baru. Apakah ini sama sekali? Atau haruskah kita tetap menggunakan perintah menggunakan MenuItems dalam koleksi MenuItem? Jika kita harus menggunakan MenuItem untuk meneruskan 1 atau lebih nilai dari tingkat Flyout, tampaknya kita tidak dapat lagi menyusun aplikasi kita dengan hierarki Shell karena kita menggunakan MenuItems sebagai gantinya? Bukankah kita kehilangan itu dalam menggunakan MenuItems dengan params perintah?

Apakah ada orang yang bisa berpadu dengan ini? Jika demikian, saya akan sangat menghargainya. Pada dasarnya ingin menggunakan Shell, tetapi masih dapat menandai ShellItem apa yang dipilih pengguna saat mengklik salah satu untuk meneruskannya ke halaman ContentTemplate atau apa pun yang sesuai karena banyak ShellItems akan menavigasi ke halaman perantara serupa untuk membuat OrderType dan pilihan dropdown OrderDepartment terlebih dahulu sebelum masuk ke layar utama Order dengan data yang sesuai untuk jenis dan dept yang tepat.

Juga, saya minta maaf jika ini adalah tempat yang salah untuk ini. Jika demikian, tolong arahkan saya ke tempat yang tepat. Terima kasih!

Memperbarui:
Mungkin saya hanya akan menggunakan MenuItems untuk saat ini dan meneruskan param perintah ke ShellViewModel untuk menavigasi dengan nilai yang tepat untuk halaman target. Sekarang saya memikirkannya, saya benar-benar tidak perlu menavigasi ke struktur tab dari MenuItems yang mendorong ke halaman ContentTemplate.

Saya juga bertanya-tanya apakah kita dapat menentukan di mana MenuItems berada di dalam Flyout sehingga ShellItems tidak semuanya muncul ke atas; dan jika suatu hari kita tidak harus mendefinisikan MenuItems kita sebagai bagian dari koleksi sehingga mereka dapat berbaur dengan ShellItems seperti:
MenuItem
ShellItem
ShellItem
MenuItem
ShellItem
MenuItem
...
Itu, atau buat saja ShellItems dapat melewati params di beberapa titik jika mereka belum bisa.

Saya bersama @anthcool dan menganggap ini fitur yang sangat penting. Saya tidak dapat menemukan cara untuk melakukan ini dan harus berhenti menggunakan Shell. Hanya perlu dapat meneruskan sesuatu ke halaman konten untuk mengetahui mana yang diklik.

@anthcool hanya mencoba membantu dan memberikan beberapa saran di sini seperti yang saya lakukan saat ini. Buat kelas parameter navigasi yang memiliki readonly Stack<NavigationParameter> sebagai daftar tumpukan, mis

public class Navigation
{
    readonly Stack<NavigationParameter> _stack = new Stack<NavigationParameter>();
...
    public Stack<NavigationParameter> Parameters => _stack;
}

Parameter Navigasi adalah:

public class NavigationParameter : NameValueCollection { }

Anda dapat menambahkan parameter sebelum push saat menavigasi, mis:

    var p = new NavigationParameter { { nameof(SomePage), SomeObject } };
    Navigation.Parameters.Push(p);

Setelah Anda berada di halaman lain, cukup Intip atau Pop nilainya dan periksa kuncinya.
Sesuatu seperti di atas. Semoga membantu.

@anthcool hanya mencoba membantu dan memberikan beberapa saran di sini seperti yang saya lakukan saat ini. Buat kelas parameter navigasi yang memiliki readonly Stack<NavigationParameter> sebagai daftar tumpukan, mis

public class Navigation
{
    readonly Stack<NavigationParameter> _stack = new Stack<NavigationParameter>();
...
    public Stack<NavigationParameter> Parameters => _stack;
}

Parameter Navigasi adalah:

public class NavigationParameter : NameValueCollection { }

Anda dapat menambahkan parameter sebelum push saat menavigasi, mis:

    var p = new NavigationParameter { { nameof(SomePage), SomeObject } };
    Navigation.Parameters.Push(p);

Setelah Anda berada di halaman lain, cukup Intip atau Pop nilainya dan periksa kuncinya.
Sesuatu seperti di atas. Semoga membantu.

Terima kasih atas idenya @rizamarhaban! Sangat menghargai Anda ikut campur dalam hal ini. Terima kasih! Saya akan memeriksa ini di sini segera. Sekali lagi, hargai!

Sangat kecewa mengetahui Shell dan Visual tidak mendukung UWP.

Apakah spesifikasi ini benar-benar selesai?
Mengapa menutup ini hanya karena sekarang ada implementasi Tizen?
Saya mendapat kesan bahwa fungsi navigasi masih dalam peninjauan.

Masih belum ada dukungan UWP. Kekecewaan terbesar yang pernah saya alami dari Xamarin.

@weitzhandler Silakan email saya di paul. [email protected] jika Anda ingin mendiskusikan hal ini dan UWP secara umum. Kami tidak secara aktif mengabaikan platform, tetapi Android dan iOS menerima implementasi awal dan investigasi terhadap dukungan Shell untuk UWP secara aktif sedang berlangsung.

@mrlacey Nah, itu belum selesai! Itu hanya terus ditutup oleh masalah terkait. 😄

Untuk semua yang meminta dukungan UWP, saya mencoba: https://github.com/xamarin/Xamarin.Forms/pull/6015

Apakah ada cara untuk menerapkan templat bilah navigasi di halaman konten?
Menentukan NavigationPage.TitleView tidak berlaku seperti sebelumnya.
Repo untuk referensi:
https://github.com/InquisitorJax/Xamarin-Forms-Shell

EDIT:
Murphy menyerang lagi - cukup gunakan Shell.TitleView alih-alih NavigationPage.TitleView :)

Halo,
Dalam proyek baru saya, saya menggunakan Shell dan CollectionView, dan saya harus mengatakan itu hebat!
Satu pertanyaan tentang Shell

• ada cara untuk menambahkan item bawah diperbaiki (contoh rubah tombol untuk logout pengguna)

Saya melihat itu mungkin untuk menambahkan tajuk tetap (FlyoutHeader dan FlyoutHeaderBehavior) tetapi saya tidak dapat menemukan info tentang footer bawah
Terima kasih!

Halo,
Saya punya pertanyaan lain tentang RegisterRoute.
Aplikasi saya agak besar, dengan jumlah halaman yang cukup banyak, sekitar 30...
Apakah benar-benar cara yang tepat untuk menambahkan RegisterRoute untuk masing-masing?
Routing.RegisterRoute("blabla", typeof(BlaBlaPage)); ... ...
Atau lebih baik menggunakan cara lama?
var blaPage = new BlaBlaPage (); await Navigation.PushAsync (blaPage);

@matteopiccioni Saya akan merekomendasikan melakukannya seperti ini

Routing.RegisterRoute("blabla", typeof(BlaBlaPage));

dan menggunakan
gotoasync("blabla")

Saya menyadari saat ini rasanya sama, tetapi seiring berkembangnya fitur, akan lebih relevan jika semua hal itu beroperasi melalui sistem Shell

Apakah benar-benar cara yang tepat untuk menambahkan RegisterRoute untuk masing-masing?

jika ini menjadi masalah, kami sedang mencari untuk menambahkan beberapa fitur yang hanya akan melakukan pemindaian perakitan untuk halaman atau bahkan mungkin beberapa fitur waktu kompilasi yang akan menghasilkan rute tersebut.

Masalah utama di sini adalah bahwa semua jenis refleksi akan memperlambat aplikasi Anda sehingga melakukan itu saat startup akan dikenakan biaya

@PureWeen terima kasih atas jawabannya
Waktu startup yang lambat adalah salah satu masalah yang paling mengganggu di xf (untuk Android)
Saat startup, bisakah saya menambahkan ke perutean hanya halaman tingkat pertama (halaman shellitems) dan menambahkan yang lain hanya setelah aplikasi dimulai (semacam pemuatan Lazy dari RegisterRoute)?

@matteopiccioni

Jadi jika Anda melakukannya seperti ini sekaligus

Routing.RegisterRoute("blabla", typeof(BlaBlaPage));

tidak apa-apa. Yang saya bicarakan adalah jika kita akhirnya membangun sesuatu yang membuatnya sehingga pengguna tidak perlu melakukan itu, kita perlu mempertimbangkannya dengan kinerja. Saat ini Routing.RegisterRoute("blabla", typeof(BlaBlaPage)); tidak melakukan refleksi apa pun sehingga melakukan semuanya sekaligus tidak masalah.

yang dilakukannya hanyalah menambahkan string dan mengetik ke kamus

@jassmith @jamesmontemagno @pierceboggan Wow tampak hebat. Pernahkah Anda melihat aplikasi Google Contacts menggunakan Pie SDK di Google Pixel? Saya suka UI/UX, tanpa bilah judul dan hamburger terintegrasi dengan bagian atas aplikasi.

Bisakah saran ini dipertimbangkan untuk Shell Anda karena ini adalah pola yang digunakan Google, dengan Kontak dan Peta, dan mungkin yang lain?

Terima kasih atas waktu dan pertimbanganmu,

Karl

Perhatikan bahwa semua sampel yang mengikuti tidak menggunakan templated ShellContent, yang dibahas di bagian lain dalam spesifikasi. Kegagalan untuk menggunakan ShellContents dengan ContentTemplate dengan benar akan mengakibatkan semua halaman dimuat saat startup, yang akan berdampak negatif pada kinerja startup. Sampel ini hanya untuk tujuan pembelajaran.
Untungnya menggunakan ShellContents dengan ContentTemplates biasanya lebih ringkas daripada tidak menggunakannya.
[...]
Masalah utama dengan menggunakan Shell adalah kemudahan dimana pengguna akhirnya dapat memuat semua halaman pada awal menjalankan aplikasi mereka. Alokasi frontload yang besar ini dapat menghasilkan kinerja startup yang sangat buruk jika diperlukan sejumlah besar halaman konten. Untuk memperbaiki template ini harus digunakan bila memungkinkan.

Bagi saya ini terdengar seperti Anda tidak boleh menggunakan konten secara langsung tetapi menggunakan template. Ini masuk akal bagi saya, jadi mengapa mendukung pendekatan konten langsung? (terlepas dari kesederhanaan, tetapi membiarkan orang menembak dirinya sendiri di kaki). Rasanya seperti dapat menggunakan konten langsung lebih merupakan fitur "hebat saat melakukan demo - jika tidak, mengerikan".

Hai,
Saya baru disini. Saya tidak yakin apakah ini tempat yang tepat untuk mengajukan pertanyaan, jika tidak, tolong arahkan saya ke mana harus bertanya:
Saya mencoba melakukan sesuatu yang mirip dengan contoh yang ditentukan di atas:

  <ShellItem Title="My music" ItemsSource="{x:Bind MyMusicModels}" TabLocation="Bottom">
    <ShellItem.ItemTemplate>
      <local:MyMusicItemTemplateSelection />
    </ShellItem.ItemTemplate>
  </ShellItem>

Tapi saya mendapatkan kesalahan berikut:

Kesalahan XLS0413 Properti 'ItemsSource' tidak ditemukan dalam tipe 'ShellItem'.
Kesalahan XLS0415 Properti yang dapat dilampirkan 'ItemTemplate' tidak ditemukan dalam tipe 'ShellItem'.

@Elashi jadi apakah Anda berharap untuk melakukan ide ini di sini
https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/layouts/bindable-layouts

Dengan ShellItem?

@PureWeen saya berharap untuk menggunakan ide ini :) .
Apakah Anda menyarankan agar ide ini belum diterapkan?
Jika belum diimplementasikan, saya mungkin tertarik untuk mengerjakannya.

Itu tidak diterapkan, semoga saja!

dikirim dari iPhone saya

Pada 5 Mei 2019, pukul 11:59 pagi, Elashi < [email protected] [email protected] > menulis:

@PureWeen https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FPureWeen&data=02%7C01%7C%7C5a4c31a04c6541d6080608d6d172b36a%7C84df9e687xfe9f6aaYs&nbsp; %2BGt13FFjR5BCwdMg0UouarnTxI0%2FawrXtVEURM%3D&reserved=0 Saya berharap untuk menggunakan ide ini :) .
Apakah Anda menyarankan agar ide ini belum diterapkan?
Jika belum diimplementasikan, saya mungkin tertarik untuk mengerjakannya.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fxamarin%2FXamarin.Forms%2Fissues%2F2415%23issuecomment-489439176&data = 02% 7C01% 7C% 7C5a4c31a04c6541d6080608d6d172b36a% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% 7C636926687892536099 & SDATA = RdPBMt9fPqsPC1x0FlJ1MQzn8BK6m9lfg7nsT09YIN8% 3D & dicadangkan = 0 , atau mematikan benang https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F% 2Fgithub.com% 2Fnotifications% 2Funsubscribe-auth% 2FAABUHE2I4F33TX2SZJE2RVDPT377JANCNFSM4EZ4GB5Q & data = 02% 7C01% 7C% 7C5a4c31a04c6541d6080608d6d172b36a% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% 7C636926687892546103 & SDATA = UXiXgRiTo4pAjJVraUqmJmYZibiWMdh9htX2SeFG4JM% 3D & dilindungi = 0 .

@Elashi tidak, tetapi saya dapat melihat bahwa menjadi fitur yang sangat kuat untuk Skenario MVVM

Jika Anda ingin mengerjakannya, dapatkah Anda membuat masalah dengan dasar-dasar apa yang Anda pikirkan?

Jadi dari trial and error ... Meskipun memiliki komentar tentang gerakan di shell 3.2 dan di TheLittlePlayground saya tidak bisa seumur hidup saya membuat Gerakan bekerja di ANDROID dengan paket visual.

Apakah saya melewatkan sesuatu dalam catatan bahwa gerakan Shell + hanya berfungsi dengan iphone?

@davidortinau Saya tahu ini hanya beberapa spesifikasi, dan sudah ditutup untuk sementara waktu, tetapi saya berharap Anda dapat mengarahkan saya ke arah yang benar karena spesifikasi menunjukkan bahwa tugas di bawah ini selesai atau di map untuk perkembangan:

• Tambahkan API untuk item "submenu" untuk GPS ala ShellContent -> Musik -> Buka aplikasi Musik

Saat ini karena saya tidak bisa membuat GroupHeaders berfungsi, saya ingin mengerjakan ulang FlyoutMenu saya untuk mengurutkan menjadi 6 grup utama, dan kemudian menampilkan submenu yang penuh dengan FlyoutItems yang mengarahkan saya ke perutean yang telah saya tentukan sebelumnya.

Kasus penggunaan saya adalah bahwa saya memiliki 50+ opsi untuk ditampilkan dan menempatkannya dalam status pengguliran tidak ramah UI, tetapi setiap opsi yang akan ditampilkan adalah sesuatu yang saya perlukan untuk memungkinkan pengguna saya mengaksesnya secara efisien tanpa harus menggulir tanpa henti. Mengurutkan ke dalam grup berdasarkan tema menyeluruh dari setiap opsi paling masuk akal dari sudut pandang UI/UX.

Bisakah Anda menjelaskan di mana itu berdiri dalam hal pengembangan / produksi? - atau arahkan saya ke basis kode yang mengimplementasikannya sehingga saya bisa belajar? (Saya baru menggunakan Xamarin selama 1 bulan, jadi saya masih baru dengan beberapa sumber daya yang tersedia).

@TheBaileyBrew

Saya baru saja mencari di Google repo ini dengan sesuatu yang kemungkinan besar dapat bekerja untuk skenario Anda. Ini bukan Shell, tetapi Anda mungkin dapat menggunakannya dalam pengaturan MasterDetailPage.

https://github.com/ishrakland/ListViewWithSubListView/

Juga, mereka baru saja memindahkan dan memperbarui banyak materi kursus mereka ke MSFT Learn (yang saya jalankan sendiri untuk mengisi kekosongan). Itu ditemukan di sini: https://docs.microsoft.com/en-us/learn/browse/?products=xamarin

Saya akan mencoba dan menjalankan melalui di atas. Semoga berhasil dan selamat datang!

Hai teman-teman saya ingin memilih file atau foto dari galeri atau penyimpanan eksternal di
xamarin membentuk siapa yang harus memilih file itu? File hanya berekstensi .PDF. Ke
pilih kedua file saya menggunakan satu tombol jadi tolong bantu saya !!!

Pada Kamis, 23 Mei 2019, 19:41 Anthony Cool [email protected] menulis:

@TheBaileyBrew https://github.com/TheBaileyBrew

Saya baru saja mencari di Google repo ini dengan sesuatu yang dapat bekerja untuk skenario Anda
yang paling disukai. Ini bukan Shell, tapi Anda bisa menggunakannya di MasterDetailPage
pengaturan mungkin.

https://github.com/ishrakland/ListViewWithSubListView/

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/xamarin/Xamarin.Forms/issues/2415?email_source=notifications&email_token=AK7KSYK4N3XIVP3IHOBE2P3PW3CKJA5CNFSM4EZ4GB52YY3PNVWWK3TUL52HS4DFVREXG43VMHZW63LN5WXVBW63LN5
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AK7KSYI5XKMXD7FC7HZH45LPW3CKJANCNFSM4EZ4GB5Q
.

Hai Guys, saya ingin menambahkan tab berdasarkan kondisi jadi bagaimana cara menambahkan tab di Shell menggunakan C # bukan di Xaml juga cara menambahkan menu itms.

@TheBaileyBrew

apakah ini yang kamu cari?
https://docs.microsoft.com/en-us/xamarin/xamarin-forms/app-fundamentals/shell/flyout#flyout -display-options

@BeleShew pertanyaan Anda mungkin lebih cocok untuk stackoverflow atau di forums.xamarin.com

@PWaliaDev Anda akan melakukannya melalui berbagai koleksi Item yang merupakan bagian dari shell

Shell.Items.Add (ShellItem baru ())
ShellItem baru().Items.add(ShellSection baru())
ShellSection baru().Items.Add(New ShellContent())

Meskipun saya berasumsi jika kami memperbaiki masalah ini
https://github.com/xamarin/Xamarin.Forms/issues/5428

yang sesuai dengan skenario Anda?

@PureWeen - Saya sudah mengatur opsi tampilan per tautan Anda, tetapi yang saya perjuangkan lebih dekat dengan apa yang dihadapi @BeleShew (membuat/menghapus item flyout berdasarkan per pengguna)

Memperbaiki #5428 akan sesuai dengan apa yang ingin saya capai.

Aplikasi saya memiliki pengguna dengan banyak peran/akses dan saya perlu menampilkan opsi menu secara terprogram hanya kepada pengguna yang berwenang (saya tidak ingin pengguna melihat apa yang _ tidak bisa _ lakukan, hanya apa yang mereka bisa.

Meskipun saya telah bermain-main dengan ini, mencoba mencari tahu apakah mungkin untuk memeriksa opsi menu saya dan menambahkan daripada menyembunyikan seperti kode ini (tetapi saya harus mengulangi setiap kemungkinan rute dan opsi menu yang akan memakan waktu muat:

foreach (var item in this.Items)
        {
            if (item is FlyoutItem)
            {
                var removeSections = new List<ShellSection>();
                var fi = item as FlyoutItem;
                foreach (var child in fi.Items)
                {
                    if (child.Route == "NOT_AUTHORIZED_KEY")
                        removeSections.Add(child);
                }
                foreach (var s in removeSections)
                    fi.Items.Remove(s);
            }
        }

Shell hebat dalam teori tetapi tidak dalam hal praktis tanpa ini harus memiliki fitur.

1. Tambah/hapus item shell secara dinamis berdasarkan peran pengguna
2. Skenario Login/Logout atau dua rute navigasi terpisah berdasarkan kondisi.
3. Secara opsional, Dukungan untuk kerangka kerja MVVM lain seperti Prism

Tidak dapat menggunakan Shell dalam aplikasi berorientasi Bisnis hingga fitur 1 dan 2 disediakan.

@Im-PJ Mengapa menurut Anda 1 dan 2 tidak mungkin? (cukup yakin mereka)

3 sedang berlangsung dan dilacak di sini .

Adakah yang tahu apakah mungkin untuk mendapatkan acara tap dari tab App Shell?
pertanyaan forum terkait: https://forums.xamarin.com/discussion/159748/app-shell-pop-to-root-on-tab-tap

Sepenuhnya setuju dengan @Im-PJ, dan tidak mengerti bagaimana fitur ini tidak disediakan secara khusus. Ini adalah alasan utama untuk alat seperti Shell. Siapa pun dapat membuat menu slide out!

@dotMorten mungkin Anda dapat melakukan 1 atau 2 melalui C# dan peretasan yang ekstensif, tetapi TIDAK ada contoh atau penyebutan pengikatan/penonaktifan/penyembunyian/penambahan item Shell saat runtime yang dapat saya temukan. Tampaknya kemampuan dinamis akan menjadi tujuan utama dari alat ini. Membuat representasi XML, bersama dengan beberapa fitur jalur, sangat minim, cukup untuk diberikan kepada orang-orang pemasaran, tetapi tidak cukup untuk benar-benar digunakan dalam aplikasi seluler berfitur lengkap yang nyata.

@Im-PJ

dapatkah Anda memperluas sedikit tentang perbedaannya?

Tambah/hapus item shell secara dinamis berdasarkan peran pengguna
Skenario Masuk/Keluar

Saat ini Anda dapat melakukan Skenario Login/Logout dengan menggunakan TabBar atau menyembunyikan navigasi flyout jika Anda berada di halaman login

<TabBar Route="LoggedOut">
<LoginPage>
</TabBar>

<FlyoutItem Route="LoggedIn"></FlyoutItem>
<FlyoutItem></FlyoutItem>
<FlyoutItem></FlyoutItem>
<FlyoutItem></FlyoutItem>

Jika Anda berada di Halaman Login, satu-satunya cara untuk keluar adalah melalui kode.

Pekerjaan sedang dilakukan di sini untuk mengekspos properti yang dapat diikat IsVisible
https://github.com/xamarin/Xamarin.Forms/tree/shell_isvisible

Hanya perlu sedikit penyempurnaan sebelum membuat PR

dua rute navigasi terpisah berdasarkan kondisi.

Bisakah Anda memberikan contoh tentang apa yang Anda coba lakukan dan tidak bisa lakukan saat ini?

Saya menggunakan Xamarin.Form Shell

Contoh Tautan: https://docs.microsoft.com/en-us/xamarin/xamarin-forms/app-fundamentals/shell/flyout

Tolong bantu aku. Bagaimana cara menampilkan Tabbar di halaman Tentang?

Saya perlu memiliki dua halaman shell secara bersamaan.
Satu untuk menu tampilan dengan halaman sebagai beranda, pengaturan, logout, dll
Satu untuk halaman tab yang harus didorong dari rumah
Untuk saat ini saya harus menggunakan 'cara lama'

Saya perlu memiliki dua halaman shell secara bersamaan.
Satu untuk menu tampilan dengan halaman sebagai beranda, pengaturan, logout, dll
Satu untuk halaman tab yang harus didorong dari rumah
Untuk saat ini saya harus menggunakan 'cara lama'

Jika menggunakan Tabbedpage, tidak dapat menampilkan Flyout . Saya ingin menunjukkan Flyout dan Tabbar kali ini.

Saya memasukkan semua halaman ke dalamsehingga halaman menampilkan Tabbar, Tapi saya hanya ingin memiliki 4 elemen di tabbar (tidak ingin menampilkan More Tab). Bagaimana melakukannya?

<shell>
<flyoutitem route="animals" flyoutdisplayoptions="AsMultipleItems">
<shellcontent route="cats"/>
<shellcontent route="dogs"/>
<shellcontent route="monkeys"/>
<shellcontent route="elephants"/>
<shellcontent route="bears"/>
<shellcontent route="about"/>
</flyoutitem>
</shell>

Saya perlu memiliki dua halaman shell secara bersamaan.
Satu untuk menu tampilan dengan halaman sebagai beranda, pengaturan, logout, dll
Satu untuk halaman tab yang harus didorong dari rumah
Untuk saat ini saya harus menggunakan 'cara lama'

Jika menggunakan Tabbedpage, tidak dapat menampilkan Flyout . Saya ingin menunjukkan Flyout dan Tabbar kali ini.

Saya meletakkan semua halaman di sehingga halaman menampilkan Tabbar, Tapi saya hanya ingin memiliki 4 elemen di tabbar (tidak ingin menampilkan More Tab). Bagaimana melakukannya?

<shell>
<flyoutitem route="animals" flyoutdisplayoptions="AsMultipleItems">
<shellcontent route="cats"/>
<shellcontent route="dogs"/>
<shellcontent route="monkeys"/>
<shellcontent route="elephants"/>
<shellcontent route="bears"/>
<shellcontent route="about"/>
</flyoutitem>
</shell>

Sayangnya saya tidak bisa menggunakan Shell
Saya masih memiliki MasterDetailPage dan TabbedPage di aplikasi yang sama (di iOS saya memiliki halaman tab teratas menggunakan plugin Naxam.TopTabbedPage.Forms)
Ini tiket lama saya