Saya berada di tingkat frustrasi Anda beberapa tahun yang lalu ketika saya pertama kali mulai mem-porting aplikasi WPF. Jadi saya pasti mengerti perasaan Anda. Ada beberapa kemajuan sejak saat itu dan seperti yang Anda katakan, tim WinUI benar-benar berusaha keras.

Dari sudut pandang saya ada masalah desain dasar kita tidak bisa bekerja di sekitar: WinRT secara teknis cacat karena harus Interop langsung dengan C ++ dan JavaScript ( di sini adalah contoh, dan lain ). Itu benar-benar tidak cocok dengan banyak konsep tingkat tinggi seperti obat generik. Tentu saja ada satu keuntungan besar dengan arsitektur ini juga: Semua Windows sekarang dapat berbagi WinRT API yang sama.

WinRT juga dilakukan oleh tim Windows di bawah Sinofsky Saya percaya yang berarti, ya, mereka hidup di dunia mereka sendiri dan tidak memiliki pengalaman bekerja dengan ekosistem pengembang pengguna akhir yang ada. Kami berakhir dengan API 'penyebut paling umum' yang tidak disukai oleh pengembang asli dan terkelola. Ini pada dasarnya adalah salah satu alasan utama Windows Phone mati -- pengembang tidak dapat mengembangkan/memindahkan aplikasi dengan mudah. Tanpa Apps tidak ada pelanggan. Microsoft memang mempelajari pelajaran ini.

Jadi, kami telah kehilangan beberapa keuntungan dari kode terkelola yang telah kami terbiasa selama bertahun-tahun. Ini jelas masih tampak seperti langkah mundur dari WPF -- saya selalu menemukan bug dan fitur yang tidak lengkap. Saya pikir #1830 tidak akan pernah terjadi di masa WPF. Kami masih harus bergerak maju entah bagaimana.

WinUI 3.0 jelas merupakan langkah ke arah yang benar untuk mencoba memperbaiki ini setidaknya di frontend. Padahal, saya lebih suka Microsoft menerapkan proses pengembangan yang lebih kuat dan lebih banyak pengujian sebelum merilis kontrol baru... Saya tahu pengembangan sekarang mendorong perubahan, perbaiki nanti. Meskipun itu mungkin berfungsi untuk aplikasi, itu bukan pola yang baik untuk platform di mana setelah semuanya diatur, sangat sulit untuk mengubahnya nanti. (TreeView, NumberBox, dll ... memiliki begitu banyak masalah pada rilis pertama yang tidak akan pernah keluar dari pintu, apalagi tahap perencanaan, 15 tahun yang lalu).

Sangat menyedihkan bagi saya untuk melihat apa yang dulunya merupakan platform UI paling kuat WPF berevolusi menjadi ini. Tapi Microsoft sekarang, perlahan tapi pasti, mendengarkan umpan balik dan memperbaiki berbagai hal. Dapat dipahami bahwa ada lebih banyak pekerjaan yang harus dilakukan.

Apakah menurut Anda pengguna akan dengan senang hati melakukan hal di atas? Tidak, mereka tidak akan melakukannya - kenyataannya, 79,8% tidak melakukannya (data AppCenter saya mendukungnya). Meninggalkan saya dengan pengguna yang tidak menggunakan aplikasi saya, atau hanya membuat aplikasi saya terlihat di bawah standar aplikasi asli lainnya.

Mungkin Anda tidak mempertimbangkan fakta bahwa pengguna Anda benar-benar berhenti untuk berpikir: "tunggu, apakah saya benar-benar ingin memberikan akses aplikasi ini ke seluruh drive saya?" Itu adalah peringatan lampu merah untuk orang yang tidak terbiasa dengan aplikasi/pengembang/perusahaan.

Anda menyalahkan proses yang harus dilalui pengguna untuk memberikan akses aplikasi Anda ke seluruh drive mereka karena tingkat retensi yang rendah. Mungkin Anda harus mempertimbangkan kembali "kebutuhan" Anda untuk broadFileSystemAccess di tempat pertama, dan alih-alih hanya meminta pengguna secara manual memilih folder yang mereka rasa nyaman untuk Anda akses.

FYI, jika saya ingin mencoba aplikasi dan setelah instalasi itu seperti "hei, beri saya izin untuk mengakses semuanya, di mana saja", saya akan menjalankan juga.

Saat Anda meminta broadSystemAccess, aplikasi Anda, secara default, tidak memiliki akses itu.

Jelas... Anda hanya membuat permintaan, pengguna Anda sebenarnya harus memberi Anda akses jika mereka merasa nyaman melakukannya.

Selain itu, berdasarkan judul yang tidak sopan saja yang melanggar Kode Etik Sumber Terbuka Microsoft , dan konten yang bukan tentang WinUI, masalah ini harus ditutup. @jevansaks @jesbis

Satu hal terakhir untuk ditambahkan. Saya pikir Rich Lander mengatakan yang terbaik pada 15 Januari .NET Community Standup (mulai @ 1:12:40).

@verelpode Anda mengikuti garis yang disebutkan dalam video di atas, tetapi Anda tetap konstruktif dan pada topik untuk sebagian besar, jadi saya menghargai kontribusi Anda ke repo WinUI - bahkan jika Anda merasa kadang-kadang tidak membuahkan hasil, seperti yang saya lihat di Anda baru-baru ini komentar.

Saat Anda meminta broadSystemAccess, aplikasi Anda, secara default, tidak memiliki akses itu.

Jelas... Anda hanya membuat permintaan, pengguna Anda sebenarnya harus memberi Anda akses jika mereka merasa nyaman melakukannya.

Bukan itu masalahnya: setidaknya di Android/iOS, Anda ditanyai hal itu saat aplikasi Anda mencoba mengakses HDD, dan itu tidak ditutup , seperti dalam kasus kami.

Aplikasi Anda tidak akan ditutup jika Anda menampilkan pemilih file yang memungkinkan pengguna memilih apa yang ingin mereka berikan akses aplikasi Anda.

Alih-alih, Anda menginginkan semuanya, mengeluh tentang langkah kecil tambahan satu kali yang harus dilakukan pengguna, dan menyalahkan tingkat retensi Anda pada langkah ini.

Selain itu, berdasarkan judul yang tidak sopan saja yang melanggar Kode Etik Sumber Terbuka Microsoft , dan konten yang bukan tentang WinUI, masalah ini harus ditutup. @jevansaks @jesbis

Sangat sulit untuk menghormati, ketika saya hampir gila. Belum lagi - Saya sudah mengatakan ini sebelumnya, tidak ada tempat untuk menulis tentang WinRT. Saya akan dengan senang hati menggunakan nada yang berbeda, jika saya benar-benar bisa menulis, dan seseorang akan mendengarkan. Semua teriakan di atas seharusnya tidak ada - WinRT harus cukup dewasa . Padahal... tidak...

Di mana komunitas dapat benar-benar berbicara dengan tim WinRT? Apakah ada yang mendengarkan?

Aplikasi Anda tidak akan ditutup jika Anda menampilkan pemilih file yang memungkinkan pengguna memilih apa yang ingin mereka berikan akses aplikasi Anda.

Alih-alih, Anda menginginkan semuanya, mengeluh tentang langkah kecil tambahan satu kali yang harus dilakukan pengguna, dan menyalahkan tingkat retensi Anda pada langkah ini.

Aplikasi saya memungkinkan pengguna untuk mengedit foto dan video, dan saya ingin pengguna dengan mudah melihat pratinjau saat dia memilih, tidak menggunakan pemilih file gaya lama. Jadi ya, sangat penting bagi saya untuk mendapatkan akses ke semua HDD. Dan tidak, folder virtual "Gambar" dan "Video" itu adalah apa yang menurut Microsoft disimpan pengguna untuk foto dan video mereka. Itu bukan kenyataan.

Saya sudah mengatakan ini sebelumnya, tidak ada tempat untuk menulis tentang WinRT.

Seperti yang ditunjukkan oleh tautan Anda, Anda telah mengoceh tentang WinRT di forum Tanya Jawab UWP, ke mana Anda telah diarahkan.

Jadi dengan memposting di sini sepertinya Anda hanya menginginkan audiens yang lebih besar, daripada benar-benar mencapai apa pun (karena tim WinUI tidak bekerja di WinRT).

Seperti yang ditunjukkan oleh tautan Anda, Anda telah mengoceh tentang WinRT di forum Tanya Jawab UWP, ke mana Anda telah diarahkan.

Namun, tidak ada solusi untuk masalah saya. Pada Q & A, Anda mengajukan pertanyaan, dan menerima jawaban. Tetapi Anda tidak dapat benar-benar menyarankan apa pun untuk diubah (sayangnya).

Aplikasi saya memungkinkan pengguna untuk mengedit foto dan video, dan saya ingin pengguna dengan mudah melihat pratinjau saat dia memilih, tidak menggunakan pemilih file gaya lama. Jadi ya, sangat penting bagi saya untuk mendapatkan akses ke semua HDD.

Tidak. Pengguna Anda tidak memiliki foto dan video di seluruh drive, mereka berada di lokasi tertentu yang mungkin bukan folder khusus.

Mintalah pengguna memilih folder itu sekali, maka Anda selalu dapat memiliki akses melalui FutureAccessList . Jangan membuat mereka memberi Anda akses ke semua file mereka, dan kemudian mereka tidak akan lari.

@kmgallahan Tentu, nadanya bisa diputar kembali sedikit, tapi kita semua pernah frustrasi sebelumnya. Bahkan lebih frustasi untuk berpikir bahwa masalah yang jelas tidak ditangani. Saya pikir terkadang konstruktif untuk melampiaskan frustrasi itu di forum di mana orang dapat memvalidasinya dan juga menawarkan solusi potensial. Poin teknisnya valid, hanya untuk WinRT dan sedikit UWP -- keduanya bukan kontrol WinUI XAML yang diwakili oleh repo ini. Untuk alasan itu, ini mungkin harus ditutup sebagai di luar topik.

Saya pikir kita dapat menjaga jenis diskusi ini tetap profesional karena mengetahui bahwa mereka berasal dari frustrasi dan banyak kepentingan dalam keberhasilan ekosistem pembangunan.

Tentu, nadanya dapat diputar kembali sedikit, tetapi kita semua pernah frustrasi sebelumnya. Bahkan lebih frustasi untuk berpikir bahwa masalah yang jelas tidak ditangani.

Terima kasih :)

Tidak. Pengguna Anda tidak memiliki foto dan video di seluruh drive, mereka berada di lokasi tertentu yang mungkin bukan folder khusus.

Mintalah pengguna memilih folder itu sekali, maka Anda selalu dapat memiliki akses melalui FutureAccessList . Jangan membuat mereka memberi Anda akses ke semua file mereka, dan kemudian mereka tidak akan lari.

Jelas, mereka tidak berada di lokasi tertentu....

Tentu, saya dapat menggunakan FutureAccessList itu dan membuat pengguna mengingat di mana mereka menyimpan foto/video mereka, karena kita semua tahu di mana kita menyimpan semua foto/video kita, bukan?

Alih-alih (apa yang dilakukan aplikasi saya) mempratinjau folder dengan baik dan menunjukkan kepada Anda folder tempat Anda memiliki foto/video.

Beberapa catatan:

Terima kasih @jtorjo telah meluangkan waktu untuk menulis tentang pengalaman dan umpan balik Anda, dan juga untuk waktu Anda di halaman Tanya Jawab juga.

Sebagai @robloo dan @kmgallahan disebutkan sebagian besar ini tidak berhubungan langsung dengan WinUI dan Anda dapat mendorong kode etik kecil yang 🙂

Namun kami juga menyadari bahwa keterlibatan di situs Tanya Jawab dan Hub Umpan Balik bisa lebih baik jika menyangkut area yang berbeda dari platform pengembang Windows. Kami benar-benar secara aktif mencoba untuk meningkatkannya, tetapi saya merasa frustasi untuk menemukan tempat yang baik untuk memberikan umpan balik dan melihat apakah ada sesuatu yang terjadi.

Misalnya kita benar-benar melihat segala sesuatu yang datang melalui Hub Umpan Balik tetapi tidak ada cara yang baik untuk menanggapi atau melanjutkan diskusi. Jadi, selama tetap konstruktif dan terkait dengan UX/pengembangan aplikasi Windows, maka kami boleh membahas beberapa umpan balik platform umum di sini jika suatu topik saat ini tidak cocok di tempat lain.

Untuk apa nilainya, topik ini juga mendapat perhatian internal yang serius. Kami menghubungi beberapa pakar WinRT hari ini untuk melihat apakah ada pembaruan di area ini yang dapat kami bagikan karena Anda dengan rapi merangkum beberapa masalah teratas dengan keseluruhan platform dan alat.

Untuk pengembangan aplikasi desktop: WinUI 3 adalah bagian besar dari upaya kami untuk memisahkan platform pengembang Windows untuk menghilangkan hambatan interoperabilitas tersebut dan membuatnya lebih mudah untuk mengadopsi WinUI dan UWP secara bertahap. Kami tahu kami perlu mengaktifkan aplikasi desktop dengan UX modern dengan lebih baik tanpa memerlukan semua batasan saat ini. Kami memiliki banyak ahli termasuk beberapa pembuat utama WPF yang mengerjakannya.

Secara khusus, kami menghabiskan banyak waktu di pulau Xaml dan di WinUI untuk aplikasi desktop dan kami menantikan langkah berikutnya yang akan merilis pratinjau untuk dicoba orang akhir tahun ini. Kami mencoba untuk lebih didorong oleh umpan balik dan transparan dan itu akan menjadi lebih mudah saat kami memindahkan hal-hal seperti platform Xaml lengkap (yaitu WinUI 3) ke open source.

Jika orang-orang tertarik dengan status paket desktop saat ini, kami juga dapat membahas lebih detail di salah satu Panggilan Komunitas bulanan - jangan ragu untuk menyarankan topik di sini:

Panggilan Komunitas WinUI (22 Januari 2020) #1857

Hai @jesbis ,

Terima kasih telah melihat masalah saya!

Sebagai @robloo dan @kmgallahan disebutkan sebagian besar ini tidak berhubungan langsung dengan WinUI dan Anda dapat mendorong kode etik kecil yang 🙂

Ya, benar-benar minta maaf tentang itu, saya hanya merasa saya keluar dari pikiran saya. Hal-hal yang saya sebutkan di sini sangat penting - saya sangat bersemangat tentang ini, karena semua hal di atas saya alami. Mereka semua mengambil korban besar, banyak orang menyerah begitu saja bahkan mencoba.

Namun kami juga menyadari bahwa keterlibatan di situs Tanya Jawab dan Hub Umpan Balik bisa lebih baik jika menyangkut area yang berbeda dari platform pengembang Windows. Kami benar-benar secara aktif mencoba untuk meningkatkannya, tetapi saya merasa frustasi untuk menemukan tempat yang baik untuk memberikan umpan balik dan melihat apakah ada sesuatu yang terjadi.

Sangat setuju. Sebagai catatan tambahan, saya benar-benar mencoba melaporkan broadSystemAccess di Umpan Balik Hub, dan setelah memberikan semua detail, dan menghabiskan sekitar 15 menit untuk itu, saya akhirnya entah bagaimana mungkin menekan hotkey yang setara dengan "Kembali" - dengan demikian, Saya kehilangan semua pekerjaan saya (tidak ada pembatalan, tidak ada teks yang disalin ke clipboard, tidak ada). Jelas, saya sangat frustrasi dan menyerah begitu saja.

Untuk apa nilainya, topik ini juga mendapat perhatian internal yang serius. Kami menghubungi beberapa pakar WinRT hari ini untuk melihat apakah ada pembaruan di area ini yang dapat kami bagikan karena Anda dengan rapi merangkum beberapa masalah teratas dengan keseluruhan platform dan alat.

Dingin!

Untuk pengembangan aplikasi desktop: WinUI 3 adalah bagian besar dari upaya kami untuk memisahkan platform pengembang Windows untuk menghilangkan hambatan interoperabilitas tersebut dan membuatnya lebih mudah untuk mengadopsi WinUI dan UWP secara bertahap. Kami tahu kami perlu mengaktifkan aplikasi desktop dengan UX modern dengan lebih baik tanpa memerlukan semua batasan saat ini. Kami memiliki banyak ahli termasuk beberapa pembuat utama WPF yang mengerjakannya.

Itu luar biasa! Saya pasti melihat lebih ke depan untuk itu. Sangat mungkin saya akan memperbarui aplikasi saya setelah ini selesai, tetapi sampai saat itu saya terjebak dengan banyak masalah.

Jika orang-orang tertarik dengan status paket desktop saat ini, kami juga dapat membahas lebih detail di salah satu Panggilan Komunitas bulanan - jangan ragu untuk menyarankan topik di sini:

Panggilan Komunitas WinUI (22 Januari 2020) #1857

Bisakah saya menyarankan topik WinRT yang saya sebutkan di sini?

Terima kasih lagi!

Misalnya kita benar-benar melihat segala sesuatu yang datang melalui Hub Umpan Balik tetapi tidak ada cara yang baik untuk menanggapi atau melanjutkan diskusi. Jadi, selama tetap konstruktif dan terkait dengan pengembangan aplikasi, maka kami boleh saja mengambil beberapa umpan balik platform umum di sini jika suatu topik saat ini tidak cocok di tempat lain.

@jesbis
Ini adalah berita bagus! Banyak terima kasih kepada tim WinUI untuk menunjukkan fleksibilitas ini dan mencoba untuk mengurangi (dirasakan) masalah sistem umpan balik WinRT meskipun mereka tidak harus melakukannya!

@kmgallahan

Saya pikir Rich Lander mengatakan yang terbaik pada 15 Januari .NET Community Standup (mulai @ 1:12:40).

Jadi Rich Lander mengatakan di sana bahwa dia lebih suka orang-orang dengan sedikit agresi tetapi baik pada saat yang sama. Saya pikir salah satu masalah terbesar dalam masyarakat adalah bahwa banyak orang sangat "sopan" sehingga perilaku mereka menjadi ekstremis dan berubah menjadi tidak hormat dan kasar sementara secara dangkal tampak "sopan". Orang yang sangat "sopan" berbicara secara tidak langsung dan samar, dan ini membuat komunikasi mereka sulit dipahami dan mudah disalahartikan. Orang yang sangat "sopan" tidak sopan dan kasar karena mereka secara efektif mengatakan yang setara dengan:

"Saya percaya bahwa Anda tidak dapat menangani kebenaran langsung, oleh karena itu saya akan menangani Anda dengan sarung tangan katun tebal berbulu, dan mengemas Anda dalam bungkus gelembung, dan berbicara kepada Anda dengan sangat sopan, tidak langsung, dan samar-samar, karena jika saya memperlakukan Anda sebagai orang dewasa yang matang dan mengungkapkan pendapat jujur ​​saya, Anda akan meledak dan meledak dan menjadi gila. Anda adalah orang yang sangat rapuh, lembut, dan Anda belum dewasa, jadi saya harus berbicara dengan sangat sopan dan tidak langsung kepada Anda, karena Anda bisa tidak menangani kebenaran langsung."

Dengan cara itu, ketika apa yang disebut "kesopanan" diambil secara ekstrem (seperti yang dilakukan banyak orang), itu menjadi tidak sopan dan kasar sambil tetap terlihat "sopan". Dengan kata lain, kesalahpahaman tentang kesopanan dan rasa hormat adalah salah satu masalah terbesar di masyarakat. Banyak orang tidak menyadari bahwa kesopanan yang berlebihan tidak sopan, dan menyebabkan proyek gagal, dll. Masalah kesopanan palsu ini menyebabkan kegagalan komunikasi lain setiap detik setiap jam setiap hari di suatu tempat di dunia -- itu terjadi terus-menerus -- dan masyarakat sangat menderita karenanya.

@jtorjo
Inilah asal mula masalahnya:

Pengulangan kesalahan bencana Nokia

WinRT/UWP secara tidak sengaja mengulangi kesalahan yang sama seperti Nokia, BlackBerry, Apple pada satu titik, dan perusahaan lain. Kisah Nokia: Nokia adalah raksasa yang sangat sukses, tetapi kemudian Nokia menyadari bahwa mereka telah tertinggal dalam teknologi smartphone. Untuk mengatasi masalah ini, mereka perlu menjadikannya prioritas utama untuk mewujudkan serangkaian versi perbaikan dari sistem mereka yang sudah ada sebelumnya. Alih-alih melakukan itu, mereka mencoba untuk beralih ke sistem baru, dan itu membunuh mereka. Benar-benar membunuh mereka -- Nokia Mobile terpaksa menerima dibeli oleh Microsoft.

Jadi, Anda akan berharap bahwa Microsoft akan belajar dari kesalahan Nokia dan tidak mengulangi masalah yang sama. Sayangnya Microsoft mengulangi kesalahan yang sama seperti Nokia. Microsoft memulai WinRT/UWP alih-alih memproduksi versi baru WPF dan .NET Framework. Tebak apa yang terjadi? Bencana bencana yang sama seperti Nokia: Itu membunuh mereka. Windows Mobile sudah mati dan dibatalkan oleh eksekutif Microsoft. Jadi sayangnya Microsoft tidak belajar dari kesalahan besar Nokia. Sekarang semua smartphone menjalankan Android atau Apple alih-alih WinRT/UWP, sehingga WinRT/UWP adalah kegagalan besar yang menyebabkan Microsoft kehilangan tempat mereka sepenuhnya di industri smartphone multi-miliar dolar. WinRT/UWP menyebabkan kerugian multi-miliar dolar bagi Microsoft.

BlackBerry melakukan kesalahan yang sama seperti Nokia dan Microsoft. BlackBerry sangat sukses, tetapi kemudian BlackBerry menyadari bahwa mereka telah tertinggal dalam teknologi smartphone. Untuk mengatasi masalah ini, mereka perlu menjadikannya prioritas utama untuk mewujudkan serangkaian versi perbaikan dari sistem mereka yang sudah ada sebelumnya. Alih-alih melakukan itu, mereka mencoba beralih ke sistem baru. BlackBerry awalnya menggunakan OS BlackBerry, kemudian sekitar tahun 2013 beralih ke sistem QNX. Apa yang terjadi? Sama seperti WinRT dan Nokia. Itu membunuh mereka. Pada 2016, BlackBerry mengumumkan akan berhenti mendesain ponselnya sendiri.

Itu juga terjadi dengan Apple pada satu titik di masa lalu. Apple hampir ambruk dan sangat beruntung bisa bertahan. Beberapa tahun kemudian, Apple akhirnya melakukan pemulihan yang kuat melalui smartphone. Beruntung masih hidup setelah kesalahan bencana.

Melanggar Perubahan

Microsoft mengklaim bahwa mereka tidak dapat melanjutkan pengembangan WPF; tidak dapat menggunakan WPF untuk ponsel cerdas/tablet karena melanggar perubahan, tetapi itu adalah kasus ketakutan yang ekstrem untuk melanggar perubahan. Ya, bijaksana untuk sangat berhati-hati dalam hal melanggar perubahan, tetapi jika dilakukan secara ekstrem, itu akan membunuh proyek dan perusahaan. Kenyataannya adalah bahwa perubahan melanggar sebenarnya bisa diperkenalkan. Microsoft bisa saja merilis "WPF 5" dengan dukungan untuk smartphone/tablet/layar sentuh, dan mengumumkan bahwa itu mencakup perubahan yang melanggar tetapi tidak ada pengembang yang dipaksa untuk segera memutakhirkannya. Aplikasi yang sudah ada sebelumnya tidak rusak karena terus berjalan dengan WPF 4 hingga pengembang aplikasi merasa nyaman dan siap untuk beralih ke WPF 5. Dengan demikian, perubahan yang terputus tidak menyebabkan kekacauan atau kegagalan.

Ini prinsip yang sama dengan versi baru dari paket NuGet yang mencakup perubahan yang melanggar. Aplikasi Anda tidak tiba-tiba rusak saat versi baru paket dirilis. Pengguna Anda terus menggunakan aplikasi Anda dan tidak mengalami masalah apa pun karena aplikasi Anda terus menggunakan versi paket yang lama hingga Anda merasa nyaman dan siap untuk meningkatkan versi aplikasi Anda untuk menggunakan paket NuGet versi terbaru. Dengan demikian perubahan yang melanggar dapat diperkenalkan.

Pembalikan sudut pandang pada kode yang dikelola

Microsoft mengatakan kode terkelola memberikan keuntungan luar biasa, dan itu benar-benar benar dalam pengalaman saya menggunakan kode terkelola dan tidak terkelola. Saya memulai karir saya dengan menulis kode yang tidak dikelola. Kemudian saya menguji klaim Microsoft dan saya beralih ke kode terkelola dan saya mengalami peningkatan yang sangat baik dalam produktivitas dan keandalan. Kemudian, Microsoft secara aneh membalikkan sudut pandang mereka dan memproduksi WinRT dengan basis kode yang tidak dikelola, dan Model Objek Komponen (COM) kuno dari tahun 1993, dan penggunaan Win16 yang berlebihan (juga dikenal sebagai Win32). Dasar dari WinRT adalah teknologi yang sudah ketinggalan zaman: Kode asli, COM, dan Win16 AKA Win32. Seharusnya tidak mengherankan bahwa sebagian besar pengembang aplikasi enggan beralih ke WinRT/UWP.

Android sekarang adalah pemimpin pasar. Microsoft dapat belajar dari Android. Aplikasi Android biasanya ditulis menggunakan kode terkelola. Meskipun saya tidak suka Java dan lebih suka menggunakan C#, saya harus mengatakan bahwa Java jauh lebih baik daripada Win16 dan COM asli.

Beberapa anggota staf Microsoft masih terus mengatakan "asli" seolah-olah itu hal yang baik. Saya memulai karir saya dengan "pribumi" dan saya tahu dari pengalaman bertahun-tahun bahwa "pribumi" adalah hal yang buruk. Legiun pengembang Android juga tahu bahwa asli adalah hal yang buruk, tetapi terlalu banyak anggota staf UWP mengatakannya seolah-olah itu hebat. Untuk menggunakan kata-kata @jtorjo , tim WinRT adalah dan "tidak berhubungan dengan kenyataan". Tim WinRT terus bersikap seolah-olah WinRT sukses, terlepas dari kenyataan bahwa itu gagal total dan Windows Mobile sudah dibatalkan oleh eksekutif Microsoft.

Saya harus terus mengulangi kata-kata itu lagi dan lagi: WinRT/UWP adalah kegagalan besar. Saya terpaksa terus mengulangi kata-kata itu karena tim WinRT "tidak berhubungan dengan kenyataan" dalam arti bahwa mereka menolak untuk mengakui bahwa WinRT/UWP adalah kegagalan besar dan bahwa Microsoft tidak boleh terus mengulangi kesalahan yang sama dari WinRT seolah-olah tidak ada yang terjadi.

Misalnya, saat ini DataGrid ditulis dalam kode terkelola modern, tetapi tim WinUI ingin menulis ulang DataGrid untuk menggunakan kode "asli" dan percaya ini adalah "peningkatan" padahal kenyataannya ini adalah penurunan versi dan regresi ke praktik yang sudah puluhan tahun ketinggalan zaman. Secara umum, WinRT/UWP diganggu dengan campur aduk antara praktik rekayasa perangkat lunak modern dan usang. Jadi @jtorjo 's penggunaan kata-kata _ 'keluar dari sentuhan dengan realitas' _ bisa diartikan sebagai sopan, tapi saya percaya itu adalah deskripsi yang akurat, bahkan jika itu bukan pilihan terbaik dari kata-kata.

Untuk contoh lain dari _"tidak berhubungan dengan kenyataan"_, lihat desain WebView2 -- ini seperti melakukan perjalanan waktu kembali ke awal karir saya, beberapa dekade yang lalu, ketika kami menggunakan konsep usang seperti HRESULT alih-alih penanganan pengecualian modern. Sungguh menakjubkan melihat WebView2 dirilis sebagai proyek baru di tahun 2020 namun masih menggunakan teknik kuno seperti HRESULT dan LPCWSTR . Desain WebView2 tidak sesuai dengan praktik rekayasa perangkat lunak modern.

Jadi, sejalan dengan apa yang dikatakan Rich Lander, pesan saya sebelumnya menunjukkan rasa hormat saya kepada tim WinUI, karena jika saya tidak menghormati tim WinUI, maka saya akan selalu sangat sopan kepada tim, atau tidak mengatakan apa-apa sama sekali. Jika saya tidak menghormati tim, saya akan menghapus dan mengabaikan WinUI: Saya tidak akan repot-repot menulis pesan apa pun -- saya akan melihat WinUI sebagai "putus asa" dan "tujuan yang hilang" dan saya tidak akan memberikan umpan balik di semua. Fakta bahwa saya memberikan umpan balik yang terperinci menunjukkan bahwa saya menghormati tim. Banyak orang tidak memberikan umpan balik -- itu tidak menghormati tim. Tidak sopan melihat tim begitu putus asa sehingga tidak ada gunanya menulis umpan balik untuk mereka.

