Microsoft Xamarin part8 [.NET MAUI]

**デフォルトの名無しさん** · 2021/08/01(日) 09:38:36.43

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

**デフォルトの名無しさん** · 2021/08/01(日) 09:39:09.73

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://mevius.5ch.net/test/read.cgi/tech/1596690797/

**デフォルトの名無しさん** · 2021/08/01(日) 09:56:07.35

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

主に.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)

**デフォルトの名無しさん** · 2021/08/02(月) 15:30:18.00

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

**デフォルトの名無しさん** · 2021/08/02(月) 15:43:07.59

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

**デフォルトの名無しさん** · 2021/08/02(月) 16:06:06.83

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

**デフォルトの名無しさん** · 2021/08/02(月) 16:49:58.01

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

**デフォルトの名無しさん** · 2021/08/02(月) 18:12:28.12

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

**デフォルトの名無しさん** · 2021/08/02(月) 18:31:55.53

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

**デフォルトの名無しさん** · 2021/08/02(月) 18:34:55.28

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

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

**デフォルトの名無しさん** · 2021/08/02(月) 18:59:23.06

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

**デフォルトの名無しさん** · 2021/08/02(月) 19:19:12.08

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

**デフォルトの名無しさん** · 2021/08/02(月) 19:21:24.42

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

**デフォルトの名無しさん** · 2021/08/02(月) 19:46:01.65

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

**デフォルトの名無しさん** · 2021/08/02(月) 19:58:17.46

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

**デフォルトの名無しさん** · 2021/08/02(月) 20:02:51.98

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

**デフォルトの名無しさん** · 2021/08/02(月) 20:39:23.36

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

**デフォルトの名無しさん** · 2021/08/03(火) 00:55:58.27

MAUIってWPFでも使えるの？

**デフォルトの名無しさん** · 2021/08/03(火) 01:29:28.32

いや、何言ってんの？

**デフォルトの名無しさん** · 2021/08/03(火) 11:40:56.32

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

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

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

**デフォルトの名無しさん** · 2021/08/03(火) 20:49:42.54

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

**デフォルトの名無しさん** · 2021/08/03(火) 21:27:15.22

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

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

**デフォルトの名無しさん** · 2021/08/03(火) 21:51:31.50

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

**デフォルトの名無しさん** · 2021/08/04(水) 00:15:33.70

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

**デフォルトの名無しさん** · 2021/08/04(水) 01:54:00.16

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

**デフォルトの名無しさん** · 2021/08/04(水) 10:05:13.12

>>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

**デフォルトの名無しさん** · 2021/08/04(水) 10:06:57.54

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

**デフォルトの名無しさん** · 2021/08/04(水) 10:13:46.74

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が出れば流れはかわるだろう

**デフォルトの名無しさん** · 2021/08/07(土) 23:37:38.72

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

**デフォルトの名無しさん** · 2021/08/08(日) 01:16:46.81

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

**デフォルトの名無しさん** · 2021/08/08(日) 02:10:39.60

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

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

**デフォルトの名無しさん** · 2021/08/08(日) 09:36:07.05

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

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

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

**デフォルトの名無しさん** · 2021/08/08(日) 13:58:44.76

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

**デフォルトの名無しさん** · 2021/08/08(日) 14:48:15.57

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

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

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

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

**デフォルトの名無しさん** · 2021/08/08(日) 15:45:56.45

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."

**デフォルトの名無しさん** · 2021/08/08(日) 16:31:50.19

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

**デフォルトの名無しさん** · 2021/08/08(日) 16:53:54.16

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

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

**デフォルトの名無しさん** · 2021/08/08(日) 22:17:08.79

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

maui??
ぷっ

**デフォルトの名無しさん** · 2021/08/08(日) 22:19:24.40

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

**デフォルトの名無しさん** · 2021/08/08(日) 22:22:45.35

UnoPlatformは忘れた方がいい

