Xamarin Part6
■ このスレッドは過去ログ倉庫に格納されています
!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 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
ハンズオンとかなら価値あるけど体験談聞いて人脈作るとかどうでもええわ 面白い話が出るかは知らんが、初心者としてハマった話など何か参考になりそうな事あるかもあれば直接話し聞けて便利ってことで行くのは何もおかしくないと思うけどね
なんかこの人物事をすごく幼稚に捉えて自分に得することしかしようとしないで結局損してる感じな人に見える 前に参加した時はハンズオンだったな
悪くはなかった
しかし、他人が色々やってるのを外から貶さなくてもって思うわ
嫌なら自分独りで黙ってやってりゃ良いだけの話 人脈を馬鹿にしてる人多いけどスタートアップとかフリーランスとかで小規模なところから始めるとなると実際人脈の影響がかなり重要
能力さえあれば勝手に仕事が降ってくるなんてことないから ■ このスレッドは過去ログ倉庫に格納されています