Jika Anda berada di pengadilan, Anda akan dengan sangat sopan mengatakan "Yang Mulia" kepada hakim bahkan jika Anda membenci keberaniannya. Kesopanan yang ekstrim adalah kekasaran. Hakim menafsirkan "Yang Mulia" sebagai rasa hormat tetapi sebenarnya tidak menghormati.

Microsoft memulai WinRT/UWP alih-alih memproduksi versi baru WPF dan .NET Framework. ...

Sepakat. Saya telah mengembangkan UWP selama beberapa bulan sekarang... Ada beberapa batasan, tetapi saya telah melakukan yang terbaik untuk menjadi "zen" tentang hal itu, dan kurang lebih, lanjutkan. Tetapi semakin saya bekerja, semakin saya menyadari - bahwa batasannya sebenarnya adalah WinRT, bukan UWP.

Masalahnya, inilah yang kita miliki, dan jelas, kita perlu bergerak maju dengannya. Dalam pikiran saya, ini seharusnya:

1. UWP perlu menyembunyikan sebanyak mungkin fakta bahwa ia menggunakan WinRT dan
2. WinRT harus berusaha untuk menghapus sebanyak mungkin batasan (yang tidak dibutuhkan)
3. Fokus utama harus Desktop, dan kemudian platform lain (Hololens, xbox dll)

(ps Fakta bahwa, untuk sebuah file, untuk mendapatkan propertinya, saya perlu memanggil fungsi async, masih membuat saya berkedut)

Pembalikan sudut pandang pada kode yang dikelola

Mengapa kita harus berurusan dengan COM di WinRT memang di luar pemahaman saya. Sepertinya mereka membungkus beberapa kode DCOM lama atau sesuatu, tetapi itu harus 100% disembunyikan dari pengguna WinRT.
Fakta bahwa kita perlu mewaspadai COM sangat buruk. Itu, sekali lagi, harus sebisa mungkin disembunyikan dari saya, pengguna perpustakaan.

[nanti edit] Sekarang kalau dipikir-pikir, kita setidaknya membutuhkan COM untuk berurusan dengan DirectX. Namun, itu harus disembunyikan mungkin dari pengguna perpustakaan.

Beberapa anggota staf Microsoft masih terus mengatakan "asli" seolah-olah itu hal yang baik.

Asli, dalam konteks "kompilasi ke .net asli", saya pikir itu hal yang baik, namun, saya tidak suka keterbatasannya. Proyek saya gagal dikompilasi ke .net native, karena menggunakan lib lain yang saya porting ke UWP, dan menggunakan beberapa API, yang diyakini oleh orang-orang Store yang kuat adalah "tidak dapat diterima". Lib yang dimaksud adalah https://github.com/naudio/NAudio - perpustakaan yang sangat kuat. Untuk alasan ini saja, saya hanya mengatakan - saya TIDAK akan mempublikasikan aplikasi saya ke toko MS.

Contoh lain dari _"out of touch with reality"_, lihat desain WebView2 -- ini seperti melakukan perjalanan waktu kembali ke awal karir saya

Saya tidak 100% yakin, tetapi Anda mungkin benar. Saya tahu bahwa WebView dikatakan sebagai pembungkus kontrol Win32, dan saya tahu bug aneh, bahwa tautan WebView tidak akan berfungsi ketika WebView berada di atas kontrol lain.

Hai @robloo ,

Maaf untuk jawaban yang terlambat

Saya berada di tingkat frustrasi Anda beberapa tahun yang lalu ketika saya pertama kali mulai mem-porting aplikasi WPF. Jadi saya pasti mengerti perasaan Anda. Ada beberapa kemajuan sejak saat itu dan seperti yang Anda katakan, tim WinUI benar-benar berusaha keras.

Ya, setuju sekali. Kembali pada 2016-2017, saya bahkan tidak akan menyentuh UWP.

Dari sudut pandang saya, ada masalah desain mendasar yang tidak dapat kami atasi: WinRT secara teknis cacat karena harus interop langsung dengan C++ dan JavaScript ( di sini

Itu sangat menyedihkan, untuk sedikitnya ... Mengapa kita menginginkan interoperabilitas JS?

... adalah contoh, dan lainnya ). Itu benar-benar tidak cocok dengan banyak konsep tingkat tinggi seperti obat generik. Tentu saja ada satu keuntungan besar dengan arsitektur ini juga: Semua Windows sekarang dapat berbagi WinRT API yang sama.

Ada banyak hal yang saya benci tentang WinRT - apa lagi dalam daftar?

Fakta bahwa saya bahkan perlu tahu tentang ini, itu buruk. Sebenarnya, saya perlu membuat 2 proyek kecil seperti itu, dan itu semua coba-coba, untuk memahami apa yang sebenarnya boleh saya gunakan.

Jadi, kami telah kehilangan beberapa keuntungan dari kode terkelola yang telah kami terbiasa selama bertahun-tahun. Ini jelas masih tampak seperti langkah mundur dari WPF -- saya selalu menemukan bug dan fitur yang tidak lengkap. Saya pikir #1830 tidak akan pernah terjadi di masa WPF. Kami masih harus bergerak maju entah bagaimana.

Ya, kita lakukan...

WinUI 3.0 jelas merupakan langkah ke arah yang benar untuk mencoba memperbaiki ini setidaknya di frontend. Padahal, saya lebih suka Microsoft menerapkan proses pengembangan yang lebih kuat dan lebih banyak pengujian sebelum merilis kontrol baru... [...]

Setuju 100%.

Sangat menyedihkan bagi saya untuk melihat apa yang dulunya merupakan platform UI paling kuat WPF berevolusi menjadi ini. Tapi Microsoft sekarang, perlahan tapi pasti, mendengarkan umpan balik dan memperbaiki berbagai hal. Dapat dipahami bahwa ada lebih banyak pekerjaan yang harus dilakukan.

Ya, jelas ada orang yang mengagumkan di MS yang mendengarkan. Semoga kita bisa membalikkan keadaan ini...

Query untuk file API Luar Biasa lambat

Rupanya, seseorang memang menemukan solusi untuk ini. Jelas, sangat menyedihkan bahwa ini memakan waktu lama - dan ini bukan cara yang saya inginkan untuk mencari file, tetapi setidaknya itu benar-benar berfungsi.
https://github.com/microsoft/microsoft-ui-xaml/issues/1465#issuecomment -575987737

Jadi, terima kasih banyak kepada @duke7553 !

@jtorjo Senang membantu!

Saya menemukan diskusi ini sangat menarik dan sebenarnya sangat relevan dengan masa depan Windows UI. Itu karena WinUI tidak duduk dalam ruang hampa. Seluruh repo ini memiliki nilai yang sangat kecil kecuali jika berguna untuk membuat aplikasi yang berjalan pada sesuatu selain WinRT/UWP. WinUI 3.0 tidak bisa datang cukup cepat.

Kami memiliki visi dan peta jalan untuk UI di windows, tetapi itu berada di paling atas tumpukan dan tidak ada visi untuk apa yang ada di bawah lapisan permukaan itu:
Apakah WinUI terlihat bagus? YA
Bisakah Anda membuat aplikasi modern dan terlihat bagus di Windows sekarang (JAN2020)? TIDAK
Bisakah Anda membuat aplikasi yang bagus dengan UWP? TIDAK!

Kami tidak dapat benar-benar bergerak maju tanpa membahas gajah di dalam ruangan: menyebutkan fakta sebelumnya bahwa WinRT dan UWP gagal total, tidak hanya dari segi bisnis tetapi juga secara teknologi. Saya pribadi di antara jumlah tubuh. Saya berhenti mengembangkan proyek hobi saya ketika saya tidak tahu cara memainkan suara ketika aplikasi saya kehilangan fokus. Remeh. Apakah hal-hal sepele harus sesulit di UWP? Bisakah Anda menyebut platform hebat ketika hal-hal sepele menjadi sangat sulit? WinUI hanyalah bagian dari sebuah platform, bukan?

Gajah lain di ruangan itu. Jika seseorang bertanya: Saya ingin membuat program Windows baru, apa cara terbaik untuk melakukannya? Tidak ada jawaban langsung di JAN2020! Jika Anda mencoba memasukkan UWP ke dalam jawabannya - Anda AKAN mengalami waktu yang buruk. (Apakah ada satu komentar, posting blog, video YouTube di mana seseorang berkata: Saya membuat aplikasi hebat dengan UWP dan saya menyukai prosesnya? Kita semua tahu tidak ada. Tidak ada yang menulis tentang membuat aplikasi dengan UWP, itu benar-benar tidak 'tidak ada di Internet). WPF? Tidak ada kontrol modern - teknologi mati, bukan ide yang bagus (masih lebih baik dari UWP). Jawaban jujurnya adalah: coba elektron, mungkin? VSCode dibuat dengan itu, jadi Anda tahu Anda bisa membuat aplikasi yang bagus dengannya.

Dan ide bahwa Anda dapat membuat aplikasi untuk windows dengan bahasa apa pun yang Anda suka hanyalah sebuah solusi. Kami berada dalam situasi di mana Anda dapat membuat aplikasi UWP yang sangat buruk dengan bahasa apa pun yang Anda inginkan. Bot tidak setidaknya SATU cara terbaik untuk melakukannya.

Hal angkatan laut yang disebutkan sebelumnya di utas? Sangat setuju. Visual Studio - The Juggernaut sendiri (UI) dibuat dengan kode terkelola - WPF. Hebat, bahkan fantastis. Meskipun bahkan Microsoft tidak dapat membuat aplikasi OK dengan kode asli superion yang seharusnya ini. Saya melihat perilaku tak terduga setiap hari dengan OneNote, Weather, dan bahkan Start/Search/Taskbar. Rasanya miring dan terkadang fokus tidak bekerja sebagaimana mestinya.

Ini adalah topik yang kaya dan penting. Sangat relevan dengan WinUI, dan sayangnya tidak ada tempat yang lebih baik untuk membicarakannya. Topik-topik ini perlu ditangani secara terbuka oleh Microsoft.

Kami memiliki visi dan peta jalan untuk UI di windows, tetapi itu berada di paling atas tumpukan dan tidak ada visi untuk apa yang ada di bawah lapisan permukaan itu:
Apakah WinUI terlihat bagus? YA

Ya itu!

Bisakah Anda membuat aplikasi modern dan terlihat bagus di Windows sekarang (JAN2020)? TIDAK

Saya yakin Anda bisa - tapi itu sangat sulit. Hal-hal sepele sangat sulit dilakukan (saya adalah bukti nyata bahwa itu mungkin, tetapi Anda pasti membutuhkan keberanian baja):

• di bagian depan UI, akan ada masalah, tetapi biasanya Anda akan memahaminya
• di bagian depan "apa pun", semuanya cukup redup.
• berurusan dengan file di UWP benar-benar neraka, karena StorageFile/Folder API, yang, secara sederhana, saya benci dengan sepenuh hati

Kami tidak dapat benar-benar bergerak maju tanpa membahas gajah di dalam ruangan: menyebutkan fakta sebelumnya bahwa WinRT dan UWP gagal total, tidak hanya dari segi bisnis tetapi juga secara teknologi. Saya pribadi di antara jumlah tubuh. Saya berhenti mengembangkan proyek hobi saya ketika saya tidak tahu cara memainkan suara ketika aplikasi saya kehilangan fokus. Remeh. Melakukan hal-hal sepele harus sesulit itu

Sepakat. Memang, sistem pemutaran terdengar, yang di WPF seperti SystemSounds.Beep.Play() , tidak tersedia di UWP.

Pada dasarnya, tidak ada perpustakaan suara di UWP, karena pembatasan WinRT "hebat", yang pada dasarnya berarti - Anda tidak dapat mengimpor fungsi apa pun dari DLL yang win32. Cukup banyak, setiap perpustakaan yang layak tidak dapat di-porting ke UWP. Tidak ada perpustakaan, tidak ada aplikasi.

Di "perpustakaan suara" di UWP, naudio telah mencoba yang terbaik untuk bekerja di UWP. Jelas, itu jatuh datar. Saya melakukan garpu, menghapus banyak #ifdefs, dan sekarang berfungsi untuk kebutuhan saya. Saya tidak akan pernah bisa mempublikasikan aplikasi saya ke MS Store, saya juga tidak pernah mau.

Langkah terbaik ke arah yang benar, menurut saya, adalah bagi MS untuk

1. Akhirnya fokus pada Windows Desktop PERTAMA . Berhenti mengejar seribu platform, seperti Hololens, Xbox, dan sejenisnya. Tentu, akan ada orang yang ingin mengembangkan platform tersebut, tetapi persentasenya sangat kecil.
2. Hapus semua batasan API dengan bijak - sehingga orang benar-benar dapat mengkompilasi lib ke UWP
3. Setelah Anda meminta broadSystemAccess, berikan saja dan berhenti bersikap terlalu protektif.
4. Setelah Anda meminta broadSystemAccess, izinkan System.IO melalui semua HDD
5. Permudah distribusi di luar toko MS (+ perbaiki masalah "Sertifikat Baru")

Gajah lain di ruangan itu. Jika seseorang bertanya: Saya ingin membuat program Windows baru, apa cara terbaik untuk melakukannya? Tidak ada jawaban langsung di JAN2020! Jika Anda mencoba memasukkan UWP ke dalam jawabannya - Anda AKAN mengalami waktu yang buruk. (Apakah ada satu komentar, posting blog, video YouTube di mana seseorang berkata: Saya membuat aplikasi hebat dengan UWP dan saya menyukai prosesnya? Kita semua tahu tidak ada. Tidak ada yang menulis tentang membuat aplikasi dengan UWP, itu benar-benar tidak 'tidak ada di Internet). WPF? Tidak ada kontrol modern -

Ya, saya setuju - menemukan sumber daya yang bagus di UWP hampir nol. Banyak masalah, Anda hanya perlu mengatasi dan memperbaikinya sendiri.

teknologi mati, bukan ide yang bagus (masih lebih baik dari UWP). Jawaban jujurnya adalah: coba elektron, mungkin? VSCode dibuat dengan itu, jadi Anda tahu Anda bisa membuat aplikasi yang bagus dengannya.

Tentang WPF Saya hanya memiliki kata-kata pujian. Saya telah berkembang selama beberapa tahun. dan meskipun kurva belajarnya cukup curam, setelah Anda menguasainya, itu luar biasa! Saya memang menemukan beberapa bug hardcore, yang saya tahu tidak akan pernah diperbaiki, tetapi hanya itu.

Saya terpaksa pindah ke UWP, karena untuk membuat aplikasi saya cukup cepat, saya harus menggunakan win2d. Ada hal-hal yang hilang dari UWP ketika datang ke UI (seperti, pada saat saya mulai porting, tidak ada cara asli untuk mendefinisikan Cursor untuk kontrol), tetapi secara keseluruhan, saya selalu menemukan solusi .

Hal angkatan laut yang disebutkan sebelumnya di utas? Sangat setuju. Visual Studio - The Juggernaut sendiri (UI) dibuat dengan kode terkelola - WPF. Hebat, bahkan fantastis. Meskipun Microsoft tidak bisa

Jelas, saya bertaruh a ** saya, bahwa Anda tidak dapat membuat Visual Studio di UWP seumur hidup saya - dan saya tidak berbicara tentang UI, Anda dapat mencocokkan dan melampaui UI Visual Studio, tetapi sisanya. ...

Ini adalah topik yang kaya dan penting. Sangat relevan dengan WinUI, dan sayangnya tidak ada tempat yang lebih baik untuk membicarakannya. Topik-topik ini perlu ditangani secara terbuka oleh Microsoft.

100% setuju!

Bisakah Anda membuat aplikasi modern dan terlihat bagus di Windows sekarang (JAN2020)? TIDAK

Saya yakin Anda bisa - tapi itu sangat sulit. Hal-hal sepele sangat sulit dilakukan (saya adalah bukti nyata bahwa itu mungkin, tetapi Anda pasti membutuhkan keberanian baja):

• di bagian depan UI, akan ada masalah, tetapi biasanya Anda akan memahaminya
• di bagian depan "apa pun", semuanya cukup redup.
• berurusan dengan file di UWP benar-benar neraka, karena StorageFile/Folder API, yang, secara sederhana, saya benci dengan sepenuh hati

Kami seperti anjing yang dipukuli di sini. Sebenarnya sangat sulit untuk membuat aplikasi modern baru untuk desktop Windows! Bukankah seharusnya ada setidaknya satu cara terbaik untuk melakukan aplikasi? Saat Anda pergi ke Microsoft Store di windows dan mencoba menggulir kategori aplikasi, Anda tidak akan menemukan aplikasi layak yang dibuat dengan UWP. Btw saya tidak bisa memeriksanya sendiri karena ...

Yap, aplikasi "modern", "pribumi". Karena Windows sekarang praktis gratis, seharusnya sumber utama monetisasi bukanlah aplikasi paling solid di sistem, tapi saya ngelantur. Anda sebenarnya tidak perlu meneliti aplikasi untuk mengetahui dengan teknologi apa aplikasi itu dibuat. Hanya satu tampilan dan Anda dapat mengetahui apakah itu dibangun dengan UWP. Tidak ada proyek komersial serius yang dibangun dengan UWP, dan yang dibangun dengannya adalah ... Anda tahu ...

Dan itu karena itu sangat sulit. Window10 adalah platform terbesar setelah Internet dan Android!!! Tapi Tidak Ada yang membuat aplikasi untuk itu dengan alat yang seharusnya dibuat untuk tujuan itu! Renungkan saja itu. Lebih mudah membangun aplikasi Electron untuk 3 sistem operasi daripada hanya untuk Windows dengan UWP!

Apakah boleh bagi kami, anjing yang kalah, yang hanya ingin membangun aplikasi desktop Windows untuk menuntut alat yang sangat baik? Saya katakan dengan tidak menyesal ya! Tapi yang kami miliki hanyalah keheningan radio dari Microsoft. Siapa yang ingin mendengar dongeng bahwa aplikasi Anda mungkin berfungsi di Holo Lens atau Windows Phone atau Xbox? Bukan siapa-siapa. Setelah 5 tahun tidak ada aplikasi komersial yang bekerja pada 2 platform yang dijanjikan untuk UWP. (Sebagian besar karena platform tersebut tidak keluar). Sekali lagi, renungkan itu! Hal terbaik yang terjadi pada kami adalah WinUI sedang di-porting KEMBALI ke win32 lama.

Saya suka desktop Windows, saya belajar memprogram C# di WinForms dan WPF. Dan itu mudah dan luar biasa untuk noob seperti saya. Hari ini saya mengeluarkan air liur melihat kontrol menarik di WinUI, tetapi seseorang harus menjelaskan gambaran besar untuk platform. Kami membutuhkan pesan yang jelas tentang kepemimpinan teknologi praktis dan bukan tentang aspirasi pasar dari beberapa eksekutif bisnis MS.

Hai,
Saya agak terlambat untuk diskusi ini tetapi tetap ingin memberikan pendapat saya yang sederhana.
Mengenai Aplikasi UWP komersial: Salah satu yang muncul di benak saya adalah Adobe XD. Yang satu ini adalah UWP dan terasa sangat matang dan lengkap.
Pengalaman saya sendiri dengan UWP, menjadi pengembang .Net selama 13 tahun: Tentu saja Anda dapat membuat aplikasi yang terlihat bagus dan berkinerja baik dengannya. Tapi... itu bukan pengalaman yang indah. Kami sedang dalam proses membuat aplikasi medis dan banyak hal yang telah disebutkan di sini dan di tempat lain juga ditemukan oleh kami:

• API file lambat yang luar biasa
• Sangat lambat "waktu F5". Jadi masuk ke debug untuk membangun/memulai aplikasi untuk mencoba sesuatu setidaknya 10 x lebih lambat daripada di WPF. (pikirkan sekitar 2 menit pada Surface Book 2)
• Secara umum, dibatasi oleh kotak pasir.
  Ini hanya yang dari atas kepala saya. Pada akhirnya ketika XamlIslands dirilis, kami memilih untuk meng-host UI UWP lengkap kami di Jendela WPF, memiliki inti .net yang cepat di belakang segalanya. Saya tidak berpikir banyak orang menggunakan XamlIsland sebesar ini (disimpulkan dari masalah github/PR yang kami buat). Namun teknologi ini juga memiliki beberapa keterbatasan yang sangat serius. Sebagai contoh, waktu kompilasi naik lebih tinggi lagi. Kehilangan kemampuan untuk mengedit langsung Xaml. Membuat penginstal untuk aplikasi WPF/XamlIsland/UWP yang serius? Itu menyakitkan. dll...
  Jadi kesimpulannya, membuat aplikasi UWP yang indah tentu saja bisa dilakukan. Tapi itu sangat tidak produktif dan lambat. Dan dibatasi.
  Jadi seperti banyak orang lain, kami sangat menantikan rilis dan pematangan WinUI 3, karena dapat memiliki frontend "UWP" dan .net core (atau .net 5 ;-) ) backend tanpa trik.

@jasonwurzel itu adalah beberapa poin yang sangat bagus

• File API lambat tetapi untuk sementara @ duke7553 memposting solusi di # 1465 (komentar)
  Itu benar, namun kami tidak mengetahuinya saat itu. Berlebihan untuk mengatakan, entah bagaimana gila untuk mengimplementasikan solusi ini hanya untuk mendapatkan file I/O cepat ...
• Waktu F5 memang memperlambat segalanya dan saya pikir itu bisa menggunakan beberapa perbaikan
• Saya ingin tahu batasan apa yang Anda hadapi dengan mencoba mengembangkan aplikasi UWP biasa sebagai lawan dari rute pulau xaml? Saya sedang mengerjakan beberapa aplikasi sekarang dan saya dapat mengatasi batasan apa pun dengan menyertakan proses Win32, tetapi saya mengerti bahwa itu tidak selalu merupakan cara yang ideal untuk membuat aplikasi.
  Saya kira pada akhirnya itu adalah jumlah dari hambatan yang kami temui, tidak diragukan lagi beberapa di antaranya dapat diselesaikan dengan proses eksternal. Tanpa urutan tertentu:
• Mengamati baki CD/port USB untuk media yang dimasukkan
• mengamati beberapa direktori yang dipilih pengguna di mana saja di PC lokal dan membuat App/Windows mengingat akses tepat saat memperbarui
• menuntut broadFileSystemAccess, mendapatkan pengecualian, membuka Halaman Pengaturan Windows yang sesuai, pengguna memeriksa sakelar Aplikasi, boom Aplikasi menutup tanpa peringatan, tidak ada kesempatan untuk campur tangan.
• domain yang sama: membiarkan pengguna memilih direktori tanpa harus membuka FolderPicker bergaya Windows (tidak, kami tidak ingin menata aplikasi layar penuh kami dengan cara yang bagus dan ramping dan kemudian Dialog Windows melompat ke wajah pengguna)
• masalah ayam dan telur: ketersediaan/dukungan paket nuget (lebih banyak orang masih menggunakan WPF, jadi menemukan solusi untuk masalah kecil jauh lebih cepat)
• mengontrol lokasi pemasangan

@AndrewPawlowski Saya terkejut Anda akan mengatakan bahwa ketika ada banyak aplikasi UWP hebat yang modern dan tampan, termasuk beberapa yang open source di GitHub.
Hanya karena Anda menyerah dalam membuat aplikasi karena Anda tidak tahu cara melakukan sesuatu, bukan berarti platform gagal, itu berarti aplikasi Anda gagal. Jika Anda melihat-lihat, Anda dapat melihat banyak pengembang yang bekerja keras dan membuat beberapa aplikasi yang sangat bagus termasuk aplikasi yang terus memutar suara saat aplikasi kehilangan fokus.

Saya tidak mengatakan itu tidak mungkin, tetapi itu sangat sangat sulit. Dan saya tidak berbicara tentang aplikasi "seperti Notepad" yang sederhana, saya berbicara tentang aplikasi yang sangat kompleks yang berhubungan dengan UI / pengeditan video / pengeditan suara / memuat / menyimpan banyak hal ke disk / (mencoba dan tidak berhasil ) meluncurkan barang (dan tolong jangan beri tahu saya tentang API FullTrust). Saya berbicara tentang aplikasi baris kode 50-100K+.

Itu lebih sulit.

Dan fakta bahwa Anda dapat memutar suara saat aplikasi kehilangan fokus - tidak ada yang mengatakan bahwa Anda tidak bisa, tetapi seharusnya lebih mudah daripada sekarang.

Anda bertanya apakah ada orang yang menikmati proses pengembangan aplikasi UWP dan jawabannya adalah bahwa ada banyak dan dalam beberapa bulan terakhir saya telah mendapatkan banyak permintaan dari pengembang lain untuk bantuan pada aplikasi mereka, platform ini jelas mendapatkan minat.

Saya setuju, itu sebabnya saya benar-benar memulai porting aplikasi saya ke UWP. Tapi itu jalan yang sangat bergelombang, dan masih begitu.

Anda juga mengklaim bahwa tidak ada yang menulis tentang mengembangkan aplikasi UWP dan saya harus mengatakan bahwa itu salah, @rudyhuyn , Martin Zikmund hanyalah dua contoh pengembang yang menulis tentang UWP tetapi ada banyak lainnya juga.

Saya sangat setuju, tetapi bandingkan dengan orang yang menulis tentang wpf. Ini setetes air.

Lakukan pencarian github sederhana - "c# wpf" (3701 hasil) vs "c# uwp" (337 hasil).
Saya yakin jika Anda akan mencari hal yang sama, dan memfilter berdasarkan "jumlah komit> 500" (yang agak berarti - pengguna terjebak dengan proyek) -> Anda akan menemukan gambar yang lebih redup.

Ini cukup banyak menunjukkan bahwa Anda dapat membuat aplikasi yang terlihat bagus pada tahun 2020 serta aplikasi UWP modern dan banyak dari pernyataan Anda tidak akurat.

Saya mohon untuk tidak setuju - untuk dapat mengembangkan aplikasi kompleks UWP dan senang melakukannya -> kami masih jauh dari itu.

• Saya ingin tahu batasan apa yang Anda hadapi dengan mencoba mengembangkan aplikasi UWP biasa sebagai lawan dari rute pulau xaml? Saya sedang mengerjakan beberapa aplikasi sekarang dan saya dapat mengatasi batasan apa pun dengan menyertakan proses Win32, tetapi saya mengerti bahwa itu tidak selalu merupakan cara yang ideal untuk membuat aplikasi.

Pada akhirnya, saya mencoba menggunakan win2d menggunakan Kepulauan Xaml pada bulan September - tidak berhasil sedikit pun. Saya mencoba beberapa contoh MS dan mereka juga tidak berhasil. Pada saat itu, saya menyadari bahwa saya benar-benar perlu mem-porting aplikasi saya ke UWP atau jika tidak, ini tidak akan pernah berhasil.

Adapun tes yang lebih baru - https://github.com/microsoft/Win2D/issues/731

• Sangat lambat "waktu F5". Jadi masuk ke debug untuk membangun/memulai aplikasi untuk mencoba sesuatu setidaknya 10 x lebih lambat daripada di WPF. (pikirkan sekitar 2 menit pada Surface Book 2)

Oh ya! Saya bahkan tidak menyebutkan ini, tapi ya, ini sangat lambat. Saya telah menyiasatinya dengan mengutak-atik proyek apa yang saya kompilasi dan mana yang tidak - dan tergantung pada bagian mana dari aplikasi yang sedang saya kerjakan, ini layak atau buruk (dan dengan layak, maksud saya, kira-kira 10-15 detik sebagian besar waktu)

• Secara umum, dibatasi oleh kotak pasir.

Oh ya :)

• File API lambat tetapi untuk sementara @ duke7553 memposting solusi di # 1465 (komentar)

Setuju, tetapi pikirkan berapa lama waktu yang dibutuhkan seseorang untuk menemukan solusi itu -- yang jelas ada, tetapi terkubur dalam-dalam di dokumen. Dan saat ini, mungkin hanya sedikit orang yang menyadarinya (termasuk saya).

Jika Anda melakukan pencarian google, Anda tidak akan menemukan posting yang menunjukkan solusi itu, jadi mungkin perlu beberapa bulan sebelum sebagian besar pengembang menyadarinya.

@jasonwurzel

Jadi seperti banyak orang lain, kami sangat menantikan rilis dan pematangan WinUI 3, karena dapat memiliki frontend "UWP" dan .net core (atau .net 5 ;-) ) backend tanpa trik.

Hanya ingin menunjukkan bahwa MS mengatakan bahwa begitu .NET 5 mendarat, Anda akan dapat menggunakannya untuk proyek UWP Anda dengan baik. Tidak perlu "trik" atau situasi seperti .NET Core 3.x. Berikut adalah posting pengumuman .NET 5 lagi: https://devblogs.microsoft.com/dotnet/introducing-net-5/