**デフォルトの名無しさん** · 2021/08/08(日) 22:38:42.37

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

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

**デフォルトの名無しさん** · 2021/08/08(日) 22:57:10.34

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

**デフォルトの名無しさん** · 2021/08/08(日) 23:13:55.61

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

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

**デフォルトの名無しさん** · 2021/08/08(日) 23:22:32.79

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

**デフォルトの名無しさん** · 2021/08/08(日) 23:40:04.66

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

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

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

**デフォルトの名無しさん** · 2021/08/08(日) 23:43:50.88

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

**デフォルトの名無しさん** · 2021/08/09(月) 03:00:55.11

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

**デフォルトの名無しさん** · 2021/08/09(月) 05:13:32.63

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

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

**デフォルトの名無しさん** · 2021/08/09(月) 05:23:04.67

>>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年以内は十分可能なラインだと思うわ

**デフォルトの名無しさん** · 2021/08/09(月) 05:25:57.11

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

**デフォルトの名無しさん** · 2021/08/09(月) 09:40:35.13

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

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

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

**デフォルトの名無しさん** · 2021/08/09(月) 09:51:00.06

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

**デフォルトの名無しさん** · 2021/08/09(月) 09:54:05.07

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

**デフォルトの名無しさん** · 2021/08/09(月) 10:27:07.72

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

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

**デフォルトの名無しさん** · 2021/08/09(月) 10:29:59.07

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

**デフォルトの名無しさん** · 2021/08/09(月) 10:40:53.46

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

**デフォルトの名無しさん** · 2021/08/09(月) 10:54:05.91

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

**デフォルトの名無しさん** · 2021/08/09(月) 11:05:57.10

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

**デフォルトの名無しさん** · 2021/08/09(月) 11:09:32.19

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

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

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

**デフォルトの名無しさん** · 2021/08/09(月) 11:12:20.90

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

**デフォルトの名無しさん** · 2021/08/09(月) 11:29:00.49

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

**デフォルトの名無しさん** · 2021/08/09(月) 11:35:24.07

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

**デフォルトの名無しさん** · 2021/08/09(月) 11:40:05.21

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

**デフォルトの名無しさん** · 2021/08/09(月) 11:40:37.27

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

**デフォルトの名無しさん** · 2021/08/09(月) 11:44:49.92

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

**デフォルトの名無しさん** · 2021/08/09(月) 13:12:38.14

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

**デフォルトの名無しさん** · 2021/08/09(月) 14:13:08.42

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

**デフォルトの名無しさん** · 2021/08/09(月) 14:52:18.34

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

**デフォルトの名無しさん** · 2021/08/09(月) 15:58:05.52

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

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

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

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

**デフォルトの名無しさん** · 2021/08/09(月) 16:01:08.63

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

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

**デフォルトの名無しさん** · 2021/08/09(月) 16:35:44.38

NG入れました

**デフォルトの名無しさん** · 2021/08/09(月) 17:04:39.46

またc#おじさんかな？

**デフォルトの名無しさん** · 2021/08/09(月) 17:23:35.09

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

**デフォルトの名無しさん** · 2021/08/09(月) 17:27:24.02

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

**デフォルトの名無しさん** · 2021/08/09(月) 18:33:15.60

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

**デフォルトの名無しさん** · 2021/08/09(月) 18:51:58.69

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

**デフォルトの名無しさん** · 2021/08/09(月) 19:39:14.67

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

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

**デフォルトの名無しさん** · 2021/08/09(月) 19:43:56.49

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

**デフォルトの名無しさん** · 2021/08/09(月) 19:49:03.59

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

**デフォルトの名無しさん** · 2021/08/09(月) 20:05:30.41

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

**デフォルトの名無しさん** · 2021/08/09(月) 20:05:49.15

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

**デフォルトの名無しさん** · 2021/08/09(月) 20:08:59.48

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

**デフォルトの名無しさん** · 2021/08/09(月) 20:09:15.30

