7049 membutuhkan waktu lebih dari 1 bulan untuk diluncurkan bahkan ketika PR digabungkan 7 hari setelah laporan bug

Dan membuka permintaan tarik masih dapat mengakibatkan permintaan macet sampai seorang pejabat dari Xamarin meluangkan waktu untuk melihat file yang diubah.

Semoga tim memiliki rencana untuk menghilangkan beberapa hambatan di sekitar proses rilis PR +.

Dan membuka permintaan tarik masih dapat mengakibatkan permintaan tersebut macet sampai seorang pejabat dari Xamarin meluangkan waktu untuk melihat file yang diubah.

Dan lihat itu, setelah disebutkan dalam masalah visibilitas tinggi, seseorang di tim Xamarin.Forms akhirnya menanggapi https://github.com/xamarin/Xamarin.Forms/pull/7728.

Dan membuka permintaan tarik masih dapat mengakibatkan permintaan tersebut macet sampai seorang pejabat dari Xamarin meluangkan waktu untuk melihat file yang diubah.

Dan lihat itu, setelah disebutkan dalam masalah visibilitas tinggi, seseorang di tim Xamarin.Forms akhirnya menanggapi xamarin/Xamarin.Forms#7728 .

Saya berempati dengan tim. Bahwa banyak masalah tidak mudah untuk diprioritaskan/dikelola/diperbaiki. Yang sedang berkata, pasti perlu ada fokus untuk menghilangkan kemacetan dan mengecilkan masalah terbuka dan PR.

Setuju, kualitas selalu menjadi masalah untuk setiap aspek pengembangan Xamarin. Sering kali saya merasa frustrasi karena ketidakcocokan antar komponen, tidak berfungsinya build di VS atau aplikasi saya mogok setelah pembaruan ke versi baru Formulir. Hal-hal hanya harus bekerja. Saya seharusnya tidak dipaksa untuk membangun kembali tata letak saya untuk ketiga kalinya karena beberapa kontrol atau tata letak tidak bekerja sama dengan baik.

Saya melihat beberapa poin terkait

1) Saya tidak tahu berapa banyak orang yang bekerja di Formulir tetapi bagi saya sepertinya tim terlalu kecil untuk mengikuti kecepatan bug atau PR baru yang berkembang pesat. Ini hanya akan menjadi lebih buruk karena mereka harus membagi perhatian antara Formulir dan Maui. Saya sangat berharap bahwa tim mendapat dorongan besar segera.

2) Akan sangat membantu jika Microsoft mulai benar-benar menggunakan Formulir di aplikasi mereka sendiri. Dan yang saya maksud bukan aplikasi demo atau konferensi sederhana. Maksud saya aplikasi nyata seperti Teams atau Outlook. Saya akan senang jika saya salah dalam hal ini, tetapi saya tidak berhasil menemukan aplikasi MS Forms di toko dan menurut beberapa sumber seperti tweet ini https://twitter.com/safaiyeh/status/1219294459298344961 yang kebanyakan mereka gunakan bereaksi warga asli.

• ini benar-benar tidak mengirim sinyal yang baik karena jika MS tidak menggunakan teknologi mereka sendiri (XF) lalu mengapa kita harus melakukannya?

• menggunakan Formulir secara internal pada aplikasi yang kompleks dapat menjadi lapisan pengujian tambahan dan dapat mengurangi jumlah masalah yang melanda rilis publik. Selain itu, mereka dapat melihat bahwa bekerja dengan Formulir tidak semudah yang mereka katakan kepada kami

3) Saya melihat masalah lain dalam kenyataan bahwa MS terus-menerus mencoba menemukan kembali roda dalam bentuk XF Xaml daripada menggunakan solusi yang sudah terbukti dan sudah ada seperti Win UI Xaml. Mereka harus menginvestasikan waktu dalam mengembangkan fitur yang sudah ada dan memperbaiki bug yang diperkenalkan karena itu dan kemudian ada lebih sedikit waktu untuk fitur dan perbaikan bug lainnya.

Saya setuju 100% dengan @Reveon
oh, dan saya harus mengatakan bahwa menggunakan VisualStudio untuk Windows dengan Xamarin adalah pengalaman yang sangat membuat frustrasi.

Mereka terus menambahkan bug yang luar biasa, pemblokiran, ... saya bahkan tidak tahu bagaimana itu mungkin (hal-hal seperti merusak SEMUA perangkat ios yang dibuat, melanggar profil penyediaan, melanggar pengenal gerakan ... bagaimana bug seperti ini bisa diproduksi dan kemudian butuh berminggu-minggu atau berbulan-bulan untuk diperbaiki dalam rilis build? tidak tahu ....)

Saya beralih ke Rider untuk itu dan sekarang saya menggunakan produk Jetbrains di mana-mana :) Setidaknya saya dapat menggunakan IDE yang sama persis di iOS & Windows dan terus bekerja secara produktif.

Saya yakin dengan MAUI hal-hal seperti itu akan berubah, dan cepat atau lambat Microsoft akan mulai menggunakan MAUI secara internal untuk proyek-proyek serius

Testimoni lainnya:
https://github.com/xamarin/Xamarin.Forms/issues/10482#issuecomment -633730446
@EmilAlipiev :

Saya telah menunggu PR saya digabung 1,5 bulan untuk masalah ini. Sudah ada masalah untuk Ios dan Android telah diperbaiki pada Juli 2019 dan tidak ada yang menyentuh untuk uwp. Saya memperbaikinya pada bulan April dan meminta beberapa kali untuk ditinjau dan digabungkan. Sangat menyebalkan bagaimana tim xamarin bekerja. Anda dapat melihat mereka meninjau hanya 1-2 PR per hari.
#10316

Meskipun saya sering frustrasi, "Xamarin buggy" adalah pernyataan yang kasar. 2000+ masalah terbuka hari ini, jika Anda memeriksa flutter memiliki 5000+ masalah terbuka. Angka tidak begitu penting. Xamarin.forms menawarkan lebih dari platform lintas lainnya seperti uwp (termasuk xbox), wpf, mac, gtk, tizen. Jadi ada banyak masalah terbuka untuk Wpf misalnya yang merupakan prioritas lebih rendah bagi kebanyakan dari kita.
Inti dari Xamarin.forms harus ios, android dan uwp meskipun tim Xamarin sering mengabaikan uwp.

1. Harus ada elemen inti seperti tata letak, tampilan daftar, korsel, tampilan koleksi, gambar, peta, label, editor, dll. Itu harus bebas bug. jika Anda membuat rilis baru atau memperbaruinya, Anda harus memastikan tidak ada bug showstopper. Jika ada bug, Anda harus menyelesaikannya dalam waktu maksimal seminggu. Tapi tim Xamarin merilis "4.5-4.6" keren itu dengan fitur keren (siapa yang butuh alat mewah ini 10% dari komunitas?) dan kontrol gambar rusak. Masalah dilaporkan pada awal Maret dan masih belum terselesaikan hingga hari ini. "Bundle into native assemblies" yang sama rusak. Untuk alasan penting itu saya tidak dapat memutakhirkan ke 4.5 dan 4.6. Mereka terus berkembang dengan 4.7 menambahkan fitur baru. Saya dan sebagian besar dari kami mengawasi catatan rilis apakah bug kami teratasi, saya bahkan tidak membaca lagi fitur apa yang ditambahkan.
2. Tim Xamarin harus memahami hal ini. Alasan terbesar banyak orang memilih Xamarin adalah "UWP". Saya pekerja lepas. Saya bertanya kepada pelanggan saya mengapa tidak bergetar atau bereaksi asli? Katanya karena Xamarin punya UWP. Saya ingin UWP juga. Tapi Uwp kebanyakan buggy dengan Xamarin.forms. mereka memperkenalkan CollectionView, ini benar-benar hebat tetapi sejak setahun bug itu tidak terselesaikan. Saya memperbaikinya, tidak ada yang mengulas. Saya berkecil hati melakukan kontribusi lebih lanjut.
3. Hotreload tidak berfungsi sama sekali. Saya membaca di twitter semua "ciuman ciuman" betapa hebatnya hotreaload. Saya pikir pasti ada yang salah dengan saya atau mereka menggunakan alat lain. Karena sering hotreload tidak update. Saya masih menggunakan alat pihak ke-3 seperti livexaml dll. Saya bahkan membuat aplikasi konsol sederhana untuk melakukan hotreload saya sendiri. biaya saya 1 hari. Bekerja jauh lebih baik daripada Xamarin dan bahkan bekerja untuk uwp. Bagaimana mereka tidak bisa menyampaikannya? Mereka memiliki livereload bekerja.