ya, itu yang saya maksud 👍

Saya pikir kata "sepenuhnya" dalam _"benar-benar tidak berhubungan dengan kenyataan"_ tidak adil dan tidak akurat, tetapi @jtorjo sangat frustrasi karena alasan yang dapat dimengerti. Jika Microsoft benar -

Signifikansi GUI daftar-dengan-kolom

Meskipun tim WinUI mungkin adalah tim dengan kinerja terbaik dari semua tim yang terkait dengan UWP/WinRT, saya pikir beberapa kesalahan masih dilakukan dalam manajemen proyek WinUI. GUI daftar-dengan-kolom (seperti DataGrid ) adalah fitur utama penting yang digunakan setiap pelanggan setiap hari (seperti di Windows Explorer dan berbagai contoh lain seperti Spotify dll). Sejak awal WinRT, sudah 8 tahun tanpa dukungan resmi untuk GUI daftar-dengan-kolom! Saya merasa situasi ini mengejutkan. Untuk alasan itu dan lainnya, saya katakan bahwa UWP masih merupakan versi alpha hari ini (belum fitur-lengkap sehingga bukan beta yang sebenarnya). Tidak mengherankan bahwa sebagian besar pengembang aplikasi tidak pernah menganggap serius UWP, dan karenanya Windows Mobile akhirnya dibatalkan.

Versi resmi dari DataGrid WinUI telah jatuh tempo selama 8 tahun terakhir. DataGrid menjadi terlambat saat WinRT 1.0 dirilis karena Microsoft seharusnya tidak pernah memulai sistem baru (seperti yang saya jelaskan dalam pesan saya sebelumnya tentang Nokia dll). 8 tahun dengan dasar-dasar yang hilang, 8 tahun terlambat, dan sekarang tim WinUI ingin membuat DataGrid semakin terlambat dengan membuang lebih banyak waktu dengan menurunkan versi ke kode asli. Untuk beberapa alasan, sulit untuk menganggap serius UWP dan sulit untuk mempercayainya.

C++/CX baru-baru ini digantikan oleh C++/WinRT

Berikut adalah contoh lain dari menjadi "tidak berhubungan dengan kenyataan":
Jelas perangkat lunak perlu ditulis dengan cara yang waras (maksud saya "waras" sebagai terminologi, bukan penghinaan seperti "Kamu gila"). "Sane" sebagai terminologi berarti Anda tidak boleh menggunakan ilmu hitam berbelit-belit yang tidak jelas untuk menyelesaikan tugas sederhana yang sederhana.
C++/CX baru-baru ini digantikan oleh C++/WinRT. C++/WinRT menggunakan apa yang disebut _"pola template yang berulang secara aneh"_ untuk pemanggilan fungsi melalui pengiriman statis. Itu adalah desain yang sangat buruk karena itu bukan desain yang waras karena ini adalah kasus penggunaan sihir hitam yang tidak jelas untuk menyelesaikan tugas sederhana yang mudah. Selain itu, CLR/C# telah memecahkan masalah ini beberapa dekade yang lalu, oleh karena itu mengapa tim WinRT masih bermain-main dan membuang-buang waktu dengan topik yang sangat lama dan primitif yang sudah diselesaikan beberapa dekade yang lalu? Mengapa tim WinRT menciptakan kembali roda?

Saya menelusuri kode sumber BARU C++/WinRT dan kesan saya adalah bahwa itu adalah perangkat lunak berkualitas sangat rendah, tetapi tim WinRT melihatnya sebagai sangat canggih. Jadi "tidak berhubungan dengan kenyataan" adalah deskripsi yang akurat.

Sistem file UWP masih versi alpha

@jtorjo dan orang lain telah menyebutkan masalah kinerja API sistem file UWP. Performanya di bawah level yang diperlukan untuk menggambarkannya sebagai versi beta lengkap fitur. Alasan lain mengapa UWP FS API masih versi alpha adalah kurangnya kemampuan untuk memindahkan folder. 25 tahun yang lalu, Windows 95 memiliki kemampuan untuk memindahkan folder, tetapi UWP masih kehilangan kemampuan mendasar ini. Dalam beberapa hal, Windows 95 lebih kuat dari UWP. Dalam berbagai hal, WPF dan .NET Framework masih lebih kuat dari UWP. Microsoft mengharapkan pengembang aplikasi untuk menganggap serius UWP tetapi ini sangat tidak masuk akal (atau "tidak sesuai dengan kenyataan") karena Microsoft tidak pernah mengembangkan UWP dari tahap alfa ke beta.

Windows membuat asumsi bahwa ponsel seperti "App Dev" adalah pasar yang sedang booming, dan modern karena memiliki keamanan dan daya tahan baterai di jantungnya.

Mereka didorong keluar dari pasar Ponsel karena kekuatan pasar. Perangkat seperti Hololens dan Xbox mencoba menghapus dukungan warisan Win32 - untuk membuat pengembangan lebih sederhana bagi mereka, dan basis kode OS yang lebih ramping dan berkinerja lebih baik.

Taruhan ini belum sepenuhnya terbayar, tetapi cita-cita untuk pengiriman aplikasi dan model keamanan modern, adalah tujuan yang patut dipuji.

Jadi setelah beberapa pencarian jiwa Microsoft telah memutuskan untuk menguraikan kerangka aplikasi modern, dari kerangka UI.

WinUI 3.0 harus menjadi yang terbaik dari kedua dunia, memungkinkan akses ke sebagian besar API modern yang mendapat manfaat dari proyeksi bahasa, standar pengkodean modern, dan keakraban seluler. Tetapi juga memungkinkan aplikasi untuk menggunakan runtime Win32 dan .NET yang kurang aman tetapi lebih kuat.

Tentu saja mengandalkan akses Win32, akan membatasi platform apa yang akan mereka jalankan - dan siapa yang tahu ke mana pasar akan bergerak di tahun-tahun mendatang.

Saya akan menyarankan alih-alih mengeluhkan alasan dan keluhan lama yang sama - komunitas ini digunakan untuk menanyakan apa yang diinginkan pengembang ke depan, dan tidak menyalahkan atau mengomel dengan cara yang tidak memajukan proyek.

@mdtauk menulis:

Mereka didorong keluar dari pasar Ponsel karena kekuatan pasar.

Berbagai anggota staf UWP/WinRT sangat ingin mempercayai penjelasan itu, agar _merasa_ lebih baik tentang apa yang terjadi. Saya tidak percaya penjelasan itu. Saya percaya bahwa UWP gagal karena:

1. Salah urus, dan
2. Kegagalan untuk mengatasi masalah pengembang aplikasi yang terus-menerus menunda versi UWP aplikasi mereka karena kesan bahwa UWP belum siap dan masih belum siap untuk prime time, dan
3. Penggunaan berlebihan dari teknik rekayasa perangkat lunak lama yang tidak produktif, dan
4. Gagal mendapatkan kepercayaan dari mayoritas pengembang aplikasi, dan
5. Hal-hal yang membuat UWP terlihat konyol seperti mempromosikan penggunaan JavaScript daripada Java, yang berarti kegagalan untuk mengenali perbedaan antara bahasa scripting versus bahasa pemrograman.

Sayangnya, mengingat salah urus adalah alasan utama kegagalan UWP, sungguh ironis bahwa UWP ditulis dalam kode yang tidak dikelola karena kata "tidak dikelola" benar-benar merangkum alasan kegagalan: Salah urus kode sumber dan manajemen proyek.

@jtorjo menulis:

Asli, dalam konteks "kompilasi ke .net asli", saya pikir itu hal yang baik

Saya setuju. Perbedaannya adalah dalam pembuatan kode asli secara otomatis versus manual. Ketika kode asli diproduksi secara otomatis oleh kompiler atau alat, maka itu biasanya merupakan hal yang baik, sedangkan jika kode sumber asli adalah kode sumber yang ditulis secara manual , maka produktivitas, set fitur, dan keandalan sangat berkurang.

Jika Anda melihat kerangka waktu pengembangan WPF versus kerangka waktu pengembangan WinUI, maka pengembangan WPF jauh lebih cepat (produktivitas jauh lebih baik), terlepas dari kenyataan bahwa WinUI seharusnya lebih mudah/lebih cepat untuk dikembangkan daripada WPF karena WinUI menggunakan kembali banyak hal yang sama konsep yang _sudah_ dibuat untuk WPF. Sayangnya, Microsoft memilih untuk terlibat dalam penggunaan berlebihan teknik rekayasa perangkat lunak lama yang bertentangan dengan sudut pandang mereka sendiri sebelumnya dan menyabotase produktivitas mereka sendiri dan menyebabkan pengembang aplikasi terus-menerus menunda pengembangan aplikasi UWP.

Apa yang bisa dilakukan sekarang untuk menyelesaikan kesalahan masa lalu? Berhenti mengulangi kesalahan yang sama yang menyebabkan kegagalan UWP. Jangan melanjutkan seolah-olah tidak ada hal buruk yang terjadi. Saya akan menggunakan DataGrid sebagai contoh di sini: Tambahkan fitur baru ke DataGrid daripada menunda DataGrid lebih jauh. Jangan membuat DataGrid lebih dari 8 tahun terlambat dengan melakukan penulisan ulang/konversi manual yang tidak berguna ke kode asli.

Pengguna akhir tidak peduli apakah DataGrid ditulis dalam kode terkelola atau tidak, dan mereka tidak tahu apa arti istilah itu, jadi yang jauh lebih penting dan masuk akal adalah menyimpannya dengan kode terkelola apa adanya dan meningkatkan fungsionalitas/fitur DataGrid. Jumlah kode asli yang ditulis secara manual di UWP sudah merupakan situasi bencana, jadi mengapa memperburuk situasi dengan menulis lebih banyak kode asli dan bahkan lebih banyak kode usang berdasarkan Win16/32 dan COM?

Saya mengerti bahwa Anda tidak bisa begitu saja membuang semua kode usang, tetapi Anda BISA berhenti membuat situasi lebih buruk dari yang sudah ada. Artinya, berhenti menulis kode asli yang lebih antik. Buat kebijakan bahwa mulai sekarang, semua kode/proyek baru akan ditulis menggunakan teknik rekayasa perangkat lunak modern. Jangan turunkan kode terkelola yang sudah ada sebelumnya seperti DataGrid dll.

Sistem file UWP masih versi alpha
@jtorjo dan orang lain telah menyebutkan masalah kinerja API sistem file UWP. Performanya di bawah level yang diperlukan untuk menggambarkannya sebagai versi beta lengkap fitur. [...]

Saya menyebutkan ini sebelumnya dan saya akan menyebutkannya lagi - API StorageFolder/StorageFile adalah salah satu API terburuk yang pernah saya lihat. Kita berada di abad ke-21, dan saya perlu bertanya "oh tolong, bisakah saya memiliki akses ke ini? dan ke itu? dan kemudian menambahkannya ke FuturesAccessList yang hebat?"

Dan saya perlu meminta properti dasar secara tidak sinkron, seperti ukuran file? Saya tidak peduli alasan apa yang mungkin dimiliki ini, tapi itu tidak berhubungan dengan kenyataan sekarang.

Taruhan ini belum sepenuhnya terbayar, tetapi cita-cita untuk pengiriman aplikasi dan model keamanan modern, adalah tujuan yang patut dipuji.

Saya sangat setuju...

[....] Tentu saja mengandalkan akses Win32, akan membatasi platform apa yang akan mereka jalankan - dan siapa yang tahu ke mana pasar akan bergerak di tahun-tahun mendatang. [...]

Saya sepenuhnya setuju, tetapi, terlalu banyak memikirkan masa depan juga bisa menyusahkan...
Maksud saya - jika Anda membatasi akses Win32 sejak awal, porting library akan menjadi "tidak boleh digunakan", jadi Anda tidak akan memiliki hadiah, apalagi masa depan.

Dengan mengizinkan kami untuk juga menggunakan kode Win32, ya kami mungkin tidak dapat melakukan port ke platform lain (yang akan datang), tetapi setidaknya kami akan memiliki kode untuk hari ini. Dan besok, itu akan menjadi hari lain, dan ketika kami sampai di sana, kami akan mencari cara untuk mem-port kode kami jika kami benar-benar menginginkannya.

Tetapi saya melakukan apa yang harus diberikan pada pilihan, dan saya akan memahami risikonya.

Saya akan menyarankan alih-alih mengeluhkan alasan dan keluhan lama yang sama - komunitas ini digunakan untuk menanyakan apa yang diinginkan pengembang ke depan, dan tidak menyalahkan atau mengomel dengan cara yang tidak memajukan proyek.

Tidak yakin apakah ini ditujukan pada saya atau apa, saya bukan penutur asli bahasa Inggris. Karena itu, saya benar-benar ingin proyek ini maju, tetapi saya pikir penting untuk mengatasi beberapa masalah yang menghentikan kami dari penggelaran - hari ini.

Saya akan menyarankan alih-alih mengeluhkan alasan dan keluhan lama yang sama - komunitas ini digunakan untuk menanyakan apa yang diinginkan pengembang ke depan, dan tidak menyalahkan atau mengomel dengan cara yang tidak memajukan proyek.

Tidak yakin apakah ini ditujukan pada saya atau apa, saya bukan penutur asli bahasa Inggris. Karena itu, saya benar-benar ingin proyek ini maju, tetapi saya pikir penting untuk mengatasi beberapa masalah yang menghentikan kami dari penggelaran - hari ini.

Saya tidak menargetkan siapa pun, tetapi judul diskusinya sedikit negatif dan orang-orang cenderung tidak menanggapi dan membahas masalah yang sah, jika mereka dibungkus dengan penghinaan dan tuduhan.

Juga sekarang kita tahu bahwa kerangka aplikasi Win32/.NET akan datang dengan WinUI 3.0 - ada gunanya masih mengkritik mereka karena hanya WinRT di masa lalu. 😁

@jtorjo

Kita berada di abad ke-21, dan saya perlu bertanya "oh tolong, bisakah saya memiliki akses ke ini? dan ke itu? dan kemudian menambahkannya ke FuturesAccessList yang hebat?"

Fakta bahwa aplikasi harus bertanya kepada pengguna menurut saya merupakan langkah ke arah yang benar. Fakta bahwa tidak seperti aplikasi Winforms dan WPF, aplikasi ini tidak dapat begitu saja memindai semua file saya dan saya memiliki kendali atas folder mana yang dapat diaksesnya adalah hal yang sangat penting dari segi keamanan. Jika Anda berpikir bahwa itu buruk bahwa kami membatasi sumber daya yang dapat diakses aplikasi untuk melindungi pengguna, saya rasa itu adalah pandangan Anda, tetapi saya tidak ingin setiap aplikasi melakukan apa yang diinginkannya dengan file saya.

Dan saya perlu meminta properti dasar secara tidak sinkron, seperti ukuran file? Saya tidak peduli alasan apa yang mungkin dimiliki ini, tapi itu tidak berhubungan dengan kenyataan sekarang.

Saya kira alasannya adalah bahwa itu tidak boleh memblokir utas UI karena hal terburuk yang dapat terjadi dari titik UX adalah bahwa aplikasi tidak merespons lagi karena pengembang lupa bahwa operasi disk mungkin memerlukan sedikit waktu. Menggunakan menunggu Anda dapat mengatasi masalah dan memaksa Anda untuk membuka blokir utas UI di beberapa titik. (Setidaknya begitulah cara saya memahami async menunggu).

Seperti yang ditunjukkan oleh

Saya pikir kita semua harus ingat untuk mematuhi kode etik sumber terbuka Microsoft, tetap berdiskusi secara profesional dan menghormati semua orang terlepas dari apakah mereka hadir atau tidak.

https://opensource.microsoft.com/codeofconduct/

Fakta bahwa aplikasi harus bertanya kepada pengguna menurut saya merupakan langkah ke arah yang benar. Fakta bahwa tidak seperti aplikasi Winforms dan WPF, aplikasi ini tidak dapat begitu saja memindai semua file saya dan saya memiliki kendali atas folder mana yang dapat diaksesnya adalah hal yang sangat penting dari segi keamanan. Jika Anda berpikir bahwa itu buruk bahwa kami membatasi sumber daya yang dapat diakses aplikasi untuk melindungi pengguna, saya rasa itu adalah pandangan Anda, tetapi saya tidak ingin setiap aplikasi melakukan apa yang diinginkannya dengan file saya.

Jadi kita mulai dengan kerugian besar dibandingkan dengan aplikasi WPF. Itu satu hal - hal lainnya adalah

1. Saya sudah menanyakan itu saat instalasi.
2. Bahkan jika pengguna mungkin tidak memperhatikan, Windows sekali lagi dapat menunjukkan kepada pengguna "Aplikasi ini ingin mengakses file Anda" dan pengguna dapat mengatakan Ya/Tidak. Saya akan baik-baik saja dengan itu. Namun, ini JAUH dari apa yang terjadi.

Dan saya perlu meminta properti dasar secara tidak sinkron, seperti ukuran file? Saya tidak peduli alasan apa yang mungkin dimiliki ini, tapi itu tidak berhubungan dengan kenyataan sekarang.

Saya kira alasannya adalah bahwa itu tidak boleh memblokir utas UI karena hal terburuk yang dapat terjadi dari titik UX adalah aplikasi tidak merespons lagi karena pengembang lupa

Ukuran file harus diambil sebelumnya (sama dengan, tanggal akses terakhir/tanggal penulisan terakhir) - ini sangat penting, sehingga harus diambil sebelumnya saat Anda melakukan kueri untuk file.

Seperti yang ditunjukkan oleh

Saya benar-benar ingin ini diselesaikan, tidak ada yang lain.

Saya pikir kita semua harus ingat untuk mematuhi kode etik sumber terbuka Microsoft, tetap berdiskusi secara profesional dan menghormati semua orang terlepas dari apakah mereka hadir atau tidak.

Diskusi ini tidak akan terjadi di sini, seandainya kami benar-benar memiliki tempat untuk mengajukan pertanyaan-pertanyaan ini, dan bagi WinRT untuk mendengarkan umpan balik di tempat lain.

Saya tidak menargetkan siapa pun, tetapi judul diskusinya sedikit negatif dan orang-orang cenderung tidak menanggapi dan membahas masalah yang sah, jika mereka dibungkus dengan penghinaan dan tuduhan.

Saya setuju itu sedikit negatif, sekali lagi, ini tidak akan terjadi, seandainya ada tempat lain untuk memberikan umpan balik tentang masalah WinRT.

Juga sekarang kita tahu bahwa kerangka aplikasi Win32/.NET akan datang dengan WinUI 3.0 - ada gunanya masih mengkritik mereka karena hanya WinRT di masa lalu. 😁

Sejujurnya, saya sangat berharap ini terjadi. Saya pasti akan menunggu masalah ini diselesaikan, dan secara pribadi tidak sabar menunggu platform non-kotak pasir itu tersedia. Tetapi sampai saat itu, saya masih mengerjakan sebuah aplikasi, dan masih menghadapi masalah yang saya uraikan di tempat pertama.

Jadi kita mulai dengan kerugian besar dibandingkan dengan aplikasi WPF. Itu satu hal - hal lainnya adalah

Untuk memperjelas, membiarkan penggunaan pilihan untuk menolak aplikasi mengakses semua file adalah kerugian menurut Anda?
Kami sebagai pengembang harus mengembangkan perangkat lunak untuk pengguna bukan untuk melawan mereka. Dan membuat pengguna tidak punya pilihan tentang data apa yang dilihat aplikasi Anda adalah kerugian keamanan bagi pengguna, menurut saya.

1. Saya sudah menanyakan itu saat instalasi.

Apakah maksud Anda kemampuan "broadFileSystemAccess"? Menurut pendapat saya, sangat sedikit aplikasi yang memiliki alasan yang sah untuk memiliki kemampuan ini. (seperti yang sudah ditunjukkan oleh @kmgallahan )
Lihat saja semua aplikasi yang Anda gunakan sehari-hari. Berapa banyak dari mereka yang membutuhkan akses ke semua file sepanjang waktu? Mungkin tidak begitu banyak, bahkan jika ada.

Seperti yang Anda katakan dalam komentar awal Anda:

Apakah menurut Anda pengguna akan dengan senang hati melakukan hal di atas? Tidak, mereka tidak akan melakukannya - kenyataannya, 79,8% tidak melakukannya (data AppCenter saya mendukungnya).

Saya pikir mungkin ada alasan mengapa pengguna tidak senang melakukan ini (selain fakta bahwa ini adalah pengaturan keamanan yang harus mereka ubah).

Namun saya mungkin tidak mengetahui semua kasus bisnis yang memerlukan akses ke semua file, jadi jika ada, saya senang mendengarnya. Pada akhirnya kita di sini bukan untuk bertarung tetapi untuk saling memperkaya sudut pandang (semoga)

Sunting:

Ukuran file harus diambil sebelumnya (sama dengan, tanggal akses terakhir/tanggal penulisan terakhir) - ini sangat penting, sehingga harus diambil sebelumnya saat Anda melakukan kueri untuk file.

Oh benar, ya beberapa dari itu pasti harus diambil sebelumnya. Saya setuju bahwa ini agak merepotkan bagi kami pengembang.

Diskusi ini tidak akan terjadi di sini, seandainya kami benar-benar memiliki tempat untuk mengajukan pertanyaan-pertanyaan ini, dan bagi WinRT untuk mendengarkan umpan balik di tempat lain.

Secara resmi hub umpan balik adalah untuk itu (saya pikir) tapi ya rasanya agak tidak responsif kadang-kadang. Semoga hub umpan balik membaik. Dari apa yang saya lihat, mereka telah membuat beberapa perubahan dari waktu ke waktu, jadi saya pikir ini akan berubah juga.

@Felix-Dev

Ini postingan pengumuman .NET 5 lagi

Terima kasih telah menautkannya. Saya terutama menemukan bagian ini menarik, dan saya yakin ini adalah berita positif:

"Interoperabilitas Java akan tersedia di semua platform.