c#おじさん...

**デフォルトの名無しさん** · 2021/08/09(月) 20:13:17.33

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

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

**デフォルトの名無しさん** · 2021/08/09(月) 20:15:18.16

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

**デフォルトの名無しさん** · 2021/08/09(月) 20:17:32.15

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

**デフォルトの名無しさん** · 2021/08/09(月) 20:18:35.41

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

**デフォルトの名無しさん** · 2021/08/09(月) 20:24:13.37

あぼーんだらけ😅

**デフォルトの名無しさん** · 2021/08/09(月) 20:27:56.85

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

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

**デフォルトの名無しさん** · 2021/08/09(月) 20:36:06.14

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

**デフォルトの名無しさん** · 2021/08/09(月) 20:36:22.82

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

**デフォルトの名無しさん** · 2021/08/09(月) 20:41:50.73

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

**デフォルトの名無しさん** · 2021/08/09(月) 20:50:32.73

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

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

**デフォルトの名無しさん** · 2021/08/09(月) 20:56:30.13

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

**デフォルトの名無しさん** · 2021/08/09(月) 20:58:17.55

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

**デフォルトの名無しさん** · 2021/08/09(月) 21:08:10.16

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

**デフォルトの名無しさん** · 2021/08/09(月) 21:10:47.52

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

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

**デフォルトの名無しさん** · 2021/08/09(月) 21:14:35.07

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

**デフォルトの名無しさん** · 2021/08/09(月) 21:46:37.14

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

**デフォルトの名無しさん** · 2021/08/09(月) 22:27:58.05

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

あ！vsダメか...

**デフォルトの名無しさん** · 2021/08/10(火) 07:32:36.86

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

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

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

**デフォルトの名無しさん** · 2021/08/10(火) 08:17:35.76

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

**デフォルトの名無しさん** · 2021/08/10(火) 16:39:04.07

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

**デフォルトの名無しさん** · 2021/08/10(火) 22:06:22.58

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

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

**デフォルトの名無しさん** · 2021/08/10(火) 22:13:58.73

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

**デフォルトの名無しさん** · 2021/08/10(火) 22:33:58.99

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

**デフォルトの名無しさん** · 2021/08/10(火) 22:53:45.08

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

**デフォルトの名無しさん** · 2021/08/10(火) 23:32:13.69

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

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

**デフォルトの名無しさん** · 2021/08/10(火) 23:38:57.17

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

**デフォルトの名無しさん** · 2021/08/11(水) 00:52:24.64

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

**デフォルトの名無しさん** · 2021/08/11(水) 08:32:41.60

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

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

**デフォルトの名無しさん** · 2021/08/11(水) 14:35:03.05

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

**デフォルトの名無しさん** · 2021/08/12(木) 00:59:14.54

さっさとpreview 7触ってこい

**デフォルトの名無しさん** · 2021/08/12(木) 09:32:48.75

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

**デフォルトの名無しさん** · 2021/08/12(木) 13:19:05.68

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

**デフォルトの名無しさん** · 2021/08/12(木) 18:05:13.21

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

**デフォルトの名無しさん** · 2021/08/12(木) 18:58:46.33

もう許してやれw

**デフォルトの名無しさん** · 2021/08/12(木) 19:17:30.09

c#おじさん...

**デフォルトの名無しさん** · 2021/08/12(木) 20:30:10.47

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

**デフォルトの名無しさん** · 2021/08/13(金) 01:02:26.78

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

**デフォルトの名無しさん** · 2021/08/13(金) 03:41:58.76

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

**デフォルトの名無しさん** · 2021/08/14(土) 22:28:17.45

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

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

**デフォルトの名無しさん** · 2021/08/14(土) 23:39:25.86

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

**デフォルトの名無しさん** · 2021/08/14(土) 23:48:07.12

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

**デフォルトの名無しさん** · 2021/08/14(土) 23:49:52.31

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

