Xamarin Part6
レス数が1000を超えています。これ以上書き込みはできません。
!extend:on:vvvvv:1000:512
C#を用いてクロスプラットフォームアプリケーション（iOS Android Mac）を
を開発するためのライブラリおよび開発環境です。
Macの人は Xamarin Studio、Winの人は Visual Studioで開発できるよ！
公式
http://xamarin.com/
前スレ
Xamarin Part5 [無断転載禁止]c2ch.net
http://mevius.5ch.net/test/read.cgi/tech/1498575762/1
煽りはスルー推奨
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured Xamarin程の糞はない
C#も10年前の時代遅れの言語だし圧倒的にswift,Java,Kotlinの方が人気が高いし求人も多い
VS for Macはgitでブランチを切り替えたりするだけでビルドできなくなって、
クリーン、リビルド、ＩＤＥ再起動、ＰＣ再起動を頻繁に繰り返さないといけなくなるのが糞
大体MicrosoftはWindowsPhoneのシェアを二桁取ってからモノを言えと言いたい
MicrosoftがやっていることはGoogleやAppleの作ったパイを横取りしようとしているだけ
MVVM前提の開発環境とか言うくせに外部ライブラリを入れないと良い感じでMVVMできないし
MVVMを推奨するならデフォルトで必要なライブラリなど全て入れた状態で配布しろ
ＵＩは共通化できると言うわりにListViewは重くてスワイプがもたついたり画像の表示が遅かったりする
スマホアプリの最も基本的なUIであるListViewすらまともに動かないとか糞
Xamarin.Formsはちょっと複雑なことしようとするとお得意のdependency serviceとcustom rendererの連発
クロスプラットフォームと言うならXamarin.Formsだけでできないことを恥じろよ
WebViewなどXamarin.Formsの提供するUI部品が糞すぎて
一旦Xamarin.Formsの提供する機能で実装して糞な思いをさせられた後で
Xamarin.AndroidとXamarin.iOSで計3回も同じ実装をさせられるのが糞
Xamarinなんてマイナーな環境使っている人が少ないせいでググって調べものするのに時間がかかるのが糞
qiitaやstackoverflowの情報もXamarinに関するものはAndroidの10分の1以下の投稿しかなくて
下手すると解決策が見つからなくてデザインや機能の面で妥協する結果となる
任天堂のXamarin製アプリもカブドットコムのXamarin製アプリも星平均3.0の糞アプリ認定されてる
エンジニアもデザイナーもお客さんも全員がっかりするのがXamarin
結論としてXamarinを使うと開発工数は伸びアプリのクオリティは落ちるということ
XamarinをやっているやつというのはC#の機能を使うことやXamarinを使うことそれ自体が目的化していて
お客さんに良いものを届けたいという意思が存在していない
ソフトウェアを作るということは価値のあるものを世の中に提供して世の中をもっといい場所にするために
行われることであるべきで、完全に自分本位でゴミを量産し続けるXamarinエンジニアは全員死んだ方が良い Xamarin程の糞はない
C#も10年前の時代遅れの言語だし圧倒的にswift,Java,Kotlinの方が人気が高いし求人も多い
VS for Macはgitでブランチを切り替えたりするだけでビルドできなくなって、
クリーン、リビルド、ＩＤＥ再起動、ＰＣ再起動を頻繁に繰り返さないといけなくなるのが糞
大体MicrosoftはWindowsPhoneのシェアを二桁取ってからモノを言えと言いたい
MicrosoftがやっていることはGoogleやAppleの作ったパイを横取りしようとしているだけ
MVVM前提の開発環境とか言うくせに外部ライブラリを入れないと良い感じでMVVMできないし
MVVMを推奨するならデフォルトで必要なライブラリなど全て入れた状態で配布しろ
ＵＩは共通化できると言うわりにListViewは重くてスワイプがもたついたり画像の表示が遅かったりする
スマホアプリの最も基本的なUIであるListViewすらまともに動かないとか糞
Xamarin.Formsはちょっと複雑なことしようとするとお得意のdependency serviceとcustom rendererの連発
クロスプラットフォームと言うならXamarin.Formsだけでできないことを恥じろよ
WebViewなどXamarin.Formsの提供するUI部品が糞すぎて
一旦Xamarin.Formsの提供する機能で実装して糞な思いをさせられた後で
Xamarin.AndroidとXamarin.iOSで計3回も同じ実装をさせられるのが糞
Xamarinなんてマイナーな環境使っている人が少ないせいでググって調べものするのに時間がかかるのが糞
qiitaやstackoverflowの情報もXamarinに関するものはAndroidの10分の1以下の投稿しかなくて
下手すると解決策が見つからなくてデザインや機能の面で妥協する結果となる
任天堂のXamarin製アプリもカブドットコムのXamarin製アプリも星平均3.0の糞アプリ認定されてる
MicrosoftのAndroid向けedgeブラウザもXamarin製じゃない
Microsoftも糞認定して使わない糞開発環境がXamarin
エンジニアもデザイナーもお客さんも全員がっかりするのがXamarin
結論としてXamarinを使うと開発工数は伸びアプリのクオリティは落ちるということ
XamarinをやっているやつというのはC#の機能を使うことやXamarinを使うことそれ自体が目的化していて
お客さんに良いものを届けたいという意思が存在していない
ソフトウェアを作るということは価値のあるものを世の中に提供して世の中をもっといい場所にするために Xamarin程の糞はない
C#も10年前の時代遅れの言語だし圧倒的にswift,Java,Kotlinの方が人気が高いし求人も多い
VS for Macはgitでブランチを切り替えたりするだけでビルドできなくなって、
クリーン、リビルド、ＩＤＥ再起動、ＰＣ再起動を頻繁に繰り返さないといけなくなるのが糞
大体MicrosoftはWindowsPhoneのシェアを二桁取ってからモノを言えと言いたい
MicrosoftがやっていることはGoogleやAppleの作ったパイを横取りしようとしているだけ
MVVM前提の開発環境とか言うくせに外部ライブラリを入れないと良い感じでMVVMできないのが糞
ＵＩは共通化できると言うわりにListViewは重くてスワイプがもたついたり画像の表示が遅かったりするのが糞
Xamarin.Formsはちょっと複雑なことしようとするとお得意のdependency serviceとcustom rendererの連発
クロスプラットフォームと言うならXamarin.Formsだけでできないことを恥じろよ
WebViewなどXamarin.Formsの提供するUI部品が糞すぎて
一旦Xamarin.Formsの提供する機能で実装して糞な思いをさせられた後で
Xamarin.AndroidとXamarin.iOSで計3回も同じ実装をさせられるのが糞
Xamarinなんてマイナーな環境使っている人が少ないせいでググって調べものするのに時間がかかるのが糞
qiitaやstackoverflowの情報もXamarinに関するものはAndroidの10分の1以下の投稿しかなくて
下手すると解決策が見つからなくてデザインや機能の面で妥協する結果となる
任天堂のXamarin製アプリもカブドットコムのXamarin製アプリも星平均3.0の糞アプリ認定されてる
MicrosoftのAndroid向けedgeブラウザもXamarin製でなく、
Microsoft自身も糞認定して使わない糞開発環境がXamarin
エンジニアもデザイナーもお客さんも全員がっかりするのがXamarin
結論としてXamarinを使うと開発工数は伸びアプリのクオリティは落ちるということ
XamarinをやっているやつというのはC#の機能を使うことやXamarinを使うことそれ自体が目的化していて
お客さんに良いものを届けたいという意思が存在していない
ソフトウェアを作るということは価値のあるものを世の中に提供して世の中をもっといい場所にするために
行われることであるべきで、完全に自分本位でゴミを量産し続けるXamarinエンジニアは全員死んだ方が良い C++相談室から誘導されてきました、質問させて下さい
VS2017のC++/WinRTで新しいプロジェクトを作成
（Visual C++ → Windowsユニバーサル → 単体テストアプリ）
実行すると TEST APP 、Unit Test 、Tests Running の３つの文字が出てくるウィンドウが出てきます
しかし、UnitTestApp.xaml の Application要素の中身は、空っぽです
新しくブランクページを作ると、Page要素になって、デザインできる上にボタン等を貼り付けると
Page要素の中に要素が作られます
Application要素の中身は一体どこにあるのでしょう？ VisualStudioみたいな糞でやるからそうなる >>26
XamarineはC#でのプラットフォームなんだが・・・ >>27読んでｇｇったんですけど、そうですよね・・・
C++で、UWPで、Win32寄りの処理をゴリゴリ実行したかったんですけど、
こっちでも質問を取り下げて、自分でちょいと追ってみます、失礼しました >>30
なんかビジネス的な話ばっかりで不安だったのですが・・・
そちらに行ってみます、ありがとうございました まあでもXamarinやC#よりいいのってないからね 普段はWindows
ついでにスマホでって時には良いね。
本気でアプリ組むならAndroid Studioに行った方が良いんだろう。 Android StudioじゃiOS開発できないんだよ そういう怠け心がアプリのクオリティの質を下げるんだ
君は本当に人間として軽蔑すべき低俗なエンジニアだな >>38
逆だ。
細かな動作の違いを考えなくて済む分、UIや処理にリソースを割けられる。 いかに単純作業を減らすか考えられない奴はプログラマーとして適性がないと思う 作ってるけど、全部非公開だからな。
顧客には評判いいよ。 業務用の糞UIのアプリだろ
つまらなそうな仕事だな 途中送信
B2Cって恐ろしい民度の顧客を相手にするつらい仕事なイメージ うん
AppStore の不調でダウンロードできないとかの苦情もレビューに書かれる 例えばボタンを押した時に動的にビューを追加するとチラついたような汚い描画になるけど、これってネイティブでもそういうもんなの？
どうしたら一瞬でパッと表示されるの？ >>50
UWP?Android?iOS?
iOSは環境が無いから試せないが、UWPもAndroidもチラついたりしないが？ みんなはなってないのか
なんでだろう。パーツごとにコントロールとして定義しまくっててStackLayoutとかのネストが深くなってるからかも
ちなみにAndroidとiOSで起きてる。他はターゲットにしてない Xamarinなんてマイナーな環境使っている人が少ないせいでググって調べものするのに時間がかかるのが糞
qiitaやstackoverflowの情報もXamarinに関するものはAndroidの10分の1以下の投稿しかなくて
下手すると解決策が見つからなくてデザインや機能の面で妥協する結果となる API 一緒なんだから Android と iOS の情報見たらいいじゃん？ OSと開発フレームワークの検索ヒット数を比較する馬鹿
比較対象は同格のものでないと無意味って教わったことないかな 過去何度も意味がないと諭されても理解しない左巻きだから無駄。
無視が一番。 >>57
だってAndroidとiPhoneを平気で比較する世の中だから。 API一緒とか言ってる奴は実際に使い込んでないだろ
AndroidはともかくiOSの方はかなり変わってるから、対応するXamarinの関数探すのに苦労した
CMTimeとか AndroidとiOSのAPIが一緒なわけ無いだろ。
APIが一緒というのは、AndroidネイティブのAPIと、Xamarin経由でアクセスするためのAPIが１対１になっているという意味だろ。 >>64
そういう意味じゃなくてiOSの方はAPIの名前が元のものと変わりすぎてわかりにくいってことだろさ >>64
基本英語で検索してる
おれは CMTimeMakeWithSeconds() をXamarinで使いたかったんだけど、
検索すると Xamarin では CMTimeクラスのFromSeconds() メソッドが同じような機能を提供してるらしいことがわかる
ただ名前が違うし同じかどうか確信がもてないのでリファレンスを調べてみたけどろくな説明も無し
https://developer.xamarin.com/api/member/MonoTouch.CoreMedia.CMTime.FromSeconds/p/System.Double/System.Int32/
しょうがないのでXamarinのソースを調べて FromSeconds() の中でネイティブの CMTimeMakeWithSeconds() を呼んでることを確認しましたとさ
なんでこんな阿保な変更してるの？ >>67
ObjectiveC流の命名規則をC#流の命名規則に変換してるだけじゃん
ものすごく分かりやすい まぁでも検索しやすいように
○○から□□に変換しました〜
くらいはドキュメントに書いてあってもいいかもね >>68
C#もObjectiveCも知ってなきゃ理解できないAPIとか流石だな
それじゃ CMTimeMakeWithEpoch()は、FromEpoch()になるのか？見当たらんが
CMTimeMakeFromDictionary()はそのままFromDictionary()なのはどういう理屈？ CMTimeMakeWithEpochはCMTimeのコンストラクタだな
ちょっと公式ドキュメント見たらすぐ分かるね XamarinのCMTimeの公式リファレンスはこれが書いてあるだけで、
CMTime(Int64, Int32, Int64)
クリックしてようやく CMTimeMakeWithEpoch() と同じ引数でCMTimeを返すコンストラクタなことがわかる
public CMTime (Int64 value, Int32 timescale, Int64 epoch)
でも引数同じだからって同じCMTimeを返すとは限らないんだよな
リファレンスには説明無いし
Xamarinのソース見ても同じなのかはっきりしない
CMTimeの中身見ると、まあたぶん同じなんだろうなって推測できるレベル 分からんでもない
API仕様とGitHubを読み込むのが必須になってるのが面倒
スクリプト言語だと、フレームワークや外部ライブラリ含めてソースコード全部が手元にある状態だから、ステップ実行しながら手元のコードを読むだけで大半の問題が解決する
少なくとも、実装仕様の確認のためにブラウザを開くなんて手間は無い
コンパイル言語の開発者用に、ソース付きのパッケージ配布の仕組みが欲しい >>70
iOSのAPI使うならObjectiveCは理解してなきゃ駄目だろ。
同じくXamarin使うならC＃を理解してなきゃ駄目だろ。
自分の勉強不足を棚に上げて文句言うんじゃないの。 C#とObjectiveCを両方知ってないとAPIの検索もままならない状況は糞だね
XamarinのAPIリファレンスが手抜き過ぎ >>77
APIを直接たたくようなアプリなら、APIがベースとしている言語の知識が必要なのはXamarinに限った事では無い。
APIを意識しなくても良いレベルのアプリならC#だけの知識で十分だぞ。
つか、糞だと思っているものに粘着とか、ンコ蠅だね。 >>79
XamarinがオリジナルのAPIを改変しているにも関わらずそこを文章化して無いのが問題なんだよ
元のAPIをそのまま呼べるなら問題無い >>80
>>68
言語の規則に合わせて変更しているだけ。
堂々巡りになっているのがわからんか？ >>81
お前もお前で意固地だな
対応表ぐらいあったほうがいいに決まってる ID:Jb/o6d5C0
こいつほどの糞はいない。擁護しようと必死で理屈なんかない。もしかして、姫の僕か？ >>81
withSecondsがfromSecondsになって
withEpochがコンストラクタになる理由を説明してくれ xamarinでバーコードリーダー入れたいんだが
Uncaught Exception
Exception of type
'System.Collections.Generic.KeyNotFoundException' was thrown.
(KeyNotFoundException)
って出たんだが分かるやつおらんかね >>85
言語の規則だって言うのならどういう規則なのか説明しろと言っている
規則へのリンクでもいいぞ >>86
エラー表示のままだろ
dictionary型などで参照しようとしてるキーが存在しないものになってる 多分規則というかBCLか.net frameworkに寄せただけだと思う
書いた人には思惑があるのかもしれないけどわからない
make withって英語的にどうなのって思う >>89
言われるがままにinfo.plistってのにkeyを追加したはずなんだがな
カメラへのアクセス許可を求める処理なんだがやはり無いと言われる 私はZXing.iOSでバーコードスキャンできてるからXamarinのせいではないと思いますよ >>91
デバイスにアクセスできないんじゃね？
つか、参考にしたページとソースを開示したほうが早いんじゃね？ >>91
エラーを見る限り、設定したキーのスペルをミスっているんじゃね
例えば大文字小文字とか ああ、カメラ機能を使うときに一度は通る道だなｗ
まぁ、がんがれ おぉ！皆ありがとう
まずはアドバイスを参考にまたにらめっこしてみてどうしようもなくなったら戻ってくるわ 連投ですまんが実行にはXamarin Live Player使ってる
まだ不安定だから動かないってのもあるかな >>99
visual studioはpreview版つかってんの？
community版ではうまくビルドできてないと感じて俺もiOSは諦めてる
この前までpreview版使ってたんだけど
SSDの空き容量がなくなって新しいのにクリーンインストールした時に
communityに戻してからXamarin Live Playerではまともにビルドできたことないわ
まあ俺が雑魚ってのもあるんだけど >>99
自分はWindows+Macだけど仕事で開発中のアプリはZXing使って問題ないからまあlive playerの問題だろうね visual studioはcommunity版だね
Live Playerの問題なら諦めるしかないな…
学生のお遊びプログラミングだから割りきる所は割りきるよ
答えてくれた皆さんありがとうございました VSでツール→オプション→Xamarin→その他から更新プログラムを今すぐ確認で、
ダウンロードしてインストールをするにしても、インストーラーが立ち上がりません。
管理者権限で実行しても同じです。
入れなおす以外で試してみたらというのないでしょうか？ Xamarinみたいな糞は捨ててネイティブでやった方がいいぞ >>103
Visual Studio Installerを実行する これから使おうと思ってる人は、配布用パッケージすら作っていないようなブログや書籍がXamarinが「使える」って言っていても信用しないこっちゃ >>106
ん？
配布用のipaやapkは作れるが 開発者モードってXamarinで開発するときのみでそれ以外は切っておいた方がいいですかね 君らがXamarinにかけてきた時間とエネルギーは完全に無駄だったってことだ xamarinの大きなメリットはクロスプラットフォームでありながら過去の.Netのライブラリが使えることであって KotlinのiOS対応ってXamarinで言うところのXamarin.Forms？それともXamarin.iOS？ KotlinてかintelMoeか
Android側からのアプローチは珍しいな
しかし... macos 10.13 でADVが動かない
だれか助けてほしいです
若干スレチごめん kotlin/native言うヤツっぽいから、昔あったRoboVMみたいな？
まあ、ここでする話じゃないっすね Xamarinに自信が持てないからKotlinのことが気になってしょうがないんだなｗｗｗざっこｗｗｗｗｗｗ 自分の能力に自信が持てないから周りの反応のことが気になってしょうがないんだなｗｗｗざっこｗｗｗｗｗｗ>>120 XamarinはMicrosoftが買ったというだけで本気でリソース投入してないからね
そりゃあKotlinの方が未来がある 少なくとも今のところはkotlinのクロスプラットフォーム対応では共通化したい部分のライブラリをほとんど自作する必要があって、
Xamarinではそういったライブラリの中でも特に頻繁に使われるものが.Net Standardとして定義されている
つまり.Net Standard相当の質と量のライブラリが提供されない限りはXamarinの方が優位と言っていいよ kotlinは嫌いじゃないけど.netライブラリ使えないと死ぬ病です 道具として便利だと思うものを使えばいいんだから
使い易ければ使う、使いにくければ使わない、でいいのに
アンチと擁護繰り返す必要奴らは何がしたいのかわからない
まぁ2chの日常風景なんだけど
俺は今んとこ面白そうだから使ってる
もっといい物が出てきたら当然そっちを使う
ただそれだけ 少なくともこのスレにおいてアンチは非論理的、擁護は論理的なのでどっちを信用すればいいかは明白 Xam.Plugin.Mediaを利用してカメラのプレビュー画像を取得することはできますか？
もし可能であれば方法をご教授願いたいです。 まず自分の書き込みを見直してアホな間違いを修正
それからググれやカス >>129
試してないけどここにまるっと書いてるんじゃないの
ttp://blog.okazuki.jp/entry/2016/11/21/155911
>>130
えらい荒ぶっとるな >>132
単なる静止画撮影じゃなくて撮影前段階でのプレビュー画像をリアルタイムで欲しいんだと思うよ
俺はそのプラグインだと無理だと思ってるけど >>134
なるほど
家計簿アプリにあるようなアプリ中で撮影して画像に残さない方法のことか ググればqiitaに作った例があるけどそれじゃ嫌なんだろう 君らがXamarinにかけてきた時間は無駄だったということだし、
君らの人生そのものが無駄だったということだ
はよKotlinにごめんなさいしてキャリアチェンジした方がええんちゃうの？ｗｗｗｗ .Net Frameworkによってほぼ全てのプログラミング領域はカバーされているわけでして Microsoftとかオワコンの過去の会社や
これからはGoogle, JetBrainsが世の中を創っていく .netがオープンソースになってる時代に何言ってるの？ ルビのテキスト表示したいんだけど、WebView使ってHtmlで表示するのが一番簡単そうなんだけど、
他に良い方法ありますかね？ >>142
プルリク送るどころかソースも見たことないくせにｗｗｗ アンチMSで凝り固まってるくせにこのスレに来てるような奴は放置で むしろMSも.NET Standardなど使って書いたものがそのままブラウザで動くような方向に持ってく気がするんだが。 >>146
モバイルもPCもブラウザシェア持ってないのに。 ブラウザに内蔵してもしょうがないでしょ
実験的にはblazorとかそっちの方向 >>149,150
いやブラウザ改変じゃなくてライブラリとして書いたものがWebAssemblyなりになってフロントのjsとつながるって事やで？ GoogleがMicrosoftのTypeScriptを積極採用してるんだよなぁ >>137
糞みたいな内容だな
意味の分からないﾄﾞﾔに付き合うほど馬鹿じゃない >>151
知ってる。
Webの世界で勝ててないのに勝てると思わないわ。
シェア取らないと力になりえない。 >>154
シェアその場合関係あるの？
必要なのはMSツールチェーン上で一度書いたらいろんなところで動かせるって話と思うが。
、 プラットフォームで縛る時代はもう終わりでしょ
このニュースなんか個人的にはむしろ好意的に見てる
http://news.mynavi.jp/news/2017/11/06/117/ Visual StudioのXamarinで、 .NET Framework のバージョンを確認する方法ってどのようにすればよいでしょうか？
Xamarin Studioでの確認方法は書いてあったのですが、VSがわからないです。。
https://chomado.com/note/tech/how-you-check-dotnet-version-in-xamarin-s そもそも.NET Frameworkではないのでは >>158
.NET Frameworkのどのバージョン相当という意味なのでしょうか。
リンク先のxamarin studioには書いてあったので、同じようなものがあるのかと思いました。 >>160
レスありがとうございます。
ただ、ソリューションのプロパティにも、xxx.Androidのプロパティにもそれらしきものは見当たらないですが、もっと別のとこでしょうか。 >>156
×プラットフォームで縛る時代はもう終わり
○マイクソに縛られる時代はもう終わり 利用してるだけで縛られてるわけじゃないんだよなあ
どうしても変えたい部分があれば好きに変えればいいわけだし >>162
それでアンドロイドとGAEに縛られるのか。 Xamarin程の糞はない
C#も10年前の時代遅れの言語だし圧倒的にswift,Java,Kotlinの方が人気が高いし求人も多い
VS for Macはgitでブランチを切り替えたりするだけでビルドできなくなって、
クリーン、リビルド、ＩＤＥ再起動、ＰＣ再起動を頻繁に繰り返さないといけなくなるのが糞
大体MicrosoftはWindowsPhoneのシェアを二桁取ってからモノを言えと言いたい
MicrosoftがやっていることはGoogleやAppleの作ったパイを横取りしようとしているだけ
MVVM前提の開発環境とか言うくせに外部ライブラリを入れないと良い感じでMVVMできないのが糞
ＵＩは共通化できると言うわりにListViewは重くてスワイプがもたついたり画像の表示が遅かったりするのが糞
Xamarin.Formsはちょっと複雑なことしようとするとお得意のdependency serviceとcustom rendererの連発
クロスプラットフォームと言うならXamarin.Formsだけでできないことを恥じろよ
WebViewなどXamarin.Formsの提供するUI部品が糞すぎて
一旦Xamarin.Formsの提供する機能で実装して糞な思いをさせられた後で
Xamarin.AndroidとXamarin.iOSで計3回も同じ実装をさせられるのが糞
Xamarinなんてマイナーな環境使っている人が少ないせいでググって調べものするのに時間がかかるのが糞
qiitaやstackoverflowの情報もXamarinに関するものはAndroidの10分の1以下の投稿しかなくて
下手すると解決策が見つからなくてデザインや機能の面で妥協する結果となる
任天堂のXamarin製アプリもカブドットコムのXamarin製アプリも星平均3.0の糞アプリ認定されてる
MicrosoftのAndroid向けedgeブラウザもXamarin製でなく、
Microsoft自身も糞認定して使わない糞開発環境がXamarin
エンジニアもデザイナーもお客さんも全員がっかりするのがXamarin
結論としてXamarinを使うと開発工数は伸びアプリのクオリティは落ちるということ
XamarinをやっているやつというのはC#の機能を使うことやXamarinを使うことそれ自体が目的化していて
お客さんに良いものを届けたいという意思が存在していない
ソフトウェアを作るということは価値のあるものを世の中に提供して世の中をもっといい場所にするために
行われることであるべきで、完全に自分本位でゴミを量産し続けるXamarinエンジニアは全員死んだ方が良い プルリクはともかく、ソース読まずに開発は無理だわ
一番参考になる手堅い実装例だし
MSのソースが読めるとか、いい時代になったなあ >>161
VisualStudioのヘルプ→バージョン、だったか？で
モジュールごとのバージョンが見れたはず >>167
言わんとすることはわかるが読んでよかったと思うシチュ何？
自分は挙動が意味不だったときに読んだけど普段はそんな読まない MSのソースで全て大文字のプロパティがあって引いた
最初c++のマクロかと思った >>170
突っかかってんじゃなくて疑問に思ったから聞いてるだけだろ VSでコンパイルに使ったxamarinバージョンってヘルプから見るしかないのでしょうか？
ヘルプから見ると後から見たときにコンパイルに使ったバージョンってわけでもない気がするのですが、ビルド後のファイルとかプロジェクトファイルには記載されませんか。 >>169
んー、直近だとAsp.NetCoreでDIの実装例見たりIdentityの挙動を追ったり
Xamarinだと、ネイティブのAPI呼び出し箇所を見て使い方把握、とか >>176
Xamarin限らず色々どうやってるんだろうって話か。
そゆんではオプソで色々読めるのは良いよね。
勉強する気のあるやつとないやつで差が出るよな。
自分はXamarin.FrmsであるControlの挙動を案件の仕様に合うようにゴニョゴニョしようとしたけどダメで、結局ソース見てレンダラーでやったらあっさりできた。 他人のソースを盗み見して技術を得た気になってるだけの糞 他人を煽り嘲笑して自尊心を満たした気になってるだけの糞 いちいち使いもしない技術のスレに来て勘違いだらけの悪口並べ立ててるやつよりは遥かにマシだよな 無能なので他人のソースコードを見ても参考にできないんです ザマリンすら使えなくて挫折して悪態ついてるぐらいだからさもありなん xamarin formsでスリープさせない仕組みって用意されてる？ 他では通用しない糞みたいなノウハウを蓄積しているだけの糞 xamarinでSQLITE使いたいんですが参考になるサイトありますか？
http://www.buildinsider.net/mobile/xamarintips/0050
xamarin SQLITEで検索して一番上に出てくるサイトを参考にしたら書き方が古いらしく使えませんでした >>188
自分は https://github.com/praeclarum/sqlite-net を使っている。
iOSは環境がないから試してないけど、UWP/Android共に同じライブラリで使えている。
nugetで sqlite-net-pcl で検索すればインストールも手間がかからないよ。 >>189
githubで探すのは気がつかなかった
まだまだ素人ですね…
ありがとうございます Xamarinでやるメリットってサーバー側も.netで作ってるような場合でしょうか >>192
クライアントがだけでも色々共通化できるメリットあるけれど、サーバーも.NETならより共通化や親しんだ言語での開発を享受できるかと >>193
いろいろ多くてすみません。
共通化というのはAndroid/iOS/windowsで共通コードになるということでしょうか？
サーバとより共通化というのは具体的にどう共通化されるのでしょうか？ クライアント側ではビジネスロジック的なものは基本的にほぼ全て共通化できる。
UIも凝ったものでなければかなりの部分を共通化できる。
サーバーとの共通化はビジネスロジックやライブラリなどで共通化できそうなものがあればですかね。 >>194
クライアント用ミドルウェアでサーバーの何を書くんだよ
アホは黙れや、低悩 >>196
安価を間違えた上に色々勘違いしてるバカがw ユーティリティ的なモノは共通化できるけど嬉しいかと言われればそれほどでもない
作りによるんじゃね？ クライアント Xamarin
サーバー ASP.NET >>198
まあサーバーとの共通化はそんなにないと思われ
ASP MVC見たいのもやるならビジネスロジックの一部とかPOCOの定義、ユーティリティの一部とかかね。
基本は言語とか開発環境を全く別のものにしなくていいってとこだろうね バリデーション共通化できると良いね。やったことないけど xamarinってvs2017 ProがあればFull機能を無償で使えるの? >>202
proでもcommunityでも全機能使える >>203
そうなのか、ありがとう！
日本語の情報が無さそうだけどCordovaより良いかな。 >>202
APIの制限とかは無いけど、ツール面では多少違いがあるよ。
iOSのエミュレーターをWindowsのパソコンで確認できるのはEnterpriseだけのはず Android SDK/Javaの知識がある程度ないと辛いかな。
wpf/c#は不自由なく使えるのでxamarin良いかなと思ってるレベル。 >>212
そうですね^^;
Xamarin.Formsのxamlを調べてみたけどwpf以上に一癖ありそうだw Xamarin.Forms程の糞はない
WebViewなどXamarin.Formsの提供する部品が糞すぎて
一旦Xamarin.Formsの提供する機能で実装して糞な思いをさせられた後で
Xamarin.AndroidとXamarin.iOSで計3回も同じ実装をさせられるのが糞
Xamarin.Formsの共通部品を使えば1回の実装で済むと思って手を出したら3回も同じ実装をやらされる
急がば回れとはこのことである Xamarin.Formsを使うということは最も工数がかかる手法で開発をするということ 任天堂が出したアプリの中で最も星平均が低いのがXamarinで作られたNintendo Switch Onlineアプリである。
任天堂はもともと今年の秋に有料オンラインサービスを開始するとアナウンスしていたのに、
Nintendo Switch Onlineアプリの出来が悪すぎたせいで来年に延期になった。
つまり、Xamarinを使うと開発工数は伸び、アプリのクオリティは落ちるということである。 Microsoftは新規にAndroid版edgeブラウザを開発中とのことである。
Android版のedgeブラウザはXamarin製なんだろうと思いきやAndroidネイティブである
なぜXamarinの提供元がXamarinを使わないのか
Xamarin程の糞はないからである >>223
作る内容によっては最も効率が良い方法と思うが。
LOBアプリなら十分だしよっぽど凝ったものでもなければレンダラーとかで対応可能。
各プラットフォームの画面作りに慣れてるならロジックの共通化だけにしといた方が混乱はないかもなのは認める >>215
本当にこれやってる奴いたらあまりに無能すぎて仕事打ち切りたいレベルだな >>223
C#、XAML派から参入ならそれだろ。 AWSからAzureに移った感想
ttps://qiita.com/kuri_hei/items/0a396b3646febe7efcbb 新規でも皆formsのイメージがあるわ
XAMLって何出来るん？バインディングってformsでも出来るんでしょ？ >>229
そうなんだ
XAMLってバインディングが売りって聞いたが違かったか >>230
お前はなんのFormsの話をしてるんだ。 MVVM周りはほぼWPFと同じに書けて楽しい
各Trigger使えるのもうれしい 時代はfluxなのに未だにMVVMとかいう原始時代の設計手法に頼っているとかMicrosoftはオワコン 糞の人の罵倒芸がだんだん楽しくなってきた
次は何がくるやろ 検索したら>>239でやっと4パターン目
この10倍はほしいところ Xamarin Studioか、Visual Studio for Xamarin どちらを使う方がよいでしょうか？ >>242
Xamarin StudioはVisual Studioになってるから質問の意図が分からない >>242
開発環境なら使うOSによって決まるかな。MS公式に縛るならだけど。
Windows: Visual Studio 2017（2015でもいける）
Mac: Visual Studio for Mac VS for Macはgitでブランチを切り替えたり、NuGetパッケージをインストール/アンインストールしたりするだけでビルドできなくなって、
クリーン、リビルド、ＩＤＥ再起動、ＰＣ再起動を頻繁に繰り返さないといけなくなる
こんな非効率な開発環境では共通化のメリットなど完全に相殺されてしまう xamarinでtabbed pageとcameraを個別に実装できたんですがタブで切り替えた瞬間にカメラを起動するにはどうすればいいのでしょうか？ >>255
おぉなんとかなりそうですね
さっそくやってみます
ありがとうございました Xamarin使えばMac買わなくてもiOSアプリをリリースできるの？ >>259
>>261
ありがとう。できないみたいですね。
Macってスペックの割に高いし汎用性無いしできれば買いたくないんですが、
仕方ないようですね。 >>262
Cordova, Monacaとか使うしかないね ビルドしてくれるサービスはあるけど
実機買った方が手っ取り早い気がする MacinCloudか
これってストアにアプリ置いていたら継続して契約してないと駄目なんかな。 >>262
ブートキャンプでWindows動くし汎用性は特に問題ないけどね XamarinにしてもCordovaやMonacaにしても、最終的にiOSアプリをストアに公開するのであればXcodeが必要
Mac実機がなければどうしようもない >>267
ネイティブコード吐くのは駄目だけどハイブリッドも駄目なの? 顔まあまあ、胸でかい、仕事できる、絵がうまい
完璧やないか カラコンやめたのか？
あれは爬虫類っぽさが増して気持ち悪かった。 自意識過剰な中学生か高校生のような喋り方がとてつもなくキモい
社会人とは思えない
まして世界的企業のPR担当とは・・・ ○○程の糞はないと主張してるけど色々なことに対してそう言ってるね
自分で矛盾に気が付かないのかな 糞は自分自身が糞であることを理解できない
故に矛盾にも気付かない >>283
目頭切開
涙袋形成
鼻プロテーゼ?
顎プロテーゼ?
エラ切除? 初心者質問です。
phpで作ったモバイルサイトをAndroidとiPhoneに作り変える予定なのですが、共通の開発ができるという噂のココに行き着きました。
複雑そうな機能は、カレンダーとQRコード読み込み、phpウェブサイトとのDB共通化(レンタルサーバのDB使用)、なのですが可能でしょうか？
スレ違いでしたらすいません。 Xamarinはクライアントサイドのフレームワークなので、PHPで作成するようなサーバーサイドのサイトの開発とは違うと思うんだけど >>288
c#が自由自在に使いこなせるのならXamarinでも良いけど
知らないのなら難行苦行で荊の道を進むことになる。
Web/Javaの技術に精通しているのなら とちゅうで送信してもた
Web/JavaScriptの技術に精通しているのならCordovaとかのがお勧め。
DBアクセスは、PHPが動いているサーバにWebサービスを作る必要がある。 >>289
返答ありがとうございます。
スマホ開発自体が初めてなので何もかもわからないのですが、、
やりたい事が、サーバサイド(web管理画面)でDB登録した情報を、クライアント(スマホアプリ)が参照したり、その逆も行いたい感じです。
その場合は、クライアント側からサーバ側にあるDBアクセスするファイルを読み込む事で実現できるような事をどこかの記事で読んだ気がします。
もう分からない事が分からないだらけで…何かスマホ入門にオススメの書籍などがあれば紹介して欲しいです… >>293
DB は直読み込みできないから、WebAPI経由で読み書きかな >>291
>>292
返答ありがとうございます。
Cは少しだけ…C#は未知です。
言語はphpが1番得意ですね。Javaはsjc-pは持ってるけど超苦手です。
JavaScriptは大好物なので、教えてもらったソフトを見てみます！ありがとうございます >>294
やはり自分でwebサーバ側にAPI作ってDBアクセスできるようにするしかないですよね…
アプリ側から登録データを送信するのもwebに飛ばさなきゃいけないとか…セキュリティとか色々やばそう… 色々と助言ありがとうございました。
周りに相談できる人がいなくて死にそうになってた所なので助かります。
スレ汚し失礼しましたm(__)m >>296
Monaca(有料)と言うのもある。
無償でも出来るけど無償だと目的としたことは出来ない気がする。
ドキュメントも日本語なのでお勧め。
Monacaは皮だけで中のアンコはCordovaです。 >>299
>>300
ありがとうございます！
どっちも調べて参考にさせてもらいますm(__)m >>297
完全にローカルに閉じたのでよければDBは、SQLiteってのが使えるよ。それなら、Webには何もいらない。 >>303
> やりたい事が、サーバサイド(web管理画面)でDB登録した情報を、クライアント(スマホアプリ)が参照したり、その逆も行いたい感じです。 なんかMBaas使った方が良いのかと思ったけどDB共通化したいのか 今の時代のニーズとしては昼間スマホでさわってた続きを
家のパソコンなりタブレットで続きからやりたいってことが多いだろうから
こういうノウハウを求める人は多いんだろうね
今から何か作りたいと思う人はほぼこれなんじゃないかと思う MonacaとかCordova環境ならアプリ内でPouch立ててLANに居るときにレプリケーションすれば？
Conflictもわかるし。
後々サーバ立てるときもCouch立てるだけだし。
便利。
まあ、あと勝ちで良いならsqliteのDBごと渡すって開き直りもあるかと。 >>312
ハイハイ、それはダマリンね
お疲れ様でした〜 iOSとAndroidでSQLite使おうとしたら開いた瞬間にアプリが強制終了するんだが原因を探すうまい方法ってなんかないかや hockeyappかVisual Studio Mobile Center使って例外発生時のスタックトレース調べるとか その手のやつはそれらのスタックトレース取れない予感 ビルドは通るんだが出るもんなの？
ちなみにMobile Center使ってる >>323
そのHosted macOS agentは自分で用意するんだよ AndroidStudioみたいなのなくてもエミュレータとかで画面みれたりするん？ 結局強制終了はどうもできんのか
今は動くのに戻したりしてるが ログとにらめっこするか、ブレークポイント貼りまくってどこで落ちるのか特定するか・・・ バイナリで落ちるやつとかはセグメントフォールト的なログ出るでしょVSに 素人が簡単なアプリ作るまでを
解りやすく解説してくれてるサイトない？ >>332
どのレベルの初心者だよ。
コマンドから何からすべての解説がほしいのなら、その手の本を買ったほうが良い。 Xamarinは素人、c#は何の不自由もなく使いこなせる
なんてヤツなら自力でなんとかできるw 簡単なアプリ作るレベルなんだからプログラミング自体初心者なんだろう
それならまず言語の文法の基礎から >>332
何作りたいのか知らんがちょまどがMobileAppにつなげたサンプルアプリとかどうよ どの本もいい加減だからその本以外でandroidやiosの知識をつけないとアプリはまともに作れない クロスプラットフォームなのにiOSとAndroidの知識が必要でさらにXamarin特有の知識も求められる 別にXamarin.Formsの範疇で治るLOBアプリとかならほぼいらんだろ
もっと凝りたいやつはそこを調べればいいだけで、むしろ他のクロスプラットフォームだとそこらへんがどうしようもないものとかありそうだが 凝ったことするのに各プラットフォームの専門知識が不要なクロスプラットフォーム開発環境なんて今のところ存在しないよ
モバイル向けでそんなのがあるなら習得したいから教えて欲しい 各プラットフォーム固有の知識は必要だけど全部C#で書けるところがいいよね。
他の言語も読んで意味理解しないといけないから知らないとはいけないけど 各プラットフォーム固有の知識は最初から必要なわけでなく必要になった時に十分対応できる。 で、最近のは インストール後の設定で
どっかの誰かのblogに小さく乗ってるのを見つけないといけないような儀式はなくなった？ Xamarin程の糞はない
C#も10年前の時代遅れの言語だし圧倒的にswift,Java,Kotlinの方が人気が高いし求人も多い
VS for Macはgitでブランチを切り替えたりするだけでビルドできなくなって、
クリーン、リビルド、ＩＤＥ再起動、ＰＣ再起動を頻繁に繰り返さないといけなくなる欠陥品なのが糞
大体MicrosoftはWindowsPhoneのシェアを二桁取ってからモノを言えと言いたい
MicrosoftがやっていることはGoogleやAppleの作ったパイを横取りしようとしているだけ
MVVM前提の開発環境とか言うくせに外部ライブラリを入れないと良い感じでMVVMできないのが糞
ＵＩは共通化できると言うわりにListViewは重くてスワイプがもたついたり画像の表示が遅かったりするのが糞
Xamarin.Formsはちょっと複雑なことしようとするとお得意のdependency serviceとcustom rendererの連発
クロスプラットフォームと言うならXamarin.Formsだけでできないことを恥じろよ
WebViewなどXamarin.Formsの提供するUI部品が糞すぎて
一旦Xamarin.Formsの提供する機能で実装して糞な思いをさせられた後で
Xamarin.AndroidとXamarin.iOSで計3回も同じ実装をさせられるのが糞
Xamarinなんてマイナーな環境使っている人が少ないせいでググって調べものするのに時間がかかるのが糞
qiitaやstackoverflowの情報もXamarinに関するものはAndroidの10分の1以下の投稿しかなくて
下手すると解決策が見つからなくてデザインや機能の面で妥協する結果となる
任天堂のXamarin製アプリもカブドットコムのXamarin製アプリも星平均3.0の糞アプリ認定されてる
MicrosoftのAndroid向けedgeブラウザもXamarin製でなく、
Microsoft自身も糞認定して使わない糞開発環境がXamarin
エンジニアもデザイナーもお客さんも全員がっかりするのがXamarin
結論としてXamarinを使うと開発工数は伸びアプリのクオリティは落ちるということ
XamarinをやっているやつというのはC#の機能を使うことやXamarinを使うことそれ自体が目的化していて
お客さんに良いものを届けたいという意思が存在していない
ソフトウェアを作るということは価値のあるものを世の中に提供して世の中をもっといい場所にするために
行われることであるべきで、完全に自分本位でゴミを量産し続けるXamarinエンジニアは全員死んだ方が良い Xamarinやっている奴ほどの人格破綻者はいない 人格破綻者 : (ﾜｯﾁｮｲ 9f81-F7Qh) 自分が使いもしないものにわざわざ粘着して文句言い続けるような人格破綻者がいるらしい SQLiteでorder byを使うと強制終了するんだがなにが悪いんだろうか
実行SQL "SELECT * FROM [User] order by [Id] desc"
[PrimaryKey,AutoIncrement]
int Id
string Name
User表の中身
Id Name
1 鈴木
2 田中
3 斎藤
Xamarinで失敗するからこっちにきたがスレチなら誘導をば >>359
強制終了なんて曖昧な書き方するやつに
誘導するスレなんか無い >>360
すまない、強制終了は曖昧な書き方なのか
拾ってきました no such column: Id no such column: Id
Idカラムが無いとご立腹であるが Nameだとできるからなにか仕様的な理由があるのかと来てみた >>364
ワカランネ
大文字、小文字が識別されてるとか
カギ括弧とっても同じかな >>365
データタイプかユニークキーかどうか、それが自動生成かどうかなどかね。
しんきでつくってみてもおなじげんしょうがでるかなどみてみ。
似たような現象ググれば出てくんじゃねーの。英語で。 どうやらprimary keyで行うと駄目みたいです…
ご協力ありがとうございました >>368
すまない、解決した
主キー使うと駄目みたい ちょまどさんを養うだけでなく
結構ガチで役立ってるのかね？
いまいちよくわからん >>371
やっと回答に気付いた人が来た
笑えるよな XamarinをやっているやつというのはC#の機能を使うことやXamarinを使うことそれ自体が目的化していて
お客さんに良いものを届けたいという意思が存在していない
ソフトウェアを作るということは価値のあるものを世の中に提供して世の中をもっといい場所にするために
行われることであるべきで、完全に自分本位でゴミを量産し続けるXamarinエンジニアは全員死んだ方が良い Xamarinがって手段にこだわってる自体言っている事と矛盾してるけどなw 良いものを届けるために無駄な二重作業を排除してやるべきことに集中するのがクロスプラットフォーム開発をする根本的な理由でしょ まあ実際アプリの基本ロジックはほぼ100％共通化してるわ。
UIでタブバーこういう風に表示してとか要求あるとレンダラとかでゴニョゴニョすることもあるけど基本的にライブラリ層にそれも押し込むしな >>378
無能馬鹿は何が共通ロジックとなるか切り分けできないんだよ VSやXamarinは道具。
技術のあるものが使えば良いものが作れる。
公開されているものの出来が悪いからいって、ツールが悪いといいきるのは思慮が足りない。 Xamarin使おうと思っている人のスレだから、Xamarinがどうだこうだと言ってもな
そういのは、Damarin 技術のあるものがXamarinを使って作った良いアプリってどれなんすかね
星4.5以上のXamarin製アプリはよ 利用者は何で作られてるなんて気にしてないし、
Xamarinですって書いた有るわけじゃないから
わからんよね。 開発するわけない人がなぜわざわざ書き込んでるんでしょうね Google Play で Xamarin で検索すれば結構出るね。
当然星５もあるし、星１もある。
作り手の技術次第という、アタリマエのことが実証されているわけだ。 Xamarinが糞であるという正しい情報を世に伝えるため
若者がXamarinという糞で時間を無駄にしないようにするため sampleとかdemoとかtutorialのアプリしかでねえじゃねえか NHK紅白のスマホアプリは今年もXamarinだろ Xamarin終了のお知らせ
Apple will reject apps created from app generation services like Xamarin in 2018
https://twitter.com/jzeferin0/status/942754863083114502 言葉通りに解釈するとすべてを排除するようだけどMonacaとかCocosまで切るつもりなのか?
イマイチ意図がよく分からんな 名指しされているのはXamarin、PhoneGap、Appcelerator、Trillian
実はXamarinよくわかっていないのだが他の3つはもっとわからない
PhoneGapが駄目ということはCordovaも駄目なのかな Twitter垢持ってない同僚にきたメールのスクショがソースとかｗｗｗ
本当なら他の開発者にもメールきてるやろ 親愛なる○○へ
2016/9/1、現行のApp Storeのアプリ評価・削除プロセスは最早想定通りに機能しておらず、
現在のガイドラインにも則っていない、もしくは時代遅れのものであるとアナウンスしました。
・・・
2018/1/1以降、商用テンプレートまたはアプリ生成サービスにより作成されたアプリはリジェクトされます。
2019年上旬からはXamarin,PhoneGap,Appcelerator,Trillianといったソフトやプラットフォームで作成された新規アプリはリジェクトされます。 FAKEの意図はともかく、12月にメールが来て、翌1月から規制とか無いから。 事実だとしたら他にも同様の連絡受けてるはずだし当然大ニュースになってるはずだからフェイクでしょ そう、このときはみんなそう思っていたのだ
しかしこれが後にあんなことになるとは…… これでObjC、swiftでしか開発できないとかなったらどうすん。
Unityとかも潰すのか？ そのツイート主のblogだろ？
確認もせずに流したアホなだけ
ほんとバカッターとはよく言ったよな 少なくとも既存有名アプリの作者からの発信がない限りFAKEだろ。
本当なら登録している製作者全員にメールがあるはずだ。
俺のところには来ていない。 [嘘でした]2019年からApp StoreでXamarin, PhoneGap(Cordova)アプリがリジェクトされるという風評について
https://qiita.com/rdlabo/items/deb5fe88b80d2737799f >>424
ああ下に顛末が書いてあったのね。最初にかけよw
あざます。 煙のないところに火は立たぬ
Xamarin程の糞はないということ
世界中から嫌われているのがXamarinということ >>426
いやその記事の人が最初にかけよと。
重ねてアザス んー、UI部分はFW化しない方がよさげやね
ぱっと見の印象でテンプレ扱いされそう 自分もはじめて聞いた
多分フレームワークだと思うけど一般的に使われてる略称なのか? エンプラの用語だよ
職務経歴書にフレームワークなんて書いてられないからFWと略す
ここにいるような奴らには縁がない FWじゃ文脈がないと
ファイアーウォールなのかフレームワークなのかファームウェアなのかワカランネ
メールだとフォワードになるし
IEEE1394ファイヤーワイヤーもある ドキュメントなんかでいきなり略語書く人もいるからな
しかも用語解説も無しで >>435
もし俺がお前の職務経歴書を見る機会があったら、まず間違いなくファイアウォールかファームウェアのことだと認識して頭の中が？マークだらけになると思うよ。 >>440
昔の職場のフォーマットを見たら「FW/MW等」という欄があった
これで通じてるみたいだから多分そうはならない。あるいは、どうでも良い欄なんだろうな それファームウェア/ミドルウェアのことじゃないのか? フレームワークとミドルウエアの違いを聞かれたら説明できないw >>442
なるほど、制御系ならありえるかも知れん
業務系だったからか、営業からはフレームワークのことだと説明されていたよ
まあ悪しき文化ですわ >>443
イメージとしてはハードを制御するソフトがファームウェア、ソフトを制御するソフト(微妙な表現だけど)がミドルウェア
例えば完成品の組み込みライブラリ(数値計算系やネットワーク系など)のパッケージがミドルウェア
フレームワークはパッケージ作成のための雛形となるソフトウェア、 Xamarinは正にそれ ID:Z/uX/8Sx0
こういう馬鹿はまともな報告書を書くことができない >>445
ライブラリ<フレームワーク<ミドルウエア<xxエンジン<アプリケーション
の並びで良いのだろうか? >>446
馬鹿じゃなくて組み込みの世界の人だろ
SIerの世界とは文化が違う 確かに組み込み系の出身だよ
逆に業務系の人がミドルウェアやファームウェアにどういったイメージを持っているのかについては興味がある
どうなんだろ
>>447についての個人的な考えとして、フレームワークについては階層並びではなくあくまでツール的な位置づけで中間層に並立しているイメージかな >>450
ファームウェアはROM書きのイメージ。
バグを仕込むと大変そうw 一昔前のマスクROM使ってた頃と違って、近頃はフラッシュROM製品が増えているので割と融通は効く
工場の製造ラインとの調整は大変だったけど5年くらい前の話 >>452
つか、マスクROMじゃなくてEP-ROMな
紫外線で消えるやつ 窓付き(紫外線消去)ROMなんか高すぎて量産では使えないよ
試作では重宝したけどね >>452
バグで死人が出るとか無いですか?
業務アプリは損失は出ても死人は滅多に出ない。 >>455
家電製品だったので死人が出るような事態になったことはない
ただしソフトバグで社告を出して、製品回収/無償修理扱いになったことはある
開発チーム全員肩身の狭い思いをした >>455
俺はあるよ。
実際には他社製品で死にそうになったから、自社には最初から対策いれていたから、事故は無い。 自分の仕込んだバグじゃ無いけど
出荷システムがトラブってトラックの待ち行列ならある。
ここは何のスレよw MasterDetailPage を使って画面の遷移を行っていますが、Xmarinのパッケージをアップデートしたところ、メニューの非表示が出来なくなってしまいました。
以前は IsPresented = false; でメニューが消え、Detailページのみの画面になったのですが・・・
Xamarin.Forms 2.5.0.121934 でのメニュー非表示はどうやってやるのでしょうか。 Xamarin & Monoって聞くとLinux発祥みたいなイメージなんだけど、
そのLinuxにXamarin開発環境が存在しないのはなんでなの？ >>463
リナックス用のクライアント作成ツールなんか需要ないやろ？ (Linux用のクライアント)の作成ツールではなくLinuxで動くIDEという意味で言った
Visual Studio、Visual Studio for MacはあるのにVisual Studio for Linuxが無いのはなんでなのかな、と サーバー上でIDE ってなかなかシュールな状況だな Visual Studio CodeはLinuxで動くけどXamarinにどこまで使えるかは知らない >>469
Syntax Highlightくらいしかできんよ Visual Studio for Linux なんて出た日には俺は Windows を使うのをやめるぜ JetBrainsのRiderなら、Linuxで動いてXamarin開発もできるよ Riderでもできるのか知らなかった
しかし有料だとVSでいいかなって気持ちになっちゃうね PCL vs .NETStandard
どっちが勝ち組なん？ windows phone不要ならpcl使う意味はないはず >>478
それはStandardとどちらを使うかって意味で？ 逆に言うとWPならPCLにするメリットがあるってこと？ 「windows phone不要ならpcl使う意味はない」と同値なのは
「pcl使うならwindows phone対応が必要なプロジェクトであるべき」になる
.net standardの本命は2.0以降だがphone向けには1.2までしか対応してくれない
そもそもphoneは消える運命だから対応しなければならない人など限られるけど 去年:.net standard 2.0
今年:xamarinがmonoベースから.net coreベースへ
来年:新開発のxamarin.forms誕生
来年が本番かな .NET Coreベースに移るとか新しいformSとかそんな話あったっけ？ 今まで作ってきたざまりん内部でのエコシステムを構築し直してまでMONOから変えて得られるメリットって何があるん
ユーザーとざまりん内部含めて。 軽量化と高速化かな
インスタントAPPは軽量化大事でしょ んー、泥もAOTとかあるけどそれいれても有意な高速化するかね 泥のインスタントAPPは、Xamarinが一番苦手な分野じゃないの？
最初にダウンロードする部分をなるべく小さくするのが、インスタントAPPの大事なところだよね？ >>489
インスタントAPP、想定されるサイズってどのぐらいなん >>490
Google はひとつのモジュールを4MB以下にしろって言ってる ユーザーが作った部分のAOTより、ライブラリがCLRじゃなくてネイティブになるのが大きい
monoと違って、ライブラリの使う部分だけを切り取ってスタティクリンクするから容量も極端に小さくなる
あ、これは現行UWPの話だけど、新型はこうなるかもしれんって話ね .Net Standard 2.0 用のライブラリってどこで検索かければ良いですかね？ >>493
MONOもつかってるところだけカリングしてんじゃ？ >>493
ああ、ごめん話の筋を読めてなかった
.net coreベースになって、.net natvie サポートしたら何が嬉しいかって話だったのね
インスタントAPP作るなら必須だと思う >>495
すでにAOTなiOSのアプリ作ったらけっこう大きなままだから、かなりそのまんまなんじゃない？ VSのライセンス無しでビルド出来る？
ビルドサーバーを建てたいんだがVSのライセンスを節約したい >>502
>>501でできるけど、Cakeが簡単かと Arduino ESP32のBLE_uart使いたいのですが、Xamarin.Formsで、NuGetは何を使えば良いのでしょうか？
教えてちょんまげ。 navigationpageで遷移したページにあるボタンの状態を維持できないんだがどうするのがいいんだろうか >>507
ViewModelをキチンとBindingするとこでしょう 勉強会というより商品説明会なタイトルばっかりでなんだか行きたいと思わないにゃ そりゃXamarinの勉強会ではなくてApp Centerがメインの説明会みたいなものだからな 使いこなせなくて僻んでるだけだかは相手にする価値なし Xamarin程の糞はない
C#も10年前の時代遅れの言語だし圧倒的にswift,Java,Kotlinの方が人気が高いし求人も多い
VS for Macはgitでブランチを切り替えたりするだけでビルドできなくなって、
クリーン、リビルド、ＩＤＥ再起動、ＰＣ再起動を頻繁に繰り返さないといけなくなる欠陥品なのが糞
大体MicrosoftはWindowsPhoneのシェアを二桁取ってからモノを言えと言いたい
MicrosoftがやっていることはGoogleやAppleの作ったパイを横取りしようとしているだけ
MVVM前提の開発環境とか言うくせに外部ライブラリを入れないと良い感じでMVVMできないのが糞
ＵＩは共通化できると言うわりにListViewは重くてスワイプがもたついたり画像の表示が遅かったりするのが糞
Xamarin.Formsはちょっと複雑なことしようとするとお得意のdependency serviceとcustom rendererの連発
クロスプラットフォームと言うならXamarin.Formsだけでできないことを恥じろよ
WebViewなどXamarin.Formsの提供するUI部品が糞すぎて
一旦Xamarin.Formsの提供する機能で実装して糞な思いをさせられた後で
Xamarin.AndroidとXamarin.iOSで計3回も同じ実装をさせられるのが糞
Xamarinなんてマイナーな環境使っている人が少ないせいでググって調べものするのに時間がかかるのが糞
qiitaやstackoverflowの情報もXamarinに関するものはAndroidの10分の1以下の投稿しかなくて
下手すると解決策が見つからなくてデザインや機能の面で妥協する結果となる
任天堂のXamarin製アプリもカブドットコムのXamarin製アプリも星平均3.0の糞アプリ認定されてる
MicrosoftのAndroid向けedgeブラウザもXamarin製でなく、
Microsoft自身も糞認定して使わない糞開発環境がXamarin
エンジニアもデザイナーもお客さんも全員がっかりするのがXamarin
結論としてXamarinを使うと開発工数は伸びアプリのクオリティは落ちるということ
XamarinをやっているやつというのはC#の機能を使うことやXamarinを使うことそれ自体が目的化していて
お客さんに良いものを届けたいという意思が存在していない
ソフトウェアを作るということは価値のあるものを世の中に提供して世の中をもっといい場所にするために
行われることであるべきで、完全に自分本位でゴミを量産し続けるXamarinエンジニアは全員死んだ方が良い 無意味な質問
リンゴとバナナどっちがいいの？と人に尋ねているようなもの >>529
AndroidだけならKotlinでも良いけど。 自分が理解できないもの全部クソ扱いしてんだろなwもうコンビニバイトでもしてればいいのに >>522 == >>532 == (ﾜﾝﾄﾝｷﾝ MM7f-f9nH)
語彙が貧弱だな >>533
マジレスするとコンビニ店員は覚えることが多いから彼には無理だよ XamarinにJava相互運用ラッパーを生成する機能があるって聞いたんだが
これはAndroidプラットフォーム以外でも使えるものなの？ Androidアプリ作ってるけどAdmob広告入れるやり方がXamarinだと分からないです visualstudio2017って、
プロパティウインドウ内のプロパティ名検索機能無いのかよ！
ビックリだわ
一々スクロールバーで探すのめんどくさ過ぎ
IDEとしては有り得んと思うけど、
有料版では検索機能有るんか？ 初回セットアップが楽勝で、起動も速いし日本語化されてるし、いいじゃないの！
と思っていた数時間前が懐かしい・・・・ C#でブラウザクライアントまで開発できたらまじで他の言語いらんくなるなぁ リッチクライアント復活なん？
標準技術ならいけるか... プロパティウインドウってWindows Formsのチュートリアルぐらいでしか触ったことないな プロパティウィンドウ、自分もリンクしてるDLLのパスを見るぐらいにしか使ってないな >>547
それが必要なシチュエーションは何だい？ 画面にパーツをペタペタ貼って、
各パーツのidやら、テキストの内容やサイズやら、マージンやらを指定するとき >>555
それをプロパティウインドウでやるのは入門書の中だけだから気にしないでいい >>556
まあ、いくつか作り貯めてれば、過去のコードの主要なプロパティ設定部分をコピペすりゃいいのは分かってんだが・・・・
androidstudioで当たり前に出来ることも出来ないとか、VSの方が歴史長いくせに使い勝手が悪いな、って話だわ 検索したいってことは名前は分かってんだよな
アルファベット順に並べりゃいんじゃね？ >>558
IntelliSenseって知ってる？ >>558
プロパティなんかそこまで多くならないだろうし名前順でわかんだろって感じなのかね
まあフィルタあっていいと思うので要望出しといてくれ Windows Formは知らんがxaml使う開発はプロパティはxamlかコードで設定するからプロパティウインドウ使わない 「XamarinといえばForms」な世界に本当になっちまったんだなあ
Xamarin.iOSならStoryboard編集でプロパティウインドウ使う
Xcodeのが早いけどmac使いたくねえし Xamarin.Forms.Macもライブラリとしてはリリースされてるしな
今はVSへの組み込み待ち xamarinをparallelsで使っていてandroidエミュがhaxm使えないんだけど
どぎゃんしたらのかと？ 自己解決した
mac側のvisualstudioで作ったエミュにadb connectコマンドでつなげて解決
parallels proだとhaxmが効くみたいだけど、pro版は金がもったいないから、解決してよかったw つか、昔のバージョンではparallelsでもnested vt出来たらしいじゃねえか
改悪してんじゃねえぞ もう解決したから、買う必要ねえな
次、mbpを新しく買うときはfusionを入れるわw Xamarin程の糞はない
C#も10年前の時代遅れの言語だし圧倒的にswift,Java,Kotlinの方が人気が高いし求人も多い
VS for Macはgitでブランチを切り替えたりするだけでビルドできなくなって、
クリーン、リビルド、ＩＤＥ再起動、ＰＣ再起動を頻繁に繰り返さないといけなくなる欠陥品なのが糞
大体MicrosoftはWindowsPhoneのシェアを二桁取ってからモノを言えと言いたい
MicrosoftがやっていることはGoogleやAppleの作ったパイを横取りしようとしているだけ
MVVM前提の開発環境とか言うくせに外部ライブラリを入れないと良い感じでMVVMできないのが糞
ＵＩは共通化できると言うわりにListViewは重くてスワイプがもたついたり画像の表示が遅かったりするのが糞
Xamarin.Formsはちょっと複雑なことしようとするとお得意のdependency serviceとcustom rendererの連発
クロスプラットフォームと言うならXamarin.Formsだけでできないことを恥じろよ
WebViewなどXamarin.Formsの提供するUI部品が糞すぎて
一旦Xamarin.Formsの提供する機能で実装して糞な思いをさせられた後で
Xamarin.AndroidとXamarin.iOSで計3回も同じ実装をさせられるのが糞
Xamarinなんてマイナーな環境使っている人が少ないせいでググって調べものするのに時間がかかるのが糞
qiitaやstackoverflowの情報もXamarinに関するものはAndroidの10分の1以下の投稿しかなくて
下手すると解決策が見つからなくてデザインや機能の面で妥協する結果となる
任天堂のXamarin製アプリもカブドットコムのXamarin製アプリも星平均3.0の糞アプリ認定されてる
MicrosoftのAndroid向けedgeブラウザもXamarin製でなく、
Microsoft自身も糞認定して使わない糞開発環境がXamarin
エンジニアもデザイナーもお客さんも全員がっかりするのがXamarin
結論としてXamarinを使うと開発工数は伸びアプリのクオリティは落ちるということ
XamarinをやっているやつというのはC#の機能を使うことやXamarinを使うことそれ自体が目的化していて
お客さんに良いものを届けたいという意思が存在していない
ソフトウェアを作るということは価値のあるものを世の中に提供して世の中をもっといい場所にするために
行われることであるべきで、完全に自分本位でゴミを量産し続けるXamarinエンジニアは全員死んだ方が良い 糞な部分を列挙してるつもりなんだろうが
読めば読むほど無能自慢してるようにしか見えないという
不思議な長文 Xamarin程度のミドルウェアさえ使いこなせない無能のたわごとだからな
生暖かい目で見つつ、心の中で笑ってやれ
こんなところでしか発散できない無能の哀れを OnLongClickListener 的なものを使おうとしたら標準ではサポートしておらず、
ジェスチャーの導入が必要とかでびっくりした。
作ったアプリの起動も遅すぎるし、
完成度低すぎだろこれ。 どうせ起動時に不要なものもあれこれ読み込ませてるんだろうな Xamarinホントすげえな
これあればiOSもAndroidでも行けるんやろ？
これ勉強して会社で無双するわ まあいける。けどどのみちiOS、Android の知識も必要になるけどな マジレスすると
Js使いたくない
HTMLはドキュメント由来だからUIの要素としてはちょっと無理がある時ねーか
ネイティブのアプリと挙動が違う
ストアとかにあげられない
辺りかね。
もちろんブラウザアプリにも利点はあるから場合に応じてって感じか Xamarin、ブレイクしなかったな。
スマホアプリも今後はPWAな方向に行くんかいな。 クロスプラットホームツールで他に有力なのって何よ
個別に作るのは勘弁してくれ 有力なものなどないし永久に出ない
ネイティブでまともなアプリを作るか
Xamarinで糞アプリを作るかだけ ハイブリッドWebアプリってやり方もあるね
ネイティブアプリにWebView貼り付けて、ネイティブ側とWebView側とをJavaScriptで連携するやり方
XamarinのハイブリッドWebアプリの案件も担当したことある XojoがAndroid対応予定だから対応されたら使えるかも >>604
ReactNative使ってる人にも聞いたことあるけど、Xamarinと同じような問題抱えてるしツールの成熟など含めてXamarin よりいいかとは思えなんだ。
まあjs大好きならいいかもね
>>605
したらコルドバとかの方が良かったりしないん？ WebView程の糞はない
大抵WebViewを使っている箇所でバグるしUIもネイティブと同じにできない
大体WebView使うなら最初からアプリなんか使わずに全部webページとして作ればいい
WebViewで良いなんて言っているやつはアプリの強みを理解していないと言っているようなもの
メルカリなんか見てもモバイルファーストで最初からアプリで作ったからうまくいってるんだ
まったく時流が読めてない時代遅れのゴミがWebView Xamarinも検討したけど、結局Android StudioとVisual C++のJNI連携にしちゃってるわ。どうもC#は馴染めない… クロス環境なんて生産性が悪すぎるからやめといて正解 C# 悪くないんだけどプラットフォームで共通の部分が C# で書けます、
なんて言われても C++ なら元からそうだし C++ 使ってた人にはアピールしないよな >>613
それC++の部分もデバッグできるの？
後C++は自分は触ってないけど2018年になった今、テンプレートのエラーわかりやすくなったの？と聞いたら何も変わってないと言われたぞ…
正直今更C++では書きたくないな
Xamarinは言語から開発環境、既存の資産の利用含めた総合力で他よりいいと思うけど。 >>614
テンプレートのエラーはわかりやすくなったし、そもそもエラーメッセージを自分出かけるようになったぞ 613だがC++嫌いな人や元々使ってない人はもちろん使わなくていいと思うよ
普段からC++使ってる人がポータブルってだけでc#使うことはないだろう、というだけ。 >>617
人に聞いただけだけも、コンパイラが違うのかね。
自分でかけるの意味がわからんがコンパイルエラー時にそのコンテキストもらってそれをもとにフォーマット出来るってこと？ >>620
それは嬉しいのかどうなのか。
まあ普段はデフォのメッセージが出てる、それでわかりにくい時は追加情報取れるからより詳しく出せるってことならまあありかも
デフォのメッセージが最初から十分な情報出してればいいだけだけど Emscriptenで、c++を、WebAssemblyにすれば、マルチプラットフォームアプリが作れる。
仮想マシンは、C#だと、.Netだが、この場合は、wasmになったような感じになる。
つまり、Webアプリではあるが結局それは、C#でも同じような事なのでデメリットには
ならない。 んC++でもマルチプラット開発できるよって話？
ウエブアプリになるのはだいぶ違うし、トータルの開発効率、言語自体の生産性からIDEのデバッグ等含む効率などなど色々違うと思うけど…まあそっちは触ってないので何ともだけど。 WPF は
1. 遅い。
2. LinuxやMacでも上手く動かないらしい。 http://var.blog.jp/archives/69202816.html
↑によると
1. WPFアプリは、VSの「外見」だけが使われている以外には、滅多に使われていない。
2. WPFは、Windows Form Appli に比べて圧倒的に遅い。
Web画面をリロードしているぐらいに遅いらしい。 Electron の API Demos を Win7 で試したら、別ウィンドウで OVERLAPPED WINDOW
や、タイトルバーも URL アドレスバーもない Window を出せることが分かった。
これはWebアプリではなく、紛れもなくスタンド・アロンアプリだ。
さらに、Electronは、JSで記述するが、JSは、内部的にはWebAssemblyと同じような物で、
簡単に後者から前者を呼び出すことが出来る。
WebAssembly は C++で書く事ができるので、C++で、Win/Linux/Mac/Androic/iOS
の全てのプラットフォームに共通のスタンドアローンアプリをC++で書くことができるハズ。 c++はオブジェクト指向を無理矢理cにくっつけたから難解になった
オブジェクト指向でやりたいならc#が現状の最適解 [結論]
1. Emscripten、Electronの組み合わせで、C++で、Win/Mac/Linux/Android/iOSの
ビジネスアプリ、ゲーム作れる。
2. 仮想マシンは、ブラウザ上の WebAssembly(wasm) 実行環境
3. ビジネスアプリは、ElectronのWidgetが使える。
4. Overlapped Window、POPUP Window が作れる。これは、子ウィンドウではなく、
Desktop に Floating している Window。アドレスバーも付かない。
5. Windowには、アプリが占有できるMenuも最初から付けられる。
6. ゲームでは、Canvas、SVG、WebGLと、EmscritenのフルOpenGLのサブセットが
使える。
7. ファイル入出力もできる。
8. node xxx とすると、コンソールアプリとしても起動できるので、サーバーサイドアプリ
も作れる。
9. Xamarineやmono、.Net、C#は終わった。 Xamarin程の糞はない
エンジニアもデザイナーもお客さんも全員がっかりするのがXamarin スマン、AndroidとiOSは、Electronだけでは動かないらしい。Android, iOS用に
Meteorで書いておいて、それを Electron のコンテナに入れないといけないらしい。
OVERLAPPED WINDOWがスマフォの狭い画面では対応しにくいからだろうか。 こいつきちがいか。
開発効率とか都合の悪いところには絶対触れないのなw >>639
Cordovaとか避けてるのは何故なんだろw がはははははははｗｗｗ
MS帝国が終わる日が来るとはなｗｗｗ >>642
オマエはElectronが何か分かってないだろ。
ここはXamarinスレだってことも。 要は老害が使い慣れた言語から離れたくないだけでクソわろす がはは。最初は知らんかったが、この数時間の内にわかってきたのさ。
それから、MS帝国を破壊する事を目的にしてるのだから、このスレが最適なんだよ。 MS帝国の崩壊以前にオマエが崩壊してるぞ
オマエの頭脳構造が不安定すぎるんだ 便利なものは使えばいいだけなのにMS帝国とか言って無理して排除する必要などない
異常なまでにベンダーロックインを恐れるのと同じタイプだな https://teratail.com/questions/100514
>それでは、VSに登場したときに話題になった、Xamarinはどうでしょうか。
>ネイティブにコンパイルするので、パフォーマンスが高いのがメリットです。
>
>しかしその一方、非常に扱いが難しい。
>Windows、Android、iOS、それぞれのOSや言語やフレームワークなど、
>三者三様の開発環境の知識が必要になるためです。
>
>Xamarinの場合、Webアプリどころか、
>（単独の）ネイティブアプリより難しくなってしまいます。
>
>マルチプラットフォームで、しかもネイティブアプリと同等、
>というのは魅力的ですが、その欲ばりな仕様のため、難しくなった。 開発工数は膨らみアプリのクオリティは落ちるのがXamarin
人と違うことをして優越感を得るタイプの変態にしか向かない Webアプリ由来のマルチプラットフォームでもいいさ
ただしBlazorが普及してからね とりあえず開発言語としてjs使うのだけは勘弁してくれ >>656
TSは外のもの使うのにマッパー書かないといかんのやろ？
ある奴はいいけど結構書かないと行けなくてめんどいと聞いたが。
まあjsよりはマシそうだからやる羽目になったら検討したい >>657
マッパーなんか書かなくても直接呼び出せるけどね >>653
新しいものが出ると必ずこういうこと言う香具師が出てくるけど
要するにスタートアップコストと開発効率改善のトレードオフでしょ？
Xamarinがそのどちらも悪化するっていう主張なら理解するけど
単にdisってるだけやん Linuxでは、公式には .Net Core だけのサポートだから、公式にはコンソールアプリだけしか動かない。
Xamarineは、monoから始まったものではあるが、Linuxで動かされたら困るMSが
買収して、なんとかしてLinuxでは動かないようにしたかった。だから今後はますます
LinuxではC#や.Netが動かなくなっていくだろう。 ところが不思議なことに、VS は Mac でも動き、VS Code は、加えて Linux でも動くので、戦略として非常に不思議な状態になっている。これは、Windowsが終わってしまう事も視野に入れて、その場合でも開発環境だけは生き残れるように手を打ったのだろうか。 サーバーサイドで動くコンパイル型言語は沢山あるが、間違ってるかもしれないが
1. Perl, Ruby などのスクリプト言語達
2. JavaScript ---> node.js
3. Java (Sun/Oracle, ServerSide)
4. C++ ---> Emscripten ---> WebAssembly ---> node.js
5. 「C#」 + 「.Net Core」
みたいなことになっている。これをみると、MSとしてなぜLinuxでも動く
.Net Coreを出さざるを得なかったのかが見えてくる。.Net Coreがなくても、
LinuxがServerSideで使われる現状は変えようがないから、.Net Coreの
存在が Windows のシェアを減らすことには考えにくいということだ。
それよりむしろ、C#を使ってもらうことを選んだ。 誤：サーバーサイドで動くコンパイル型言語は沢山あるが、間違ってるかもしれないが
正：サーバーサイドで動く言語は沢山あるが、間違ってるかもしれないが ServerSideプログラム ---> CUI だけで十分で、ライバル達も CUI のみ。
(JPEGやPNG形式の画像などをCUIプログラムで合成しHTTPプロトコルで
クライアントに送ることは可能）。
だから、ライバルと互角になるためには、.Net Coreだけで十分だった。
ところが、monoは、LinuxのデスクトップでC#が使われてしまうので、
デスクトップOSでのWindowsのシェアを減らしてしまう可能性があった。
そこで、MSとしては、C#は、LinuxではCUIだけが動くようにし、GUIは
わざと動かないようにしたかった。そして今後も知恵を絞ってそういう方向
に持っていくのではないか。 linuxがどれだけ便利になってもwindowsシェアを脅かすほど一般人がlinuxに流れるわけないだろ
あるとすればノートPCメーカーがlinuxプリインストールの安価ノートを各社色々出した場合だけど
メーカーも量販店も利ざや減るだけだからその可能性は考えなくていい CUI : Win/Mac/Linux ; .Net Core
GUI : Win/Mac ; .Net Framework / Xamarine / .Net Core
LinuxでGUIのC#は、非公式(mono)のみ。MSは、Xamarineを買収してまで、LinuxでGUIのC#を使えないようにしたかった。Desktop OSのWindowsのシェアを奪われたくなかったから。 >MSは、Xamarineを買収してまで、LinuxでGUIのC#を使えないようにしたかった。
全然違うと思う。 monoがそのまま発展していくと、C#アプリがWinとLinuxで全く同じように動いて
しまう可能性があった。そうなればデスクトップでWinを使う必然性がなくなる。
そこでmonoの発展を止めるためにXamarineを買収せざるを得なかった。 iOSとAndroidを侵略する為にXamarinを買収したんだ >>676
それはひとつの側面。携帯OSは、元々Windowsのシェアが0に近かったため、
シェア低下の恐れがなかった。ところがデスクトップOSのLinuxでは違う。 >>677
我がMS帝国はLinuxデスクトップなど驚異とは思ってないぞ リナックスのGUIなんてだれも相手にもしてねーよw何夢見てんだw MSの狙いはJavaのシェアを.NETで切り崩したいだけだろ でもそれと同時に、ちゃっかり、Linuxの.Net実行環境の発展を阻害するように
した事に気付く人は少ない。 そりゃLinuxなんてクライアントでは誤差レベルの環境にわざわざコストかけて対応するわけねーだろ。
Macですらfoams対応の人ごく数人でほそぼそと続けられてやっとまともになって来たんだぞ？ public const string GTK = "GTK";
GNU Image Manipulation Program Tool Kit https://www.indeed.com/q-Xamarin-jobs.html
ペプシの会社は内製で使ってるみたい。テキサス(オースティンではない)で募集してた。 >>697
おっさんの体験談を500円払って聞きたい奴おるのか？ 内容はよく分からんが>>702はまともな開発者の発想では無いな
小学生並みの所感だな >>703
ハンズオンとかなら価値あるけど体験談聞いて人脈作るとかどうでもええわ 面白い話が出るかは知らんが、初心者としてハマった話など何か参考になりそうな事あるかもあれば直接話し聞けて便利ってことで行くのは何もおかしくないと思うけどね
なんかこの人物事をすごく幼稚に捉えて自分に得することしかしようとしないで結局損してる感じな人に見える 前に参加した時はハンズオンだったな
悪くはなかった
しかし、他人が色々やってるのを外から貶さなくてもって思うわ
嫌なら自分独りで黙ってやってりゃ良いだけの話 人脈を馬鹿にしてる人多いけどスタートアップとかフリーランスとかで小規模なところから始めるとなると実際人脈の影響がかなり重要
能力さえあれば勝手に仕事が降ってくるなんてことないから 今のマイクロソフトはAIやらないとクビだよ
Xamarinなんて眼中にない .NET 広めたいだろうし早々捨てないんじゃねーの
むしろ Flutter が突然切り捨てられないか心配 Xamarinはオワコン
flutterやった方がマシ 来月が楽しみだな。
Google I/O 2018 Flutter正式リリース
Microsoft Build 2018 ?????? Flutterにも良いとこ悪いとこあるしな
誰か機能のミートアップ行ってないのかね Dart触ったことないや
C#よりいいって話は聞かないけど
覚えようかな >>719
じゃあ、自分の考える環境ランキングをザマリン含めて発表してちょ
最下位のザマリンは何位になるのかな？ >>719
こいつはスカトロマニアで、一番の糞扱いは最高の賛辞 >>720
1. c#
2. Java
(省略)
98. PHP
99. Xamarin
100. COBOL なんで一つだけプログラミング言語じゃないものを混ぜてるんだろう？ Pythonもかなりの糞だがアリンコが群がって巨大な糞の塊になっている。
同じ糞なのにXamarinはアリンコが居ないw この世には二種類のプログラミング言語がある
文句を言われる言語と
誰も使わない言語だ 比較対象の例
C# と Python (プログラミング言語)
Xamarin と Anaconda (環境) 1.Unity
2.flutter
3.ReactNative
4.Cordova
(省略)
100.Xamarin Microsoftはxamarinをrebootしないと、flutterにすべて持ってかれそう。
で、c#がやばくなる。 >>728
おぉ、すげえな
モバイルアプリ開発環境がそんなにあるとは知らなかったよ
つか、キチガイは限度を知らねえなwww
明日の期日は1000%守りますとか言っちゃう人？ >>727
オレが言うのもなんだが
最後の行は違うんじゃないのか Xamarin.Formsの標準機能で出来上がるものが、JSやらDartで作られたハイブリッドアプリと大して変わらないのが最大の欠点だろうな
疲れる割にしょぼいのが出来上がる >>733
疲れるって、その大して変わらないものならレンダラもいらないし、全部共通で作れるだろ。
そうやって作れるのがRNやFに比べてめんどくさとは思えないけどな Flutterはマテリアルデザイン以外のUIを選択できるのかな？ GoogleはFUCHSIA次第なのかなあ
Androidは捨てるんだろうか 開発のしやすさから見ると、捨ててOK。
というか、UIフレームワークだけとっかえてくれればいい。flutterみたく。
データバインディングやAndroid Arch Componentsでいくらかマシになったとはいえ、
元がアレだから限界がある。 Xamarinみたいな雑魚は単独でスレを立てるほどではないと >>728
unityってUIどうですか？
マテリアルなデザインやモダンかデザインいけます？？ まだちょまどに相手してもらうために荒らし続けてるの？ decode2018のモバイル開発関連のセッションを担当するみたいだけど 明日か。
.net standard2.0の次の一手の発表がなければ失望。 >>760
今週は今後の1年を占うMicrosoft build2018とGoogle IO 2018とイベント盛りだくさんでしょうに。 >>763
WebAssemblyか
js多用しなくてもほぼC#でWebアプリ書けるのはいいね XamarinスレなんだからWebはOouiでどうだ？ >>762
月曜じゃないじゃんｗ 現地では月曜かもしれんが・・・ コードがC#で書けるところは別に良いんだけど、結局Razor/HTMLかよってところが刺さらんのだよ。 >>772
なんとかしてXAMLの構文を持ち込もうとしてすぐにCloseされてたアホが結構いたことに逆に驚いたわ 結局Razor/HTMLかよってところが刺さらんっていったら、他にXAMLしか想像できない視野の狭さに驚いたわ >>774
C#使いになじみのあるRazor、XAMLや、一般的なHTML以外にどうしろと？ >>776
だからそこが視野がせまいんだよな。新開発環境なんだから、別に従来型のテンプレート/データバインディングにこだわる必要はない。
これから来そうなflutterみたいなのもいいだろう。もちろん、flutterがインスパイアされたと言うreactはjsxみたいのはあるが。 まったく考え方が違うから平行線だな。
MSが新規のものやって流行るわけない。
既存＋αでさえうまくいっていないのに。 せっかくWASMするんなら何か新しいものが欲しいと思っちゃうな、俺は。
単にC#でロジック書いてXAMLでUI書きたいだけならOoui.Formsで良いと思うし。
https://www.infoq.com/jp/news/2018/05/net-browser-ooui >>779
またSilverlightでも作りたいのかい？ MicrosoftのWindowsプラットフォームに対する今後の計画が、
定義されておらず、UWPアプリがブレークスルーになっていない今、
.NET開発者が取り残されていると感じていたとしても不思議なことではない。
さらっといいこと言うねｗ xamarin live reload試してみてcross platformのテンプレートから作ったプロジェクトなら下記の公式の手順で動いたけどprismのテンプレートだと動かないなあ
https://docs.microsoft.com/en-us/xamarin/xamarin-forms/xaml/live-reload やっぱりprismでもできたわ
エミュレータの接続に失敗してただけだった ［速報］AIがコードのレコメンドやバグの指摘など開発を支援してくれる「Visual Studio IntelliCode」発表。Build 2018
https://www.publickey1.jp/blog/18/aivisual_studio_intellicodebuild_2018.html
僕たちが要らなくなる日が来る Razorが来たら、次はハイブリッドアプリにも手を出すことになるだろうからな
Xamarin.Forms人口がさらに減り、フレームワークが保守されなくなって元からの住人は詰む・・・・・みたいなことだけはやめてくれよ そういえばプログラミングXamarin本の下巻のほうってもう発売されてるの？
本屋にもAmazonにもないみたいやけど >>790
ありがとう
うーん、たしか上巻発売時には去年の秋くらいに下巻発売だったよな気がｗ
これは発売中止って考えておいたほうがよさそうかね
下巻も日本語版でじっくりと読んでおきたかったんに残念 Xamarinが糞すぎて全く売れなかったから下巻はなしだとさ App centerでのテストってどの程度テストできるの？ 基本UIテストだろ
ユニットテストしたいならVSTSの方がいいんじゃ キーノートでのちょまどの喋りは、だんだんてんぱってきて最後の方はマジウザすぎ
ttps://www.youtube.com/watch?v=JnX9nhoPXTY&feature=youtu.be
1:19:20あたりから Xamarin.LiveReloadとXamarin.Essentials 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
C617P React Nativeも糞
ttps://twitter.com/Psychs/status/1003028636071387136
クロスプラットフォームは総じて糞
Xamarinはキングオブ糞 Natがgithubうまく残してくれるといいけど、devopsみたいなツール群統合したところにまた統合するのかね。 ザマリンとC＋＋のクロスプラットフォームってどうちがうん？
言語が違うのは分かるんだけど クロスプラットフォームって言葉ぐらいしか一緒なとこなさそう デスクトップのクロス環境は成功してるけどモバイルはOS差が大きすぎて無理があるんだよなあ Xamarin.Essentialsでスマホ特有の各種機能の大部分（センサー、カメラ等）も共通部分のプログラミングだけで済むようになるからかなり各OS毎に書き分けなきゃならない要素は減るだろうな githubのtがfに見えたからギフハブ
これは苦しいけどまあ判らないでも無い
gidhubは全く意味が判らない GithubというかGitを知らんからそんな間抜けな読み方をするんだろ gitは発音記号にしたらgit
無理矢理カタカナ表記にするならギットだろ セブンのソフト、そそのかされて食べてみたけどなんかボソボソした感じだし自分はミニストップのの方が美味しい Xamarin.Formsのgtkが.net core で動いた人います？
解説ページそのままで.net coreに置き換えても動きませんでした。 apkにdll追加したいときはどうしたらいいの？
使いたいc#ライブラリがあって（これは参照の追加）、そのc#ライブラリが内部で利用しているdllをプロジェクトの中（apkの中に）に含めたい Referenceでそのdll選んでプロパティよりコピーローカルじゃダメ？ それだと参照としてプロジェクトに読み込まれるからだめなんだよね。できなさそうだね >>849
何がダメなのか意味わからん
動的に読み込みたいって事か？
だったらただのバイナリとしてでも置いとけ >>854
これは同意だわ
他の言語は終わってるし へじたんはC#に見切り付けてtypescript側に移っちゃったけど
この前も提案した仕様が取り入れられてて喜んでた
typescriptは上位の能力者の戦いみたいな世界になってて嫌い Xamarin.forms でShiftJISに変換する方法ってないの？ encodingがshiftjisサポートしてないみたい例外でちゃう
なんかまちがってる？ >>864
Shift_JIS or MS932? >>864
今は知らんけど2年くらい前はXamarin.Forms側では対応してなかったからネイティブ側で呼び出して解決した >>865
932は試したけどms932はためしてなかった、あしたやってみよう、ありがとう
>>866
やっぱり？わざわざencordingに似たinterface作ってdependencyservice呼んでだめだったらダルダルだなと切り上げたところでした 昔PCLで何か作ってshift-jisデコードした覚えがある
標準の環境では無理だった PCLもdroid側もCJKもその他もダメだったorz
nugetしたP~なんとかもダメ
shiftjisのencoderが取得できないみたい
環境なのかなんなのかあきらめてAndroid studioですることにしました
でもモヤモヤ晴れないんでこれでいけたという例を頂けるとうれしい Portable.Text.Encoding.GetEncoding("Shift-JIS");
で例外出るの？ >>871
あ、これの場合は共有ライブラリをPCLじゃなくて.NET Standard化する必要があるかな多分 Xamarin.Forms / UWP で DetailMasterPage の MasterPage(メニュー）が引っ込んでくれない。
同じソースでAndroidなら引っ込んでくれるんだが・・・
解決方法がわかるかたいませんか？ Androidアプリって設定情報とかをローカルに保存するとき
jsonかxmlで保存するのはスタンダードな事ですか？ 俺はアプリの単純な値の設定情報はpreferencesに突っ込んでるな。 というかPreferences使えばpreferencefragmentとか自動でUI作ってくれるから、みんな大抵これ使ってるんじゃね? とりあえず原因はわかりました。
MasterDetailPage.MasterBehavior のデフォルトが MasterBehavior.Default になっている場合、モバイル端末以外では非表示にならないようです。
UWPでも消したい場合はPopoverにすれば消えました。 「Delphi」「C++Builder」のフル機能を無償で 〜“Community Edition”が発表 - 窓の杜
https://forest.watch.impress.co.jp/docs/news/1133620.html
これの C# 版が求められている > Microsoft >>884
Visual Studio Community じゃダメなの？ >>884
これ(開発ツール)のC#版ってVisualStudioのことだろ
どちらかと言えば、EmbarcaderoがMicrosoftの後を追っているだけのようにしか見えない
以前のXamarinStudioからVisualStudioへの移行時とほとんど同じ流れだな >>885-887
C# だとWindows、macOS、iOS、Android向けのネイティブアプリをワンソースで開発できないやん。 プラットフォーム差があまりに大きいからな
完全にワンソース化も技術的にはできるがデメリットが大きすぎる。そんなもん誰も欲してない 馬鹿でも使えるようにスマホ基準で作ればいいだけだから。 >>890
それならXamarinでもできるやん。
各プラットフォーム毎に自動生成のプロジェクトはできるけど、実際のソースは一か所で済む。 >>891
ワンソースでmacは無理、Windowsもまぁ半分無理。 >>893
スマホ基準でMacやWindowsを無理矢理ワンソース化するとかアホだろ
誰もデスクトップアプリをスマホ基準に合わせようとは思わないよ こんな優秀なクロスプラットフォームが存在したのか
凄すぎるよ全く ようするに UI は共通化するのがベストとは言えないんだよな
無理やり共通化すれば開発コストは下がるけど、ユーザーからするとプラットフォームごとに最適な UI のほうが嬉しい
コストを下げる代わりに UI は多少チグハグになることを理解してる客向けなら Xamarin.Forms は良い選択肢 客からiOSとAndroidでUI一緒にしてくれと言われることが多い >>903
客の意見をそのまま通す、無能な営業にはお似合いだろうね。 働いたことのないニートの戯言聞いてるとああ夏休みかと実感するわ
あニートに関係ないかw 糞みたいな職場のやつがXamarinみたいな糞を使う >>908
UI スレッドでの await は UI スレッドに戻るけど、ワーカースレッドでの await は別のワーカースレッドに戻る可能性があるっていう理解で合ってますか? >>910
基本そういう理解であってる。UIスレッドでのawaitでUIスレッドに戻したくなければ、TaskクラスにConfigureAwaitメソッドあるから、ひきすうをfalseにして呼び出してそれをawaitする。 >>910
awaitをuiスレッド以外で使う必要があるのだろうか? >>914
いやUIを固まらせないためだけのものじゃないから >>913
なるほど、そういうことだったんですね。回答ありがとうございます。
Realm を使っててよく incorrect thread の例外が出ると思ってたんですが、ワーカースレッドで await してるから出るっていうことなんですね。 >>916
ワーカースレッドを非同期で実行させなきゃいけない場合って具体的にはどんな場合?
uiスレッド以外は待たせても問題ないと思ってるんだけど。 よく知らずに回答するけど、ソケット監視してるスレッドとか、ui以外でも固まったら困るスレッドはいくらでもあるんでないの？ ワーカースレッド内で複数の非同期処理を同時実行したいときなんて普通にあるだろ 今回問題になったのは、とあるメソッドがタップと通知どっちからも呼ばれるケースがあったからでした
通知から呼ばれた場合には await してる部分の前と後でスレッドが違うから Realm の制限に引っかかってた
どっちからも呼ばれる作りがよくないのかな >>923
いやRealmはよく知らんけど作成したスレッド以外で触るなとか制限あるの？だったら通知で違うスレッドになりうるならUIスレッドからになるように調整しろよ >>920
その普通を思いつかないから聞いてるんだ
>>921
ビジーループで待たなきゃ良い >>925
いやWaitしたらCPUの１つのスレッドその間死ぬんだけど。何ビジールーブしなきゃいいって。 >>928
CPUが無駄ってブロックされるって事か。
無駄にCPU Timeを食うのかと思ったw
スレッドがブロックされるから別スレッドにしてるんだろう。
ワーカースレッドがブロックされても問題ないだろうよ。 >>929
ほんと馬鹿だろお前。無能すぎて草生えるわ。
教えてやんないから一生バカのまんまでいろや >>928
WaitしたらCPUのスレッドは別のスレッドの実行に使われるよ
普通のOSなら いまだによくわかってないんだけど、皆さんはイベントハンドラーが UI スレッドで実行されるのかワーカースレッドで実行されるのかってどうやって判断してるの?
ドキュメントに書いてなくない? 経験則? >>933
System.Threading.Thread.CurrentThread.ManagedThreadId で見れば分かるけど
ドキュメントにセカンダリースレッドで実行されるって書いてないかな。 >>932
マルチスレッドを使わない方が良い人だね。
async/awaitは馬鹿を量産できる仕組みかも? async await 便利だけど、Xamarin Android で Activity の中で使うのは注意しないと危険だねえ
いろいろやったり調べたりした結果、
使いたいなら Task.Run( async () => { .... } ) の中で使うのがいいのかなとか思った
await 指定無しで呼んで ContinueWith(() => { }) とか付けといてもいいかもだけど 流れぶった切って初心者質問させてください。
スライドスイッチの大きさを大きくしたいんですが
どうやってやりますか？
SwitchCell でも Switch でもどっちの場合でもいいんですが
縦横2〜3倍に巨大化したいのです。 ダメっていうか無理だろ。
WPFみたいなレンダトランスフォームあったっけ？
ネイティブコントロールには無理そうだけど iOS/Android ともに Scale は変えられるみたいだよ
カスタムレンダラーで変えればいけると思う > Xamarin.Formsはちょっと複雑なことしようとするとお得意のdependency serviceとcustom rendererの連発 >>944
IOSもいけるんだっけ。したら両者Effectでもいけるのでは 公開アプリじゃなくて社内アプリなので
iOSは無視でいいです。
デフォのが小さすぎて操作しづらいという意見があって。 >>943
これは自前のスイッチ作っちゃう系ですか。
スイッチ以外のテキストもろとも大きくなっても文句は出ないと思うので
スケール弄りという手段もOKです。 atsushienoも逃げ出すXamarinの糞さ ちょまどはもう全然Xamarinの情報発信してなくね
Xamarinみたいな糞を未だにやってるのは騙されたお前らだけ >>950
辞めるのはMSであってXamarinの開発はまだやると言っているんだが >>955
他の言語やフレームワークに乗り換える可能性が高いって意味のこと書いて無い？ 会社に所属していると自分でやりたいことができない。だから辞める。
としか取れないんだけどな・・・
>>956
>非OSS部分が無いとコードが維持できないレベルになってきたら、他の言語やフレームワークに乗り換えてやっていくつもりです。
と書いてるだけ。逆にいうと、コードが維持できるのならC#のままって事だろ。 >>957
その次の「〜早々にそうなるかもしれません。」が目にはいらないのかな？ ちょまどはどうしてEnoさんにお疲れ様リプをしないのかな？^^ >>953
先月カンファレンスで登壇してたぞ食糞野郎 すみません、StackLayout の高さって自動じゃないんですか。
<TableView Intent="Form">
<TableView.Root>
<TableRoot>
<TableSection>
<ViewCell>
<StackLayout>
<StackLayout>
<Label FontSize="Large">あ</Label>
</StackLayout>
<StackLayout>
<Label FontSize="Large">い</Label>
</StackLayout>
</StackLayout>
</ViewCell>
</TableSection>
</TableRoot>
</TableView.Root>
</TableView>
で、「あ」は表示されるのですが「い」が表示されません。 自己解決
HasUnevenRows = "True" にしないといけないのですね。
あとはスイッチのサイズ・・・ Xamarin.Forms 2.5.x で作ったプロジェクトを3.xに更新すると以下のエラーが出るのですが、解決方法はありませんか？
エラー CS0012 型 'Attribute' は、参照されていないアセンブリに定義されています。アセンブリ 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' に参照を追加する必要があります。 ロジックの組み立ては C# でラクなんだけどなぁ
Java なんて関わりたくない w 素晴らしい
一つの言語でiOSとAndroidの開発が出来てしまうのか
Xamarin使うしか無いじゃんコレ それならFlutter dartの方が良さそうだけど .Formsの方は痒いところに手が届かなかったりするけど.Nativeの方はマジ強力で使える Flutterは後発で色々良いところもありそうだけどこなれてないとこもまだ多そうなイメージ
まだネイティブコントロールとの混在はできないんだっけ？ Android で Switch のカスタムレンダラー書いてスケール変えれるか試してみたけど、元々のサイズまでで描画が切れちゃってダメだな
Forms 生かすなら Android の Switch 使うのやめて、Switch っぽい見た目のもの作ったほうが早そう そんな無駄な実験に時間を浪費する暇があったらネイティブでそれぞれで作ったほうが早い iOSだったら三点タップして拡大してくださいで済む話 ネイティブでも結局カスタムSwitch造ることになるんだからFormsでもネイティブでも手間は大して変わらんな 念のため書いとくけどiOSは三点ダブルタップで画面が拡大する カスタムレンダラーで実験して時間を無駄にした分の負け PGなんて、try and error の積み重ねじゃん。
そういった時間を無駄と思っているなら将来性無いね。
枯れた技術だけで組んでいればいいさ。 そもそもカスタムレンダラーなども含め、Xamarinその他のクロスプラットフォーム技術によって共通化させる主な目的は開発の高速化ではないからね
特に対象の規模が大きくなればなるほど後の保守の効率化の方がメインとなる もっと意味のあるtry and errorに時間を使うべき
Xamarin特有の糞関わっている暇などない >>984
明らかにお宝の埋まってない穴を掘り進むTry and Errorもあるからねえ。そのあたりはPGセンスの有無が大きい。
いくらTry and Errorをしてもお前にゃ一生無理だってのはある。 どのクロスプラットフォームでもカスタムレンダラーなりDIなりに当たる仕組みは存在する（というか特にスマホ向けなら必須である）わけで
言語や文法が異なるだけで実質的には何も変わらずxamarin特有のことなどではない >>985
いや開発の高速化も普通に入るだろ。
お前の主観か？
>>986
この場合にネイティブとレンダらで試行錯誤がどう違うのかよろ クロスプラットフォームは総じて糞
その中でもXamarinはキングオブ糞 求められるのは高速化ではなく、効率化だな。速く組んでも無駄な動作ばかりしてたら駄目だろ。
そういう意味合いで、開発言語の共通化は部品の共通化になり、効率が上がる。 どうでもいい言葉遊びは置いといて、多くの部分を共通に作れるからトータル時間短く開発できるしメンテも楽。
決して共通化=早く開発できるではないけれど、自分の経験上は環境構築のトラブルなど考慮してもざまりんでやった方が別々に作るよりはるかにマシっていうか別々に作ることとか考えただけでもやだわ 最初にちょまどさえ使わなければこんなに粘着されることもなかったのに 粘着する基地外を叩くべきでそれでチョ窓を叩くのは基地外の思う壺 このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 290日 6時間 55分 0秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
