Xamarin.forms: Bagaimana dengan hal-hal di mana-mana untuk Xamarin.Forms?

FWIW @juepiezhongren Saya sedang menyelidiki Ooui di sini:
https://github.com/praeclarum/Ooui

Jika ada cara untuk mengemasnya dengan Trigger.io, Anda akan dapat menjalankan .NET di keempat grup makanan utama iOS, Droid, Windows, dan web.

Ini masih dalam keadaan demo, tapi menarik minat saya. 👍

OP sulit dimengerti tetapi saya menyimpulkan bahwa "ubi" berarti "tampilan Xamarin.Forms yang dirender dengan cara yang tidak bergantung pada platform menggunakan SkiaSharp atau yang serupa". Dalam hal ini wadah "ubi" tidak dapat berisi hal-hal non-ubi. Saya berasumsi OP adalah permintaan untuk lebih banyak orang untuk membuat tampilan "ubi"? Jika tampilan "ubi" dibuat, saya yakin sebagian besar dari kita tidak akan keberatan menggunakannya.

Bagian dari masalah di sini adalah bahwa akan diperlukan perubahan dalam cara kita melihat aplikasi "asli", Atau lebih tepatnya bagaimana aplikasi tersebut dirender. HTML5 benar-benar contoh terbaik di sini. Anda dapat melihat halaman HTML5 di perangkat apa pun dan pada dasarnya akan terlihat sama, apa pun perangkatnya . IMO ini adalah bagaimana semua aplikasi harus dirender. Jika Anda menginginkan rendering atau interaksi "khusus platform", ini harus menjadi masalah gaya dan/atau templating (sesuatu yang mudah dilakukan dengan WPF ). Artinya, pengembang harus bisa menghadirkan UX berbasis iOS di perangkat Droid dan sebaliknya cukup dengan menerapkan tema.

Untuk semua maksud dan tujuan, HTML5 adalah mekanisme rendering yang ada di mana-mana, tetapi telah begitu mendarah daging dengan JavaScript sehingga memperkenalkan TCO yang mahal saat dipasangkan dengan .NET. Apa yang Ooui perkenalkan adalah prospek memanfaatkan HTML5/CSS sebagai mekanisme rendering, sementara masih secara eksklusif menggunakan .NET untuk semua pengembangan lainnya, sehingga mempertahankan pengetahuan, memanfaatkan investasi yang ada, dan karenanya _mengurangi biaya pengembangan secara keseluruhan_. Pengembang kemudian dibiarkan dengan SATU basis kode untuk presentasi mereka dan infrastruktur pendukungnya, bekerja di iOS, Droid, Windows, dan Web. Sesuatu yang telah diminta oleh banyak pengembang .NET selama beberapa tahun sekarang .

Kelemahannya adalah pengembang .NET harus berurusan dengan CSS, tetapi pada titik ini setelah menunggu begitu lama untuk solusi yang benar-benar ada di mana-mana, ini adalah konsesi yang akan kami buat. Setidaknya, saya akan melakukannya. 😛

Utas suara pengguna adalah panggilan untuk sesuatu seperti Xamarin.Forms. Itu diposting pada 2015 sebelum Microsoft membeli Xamarin. Di luar persyaratannya, Xamarin.Forms telah dirilis pada 1) Windows 10 4) Droid 5) iOS , dalam pratinjau pada 3) *nix (Unix/Linux) 6) Macintosh, telah dimulai dengan 2) Windows Legacy, dan tidak 't do 7) HTML5 yang terlalu berbeda. Dan sebenarnya Windows 10, Droid, iOS, Legacy windows, dan Mac mencakup 99,5% perangkat klien. Karena Xamarin.Forms ada dan melakukan semua ini sekarang, tidak perlu solusi besar lainnya.

Satu-satunya hal yang diperlukan adalah:

• Gabungkan Xamarin.Forms dengan WPF dengan mempercepat Xamarin.WPF
• Advertisement Xamarin.Forms: ternyata masih ada beberapa developer .Net yang belum mengetahuinya.

Yang Anda inginkan adalah sesuatu yang berbeda: rendering lintas platform yang identik. Saya dapat memahami kebutuhan ini. Proyek itu, untuk Xamarin.Forms, dapat dibagi menjadi:

• Dokumentasikan perbedaan platform antara kontrol Xamarin.Forms yang berbeda. Saya pikir banyak pengembang akan menganggap ini menarik, bahkan jika mereka tidak membutuhkan rendering identik yang tepat.
• Siapa pun yang menganggap kontrol tertentu terlihat terlalu berbeda di seluruh platform dapat membuat kontrol yang dirender secara identik.

Terima kasih telah meluangkan waktu untuk menyampaikan pandangan Anda, @charlesroddie. Saya sangat menghargai mereka.

dan tidak melakukan 7) HTML5 yang terlalu berbeda

Sayangnya, itulah pola pikir/sikap yang kita lawan di sini. Web hanyalah lingkungan hosting, persis seperti platform asli yang menghosting lingkungan untuk aplikasi. Dengan melihat web sebagai "berbeda" Anda jatuh ke dalam perangkap yang sangat mahal karena harus mengembangkan dan memelihara dua basis kode yang terpisah .

tidak perlu solusi besar lainnya.

Idenya di sini bukanlah solusi besar lainnya, tetapi solusi yang lebih sederhana. Jika Anda meluangkan waktu untuk membaca komentar UserVoice itu (sangat hidup btw ), tidak banyak penggemar Xamarin.Forms di sana. Saya sendiri mendukung proyek (dan semua hal Xamarin!), Tetapi pada akhirnya Anda mendukung n-jumlah tumpukan presentasi, masing-masing dengan keistimewaan dan pertimbangan mereka sendiri (yang seperti yang kita semua tahu telah menyebabkan kualitas yang sangat buruk yang baru saja mendapatkan pegangan pada dirinya sendiri). Plus, ada perender khusus yang merepotkan jika Anda memerlukan perenderan khusus per platform. Bandingkan dengan paradigma di mana Anda hanya mempertahankan satu teknologi presentasi (HTML5) dan platform hanya merender HTML5 yang telah mereka dukung dan mampu melakukannya selama bertahun-tahun sekarang. Render khusus platform diterapkan hanya dengan menerapkan gaya tertentu.

Saya tidak mengatakan itu sempurna, tetapi terasa jauh lebih ringan dan lebih mudah dirawat dalam jangka panjang -- belum lagi LEBIH MURAH, LOL!

Yang mengatakan, pertimbangkan bahwa ruang desain HTML5 sarat dengan bakat berpengalaman, terutama yang berkaitan dengan CSS. Dari perspektif bisnis, ini mengurangi TCO karena Anda tidak hanya peduli dengan satu penawaran teknologi presentasi (bukan n+), tetapi ada banyak sumber daya yang dapat bekerja di ruang ini untuk memberikan pekerjaan berkualitas di sekitarnya. misalnya jika Anda memiliki omset, akan lebih mudah untuk menemukan sumber daya yang mengetahui satu teknologi presentasi (khusus -- kualitas lebih tinggi), vs. menemukan sumber daya yang mengetahui n+ (umum -- kualitas lebih rendah).

Saya tahu sudah mengakar di komunitas kami untuk menganggap web sebagai "berbeda" tetapi tampaknya semakin "berbeda" mampu mengubah semua yang kami ketahui tentang presentasi di ruang .NET.
Itulah kesan saya tentang apa yang terjadi, setidaknya. Saya telah diketahui salah, dari waktu ke waktu, namun. 😉

Saya tidak memiliki keahlian dalam teknologi web dan ketika saya mengatakan terlalu berbeda maksud saya bahwa teknologi saat ini tampak jauh dari menjembatani kesenjangan antara struktur aplikasi asli dan web. Xamarin.Web akan menjadi ide yang bagus tetapi sulit untuk diterapkan, meskipun mungkin ada bukti konsep yang sudah didasarkan pada Ooui. Dalam konteks Xamarin.Forms ini tentu saja berarti lebih sedikit html, tidak lebih.

Itu aha di sini, memang. Saya tidak berpikir itu sulit sama sekali, mengingat. Ooui tidak (belum) mendukung pengikatan data, atau konstruksi Xaml apa pun, tetapi itu harus cukup mudah untuk diterapkan. Juga, tolong jangan salah paham di sini karena saya sama sekali bukan penggemar HTML, sebenarnya Xaml adalah persyaratan yang tercantum dalam UserVoice yang disebutkan di atas. Tapi sekarang hampir 3 tahun kemudian saya bersedia mengakui ini jika itu berarti satu basis kode untuk jangkauan pasar 100%. Selain itu, saya tidak yakin apakah Anda melihatnya, tetapi Ooui pada dasarnya adalah model pembungkus/adaptor di sekitar elemen HTML5. Jadi, Anda akan bekerja dengan objek .NET dan tidak harus berurusan dengan tag div dan yuck . Itulah yang menarik minat saya di sini, antara lain.

