Saya pikir akan sangat membantu bagi orang-orang komunitas jika tim Xamarin.Forms menuliskan lebih banyak dokumen tentang arsitektur Xamarin.Forms, prinsip desain, dan alur kerjanya di Github atau MS docs.
Dari sudut pandang saya, saya menggunakan Xamarin.Forms untuk membuat produk saya, saya akan memiliki 2 pilihan ketika saya menemukan bug, satu adalah mengirimkan masalah ke github dan menunggu itu akan diperbaiki suatu hari nanti dan yang lain adalah mengirimkan masalah ke github dan memperbaikinya sendiri.
Setelah mengkloning kode sumber dan men-debug-nya, sulit untuk memahami cara kerja fitur-fiturnya. Misalnya https://github.com/xamarin/Xamarin.Forms/issues/8521
Contoh lain adalah fitur navigasi halaman Xamarin.Forms di sisi android. Sangat mudah memahami fitur navigasi antar aktivitas di Native Android. Tetapi pada Xamarin.Forms sepertinya menggunakan satu aktivitas utama untuk menangani semua halaman (mungkin) (kecuali formulir asli dan tampilan asli).

Saya pikir ini bagus.

Memisahkan galeri dan pajangan untuk spesifikasi/masalah dll menjadi proyek yang lebih kecil yang dapat dikerjakan dan dipamerkan dengan lebih mudah adalah keuntungan besar dalam siklus pengembangan.

Salah satu hal yang paling bermasalah untuk dilakukan adalah memiliki beberapa versi berbeda di mana bug diperbaiki atau fitur diperkenalkan dan kemudian ketika pindah ditingkatkan.
Memiliki beberapa instance yang lebih kecil sangat membantu dalam hal ini.

Satu hal lain yang saya pikirkan adalah menggunakan ruang kode dan di masa depan github-codespaces, di mana seseorang dapat melampirkan dotfiles untuk suatu masalah (termasuk versi xamarin yang tepat dll) dan kemudian kita bisa menggunakan ruang kode atau checkout versi itu.

Yang terbaik adalah jika bagian galeri-kontrol yang lebih kecil kemudian dapat tersedia sebagai proyek yang tersedia secara terpisah dan hanya dapat dibuka di ruang kode. Saya dapat melihat banyak manfaat dalam kombinasi aplikasi kontrol dan ruang kode yang lebih kecil.

Saya kira apa yang saya coba katakan adalah:

• Galeri-kontrol multi-bagian
• dukungan ruang kode
• dotfile dalam masalah

Sunting: menambahkan poin ketiga.

Saya setuju bahwa saya memiliki beberapa masalah yang terbuka selama berbulan-bulan pada suatu waktu. Saya telah mengkloning XF tetapi tersesat di dalamnya.
Jadi, dokumen untuk video yang hanya menunjukkan cara kerja solusinya akan sangat bagus.

Semakin banyak .Netty ini bisa semakin baik.

1. Hapus string ajaib dan ikatan yang tidak diketik dari inti. Jangan meminta siapa pun yang berkontribusi pada repo untuk menulis penjilidan yang tidak diketik atau string yang tidak dicentang. Ini akan secara dramatis mengurangi bug, membuat perbaikan bug jauh lebih mudah, dan membuat refactoring lebih mudah sehingga bug baru tidak muncul.
2. Tidak memerlukan kontributor untuk menangani lapisan markup apa pun. Beberapa pengembang ingin menggunakan XAML atau CSS tetapi kontributor yang memperbaiki bug tidak perlu peduli dengan hal-hal ini. Hanya orang yang bekerja pada bahasa markup, yang seharusnya menjadi lapisan di atas kelas .Net yang sebenarnya, yang perlu memperhatikan lapisan ini.
3. Pendekatan penyaji harus terstruktur sedemikian rupa sehingga kegagalan untuk mengimplementasikan perubahan properti (atau kesalahan tipe dalam melakukannya seperti di atas) adalah kesalahan tipe.
4. Jika sesuai, harus ada toleransi untuk mengimplementasikan beberapa fitur tanpa ikatan khusus platform sama sekali, misalnya menggunakan SkiaSharp atau Shapes atau objek MAUI komposit, untuk implementasi lintas platform yang andal yang menampilkan hal yang sama dan tidak memperkenalkan bug baru.

Pada satu titik kami menguji arah agar pengguna SLN yang disederhanakan dapat berkontribusi seperti ini

https://github.com/PureWeen/Xamarin.Forms.Sandbox

Cukup sediakan "Contributor.sln" yang sangat bertarget di mana kontributor dapat menunjukkan perbaikan atau API

Hapus semua galeri saat ini dan fokuskan saja ke platform dan Halaman Utama

Apakah Filter Solusi akan lebih baik? Anda tidak harus mempertahankan dua solusi.

Kita akan melihat apa yang dikembangkan dengan Filter Solusi

AFAIK saat ini tidak berfungsi di vsmac dan agak aneh ketika Anda memiliki proyek multi-target. Setelah kami dapat memiliki dukungan kelas satu untuk multi penargetan dan proyek utama hanya dapat bergaya SDK maka saya pikir kebutuhan akan filter solusi tidak terlalu tinggi.

Hal menjengkelkan lainnya adalah VS untuk Windows saat ini membangun semua target ketika Anda memiliki multi penargetan sedangkan vsmac hanya membangun satu untuk kepala platform yang Anda jalankan.

Hal menjengkelkan lainnya adalah VS untuk Windows saat ini membangun semua target ketika Anda memiliki multi penargetan sedangkan vsmac hanya membangun satu untuk kepala platform yang Anda jalankan.

Mendapatkan dukungan untuk itu di VS untuk Windows akan luar biasa! Saya dapat menyingkirkan semua konfigurasi tambahan yang saya buat hanya untuk membangun platform yang sedang saya kerjakan saat ini.

Setuju bahwa cerita multi-penargetan saat ini di VS untuk mac sangat membuat frustrasi. Sayangnya, multi-penargetan adalah pilihan yang bagus sehingga saya masih memilihnya sebagai pendekatan saya dan hanya berfungsi sebagai dukungan teknis untuk orang lain di tim yang mengalami masalah. Ini adalah aliran frustrasi yang tidak pernah berakhir.