Microsoft Xamarin part8 [.NET MAUI] YouTube動画>9本 ->画像>14枚

Xamarinと.NET MAUIのスレッドです。
C#でクロスプラットフォームのアプリを開発できるフレームワーク
無料、クロスプラットフォーム、オープンソース。
対応プラットフォームは、Windows, Android, iOS, macOS, Linuxなど

Xamarin
https://dotnet.microsoft.com/apps/xamarin

.NET MAUI [.NET Multi-platform App UI]
2021年11月正式リリース予定。Xamarinの後継フレームワーク
https://docs.microsoft.com/en-us/dotnet/maui/
https://github.com/dotnet/maui

前スレ
Xamarin Part7
http://2chb.net/r/tech/1596690797/

他にも有用なリンクあったら張っていってね

主に.NET MAUI関連
https://github.com/dotnet/maui/wiki
https://github.com/dotnet/maui/wiki/faqs
https://docs.microsoft.com/en-us/dotnet/maui/get-started/installation
https://docs.microsoft.com/en-us/dotnet/maui/
https://github.com/dotnet/maui/wiki/Roadmap

https://twitter.com/xamarinhq
https://twitter.com/5chan_nel (5ch newer account)

.NET MAUI | .NET Blog
https://devblogs.microsoft.com/dotnet/category/net-maui/

MVVMってめんどくさすぎんか？
いや後発の仮想DOMの完成度が高杉たというだけなのだろうが
ベタFormsとどっちがマシなんだろってレベル
PrismとRxPropertyてのを使えば楽になんのかな…

クラスが増えて面倒だけど後でメンテするとき楽

>>5
WPFのMVVMが稀にみる駄作だからですよ

MVVMがめんどくさいって雑すぎるだろ
MVVMアーキテクチャがめんどいのかMSが公式でPrismのようなフレームワークやコンポーネント用意してないからめんどいのかどっちなんだ
後者なら同意するMVVMに限らずMSの開発環境全てが投げっぱなしでコミュニティも育たず何もなくGrapeCityやReSharperのような糞高いサードツールないと効率も悪いから糞めんどい
そしてMAUIだBlazorだ思いつきで提案してきたり頑なにASPは固辞して押し付けるくせに自分らはOffice含めた自社サービスはがっつりReact Nativeで開発とか糞ウケる

>>5
とりあえずお前のめんどくさいところを言語化しろ

>>5
Virtual DOMってReactの話してるの？
MVVMとぜんぜん違うカテゴリの話だと思うんだけど

あとMAUIはMVVMだけでなくMVUも使えるとかいてあった。
MVVM, MVU好きなほうをつかえってことらしい

WPFもMVVMは最小限でいいんだよ
コアフレームワークに入ってないのは
そういう理由と推測されるし
イベントハンドラーと組み合わせで書ける

>>11
JSやPythonが人気出た理由がお前もわかってなさそうだな
OSSコミュニティが自発的に盛り上がって便利なフレームワークやライブラリがどんどん開発されてそれがちゃんとメンテされてナレッジが整備されたからだぞ
MSみたいに最低限の仕組みは用意したお前らプログラマーなんだから必要な物は自分で作れみたいな投げっぱなしで人気出るわけねーんだわ
結局コミュニティが育たず一部の技術オタクみたいな奴らがC#マンセーしてそいつらのおもちゃになっただけでPrismやRxなんかのフレームワークやライブラリもメンテされずRxなんてC#捨ててJSに移行したし
WPF黎明期なんてINotifyPropertyChangedやICommandを毎回実装してたんだぞコーディングしながらC#やXAMLはものすごく好きなんだがMSの開発環境ってマジで糞だなってずっと思ってたわ

>>12
自分で判断できなそうで
あたま悪そう

VMの実装が直感的じゃないし冗長すぎるよね
もっとシンプルなVMが理想なんだけどReactiveProperyとかLinqとかPub/SubとかCommandとか色々書かされてつらい
なんかいい感じのジェネレータが欲しいッス

>>14
そりゃ書くからでしょ
評価して糞パターンは捨てればいい

VS2022 + MAUI preview6で順調につまづいているわ
preview 4以降はOpenJDK11を推奨とかいてあるし
preview6のmaui-checkではOpenJDK11がインストールされる。
OpenJDK11だとVSのAndroid Emulatorが起動しない。
VSの設定でJDK1.8.0-25に戻すとEmulator起動した。

MAUI preview6、OpenJDK11でAndroid Emulator起動できてる人いる？
現状、どのバージョンのJDKを使えばいいのかわからん、

maui-checkは、
? OpenJDK 11.0 Checkup...
? 11.0.10 (C:\Program Files\Microsoft\jdk-11.0.10.9-hotspot\bin\..)
? 1.8.0-25 (C:\Program Files\Android\Jdk\microsoft_dist_openjdk_1.8.0.25)

? Visual Studio 17.0.0-pre.2.0 Checkup...
? 17.0.0-pre.2.1 - C:\Program Files\Microsoft Visual Studio\2022\Preview

戻すと言うよりAndroid SDKのライセンス同意にJDK8使ってるだけだからライセンス同意後はJDK11で動くよ

MAUIってWPFでも使えるの？

いや、何言ってんの？

>>17
ありがとう、
MAUIでなくXamarinでproject作ったらJDKライセンス同意の画面がでてきて
それ以降、API30のAndroid emulator立ち上がるようになった。

MAUIはまだGUIのテンプレートでproject作れないんだな
dotnet new maui -n mauitest
でproject作れるのはわかったがBuildはエラーで通らなかった。

9月にリリース候補RCでるようだけどこの品質で間に合うのかな
RCでるまでVS2022previewでXamarinでもいじってようかな
MAUIはまだきついわ

xamarinと何も変わってない
開発体制、品質全く同じ
望みなし

PrismでMVVMやってるんだけどDynamicResoursesの切り替えってどうやるんすか？
動的にスタイル変える方法をググるとApplication.Current.Resourcesを書き換えろって出てくるんだけど
これってレイヤーが違うと思うんでVMではやりたくない

CSSだとclassだけ書き換えてスタイルを切り替えれたけどこれと同じことをやりたいつまり
・動的にスタイルを切り替える
・VMは具体的なスタイルを知らず代わりにスタイルを示す名前を扱う

Firestoreからデータ取得したいけど、参考になるサイトありますか?

>>22
DataTrigger使う
どちらにしろコードビハインドする必要があるこれはXAML(MVVM)では避けて通れないモヤモヤポイントだから諦めるしかない
ControlTemplateなんかのXAMLだけじゃどうしようもないカスタマイズしまくりのユーザー定義コントロールとかクラス拡張しまくりのコードビハインドの塊だからな
まぁ別にReact NativeだってHooksをViewに書きまくるわけだからFluxtとか何それって感じだしアーキテクチャに矛盾が生じるなんてそれこそよくあること

>>24
あざす
XAMLしんどいすね…
はじめたばかりなののこころおれそう

>>20のエラー解決した
VS2022の下のworkloadsの上から4個も追加でいれたらMAUIの新規アプリ作成できるようになった。
ファイルサイズ大きすぎるからdocument無視してUWPとかC++入れてなかった。

Mobile development with .NET
Universal Windows Platform development
Desktop development with C++
.NET Desktop Development
ASP.NET and web development (required for Blazor Desktop and the BlazorWebView control)

その他
Single-project MSIX Packaging Tools
maui

残りはmaui-checkが自動でいれてくれる。
https://docs.microsoft.com/en-us/dotnet/maui/get-started/installation

>>21
開発体制はXamarinと全く違うしクオリティは必ずあがるだろう
すでにドキュメントの充実度があがってる

https://www.statista.com/statistics/869224/worldwide-software-developer-working-hours/
Cross-platform mobile frameworks used by software developers worldwide

Xamarin 11%
C#ではトップ維持するもシェアが減った
Flutter以外、すべてシェアが減っているがMAUIが出れば流れはかわるだろう

うーむわからない
PrismのViewModelsのボイラープレートのDestroyでReactivePropertyをDisposeするコードを書いたんですけど、
このDestroyイベントが呼ばれてないっぽいです
このイベントってアプリ終了しても呼ばれないんですかね？
ちなみにランタイムはAndroidです

ReactivePropertyは使ったことないけど俺はおすすめしないな
特にフレームワークやライブラリが全く成熟せずメンテされないXamarin環境ですでにPrismですらろくにメンテされてないのに技術自慢の河合がノリで作ってろくにメンテしてないフレームワークとか俺なら絶対に採用しないわ
Firebaseのライブラリですら海外の個人メンテナーに頼っててIssue山積みなの知らなくてバグ満載でどハマりしたからな
ピンハネしすぎでまた別問題だがそれでもCOCOAの惨状とか見ればわかる通りぶっちゃけ現時点でハイブリッド開発でXamarinを選択するのはめちゃくちゃリスキーだぞ環境やコミュニティが全く盛り上がラズ成熟もしてないからなMS自体がXamarinじゃなくReact Nativeで開発してる時点でお察し

あ、はい
すごくしんどい気はしてるんだけどもうやるしかないとこまできてる
次の機会ではFlutterでチャレンジするよ
RNはRNでアップデートしんどいって聞いた

話戻すんですけどDestroyが呼ばれない件って何かわかりますかね？

MAUIとXamarinはドキュメント少ないね
サンプルアプリをbuildして動かしたあとすぐに学習が停滞する

Android Studioはドキュメント充実してると実感する
IDE触ってるだけでUIの開発がなんとなくわかってしまう。

JetPack Composeが人気らしいけど
Compose Multiplatformってすごく人気でそうじゃない？
言語がKotlinだしReactNative, Flutter, Xamarinをすぐに抜き去るんじゃないかと

VBで作ったアプリをxamarinにコンバートしてますが、情報が少ないのでKotlinやflutterで作り直したほうが良いでしょうか?
ちなみにxamarinを選択した理由はメインロジックをツールでコンバートしやすいのとvisualstudioに慣れてるからです。

>>33
動作が必要なプラットフォームは？業務用？
ユーザー数は？VBのバージョンは？
コンバートに使ってるツールは？

compose multiplatformはまだアルファ版だし業務なら使えない。
あとまだiOSなどが対応してない
https://blog.jetbrains.com/kotlin/2021/08/compose-multiplatform-goes-alpha/

IDEの違いはすぐ慣れるからどうでもいいと思う。
Android studioは直感的にUI作れるしよくできてる。すぐ慣れると思う

Flutter(Dart)への移植は絶対やめたほうがいいと思う。Flutter以外でdartほぼ使われてない。

https://www.theregister.com/2021/08/06/compose_for_desktop_kotlin_framework/

Play StoreはCompose利用らしい
2000のアプリが Compose利用とのこと
Despite only just hitting 1.0, Google said: "There are already over
2,000 apps in the Play Store using Compose – in fact, the Play Store app itself uses Compose."

>>33
VBアプリケーションは当時の流行のせいで
プレゼンテーションとビジネスロジックが密結合している可能性が高く
簡単に資産を捨てることはできないと思うよ
たぶん.NETでやる以外の選択肢はないんじゃないかな

>>33
スタンドアロンのシステムなの？

サーバーを.NETにしてビジネスロジックを全部そっちにおいて
UIは好きなので組めばいいんじゃないの？

もう勝負あっただろ
flutterは今年中にwindowsにもしっかり対応するし
flutterでandroid,iOS,macOS,windowsでさらにUWPでwebも!!
jetpack composeも正式リリースしてcomposableは状態変化を自動で検出してflutterの上位互換

maui??
ぷっ

WinUIはコントロール豊富だからこれらがwindows専用じゃなくてmauiで使えたら
他のプラットホームでfluent design!!
ってワンチャンはあったな

UnoPlatformは忘れた方がいい

>>38
MAUIもofficial wikiにbrowser対応検討中と書いてあるぞ
Blazorと連携するようになると思われる

MAUIを見下してるがflutterも負け組になるんじゃないか
Dart嫌い多いしCompose MultiPlatformがiOS対応したらFlutterはおしまいだと思うわ
Dartなんて選んだ時点で失敗は確定していた

更に優秀なのでてきて負け組になるなら優秀なのに乗り換えるだけだし
別に問題ないだろ
楽に開発したいのが目的だから
現状はトータルとしてflutterが一番楽だから使ってるだけだし
composeは一つ作りかけのアプリcomposeに移行してるけど

つか、composeがiOSに対応なんて先長いだろ?
よくわかってないが現状JVM依存してる?からiOSでは駄目なんしょ?
そこまでJetbrain頑張れる?

xamarinの場合はAOTコンパイルしてるからiOS向けokだけど

新しくなくても優れてなくてもいいから長期間メンテ最小限で動くやつがいい

>>43
JetBrainsが有能すぎるから、何でもありうるんじゃないか