4. Poin terpenting; apa yang @Reveon sebutkan. mereka membutuhkan aplikasi perusahaan nyata yang bekerja dengan xamarin.forms dan mereka harus memperbaruinya dengan rilis baru untuk mendeteksi masalah nyata. Mereka mengeluh bahwa "tidak begitu sulit untuk memberikan repro". Ya sangat sulit jika masalah ini hanya terjadi pada aplikasi perusahaan Anda, bukan pada aplikasi todo. Anda perlu mencoba mereplikasi ui yang sama. mungkin menghabiskan hari-hari Anda sampai Anda mengetahuinya. Itulah mengapa sangat penting bahwa harus ada seseorang yang memiliki aplikasi besar. Saya benar-benar bertanya-tanya apakah salah satu dari pengembang Xamarin yang kita lihat di twitch, youtube, twitter dll pernah mengembangkan aplikasi besar dengan xamarin.forms.

5. Saya harus mengakui sesuatu meskipun saya tidak suka menggunakan alat non-sumber terbuka, lebih dari 50% aplikasi saya menggunakan alat sinkronisasi. Tanpa Syncfusion, menurut saya sangat sulit untuk mendapatkan aplikasi kerja perusahaan. Mereka memiliki segalanya apa yang xamarin tidak atau apa itu xamarin buggy. Sebagai contoh, saya mencari pengganti sfListView selama bertahun-tahun memiliki drag and drop, tampilan gesek, tata letak linier dan grid, virtualisasi yang lebih baik dll. Akhirnya xamarin keluar dengan CollectionView dan mereka melemparkannya ke wajah kita sebagai "versi keren" dari Listview tapi kemudian adalah itu buggy. Tidak bekerja untuk Uwp. banyak fitur yang hilang. Cukup cari CollectionView dalam masalah, Anda akan mendapatkan lusinan dari mereka.

Saya masih percaya bahwa Xamarin adalah alat terbaik untuk lintas platform dan saya berharap mereka akan menganggap masalah ini sebagai umpan balik yang konstruktif.

Komentar yang bagus dan membangun sejauh ini. Saya membaca daftarnya, dan merasakan hal yang sama dengan pengembang lainnya. Masalah umum terjadi di antara kita yang menggunakan Xamarin.Forms untuk mengembangkan Aplikasi perusahaan. Pelacakan dan perbaikan bug membutuhkan perhatian lebih, tetapi secara khusus, satu hal yang jelas, dan berkali-kali saya bertanya pada diri sendiri adalah mengapa tidak ada aplikasi MS perusahaan yang dibangun dengan Xamarin.Forms. Tim MS atau lainnya. Jika jawabannya adalah: cara yang rumit atau tidak mungkin dilakukan dengan Xamarin.Forms, ada wawasan internal yang bagus untuk meningkatkan platform secara keseluruhan dan mencoba memperbaiki masalah tersebut. Xamarin/MAUI pasti akan mendapatkan keuntungan dengan lebih banyak pengembang menguji, berkontribusi dan menyebarkan berita, tetapi ini harus menjadi jalan dua arah. Sekali lagi, saya tidak mengeluh, tetapi akan sangat besar untuk melihat, tahun ini, tahun depan, rilis MS yang hebat dari Aplikasi Seluler yang dibangun dengan MAUI atau Xamarin. Juga periksa para pengembang untuk mengetahui frustrasi mereka atau kemungkinan peningkatan, dan bawa pengembangan lintas platform ke tingkat yang baru.

Karena, saya disebut...

Saya memimpin proyek kecil untuk aplikasi lintas platform antara Android dan Windows Desktop (WPF).

Kami menemukan banyak bug, yang harus kami perbaiki atau perbaiki. Saat ini, saya memulai proyek internal untuk perbaikan dan peningkatan kinerja, karena berbagi solusi kami dengan kemajuan yang lambat ini tidak mungkin. Kami juga memiliki garis mati.

Membawa bug di saluran resmi sangat mahal untuk tim kecil kami, jadi alangkah baiknya untuk mendapatkan lebih banyak perhatian, mungkin Anda mendapatkan lebih banyak dari komunitas.

Di bagian wpf xamarin ada banyak hal yang harus dilakukan. Performanya buruk dan itu adalah bug sederhana . Tapi ide di balik dan dasarnya sudah diatur. Sungguh miris melihat keadaan saat ini, karena bisa jadi jauh lebih baik...

Setuju, kualitas selalu menjadi masalah untuk setiap aspek pengembangan Xamarin. Sering kali saya merasa frustrasi karena ketidakcocokan antar komponen, tidak berfungsinya build di VS atau aplikasi saya mogok setelah pembaruan ke versi baru Formulir. Hal-hal hanya harus bekerja. Saya seharusnya tidak dipaksa untuk membangun kembali tata letak saya untuk ketiga kalinya karena beberapa kontrol atau tata letak tidak bekerja sama dengan baik.

Saya melihat beberapa poin terkait

1. Saya tidak tahu berapa banyak orang yang bekerja di Formulir tetapi bagi saya sepertinya tim terlalu kecil untuk mengikuti kecepatan bug atau PR baru yang berkembang pesat. Ini hanya akan menjadi lebih buruk karena mereka harus membagi perhatian antara Formulir dan Maui. Saya sangat berharap bahwa tim mendapat dorongan besar segera.
2. Akan sangat membantu jika Microsoft mulai benar-benar menggunakan Formulir di aplikasi mereka sendiri. Dan yang saya maksud bukan aplikasi demo atau konferensi sederhana. Maksud saya aplikasi nyata seperti Teams atau Outlook. Saya akan senang jika saya salah dalam hal ini, tetapi saya tidak berhasil menemukan aplikasi MS Forms di toko dan menurut beberapa sumber seperti tweet ini https://twitter.com/safaiyeh/status/1219294459298344961 yang kebanyakan mereka gunakan bereaksi warga asli.

• ini benar-benar tidak mengirim sinyal yang baik karena jika MS tidak menggunakan teknologi mereka sendiri (XF) lalu mengapa kita harus melakukannya?
• menggunakan Formulir secara internal pada aplikasi yang kompleks dapat menjadi lapisan pengujian tambahan dan dapat mengurangi jumlah masalah yang melanda rilis publik. Selain itu, mereka dapat melihat bahwa bekerja dengan Formulir tidak semudah yang mereka katakan kepada kami