Ada juga sedikit diskusi Java di komentar di akhir halaman web itu, di mana Rich Lander mengkonfirmasi interop dua arah. Saya menafsirkan ini sebagai tanda positif bahwa Microsoft kembali berhubungan dengan kenyataan. Saya bukan penggemar Java (saya lebih suka C#), tetapi saya mengakui bahwa interoperabilitas Java sangat bermanfaat dan seharusnya menjadi fokus di UWP/WinRT sejak awal. Jika UWP/WinRT telah memberikan prioritas utama ke Java dan C# (kode terkelola) alih-alih kode asli lama yang kikuk (C++/CX, Win16/32, COM), dan jika UWP tidak mencampuradukkan tujuan JavaScript versus Java, maka UWP akan menarik lebih banyak pengembang aplikasi, dan Windows Mobile mungkin masih hidup hari ini.

Suka atau tidak, kita perlu bangun dan mengakui realitas situasi: Pemimpin pasar adalah Android dengan fokusnya pada pengembangan aplikasi Java. Java dan C# berarti kode terkelola. Microsoft membuat kesalahan yang sangat mahal ketika membalikkan sudut pandangnya pada kode yang dikelola.

Meskipun saya tidak terlalu menyukai Java, jelas bagi saya bahwa teknik Java Android jauh lebih baik daripada cara lama yang kikuk di mana Microsoft mengembangkan WebView2 dengan menggunakan teknik pemrograman Win16 antik seperti pointer 16-bit versus 32-bit , dan HRESULT alih-alih penanganan pengecualian modern, dll. WebView2 menggunakan LPCWSTR dan L berarti "penunjuk panjang" yang berarti penunjuk 32-bit sebagai lawan dari penunjuk 16-bit pointer "pendek" di Win16. W berarti "karakter lebar" yang berarti Unicode (UTF-16) sebagai lawan dari karakter ASCII/ANSI 8-bit. Sebagai perbandingan, penggunaan Java oleh Android jauh lebih profesional, modern, dan membangkitkan kepercayaan daripada yang dilakukan beberapa departemen Microsoft.

Jadi pada catatan positif, itu adalah berita yang sangat bagus untuk mendengar bahwa Microsoft akan mendukung Java (walaupun secara pribadi saya lebih suka C# daripada Java). Pengembang aplikasi Android akan meningkatkan minat mereka pada Windows segera setelah interop Java andal yang baik dirilis.

Juga sekarang kita tahu bahwa kerangka aplikasi Win32/.NET akan datang dengan WinUI 3.0 - ada gunanya masih mengkritik mereka karena hanya WinRT di masa lalu. 😁

1. Masa depan cerah, saya suka apa yang saya lihat sedang dikembangkan di WinUI.
2. Masa lalu cukup suram, untuk platform dengan 900 JUTA perangkat, prevalensi UWP yang buruk sulit dipertahankan. EDIT: masa lalu adalah satu-satunya tempat kita bisa belajar, jadi penting untuk didiskusikan.
3. Saat ini , saya pikir, adalah poin utama dari utas ini dan tidak dibahas. Jika seseorang ingin memulai hari ini aplikasi non-sepele yang akan membutuhkan waktu 1-1,5 tahun untuk dikembangkan, saran jujur ​​apa yang dapat diberikan? Jawaban saya adalah: bereksperimen dengan WinUI, buat lib Anda di dotnet Core, dan tunggu hingga WinUI3.0 keluar untuk benar-benar mulai membuat aplikasi Anda. Jangan repot-repot dengan UWP karena Anda akan ingin membuangnya dari aplikasi Anda, Anda mungkin tidak ingin platform yang berbeda karena yang 900 juta cukup besar. Pertanyaan-pertanyaan tentang masa kini bukanlah hal sepele, keputusan bisnis perlu dibuat hari ini.

Apa yang tidak dikatakan, tetapi apa yang sebenarnya terjadi adalah bahwa UWP dan UI modern tidak diperluas ke win32, tetapi sebenarnya UWP sedang di-refactored OUT dari stack . Mengapa ada orang yang ingin berurusan dengan UWP ketika mereka dapat menggunakan kekuatan dotnet standard 2 dan dotnet core 3 dan semua lib yang tersedia dengan itu?

Tentang sandboxing dan ide-ide bagus lainnya yang diperkenalkan di UWP: itu adalah ide-ide bagus, tetapi bisa dieksekusi jauh lebih baik. Saya berharap mereka akan kembali dan akan ada kemungkinan OPT-IN menjadi sandbox atau OPT-IN menjadi manajemen negara yang mirip dengan UWP. Sebagai pengembang kami ingin melayani pengguna tetapi di UWP kami diancam sebagai masalah yang harus ditampung oleh platform.

Nasihat jujur ​​apa yang bisa diberikan? Tunggu?

@AndrewPawlowski Jika Anda telah menentukan bahwa UWP dan kotak pasir tidak berfungsi untuk Anda, saya pikir menulis aplikasi WPF paket MSIX adalah pilihan yang baik hingga WinUI 3 mendarat. Anda sudah dapat memanggil Windows 10 API eksklusif, memberi pengguna pengalaman menginstal/mencopot pemasangan modern dan umumnya memilih dari permukaan Windows 10 API apa yang Anda suka dan apa yang tidak (yaitu Anda dapat mulai menggunakan Windows 10 Shell API). Beberapa API WinRT benar-benar menyenangkan untuk digunakan dibandingkan dengan cara win32 sebelumnya dan beberapa skenario yang saya yakini bahkan dilakukan paling baik di DesktopBridge daripada UWP murni. Contoh kasus: Mendaftarkan aplikasi untuk mulai otomatis saat masuk, lihat posting ini untuk perbandingan perilaku UWP vs DesktopBridge. Dalam kasus DesktopBridge, Anda tetap, pada akhirnya, membiarkan pengguna memegang kendali, tetapi pengguna tidak akan terus-menerus ditanya dua kali (pertama, sakelar di aplikasi, lalu prompt sistem yang meminta konfirmasi) saat mengaktifkan mulai saat log- di dalam aplikasi.

Sayangnya, banyak bagian dari API WPF benar-benar menunjukkan usia mereka sekarang jika dibandingkan dengan API UI UWP sehingga Anda hanya perlu hidup dengan itu beberapa bulan lagi (setidaknya). Banyaknya toolkit WPF yang tersedia akan mengurangi fakta ini, tetapi jika Anda benar-benar menginginkan tampilan dan nuansa asli untuk aplikasi desktop Windows Anda (dan pengalaman pengembangan XAML modern!), Anda benar-benar tidak akan dapat keluar dari API UI UWP (dan kemudian API WinUI 3). Itu berarti, bahkan jika Anda dapat menggunakan kembali beberapa kode UI WPF untuk WinUI nanti, memodernisasi UI masih akan menjadi item pekerjaan yang agak besar yang saya yakini.

Itulah keadaan pengembangan aplikasi windows asli yang saat ini saya lihat untuk Anda jika Anda tidak dapat menunggu hingga WinUI 3 dikirimkan dan UWP bukanlah pilihan untuk Anda.

@AndrewPawlowski

1. Masa depan cerah, saya suka apa yang saya lihat sedang dikembangkan di WinUI.

Setuju

1. Masa lalu cukup suram, untuk platform dengan 900 JUTA perangkat, prevalensi UWP yang buruk sulit dipertahankan. EDIT: masa lalu adalah satu-satunya tempat kita bisa belajar, jadi penting untuk didiskusikan.
2. Saat ini , saya pikir, adalah poin utama dari utas ini dan tidak dibahas. Jika seseorang ingin memulai hari ini aplikasi non-sepele yang akan membutuhkan waktu 1-1,5 tahun untuk dikembangkan, saran jujur ​​apa yang dapat diberikan? Jawaban saya adalah: bereksperimen dengan WinUI, buat lib Anda di dotnet Core, dan tunggu hingga WinUI3.0 keluar untuk benar-benar mulai membuat aplikasi Anda. Jangan repot-repot dengan UWP karena

Pikiran awal saya adalah sama, tetapi saya tidak menunggu ....

Tentang sandboxing dan ide-ide bagus lainnya yang diperkenalkan di UWP: itu adalah ide-ide bagus, tetapi bisa dieksekusi jauh lebih baik.

Setuju 100%

Namun saya mungkin tidak mengetahui semua kasus bisnis yang memerlukan akses ke semua file, jadi jika ada, saya senang mendengarnya. Pada akhirnya kita di sini bukan untuk bertarung tetapi untuk saling memperkaya sudut pandang (semoga)

Di mana pun Anda ingin mempratinjau hal-hal, Anda akan menginginkan akses cepat ke file. Dalam kasus saya, saya ingin mempratinjau folder untuk secara visual menunjukkan kepada pengguna di mana foto/video berada, dan untuk video, saya ingin pengguna melihat pratinjau video sebelum memilihnya. Intinya adalah: file picker menawarkan pengalaman yang cukup sub-par, dan saya ingin memperkaya itu.

Secara resmi hub umpan balik adalah untuk itu (saya pikir) tapi ya rasanya agak tidak responsif kadang-kadang. Semoga hub umpan balik membaik. Dari apa yang saya lihat, mereka telah membuat beberapa perubahan dari waktu ke waktu, jadi saya pikir ini akan berubah juga (^∇^)

Secara pribadi saya tidak suka hub umpan balik - terlalu tidak spesifik, di antara masalah lainnya.

@jtorjo @chingucoding hub umpan balik untuk WinRT API mungkin segera diganti/dipasangkan dengan Microsoft Q&A, lihat komit ini: https://github.com/MicrosoftDocs/winrt-api/commit/efcc4e041122e8a816a12c0581199c2f36ba36fc

Melihat Chigusa telah disebutkan di sana: @chigy Akankah platform Tanya Jawab Microsoft menjadi platform umpan balik yang disukai untuk API WinRT non WinUI? Jika tidak, bagaimana hubungannya dengan hub umpan balik (mis. mengajukan bug/pertanyaan pada T&J, permintaan API pada hub umpan balik,....)?

Semoga kita tidak berakhir dengan tiga platform umpan balik yang berbeda

Karena ini adalah diskusi tentang UWP, saya dapat mempromosikan permintaan fitur: Izinkan kata kerja menu konteks dengan integrasi file explorer tanpa memiliki asosiasi tipe file https://aka.ms/AA71n2t btw. https://aka.ms/AA6rmrk ( tetapi dalam kategori yang salah - mungkin seseorang dapat memperbaikinya?)

Sumber permintaan fitur yang baik adalah:
https://web.archive.org/web/20161221051552/https://wpdev.uservoice.com/forums/110705-universal-windows-platform/category/171141-missing-apis
Sayang sekali snapshot dari uservoice ini cukup lama (2016). Saya ingat ada hal-hal seperti:

• menyelaraskan perilaku permintaan broadFileSystemAccess seperti yang akan dilakukan saat meminta kamera, lokasi, memulai aplikasi saat startup...
• mobil. pencetakan (saat ini hanya didukung untuk POS di IoT sejauh yang saya ingat)
• membuat pencetakan lebih dapat dikonfigurasi

@jtorjo

Di mana pun Anda ingin mempratinjau hal-hal, Anda akan menginginkan akses cepat ke file. Dalam kasus saya, saya ingin mempratinjau folder untuk secara visual menunjukkan kepada pengguna di mana foto/video berada, dan untuk video, saya ingin pengguna melihat pratinjau video sebelum memilihnya. Intinya adalah: file picker menawarkan pengalaman yang cukup sub-par, dan saya ingin memperkaya itu.

Dugaan saya adalah untuk itu Anda terlebih dahulu membiarkan pengguna memilih folder tempat dia ingin menggunakan aplikasi Anda. Lagi pula, pengguna paling tahu di mana dia menyimpan videonya.

Jika tidak, Anda mungkin ingin melihat:
https://docs.microsoft.com/en-us/windows/uwp/files/quickstart-managing-folders-in-the-music-pictures-and-videos-libraries

Tapi sejujurnya, saya tidak tahu persis apa yang akan broadFileSystemAccess akan membantu Anda dalam kasus itu. Anda tidak dapat memastikan di mana tepatnya file tersebut (tidak seperti pengguna). Tapi mungkin saya tidak sepenuhnya memahami ide aplikasi Anda dengan benar.

@Felix-Dev
Terima kasih atas informasinya, tidak tahu bahwa umpan balik WinRT mungkin bergerak.

Semoga kita tidak berakhir dengan tiga platform umpan balik yang berbeda

Haha iya semoga tidak!

@jtorjo -- Sudahkah Anda mempertimbangkan untuk membatalkan porting aplikasi Anda dari WPF ke UWP? Anda dapat membatalkannya dan menunggu hingga WinUI 3 dirilis, dan kemudian Anda tidak akan dipaksa untuk menggunakan API sistem file UWP yang bermasalah, broadFileSystemAccess, dll. Sementara itu, sambil menunggu WinUI 3, Anda dapat melanjutkan ke berikan versi baru aplikasi Anda kepada pengguna dengan terus mengembangkan versi WPF aplikasi Anda.

Selama 8 tahun sejak awal WinRT, kami tidak pernah benar-benar memberikan aplikasi WinRT atau UWP kepada pengguna kami. Sebaliknya, kami telah memberi mereka banyak pembaruan yang terus menggunakan versi WPF dari perangkat lunak kami. Pengguna kami tidak memiliki keluhan tentang hal ini karena mereka tidak peduli dengan detail teknologi seperti WPF, WinUI, UWP, melainkan mereka peduli dengan seberapa baik aplikasi bekerja dan fungsionalitas apa yang dimilikinya. Pengguna kami juga tidak memiliki keluhan tentang GUI lama karena aplikasi WPF kami menyertakan banyak modernisasi GUI.

@AndrewPawlowski mengatakan "eksperimen dengan WinUI". Ya, percobaan. Saya telah menulis banyak kode untuk UWP dan WinUI selama bertahun-tahun, tetapi semuanya adalah kode eksperimental, alfa, atau beta. Saya tidak pernah mencapai titik di mana saya cukup nyaman untuk merilis aplikasi UWP apa pun kepada pengguna.

Pemisahan WinUI 3 dari UWP sangat membantu, tapi saya rasa itu bukan solusi lengkap. WinUI 3 tidak mengatasi produktivitas rendah / lambatnya pengembangan WinUI: WPF dikembangkan jauh lebih cepat daripada WinUI, meskipun WPF lebih sulit daripada WinUI.

Tim WinUI mengatakan kecepatannya akan meningkat ketika WinUI 3 adalah open source, dan mungkin akan, tetapi secara pribadi saya tidak akan menulis kontribusi C++/CX, C++/WinRT, Win16/32, atau COM untuk WinUI 3. Saya memulai karir saya dengan Win16/Win32 beberapa dekade yang lalu, dan Win32 adalah mimpi buruk, dan saya tidak berniat untuk kembali ke teknik pemrograman lama dan bermasalah seperti itu. Selama bertahun-tahun, saya terus memperbarui keterampilan rekayasa perangkat lunak saya dan saya beralih ke C# dan .NET Framework, dan itu merupakan peningkatan dan manfaat besar, dan saya tidak akan kembali ke mimpi buruk Win16/32 yang lama. hari dan sejumlah besar kode asli yang ditulis secara manual.

@AndrewPawlowski menulis:

Nasihat jujur ​​apa yang bisa diberikan? Tunggu?

Itu pertanyaan yang sangat sulit untuk dijawab. Di satu sisi, ya tunggu saja WinUI 3, namun di sisi lain, WinUI 3 bukanlah solusi penuh dari masalah besar yang digagas WinRT 8 tahun lalu. WinUI 3 adalah resolusi parsial yang membantu.

Video Hebat dari Ignite: https://youtu.be/Ul5JcdIJv5s

Saya pikir banyak diskusi di sini mempertanyakan tujuan WinRT. Pengembang dan pengguna masih bertanya-tanya peran apa yang akan dimainkannya setelah WinUI 3 dan .NET 5.0 memungkinkan inter-op yang mudah antara teknologi yang berbeda. Belum lagi, kemampuan akhirnya untuk memilih antara model aplikasi kotak pasir vs klasik.

Saya berasumsi menulis API WinRT baru lebih mudah dilakukan Microsoft secara internal, yang menjelaskan mengapa mereka telah menyatakan berkali-kali sebelumnya bahwa sebagian besar inovasi lapisan API akan dilakukan dalam WinRT. Ini berarti bahwa untuk aplikasi Windows baru yang modern, masuk akal untuk menggunakan WinRT karena akan memiliki integrasi terbaru dan terhebat dengan pengalaman baru yang akan datang dengan faktor bentuk baru. WinRT hanya dimaksudkan sebagai kumpulan API Universal tertentu yang menyala di aplikasi .NET Anda di Windows.

Dengan itu, saya pikir kita semua setuju bahwa itu akan membuat aplikasi Universal lebih berharga jika UWP Desktop Extension Pack memiliki kemampuan integrasi yang lebih baik dengan Windows Shell yang ada.

Siapa tahu, Microsoft mungkin memiliki rencana untuk akhirnya mengganti Windows Explorer Shell dengan Composable Shell (CShell) yang lebih baru yang ditemukan di Windows 10X, dll. Para ahli di Twitter juga telah menemukan UDK (Undocking Development Kit) baru yang ditemukan di Windows yang memungkinkan untuk integrasi yang lebih baik dengan shell baru ini di masa depan.

@AndrewPawlowski

Anda mungkin tidak ingin platform yang berbeda karena yang 900 juta cukup besar.

Sementara saya mengerti apa yang Anda maksud, Anda harus menyadari bahwa UWP dan .NET bukan lagi hal yang saling eksklusif ini, jadi jika masuk akal untuk meluncurkan aplikasi Anda dengan fitur Universal, seseorang harus berinvestasi dalam memahami bagian-bagian WinRT.

saya ngelantur. Sebagai salah satu yang membangun pesaing Windows File Explorer dengan model aplikasi murni-UWP, WinUI 3 tidak bisa datang cukup cepat. Dalam waktu dekat, Anda tidak perlu memilih antara menggunakan fitur Universal dan "900 juta pengguna"

@jtorjo Saya akan menyarankan untuk mengubah judul yang akan dianggap kurang negatif, sehingga lebih banyak orang akan memberikan masukan di sini.
Mungkin "Peluang untuk menambah nilai pada WinRT"

@verelpode

@jtorjo -- Sudahkah Anda mempertimbangkan untuk membatalkan porting aplikasi Anda dari WPF ke UWP? Anda dapat membatalkannya dan menunggu hingga WinUI 3 dirilis, dan kemudian Anda tidak akan dipaksa untuk menggunakan API sistem file UWP yang bermasalah, broadFileSystemAccess, dll. Sementara itu, sambil menunggu WinUI 3, Anda dapat melanjutkan ke berikan versi baru aplikasi Anda kepada pengguna dengan terus mengembangkan versi WPF aplikasi Anda.

Saya berpikir panjang dan keras tentang ini - inilah yang ingin saya lakukan. Tapi saya tidak bisa tidak melakukannya, karena saya benar-benar membutuhkan win2d (atau lebih tepatnya, pembungkus yang bagus untuk Direct2D). ShapDX (pembungkus lain dari Direct2D) tampak jauh lebih rumit, jadi saya memilih untuk menggunakan win2d (yaitu UWP). Oleh karena itu, port semuanya ke UWP.

Dugaan saya adalah untuk itu Anda terlebih dahulu membiarkan pengguna memilih folder tempat dia ingin menggunakan aplikasi Anda. Lagi pula, pengguna paling tahu di mana dia menyimpan videonya.

Apakah Anda benar-benar mempertaruhkan hidup Anda untuk itu? Saya tidak akan - jelas, jika Anda adalah pengguna tingkat lanjut, Anda mungkin sangat terorganisir, dan tahu di mana setiap hal berada. Sebaliknya....

Dan kemudian, setiap kali Anda (pengguna), entah bagaimana menyalin foto/video ke folder baru, Anda harus ingat untuk memberi tahu aplikasi saya untuk memasukkannya juga...

Bukan untuk mengatakan bahwa FutureAccessList "hebat" - tidak benar-benar menentukan -> jika saya menambahkan folder, apakah semua subfoldernya dapat diakses oleh aplikasi saya?

Juga, jika saya telah menambahkan sesuatu ke FutureAccessList, apakah saya perlu mengambilnya dari sana atau dapatkah saya mendapatkannya dengan GetFolderFromPathAsync/GetFileFromPathAsync (ini yang pertama, saya lebih suka melompat dari tebing)?

Dan tahukah Anda, bahwa jika menggunakan FutureAccessList.AddOrReplace, dan menggunakan path file sebagai token, Anda mendapatkan pengecualian? Betapa bijaksananya... (tidak ada di deskripsi)

WinUI 3 dan .NET Core akan menjadi opsi di masa mendatang - Saya berasumsi bahwa kombinasi, tanpa kotak pasir UWP akan bekerja dengan cara yang sama seperti WPF, tetapi dengan kontrol XAML yang lebih baru, Lapisan Visual, dan akses API WinRT sederhana.

Dugaan saya adalah untuk itu Anda terlebih dahulu membiarkan pengguna memilih folder tempat dia ingin menggunakan aplikasi Anda. Lagi pula, pengguna paling tahu di mana dia menyimpan videonya.

Apakah Anda benar-benar mempertaruhkan hidup Anda untuk itu? Saya tidak akan - jelas, jika Anda adalah pengguna tingkat lanjut, Anda mungkin sangat terorganisir, dan tahu di mana setiap hal berada. Sebaliknya....

Nah jika Pengguna tidak tahu di mana dia menyimpan videonya, apa yang harus dilakukan aplikasi Anda? Pindai semua file dalam sistem, yang bahkan dengan perangkat lunak tercepat pun dapat memakan waktu berjam-jam? Setidaknya bagi saya ini sepertinya bukan pengalaman yang baik. Lagi pula, jika aplikasi Anda ditargetkan untuk pengguna yang ingin melakukan sesuatu dengan video, pengguna sudah agak "teratur" dalam arti bahwa mereka tahu mereka memiliki video di suatu tempat. Tetapi sekali lagi, hanya pemikiran saya tanpa benar-benar mengetahui aplikasi Anda dan kasus bisnis tertentu.

Dan kemudian, setiap kali Anda (pengguna), entah bagaimana menyalin foto/video ke folder baru, Anda harus ingat untuk memberi tahu aplikasi saya untuk memasukkannya juga...

Saya pikir jika Anda memiliki akses ke direktori induk, Anda juga dapat mengakses folder anak di masa mendatang (meskipun saya tidak 100% yakin).

Dan tahukah Anda, bahwa jika menggunakan FutureAccessList.AddOrReplace, dan menggunakan path file sebagai token, Anda mendapatkan pengecualian? Betapa bijaksananya... (tidak ada di deskripsi)

Itu aneh, ini adalah sesuatu yang pasti harus didokumentasikan!

Secara pribadi saya bukan penggemar aplikasi yang meminta "broadFileSystemAccess" karena banyak dari mereka tidak membutuhkannya. Mungkin ada beberapa kasus yang masuk akal (menulis file explorer dll) tetapi banyak kasus yang memerlukan akses ke BEBERAPA folder tidak boleh dilanjutkan dan mengatakan "tolong izinkan saya mengakses semua file", karena Anda juga dapat meminta bahwa folder pada khususnya.

Tapi mungkin saya tidak tahu cukup banyak kasus bisnis untuk itu. Jika ada lebih banyak, saya akan senang mendengarnya!

Tapi mungkin saya tidak tahu cukup banyak kasus bisnis untuk itu. Jika ada lebih banyak, saya akan senang mendengarnya!

• perangkat lunak alat dan utilitas, seperti alat kompresi (de). Jika Anda ingin mengekstrak file terkompresi di direktori yang sama di mana file saat ini berada dan ketika aplikasi dipanggil oleh menu konteks windows explorer, Anda hanya mendapat akses tulis ke file yang dipilih. Jadi tidak akan dapat membuat file atau direktori baru (untuk file yang tidak terkompresi).

  • Jika pengguna menyeret file ke aplikasi uwp Anda, Anda tidak memiliki akses tulis ke file itu!
    https://stackoverflow.com/questions/48001601/c-sharp-uwp-drag-and-drop-file-folder-permission?rq=1

seperti alat (de)kompresi. Jika Anda ingin mengekstrak file terkompresi di direktori yang sama di mana file saat ini berada dan ketika aplikasi dipanggil oleh menu konteks windows explorer, Anda hanya mendapat akses tulis ke file yang dipilih. Jadi tidak akan dapat membuat file atau direktori baru (untuk file yang tidak terkompresi).

Saya pikir sangat bisa diperdebatkan apakah Anda harus mendapatkan akses ke seluruh folder ketika Anda mengklik kanan satu file atau tidak. Meskipun tbh saya biasanya menentukan folder yang berbeda saat mengompresi/membuka kompresi karena saya biasanya membutuhkannya hanya untuk "pertukaran" yaitu cadangan atau unduhan/unggahan. Jadi bagi saya hampir perlu untuk menentukan di mana tepatnya untuk menyimpan file. Tapi ini mungkin kasus penggunaan yang valid tergantung pada pilihan pengguna

Jika pengguna menyeret file ke aplikasi uwp Anda, Anda tidak memiliki akses tulis ke file itu!
https://stackoverflow.com/questions/48001601/c-sharp-uwp-drag-and-drop-file-folder-permission?rq=1

Yah itu sepertinya agak terlalu rumit untuk pengguna dan pengembang. Saya berharap Anda mendapatkan setidaknya akses tulis ke file yang dijatuhkan. Menurut pendapat saya ini hanya kendala yang tidak perlu untuk devs.

Meskipun setidaknya dalam penggunaan aplikasi saya sehari-hari, saya hanya memasukkan file ke komentar GitHub. Untuk setiap kasus lain saya hanya klik dua kali atau klik kanan, tetapi setuju dalam beberapa kasus itu tidak bagus. Saya kira ada beberapa kasus di mana masuk akal untuk memiliki akses ke semua file.

Nah jika Pengguna tidak tahu di mana dia menyimpan videonya, apa yang harus dilakukan aplikasi Anda? Pindai semua file dalam sistem, yang bahkan dengan perangkat lunak tercepat pun dapat memakan waktu berjam-jam? ...

Jelas ada banyak kemungkinan, salah satunya adalah, ketika pengguna memperluas folder, untuk mempratinjaunya - jadi dia dengan mudah melihat folder mana yang memiliki foto/video, dan mana yang tidak. Satu hal yang benar-benar akan dilakukan aplikasi saya, jika Windows mengizinkan saya

Secara pribadi saya bukan penggemar aplikasi yang meminta "broadFileSystemAccess" karena banyak dari mereka tidak membutuhkannya.

Aku tidak peduli. Model perlindungan sistem file kotak pasir WinRT tidak sesuai dengan kenyataan. Ini adalah sesuatu yang diambil seseorang dari mantra "Mobile first" yang hebat, yang tidak berlaku untuk desktop.

Faktanya, cara yang lebih cerdas untuk meng-sandbox file/folder adalah membiarkan pengguna memutuskan file/folder mana yang ingin dia lindungi - seharusnya ada cara yang sangat mudah untuk melakukannya (seperti, mungkin di File Explorer, dengan perintah klik kanan) .

Ini berbeda dengan memblokir semuanya secara default, dan kemudian pengguna secara tidak sengaja memberi Anda akses ke file rahasia secara tidak sengaja.

Biarkan saya berterus terang di sini - aplikasi non-sepele apa pun tidak hidup dalam ruang hampa.

Jelas ada banyak kemungkinan, salah satunya adalah, ketika pengguna memperluas folder, untuk mempratinjaunya - jadi dia dengan mudah melihat folder mana yang memiliki foto/video, dan mana yang tidak. Satu hal yang benar-benar akan dilakukan aplikasi saya, jika Windows mengizinkan saya

Ya itu kemungkinan. Tapi kapan Anda akan memindai folder? Dan folder mana yang dapat diperluas pengguna di aplikasi Anda?

Aku tidak peduli.

Apa sebenarnya yang Anda coba katakan di sini?

Sebenarnya, cara yang lebih cerdas untuk meng-sandbox file/folder adalah membiarkan pengguna memutuskan file/folder mana yang ingin dia lindungi - seharusnya ada cara yang sangat mudah untuk melakukannya (seperti, mungkin di File Explorer, dengan perintah klik kanan) . Pengguna akan mengetahui dengan jelas dokumen/file apa yang bersifat rahasia, dan melindunginya.

Saya rasa seluruh perlindungan akses ini bukan hanya tentang file "rahasia" tetapi privasi secara umum, misalnya file konfigurasi (yang biasanya tersembunyi di folder yang tidak dilihat pengguna) atau hanya program mana yang diinstal. Ini adalah informasi yang saya tidak ingin setiap program dapat mengakses, terutama "aplikasi sepele" seperti yang Anda sebut.

Dan ada juga analogi dunia nyata - pikirkan saja seif.

Ya, Anda dapat melihat barang-barang di brankas. Tapi ini tidak mengubah fakta bahwa Anda memiliki kunci flat atau rumah Anda. Tetapi mengatakan bahwa setiap program dapat mengakses semuanya kecuali di brankas adalah seperti mengatakan, Anda tidak memerlukan pintu untuk apartemen Anda karena Anda memiliki brankas untuk barang-barang berharga Anda.

Ini berbeda dengan memblokir semuanya secara default, dan kemudian pengguna secara tidak sengaja memberi Anda akses ke file rahasia secara tidak sengaja.

Kesalahan ini dapat terjadi dalam kedua kasus, tetapi saya pikir lebih mungkin untuk lupa mengunci file rahasia daripada secara tidak sengaja memberikan akses ke file rahasia.

Biarkan saya berterus terang di sini - aplikasi non-sepele apa pun tidak hidup dalam ruang hampa. Itu perlu mendapatkan data dari suatu tempat (input) dan mengeluarkannya di suatu tempat. Input dan output sering berupa file - Anda perlu bekerja sama dengan aplikasi lain dan seterusnya. Dan WinRT membuat saya tidak mungkin mendesain UI yang bagus untuk diberikan kepada pengguna saya.

Mengatakan tidak mungkin adalah peregangan di sini karena ada banyak aplikasi UWP yang bagus (meskipun sayangnya tidak banyak).

Ya itu kemungkinan. Tapi kapan Anda akan memindai folder? Dan folder mana yang dapat diperluas pengguna di aplikasi Anda?

Apakah Anda akrab dengan konsep Windows Explorer? Anda memperluas folder atau drive - saat itulah saya akan mulai memindai

Saya rasa seluruh perlindungan akses ini bukan hanya tentang file "rahasia" tetapi privasi secara umum, misalnya file konfigurasi (yang biasanya tersembunyi di folder yang tidak dilihat pengguna) atau hanya program mana yang diinstal. Ini adalah informasi yang saya tidak ingin setiap program dapat mengakses, terutama "aplikasi sepele" seperti yang Anda sebut.

Ini bukan masalah, jika aplikasi akan menyimpan filenya di folder "hanya aplikasi ini yang dapat mengaksesnya".

Ini berbeda dengan memblokir semuanya secara default, dan kemudian pengguna secara tidak sengaja memberi Anda akses ke file rahasia secara tidak sengaja.

Kesalahan ini dapat terjadi dalam kedua kasus, tetapi saya pikir lebih mungkin untuk lupa mengunci file rahasia daripada secara tidak sengaja memberikan akses ke file rahasia.

Saya sepenuhnya tidak setuju - inti dari "rahasia" seharusnya membuat Anda ingin mengunci file itu.

Mengatakan tidak mungkin adalah peregangan di sini karena ada banyak aplikasi UWP yang bagus (meskipun sayangnya tidak banyak).

Anda bertentangan dengan diri Anda sendiri di sini. Tapi mari kita selidiki luasnya aplikasi UWP yang hebat:

Perhatikan "kelimpahan" suka, yang seharusnya memberi tahu Anda berapa banyak orang yang menggunakannya. Saya ingin memberikan kontras dengan toko apel, tetapi saya tidak bisa karena saya tidak punya apel. Tapi mari kita lihat Android - Facebook memiliki 70+ Juta ulasan (dibandingkan dengan 1353 di Windows). Instagram memiliki 93+ Juta ulasan (dibandingkan dengan 1578 di sini). Dan saya hampir yakin baik Fb maupun Instagram sebenarnya adalah aplikasi elektron, bukan UWP.

Apakah Anda akrab dengan konsep Windows Explorer? Anda memperluas folder atau drive - saat itulah saya akan mulai memindai

Jadi Anda sedang membangun sesuatu yang mirip dengan Windows Explorer yang akan mempratinjau file video di folder?

Ini bukan masalah, jika aplikasi akan menyimpan filenya di folder "hanya aplikasi ini yang dapat mengaksesnya".

Jadi di sisi lain, aplikasi umumnya harus memiliki akses ke semua file, tetapi di sisi lain beberapa file dan folder akan dikunci oleh pengguna (karena ia hanya akan memiliki file "rahasia" dan yang lainnya secara otomatis tidak rahasia) dan beberapa folder dirahasiakan. diblokir oleh aplikasi sendiri? Dan bagaimana jika saya ingin memprogram aplikasi yang akan menangani file yang telah dihasilkan oleh program? Apakah setiap program pencadangan akan gagal karena tidak dapat mencadangkan program? Saya tidak yakin bagaimana itu akan berhasil, dan saya minta maaf jika saya salah memahami ide Anda di sini.

Saya sepenuhnya tidak setuju - inti dari "rahasia" seharusnya membuat Anda ingin mengunci file itu.

Jadi apa sebenarnya yang tidak akan saya pilih sebagai rahasia? Saya tidak ingin setiap aplikasi melihat gambar liburan saya, tetapi Photoshop seharusnya dapat melihatnya. Jadi apakah mereka rahasia atau tidak? Atau apakah "tandai" rahasia ini merupakan daftar program dan beberapa file tidak rahasia untuk beberapa aplikasi?

Anda bertentangan dengan diri Anda sendiri di sini.

Ya ungkapan saya adalah sampah di sana. Maaf tentang itu. Saya ingin menunjukkan bahwa pasti ada aplikasi non "sepele" hebat yang berfungsi dengan baik.

Perhatikan "kelimpahan" suka, yang seharusnya memberi tahu Anda berapa banyak orang yang menggunakannya. Saya ingin memberikan kontras dengan toko apel, tetapi saya tidak bisa karena saya tidak punya apel. Tapi mari kita lihat Android - Facebook memiliki 70+ Juta ulasan (dibandingkan dengan 1353 di Windows). Instagram memiliki 93+ Juta ulasan (dibandingkan dengan 1578 di sini). Dan saya hampir yakin baik Fb maupun Instagram sebenarnya adalah aplikasi elektron, bukan UWP.

Ini bukan masalah dengan UWP melainkan dengan fakta bahwa:

1. Orang biasanya tidak cenderung menulis komentar
2. Toko iTunes/Google Play Store jauh lebih tua dari Microsoft Store
3. Toko Microsoft tidak diterima dengan baik di antara pengguna dan tidak dimulai dengan baik
4. Sebagian besar perusahaan lebih memilih mengembangkan Situs Web daripada aplikasi terbatas platform

Dan saya hampir yakin baik Fb maupun Instagram sebenarnya adalah aplikasi elektron, bukan UWP.

Sulit untuk mengetahui apakah mereka elektron atau bukan karena situs web dan aplikasinya terlihat sangat berbeda. Berdasarkan fakta bahwa dialog terlihat hampir persis seperti yang default, mereka mungkin aplikasi UWP.

Jadi Anda sedang membangun sesuatu yang mirip dengan Windows Explorer yang akan mempratinjau file video di folder?

Itu adalah bagian dari wizard dari aplikasi saya.

Jadi di sisi lain, aplikasi umumnya harus memiliki akses ke semua file, tetapi di sisi lain beberapa file dan folder akan dikunci oleh pengguna (karena ia hanya akan memiliki file "rahasia" dan yang lainnya secara otomatis tidak rahasia) dan beberapa folder dirahasiakan. diblokir oleh aplikasi sendiri? Dan bagaimana jika saya ingin memprogram aplikasi yang akan menangani file yang telah dihasilkan oleh program?

Ide saya adalah kebalikan dari apa yang kita miliki sekarang. Saya tidak mengatakan itu sempurna, jauh dari itu - tetapi ada yang lebih baik dari apa yang terjadi sekarang. Jadi, secara default, Anda akan memiliki akses ke semua file non-rahasia. Jika Anda memerlukan akses ke file rahasia, Anda harus bertanya terlebih dahulu.

Jadi apa sebenarnya yang tidak akan saya pilih sebagai rahasia? Saya tidak ingin setiap aplikasi melihat gambar liburan saya, tetapi Photoshop seharusnya dapat melihatnya. Jadi apakah mereka rahasia atau tidak? Atau apakah "tandai" rahasia ini merupakan daftar program dan beberapa file tidak rahasia untuk beberapa aplikasi?

Cara saya melihatnya, "bendera" ini akan mengubah file atau folder menjadi "Akses ditolak". Jika Anda benar-benar ingin mengaksesnya, Anda dapat meminta izin dan pengguna dapat memilih untuk memberikan kepada Anda atau tidak (dan izin tersebut dapat - hanya sekali ini, atau selamanya).

Ya ungkapan saya adalah sampah di sana. Maaf tentang itu. Saya ingin menunjukkan bahwa pasti ada aplikasi non "sepele" hebat yang berfungsi dengan baik.

Saya tidak mengatakan tidak ada. Saya mengatakan itu sangat sulit untuk membuatnya, dibandingkan dengan WPF.
Saya mengatakan saya membuang-buang waktu berurusan dengan masalah yang seharusnya tidak ada.

Seperti misalnya, kadang-kadang, saya mendapatkan pengecualian (pengecualian COM, untuk lebih spesifik), dan alih-alih mendapatkannya pada titik kegagalan, saya benar-benar mendapatkannya di utas lain, dan sebagian besar waktu, bahkan jejak tumpukan adalah hilang. Mencari tahu apa yang terjadi sangat sangat menyakitkan.

Masalah lainnya adalah seluruh mantra "mari dapatkan info async" - yang sangat saya benci. Saya berurusan dengan rendering yang harus segera dilakukan, tetapi pemuatan bitmap tidak sinkron. Jadi saya harus membangun mekanisme caching yang sangat rumit hanya untuk itu.

Dan jangan masuk ke waktu kompilasi. Dan akhir-akhir ini terkadang ketika membangun, saya mendapatkan "...dll dibangun dalam mode rilis" (yang pada dasarnya tidak bisa, karena saya sedang membangun debug). Solusinya adalah dengan hanya membersihkan semua solusi dan membangun kembali (yang membutuhkan waktu 1+ menit).

Dan ya, crash. VS mogok setiap 10-20 kali, mengalahkan saya mengapa.

Dan ini adalah masalah yang muncul di kepala saya sekarang. Ada banyak lagi.

Ini bukan masalah dengan UWP melainkan dengan fakta bahwa:

1. Orang biasanya tidak cenderung menulis komentar
2. Toko iTunes/Google Play Store jauh lebih tua dari Microsoft Store
3. Toko Microsoft tidak diterima dengan baik di antara pengguna dan tidak dimulai dengan baik
4. Sebagian besar perusahaan lebih memilih mengembangkan Situs Web daripada aplikasi terbatas platform

Yah, saya berharap saya bisa memiliki perbandingan toko Apple - Saya cukup yakin aplikasi teratas mereka memiliki jutaan ulasan. Idenya adalah toko MS tidak pernah tertangkap - karena orang menyerah begitu saja pada UWP/WinRT. Seandainya saya tidak membutuhkan win2d, saya akan menyerah setidaknya 20 kali.

Pikirkan tentang itu - saya perlu meminta Windows untuk membuka layar penuh, sebagai aplikasi UWP. Itu lebih dari gila. Dan untuk membuatnya lebih bodoh, itu hanya akan berlaku pada putaran berikutnya .

Saya sedang melihat API "Ambil tangkapan layar layar" - Saya menyerah begitu saja, tidak ada gunanya. Saya pada dasarnya ingin memiliki cara yang keren untuk memulai aplikasi, berdasarkan layar saat ini (semacam, memiliki transisi ke aplikasi saya) -> itu tidak mungkin, karena memerlukan interaksi pengguna (yaitu, pengguna harus mengatakan - ya , saya ingin mengizinkan pengambilan tangkapan layar, yang merusak semuanya)

Biarkan saya tidak memulai dengan clipboard -- yang hanya berfungsi saat aplikasi Anda berada di latar depan. Dan untuk membuatnya lebih lucu, Microsoft berpikir "kami akan memberi Anda akses ke clipboard setiap saat, saat dalam debug", tetapi dalam rilis, Anda akan mendapatkan pengecualian "Akses ditolak" yang bagus. Tahukah Anda berapa jam yang saya perlukan untuk akhirnya mengetahui itu sebabnya aplikasi saya tidak mulai di Rilis (sementara semuanya bagus di Debug)

Daftarnya terus berlanjut -- saya pikir saya bisa menulis buku. Tentu, UWP/WinRT secara teori keren. Tapi ketika Anda mulai menggunakannya, oh well..

Sulit untuk mengetahui apakah mereka elektron atau bukan karena situs web dan aplikasinya terlihat sangat berbeda. Berdasarkan fakta bahwa dialog terlihat hampir persis seperti yang default, mereka mungkin aplikasi UWP.

Benar, maksud saya adalah - orang-orang menyerah pada aplikasi UWP - manfaatnya lebih besar daripada banyak masalah yang menyertainya.

@jtorjo
(Hanya untuk memastikan Anda menyadarinya.)

Biarkan saya tidak memulai dengan clipboard -- yang hanya berfungsi saat aplikasi Anda berada di latar depan.

Saya mencapai masalah yang sama (atau serupa) selama pengembangan salah satu aplikasi UWP saya di mana saya harus menempatkan data di clipboard dan pada akhirnya saya menyelesaikannya melalui proses kepercayaan penuh win32 yang menyertainya (yang hanya memanggil SetClipboardData Win32). Jika konsep memiliki proses kepercayaan penuh win32 yang menyertai untuk aplikasi UWP Anda adalah berita bagi Anda, Anda akan mendapatkan pengantar yang bagus di sini (penulis sebelumnya mengerjakan UWP di Microsoft).

@Felix-Dev

Saya mencapai masalah yang sama (atau serupa) selama pengembangan salah satu aplikasi UWP saya di mana saya harus menempatkan data di clipboard dan pada akhirnya saya menyelesaikannya melalui proses kepercayaan penuh win32 yang menyertainya (yang hanya memanggil SetClipboardData Win32). Jika konsep memiliki proses kepercayaan penuh win32 yang menyertai untuk aplikasi UWP Anda adalah berita bagi Anda, Anda akan mendapatkan pengantar yang bagus di sini (penulis sebelumnya mengerjakan UWP di Microsoft).

Terima kasih untuk penunjuknya! Saya memang tahu tentang proses kepercayaan penuh win32. Saya mungkin sudah membaca artikel-artikel itu beberapa kali :) Saya benar-benar berpikir untuk memiliki aplikasi pendamping proses kepercayaan penuh win32 beberapa kali. Saya memilih untuk tidak melakukannya, karena kerumitan tambahan - saya sudah berjuang untuk menghasilkan kit pengaturan yang benar-benar berfungsi tanpa toko MS. Saya hanya tidak ingin membawa ini ke dalam persamaan juga.

Jadi Anda sedang membangun sesuatu yang mirip dengan Windows Explorer yang akan mempratinjau file video di folder?

Itu adalah bagian dari wizard dari aplikasi saya.

Kedengarannya seperti file explorer dengan langkah ekstra (⊙ˍ⊙)

Ide saya adalah kebalikan dari apa yang kita miliki sekarang. Saya tidak mengatakan itu sempurna, jauh dari itu - tetapi ada yang lebih baik dari apa yang terjadi sekarang. Jadi, secara default, Anda akan memiliki akses ke semua file non-rahasia. Jika Anda memerlukan akses ke file rahasia, Anda harus bertanya terlebih dahulu.

Jadi pada dasarnya, pada akhirnya, aplikasi Anda kemungkinan akan mengalami masalah yang sama seperti sekarang karena Anda tidak akan pernah tahu apakah file bersifat rahasia. Bagaimana dengan pengguna yang akan menandai semuanya sebagai rahasia? Jadi Anda baru saja membuat sistem yang sama seperti sekarang hanya dengan lebih banyak variasi yang dapat Anda akses.

Seperti misalnya, kadang-kadang, saya mendapatkan pengecualian (pengecualian COM, untuk lebih spesifik), dan alih-alih mendapatkannya pada titik kegagalan, saya benar-benar mendapatkannya di utas lain, dan sebagian besar waktu, bahkan jejak tumpukan adalah hilang. Mencari tahu apa yang terjadi sangat sangat menyakitkan.

Jika itu sering terjadi pada Anda, itu sangat menjengkelkan. Namun bagi saya, hampir setiap pengecualian yang terjadi pada saya (misalnya di XCG) memiliki pesan pengecualian yang terkait dengan StackTrace dan terkadang bahkan berguna. Jadi saya tidak bisa mengatakan apa-apa tentang itu karena itu tidak pernah benar-benar menjadi masalah bagi saya.

Masalah lainnya adalah seluruh mantra "mari dapatkan info async" - yang sangat saya benci. Saya berurusan dengan rendering yang harus segera dilakukan, tetapi pemuatan bitmap tidak sinkron. Jadi saya harus membangun mekanisme caching yang sangat rumit hanya untuk itu.

Terkadang async sedikit mengganggu, namun dalam banyak kasus metode async memiliki alasan untuk menjadi async, karena Anda tidak ingin memblokir UI pada operasi seperti operasi jaringan atau file. Karena itu, Anda dapat menggunakan metode berikut untuk menjalankan metode async Anda secara sinkron:

```c#
// Akan memblokir utas hingga MyAsyncMethod selesai
var myResult = MyAsyncMethod().Hasil;

// Ini juga akan selesai ketika metode telah selesai dieksekusi.
// Perhatikan bahwa ConfigureAwait dapat mengakibatkan metode dipanggil pada konteks yang berbeda
var myResult2 = MyAsyncMethod().ConfigureAwait(salah);
`` For ConfigureAwait` Anda dapat melihat artikel berikut: https://devblogs.microsoft.com/dotnet/configureawait-faq/

Dan jangan masuk ke waktu kompilasi. Dan akhir-akhir ini terkadang ketika membangun, saya mendapatkan "...dll dibangun dalam mode rilis" (yang pada dasarnya tidak bisa, karena saya sedang membangun debug). Solusinya adalah dengan hanya membersihkan semua solusi dan membangun kembali (yang membutuhkan waktu 1+ menit).

"...dll" dibangun dalam mode rilis aneh. Mungkin memeriksa apakah file proyek tidak koheren? Soal waktu kompilasi, ya agak mengganggu sih, meskipun ~1 Menit masih oke, WinUI membutuhkan waktu sekitar 5-10 menit

Dan ya, crash. VS mogok setiap 10-20 kali, mengalahkan saya mengapa.

Ya itu cukup mengganggu, meskipun saya tidak berpikir bahwa ini benar-benar tergantung pada UWP tetapi hanya Visual Studio secara umum (ini masih merupakan proses 32 bit karena suatu alasan!).

Yah, saya berharap saya bisa memiliki perbandingan toko Apple - Saya cukup yakin aplikasi teratas mereka memiliki jutaan ulasan. Idenya adalah toko MS tidak pernah tertangkap - karena orang menyerah begitu saja pada UWP/WinRT. Seandainya saya tidak membutuhkan win2d, saya akan menyerah setidaknya 20 kali.

Sepertinya Anda dapat menggunakan Win2D dengan WPF: https://github.com/Microsoft/Win2D/issues/660

Pikirkan tentang itu - saya perlu meminta Windows untuk membuka layar penuh, sebagai aplikasi UWP. Itu lebih dari gila. Dan untuk membuatnya lebih bodoh, itu hanya akan berlaku pada putaran berikutnya.

Tampaknya mungkin untuk mendapatkan Aplikasi UWP Anda dalam mode layar penuh, bahkan saat startup: https://stackoverflow.com/questions/31758775/windows-10-universal-app-run-in-fullscreen-mode-by-default
(Meskipun saya belum mencoba mengirimkan aplikasi dengan itu)

Saya sedang melihat API "Ambil tangkapan layar layar" - Saya menyerah begitu saja, tidak ada gunanya. Saya pada dasarnya ingin memiliki cara yang keren untuk memulai aplikasi, berdasarkan layar saat ini (semacam, memiliki transisi ke aplikasi saya) -> itu tidak mungkin, karena memerlukan interaksi pengguna (yaitu, pengguna harus mengatakan - ya , saya ingin mengizinkan pengambilan tangkapan layar, yang merusak semuanya)

Sebagian besar pengguna tidak ingin aplikasi mengambil gambar layar mereka secara sewenang-wenang tanpa izin mereka. Anda mungkin tidak punya masalah dengan itu, tapi saya pasti punya dan begitu juga banyak orang lain.

Biarkan saya tidak memulai dengan clipboard -- yang hanya berfungsi saat aplikasi Anda berada di latar depan. Dan untuk membuatnya lebih lucu, Microsoft berpikir "kami akan memberi Anda akses ke clipboard setiap saat, saat dalam debug", tetapi dalam rilis, Anda akan mendapatkan pengecualian "Akses ditolak" yang bagus. Tahukah Anda berapa jam yang saya perlukan untuk akhirnya mengetahui itu sebabnya aplikasi saya tidak mulai di Rilis (sementara semuanya bagus di Debug)

Ya, Anda mendapatkan pengecualian, namun fakta bahwa aplikasi Anda tidak dapat mengaksesnya saat tidak fokus disebutkan dalam dokumentasi:

https://docs.microsoft.com/en-us/uwp/api/windows.applicationmodel.datatransfer.clipboard

Tetapi mengapa Anda memerlukan akses ke clipboard saat pengguna tidak menggunakan aplikasi Anda? Jika Anda mencoba mengatur clipboard saat pengguna tidak menggunakan aplikasi Anda, pengguna akan merasa kesal saat Anda mengganggu salin/tempelnya. Dan jika Anda membaca clipboard saat pengguna tidak meminta aplikasi Anda untuk melakukannya, Anda memata-matai dia. Kecuali itu tujuan Anda (dalam hal ini Anda tidak boleh menggunakan UWP), hanya ada sedikit alasan untuk membaca clipboard saat aplikasi Anda tidak fokus (jika ada sama sekali).

Benar, maksud saya adalah - orang-orang menyerah pada aplikasi UWP - manfaatnya lebih besar daripada banyak masalah yang menyertainya.

Mungkin, tetapi juga karena lebih mudah untuk menulis Situs Web dan mengemasnya di dalam Electron dan mengirimkannya ke Mac, Linux, dan Windows daripada menulis aplikasi terpisah untuk semua platform.

Kedengarannya seperti file explorer dengan langkah ekstra (⊙ˍ⊙)

Ini bukan. Jauh dari itu.

Jadi pada dasarnya, pada akhirnya, aplikasi Anda kemungkinan akan mengalami masalah yang sama seperti sekarang karena Anda tidak akan pernah tahu apakah file bersifat rahasia. Bagaimana dengan pengguna yang akan menandai semuanya sebagai rahasia? Jadi Anda baru saja membuat sistem yang sama seperti sekarang hanya dengan lebih banyak variasi yang dapat Anda akses.

Saya tidak mengatakan solusi saya adalah solusi yang tepat. Jelas saya lebih suka tidak berada di kotak pasir sama sekali, saya hanya mengatakan implementasi saat ini sangat buruk.

Terkadang async sedikit mengganggu, namun dalam banyak kasus metode async memiliki alasan untuk menjadi async, karena Anda tidak ingin memblokir UI pada operasi seperti operasi jaringan atau file. Karena itu, Anda dapat menggunakan metode berikut untuk menjalankan metode async Anda secara sinkron:

Ini salah. Ini hanya mengasumsikan saya akan selalu menelepon dari utas UI. Maksud saya yakin ini bagus untuk hal-hal sederhana, tetapi saya dapat membuat utas saya sendiri, dan saya juga dapat membuat Tugas saya sendiri, dan melakukan hal-hal di sana.

Memiliki semuanya async hanya memaksa saya untuk selalu memanggil menunggu dan menandai fungsi async.

[...] Untuk ConfigureAwait Anda dapat melihat artikel berikut: https://devblogs.microsoft.com/dotnet/configureawait-faq/

Terima kasih, saya tahu tentang ini. Masalah lain yang saya temui adalah memuat bitmap (async) persis seperti yang Anda sarankan. Sesekali, saya akan mengalami waktu tunggu yang gila, seperti 5-6 detik untuk memuat bitmap.
Saya akhirnya melakukan solusi.

"...dll" dibangun dalam mode rilis aneh. Mungkin memeriksa apakah file proyek tidak koheren? Soal waktu kompilasi, ya agak mengganggu sih, meskipun ~1 Menit masih oke, WinUI membutuhkan waktu sekitar 5-10 menit

Ya, saya bahkan tidak ingin memikirkannya :) Saya tidak yakin apa yang Anda maksud tentang file proyek yang tidak koheren.