compose multiplatformはbrowserとdesktopを同時に開発してきたんだろ。
しかも今アルファだが年内に正式版だすといってる。
iOSも1年以内に正式版出してくると思われる

なんでiOSは無理だと思うわけ？iOSはJVM使えないからってだけ？
KotlinもtypesafeなわけだからSwiftに変換してコンパイルするのは
別に不可能ではないだろう
有能すぎるJetBrainsならなおさら。

そんなもん正式版出てきてからでいいだろ
「正式リリースはXX年のXX月です」ってその手のやつってなかなか出てこないし

あの、xamarin native はどうなるのですか？

>>46
アルファかベータが出てからでもよいかもしれないが、
正式版出てからでは遅いな
今書いてるコードが無駄になるかが決まるから。
今からFlutter/Dartのコードは書かないほうがいいだろう

>>47
Xamarin native is moribund.
MAUIができたらMSはxamarin nativeのメンテナンス停止すると思われる

>>43
そういえばKotlinはKMMですでにロジックはiOS対応してるじゃないか
あとはUI部分だけcross platform対応すれば、Compose multiplatform出せる。

Kotlin Multiplatform Mobile
https://kotlinlang.org/lp/mobile/

KMMのアルファが出たのが2020年10月っぽいからわずか10か月で
Compose multiplatformのdesktopとbrowserを出してきたことになる。
Compose multiplatformのiOS対応、1年以内は十分可能なラインだと思うわ

そもそもIntelliJ IDEAがクソ使い辛いクソIDEなんだが
そのクソ使い辛いものがベースのAndroid Studioもクソ使い辛くてクソ重いんだよなぁ
そもそもまともなPHPのIDEがなかったからPhpStormが人気なだけでIntelliJとかVSと比較したらゴミだぞ

>>50
PHP、そもそもまともな言語ではない。
IDEは言語やフレームワーク、ライブラリのクオリティに比べたら重要度は低いと思う。