**デフォルトの名無しさん** · 2021/08/15(日) 00:05:04.22

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

**デフォルトの名無しさん** · 2021/08/15(日) 01:55:10.19

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

**デフォルトの名無しさん** · 2021/08/15(日) 02:36:14.47

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

**112** · 2021/08/15(日) 10:58:53.00

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

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

**デフォルトの名無しさん** · 2021/08/15(日) 13:37:41.81

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>
こんな感じなんだけど、浴したのタブが自動的に隠れて、必要なときににゅるっと出てくるじゃん
ああいうふうにしたい

**デフォルトの名無しさん** · 2021/08/15(日) 22:49:54.45

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

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

**デフォルトの名無しさん** · 2021/08/15(日) 23:37:59.86

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

**デフォルトの名無しさん** · 2021/08/15(日) 23:43:00.64

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

**130** · 2021/08/15(日) 23:54:48.83

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

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

**デフォルトの名無しさん** · 2021/08/16(月) 00:15:46.24

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

しまぶーのこの動画でも見たほうがいい
https://www.youtube.com/watch?v=OOIz2nl5524
アニメーションでメニュー出すにしても0.3秒とか時間をかけずにやらないといけない
ナビゲーションは独自性は出さずに大手のを真似したほうがいい。
Xamarinのハンバーガーメニューとかを検索すればいいんじゃないか、英語情報含めて。

**デフォルトの名無しさん** · 2021/08/16(月) 00:21:45.70

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

**デフォルトの名無しさん** · 2021/08/16(月) 00:24:50.83

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

**デフォルトの名無しさん** · 2021/08/16(月) 00:30:31.74

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

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

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

**デフォルトの名無しさん** · 2021/08/16(月) 00:42:11.88

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

**デフォルトの名無しさん** · 2021/08/22(日) 03:29:00.21

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 は我々に教えてくれます

**デフォルトの名無しさん** · 2021/08/22(日) 05:22:30.87

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

**デフォルトの名無しさん** · 2021/08/22(日) 13:18:18.25

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 は我々に教えてくれます

**デフォルトの名無しさん** · 2021/08/26(木) 22:26:39.12

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

**デフォルトの名無しさん** · 2021/08/28(土) 11:12:24.30

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

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

**デフォルトの名無しさん** · 2021/08/28(土) 11:47:42.91

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

**デフォルトの名無しさん** · 2021/08/28(土) 14:53:58.52

HTML/CSSと比べてレイアウトが難しい…

Grid
　Row
　　Frame
　　　色々
　Row
　　Frame
　　　色々

色々の内容がぴったり収まるようにFrameの高さを調整
Frameがぴったり収まるようにRowの高さを調整
といった感じのことをしたいんだけどどうやってもうまくいなない
Rowの高さにAutoに設定しても*にしてもFrameが意図せず伸びてしまう

**デフォルトの名無しさん** · 2021/08/28(土) 19:09:03.02

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

**デフォルトの名無しさん** · 2021/08/28(土) 19:33:05.58

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

**デフォルトの名無しさん** · 2021/08/28(土) 20:11:24.19

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

**デフォルトの名無しさん** · 2021/08/28(土) 21:49:51.89

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

**デフォルトの名無しさん** · 2021/08/30(月) 13:40:30.27

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

**デフォルトの名無しさん** · 2021/08/31(火) 01:16:49.61

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

**デフォルトの名無しさん** · 2021/08/31(火) 10:50:02.21

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

**デフォルトの名無しさん** · 2021/09/01(水) 19:13:15.38

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

**デフォルトの名無しさん** · 2021/09/01(水) 21:56:30.59

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

**デフォルトの名無しさん** · 2021/09/01(水) 23:28:46.15

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

**デフォルトの名無しさん** · 2021/09/02(木) 01:29:31.26

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

**デフォルトの名無しさん** · 2021/09/02(木) 01:41:19.28

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