Dan ya, crash. VS mogok setiap 10-20 kali, mengalahkan saya mengapa.

Ya itu cukup mengganggu, meskipun saya tidak berpikir bahwa ini benar-benar tergantung pada UWP tetapi hanya Visual Studio secara umum (ini masih merupakan proses 32 bit karena suatu alasan!).

Saya percaya ini terkait dengan UWP. Ini tidak pernah terjadi pada saya ketika berhadapan dengan WPF - saya memiliki 28 proyek, dan tidak pernah macet. Di UWP saya memiliki 15 proyek (yang saya porting dari WPF), dan macet. Dan jika saya melihat di Peraga Peristiwa, ada sesuatu tentang kotak pasir yang mogok - saya tidak ingat persisnya.

Sepertinya Anda dapat menggunakan Win2D dengan WPF: microsoft/Win2D#660

Itu adalah usaha pertama saya. Ini benar-benar tidak ada jalan. Saya mengalami begitu banyak masalah, sehingga saya akhirnya menyerah. Kode yang berhubungan dengan win2d cukup kompleks, jadi saya beralasan akan memakan waktu lebih lama untuk menulisnya di atas WPF daripada menggunakan UWP secara langsung.

Meskipun saya membenci pengaturan UWP, saya benar. Saya tidak akan pernah bisa membuatnya bekerja dengan benar. Dan saya berasumsi Anda mengetahui https://github.com/microsoft/Win2D/issues/731

Pikirkan tentang itu - saya perlu meminta Windows untuk membuka layar penuh, sebagai aplikasi UWP. Itu lebih dari gila. Dan untuk membuatnya lebih bodoh, itu hanya akan berlaku pada putaran berikutnya.

Tampaknya mungkin untuk mendapatkan Aplikasi UWP Anda dalam mode layar penuh, bahkan saat startup: https://stackoverflow.com/questions/31758775/windows-10-universal-app-run-in-fullscreen-mode-by-default

Maaf, maksud saya "untuk memaksimalkan" - maaf untuk itu.

Ya, Anda mendapatkan pengecualian, namun fakta bahwa aplikasi Anda tidak dapat mengaksesnya saat tidak fokus disebutkan dalam dokumentasi:

Masalahnya adalah - kami memiliki perilaku yang berbeda di Debug daripada di Rilis. Itu harus konsisten.

https://docs.microsoft.com/en-us/uwp/api/windows.applicationmodel.datatransfer.clipboard

Tetapi mengapa Anda memerlukan akses ke clipboard saat pengguna tidak menggunakan aplikasi Anda? [...]

Yang lucu adalah ini - saya ingin menyalin sesuatu ke clipboard saat startup. Namun, ini ada di konstruktor MainPage, jadi ternyata, saya belum berada di latar depan. Bekerja sangat bagus di Debug, macet di Rilis - dan maksud saya persis saat startup, tidak ada logging tidak apa-apa.

Benar, maksud saya adalah - orang-orang menyerah pada aplikasi UWP - manfaatnya lebih besar daripada banyak masalah yang menyertainya.

Mungkin, tetapi juga karena lebih mudah untuk menulis Situs Web dan mengemasnya di dalam Electron dan mengirimkannya ke Mac, Linux, dan Windows daripada menulis aplikasi terpisah untuk semua platform.

Ketika berbicara tentang independensi platform, itu adalah topik yang sama sekali baru - yang saya maksud adalah fakta bahwa banyak masalah yang dihadapi orang saat mengembangkan aplikasi UWP seharusnya tidak ada. Beralih dari WPF ke UWP merupakan pengalaman yang sangat buruk.

@chingucoding

Tetapi mengapa Anda memerlukan akses ke clipboard saat pengguna tidak menggunakan aplikasi Anda? Jika Anda mencoba mengatur clipboard saat pengguna tidak menggunakan aplikasi Anda, pengguna akan merasa kesal saat Anda mengganggu salin/tempelnya. Dan jika Anda membaca clipboard saat pengguna tidak meminta aplikasi Anda untuk melakukannya, Anda memata-matai dia. Kecuali itu tujuan Anda (dalam hal ini Anda tidak boleh menggunakan UWP), hanya ada sedikit alasan untuk membaca clipboard saat aplikasi Anda tidak fokus (jika ada sama sekali).

Dalam kasus saya, aplikasi saya dari waktu ke waktu menampilkan pemberitahuan ketika suatu peristiwa terjadi, aplikasi sedang menonton. Pemberitahuan roti panggang mungkin berisi informasi yang ingin diproses lebih lanjut/digunakan pengguna dalam konteks lain, jadi saya menyediakan tombol tindakan [salin ke papan klip] yang menyalin beberapa informasi yang ditampilkan. Karena pemberitahuan mungkin tiba kapan saja dan aplikasi mungkin berada di latar belakang pada saat itu, saya harus menggunakan proses pembantu Win32 dalam kasus itu.

Menggunakan Win32 di luar kotak pasir UWP tidak selalu karena pengembang ingin mencapai sesuatu tanpa pengguna mengetahuinya. Jadi meskipun secara umum kotak pasir memberikan nilai bagi kami pengguna, Anda masih harus menghadapinya sebagai pengembang dalam hal apa pun, bahkan jika Anda bukan pengembang jahat yang tidak keberatan memata-matai pengguna atau tidak berniat meminta persetujuan pengguna sebelum mengubah sesuatu di sistem mereka.

Fakta bahwa Anda dapat menggunakan proses kepercayaan penuh Win32 bersama aplikasi Anda menunjukkan bahwa MS menyadari dilema ini dan memberi kami alat untuk menggunakan UWP dan masih dapat menikmati kebebasan Win32 sampai batas tertentu.

Ini bukan. Jauh dari itu.

Bisakah seseorang mengunduh aplikasi sekarang? Jika demikian di mana saya bisa menemukannya? 😅

Jelas saya lebih suka tidak berada di kotak pasir sama sekali, saya hanya mengatakan implementasi saat ini sangat buruk.

Saya kira, jika Anda tidak menyukai kotak pasir, daripada mungkin beralih ke alternatif WPF mungkin merupakan pilihan yang lebih baik, daripada hanya mencoba mengembangkan aplikasi Anda di UWP, yang Anda jelaskan, menurut Anda "tidak mungkin" atau "sangat sulit" untuk mengembangkan aplikasi untuk. Saya tidak berpikir bahwa alternatif WPF begitu buruk dibandingkan dengan Win2D, itu akan membenarkan Anda melalui semua perjuangan Anda. Tapi itu hanya sudut pandang saya tentang itu.

Juga, implementasi saat ini "buruk" bagi orang yang terbiasa tidak memiliki batasan terkait dengan file. Berasal dari latar belakang pengembangan Web, saya sangat setuju dengan itu. Saya dapat melihat tempat mereka, terutama karena Web juga memiliki keterbatasan yang tujuannya untuk melindungi pengguna.

Saya tidak yakin apa yang Anda maksud tentang file proyek yang tidak koheren.

Mungkin file proyek untuk debug salah dan beberapa dll sedang dibuat dalam rilis, meskipun saya ragu itu akan terjadi jika Anda membiarkan Visual Studio menanganinya.

Saya percaya ini terkait dengan UWP. Ini tidak pernah terjadi pada saya ketika berhadapan dengan WPF - saya memiliki 28 proyek, dan tidak pernah macet. Di UWP saya memiliki 15 proyek (yang saya porting dari WPF), dan macet. Dan jika saya melihat di Peraga Peristiwa, ada sesuatu tentang kotak pasir yang mogok - saya tidak ingat persisnya.

Keandalan Visual Studio sangat tergantung pada ukuran proyek untuk saya. UWP/NetCore/NetFramework kecil/menengah selalu berfungsi dengan baik. Proyek-proyek besar mengakibatkan Visual Studio menjadi tidak responsif, hang atau hanya crash pada waktunya. Tapi itu hanya pengalaman saya.

Maaf, maksud saya "untuk memaksimalkan" - maaf untuk itu.

Dalam hal ini, ya, perubahan hanya akan diterapkan pada startup berikutnya, karena Anda menetapkan nilainya SETELAH aplikasi Anda dimulai. Saya tidak tahu apa yang Anda maksud dengan "Saya harus bertanya pada Windows". Apakah Anda mengacu pada fakta bahwa Anda harus mengaturnya dalam kode?

Juga ada cara untuk mengatur ukuran yang diinginkan, yang akan mengakibatkan aplikasi mengambil semua ruang di layar yang aktif (mirip dengan dimaksimalkan) meskipun tidak sebagus yang dimaksimalkan nyata:
https://stackoverflow.com/questions/35247320/how-to-maximize-a-uwp-window-not-fullscreen?rq=1

Ini salah. Ini hanya mengasumsikan saya akan selalu menelepon dari utas UI. Maksud saya yakin ini bagus untuk hal-hal sederhana, tetapi saya dapat membuat utas saya sendiri, dan saya juga dapat membuat Tugas saya sendiri, dan melakukan hal-hal di sana.

Jika Anda sudah menggunakan utas Anda sendiri, menggunakan menunggu seharusnya tidak menjadi masalah bagi Anda. Bahkan jika Anda menggunakan utas terpisah, pengendali acara selalu dijalankan di utas UI, jadi jika Anda melakukan komputasi ekstensif di sana, aplikasi menjadi tidak responsif.

Meskipun saya membenci pengaturan UWP, saya benar. Saya tidak akan pernah bisa membuatnya bekerja dengan benar. Dan saya berasumsi Anda mengetahui microsoft/Win2D#731

Saya tidak menyadarinya, saya pikir karena masalah yang saya sebutkan dari 2018, itu akan diselesaikan dengan baik sekarang.

Masalahnya adalah - kami memiliki perilaku yang berbeda di Debug daripada di Rilis. Itu harus konsisten.

Hm itu sangat aneh. Perilaku harus konsisten.

Yang lucu adalah ini - saya ingin menyalin sesuatu ke clipboard saat startup.

Mereka juga menyebutkan kasus penggunaan itu dalam dokumentasi, dan Anda harus menunggu CoreWindow.Activated untuk menyalin. Mengapa tepatnya Anda menyalin sesuatu ke clipboard, ketika pengguna baru saja memulai aplikasi Anda? Sesuatu yang mirip dengan apa yang ingin dicapai/dicapai @Felix-Dev?

@Felix-Dev Terima kasih atas tanggapannya. Saya tidak memikirkan skenario itu. Dalam hal ini, ya Anda perlu mengakses clipboard dan ini pasti meningkatkan pengalaman bagi pengguna. Dugaan saya adalah karena Anda bersulang "memiliki fokus" ini akan berhasil. Tapi saya kira itu tidak terjadi.

Jadi meskipun secara umum kotak pasir memberikan nilai bagi kami pengguna, Anda masih harus menghadapinya sebagai pengembang dalam hal apa pun, bahkan jika Anda bukan pengembang jahat yang tidak keberatan memata-matai pengguna atau tidak berniat meminta persetujuan pengguna sebelum mengubah sesuatu di sistem mereka.

Ya kita harus menghadapinya, namun banyak aplikasi tidak dibatasi oleh kotak pasir sedemikian rupa sehingga akan sangat sulit untuk menemukan solusi. Dan satu hal yang tidak boleh dilupakan adalah jika UWP tidak berfungsi untuk Anda, masih ada 2 opsi lain.