@Mike-EEE Avalonia benar-benar eksperimen yang bagus

Saya pikir hal yang paling produktif untuk pengembang Xamarin Forms adalah menghidupkan kembali https://github.com/chrfalch/NControl dengan porting ke SkiaSharp. Itu akan memungkinkan kontrol pembuatan yang mudah yang hanya memerlukan jenis interaksi tertentu, dan kontrol ini akan berperilaku lintas platform yang identik, dan segera mendukung semua platform yang didukung SkiaSharp.

Flutter datang seperti longsoran salju. Banyak pekerjaan telah dilakukan untuk membuat kerangka kerja itu dan dokumentasi yang sesuai. Tapi untungnya, ini open source!

Mesin flutter adalah c++ dan Dart - hampir menjadi bagian dari c# - harus "dapat diubah" ke C# dan Xamarin.

Saya pikir cara paling produktif untuk naik kereta ski adalah dengan membuat Xamarin merangkul Flutter dan membantu Google memajukannya. Xamarin dapat menawarkan integrasi platform yang lebih baik.

Ya, Ini tidak akan menjadi upaya Formulir (mis. Redux menjadi pilihan yang lebih jelas daripada MVVM), tetapi itu akan sangat keren :)

Ayo MS. Rangkul dan rentangkan seperti kemarin. Anda harus tetap melakukannya jika Fuchia menjadi sesuatu.

Oh Boy. Jadi setelah flex, CSS, dan hal-hal gila lainnya yang bahkan sebenarnya tidak berfungsi sepenuhnya, sekarang Flutter? Xamarin Forms, Jack of all trades, master of none.
Bagaimana kalau pertama kali membuat Xamarin Forms menjadi kerangka kerja kelas satu yang benar-benar matang dan stabil? Tapi tunggu, saya pikir itu sudah lama tertunda ...

@timahrentlov dapatkah Anda menunjukkan kepada saya perbandingan redux vs mvvm, di mana saya ingin tahu

@juepiezhongren Saya belum pernah menemukan perbandingan seperti itu untuk flutter.

@timahrentlov maksud saya untuk membandingkan xamarin.forms vs reaksi asli mengingat mvvm vs redux

@Mike-EEE apakah Anda memperhatikan badai keluar dari blazer dan ooui-wasm frank?

@juepiezhongren memang... semuanya mulai memanas! 🎉

@Mike-EEE mempertimbangkan ubis untuk wasm, skiashharp bukan pilihan yang baik.

@samhouts apa artinya t-enhencement?

Sejujurnya @juepiezhongren , saya pikir satu-satunya opsi nyata jangka panjang adalah HTML5/CSS. Itulah mengapa saya semua tentang pendekatan WebSocket Bridge (Ooui). Ini lebih ringan dan lebih sedikit overhead daripada WASM. CSS menyebalkan tetapi dengan sedikit minyak siku saya pikir kami sebagai pengembang dapat membuatnya bekerja. Bagaimanapun, saya merasa kita sekitar 12-18 bulan lagi dari sesuatu yang benar-benar layak, yang luar biasa. Ooui dan Blazor hanyalah awal/perintis (trail Blazors? hah hah).

Juga, ketika saya melakukannya, saya harus memuji MSFT dan @stevesanderson karena eksperimental dan inovatif dengan inisiatif Blazor mereka. Kami benar-benar belum melihat sesuatu seperti itu dalam beberapa saat. Sangat membesarkan hati dan saya berharap pendekatan dan proyek semacam ini berlanjut di luar MSFT. 👍

@Mike-EEE ya, ini adalah CANVAS di html5, seperti echarts.js yang disponsori baidu, yang dirender cukup bagus. Jadi, mesin render harus dipisahkan.