**デフォルトの名無しさん** · 2021/09/15(水) 06:45:57.06

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

**デフォルトの名無しさん** · 2021/09/15(水) 08:54:57.16

期待はしてない

**デフォルトの名無しさん** · 2021/09/15(水) 10:37:48.94

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

**デフォルトの名無しさん** · 2021/09/15(水) 11:30:20.17

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

**デフォルトの名無しさん** · 2021/09/15(水) 12:21:33.43

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

**デフォルトの名無しさん** · 2021/09/16(木) 05:57:28.70

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

**デフォルトの名無しさん** · 2021/09/16(木) 13:07:00.44

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

**デフォルトの名無しさん** · 2021/09/16(木) 23:53:57.15

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

**デフォルトの名無しさん** · 2021/09/17(金) 13:35:16.51

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

**デフォルトの名無しさん** · 2021/09/17(金) 16:00:04.98

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

**デフォルトの名無しさん** · 2021/09/17(金) 17:48:55.37

>>168
jsでやれ

**デフォルトの名無しさん** · 2021/09/18(土) 01:03:33.84

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

**デフォルトの名無しさん** · 2021/09/18(土) 02:12:24.51

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

**デフォルトの名無しさん** · 2021/09/18(土) 03:04:34.98

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

**デフォルトの名無しさん** · 2021/09/18(土) 03:06:51.99

Micr※s※ft Akan Unk※ Irane

**デフォルトの名無しさん** · 2021/09/18(土) 13:27:29.89

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

**デフォルトの名無しさん** · 2021/09/18(土) 14:34:29.34

懐かしいねSL

**デフォルトの名無しさん** · 2021/09/19(日) 16:11:36.98

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

**デフォルトの名無しさん** · 2021/09/19(日) 16:27:32.66

>>176
整数だけ
Androidの仕様

**デフォルトの名無しさん** · 2021/09/24(金) 23:53:09.35

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

**デフォルトの名無しさん** · 2021/09/25(土) 21:39:23.90

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

**デフォルトの名無しさん** · 2021/09/26(日) 14:47:39.49

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

**デフォルトの名無しさん** · 2021/09/27(月) 16:38:04.18

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

**デフォルトの名無しさん** · 2021/09/27(月) 17:08:37.27

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

**デフォルトの名無しさん** · 2021/09/27(月) 17:14:44.20

気にいらん

**デフォルトの名無しさん** · 2021/09/27(月) 18:34:25.38

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

**デフォルトの名無しさん** · 2021/09/27(月) 19:05:58.85

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

**デフォルトの名無しさん** · 2021/09/27(月) 19:08:58.63

ないわー

**デフォルトの名無しさん** · 2021/09/27(月) 19:33:15.96

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

**デフォルトの名無しさん** · 2021/09/27(月) 19:47:24.87

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

**デフォルトの名無しさん** · 2021/09/27(月) 19:58:33.69

ドヤッ

**デフォルトの名無しさん** · 2021/09/27(月) 20:39:22.80

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

**デフォルトの名無しさん** · 2021/09/27(月) 21:16:49.54

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

**デフォルトの名無しさん** · 2021/09/27(月) 21:22:34.62

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

**デフォルトの名無しさん** · 2021/09/27(月) 22:49:58.55

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

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

**デフォルトの名無しさん** · 2021/09/28(火) 05:23:13.88

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.

**デフォルトの名無しさん** · 2021/09/28(火) 05:25:45.05

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

**デフォルトの名無しさん** · 2021/09/28(火) 08:59:30.90

書いてあんじゃねーか

**デフォルトの名無しさん** · 2021/10/01(金) 06:43:00.65

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

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

**デフォルトの名無しさん** · 2021/10/01(金) 08:29:55.79

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

**デフォルトの名無しさん** · 2021/10/01(金) 08:49:37.02

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

**デフォルトの名無しさん** · 2021/10/04(月) 19:56:50.07

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

本当はXamarinすごいよな？