VSはWPFとかでは使いやすいがMAUI利用時はそうは思わない。
Android Studioは直感的にUIの部品を張り付けてUI書ける。
Visual StudioのWPF(C#)ライクでいいと思う。
でもXamarinやMAUIで同じようにUI書けないでしょう

Buildの時間もAndroid StudioのほうがVS2022 + MAUIより速い気がする

UI部品を貼り付け…
VBerかな？

ポトペタって最初は楽なんだけど、ちゃんと考えると辛いよね。
formsアプリでちゃんと画面のリサイズに対応したり、split系のコンテナ使ってたりしたら、二度とやりたくないって思うぐらいのものだと思って。

>>52
WPF(C#)ってかいてるだろ
Android Studio(Kotlin)でもポトペタできる

>>53
Android Studio使ってる？
ポトペタでもC#のとは違うでしょう
どの場所を起点に配置するかも上下左右、指定必要だし
マージンも指定するのが普通だからリサイズは対応できるでしょ

まぁ…初心者には安心かもね
でもMSがとっくに通り過ぎて開発者が切り捨てたアイデアなんだよなポトペタって

まさかVBってVB.NETじゃなくてVB6か？コンバートってなんだポーティングだろ？
しかもvisualstudioってレスしてるやつもやばそうだな・・・なんかただのクソ案件臭いんだが

VB.NETからの移植な。
糞案件というか個人的に作ってアプリ公開したいだけ!
しかも本職はプログラマーじゃないです。

>>54
使ってるけど、XML書いた方が幸福度高いよ。

>>55
知ったかぶりが過ぎる
VS2022使ってないだろ

ポトペタがでめなのではない。
視覚的に配置したほうが直感的にできるし使いやすい。
一時廃止されたのはブラウザとレンダリング結果が違いすぎて意味なくなってたからだ。
VS2022ではLive Previewで新機能としてフィーチャーされてるわ
EdgeのエンジンがIDEの中で使える

配置は視覚的に確認する必要があるのだからIDEでやったほうが効率いいに決まってる。

KotlinでAndroidのサンプルプログラム作ってるけど、ブレークポイントで止まらない。
VisualStudioみたいに一行ずつ実行して変数の値をチェックとかできないの?

VSと同等のIDEは存在しないXcodeもIntelliJもVSの足元にも及ばないVSのデバッガーはマジで最強VSCodeがメインになったけどVSのデバッガーが神だと常々感じる

>>59
ライブプレビューとポトペタ一緒にするのはちょっと違うんじゃない？
ポトペタだとユーザコントロールとか、リスト系のコンテナのレイアウト辛くない？

>>59
ポトペタとLive Previewは別の機能

ぜんぜん違うものを混同するあたりやっぱり初心者なんだろうね

ポトペタが廃れた理由はようするに生成されるマークアップがクソなことだよ
思い通りのマークアップ生成されないから繊細なコントロールができない(あるいは時間がかかる)
クソマークアップでも気にしない初心者向けの機能といえる
でも初心者はいつの時代にも居るから機能自体に全く価値がないということはない
でもエンタープライズでポトペタだよりってのはちょっとね

マークアップが下手すぎるのもあるし、統一したリソースを使うのも難しいんよね。
paddingとかフォントとかを全コントロールに定義するの、悪手。

ポトペタってVBAのマクロ記録みたいなもんだろ
初心者とかがマクロ記録で生成したコードに肉付けして行くと言うのはあるけど結局ほとんどの行を修正するハメになる
なので慣れてきたら最初から書いた方が速い

WinFormsならポトペタの方が早いけどXAMLは直書きの方が早いな

ポトペタ＝コードが汚くなる、というわけでもないのに何言ってんだろうな
俺はたんにGUIでUIの部品配置できると直感的でいいって話してるし
コードが汚くなるかどうかはツールによる。
Android Studioではコードは汚くならない

VSのLive PreviewもPreviewできるだけでなくそこでサイズ調整もできるから
GUIで一部のコード変更してることに変わりない

コードが汚くならないのならGUIでUI設計できる方法もあったほうがいいに決まっている

>>64
初心者っておまえのことだろう
WPF(C#)って書いてたのにWPFすら知らないからVBerとかかいちゃう
Android Studio使ってないからコードが汚くなるとかリサイズできないと勘違いする。

>>63-64
おまえのポトペタの定義で決めるな
GUIでコード変更したら必ずコードが汚くなるわけではない

Classic ASPのようなゴミコード吐くのがだめなのくらい知っている。
Android Studio全く知らないおまえはそれらと混同した初心者ってこと

NG入れました

またc#おじさんかな？

>>71
Android Studio使ったこともない初心者なのがばれて逃げやがったｗ

うーん、Androidなら余計になんだけど、ThemeとStyle作って適用するならコードベースの方が楽じゃ無い？

>>74
だよねー
同じスタイルの画面を複数作る時にポトペタしてちまちま属性設定とかやってられない
Android Studioとやらはそこら辺を忖度してくれるのかなw

ポトペタwwwクソウケるwww
未だに使ってんの現代のフロントエンド開発が理解できないVB含めたド底辺のガイジPGだけなんだよなぁ
Xcodeオンリーで開発してる奴らでもポトペタなんて使わないんだがしかも昨今はVSCodeなんかのエディタ開発全盛期だから尚更ポトペタとか失笑ものなんだが
そもそもXAMLのツリービジュアライザーですらVS2015あたりからテスト実装された新しい機能でそれまでLogical TreeやVIsual Treeは実行後に独自クラスやデバッガでノード調べててXAMLのカスタマイズは非常に大変だったんだがそういう苦労すらわからない○○なんだろうなぁ

>>76
PHPなんてやってたおまえのが底辺なわけだがｗ
結局、おまえAndroid開発経験ゼロなのばれてる
Web appとかXAMLの話にすり替えてるだけ
今そんな話していない

Android app開発でふつうVSCodeなんて使わない
VSCodeが人気とか関係ない
適材適所がわかってない
Android開発経験ゼロのひとにはわかるわけもないがね

>>74-75
直接のコード編集とGUI併用するに決まってるだろう
ほかのプロジェクトからの使いまわしならコピペするし、
ふだんあまり使わない部品ならGUIでやると細かいプロパティが設定しやすい

>>77-78
Android開発でVSCode使うけどな。
細かいプロパティ設定する事なんか滅多に無いだろ。
そんな場当たり的なレイアウトするより、プロパティ設定したコントロールを貼り付けるわ。。

おいおい現代の開発環境でPHPやJS(TS)やPythonを否定するってどんだけ時代遅れの遺物で老害でド底辺なんだレベル低すぎて会話が成立しないんだが・・・w
底辺VBおじと違ってオイラはフルスタックエンジニアなんでDBもRDBMSだけでなくNoSQLも使うけどあんたのようなド底辺はFirebaseすら触ったことないんだろうなまぁお前のにはAccessでも使ってなさいってこった

>>78
ん？
ポトペタしてコードを修正するってこと？
要するに>>67に書いた初心者ってことやねw

>>79
嘘つけ
おまえがAndroid Studio使ったことないのはばれてるしだまってろ
本家推奨の開発環境は便利な機能がある
Android Studioあるのにわざわざ低機能なVSCodeを使う理由がない

c#おじさん...

>>81
はぁああ？
ドラッグ＆ドロップしたらVBAのマクロ記録だ？
頭悪すぎ

なんかこのスレやばいな
SP appの開発したことないやつがやたら多くてえらそうにしてる

>>83
Xamarin, MAUIのスレなんてC#おじだらけだろ
慣れ親しんだC#でさくさくSP appも作れたらって夢見てる人たち

>>80
アンカーもつけられない低能が何言っても

>>82
なんでだよ。
重いじゃん。

あぼーんだらけ😅

>>87
IDEすら重いのはおまえのPCがしょぼいだけ
そんなしょぼいPCではAndroid emulatorもまともに動かせないだろう

VSCodeではできないことが多すぎる

XamarinのスレになんでAndroid StudioだのVSCodeだので盛り上がってるの

>>84
ああ、比喩も理解できないのか…
可哀想にw
まあ「その程度の」開発しかしてないってことなんだろうね

>>89
いや、動くよ。
使い方だぞ。

>>90
流れみりゃわかるでしょ
このスレ、MAUIもXamrinもAndroid Studioも使ったことないやつばっかりなんだよ
だからPHPとかVSCodeとかVBAとか関係ない話するおじいが多い

Android Studioは現状MAUIに失望して話が盛り上がっている
もちろん話したいのはIDEそのものの話じゃなくAndroid app開発なんだが
このスレのやつらは経験ゼロばかりでまともな議論ができない

ここはXamarinもMAUI経験ゼロばかりのようだが
それなら最低でもAndroid StudioとKotlinくらい覚えるべき。

>>94
そう言う話ならそっちのスレに誘導して出て行ってくれ

>>93
Xamarinに関してはほとんどVSCodeでやってるぞ。
これはガチで。

>>93
>>51,53で君が長文で反応したから話がこうなったんだろww

>>50とか突然の単発IDEの話とか無視すりゃいいのに

>もちろん話したいのはIDEそのものの話じゃなくAndroid app開発なんだが
自分でIDEの話に思いっきり食い付いた癖に何いってんだか..

Android Studio使い始めて楽しい時期なんだろうと微笑ましいw
ガチでやりだしたらポトペタなんかよりコード作った方が遥かに楽

コードの変更管理の問題もあんね
変更箇所以外を安易に変えられては困る...

あ！vsダメか...

>>99
まだこの無知はいいかげんなこといってるのか
コード作るってなにいってんだ
Android Studioでは手動で書くのと同じコードになるわけだがアホには理解できないんだな

ガチでやりだしたらっておまえAndroid未経験者だろｗ

>>98
Android StudioはただのIDEではない、Android開発に最適化されてるから
Android開発と密接な関係がある。

>>101
>> Android Studioでは手動で書くのと同じコードになるわけだがアホには理解できないんだな
Android Studioスゲーな
>>75みたいなのも忖度してくれるんだw
使い始めの信者モードなんだろうな…

Android studioとeclipseはトロいから嫌い

安定して今日もMAUIの話題無し

>>102
コピペのが速い場合はコードコピペすればいい
効率低下などの副作用がない場合はGUI designer使えばいい
併用したっていい
ケースバイケースで臨機応変にできないやつはアホだな

>>104
Android Studio凄い、俺凄いってのはよくわかった

>>104
MAUI試してみたいけど製品版のVisual Studioにまだ入れられないから試せてない

MAUIなんてあまり期待してないからな、正式リリースするまでインストール何かしないし
だから話題にする事何かないわ
取りあえず今はjetpack composeでアプリ作るだけ

>>105
俺はすごくないがAndroid Studioはすごい。
mobile appでは一番使われてるだけあって安定してるし使いやすいわ

>>106
VS2022はほかのVSと共存・併用できるよ
MAUIはまだproject templateすらGUI用意されてないし
ドキュメントも足りないし
急いでないなら9月のRCか11月の正式を待ってもいいかも

>>108
だから早くAndroid Sdutioのスレに行けって言ってるだろ
気狂いよ

MAUIの話題がないて完全なるMSの身勝手な都合で作られただけのゴミについて何を話せばええんや？w
AppleやGoogleから周回遅れでストア立ち上げて何をとち狂ったのかUWPゴリ押ししてWin32切り捨てたら総スカン食らって過疎化
ストアだけでなくデスクトップ全体のアプリの過疎化を招いてモバイルアプリあればええやんって風潮になってしまい焦ってWin32でストア配布認めますライセンス更新料も取りません手数料も10％だけで業界一安いですリッチなUIもWin32対応させますって尻に火がついたMSの下心が生み出したのがMAUIなんだが何を語れと？www
結局開発者が望むネイティブとウェブの融合は頑なに拒否してXAMLとASP(Blazor)を固辞して自社の開発ですら認めるXamarinのネイティブとウェブが統合されていないという欠点を華麗にスルーし続けるMSの開発環境とかよほどの事情がない限りあり得ないんよ

>>110
いいかげんに句読点の使い方覚えてくれ。
一文が長すぎて読む気がしない。

native, browserのcross platformはMAUI wikiに書かれてる。
desktopとmobileがnative対応したらweb appはいらないと思うわ
わざわざbrowserでやる必要がない。

ここで聞くのが良いのか分からないのですが、質問、と言うか相談をさせてください。
Xamarin.Formsで作成中のアプリ(ターゲットはUWP,Android)から、WebAPIへのアクセスを行う予定なのですが、
この時、OAuthの認証に使うclient_idとclient_secretなど、アプリに固有で出来ればユーザから隠したい文字列が複数あり、
これの保持(実装に当たって、どこにどう記述するか)に迷っています。
個人だけで使う分にはハードコーディングしちゃうのですが、一応不特定多数が使う想定なので
気休めなりにも対策できないかと考えています。
この手の隠蔽しておきたい情報の保持について、定石(個人で出来る範囲で)とかありますでしょうか？

さっさとpreview 7触ってこい

>>112
どこに保存するかはおいといて、暗号化して保存しておけばいいんじゃない。

>>112
プログラムの説明みたいな文章が一行書かれてて、それを部分的に複数切り出して結合してパスワードにするとか見たことある
いいのか悪いのか分からん

久しぶりに見たらポトペタとかいう死語が飛び交ってて激しくワロタ
使ってたらXAMLはポトペタ開発より優れてるって気づくと思うけどな
多分、彼は食わず嫌いというか新しい開発方式などに抵抗感が強いタイプの人間なのだろう

もう許してやれw

c#おじさん...

>>116
彼って誰だよ
ポトペタの定義は？
アンカーつけられない人ってこういう無能ばかり
併用できるなら使いわければいいと結論でたのに理解できていない

アンカーおじ自演乙www
アンカーおじ＝ポトペタおじ＝PHPはまともな言語じゃないおじ＝本人ド底辺のVBおじ
やっぱレベル低いやつって根本的に頭悪いというかリアルガイジなんやな

自演じゃないのにアホだな。
>>120
あと俺はC＃とWPFで開発の仕事してたから、今はポトペタなんかやってない。

Xamarin.Formsで作るとプラットフォームごとにデザインの統一感が無いんだけど、これどうにかならん？
ウェブで言うところのCSSフレームワークのような、見た目を揃えるフレームワークがほしい

>>112
そもそもパブリッククライアントから認可サーバー、リソースサーバーにリソースオーナーパスワードクレデンシャルグラントでアクセスする場合、クライアントシークレットは使わんらしいよ

>>122
無理だな諦めろプログラマーは言語やアーキテクチャやフレームワークの選定も技術のうちだからXamarin選択したのがそもそもの失敗
Xamarin.FormsとReact NativeはネイティブUIを利用するから無理Flutterは独自UIだから何もせずそのままでデザインを統一できる
ここで頭が痛いのがXamarin.Formsでプラットフォーム毎にカスタムレンダラーを実装する必要がありコードビハインドが必須でEntryのアウトラインやカラーいじるだけでもメタクソ苦労する
これがReact NativeならCSSに良く似た構文でStyleを記述すれば済むからHTMLのようにものすごく簡単にカスタマイズできる
この独自のデザインやアニメーションを実装するのがドチャクソ大変なのはXamarin.Formsに限らずWPFでもUWPでもずーっとXAMLの欠点だったんだがMSは実際に自分たちでXamarinを使って開発しないからいつ迄経っても気付かないし反省しないんだわ

>>123
句読点つかえない頭の悪そうなおじさん

とりあえずflutter誉めとけってのがずっと前からいるなw

いやXAMLのデザインの不甲斐なさは
他を知ってるなら問題だぞ

数あるクロスプラットフォームフレームワーク向けフロントエンドの中でもデザイン・アニメーション・エフェクトのカスタマイズが極めて面倒かつ困難で最低なのがXAMLだからな
React NativeのComponentもFlutterのWidgetもほぼCSSな構文でStyleをHTMLのように簡単に定義できるからやりたいことが簡単かつ迅速に実装できる
さらに輪を掛けてクソなのがMSも必要なら自分で作れと放置プレーかつコミュニティも全く盛り上がらなくてフレームワークやライブラリがほとんどなく実装が大変だから頼りたいライブラリなどもないという負のスパイラルでもうどうしようもないくらい悲惨な環境
ぶっちゃけここが一番の問題でJS(TS)やPythonのようにコミュニティが活発でどんどん増える便利なフレームワークやライブラリが使いたいから言語を選ぶという逆転現象がMSの環境では絶対に起こらないんだわ

React FlutterあたりをNGに入れるといいのかな

いろいろとアドバイスありがとうございます。やはり定番のやり方みたいなものは無いようですね……もう少し頭ひねってみます。

>>122
今相手にするサーバー側、認証の実施後に改めてaccess_tokenを得るとかで、client_secretも必要なんです。
OAuth2 よく分かってないのでアレなんですが、相手がそうなってる以上そうするしか無いというヤツで……

Xamarin.Formsでアプリ作ってるんだけど、一番下のタブバーを自動的に隠すのってどうやるの
Shellページをどう書けばいいのかわからない

<Shell.Resources>
<ResourceDictionary>
<Style x:Key="BaseStyle" TargetType="Element">
<Setter Property="Shell.BackgroundColor" Value="{StaticResource Primary}" />
・・・
<Setter Property="Shell.UnselectedColor" Value="#95FFFFFF" />
</Style>
<Style TargetType="TabBar" BasedOn="{StaticResource BaseStyle}" />
<Style TargetType="FlyoutItem" BasedOn="{StaticResource BaseStyle}" />
</ResourceDictionary>
</Shell.Resources>

<TabBar > <!-- ●自動的に隠したい -->
<ShellContent Title="メイン" ContentTemplate="{DataTemplate local:main}" />
<ShellContent Title="サブ" ContentTemplate="{DataTemplate local:sub}" />
<ShellContent Title="サブミッション" ContentTemplate="{DataTemplate local:kansetsu}" />
</TabBar>
こんな感じなんだけど、浴したのタブが自動的に隠れて、必要なときににゅるっと出てくるじゃん
ああいうふうにしたい

>>130
その必要な時はなにで判断するの？
ブラウザならマウスカーソルの場所だろうけどSPは？

UXとして自動的に隠れるのは良くないと思うんだが

>>131
自動的に隠れるのはタイマーを考えてます
出てくるのは画面の下の適当なところをタップされたとき
結構AndroidだとメジャーなUIだと思うから俺も実現したい

タイマーはあんまり見なくね？
スクロールに合わせて出てくるのが多いと思う

>>133
あ、ホントだ
下方向にスクロールしたらにゅるっと出てきて
上方向にスクロールしたら消えてるや

スクロールはスクロール位置を監視してればなんとかなりそうだけど(それもやったこと無いけど)
いきなり消えたりするんじゃなく、にゅるっと出たり消えたりするのを組み込みたいの

>>132
タイマーとか最悪だろｗ
セールスの電話とかで割り込まれたらイラっとするだろう？
なんか視界のものが動いたら視線動かしちゃうけど意味のないものだったら
すごくイライラさせてしまう。
ポップアップ広告とおなじようなもので不快にさせてしまう
それならハンバーガメニューのがはるかにまし

しまぶーのこの動画でも見たほうがいい


アニメーションでメニュー出すにしても0.3秒とか時間をかけずにやらないといけない
ナビゲーションは独自性は出さずに大手のを真似したほうがいい。
Xamarinのハンバーガーメニューとかを検索すればいいんじゃないか、英語情報含めて。

>>131
Androidアプリでよくあるよ

>>134
0.3秒じゃなくて0.2秒だった
135の動画の前半にアップルのハンバーガーメニューがあるが
たしかに遅いだろう。
にゅるっと出るという表現みるあたりこういうとろいメニューにしたいんだろうけど
遅いのはいらつかせるだけだ。
0..2秒以内に瞬時に出てくるのならいいと思う
上の動画はXamarinではないがメニューの作り方の話は参考になるはず

>>136
俺の使ってるアプリではタイマーのうざいメニューはないな
タイマーのタイミングで移動したくなるわけじゃないんだし

>>137のアップルのとろいアニメーションとかも
プログラマーがアニメーション見せたい欲求が出ちゃってゆっくりメニューになってんだとおもう

タップしやすい下タブとかおなじみのハンバーガーメニューが無難でいいとおもうわ

片手操作の割合が50%らしい、信じられない
Androidは画面大きいから両手じゃないとむり
次のアプリも片手持ちユーザーは無視して上にハンバーガーメニュー置くわ
タブレットのユーザーも片手持ち操作はしないわけだし

Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています

Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しのView typesで参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます

Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ

なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？

Nimの実験的特徴
著者： アンドレアス・ルンプ
バージョン： 1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html


Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、高速なCのソースコードを吐き出せるのでC言語でリモートワーク
されている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる

「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます

GithubのCopilotもコメントや書きかけのコードからボイラープレートやスニペットを用意するくらいっぽくて大したことなさそうだな残念だわ
個人的にアプリとDBの処理が毎度似たようなものなのに互換性がないという非常に面倒でイライラする作業だからここをAIでオートメーション化できればめちゃくちゃ嬉しいんだがな
てかいい加減ER図からまともなDB構築してくれるAIはよ作れって感じなんだがいつまで経ってもできないのにAIでアプリのコードを自動生成なんて不可能だな

Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています

Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しのView typesで参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます

Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ

なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？

Nimの実験的特徴 バージョン1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html

第二プログラミング言語として Rust はオススメしません Nim をやるのです
https://wolfbash.hateblo.jp/entry/2017/07/30/193412


Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、高速なCのソースコードを吐き出せるのでC言語でリモートワーク
されている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる

「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます

メインページからサブページのテキストボックスの参照とかどうすればいいですか?
sub.txtNameとかやるとエラーになる。

xamarin.formsでタブAからタブBのテキストボックスの値を参照できないので、どうすればいいですか?

タブA.csから
タブB.txtName
を参照するとエラーが出る。

別のスレで答えたぞ。
マルチしたらどこで答えたらいいか解らんくなるので辞めて。

rowの高さをポイント指定して決め打ちすればいいという話ではなくて？

色々の高さが不定なんでしょ
>>147

>>147
>>148
色々の高さが不定ってことです

GridからStackレイアウトに変えたら内容に合わせてFrameが伸びるようなった
ただ今度は隣接する要素に依存してFrameが若干潰れてマージンが増えたように描画されるようになってしまった
もう何がなんだかわからない

だんだんレイアウトのやり方がわかってきた
Reactと同じで、小さいGUI部品を地道に作りこむのがコツだね
でもContentViewだとReactiveProperty、というかMVVMパターンががうまく機能しないんで、別の苦しみがある
BindableProprrtyが凄まじくダルい

部品化してると普通のプロパティはBindablePropertyでいいんだけど
中にListViewとかあってBindingContextがネストしてると
もうどう実装していいか分からなくて{Binding なんとか}と自分で実装したBindablePropertyが
混在して訳が分からなくなる
何が正しいんだろうか、動いてるからいいのか

ContentViewの実装をスマートに解決してくれるライブラリがあればな
ReactivePropertyでいいかなーと思ったけどこいつはDispose問題があるんで断念

Prismが管理してるVM、DIのシングルトンっていつ破棄されるのだろう
ナビゲーションでVを破棄した時は問題ないのだけれども、強制終了した時にデバッグログが出ない

そりゃ強制終了したらどんなクラスだって正常にファイナライザー走らないよw

そうなのか
なんかプラットフォームの方でタスキル時の安全な終了手順が用意されてるのかな、と思った
スマホユーザーはかなり気軽にタスキルするのに、終了処理がこんな杜撰でいいのかな…

>>156
一般ユーザーがやるようなスマホのタスクkillは強制終了じゃなくてちゃんとした終了イベントがくるでしょ

IDestructible実装すりゃいいんじゃないの知らんけど

.net maui延期wwww
flutterみたく自前描画として大変じゃないのに
xamarinと何も変わってない
98%失敗する羊羮

期待はしてない

そもそもMSのOfficeもTeamsもSkypeも自社のXamarin使わないでReact Native使ってんだから答え出てんだよな
今やゲームですらウェブでサービスするのが常識の時代にデスクトップとモバイルだけのなんちゃってハイブリッドなんて選択肢にすら入らない
しかもXAMLと言う時代遅れのフロントエンド実装はゴミだしフレームワークもライブラリも全然ないしコミュニティも盛り上がってないしググっても英語ですらナレッジがまったくなくてマジでオワコンなんだなって感想しかねーわ
個人的にハイブリッドのフロントエンド実装はプラットフォーム毎のUIを統一するのが一番手間がかかるところだから独自UIでデフォのまま統一されてるFlutterが一番好みだな

>>161
独自UIだよなーーやっぱ
ネイティブにこだわるの結構多いけど

Xamlでなければ悪くないと思う
C#はなんだかんだ言って書いてて安心感がある
なのでBlazor Nativeに期待しておこう
できれば独自UIのサポートも

別にXAMLでもASP(Blazor)でもどちらでもいいからWeb～Mobile～Desktopのフロントエンド実装を統一しろってことなんだわ
昔ならいざ知らずモダンな言語が溢れていて便利なフレームワークやライブラリが利用できる開発環境が支持される現代においてC#の利点なんて静的型付けで開発できることが全てなんだからC#の素性や財産がどうのって解釈は的外れで筋が悪い
しかし結局ウェブの連中が老害認定してあれだけ否定してた静的型付けやサーバーサイドに先祖返りしてるのを見ると笑ってしまうんだがな

>>164
flutterでok!
勝負ももうついてる

flutterは>>165みたいなのがいっぱいいるから近寄らないようにしている

>>27
maui延期
全然駄目じゃん
何も変わってない

xamarinで正規分布グラフが作れるライブラリない?

>>168
jsでやれ

XamarinというよりMSの開発環境であれがしたいこれがしたいで調べて探してまともなOSSのフレームワークやライブラリがあったためしがない
XamarinなんてFirebaseライブラリですらバグだらけでまともに動かないクソっぷりなのがマジで終わってる
GrapeCityみたいなコンポーネントやReSharperみたいな開発支援系は多いがどれも法外なライセンス料だしな
一昔前なんて日本語OCRなんてパナが特許持ってるからゴミみたいなライブラリを法外な価格でしか使えなかったが今はAIのおかげでまともなOSSやサービスが利用できるから本当に良い時代になったわ

MAUI延期かよ
もうMSのやる気が感じられんというか
TypeScriptとVSCodeは熱心に更新してるし温度差あり過ぎなんだが

ぶっちゃけ毎年予算を使い切らないと次年度から予算減らされるから仕事してますってアピールしてるだけなんじゃねーのって思ってるわ
ホンダのSRSなんてガチでそうなってて鈴鹿レーシングスクールの面接がホンダの入社試験で責任者はモータースポーツなんてわからないド素人総合職サラリーマンで3～5年で入れ替わるから誰もやる気なくて毎年決められた予算使い切ることだけしか考えてない
あながち間違ってねーんじゃねーのだってMSのメインがXamarinじゃなくてReact Nativeなんだから笑っちまうだろ

Micr※s※ft Akan Unk※ Irane

Microsoft Silverlightがオープンソース化、「OpenSilver」ベータ版リリース
https://news.mynavi.jp/article/20210916-1974193/

懐かしいねSL

Androidアプリ公開したけどアップデートのバージョンって整数じゃなきゃ駄目なの?

>>176
整数だけ
Androidの仕様

maui延期なんだな
2022第２四半期目標

このえんえんとXAMLディスってるゴミなんなのw

あーこれはFlutterに持っていかれるな

多少は流れると思うけどこれでFlutter行く勢はとっくに行ってるのでは
まあ案件とかにもよるけど。
ワイは今はUnityで作ってるけど3dとか絡まないアプリ次来たらmauiは検討するわ

流れる流れないとかそういう問題じゃねーんだよな
個人なら好きにすりゃいいだろうがこと仕事においては精力的に継続してメンテしてくれないと困るわけよ
よっぽどMSKKとのしがらみがあるとか出ない限り今や国内の業務システムでもMSの開発環境なんて少なくなってるぜ
ウェブやアプリなんてそれこそMS？何それ？おいしいの？って感じでC#？あー名前は聞いたことあるってレベルだからな
ハイブリッドの開発環境はReact NativeがメインストリームでFlutterがそれを追うって感じだなXamarinとかもう時すでにおすしってことよ

気にいらん

Flutterは全く使われてる気配がないよ

日本ではな
IT後進国の日本ではAppleプラットフォームはObjective-C、AndroidはKotlinと結局ネイティブで開発してるからな
理由は簡単で日本はIT後進国かつ多重請負中抜きピンハネの人月仕事が常識だからエンジニア()が調達しやすい開発環境しか採用されないからな
自社リソースで完結できるベンチャーなんかは普通にReactやFlutter使ってるからな

ないわー

今年のGoogleIOでPlayStore新規アプリの1/8はFlutter製って発表してたよ

flutterの技術者募集も増えてますからな
XAML系列の要員募集案件とか殆どみない

ドヤッ

両方使ってるけど、flutterは日本語の入力でカーソルが見えないとか微妙な残念仕様はある。
その代わりiOSとAndroidがバッチリ揃うんだけど。
割とストアのアプリでも使われてるの多いよ。
ライセンス情報とか読むと面白い。

>>190
両方使ってて生産性的にはどう？
ザマリンはネイティブのAPI触りやすかったりするところいいと思ってるしF#使えるから捨てがたい

>>191
Xamarinが好きなんだけど、やっぱ重い。
最近、トレースAOTみたいなの入ってだいぶマシになったものの、って感じ。
ただ、ネイティブ叩けるのは俺も全く同感。
Mauiの新しいコードでUIを表現するあの最近のUIフレームワークの機能、Dart書いたらUIに全振りしたDartに勝てるわけねえなって思ってしまったぐらいDartは出来が良いと思う。

>>192
泥の方だよね？最近のは追ってないけどやっぱり重いの相変わらずかー
マウイでもなんかより層を薄くする仕組みになるんだっけ？

日本語入力とかトラブらないんならflutterでもいいのかもしれんな言語やら環境やらあまり増やすのもあれなんだけど

Hi echo,
We’re writing to let you know that on September 27, 2021, we will be updating the Firebase Data Processing and Security Terms and Crashlytics and App Distribution Data Processing and Security Terms.

As part of these changes, we will incorporate the new versions of the Standard Contractual Clauses (“SCCs”) approved by the European Commission on June 4, 2021. The new SCCs replace the clauses previously approved under Directive 95/46/EC.

What happens next?
No action is required on your part to accept these updates. These updates will apply to your use of the relevant service(s) from October 27, 2021.

You can review more information about the new SCCs in the Privacy and Security in Firebase resources.

こういうメールが来たけど、無視していいよね?

書いてあんじゃねーか

Androidアプリを公開したので、今度はiOSアプリを動かそうとWindowsからMacにリモート接続して実行するとビルドエラーが出まくる。
エミュレータはWindowsPCに表示されてるんだけどね。

しょうがないからXcodeでswiftを触ってみたがC#より簡単じゃね?

ハイブリッド特有の環境ごとのエラーに悩まされないからフロントエンドを共有できないというジレンマは残るがネイティブで書いた方が結局のところ一番楽だったって判断でハイブリッドやめるところは多いのは確かだな
ReactにしてもFlutterにしてもネイティブ実装がくそ面倒だし3Dは一切実装できないし古くなった開発環境やパッケージのアップデートでドツボにハマるし俺も今進めるならネイティブ実装だな

自分の作るやつはアプリ側でモリモリ実装してるやつが多いから、別に作るとか考えられん…
サーバにロジック逃がせるならアリだな

そういう意味ではXamarin.Forms使わないXamarinって本当はけっこういい感じだよな？
OSごとに思想が違うUI周りはそれぞれで作って、ビジネスロジックはモデル層で共通化
ネイティブの関数もほとんどそのまんまの名前で楽々呼べるし
技術者集めもネイティブプログラマにC#覚えてもらうだけ
ネイティブライブラリ利用はObjectiveSharpieとかツールがあるしまあいける

本当はXamarinすごいよな？

俺はXFも嫌いじゃないがね
XNativeもほぼただラップしてるだけで色々共通に使えるしフラッターじゃやりにくいこともできるし

C#初心者です。
長いループ文の中でOxyplot使ってリアルタイムに折れ線グラフ表示したいけど上手くいかない。
何かいい方法ありますか?

長いループ文をやめよう

こいつちょっと前からこのスレに住み着いてくだらねぇ質問連投してた馬鹿だな
この前も同じ質問してたなここはお前の質問箱じゃねーんだよクズwww
まぁ心優しい俺様が教えてやるよ

答え：
1. 開発環境をReact Nativeにする。
2. ApexCharts.jsを利用して実装する。

以上

あぼーんになって見えないよ。
暴言は全て非表示にしてる。

長いループ文か、プログラマのどちらかをやめよう

>>202
スレッドか非同期使う

長いループ(笑)
初心者がXamarinを選択した時点で詰んでるってことをズバリ指摘してやったのに煽ってくるとかガチガイジだったようだなwww
MSの開発環境は必要な物は全部自分で作れが基本、ろくなフレームワークやライブラリもないから人気ねーんだってことがまだ理解できてないみたいだなwww
PythonやReactが何で人気出たかってコミュニティが超活発でググればいくらでもナレッジやHow Toがあって何より超便利なフレームワークやライブラリが沢山あってそれが継続的にメンテされてるからなんだよ
得にPythonなんて特定のライブラリ、BeautifulSoupやPandas使いたいからPython使ってるレベルでトータルの開発環境で人気があんだよ理解したか？w

またあぼーんになってる（草）
荒い言葉でマウント（草）

（草）ってスタイルは初めて見たな（草）

>>208
無能には辛い環境ってのがよくわかった

開発環境なんかその時に好きなのを選べばいいのに
何でそんなに憎しみを燃やすのか、その心理に非常に興味があるな

>>212
個人でしか開発したことがない人？

Visual Studio 2022 for Mac もう使ってる人いる？
Xamarin開発問題ない？

>>213
案件だってその時に1番いいのを選ぶだけだろ？

案件だと最優先は要員の確保ができることじゃない？

>>216
いや、客の要望だよ

知見と技術を買われてXamarin開発のチームリーダーとして招集されたが気がついたら何故かReact Nativeで開発してたこともあったな
今企業、特に国内でXamarin選ぶやつなんてMSKKとよほどしがらみがない限りまず有り得ねーんだわwww

ねンだわ

>>216
それを含めての、1番いいの、だぞ

c#で書きたいって想いだけでXamarinやってるから案件とか気にしたことないな

ProjectReunionでUWPからWin32に移行するガイドライン発表されたがグダグダやなwww
重要なの項目を以下にまとめてみた

・MSはUWPからWin32への移行を強制や推奨しない。 ←またこれ？んでUWPとWin32が混在してグチャグチャで開発者に負担だけ強いるいつもの投げっぱなしwww
Appleみたいにリーダーシップ発揮して環境を統一しろや！

・今後の開発はWindows App SDKがメインになる。WinUI3.0～やWindowsAppSDKにはWin32からしかアクセスできない、UWPはWinUI2.xと.NETCore3.1まで。 ←またこれ？また分断すんの？でもUWPは残すの？メンテする現場がまた地獄を見るんだが？www

・UWPのみのプラットフォームはまだ存在する。HoloLensとXboxはUWPでしかできない。 ←意味不明、だったらWindowsAppSDKでWin32への回帰いらんやろ、UWPをネイティブとウェブを統合して昇華させろや！

Windows StoreでAndroidアプリ配布できてAndroid Subsystemでそのまま動作するんだからもうMSの開発環境でWindowsアプリ作るアホなんておらんやろwww

UWPはUWPとして必要だろ
すべてのアプリがフルアクセスで動作してもセキュリティ的に嫌すぎる
例えばTwitterアプリなんか基本ネットワークアクセスだけが必要で、ストレージに
自由にアクセスできるwin32アプリだと嫌すぎる

サンドボックス化で誰も幸せにならなかったんだが？デスクトップアプリまで死亡して藁にも縋る思いでAndroidアプリ許可、Win32回帰、手数料15%、独自決済なら0%という全面降伏焼き土下座でまだそんなこと言ってるやついるんだなセンスないわこれが雑魚奴隷プログラマーかwww
そもそもPCLで散々苦しんだ開発者はサンドボックス化でAPIアクセス制約なんて誰も望んでないんだよ馬鹿www

UWPからWin32に回帰するのではなくてUWPで導入された要素をWin32から利用できる様にするため今後はWindows App SDKに統合するということ

それはどこ情報なんだ？そもそもMSは当初はUWPにFluent Designなんかを持ち込もうとしてたのに急遽Win32だけになったんだがそれについての反証してみてくれよ

現在はFluent DesignはUWPからだけしか利用できない
今後はWin32からでも利用できるようになる

WinUI3.0はWin32だけなんだよ俺が今WindowsAppSDKでWinUI3.0のWin32アプリ触ってんだがwww
知ったかも大概にしろよそもそもなんの根拠もないから反証になってんねーんだよ

Win32のフォームをアクリルに出来るの？

>>226
そもそもFluent　DesignはWinUIじゃなくてUWPの機能の一部としてくつられたもの
その機能をWinUI3にも移植したに過ぎない
つまりUWPのFluent Designは完成している

>>229
reunion0.8でアプリ内のアクリルは出来る。
出来ないのはアプリを透過してウインドウの壁紙や下のアプリが透けて見えるアクリル
これもロードマップには載っている

両者とも微妙に間違っているようだね

真っ赤にしてるやつ脳みそアッパラパーなの？
「WinUI 3 での実稼働可能な UWP アプリのサポートは、現在はプレビュー段階です。WinUI 3 - Project Reunion 0.5 Preview に関するページを参照してください。」

が、アップコンテナってどうなるんだっけ？正直UWP色々めんどいから自由にかいはつできるけどコンテナで外部へのアクセスをコントロールって方が良いんだが

そもそもXamarinってUWPがどうなろうとあまり関係ない気がする
そういう部分を吸収するためのフレームワークじゃないの？

MSはUWPを捨てる積りだろ
いきなりやると混乱するし総スカン食らうから
だましだましWin32に戻す積りだろ
10年後にはUWPは消えてるよ

レベル低いやつばっかだな特にこのアップコンテナとか独自の造語展開するこのにわかがキモすぎるなWinUI3.0はフロントエンドの話なんだがwww
UWPの前身であるWinRTからストアアプリとデスクトップが分断されたことすら知らん浅薄さがやばいなwww
まぁ5chでにわか底辺PGのクズと議論するだけ時間の無駄だし情報提供してやる必要もないから教えてやらんwww

教えれないんでしょ無理すんな

アップコンテナが独自用語とか言ってる時点でお里が知れるわ

Win11 Preview USで早速Amazon App Storeのレビューが始まってもうたな
WSA(Windows Subsystem for Android)で全てのソースコードがサイドローディング可能でWindows App SDKとWinUI 3.0が始まる前から終わってて草
Android用のスマホとタブレット向けのアプリを実装すればそのままWindowsで動くんだから誰がMSのオワコン開発環境で実装すんだよ
ReactやFlutterで書けばWeb/ネイティブ/Windowsデスクトップまで全て対応可能なんだからMSの開発環境がマジでオワタ
MS自らMSの言語と開発環境使ってる技術者をコケにして切り捨てるとか新しい煽りだなwww

WindowsAppSDKとWinUI3はWindowsに限られた話
モバイルなら素の.NET6とMAUI

ReactやFlutterじゃ、Winの他のアプリからD&Dすることすら大変なのでは。
デスクトップは複数アプリ往復するのがスマホやタブレットとは異なるわけで。
なぜディスプレイ2枚ある人も多いのか考えないと。

>>238
この人書いてることが色々と見当違いで草生える

C#で一つのコードで開発したいからMAUI頑張って欲しいのぉ 延期は残念過ぎる
独自UIだと色々と楽そうだけど今のところその予定はないのよね

ReactならTypescript or Javascript、Flutterならdartだけで開発できるぞ
結局MSの開発環境にしがみついてるやつって>>242のC#で開発したいという言語に依存した底辺プログラマーなだけなんよ
ぶっちゃけアプリのフロントエンド作るだけなんだから言語なんてなんでもいいんだよキャッチアップできない雑魚に合わせるからいつまで経っても普及しないわけ
ハードウェアでもソフトウェアでもAppleに負け続けてるのがその証拠、MSだけでなくIntelのCPUもM1にフルボッコにされてWintel完全に崩壊したからもうMSの開発環境なんてまともな企業はどこも使わんよ

ひ…ひどい…

>>243
普及してないものを使ってもらいたい態度じゃないなあ

243が正しい

>>243【審議中】 ( ´・ω) (´・ω・) (・ω・｀) (ω・｀ )

>>243
こいつがjsやDartがC#より優れてるとしてる根拠が全くわかんねんだけど。やってる事一緒やろ

MSをこき下ろしたいで何も考えてないからこういうノータリンな言説しても恥ずかしいと思わねんだろな
TwitterでもMSに親殺された輩よく沸いてるけどその類？

>>243
おいおい
MSはとうの昔にオープンソース派に転向済みですよ

優れてるなんて一言も書いてないんだが日本語読めないのか故意にミスリードしてるのかどっちだ？
C#という言語に依存して上から下まで全部C#で開発したいからがんばぇ～なんて言ってんのは雑魚プログラマーだけだよって話なんだが？
適材適所でその時一番コスパの良い開発環境使うのがフルスタックエンジニアなんだよ言語に依存して開発環境の選定なんて普通はしねーんだよ
そんなの日本のITを世界最低の中間搾取ゼネコンビジネスに貶めたマネキン紹介(人材派遣・SIer)の発想なんだよ

やりたい事に合う言語を使うとしあわせになれますな
言語の習得より環境、ライブラリー等の習得の方がコストが高いと思います

よく読んでないけどいろんな開発環境使える派遣の俺すげーってこと？w

ベンダーロックインされるからMS言語は避けろと、あわしろ氏が言ってたけどな。

すると、Google言語、Apple言語、Mozilla言語、Jetbrains言語、Oracle言語もダメだな
まあ、俺は C++ 好きだよ

>>253
誰やねん

言語自体の話題はここじゃない気がします

>>250
優れてるとこないならざまりんでええやん。アホ？
後々のメンテやら社内のエンジニアとか考えた時に、いろんな言語や環境を食い散らかすとか普通はしないと思うけどね
選定権のない下請けエンジニアくんなの？

読解力なさすぎだろ君

いつもの彼だ、そっとしておいてやれ

c#とvsでスマホアプリ開発できるとかコケるはずないだろって感じなのになんでこんな過疎るん？
どうイケてないのか調べてもよくわからん

>c#とvsでスマホアプリ開発できるとかコケるはずないだろ

ωωω

・C#用のフロントエンド実装とアーキテクチャが実質ベンダーロックインされたXAMLとMVVMしか用意されてない。
・dot NETもC#もXAMLもOSS化されたが時すで遅く人気が出ずコミュニティも盛り上がらず積極的なコントリビュートやコラボレートもされないのでまともなフレームワークやライブラリがなく人気が出ない(ループ)。
・Pythonのようにフレームワークやライブラリ目当てで言語が採用されると言うコミュニティベースの人気や活気がないのでデベロッパーの母数が圧倒的に少ない。
・何よりオーナーかつコントリビューターであるMSが作りっぱなし投げっぱなしで便利で使いやすいフレームワークやライブラリを全く用意しない上にバグをコストが合わないから仕様だと放置する始末。
・今一番人気と活気のあるエディタであるVSCodeでは静的型付けであるC#を使う一番の理由になる世界一優秀なVSのデバッガが使えない。

まぁまだまだあるがパッと思いつくだけでもこんなにある、逆になぜFlutterやReact Nativeを採用せずXamarinを採用するのかその正当性と妥当性の根拠を聞いてみたいわ

vs2022はよ

>>262
俺はキミがこのスレに来て長文を書いている理由を聞いてみたい

>>262
んじゃお前パイソンでクロスプラットホーム開発してろよw
お前が言ってるもの全部当てはまる言語や開発環境ってどれ？
C#は言語インデックスでも普通に上位だし、ゲームからサーバーまで開発できる幅広い言語だよ？
むしろ他のでそんなことできるの？

https://vscode.dev/

VｓCode　のWeb実装

なんというか時代に狂わされた人間って感じがする
彼は何も作れない何も生み出せない人間なのだろうと思った
技術選択はプログラミングの本質的なものではないんだ

そういうエンジニアはC++かRustかGo使ってるよ
少なくともC#使うことはないね

.netは言語、ランタイム自体の開発は頑張ってるけど、それ以外が駄目だからな

mauiもUWPぐらい頑張ってればワンちゃんあったけど、全く力入れてないから延期されクライアントサイドはunity以外は絶滅危惧種

サーバーサイドでは誰使ってるのかしらんが

sliverlightやUWPは開発リソース大きくさいて力入れてたのはわかった

短期間でどんどん進化して仕上げてきたからな

mauiやwinuiはどうみても力入れてない片手間プロジェクト

まぁ、でもWPF、Sliverlightそして今回のUWP
頑張って作ったけど速攻で見捨てるマイクロソフトある意味すげぇw

WPFとWinformsが結局しぶとく生き残ってる

まぁ結局そういう結論になっちゃうよね
いくらOSSにしたってMS以外にコントリビュータもメンテナもいないんじゃMSが見限ったら終わりだからね
現代の開発環境はコミュニティベースじゃないとユーザー数が増えないから発展もなくて成功しないんだよ
MSもそれに気付いたからOSSにしたけど音頭取るべきMSにやる気がないから誰も見向きもしない
俺の予想通り毎年予算使い切らないといけないから仕事してますポーズで自分らで仕事作ってるだけなんだろ
MSの開発環境でちゃんとメンテされてんの結局VC++だけなんだからな

>頑張って作ったけど速攻で見捨てる

自社では造ってないやろ
他社が造ったのを会社ごと買うのがMSの手口

どうでもいいけどsilverだな
flutterのsliverじゃなくて

>>262
は？VSCでc#のデバッガが使えない？ベンダーロックインされたニワカか？

VSのデバッガがVSCodeで使えるなんて初耳だな
にわかですらないエアプとか草

>>277
> VSのデバッガがVSCodeで使える
誰もそんなこと言ってないけど頭大丈夫？w
とりあえずこの辺りでも見とけ
https://docs.microsoft.com/ja-jp/dotnet/core/tutorials/debugging-with-visual-studio-code

VSのデバッガーが使えることだけがMSの開発環境を選択する理由ではあるよな

デバッガは知らんけどホットリロードはVS2022以外で使えなくなりそうだったよね
XamarinFormsやF#も対象から外されそうだった
今回は反発多すぎて撤回してたけど
https://japan.zdnet.com/article/35178568/

MSDNダウンロードとプロダクトキーを目当てにVSEnterpriseサブスクリプションを継続してる

>>273
一番メンテされてるのはVC#だろ

>>274
シルバーライトどっから買ったの

>>282
ろくな知識もないくせにMSを叩きたいだけだからそっとしといてやれ

>>280
ホットリロード廃止の理由もソース消しちゃったテヘッだからな
手戻りのコスト掛かり過ぎるからホットリロードやめまーすしたらコミュニティにブチ切れられて慌てて再考した結果続けまーすてあんたら馬鹿にすんのもいい加減せーよとまさにMSらしい一幕だった
ホットリロードよりもいい加減XAMLでブレークポイント実装しろよ
ReactもFlutterもViewでブレークできるのに今まで何してたんだって話

>>277
VSのデバッガ同等のがVSCでも普通に動くとまで深読みして言ってんだけどな

そもそもc#エンジニアのかなりの割合がエディタにVSC選択してる時代なんだが時代についてけてんの？

>>285
>>ホットリロード廃止の理由もソース消しちゃったテヘッだからな

それまじすか！

https://github.com/dotnet/maui/issues
まぁ、バグだらけなんだけど
到底、Q4に.net 6と共にリソースできるレベルじゃなかったし、
リリース後もユーザー増えてバグ潰しが進まないだろうしオワコン

Viewでブレークポイント設定したいと思ったことないわ

>>289
たいした事やってねーーからだよ

まあほんと無能だからビューでデバッグ必要ってなるんだと思うわ

GitHubにVisualstudioで開くってボタンがある。
便利。

>>291
有能ならデバッガ不要という珍論乙w

デバッグは心の甘え。
真剣に書けばバグなど出ない。

日本は甘えんぼさんが多すぎる。

有能はバグを入れない

>>293
XAMLとMVVMという環境でビューでデバッグ必要となるのは無能と言っていいのでは？という話だよ

カスタムコントロール作るときとかデバッガ使いたいけどな

Viewでデバッグいらないは斬新な珍論www
これだけで雑魚グラマーだとバレてしまうのがプログラミングの面白いところだよな
VisualTreeやLogicalTreeすら存在を知らないXAMLをHTMLのように使ってる雑魚がこのスレ多すぎるんだがこのスレはマジでレベル低すぎるだろ・・・w
XAMLがどういう仕組みなのかすら理解してなくてゴリゴリのユーザー定義コントロール作ることもないんじゃ実行時にベースの要素を組みあわせて自動的にバッキングフィールドが作られることも知らんのだろうな
そりゃLogicalTreeと睨めっこしながら複雑なカスタマイズしてるなんて夢にも思わんだろうな
GrapeCityと変わらんレベルの物を単発プロジェクトでも普通に個人が作ってんだぞレベル低い奴らには信じられないだろうがw

>>297
自称有能さん
実は単なる無知でした
ってかw

とある的外れな持論を単発が連続して書き込むのこのスレ特有の珍現象なんだよなぁ・・・w

>>298
コードビハインド側でデバッグしたいはあるけどXAML側でセットしたいってそんなある？
それこそOnBindingChangedだっけ？とかBindablePropertyのモニョモニョのところでやれば良くない？
XamarinFormsの内部コードに入ってブレークしたいとかはちょっとあったけど

>>302
XAMLでプロパティ設定出来るようにコントロール作るけど

>>303
VM側かBindingPropertyでいいっしょ？

簡単なのしか作らん人には不要

列が縦に2段だったり3段だったりして行が横に2段だったり3段だったりしてそれが表示されてるデータと連動して動くけどデータの種類によって挙動が違う
珍論者の雑魚グラマーくんはこんな無茶苦茶な仕様のDataGridなんて作ったことないだろう
これは実際に超大企業で俺が作ったユーザー定義コントロールなんだが物凄く大変だったんだがこの時俺はどうしてViewでブレークポイントがないだろうってMSを呪ったね

元の話はXAMLでブレークポイントだろ??
XAMLにブレークポイント設定してどのタイミングでブレークしてほしいのか知らんが

XAMLでブレークポイントからビューでブレークポイントに変わって、カスタムコントロールでデバッグしたいとかになったり

ゴールポスト動かしまくるのが笑える

理解してないならいちいち絡んでくるなよ…

> XAMLでブレークポイント実装しろよ
> ReactもFlutterもViewでブレークできるのに今まで何してたんだって話

で、xamlにブレークポイント設定してどのタイミングでブレークさせたいのかなww??

VisualTreeとか出したけど、flutterだってWidgetツリーとは別にElementツリーとRenderツリーあるけど
ちょっと内部の事出せば相手黙ると思ってるだろww

>>308
そもそもそいつらはMVUで毎回通るからそこでブレーク仕掛けるとハッピーって話じゃねーの
XAMLで仕掛けてどうすんの

低レベルのが出張って醜い

Application.Current.Propertiesで保存したデータをOnStartで呼び出して
TimePickerの初期化時入れたいんですがどうしても00:00:00
になるんですがOnStartってMainPageの後に呼び出されるんですか？

保存もOnSleepなら必ず保存できるかと思ってたんですがうまくいかない場合があるっぽいです

ごめんねMSにチュートリアルがあった

なんで答えを書かないのこの阿呆は

そもそも間違えてる部分が違った
初期化以前にTimePickerのPropertyChangedが起動時に2度くらい呼び出されるらしく
ここでPropertiesに保存する処理入れていたものだから毎回起動するたびに0にされてた
初めてFocusedが呼び出されてから書き込むようにしたらうまくいった

.NET 6.0 SDKがVS2022でしか動作しないあたりWindows専用サブセットばかりなんだろうな
てかダイアログすらダークモードに対応してないWin11のゴミっぷりでMAUIとかWinUI3.0とかギャグだろMSはおお仕事してるんでちゅかねぇー

お前よりはしてるんでない？知らんけど

uwpやWinUI3では、ダイアログはレガシーでコンテントダイアログ使うからな

>>318
ストアアプリをデスクトップと同じWin32に回帰するってのがMSの戦略なんだが
UWPは捨てませんから安心してくださいって今更開発環境リセットできないHololensやXboxだけで行き当たりばったり

WPFはVSで使ってるスタイルとUIライブラリ公開してくれるだけでWPFでずっと戦えるというのに

https://qiita.com/advent-calendar/2021/xamarin
我が軍は圧倒的ではないか

まぁ5chの勢いとか世間の動向とは全く関係ないどころか真逆だったりするから気にしなくていいよ
ただしXamarinはそもそも英語ですらナレッジやノウハウがなくてのっけから詰むからなフレームワークもライブラリも全然ないしあっても更新止まっててバグ放置とかばかりで心が折れて俺はなぜこんなもの必死になって時間を使ってしまったんだろう・・・ってのが一連の流れだなw
C#使う理由でもあったLINQも他言語にもたくさん移植されたしRxなんて今やJS/TSがメインだからなもうC#や.NETを使う理由のフレームワークやライブラリがない
唯一残ってるのがUnityだけだけどあれはゲームという特殊な分野だからぶっちゃけ俺らに関係がない

ほんとにこの延々と住み着いてくさそうとしてる奴なんなのw
いつも中途半端な知識ででも上から目線で見てて恥ずかしいんだけど

でも別に頓珍漢なことは言ってないから質問してくる馬鹿より100倍マシ

>>322で言ってることが既に頓珍漢だと思うが

とんちんかーんちんちんかーんとんちんかーん
このスレ雑魚ばっかでとんちんかーん

今度は起動できないとか
作る人の問題かそれともザマリンの問題か

結局mauiはどうなったの?
VS2022入れてみたけど今まで作ったアプリは
.net6にすると互換性が無いとか言われて移行できないし

VS2022自体はちゃんと動いてるから今のまま移行しても良いんだけどさ・・・

>>328
来年までお預け

> 673デフォルトの名無しさん2021/02/21(日) 21:08:55.16ID:gtcxpqGP>>683
> トヨタもＥＶ化の流れについていけず脱落しそうだな
> これも俺が5年以上前から予言していたことだ
> 俺には未来が見える俺様の先見の明を称えよ

やっと世の中がトヨタが駄目になりそうなことに気づいてきたな
早期にXamarinが糞だと見抜いた俺様を讃えよ

>>330
俺もずっとXamarinに期待してわ正直すまんかった
Xamarinで進行してた案件が突如React Nativeにすり替わったときにキレたのも正直すまんかった
今考えるとなぜXamarinみたいなゴミに期待してたのか当時の心境が思い出せない
きっとC#に縋ってたんだろうなあれからかなりレベルアップしてフルスタックエンジニアなったからもうMSの開発環境に期待しなくなったな

>>330
>>331
バレバレの自演だなw

かなりレベルアップしたフルスタックエンジニア様がこのスレで粘着してる理由は何だろう
ゴミと思うXamarinのことなんて考えずに価値があると思うもののことを考えてればいいのに

Xamarinへの思いがオーバーフローしただけだよ

このスレ愚痴などのはけぐちとしてちょうどいい

ネタがなくレスがないが何気に見てる人は多そうなところが捌け口としてちょうどいい

公開オナニー派の変態か

C#という言語自体、Essentials、ネイティブAPIラッパーなどは魅力的だと思うんだけどな
Xaml、MVVM、Reactive、ホットリロードの遅さ不安定さが致命的なんでそこ改善したら化ける
Blazorの登場でXaml、MVVM、Reactiveを捨てれる兆しは見えてきた
あとはホットリロードだけどC#スクリプトのサポートとかでなんとかならんもんかね

ここで言ってるReactiveって何？Rxの事？

C#自信ニキの河合がコントリビュートしてるReactivePropertyというフレームワーク使ったリアクティブプログラミング()のことだよ
河合は確かに技術力あるけどぶっちゃけコネで仕事もらってそれをC#と.NETで無理矢理形にしてる自己満足オナニー野郎でそれを自慢気にドヤ顔でC#素晴らしいとかふざけたことを吹聴してるクソ野郎だよ
少なくとも海外でReactivePropertyなんて誰も使ってないしLivetと同じ採用したはいいがメンテされなくなってドツボにハマるというC#/.NETあるあるの地獄を味わうことになるからMS環境にするならできるだけ海外の信頼できるデベロッパーのフレームワークやライブラリ以外は使わないことをおすすめする

わかるように頼むよ

UniRxやUniTaskは普通に使われてるしその中でReactiveProperty^_^も使うやつは使うだろ
ワイも使ってる
サマリン案件では使わなかったけど。
あのへんより信頼できるライブラリイズどれ

C#でドツボにハマってたらTypeScriptとか地獄だよ
Xamarinは酷い失敗作だがC#は優秀これは間違いない

>>343
単にtypescriptが凄すぎる！だけだろ

まぁ見れば分かり通り日本のMS開発環境ってのはこういう偏ったコミュニティばかりだからそりゃ過疎るわなって単純な話
Xamarin界の姫騒動とかもググればすぐヒットするけどマジでこういうキモい奴らが利害関係で繋がってて排他的なんだわ

別にMSのコミュ、閉鎖的じゃないし他のコミュともなんも変わらんぞ？
強いていうと顔合わせ頻度が高いから馴染みとそうでないやつってのは出やすいかもしれんけど、なじみじゃないやつはガン無視とかするやつなんか見た事ないし単にMS嫌いを拗らせた頑張れゲイツくんを愛読してた輩が張り付いてんじゃないのここ？他にやる事ないのと思うけど

本家の北米の事情は知らんけど日本のMVPはMSやMVPとお友達なら他薦で取れるゴミアチーブやてことを知ってる奴案外いないのも滑稽すぎて笑えんねんよな
まぁエヴァンジェリストもそうやが兎角日本のMS関係はおかしなことばかりよ

その言葉遣いは劣等感の反動なのか？

AppleやGoogleならわかるけどMSKKに劣等感なんて持ってる奴いないだろ

自分の頭の悪さに対する劣等感だろ
無理に自分を誇示して偉そうに振る舞う奴

COCOAがトラブってる最中にコミュニティが何も動かなかったからなー
MS社員もガン無視で失望したよ
国内でXamarinに一番詳しいのはお前らじゃないのかと
結局Xamarin経験が無いiOS/Androidアプリエンジニアが有志で対応してるし
技術支援できないコミュニティって何のためにあるんだ？

MSKKにまともなエンジニアなんていねーよw
日本法人はB2Bのための営業とインシデント対応がメインだぞ
MSKKの案件も顧客向けのOutlookカスタマイズとかクソみたい内容ばかりだしクリエイティブ()な仕事なんてひとつもないぞw

初期段階ならともかく行政主導で高額の費用が動き出した案件に簡単に介入できるとも思えないけどな

普通は行政予算絡みのプロジェクトに民間のコミュニティが横から口出ししたらそれこそ問題になるな

>>351
それでザマリンに散々悪態ついてたから笑えるわ
最初の頃のトラブルはザマリンのせいというよりも頻繁に変わるトラッキング用のAPIにザマリンのラッパーライブラリの追随遅かったせいなのにそれをザマリンのせいとか息巻いてるアホがいて素のAPIのラップは早々にされてたんだからそっち使えよと

>>347
まぁ言いたいことは分かるよ
コミュニティの人数が少ない分濃縮されてアレな感じが際立ってる
今はなるべく近付かないようにしてるわ

https://github.com/xamarin/Xamarin.Forms/issues/13676
これいつまで放置されてんだろうな
よほどユーザーいないんだな

つかそんなもん使ってるのが悪いのでは

>>358
なんで？

Xamarin使ってるってことはプライベートプロジェクトだろ
さっさとFlutterかReact Nativeにポーティングすりゃいいだけの話で結論でてんじゃん
ビジネスでXamarinチョイスは頭が悪いし先見性がないからお前が悪いとしか言いようがない
そもそもMSはWPFの数ある深刻な不具合をコストに見合わないから仕様にするわごめんやで？でFixしやがった前科があるからわかってる奴等は端から信用してない

>>359
いやそんなメソッド使った試しがないが

>>360
阿呆はクソして寝てろ

SavePropertiesAsync使ったことないってお前Xamarinでアプリ作ったことないって言ってるのと変わらないんだがエアプがドヤ顔で語ってんじゃねーよボケが

Playに公開してたけど、俺も使ったこと無いわ。
自力でデータ保存してる。

車輪の再発明してバグ仕込む馬鹿の集まりー♪

発明じゃないものにまでそれ言うなｗ
どこの自動車メーカーや鉄道車両メーカーだって、車輪の再設計は行っている。
古代から続く丸くて回転するという、すごく原始的で単純な仕組と概念に沿って。

だから、既にある似た概念や機能を実現するソースコードも同じ。
それさえも再発明というのなら、Windowsを一つをとっても、バージョンアップの度に
再発明じゃないかｗ　世の中のほとんどは再発明で愚かなのか？

車輪の再設計？
新設計じゃなくて？

おお、新設計の方がピッタリな表現だな。再設計だとやり直し感を匂わせるもんな。
こう言っちゃなんだけど、ソフト関係の人間って、車輪の再発明という例えを濫用しすぎるよな。
そもそもプログラミングは構造や処理をプログラミング言語に脳内翻訳（変換）してコンパイラへ
流すための記述作業だから、発明に例えるだなんて恐れ多くて言えない。

2022令和最新版、最高のエアレスタイヤ、完全新設計。

↑良さげです。

>>362
データの保存にそれ使わないとできないと思ってる低知能がイジキタコレ

オレオレライブラリでバグ仕込んだ上に属人化したがる無能プログラマーってどこにでもいるよな
レベル低くて生産性低い奴ほどオレオレライブラリ作りたがるんだが事故った時に100%責任取らずに逃げるのもワンパなんだよなぁ

前もって何のテストもせずにオレオレ詐欺みたいなライブラリを使うの？

日本の雑魚プログラマーよりも優秀な本物のエンジニアが作った実装使わないで低脳が車輪の再発明したオレオレライブラリを使って属人化されたアプリとか絶対触りたくないゾッとするわ

データ保存するのにわざわざプロパティ使ってやってなんのメリットがあるのかましてやそんなもの使ってるから変なバグ踏んでんじゃねーか
暗号化とか評価の高いライブラリ使え絶対ってものは当然あるけどそれがこれに当てはまるか言ったらどうなん

工数増やして見積もり吊り上げたいだけの日本のITぶっ壊したSIerの発想で草

シンプルで見通しがいいコードを選択するのはアリだと思うよ

log4j とか、長い間誰も仕様を知らずに使ってたわけだろ
そういうのもゾッとするよ

>>357
COCOAのデータ吹っ飛ばしてたバグだな
報告から1年近く経つのに放置なんだから
もうXamarinはまともにメンテしてないんだろ
まあこんな初歩的なファイルジャーナリングの実装ミスするような連中に期待するだけ無駄だが

>>374
実装見ないで使って訳分からんバグで延々と障害出したままの事例がつい最近あったのに本当愚者は経験からすらも学ばないなw

まあ本当内容次第だとは思うけど自分のコントロールできる見通しの良いコードを使うことのメリットももう少しお考えになっては？

Xamarinをビジネスで使うボンクラ雑魚グラマーの集団で仕事してる底辺野郎だという最初の結論に帰結してるだけなんが本人がまったく認証してないのが救えねーよ

ほらな？ボンクラクズって反論できないと人格攻撃に走るだろ？マジでクズの極みだな

>>357
それって、非同期関数なんだから、結果を確認せずに、アプリを終了する方が悪い
わけで、バグというか使い方の問題では？

高品質で可読性・保守性も高い、Ruby on Rails でも使えば？

GitHub, Airbnb, Disney, Hulu, SoundCloud, Shopify といった世界的に有名な企業や、
日本国内でも、note、クックパッド、freee、マネーフォワード、Progate、Qiita などで使われている

2021年10月には、GitHubのコピーで、
Railsを使い続ける宣言をしている、GitLab が上場し、時価総額は約1.9兆円！

ドヤッ

>>380
確かに

ルビーオンレイルでアプリ作れんのか初耳だわ

ルビーオンレイルwww
レイルズだよ馬鹿www
MSの開発環境ってVB6とか老害がしがみついてるだけの魔境になってる草
Pythonでウェブアプリが作れることも知らずDjangoでの開発は北米ではすでにASP以上にメジャーだと言うことすら老害どもは知らないんだろうなwww

キリッ

>>385
んじゃそのレイルズでアプリ作ってリリースしてください

Railsの話出てるからこの際だから言っちゃうと結局MSって自社開発にこだわるくせに全部作りっぱなしで放置して結論として便利なFWやライブラリやミドルウェアがなにもなくてバグも修正しない面倒臭くて使い辛くて欠陥だらけの開発環境なんだよ
話の流れでウェブを例に挙げればRailsやLaravelが人気だったのはRubyやPHPが優れてたわけじゃないって誰も理解できるよな
実際開発したことあればRubyやPHPはクソだけどRailsやLaravelは使いやすい、LaravelなんてDocker環境までオールインされたLaradockまであるからちょっとしたもの作るのにこりゃ便利だわって人気でるのもわかる
ASPなんて結局最後までまともなプロジェクトテンプレートも存在せず新規プロジェクト作ってからの毎度の下地作りが本当に面倒臭い上にプロジェクトリーダーによってその実装や方向性がバラバラで苦労した記憶しかない

続けて言うと自社開発にこだわるくせに一貫性がなくてMSの開発環境は至る所に悪影響が出てグダる
バージョン管理でだけでもVSS、TFSで最近やっと買収したGitを標準にしたがつい最近までTFS推しだったのも本当にクソ
MSの開発環境のプロジェクトだと未だにVSS使うところもあればTFS使うところもあって日本だと未だにGit使う方が少ないうえにSVN使うところもあって実はMSの開発環境が一番カオス
中小零細や個人で開発してるとピンとこないかもしれないが日本の大手ほど古くて枯れた技術使いたがるから国内でのMS環境での開発は本当に大変

>>389
git買収したの？？？

git と github の区別もつかない人なのでそっとしてやってくれ

Microsoftのバージョン管理製品
現在は Azure DevOps Server
バージョンコントロールは Git または TFVC


Visual SourceSafe (VSS)
↓
Team Foundation Server (TFS)
↓
Azure DevOps Server ←いまここ

https://docs.microsoft.com/ja-jp/azure/devops/?view=azure-devops-2020

何でこのろくに知識もアップデートしてないMS嫌い君延々とここに居続けてるの？お前の好きなグーグルでも何でも好きなとこに行けば良いのに

MS嫌いだから勘違いしてgit避けてんのかなw

SuicaアプリがXamarin製になってからとんでもなく使いにくくなったな。
操作一つするたびにクルクル〜クルクル〜
Android版の場合は、一般的な流儀に反してバックでアプリを終了できないようになってたり。

iPhone版は悪くないぞ
Xamarinせいか知らんけど

Androidだけどそこまで重くはないけどな。
Switchのアプリとかもそうじゃなかった？

iPhone版を作らなくちゃならなくなって、安直にXamarinに飛びついた結果がコレだよ。
ほんとXamarinは害悪でしかない。

別に不具合ないけど

Xamarin使ってるのはAndroid版だけだよ
iPhoneはSwift実装
Suicaアプリと言ってもそれぞれの機能全然違うからね

しかし低スペ端末多いAndroidでXamarin使ったらどうなるか分かってるだろうに
どうして採用しちゃったんだろうね
案の定ストアの評価ボロクソになってるし

え、マジかｗ
いずれは統合するつもりでいるのだろうか。
さすがにAndroidだけのためにXamarin採用とかありえんだろ。

モバイルPASMOの方はすでにiPhone版もXamarinじゃなかった？

ICOCAモバイルアプリはよ

あと1年
https://www.itmedia.co.jp/news/articles/2010/16/news130.html

え？Suica圏内の関東以外は未だに改札のモバイル決済対応してないのか？マジで？www
東京が進んでるというより東京と関わりのある関東以外の地方が終わりすぎだろwww
てか関西も確かSuicaはもう使えたはずだからモバイルSuicaで改札通れるんじゃねーの？無理ならマジで終わってるな関西田舎すぎるwww

プリベイドICカードが主流

マウイ島

結論として東京とそのおこぼれに与れる関東一円の外にある地方はFeliCa搭載モバイル端末のオートチャージと決済に改札機が対応してないんだなwww
遅れてるという次元を通り越して日本国内で更にガラパゴス化してるの草生えるwww
しかも関西の南海電鉄という私鉄がVISAタッチ決済というオープンループを独自で構築してるのももうむちゃくちゃのカオスで草www
結局VISAタッチでいいならNFCもFeliCaにこだわる必要なくてMifareでよかったんじゃんあほくさwww
結局非接触IC決済もPaypayだIDだEdyだNanacoだWaonだ乱立しまくって消費者おいてけぼりだし日本人てルール作るルーラーになるセンスが根本的に欠けてんだなそりゃプラットフォーム構築できなくて一人負けするよwww

一人勝ちしようとする商売人ばかりだよな。三方良しを目指してほしい

南海のVISAタッチは関西空港から訪日する外国人がターゲットだからね

お気に入りのアプリがWPFで実装されてて公開されてるから古いUIをWin 11のUIに合わせたくてForkしてWinUI3.0に対応させようと思ったらWindows App SDK 1.0だとAcrylicやMicaに対応してないとかズコーだわやっぱアホだわMSやることがすべて片手落ち
結局サードパーティー製のAcrylic実装を使う羽目になったわけだがこっちもろくすっぽメンテされてなくてWin11に対応してなくてダブルでズコー
たまにやる気になってプライベートでいじろうかと思ったらこれだからMSの開発環境ってマジでどうしようもないな

GNOMEとMonoとXamarinの開発者Miguel de Icaza（ミゲル・デ・イカザ）氏がマイクロソフト退職を発表
https://www.publickey1.jp/blog/22/gnomemonoxamarinmiguel_de_icaza.html

そりゃずっと買収しろって言われてたのに3週遅れくらいでやっと買収したと思ったら塩漬けにして飼い殺してんだもん
その間にReactやFlutterが台頭してきてシェア奪われてWASMだMAUIだWinUIだと自社の派閥争いで開発環境はしっちゃかめっちゃかでオワコン
唯一成功したと言える成果物のC#もOSS化が遅すぎてどこにも採用されず優秀なのに報われない言語になってオワコン

これはひどい
アホすぎる

>>412
LinuxでVB.NET
と思ってたのに.NET CORE(C#)さえ普及が遅れてる
マイクロソフトはプロダクト育てるのは下手クソだと証明してる様だな

LinuxではVB.NETのようなフォーム系の言語は無理
コンソール系かブラウザ系しか使いものにはならんだろ

HoloLensもボロボロにしちゃうし。
最高の言語と最高の開発環境がありながらまったくプラットフォーム作れないのは糞すぎる。
今のトップの力の入れ具合からすればそうなるよなとしか。

html5とjavascriptさえあればおｋ

>>417
こいつTwitterで延々とMSの開発環境の悪口言ってる顔文字のやつなんじゃ？

VS code最強じゃん！

VS Entが最強

>>418
TypeScriptないとやだ

やっぱりデザインビューワーないときついなぁ
皆ホットリロードだけでなんとかしてるの?
ホットリロード効くのデザインだけでcsファイルは効かないじゃん
MAUIになったら、効くようになるの?

>>423
こんな底辺しか残ってないんやからXamarinが終わるわけやな
ReactでもFlutterでも静的な値は再実行しないと変化せんのだが頭悪そうだから理解できんのだろうな

>>423
デザインだけならいまのほっとりろーどだけでいいんじゃ？

>>425
一人でやるならそれでいいけど友達と作ってるからなぁ
それにホットリロードだと、わざわざその画面まで行って表示させないと行けないじゃん
開発初期はそれは無理じゃない?

なるほど
まあ全画面開くためのエントリーページかなんか作ればいいと思うけど手間は手間だな

>>424
この人何でこんないきり散らしてるの？
VSはc#もc++も実行コードのホットリロードできるのにXamarinでも出来ると思うだろうに
いきなりflutter出したり
思考が途切れすぎじゃない？

>>428
ずっと居ついてるMSに親殺された人だからそっとしといてやれ

3年離れててこの間久々にXamarinで仕事したけど公式のドキュメントも整備されてて使いやすくなったなあ(´-ω-`)

>>424

ホットリロード効かない時はブラウザリロードかFlutterならホットリスタートでリフレッシュされるでしょ
再実行必要になるのはライブラリ入れ替えた時くらいじゃね？
Xamarinのこの辺の開発効率は他プラットフォームに劣ってる所だから改善して欲しいんだけどね……

mauiはレビューなのに、本格的に作ろうしているバカなのですが
やっぱりmaui早いよね…今、実装しようとしてバグが出て
ググったらredditで「プレビューだから期待すんなアホ」みたいなこと書いてあった

xamarinは、軽く触ってみたけどwindowsへの対応が、かなり甘い感を感じただけど
実際長期使っている人の感想が知りたい

>>432
Windowsの対応なんか期待してないw
Androidでずっと使ってて、確かに年々ちょっとずつマシになってきてたんだけど、それ以上に端末スペックで殴れるようになってきてしまって今ではWebViewでほとんど何とかなるようになってる。

C#+Xamarin+WebViewはinteropやりやすくてガワネイティブにはめちゃくちゃ良いと思うんだけど、現状の中途半端な状態でモタモタされつづけたら継続して選定出来ないよねって状態。

一昨年から止まってるからな。

XamarinはUIをネイティブラッパーにしたのがそもそもの失敗だった
Flutterのように独自UIにしてれば一つの実装で全プラットフォームに対応できたのに結局プラットフォーム毎にUIを統一するという地獄が待っている
その癖UIのカスタマイズがXamarin Formsであろうとプラットフォーム毎にコードビハインドでしか実装できずUWPやWPFとまったく違う実装でノウハウが役に立たない

>>433
あーやっぱりか…「Windowsもできるよっ(ﾁﾗｯ」的な感が強かったから、怪しいとは思ってたけど
なるほど、かといってこのままmauiのGAの10月あたりまで待てる気がしないだよなぁ、Flutterに行くしかないのか

個人的に、Flutterに親殺された感(VS使えない&追加ソフト必須)があってので、嫌いなんだよな
mauiの使い方もそこそこ分かったし、ついつい、mauiやりてぇ！と思ってしまう

>>435
わかる
Flutter使ってみたいけどWinだとどうしてもVSが必要だからインスコできない環境だと無理ゲー…
かといって他のフレームワークだと制限がきついし

>>435
GAはQ2だから、6月までに出るんじゃないの？
RCが4月だから、まあそんなもんかという気はする

ガワネイティブはいいよな
中身reactでパスワード保管・通知・カメラ起動なんかは
ネイティブと相性がいいXamarinで実装

全部TypeScriptかC#で済む
Xamarin.Formsのバギーなところが露呈せずにいいところだけ活かせる

自分が楽するために便利なもの勉強するんだろ?
親殺された感とか意味不明
まぁ、Flutter学習してのちのち楽できるかは知らんが

>>438
実際この組み合わせ相当良いよね。
当時Android+Xamarinでやってたんだけど、WenView2でWindowsに持ってくるのはだいぶ楽だった。
しかしこのWebView2も年単位で遅かったと思ってる。

「.NET MAUI Community Standup - One month till MAUI! It's go time!」

Flutterと比較されるのってBlazor Hybridになるのかね？

> Xamarin Developers
> チャンネル登録者数 6.95万人

> Flutter
> チャンネル登録者数 38.5万人

完全に負けてますね。

https://devblogs.microsoft.com/dotnet/dotnet-maui-rc-1/

うれちぃ

mauiよりwinuiのウンコ垂れをどうにかして

ぶっちゃけwinUIとかなんかもうどうでもいいやー

MSのやるきがなくて

>>444
なぜ頑なにウェブに対応しないのか謎すぎるんだがASP開発チームに忖度してるのか？アンタッチャブルなのか？
Flutterだってウェブサポートするとネイティブアプリとパッケージに互換性がなかったりともちろん万能ではないけどさ
それでもほぼ同じ実装でフロントエンド作れることが如何に重要かまだわからないのかなXAML切れないならさっさとASP廃止すべきだよ

Mauiはweb対応するものではないのでは？
俺の中で一番最初にこれがものになるのは、全プラットフォーム統合で作れるガワネイティブアプリだと思うよ。

俺は、全くwebの必要性を感じない族だから、よく分かんね
ネイティブフルコンプリート感があって、これで十分じゃね？と思っちゃう

とりあえず、webやりたきゃ、別ライブラリでも使ったら？と思う

似たようなUnoでWebに対応してる(Xamarinを使って)。
マルチプラットフォームだけどWebだけ特殊構文使ってというのが最高にアホ。

>>450
よくわかんねんだったら黙ってろって感じしかないな

まあwebだとプラットフォームとして色々違いすぎてってのは分かるけど　フラッターにしても上にあげたような話だし。
それでもその辺が必要ないものもあるしWEB含めて一緒に作りたいってニーズはあるわな

必要性を感じる人がいたからといって全部が全部それに従わなきゃならん道理は無いしな。

その結果人気が出ず誰も使われなくてオワコンになっちゃってストアが完全に死亡してるんだけどな
そしてにっちもさっちもいかなくなってiPhoneアプリが良いけどAppleが100%許可してくれないから仕方なくAndroidアプリをAmazon App Store経由でデスクトップに持ってきちゃった
WSAが正式リリースされたら業務システムなんかのニッチな分野以外は全部Androidアプリに駆逐されるの確定
Androidアプリがそのまま動作するのにプラットフォーム固有のサブセットが3割近くあるWindowsでしか動かないアプリなんて誰も開発するわけがない
しかし既にソシャゲでNoxやBlueStacksなんかのエミュレーターが高い再現性と高パフォーマンスを実現してるのにWSAは未だにリリースできない時点でMSって技術力低すぎなんじゃないのw

>>454
このずっと居ついてるMSに親殺された奴、ほんと言ってることが的外れなのいい加減気づかないのw

>>454
全画面表示が大前提でマルチウインドウすら開けないスマホアプリがデスクトップ
で主流になるとか永遠にあり得ないな。

スマホアプリがフルスクリーン大前提とかまたにわかのキチガイが知ったかしてると思ったらいつものマルチウィンドウおじさんで草

.NET MAUIでマルチウィンドウできるようになったら起こしてね。

Windowsで業務システムがニッチなのか？
むしろWindowsの主戦場じゃないかと思うんだが

Windowsの業務システムなんて
それこそformかwpfでそのままつくっておしまいだろう
いちいちmauiになんかにしないと思う

それこそ一つでいろんなので動くならmauiにするだろ
ノーコードだとやりにくいしwebだと何かしらで問題があるとかな

それならflutterというのもわかるけど.NETで組みたいってケースはあるでしょ

そもそもレガシーな要件でしか開発しない業務システムでMAUIなんて採用されるわけないだろホビーPGのエアプかよ

>>462
> そもそもレガシーな要件でしか開発しない業務システム
無能がすぎるだろw

MAUIやるにはまず人脈♪

本当に頭悪い底辺ばかりだなこのスレはw
WinUIだMAUIだ開発してるMSが自社のドル箱アプリに自社のテクノロジーを使っていない件www
Office・Teams・SkypeはReact NativeだしVSCodeはElectronなんだが？
そしてXamarinではなくReact Nativeを選択しか理由がウェブをサポートしているから
そしてWindowsデスクトップ専用のVSだけがフロントエンドをXAMLで作ってるがUI・UXのクソさに加えてXAMLで独自UIにしちゃってるからAcrylicやMiacやダークモードに対応できないゴミっぷり

>>465
XAMLがそれらに対応できないなんて制限はない。
てかダークモードなんて(UWPの)XAMLが元祖。

COCOAアプリをMAUIで作り直したらよくね？

まあMSは自分のフレームワークを自分で使ってないからクソが放置されてるはあるな

Appleとかはどうなのか知らんけど

それでも>>465の的外れっぷりはほんと相変わらずだな

React Nativeなのか

>>465
ダークモードのな話要らんかったね

Material Design 3 非対応のMAUIはFlutterに劣る

しかもWin11のウリの一つであるFluent DesignのAcrylicやMicaというフロントエンド実装が11リリース半年過ぎても未だに使えないという意味不明なスケジュール
WIndows Desktopに対応したFlutterは既にFluent DesignのAcrylicやMiacに独自対応したパッケージがいくつもリリースされていてMS公式実装では使えないのにFlutterでは使えるという逆転現象が起こってしまっている
ようするにMSって新しいプラットフォームを立ち上げて基礎は作るけどその後の便利なパッケージは一切作らないで放置するからまったく人気が出ず盛り上がらないオワコン開発環境になるというループ

オープンソースでok!

>>472
マジでこいつ頭おかしいだろw

Microsoftに期待出来ない気持ちは伝わった
Dartをここまで普及させたGoogleの偉大さよ

EdgeがChromiumになった時点でお察し

C#をもう使わなくなっちゃったからなあ

>>477
最近何使ってんの

>>478
F#

mauiちょこっといじってみたけど
相変わらずデザイナーがないように見えるけど、なんか俺が間違ってるんだろうか

それとパーツのデザインにcssを使えるってどこかで見たけどどうやるんだろう
余所でも使ってるから流用出来るかと思ったのだけど・・・

StyleSheet効いてたわ
ホットリロードに全く反応しなかっただけだった

プレビューだしな・・・

1.0出たんじゃなかったっけ？

そうなの？

MAUIは1.0だけどVisualStudioのほうはまだプレビュー

>>480
おおマジか！MAUIはCSS使えるのかぜんぜん期待してなかったけどちょっと触ってみるかな
MSのドキュメント読んだらCSSテキストを実行時に解析・評価だからT4で実行時生成できるな
なんでこれでWebをサポートしないのかマジで意味わからんな
MS社内ではそんなに他プロジェクトであるASPのレイヤーに手を突っ込むのがタブーかつアンタッチャブルなのか？
逆にこの仕様でWebだけビルドできないの不自然なんだが

なんかプロジェクトテンプレートにBlazorでMAUIがあるな
だったらXAML捨ててBlazorでHTML+CSSに統一しろよMSってほんまアホやな

ブレーザーよく知らんしクライアントサイドでWASM使うやつとの違いもよくわかってないが、今までの資産やソフトの移行含めて非現実的な戯言じゃねーの？

いやよくわからんならシャシャんなや

ほんとWebが欠けているのは致命的。

これからの時代はWEBアプリ
これ絶対

こんな機能縮小＆独自改変したCSS入れるくらいなら
最初からHTMLベースで書けばいいよな
独自XML+独自CSSってJavaFXと同じ構成になってるし
何年も迷走して出した結論がこれなのかと

しかもページングファイルなしにしてるとAndroidのビルドでベージングファイル不足でエラーとかPreviewにしてもお粗末すぎるだろ
メモリ32GBなんだからページングファイルなんてなしに決まってんだろ馬鹿なのかMSは

ページファイルはあった方がいいぞ
止まってるプロセスをページアウトしてディスクキャッシュを増やした方がいい場合もあるからな

32GBしか積んでないならなおさらだよ

>>491
JavaFX懐かしいな12年前くらいにSwingもAWTもUIデザインがゴミすぎてJavaFXに期待してた時期があったがその後どうなったのか知らんけどほんま懐かしいwww

クロプラのフロントエンド開発はReacとFlutterが人気の理由考えればHTML+CSSしかないんだがなぜBlazor使えるのにXAMLを捨てられないのかMSは何がしたいんや？
その点AppleはObjective-CもSwiftも普通にコードビハインドするという非常にシンプルな方法で一貫性があるんだよなMSってマジでビジョンがないよな役所の仕事かよ

xamarinの無料化のとき、一時期使ってみる人増えたけどゴミ品質であっという間に見捨てられたけど
mauiは大丈夫か?ある意味最初が肝心だぞ?

ReactやFlutter使えばわかるけどぶっちゃけ言語や仕様なんてどうでもよくてユーザーフレンドリーかつコミュニティが盛り上がってるってことが非常に重要なんよ
MSのOSSってどれもぜんぜん盛り上がってないからコントリビューターが集まらなくてすぐにメンテされなくなって過疎る

>>496
死ね

>>494
ReactもFlutterも素のHTM+CSSだけじゃ足りんからいろいろガワを被せているわけだろう。

>>497
MSに親を殺された、若い者に相手にされないでここでいきがってるだけの老害だからそっとしてやれ…

会社でザマリン使ってる人いるな
俺はネイティブとflutterしか出来んけどｗ

触ってみようかとおもったけど
2022 v17.3 Preview 1.1じゃねーとだめなのかよ…
ならいいわ…

うちのVSは2012だから、もういいや
Flutterとかなら無料だし

は？CEを知らないとか底辺雑魚グラマーなのバレちゃったなwww

>>503
ごめん知らない
CEってなに？

あれ？WindowsCEも知らないとは嘆かわしい

今知る意味皆無だな

なにここマ板なのにCEすら知らないホビープログラマの老害がシャシャってくんの？www

WindowsCEってなつかしいな

>>507
ここはム板ですけどね

CEは20世紀に終わってるω
20代の若者が産まれたときにはもうない

Windows Embedded Compact （ウィンドウズ エンベデッド コンパクト）は、マイクロソフトが開発した組み込み機器向けの32ビットのマルチタスク/マルチスレッドリアルタイムオペレーティングシステム (RTOS) 。一般にはHandheld PCやPocket PC、SHARP BrainなどのPDAで使われているオペレーティングシステム (OS) として知られている。1996年11月に発表されている。近年はPNDにも採用されている[注 1]。バージョン 6.0 では Windows Embedded CE 、バージョン 5.0 までは Windows CE（ウィンドウズ シーイー[1]）と呼ばれていた。

https://ja.m.wikipedia.org/wiki/Microsoft_Windows_Embedded_CE

>>504
CE = Community Edition (≒ Professional相当の無償版, 利用に条件あり)

CEすら知らない底辺にわか老害が赤っ恥かいて顔真っ赤で単発で荒らしまくるとかこのスレもういらねーだろwww
技術的なディスカッションとか不可能なレベルの低さでクソワロタwww

スレ勢いあるけどmauiユーザ増えたんか？

MAUI の本てまだないのかな
「プログラミングXamarin」一択？

>>514
CEになぜか拘るガイジが単発で騒いでるだけ

>>515
まだじゃないかな
マイクロソフトのページをちゃんとした日本語にしてくれるだけでも有用なんだけど…