Xamarin Part6
■ このスレッドは過去ログ倉庫に格納されています
>>748
アメリカのソフトは全体的に日本人が不利になるようなことを増やしてきている。 初歩的な質問ですまないがXamarinでクロスプラットフォーム開発するのと、Swift・Kotlinで分けて開発するのってどっちが吉？
もちろんひとや会社の状況によるだろうけど実際にXamarin使ってる人たち視点でここが優秀、ここが糞っていうのを教えて欲しい 100%ネイティブ
Xamarinはフロントエンドのロジック共有できるがUIはカスタマイズするなら別実装必要かつ超めんどい
あとBaaSなんかのサードパッケージがバグだらけで絶対ハマる そもそもXamarinは当時フロントエンドのUI、ロジックをクロスプラットフォームにC#だけで書けることだけがメリット
今そんなの腐るほどあってXAMLのメリットもただWPF/UWP開発してたやつはMVVMやフレームワーク含めた諸々を引き継げるでってだけ
Xamarin FormsのXAMLそのものがHTML5+CSSにあらゆる点で劣ってる時点でオワコン
今C#なんてUnityだけで耐えてるようなもんだろ B to Cのアプリいくつか案件でやったけど自分はネイティブで分けて作るとか絶対やらんわ
よくそんなめんどくさいことすき好んでやるなぁと思う
UIの作り込みが昨今だとXAMLよりいいのあるんじゃないかって話はまあ分かるけどそれでもそんな二つ別々に作るよりははるかに手間かからん
まあ別部隊が各々作るなら良いけどうちはビジネスロジックもそこそこフロントに実装してるから別言語で作り直すとかありえん
Xamarin.Formsで作ってるけどUIもアニメーション含めてそこそこ良い感じに仕上がってると思う
フラッターの方がいいんじゃ？ってのはまだ議論の余地あるけどあれはあれで闇な部分もあるしな >>753
腐るほどあるならまともなもの後何があるのか教えてくれ
後C#は言語としてまあモダンなものより劣ってるとこもあるかもだが色々頻繁に手が入って開発環境や対応できる場面含めて悪い選択肢じゃないぞ？ web 系のOSS のライブラリは、Linux サーバーを対象にしてる
Windows を対象にしていない。
Windowsで動くように作っていない
Windows で、web 系はダメ！
#!/usr/bin/env node
とか、1行目に、Linux のシバンを書いているファイルも多い もともとxamarinはC#ユーザー向けに使いやすくしましょうって始まったんだから
C#に慣れてる人間が多い会社はXamarin
そうじゃ無ければkotlinなりcordovaなりすればいいだけで
そんなにこだわるようなことじゃないだろ このスレの人間にはUnityだけで頑張るとかして欲しい気はちょっとするけども C#そのものは数ある言語の中でも個人的大好きなんよ
静的型付けとモダンさのちょうど良いバランスとか最高
今ならXamarinよりBlazorキャッチアップした方が良い なんでIPhoneはPWA対応しないんだろうか。
とりあえずはその程度のソフトでいいんだよ。 >>760
iPhoneでもPWAには最低限の対応は出来ていて、既にHome画面への追加は出来るんじゃないの？ >>760
詳しくないから分からんけど、例えば東京アメッシュはホーム画面に追加するとアプリみたいに動くよね PWAとかオワコン進めるとかど素人が知ったかしてて草
時代はWASMやしMS、GoogleはWASM推しでそのためのBlazorよ 時代の潮流は、WasmとPWAの同時対応へと進んできている。
それらは互いに排他的ではなく、同時使用したときに最も力を発揮するので。 しかしKrippすげーな
MTGAで7000人以上の視聴者数とかKrippしか見たことないわ
MPLが人気なさすぎやねんな >>762
Flutterはネイティブコンポーネントとの共存があれでしょ ReactもFlutterもカスタマイズ必要でネイティブ触る必要ある場合途端に破綻するから最初からネイティブで書くほうがゲインあるんよ
ネイティブ実装を自分でReact対応させられるスキルあるやつなんて滅多におらんし実際そこまでやるならネイティブで書くし
あとnpm含めたバージョンと依存関係でハマるからメンテもネイティブのが楽 >>772
それだてネイティブで各々書く事言ってん？
だったらないなー >>771
最近じゃFlutter pubもだいぶ充実してきたし、ほとんど自分でNative部分を書くことはないなぁ。
WebViewサポートが弱いのと、OpenGLがiOSで使えないのが難点だけど。 IMEもなんかダメみたいなこと誰か言ってたけどそれは大丈夫？
いずれにしても全部自前描画はメリットもあるけどデメリットもあるから案件次第だよなぁ swiftで作成済みのアプリ(ソース)をXamarin.iOSに移植するのって簡単？ simulationライブラリで純粋な関数式プログラミングをする
ttp://x0000.net/topic.aspx?id=3631-0
UIライブラリ (C#, 2D) を作ったよ
ttp://x0000.net/topic.aspx?id=3688-0
連続と離散を統一した！
ttp://x0000.net/topic.aspx?id=3709-0
4Dエンジン
ttp://x0000.net/topic.aspx?id=3677-0
matrixのライブラリ
ttp://x0000.net/topic.aspx?id=3711-0
ある強力なFor関数
ttp://x0000.net/topic.aspx?id=3630-0
SQLライブラリ
ttp://x0000.net/topic.aspx?id=3675-0 >>776
SwiftUIとかよく知らんのでその辺は分からんけど、ObjectiveCでも実現出来そうなら多分簡単 >>778
なるほど
まずはobjective-cで移植してる記事を探してみる
コロナ影響でテレワークのせいで顧客環境にあるソースを触って試しに移行とか出来なくて困ってたのよね
ありがとう >>779
Swiftよく知らんのであれなんだけど要は既存のUIKitとか使って実装してるものならXamarin.iOSはただそれをそのままC#で書けるので実装は可能だよ言いたかった。
SwiftUI はよく知らんのだけどあれもきぞんのUIKitを違う形でかけるよってだけ？ Xamarin、React、FlutterでUIの実装が違う
ReactとFlutterは独自実装だからカスタマイズ前提の仕様で独自UIの実装が容易
Xamarinはネイティブラッパーやからカスタマイズが超大変
ぶっちゃけアプリ案件でUIいじらないって100％ありえへんからそれだけでXamarinて択がなくなる >>782
個人的には、グラフィックの Line 文や画像描画命令でプログラムから
カスタマイズできるほうが便利だと思っているので、native wrapperより
独自描画してくれていた方が便利そう。 >>783
それと、表示だけでなく、Edit要素の5行目に文字列を挿入したいような
場合、native要素だとどれだけ互換性の問題がクリアされているか心配。
挿入後に勝手にスクロールするかどうかはWindowsだけでも非常に複雑。
でもそこが一番重要だったりする。
その辺が独自描画だとどのOSでも同じ動作になってくれるので楽。 同じ画面になってくれりゃいい場合と各プラットフォームでそれっぽい挙動して欲しい場合と色々いあるしなぁ 久しぶりにxaml触ってるけど(xamarinじゃなくてwpfだが)ほんと楽だわ(覚えるまでが大変なんだろうが)
だが、wpfで今アプリ作ると見た目が残念になるし。materialdesignxaml使うとデスクトップアプリでは不要な余分なスペースだらけになるし
いくらxamlすごくても自分でテーマつくちゃうぐらいのセンスねぇし
まぁxamlどっかで復権してほしい。チャンスあるとすればwinui 3.0次第かな なんかXamarin FormsでXAML楽チンて言ってるやつはほんまにXamarin Formsでアプリ書いたことあんのか
Entryのborderのcolorを変更するだけでiOS/AndroidそれぞれPlatformEffect継承・実装してSharedでRoutingEffect実装してくっそめんどいんやがどこにReact Nativeよりメリットあんのか教えてほしいわ
個人的にずっとWPF/MVVMで開発してたからXAMLは好きやしゴリゴリユーザー定義コントロール作ってたけどXamarin Formsはクソで少なくともUI実装においてJSX/TSXに勝てる要素がない 初めてのアプリ開発にXamarinかFlutter使ってみようかと思ってたんだが、こういう流れ見てると素人ほどネイティブで作ったほうがよさそうね
楽しようとして結局苦労しそう >>788
ちょっと作ってみるにはFlutter、ガッツリ作るならFlutterでもnativeの知識必須。 >>789
ちなみにその基準の「ガッツリ」ってどの辺から…？ >>790
ゲームのようなアプリとか、GPSやBLEをマニアックに使うアプリとか、スマホの性能ギリギリまで色々とやりたい時。
逆にスマホデバイスもほとんど使わずListViewレイアウトぐらいしか使わないアプリはFlutterのほうが早い。
mateと同じ見た目のアプリをFlutterでやろうとするとかなりシンドい。 継承・実装って言うと大げさだけど右クリからポチポチクラスつくって
2,3ステップのコード書くだけやん
大体Xamarin Formsでいけるし
ios12→ios13のSegmentedControlの仕様変更は少し大変だったけど Buttonをまったく違う形状にゴリゴリにカスタムしたい
Xamarin FormsならEffect、Visualを使ってコードビハインド
React NativeならCSSプロパティ設定するだけ
どっちが簡単かつ柔軟で実装が楽か結論でてるやろ >>791
なるほどありがとう
mateはchmateでは
使ったことないけど2chブラウザがそんな難解なデザインしてるのかな xamarinは、最小に近い簡単なプログラムでも *.apk が22MB位、
同じアプリをJavaとAndroid Studioで作ると *.apk は1.8MB位
で済むそうだ。 >>794
それはReactNativeがround buttonについて実装済みってだけじゃね？ ボタンの形とかより、なんとなくボタンを押したときのグラフィックの感じとか nativeのままだとが気に入らないことがある。 ソフトウェアの利用者は、ソフトウェアごとにお作法が違うとめんどくさい。
おまえのソフトは誰も使わないからどうでも良いけど。 Xamarin程の糞はないと3年前から言い続けてやっと時代が追いついた Xamarinはネイティブラッパーな仕様が糞すぎんだよ
RNやFlutterのように独自実装ならiOS/Android同じViewで同じ見た目にできるのにネイティブラッパーだからできない
肝心のXAMLも同じ見た目にする場合カスタムが必要でプラットフォームごとにコードビハインドで実装しないといけない糞仕様
FlutterはPlatformViewでネイティブ利用も改善されてきたがDartが糞すぎて嫌いだしWedgetsの構文がまんまJSXのパクリで草
RNは開発環境でハマるのが糞やけどXamarinやFlutterよりは好み やっぱ俺の先見の明は確かだな
Xamarin程の糞はないしクロスプラットフォームは例外なく糞 客が既にSwift/kotlinで作ってあるアプリをXamarinに切り替えるって言って聞かねーんだがどう説得すりゃいい？
ここで言われてるようにクソだからやめとけって言ってんのに全然だめだわ
切り替えたい理由は自社にネイティブの有識者はいないがXamarin経験者はいるから保守が楽になるだろうと言うことらしい お前がそのXamarin経験者より下に見られているというだけの話
人脈作りを怠ったツケだよ 歴史的過程から考えて今後長くXamarinが保守されるとは思えない。 >>803
調達したチーフプログラマーはC#が得意だったという理由だけでXamarinにするなら絶対ハマるし属人化するから100％保守が大変になると説得しろ
俺がネイティブで書けと断言する理由はおおよその企業のプロジェクトにおいて一番苦労するのは人材の調達や交代やからや
プログラマーを調達・交代できずに苦労するのが目に見えてるから先を見てネイティブで書けと言ってんねん
そら最新の言語・環境なんかのメタをすぐキャッチアップできるフルスタックな高スペックプログラマーがいくらでも社内におるなら別やから好きにすればええけどな 問題起きても客が対応するって事だろ？
Xamarinに切り替えたらええやん
ディスコンになったらまた切り替える羽目になるんだから
いっぱい稼げて美味しいじゃん 企業としてのXamarin社は当面残るだろうが、プロダクトとしてのXamarinは.NET 5(更に先の.NET 6)に統合
することをMicrosoftが言明している
中身はともかくXamarinの名称そのものは近いうちに消滅する xamlをちゃんとデザインできるようになったら
xamarinと言う名前はどうでも良いし、上手く行けばUWPを1回書いたら
Windowsでもandroidでも動くように・・・・なるのかな
AdobeのFlashはAndroidもiOSもWindowsもmacも全部同じバイナリが同じように動いたのに残念だった・・・ XAMLがすでにオワコンやねんなー
XAMLでウェブアプリ作るサードフレームワークあったけど盛り上がらずMSも買収せんかったし
んで結局アプリ・ウェブをクロスプラットフォーム開発可能なBlazorがリリースでこっち推しはじめて時代はWASM/WASIのBlazorですよと
.NETもオープンソース化に遅れてオワコン化手前までいったけどUnityなんかでなんとか耐えたけどXAMLは完全にオワコン
ウェブとモバイルを軽視しすぎたMSの失敗でXAML死んでしもうた、XAMLでウェブ開発かのうにすべきやったと思うけどASPあるからしゃーないわな >>810
それがUno。
弱小だし、Xamarin頼りな点が惜しい。
そういうのをMSが作れない、作らないのがダメダメ。 だな。MSがやらんから、他がやろうとして結局リソース不足の品質でリソース分散で共倒れ Unoもそうだしavalonia UIもそうだし。リソース分散 >>804
クッソ頭悪そう
文脈から考えて作るのはアウトソーシングで納品後のメンテは自社でやるってことだろ >>803
Forms使うんじゃなくXamarin.Native使うならありなんじゃねーの
ロジックが共有されるのは大メリットだろ ロジック共有なんてRNもFlutterも一緒やしすでにXamarinの専売特許やないねん
そもそも当事者のMSがSkypeをRN、VSCodeをElectronで書いてるからな
Blazor推すならさっさとこれらをBlazorで書き直せと、なんかMSは縦割りなんか知らんがやってることがあべこべなんよ
俺がMSの開発環境に絶望して忌避するようになった理由はそこなんや、C#そのもの今でも一番好きな言語や マイクロソフトが嫌いだからって周りにマイクロソフト嫌い菌をばら撒くとか気違いすぎる さすがにblazorで書き直せはいくらなんでも明確なメリットないと相手が大企業で高収益企業だからって無茶苦茶すぎる すまん、ネイティブしかやった事ないけどロジック共有ってどのくらいできるものなの？
ささっとググったら半分も行きゃ良い方、ＵＩ周りは結局別で作らなアカンしXamarin特有のバグもあるから旨味が消えてしまうケースも多いと出てきたんやが >>820
BtoCのアプリだけどForms使って9割以上共有してる
共有できるやつはそう書いて固有に実装しないと無理だなってところだけ個別に書くだけだからものにもよるけどほとんど共有できるだろ >>817
Xamarin,RN,Flutter各々のいいところ悪いところあんだからじぶんがつかいやすいものをえらべばいいだけでは。
MSがそれらを作り直さないのはわざわざ作り直す必要性がないしそれらを選んだのも既存コードとの関係でそうした方が都合が良かっただけだろ まあマジレスすると、Xamarinが最強とかは言わないけどロジック共有して開発できる実プロジェクトで十分問題なく使えるある意味枯れたクロスプラットフォーム開発環境として十分に選択候補としうるものだと思うけどね
js得意ならRNとかでもいいんじゃね？ >>821
Xamarin.iOS/AndroidとXamarin.Formsってどう違う？
俺もXamarin使ったことない素人だから聞きたい >>824
X.iOSと泥は各プラットフォームネイティブアプリをC#で書ける仕組み。それだとUIも各プラットフォームの流儀で書く。Xamarin.Nativeとも呼ばれる。
FormsはXAMLを使ってどちらででも動くUIコードを書けるフレームワーク。
AppDelegateとかMainActivityとかからXamarin.Forms.Init()などを呼んで動く。XAMLで書かれたコードは結局は各プラットフォームのUI,ViewControllerやら何やらに作用して動く。ので共通コードで書いても各プラットフォームっぽいUIになる。 のでFlutterが全部自前描画して共通なUIを作ってるのとはまるっきりアプローチが違う。これは強みでもあり弱みでもある。Flutterは同じ見た目のアプリを作るのは容易い。が自前描画ゆえ既存のネイティブコントロールとの混在などが苦手。
のでwebViewがらみとか弱いらしい(使ったことないので聞き齧り >>825
ありがとう
NativeはUIはそれぞれ作成、FormsはUIも共通化可能と言うことなんだね
Formsで共通化する方が利点が多そうだね >>827
共通にするが故のデメリットもあるから銀の弾丸じゃないけどハマればメリット多いと思うよ Formsはフォームにパーツを配置してデザインできないのがなぁ
開発画面はXamarin.Androidと大差ないのに
Visual Studioの機能を生かし切ってないのが不思議 c#使いが期待するのはまさにそれなのよね
だからみんなコレジャナイ感で手が進まない そんなんレベル低いやつだけだろ
ポトペタでUI作るやつなんてウェブですらおらんぞ
勝手にC#erの総意にすんなよ いちいち意図通りのUIになってるか確認する作業と調整を繰り返すんですかね？
それこそ低能なような なんのためのホットリロードなんだよ
こんなレベルであれこれ言ってんだから草 >>827
ところがどっこい、Formsは最大公約数でしかないので細かいことをしようと思ったら結局Native UI使うハメに。
それにFormsはNative UIへマッピングされてるに過ぎないので細かい挙動が違うこともしばしば。
それでも別に作るより楽だけどね。 なんかレベル低いそもそもネットで調べただけでXAMLまともに書いてないにわかが湧いてんな
XAMLをデザイナで作るやつなんていねーんだよバカそもそもExpression Blendすらそんなのあったななんて存在なのにおまえにはWindows FormsかVBがお似合いなんだよボケ
XAMLの真骨頂のControl TemplateやFlameworkElementでゴリゴリにカスタマイズするときにポトペタできないとか微調整するんですかとか無知すぎんだよにわかが
XAMLは常にデータバインド意識しながら書くんだから微調整するに決まってんだろだからMSもホットリロード実装しんたんだよにわか 総意にあらずとか無知すぎんだろ
XAMLはMVVMアーキテクチャでViewを書くために作られてデータバインドなくしてXAMLはねーんだよ
そもそもXAMLのオブジェクトはすべてDependencyObjectを継承してんの理解してんのか？HTMLのDOMじゃないんだぞ？
マジでレベル低すぎんな >>835
足りないコントロールとかはViewなりSkia使っての描画なりで共通に動くもの作ったりすると思うけどそれで足りないもの何ある？
自分とこでは一部Renderer使うぐらいで治ってるけど
>>836
最近UI側触れてないのでホットリロードあんま触ってないんだけど、あれちゃんと動く？この辺はちょっと制約があるとかあれば教えてくれ 俺もデザイナーいらんと思うわ
どうせ実機とずれるし。だったらちゃんと動くホットリロードあるならそれの方がいい WYSIWYGはいらんなぁ
デルファイかよっていう >>840
XAMLのHot Reloadは言語的制約で完全じゃないしまだプレビューだからかバグい
Viewの変更を保存したらリビルドせずにリアルタイムで反映させられるんだがもちろんロジックであるViewModel以下の変更は反映されない
まぁLive Visual Treeあれば俺は気にしないがな、これがなかった昔は実行時生成のバッキングフィールドやnameしらべるてて大変だった Unoとかも結局WasmでWebアプリ書けないからダメだな
XAMLをHTML5+Javascriptに変換するトランスパイラないと人気でるわけない
まぁXamarinをバックエンドに使ってるだけだからできんのだろうが >>844
>Unoとかも結局WasmでWebアプリ書けないからダメだな
？？ >>845
独自調べによれば、XamarinもBlazorもFlutterも人気が無いらしい。
逆に、Qt、Unity、vue、Reactが人気が有る。 ■ このスレッドは過去ログ倉庫に格納されています
