Xamarin Part5 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
アズュールって
灼眼のシャナに出てくる火除けの指輪でしょ？ >>87
その表記だと日本語読みだけどな
ネイティブの発音聞いてみろよ、低悩 発音はともかく表記はアジュールで問題ない
マイノリティ派の意見など無視されるのが世の常 仕事でxamarin使ってるんだけど、androidのアプリ起動がゲロ遅い
起動時に多少処理はしてるんだけど、
メイン画面が開かれるまでに3秒以上かかるのなんやねん
aot有効にしたら早くなるけど100mとかなるし >>99
割と致命的な遅さ
ネイティブで作り直しかもしれん
100mは100メガバイトのアプリサイズになるってことだ 起動時間が遅いことについて上流工程/顧客が諦めるまで時間稼ぎしれ
起動時間が遅かったり、ランタイムがでかかったりするのは、Xamarinに限らずマルチプラットフォーム(笑)の宿命だゾ 自分はAOTで起動速度そこそこになったからそれで出荷したけど、とっとと改善して欲しいわ Xamarinでやるとアプリのクオリティが落ちる
クオリティが落ちることに対してなんとも思わなくなる >>103
バカでかくならない？
30メガ程のアプリやけどaot有効にしたら100メガになって変な声出たわ
しかも、vsでそのオプション（試験段階）とか書かれてるし >>106
100メガバイトは100MBな。
略称は大文字小文字で意味が変わる。
例えば100Mbって書くと、100メガビットになる。
仕事でPGやっているなら単位は正確にな。 PG
アメリカ合衆国海軍及び日本国海上自衛隊における「ミサイル艇」の艦種記号。
昔はアメリカ合衆国海軍では「砲艦」（Patrol Gunboatの頭文字を取ったもの）だったのだが、いつの間にか「ミサイル装備艦船」の艦種記号は「Ｇ」が付くことになったので（たとえば、ミサイル（艦隊防空用）駆逐艦はＤＤＧなど）、
ＰＧはミサイル艇になった。古い世界の艦船などを読むときには要注意である。
護衛艦に装備しているものは「艦対艦誘導弾」と称する海上自衛隊でも「誘導弾艇」とは言わない（笑）。 >>106-107
この流れで100Mbitとかありえへんわ >>109
例えで書いているだけというのが理解できないのか？ >>111
例えが的はずれって言われてるのが理解できないのか？ 100mって書くと100メートル、最大限譲歩しても100ミリ秒と受け取られて混乱するだけと言っておけば済む話だな
100MBというのは無理がある >>116
後付け？
恥の上塗りにしか見えんわ w Xamarin（ザマリン）とは、2011年5月、Mono、MonoTouch、Mono for Androidの開発者により設立された企業
Xeon（ジーオン）は、インテルがサーバあるいはワークステーション向けに製造販売している、x86 命令セットを持つ CPU Xerox=ゼロックス
エックスエロエックスではない Xamarin = 糞
Xaml = 糞
C# = 糞
Microsoft = 糞 Xamarin = 糞
Xaml = やや糞
C# = 糞じゃない
Microsoft = 糞じゃない
MSKK = 糞中の糞 Xamarinを使いこなせないクソプログラマーがwww Xamarinを使いこなせてる人が一人もいない説について qiitaの投稿数
Android: 7851
iOS: 9500
Xamarin: 574 <- 爆笑
stack overflowの投稿数
Android: 1,002,288
iOS: 514,864
Xamarin: 60,299 <- 爆笑
情報の少ない環境でご苦労さまですｗ そりゃiOSやAndroidのネイティブ情報を流用できるんだからXamarin単独の情報はネイティブ情報に比べて少なくなるのは当たり前でしょう いつの数値だよw
Xamarin 860
react native 455
cordova 574
まあクロスプラットフォーム手法としてはメジャーな方？
後何かあったっけ でもxamarin 2017 adventだけは急激に増えたのはびっくりしたけど。 ObjCやらJavaで書かれたサードパーティライブラリを、手軽にインポートやら変換やらする方法て無いの？
愚直に書き直すしかない？ >>137
RubyMotion, Kivy, NativeScript, Corona, Cocoa2d-x, Qt, GoMobile >>142
メジャーと言えなくもないのQtぐらい？ 漫画ビュアを5月中頃からXamarinで作り始めたけど、なんとか形になったわ。
Xamarinの制限というより、UWPの制限で苦労した。
Androidの方はFormsでActivityを使うやり方を理解したら機種依存部分はすんなりいった。
1本作って思ったのは、日本語での資料が散在していて、趣味でやっていたら問い合わせ場所がほとんどない。
Xamarinを普及させたかったら、このあたりをなんとかしないと難しいね。 あめい@バレル待ち @amay077:
きたな！ Nintendo Switch Online アプリ(Android/iOS)Xamarin(Xamarin.Forms)製です！
https://twitter.com/amay077/status/887610194947067904/photo/1 ゲームの世界の人たちも C# には大分馴染んできたようで。 任天堂ももうXamarinはこりごりだと思っただろうな 任天堂のオンラインサービスの開始が2017年秋から2018年中に延期になったのもXamarinのせいなんだろう 東大卒のオタクが姫に入れ込んじゃったんじゃねーの？ Nintendo Switch Onlineのボイスチャット機能ですが、海外ゲームメディアのPolygonやGameSpotによると、ボイスチャットはアプリが開いている間のみ有効になっているとのこと(´・ω・｀)
つまり、ボイスチャットを楽しむにはスマートフォンの画面ロックを解除し、常に画面を表示しておく必要があるというわけ(´・ω・｀)
間違ってスマートフォンの電源ボタンなどを押して画面をロックしたり、他アプリでメールや検索などを行おうとすれば、ボイスチャットは終了してしまうそうなので、LINEやSkypeなどのIP電話よりもかなり使い勝手の悪いものになっている模様(´・ω・｀)
なお、GameSpotは「スマートフォンのバッテリーの減りが劇的に早くなる！！！！」と指摘しています
https://www.gamespot.com/videos/gs-news-update-nintendo-switch-online-app-has-voic/2300-6439956/ iOSでVoIP専用APIをきちんと使わないとそういう制限になるよねー
後から問題が発覚したけど今更再実装は無理ぽってなった予感
まぁ正式ローンチは来年だしドーンと待とうや(その時にXamarinからネイティブに切り替わってないことを祈りつつ どうせ理解していないだろうから書いてやるけど、プログラマーがプラットフォームのAPIをちゃんと理解して使ってないだけだろ。
Xamarin.FormsはUIの共通化がメイン。
各プラットフォーム固有の機能はAPI経由。
Xamarinは関係ない。 結局OS毎の機能使うのにはネイティブの知識とAPIの知識も必要
Xamarinを無理して使う必要性はないな
開発してる側も、Xamarinなしで普通にネイティブで作った方が楽そう >>157
何度同じ話を繰り返したいのか知らんが、XamarinのメリットはC#など.NETメインで開発できることとそれゆえコードの大幅な共通化が出来ること。
そこにメリット感じないならネイティヴでやれば良いし好きにしろ、 C#をロクに知らずにXamarinに手を出したら痛い目に遭うだろうな
OSSのソースを読み慣れてて、英語圏の技術系掲示板でやり取り出来て、JavaやC#みたいな古式ゆかしい静的型付オブジェクト指向言語に慣れてる人でないと、それはそれはクソに見えるだろう UnityでC#慣れてるからイケると思ったんじゃね
必要なノウハウ全然違うけど 何が糞ってXamarin.formsが中途半端に機能ｊを提供してるのが糞
初めから糞だと分かってれば手を出さないのに、中途半端に対応してるから、
まずXamarin.formsの機能で実装しようとしてみる。
結局Xamarin.formsだとうまくいかないことが分かって、
その機能だけXamarin.AndroidとXamarin.iOSで書き直す羽目になる。
同じ機能を実装するのに、3回も実装しないといけない
ネイティブだったらAndroid版とiOS版の2回で済む Forms見切り付けてXamarin.Nativeやれば済む話
今までの工数が勿体無ぇ的なコンコルド効果全開で強行すりゃ、そら当然痛い目見るわさ >>166
どこがだwww
お前が作るもののうち、Xamarin.Formsじゃ作れない画面がどんだけあるのか考えろ
ほとんどの画面はXFで事足りる。足りないとこだけ少しレンダラするなりそれでもダメならネイティヴコントロール梅込みゃいいだけ
どれだけコード共通化出来るか作るもの次第だろうけれどまともなものを作るならその共通化メリットが学習コストを大きく超える
いまさらTableViewSourceみたいなクソに触りたくないわ >>167はXamarin.Forms使ったら痛い目見るよって言って
>>168はXamarin.Forms使っても痛い目見ないよって言ってる
どっちが正しいんだろう >>163
3回実装する前提で笑った。
その部分を2回実装で済ませば確実にXamarinのほうが生産性高いという言い分かｗ >>168
言いたいことはわかるが、
まともなもので Xamarin 使ってるものがあるみたいな書き方はよくない
Xamarin 使ってまともなものが作れるみたいな誤解を招くよ >>163
行き当たりばったりでいきなり実装するからだろ
何がプラットフォーム固有で何が共通化できるかなんてプログラミング実装前に要件を整理してる段階で分かってるはずなんだから >>172
わかんねえよ
Xamarin.Formsのwebviewが糞かどうかなんてあらかじめわかんねえよばか 糞が糞であるかどうかの検討なんかしたくないし
糞とかかわりたくない ID:ULNyj/4O
こいつどんだけ無能なんだよ 手元にどんな材料があるかも把握せずに作りたい物が作れるかどうかなんて分かるはずないんだけど >>171
正直Xamarin使ってネイティヴに劣るのってアプリサイズがどうしても肥大しがちなぐらいだろ。
他でまともなのが作れないのは無能だからだよ、 >>169
べつにFormsが絶対悪ってこたあない
分かった上で使えってだけ
技術検証の時点で前述の三回実装が大発生する事に想像が及ばないはずは無い
分かった上でForms先行投資に腰を据えるか、モデル共通化程度にハードル下げてXamarin.Nativeやるか、Xamarinやめるかのどれかだろ 結局、Xamarin.Formsで試作してダメなことを確認して、Xamarin.Android, Xamarin.iOSで実装するんだよね
ダメなことを確認するための無駄な検証作業はやらず、最初からXamarin.Forms捨てた方が正しくない？
「分かった上でForms先行投資に腰を据える」に何のメリットがあるんだろう あと、UIは最初はテキトーでいいけど、完成度を詰めて行くにつれて要件が変わっていくから
最初はXamarin.Formsで凌げてたけど、やっぱりダメだわってなることがあるんだよねぇ
「分かった上でForms先行投資に腰を据える」は
「(後から痛い目を見る可能性があることを)分かった上でForms先行(の開発)投資に腰を据える」って意味かな
Formsは予算がたくさんないと無理だなって思った。 結局君自身が何を作りたいのか正確に理解できていないんだろ
プログラム書き始める以前の問題 いや、だからさ、、、
Xamarin.Formsで作れるかどうかを検証するための予算を用意しないとダメでしょ
これを個人の問題だと思えるのなら、日曜プログラミングでしか考えてない随分遠い話だよ formsで作れるかどうかの検証ってネイティブで作る場合にどんなライブラリ使うべきかの調査、
もしくはそもそもそんなライブラリあるのか自作しなきゃならないのか調べるのと同等でしょ >>181
要件が変わったら当初の予算からずれるのは当たり前。
地元の中小企業相手ならのまざる負えない時もあるが、基本的には要件が変わった時の取り決めも契約書に書いているだろ。
なにもXamarinに限った事じゃない。 うむ、だから.Formsやるなら大目に予算を用意しておこうってことだよな
.Forms先行試作してダメだったら、.Android, .iOSで作り直す訳だし、
最初から.Android, .iOSで作るより予算を多めにしておかないと赤字になる可能性がある ■ このスレッドは過去ログ倉庫に格納されています