HTML5 murni lebih cepat, @juepiezhongren. Skenario yang paling ideal adalah menggunakan kontrol DOM HTML5, karena rendering sudah terjadi di kanvas NATIVE. Jika tidak, Anda kemudian merender pada Kanvas HTML5 dan memperbaruinya melalui JavaScript yang sangat lambat dengan perbandingan dan sumber daya yang intensif. Tentu saja, Kanvas HTML5 masih dapat digunakan untuk kontrol non-asli yang kompleks (seperti pembuatan bagan, dll), tetapi tidak boleh digunakan sebagai permukaan rendering, IMO.

apa itu HTML5 murni?@Mike-EEE sesuatu yang bukan js?

Benar, @juepiezhongren ... memanfaatkan semua kontrol "asli" (harus berhati-hati dengan kata itu, LOL) dari HTML5 daripada membuat yang baru untuk dirender melalui kontrol HTML5 canvas (sesuatu yang Anda akan melihat di Unity atau JSIL ).

Tentu saja, ini tergantung pada konteks dan aplikasi yang Anda bangun. Dalam semua percakapan saya, saya mengasumsikan/mempertimbangkan bisnis/LOB secara default, jadi menggunakan HTML5 "murni" akan lebih disukai. Jika Anda melakukan skenario permainan/grafis yang intensif maka WASM adalah pilihan pertama Anda, diikuti dengan kontrol canvas .

Saya pikir HTML5 sebaiknya ditinggalkan demi XF daripada SkiaSharp. ooui bagus, tetapi selalu akan menderita karena harus mengonversi kontrol XF ke HTML. Langsung saja ke kanvas adalah apa yang saya katakan. Aksesibilitas/SEO akan menjadi masalah sekarang tetapi tidak melihat mengapa itu tidak dapat diatasi dengan cara yang sama seperti winforms menggunakan GDI dapat diakses.

Kan @yowl ... tergantung skenarionya

SkiaSharp tidak berfungsi di web, jadi Anda masih perlu memiliki aplikasi lain untuk menjalankannya di sana. Kecuali Anda menggunakan WASM, tentu saja. Tapi itu unduhan yang lebih besar. Semuanya berjalan HTML5/web/ringan hari ini. Aplikasi yang memuat lebih cepat dan lebih cepat karena itu akan menjadi aplikasi yang mendapatkan pengguna dan oleh karena itu daya tarik pasar. Kami melihat ini dengan PWA dan teknologi web secara keseluruhan.

Asli/toko menjadi ketinggalan zaman karena web menjadi semakin seperti mereka dan mengambil alih kekuatan mereka. Dan itu melakukannya tanpa semua BS terpusat/otoritatif/smothering/censoring/store/registrations/guidelines, untuk boot. Teknologi bergerak lebih mundur ke arah cara berbisnis yang terdesentralisasi/bebas, seperti yang semula dirancang, dimaksudkan, dan dimaksudkan.

Meskipun demikian, saya setuju dengan Anda bahwa pada akhirnya akan ada dua skenario di sini: HTML5 untuk sebagian besar aplikasi (yang memerlukan aksesibilitas/SEO ), dan kemudian WASM untuk khusus/grafis-intensif/permainan/dll. Penawaran teknologi presentasi yang ideal akan memenuhi kedua kubu dengan mulus sehingga pengembang tidak perlu mengetahui atau berurusan dengan perbedaan (yaitu sakit kepala) dari salah satu/keduanya.

Anda mengatakan SkiaSharp tidak berfungsi di web dan sejauh yang saya tahu tidak ada yang membuatnya untuk wasm, tetapi Skia melakukannya, saya membayangkan itu mungkin. Atau membangun XF dengan backend Skia, sampai pada hal yang sama. Orang-orang mono memiliki sesuatu di lengan baju mereka, saya yakin, cari sesuatu di Build in May.

Ya, saya telah menunggu _years_ sekarang untuk //build menunjukkan sesuatu yang menarik, @yowl. Bahkan Hubungkan(); acara telah direduksi menjadi membual tentang menjalankan .NET di lemari es dan peralatan lain (nilai sangat rendah) daripada di halaman web (nilai sangat tinggi).

Saya mengambil pendekatan yang lebih "Saya akan percaya ketika saya melihatnya" akhir-akhir ini. Untuk sirkus tahun ini, saya tidak mengharapkan untuk mendengar sesuatu yang signifikan selain Aplikasi Web Progresif, dan bagaimana MSFT telah berhasil "mengintegrasikan" mereka ke dalam ekosistem kami sementara membuat bekerja dengan mereka sebagai pengembang .NET semahal mungkin. Sepotong kecil optimisme ada untuk Anda. 🎉