Mengenai poin terakhir Anda, ya fakta bahwa Anda dapat menggunakan proses Win32 merupakan indikasi bahwa ada kasus di mana UWP membatasi Anda.
Mungkin ini adalah solusi termudah/tercepat yang ada, atau mungkin memang benar-benar dirancang.

Ini bukan. Jauh dari itu.

Bisakah seseorang mengunduh aplikasi sekarang? Jika demikian di mana saya bisa menemukannya? 😅

Di sini -> https://photo-awe.com

Saya kira, jika Anda tidak menyukai kotak pasir, daripada mungkin beralih ke alternatif WPF mungkin merupakan pilihan yang lebih baik, daripada hanya mencoba mengembangkan aplikasi Anda di UWP, yang Anda jelaskan, menurut Anda "tidak mungkin" atau "sangat sulit" untuk mengembangkan aplikasi untuk. Saya tidak berpikir bahwa alternatif WPF begitu buruk dibandingkan dengan Win2D, itu akan membenarkan Anda melalui semua perjuangan Anda. Tapi itu hanya sudut pandang saya tentang itu.

Ini adalah aplikasi WPF. Namun, karena sifat pengeditan video, saya telah lama mencapai batas WPF dalam hal kecepatan (pada dasarnya, berurusan dengan DrawingVisual ). Percayalah, saya tidak akan melakukan ini, jika saya punya pilihan.

Juga, implementasi saat ini "buruk" bagi orang yang terbiasa tidak memiliki batasan terkait dengan file. Berasal dari latar belakang pengembangan Web, saya sangat setuju dengan itu. Saya dapat melihat tempat mereka, terutama karena Web juga memiliki keterbatasan yang tujuannya untuk melindungi pengguna.

Saya berani bersumpah Anda berasal dari latar belakang Web :)

Mungkin file proyek untuk debug salah dan beberapa dll sedang dibuat dalam rilis, meskipun saya ragu itu akan terjadi jika Anda membiarkan Visual Studio menanganinya.

Bukan itu masalahnya, tetapi saya melakukan pemeriksaan ulang - bukan itu masalahnya.

Keandalan Visual Studio sangat tergantung pada ukuran proyek untuk saya. UWP/NetCore/NetFramework kecil/menengah selalu berfungsi dengan baik. Proyek-proyek besar mengakibatkan Visual Studio menjadi tidak responsif, hang atau hanya crash pada waktunya. Tapi itu hanya pengalaman saya.

Ya, saya sudah berurusan dengan itu di masa lalu. Tampaknya tidak demikian dengan versi terbaru VS (2017,2019). Singkat cerita, ini baru saja terjadi di UWP untuk saya. Ini mungkin ada hubungannya dengan fakta bahwa saya menggunakan win2d, dan saya merasa itu adalah binatang yang cukup rumit.

Dalam hal ini, ya, perubahan hanya akan diterapkan pada startup berikutnya, karena Anda menetapkan nilainya SETELAH aplikasi Anda dimulai. Saya tidak tahu apa yang Anda maksud dengan "Saya harus bertanya pada Windows". Apakah Anda mengacu pada fakta bahwa Anda harus mengaturnya dalam kode?

Di WPF, saya cukup mengatur ukuran jendela ke tempat yang saya inginkan. Di sini, ada API yang perlu Anda panggil -> ApplicationView.PreferredLaunchViewSize - yang menurut dokumen "berfungsi, kecuali jika sistem mengelola ukuran jendela secara langsung." - dan ya, ini hanya berfungsi untuk permulaan aplikasi berikutnya.

Juga ada cara untuk mengatur ukuran yang diinginkan, yang akan mengakibatkan aplikasi mengambil semua ruang di layar yang aktif (mirip dengan dimaksimalkan) meskipun tidak sebagus yang dimaksimalkan nyata:
https://stackoverflow.com/questions/35247320/how-to-maximize-a-uwp-window-not-fullscreen?rq=1

Saya menggunakan kode lain, yang sebenarnya berfungsi dengan benar

var view = DisplayInformation.GetForCurrentView();
var resolution = new Size(view.ScreenWidthInRawPixels, view.ScreenHeightInRawPixels);
var scale = view.ResolutionScale == ResolutionScale.Invalid ? 1 : view.RawPixelsPerViewPixel;
var bounds = new Size(resolution.Width / scale, resolution.Height / scale);

ApplicationView.PreferredLaunchViewSize = new Size(bounds.Width, bounds.Height);
ApplicationView.PreferredLaunchWindowingMode = ApplicationViewWindowingMode.PreferredLaunchViewSize;

Jika Anda sudah menggunakan utas Anda sendiri, menggunakan menunggu seharusnya tidak menjadi masalah bagi Anda. Bahkan jika Anda menggunakan utas terpisah, pengendali acara selalu dijalankan di utas UI, jadi jika Anda melakukan komputasi ekstensif di sana, aplikasi menjadi tidak responsif.

Jelas, event handler berjalan di thread UI. Saya sudah agak terbiasa dengannya, saya harus memodifikasi sedikit aplikasi saya - hanya menambahkan async ke fungsi... Yang masih benar-benar mengganggu saya adalah bagi saya, sepertinya beberapa API telah mengambil ini secara ekstrem, hanya memiliki versi Async() saja, yang tidak masuk akal.

Saya tidak menyadarinya, saya pikir karena masalah yang saya sebutkan dari 2018, itu akan diselesaikan dengan baik sekarang.

Belum - setidaknya terakhir kali saya memeriksa.

Masalahnya adalah - kami memiliki perilaku yang berbeda di Debug daripada di Rilis. Itu harus konsisten.

Hm itu sangat aneh. Perilaku harus konsisten.

Ya, itulah yang benar-benar membuatku kesal. Dan jelas, bekerja dengan clipboard untuk waktu yang sangat lama pada aplikasi non-UWP, saya tidak berpikir kami akan memiliki batasan ini, jadi ya, saya tidak membaca tentang harus menunggu CoreWindow.Activated. Karena itu, sangat tidak praktis untuk mempelajari semua detail ini. Sepertinya saya perlu belajar bahasa yang sama sekali baru. Alih-alih menjadi proses yang mulus, sepertinya setiap minggu saya belajar sesuatu yang baru saja mengejutkan saya.

Mereka juga menyebutkan kasus penggunaan itu dalam dokumentasi, dan Anda harus menunggu CoreWindow.Activated untuk menyalin. Mengapa tepatnya Anda menyalin sesuatu ke clipboard, ketika pengguna baru saja memulai aplikasi Anda? Sesuatu yang mirip dengan apa yang ingin dicapai/dicapai @Felix-Dev?

Saat itulah saya menguji aplikasi saya lebih awal, dan saya hanya ingin memberikannya kepada seorang rekan untuk beberapa pengujian internal lagi. Namun, dia perlu mengubah beberapa pengaturan. Dan pengaturan disimpan di LocalFolder Aplikasi. Ini berbeda untuk setiap pengguna, jadi pendapat saya adalah -- biarkan saya membuat ini tetap sederhana dan menyalinnya ke clipboard. Kemudian ketika dia memulai aplikasi, dia kemudian akan pergi ke "PC ini", menempelkan lokasi, dan mengedit file pengaturan di sana (sekarang, saya tahu bagaimana saya bisa membuka aplikasi di Explorer, tetapi pada saat itu, saya tidak). Yang akhirnya mogok, dan saya menyelidiki dan mengutuk selama beberapa jam yang baik.

Di sini -> https://photo-awe.com

Terima kasih!

Ini adalah aplikasi WPF. Namun, karena sifat pengeditan video, saya telah lama mencapai batas WPF dalam hal kecepatan (pada dasarnya, berurusan dengan DrawingVisual). Percayalah, saya tidak akan melakukan ini, jika saya punya pilihan.

Tidak tahu bahwa WPF memiliki penurunan kinerja yang begitu besar dibandingkan dengan UWP.

Bukan itu masalahnya, tetapi saya melakukan pemeriksaan ulang - bukan itu masalahnya.

Itu aneh. Saya akan berharap ada sesuatu yang salah. Mengapa VS berbicara tentang rilis dll ketika Anda menjalankan debug.

Di WPF, saya cukup mengatur ukuran jendela ke tempat yang saya inginkan. Di sini, ada API yang perlu Anda panggil - ApplicationView.PreferredLaunchViewSize - yang menurut dokumen "berfungsi, kecuali jika sistem mengelola ukuran jendela secara langsung."

Tetapi bukankah kode yang Anda gunakan juga merupakan API untuk mengatur ukuran jendela?

• dan ya, ini hanya berfungsi untuk memulai aplikasi berikutnya.

Tidak mengherankan bila disebut "PreferredLaunchViewSize"
Hanya sedikit merepotkan karena tidak ada cara untuk mengatur ini setelah peluncuran.

Ya, saya sudah berurusan dengan itu di masa lalu. Tampaknya tidak demikian dengan versi terbaru VS (2017,2019). Singkat cerita, ini baru saja terjadi di UWP untuk saya.

Senang mendengar bahwa ini tidak seburuk dengan versi VS sebelumnya.

Ini mungkin ada hubungannya dengan fakta bahwa saya menggunakan win2d, dan saya merasa itu adalah binatang yang cukup rumit.

Saya tidak terlalu bergantung pada desainer karena mulai gagal untuk binding template. Sudahkah Anda mencoba Blend untuk Visual Studio? Apakah itu lebih dapat diandalkan mengenai desainer?

Ya, itulah yang benar-benar membuatku kesal. Dan jelas, bekerja dengan clipboard untuk waktu yang sangat lama pada aplikasi non-UWP, saya tidak berpikir kami akan memiliki batasan ini, jadi ya, saya tidak membaca tentang harus menunggu CoreWindow.Activated. Karena itu, sangat tidak praktis untuk mempelajari semua detail ini. Sepertinya saya perlu belajar bahasa yang sama sekali baru. Alih-alih menjadi proses yang mulus, sepertinya setiap minggu saya belajar sesuatu yang baru saja mengejutkan saya.

Ya saya bisa membayangkan itu. Sesuatu yang mungkin bagus adalah panduan transisi dari WPF ke UWP. Jika ini ada, itu pasti akan menghemat banyak waktu bagi pengembang UWP baru dan mantan WPF. Dan ini bukan pertama kalinya ada panduan transisi. Sudah ada panduan Java ke C#, yang sangat membantu pengembang Java.

Saat itulah saya menguji aplikasi saya lebih awal, dan saya hanya ingin memberikannya kepada seorang rekan untuk beberapa pengujian internal lagi. Namun, dia perlu mengubah beberapa pengaturan. Dan pengaturan disimpan di LocalFolder Aplikasi. Ini berbeda untuk setiap pengguna, jadi pendapat saya adalah -- biarkan saya membuat ini tetap sederhana dan menyalinnya ke clipboard. Kemudian ketika dia memulai aplikasi, dia kemudian akan pergi ke "PC ini", menempelkan lokasi, dan mengedit file pengaturan di sana (sekarang, saya tahu bagaimana saya bisa membuka aplikasi di Explorer, tetapi pada saat itu, saya tidak). Yang akhirnya mogok, dan saya menyelidiki dan mengutuk selama beberapa jam yang baik.

Oh begitu. Jika seseorang tidak berpikir untuk membuka folder, menyalin jalur folder ke clipboard adalah solusinya. Untuk tujuan pengujian ini cukup cerdas.

Tidak tahu bahwa WPF memiliki penurunan kinerja yang begitu besar dibandingkan dengan UWP.

WPF tidak dioptimalkan untuk DirectX - ketika pixel shader dan mask ikut bermain, akhirnya menjadi sangat lambat. Porting ke UWP/win2d membuat aplikasi 3-4 kali lebih cepat. Itu sangat terlihat.

Itu aneh. Saya akan berharap ada sesuatu yang salah. Mengapa VS berbicara tentang rilis dll ketika Anda menjalankan debug.

Ya, poin saya persis.

Tetapi bukankah kode yang Anda gunakan juga merupakan API untuk mengatur ukuran jendela?

Maksud saya, Anda menggunakan Preferred...Size, tetapi Anda tidak menjamin hal itu akan terjadi. Seperti saat menggunakan WPF, Anda dijamin ketika Anda mengatur posisi/ukuran, itu akan benar-benar terjadi.

Tidak mengherankan bila disebut "PreferredLaunchViewSize"
Hanya sedikit merepotkan karena tidak ada cara untuk mengatur ini setelah peluncuran.

Ini sangat tidak nyaman - ini sangat tidak nyaman. Pada dasarnya, saya tidak dapat mengubah ukuran aplikasi saya setelah dimulai. Dan ya, saya ingin aplikasi saya memiliki "mode" operasi yang berbeda (seperti, Dasar/Lanjutan) -berdasarkan itu, saya ingin mengambil lebih banyak atau lebih sedikit ruang - saya tidak bisa melakukannya. Apakah menurut Anda pengguna akan baik-baik saja dengan "Perubahan hanya akan terjadi setelah restart"?

Saya tidak terlalu bergantung pada desainer karena mulai gagal untuk binding template. Sudahkah Anda mencoba Blend untuk Visual Studio? Apakah itu lebih dapat diandalkan mengenai desainer?

Saya seharusnya lebih spesifik - VS tidak mogok saat mengedit xaml - itu macet saat meluncurkan aplikasi; pada dasarnya, saya berasumsi itu terjadi persis saat penerapan, karena Anda baru saja melihat "x" besar pada aplikasi (uwp) selama 10 detik, dan pada saat itu saya tahu itu hang. Pada titik mana saya dapat menunggu 45-60 detik lagi dan melihat bahwa VS akan macet, atau tutup saja VS dari Pengelola Tugas.

Ya saya bisa membayangkan itu. Sesuatu yang mungkin bagus adalah panduan transisi dari WPF ke UWP.

Ya, itu akan sangat membantu.

Oh begitu. Jika seseorang tidak berpikir untuk membuka folder, menyalin jalur folder ke clipboard adalah solusinya. Untuk tujuan pengujian ini cukup cerdas.

Terima kasih ;) ​​Yah itu akan menjadi pintar, seandainya itu benar-benar berhasil :)

@chingucoding

Terkadang async sedikit mengganggu, namun dalam banyak kasus metode async memiliki alasan untuk menjadi async, karena Anda tidak ingin memblokir UI pada operasi seperti operasi jaringan atau file. Karena itu, Anda dapat menggunakan metode berikut untuk menjalankan metode async Anda secara sinkron

Izinkan saya memberi Anda satu alasan lagi saya benci async - ini baru saja terjadi pada saya sekarang (pada dasarnya, ini adalah laporan bug dari pengguna). Awalnya, saya tidak bisa mengetahuinya untuk kehidupan saya.

Singkat cerita - dengan satu klik tombol, saya membuka file picker. Yang, Anda dapat menebaknya, adalah async.

Jadi, pengguna mengklik dua kali (dengan jeda sekitar 100 ms di antara klik). Tentunya, ini membuka 2 pemetik file.

Sekarang, jelas saya dapat memperbaiki ini, tetapi ini tidak akan pernah terjadi, seandainya fungsi awal sinkron (dan tentu saja, ini tidak akan pernah terjadi di WPF).

Ini sangat tidak nyaman - ini sangat tidak nyaman. Pada dasarnya, saya tidak dapat mengubah ukuran aplikasi saya setelah dimulai. Dan ya, saya ingin aplikasi saya memiliki "mode" operasi yang berbeda (seperti, Dasar/Lanjutan) -berdasarkan itu, saya ingin mengambil lebih banyak atau lebih sedikit ruang - saya tidak bisa melakukannya. Apakah menurut Anda pengguna akan baik-baik saja dengan "Perubahan hanya akan terjadi setelah restart"?

Yah "sangat tidak nyaman" mungkin untuk aplikasi yang perlu menerapkan ukuran tertentu, tetapi dalam kebanyakan kasus aplikasi tidak perlu mengubah ukurannya sendiri. Bagaimana seharusnya aplikasi memilih ukuran mana yang saat ini sesuai untuk kasus penggunaan pengguna? Jika pengguna memiliki kebutuhan untuk membuatnya lebih kecil atau lebih besar, maka pengguna adalah yang pertama menyadarinya. Terutama karena dia paling tahu di mana jendela terbuka lainnya dan di mana ruang akan tersedia untuk tidak menghalangi jendela lain agar tidak terlihat.

Jika Anda memiliki mode dasar dan lanjutan, Anda dapat mengubah ukuran minimum yang diinginkan jika aplikasi pasti tidak akan berfungsi saat terlalu kecil. Tetapi menurut saya akan sangat menjengkelkan bagi saya jika program mulai mengubah ukurannya sendiri (dan untungnya sejauh ini tidak ada program yang melakukannya).

Saya tidak bisa melakukannya. Apakah menurut Anda pengguna akan baik-baik saja dengan "Perubahan hanya akan terjadi setelah restart"?

Jika mengubah ukuran itu penting, pengguna dapat melakukannya sendiri. Namun "perubahan hanya akan terjadi setelah restart" tidak jarang, jadi sebagian dapat diterima menurut saya.

Jadi, pengguna mengklik dua kali (dengan jeda sekitar 100 ms di antara klik). Tentunya, ini membuka 2 pemetik file.

Mengapa tepatnya itu membuka file picker dua kali? Apakah event handler memicu dua kali? Daripada ini bukan masalah yang disebabkan oleh async tetapi oleh fakta bahwa event handler tidak memblokir UI dari menerima event tambahan dari masing-masing tombol.

Singkat cerita - dengan satu klik tombol, saya membuka file picker. Yang, Anda dapat menebaknya, adalah async.

Ya itu async karena Anda tidak ingin memblokir seluruh utas Anda saat pengguna menavigasi drive-nya dan memilih folder. Panggilan selesai ketika pengguna selesai memilih file/folder, dan Anda mendapatkan file yang dipilih sebagai hasilnya.

Menurut pendapat saya, lebih baik tidak memblokir utas pada operasi seperti itu karena Anda tidak pernah tahu berapa lama waktu yang dibutuhkan. Jika Anda memblokir utas UI karena itu, aplikasi Anda menjadi tidak responsif selama pemilih file terbuka, yang mana IMO bukan UX yang baik.

Mari saya mulai dengan mengatakan ini dengan hormat: kita tidak akan pernah setuju dalam hal apa pun .

Jelas Anda berpikir dari perspektif web, dan Anda tidak melihat apa pun sebagai "desktop". Saya tahu maksud Anda baik, tetapi Anda hanya tidak berpikir "desktop" sampai Anda mengembangkan sesuatu yang rumit - ketika datang ke desktop. Dan saya yakin Anda belum.

Yah "sangat tidak nyaman" mungkin untuk aplikasi yang perlu menerapkan ukuran tertentu, tetapi dalam kebanyakan kasus aplikasi tidak perlu mengubah ukurannya sendiri. Bagaimana seharusnya aplikasi memilih ukuran mana yang saat ini sesuai untuk kasus penggunaan pengguna? Jika pengguna memiliki kebutuhan untuk membuatnya lebih kecil atau lebih besar, dari pengguna

Apakah Anda serius menanyakan ini? Bukankah aplikasi seharusnya membantu pengguna? Dan kemudian jika pengguna tidak setuju dengan ukuran aplikasi, dia dapat mengubah ukurannya. Tetapi aplikasi harus dapat mengatakan, berdasarkan apa yang seharusnya dicapai, ini adalah ukuran yang harus saya jalankan. Katakanlah, Photoshop - akan selalu lebih suka menjalankan layar penuh, karena memiliki banyak info untuk ditampilkan kepada pengguna.

Jika Anda memiliki mode dasar dan lanjutan, Anda dapat mengubah ukuran minimum yang diinginkan jika aplikasi pasti tidak akan berfungsi saat terlalu kecil. Tetapi menurut saya akan sangat menjengkelkan bagi saya jika program mulai mengubah ukurannya sendiri (dan untungnya sejauh ini tidak ada program yang melakukannya).

Jika mereka melakukannya, Anda bahkan tidak memikirkannya. Wizard terkadang berjalan pada ukuran yang lebih kecil, dan kemudian ketika wizard selesai, aplikasi mungkin menjadi layar penuh.

Saya tidak bisa melakukannya. Apakah menurut Anda pengguna akan baik-baik saja dengan "Perubahan hanya akan terjadi setelah restart"?

Jika mengubah ukuran itu penting, pengguna dapat melakukannya sendiri. Namun "perubahan hanya akan terjadi setelah restart" tidak jarang, jadi sebagian dapat diterima menurut saya.

Dan memiliki pengalaman memulai yang buruk, karena saya menampilkan jendela yang terlihat bagus hanya dalam ukuran tertentu - dan Windows hanya mengatakan "Oh, tapi saya akan menampilkan aplikasi seperti yang saya inginkan".

Mengapa tepatnya itu membuka file picker dua kali? Apakah event handler memicu dua kali? Daripada ini bukan masalah yang disebabkan oleh async tetapi oleh fakta bahwa event handler tidak memblokir UI dari menerima event tambahan dari masing-masing tombol.

Apakah Anda jujur ​​melakukan ini? Tunjukkan pada saya bagaimana sebuah kode terpotong di tempat Anda melakukan ini secara sadar.

Menurut pendapat saya, lebih baik tidak memblokir utas pada operasi seperti itu karena Anda tidak pernah tahu berapa lama waktu yang dibutuhkan. Jika Anda memblokir utas UI karena itu, aplikasi Anda menjadi tidak responsif selama pemilih file terbuka, yang mana IMO bukan UX yang baik.

Bagaimana WPF menangani ini? Ini menanganinya dengan benar. UI tidak memblokir, tetapi aplikasi memblokir panggilan itu - jadi hal di atas tidak akan pernah terjadi di WPF

Mari saya mulai dengan mengatakan ini dengan hormat: kita tidak akan pernah setuju pada apa pun.

Jika ini adalah pandangan Anda tentang diskusi ini, saya minta maaf tentang itu.

Jelas Anda berpikir dari perspektif web, dan Anda tidak melihat apa pun sebagai "desktop". Saya tahu maksud Anda baik, tetapi Anda hanya tidak berpikir "desktop" sampai Anda mengembangkan sesuatu yang rumit - ketika datang ke desktop. Dan saya yakin Anda belum.

Saya pikir deskripsi yang lebih akurat adalah: Saya berasal dari latar belakang di mana pengembang tidak memiliki akses ke apa pun dan Anda berasal dari latar belakang di mana pengembang memiliki akses ke setiap sumber daya OS.

Jika mereka melakukannya, Anda bahkan tidak memikirkannya. Wizard terkadang berjalan pada ukuran yang lebih kecil, dan kemudian ketika wizard selesai, aplikasi mungkin menjadi layar penuh.

Ya penyihir berjalan pada ukuran yang lebih kecil TETAPI sebagian besar penyihir (termasuk Visual Studio 2019 Startup "Wizard") menutup diri mereka sendiri dan kemudian memulai program sebenarnya. Mereka tidak "berubah" menjadi aplikasi yang sebenarnya.

Perlu dicatat bahwa beberapa penyihir juga bukan jendela baru melainkan hanya munculan, dengan aplikasi sebenarnya berada di latar belakang.

Dan memiliki pengalaman memulai yang buruk, karena saya menampilkan jendela yang terlihat bagus hanya dalam ukuran tertentu - dan Windows hanya mengatakan "Oh, tapi saya akan menampilkan aplikasi seperti yang saya inginkan".

Anda membuatnya tampak seperti Windows hanya mengabaikan kode Anda sepanjang waktu, sementara itu jelas kapan akan mengabaikannya (diambil dari dokumentasi "PreferredLaunchViewSize"):

Properti ini hanya berpengaruh saat aplikasi diluncurkan di perangkat desktop yang tidak dalam mode Tablet.

Jadi ini hanya berfungsi di desktop dalam mode non tablet. Tetapi apakah masuk akal pada perangkat lain untuk benar-benar meminta ukuran? Apakah Anda mengharapkan aplikasi Anda berjalan di X-Box atau Holo Lens, dan apakah Anda sudah mengoptimalkan perangkat tersebut? Jika tidak, maka batasan ini seharusnya tidak terlalu mengganggu Anda.

Apakah Anda jujur ​​melakukan ini? Tunjukkan pada saya bagaimana sebuah kode terpotong di tempat Anda melakukan ini secara sadar.

Tidak, saya hanya mencoba menunjukkan fakta bahwa Anda menyalahkan "async" untuk sesuatu yang tidak terkait dengan itu. Jika pengguna mengklik tombol dua kali, acara yang diklik akan dipicu dua kali.

Bagaimana WPF menangani ini? Ini menanganinya dengan benar. UI tidak memblokir, tetapi aplikasi memblokir panggilan itu - jadi hal di atas tidak akan pernah terjadi di WPF

Saya cukup yakin jika Anda menjalankan kode di utas UI dan butuh waktu untuk menyelesaikannya, daripada Anda memblokir utas UI di WPF.

Hai, saya pemimpin pengembang untuk Windows SDK dan infrastruktur Windows Runtime di tim OS Windows.

Ini adalah diskusi yang bagus dengan banyak detail dan percakapan. Seseorang membawa percakapan ini beberapa hari yang lalu, dan saya tidak sabar untuk membacanya, tetapi mungkin masih perlu beberapa hari sebelum saya sampai ke sana. Namun, saya akan membaca semuanya, dan mencoba memberi Anda beberapa jawaban yang lebih terperinci atau menindaklanjutinya sebaik mungkin.

Ini mungkin bukan tempat terbaik untuk masalah umum winrt. Anda dapat mengangkat masalah di forum pengembang Microsoft, atau untuk masalah Windows Runtime secara khusus, Anda dapat membuka masalah di https://github.com/microsoft/xlang. Tim kami meninjau masalah yang masuk di sana secara teratur. Masalah yang diajukan di github akan sampai ke tim saya lebih cepat, tetapi memiliki lebih sedikit pelacakan. Jika umpan balik Anda memerlukan perubahan OS, menjaga agar OS tetap sinkron dengan masalah github yang diajukan adalah proses manual. Di sisi lain, umpan balik forum mengikuti pekerjaan di seluruh tim dan organisasi, dan cenderung tidak terputus dari pekerjaan aktual yang dilakukan berdasarkan umpan balik.

Terima kasih sekali lagi untuk diskusi yang hidup. Saya akan memposting lagi tentang masalah ini segera.

Ben Kuhn
Microsoft

Hai Ben,

Hai, saya pemimpin pengembang untuk Windows SDK dan infrastruktur Windows Runtime di tim OS Windows.

Ini adalah diskusi yang bagus dengan banyak detail dan percakapan. Seseorang membawa percakapan ini beberapa hari yang lalu, dan saya tidak sabar untuk membacanya, tetapi mungkin masih perlu beberapa hari sebelum saya sampai ke sana. Namun, saya akan membaca semuanya, dan mencoba memberi Anda beberapa jawaban yang lebih terperinci atau menindaklanjutinya sebaik mungkin.

Luar biasa - nantikan balasan Anda!

Karena saya adalah poster asli, jika Anda memiliki pertanyaan / ada yang tidak jelas, beri tahu saya dan saya akan melakukan yang terbaik untuk mengklarifikasi.

Ini mungkin bukan tempat terbaik untuk masalah umum winrt. Anda dapat mengangkat masalah di forum pengembang Microsoft, atau untuk masalah Windows Runtime secara khusus, Anda dapat membuka masalah di https://github.com/microsoft/xlang.

Setuju itu bukan tempat terbaik, masalahnya adalah orang tidak tahu ke mana harus memposting.

Jika Anda mengatakan kami harus memposting ke https://github.com/microsoft/xlang , saya pasti akan memposting di sana mulai sekarang.

Terbaik,
John

Pertama, izinkan saya menyebutkan beberapa hal yang tidak akan saya bahas.

• Ada banyak diskusi hebat tentang Windowing, posisi jendela, dll. di dekat bagian bawah utas. Itu mungkin masih sedikit di luar topik untuk WinUI, tetapi lebih dekat ke rumah. Saya ingin membiarkan orang-orang WinUI mengurai umpan balik tentang posisi jendela, layar penuh, dll. dan membantu mengarahkan ulang. @StephenLPeters , dapatkah Anda membantu dengan ini?

• Saya tidak akan menyentuh umpan balik VS. Ada forum yang sehat untuk membahas kualitas dan kinerja VS. Meskipun saya telah mencatat diskusi bahwa cerita untuk mengembangkan aplikasi Windows dari Visual Studio telah menjadi sedikit lebih kompleks dan kacau.

• WPF. Saya memiliki hubungan cinta benci dengan WPF. Ini berguna, dan sebagian besar baik. Ketika saya membaca komentar tentang klik bersarang pada pemilih file, itu membuat saya tertawa. Karena ada beberapa kebiasaan di WPF yang membuat saya sakit kepala. Seperti fakta bahwa ketika Anda menyeret di WPF, pesan seret kadang-kadang dikirim ganda dalam pesan bersarang, sehingga Anda benar-benar melakukan penyeretan modal di dalam penyeretan modal. Anda biasanya tidak pernah memperhatikan. Biasanya. Tapi saya masih suka WPF. 😉

