Xamarin Part7
レス数が1000を超えています。これ以上書き込みはできません。
Introducing .NET Multi-platform App UI | .NET Blog
https://devblogs.microsoft.com/dotnet/introducing-net-multi-platform-app-ui/
GitHub - dotnet/maui: MAUI is the .NET Multi-platform App UI, a framework for building native device applications spanning mobile, tablet, and desktop.
https://github.com/dotnet/maui え?
.net 5はそれこそ順調やん?
今preview 7?で、後1つか2つかなんかでなんかになるって Today, we’re releasing .NET 5.0 Preview 7. It’s the second to last of the preview releases (before moving to RC).
ちょっと遅れてるのかな flutterよりxamarinのほうが良いってところは何だろう？
C#とdartの言語の違いは別にして。 接触確認アプリcocoaもXamarinを使ったから品質が悪くなった 誤通知とか通知されないとかそもそもチェックされないとか
どうすんだよあれ cocoaでxamarin＋Azureの巻き返ししようとしたけどかえってミソつけたな >>14
感染者既に東京だけで1万4千とか
全国で2万とか越えてるのに
アプリ利用の感染者で感染登録数十人とか全く使えねー むしろ直近2週間以内の行動圏内に感染者との接触が10人も表示されているのはヤバくないか？ いや
日本全国でまだ数十人分しか登録されてないって話 ソースはこれ
https://japan.cnet.com/article/35157557/
感染(陽性)判明した人には本人のスマホに強制的にCOCOAインストールさせて感染登録させるくらいでないといかんが
感染後にインストールしても無意味かも知れんな Ｘａｍａｒｉｎで作るとそれだけでアプリの品質が悪くなる Xamarinってそんなひどいの？
Unity使った方がマシまである？ Unityはクロスプラットフォームで唯一成功しているそれは認めよう
他は糞ばかり、その中でもキングオブ糞なのがXamarin Flutter > React Native >> WebViewアプリ >>>>>>>> Xama糞 Xamarin Nativeはいい出来だけど肝心のXamarin Formsはクソ
バグ多すぎ FlutterもWeb正式対応したけどぶっちゃけどうなのよ
やっぱ案件はWebが一番需要あるからあえてハイブリッド選ぶならReactになっちゃうと思うんだが あとReactはクラスじゃなくてSFC推奨で継承じゃなくてHOC使えってのが困惑
俺もSFCのが書き方好きだからクラス使ってないけどHOCは複雑だからHooksバリバリ使っててこれRedux必要なんか？って感じながら書いてるわ 開発環境の話になったらめっちゃ饒舌になっててワロタ Xamarinがいまいち広がらないのはXAMLのせい
はよC#で統一してくり >>12
プラッタは良くも悪くも隠蔽して独自描画だからな
ネイティブとの連携などXamarinが強いとこもあるでしょ >>37
XAML使わなくてもC# コードだけで作れますよ >>37
マジでにわかどころかエアプすぎるだろなんなの？
C#は言語、XAMLはフロントエンドでReactと同じだよしったかくん
そもそもXMLでアプリケーションフロントエンド実装の先駆けで期待されてたしニーズもあったのにMSはプロプライエタリから脱却できなくてWPF放置したから結果MVVMも死んだ
スティーブ・バルマーによって失われた10年は開発環境でもMSを敗者にしてしまった そもそもXamarinはMAUIが正式リリースされた1年後にサポート終了予定だぞ
MVVMもMVUが主流になるだろうからデスクトップアプリでだけ生き残れるのかな？放置されて死んじゃいそうだけど ウチはずっとXAMLでUI組んでるなあ
慣れると楽なんだがみんな嫌いか？ >>44
嫌いじゃないよ
XAML使った方がレイアウト定義するの早いもん Xamarin.Formsだとパーツ貼り付けできないし
リストでパーツを増殖させるような方法だとそもそもガイドすら表示されない(xamlのせいではないのだけ)
なんかせめてガイドを表示する方法って無いのかな
やってる人いるみたいだから俺が知らないだけみたいだけど・・・ 俺もXAML大好きだよControlTemplate、VisualTree、LogicalTree理解しててユーザー定義コントロールでゴリゴリカスタマイズできるやつ少ないからかなり重宝された
たださっさとASP捨ててXAMLをWebに対応させなかったのがMSの大失策だったし今もBlazorなんかでASP引っ張ってるのは愚策だと思う
俺ならXAML+MVUですべてのアーキテクチャをWebとHot Reloadを前提にしたフロントエンドに統一する >>46
XAML使いこなすやつらはデザイナを必要としないLive Visual Treeがあるだけで昔とは段違いの効率になってる
ポトペタしてるレベルならXAMLは使いこなせないしメリットないからコードビハインドで書いたほうがいいよ Prism使わないMVVMとかINotifyPropertyChangedやICommandなんかの基本機能すら全部スクラッチするんだぞナンセンスだね
さらにDIコンテナなんて自分でまともな代物作れんのかよ、そんなアーキテクトレベルなら業務システムやアプリなんてシコシコ作ってねーだろ INotifyPropertyChangedなら20行くらい
ICommandのDelegateCommandくらいなら20行くらい
それぐらいならしこしこできるというか、それぐらいなんでしこしこしてるわ で、kotlinでのandriod開発やflutterでの開発もMVVMで、.netのようにINPCが標準で用意されてないのでこれもしこしこする
まぁ、andriodはDataBinding用のObservableインターフェース、flutterはValueNotifierやらObservableパッケージもなどいろいろあるが 別にCommandにしてもINPCにしてもベース一度作ればそれでいいしDIもコンストラクタインジェクションしか使わないしな
ライブラリ、機能や考え方がバッチリ自分に合ってればいいけど外れた時にめんどいんだよね
MVVMCrossだっけ？あれ使ってた時は起動速度遅くて、調べたら勝手に色々やるところでリフレクションでなめてるところがクソ遅くて回避するのにすごい手間取ったわ >>56
その回避策おせーて
ヒントだけでもいいから >>59
昔なんで忘れたが、動作を変えられるクラスでリフレクションしてるメソッドを呼ばないようにしたかオーバーライドしたかソースで無理くり変えてローカルでビルドしたやつ使ったか… >>63
チーム開発と個人開発の違いとか全く関係のないライブラリだと思いますが むしろ個人開発の方がライブラリ導入のハードルは低い気が ちょっとしたアプリだったらPrismなんか鬱陶しいだけや
インタフェースすらいらんクラスは全部newして使え >>66
BindableBaseだけでも便利じゃない？ Prismに実装は知らんけど、それぐらいだったら自分で実装した方がいいわ Xamarin.Formsで作ったアプリの起動を速くする方法教えて 今度は.NET Standardの開発を2.1を最後に中止かMSの開発環境はもうブレブレだなw
今後は.NET 5だけを継続して.NET xxというナンバリングに統一するんだな
さっさとXAMLも廃止して今後すべてのフロントエンドはHTMLベースのASPに統一すればいいのに
なんでフロントエンドの実装がいくつもある状態は維持するんだよ先にこっちに手をつけろよ
なんかもうC#なんかはAzure使ったバックエンドだけで飯食っていきたいってのが見え見えなんだよなフロントエンドとかFlutterやReactなんかの好きなの使えって感じでお荷物なんだろうな Flutterも大概やぞ
企業案件じゃ怖くて使えん xamarin使用してまともに作られたアプリってあるの >>76
cocoa
ってMSは言わせたかったんやろなあ。なお 日本人全員に使わせたいアプリという条件下で採用されたのは大きいね >>72
JSに頼らなければならないHTMLよりXAMLだけで作れるほうがシンプル
C#はゲーム業界でも活発に使われている >>70
つか、今時のマシンで素のテンプレアプリなら起動早いだろ
後はお前のアプリ次第なんじゃないの
>>72
名前が変わるだけで中身大して変わってないだろ
Xamarin.Formsもクロスプラットフォーム開発としてはネイティブともモニョモニョできるし筋は悪くないと思うけどね google payはflutterで作り直したのか
msもreact native捨ててxamarinでoffice作り直せよ それな
GoogleもFacebookも自社で使ってる技術を公開したり自社の技術で開発するのにMSだけは他社の技術で作る矛盾だらけの現実www
React NativeのOfficeやSkypeだけじゃなくVSCodeもElectronだしコアなとこC++だしそこもRustに試したりしてるしマジでMSがこんなことしててMS環境をデベロッパーに使えって無理筋すぎるだろwww どうして選択肢を狭めたほうがいいと思ってるんだ？？ いやMSの開発環境とか選択肢にすらなってないから
日本はMSとエヴァンジェリスト()とかいう開発まったくできない意味不明なやつらが大規模開発で採用されてたりする世界でも特殊な環境ですからwww Linux 財団が作った、Cloud Native Computing Foundation (CNCF)には、
Microsoft(MS), Apple など、ほとんどの企業が参加してる
Kubernetes, Fluentd, Prometheus などが卒業ソフト
MSは、ここ10年、Linux 主体で採用してきたから、WSL を作れた！
一方、Apple は、資源をスマホに集中させたから、将来性は危い デプロイ王子まで投入してあのざまなんやから、xamarinでまともなアプリ作れる人間は存在しないんやろなあ 日本のアプリ開発のレベルが低いんだよアプリの開発力って卓越した技術力とかじゃないんだよな
まぁアプリを開発するうえで基準となる技術は持ってて当たり前の話だから
よーするにセンスがない日本のウェブでもアプリでもまともなもの存在がしないのにネットじゃ日本の技術力は世界レベル！とか笑う Flutterで構築新しいGooglePayも実際に触ってみないと何とも言えんでしょ
てかはよ使ってみたいから日本ユーザーにもベータ版開放してや そのツイート見ても>>92とどう繋がるのかよく分からないんだが解説してもらってもいいか？ >>81
マジで？
prismのテンプレそのままで起動しただけでも遅くない？ 早いとか遅いとか議論にならんやろ、具体的な数値もなしにw >>96
テンプレのFormsアプリとテンプレのprismで比較してからだな デレゲートコマンドの良さが全く理解できないんだけど何のためにあるの？
ICommand継承したコマンドクラス用意したほうが分かりやすいし使いまわせるからいいと思った は？DelegateCommandはICommand継承してんだが？
MVVMというよりプログラミングがにわかすぎるから基礎を勉強してから質問しような？ だからそのインターフェースがあるのにああいう使い方するのはどうなんだ？ってこと >>101
処理ごとにクラス定義すんのめんどくさいし全く必要ねーだろ つーかF#みたいなアドホックなインターフェース実装導入してくれよ Xamarin.formとXamarin.androidの違いがよくわからんです
前者はwinformと同じ系統？androidアプリにも使ってる例があったので使い分けがあるんですかね？ FormはXamarin.iOSやAndroidの上で使える共通UIライブラリだよ UI含むフレームワークって言った方が適切かも知らんが Xamarin.form
→ 糞
Xamarin.android
→ 糞 Xamarinめっちゃ最強なのになんでお前ら文句言ってんの？
自分の脳力のなさをツールのせいにする奴って嫌いやわ 春はあけぼの
夏は夜
秋は夕暮れ
冬はつとめて
糞はざまりん FlutterスレでXamarinの悪口を言いたい放題になってるんだけど、悔しくないの？ 国税庁で出したやつもXamarinなんだろうな
日本はXamarinで決まりだな やっぱ The Marine にかけたのかな。Xを使うところも厨二っぽいし。 VS 2019 CommunityでAndroid用アプリを作ろうと思って試してるけど、
レイアウトをRelativeにした場合、Buttonなどのウィジェットを一つしか張り付けることが出来ない。
レイアウトをVerticalにした場合、ウィジェットを縦に２つ以上並べることは出来るけど、横に２つ以上並べることが出来ない。
レイアウトをAbsoluteにした場合、ウィジェットを一つも貼り付けることが出来ない。
どうやったら縦横自由にウィジェットを貼り付けることが出来るでしょうか？ そんな基本のところのチュートリアルも自分で探せないなら厳しいな 返答ありがとー
まず、Linear(Vertical)を配置したあと、入れ子でLinear(Horizontal)を部分的に配置することでやりたいこと出来るようになりました。
C#+Windows Formの経験しか無かったから、こんなところで躓くことになる。 c#ポトペタでスマホアプリできるんか！？って思ってた時期が俺にもありました え？できないの？
じゃあなんのためにxamarinて存在するの？ UIViewにAddSubView()とAdd()があって、どっちを使っていいか分からんから違いを調べたわ。
こういうのほんとうざい。
Add()を使うとか規約で決めてますか？
それとも統一性の無い糞コードをメンテしてますか？
私は後者です。 >>128
お前はポトペタ以外の開発って一切しないの？
>>129
UIKitもう忘れたけど必要なら統一したまへ
既に量産されてたら頑張れ UIView.AddSubViewはアップルが定義した名前だからXamarinに文句言うのはお門違いやで 普段、Android StudioでKotlin（またはJava 8）でAndroidネイティブアプリの開発しているけど、Xamarinに変更しようか迷ってる。
Android Studio開発環境からXamarin環境に移動した人の感想が知りたい。 名前が糞
M$得意の名前だけ変えて中身同じ作戦実行したら
また逝き還ると思う .NET FrameWork +.NET Core + Xamarin/Mono
3本のフレームワークまとめて.NET 5に統合…されるはず……
2020/11月予定だったけどどうなった？ 質問の仕方変えるか。
Android Studioでサポートされたばかりの機能って使える？ さっきから理由説明も無く糞だの老害だのVSが良いだの言うけど、理由説明くらいしようぜ。 Xamarinで開発することはDLLヘルの労苦を自分から招き入れることと似ていると思う .NET MAUIの続報を待て
てか早く情報出せよん mauiのことならGAが来年の11月
.net 5なら今年の11月 5だとXamarinはどういう位置付けになるんだっけ。
最近そっち全然追ってないや MSの中でも力入れてる技術じゃないから
もうむりでしょ。 何がもう無理なんだか意味わかんないんだけどお前使ってねーだろ PCのハード変えようと思うんだけど
VS19のXamarin.Formsに適したメモリスペックはどれくらいですか？
Androidエミュレーターだけで推奨4GBと書いてるから、RAM8GBが
最低ラインだと思うけど、VS用途で16GB, 32GBにしてどの程度差がでるかわからない。
メモリたくさんつんで、複雑なUIをXamarin.Formsで使う場合に
XamarinとVSでRAMどれくらい使いますか？ あ、iOSとAndroidのエミュレーターが同時に起動するのなら8GBと16GBで差が出るかな
Xamarinでの開発用途で16GBと32GBで差がでるのかは気になる よくわからんけどハード変える前にまず今の環境で試してみれば？
あとiOSはMacへのリモート接続だよ >>164
メモリスロットの空きがない上に手持ちメモリの規格が
違って大容量のテストができないのです。
メモリを買うか、PCまるごと変えるかしないと試せない状態
同じ画面でAndroidとiOSのふたつエミュレーターらしきもの起動してるのをYouTube
のXamarin.Forms動画で見た気がするんだけど、
あれiPhoneの画面はリモートの画面を映してるだけのエミュレーターもどきってことかな？
だとするとWindows側のメモリやCPUの負荷はほとんど増えないのか
iPhoneはあるけどMacもまだ買ってないので試せない 4GBではiOSはしらんけどアンドロのエミュレータ開くのにも応答なし連発しながらすごい時間かかる
なので自分なら16GB以上を選ぶ >>165
そう、iOSはmac側でシミュレーターが動いてて、xamarinは表示してるだけ。mac画面でも同じ画面が表示されてる。 >>166
Android Studioでもemulatorだけで最低2GB、推奨は4GBらしいから、
OSいれて8GBが最低ラインとみている
>>167
なるほどー
Xamarin以外にAndroid StudioやFlutterを同時起動したり
Xamarin.Formsのemuを2つ以上同時起動することも考慮しても
トータル16GBでSSD構成ならば快適に使えそうな感じがしてきた。 最低メインメモリは16GB
ストレージはSSD
CPUは4コア8スレッドで充分 >>169
Xamarin.Formsで16GB超えるケースってどんな使い方？ なんでVisualStudio以外起動しない前提なのよ いっその事、実機は？
XamarinじゃなくてAndroid Studioしか触ったことないけど。 iOS appをMac hardware使わずにbuildできるみたいだな
Hackintosh / RyzentoshにしてMac OS使う方法のが
Win10にEmulatorとMac OS入れる方法より快適そうに思えるけど
Xamarin民はHackintosh多いのかな >>171
PostgreとかPostmanとかVS以外にも起動するけど
そんなGB単位でメモリ使うソフトがあまりないからだよ。
ブラウザもタブ数個しか開かない派
メモリ16GB超必要な人はやっぱり仮想化したMac使ってるのかな？
ゲームと仮想化OSとChromeはメモリ馬鹿食いの代表だし >>173
効率よくクロスプラットフォーム開発したいから、
Android StudioではなくXamarin.FormsかFlutterにしたい。
C#が好きだからXamarin.Formsのが現時点で好き
Madの実機はコスパ悪いので買いたくない
Mac OS入手するために中古は買うカモだけど
開発はHackintoshにした自作PCか
Mac OS仮想化したWindows PCでやりたい。 仕様書は開かないでプログラム作る人?
Visual Studio別にして普通に使ってても8Gなんて足りないケース多いけど
金の問題かもしれないけど
マシンを快適にしたいなら上限決めるんじゃ無くて、下限決めておいた方がいいよ >>178
8GBにするなんていってない。>>168で8GBは最低ラインだろうと書いてる。
175 170をよく読んで欲しい。「16GB超」と書いてる
つまりXamarinで32GBとか64GBが必要な状況を聞いたわけ
「超」の一文字見落としてるでしょ
そこまでメモリ使うとしてXamarinではなくMac OS仮想化で大半使ってるんじゃないかなと
>>177
ぜんぜん切れてない
ふつうに誤解を訂正してるだけ 6年前のパソコン工房の初心者向けノートPC、
Windows 10 Home, 64 bit, 20H2(2020 秋)
CPU は、i3-3120M。2 core, 4 thread。
8GB メモリ、128GB SSD
WSL2 で、Windows 側に、VSCode, ブラウザ、
Linux 側に各プロジェクト、Ubuntu 18.04, Docker, Ruby on Rails, Node.js, データベース
8GB メモリでは、キツイ！ Visual Studio なら、CPU-i7, 16GB メモリ、256GB SSD が最低ライン
VirtualBox, WSL2, Linux まで考えると、32GB メモリを推奨 >>180
Xamarinが入ってないというツッコミを置いておいてｗ
その使用例でもメモリ喰ってるのはブラウザとコンテナだろうな
コンテナ/仮想化が大量に使ってるだけでほかはたいしたことない
Dockerとか仮想化使わなければかなり高速化するはず >>181
あとi7が最低ラインとかおかしい
Passmarkとかベンチスコアでかかないと意味ないだろう
i7でも世代が古ければ意味ないし
SSDも安くなったから容量より速度だろう。M.2のがいい >>184
ありがとう、Hyper-Vは有効にした。
有効にしないとXamarinのAndroid emulatorがOS起動すらしなかった。
Hyper-Vを有効にしたらMEmuというAndroid gameやるための
emulatorが使えなくなってしまった。
正確に言うとMEmu起動するとHyper-Vを無効化されてしまう
MEmuはVirtualBox依存だからほかのVirtualBox上のVMも
XamarinのAndroid emulatorと共存できないかもしれない。 Hyper-Vはハイパーバイザ型の仮想マシン
VirtualBoxはホスト型の仮想マシン
そもそも原理が違うので共存できない
https://ascii.jp/elem/000/000/414/414625/4/ >>186
ありがとう
どうやら新しめのVMwareやVirtualBoxでは
Hyper-Vとの共存ができるようになっているようだよ
https://qiita.com/mfunaki/items/d46e1c8bc3c7eb055b06
https://kb.vmware.com/s/article/76918
共存させるにはVMwareやVirtualBoxだけでなくHost OSのWindowsも
新しいBuildじゃないとだめみたい。
仕方ないからWindows10を20H2にupdateをしている。
Xamarin.FormsのAndroid emulatorとVMware Workstationの共存可能になれば
VMwareにMac OSのVMいれて、PC1台でiOS, Android appsを開発できるよう
になるはず。まだ試してないから断言できないけど Xamarin.FormsのAndroid Emulator,
「設定」とか開いているとすぐにエラーでて処理が止まったりしてまともに動かない。
Xamarin使用時のタスクマネジャーみるとEmulatorはQEMUみたいですね。
作成したVMはproject作成時にデフォルトで作成されるVMで
Pixel, Android9 pie, というやつです。
安定してXamarinのAndroid emu動いてますか？
安定して動くバージョンのVMとかありますか？ xamarin.formsでアプリ作ってるんだが、iOS側でキーボードの高さを調べる方法の参考になりそうなサイト知ってたら教えてください xamarin.formsでアプリ作ってるんだが、iOS側でキーボードの高さを調べる方法を調べるのが面倒なので、誰か調べて参考になりそうなサイトあったら教えてください teratailかstackoverflowに聞いた方が早い
ここよりも嫌らしいしネチっこいけど >>188
Hyper-Vを使えるPro版のWindowsでしかAndroid Emulatorは使えなかったような >>193
ありがとう
VMwareはProではない無料のVMware workstation player 16だけど、
Win10 はWin10 Pro 20H2の最新安定buildです。
Win10 1909から20H2アップグレードしたあとは、VMware player16で
Hyper-V関連の警告がでることもなく、VMwareをインストールできた。
Hyper-VとVMwareは共存できるようになった様子。
他の人はAndroid emulator安定してるとなるとメモリ不足のエラーかも。
増設メモリ届いてからVMwareにMac OSいれてXcodeとか使えるようにする予定 USBケーブルでAndroid実機つないでテスト、デバッグして、
Android Emulatorは使わない派けっこう多いの？
実機メインとXamarinのエミュレーターメインの開発どっちがいいのかよくわからん >>195
実機で確認できない解像度での表示確認くらいにはエミュレータ使うけどほとんど実機でデバッグするね
実機の方がサクサク動くから >>196
なるほど。タブレットとか解像度いろいろあるし解像度かえて、
エミュでUIのバランスとかをチェックするわけね。
USBケーブル着脱がちょっとめんどくさいけど実機メインで始めてみます。
サクサク大事ですね iOSは実機ビルドが遅くてシミュばかりだけど、泥は実機の方がエミュが動かないとかないしデプロイもクソ楽だし実機の方がいい。
けど家では実機持ってないのでエミュ使ってる >>194
20H2でPixel 2 Q 10.0 - API 29のAndroid Emulatorで使えてる。エラーが出たりしたらデバイス削除して作り直してた。
メモリ8GBでも使えてる。CPUはN4100ってセレロン。
エラー出なくなったらデバイス削除しなくても使えるようになると思う。
不安定さに関係あるかわからないけどAndroid SDKとツールでHAXM installerも入れてる。 >>198-199
なるほど、iOSはbuild/deployが遅いのね
仮想化MacOS (on VMware)は遅くなりそうだし、
Mac実機ないならHackintosh自作PCを用意したほうが良いかな
Android10の実機をUSBでつないで試してみたけど実機だとほんと速くてびびった。
いろんな解像度のチェック以外にはもうAndroid Emulatorは使わないかも。
Wi-Fiでもdeployできるし楽でいいね。
Android11になるとwi-fi deploy楽にできるから早くAndroid11来て欲しいわ >>199
YouTubeでもAndroid Emulatorだと謎のエラーでてたし
ある程度は謎エラーでるのかな。
メモリはDDR4-16GBを購入しました。眠ってたマザーでXamarin用PC組む 正規のMac実機が無いとAppleのサイトで開発者登録拒否されるのでは？ >>202
searchした限りではHackintoshでiOS apps作ってる人もいるようだよ
iOS app作ってくれるのはアップルとしては大歓迎でしょ。
アップルハード買わせたい狙いはあるだろうけどそれならば
もっと徹底的にHackintosh潰し対策してるはずだよ
現状はほとんど黙認
Mac OSは無料化されてるしあまりOSのライセンスはうるさくない。
ただApple siliconになっちゃうからHackintoshできるのも
せいぜいあと2年。 >>203
Hackintoshは動くハードが限られてるみたいだし、動くハードを買うなら整備済Mac miniでも買った方が時間かからないと思うよ。
税別60800円で買った整備済2020年のMac mini Intel Core i3 メモリ8GB SSD128GBだけどXamarinのビルドに使えてる。
その前買った2011年のMac miniはよく持ったけど最新macOS対象外になったから買い替えた。 というよりHackintoshのインストーラ作るのにmacOSが載ってる実機要るみたいよ 既に開発者登録を澄ませているユーザーならいけるかも知れないけど未登録だとXcode実行させる段階で詰むと思う >>204
昔、自作PCが趣味だったからそのめんどくささを楽しめてしまう。
Win自作PCが簡単になりすぎたからこそHackintoshは少しハードル
高いからおもしろいかなと。
パーツはintel CPU、マザー、GPUさえ動作済みのを選べば後は割と自由みたいだよ
開発用なら内蔵GPUのマザーでもいいし。
マザー交換できないノートならともかく自作PCなら主要パーツ選べるから
あんまり制限は感じない。
Ryzenは一部動くようになったけどいろいろめんどうらしい。intel CPUなら楽 >>204
中古Mac miniは少し考えたけど２年もしたらApple siliconが普及する。
intel Macはゴミになると書かれていて自分もそのとおりになりそうと思った。
intel MacはOS updateも長くない噂されているのも気がかり。
それならApple siliconの最安のMac mini買おうかと思ったらメモリ増設不可。
メモリ増やしたスペックで買うと割高になるしで計画中止w
いくらM1速いといってもメモリたったの8GB, SSD256で10万は割高ですわ
Hackintoshなら10万あったらRAM 64GB, NVMe SSD 1TBとかいけるし。
https://www.apple.com/jp/shop/buy-mac/mac-mini XamarinでAndroid実機でXAMLファイル修正してdeployすると
5秒以内で実機に反映される。
けっこう速いし差分だけbuildできてるように見える。
iOSだとbuild遅いそうだけど実機とシミュレーターとでどれくらいかかるものなの？
XAMLのファイル１個修正してbuild、みたいな小範囲の変更で。
>>207
VMware workstationも動かしてはみる予定だけど
仮想化だからかなり遅いんじゃないのかな
>>206
>>210 M1はメモリ増設不可で割安感ゼロ。intel Macは今後ゴミ化の恐れ >>210
M1が速い要素の一つはSoCで統合されたメモリだろ
ドリキンとかも言ってたけど今までのPCのは不効率だけどパワーを上げてなんとか速度を稼いでたがM1は高効率で少ないパワーでも速度を出せるっていうのが言い得て妙だと思った。
M1のメモリ容量は今までのPCの基準で考えない方が良さそう >>212
SoC内のメモリ速いのはいいけど増設不可で8GBは少なすぎでしょ
従来の1次キャッシュみたいなのを8GBにしたと考えればいい。
アクセス速度は落ちるけど増設可能なRAMも使えるようにすればよかったが
アップルが儲けるためにできなくされた。
iPhoneでmicroSDを使えなくしてるのとおなじやり口だよ
割高な上位モデルを買わせるためにRAM増設できないようにされた >>212
あとM1はメモリが違うから少なくても大丈夫っていうアップルの言い分だけど
完全に嘘だと思ってる。
そんなの使うアプリとOSが全部効率的なメモリ管理しないと実現しないし
ひとつの処理が大きなメモリを要求してきたらどうやったって足りなくなる。
性能3倍とかアピールも嘘だと言われてる。 >>213
16GBの使えよアホか
別にM1が完璧だなんて話じゃなくもちろん64GB全部使って処理するようなものなんかはまあ無理があるだろ
けど特に開発用途なんかじゃそういう場面も少ないだろうし今回のアーキテクチャがぶっ刺さる場面もまあ多々あるだろ
とりあえずバカはクソして寝てろ なんできれてるんだろ、Apple信者かな
M1は32GB以上の構成にはできないし
仮想化しようとしたら16GBにしたところで足りない。
10万以上出していまどき16GBはしょぼい。
開発者だからこそ仮想化を使う人が多い。 全員が仮想化使うわけじゃねーだろ さっきから用途によっては不向き言ってんだろマジでアホか
この手のバカがしたり顔でのたまってるのほんと嫌い 全員使うなどと言っていない
「開発者だからこそ仮想化を使う人が多い」と書いている
用途によっては不向き、当たり前
冷静に反論すればいいのにアホ、バカ連呼するから、アップル信者と言われる アップルが儲けるためにPAM増設できなくしたとか超短絡的な考えが面白いw >>222
儲けるため以外にないでしょ
信者脳だと真の理由に気付かないのかな
iPhoneがmicroSDを頑なに拒否するのも上位モデルをぼったくり価格で売るためだ。
M1でメモリ増設不可、SSD換装不可にしたのもiPhoneと同じ構図。
他社にはハードを作らせない、パーツ交換すらさせない。
アップルなら後付けRAM対応は今後もやらないだろう
MSが高速なARM SoC作ってほしい MSファンボーイの嫉妬かよくだらねーw
surfaceみたいなメモリ増設不可の低性能マシンしか作れないんだから期待しても無駄だぞw >>218
だったらグダグダ低脳理論で文句垂れてんなよクズ >>224
外部メモリ増設だとUMAの恩恵がない
別のメモリコントローラを内蔵しないといけないのでトランジスタ数がふえる
最初からメモリを増やすとトランジスタ数が増えるので歩留まりが悪くなるし検査工程も増えるので価格上昇
現状での落とし所だったんだろ
たぶん アンチ脳でiPhoneとかのアップル陰謀論とか信じ込んでる可哀想なやつw >>227-228
そんな性善説がアップルには通用しないですわ
下請け企業いじめたり、技術盗んだり、カネのためならなんでもやる企業 >>225
それは良いCPU作れなくなったインテルが悪い
高性能なWindows向けCPU/SoC作れないQualcommも低能 ID:AaN5oABb
最近Blazorスレでも頓珍漢な事を喚いて笑いものになったただの素人爺
MSのプログラマーに強い憧れを持つ なんでそんなに憎いに憎いappleのiPhone向けアプリ作りたいのかな >>232
そんなのスマートフォンアプリが儲かるからに決まってるでしょう
Xamarin使ってるやつはだいたいそうだろう
MicrosoftやC#が好きだが儲かるからXamarinでiOS/Android appを作るみたいな スマホアプリが儲かるっていつの時代の話してるんだ？
お前マジで聞き齧りの知識だけでプログラム板に書き込み続けてるんだな >>234
だれが儲からないっていってんだよ
YouTuberかなんかの受け売りだろｗ
儲ける奴は儲けてるよ
友人のエンジニアもかなりアプリで稼いでる 脳内の友人エンジニア出されても対応に困るわ
ここはお前のポエム語るスレじゃないから他スレに行けや >>229
完全に憎しみだけの思い込み論になっててワロタw アップルの悪口かいたらアンチが湧いてきた
アップル信者はわかりやすい アンチって何のアンチだ
Appleアンチはお前じゃないのか？ >>244
M1ならWindowsもMacOSも使えるってなると
ますます開発者がMacに流れてしまう >>244
>>245
いいかげん、Xamarinに関係ある話でお願い >>246
iOS app buildにMac OS必要なんだから
めちゃくちゃ関係ある話だ >>247
Xamarinスレ的には実機買えで終了だからあとはハッキントッシュのスレでやってくれ 248-249
244はHackintoshの話じゃないっての
おまえらOSとハード知識ゼロかよ
ろくにコード書けなさそう AaN5oABbのこいつxamarinに関係ある話ししろって言っといて、他から同じ事言われると…
書き込み見てると本人がハードとか分かってる様には見えんし^^; ここまでのレスを見ると...俺はAndroid StudioとUWPしか触ったことないけど、俺の方がまだ知ってそう。
なんでこんなにXamarinから遠ざかった話題で盛り上がっているのだろうか...。
Xamarinに興味があるのに何も伝わらねぇ。 >>255
Macでビルドできてないから前に進めてないんだよw >>251-255
なんで嫌いな俺の話ばっかりしてるの？
プログラミングの話できないレベルなんだろうけど
>>244とかアプリ開発やってたら興味深いトピックなわけだが
Hackintoshと区別つかない低レベルな人がいて驚いた いいからコテつけろよガイジ
何度もNGさせるな鬱陶しい >>255
C#ではWPFとかASP.NET MVCとかBlazor使えるし
Web appはDBとかバックエンド含めてゼロから作れるし
ハードの知識あるからサーバー組んでオンプレミス運用もできる
PHP, JS, Javaも経験ある
Xamarinは始めたばかりだが開発者としては中級以上
人の批判するなら自分でプログラミングに関連した話題あげたら？ >>258
Mac板はプログラミングできるやつほとんどいない
XcodeやXamarinの話をしたところでレスはない XamarinスレでMac買いたくない主張を延々とするわBlazorスレでXamarinの話延々とするわなんなのこのガイジ >>260
当たり前の事を自信満々に言われても…^^; >>260
じゃあ初心者の私から質問です。
Android JetpackってXamarinでも使えますか？
例えは...navigationとかってAndroid Studioの専用エディタが無いとナビゲーショングラフが表示されないと思うのですが、Xamarin環境でも表示されるのか疑問です。
ここらへんの事情が知りたいです。 >>255
でいきなりマウントとってきておいて
認識が間違っていても謝りもせず
今度は俺を利用しようとするような人間はクズすぎて相手にできない >>267
> 人の批判するなら自分でプログラミングに関連した話題あげたら？ Xamarinでどんなスマホアプリ作ったのか教えてよ
おそらく企業向けだと思うけど >>267
>俺を利用しようと
自意識過剰すぎて草生えるわ クズにまともに教えたところで感謝されることはないし
答えなければ、さらに不快なことをやってくる。
実際この態度だからな、>>269
予想通り
>>271
質問に答えさせる＝利用する、なわけだが？
失礼なことやったあとによく質問できるなとおもうわ
ずうずうしすぎる>>266 ID:/LlHv+1p
きんもーっ☆
プログラム板はこんなのがこんなのがぶわーっといるの >>260
むしろ、ここまでのレスを見るとまともな人達に見下されない方が不思議だし、お前のレスが特にそれを裏付けている
255のAndroid StudioとUWPの件はXamarinに関連する話だから別に変な反応ではないけど、それを経歴自慢と解釈したのか260で必死にXamarinと無関係なハード知識やオンプレ開発及びPHP，JSの経歴PRをしだす辺り草生える
Xamarin触ったことないから謎の対抗意識が芽生えちゃったのかな？
266の質問の意味がわからないなら素直に「Androidネイティブアプリ開発したことないからわかりません」って言えばいいのに。 まあ餅付け
変なのはNGするとしてとりあえずQiitaでトレンド入りしてたC#の良記事読んでよ
.NET 5 を使いたい理由6選
https://qiita.com/proprogrammer0/items/560ffaf99cdf828c8e52 昨日あたりからトンチンカンなイキリしてるやつの無能臭が半端なくて草生える >>276
技術的な話ゼロのおまえがいうな
おまえはからっぽだから技術的な話がふれずマウントとりたがる >>274
挑発にのって答えたらカスの思うつぼ
本人じゃないなら口出すなよ
おまえみたいなレスつけてたらずっとこの流れ終わらない XamarinとXamarin関連の話しろよ
おまえらずっと俺の話ばっかりしてる
俺のAppleの話のがまだXamarinと関連性があった 都合悪くなるとすぐ話逸らして逃げやがって…
お前がXamarinについて無知な事が証明出来たんでこれ以降は完全にNGするわ こいつ無能さを自覚してるから無能と言われると顔真っ赤にしてて草生える Xamarin.Formsだと.Netを選択出来るけど(2.1までだけど)
Xamarin For Androidだと.Netは選択できない
.net 6.0でFromsが統合されるそうだけど
Xamarin For Androidはどうなるの? >>286
Xamarin for Androidは重複する機能になるし新しいバージョンのリリースはなくなるだろう
セキュリティ関連パッチなど最低限のアップデートのみは
しばらくは提供されるパターンが多い。 FormsからiOSとかUWP除外したらいいだけじゃないの >>286
.NETってStandardのこと言ってるの？ 重複する機能ではないと思うぞ。
結局Formsの下回りはXamarin.Androidだから。
Formsに移行させられるなら別言語でいいってなるわ。
Xamarin.Androidが一番使いやすいのに。 Androidの役割するやつは残るんだろうけど、namespaceとか変わる予定なんだっけ？ AWSがmacOSをクラウド上で利用可能にする「Amazon EC2 Mac Instances」を発表 - GIGAZINE
ttps://gigazine.net/news/20201202-amazon-ec2-mac-instances/
macなくてもいいんだ。 >>292
クラウド経由で実機デバッグとかまともに動くのかな Xamarin Community Standup - .NET MAUI Update!
https://www.youtube.com/watch?v=5bK2ICHtMxo >>292
価格も分からないし、GUIが使えるかどうかも分からない。
Mac miniは8万円ほどなので、料金がよっぽど安くないと使いたくない。 >>295
[補足]
・8万円のMac miniを買えば何年か使えるし、トラブルも少ないだろうから、
それより十分安くない限りはそのようなサービスはメリットが少ない。
・高速な固定回線が前提になるが、それがそもそも年間6万円くらいは必要になるが、
それに比して十分そのサービスが安くなければ余り意味が無い。 iOSアプリを作る企業だったらMac実機とiOSが動く実機を買った方が良さそうだし、
そのサービスは個人のアプリ作家くらいしかターゲットに出来ないかも知れないから
よっぽど安くなければ意味無いかも。
iOS実機と言えば、やはりiPhoneとiPadの両方の実機でテストしなければ
企業が作るソフト品質には達しないと思われる。 >>292 >>295
そのMac EC2はiOS apps開発者にすらニーズはあまりなさそう。
スポットプライスで利用すれば安く使えそうだが、使うたびに利用の
手続きするなんて煩雑すぎて現実的じゃない。
EC2サーバーもMac Mini intel 32GBだしスペックたいしたことない。
これを多数のユーザーが共有してつかうわけだから速度もひどいだろう
EC2より安めのMacMini買って占有してbuildするほうがずっと快適なはず やっぱりiOS app Build環境のコスパ最強は
自作PCでHackintoshだろうな
RAM16G, SSD256GBくらいでいいなら3万円程度でも組めるし >これを多数のユーザーが共有してつかう
アホか
お前何も分かってないだろ Hackintoshを使ってないから知らないけど、PatcherのMacでXamarinペアリングビルドできなかったから多分イバラの道だと思う >>300
細かい料金システムは熟知してないが
クラウドの本質はおまえよりかはわかってるだろう
何もわかってないと否定してるのは
多数のユーザーの部分か？
共有してつかうの部分か？
否定してるなら具体的に項目や理由を書いてみろ >>301
Patcherって古いMacに入れるやり方？
それならハードが新しいOSのスペック満たしてないしできなくても驚きはない。
HackintoshはMacで使用実績のあるパーツで
比較的新しいパーツを使うことが多いから互換性はかなり高い。
ちゃんといれればセキュリティパッチもインストールできる >>302
普通はユーザー接続ごとにCPUコアやメモリは割当てられる
ひとつのインスタンスを多数のユーザーが共有するはず無いだろ >>304
やっぱりそんなレベルの話かｗ
CPU, RAMなどの重要なリソースを共有してるという
重大な事実を忘れるなよｗ
パフォーマンスに影響するのはハードウェアリソースだろうがｗ
それと「多数が」というのは「数人」でも多数だ
buildなんてCPU使いまくるから数人でも遅くて話にならない
契約上1-2core占有できたところで性能の絶対値が低い
Mac EC2とか使うのは情弱だけだと思うわ 多くのユーザーがハードを共用していれば
ハードリーソースは共有してることになる。
ストレージは容量でわけることくらいはできるが、他のユーザーの負荷の影響を受ける。
各ユーザーごとにストレージが用意されるわけでもない。
Ethernetなども同様
自分の契約で使えるRAMなどが決まっていれば
共有していないとかいう無茶な理論にはついていけない >>305
Amazonのデータセンターで何万台のサーバーが稼働してると思ってるんだ？
個人のサーバー共有とは違うんだぞ 彼の頭の中ではMacがポツンと1台だけあってそれをすべてのユーザーが共有しているとでも思ってるんだろう >>303
それ以前にPatcherだとリモート共有できなかった。論外。
Patcher作る側の動作確認不足なんだと思う 仕組みがわかってないんだけど
自分が契約して作った仮想マシンのリソースがフルに使えるのは他の人があまり使ってなくてリソースに余裕がある時だけってこと？
本体のCPUの処理能力が100だとして仮想マシンが1台あたり20×10台で全体のCPU処理能力合計が200だったりすると他でCPUが80以上使われてると自分のPCでは20の全力が出ないみたいな？ EC2のiOS以外のCPU、OSみたいにハードの増減自由自在なんじゃないの？ >>310
利用者側が細かいこと気にしても仕方ない
CPU負荷やネットワーク負荷に応じてデータセンターのロードバランサーがサーバー群に適切に負荷分散させるので(契約内容に相当する)スループットはほぼ平均化される
大手のクラウド事業者ならその辺りのノウハウは持っている >>307-308
こいつらアホ決定
AWS絶賛してるアホYouTuberと同類
AWS全体で何台あろうが関係ない話だ。
自分が利用できるリソースは
そのある1台のMac Miniのうちの一部のハードウェアリソースでしかない。
buildなんて数人同時すら重くて話にならない。
あと>>298でAWSのスポットプライスのことかいてる。
一応、AWSの料金ページくらいは見て書いてる >>310-312
AWSの場合はインスタンスで課金だから空いてても意味ない。
たくさんのサーバーを同時に使えば料金も跳ね上がるから、
実質的にできない。
光回線とかなら空いてる時間帯は快適に高速回線使えるが、
AWSはそういうことにはならない。
>>311
そもそもBuildだから技術的に複数サーバーまたがっての動作はしないだろう。
コンパイラが対応してない。
仮にできたとしても上に書いたように料金面で不可能 >>313
ユーザーごとに別のMacのインスタンスが生成されるのがまだ分からんのか
複数のユーザーであればそれぞれ別のリソースが割り当てられる
同じリソースを使い回すのではない
具体的な割り当ては>>312の通りどのサーバーか流動的なので多数のサーバーが利用される >>315
だからそんな契約の話でなくて
CPU1個をまるまる使えないから遅いだろって話だよ！
BuildはCPUリソースを使うわけだから
あるCPU１個のうちのコアの「一部だけ」をひとりで使えても意味ないの。
遅すぎる
なんでこんな基礎的な話がつうじないのか
ハード知識ゼロすぎだろう 例えばｖCore x8, 16GBで
Linuxでc5d.2xlargeだと24時間で11.52ドルもかかる
これならMac買った方が安いに決まってる。すぐ元が取れる。
Macだとハードが割高だからLinuxより高くなるはず
>>317
それapplication serverとかでしょ
buildはCPUリソースがっつりつかうから
安いプランでは３年前の中古Macにすら勝てないと思う >>318
Amazon Linux 2の話だけどRocketChatってNode.jsのチャットサーバーのビルド結構速かったよ。 AWS は、普通の共有サーバーみたいに、他人の影響は受けないだろ
Linux のcgroup とかで、リソースを分割してるから。
他人のリソースを使えないだろ
例えば、vCPU 1個の契約なら、絶対にそれだけ。
他人のvCPUを使えない
コンパイルなら、20分掛かる。
vCPU 4個なら、5分 サーバー用のx64/x86コアならXeonで18C/36Tや28C/56Tの様なCPUがある Mac EC2はIntel Mac Miniの32GBだからスペック高くない
Linux EC2よりはるかに性能は落ちるは間違いない
それでいてハードは割高なAppleだから料金はそう安くもならないだろう
EC2ならMac買った方が得という結論は変わらないな
>>320
20分は耐えられないわ
例えばAndroidで動いたらiOSでも問題なく動くというなら
MacOSでのbuild少なくて済むからいいけどそう甘くはないだろうし >>318
>Linuxでc5d.2xlargeだと24時間で11.52ドルもかかる
>これならMac買った方が安いに決まってる。すぐ元が取れる。
そんなに高いのか。
そりゃ駄目だわ。 大体、EC2 1つで、月1万円ぐらい
だから、Lambda みたいな必要な時だけ動かすようなものを勧めている >>322
こいつ、また薄っぺらな知識で大層な文句垂れてるのか
そんなの利用携帯とかで料金いくらでも変わるだろ
クラウドは結局えんえんとつ買い続けるなら実機の方が安いけど、短時間などしか使わないなら割増料金になっててもトータルコストやイニシャルコストは安くなるかもで基本はまあ変わらん >>323
具体的な金額出したらやっと納得してくれる人でてきたか
>>326
計算できないアホ？
短期間でもMac EC2のが損するっての。
8万円のM1 Mac Miniの3年後に３万円で売ってリプレースする場合
のコストは年間あたり16500円程度でしかない。
>>318 の例だと１日1150円かかり、たったの14.34日で
Mac Miniの所有期間コストを超えてしまう。
週1時間しか使わないような趣味プログラマーさえもEC2のが損する。
しかも実機M1 Mac miniよりはるかに遅い。 この手のバカって勝手に自分に都合の良い数字を仮定して計算して悦に入るんだよね >>328-329
M1 Mac miniの３年後売却価格から１年あたりの所有コスト計算してるだけなんだが
やっぱりバカには理解できなかったようだ
これだけ詳しく書いてもわからないとはそうとう知能低そう
ちょっと計算すれば利用日数が少なければ借りるほうが得ってのが
思い込みだとわかるんだが
やっぱりクラウド絶賛してるやつってレベル低い またオンプレ爺が暴れてるの？
こいつ昔の経験に囚われて新しい知識全く吸収しようとしないんだよな
結構いい歳だろ50代？ >>331
新旧の話じゃない
コスト計算できないかオンプレミス構築、運用するスキルが
ないからクラウド絶賛してしまう。
無能にとってはクラウドは救世主なわけ
新しい知識を吸収しないのはクラウド絶賛のやつらのほうだ
自分でできる範囲が少ないからクラウド頼み
フルスタックでやるほうがよほど学習量は多い おまえらだってスクリプトしかできないフロントエンドの奴らに
C#バカにされたら腹立つだろｗ
C#古いだのdisってるYouTuber多いぞ
>>333
すぐ上にいただろう、331とかな
バックエンド構築、運用のスキルない雑魚のくせにオンプレミスに
対応できる人をバカにしてるっていうね
フロントエンドのやつらにそういう奴らが多い クラインババアのまんこのにおいくんくんくんくんくん…ガクッ（窒息して死ぬ音 >>330
このバカ前提が間違ってることにまだ気づかないのかw
老害は逝ってどうぞ >>336
ホントお前は人の話を全く聞かず、自分に都合よく解釈する嫌なジジィだな
会話が全然成立しないからリアルでも敬遠されてるだろ？
還暦迎える前にその癖直せや >>339
人の話をきいてないのではない
論理破綻に気付かないほどおまえの頭が悪い
知識とスキルは
何もできない人＜クラウドがないと開発できない人＜オンプレミス対応できる人
クラウド頼みでいきってるやつはWeb APIもまともにつくれない
つくっててもFirebaseとかザコしかつかえない オンプレミスできてクラウドも言える人は強いと思うけど、オンプレミスしかできないってのはただの老害だろw
どの技術も範囲が違いこそすれ深掘りの余地はあって範囲の違いを持って優劣つけるのとか愚の骨頂だろ
松本零士の「この武器こそ最高なんだ！」とか言ってる漫画の人みたいだわ な、全然噛み合わないだろ？ｗ
クラウドの高速進化に追いつけないからオンプレにしがみつくしかないのよ
完全に会社のお荷物だよこの爺さん しかもこの爺さんBlazorスレでXamarinの話ばっかりやるし
頭おかしいだろ >>341
ねえコンテナって知ってる？
デプロイしたことある？ ていうかこの人クラウドはPAASやSAASしかないと思ってんとかな AWSの初回一年間の無料枠でいろいろできるからとりあえずやってみたら良いのに >>346
Docker使えるくらいで自慢したいって相当レベル低いな
Dockerはインフラ得意な上級者ほど嫌う
自分の開発環境では使わない
副作用あるから >>342
オンプレミス対応できるのにクラウド使えないやつはいないだろ
設定のハードル低くして無能でも始められるようになってるんだから でも話聞く限りAWSもGCPもやったこと無いよね。
この手の人は誰に何言われても絶対やらないから
やればわかることが永遠にわからない Dockerはローカル環境を汚したくない時にこそ使うけどな
仮想環境とクラウドをごっちゃにしてないか？ >>349
Dockerでイキってきた人、お爺ちゃんが初めてだよ
クラウド上でコンテナ扱った経験は無いんだねOK
で、デプロイは？単語の意味は分かるかな？ 副作用って何だ？
諸般の事情でマシンに直接構築せざるを得ない状況が多いが、その副作用を無くしたくてDocker使いたくて仕方ないぞ。 >>354
オンプレミスで開発・運用やってる人に
その質問をすることがどれほど馬鹿げているか気付かないわけね
deploymentしなければ仕事にならない
deployの意味もおまえが考えてるのは間違ってる。本来はもっと広い意味をもってる
レベル低すぎ
発音も「デプロイ」ではない。
>>355
副作用知らずにDocker使うとか意味わからん 俺への質問ばっかりになっててめんどくさい
無視せずにまじめに答えてしまう俺もわるいんだが
今日は忙しいしレスひかえる
いいかげんXamarinの話しろよ >>356
具体的に害のある副作用教えてくれよ。
少しパフォーマンスが落ちるとかそういう部分じゃない所を是非。
もちろん、オンプレ上にDocker建てるのが前提な？ まあ大体把握できたからもう何も答えなくていいよ
お爺ちゃんはずっと中小企業向け案件担当してきた人で最新技術に触れる機会も必要性も無かった
今はそれらシステムのメンテと追加開発案件で食べているんだろうね
それはそれで幸せである意味実に羨ましいエンジニア人生送ってるなあと思う オンプレでハードのセットアップから含めてインフラ構築できるとかってのは一つのスキルかもしれんけど、その辺すっ飛ばしてクラウドでIAASやらPAASやら組み合わせて動くシステムを素早く生産性高く作るってのはまた別のスキルで、そんなのはIT関わってりゃ普通わかると思うけどね
アセンブラできるやつと関数型わかるやつは違うしDirectXでゴリゴリ作るやつとUnityでVFX使いこなすやつもまた別。
まあオンプレのスキルしか身についてない老害だってのは話せば話すほど透けて見えるからある意味可哀想 >>356はオンプレの経験あるってどの規模のオンプレなの？
零細企業だとサーバーの選定とか、データベースの管理とか色々一人でやったりするけどその程度じゃないよね？
要は自作に毛が生えた程度の規模だったら笑う >>362
オンプレミスでやっても慣れてればたいして時間かからない。
おまえらはRDBとかapplication serverの設定に何時間もかかる無能なのか？
あとオンプレミスといっても決済機能とかは普通に外部のサービス使うぞ
なんでもゼロからつくるわけじゃない
知識あれば楽に構築・運用できるDBとかAPP serverは外部に運用を
任せない。
性能落ちるし維持費高いしろくなことない YouTube に動画を上げてるクラスメソッドは、すごい
全社で、AWS 資格を800。
全12資格を取った、マスターが7人いる AWS ソリューションアーキテクトは、遂に、Ruby on Rails を超えて、頂点に立った！
年収1,500万円
Rails 1,300万円。
Node.js 900万円
たぶん日本でも、500万円以上はもらえる
Amazon の時価総額も、150兆円。
不況の金余り・株高で、たぶん、500兆円ぐらいまで上がりそう 従業員数1万人2万人以上の大企業はNさんとかIさんとかFさんに大金払ってオンプレ運用
それより小さい中小企業はAWSとかGCPのVPC運用でやり繰りする感じかな
業務システムに大金払う企業少ないよね >>364
その調子だと「Dockerの副作用」とやらはオーバーヘッドという主張かいな？ ベンチャーでは、AWS, Ruby on Rails, CircleCI, Capistrano の組み合わせが一番多い
Docker は本番では使わない。
本番では、Kubernetes みたいなオーケストレーション
素人には、AWSのお勧めは、マネージドのLambda, Fargate
玄人には、CloudFormation で、
Terraform, Ruby のKumogata, Cookpad 製のItamae などを使える人は、EC2
CentOS 系のAmazon Linux と、MySQL 系のAurora の組み合わせで、数倍速く改造してる 何これオンプレスレ？
てか、隔離スレ作ろうか？
staticおじさんと同類の匂いがするんだが。 スキル無い爺さんは口でマウントとらにゃ生き残れんから大変だな
一緒に働いてる人達が気の毒すぎる
>>370
お願いしてもいい？助かるよ >>370-371
クソスレ立てるなよ
立てても誰も書かない
>>369とかのRailsおじさんはどのスレにもでてくる
おまえらみたいに技術の話しない、できない人が
人物批判をしてるからいつまでも終わらないということに気付け
Xamarinの話しろといっても誰もしない
Xamarin使ってない人ばかりが書き込んでる >>372
お前が香ばしい発言繰り返してるから終わらないんだよw もともと過疎ぎみのスレなんでね
そもそもM1にしろEC2にしろやってみてどうだったって話を投下する人が一人でもいれば建設的な話が進むのだが 遡ってみたところ、XamarinスレでmacOSがawsで使える！って書き込みに食いついたのはオンプレおじさんだった オンプレ爺さんって話している内容が薄っぺらで何処か微妙に的外れなんだよな
本当に開発経験あるのか？ >>375
ガッツリ開発してるわけじゃなくて情報収集のために見てるだけなんだ……
すまんな 常識的に考えてギブアンドテイクだろ。
余計な調査やトラブルを避けて開発効率考える人はMac買って開発するだろうし新CPUも避ける 米軍からチョコレートもらったお礼にジープ乗り逃げするんだろ お前の欲しい情報が得られないからといって悪態つくのは荒らしの考え方だぞ >>383
まあ、確かにそういう意味にもとれるよな。 今日も安定のXamarinの話ゼロ
Xamarinインストールすらしたことないひとが50%超えてると思う
おれは多少はつかった。来年から本気出す
Xamarin.FormsもFlutterも本気でやってるやつはかなり少なそう 使ってるぞ
phonewordってプロジェクトを実行してる 5月にビルド&実行できてたUnoのプロジェクトが今はエラーが出てビルドできなくなってた。Uno上げたらテンプレートが割と変わってた >>389
ずっとxamarin使ってるけど、いつもそんな感じやで。
バージョンアップの度にビルドできるかヒヤヒヤしてる。
unoがxamarinに依存してる時点で、オワコン臭しかしない。 >>387
案件で普通に使ってるぞ
ネイティブの方が変なレイヤー噛まないとか軽いとかいいとこもあるかもだけど大きなトラブルもないし今んとこ他の選択肢ないわ Xamarin.Formsは使わずにXamarin.AndroidとXamarin.iosで
MVVMでいうところのModelとかUtil系とかだけ共通プロジェクトにして開発できる？課題とかある？
画面に近いところだけはそれぞれの文化にのっとってつくりたい >>394
全然できるよ
ちょと最近の各スマホのUI追ってないのでMVVMなりのVMより上と下のUIの連携がいい感じにできるのかわからんけど3-4年前にMVVMCross使ってた .Net6.0ってXamarin.AndroidからもXamarin.Formsからもちゃんと移行できるの? .NET6まだ出てないんだしだれもわからないが
Xamarinの進化系だし自動移行は無理でも
大半のコードは使いまわせるだろう .NET 6からVSCodeでも開発できるらしいからそれが一番楽しみだわ
Visual Studio for Macとかいう粗大ごみさっさと捨てたい iOSデザイナ開発中止になったんだな。
最高の開発環境はXcodeです みたいなメッセージ出てきてワロタ。
今まで一度もまともに使えたことなかったから影響ないけど。 Xamarin、結局デザイナの恩恵に預かったこと一度もねーわ xcodeのデザイナーも使いにくいよな
せめてボタンの上でツールチップ出してくれ、ボタンの機能が分からんw Xamarinは、いつ使ってもどこかがおかしい状態が続いてたけどさ
そうしているうちにKotlin Multiplatform Mobileが伸びてきて、こっちはまともに動いてるっぽいな
https://kotlinlang.org/lp/mobile/
こりゃ、まともに動かないまま完敗か・・・・？ それは共通のUI Frameworkがない、xamarin android,xamarin iosみたいな感じじゃない？
xamarin formsに当たるのが
https://www.jetbrains.com/lp/compose/
こっち?
コアとなる部分はjetpack compose?でgoogleが気合いいれてやってるから品質は問題ないんじゃないかな つか、コアとなる部分はjetpack composeかはよくわからん
全く知らないので Kotlin Multiplatform Mobile
https://www.statista.com/statistics/869224/worldwide-software-developer-working-hours/
KMMはここみると利用率2%だから人気ないのかと思ってたけど
もう安定して使えるレベルなのかな？
Xamarinの利用率が激減してるのが気になる。バグが多いからなのか？ やる気ないからflutterにとられてる
https://github.com/flutter/flutter/wiki/Roadmap
来年のロードマップが発表されたが、今年は17000のissueを解決
xamarinより数倍近く人的リソース割かれてそう Our goal for 2021 is to deliver production-quality support for Web, macOS, Windows and Linux
はよ、windowsアプリに対応を それにしてもFlutterやKotlinは思っていたより強敵だった
動くかわからないパッケージが揃っているよりも、自分の好きなC#言語が使えるってことよりも、まともに動くことの方が重要だった Xamarin 始めようかと思ってのぞきに来たけど、
そんなにひどいのか
学習コスト高めで避けられてるだけかと思っていたが、
ちゃんと動かないのはヤバイね Xamarin Formsがバグ多すぎるし、唐突に致命的なバグが増えたりもするから
バージョンアップも命がけだわ、もちろんチェックはするが
TabbedPage使ってるアプリが全滅するような致命的なバグをもう4カ月も放置
https://github.com/xamarin/Xamarin.Forms/issues/11809
なんなのこれMicrosoftどんだけやる気ないの microsoftはxamarinを買収してもっと人的リソース投入してxamarinがMicrosoft品質になるかと期待したが、ただ無償化して放置
mauiもただのリブランディングっぽさそうなので期待するだけ無駄そう >>412
iPhoneアプリで使ってるがビルド出来なくなるとか普通にある。
その場合はVSとmacのVSとXcodeのバージョンを下げるか、1月くらい先に修整される事をひたすら祈る。
デバッグも気まぐれでブレークポイントで止まらないときもある。その場合はwindowsとmacを両方再起動する。
昔はブレークポイントをかけた行で止まってくれなかったが、最近は少しマシになってる。 >>413
6-7個案件で使ってるけどあまりバグにハマったことない
そこそこ大きいアプリかなとは思うけど
まあバージョンアップで動かなくなるとか挙動変わるはあるね 作ったプログラムそのものは変なバグは出ない
ただ、Xamarin.Formsはデザイナーがすぐに転けるのと、ラジオ釦とか結構重要なパーツがさくっとバージョンアップでデザインが変わったりするのが困る >>412
デプロイ王子まで投入されたCOCOAはどうなりましたか？ Xamarinじゃなければもっとダウンロードされたのに Xamarin.FormsもMS支配下のMAUIになったら品質もよくなるんでは？
MonoでLinuxでASP.net動かせると言ってた時代は
バグだらけでbuildすら通らないとかザラだったけど
MSのもとでASPが正式にLinux対応したらふつうに動くようになった >>416 >>417 みたいに、使えてる人もいるんだね
バージョンアップはスルーしちゃいかんのかな
デザイナーがダメなのは WPF で諦めたから気にしない
XAML手書きで十分
ちょまどやデプロイ王子はプロダクト作ったことないんじゃね？ >>424
バージョンアップはまあ必要な時はやらないと。
基本ギリまで上げないけど、バグがその先ので治ってたり最近だとダークモード対応とかで上げた方がええなってのがあった。 デプロイ王子はCOCOA作っただろ
ちょまはMS入ってからはないんじゃ？少なくとも。けどそもそも入ったきっかけがその前の会社でザマリン使っててMSの中の人の目に止まってスカウトって話だった気がするから当時は製品には関わってたんじゃないの知らんけど ちょまどの名前を口にしてはいけません
必ず荒れるから・・・ Xamarin関連のところでは、ワンソースマルチプラットフォームは全て上手くいかないとかいうのが定説だけど・・・・・
周りを見渡せば、JS系のもFlutterもKotlinもC++系のもみんなちゃんと動いてるじゃねえか
あ、ちょまどかわいいからXamarin最高！ クロスプラットな開発環境を用意するには膨大なリソースが必要
中途半端な中小企業が手掛けるから品質が維持できない
xamarinはもちろん、qtしかりfiremonkey(delphi)しかり...??
ただそれだけのこと モバイル開発で今まで一番出来がいいと感じたのは
Adobe Airかな
フラッシュと一体化されてて、動きものがすぐ作れたし
iOsとAndroidと何も変更しないでさくっと動いた
ただ、儲からないからってあっさり放り投げられてしまったけど・・・ ちょまどさん見てて分かったんですが。
女はなぜDV男が好きなのかって命題があるじゃないですか。
あれ、女がDV男を好いてるんじゃなくて、男にDVさせる女がいるんじゃないですかね？
だって、ちょまどさん見てたら殴りたくなってきますし。 >>432
別にXamarin動かないって話じゃねーぞ？
上でも言ってるようにXF自体にバグが出たりビルドなどでよくわからんエラーが出ることもあるけど今んとこ次の開発でも使う気満々だわ
AdobeAir やFlutterみたいなアプローチはネイティブコンポーネントにアクセスしづらいから特にWebビューとかでハマってることも多い。日本語入力とかな
MSがすごい気合入れてる感でもないところはちとアレだがな 外からじゃ内部の開発体制全くわからんが、xamarinとmauiで何か開発体制変わったの？って感じ これが変わらなきゃ、また、xamarinと同じ品質のものがでてくる >>437
MAUIになると
開発のトップがMicrosoftの人になり、
品質の管理がMicrosoftになり、
開発者の大部分がMSの人になるんじゃないか？
間違いなく、品質は上がるでしょう
すでに書いたようにMono時代に比べてMSの支配下になってから
ASP.NETのLinux対応は格段によくなった。 そこらへんはやる気見せてたような
.net standard策定や.net coreの開発からのasp.net coreやentity framework coreはマルチプラット対応するき十分伝わってた
でも、なかなかUIフレームワークの話は一向にでてこなくて、直前にsurveyみたいのやってたが、あれで決めたの？ .net 5で完全にハブられたXamarin君かわいそう Kotlinのクロスプラットフォーム向けのKMMはNetflixが採用のようだ。
Netflix効果でこれから人気出るかもしれない。
C#のMAUI
KotlinのKMM
どちらも期待
>>440-441
GUIまわりはプラットフォーム依存が大きいし開発も大変。
nativeが後回しになるのは仕方ない ぶっちゃけもうモバイルアプリの開発は無理になるまでザマリンでいいや
Unityとか機械学習とかRustとか他にやることあるし 機械学習は本格的にやらないのなら、大した覚えることはない とは言ってもこういう時にはこれ使ってこうやって環境とかデータ整えてーとか分かんねわ。
今日も動画から3dポーズ認識に深層学習使って良い感じにしてるやつみたけどそこまでいかなくてもこれこれこうだったらホゲホゲでいけんじねゃね？ってぐらいには理解したい しかし開発中にビルドが異常に遅くなったり、ビルドキャンセルもできなかったり、実行出来なくなったり、しょっちゅう再起動なのだが、プロジェクトが悪いのか？ >>447
あんまそういうのはないかなー
Androidだとデプロイする時にOutofNemoryとかJava関連のなる時あるけど Googleには、マルチプラットフォームツールキットとして、
Flutter(Dart)とKMM(kotlin)の二系統あるのか。
それに加えてGo langがあり、Javaもある。 Unity Cordova Monaca Cocos UE4 >>451
ちなみに、MonacaはCordovaを使ったブラウザ上の開発環境(IDEなど)。 xamarin.forms はビューワーがすぐにコケるのはなんとかならないのか あれだけの注目プロジェクトでMSも噛んでいてこのザマとか、一体誰だったらxamarinでまともなアプリ作れるんだろうか アップデートでバグ入れたんだから開発管理してる奴らがクソだっただけ 悪いのはXamarinということでなければ納得できません Ｘａｍａｒｉｎでやると糞人材が寄ってくるということ >>468
お前が何のエンジニアか、そもそもエンジニアなのか分からんが、お前が人格破綻者なのは分かったよw MSのAzureベンダーロックイン狙いが裏目に出ただけだからXamarinはセーフ？ 国が発注した金額は3億超で
改良を引き受けた企業が受け取ったのが1600万円とかだからベンダーロックインすら関係ない ごめん
国が支払ったのは3億要ってなかった
国の支払2億9448万
開発会社が受け取ったのが1615万 正直、いくら保守費用込だと言ってもこんなクソアプリを3億かけて発注する側も頭おかしい。
妥当な金額はリクス込みでも1000〜2000万だわ。 ココアの開発、MSの人が開発にかかわったわけじゃないのか？
>>473-474
よくその数字見つけてきたね
中抜きがひどいな
電通とか竹中、パソナが間にはいってごっそりピンハネしてるんでしょ？ ホリエモン・KENTA などが言う、
中抜き会社は、社会でもっともいらない存在
大量の貧乏人を作り出しているだけだから
反日・韓国系のNHK・テレビ局などの流通経路の独占は、
下請けの給料と、製品の品質を下げるから、もっともいらない独占 >>476
受注したパーソルって会社が既に人材派遣会社
そのくせ自分のところの人員に開発させずに、下請けに出してたんだよ
このスレでもパーソルの派遣を使ったことある人いるでしょ 中抜き世界一の日本だけあるな。
能力ない会社に任せる政府が悪い。 >>473
HER-SYSの開発運用費用、約1億2000万円も込みらしいぞ
COCOAにしてもサーバ側の開発運用費もあるだろうし
だとしても厚労省&パーソルが粗末な仕事しやがった事実は覆らないが
そもそもHER-SYSの方も巨額を費やしてひり出したそびえ立つ糞の山だからな >>476
OSS開発者のはずデプロイ王子に納期と仕様変更強制できるのって誰だよ、って話
MSのAzure関連部隊の不始末であってXamarinは関係ない。 だからXamarin程の糞はないって3年前から言ったろ？ Xamarin のせいじゃなくて、単にバグってるだけだろw
マルチプラットフォームじゃなくても同じことをすれば同じことが起こる Xamarinを使っただけでバグが量産されまともに動くアプリを作ることすら困難になる >>487
いやこれは本当にXamarin.Formsの設定保存クラスのバグっぽい。 やっぱりXamarinのせいじゃねーかｗｗｗｗｗｗ よくわかんねーがそもそもそれ2行目と3行目の間にすっ飛んだらって、しょうがなくね？そこまで問題ないようにとかいってたらエラーハンドリングコードが9割ぐらいになるぞ？ 斜め読みしかしてないけど、そこで解決策ってやってるのは単に元ファイルをとりあえずどっか逃してるだけで、だったらtmpファイルで良くね？
tmpをさらに誰かが消しちゃうとか？ >>493
そもそもこのコード自体がtryブロックの中じゃないか……全然関係無いぞ
atomicに行うべき動作がatomicにできてないのが問題 途中で落ちても元ファイルかtmpのどちらかは残るようにしてるのに読む時はtmpを見てないのか
これをコードレビューで見逃すのはちょっとなあ…
まあせっかく数千万人の日本人無償テスターを確保できたんだから存分に使い倒してXamarinの品質上げてくれ これでもう完全に終わりか
ちょまどに転ばされデプロイ王子に叩き潰され最後は自分自身のバグでトドメを刺された いや、11月には終わるけどな
順調にいけば.NET 6に統合されてお終い >>496
他の箇所見てないけど、一発でやるオーバーライトみたいのがないからtmpを作成後、オリジナルを消してtmpをオリジナルとして保存で、それ以外にやりようなくない？
間違ってたこといってたらすまそ >>500
ジャーナリングのアルゴリズムをどう設計するかだけど、俺が設計するならオリジナルがないまたは壊れてたらtmpを採用、両方正常ならオリジナルを採用、両方壊れているってのはアルゴリズム上はあり得ないけどフェールセーフで初期値って感じにするかな？ >>500
https://github.com/xamarin/Xamarin.Forms/issues/13676
原因を突き止めた方はAndroidのSharedPreferencesを参考にした解決策をXamarin.Formsに提案してるね Xamarinの問題じゃなくてファイル更新のアプリ側実装の問題でしょ。
Androidはアプリがバックグラウンドに移された時の処理が独特なので、処理途中で例外発生は割とある。ちゃんと拾えば安全だけど。 Xamarinさえ使わなければこんなことにはならなかったのにかわいそう
Xamarinが無ければ世の中はもっとより良い場所になる >>504
コミュニティの議論を見る限りライブラリのメソッド実装の問題のように見えるがな >>501,502
今のままでファイルがなくてtmpがあるならそれをリネームでいい気がす
ただそれ、原因突き止めたってよりもこれなんじゃないかなーというかここしかない…かなーって感じなのでは
正直2と3の間でターミネートされるとかレアもレアなんちゃうの
元のバグがどんぐらいの頻度で起きてるのか知らんけど。なんか筋悪な予測な気がするんだが 別プロセスにファイルロックされててファイル置き換え失敗とかいうオチはないかな？ >>507
「ここしかない」まで示せたなら十分じゃないの >>507
tmpリネームだとリネーム中にterminateされたらと考えたけどそこのトランザクションは流石にOS側で保証されそうね。
確かにあのバクレポートのピンポイントのタイミングは確率的にそうそう発生しないように見えるけど、I/O待ちが入るのでOSから見ると絶好のterminateタイミングなのかもしれない。 Xamarin側の不具合なのか、開発チームが責任のバグなのか、
まだ確定はしていないってこと？
フレームワークのバグが多すぎると
クロスプラットフォームのフレームワーク使わないほうが
時間もコストもかからない、ということになってしまうな >>511
それが答えだよ。
それぞれのプラットフォーム依存言語の実装を調べてさらにマルチプラットフォーム言語を調べるわけだけだから、結局２度手間なんだよ。
もっといろんなプラットフォーム依存言語が出てこないと、マルチプラットフォーム言語を使うメリットが乏しい。 だから３年前からクロスプラットフォームは総じて糞
その中でもXamarinはキングオブ糞って言い続けたろ？
俺様大勝利 >>509
いやここしか無いんじゃないか、ってのも推測に過ぎんからね
>>511,512
それ言ったら他人の作ったライブラリも一切使えないって話になるだろ
まあややこしいことしてるからアレだけど、案件でいくつか使ってたけど特にうちのやつは画面数ひたすら多くて挙動も共同なのばかりだったからクロスプラットフォームの恩恵非常に受けてるわ
こんなの二つ同時に作るとかしたく無い。
COCOAだったら別に作るとかはまあアリかもとは思うけど >>517
二つ同時はコツをつかめばわりと簡単。
三つ四つになってくると流石にきついけど、きついのはXamarinの中の人も同じ。 ↓全ての人生を実況に費やし、晩年に差し掛かり、もう何も残ってない >>518
いや業務寄りのロジックがムッサ多いから
別々に作るのは避けたいのよ ∧＿∧ ／￣￣￣￣￣
（ ´∀｀）＜ オマエモナー
（ ） ＼＿＿＿＿＿
｜ ｜ |
（_＿）＿） >>522
こいつの世界における存在必要性皆無すぎない？ Xamarinに費やした時間をもっとマシなことに使っていれば
もっと市場価値高められたのにな
残念ｗｗｗ Xamarinの品質とそれを隠したい人が露わになっていく……
https://togetter.com/li/1667874 俺様の勝ち！
Xamarinエンジニアは俺にごめんなさいしなければならない ta@台北 @ta1nakamura
COCOAはMSのXamarinっていう開発環境で作られていて、MSが威信をかけてサポートすると思ったんだけど（厚労省もそれを期待？）全然そうしなかったってことはもうXamarin普及は諦めたという事では
むけえだ @mr_mkeeda
cocoaのAndroid版、9月からバグってて機能してなかったは残念すぎる。協力したくてもXamarinだから分からんのがな…
みょうが @mrkn
Xamarinは使ったことがないから良し悪しについて何も分からないけど、COCOAの不具合の話を見てると絶対近寄りたくないフレームワークだなと思ったわ。通知の不具合とか永続化データの謎リセットとか、謎のフレームワークを挟んでなかったらすぐに解決できるんじゃないの？
ENDO Yasuyuki @eyasuyuki
COCOAはXamarinだったので誰も手伝えなかった。オープンソースにする意味があったのだろうか。
ねこ吸い @8796n
AndroidでもiPhoneでもどっちでも使えるフレームワークのメーカーが実績作りたくてぶち上げたけど結局悪評だけ残ったみたいになってるな
sokaye @soakaye
COCOAデザインミスだよな。
Xamarinである必要ないもの。
そもそもメンテ会社が、ってのは置いておいても。 なまじ別ターゲット向けコンパイル通っただけで大丈夫と思ってしまう錯覚を誘引しやすい。クロスプラットフォーム環境だと特にそう。
信頼できないものを信頼できるかのようにみせてしまう。 Kunio Okita @okitan
まぁでも COCOA って正直、そんなに難しいアプリではないとは思うけど、xamarin とかクロスプラットフォーム系のやつを選んじゃったのがものごとをものすごく難しくしてると思うんだけどね。。
Satoshi Kato @katoSat
オレも好きだから、昔からいくつもwのクロスプラットフォームな開発環境で、Windows/Mac両対応なアプリ両手に余るぐらい作ったことあるけど、やっぱ保守がガンになりがちなのは確かだわ。
Masanori Kusunoki / 楠 正憲 @masanork
接触確認アプリはAzure Functionsを使ったシステムだったので、ぶっちゃけAWSと比べてエンジニアを見つけるのも難しかったはずだ。XamarinもAzureも、Swift、Kotlin、AWSと比べてエンジニアが少ない。ましてやEN APIに精通したエンジニアはほぼおらず担当してから勉強することに
( ﾟ∀ﾟ)o彡ﾟチキン！チキン！ @kitamurahisao
cocoaでxamarin採用したの良くなかったと思う。swift、kotlin、awsで構築してればエンジニアのアサインも容易で、発注価格ももっと安くすんだ気がする。
厚生労働省の役人はこの辺の事情分からなくても仕方ないけど設計と提案持って行った会社のミスよ。
もっさりさん @TeamMOSA2
COCOA接触感染アプリの話を聞けば聞くほどなんでXamarinの必要性があるん？ってなる。
サンドボックス内の保存方法もEN APIも異なるのにボタンとリスト程度が乗ってる画面のためだけにXamarinって正気をうたがう。 ケイバリュエーション(鈴木健治) @info_kvaluation
@keiji_ariyama 私は、Cocoa-logをiPhoneのとAndroidのと見比べて、iPhone側の不安定な処理（許諾等確認、zipダウンロード済みのチェック、ダウンロード）を安定化させるには、iPhoneとAndroidで最初から別に書かないとだめそうかなあと予測しまして、そうするとXamarinはエラー特定面でデメリットのみかなあと。
ARIYAMA Keiji @keiji_ariyama
@info_kvaluation ネイティブで開発しなおす。オープンソースで開発を推進する。診断キー配信サーバーとのIFを定義して、本番（HER-SYS?）側は厚労省側の人に実装してもらう（通常はモックサーバーと通信する）
喫緊の不具合修正はしょうがないとして、次の段階でXamarinを捨てることを決断していただきたいです。
ケイバリュエーション(鈴木健治) @info_kvaluation
COCOAがXamarinを捨てるべき理由として、いま通知サーバーからzipをダウンロードしたかどうかを何時何分までのzipをダウンロードしたかという記録と照合で行っていて、1件1件のトランザクション管理になっておらず、
重複したり、飛ばしたりの不具合が発生している（iPhone）。
ケイバリュエーション(鈴木健治) @info_kvaluation
これを1件1件照合したかどうか記録・管理するように直すのはほぼ全面書き直しで、しかもiPhoneはiPhone向けに独自に書かないといけない。Xamarinで統一コードを書けず、Xamarinのデメリットだけが残る。
テストが複雑で、不具合の検証が数段階深くなってしまう。
ケイバリュエーション(鈴木健治) @info_kvaluation
しかも、COCOAのもとになりそうなiPhone向けのコード、Appleが書いて公開済みなのだ。それに乗っかるのが一番ミスが発生しない。品質を管理したければ。 Xamarinで開発工数減るとか言ってたやつｗｗｗ Naoki Kuzumi @kudzu_naoki
Xamarin関係ねーだろと言ってたらiOS版はXamarinのバグだったくさいとか出てきてMSが本当に関わりを持たざるをいけなくなってるのか。
V層もどき @desuga_NlkL5EiN
この手のバグ、Xamarinがあまり使われてないというのを示唆してしまってますね……。
K.Shirakata @argrath
https://github.com/cocoa-mhlw/cocoa/issues/16 ちょいちょい出てたCOCOAのユーザーデータ初期化問題、Xamarinのバグだったっぽいのか
Keita Kozuka🐈Flutter時々Premiere後クリスタ @KeitaKozuka
主要国のCovid19接触探知のアプリのGitHub見たけど
みんなネイティブで作ってる
命に関わるものだし当然といえば当然だけども
日本だけなんでXamarinなんだ...
Takeo Tsuchida @takeo_t
Xamarinはクロスプラットフォーム開発環境の中では古株なのにそれでもやっぱりバグはあるのか、絶対ユーザー数が少なくてバグが取り切れてないのかな。 Xamarinは2案件ほどやって見限ったけど、かと言っていまさらiOSとAndroidのそれぞれのSDK使って1から作るのはもっとダルいわ。
最近ではFlutterが大きな問題なく使えてる。奇跡的に罠を回避できてるだけかもしれんが。 FlutterはFlutterでネイティブの混在とかしにくいし日本語入力やらなんか知らんけどWebビュー絡みで辛いとか聞いたぞ
その辺はやりようがあるXamarinの方がいいと思う
ちなどのへんで見限ったん？ > この手のバグ、Xamarinがあまり使われてないというのを示唆してしまってますね……。
これが案外的を射ってて、だけらこそ新しいフレームワーク出したとき開発元は必死にステマして人柱集めて市場デバッグさせる。
今ならBlazorがステマして必死に人柱集めてるな。 xamarinとしてはxamarin apiは開発者のほうで書いてほしいんじゃないの
元々共通化が目的のGUIサブセットのフォームクラスでしょ >>537
Xamarin.Formsが出る前ぐらいなので結構前だね。
基本的にAndroidメインで開発してたんだけどmonoとdalvik/artのガベージコレクションの意味不明な挙動とか、それぞれのVMのマイグレーションのオーバーヘッドの重さとか。
Flutterは全てskiaで自前描画という仕組みからWebView実装に欠点はあるけどだいぶ緩和されてきた。IME問題は過去のものじゃないかな？
Nativeとの連携もプラグインの作り方さえ分かってしまえば全然難しくない。 >>540
なる
うちはXFでやってるけど泥はまだiPhoneに比べ遅いというかもっさり感はある 後から組み込まれた泥向けの最適化の指針をきっちりやってないのもあるけど
今は他のことやってるのでモバイルそんな興味ないからFlutterも手を出す気はないんだけどその辺改善されてるならプロトなんかは特に向いてそうだし製品版でもいけるものはいけそう
が正直この先XamarinはMAUIなるものになってって、中のアーキテクチャが変わって物としてはちゃんと動くならクロスプラットフォーム開発として良さそうではあるんだけどどうなるかわからんしFlutterやRNもそれはそれでだしなんつーか悩ましいところではある Flutterはネイティブとの連携シンプルなやつはいいけど、複雑なやつはめんどくさくね?
今flutterで通知メッセージだしたいんだけど、android版だけでいいから色々細かくやりたいんだけど、
https://pub.dev/packages/flutter_local_notifications
使ってるけどこれが対応してない機能ついたいんだけどどうしよう状態 単にネイティブのAPI呼んで結果受けとるぐらいなら簡単だけど、通知で更に例えばPendingIntent受け取ってDart側に伝えるとか自分でやるなんてめんどくさ〜
xamarinの場合って、ネイティブAPIとの連携ってどうなるのか知らんが >>538
ほんとこれ
MSは自分たちが作ったフレームワークを自分たちで使わない
だからいきなり梯子降ろすみたいなことができる >>544
Appleはもっとひどいよ。MSのほうがマシに見える。 >>543
XamarinだとネイティブAPIがC#でラップされてるからAndroid側のプロジェクトでそれを読んでゴニョゴニョする部分を作って共通のプロジェクトになんらかの方法で渡すなり連携する感じかね
>>544
それはある
アップルだとSwiftUIとかも自分のとこで使ってんのかね
自分のとこで使うものじゃないと気合入らんよな
.NET自体はAzureとかでも使うから問題ないと思うけど
MSのUIフレームワークが迷走してるのも自分たちで使わないせい＆Windowsチームとその他が分かれてるせいな気はする 「officeの開発に何を使っているか？」
今も昔もMSの本気を探るにはこの指標が一番よい >>542
確かにOS固有バックグラウンド動作なんてのはFlutterの得意分野じゃないね。
と言うかXamarin含めてマルチプラットフォーム環境共通の弱点と言うべきか。 >>544
いやいやｗｗｗｗｗｗｗｗｗｗｗｗｗ
MSは自分で作ってないからｗｗｗｗｗｗｗｗ このスレにXamarinはMSが作った！と言ってるやつがいるとはｗ >>550
544のどこにXamarinと書いているのかね？ >>549
XamarinはC#でその層書けるから割と柔軟だけどな。 >>551
はいはい、MS-DOSもWindowsもよそから買ってきましたよ >>553
そこはXamarinの利点だとは思う。
その辺がアレなんでフラッターを実案件に突っ込むのは客の理解ないと怖いな感ありそうな気がする
まあザマリンでも客の理解必要だけど >>548
Eat your own dog foodだな
やっぱいまでもC++? >>549
本当にこれモバイルOSは節電のためとかで手続きややこしいし、Androidでもバージョン間でかなりかわるからなあ。 >>548
https://appfigures.com/resources/insights/microsoft-goes-all-in-on-react-native
iOSアプリでは…
Bing Search
Microsoft OneDrive
Microsoft Outlook
Xbox
Microsoft Word
Microsoft OneNote
Microsoft Excel
Mixer - Interactive Streaming
Microsoft SharePoint
Microsoft Teams
Cortana
Microsoft Edge
Office Delve - for Office 365
Microsoft Visio Viewer
Dynamics 365 for phones
PowerApps
MS Executive Industry Summit
続く >>560 続き
Androidアプリでは…
Microsoft OneDrive
Microsoft Outlook
Microsoft Word
Microsoft Excel
Microsoft PowerPoint
Xbox
Mixer - Interactive Streaming
Microsoft Teams
Xbox beta
Microsoft Edge
Microsoft Cortana - Digital assistant
Microsoft Kaizala
Microsoft SharePoint
Face Swap
Microsoft Selfie
Bing Ads
AltspaceVR - The Social VR App
PowerApps
Mixer - Interactive Streaming Beta
Xbox Game Pass (Beta)
…が、ReactNativeを使うてますねｗ
なぜXamarinを使わなかったのか！？ｗ C#とVISUAL STUDIOで開発できる以上のメリットを感じない
木っ端開発者としてはそれでも十分なんだけどね ミッションクリティカルなアプリを作るならReactNativeを使いましょうってことなんだよ
みんなC#じゃなくてTypeScriptを習得するんだ >>490
このIssue進展ないけど深刻度が伝わってないのかね
他のXamarinアプリでもデータ消失なんて起きたら影響でかいんだからすぐ修正すべきだろうに
日本MSからも働きかけろよと思うんだが
普段MSの出張ってる連中が何故かCOCOAに関してはだんまりなんだよな
緘口令でも出てるんかね 緘口令どころか原因も対応策も全て公開されてるだろ
これ以上何を議論するんだ？ デプロイ王子がこの件を完全スルーなのが笑える
まあ無能な働き者は何もしない事が最大の貢献だからそれで正解なんだが
それなら最初から余計な事せずcode for japanに任せてくれてたらこんな惨状にならなかったのにねぇ code for japanではなくcovid-19rader japanを選定した上でスマホアプリにはさほど実績のないパーソナルP&Tに丸投げしたのは厚労省だけどな >>566
ボランティアOSS開発者の体をとっているにも関わらず、納期短縮にブチ切れるというガイジムーブかましちゃったから、そらMS的には当分謹慎やろな >>566,571
就業時間外に好きで作ってたものを採用するからと言ってコロコロ変わるAPIに短時間で対処しながら無理やり出しておそらく一銭ももらっておらずボロクソに叩かれた上に引き継いだところが蓋を開けてみれば億単位でもらってるとか聞いた後でやる気になるわけねーだろアホかクズども常識で考えろよゴミ 矢面に立つのが嫌なら最初から立候補しなきゃよかったのに
1国1アプリルールで代わりが無いのにバグまみれなんだから文句言われるのは当たり前だろ
COCOAがまともに動いてたら感染者も死者も少しは減ってたんじゃないのか？
そこらの有象無象のアプリと重要性が違うのにクソみたいな話ばっかり出てくる >>572
もし本当にボランティアのOSSでやってんなら一方的に納期押し付けられるなんてありえんでしょ。無茶したらフォークになるんだから。
出来もせんのにできるできる言って、最後にやっぱりできませんでしたっていうやつほどの害悪ってないよな。ほんで善意だからとか逆ギレする奴って本当に最悪。 apiが変わったとかいう事実はないけど
cocoa側のパラメーター設定値の間違いと
修正時のミスが原因
xamarinの罪といえばcocoaが直でapi扱ってる
わけじゃなく隠蔽されてるからわかりにくい
ということ
それとappleとgoogleでtransmissionrisklevelというのが
仕様が違ってたappleは７種類でgoogleは8種類
結果的にそれがappleはappleの技術者は確認したけど
googleは確認してないからバグになった >>577
善意で作ってた。
なんかMSやら何やら色々な思惑ありそれを元に作ることに決まった。
そこからは業務の一環としてやってただろうけど総理だか厚生大臣だか知らんがいついつにリリースとか言っちゃったからそれ死守しろみたいな話になっていやこのスケジュールだと無理でしょ言っても何とかしろってなった感じなんじゃねーの
知らんけど。
とりあえず>>575,577みたいなクズニートには分かんない話だろうけど 修正までこんなに時間かかるのは
びびってるとしか思えない
それかさらに出費して新しいものを作ろうとしてるか
基本的にiOSやアンドロイドやその他で近接情報を
共通のフォーマットで残せればいいだけ
そこから数値でリスクを判定するのは難しいことじゃないのだけど
（医療では実際どこからどこまで安全化の判定は難しい）
大事な部分を隠蔽したから難しくなった感じ >>580
善意でやってたからしかたありません。なんて言い訳まともに社会人経験wあったら通るわけないのわからんの？それで途中から業務でやってたのなら業務なりの責任があるでしょ。twitterで公衆に愚痴ってりゃそうも見られるだろうよ。
MS日本がそういう美談仕立てにしたくて、王子は生贄にされた犠牲者だと思うからそこは同情するし、彼が悪人だとは全然思わないけどさ。
日経xtechではそのへんの丸投げにMSが関わってて
https://xtech.nikkei.com/atcl/nxt/column/18/00001/05203/
では"実質的にはマイクロソフトが選考か"まで言われてるんだし。 利権狙いと責任の押し付け合い
日本社会の悪い側面が露骨に表面化してる リリース前からパーソル決まってたの本人インタビューでも答えてたのに
叩かれたからやめますみたいな言動に惑わされた記事だね >>582
まともな社会人ならきちんと契約でやること決めるのでは https://asahi.5ch.net/test/read.cgi/newsplus/1613575734/36
36 くろもん ◆IrmWJHGPjM sage 2021/02/18(木) 00:49:38.32 ID:/NulqGiU0
開発初心者あるあるバグ。
接触通知アプリCOCOAの不具合、Xamarinを使用したことが一因か？
https://it.srad.jp/story/21/02/15/1636231/
> 設定情報を保存したプロパティをシリアライズしてファイルに書き出すロジックで、「.tmp」に書き出したのちに、
> 元のファイルを削除してから、「.tmp」を元のファイル名にリネームすするコードが書かれているという。そのため、
> 削除してリネームするまでの間に、プロセスがOSにより強制終了されると、設定ファイルが消失し、アプリが初期化されてしまうという。
COCOA iPhone版のリセット不具合 Xamarinの基礎的欠陥が発見される
https://togetter.com/li/1667874 >>590
COCOAの仕組みって確か一日の接触履歴をサーバーに上げずにローカルに保存してて、定期的にサーバーから陽性者IDリストをダウンロードしてローカルでマッチングするんだよね？
もし同じ方法で接触履歴保存してたら消えちゃうわな。 規模は小さいが品質が求められるアプリで
マルチプラットフォームにする必要なんて全然なかったのに クロスプラットフォームにする必要なかったわまわわからんでもないけどプラットフォームごとに違う動作する部分はXamarinは違うように書けるんだからXamarinのせいいうよりも杜撰なコード書いてた＆チェック杜撰すぎたせいだろ
StoreとMoveがアトミックになってないとかもべっにその部分必要なら自分で書けばいいわけで 接触の履歴保持はOSのENAPIがしてくれるんじゃなくて？ まともなアプリはバックグラウンドからSaveProperties繰り返し呼んだりしないから
今まで誰もXamarin.Formsのバグに気付かなかったのではないかと
iOSはバックグラウンドで動作し続けるアプリをより積極的に殺しに行くから
不具合が出やすいとの説が出てる
（Androidはバックグラウンドのアプリをスリープさせるけど、メモリが不足してなければ殺さない）
iOSでもAndroidでもお行儀悪すぎて
OSに止められるような実装になってるのかも ソース見た人いるね。
「COCOA iPhone版のリセット不具合 Xamarinの基礎的欠陥が発見される」 https://togetter.com/li/1667874 if (store.FileExists(PropertyStoreFile))
store.DeleteFile(PropertyStoreFile);
store.MoveFile(PropertyStoreFile + ".tmp", PropertyStoreFile);
２行目の処理が完了してるとは限らないのに
３行目が実行されると だめだこりゃ、初期登録 -> 0日使用中になってるIOS >>601
それも何も担保してないし
OSがファイルが削除されたのを確認するまでループするのが
現実的 >>603
ん？いや本ファイルが存在しなくてtmpファイルが存在したらそっち採用するのが現実的でしょ。 >>604
RecoverLostPropertiesFileって
本当のファイルがなかったらtmpファイルを
本当のファイルにしましょうってことか
問題が明確になってないのに
言い訳的なコードがほとんど
これは絶対採用されない
if (store.FileExists(PropertyStoreFile))
store.DeleteFile(PropertyStoreFile);
store.MoveFile(PropertyStoreFile + ".tmp", PropertyStoreFile);
これはダメだしここをはっきりさせないと
何が悪いかもわからない >>590
こんなレアなタイミングで発生する不具合が問題になることあるの？
それとこれトランザクションの説明を端折っただけじゃなくて
本当にDBじゃなくてファイルでやってるのか >>606
バックグラウンドで何回も保存してるんじゃね？
そうすれば保存中にOSの電池節約機能でキルされる可能性が上がる
しらんけど
SavePropertiesってデータベース的な使い方には向いてないんじゃね？
本格的なデータ保存にはsqliteとか使えってことだと思う
しらんけど >>605
workaroundって言葉の意味わかってる？ ファイルじゃなくてsqliteとかでDBファイルにしとけばよかったのに >>610
無駄な開発費を使わず運用で回避
素晴らしい前例となるだろう モバイルPASMOはXamarin.Formsだけど快調だよね .NET6ぼちぼち色々話出てきてるけど、まあweb含めたクロスプラットフォーム開発の一手法として役立ちそうだから期待してるわ MSの良いところは時代遅れになったら丸ごとリライトしてくれること
Windows、Office,VisualStudioなど主要アプリ以外でも定期的に見直してくれる
その波にXamarinが加わるならとても良い事だ デプロイ王子ってXamarinじゃなくてAzureの人なのか
アイツのせいでXamarinがこんだけ叩かれてるのにAzureがノーダメージってのもなんかやり切れないな 自意識過剰の被害妄想
世間的には叩くというほど注目されてない
むしろ>>610の通りまったく問題解決してないのに事態を終息させて無理やり幕引きされた感すらある >>606
>こんなレアなタイミングで発生する不具合が
人間はレアだと思っててもCPU的には全然レアじゃない
人間と宇宙と地球と地震の時間感覚の差と似たようなもの Covid19RadarのリポジトリがArchivedになってるな cocoaのほうは昨日の修正反映されてるような
見てもわからんが >>618
いやレアだろw
バックグラウンドタスクで絶妙のそのタイミングでターミネートされたら、だろ？
まあ母数が多いからってはあるけどな >>621
ファイルIOはブロックされるので可能性が低いというわけではない。 データベース(DB)を知らない香具師だろ
DBなら絶対に、transaction を使うから >>624
全体の処理時間がどのくらいでそれがどのくらいの頻度かにもよると思うけどそんなある処理なん？
まあsqliteでも使ってろって感じだな ブロックするかどうかとは別に遅延書き込みの問題もあるから、レアとは言い切れないでしょ。 androidのディープスリープやらの省電力で
push通知が受け取れない問題と同じだったのかな >>619
デプロイ王子の方のリポジトリだよね
COCOAの風当たり強くなってきたから
もう無関係だしメンテもしないぞってアピールなんだろうか なんでOSのお作法無視してバックグラウンド処理を長時間やるの？
過去にちゃんとスマホアプリ作った事があればOSにキルされるって分かるだろ
デプロイ王子？とやらが作ったコードの部分が既にそうなってたのか知らんが
少なくともまともにスマホアプリ作った事あるやつならそんな事やらねえだろ >>635
それかDOZEより下のレベルでSoC固有のバッテリー最適化とかしちゃってる機種があるので苦労するのよ。 >>638
それはOSのカスタマイズだろ…
アプリのキルとかスリープのタイミングの制御はSoCの役割じゃねえだろ https://medium.com/mindorks/app-standby-buckets-in-android-ada2d2929350
https://stackoverflow.com/questions/53434668/exclude-android-app-from-being-put-into-standby-bucket
一日一回再起動しないと動作しないって
Android 9以降の自動調整バッテリーでスタンバイバケットに入ってしまう事言ってるの？
アプリのコア機能が影響を受けるんだったら
電池の最適化を無効にするようユーザーにお願いするのは良いみたいなので
それをやってもらえば良いのでは
コア機能に影響が無いのに電池の最適化を無効にするようユーザーにお願いするのは禁止されてるらしい >>640
そうじゃなくて、SoC固有の機能を使ったという意味。OSと言うかBSPだな。
具体的にはMediaTekとかのSoC。 モバイルはよく知らんが、ユーザーのプロファイルを更新するタイミングだとバックグラウンド処理でkillされるなんて有り得そうもない
バックグラウンドで処理するのは位置情報の記録あたりだろうから、ソレをメインのプロファイルと分けたら修正できるんじゃね？ へえｗ各国covidアプリはこんなお粗末なバグ出してないのにねｗ
OSが違うのかな？ｗｗｗ >>645
>へえｗ各国covidアプリはこんなお粗末なバグ出してないのにねｗ
各国のcovidアプリの稼働状況や普及率知ってるの？
そのあたりのデータあるのなら見てみたいな 世界中でexplosure notificationが効いて感染数が減ったって話は聞かない プロセス云々以前に
MoveFileが常に成功する前提のコードになってるからねえ
こんな初心者みたいなミスが見過ごされちゃうのはちょっとXamarin.Forms開発者の技術レベルが心配 そもそもこんなアプリは世界共通のほうがいいんじゃないか？ >>648
そんな全てをチェックしてたらチェックコードが9割くらいになるぞ 新バージョンのCocoaはXamarin当てにしないで各プラットフォームのPreferece使うように変えてるね
正しい判断w >>649
各国の法規制も運用方針もバラバラだから共通化は無理だろうね
>>650
どうして全チェックみたいな極論に行っちゃうんだろ
Xamarin.FormsのDeserializer.csにリカバリコード入れるだけの話なのに >>652
全ての箇所にそういうエラー対処コード入れないならそもそも対処されないだろアホか 重要なサンプリングデータはgoogle,apple apiですでに世界共通
その先を世界共通にしてもなにもいいことがない
世界共通のサーバーと共通の運用して
cocoaがワールドcocoaになるだけ >>653
Xamarin.Formsの中でファイル書込みしてるコードなんて数箇所しかないよ？
プラットフォーム差異を吸収できるように当然ファイルIOは一箇所に集約するからね
もしかしてコピペで類似コード量産してしまうタイプの人かな？ >>655
チンパンジーは理解できないならバナナでも食ってろよw 日本マイクロソフトも何もせず金もらったみたいだし
Windows使うのやめます
3億だか4億だか税金使ったけど何に使ったか内訳は一切公表出来ないって
国民を馬鹿にしてるにもほどがある
MSも8千万円以上ガメただろ >>660
こんな世の中に何の影響のない宣言はなかなかないな >>646
バグの話してんのに何で稼働状況とか普及率の話になるの？ でも公表したらお前ら怒るんだろ？
だったら公表するわけないだろ。 わざわざオープンソースにしてgithubに公開して
バグ報告をガン無視するとかなかなか出来ることじゃない オープンソースだろうが何だろうが開発元が適当だとどうしようもない
今回はもっと早くに発注元の厚労省が動くべきだった
利用規約
（連絡方法）
第14条 本アプリに関するアプリ利用者から厚生労働省への連絡は、本アプリ内又は厚生労働省の新型コロナウイルス感染症対策に関するウエブサイト内に掲載し、厚生労働省が指定する方法により行っていただきます。 >>669
まともなOSSなら透明性の高い運営と意思決定システムを持っている
COCOAの開発は密室で行われててオープンではない >>629
cocoaはオープンソースではなく、オープンソースのソフトウェアを流用したアプリ トヨタもＥＶ化の流れについていけず脱落しそうだな
これも俺が5年以上前から予言していたことだ
俺には未来が見える俺様の先見の明を称えよ お前自身の生活は5年前に想像していた通りなのかい？ 予言とか占いとか、コロナ予想できなかった時点でゴミなんだわ
それ差し置いてこういう技術が発達しますとか、何の意味があんだよ >>675
ノストラダムスの大予言、コロナ当てはまるよ
予言では世界が暗黒で包まれて日本発の何かで世界が助かるっていうような記述 >>667
普通のOSSなら開発元が放置してたら有志がforkしてバイナリを作成して公開したりするけど
COCOAはそういったことができるソフトじゃないもんな 国に一つの他に国の保健機関以外はストアでの公開を認めないようにGoogleとAppleが規制している >>673
トヨタが用意してないわけないだろ
頭悪すぎて話にならんw >>677
ソース自体はforkして改変してもいいんじゃないの？
リリースしなければいいだけで UnityのuGUI記述ライブラリ『Mux』をオープンソース化いたしました
https://www.pixiv.co.jp/2021/02/24/151803
コードホスティングプラットフォーム『GitHub』に、Unityで利用できるuGUI記述ライブラリ『Mux』をオープンソースソフトウェアとして公開しました。
pixiv insideに詳細を解説した記事を公開しています。
ライブラリ名：Mux
URL：https://github.com/pixiv/Mux
ライセンス：Apache-2.0
概要：
uGUIとはゲーム開発などに用いられるUnityのアプリケーションで使うことができるUIツールキットです。
これにXamarin.FormsのXAML処理系とデータバインディング機能を統合することで、UIの記述を容易にします。 >>688
板のルールをよく読んでください。
宣伝は禁止です。 >>688
Pixiv はそういう会社なんですか？
だんまりですか？ pixivなんか屑の集まりなんだからこういうことするのは仕方ない pixiv は、Ruby で有名な会社
Rubyのコアコミッター・中村宇作氏を採用し、Ruby開発とImageFlux開発を加速します 別にruby自体に罪はないし個人的に好きな言語だけどね 個人的には Rubyは、なかなか使えると思う。
node.jsはファイル関連がデフォルト非同期で、追加モジュールを入れないと
同期にできず、posixなどの伝統には合わないので使いにくい。 なんかNGが続いてる
どうせルビー基地外が発狂してるんだろうな IronRubyが生きてたらRuby+Xamarinもあったかもね
さらに重くなりそうだけど 使うのに人脈が必要ってドキュメントがクソなの？
閉じコンってやつか COCOAのissueにコメント出すようにしたのか
まあ無償調査に礼を言うくらい当たり前なんだが今までガン無視だったからな……
https://github.com/cocoa-mhlw/cocoa/issues/16
ここで出てくるのが王子だったら多少は見直すんだが新チームの人か
しっかしXamarinの保存処理は迂回して独自処理に置き換えって
MSにとっては情けない対処が入っちゃったなぁ そのアカウント、2014年に作られてから初のアクティビティが今月か… >>702
ひとりのイタいオッサンの発言をいつまで引っ張ってんのよ >>700
むしろデフォルト非同期だからこそnode.jsは他よりも効率的に動くんですよ
ちなみにあなたの言うposixなどの伝統でも相手が複数ならばノンブロックで読み書きしますよね
その時はselect()ループで待ち受けて読み書きできるようになったらそのイベントドリブンで読み書きしますよね
つまり結果的に非同期になるわけですがその部分を自分でやらずとも提供してくれているnode.jsはむしろ楽に便利に書けるわけです >>709
いや、ファイルの読み書きはそこまで複雑なものは必要無い事がほとんど。
非同期「も」出来る様になっているのは良いが、非同期がデフォルトで
同期がモジュールを追加しないとできないと言うのは困る。 どこの馬の骨とも分からん野良モジュール入れまくってる輩がよく言うよｗｗｗ cocoa4億の内訳でてたけど、MSには1億ぐらいいってるな
アーキテクトとかでぼったくってる予感 国も業界も腐りきってる。
奴隷商だけが儲かって残りはカス。 >>702
おまいがちょまど大好きなのは良く判ったぞ >>702
今回やらかしてるのってXamarinのあのへんの連中じゃなくて、Azure営業部隊とかだから関係ないぞ >>718
思い込みだろ。
Azure関係ないし
Xamarinのバグなら営業も関係ない。
営業をなんだとおもってるんだよ >>720
日経くらい読んどけよ。厚生省に移ってから会議仕切ってるのはMS よく分からんけど行政機関の会議(？)とやらを民間企業が仕切れるものなのか？ >>723
役人は技術に精通している人間ばかりでもないから有識者を呼ぶ。そこで事前に想定した結論通りになるように人選する。最近は人手もたりないから、ひどい時には有識者のメンツ集めも民間頼み。
>>722
パーソルはMS頼みやったってもうゲロってるんやで MAUIってwebも全部出来るようなこと言ってるけど
だとするとパーツにcssを使ってデザインできるようになったりするのか このタイミングでちょまどとパーソルCIO対談記事かよ
信頼関係だのコロナ禍をチャンスだのよくこんな記事出せたな…
https://techplay.jp/column/1476 >>721
日経読めとかいいながら厚労省ではなく厚生省ってじいさんかよ
日経なんてシステムの素人が書いてるのに
そんなの信じてるのか？
nvidiaのことを謎の半導体メーカーとかかいてるしなｗ
実機テストすらやってないと聞いているがそれならば
元請けのパーソルと受注させた厚労省の責任だ。 >725
XamlでUIかいたのをそのままweb appにできるってことだとおもうぞ
おそらく自動生成のタグだからSEOがごみになる
Flutter webも自動生成だからコードがひどいらしい >>726
コロナ禍をチャンスwとか草生えるわ。やっぱXamarinって糞だわ。ちょまど肩書にMSないけど辞めたんか >>733
どれがデマだっていうんだよ、いってみろ
>>730
の1行目は予想だし
2-3行目は事実。
Flutter webはろくでもないHTML, CSSになると利用者が言ってる。 >>734
根拠のない伝聞と予想だけだからデマと言われても仕方ない >>735
バカなの？
「おもうぞ」っていう文末みれば1行目は予想だってわかるだろ
Flutter Webがゴミみたいなコードを生成するのは事実だ。
なにも知らずにそれを否定するおまえらのがデマ >>736
それってあなたの感想ですよね。なんかデータとかあるんですか？ 自動生成のコード、著しく不効率とかそういうのでないならどうでもいいのでは
デバッガビリティが元コードでできるの前提だけど .NET MAUI は、Xamarin.Forms を進化させた
iOS/Android/UWP用のモバイルファーストなフレームワーク
だそうで、デスクトップ向けでは無いらしい。 >>740
UWP対応ならデスクトップ対応できるんじゃないの >>740
リポジトリではDeploy to multiple devices across mobile & desktopって言ってるし、Xamarinブログでもデスクトップ向けではないとは言ってない気がするが。 >>738
ひろゆきの猿真似しかできないアホ
ソースみれば事実かわかるだろボケ >>743
なんだろう、ウソつくのやめてもらっていいですか >>740
嘘つきがすぎるのでは
MAUIはXFの発展系でWinUIでもBlazorでも動くでしょ >>730 も >>740 も間違い。
このスレデマばっかり。 >>747
間違いだとかデマだとかいうなら
どこがどう違うのか詳しく書け。
それができないなら否定などするな >746
1行目のプラットフォームにwebがないじゃないか
MAUI対象からwebこっそりと外れたのかね
nativeしか入ってない。
webはXAMLじゃなくてhtml、cssだからな
無理に統合するとFlutterみたいなゴミソース生成マシンになってしまう 最終的にはUWP、スマホ、webアッセンブリーが同一ソースでコンパイルできるって話だから
unoに近いものになるんだろうか？ >>749
2つチームが有って、xamarinチームとBlazorチーム
後者がwebの担当だよ >>747
https://devblogs.microsoft.com/xamarin/the-new-net-multi-platform-app-ui-maui/
.NET Multi-platform App UI (MAUI)
.NET MAUI is the evolution of Xamarin.Forms, a cross-platform
mobile first framework for Android, iOS, and UWP. >>730
1つのXAML、コードでWebはできない。Unoでできているのにポンコツすぎる。
>>740
https://github.com/dotnet/maui
.NET MAUI is the .NET Multi-platform App UI, a framework for building native device applications spanning mobile, tablet, and desktop. Flutter2.0がでたそうだ。進化しすぎてるわ
Linuxやwebもstableになったそうだぞ
MAUI, Xamarin、だいぶ遅れをとってとりそう
https://itome.team/blog/2021/03/flutter-v2/
>>753
MAUIに一時期、web入ってた気がするんだが勘違いか https://www.publickey1.jp/blog/21/uinet_multi-platform_app_uimauiwebwindows.html
新たに登場するBlazor hybrid desktop appは、いわゆるハイブリッドアプリ、つまりHTMLやJavaScriptなどの
Web技術を用いてアプリケーションを実装し、それをElectronのようなWebViewコンポーネントの上で実行する
ことでネイティブアプリのような使い勝手を実現するのと似た仕組みで、デスクトップアプリケーションを実現します。
で、こいつでMAUIのソースをそのまんまコンパイルできるってことらしい Blazorをよく知らないのだけど
html/javascriptでアプリを構築するの?
xamarin.formはc#でアプリを書くけど
同じアプリをc#からのアプローチと、html/javascriptからのアプローチとそう言う違いなのかな >>754
ごめん、マジレスでそれ見て何がそんな進化してると思ってるのかよくわからないんだが >>757
web対応の正式版
sp app作ればそのままweb appとしても動く
それがベータ版だったのがstableになった。
時間かけてhtml, cssでweb app作らなくていいという事
タグが汚いらしいけど、SEO無視ならありだろう。
あとLinux対応もあるし、
トヨタが使い始めるとかいう話もかいてあった。
>>756
BlazorはC#だぞ。JSのかわりにC#でかける。
Blazorも種類がいろいろあるから詳しくは調べてくれ .NETで1つにまとめておきながらXAMLとXAML使わないキモい特殊構文Blazorの２本立て。
アホやで。 >>759
それは非効率なCSSが悪いからだろ
nativeにまでcssを強要するわけにはいかない
CSSが消えれば解決する >>761
名前空間がない
予想外に上書きされたりしがちでバグの温床
大規模サイトになると管理が困難になる
CSSはグローバル変数のようなもので害悪
XAMLのほうが明らかにコード読みやすい、書きやすい >>762
scoped css とか
CSS Modules とかは
結構一般的ですよ。
JSX(React)とかだと
ロジックから動的にとかアイデア次第でなんでもできます。 CSS汚染は
もう数年前から過去のものになってます。 >>764
web開発よー知らんけど外部のテンプレートとか使う時でも汚染一切ないの？ >>765
css moduleに対応してればOKかな？ >>763
ピュアなCSSで保守性とかの問題が解決できてないっていうのは
今も変わってないんじゃないかね
それらの技術のIT業界での採用状況、シェアはどの程度なんだろうな
Scoped CSSでも問題がでるという話もあるようで
https://ics.media/entry/200515/ VS16.9にしたら、cascadepackageがロードできませんでしたってVS起動時に出るようになって
ホットリロードが効かなくなるわ、ビューワーがそもそも出てこなくなるわ
何だよこれ それはXamarin関係ない
普通にVSのアプデに失敗しているだけ >>767
元はXAMLを主戦場にしてまして
今はWebViewに主戦場を移しましたが、
CSS凄いですよ。
改変の歴史がありますので少々乱れた感ありますが、
マイナス要素は今のところ感じませんね。 javascript/htmlのエコシステムとかたまにいうやついるけど、そんなもんあるようで全くない
jqueryに始まり、元があまりにも糞過ぎてそれを改善しようとしてできたので、元が普通であれば元から必要ないもの
cssが元からまともなら>>762のscoped cssとかCSS modulesとか元から必要なかった javascript/html/cssという最悪のゴミをどうにかまともにしようと、みんであーだコーダで頑張って作り出してる環境がjavascript/html/cssのエコシステム
その大半が元が最初からまともだったら最初から必要なっかたものばっか 何でこうあれも否定、これも否定ってやつばっかり何だろう
JavaScript/html/cssなんて当時の最適解として出てきて今はそれを改良してるだけなのに HTMLベースは開発効率悪いからわざわざWeb以外の開発に使いたくないってだけ もともとドキュメントをブラウザに表示させることしか考えてなかった
そっから見た目をもうちょいこだわりたいとか言い出して
ユーザーからの入力を受け付けたりアニメーションしたいとか複雑になってきたのに
新しく作り直さず無理やりもともとのを拡張していくからこうなる 今がいいなら気にならんけどな
自分も以前はjavascriptって聞くと2000年代の地獄のイメージを持っていたが
今はもうそんなことないんだろ？
vb6がC#に進化したようなもんじゃないの >>768
おまえも否定ばっかしてんなよ
自分の事棚にあげてんじゃねぇよカス >>776
そうだよね、まだ生産性が悪いからnativeでｈｔｍｌ/cssは避けられている。
JSの出来が悪いからしかたなくTSが伸びている
CSSがゴミだからCSS in JSとかいろいろ代替はでてきたが
決定打となるものはでていない。
>>778
なんかたとえが悪いな
C#ほど完成度高かったらどれだけ楽か Webサイトレベルのデザインやるなら
XAMLじゃ無理だと思いますけど... あと、Web開発でcssにScopedが求められる背景や意味が
ここの人判ってないんじゃないですかね？
XAMLじゃそもそもシンプル過ぎて、
そもそもデザイン性が無いか、
複数のデザインライブラリが入り乱れる運用事情とかほぼないでしょ？ それは作るものによるだろうな
業務システムならXAMLで充分 >>782
認識がずれてる
XAML単独でどうこうではない。
XAMLを使う技術、例えばWPFならきれいなUIのnative app作れるだろう
短時間で効率よくUIつくれる
そういうのを効率がいいと言っている。
1pxレベルでコントロールが必要なweb designの話もしてない。
いまはいかに生産性高く、app UIを作るかという話
見下してるけどおまえのがわかってない。
C#やフレームワークにカプセルかや名前空間の機能があるのだから
XAML自体にその機能はなくてもいい >>784
業務系だからXAMLでなんとかなってるけど、
Webデザイナーと作業すると無理ですよ。
XAMLでポータルサイトのようなもの運用できんでしょ。
自分が作業した後にそのページが改編される事も考えなければならない。
CSSにScopedが求められるのは
考慮出来ないぐらい複数のシステムが一つの画面に集約されて
お互いのシステムが相互干渉する可能性が
”自分の作業以降にありえる”
からですよ。
技術的に求められるものが桁違いなんんですよ。
それがXAMLしか分からない人と、WEBシステムで奮闘してる人の違いでです。 >>786
デザイナーとコーダの分離が昔からのxamlの売りの一つなんだけど頭大丈夫?? xamlでちゃんと行儀よく完全に分離すれば、デザイナーとコーダーが別々に平行作業したり、コーダーが作業終えた後に、デザイナーだけで
作業できるように作られてるんだけど
もうちゃんとマイクロソフトが昔からのデザイナーとコーダーの分離とかWPFが生まれた13年前?くらいから考えてるから、そんなどや顔で言われても草しか生えない XAMLだと無理がよくわからん
これはできないっていう例をあげてくれ >>786
奮闘するってことはやっぱり土台が今ひとつな出来ってことなんだなあ
>>777
の言っている通りじゃん
Excel方眼紙でドラクエ作るのに日々奮闘してるんですよ的な印象 >>786
おまえC#+WPFでまともにnative app作れないだろ
WPFなら十分すぎるほどきれいなUIつくれる
XAML単体でなくUIのコントロールとかあわせての話だと
お前以外はみんな気付いてる。
Xamarinはクロスプラットフォームのアプリつくるフレームワークと
いうことすらおまえはわかってない。
SPではデザイナーなどいれずにひとりでアプリつくれないとだめだ >>790
>>758 こいれ以降位から各自の話が合わなくなってる。
DesktopとWeb アプリの話がまざって... S3に静的コンテンツ置いてLambdaにAPIデプロイしてDynamoDBでサーバーレス構成とかXamarinは一切無関係だしね >>795
nugetでAWS用のライブラリを取得できるぞ >>794
>>786はデスクトップやモバイルでXAMLはダメだと言ってるんじゃ？ >>784
ていうかXAML1ピクセルレベルでコントロールできるよね？ >>797
デスクトップやモバイルのデザイン用途だとXAMLで十分だろうけど、
Webサイトの様なデザインバリバリのに適用するには厳しいですよと言ってる。
そもそも機能差がありすぎてXAMLは削りようもない位、最低限必要なもののみって感じ。 >>801
いやだから具体的にこういうのは難しいって言ってよw
その機能差でも良いからさ アメリカ人が情報を盗もうとしてるから気をつけろ。
不用意にMSを利するようなことは言うな。
彼らはここで現状のMS製品の何が問題なのかの情報を得ようとしている。 俺だよオレオレ
このネタもなんか誰も使わなくなったな >>801
おまえがWPF知らずにテキトーなこといってるのはわかったからもういいよ
WPFは必要最低限どころかこんなのだれが使うんだよっていうくらいに
細かくUIいじれる
>>798
1pxレベルってのはそれくらい細かい注文っていう表現。
pxレベルで幅が指定できないっていう意味ではない このサイトのデザインはXAMLでは無理だろ！ってやつをいくつくあげてくれたらきっとみんな納得するよ。
阿部寛のサイトとか難しいんじゃないかな。 Mauiって期待していいんですかね？
マルチプラットフォームワンUIが実現される・・・？ >>814
あわしろ氏もうなぎ問題について警告してましたね >>796
サーバーレス構成とかXamarinじゃできないじゃん >>816
もしかしてサーバーサイドをXamarinで書きたいと言ってんの？ >>816
クライアントサイドならnugetでAWS.Lambdaとか取得すれば通信できるのでは？ >>818
そうそう、Xamarinはサーバーサイド開発用ではないって話 >>821
いずれにせよサーバーレス構成でもXamarin+AWSの通信ライブラリでクライアントサイド開発が可能なので
>>795の「サーバーレス構成とかXamarinは一切無関係だ死ね」というのは的外れ とりあえず>>816は何言ってんだアホかでオケー？ サーバーレスとかレベルが低いしスレ違い
クロスプラットフォームの話しろ .net6.0になるまでネタあるんか？
16.9にしてもホットリロードが全画面にしか効かないじゃんとかこのスレにいってもしょうがないし MSはEdgeをChromiumに移行したことによって今度はFlutterにコミットし始めてワロタｗｗｗ
結局MS自身がほぼすべてのアプリをReact NativeやFlutterで作ってんだから.NETなんて既に形骸化して公務員が毎年予算作るためだけに用意した部門やプロジェクトとかわらんことになってんだよな・・・
俺はずっと真面目に.NET触ってきたからけっこう本気で.NETに期待してたのに結局XAMLでウェブアプリ作らせないからReactやFlutterにフルボッコにされてオワコンになってしまったな 先見の明がない無能がネイティブだけずっとやってりゃ市場価値上げられて年収上がってたのに馬鹿だねえ とはいえReact NativeやFlutterで即ウェブアプリが作れるわけではないし、
RNはReact似てるだけだぞ。
まあフルボッコにされてるのはわかる。Xamarin好きだから辛い。 js書けないからXamarinに頑張ってもらうしかねぇ >>830
いや結局ReactもFlutterもXAMLもUIフレームワークなわけでフロントエンドを支えるアーキテクチャはそれぞれ違うがHTMLとCSSがベースで開発できるReact、FlutterとXAMLは天と地とほどの差があるだろ
XAMLなんてちゃんとLogical Tree、Visual Tree、DependencyObjectなんかを理解しないとユーザー定義でカスタマイズすらできんからな
ぶっちゃけゴリゴリやってる俺でもXAMLのスタイル周りはマジで超絶面倒くさいからCSSっぽく書けるReactとかマジ神だなって思うもん ちょくちょく同じ文体の人がflutterがいいって宣伝に来るのは何でなの? COCOAは一発逆転するための最後のチャンスだったのかもな >>832
XAML周りの面倒くささは同意。
Flutterで快適に書けることがわかったから、.net 6のMAUI/MVUがどれぐらい使い物になるのか興味深い。 >>822
一切関係無いとまでは言わないけどサーバーレス構成のサーバーサイド向け開発にはXamarinは向いてない。
>>824
アホと言われる筋合いはないけどXamarinやるよりAWSとかGCPやったほうが売りになるよ。 FlutterがTypescriptで書けたらC#erな俺でもとっかかりやすいかなあと思ったが
Dartなんだなあ >>839
サーバーサイドだけ作れてクライアントサイドできない奴は役立たずだと思う >>840
まともなC#erならDartなんて余裕よ？ >>839
何でサーバー向けにXamarinで開発すんだよw >>844
Xamarinで作ったUWPアプリをHTTPサーバーにしようと思ったんでしょう
知らんけど >>836
マイクロソフトパートナーアワード2020
https://partner.microsoft.com/ja-jp/connect/jp-award
パーソルwも選ばれてるwけどcocoaもXamarinも全く載ってないね。もうどっちも黒歴史なんだろうな。 MSの賞ほど無意味なもんねーからな
MVP取ったやつに実際どうなん？って聞いたら受賞歴あるコミュニティで顔のきくやつから推薦されれば貰えるって聞いてアホかと思ったわ
エヴァンジェリストとかもそうだがプログラムのプの字もわからん無能が金とコネで現場引っ掻き回すしCocoaで日本のこの業界が如何に終わってるか白日の下に晒されたが何もかわらんのだから終わってんだよ MSならまだしもMSKKに選ばれて何が嬉しいかわからん XamarinなんかどうでもいいがAzureでは稼ぎたいのがよくわかるメンバー表だな。cocoaも王子もそのための生贄で 日本MSって営業や広報だけなん？開発者はいないん？ エバンジェリスト的なのはいるけど製品開発に関わるとかはないのでは 漏れは、MS の面接を、東京本社で受けたことがあるけど、
英語を喋って下さいと言われて、喋れなくて落ちたw
外人と一緒に開発するから 俺の会社にいた全く技術センスの無い帰国子女の子がマイクロソフトに転職した。
流石に開発部署ではなかったけど。
派手好きな可愛い子だった。 >>851-852
開発部門あるよ
日本でテスト、ローカライズもやってたしプロダクトによっては日本で開発してる
サポートエンジニアもいる 基本、英語重視なので文系が有利
ドラゴン桜の東大理1 と同じ。
英語が苦手な理系 vs 数学が苦手な文系
数学では、どちらも部分点しか取れないので、あまり点差がつかないけど、
英語では、かなり点差がつくから文系有利
ビジネスは、ほとんど言葉を理解する能力だから、
英語が喋れない香具師は、お金を稼がないから大嫌い
だから外人は、自国語を喋れない香具師が大嫌いで、白人以外を差別する 取引先がMSKKと開発支援契約してたからMSKKのPGと一緒に仕事したけどめっちゃ仕事できる人だったよ MSKKの技術支援コンサルと一緒に仕事したことあったけどピンキリだったわダメな方はほんとたよんなかったな
自分も生意気な20後半ぐらいだったからだいぶ舐めくさってた MS-IME
MSDN日本語訳
COCOA
表に出てるこの辺の出来をどうにかしないと評価される事は無いかと そもそも本当に優秀なら北米のレドモンドで開発してるだろアホなのか
MSKKから流れてくる案件なんて自社製品のローカライズや顧客ごとのオフィスのカスタマイズとかクソみたいなのばっかじゃねーか MSKKみたいな企業が率先してコネと多重請負を助長してんだから終わってんなってイライラすんだよ MS-IME ← 中国で開発
MSDN日本語訳 ← 機械翻訳
COCOA ← ボランティア 難関の私立文系は英語配点高いから語学得意な人は多い
あとは女子のが語学は得意
語学は難関大の女子が最強 普通に読み書きと会話ができれば語学なんていらんだろ IMEが中国で開発されてるって言い出したのは旧社長の古河さんでしょ
本人がIMEの出来が悪いってこぼしてたのに Xamarin触ってみたけど一度レイアウトのxamlでコンパイルエラー起きてから、ロールバックしてもずっとエラーが残り続けるんだけど何なのこれ
おま環かもしれんがある日突然エラー吐き出始めたり、WPFやASP.NETと比べて挙動が不安定すぎて怖い >>871
つまり現在は外部の人間だってことだよね パーソルMSの投げっぱなしよりはマシになるんじゃないの。知らんけど cocoaはOSSとして関心持つ開発者少なそうだから、活発なcocoa開発者じゃないと技術参与として不十分だと思う。
OSS開発者が関心持たなそうなのは政府がきちんと金払って、責任持って開発してくれるところに開発してもらわないと迅速な不具合修正とか期待できない 平井デジタル担当相「余裕なかった」 ココア未対応で釈明 (毎日新聞)
https://news.yahoo.co.jp/articles/462b9f9cc600aa6879b7bcfb3638d7da0916ba23
3/16(火) 12:13配信
新型コロナウイルスの感染者と濃厚接触した可能性を知らせる政府のスマートフォン向け接触確認アプリ「COCOA（ココア）」が、
米グーグルとアップルの基本ソフト（OS）の最新仕様に未対応である問題を巡り、平井卓也デジタル改革担当相は16日の閣議後記者会見で
「バージョンアップする以前のところ（の不具合）で引っかかっていたので、余裕がなかった」と釈明した。 まあいくらマンパワー使っても2・3週間突貫で作れって言われてもろくなもんできるわけないよな
アプリの性質上ほぼすべての機種に対応しないとだめだし 日本のこの業界の現実を理解してる人間からするとパーソルとかなぜ今更炎上してるのかクエスチョンマーク出まくるんだが
国内は過去から現在、そして未来永劫ずーっとこの多重請負が常識、商習慣、慣例でこんなの異常だと声を上げたやつは相手にされず干されて排除されるグローバルな競争力なんて皆無の終わってる業界なんだが
役人の天下りも含めてもうそういうビジネスモデルとして定着してんだよ多重請負とか定期的に炎上するが1ミリでも良くなったかよｗｗｗ NEC富士通あたりならもうちょっとうまくやったとは思うけど、突貫工事の炎上案件請け負わんわな いやいやオムニセブンでNEC、ネッツエスアイ、フィールディングスすべて大炎上でしたが？
富士通もエフサス、FIPも目くそ鼻くそですが？
大概の大手案件やってきたがまともな案件なんて一つもなかったわ俺とは違う世界線で開発してんだろうなGoogleとかAppleかな？ >>877
いや、使ってるAPIが古いとか、通知が飛ばないとちゃんとissueで上がってるんだから
OSSの人間が興味云々は関係ないでしょ >>877
いやAndroidの知見を提供するって話でしょ 派遣産業オワタとは言わんが、
登録者の技術を言語とかアプリ使用技術レベルではなく
細かいモジュールをどう利用できるかを評価する部署くらい作らないとダメだな
プログラマーを3年で本社に引き上げて技術営業にするのを怠ってたって事だ >>883
>>884
関心持つ人が少ないと作業者が集まらないでしょ。
ストールマンとかリーナスみたいなOSSで活躍した、してた人は本人も活発な開発者じゃん Cocoaのボランティアデバッグしてる人はそこそこいるでしょ 16.9.2をインストールしたらホットリロードがすげー軽やかになった
けどデザインビューワー何処行ったん? パーソルが実際にどんな企業かは知らんがどうせ天下り先かなんかのステークホルダーだろ
この国のエスタブリッシュメントはソフトウェアというものについてスキルなんて関係ないどころか必要ないとすら思ってるからな
だから日本のソフトウェア業界というのは技術でなくコネでしか金が回らないビジネスモデルだから多重請負や人海戦術という国内でも屈指の低水準の労働生産性なんだよ もうそういう、この国のITはどうこうとか手垢付きまくりの言説ウンザリだわ MSKKが必要だったらMSKKとも直接契約するだろ XamarinとXiaomiがいつもごっちゃになる
ならない？ XamarinもXiaomiも知らなくても生きていられるのに
、何言ってんだ ここxamarin本スレなのにスレの大半がcocoaとかの話題ばっかじゃんきしょい iOS版は何年も前にSwiftUI化してたのに
Androidはどうしてこんなに遅くなったんだろうか
Xamarinが原因で開発が難航してたとは思いたく無いけど MSがリリースしてるマルチプラットフォームアプリのほぼすべてがReact Nativeなんだからいい加減に現実を直視しろ
そしてFbがずっと対応せすハブってたWindowsネイティブもMS自らがReact Native for Windowsとしてリリースする始末
しかも最近C++で書き直してパフォーマンスも改善する力の入れようでこれってすでにMS自身がReact Nativeの方が使いやすいからOfficeやSkypeなんかのメジャーアプリですらReact Nativeで書いててもう勝負ついてんだわ
今後はReact Nativeをリスペクトして更に洗練されたFlutterが人気だしReact NativeとFlutterでXamarin()とかマジで時間とメモリの無駄遣い c++で書き直してるのはwinuiのことだろ
でreact native for windowsの裏でwinuiを使おうってだけ
まぁxamarinは糞なのは違いないが、その後継のmauiも大しては変わってないから同じく失敗しそう 失敗するも何もマルチプラットフォーム開発の一つの選択肢として一定のシェアで定着してるだろ
お前らこそ現実見ろよw xamarinに親を殺されたので、絶対に認めてはならないのです ハブったも何もReact Nativeって元からモバイル開発専用じゃん 一定のシェア??
そんなのあるに決まってんだろ
お前のなかじゃ失敗=シェア0%の前提で話してるのww?? Delphiなんてもう終わっている言語でも一定のシェアはあるから VB6ですら未だに使われてんのに一定のシェア()とか超ウケるｗｗｗ
俺もC#は言語の中で一番好きだからXamarinに期待するのは理解できるがDOMやJS/TSなんかのウェブの基礎がわからない・学習意欲がない・ついていけないなんて理由で.NETにしがみついてるやつが多すぎてマジで死ねよって感じ >>912
むしろんじゃ何を持って失敗って言ってんのか理解に苦しむな
>>914
jsとか関わりたくないわ モバイルSuicaのようなユーザー数がとても多いアプリでXamarinが動いているのはいいね インストールベースで2000万超えてるCOCOAがXamarinアプリの代表かな
世界でもトップクラスなのでは 制作が楽になる方に機能してくれたらいいんだけどさ
Appleの求める独特な仕様を満たす必要があるとか、Androidの外部ライブラリを使うのが一般的になってる分野だとか、そういう部分が本家ツールより苦労するからな >>920
まあザマリンの目的が同じ言語での開発とロジックの共有だからの
なんだかんだ言ってそこはでかいよ そら(ネイティブに比べてハイブリッドが遅いのは)そうよ
3Dが一切使えないからゲームが作れないしパフォーマンスも良くないから今でもプラットフォームごとにネイティブコードで書いてるとこばかりでハイブリッドなんて2割あるかないかじゃねーかな
その中でも特に起動が遅いXamarinとかインフラ系アプリで採用しちゃあかんやろとしか言えんわｗｗｗ クロスプラットフォームは総じて糞
その中でもキングオブ糞なのがXamarin そんなに遅いか？
ちょっと使ってみたけど予想外に速くてビックリしたぞ リニューアルでXamarinからネイティブに変更したんじゃないの？ https://twitter.com/kumamo_tone/status/1373851255764787204
＞Android版だけ見て書いてしまったのだけど、iOS版はAndroid版とレイアウトが異なり、Xamarinに依存していないようでした
iOS版は無事みたいだな
別スレでもAndroid版だけ激重って書き込み見たし
https://twitter.com/5chan_nel (5ch newer account) >>924
ゲームXamarinで作ってるとこは聞いたことないがCocosSharpとかあんだろ
つかUnityなんだと思ってんお前は Android版は起動に失敗することがあるけど、
ちゃんと起動したらそんなに遅くもなく動いてるけどな。 FormsのXamlバインドで式書く方法てあるん？ 質問してるやつも答えてるやつもまったく理解してなくて頓珍漢なのクソワロタｗ
属性構文でもプロパティ要素構文でもバインドできるんだが基礎を勉強しろXAMLの要素はDOMじゃなくてクラスだってことを理解しろ やっぱりデザイン時にフォームのデザインがわからないのは不便だなぁ
いくらホットリロードがあるっつッてもなぁ vsアップデートしたら、起動時の度にiPhoneに2段階認証届くようになった。なんぞこれ？ VS2019でXamarin.Formsのアプリを作ってるのだけど
なんでXamarin.Formsだとエディタの設定無視して
インデントが片っ端からスペースになっちゃうの?
デスクトップアプリだとcsファイルはインデントすると全部タブが入るのに
Xamarinのソースはインデントが全部スペースになっちゃう なんか、
.editorconfigを作ってソリューションに追加して
そのファイルを開いて
インデントと間隔の「タブの使用」のチェックボックスを両方外したらタブになった
なんで反対の動きするん? 水の星へ愛を込め手を聞いてるけど
森口博子ってデビューの時から歌うまかったんだな 久しぶりにForms触ったんやが、別世界になっててビビった
ライブラリの充実ぶりがすげーな 結局MSの開発環境が一番一貫性がなくなってしまっててクソワロタ
Windows 11に合わせてWinUI3を散々推してきたUWPじゃなく今更WIn32を優先する始末
XAMLを全面に推すくせにASPやRazorは捨てない曖昧な態度で困惑
そりゃMS Storeでアプリ増える訳ねーんだよなにっちもさっちも行かなくなってAndroidアプリの配布と実行に賭けるとか無能しかおらんのかよ
そして結局MS自身が自社開発環境ではなくReact Native使っとるという意味不明すぎる態度も無能すぎる MSはもうオープンソースに舵切ってから
けっこう時間たちますよ
開発者も主力はVSCodeに移ってるでしょ。 久しぶりにココ見たけどUnityのことを誤解してる人がこのスレにもいるんだなと
ゴミレスですまん
Unity自体はc++で書かれたネイティブのゲームエンジンでスクリプト部分がC#やjavascriptで記述できるだけ
Unityをマネージアプリだと思ってはいけない 最近どいつもこいつも新しい言語作りやがって老害の俺にはついていけなくなってきたよ C++/Go/Rust以外のモダン()な言語はどれも変わらんから数時間書けば覚えられる
問題は言語じゃなくて実際に開発で必要な独自の開発環境の構築(ミドルウェア)・アーキテクチャ・フレームワーク(ライブラリ)を覚えるのが大変だわ
特にコーディングが便利で楽になったトレードオフとして開発環境構築が半端じゃなく大変になってる MAUIってどうなん？
XamarinFormsから乗り換え簡単？ APIは同じなんでソースは変えなくていい、山椒だけ変えればとかみたような気もするけど試してないのでわからん
新規に作る分にはあまり違いないんじゃ？ MAUIでのモバイル開発もこのスレに含まれるの？
別スレッド立てたほうがいい?
含まれるなら次はスレタイにMAUIのキーワードいれたほうがいいな MAUIはXamarinを進化させたような別技術だから別の方がいい気はする 次スレは一緒の方がなくない?
そんなに話題無いし、
XamarinはMAUIに引っ越せとMSからのお達しでてるし ぶっちゃけMAUIとか俺ら関係ないんだよなオタクの技術自慢みたいなことばかりで何度同じ失敗を繰り返すんだよMSさんよ
C#erが望んでるのはXAML+C#(MVVM)でネイティブとWebを実装できることでMAUIもアプリだけでWebはASP(Blazor)使えって頭おかしいやろそれでお前らOfficeも何もReact Nativeで開発してるってガイジすぎる
Win11はMS StoreでWin32アプリ配布可能だから普通にWin32(しかもVB.NET)だらけになるわこんな結末を望んでたんですかMSさんよ Xamarin → .NET 6
Xamarin.Forms → MAUI jetpack composeも1.0になったし、windows 11でandroidアプリ動くようになるし
Flutterやjetpack composeでwindowsアプリ作るのがトレンド >>963
webは一緒に開発させて欲しかった
>>964
そういう括りの方が正しそうやな
ちょい雑だった
6でiOSとかのラッパーの部分はどういう扱いになるんだ？ベースの部分が.NET6としてあって、各プラットフォーム用の部分はエクステンション的な感じ？ >>965
FlutterとMAUIとかXFで生産性の差出てくる？ >>965
Flutterでwindows apps?
2行目、Windows appsではなくAndroid apps ?
>>966
MAUIならWin, Mac, Android, iOSで動くのだから
もうWeb app自体、開発する必要ないんじゃないかね
webはサービスの案内だけにして、
native appいれてもらうスタイルも増えると思う >>968
やー、やっぱりwebでもチャラっとは動かしたいよ
自分で使っててもこのマシンでアプリ入れるのだるいな、webのやつでいーやとかよくやってる
それにwebだけでいいようなもんだったらむしろそれだけの方が運用も楽だし。そこで開発方法とか変わるのはめんどい マウイってiPadOSとワッチOSにはビルドできないのかな Windowsおじさんが最も安価にiOSアップリビルドする方法教えてよ >>971
自作PCでHackintosh
または中古iMacを買う 結局XcodeがないとAppleプラットフォームのバイナリをビルドできないのがマジで不便だよな
プライベートではゲーミングPC以外はMacオンリーの俺ですらそう感じるんだからそうじゃない奴らは案件でも慣れないMacで四苦八苦してて超ウケるwww >>972
ハッキングはわからんのでしょうがない買います
開発するのに便利になるわけでもないのに金かかるとか(;´д｀)ﾄﾎﾎ… >>974
AWSのEC2でmacインスタンス使うって方法もあるよ AzureもAWSもGCPもどんどん高くなってて個人だと学習できなくなってんのやべーだろ スレッド立ててきた
MAUIリリース近くMAUIの話題も増えてきたので検索ワードとして追加した
Microsoft Xamarin part8 [.NET MAUI]
http://mevius.5ch.net/test/read.cgi/tech/1627778316/ >>975
それってiPhone繋いで実機デバッグできるん？ MAUIのPreview6入れてみた。
maui-checkはすべてokになったんだがemulatorがうまく動かない。
Android Device Managerのところで、Android EmulatorのLevel 30と29は
デバイスの作成すら失敗する。
Preview6でAndroid Emulator使ってる人、どのバージョンのAPIで使えてますか？ >>979
iPhoneと同一ネットワークになるようVPN構成したらいいんじゃないの iOSアプリ作るなら整備済のMac mini買うのが情報豊富で無難だよ。
ググって英語情報しか無いとか情報自体無いような環境はアプリの中身じゃ無いところで無駄に苦労する >>971 >>974
この記事を思い出した。
iPadのみでiOS appがbuildできるようになるらしい。
https://k-tai.watch.impress.co.jp/docs/news/1329849.html
アップルは、今秋提供するiPadOS 15の新機能のひとつとして、
iPad版「Swift Playgrounds」において単体でアプリを開発、公開する機能を発表
このiPadが出たら規約的にiOS appのbuildができるようになりそうだし
Visual Studio側が対応すればiPadだけ買えばOKって感じになりそう PlaygroundsはSwiftのSqueakみたいなもんでXCodeとは全然モノが違う >>985
iPad OSからストアアプリ登録できるってかいてある。
つまりAppleがiPadでの開発を認めたってこと。これが重要。
Appleのポリシーの問題は解決したしあとはあとは技術的な問題。
Visual Studio側が対応することで
iPad経由でMAUIのコードをPlaygroundでbuildできるようにすることは
技術的に難しくはないだろう。
あとはXcodeがiPadで動くようになる可能性もある。
iPadなら3.8万円程度からあるから負担は軽くなるね
いまさら脆弱性あるintel siliconの中古iMac買うのは抵抗ある なんかめんどくさそうなので素直に最新モデルのMac mini買っとくわ
業務のお勉強なのに自腹つれぇけどしゃあないか
これがアップルの目指した世界なんだな >>987
金額的に新品Mac miniつらいなら少し待てばいいじゃない。
あと2-3か月でiPadOS出るんだし、Swift開発でよければiPadでできる。
今からやるならXamarinではなくMAUIになるはずだが
MAUIの正式版は11月だ
ただの勉強用ならあせって買わなくてもWindowsとAndroid実機とXamarin
で勉強できる。
MAUIの正式版とiPad OS15が出てから考えればいい。
仕事で使うなら会社の経費で買ってもらえばいいし。 >>989
我慢できない性格なだけじゃないんか？ｗ
C#とXamarinはかなり経験あるの？
Androidで出してヒットしてからiOS版だしたっていい。
Appleはストアにアプリ出すのにお金かかるけどその予算も計算にいれてる？
Googleに比べてかなり高いよ 実際案件でハイブリッドで開発できてるケースなんて国内の場合は極少数なんだよな
結局プラットフォーム毎にネイティブで開発ってパターンが圧倒的に多いからプライベートでゴリゴリ触ってても使う機会が少ない
国内の場合は開発者の調達に苦労するからって話だがまぁ嘘だな案件の開発方針決めるの頭悪い客や元請けだからな >>991
経験値ゼロですわ
計算なんかしてないすわ
でもウチの族長がいいから黙ってヤレというんですわ ところでザマリンてHTML/CSSみたいにスタイルを外に出すのが一般的ではない感じすかね？ Xamarinはプラットフォーム実装なんだが
React NativeかFlutterの方がいいんじゃねその頓珍漢ぶりじゃC#もよくわかってねーだろ？ C#はASP.NET Coreやってるんでヨユーっす
自分スマホ童貞っす >>993
なんじゃそりゃ
上司の指示なら会社に金を出させればいい話
仕事にもつかえるスキルを無給で勉強するわけだから、
ハードウェアくらい会社で負担してくれって言ったらいい。
その流れで会社が金出さないんならブラック気味だな >>992
普通に案件で使ってるわ
コードの共有率94%ぐらいになってるからこれを別に作るとかないだろって感じだわ ロジッククライアント側にてんこ盛りだし
まあサービスのフロントとかで各々のプラットフォーム向けにUI最適化したい、ロジックはほとんど上ですっていうんだとバラで作った方がいいんだろね
>>997
ホントそれ
なんで自腹切ろうとしてるのか意味わからん 次スレ。
Microsoft Xamarin part8 [.NET MAUI]
http://mevius.5ch.net/test/read.cgi/tech/1627778316/
検索用ワードで.NET MAUIとMicrosoftを追加しましたが、
扱う内容はここと同じです。 このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 360日 20時間 39分 49秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