Skia + Canvas akan bekerja dengan http://webassembly.org. Flutter akan memukul itu di masa depan yaitu "bawa UI Anda sendiri". http://webassembly.org/demo/Tanks/ ini mungkin juga merupakan aplikasi bisnis Skia.

@timahrentlov skia+kanvas? 10M diunduh, itu sangat besar.

saya hanya ingin tahu, bagaimana dengan xamarin.flutter?

Saya setuju dengan @juepiezhongren , ukuran

Diskusi yang menarik. Sementara kontrol dasar seperti ListView masih memiliki masalah di iOS dan Android. Pratinjau XAML juga tidak sepenuhnya berfungsi. Masih ada kontrol dasar yang belum diterapkan. Performa masih tertinggal. Senang berbicara dan bermimpi tetapi keadaan XF tidak benar-benar berada di tempat yang seharusnya meskipun sudah hampir 3 tahun.

Masalah dengan XF adalah seperti membangun rumah di atas mesin pengumpul. Ini memiliki jejak platform UI raksasa dan retakan dan celah akan terbentuk di bawahnya.

Memperbaikinya, dan menambahkan fitur-fitur baru, adalah perjuangan berat yang terus-menerus yang hanya akan memburuk karena lebih banyak platform ditambahkan. Mac OS x, OOUI/Web, Tizen, apa pun. Ini akan menggiling berhenti. Maksudku, hampir sudah. Ini adalah pendekatan DOA. Dan alat seperti flutter akan berputar di sekitar XF.

XF perlu membawa UI-nya sendiri dan hanya mengintegrasikan UI platform tertentu yang benar-benar diperlukan. Seperti peta, tampilan kamera, dll. Lagi pula, Xamarin harus segera mengimplementasikan (mesin flutter open source!), jika ingin mendukung Fuchia atau apa pun namanya.

Saya benar-benar tidak peduli tentang Flutter atau Tizen atau hal lainnya. Yang penting dalam hal pengembangan seluler adalah iOS dan Android. Kemudian mungkin UWP. Saya tidak peduli tentang Mac OS X dan WPF, terlepas dari apa yang orang katakan. Mencoba menyatukan seluler dan desktop ketika Anda bahkan tidak dapat menangani seluler (iOS dan Android) benar menyedihkan.
Xamarin Forms benar-benar contoh terbaik dari Jack of all trades, master of none. Ini adalah proyek OSS yang dimulai sebagai proyek akhir pekan. Satu-satunya pekerjaan yang signifikan adalah pada kompilasi XAML.
Selain itu, Xamarin cukup banyak menunggu pengembang di alam liar untuk melanjutkan pekerjaannya. Masih belum ada komitmen serius untuk membuat kerangka kerja sebagaimana mestinya.
Membangun konferensi akan datang dan mereka akan mengumumkan dengan lonceng dan peluit betapa hebatnya Xamarin Forms 3.0. Pada kenyataannya, masih akan ada bug dan batasan yang sama.

kita membutuhkan keduanya asli dan ubi. xf cukup bagus, karena menggunakan semua api asli dengan c#. ubis juga harus penting.

Adakah yang bisa memberikan contoh proyek/kerangka/alat lain yang memiliki banyak arahan seperti Formulir Xamarin? Yang saya maksud dengan "petunjuk" adalah Android, iOS, UWP, Mac OS X, CSS, Flexbox, Tizen, WPF. Apakah saya melewatkan sesuatu? web/HTML? Gila...
Ini hampir seperti seseorang terus-menerus mengatakan "apakah ada hal lain yang bisa kita mainkan hari ini"? Ini seperti seseorang yang terus-menerus bereksperimen. Tidak ada yang salah dengan bereksperimen, tetapi aneh untuk membicarakan hal-hal yang sedang Anda kerjakan seolah-olah itu solid, padahal sebenarnya itu semua adalah eksperimen.