1. Saya melihat masalah lain dalam kenyataan bahwa MS terus-menerus mencoba menemukan kembali roda dalam bentuk XF Xaml daripada menggunakan solusi yang sudah terbukti dan sudah ada seperti Win UI Xaml. Mereka harus menginvestasikan waktu dalam mengembangkan fitur yang sudah ada dan memperbaiki bug yang diperkenalkan karena itu dan kemudian ada lebih sedikit waktu untuk fitur dan perbaikan bug lainnya.

Saya setuju dengan banyak masalah yang Anda sebutkan. Microsoft pasti perlu membuat aplikasi perusahaan menggunakan Xamarin Forms atau iOS atau Android. Setelah mereka memiliki contoh aplikasi perusahaan yang berfungsi, maka kami tidak dapat mengeluh bahwa membuat aplikasi profesional membuat frustrasi.

Xamarin Forms adalah kerangka kerja lintas platform yang bagus bagi mereka yang ingin membuat aplikasi sekali dan bekerja di mana saja. Ini berfungsi dengan baik jika Anda membuat aplikasi sederhana. Tetapi begitu Anda mulai membuat aplikasi yang lebih profesional dengan lebih banyak fitur seperti animasi, tab tersegmentasi, virtualisasi data, tata letak yang kompleks, dll., Anda akan semakin berjuang melawan kerangka kerja agar fitur berfungsi. Saya menemukan bahwa hal-hal sederhana yang seharusnya berfungsi tidak jelas atau memerlukan peretasan untuk membuatnya berfungsi.

Fitur seperti Xamarin Hot Reload masih prematur dalam tahap pengembangan. Misalnya, jika saya membuat perubahan gaya di App.xaml atau kamus sumber daya yang dirujuk dari App.xaml, tempat saya menyimpan gaya dan sumber daya, Hot Reload akan mengacaukan tata letak aplikasi di simulator atau menyebabkan aplikasi mogok.

Saya menemukan bahwa Visual Studio sangat bermasalah ketika mengembangkan aplikasi Xamarin. Misalnya, jika proyek Android saya dipilih sebagai proyek startup, uji dengan itu, dan kemudian beralih ke proyek iOS saya sebagai proyek startup saya, itu akan menampilkan semua jenis kesalahan palsu. Menghancurkan folder bin atau obj tidak membantu. Itu mengharuskan saya untuk me-restart VS. Dalam contoh lain, VS akan secara acak kehilangan koneksinya ke Mac saya saat saya men-debug aplikasi saya. Ini akan menyebabkan VS saya membeku. Saya akan mengamuk, mempertanyakan hobi dan hidup saya sebagai pengembang seluler, dan memaksa membunuh VS menggunakan Task Manager. Selain itu, saya menemukan bahwa versi Visual Studio yang akan datang memperkenalkan kembali bug yang diperbaiki di versi sebelumnya. Saya tidak tahu cara menginstal versi VS sebelumnya setelah versi terbaru dirilis dan saya menginstalnya. Saya dapat menghapusnya dan mencoba menginstal ulang menggunakan penginstal, tetapi itu akan selalu menginstal versi terbaru. Ini tidak seperti paket NuGet di mana Anda dapat menginstal versi apa pun.

Terakhir, mengapa kontrol tab tersegmentasi bukan merupakan bagian dari toolkit Xamarin? Tab tersegmentasi digunakan hampir di mana-mana. Saya tidak perlu menggunakan Syncfusion toolkit atau toolkit lain untuk menggunakan kontrol yang sangat umum.

Saya gugup untuk mengadopsi menggunakan MAUI ketika keluar di aplikasi profesional apa pun yang saya kembangkan sampai banyak dari frustrasi pengembang ini menggunakan Xamarin dan Visual Studio teratasi. Saya akan bermain dan bereksperimen dengannya ketika itu keluar. Tetapi saya akan lebih percaya diri jika Microsoft keluar dan membuat aplikasi perusahaan menggunakan MAUI daripada membuat aplikasi demo sederhana.

Dapatkah seseorang mencerahkan kami tentang Formulir Xamarin dan peta jalan MAUI? Apakah mereka akan dipertahankan secara paralel? Apakah ada penghentian keras untuk dukungan Xamarin Forms dan akankah Microsoft mendorong MAUI ke tenggorokan kita di pembaruan Visual Studio di masa mendatang?

Terima kasih

@SunnyMukherjee Dari FAQ,

Bagaimana masa depan Xamarin.Forms?

Versi utama Xamarin.Forms berikutnya akan sekitar September 2020 dan terus diperbarui melalui rilis .NET MAUI dengan .NET 6. Setelah itu, Xamarin.Forms akan terus menerima layanan prioritas selama 12 bulan.

Pada dasarnya, Xamarin.Forms akan dimatikan setelah versi 5.

@SunnyMukherjee Dari FAQ,

Bagaimana masa depan Xamarin.Forms?

Versi utama Xamarin.Forms berikutnya akan sekitar September 2020 dan terus diperbarui melalui rilis .NET MAUI dengan .NET 6. Setelah itu, Xamarin.Forms akan terus menerima layanan prioritas selama 12 bulan.

Pada dasarnya, Xamarin.Forms akan dimatikan setelah versi 5.

Pada Pertengahan 2021 . . . jika Covid tidak membunuh saya sebelum itu, Formulir Maui atau Xamarin akan melakukan pekerjaan itu.

@SunnyMukherjee saya mendengar rasa sakit Anda. Saya telah menggunakan Xamarin.Forms sejak pertama kali diluncurkan, dan telah berkembang sejak saat itu. Ingat bahwa Microsoft tidak membuat Xamarin.Forms, mereka hanya membeli Xamarin pada tahun 2018. Jadi MAUI adalah proyek Microsoft untuk menulis ulang menjadi lebih baik dan membuatnya bekerja mulus dengan seluruh .net. Bekerja dengan Xamarin.Forms bukanlah hal yang sepele karena yang harus dilakukan bukanlah hal yang sepele. Banyak orang mengatakan bahwa mereka harus melakukan apa yang telah dilakukan Uno atau Flutter dan membuat kontrolnya sendiri sepenuhnya - tetapi itu bertentangan dengan Xamarin.Forms. Ini adalah kerangka kerja pengembangan asli - mengekspos kontrol asli dengan cara yang umum. Ini bukan tugas kecil. Saya juga memiliki banyak masalah dengan Xamarin.Forms, tetapi secara keseluruhan waktu yang dihemat dengan menggunakannya daripada menulis aplikasi yang sama dalam berbagai bahasa jauh lebih besar daripada masalahnya. Ditambah kemampuan untuk membagikan 90% kode dengan proyek inti ASP.Net backend membuatnya lebih bermanfaat.
Meskipun penting untuk memberi tahu Microsoft apa yang kami inginkan di MAUI - tetapi kami harus memahami bahwa itu bukan tugas kecil bagi mereka, dan saya berharap MAUI akan menjadi langkah besar ke arah yang benar.
Tonton video ini dari build terbaru MAUI demo itu dan jelaskan bagaimana itu cocok dengan peta jalan dan juga apa yang akan mereka lakukan dan dukung di Xamarin.Forms untuk sementara:
https://channel9.msdn.com/Events/Build/2020/BOD106?ocid=AID3012654&WT.mc_id=Build2020_pmmsocialblog

Membaca di sini saya bertanya-tanya apa yang dapat saya pelajari di sini untuk meningkatkan kualitas Xamarin.Forms. Saya ingin kembali ke pertanyaan awal @Happypig375 :

Adakah pemikiran tentang cara meningkatkan?

Salah satu tujuan utama kami antara sekarang dan pengiriman .NET MAUI adalah meningkatkan fondasi, titik awal. Untuk alasan ini, kami menghabiskan sebagian besar sprint kami saat ini untuk masalah CollectionView, dan kami mengusulkan untuk menjeda pengembang fitur di Xamarin.Forms 5 sehingga kami memiliki waktu dari September 2020 hingga November 2021 untuk lebih fokus pada penyelesaian masalah.