Kedua, @verelpode : Ini membuatku tertawa. Keberatan jika saya berpegang pada yang satu ini?
"Saya percaya bahwa Anda tidak dapat menangani kebenaran langsung, oleh karena itu saya akan menangani Anda dengan sarung tangan katun halus yang tebal, dan mengemas Anda dalam bungkus gelembung"

Oke, sekarang ke topik sebenarnya.

WinRT vs. UWP vs. .NET – beberapa latar belakang

Windows Runtime benar-benar dua hal yang digabung menjadi satu, dikemas dalam yang lain, dan benar-benar disalahpahami.

Sistem tipe Windows Runtime benar-benar, dalam arti tertentu, COM V2. Ini adalah langkah spiritual berikutnya dalam perkembangan dari memicu interupsi, memanggil Win32, hingga memanggil COM API. Sistem tipe dalam beberapa hal sedikit kurang ekspresif di COM, tetapi dalam banyak hal merupakan superset yang substansial. Awalnya dirancang untuk mengatasi satu masalah: bagaimana kami mempermudah pengembang yang menggunakan .NET atau bahasa lain untuk memanggil API WinRT tanpa harus menunggu VS membuat pembungkus yang bagus dalam kerangka kerja .NET.

Lalu ada perpustakaan API. Kami melakukan beberapa hal hebat di sini, dan beberapa hal konyol. Kami mungkin sedikit terbawa dengan beberapa hal async. Jika Anda memprogram dengan C++ /WinRT, Anda dapat mengurangi ini secara signifikan. Jika Anda tidak berada di utas UI, Anda cukup mengambil hasilnya dan itu akan memblokir dan menyelesaikan secara sinkron. .NET mungkin juga membuat ini lebih mudah sekarang, tetapi saya menulis lebih sedikit kode .NET akhir-akhir ini, dan saya kurang yakin tentang keadaan saat ini. Kami juga melakukan beberapa hal lain yang tidak berjalan sesuai rencana. Saya tidak akan mencantumkan semuanya. Kami telah membuat beberapa perbaikan.

Model aplikasi UWP melompat ke winrt dengan kedua kaki. Itu berarti kami dapat menulis API OS sekali dan membuatnya mudah diakses dari aplikasi berbasis JS, aplikasi .NET, dan aplikasi asli. Itu dengan sendirinya adalah kebaikan. Mengambil semua API Win32 lainnya tidak begitu baik. Kami masih memiliki beberapa pekerjaan dokumentasi yang harus dilakukan, tetapi ada jauh lebih banyak API Win32 klasik yang dapat digunakan di aplikasi toko sekarang. Singkat cerita, kami membuat platform aplikasi yang sama sekali baru dengan basis pengguna kecil di perangkat baru, tidak mengizinkan Anda membawa kode yang ada, dan tidak banyak orang yang muncul. Kita tahu. Makanya kita perbaiki sedikit demi sedikit. Kami juga melakukan banyak hal dengan benar, dan bekerja dengan cara kami perlahan tapi pasti menuju pendekatan terbaik dari kedua dunia. Sistem instalasi deklaratif, dalam banyak hal, adalah hal yang luar biasa.

Portabilitas kode antara aplikasi UWP dan aplikasi desktop juga dibahas di utas ini. Karena model UWP sangat menyimpang, ada beberapa poin kesulitan. Kami menangani mereka secepat praktis. Beberapa membutuhkan waktu, atau membutuhkan "istirahat besar". Misalnya, kami menggunakan nama yang berbeda untuk CRT DLL. Kami menyusun mitigasi, paket penerusan VC, tetapi perbaikan sebenarnya adalah pada akhirnya menghapus perbedaan dalam versi CRT di masa mendatang, yang secara inheren membutuhkan penggantian nama file dan perubahan besar yang melanggar. Kami sengaja jarang melakukan ini karena mengganggu.

WinRT sendiri semakin menggerakkan perangkat open source-nya, dan meskipun tidak terlalu dikenal, sebagian besar WinRT tersedia untuk aplikasi desktop. XAML adalah celah besar. Kepulauan XAML adalah langkah ke arah yang benar, tapi saya jauh lebih bersemangat tentang WinUI.

Umpan balik untuk API tertentu

Untuk beberapa hal ini, saya akan meminta Anda untuk mengajukan umpan balik jika ini adalah masalah Anda. Saya akan membantu mempromosikan masalah ini ke tim yang tepat. Tim yang berbeda di Windows masing-masing bertanggung jawab atas API mereka sendiri, dan itu akan paling efektif jika Anda mengajukan di hub umpan balik. Ini menghubungkan umpan balik dengan manusia dan cerita nyata. Ini juga memungkinkan Anda untuk melacak umpan balik. Anda dapat sedikit membantu satu sama lain dengan menambahkan umpan balik yang diajukan orang lain sebagaimana mestinya. Cobalah untuk memilih kategori yang sesuai. Jika tidak jelas, Anda dapat menggunakan "umpan balik pengembang" -> Umpan Balik API

API sistem file untuk aplikasi modern sangat lambat dan tidak terduga

https://docs.microsoft.com/answers/questions/608/please-either-allow-systemio-all-over-hdd-or-drast.html
Kami telah mendengar umpan balik ini, baik dari pelanggan dan tim kami sendiri yang membuat aplikasi. Saya berharap saya memiliki lebih banyak yang dapat saya bagikan saat ini. Untuk saat ini yang bisa saya katakan, sayangnya, adalah "kita tahu".

API / kemampuan BroadSystemAccess tidak praktis seperti yang diterapkan.

https://docs.microsoft.com/answers/questions/6483/is-uwp-the-right-development-tool-for-my-project.html
Silakan kirimkan item hub umpan balik dan kirimkan saya tautannya. Saya pribadi akan mempromosikannya dan menyerahkannya kepada pemilik yang tepat. Tingkat falloff 80% tidak baik. Saya mengerti maksudnya menjadi bendera merah bagi pengguna juga. JIKA, API file cukup cepat, sepertinya daftar akses di masa mendatang akan mengurangi setidaknya beberapa rasa sakit, tetapi mungkin tidak 'licin' seperti yang Anda miliki sekarang. Tapi kemudian, Anda berada di antara batu dan tempat yang sulit. Untuk menjadi ajaib seperti yang Anda lakukan sekarang, Anda membutuhkan pengguna untuk membiarkan Anda melihat semuanya. Spreadsheet kata sandi mereka, folder email mereka, cache browser mereka, dll. Anda mungkin dapat dipercaya, tetapi aplikasi Anda harus membuat pengguna berhenti sejenak dan berpikir tentang seberapa besar mereka mempercayai Anda sebelum menyerahkan dunia mereka.

Saya mengerti bahwa ide menutup aplikasi dan memulai ulang adalah langkah yang canggung. Ini sepertinya jenis hal yang setidaknya harus diselesaikan pada peluncuran pertama. Harap ajukan item masukan terpisah. Penawaran yang sama. Saya akan mempromosikan dan memberikan.

Berkenaan dengan apakah daftar akses di masa mendatang dapat mengakses subfolder, saya telah membuat masalah dokumentasi untuk halaman tersebut. https://github.com/MicrosoftDocs/windows-uwp/issues/2322. Perlu dicatat bahwa karena halaman dokumen ada di github, Anda dapat mengajukan masalah pada dokumen atau mengusulkan perubahan pada konten juga.

Menyeret file ke dalam aplikasi tidak mengizinkan akses tulis: Penawaran yang sama tentang hub umpan balik. Silakan ajukan, dan saya akan merutekan sesuai dengan itu.

Membuat aplikasi untuk sideloading di luar toko MS

Kesimpulan yang saya dapatkan di sini adalah bahwa sebagian besar masalah adalah masalah dokumen, tetapi ini menyentuh aspek kunci lainnya. Karena beberapa alat kami telah pindah ke proyek github dan sumber terbuka, dokumentasi telah pindah bersamanya, dan itu membuat lebih sulit untuk menggunakan dokumentasi Windows sebagai toko serba ada untuk semuanya. Saya akan mengangkat masalah ini secara internal terkait dengan masalah khusus seputar file .appinstaller dan mendiskusikan secara lebih umum dengan tim konten kami tentang cara mengatasi masalah ini dengan lebih baik.

Anda juga mencatat masalah khusus tentang perlunya merutekan melalui server untuk melakukan debug. Bahwa Anda harus mengajukan sebagai masalah terhadap proyek github yang ada.

Masalah Sertifikat Baru & Distribusi Pribadi

Ini sedikit lebih dekat dari saya (tim saya yang lebih besar juga menangani aspek pemasangan aplikasi. Saya masih menghargai masalah hub umpan balik tentang ini yang dapat saya kerjakan.

Sistem tipe WinRT memengaruhi kemampuan untuk menghadirkan API & perpustakaan yang hebat

Ketidakmampuan untuk membebani nama tipe adalah karena desain. Sampai kami memikirkan kembali bagaimana javscript (bagaimana dengan Node / V8? Apakah itu menarik?) aplikasi mengakses API WinRT, kami tidak akan siap untuk meninjau kembali ini. Masalah lain seputar properti dan NaN ada dalam masalah terpisah yang memiliki beberapa diskusi yang bagus, jadi saya tidak akan membahasnya dalam tanggapan ini.

Umpan Balik Hub harus meminta saat meninggalkan untuk mencegah penghapusan konten yang tidak disengaja

Ya, saya akan memberi +1 itu. Silakan ajukan. Ada kategori di hub umpan balik di bawah aplikasi untuk… hub umpan balik. Itu sangat meta.

API Async masih di luar kendali, dan tampak canggung untuk hal-hal yang seharusnya tidak asinkron

Ya. Hal ini terus menjadi topik perdebatan internal juga. Ada keseimbangan yang baik antara pengasuh anak dan mendorong perilaku baik yang belum kita dapatkan. Harap lanjutkan untuk mengajukan masukan tentang API tertentu yang ingin Anda sinkronkan.

Tidak ada API audio yang bagus di WinRT

Saya bukan ahli audio. Jangan ragu untuk mengajukan di hub umpan balik, tetapi saya juga akan menelepon saluran kehidupan di sini dan melakukan beberapa pertanyaan.

Sakit Papan Klip

Saya harus mulai dengan Mae Culpa di sini. Model akses clipboard kami dirancang di era Win8, ketika kami sangat melindungi pengguna. Saya mengkodekan sebagian besar. Ada alasan bagus untuk melindungi clipboard. Pengguna meletakkan segala macam data sensitif di clipboard, sementara aplikasi yang dapat menimpa clipboard juga dapat membahayakan dengan mencoba mengeksploitasi kelemahan di aplikasi lain yang mungkin memiliki lebih banyak akses. API clipboard Win32 juga memungkinkan beberapa perilaku yang cukup kuat yang dapat disalahgunakan. Oleh karena itu clipboard membatasi akses kecuali aplikasi Anda berada di latar depan atau dilampirkan ke debugger, dan sedikit mengencangkan apa yang dapat Anda letakkan di clipboard (dengan cara yang tidak akan pernah Anda sadari kecuali Anda benar-benar mencoba).

Yang mengatakan, pemberitahuan yang sedang berinteraksi sepertinya harus diizinkan akses clipboard. Ini akan memerlukan penanganan khusus karena bagaimana Windows dan latar depan dihitung, saya pikir, tetapi tampaknya tidak masuk akal. Silakan ajukan di bawah umpan balik API dan saya akan mempromosikan masalah itu ke dalam basis data bug juga.

Membungkus

Saya harap itu membantu. Saya akan melacak utas dan menindaklanjuti masalah di atas seperti yang disebutkan jika Anda mengajukannya.

Untuk menghormati tim WinUI, yang sudah memiliki banyak hal, harap biarkan utas ini berakhir dan fokus hanya pada aspek WinUI & Jendela yang diangkat di utas ini. Karena yang satu ini sangat panjang dan berliku-liku, mungkin akan membantu untuk menguraikannya menjadi masalah yang terpisah dan lebih kecil. Saya akan membiarkan ini terbuka selama beberapa hari bagi Anda semua untuk mengajukan umpan balik dan memberikan komentar dengan tautan, lalu saya akan menutup utas ini.

Jika Anda ingin lebih mendalami diskusi sistem tipe WinRT, proyek xlang adalah tempat yang baik untuk memulai. Untuk perilaku Windows API tertentu, hub umpan balik adalah pilihan yang lebih baik. Itu memang memiliki sistem komentar juga, sekarang, jadi semoga membantu.

Sekali lagi terima kasih atas diskusi yang hebat dan semua umpan balik terperinci tentang begitu banyak topik.

Ben Kuhn
Microsoft

Aplikasi Anda tidak akan ditutup jika Anda menampilkan pemilih file yang memungkinkan pengguna memilih apa yang ingin mereka berikan akses aplikasi Anda.

Saya tidak bisa cukup menekankan betapa pentingnya ini sebagai pengguna. Saya tidak ingin memberikan akses aplikasi apa pun ke semuanya, tetapi jika Anda meminta lokasi yang aneh _dan itu masuk akal_ saya akan memberikan akses.

@BenJKuhn Terima kasih atas jawaban terperinci. Sangat sangat dihargai!

• WPF. Saya memiliki hubungan cinta benci dengan WPF. Ini berguna, dan sebagian besar baik. Ketika saya membaca komentar tentang klik bersarang pada pemilih file, itu membuat saya tertawa. Karena ada beberapa kebiasaan di WPF yang membuat saya sakit kepala. Seperti fakta bahwa ketika Anda menyeret di WPF, pesan seret kadang-kadang dikirim ganda dalam pesan bersarang, sehingga Anda benar-benar melakukan penyeretan modal di dalam penyeretan modal. Anda biasanya tidak pernah memperhatikan. Biasanya. Tapi saya masih suka WPF. 😉

Saya sangat setuju. Saya bukan pendukung WPF, saya telah mencapai batas WPF sejak lama. Itulah alasan saya pindah ke UWP. Dari segi stabilitas, WPF tampaknya jauh lebih stabil.

WinRT vs. UWP vs. .NET – beberapa latar belakang

Lalu ada perpustakaan API. Kami melakukan beberapa hal hebat di sini, dan beberapa hal konyol. Kami mungkin sedikit terbawa dengan beberapa hal async.

Kamu bisa mengatakannya lagi :)

Portabilitas kode antara aplikasi UWP dan aplikasi desktop juga dibahas di utas ini [...] tetapi perbaikan sebenarnya adalah pada akhirnya menghapus perbedaan dalam versi CRT di masa mendatang, yang secara inheren memerlukan penggantian nama file dan perubahan besar yang melanggar .

Ada ETA? .Net 5?

API sistem file untuk aplikasi modern sangat lambat dan tidak terduga

https://docs.microsoft.com/answers/questions/608/please-either-allow-systemio-all-over-hdd-or-drast.html
Kami telah mendengar umpan balik ini, baik dari pelanggan dan tim kami sendiri yang membuat aplikasi. Saya berharap saya memiliki lebih banyak yang dapat saya bagikan saat ini. Untuk saat ini yang bisa saya katakan, sayangnya, adalah "kita tahu".

Sejauh ini, saya memiliki solusi - jauh dari ideal, tetapi untuk saat ini saya baik-baik saja - https://github.com/microsoft/microsoft-ui-xaml/issues/1465#issuecomment -575987737

API / kemampuan BroadSystemAccess tidak praktis seperti yang diterapkan.

https://docs.microsoft.com/answers/questions/6483/is-uwp-the-right-development-tool-for-my-project.html
Silakan kirimkan item hub umpan balik dan kirimkan saya tautannya. Saya pribadi akan mempromosikannya dan menyerahkannya kepada pemilik yang tepat. Tingkat falloff 80% tidak baik. saya mengerti

Akan dilakukan, saya berharap untuk mendapatkannya selama akhir pekan.

intinya tentang hal itu menjadi bendera merah bagi pengguna juga. JIKA, API file cukup cepat, sepertinya daftar akses di masa mendatang akan mengurangi setidaknya beberapa dari

Ya, jika StorageFile/Folder API akan secepat System.IO (atau setidaknya sebanding), itu akan menguranginya. Ini bukan karena kurang mencoba - saya telah melakukan semua yang diuraikan dalam dokumen.

sakit, tapi mungkin tidak 'licik' seperti yang Anda miliki sekarang. Tapi kemudian, Anda berada di antara batu dan tempat yang sulit. Untuk menjadi ajaib seperti yang Anda lakukan sekarang, Anda membutuhkan pengguna untuk membiarkan Anda melihat semuanya. Spreadsheet kata sandi mereka, folder email mereka, cache browser mereka, dll. Anda mungkin dapat dipercaya, tetapi aplikasi Anda harus membuat pengguna berhenti sejenak dan berpikir tentang seberapa besar mereka mempercayai Anda sebelum menyerahkan dunia mereka.

Saya sangat mengerti semua ini. Dan saya setuju dengan Anda. Titik sakit saya adalah implementasi saat ini dari semua ini. Saya sudah menulis ulang sebagian besar UI yang berurusan dengan ini (beberapa kali).

Karena itu, inilah ide saya untuk perbaikan:

• "Pilih Folder" bisa sedikit lebih membantu - saya bisa menentukan file yang saya minati, dan itu bisa menyorot kepada pengguna folder yang berisi itu
• Clipboard - jika pengguna meletakkan beberapa file/folder di clipboard, dan kemudian kembali ke aplikasi saya, saya akan secara otomatis memiliki akses ke file tersebut (mungkin Anda dapat menambahkan kemampuan "ClipboardFilesAndFolders")
• drag-and-drop file/folder - yang secara otomatis akan memberi saya akses ke file-file itu (mengapa pengguna menjatuhkannya di aplikasi saya?)

Saya mengerti bahwa ide menutup aplikasi dan memulai ulang adalah langkah yang canggung. Ini sepertinya jenis hal yang setidaknya harus diselesaikan pada peluncuran pertama. Harap ajukan item masukan terpisah. Penawaran yang sama. Saya akan mempromosikan dan memberikan.

Mengerti, terima kasih - selama akhir pekan.

Menyeret file ke dalam aplikasi tidak mengizinkan akses tulis: Penawaran yang sama tentang hub umpan balik. Silakan ajukan, dan saya akan merutekan sesuai dengan itu.

Benar, akan dilakukan - hal tentang menyeret file ke dalam aplikasi. Saya belum benar-benar mencobanya:

1. apakah ini berfungsi dengan file dan folder?
2. cara mendapatkan akses ke .Path ?
3. Apakah itu persisten (saya berasumsi tidak)?
4. Apakah saya perlu menyimpan StorageFile/Folder, atau membuatnya kembali nanti dari .Path akan berfungsi (dengan asumsi jawaban untuk 2. adalah YA)?

Membuat aplikasi untuk sideloading di luar toko MS

Kesimpulan yang saya dapatkan di sini adalah bahwa sebagian besar masalah adalah masalah dokumen, tetapi ini menyentuh aspek kunci lainnya. Karena beberapa alat kami telah pindah ke proyek github dan sumber terbuka, dokumentasi telah pindah bersamanya, dan itu membuat lebih sulit untuk menggunakan dokumentasi Windows sebagai toko serba ada untuk semuanya. Saya akan mengangkat masalah ini secara internal terkait dengan masalah khusus seputar file .appinstaller dan mendiskusikan secara lebih umum dengan tim konten kami tentang cara mengatasi masalah ini dengan lebih baik.

Ya, itu akan luar biasa!

Secara pribadi, saya telah menemukan jawabannya untuk aplikasi saya. Ini mencegah saya melakukan beberapa hal lanjutan lainnya yang ingin saya lakukan (seperti, memiliki aplikasi win32 untuk diluncurkan, karena saya khawatir bagaimana seluruh file .appinstaller perlu diubah).

Tetapi, bagi saya, ini harus menjadi bagian dari proses "Publikasikan" Visual Studio. Anda harus membuat .appinstaller untuk saya (karena mendapatkan semua nama dependensi dengan benar bukanlah hal yang sepele, dan pembaruan apa pun untuk dependensi -> ini dia lagi). Itu juga harus membuat file readme.txt, di mana ia harus menjelaskan apa yang perlu saya unggah ke server saya, dan juga memberi tahu saya bahwa saya tidak dapat menggunakan .appinstaller secara lokal, itu perlu diunduh dari server (saat pengujian )

Anda juga mencatat masalah khusus tentang perlunya merutekan melalui server untuk melakukan debug. Bahwa Anda harus mengajukan sebagai masalah terhadap proyek github yang ada.

Saya tidak ingat apa masalah itu :)

Umpan Balik Hub harus meminta saat meninggalkan untuk mencegah penghapusan konten yang tidak disengaja

Ya, saya akan memberi +1 itu. Silakan ajukan. Ada kategori di hub umpan balik di bawah aplikasi untuk… hub umpan balik. Itu sangat meta.

Benar :)

API Async masih di luar kendali, dan tampak canggung untuk hal-hal yang seharusnya tidak asinkron

Ya. Hal ini terus menjadi topik perdebatan internal juga. Ada keseimbangan yang baik antara pengasuh anak dan mendorong perilaku baik yang belum kita dapatkan. Harap lanjutkan untuk mengajukan masukan tentang API tertentu yang ingin Anda sinkronkan.

Hehe, itu daftar panjang;)

1. Dimulai dengan properti dasar di StorageFolder/File; StorageFile.GetFileFromPathAsync (+ serupa untuk Folder).
2. Memuat thumbnail (StorageFile.GetThumbnailAsync
3. Memuat bitmap. Ini sangat menyakitkan, karena dibawa ke lib lain (seperti win2d), dan saya telah mencapai ambang batas yang gila - seperti, memuat bitmap sederhana (yang seharusnya memakan waktu <20 ms), hingga 5 detik atau lebih. Jelas ada beberapa penguncian di balik layar, tetapi tidak ada yang tahu apa/mengapa/kapan. Dan ya, laptop saya adalah roket.

Saya belum melacak banyak API lain, pencarian cepat di proyek saya menunjukkan 326 kegunaan -- Saya telah banyak memangkasnya, karena banyak hal di pihak saya perlu disinkronkan.

Di atas adalah rasa sakit utama saya, dari atas kepala saya. Mulai sekarang, saya akan membuat dokumen, dan menambahkannya :)

Tidak ada API audio yang bagus di WinRT

Saya bukan ahli audio. Jangan ragu untuk mengajukan di hub umpan balik, tetapi saya juga akan menelepon saluran kehidupan di sini dan melakukan beberapa pertanyaan.