Kalau saja XF difokuskan hanya pada iOS dan android..
Jika saja MS mulai menggunakan XF untuk aplikasinya sendiri..
Andai saja MS menerapkan lebih banyak sumber daya dan penguji manusia..
Andai saja Xamarin tidak begitu ingin menjadikan acara teknologi sebagai fokus rilis utama mereka..
jika hanya..

Tampaknya selama beberapa tahun terakhir tidak ada orang dewasa di rumah. Siapa yang berada di belakang kemudi, merencanakan jalannya? Jurusan apa?

Rilis memiliki kualitas teknologi-demo, stabil tentu saja tidak Stabil, dan hal-hal telah dirilis bukan karena cocok dengan strategi umum dan dengan demikian harus - tetapi karena teknisi mendapat ide dan mereka bisa. Dan selain menghasilkan konten ke keynotes, XF belum sukses seperti yang kita semua harapkan. Bahwa seharusnya sekarang.

Saya masih berharap bahwa XF dapat direnggut dari rahang kematian. Saya masih berharap bahwa orang dewasa akan mengambil kemudi. Ini di akhir permainan itu akan membutuhkan upaya yang sangat besar. Setidaknya jika MS ingin berhasil menggunakan paradigma UI XF saat ini.

MS bisa membuatnya lebih mudah pada diri mereka sendiri dan menjadi lebih seperti, well, flutter. _XF perlu membawa UI sendiri!_

Saat ini, sisi panahnya benar-benar terlihat menggoda bagiku!

Microsoft tidak peduli dengan Xamarin Forms... Microsoft hanya menggunakan perangkat seluler Xamarin untuk mencoba menginjili dan menjaga tingkat hype .NET tetap hidup... Microsoft masih hidup di masa lalu, di "pengembang, pengembang, pengembang "zaman heboh. Yang tidak buruk, yang buruk adalah bahwa itu lebih hype daripada kualitas sekarang.
Kenyataannya adalah sebagian besar pengembang menggunakan MacBook dan tidak peduli dengan Windows dan .NET untuk waktu yang lama sekarang. Microsoft gagal di hampir semua tempat di ruang seluler dan perangkat keras. Mereka berjuang untuk menjaga hype tetap hidup tetapi itu sangat sulit. Di tingkat manajemen, Microsoft gagal keras. Jangan salah paham, ada banyak orang teknis yang sangat hebat di Microsoft, saya berbicara tentang orang-orang tingkat rendah/teknis.

Jika saja MS mulai menggunakan XF untuk aplikasinya sendiri..

Bagaimana mereka bisa? Kinerja tidak berada di tempat yang seharusnya.

Reality is most of developers are on MacBooks apakah Anda memiliki sesuatu untuk mendukungnya?

apakah Anda memiliki sesuatu untuk mendukung itu?

Tidak, tetapi jika Anda melihat ke teknologi paling populer, saya dapat meyakinkan Anda bahwa sebagian besar pengembang itu ada di MacBook

@opcodewriter apa

@encrypt0r Ya, abaikan saya. Semuanya bagus. 👍

mempertimbangkan vs popularitas，bagaimana mungkin sebagian besar pembuat kode menggunakan mac？

Agak terlambat ke pesta di sini, tetapi bahkan Xamarin ada di teknologi web sekarang:
http://www.davidortinau.com/blog/styling_xamarin_forms_with_css

Tampaknya semacam Frankenstein untuk menggabungkan CSS ke teknologi berbasis Xaml, tapi hei. Juga, CSS yang digunakan di sini lebih merupakan DSL untuk gaya kontrol Xamarin yang berbunyi seperti CSS. Bagaimanapun, intinya adalah KETIKA DIGUNAKAN DENGAN BENAR itu adalah standar matang yang dapat digunakan oleh perangkat di mana pun.

Beberapa diskusi tambahan seputar ini di sini:
https://twitter.com/migueldeicaza/status/972525236301238272

@Mike-EEE, pernahkah Anda melihat masalah draw dan materialShell?

Saya belum @juepiezhongren ... apakah ini mengacu pada HTML atau Formulir?

@Mike-EEE
https://github.com/xamarin/Xamarin.Forms/issues/2452
https://github.com/xamarin/Xamarin.Forms/issues/2415

Itu luar biasa

Ya tidak buruk @juepiezhongren tetapi tidak sepadan dengan waktu/uang/usaha/sumber daya jika tidak ada di mana-mana sejak awal. :)