Ini semua terlihat di papan proyek sprint kami.

Pendeknya:

• Lebih cepat dalam permintaan tarik komunitas.

Saya membuat ulang pohon permintaan tarik beberapa hari yang lalu. Kenapa reviewnya lama banget?

WPF-Renderer, poin bug potensial:

• Ukur / Atur kontrol
• Logis/Visual-Childtree rusak
• Pertunjukan

Hai @davidortinau , saya pikir cara yang baik untuk mengatasi ini adalah secara terbuka mengabdikan seseorang untuk terlibat penuh dalam:

• triase masalah bug
• kelola, kirim, dan dorong untuk peninjauan dan penggabungan PR.

Dia akan menjadi titik kontak kita jika sesuatu berjalan terlalu lambat dan dia dapat menjelaskan apa yang sedang terjadi.
Selain itu, jika ada hambatan non-hukum, akan luar biasa jika kita dapat memiliki saluran Twitch di mana pada gilirannya seseorang memperbaiki bug atau meninjau PR online. IHMO, ini bisa berdampak luar biasa pada minat dan kolaborasi pengembang eksternal.
Ini berlaku untuk Formulir .NET MAUI dan Xamarin. Tapi mungkin aku hanya seorang pemimpi

Saya tidak terlalu terkejut bahwa Xamarin.Forms memiliki banyak bug mengingat jumlah platform yang dijalankannya dan perubahan dari platform atau oleh pengembangannya sendiri.

Yang mengejutkan bagi saya adalah jumlah bug regresi, hal-hal yang berfungsi sebelumnya atau diperbaiki sebelum dan kemudian rusak dengan rilis berikutnya.
Bagi saya ini adalah tanda yang jelas dari tidak cukup menguji. Rezim pengujian yang lebih ketat dapat menyebabkan beberapa perubahan tidak ada di rilis berikutnya tetapi menangkapnya lebih awal benar-benar diperlukan untuk menghindari stigma produk yang tidak dapat diandalkan, terus terang.

Lebih banyak pengujian adalah sesuatu yang saya ingin lihat sebagai pelajaran yang diambil dari Xamarin.Forms untuk MAUI. Itu bisa menghindari banyak masalah yang dilaporkan dan sumber daya yang terbuang karena kode kereta memakan waktu lama alih-alih segera ditangani dengan PR yang dibuat.

Ketika saya mengatakan "fitur inti" dan "bug kritis". Ini yang saya maksud masalah seperti ini . Ini sangat menjengkelkan sekarang. Saya telah melakukan rilis seminggu tanpa benar-benar mengetahui masalah ini. Saya bertanya-tanya mengapa retensi aplikasi turun drastis. Bayangkan saya memiliki sebagian besar penutur non-Inggris dan pengguna Spanyol atau Jerman membuka aplikasi dan itu adalah bahasa Inggris karena bug ini. Dia akan langsung menghapusnya meskipun aplikasi saya diterjemahkan ke dalam bahasa tersebut. Bug ini dapat terjadi tetapi telah dilaporkan mount yang lalu? mengapa tidak diperbaiki. Bahkan Appcenter dan Azure Pipelines memiliki bug itu.

Untuk meningkatkan kerangka kerja. Saya ingin menambahkan:

Tingkatkan kemungkinan untuk menulis penyaji Anda sendiri. Hindari kata kunci internal .

Daripada hanya memposting proyek sampel di GitHub, Microsoft dapat membuat aplikasi perusahaan profesional seperti OneDrive atau aplikasi Xbox dengan Xamarin Forms, iOS, atau Android dan mempublikasikannya ke App Store sehingga orang selain pengembang akan menggunakannya. Microsoft telah melakukannya sebelumnya dengan memigrasikan Visual Studio dari C++ ke C# dan WPF (diberikan pelanggan adalah pengembang dalam kasus itu). Itu akan memberi tahu Microsoft tentang masalah kami dan jika mereka berhasil, itu akan memberikan kepercayaan yang luar biasa kepada komunitas pengembang bahwa segala sesuatu mungkin terjadi dengan Xamarin.

Saya senang ada posting tentang ini dan saya ingin menimbang frustrasi saya. Saya sering pasif dalam memposting balasan untuk masalah yang ada, tetapi yang memicu saya adalah masalah ini terkait dengan BundleAssemblies ; setelah lebih dari 2 bulan masalah berdampak tinggi ini, saya masih tidak memiliki indikasi yang jelas tentang apa solusi, status, atau langkah maju dari anggota Xamarin.

Saya menjalankan tim Agile Scrum, dan sangat sering KPI adalah Velocity (jumlah pekerjaan yang dilakukan). Kadang-kadang, ketika kami memiliki masalah yang meningkat ke tingkat panas tertentu, pernyataan akhir saya akan selalu "... Saya ingin tahu apa yang dapat saya pelajari di sini untuk meningkatkan kualitas " [produk kami]. Jangan tersinggung (sungguh), tapi itu hanya untuk menggurui bos saya atau pelanggan kami. Ketika saya mengatakan bahwa selama konteks diskusi semacam itu, itu hanya akan berarti bahwa saya atau pemilik Produk saya tidak siap untuk pekerjaan itu atau kami dalam keadaan penyangkalan atau yang terburuk, kami benar-benar tidak tahu apa yang sedang terjadi. (Kudos kepada salah satu pemangku kepentingan kami yang menampar akal sehat saya)

Apa yang benar-benar mengganggu saya adalah bug regresi dan kurangnya tanggapan/penjelasan singkat untuk masalah ini. Setiap rilis XF cenderung merusak sesuatu; dan itu merusak sesuatu yang jelas - penyelarasan salah, gambar tidak ditampilkan, pemotongan teks tidak berfungsi dan lain-lain. Setengah dari kasus uji kami hanya untuk memeriksa regresi XF ini; itu konyol. Jelas ada yang salah dengan pengujian internal XF. Bahkan ketika bug show-stopper dikenali, masih ada beberapa rilis baru berikutnya; apa gunanya rilis baru itu ketika kita tidak bisa menggunakannya? Bukankah rilis baru itu seharusnya masuk ke Beta Anda?

Setelah mengatakan semua ini, saya dan pemangku kepentingan kami sangat lelah dengan "budaya beracun" dengan XF. Ini seperti bagaimana Windows 10 dapat merilis pembaruan yang menghapus file pengguna atau sistem pengguna bata (tetapi setidaknya respons dan perbaikan terbaru mereka cepat). Saya yakin rasa frustrasi kami di sini bukan tentang kurangnya fitur di XF, tetapi tentang kualitas rilis. Adapun bagaimana XF dapat meningkatkan kualitas? Anda dapat mencari secara online dan mendapatkan jutaan hasil; dan saya bahkan tidak yakin harus mulai dari mana di sini tanpa menjadi sombong untuk melemahkan pemahaman Microsoft tentang "jaminan kualitas". Saya yakin Microsoft tahu bagaimana melakukan jaminan kualitas (hei, saya membaca buku putih Microsoft tentang ini). Ini bermuara pada orang yang bertanggung jawab; dia membutuhkan tanggung jawab, akuntabilitas, dan komitmen untuk meningkatkan (atau menerapkan) pemeriksaan kualitas.

Menurut saya hal yang paling membuat frustrasi tentang XF adalah ketika kontribusi kami (apakah itu PR baru, masalah baru, atau bahkan pertanyaan atau umpan balik sederhana) diabaikan begitu saja oleh tim.
Tim ini mungkin terlalu kecil. Tetapi memiliki satu orang yang berdedikasi untuk memberikan jawaban dalam waktu yang wajar pasti akan membantu.