Saya tidak yakin apakah/bagaimana ini akan diselesaikan. Hal termudah adalah melonggarkan persyaratan atau sesuatu, sehingga naudio (https://github.com/naudio/NAudio) dapat di-porting dengan benar ke UWP. Untuk lebih jelasnya, itu dapat dikompilasi ke UWP di luar kotak, tetapi tidak berguna karena sebagian besar hal-hal yang bermanfaat #ifdef-ed out.

Untuk lebih jelasnya, saya tidak mengeluh tentang API suara di UWP - yang benar-benar baik-baik saja, tetapi saya membutuhkan lebih banyak. Yaitu, kemampuan untuk menafsirkan gelombang suara dan sejenisnya (yang memungkinkan naudio).

Saya telah melakukan port naudio, di mana saya cukup banyak menghapus semua #ifdefs - itu berfungsi, tetapi aplikasi saya tidak akan pernah berhasil masuk ke toko MS - dan saya baik-baik saja dengan itu.

Sakit Papan Klip

[...] Yang mengatakan, pemberitahuan yang sedang berinteraksi sepertinya harus diizinkan akses clipboard. Ini akan memerlukan penanganan khusus karena bagaimana Windows dan latar depan dihitung, saya pikir, tetapi tampaknya tidak masuk akal. Silakan ajukan di bawah umpan balik API dan saya akan mempromosikan masalah itu ke dalam basis data bug juga.

Kedengarannya bagus, akan dilakukan.

Terima kasih!

@jtorjo Maukah Anda juga memasukkan masalah # 1893 (Usulan: Akses sistem file: Berikan cara yang mudah digunakan untuk meminta izin untuk mengakses lokasi file tertentu) di item Hub Umpan Balik Anda tentang sistem File (jika Anda tidak melakukannya belum merencanakan itu, saya pikir Anda mencantumkan masalah mendasar di atas). Saya khawatir saya sudah memiliki banyak item lain untuk diarsipkan, jadi jika Anda dapat membahas yang ini ketika Anda menangani Sistem File, itu akan bagus :)

Tentu saja, saya masih akan mengajukannya jika menambahkannya ke Hub Umpan Balik akan merepotkan Anda!

@Felix-Dev Saya akan melakukan yang terbaik! Akan membuat Anda tetap diposting!

Menyeret file ke dalam aplikasi tidak mengizinkan akses tulis: Penawaran yang sama tentang hub umpan balik. Silakan ajukan, dan saya akan merutekan sesuai dengan itu.

Benar, akan dilakukan - hal tentang menyeret file ke dalam aplikasi.

Ini sebenarnya seharusnya menjadi catatan tentang membuka dari menu konteks Shell. Maaf bila membingungkan.

@BenJKuhn Mengingat repo Github ini menjadi tempat yang jauh lebih baik untuk berdiskusi untuk proposal WinRT tertentu daripada tempat Hub Umpan Balik (berdasarkan sentimen pengembang yang diungkapkan beberapa kali dalam repo ini selama 12 bulan terakhir): Apakah boleh memposting saja ringkasan proposal cepat di Hub Umpan Balik dengan tautan ke proposal yang jauh lebih mendalam yang terletak di repo ini (untuk saat ini, karena tidak ada platform umpan balik model aplikasi UWP khusus yang memiliki kepercayaan dari komunitas pengembang yang saya ketahui)? Saya telah melihat proposal disempurnakan lebih lanjut dengan masukan komunitas lain di sini sehingga tim khusus di Microsoft akan memiliki tautan langsung ke proposal yang sedang berkembang.

@Felix-Dev Untuk proposal tertentu, sejujurnya saya pikir yang terbaik adalah mulai mengirimkannya ke Hub Umpan Balik yang ditandai sebagai "Platform Pengembang > Umpan Balik API."

Melihat melalui umpan balik baru-baru ini yang diajukan di bawah filter itu, sepertinya tidak banyak umpan balik spesifik yang ditambahkan. Saya hanya melihat 30 item (paling banyak) diajukan di bawah filter itu. Namun, para insinyur telah menanggapi umpan balik di sana baru-baru ini.

Saya meminta komunitas untuk mengajukan umpan balik API mereka melalui Hub Umpan Balik seperti yang ditandai di atas, dan kami akan mulai melihatnya berkembang sebagai opsi untuk mengirimkan umpan balik API setelah proposal menjadi lebih baik.

Saya pikir @BenJKuhn akan setuju dengan saya.

Saya baru menyadari bahwa tanggapan saya menjadi sangat panjang, jadi anggap ini sebagai peringatan sebelumnya

@duke7553 Kami memiliki situasi di sini di mana komunitas harus menggunakan dua platform berbeda untuk umpan balik platform UWP mereka. Permintaan API khusus seperti (tolong tambahkan parameter x ke metode y, atau tambahkan metode untuk melakukan z) setidaknya harus diajukan di Hub Umpan Balik (meskipun mungkin juga harus diposting di tempat tambahan). Namun, masalah/proposal yang lebih kompleks dari itu (sampai ke inti dari platform UWP) pasti harus diposting di tempat lain selain Hub Umpan Balik dalam bentuknya saat ini. Tidak apa-apa untuk memposting ringkasan singkat di Hub Umpan Balik tetapi untuk hal lain, Hub Umpan Balik bukanlah platform saat ini. Baca di bawah untuk detail lebih lanjut tentang alasannya.

Dalam keadaannya saat ini, Hub Umpan Balik tidak dipandang positif oleh banyak anggota aktif dari komunitas pengembangan berdasarkan sentimen mereka yang diungkapkan dalam repo ini dan tempat-tempat lain seperti Twitter berkali-kali . Isu yang diangkat di sini misalnya adalah:

• Kurangnya keterlibatan (dirasakan) oleh tim Windows Dev (Saya baru saja melihat umpan balik API yang diajukan baru-baru ini juga dan banyak masalah di sana muncul dengan 0 komentar dan nol balasan resmi pada saat ini, terutama mengenai masalah 2 bulan dan lebih tua).
• Keterlibatan masyarakat untuk isu/proposal tertentu cukup rendah (suara naik, komentar).
• UI/UX keseluruhan dari Hub Umpan Balik yang benar-benar membuatnya cukup sulit untuk melakukan diskusi umpan balik yang menarik dengan tim dan komunitas. Tentang ini, beberapa orang di tim WinUI menyatakan bahwa mereka juga setuju dengan komunitas di sini .
• Terakhir, kini jauh lebih mudah di Github untuk menambahkan file media pendukung seperti gambar atau GIF ke proposal untuk membantu memvisualisasikannya. Saya hanya akan meninggalkan gambar ini di sini langsung diambil dari Hub Umpan Balik saat mengajukan masalah:
  

Saya tidak menggunakan Hub Umpan Balik sebelumnya untuk mengajukan masalah khusus platform pengembangan dan melihatnya sekarang, melihat bagaimana masalah di sana diterima oleh komunitas (hampir nol keterlibatan komunitas!), tim pengembang Windows dan struktur keseluruhannya, saya harus mengatakan repo WinUI tunggal ini lebih unggul dari Hub Umpan Balik pada dasarnya setiap aspek (kemudahan pembuatan proposal/keterlibatan komunitas/ketersediaan pengembang MS/...).

Itu bahkan tidak dekat, jujur.

Apalagi jika dikaitkan dengan partisipasi masyarakat. Saya tidak dapat cukup menekankan betapa luar biasa masukan komunitas dalam repo ini di sini dan telah secara besar-besaran mendorong dan meningkatkan begitu banyak masalah/proposal. Semua masukan komunitas yang hebat itu akan hilang jika hanya disimpan di Hub Umpan Balik saat ini.

Dan tentang tanggapan oleh tim pengembang untuk masalah model aplikasi UWP saya yang dibuat di sini, saya hanya akan mengatakan ini: Dalam banyak kasus seperti ini, saya mendapat umpan balik tepat waktu dengan catatan bahwa item kerja telah dibuat secara internal. Apa lagi yang bisa saya minta? Bandingkan dengan sentimen banyak pengembang yang merasa masalah mereka tidak akan kemana-mana jika diajukan di Hub Umpan Balik. Dan saya dapat melihat dari mana mereka berasal hanya dengan melihat Hub Umpan Balik sekarang.

@BenJKuhn
Tim di MS perlu secara serius meningkatkan platform umpan balik UWP mereka dan sampai saya melihat peningkatan itu, saya akan selalu menggunakan repo ini di sini juga selama diizinkan oleh tim WinUI. Umpan Balik Hub saat ini memiliki posisi terendah di mata banyak pengembang Windows dan posting dalam semalam tidak akan tiba-tiba mengubah situasi itu. Ini adalah permulaan, tetapi masih banyak lagi yang diperlukan untuk secara mendasar mengembalikan kesan negatif yang akan didapat banyak pengembang ketika berbicara tentang Hub Umpan Balik (atau platform umpan balik pengembang khusus MS lainnya seperti UserVoice for UWP yang sebelumnya ditutup). Mengingat banyak pengalaman mengecewakan yang didapat banyak pengembang UWP/Windows ketika berurusan dengan Hub Umpan Balik atau platform umpan balik sebelumnya, saya - dalam hal ini - sangat yakin bahwa tim Pengembang & umpan balik Windows perlu melangkah lebih dulu dan terutama daripada memohon kepada para pengembang untuk kembali (tanpa banyak - jika ada - peningkatan yang terlihat untuk ditampilkan). Saya menyadari ini adalah pandangan yang cukup keras, tetapi jika Anda benar-benar melihat banyak tanggapan oleh pengembang yang diberikan dalam repo ini dan banyak platform umpan balik lainnya selama bertahun-tahun, Anda akan dengan mudah melihat ada frustrasi nyata dalam komunitas pengembangan.

Saya tidak ingin bersikap keras di sini karena kedua belah pihak akan saling membutuhkan untuk menciptakan platform umpan balik yang bersemangat dan bermanfaat yang memberikan nilai kepuasan tinggi bagi Microsoft dan komunitas pengembang. Sebagai kompromi, saya telah menyarankan dalam posting saya di atas untuk memposting masalah UWP di sini di repo ini di mana mereka dapat didiskusikan secara aktif dengan komunitas dan memposting ringkasan singkat dengan tautan ke utas github yang disertakan dalam Hub Umpan Balik. Selain semua keuntungan ini untuk komunitas yang saya sebutkan di atas, tautan yang ditambahkan juga akan memberi tim Windows Dev melihat banyak tampilan berbeda yang ada di komunitas ini dan bahkan menangkap banyak ide kecil yang mungkin tidak akan pernah diajukan di Hub Umpan Balik tetapi dapat ditemukan di banyak komentar di sini .

Saya akan mengakhiri posting ini dengan tangkapan layar yang diambil dari Platform Pengembang Hub Umpan Balik -> bagian Umpan Balik API:

PS: Saya akan menggunakan posting ini untuk mengucapkan terima kasih yang tulus kepada tim WinUI lagi bahwa mereka setuju untuk membuka repositori mereka untuk meng-host masalah yang sama sekali tidak terkait dengan WinUI tetapi sebaliknya bertujuan untuk mengatasi masalah mendasar yang dilihat pengembang di UWP . Terima kasih, tim WinUI!

@BenJKuhn

Inilah masalah hub umpan balik yang saya buat

API / kemampuan BroadSystemAccess tidak praktis seperti yang diterapkan. https://aka.ms/AA804aq

BroadSystemAccess API / tidak boleh memulai ulang aplikasi saat pengguna mengizinkan akses sistem yang luas https://aka.ms/AA7zpe3

Clipboard harus bekerja setiap saat. https://aka.ms/AA804ce

Akses sistem file: Menyediakan cara yang mudah digunakan untuk meminta izin untuk mengakses lokasi file tertentu https://aka.ms/AA804cp (untuk @Felix-Dev )

Tidak ada API audio yang bagus di WinRT https://aka.ms/AA804d0

API Async masih di luar kendali, dan tampak canggung untuk hal-hal yang seharusnya tidak asinkron https://aka.ms/AA804d3

Hal-hal lain yang saya buat

Lebih detail - harus memungkinkan lebih banyak karakter https://aka.ms/AA7zws5

Pilih kategori - buat ini lebih mudah https://aka.ms/AA804cd

Hal-hal yang saya tidak yakin tentang

Seret dan lepas file/folder - Saya belum mengujinya secara pribadi. Yaitu, saya tidak ingin tahu tentang bagian drag and drop, yang tidak terlalu sulit untuk diterapkan. Saya ingin tahu apakah itu benar-benar berfungsi ketika pengguna menjatuhkan file/folder pada kontrol UWP. Apakah saya memiliki akses hanya baca (yang cukup bagi saya)? Bisakah saya menambahkan file/folder ini ke FutureAccessList?

Saya ingin tahu apakah ada yang berhasil menguji/menggunakan ini, karena tidak banyak info online.

Pusat umpan balik

Hub umpan balik bukanlah pengalaman yang menyenangkan. Untuk satu hal, masalah yang saya tambahkan tidak muncul di "Umpan Balik Saya" untuk sementara waktu - saya harus menutup dan memulai ulang aplikasi. Itu tidak ingat pilihan terakhir saya. Saya tidak bisa menulis terlalu banyak teks, tidak ada cara untuk menjatuhkan file, dan/atau gambar clipboard. Jadi saya sangat setuju dengan @Felix-Dev - sangat sulit untuk memahami di mana harus memposting masalah (selain, mulai sekarang akan memposting ke xlang).

@BenJKuhn Berikut adalah tautan Hub Umpan Balik untuk masalah pemberitahuan roti panggang tertentu yang memiliki akses ke papan klip saat berinteraksi dengan pengguna: https://aka.ms/AA7zx69

Terima kasih semuanya untuk diskusi yang luar biasa. Saya telah mengarahkan setiap masalah platform yang Anda ajukan ke tim yang sesuai. Untuk menetapkan harapan yang sesuai, izinkan saya menggambar analogi dari perburuan pekerjaan: ini seperti melewati penyaringan dan langsung ke wawancara dalam proses perekrutan. Dari sini, setiap masalah ada di tangan tim yang tepat untuk diselidiki dan diprioritaskan.

Saya menghargai upaya yang Anda lakukan untuk melaporkan masalah ini, dan akan terus melacaknya saat tim meninjaunya. Saya harap Anda masing-masing akan terus terlibat dengan kami dalam masalah yang Anda hadapi, dan saya akan melakukan yang terbaik untuk mendukung Anda dalam meningkatkan pengalaman pengembang aplikasi di Windows.

Terima kasih,

Ben Kuhn

@jtorjo dapatkah Anda membagikan laporan WACK untuk port UWP NAudio yang Anda buat?

Data ini akan membantu kami mengevaluasi batasan apa yang perlu dilonggarkan agar NAudio dapat melewati sertifikasi Store.

@mikebattista Saya telah melampirkan WACK. Harap pertimbangkan hanya masalah naudio.

Jelas, masalah dari log4net akan keren untuk dipecahkan juga, meskipun saya berasumsi dengan mem-forking log4net dan menghapus panggilan itu, saya akan baik-baik saja. Namun, anehnya mereka muncul, karena aku cukup yakin kita tidak pernah benar-benar dipanggil. Bagaimanapun...

FindFirstFileExFromApp - ini seharusnya (dan sebenarnya ada) - seharusnya tidak ditandai.

Anda dapat mengabaikan EnumChildWindows/EnumWindows - saya dapat #ifdef mereka keluar.

ValidationResult.zip

Terima kasih! Kami akan mengevaluasi kegagalan API yang Didukung. Saya telah menghubungi tim audio untuk mendapatkan masukan mereka tentang kemungkinan melonggarkan batasan apa pun di sini.

@mikebattista luar biasa, terima kasih! Sangat menantikan ini :)

@jtorjo mengenai skenario seret dan lepas:

1. apakah ini berfungsi dengan file dan folder?
   Seharusnya dan tidak untuk banyak aplikasi dan tes, jika Anda menemukan sebaliknya, silakan laporkan bug itu.
2. cara mendapatkan akses ke .Path ?
   Mungkin - Jika ada jalur sistem file nyata untuk mendukung item penyimpanan, maka ya. (hal-hal seperti perpustakaan Shell sebenarnya tidak memiliki jalur sistem file nyata)
3. Apakah itu persisten (saya berasumsi tidak)?
   Tidak, aplikasi dapat membuatnya persisten dengan menambahkannya ke daftar Akses Masa Depan.
4. Apakah saya perlu menyimpan StorageFile/Folder, atau membuatnya kembali nanti dari .Path akan berfungsi (dengan asumsi jawaban untuk 2. adalah YA)?
   Anda perlu menambahkannya ke Daftar Akses Masa Depan atau daftar Paling Baru Digunakan, jika tidak, HANYA akses yang Anda miliki adalah melalui satu objek instance, Ketika Anda melepaskan instance itu, akses akan hilang.

Mengenai menambahkan file video dari lokasi yang berubah-ubah - sistem sengaja tidak mengizinkan akses sewenang-wenang, namun masih mungkin bagi aplikasi untuk menangani kasus umum file yang ditempatkan di lokasi alternatif dan pengguna belum memperbarui perpustakaan untuk memasukkannya. Layanan pengindeks dan penyimpanan keduanya berisi kode untuk memindai drive secara berkala untuk detail (Ukuran file, dll.) dan mereka dimanfaatkan untuk menemukan file foto dan video. Aplikasi dapat menggunakan StorageLibrary API untuk menentukan apakah lokasi tersebut ditemukan yang belum ada di perpustakaan, dan jika demikian, minta pengguna untuk menambahkannya. (Ini membuat pengguna tetap bertanggung jawab dan memungkinkan skenario kasus umum) Tidak ada yang otomatis menambahkan semua lokasi yang berisi file karena tidak ada cara untuk menentukan apakah itu hal yang benar untuk dilakukan. [Saya menggunakan sejumlah alat pembuatan dan rendering model 3D dan memiliki ribuan gambar tekstur yang tidak ingin saya tampilkan di perpustakaan foto saya, misalnya]

'FindFirstFileExFromApp - ini seharusnya (dan sebenarnya ada) - seharusnya tidak ditandai.'
Sangat setuju semua *FromApp API dirancang dan dimaksudkan untuk digunakan dalam aplikasi container aplikasi. Jadi jika alat menandai salah satu dari mereka, itu adalah bug yang perlu kita atasi.

@smaillet-ms Terima kasih telah menanggapi di sini. Apakah pekerjaan sedang dilakukan untuk meningkatkan kecepatan Windows.Storage API? Kami telah menunggu jawaban untuk waktu yang sangat lama. Saya bersedia menandatangani NDA untuk menggunakan API yang ditingkatkan dalam skenario aplikasi saya.

Saat ini saya menggunakan implementasi FromApp dari FindFirstFile, tetapi tidak mungkin untuk mendapatkan thumbnail item menggunakan FromApp API.

Tingkat kerahasiaan tentang pekerjaan yang dilakukan untuk meningkatkan Windows Runtime ini kontras dengan apa yang sebelumnya telah dibagikan oleh para insinyur Microsoft di utas.

Tautan umpan balik yang diabaikan yang relevan: https://aka.ms/AA6dgqz

Hanya untuk menambahkan di sini, detail spesifik mungkin dilindungi di balik NDA tetapi jika ada pekerjaan yang dilakukan pada topik ini secara internal, itu akan meyakinkan banyak pengembang UWP jika MS akan menyatakan ini secara publik (bersama dengan pandangan umum ketika kita dapat berharap untuk melihat /dengar lebih banyak).

Ada banyak pekerjaan yang dilakukan untuk meningkatkan kinerja API penyimpanan di beberapa rilis OS. Tantangan bagi pengembang saat ini sebagian besar adalah mengetahui API mana yang akan digunakan dan kapan.

Ada banyak cara untuk melakukan sesuatu dan banyak di antaranya benar-benar salah untuk aplikasi tertentu. Sayangnya, tidak ada semacam "satu jawaban benar yang benar" karena sangat tergantung pada aplikasi dan apa yang akan dilakukan dengan informasi yang didapatnya dari sistem file. *FromApp APIs saat ini akan memberikan kinerja terbaik relatif terhadap rekan-rekan standar Win32 mereka. Meskipun seperti yang ditunjukkan di sini, ia tidak memiliki semua data shell tambahan seperti thumbnail dll. (Yang sebenarnya mahal untuk diperoleh jika tidak tersedia dalam cache). Jadi, jika aplikasi Anda perlu menemukan file yang diminati berdasarkan nama/jalur atau ekstensi, aplikasi dapat melakukannya menggunakan *FromApp API, lalu buat StorageFile berdasarkan nama tersebut untuk mengambil detail selengkapnya. Meskipun ada overhead yang digandakan dalam hal itu, karena pemeriksaan akses dilakukan dua kali dalam kasus ini. Jika Anda mencoba menemukan hanya satu file, itu sering kali tidak menjadi masalah, tetapi redundansi pada skala yang lebih besar dapat memakan biaya. Jika Anda menggunakan Storage WinRT Apis dengan Windows.Storage.Search.IndexerOption .OnlyUseIndexerAndOptimizeForIndexedProperties Anda bisa mendapatkan enumerasi BENAR-BENAR cepat, yang jatuh kembali ke item penyimpanan yang direalisasikan sepenuhnya di bawah permintaan, yang memiliki hit perf tetapi lebih rendah daripada membuat item dari jalur karena itu perlu menyertakan pemeriksaan akses tambahan. Kelemahannya adalah itu tidak berfungsi jika pengguna telah menonaktifkan pengindeks untuk lokasi yang dimaksud.

Jika Anda mengisi UI, seperti aplikasi jenis foto/media maka kelas BulkAccess mungkin adalah pilihan terbaik Anda karena diarahkan untuk skenario penggunaan di UI dengan virtualisasi dll. sehingga mereka dapat menyediakan data ke UI dengan cepat dan memberi makan lebih banyak data berdasarkan kebutuhan saat pengguna menggulir konten.

Seperti yang saya katakan, banyak trade off. Jelas, kami memiliki pekerjaan yang harus dilakukan dalam mencari tahu bagaimana mendokumentasikan proses evaluasi apa yang paling cocok untuk aplikasi tertentu. Kami juga terus mengevaluasi tempat-tempat di mana kami dapat mencapai peningkatan umum terbesar tanpa merusak aplikasi yang ada.

WinRT adalah permukaan besar dan tidak dimiliki oleh satu tim di MS, setiap tim mengevaluasi prioritas mereka untuk setiap rilis dan mungkin atau mungkin tidak mempublikasikan rencana mereka sebelumnya. Secara pribadi, saya ingin melihat hal-hal sampai ke tempat kami memiliki Zero Overhead sehubungan dengan API Win32 di dalam atau di luar wadah aplikasi. Jelas kami tidak pada titik itu sekarang dan saya tidak dapat membuat janji apa pun bahwa kami akan sampai di sana, prioritas bisnis dan rencana pada proyek sebesar Windows dengan pengguna akhir sebanyak yang kami miliki adalah proses kompleks yang melibatkan sulit/keras pilihan di semua tingkatan. (Belum lagi berbagai tantangan teknis yang bisa menghalangi...)

@smaillet-ms

@jtorjo mengenai skenario seret dan lepas:

1. apakah ini berfungsi dengan file dan folder?
   Seharusnya dan tidak untuk banyak aplikasi dan tes, jika Anda menemukan sebaliknya, silakan laporkan bug itu.
2. cara mendapatkan akses ke .Path ?
   Mungkin - Jika ada jalur sistem file nyata untuk mendukung item penyimpanan, maka ya. (hal-hal seperti perpustakaan Shell sebenarnya tidak memiliki jalur sistem file nyata)
3. Apakah itu persisten (saya berasumsi tidak)?
   Tidak, aplikasi dapat membuatnya persisten dengan menambahkannya ke daftar Akses Masa Depan.
4. Apakah saya perlu menyimpan StorageFile/Folder, atau membuatnya kembali nanti dari .Path akan berfungsi (dengan asumsi jawaban untuk 2. adalah YA)?
   Anda perlu menambahkannya ke Daftar Akses Masa Depan atau daftar Paling Baru Digunakan, jika tidak, HANYA akses yang Anda miliki adalah melalui satu objek instance, Ketika Anda melepaskan instance itu, akses akan hilang.

Kedengarannya bagus. Akan menerapkan ini di aplikasi saya di beberapa titik.

[...] Layanan pengindeks dan penyimpanan keduanya berisi kode untuk memindai drive secara berkala untuk detail (Ukuran file dll.) dan mereka dimanfaatkan untuk mencari file foto dan video. Aplikasi dapat menggunakan StorageLibrary API untuk menentukan apakah lokasi tersebut ditemukan yang belum ada di perpustakaan, dan jika demikian, minta pengguna untuk menambahkannya.

Saya tidak menentang ini, tetapi ini terlihat sebagai komplikasi tambahan pada aplikasi saya. Pernahkah Anda mendengar ada orang yang benar-benar menggunakan ini?

Saat ini, saya perlu mencari ribuan cara untuk menangani segala macam masalah terkait StorageFolder/File , dan ini hanya tambahan. Itu hanya menempatkan beban, sekali lagi, pada saya, pengembang.

'FindFirstFileExFromApp - ini seharusnya (dan sebenarnya ada) - seharusnya tidak ditandai.'
Sangat setuju semua *FromApp API dirancang dan dimaksudkan untuk digunakan dalam aplikasi container aplikasi. Jadi jika alat menandai salah satu dari mereka, itu adalah bug yang perlu kita atasi.

Sepakat.

@smaillet-ms

Ada banyak pekerjaan yang dilakukan untuk meningkatkan kinerja API penyimpanan di beberapa rilis OS. Tantangan bagi pengembang saat ini sebagian besar adalah mengetahui API mana yang akan digunakan dan kapan.

Maaf untuk mengatakan, tapi ini tidak terdengar sangat meyakinkan.

Pada hari-hari WPF, saya hanya akan menggunakan System.IO, melakukan kueri file/folder apa pun yang saya inginkan, dengan cara yang sangat mudah, dan tidak khawatir tentang kecepatan sama sekali. Saya hanya akan tahu - itu berhasil. 4000 file, 10.000 file - ini hanya berfungsi.

Ada banyak cara untuk melakukan sesuatu dan banyak di antaranya benar-benar salah untuk aplikasi tertentu.

Itu cukup banyak mengatakan - API seharusnya tidak ada di tempat pertama.

Sayangnya, tidak ada semacam "satu jawaban benar yang benar" karena sangat tergantung pada aplikasi dan apa yang akan dilakukan dengan informasi yang didapatnya dari sistem file. *FromApp APIs saat ini akan memberikan kinerja terbaik relatif terhadap rekan-rekan standar Win32 mereka.

Itu benar pasti. Sementara saya telah membungkus *FromApp API dalam kelas yang bagus untuk digunakan (untuk skenario saya sendiri), inilah yang harus dilakukan MS juga - sajikan ini dalam API yang bagus dan mudah digunakan - pembungkus C# sederhana yang akan sangat mungkin mencakup 98% dari kasus penggunaan.

Saya akan melakukannya sendiri, tetapi saya tidak punya waktu. Saya dengan senang hati dapat membagikan kelas sederhana saya dan seseorang dapat mengambilnya dari sana.

Meskipun seperti yang ditunjukkan di sini, ia tidak memiliki semua data shell tambahan seperti thumbnail dll. (Yang sebenarnya mahal untuk diperoleh jika tidak tersedia dalam cache).

Setuju - Saya sudah melakukan ini secara terpisah (meminta thumbnail di utas yang berbeda) - API kueri untuk ini akan sangat membantu. Pada dasarnya, saya akan meminta thumbnail secara massal. Dan saya bisa mendapatkan IAsyncEnumerable.

Sekali lagi, MS dapat membuat API sederhana untuk ini, dan untuk saat ini, lakukan saja .GetThumbnailAsync pada setiap file. Kemudian beri kami API, dan kemudian Anda dapat meningkatkannya (kecepatannya).

Jadi, jika aplikasi Anda perlu menemukan file yang diminati berdasarkan nama/jalur atau ekstensi, aplikasi dapat melakukannya menggunakan *FromApp API, lalu buat StorageFile berdasarkan nama tersebut untuk mengambil detail selengkapnya. Meskipun ada overhead yang digandakan dalam hal itu, karena pemeriksaan akses dilakukan dua kali dalam kasus ini.

Di sisi positifnya, banyak info sudah ada di *FromApp API - waktu pembuatan, waktu akses terakhir, waktu penulisan terakhir, ukuran file.

Jika Anda mencoba menemukan hanya satu file, itu sering kali tidak menjadi masalah, tetapi redundansi pada skala yang lebih besar dapat memakan biaya. Jika Anda menggunakan Storage WinRT Apis dengan Windows.Storage.Search.IndexerOption .OnlyUseIndexerAndOptimizeForIndexedProperties Anda bisa mendapatkan enumerasi BENAR-BENAR cepat, yang jatuh kembali ke item penyimpanan yang direalisasikan sepenuhnya di bawah permintaan, yang memiliki hit perf tetapi lebih rendah daripada membuat item dari jalur karena itu perlu menyertakan pemeriksaan akses tambahan. Kelemahannya adalah itu tidak berfungsi jika pengguna telah menonaktifkan pengindeks untuk lokasi yang dimaksud.

Ini memiliki beberapa kelemahan - pertama-tama, dalam pengujian saya, ini lebih cepat daripada file yang tidak diindeks, tetapi tidak secepat itu. Saya pikir itu 3x-5x lebih cepat, tapi itu masih sekitar 10x-50x lebih lambat dari *FromApp. Itu SANGAT LAMBAT. Selain itu, saya tidak dapat benar-benar memberi tahu pengguna saya untuk memeriksa "Semua file memiliki konteks yang diindeks selain properti file", itu hanyalah pilihannya. Dan mungkin banyak pengguna membiarkannya tidak dicentang.

Faktanya, Windows akan secara otomatis mengetahui file yang digunakan dan mengindeks folder tersebut - kemungkinan besar akan sangat penting untuk file media (video/foto/musik) dan untuk dokumen.

Jika Anda mengisi UI, seperti aplikasi jenis foto/media maka kelas BulkAccess mungkin adalah pilihan terbaik Anda karena diarahkan untuk skenario penggunaan di UI dengan virtualisasi dll. sehingga mereka dapat menyediakan data ke UI dengan cepat dan memberi makan lebih banyak data berdasarkan kebutuhan saat pengguna menggulir konten.

Sejujurnya, saya bahkan tidak menyadari ini ada - saya melihatnya saat kita berbicara.
Namun, jika saya memahami ini dengan benar, ini hanya sedikit gula sintaksis, karena akan mengalami masalah kinerja yang sama dengan IStorageQuery.

Dan masalah kinerja itu sangat besar. Mereka sangat besar, sehingga pada dasarnya, untuk sekitar 1000 file, file pertama diambil setelah 9-10 detik. Dengan kata lain, setelah Anda mulai menghitung hasilnya, itu akan memblokir selama 9-10 detik sebelum melakukan apa pun. Saya berasumsi hal yang sama akan menggunakan FileInformationFactory, hanya saja UI akan responsif selama waktu itu.

WinRT adalah permukaan besar dan tidak dimiliki oleh satu tim di MS, setiap tim mengevaluasi prioritas mereka untuk setiap rilis dan mungkin atau mungkin tidak mempublikasikan rencana mereka sebelumnya. Secara pribadi, saya ingin melihat hal-hal sampai ke tempat kami memiliki Zero Overhead sehubungan dengan API Win32 di dalam atau di luar wadah aplikasi.

Yah, banyak dari kita juga ;) Saya mengerti bahwa WinRT adalah bagian besar dari Windows, dan bagian yang berbeda tersebar di tim yang berbeda.

Sangat tidak nyaman bagi kami untuk tidak secara terbuka melihat visi MS untuk WinRT. Untuk tidak memiliki garis waktu tentang apa/kapan/jika terjadi.

Bagi saya, kecepatan menangani File/Folder adalah yang terpenting. Bagaimana seseorang bisa mempercayai WinRT/UWP, ketika melakukan sesuatu yang sederhana seperti menghitung file dalam folder bisa memakan waktu lama? Dan mencari tahu cara meningkatkannya menjadi "apakah saya akan cukup beruntung untuk pencarian google saya untuk masuk ke *FromApp API"?

Saya tidak ingin terlihat tidak tahu berterima kasih -- saya sangat menghargai Anda meluangkan waktu dan menjelaskan semua ini kepada kami. Terima kasih!

@BenJKuhn Seseorang (https://docs.microsoft.com/answers/questions/6112/updating-existing-app-with-new-certificate-uwp.html?childToView=25297#comment-25297) mengajukan tiket lain tentang The Masalah "Sertifikat baru" di sini --> https://aka.ms/AA8bw9v

Sisi buruknya -- saya mencoba mengakses ini, dan ini memberi tahu saya bahwa saya tidak memiliki akses untuk melihat tiket ini. Ini benar-benar tidak membantu dengan kredibilitas "Feedback Hub".

Mengapa Anda mengizinkan sideloading di luar toko MS, tetapi membuatnya hampir mustahil untuk benar-benar melakukannya?

Sebenarnya, itu tidak benar. Anda tidak dapat mengunggah aplikasi Anda ke MS Store dan menggunakan penginstal aplikasi sebagai cara alternatif untuk menginstal aplikasi. Aplikasi saya dilarang untuk itu selama sertifikasi.
Kebijakan Toko MS:
https://docs.microsoft.com/en-us/windows/uwp/publish/store-policies?redirectedfrom=MSDN#101 -distinct-function--value-accurate-representation

10.1.5
Aplikasi Anda dapat mempromosikan atau mendistribusikan perangkat lunak hanya melalui Microsoft Store.

Setelah saya harus menghapus file appinstaller dari server saya, pengguna dapat menggunakan MS Store lagi untuk menginstal aplikasi saya. Saya mengerti - aturan adalah aturan, bahkan saya tidak bisa mendapatkan alasan untuk itu. Tapi sungguh mengecewakan, ketika saya tahu banyak aplikasi, yang didistribusikan melalui store and appinstaller (Unigram) atau chocolatey (MS Terminal baru).

Mengapa Anda mengizinkan sideloading di luar toko MS, tetapi membuatnya hampir mustahil untuk benar-benar melakukannya?

Sebenarnya, itu tidak benar. Anda tidak dapat mengunggah aplikasi Anda ke MS Store dan menggunakan penginstal aplikasi sebagai cara alternatif untuk menginstal aplikasi. Aplikasi saya dilarang untuk itu selama sertifikasi.
Kebijakan Toko MS:
https://docs.microsoft.com/en-us/windows/uwp/publish/store-policies?redirectedfrom=MSDN#101 -distinct-function--value-accurate-representation

Saya tidak yakin kita sedang membicarakan hal yang sama di sini - di zaman sekarang ini, saya tidak dapat menemukan satu alasan pun untuk membutuhkan atau menginginkan MS Store. Daging sapi saya dengan itu adalah sangat sulit untuk mengembangkan aplikasi dan kemudian menyebarkannya di luar toko MS.