Material Shell memang berhubungan dengan masalah ini, tetapi kontrol asli masih bergaya dan bukan kontrol di mana-mana yang sebenarnya.

@juepiezhongren
Saya suka konsepnya, meskipun bukan cara Anda meletakkannya.

Dalam mimpi saya, kerangka seperti Avalonia adalah pilihan yang sempurna. Tampilan dan nuansa asli tidak terlalu menjadi perhatian saya; Saya lebih suka kontrol dirender sama di mana-mana, dengan opsi untuk menambahkan tema tampilan dan nuansa asli ke setiap platform bagi mereka yang membutuhkannya.
Segera setelah itu mendapat dukungan wasm, Silverlight kembali, dan hanya akan ada yang tertinggal untuk Layanan RIA 😁

@MisterJimson sebenarnya idenya adalah bahwa material shell secara inheren membawa kontrol di mana-mana

@jassmith bagaimana tepatnya? Rendering mentah atau gaya kontrol asli? Gaya kontrol asli akan selalu memiliki beberapa inkonsistensi, meskipun minimal.

@MisterJimson shell didasarkan pada skia atau ios CoreDraw api, saya pikir
@jassmith jadi, akan ada fasihShell atau cupertinoShell?

@MisterJimson sebagai @juepiezhongren ya idenya adalah menggambar sepenuhnya dari awal. Itu tidak harus menggambar pada platform target tetapi Anda pasti bisa memintanya. Tujuannya adalah untuk membawa Material (setidaknya dengan MaterialShell) ke mana-mana.

@juepiezhongren Idealnya ya. Masalahnya saat ini adalah FluentShell dan CupertinoShell akan sangat bergantung pada keburaman langsung. Android itu indah dan semuanya tapi entah bagaimana mereka berhasil menghindari tampilan blur langsung yang efisien. Ini menjadikan Material sebagai target alami pertama sementara kami mencari tahu apa yang harus dilakukan untuk mengatasi masalah itu.

Untuk lebih jelasnya, Shell tidak menggambar, MaterialShell melakukannya.

Pernahkah kalian melihat ini- https://github.com/SteveSandersonMS/BlazorElectronExperiment.Sample ?
Hanya untuk desktop, bukan platform seluler.

Sisi server

@juepiezhongren memikirkan tentang
https://github.com/xamarin/Xamarin.Forms/issues/4435

Tampaknya mirip dengan apa yang Anda usulkan di sini kecuali alih-alih menjadi tag, itu adalah atribut yang membawa ke mana-mana dan jika seseorang cenderung, mereka dapat membuat Visual = "Skia"

@PureWeen saya tidak memperlakukan visual="skia" saran yang bagus, hanya karena kontrol xf saat ini kekurangan dua properti untuk penyesuaian pribadi, mis. sikat, kontrolTemplat, dll.

atau, buat saja kontrol saat ini api penuh diimplementasikan, banyak properti tidak valid saat mode pembungkus dan valid saat mode skia

Kami telah membuat banyak kemajuan di Visual dalam beberapa bulan terakhir. Kami senang mendapatkan tanggapan Anda tentang hal itu. Kami mengundang Anda untuk mencoba Tantangan Visual dan beri tahu kami jika ini memecahkan masalah Anda yang membuat Anda membuat proposal ini. Terima kasih! https://github.com/davidortinau/VisualChallenge

@samhouts visual bagus, tapi kami perlu menggambar, kami membutuhkan solusi sempurna piksel

Jadi di mana permintaan peningkatan ini jatuh ketika dihadapkan dengan visual dan spesifikasi gambar https://github.com/xamarin/Xamarin.Forms/issues/2452

hanya karena kontrol xf saat ini kekurangan dua properti untuk penyesuaian pribadi, mis. sikat, kontrolTemplat, dll.

Ini cukup mudah diatasi melalui properti terlampir yang kami cari tahu cara terbaik untuk mencapainya di sini

https://github.com/xamarin/Xamarin.Forms/issues/5005

@samhouts

Kami telah membuat banyak kemajuan di Visual dalam beberapa bulan terakhir.

Oleh kami, Windows dan desktop adalah yang pertama. Visual bahkan tidak mendukung UWP, bahkan tidak akan mencobanya.

Saya pikir kita bisa menutup ini sekarang karena kita membuat kemajuan di #2452. Terima kasih!