Salah satu contoh yang baik adalah regresi tentang BundleAssemblies ini (telah disebutkan beberapa kali).
Contoh bagus lainnya adalah masalah tentang CollectionView ini.

Kekhawatiran lain bagi saya adalah bahwa aplikasi XF dipengaruhi oleh perubahan XF tentu saja, tetapi juga Mono, Visual Studio, Xamarin Framework, DotNet, dan bahkan beberapa perpustakaan Microsoft.
Saya merasa bahwa tim-tim tersebut tidak berkomunikasi dengan baik secara internal.
Menurut pendapat saya, meminta Microsoft menggunakan XF secara internal untuk aplikasi mereka pasti akan membantu.

Sekali lagi, satu contoh bagus adalah regresi ini , yang akar masalahnya sebenarnya ada di Mono dan AndroidX.
Tetapi saya juga dapat menyebutkan masalah ini di ekstensi dotnet yang memengaruhi aplikasi iOS, atau bahkan masalah ini di msal.
Dan tentu saja masalah ini di visual studio , mengenai tautan sumber.

Orang-orang di sini melakukan pekerjaan yang hebat dengan mengatakan sebagian besar dari apa yang akan saya katakan secara detail, jadi saya akan membuatnya cepat

Masalah Teknis

• Visual studio mogok lebih dari 3 kali/menit saat bekerja dengan XF.
• Banyak kontrol dasar yang hilang, Atau perlu untuk membentuknya seperti yang seharusnya.
• Ketika Anda mengatakan XF, Anda baru saja mengatakan kerangka kerja lintas platform kinerja terburuk, dan izinkan saya menjelaskan kepada orang-orang yang mengatakan XF menangani Android/ios asli ... dan itu sulit. Hanya melihat! silahkan lihat! demi kasih Tuhan! di flutter, RN, NativeScript... Mereka semua memiliki tujuan yang sama tetapi XF jauh di belakang
• Muat ulang panas hanya berfungsi dengan baik ketika Anda membuat proyek baru dan membuat teks default di sisi kiri dan hanya itu, Kemudian Anda sendiri!
• Semua orang di komunitas flutter misalnya dalam setiap rilis seperti: Oh OMG keren sekali apa yang mereka lakukan, Di sisi lain com XF seperti: Mari kita lihat apa yang mereka rusak atau apa yang mereka tambahkan yang hanya dibutuhkan 10% dari com!
• Perjalanan awal menggunakan XF adalah serangkaian hecks, contohnya adalah: baru-baru ini saya harus membuat salah satu kontrol umum di semua aplikasi di Playstore yang merupakan ikon tab bawah sederhana saja, Menggunakan shell dengan ikon hanya memiliki margin besar di bagian bawah yang terlihat jelek dan seperti semua orang, saya membuat masalah, hanya untuk memperhatikan bahwa masalah serupa telah diatasi lebih dari 6 bulan yang lalu ... Dan tidak ada perbaikan di jalan
• Pikirkan sebuah aplikasi oke? Aplikasi apa saja? Apakah itu memiliki pembelian dalam aplikasi atau semacam layanan premium? Tentu saja. Jadi Anda mulai mencari plugin untuk google pay dan apple pay kan? Atau bahkan paypal kan? Biarkan saya memberi tahu Anda sesuatu, tidak ada !!! Ketika Anda bertanya kepada tim resmi XF, Anda tahu apa yang akan mereka jawab? Mereka mengirimi Anda tautan ke plugin usang yang tidak resmi yang dibuat oleh satu orang (yang saya hormati) 2 tahun yang lalu tanpa pembaruan, WTF (maaf) !!

Tidak teknis

• Oh ayolah, bahkan dokumentasi resminya sangat buruk, mereka menangani fitur tingkat aplikasi yang harus dilakukan dan tutorial caranya
• Saya membenci XF bahkan sebelum menggunakannya, tahu mengapa? Semua orang mengatakan bahkan MS tidak menggunakan jadi mengapa F Anda menggunakannya?
• Respon yang sangat lambat untuk masalah dan PR yang dibuat komunitas atas waktu dan biaya mereka sendiri untuk membantu tim XF !!!

Solusi

• Tim XF sangat sangat kecil, Bagaimana bisa sebuah perusahaan besar seperti Microsoft tidak mempekerjakan cukup banyak orang untuk membuat produk mereka sendiri lebih baik? Ada talenta di mana-mana di seluruh dunia yang sangat menyukai Microsoft seperti saya!
• XF harus mengatasi masalah tingkat tinggi sebelum dirilis, itu hanya menunjukkan betapa tidak matangnya tim, seperti hanya mengirim siapa yang peduli ...
• Microsoft sebagian besar dan wajib menggunakan XF untuk produk mereka! Jika tidak itu hanya cara untuk mengatakan XF itu bagus tapi nah saya tidak menyukainya yukh
• Buat dokumentasi yang sangat kaya! Sebuah dokumen yang merupakan tujuan pertama di sebagian besar situasi, mempekerjakan lebih banyak orang! semudah itu, ada banyak pengembang berpengalaman yang membuat blog Anda dapat bekerja dengan mereka
• XF tidak dikenal sebanyak Flutter, Bermitralah dengan influencer pengkodean besar di youtube, bahkan penyebutan sederhana membantu XF
• Okey juga lihat produk lain dan lihat apa yang disukai pengembang tentang mereka dan buat versi Anda sendiri. Berkibar misalnya.
• Jangan takut bertanya kepada komunitas apa yang mereka inginkan, jangan hidup di bawah batu dan buat apa yang tidak akan digunakan siapa pun!

Saya sangat menyesal atas perilaku agresif saya dan bahasa Inggris saya yang buruk, saya sangat suka XF!
Maui adalah titik awal baru, tolong buat revolusi baru, semua orang berharap menjadi sesuatu yang hebat jadi tolong jangan mengecewakan kami, kami memiliki harapan besar.

@Amine-Smahi Silakan hubungi melalui email dengan informasi lebih lanjut tentang perilaku yang menyebabkan crash ([email protected]).

Saya sepenuhnya setuju bahwa perbaikan bug dan proses pengujian fitur baru sangat buruk.

Sebagai contoh:
https://github.com/xamarin/Xamarin.Forms/issues/3335 - berhenti menggunakan ListView.RecycleElement
https://github.com/xamarin/Xamarin.Forms/issues/4168 - berhenti menggunakan CompressedLayout

Saat Anda menambahkan fitur baru yang meningkatkan kinerja - itu bagus! Tetapi ketika fitur-fitur ini tidak dapat digunakan, itu sangat mengecewakan.

Dan beberapa masalah yang memengaruhi aplikasi saya dan tidak diperbaiki untuk waktu yang lama:
https://github.com/xamarin/AndroidX/issues/64
https://github.com/xamarin/Xamarin.Forms/issues/5087
https://github.com/xamarin/Xamarin.Forms/issues/5127
https://github.com/xamarin/Xamarin.Forms/issues/3168
https://github.com/xamarin/Xamarin.Forms/issues/8058 https://github.com/xamarin/Xamarin.Forms/issues/10055
https://github.com/xamarin/xamarin-android/issues/3341
https://github.com/xamarin/xamarin-android/issues/3480

Tim harus bertanggung jawab atas fitur yang mereka terapkan. Misalnya, @StephaneDelcroix mengimplementasikan https://github.com/xamarin/Xamarin.Forms/pull/1136. Saya pikir dia adalah orang yang harus ditugaskan untuk https://github.com/xamarin/Xamarin.Forms/issues/4168 dan memperbaiki bug terkait CompressedLayout.

Tentang dokumentasi: Saya pribadi berpikir bahwa sebagian besar baik-baik saja, kecuali untuk catatan rilis, yang benar-benar f * d up ;) (selalu terlambat atau tidak lengkap)
Sekali lagi, saya tidak berbicara secara khusus tentang XF, tetapi lebih umum seluruh kerangka xamarin (xamarin.android, xamarin.ios, visual studio, mono, komponen...).

Berikut ini contohnya: catatan rilis xamarin ios

@melimion

Saat Anda menambahkan fitur baru yang meningkatkan kinerja - itu bagus! Tetapi ketika fitur-fitur ini tidak dapat digunakan, itu sangat mengecewakan.

Ini benar-benar benar.
Anda telah menambahkan CollectionView. Hasilnya adalah banyak kesalahan di Android, di iOS umumnya tidak dapat digunakan (Pengecualian yang dibuang, pengecualian NSinconsistency, dan sebagainya. Dan ini jika Anda melakukan semuanya sesuai dengan panduan resmi (!).
Anda menambahkan CarouselView-kesalahannya sama.
Kita harus menggunakan Listview yang sudah ketinggalan zaman tetapi lebih stabil.

Sekarang, ketika saya melihat judul "kami menambahkan", saya langsung menggulir lebih jauh.
Dan Anda juga memiliki elemen lain, misalnya
Swipeview,Expander, yang juga memiliki banyak kesalahan.
Dan kemudian ada, seperti yang ditulis orang di atas, mono, studio visual dengan bugnya sendiri.

Batalkan fitur baru di 4.7-4.8, perhatikan perbaikan bug.
Pengembangan pada Xamarin seperti menemukan solusi, solusi sementara.
Saya minta maaf untuk bahasa Inggris saya yang buruk

Kemarin saya sudah cek. Ada lebih dari 200 masalah yang ditandai dengan dampak tinggi. Tidak ada gunanya merilis fitur baru, ketika bug kritis belum teratasi. Saya setuju dengan saran sebelumnya. Hentikan fitur baru. Luangkan waktu untuk memperbaiki dan mengurangi jumlah masalah. Saya terjebak di 4.4 , misalnya, karena suatu masalah. Bayangkan lebih banyak orang dalam situasi ini. Stabilitas dan kinerja didahulukan, jika tidak ada tenaga untuk memiliki inovasi dan pemeliharaan IMHO.

Saya ingin tahu apakah mungkin ada semacam jajak pendapat di antara pengembang XF untuk melihat apakah kami lebih suka melihat upaya rekayasa untuk membersihkan bug yang ada atau menambahkan fitur yang direncanakan untuk 4.7 dan seterusnya. Maksud saya fitur-fitur baru itu sendiri akan menambahkan lebih banyak bug baru yang menyebabkan lebih banyak pengerjaan ulang dan lebih banyak penundaan ... terkadang pembekuan fitur kuno yang baik diperlukan.

Bagi saya pribadi, saya ingin melihat upaya paling banyak masuk ke MAUI, yang terdengar seperti pengaturan ulang arsitektur XF yang masuk akal, dengan upaya paling banyak kedua untuk membersihkan bug berdampak tinggi. Menambahkan fitur baru bahkan tidak akan masuk dalam daftar saya - saya lebih suka menambahkannya ketika kami memiliki platform yang lebih baik untuk menambahkannya.

@freever Saya sangat setuju!
Ini tidak hanya akan membuat pengembang Xamarin saat ini lebih bahagia, tetapi juga akan menyelesaikan bug tersebut untuk MAUI!

Saya tidak tahu apakah bug ini akan dilakukan untuk diperbaiki di sini di MAUI, atau akan diperbaiki di Xamarin.Forms.

Saya merasa @davidortinau menutupi semangat masalah ini di sini

https://github.com/dotnet/maui/issues/109#issuecomment -635078640

Saya telah memperbarui deskripsi dengan komentarnya

Saya benar-benar ingin menyoroti bagian ini dari apa yang dia katakan lagi untuk semua orang

kami menghabiskan sebagian besar sprint kami saat ini untuk masalah CollectionView, dan kami mengusulkan untuk menjeda pengembang fitur di Xamarin.Forms 5 sehingga kami memiliki waktu dari September 2020 hingga November 2021 untuk lebih fokus pada penyelesaian masalah.

PureWeen tutup 10 jam yang lalu

Lusinan pengembang xamarin telah menyatakan pendapat mereka dalam tiket ini, dan saya tidak merasa bahwa mereka telah didengar.
Sayangnya, Anda baru saja membuktikan maksud saya

@PureWeen Masalah ini mencakup lebih dari sekadar jumlah bug. Mereka bahkan terdaftar dalam bentuk poin.

@tranb3r

Menurut saya hal yang paling membuat frustrasi tentang XF adalah ketika kontribusi kami (apakah itu PR baru, masalah baru, atau bahkan pertanyaan atau umpan balik sederhana) diabaikan begitu saja oleh tim.

Bagaimana komentar @davidortinau gagal untuk Anda? Poin utama yang saya buat adalah bahwa kami memperlambat pengembangan fitur-fitur baru sehingga kami dapat lebih fokus pada PR terbuka dan bug dan akhirnya sampai ke .net maui yang akan menjadi produk berbasis .net 6 kami yang lebih baru

@Happypig375

@pauldipietro menjangkau individu yang memposting masalah itu sehingga dia dapat mulai menangani masalah tersebut secara lebih langsung dengan mereka.

Inti dari masalah ini adalah XF memiliki terlalu banyak bug dan mengabaikan komunitas. Jadi, kami memperlambat pengembangan baru untuk lebih fokus pada bug yang ada dan membuka PR

Jika ada masalah lain di luar bug yang terbuka, mari kita buka masalah untuk itu. Tetapi masalah ini adalah tentang terlalu banyak bug terbuka dan kami memiliki rencana untuk mengatasinya.

Dengan MAUI, kita harus memiliki proses perbaikan bug yang secepat mungkin. Adakah pemikiran tentang cara meningkatkan?

Kami menghapus banyak aspek warisan dari Formulir dengan .NET Maui dan kami menghabiskan tahun ini sebelum berfokus pada bug dan PR terbuka sehingga kami dapat lebih produktif dengan .NET Maui

Ini adalah papan proyek kami

https://github.com/xamarin/Xamarin.Forms/projects

Anda dapat melihat apa yang kami tambahkan ke setiap sprint
https://github.com/xamarin/Xamarin.Forms/projects/70

Inilah peta jalan kami
https://github.com/xamarin/Xamarin.Forms/wiki/Feature-Roadmap
Kami berusaha setransparan mungkin dengan apa yang sedang kami kerjakan

Jika masalah pada repo tersebut di-ping atau memiliki fokus tinggi, kami mencoba untuk mengangkatnya ke atas tetapi terkadang algoritme itu tidak sempurna.

@Amine-Smahi inilah papan proyek untuk shell dan apa yang kami lihat sebagai pemblokir
https://github.com/xamarin/Xamarin.Forms/projects/54

Bisakah Anda mengarahkan saya ke masalah yang Anda maksud sehingga saya bisa melihatnya?

@PureWeen

Bagaimana komentar @davidortinau gagal untuk Anda? Poin utama yang saya buat adalah bahwa kami memperlambat pengembangan fitur-fitur baru sehingga kami dapat lebih fokus pada PR terbuka dan bug dan akhirnya sampai ke .net maui yang akan menjadi produk berbasis .net 6 kami yang lebih baru

Seperti disebutkan sebelumnya, masalah ini mencakup lebih dari sekadar jumlah bug di XF.

Jika ada masalah lain di luar bug yang terbuka, mari kita buka masalah untuk itu. Tetapi masalah ini adalah tentang terlalu banyak bug terbuka dan kami memiliki rencana untuk mengatasinya.

Sudah ada terlalu banyak masalah terbuka !!! Apa gunanya membuka yang baru jika Anda mengabaikannya ...

Misalnya, salah satu poin penting yang disebutkan sebelumnya adalah bahwa tim Microsoft harus menggunakan xamarin saat mengembangkan aplikasi.
Apakah Anda mendengar tanggapan ini? Apa yang harus kami lakukan untuk meyakinkan Anda bahwa ini adalah ide yang bagus? Apakah kita harus membuka masalah untuk itu ???

Seperti disebutkan sebelumnya, masalah ini mencakup lebih dari sekadar jumlah bug di XF.

Mari kita buat masalah yang berbeda untuk itu. Mengatasi banyak hal menjadi satu masalah tidak akan produktif.

Apa komentar lain di sini yang tidak ada hubungannya dengan masalah bug/prs/kerapuhan terbuka di sekitar XF yang Anda ingin kejelasan?

Misalnya, salah satu poin penting yang disebutkan sebelumnya adalah bahwa tim Microsoft harus menggunakan xamarin saat mengembangkan aplikasi.
Apakah Anda mendengar tanggapan ini? Apa yang harus kami lakukan untuk meyakinkan Anda bahwa ini adalah ide yang bagus? Apakah kita harus membuka masalah untuk itu ???

Ya, kami mencoba meyakinkan semua orang untuk menggunakan Xamarin

Kami banyak berbicara dengan tim internal tentang pilihan aplikasi dan ini adalah diskusi yang berkelanjutan. Banyak dari diskusi internal ini juga akan memandu arah .NET Maui.

Saya tidak yakin apa lagi yang bisa saya komentari tentang ini. Tidak banyak yang dapat ditindaklanjuti di sini yang dapat saya lakukan untuk membantu Anda secara khusus sebagai pengguna.

@PureWeen Semangat dari masalah ini adalah XF memiliki terlalu banyak bug dan mengabaikan komunitas. Jadi, kami memperlambat pengembangan baru untuk lebih fokus pada bug yang ada dan membuka PR

Jadi kami mengharapkan tingkat perbaikan bug yang sedikit lebih cepat untuk sementara waktu. Itu bagus tetapi tidak sepenuhnya mengatasi masalah ini. Mengambil XF dari kualitas beta ke stabil adalah tugas yang sangat besar dan tidak ada perbaikan cepat atau strategi tunggal yang akan mencapai ini. Ini akan membutuhkan perubahan besar dalam organisasi, filosofis, dan arsitektural. Saya akan menyarankan:

1. Sederhanakan repositori agar lebih mudah untuk berkontribusi dan meninjau kontribusi. Arsitektur perender baru mungkin membantu jika menggantikan XAML dari inti dan memberikan pendekatan yang lebih aman untuk jenis perender.
2. Prioritaskan perbaikan bug dan kode bersih di atas fitur. Mengingat bahwa budaya Xamarin adalah menambahkan fitur baru sambil mengabaikan bug, cara terbaik adalah dengan melarang sepenuhnya fitur baru hingga ambang batas kualitas terpenuhi untuk fitur yang ada.
3. Izinkan perubahan yang
4. Manfaatkan sepenuhnya .Net untuk mengurangi bug. Simpan barang-barang di dalam sistem tipe sedapat mungkin, dan adopsi C# 8 NRT.
5. Perbaiki kontrol paling dasar terlebih dahulu , lalu kontrol yang tersisa.
6. Singkirkan OS target lama dan editor lama untuk membersihkan repo, merampingkan pengujian, dan membebaskan sumber daya untuk perbaikan bug.
7. Laporkan metrik bug secara publik. Ini akan membantu memfokuskan organisasi pada bug. Letakkan kemajuan pada bug sebagai bagian pertama di blog mana pun tentang pembaruan.
8. Hapus fitur untuk mengurangi ukuran repositori, agar lebih mudah dipelihara.

Pengalaman kami: kami hanya menggunakan tampilan XF dasar karena kami tidak mempercayai hal lain untuk dapat digunakan. Label, Entri, Tombol, Picker, Switch, DatePicker, Slider, StackLayout, ScrollView, ContentView, Grid, ContentPage. Tetapi meskipun demikian, serangga muncul dan bertahan selama berbulan-bulan. Sangat sulit untuk mendapatkan perbaikan ke XF sehingga kami hanya menyalin dan menempelkan penyaji ke dalam kode kami.

Sederhanakan repositori agar lebih mudah untuk berkontribusi dan meninjau kontribusi. Arsitektur perender baru mungkin membantu jika menggantikan XAML dari inti dan memberikan pendekatan yang lebih aman untuk jenis perender.

Itu rencana kami. Saya telah membuat masalah tempat penampung di sini yang dapat Anda ikuti atau tawarkan saran Anda https://github.com/dotnet/maui/issues/147

Prioritaskan perbaikan bug dan kode bersih di atas fitur. Mengingat bahwa budaya Xamarin adalah menambahkan fitur baru sambil mengabaikan bug, cara terbaik adalah dengan melarang sepenuhnya fitur baru hingga ambang batas kualitas terpenuhi untuk fitur yang ada.

Ini sebagian besar rencana kami.

Izinkan perubahan yang melanggar yang memperbaiki bug dan membersihkan kode.
Manfaatkan sepenuhnya .Net untuk mengurangi bug. Simpan barang-barang di dalam sistem tipe sedapat mungkin, dan adopsi C# 8 NRT.

Ini pelan-pelan rencana kita. Namun penting untuk memahami cakupan penuh pengguna yang menggunakan produk kami. Misalnya, setelah kami memecahkan dukungan vs2017, masalah ini muncul di sini yang menerima banyak komentar dari pengguna
https://github.com/xamarin/Xamarin.Forms/issues/7602

Jadi kita tidak bisa melompat begitu saja. Saya akan 100 persen senang untuk mengambil lompatan itu tetapi kita tidak bisa begitu saja menghancurkan orang.

Tapi kami secara konsisten mengambil langkah-langkah untuk bersiap untuk lompatan ini. Misalnya PR di sini
https://github.com/xamarin/Xamarin.Forms/pull/10937

Akan memungkinkan saya untuk menjalankan proses CI internal untuk menguji C# 8 dan fitur beta lainnya sehingga begitu kita dapat mengambil lompatan itu akan menjadi lompatan yang mudah untuk diambil.

Perbaiki kontrol paling dasar terlebih dahulu, lalu kontrol yang tersisa.
Singkirkan OS target lama dan editor lama untuk membersihkan repo, merampingkan pengujian, dan membebaskan sumber daya untuk perbaikan bug.

Itu rencana kita seperti yang sudah saya sebutkan di atas

Laporkan metrik bug secara publik. Ini akan membantu memfokuskan organisasi pada bug. Letakkan kemajuan pada bug sebagai bagian pertama di blog mana pun tentang pembaruan.

Melihat ke dalam ini. @samhouts menjalankan banyak laporan ini untuk kami setiap sprint sehingga kami memiliki perspektif tentang segala hal, tetapi kami akan melihat ke permukaan ini dengan lebih baik kepada komunitas.

Hapus fitur untuk mengurangi ukuran repositori, agar lebih mudah dipelihara.

Ini adalah rencana kami dengan .net MAUI. Sebelum kami meluncurkan rencana .NET MAUI kami, kami menyiapkan daftar area yang dapat kami kurangi agar lebih efektif. Sebagian besar dari ini akan menjadi pekerjaan penyaji.

Hai, selain Masalah yang disebutkan, ada banyak Bug yang terkait dengan bahasa Kanan Ke Kiri. Tampaknya bug ini kurang penting dari sudut pandang Tim Formulir Xamarin (mungkin karena lebih sedikit penggunaan bahasa Kanan Ke Kiri daripada bahasa Inggris atau Kiri Ke lainnya Bahasa kanan), tetapi kurangnya dukungan penuh untuk budaya kanan ke kiri, mengecewakan dan benar-benar menghentikan Pengembang untuk menggunakan XF di Aplikasi internasional / multibahasa / Kanan Ke Kiri.
Terima kasih.

Edisi dua bulan berikutnya: https://github.com/xamarin/Xamarin.Forms/issues/11166
Bug Dibuat 22 Jun.
PR dibuka 25 Juni.
Status Bug 17 Agustus: Masih belum digabung. Mengapa? ;(

@PawKanarek selamat datang di Xamarin. biasanya mereka hanya menggabungkan perbaikan atau Prs yang dibuat oleh tim. itu sebabnya tidak disarankan untuk berkontribusi di Xamarin. Saya pikir mereka mengurangi kapasitas tim. hanya 2-3 orang yang aktif mengerjakan proyek. jika Anda memerlukan perbaikan cepat, buat paket xamarin nuget Anda sendiri.

@EmilAlipiev Tapi kali ini PR (untuk # 11166) dibuka oleh anggota tim Xamarin dan masih belum digabung xD

Jika Anda melihat catatan rilis dan wawasan GitHub kami, kami menggabungkan banyak PR dari komunitas. Bahkan, saya melihat nama Anda di daftar terbaru , @EmilAlipiev :)

Anda dapat melihat bahwa selama sebulan terakhir, 40 pull request baru telah dibuka oleh 18 orang yang berbeda . Permintaan tarik harus diuji dan ditinjau sepenuhnya, dan dengan jumlah yang kami terima, kami harus memprioritaskan masalah pemblokiran dan regresi besar tanpa solusi.

Saya tahu kami tidak selalu sempurna, tetapi kami bekerja untuk meningkatkan setiap hari. Terima kasih atas kesabaran Anda dan tetap bersama kami. Kita bisa melakukan ini bersama!

@hamiddd1980 Anda akan senang mengetahui bahwa kami telah bekerja cukup banyak di RTL selama beberapa bulan terakhir. Saya harap ini meningkatkan pengalaman Anda!

@samhouts Ingatlah bahwa Anda bukan produk akhir Xamarin. Kami tidak hanya membutuhkan kesabaran, tetapi juga banyak sumber daya manusia dan uang. Setiap bug yang terbuka & terverifikasi di github harus segera diperbaiki karena menimbulkan efek bola salju dalam bentuk hutang teknis, kemarahan, dan ketegangan yang tidak perlu dengan klien kami.

Harap perbaiki lebih banyak bug, jangan tambahkan lebih banyak fitur. Stabilitas atas fungsionalitas. Anda masih memiliki 1.590 bug terverifikasi https://github.com/xamarin/Xamarin.Forms/issues?q=is%3Aopen+is%3Aissue+-label%3As%2Funverified+label%3A%22t%2Fbug+%3Abug%3A% 22

@samhouts terima kasih atas balasan Anda. 1-2 penggabungan per hari sangat kurang. Saya bekerja pada alat lintas platform lainnya dan mereka memiliki 15 penggabungan per hari 455 penggabungan bulan lalu. Saya masih lebih menyukai Xamarin sebagai alat dan saya selalu ingin berkontribusi tetapi penggabungan saya memakan waktu lebih dari 2 bulan dan saya harus membuat penggabungan ini 3 kali dengan rebased dari cabang yang berbeda.
Selain itu ada masalah prioritas di pihak Anda. Orang-orang putus asa mencari perbaikan untuk alat inti seperti bug seperti Device.Idiom.. atau CollectionView bug dll.
Hari ini ada kemajuan besar memang 8 total penggabungan sejauh ini. Tapi sejujurnya di bawah gabungan, lebih sedikit orang yang tertarik dengan tampilan gesek, kuas gradien atau tema, dll. Ketika ada PR kritis seperti itu dalam antrian selama berbulan-bulan. Ini adalah frustrasi terbesar yang saya yakini

Setiap bug terbuka & terverifikasi di github harus diperbaiki secepatnya

Ini jelas tidak realistis; bahkan jika Microsoft secara dramatis meningkatkan ukuran tim Xamarin.Forms.
Bekerja lebih cerdas, tidak lebih keras, kata mereka (dalam hal ini, ini berarti mengharuskan PR untuk memasukkan pengujian regresi untuk memastikan bug tidak muncul kembali; namun, seperti apa pun, ini juga merupakan trade-off, karena ulasan kontribusi PR akan menjadi lebih lama dan lebih sulit).

Tolong perbaiki lebih banyak bug, jangan tambahkan lebih banyak fitur

Ini juga pendapat yang saya bagikan. Namun, sebenarnya, rencana transisi MAUI<>Xamarin.Forms sudah mencakup ini: Xamarin.Forms akan bertransisi ke mode perbaikan bug saja, sementara fitur baru hanya akan mendarat di Maui.

(dalam hal ini, ini berarti mengharuskan PR untuk memasukkan pengujian regresi untuk memastikan bug tidak muncul kembali; namun, seperti apa pun, ini juga merupakan trade-off, karena ulasan PR yang dikontribusikan akan semakin lama dan sulit).

Sangat. Ini adalah tradeoff yang telah kami perjuangkan juga. Kami memiliki ribuan (!) pengujian yang otomatis, dan kami menjalankannya di beberapa perangkat. Masalahnya adalah dibutuhkan waktu berjam-jam (saat ini sekitar 4 jam per proses per perangkat) untuk menyelesaikannya, dan sayangnya, kadang-kadang, agak terkelupas karena sejumlah alasan. Misalnya, saya baru saja melakukan ping ke kontributor kemarin tentang tes yang saya pikir gagal secara sah, hanya untuk menyadari bahwa itu sebenarnya gagal karena Chrome meminta kami untuk menerima persyaratan layanan baru. 🤦

Hal ini menyebabkan banyak penundaan, dan ini berarti bahwa PR terkadang membutuhkan waktu berhari-hari hanya untuk lulus ujian. Itu ada pada kita, dan itu adalah masalah yang harus kita pecahkan.

Untungnya, kami _are_ mengerjakan masalah ini. Kami sedang mengembangkan metode baru untuk menguji perender platform yang lebih mirip pengujian unit daripada mengotomatiskan UI, yang jauh lebih andal dan lebih cepat.

Sejauh menambahkan fitur baru vs memperbaiki bug...seperti yang dikatakan @knocte , rencana transisi dirancang dengan mempertimbangkan hal ini. Tujuan kami adalah agar .NET MAUI menjadi ramping, cepat, dan dapat diandalkan. Sebagai bagian dari ini, kami mengevaluasi fitur apa yang sebenarnya termasuk dalam proyek inti dan fitur apa yang lebih cocok untuk Toolkit Komunitas baru--yang masih memiliki dukungan Microsoft, tetapi sebagian besar didukung oleh komunitas.

Perlu diketahui bahwa kami selalu memperhatikan Anda dan pelanggan Anda saat kami melakukan perubahan, dan kami mendengarkan masukan Anda.