Xamarin Part6
レス数が1000を超えています。これ以上書き込みはできません。
>>229
んーネイティブは普通にAndroidをKotlinなりで開発する方法をC#に翻訳した感じだけど、formsはネイティブの上にUIフレームワークを乗っけてる感じなので、例えばTODOリストを作るとしても全然違う。
それぐらいだとformsではスタートアップのところでしかMainActivityとかに触ることはない。
自分もformsで業務アプリ作ってるけどAndroidの開発ほとんど知らないで作った。
が色々やってるとそのうちネイティブにも触らないといけなくなる。レンダラーとか。
formsはネイティブの知識があまり知らなくても共通に動かせるものが作れる。
けど突っ込んだことやる場合にネイティブのことを知らないといけなかったりネイティブの方がやりやすいこともある。
自分の感想では凝ったアプリでもかなりの部分はformsで作れるので自分ならforms使う。最近はflutterも良さげなので場合によってはそっちを選択するもよし。 自分ならネイティブにする
Forms の仕組みも理解しなきゃいけないから学習曲線なだらかな方が楽じゃないかな でも単一プラットフォーム向けに調整するだけでいいから、Forms が極端にネックになることもなさそうだしどっちでもそんなかわんないか >>234
各々のネイティブに詳しいならだけどそうでなかったらとりあえず両方で動く何かを作るんだったら formsの方が覚えること少ないと思うけどな
もちろんまともなものを作ろうとしたらおいおいネイティブの知識も必要になるけど。 >>232
情報も何もJavaの情報をそのまま流用するだけだろw LineBreakModeっておかしくない？
CharacterWrap とか WordWrap って折り返しの方式なのに
TailTruncation とか MiddleTruncation って文字列が入りきらないときの表示の方式
二つの意味が混在してる意味が分からない
Label で CharacterWrap かつ MiddleTruncation したいときどうすればいいの？ >>239
Effect なりを使わないと無理みたいだよ
公式でサポートしてほしい気もするから Issue 作ってみてはどうでしょうか？ プログラミング初心者でxamarin.Formsに手を出して5chブラウザ作ってるんだけどスレの表示に困ってる
Labelで書くとリンクや安価をタップできるようになるけど遅い（数秒〜10秒程度）
ListViewで書くと速いけど安価やリンクを押せるように出来ない（レスの塊としては押せると思う）
レス本文をパースして安価やリンクを押せるようにする自作ViewCell？を作ってListViewに入れるのが手っ取り早い気がしてるけど、パースするようなビューはコードでしか書けずコードでバインディングする（あるいはバインディングせずにListViewを使う）方法が分からない
用語がよく分かってないから変なこと言ってたら申し訳ないけどつまりは、スレを速く表示することとURLや安価をタップ可能な構造を両立したい MVVMはわかる？
MなりVMなりでパースしたものをVでバインディングすればいい
リストビューを使わないやつで何がそんな遅いのかはよく分からないんだが。
全部パースしてモニョモニョしてるから？ >>242
独学ばかりだから雰囲気でしか理解してないけどMVVMは表示系（V）とロジック系（M）とそれをつなぎ合わせる部分VMみたいな理解してる
Labelが本質的になぜ遅いかは分からないけど調べると40要素で100msくらいかかるって言ってるページがあったから数百レスあるスレでID、本文、名前とかごとにLabelを使うと数秒かかるのは納得してる
実際レス番だけ表示するようにしてもlabelを使うと800くらいあるスレで2,3秒かかった
（じゃあなぜListViewは速く描けるのか？はよく分からない。部分的に描画してるから？）
事前にパースしてっていうのはたぶんLabelを使うパターンを想定してると思うけど上の通りラベル単体で遅いからできなかった
それともListViewのセル内のバインディングを動的に弄ることができる？
こんなに早くレスしてくれてありがとう MVVMのおおまかな説明はそれでいいかと。
まあとにかくUI向けのコードを分離する１つの方法です。
GUI系のアプリは基本的にUIコントロールでの処理がムッサかかるからそこをなるべく避けないと。
全部のデータをラベルにぶっこんでたらおそくなるのは必然かと。
リストビューが速いのは言われるように部分的にしか表示しないから。仮想リストビューとかでググると出てくる。ちなCacheStrategyだったかな？そこの指定で仮想じゃなくも出来る。
5chのデータ形式は知らんが受信したデータを表示できる文字などに変換する部分のことをパースと言ってる。ラベルは関係ない。
MVVMの形にのっとってたらビューセル内のラベルが対応したVMのプロパティにバインディングしてるので、そのプロパティを変更すれば対応したラベルの表示が変わる >>244
ごめん、後半があまり分かってないから確認しながら返信してる
分からないことが多くて申し訳ない
> 受信したデータを表示できる文字などに変換する部分のことをパースと言ってる。ラベルは関係ない。
現状VMまででやっているのは文字コードの変換、不要なHTMLタグの除去、res構造体にID、名前、時間、レス番、本文に分けてstring型で入れてる
ここまでをパースと呼んでいる？ それとももっと他に含むものがある？
> MVVMの形にのっとってたらビューセル内のラベルが対応したVMのプロパティにバインディングしてるので、そのプロパティを変更すれば対応したラベルの表示が変わる
ビューセルと言うことはListView使うこと前提で良い？
上で書いたres構造体をそのままビューセルにバインディングするということ？
確かにそれは速く描けるのだけど、そうすると安価やリンクを挿入できない問題に至る
res構造体の本文要素をさらに細かくすると、レス毎に分解のされ方が違うから単純なバインディングで解決出来ない（ように思う） ラベルのテキストで省略とかがあることを考えるとプロパティの値に応じて見た目を弄ることが出来るわけだから本文を受け取ってそれを安価部リンク部で表示を変えるビューを自作すれば良いのかな？
どう作るか見当つかないけど… ListView もしくはそんな感じのネイティブ実装にするかの 2 択になる
ListView の場合、バインディングするとしたら表示時に全レス分 ViewModel 作ると遅いので、
俗に言う Infinite Scroll と言われる実装にしないと現実的なパフォーマンスは出ないと思うよ バースがどこまで含むかはやりたいこと次第だと思われ。
とにかく何かしらの受信データから処理に必要な値なりを抽出する部分
ViewCellにラベル乗っけたら安価とか何でも出来ると思うけどダメなん？
分解のされ方が違うから単純なバインディングで出来ないはよく分からんのだけど、DataTemplateSelector的な話かの レスの本文を表示するときに、分解された部分毎にラベル割り当てようとしてるんだろ。
そうすると、レスの内容によってURLやアンカーの数が違うからひつなラベルの数も違うから設計時にバインディングできないってことだろ。 本文用のらべる1個にしてFormattedTextで色付けして、部分クリックとかできたっけ? >>248
もしかして何か根本的なところで俺の理解がおかしい…？
色々弄ってる最中で本文しか表示してないけど今はこんな感じなんだ
https://i.imgur.com/8fglyEg.jpg
これを
https://i.imgur.com/BLqhbky.jpg
こんな風に部分的に選べるようにしたいのだけど、ViewCelって一律にバインディング指定してるから安価のあるレスの安価のある場所だけ別にバインディングするって出来ないと思ってる
まさに>>249
>>247
とりあえずListViewで攻めてみる
ネイティブで書く場合はまた別のスレになるのかな https://stackoverflow.com/questions/40592475/partial-text-clickable-in-xamarin-label
ああこの一番下のレス見るとLabelのFormattedTextで部分クリックとかできるね。レスの本文用のラベルをレス毎に1個用意して、これでアンカーやURL部分を色付けしてクリック時の処理書けばいい 後はこのFormattedTextの中身を組み立てる部分をどこに書くかだね。UWPの場合、添付プロパティ追加してそこに書いたりてきるけど。俺はxamarin使った事はねぇからそこは詳しいヒトにまかせる。 >>253
やりたいことはまさにこれ！
でも今日はもう眠いのでまた明日来ます 自分がやるとしたらViewModelにはOservableCollection<FormattedTextSrc>みたいなのがあってFormattedTextSrcはSpanなどにほぼ一対一対応することができるただのデータ。
たとえばList<Tuple<int,string>>などをプロパティで持っててintはその文字列をどのように扱うかがわかるもの。intはもちろんenumか何かにすべき。
でUI側のResViewなりがOnBindingContextだっけ？バインディングした時に上がるメソッドでそのListからFormattedTextを組み立てる >>255
OnBindingうんたらで大体なんとかなった！
https://i.imgur.com/wGRoAVF.jpg
細かな問題としてはvmまでにTupleのlistを作っても上手く渡せなかった（Timeout exceeded ...エラー出た）からvでstringを分解してること
中程度の問題としてはviewcellの塊自体にロングタップのイベント付ける方法が分かってないこと（多分、iOSプロジェクトの中にexportrendererみたいなのを書く？ 出来なくともタップで代用できる気もしてる）
かなり大きな問題はセル内の安価をタップしたときに安価先を表示する方法（指定されたレスの実体なり参照なり位置なりを渡す方法と現在の画面の上にこんな感じに https://i.imgur.com/twtzEHs.jpg 表示か移動かする方法）の見当が全く付いてないこと
viewcellのOnBindingContext..は親画面のことも前後のレスの情報も知らないからそれを渡す方法が必要だよね？ Viewは自分の表示位置は取れなかったかな…
スクリーン上でのView位置を取るような奴が何かあった気がするが。 後Viewの親は辿れると思うからそこで親のクラスを見つけるとかは出来ると思う >>258
親要素辿ってコンソールに表示できた
あとは自力でアプローチしてみる
色々ありがとう！ だいぶ専ブラっぽい見た目になってきた
そういえばリストを渡せない問題はデフォ値がコピペ元のstringのままだったからだった
https://i.imgur.com/ecL8Ahs.jpg
安価はListViewにvmをバインディングして再帰的になんとかしようかなと考え始めてる
明日は予定あるし明後日から仕事始まるからあまり時間割けなくなるけど頑張る visual studio 2015 Professionalでxamarin開発を始めたら
後々困ったりすることある？ >>263
対象のフレームワークが使えるなら大丈夫でしょうが、STANDARD2.0を使うのに1手間必要とかあるみたいですね。 WebAPIでホストのデータを取得し、Xamarin.Formsで受け取る処理を書いています。
WebAPIはLinuxでの実行も考えていますので、.NETCore 2.0 で、Xamarin.Forms は .NETStandard 2.0 を選択しています。
WebAPI側と、Xamarin側とで共通な処理を.NETCore 2.0のライブラリで実装しようとしましたが、プラットフォームが違うのでXamarin側で利用できません。
こういった場合、同じ内容を .NETStandard 2.0 のライブラリを作成し、ソースはリンクを張れば実現できるのでしょうか。
もしくは、「普通はこうやる」というのがあれば教えてください。 >>267
参照でのエラーです。
エラー NU1201 プロジェクト foo.core は netstandard2.0 (.NETStandard,Version=v2.0) と互換性がありません。 プロジェクト foo.core がサポートするもの: netcoreapp2.1 (.NETCoreApp,Version=v2.1) foo D:\Temp\VS2017\foo\foo\foo\foo.csproj 1 それサーバー側？
Standardのバージョン違うのでないとダメとか？ >>269
.NETCore2.1 WebAPI のプロジェクトでのエラーです。
参照先は .NETStandard 2.0 クラスライブラリです。
とりあえずnuget経由なら、.NETCore2.1 のプロジェクトに .NETStandard のライブラリを追加できるようなので試してみます。 共通ロジックは.NetStandardクラスライブラリで作って、NugetパッケージにしてNASに放り込んどく
NASをローカルリポジトリに登録しといて、プロジェクトごとに欲しいやつを食わせる formのWPFとGTK#っていつプレビュー版じゃなくなるんだろ >>271
ライブラリ頻繁にいじるものでないならいいけど、そうでないとプロジェクト参照の方がいいな AndroidでC#のアプリをダウンロードすればアイコンをクリックするだけで
起動できるようにする場合、.NET の RUNTIME はいつインストールされる？
AndroidマシンはCPUが色々あるらしいので、.NET RUNTIME は、1つだけの
CPUに特化したものでは駄目なはず。なので、以下のどれかを行わなくてはならない
ハズ：
1. アプリの起動前に、手作業でそのCPUに応じたRUNTIME をインストールしておく。
2. アプリの初回起動時にCPUに応じたものをネットから自動ダウンロードする。
3. RUNTIMEは、CPU Native 用ではなく、Java仮想マシン用のものとする。
つまり、.NET 仮想マシンが、Java仮想マシンの上で動作する二重構造
とする。<--- めちゃくちゃ効率が悪い。 >>274
apkの中に各CPU向けランタイムも含まれてるから、ストアからアプリをダウンロードしたならそこに適切なランタイムも勝手に含まれている だからアプリとは別にランタイムをダウンロードする作業はありません androidならapkに各CPU用のランタイムが含まれてるんじゃねぇかな。つまりユーザーがアプリをダウンロードする段階で全部ダウンロードしてインストールしてる。 >>275
でも、CPUの種類は時間がたつにつれて増えていくかも知れないので、
それだと、2019年に作ったC#アプリのapkは、再コンパイルなしでは
新しい Android マシンでは起動できないと思うけど。 C#アプリの Android 版の apk は、15MB 程しかないらしい。
これに本当に全てのCPU向けの .NET ランタイムが入るだろうか？
Windowsマシンで、Windows Update の詳細記述を見ていると
.NET の 修正 Update だけで、数10MB〜数100MB あったと思う。
修正と言うのは、部分 patch にすれば小さく出来るはず。
それでも、こんなに大きい。
あらゆる Android マシンの、修正 patch ではない、完全な .NET ランタイムが、
本当に 15MB に入るのだろうか。
どっちにしろ、論理的に考えて、それでは新しいアーキテクチャの CPU には対応できない。 >>278
CPUが追加されるのとか数年に1回くらいだろ
再コンパイルすればいいじゃん
追加されたCPUが下位互換持ってたら再コンパイルなしでも動くし >>279
apkのランタイムサイズは15MB×サポートCPU数だろ
ストアからは適切なもんだけダウンロードされるから15MBのダウンロードになるわけだな >>281
そういう仕組みだったのか。
じゃあ、Java の思想とはぜんぜん違う。
Java の場合は、同じ jar ファイルが、異なるマシンでもそのまま動作する。
C#の場合、MSの判断一つで特定のCPU用のパッケージが作れなくなってしまう可能性が
ある訳だね。なんちゅうこっちゃ。Javaとは全く違うじゃない。 >>282
Java + NDK(C++)で作られてるアプリがたくさんあるだろ
それと同じことよ >>283
Android マシンには、最初からそのマシンの CPU に合わせた
JVM がインストールされているので、違うぞ。 >>281
あれ、そうなの？適切なものだけダウンロードだと開発者が署名したapk分解しちゃうの？署名無効になるな。
つか、arm端末にインストールされたapk覗くとx86のバイナリも含まれてるぞ >>287
x86コードの除去し忘れだったりして。 基本的に互換性のない新CPUなんてそう頻繁に出ないでしょ。
そのCPUの性能を100%引き出したいのでなければCPUが出る都度コンパイルなんてしないでしょ。 >>289
「各アーキテクチャ向けapk」と「それらをまとめたapk」は、
それぞれ何MB 位なの。
同じサイズということは論理的にありえないハズだが。 んなもの、アプリによって変わるにきまっているだろ。
Javaのアプリは何MBくらいなの？って聞かれて的確な答えが返せるの？ >>288,289
あ、そういうオプションもあるのね。
xamarin関係なく前にいくつかの他人のapkとかリバースエンジニアリングしてたときぬにNDK使ってるやつでx86やらarmのバイナリが含まれてるのばっかだったからそういうもんだと思ってた。
c/c++部分がちょこっとだったからそうなってたのか。
すまんかった。 >>292
Android における C# の GUI の Hello World の場合に決まってるじゃん。 >>294
自分で試せばいいやん。ほぼ全部無料のものばかりだ。 自分で試せることすら率先してやらない程度の興味ならそれこそ時間の無駄じゃろ そんな簡単なことなのに、誰も答えられないということは、誰も試してないこと
が証明されました。
（証明終わり） そうだね
誰が何を知りたかった話なのかは当人以外どうでもいいからね 聞けば何でも教えてもらえると思ってるのは
典型的なゆとり わざわざhello worldの容量調べようなんてこと誰も考えないからこれから作らないと確認できない
それなら自分で作れば？となるのは極めて自然 C#の場合、よっぽど作りこまなければ自分のコード部分のバイトサイズなんて
アプリ全体のサイズの数%未満だろう。だから、Hello Worldでもなんでもあんま
変わらんかも知れんけどな。
C#アプリのサイズが仮に15MBとしよう。自分の書いたプログラムがコンパイル
された結果のバイナリコードは、大体20KB〜300KBくらいなんだよ、多分。 つか、xamarin.essentialsは誰もしないんだな アーキテクチャー別のバイナリーダウンロードする機能ってもう Xamarin でサポートされたんだっけ？
名前忘れちゃったけど割と最近 Android でサポートされた気がするからまだなんじゃないの
それ抜きにしてもリンカー入れれば最小のアプリサイズは 10MB 未満だよ アプリサイズより起動速度の遅さが気になるけど、その Qiita の投稿の手法だったり、Visual Studio の次のバージョンでも d8/r8 とかいうやつで改善されるらしいしよっぽどシビアな案件じゃなければ気になんないんじゃないのという気持ちがある つうか、そのアプリサイズって、起動直後にネットから追加 Download が
絶対に始まらない保障はあるの？ 斬新な発想だな。ランタイムを段階的に追加ダウンロードするの? >>311
インターネットに繋がってない環境でapkインストールしてから正常起動するか試してみたらええやん Xamarin程の糞はない
ttps://twitter.com/ca_developers/status/1093416959243300864?s=09
https://twitter.com/5chan_nel (5ch newer account) 何のイベントか知らんけど参加者のMacユーザーの割合やクロスプラットフォーム開発ツール(?)への関心の低さを考えれば
当たり前の結果の気がする
というかクロスプラットフォームとマルチプラットフォームの使い方間違えてないか？ x-code使わないとダメだから単体では無理なのはわかるが、Windows用VisualStudioでOSX用のアプリってビルドできないの？ こういうのに参加する自称意識高い系のミーハーはMac使い多いな。
中身なさそうなアホばっかやな お前らがXamarinに費やした時間は無駄だったということ残念でした macないとビルドできないからな。
それがXamarinがブレイクしない理由でもある。 既に、Apple 離れは始まってるのかね。
株が急落、iPhoneの売り上げの急減、日本での売り上げの、Huauay
みたいな中華スマホへの敗退は聞いたけど。
少なくとも、10代のプログラマには嫌われてるだろうね。
企業以外は作っても公開できないので、昔の「パソコン」や「ポケコン」
「MSX」みたいなものの代わりにはなりえないね。 ん？FlutterとかはMacなくてもビルドして実機で動かしたりできるの？ できないよ
そもそも趣味だとしてもモバイル開発をやっててMacを持ってないとかありえんわ 仕事ならともかく趣味であれば自分の所有しているスマホ以外は興味薄いだろ
AndroidユーザーがわざわざMac手に入れる動機としては弱い
XamarinもマルチプラットフォームではあるけどどちらかといえばAndroid寄り
逆にMacユーザーにしてみればXamarin への関心は薄い 元はMS、Windows派の技術なのにAndroid向け、iPhoneはMacないとダメっていう中途半端さがネック Appleが頑なにライセンス解放しないので仕方ない
最近の凋落ぶりを見るとそろそろ意識改革してもおかしくはないが…
MSがXamarinを買収してまでライセンスを一般に無償解放したのを見習って欲しい >>324
俺は仕事だけど、swiftよりもC#の方が快適だからiOSのみの案件でも最近はXamarinを好んで使うよ 若い人で、自作プロラムをいろんな人に使ってもらいたい人は困るだろうな。
でも、MSのVisualStdioのライセンスも日本には合わない気がするよ。 そうか？
個人開発者やオープンソース開発に対しては殆ど完全に無償解放されてるだろ
商用利用についても以前に比べれば随分敷居は下がった
以前のVS Enterpriseだと新規で200万近く費用必要だったのが今はほぼ半額
維持するだけなら年間20万程度で済む はー。
ひきこもりのオイラの通信回線の遅さを知らないなー。
いくら無料でもDLできないんだよ。。。 1,000円払うから、誰か宅配してくれ、VS Community。 近所にネカフェはないのか？
引きこもりでもたまには外出くらいはするだろ 近所にはない。風呂入って、バスと電車で行って帰ってきて、また風呂に入らね
ばならん。
そこに巨大な壁が有る。 それなら雑誌かムックの付録でVSのDVDが付属してる古本でも探してネットでポチれ そんな通信速度だと何するにしても辛いのでまず速くするのがベストなのでは >>330
それが日本に合ってないという理由？
ふざけんよ 少しは自分で調べろ
初心者向けの入門書や定期刊行雑誌のバックナンバーなんかを調べれば出てくる
出版社のサイトかAmazonなどの評価欄を参考にしろ
ただ良くも悪くもVS2017はバージョン末期なので最近新規に刊行されたものは少ない
VS2017登場当時の頃を狙え Expression Edition は見つかるけど、Community Edition も本当にあるんか？ 20年前にこの業界で仕事始めてからずっと言っているのは、UIのクロスプラットフォーム技術は必ず失敗する。
ttps://twitter.com/mkino/status/1093731721378377729?s=19
https://twitter.com/5chan_nel (5ch newer account) それ言い出すとすべてのWebアプリも該当するんだけどね コンビニで落とせよ
スマホあんだろ？
1.セブンに行く
2.セブンのアプリをインストールしてwifiにログインする
3.スマホのブラウザをpcモードにしてxamarinをdl
4.スマホで落としたファイルをpcにコピーしてインストール
アップデートの時は
ノートpcならノートPC持ってセブン行け
デスクトップなら寝てる間にやれ Xamarin は UI のクロスプラットフォーム化を目指したものじゃないよ。その方の書き方が誤ってて、意図してるものに該当するのは Xamarin.Forms だね。その時点で雑な言い方する人なんだなと思っちゃう 5,000円くらいで、Wifiが使える端末を買えば、Lawsonでも行けるかな。
近くにはLawsonしかない。しかも、500mくらい離れていると思う。 をーー。
そういうことが出来る、お勧めの5,000円くらいまでで変えるWifi端末を教えて
くれやーーー。PCと接続してデータを読み取れる奴ーー。 >>346
form sでほとんどのもの作れるし、必要ならrendererなりネイティブコントロール使うなり何とでもなるからなー 巨大ファイルのダウンロードなら 4G 回線でも十分速いんじゃない。ギガモンスターみたいなプラン入ってさ。でも 50GB じゃ足りないかも スマホないのか。じゃあできるだけ安くで速度考えればネカフェだな 一ヶ月だけ、自宅に光回線契約して、すぐにやめられる安いプロバイダって
どっかない？ というかそもそも地域はどこなのか
一軒家なのか共同住宅なのか
契約者は本人なのか家族なのか
情報が無さすぎて何も分からん Xamarin.WPFでKeyDownイベントの取得はどうやればいいのでしょうか。
UWPの時は、Dispatcher.AcceleratorKeyActivatedに追加すれば出来たのですが、
Xamarin.Forms.Platform.WPF.PageRendererでは項目がありませんでした。 自己解決しました。
テラテイルでも書きましたが、MainWindowに対してイベントハンドラを追加することで取得できるようになりました。 Windows版のiOS用AppDesignerでのScrollViewの使い方がぜんぜん分からん
XCodeだとScrollViewにViewを突っ込むだけでスクロールするのに、同じようなことをやっても全くスクロールせえへん・・・ ああ、これデザイナーじゃなくてXCodeの画面なのか >>369
Xamarin live playerではあかんか？ >>370
あれで良さげな気はする
ちょと公式で出て欲しい気はする c#でandroid開発するなら今でもXamarinがスタンダードなんですか？
本家VisualStudioとVS for Macのどちらが良いでしょうか？
VS for Macのほうが軽いように感じるのとスマホの仮想化が簡単ですが本家のほうが開発支援は手厚いはずなので迷いますね
今のところiPhone開発の予定はありません >>373
グラフィックメインならUnity、そうでないならXamarinがスタンダードでしょうな
Xamarinでやる場合WindowsだろうがMacだろうがプロジェクトファイルは共通だから自分の好みに合わせてどっちでやっても困らん 現に弊社のチームでも同じアプリ開発するのにWindows使う人間とMac使う人間混在してるからね いつの間にかXamarin.FormsのテンプレートからUWPが消えてAndroidとiOSだけになってるな。
UWPはどうでもいいが、WPFとMACを入れてくれないかな・・・ MSはどこへ行こうとしているのか？
舵取りする人がいない。 クロスプラットフォームは全部糞
ネイティブのみが正義 よっぽどじゃないとネイティブで別のプラットフォームに作り直そうとか思わないですが… 世の中に出ている有名なアプリは全てプラットフォーム毎に別で実装している
Xamarinで作れるのは見た目も挙動もしょぼいゴミアプリだけ >>384
お前XamarinとXamarin.Formsの区別付いてないだろw
仮にFormsだとしてもおそらくほとんどのものは作れるけどな クロスプラットフォームだとしょぼいのしかできません！と客に説明しなきゃ仕事取れないプログラマーがいるんだよな
古いスキルをアップデートせず一生食っていきたいと考える勉強嫌いな技術者 じゃあ具体的にXamarin製の有名アプリ名挙げてみろよ
有名なの一つもねえわ Windows Forms と WPF があって、UWP、 Xamarin.*も出てきて、.Net 関係のテクノロジーはもうぐちゃぐちゃ。 Run Anywhere のはずだった Xamarine なのに、Xamarin.Forms では、
Linux 用開発は出来ないの？ >>388
まだまだあるで、
Windows CE → Silverlight → WinRT → UWP
似て非なるフレームワークを次々とリリースし、その都度対応を強い続けてるし。 >>390
>>388
こんなふうにこれからも黒歴史を続けるのであれば、もう Microsoft を追いかける気力も湧かないですねえ… >>388
Win向けにUIライブラリとアプリケーションモデルをコロコロ変えてきてるのは同意だけどXamarinはそれとは別の話だぞ？ >>390
それらも線で繋がるの最後のやつだけじゃねーか
むしろ新しい環境(WEBや組み込み)向けに似通ったプログラミングモデルを使えるようにしただけ。
UWPは更にプログラミングモデルだけでなくアプリケーションをいろいろな環境でも使えるようにしようとする試みでしよ。そゆんでは組み込み->UWPは線が繋がってると言えるのか
むしろ他のところはそんなのが一切な記載から個別にネイティブで書かなきゃいけませんよってだけで。 Windows10 Mobileが終わってもXamarin.iOS/Xamarin.Androidをサポートし続けてくれるのかどうかは気になるな・・・・
これらってWindows10 Mobileにアプリを引っ張ってくるために策みたいなもんだったんでしょ？その目的が無くなったらやばくねえか >>397
最初からWindows10モバイルはXamarinのメイン扱いではない サポートされるかどうかは分からん。
そもそも、開発環境自体は使う人が少なすぎて売り上げも利益も余り出ない
と昔聞いたことがある。
だから、MSが開発環境を作る理由は、ビル・ゲイツが「作りたいから」と、
OSを売りたいから、の2つだと思う。
金儲けにならなくても、作りたいから作る的な部分はありえるかも知れぬ。 >>398
そうだ。元々は、MSとは全く(?)関係ない別会社が、C# 用の
Multiplatform Toolkit として出していたのを、MSが買収したんだんだ。
だから、元々は、MSの首脳陣の望みが反映されているわけじゃない。
むしろ、目の上のたんこぶだからコントロールするために買収したと
思ってる。 >>397
VS2019RCのテンプレートから（iOSでもAndroidでもなく）UWPの方が消えたもんで最近騒然としてたなｗ 買い殺しですね
ライバルチームの主力選手を買うのと一緒 >>402
そういうやり方が問題になってるらしい。超大企業がベンチャーの芽を摘んで
しまうので。まるで大人が赤ん坊を苛め倒すみたいな感じ。弱いものいじめ。 >>403
商品化する技術を買っただけで、オープンソースの方は続けられているけど？ >>404
大体オープンソースで立派に成長したソフトは、一般人ではなく、大企業
サラリーマン・プログラマが有給で作ったものが多いんだ。
Linux(IBM)や、Qt(Nokia)、clang(Apple) などがそれに当たる。
だから、MSの傘下に入った時点で、将来はMSの独占を強化する方向だけが
成長していく可能性がとても高い。デスクトップ向けのマルチプラット
フォーム ToolKit はWindowsの地位を危うくするのでもう終了すると思う。 >>405
Windowsにまるで囚われないVSCodeやTypeScriptは大人気だしコミュニティとの関係も良好やん いずれiOSとAndroidはサポートを切られる気がするな
Xamarinを買ったのもUbuntu版XamarinStudioが出るのを直前で阻止するためじゃないの MSにとっては以前の年間約20万円×3のライセンス料では利用者が増えなくてC#のモバイル展開が難しかったのでXamarin買収したんだろ 結果として買収しない方がよかったな。時間かかってもマイクロソフトが一から作るべきだった。そしたら、今頃発表になってたのかなぁ でもMicrosoftが買ってくれて無料でXamarinが使えたんだからよかったかな
ただAzureの収益につながるとかMicrosoftになんか大きなメリットが無いとね、いつサポートが打ち切られるか不安だわ C#,.NETでモバイル開発できるだけでAzureの誘導にも寄与するだろ Androidが何年後かにFuchsiaに置き換わったとき、Fuchsiaを新規でサポートするのか気になるな
しないのならどさくさに紛れてiOSも同時期に終わりかな ケーキでダイエットってw
美人で巨乳なのは良いことだ >>422
よく考えてみると Xamarine は Unityと働きが被っている部分が多かったり。 Unityってゲーム機等のMonoが公式サポートしてない端末でも動いてるけどさあ
あれってどういう仕組で動いてんの？ ほんと、日本以外を含めて使ってる人おるんかな？
金がマイクロソフトに落ちないことには将来性ねえだろう >>430
それって.NET作ってもMSに金落ちないから将来性がないって言ってるのと一緒やで >>432
.netはAzureに金を落とさせるためだから将来性あるよ >>433
Windowsは、アプリ資産の互換性のために支配力を維持できたけど、
クラウド分野ではそれがないので独占は出来ない。
MSの終わりの始まりかも。 >>433
だからXamarinも一緒だろって話だよ >>435
株主が儲けようとして余計な下支えするから、消費者目線でもプログラマ目線でも
ない質の悪いソフトウェアがはびこることになってしまい、世界中の生産性が
下がってしまって迷惑してる。 >>436
そうはいかんな、Xamarinはあんまり使われてねえんだから XamarinよりもUWPでモバイルやってたほうが多く、数％はシェア取れていた いつサポートが打ち切られるかわからないから長期プロダクトに使えない
長期プロダクトに使えないからユーザーが少ない
ユーザーが少ないからいつサポートが打ち切られるかわからない
・・・・と、酷い悪循環に陥ってる気がする native アプリだと AppleStore や GooglePlay に登録するから
手数料が取られる。Webアプリだと手数料が取られない。
そんな違いがあるとは知らなかった。 トレンドがどんどん変わり、どう変わるかは事前に予想できない状況なので、
色んなプラットフォームで動く可能性の有る言語C#は安心感はあるが、
一方で起動速度も実行速度も遅いみたいだ。MS純正のHTML Editorの
FrontPageとExpression Webは、C++とC#の違いだけで機能はほぼ同じだが、
速度差がかなりあり、後者は常用するのは辛い。また、最近のVSの遅さも
C#に起因している可能性がある。 >>446
懐かしい製品だけどどちらも古すぎるだろ
もうとっくにサポート終わってるんじゃないのか？ Xamarinごと捨てるか、Mono捨てて.Net coreベースにして更に.net nativeにするなどの早期の英断が必要な時期。
来月のBuild 2019のカンファレンスで運命が決まるだろう(適当) MSがXamarin切り捨てる可能性はあるけど、そうなったら別会社で有料になっても良いから続けて欲しいな。
やっぱりお手軽さはXamarinが一番だと思う。 Xamarin社はMSの子会社ではあるけど今でも一応は独立した別企業だよ Xamarin捨てる必要ってアプリサイズぐらいしかなくね？あとよっぽど起動時間を短縮したいか。
AndroidもAOTかけたらそんな遅くないだろ Xamarin.Formsは置いといて、Xamarin.Native使うと快適なC#でコーディングできるということだけでありがたいね
情報量はswiftやJavaのそのまま流用できるから困らないし vst2019出たみたいだけど
xamarinアプリの起動
少しは速くなったの？ ツールが変わっただけだろ
アプリの起動には関係ないだろ VS2019でXamarin.FormsでもIntelliSense が使えるようになったってのを見たけどXamlのこと？ と思うけど今まで使えなかったん？R#入れてたから気づかんかった 今までも使えてたけど AI で補完するようになった >>456
アプリの起動速度は多分変わんない。アプリサイズを小さくできるようになったのと、ビルド速度がはやくなった。プロジェクト開くのも速くなったのかな? visual studio for mac はビルド速くなったって公式にあったけど
windowsの方も速くなった？ Android で d8/r8 のオプション有効にすれば速くなるって書いてある Xamarin.WPFだけど、基本的にはマウス操作なんだな・・・
キーボード主体で動かそうとしたら問題山積みだわ。
DisplayAlertですらキーボード操作できない。
ちと、テンション落ちた・・・ https://blog.nkzn.info/entry/2019/04/16/163743
によると、
「マイクロソフトのiOSおよびAndroidアプリの中身をスキャンしてみた。
その中で、Word、Excel、Xbox、その他もろもろ38本ものアプリが、
最近のアップデートでReact Nativeを利用するようになったことを発見した」
ってことだが、なんでなん？ >>467
以前からWeb版OfficeがあるんだからそれをJSで移植する方が効率いいでしょ マイクロソフト自身も呆れて自社プロダクトに採用しないのがXamarin Pix（グラフィックデバッガの方ではない）とかいうよくわからんアプリで採用してるのは見たな >>468
いやロジックは基本的にバイナリだよ
C++のを共有してる 今見たらXamarin.FormsのテンプレにUWPが復活してるな。
どちらかといえば WPF に力を入れてほしいんだが・・・ UWPってなんでクソなんだっけ？
なんかすると警告見たいの出るんだっけ？
ど忘れしたわ ストアからしか入れられない、機能に制限があるっちゃある辺りじゃ
いいとこともあるんだけどね >>474
ローカルからでもインストールできるけど？ >>476
ローカルで動くインストーラを作れるの知らない？ >>481
「開発とか用」っていう意味がわからん。
アプリを開発して、開発PC以外で使うなら必要なものをコピーするか、インストーラを作って実行するしかないだろ。 >>482
いやだからそれ特定のデバイスに配布するのにしか使えないよね？ 上でストアからしかとか言ってるのは、そもそも企業で社内に配布するとかも省いてるんだからそれぐらい汲み取れ >>484
は？
Webサーバなり、NASなり、公開できる場所さえあれば社内だろうが、不特定多数だろうが配布できますけど？
自動更新もできますが？
それぐらいくみ取れとか、バカ営業の要件定義かよ。 FormsでiOSで動作させてListViewにバインドしてあるObservableCollectionを
Clear()してGCしてもメモリ使用量上がりっぱなしなんだけどこういうもの？
ObservableCollectionの中身のオブジェクトはGCに回収されてるんだけど・・・ 他のところでリークしてないの
つかプロファイラ、多少はまともになった？ >>486
ListViewが参照しているからそのままになってるんじゃないの？
ListViewを破棄してみれば？ 大胆にぶっ壊れていても放ったらかしだからな・・・・
VisualStudio for MacのIntelliSenseが参照する範囲がWindows版やVSCodeより狭くて使いづらい
Xamarin.iOSでネイティブコードをリンクする際、参照先を間違えてWindows用のDLLをリンクしようとしてしまう（年末年始あたりに治った2017のバグが大復活！）
Windows版のみXamarin.Androidのプレビュー機能が特定の機能との関係で不安定 原因分かった
GroupHeaderTemplateがメモリリークしている
これ外したら全くメモリ使用量増えなくなった
けっこう凝ったデザインをヘッダでやってたから派手にリークしてたわ
幸い何百件も表示するようなページじゃないからTableViewかなんか
カスタマイズして置き換えるか・・・ >>491
どこでどう参照残ってんだろな
プロファイラとか使った？ >>493
プロファイラってVisual Studio Enterpriseじゃないと使えないやつだよね？
ライセンスないから使ってない
自前でつくったオブジェクトのWeakReferenceを片っ端からリストに突っ込んで
泥臭いprinfデバッグで問題なかったから、Xamarinに何か問題あるなと思って
ページを少しずつ削っていったら分かった。
実際小さい再現用のプロジェクトつくってGroupHeaderTemplateつけて
ObservableCollectionにオブジェクト出し入れしてるだけで
GC.GetTotalMemoryが増大していってるので間違いないはず >>494
最初のやつはiOSでARCの関係なんだろうか？
にしてもC#と同じくDisposeしなくともそのうち回収される気がする。
2つ目のやつはXamarinに限らずC#固有の有名なリークパターンなのでこれは慣れてる。 broadFileSystemAccess対応でUWP/iOS/Android/MACOS対応のファイルアクセスライブラリって無いかな？
フォルダの指定、フォルダ内のファイル（フォルダも含む）一覧、ファイルのストリーム化だけでいいんだが・・・ >>498
ライブラリの形態は問いません。
ご存知でしたら教えていただけますか？ いやだからEssential 、使用用途に合うか調べろや >>500
ざっと調べてみましたが、任意のフォルダ（例えば、D:\Temp）を指定する方法が見つかりません。
もしその方法が無いようなら自分の求めているものではないようです。 Google、「Flutter for Web」発表。FlutterからWebアプリを生成。Flutterはマルチプラットフォーム対応のフレームワークに。Google I/O 2019 − Publickey
https://www.publickey1.jp/blog/19/googleflutter_for_webflutterwebfluttergoogle_io_2019.html
マイクロソフトにはこれをやってほしかった C#がブラウザフロントエンド征服すりゃワンチャンあるって いまandroid用のアプリをandroid studio+javaで開発してますが、
言語やライブラリの知識経験はJavaよりc#+.Netの方があります。
Xamarinに乗り替えると幸せになれますか？
またXamarinのレイヤー(?)被せる事のオーバーヘッドってあるんですか？
android studio+javaだと出来るけどXamarinでは出来ないみたいな制約とかありますか？ オーバーヘッドはこの記事読んで
https://qiita.com/conduits/items/cd7338329c3b7c22dc9c
androidしか開発しないんならネイティブでいいんじゃね？とも
やっぱC#＋VisualStudioで書きたいわ、でも新しいこと覚えたくねぇならXamarin.Android
マルチプラットフォームならXamarin..Forms、Prismに慣れときゃ非XamarinのWPFやUWPやMaｃも視野に
自分がどうしたいかやね
Xamarinでできないことについては、androidのAPIラップしとるから基本的に全部できるはずだけど、
手軽にマルチプラットフォームやりたいからPrismだけ把握しとけばいいやの人なんでそこら辺詳しくないわ >>504
基本的にはしあわせにはならない
なぜならc#の知識よりandroidでの開発経験のほうが重要だから >>507
そんなのはどんなアプリをどんな風に作りたいかによるだろハゲ >>504
Xamarim経験3年ほどの初心者だがアドバイス。
基本的にXamarinだからできないということはない。
メリットはLINQなどJavaよりC#のほうが言語的に便利な構文が多いので、サクッと簡潔に書けることが多い。ただし好みと場合による。
デメリットは色々あるが、一番大きいのはちょくちょくXamarin特有のバグに悩まされることがある。
パフォーマンスについては概ね問題ないが、例えばBLE関連のようなAndroid SDKでJava I/Fしか用意されてないもの(Nativeから使用できないもの)はNative→Java→MonoのマイグレーションをすることになるのでCPU負荷が高くなる。
結論としては対象アプリがAndroidだけならXamarin使う必要はない。 >>509
それもその人によるだろ
Androidでしか作らなくても普段Javaに馴染みないような人だったらわざわざ開発環境整えてJavaで開発するより慣れ親しんだC#とVSでサクッと開発とかするだろ普通 >>510
Javaに馴染みがなかったらそうですけど、>>504は今Java使ってるようなのでわざわざXamarinに乗り換える必要はないのでは？ >>511
.NET,C#に慣れてるいうからその辺と今後の他プラットフォームとのロジック共通かを考えてXamarinも全然ありでしょ
ただ上でも言われてるように余計なレイヤー増えるからパフォーマンス劣化はそんなないだろうけど多少なり複雑度は増えるのでそのへんのデメメリのバランス次第かと .NET5のSwiftやJavaとのinteroperabilityってのは、Swift等からC#で書いたコードを呼び出せるようになるんか？ >>510
サクッと言うのはちがうんでは？
SDKとか考えたら普通にandroid studioのほうがサクッとインストールしてあまり問題も出ないよ
みんなXamarinに飛びつくけどコレジャナイ感で止めていく
フォームにボタン一個で押したらメッセージ出すアプリを作ってみんな出ていく
実際androidやiOSなどの経験や知識がないとまともなアプリ作れない
単一のターゲットでしか使わない場合javaがc#に変わるというだけで選択するとがっかりして出ていくだろうね 俺は２年前から糞だと見抜いていたからな
我ながら先見の明に感心する 単一ターゲットでもC#でコーディングできるだけでかなり快適に開発できてるけどな
Formsはまだ微妙だけどXamarin.Nativeはかなり快適
Android StudioもXcodeもそれなりに経験あるが Microsoft、「.NET Core 3.0」の後継となる「.NET 5」を2020年にリリース
https://www.atmarkit.co.jp/ait/articles/1905/09/news108.html
Microsoftは「.NET Core」「.NET Framework」「Xamarin／Mono」を1つに集約すると発表した。
「.NET Core 3.0」の後継となる「.NET 5」は、Windows、Linux、macOS、iOS、Android、tvOS、watchOS、
WebAssemblyなどに対応した開発が可能な単一のプラットフォームになる。
https://devblogs.microsoft.com/dotnet/wp-content/uploads/sites/10/2019/05/dotnet5_platform.png iOSの開発はStoryboardが主流じゃなくなりそうだな
純正開発環境に近い開発方法でC#を使える時代は終わるのかな・・・・ Xamarin.Forms でフリーで使用できる DataGridView はありませんか？
ComponentOne等の市販ライブラリでは見つけたんですけど、個人的な趣味のPGにうん十万もかけたくないので・・・
ヘッダ行を常に表示。データ行はスクロール可。データ行をタップ、もしくはダブルタップでイベント発生。データはList<T>でBinding可能なもの。
ってのが理想です。 >>526
標準のStackLayout・ScrollView・ListViewの組み合わせで作れそうだけどね >>528
1行に３項目あって、それぞれの文字列長が一定じゃないんですよね。
それぞれの頭を縦に揃えたいけど・・・
ColumnDefinitionで決め打ちするしかないですかね。
その時に必要な最大幅がわかれば Width="{Binding Col1Width}" とかでできそうなんですけどね。 >>530
見てみましたが、実際に表示する文字列の指定方法が無いのでプロポーショナルフォントだと正確な幅は出ませんよね？ >>531
LabelのTextプロパティにセットしても駄目だった？ >>532
おお。ちゃんとしたサイズかどうかはともかく、"ABC"と"abcdefg"では違った結果が返ってきました。
ちょっとあがいてみます。
ありがとうございました。 Windows 10の電卓アプリがiOS/Android/WebAssemblyで動作 〜「Uno Calculator」が公開 - 窓の杜
https://forest.watch.impress.co.jp/docs/news/1193107.html
Xamarinよりプラットフォームの多いこっち買ってくれたほうが良かったな フレームワークの出来をドヤって見せるにしてはちょっとショボくね？ 全く違うか？結局はクロスプラットフォーム実現するためのものだと思うが >>521
ソースひとつで全てのプラットフォームで動くアプリが書けるなら、
Windowsの優位性がなくなりそうだ。MSには、やるといって、実際やら
無かった前例があり、
「将来できるようになるからC#使っていれば良い事有るよ」
詐欺の恐れがある。 iOSやAndroidのアプリをUWPに流させるという莫大なメリットがMSにはある MSとしてはWindowsに限らず各OSからAzureに繋いで課金してもらおうという戦略だよ
それで各OSで動作するAzure向けライブラリを色々作ってるんだよ >>540
Windowsの優位性がなくなったからこそ必要なのに >>541
それは、スマホ--->Windows へのアプリの流入を想定しているということだけど、
逆方向の流れが生じてしまう可能性もある。それを甘く見ているのだろうか。
仮にWindowsが不要になって売れなくなると、2兆円を超えるくらい、MSの
売上げが減る。確か、会社全体だと7兆円くらいの売上げだったから、無視できる
数値ではないと思うが。 >>544
マルチプラットフォームの開発ルールの開発で、どうしてWindowsの優位性が
が増す？？ 無視できる額ではないけどMS自身はソフトウェアを売って稼ぐモデルからは脱却したがってるから 無視できる額ではないけどMS自身はソフトウェアを売って稼ぐビジネスモデルからは脱却したがってるから ナデラになってからMSは物凄く嫌味な感じのする企業になった。
株価下落は、それだだんだん分かってきたことから来るものかもしれない。 ナデラは技術を舐めており、人を集めさえすれば出来ると思ってるが、
最近のVSの速度の遅さとサイズの大きさを見ればそれが幻想であることが分かる。
ダウンロードとインストールに莫大な時間がかかるし、起動速度もコンパイル速度
もとても遅い。C#で作ったプログラムもとても遅い。Windowsは新バージョンに
乗り換えるとアプリの起動速度がとても遅くなり、Update前より品質低下する。 MSはナデラになってから技術の会社から一般人向けの会社になった。 GestureRecognizerを試しているんだがPanとTapは問題ないのにSwipeとPinchが起こせない。
コードビハインドでDebug.WriteLineでコンソールにログをはくだけの簡単なコードなんだけど。
SimulatorでOptionキー押してピンチ操作してる感出てるのにイベントが発生してくれないのはなぜなんだ？
同じようにハマった人いない？
誰か教えてえろいひと >>567
macOS 10.14（Mojave）だよ
Optionキーって言ってるからmacOSってことは分かると思うが
simulatorのiOSは12.4でXRで試してる
osもvsもアップデートかけたばかりだから基本的には最新版になってるはず
ググっても同じように困ってる人あんまり見当たらないし、オレの操作の仕方がどこか悪いんじゃないかと思ってるんだが全然分からなくてな >>566,>>568
自己解決したわ
Optionキー押してtouchpadをスライドしてたんだが
touchpadを押した状態(クリックした状態)でスライドさせないとダメなんだな
スレ汚してすまん 誰か助けて！
あるパッケージがPCLはなくてiOS、Android個別でしか提供されてなくて各プラットフォームに処理を書いてるんだけど
どうしてもiOS、Androidでパッケージを利用したオブジェクトを共通で受け取りたいんだけどDependencyServiceでオブジェクトを受け取っても型がないからエラーになっちゃう
いくら調べても共通側での型の利用方法がわからないんだけど解決策って存在する？
調べるとJNIでMCWやACWsなんかがあるけどこれってJavaをP/Invokeで呼び出すっぽいからなんか違うっぽいしわかんないわ・・・ >>570
ネイティブの型をそのまま使うとかって意味なら素直にやめてインターフェース経由での利用とかにとどめたら
ネイティブをそのままマネージドの中で使いたいとか死亡フラグしか見えん >>571
msgpack初めて知りました
型を指定してシリアライズしたバイナリを送信するから受信側でクラスやインターフェイス定義の参照がなくても
デシリアライズしたオブジェクトのメンバにDynamicObjectやExpandoみたいにアクセスできるって認識でいいっすか？
>>572
Xamarin Formsの共通(Standardなので適切かわからない)コードからモバイルプラットフォームのパッケージを参照できないんでパッケージで定義されてるインターフェイスにアクセスできないんすよ
P/InvokeできればいいですけどマーシャリングでハマりそうだしXamarin Forms難しいっすね！ 共通で利用できるインターフェイスを用意する
その実装を各プラットフォームごとに書く（プラットフォームのパッケージはここで使う）
共通コードからはインターフェイスのみ使う
データが欲しいなら共通のクラスをつくってそれを受け取る マルチプラットフォームでどの開発環境がベストかって話題で盛り上がるんだけどReact Nativeも制限多いしパッケージの組み合わせやバージョン毎の互換性云々の不具合も多いし
Xamarinも歴史長いからサポートや下位互換は優れてるけどフロント実装の手間が圧倒的にReactに劣るよねとなって結論としてネイティブで書くのが一番良いって結論になるんだよね毎回 そこまで劣るかね？MVUの方がスッキリはするけどjsでReactだとElmより汚いし生産性でそこまでXAML+MVVM劣ってる？ C#、MVVM、XAML、Xamarinに習熟したプログラマーが常に集まって開発できるならギャップは誤差だと思うよ
ただ現実的にHTML5+CSSで簡単かつ自由にコンポーネント作れるReact Nativeと比較してXAMLのユーザー定義コントロールやゴリゴリにカスタマイズは
比較するとTemplateやPresenterなんかとViewModelとのバインディングをイメージしないとダメだから難しいし作れる人って極端に少ないよね
XamarinのExampleやKnowledge記事だって英語すらほとんどなくてGoogle検索で100件以下とかザラだし
あとGoogleなんかの大手のライブラリやドキュメントですらXamarinがハブられてるからどんなライブラリやドキュメントでもほぼ存在するnode.jsで書ける安心感はでかいよね
React Nativeもハマりどころ多くて苦労するけどどうせ苦労するならパッケージのメンテナ多くて苦労が報われる方が安心感ある 自分はむしろHTML疎くてちょっとElm触ったぐらいなのであれだけど人口はまあHTMLの方が多いのかの
RNはバージョンアップ頻度が激しいとかで疲弊する聞いたけどどうなん
XFは比較的後方互換差異は保ってると思う アプリって業務や基幹システムと違ってフロントをゴリゴリ作るからケースばかりでフロントのカスタマイズしやすさって最重要なんだけど
その点で言うとIVisual用意・プラットフォーム毎にRendererでゴリゴリ、Converter・プラットフォーム毎にEffect用意してゴリゴリコードビハインドしないとBorderの色すら変更できないAnimationもそうだけどXamarin FormsのXAMLは終わってるレベル
ここがWPFから進化どころか退化したままなのがMSマジでやる気ないんだなって感じw
HTML5+CSSなら見た目いじるの超簡単だし、デザイナーがベクターグラフィックスアプリで描いたのそのままHTML5+CSSでエクスポートできてほぼそのまま適用できる
Expression Blend+XAMLでMSがやりたかったフロント開発がReact NativeやFlutterなのかなって感じ クロスプラットフォームは糞
RNもFlutterも全部糞
糞の中のキングオブ糞がXamarin >>581
んーRNでHTML+CSSをどうネイティブの表示に変えてるのか知らんけど、それはその辺をやる薄皮があるだけで、似たようなものを作るだけでいいからあまり本質的な話じゃなくね VSから実機へのデプロイができない
たぶんAndroid 9へアップデートして不明アプリのインスト一括許可設定が廃止されたせいだと思うんだけど、これどうしたらいいん？
VSからの配置やadb installは不可(配置を試みて止まる)
Android 8までは設定で許可すれば、普通にVSから配置してデバッグできてたのに
泥9以上の場合どうしたらいいのか、ご存じの方、教えてplz… その情報だけじゃ答えられないw
React-NativeやExpoもパッケージのバージョン違いだけでエラー吐きまくってハマったら実装始めるまでがめちゃめちゃ苦労する
かと言ってXamarinは開発環境構築は楽だけどViewのカスタマイズが含めた実装がクソめんどい
FlutterはAndroid StudioとDartがクソすぎて馴染めない android studioのかわりにvisual studio codeつかえばok dartは俺も最初はブチキレまくってたけど、なんとか乗り越えてた flutterも触ってみようかと思ってるんだけどdartはどうクソなん？ Dartはまんまjsなクソ言語
LLで選べと言われればTypeScript一択で俺はReact Native + TS
ぶっちゃけ言語仕様や機能は今でもC#最高っスよ
8.0のswitch式、範囲アクセス、インターフェイスデフォルト実装、非同期ストリーム、using変数宣言、null合体代入等々書いてて楽しいもん
LLが型指定素晴らしいなんて馬鹿にしてた静的型付けに寄ってきてんの笑うわ
XamarinでフロントエンドだけReact NativeかVueで書ければマジ最強なんだけどな
MSは言語設計素晴らしいがフロントエンド実装のクソさとフレームワークがやる気なくて全部自分で作れだから人気でねーんだよな
EffectやCustom RendereでUI作れとかキチガイすぎんだろ 絶対ではないが、Xamarinは、原則、Android, iOS, MacOS X だけの対応で、
WindowsやLinuxアプリは作れないそうだから、互換ツールキットとしては
存在意義に疑問を感じてしまう。Linux用にも全く作れないわけでは無いらしいけど、
同じソースでマルチプラットフォームになるわけではないようだ。
MSも公式には、Android, iOS, MacOS X 用と書いており、LinuxやWindows
用アプリには Xamarin は使わないことになっている。
そもそも、Xamarinは、設立当初から Linux サポートはしないことに決めて
いたという情報を耳にした。 ざっくり言えば、Android,iOS向けのフレームワークがXamarin
Windows向けは.NET Framework
Linux向けは、.NET Core
すべて.NETを基盤としているけど微妙に異なる Windows向けもCoreとなりつつあるし、さらに来年は5として残部統一されるとなってるけどな 9月23日に、WinFormsとWPFがWindows環境のみ限定で、.NET COREでも動くように
なったらしい。しかし、.NET COREのLinux版は、今のところCUI限定でGUIは動作
しない。果たして本当に来年には統一されているか疑問だ。
MSが公式に保持しているツールキットで、C#のGUIがLinuxで動くものは、
恐らく一つもないらしいから。
それができるのは、今のころ、Xamarinとは懐を違えたMonoのみらしいが、
Xamarinを持ってしまっているMSがいまさらMonoの成果を取り入れるかは
甚だ疑問。
それに根本問題として、LinuxにGUIアプリまで簡単に移植できるようになると、
MSはデメリットしかないような気がするから。 >>597
ランタイムは統一されても、GUIツールキット(ライブラリ)は統一されないかも
知れません。 そもそも誰がLinuxのGUI環境に期待してるんだって話
あれは、それなりに動けば十分だろ
誰も期待してない。Linuの役目はCLIだけあれば十分。
そこでWindowsで作ったサーバーサイドアプリを動かす。
インターフェースはHTMLもしくはスマホネイティブアプリだ。
世間一般にLinux GUIの出番はない。 MSも世の中もクラウドに移行してる時代に
誰がデスクトップアプリを開発すると言うんだろう？
仮に.NETのGUIアプリがLinuxで動くようになったとして、
今更誰がGUIアプリの開発をしようと思う？
みんなウェブアプリに力を注いでいるんだよ。
デスクトップアプリは今あるもので十分。
WindowsとMacの世界ではスタンダードが確立されてしまった。 >>599
https://mevius.5ch.net/test/read.cgi/tech/1557960752/797-800
6ヶ月前の時点で「.NET 5 がクロスプラットフォーム能力を持つことになるという
PRをしたくない」ということをMSは明確に述べていたそうです。
つまり、.NET 5 は、来年年末も、クロスプラットフォームにはなって無いという
ことらしいです。似た説は、海外のサイトで何度も見た。MSがマルチプラットフォーム
に積極的になった事は無いとのことです。
Q: WPFは.NET 5のクロスプラットフォームになりますか
A: 6か月前
これは、Windowsシェル全体とパッケージ化サブシステムをパッケージ化しないと技術的に不可能です。
これは、明らかにMicrosoftの予定リストにはありません。
Winformsは、グラフィックスデバイスインターフェイスであるGDI +に対する非常に薄い抽象化です。
アプリケーションのUIを直接描画する方法を変更できるように、非常に薄いということです。WPFは、
この抽象化を拡張し、コンポジターアプローチと新しいマークアップ言語に置き換えて、
その合成エンジンを活用します。また、グラフィックデバイスサブシステムの3D機能へのアクセス
（DirectXおよびDirectDraw経由）を提供します。これにより、WPFはWinFormsができないすべての
素晴らしいことを（とにかく多大な労力なしで）実行できます。
言うまでもなく、いいえ。今ではなく、実際にはありません。これらの技術はどちらも、Windows
コンテキスト以外では意味がありません。ターゲットプラットフォームのネイティブグラフィック
エンジンが何であれ、Quartz、Weyland、XOrgを介して両方の抽象化を再作成する必要があります。
繰り返しになりますが、これらのプラットフォームには既に独自の同等のツールがあるため、
そうすることに興味のある人はあまりいません。 >>602
それは個人的には気づかなかった視点です。
もう一つあるとすれば、デスクトップLinuxへの移行はブームも去ってしまった
ので、いまさらLinux用GUIアプリを作っても使う人が少なすぎて、少なくとも、
個々のアプリがたまにLinux対応するだけでは余り意味が無い可能性があるということです。
ただし、一挙に対応が進むような環境が整えば別です。それができるのはMSやEmbarcadero
やQtのような組織なのですが、MSがやれば、自らの首を絞めることになりかねません。
もう一つは、LinuxでのWineや、ReactOSの完成度が上がってくる可能性です。
そうなれば、Linuxにマルチプラットフォームのツールキットで移植したとしても、
余り意味がなくなる可能性があります。Windowsアプリがそのまま、無料OSの上で
動くようになるからです。無料Windows互換OSが完成してくれば、パソコンメーカー
はこぞってそれを新品パソコンにインストールして売るようになるでしょう。
その時、Linux-nativeのアプリは速度面以外では意味が無いばかりか、そもそも
ReactOSでは動きません。素直にWindows専用アプリを作っていればそのまま
それらのOSでも動くのです。 >>605
しかし、
>6ヶ月前の時点で「.NET 5 がクロスプラットフォーム能力を持つことになるという
>PRをしたくない」ということをMSは明確に述べていたそうです。
の部分は注目に値します。 俺の友だちが言っていたそうです。
みたいな文章を信じるとかｗ >>608
ただ、英語圏の人は、ネットで根拠を上手く伝え切れてなくても、MSの普段からの
言動をテレビや新聞などからも見聞きしています。それらを総合して直感的に
分かってる可能性も有ります。根拠を示すのは大変なので書いてないだけで、
結論は正しい可能性は有ります。なぜなら、複数の人が同じ結論を
書いているからです。逆に、それに明確な反対意見を述べている人は見かけ
ませんでした。 > ただし、一挙に対応が進むような環境が整えば別です。それができるのはMSやEmbarcadero
> やQtのような組織なのですが、MSがやれば、自らの首を絞めることになりかねません。
なんでMSがLinux用開発ツールを提供するのが当たり前の前提になってるの？
首を絞めるも何も、逆にMSがそんなことするわけがないと思うのが当たり前だろ。
まあ実際はLinux用アプリの開発手段を提供してるわけだけどさｗ
https://docs.microsoft.com/ja-jp/visualstudio/releases/2019/compatibility
対象となるプラットフォーム
Visual Studio は、最新のプラットフォーム (Windows、Android、iOS、または Linux) 機能を利
用するアプリを作成するための最先端のツールとテクノロジを提供します。
Windows 用アプリの開発
Android 用アプリの開発
iOS 用アプリの開発
Linux 用アプリの開発
macOS 用アプリの開発
その他のテクノロジやプラットフォーム用アプリの開発 >>606
まあ、何が言いたいのかわからんが、
LinuxのGUI環境に期待するのはやめとけ。
あれはコミュニティが団結しようとしてないから
何をやろうがまとまらんよ。
MSだけが頼りなんだってことかもしれんが、
MSにそんなことをする義理はない。 >>606
> 無料Windows互換OSが完成してくれば、パソコンメーカー
> はこぞってそれを新品パソコンにインストールして売るようになるでしょう。
それはないなー。パソコンメーカーはWindowsの値段をパソコン本体に含めて売ってる。
つまり実際にお金を払ってるのは購入者であって、OSを無料にしたところで
パソコンメーカーの儲けはたかが知れてる。
無料Windows互換OSが、デスクトップ見た目までWindowsなら、
安い方を消費者は買うかもしれないが、それは無理だろ？
Windowsアプリが動くというのは、Windowsなら当たり前だからメリットにはならない。
Windowsアプリが動く（かもしれない）Windowsとは違った見た目のOSを
消費者が買おうと思う流れができない限りパソコンメーカーはインストールする意味を見いだせない。
つまりビジネスにならんのだよ。 >>610
>なんでMSがLinux用開発ツールを提供するのが当たり前の前提になってるの？
>首を絞めるも何も、逆にMSがそんなことするわけがないと思うのが当たり前だろ。
ところが、MSが方針転換して、Linux用(GUI)アプリも作れるようにし始めた、と
言う人も居るのです。CUIアプリまでは作れるのですが。
しかし、そもそもCUIアプリといえば、printf()とfopen()系だけでも作れますね。
C++ならば。 > もう一つは、LinuxでのWineや、ReactOSの完成度が上がってくる可能性です。
> そうなれば、Linuxにマルチプラットフォームのツールキットで移植したとしても、
> 余り意味がなくなる可能性があります。Windowsアプリがそのまま、無料OSの上で
> 動くようになるからです。
その逆をMSはやり遂げたんだよね。WSLでLinuxアプリがそのままWindows上で動くようになった。
Linuxアプリを使いたいためだけにLinuxを使う理由がなくなった。
Linux開発者はWindowsに移植する意味がなくなった。
Linuxアプリを作れば、それはWindowsで動く。
ありがと！ Linuxアプリを作ってくれて！ >>613
> しかし、そもそもCUIアプリといえば、printf()とfopen()系だけでも作れますね。
リンク先のVisual Studio 2019のLinuxサポートの内容を読めよ。
デバッガやGCCの対応って書いてあるだろ。
お前のその理屈なら、ワープロ専用機でもLinuxアプリ作れるって話になるぞｗ >>614
そもそもC/C++で書かれたUnix系CUIアプリであれば、fork()やselect()、pipe()
opendir(), readdir() や、/procやioctlやsignal(), raise(), curses, terminfo,
termious, Mutexなどを使ってなければ、再コンパイルすれば、ほとんどの
プラットフォームでそのまま動きますね（この他にも未定義や非互換の関数は
沢山有りますが。） >>616
だから、ソースコードをかければ十分だっていうのなら、
最初からどのOSでも開発できるって言ってるだろ。
だからお前の理屈なら、たとえメモ帳でもLinux用CUIアプリどころか
GUIアプリだってできる。
Visual StudioでもLinuxアプリの開発できるってことで
お前の希望は叶ってるじゃんか ロードプリン
2ポイント
・
6か月前
コアはクロスプラットフォームではありませんが、wpfはコアを利用する機能であり、実際にはコアではなく、コアの上に構築された機能になります。
コアはクロスプラットフォームになりますが、コアを実装するすべての機能が初日からクロスプラットフォームになるわけではありません Visual Studio がLinux開発サポートするのは不思議でもなんでも無いんだよな。
自社でAzureを運営してて、Linux仮想マシンもサポートしてる。
そこで動かすアプリは当然Linuxアプリ（ウェブサービス）
それをWindowsだけで開発できるようにWSLも作ったし、
Visual StudioもWSLに対応している。
Windows上で開発し、Azure上で動かす。
総合的な開発環境と考えれば、不思議なところはなにもない。
むしろVisual StudioのmacOS対応の方が不思議なんだよな。
macOSアプリの開発に対応してもメリットがあまりない。
もっともVisual StudioのmacOS開発サポートは
コンソールアプリとASP.NETアプリに限られてるからギリギリ理解はできる。 >>621
>もっともVisual StudioのmacOS開発サポートは
>コンソールアプリとASP.NETアプリに限られてるからギリギリ理解はできる。
初耳です。Mac用のGUIアプリは作成できなかったんですね。 >>622
君は知らんことが多すぎる。少しは勉強してからにしたまえ。
そして当たり前だが、MSはビジネスやってるんだ。
売れる方向にかじを取るのは当たり前。
何もせずMSさんあなたの力だけが頼りなんですって言っても
何もしてくれないよ。 >>623
個人的にはMSのクロスプラットフォームに期待していません。
単に状況を把握したいだけです。 >>624
LinuxのステークホルダでもFOSS信者でも有りませんので、
何が起きるか、今何が起きているかを知りたいのです。
FOSS信者では有りませんが、MS信者でも有りません。
この世界はその二つだけで出来ているわけではないのです。 教えるついでに今のソフトウェア開発の標準を教えてやろう
まずウェブサービス。そこでしか金は儲からん。GUIアプリなんか作らない。
（オープンソースを使って）有料サービスを提供する。
サーバー側はRuby、Python、Go等、いろんな言語が使われるが
C++の出番はまずない。.NETは業務系なら使われる。
クライアント側はHTML+JavaScript、そしてスマホネイティブアプリ
そのスマホネイティブアプリの開発をXamarinが担当してる。
サーバー側の開発はVisual StudioよりもむしろVisual Studio Codeがよく使われている。
Visual Studio CodeはWindows版だけではなく、Linux版もmacOS版もある。
あんたの開発のイメージは20年ぐらい古い。
MSは最新に対応し続けているが、あんたは遅れてる。 >>623
>そして当たり前だが、MSはビジネスやってるんだ。
>売れる方向にかじを取るのは当たり前。
私は前からそう思ってるのですが、ネットでは、逆に、MSが
「Linuxと共存の道を歩み始めた」などという人が多いので、
正しく物事を把握したいと思っているのです。
MSはLinuxと共存どころか、機会があれば何とか壊そうとしているに
違いないと思っています。彼らにとっては目の上のたんこぶだからです。
別にMSがLinuxへの対応しないことが悪いことだとは全く思っていません。
何度も言いますが、状況把握したいだけです。 >>624
> 個人的にはMSのクロスプラットフォームに期待していません。
もはや誰もクロスプラットフォームアプリの開発に興味を持っていない。 >>627
> 「Linuxと共存の道を歩み始めた」などという人が多いので、
共存初めてるだろ。Linuxを拒絶するのではなく、
Linuxも取り込んでMSビジネスの一部にしている。
あんたはLinuxと共存の道を勘違いしてる。
Windowsを捨ててLinuxを発展させるのは「共存」ではない。
そこまで来るとLinuxへの移行だ。
共存というのは、Linux「も」利用できるようにすること。
AzureでLinuxも使えるのが、Linuxと共存している一例。 >>629
共存ではなく、利用だと思うんです。
自分の都合の良い部分だけを利用しつつ、相手が本当に必要としている
事は、決して与えないような。
例えば、LinuxのLinusは、デスクトップOSとして発展させたいと言ってる
そうですが、MSは絶対にそうはさせない。
無料であるから利用しつくせるだけ利用して、その一方で、デスクトップOS
としては、出来るだけ弱らせる事を常に考えている。
そういうしたたかさこそ、大事だと思うんです。 > 例えば、LinuxのLinusは、デスクトップOSとして発展させたいと言ってる
> そうですが、MSは絶対にそうはさせない。
MSに頼るんではなく、自分で頑張るべきでは？ｗ >>630
> 自分の都合の良い部分だけを利用しつつ、相手が本当に必要としている
> 事は、決して与えないような。
ビジネスなんだから当たり前。MSにとって「相手」とは開発者だよ。
開発者がLinuxアプリの開発を必要としていたから、それをWindowsで
やる方法を提供した。
Linuxを望んでる人は、Linuxを使えばいいだろ。
Linuxを使ってもらうように頑張るのは、Linux陣営がやることであって
MSの仕事じゃない。
MSは相手（開発者）が必要としている手段を提供した。
Linuxを拒絶してWindows技術を使わせるようにしていたのが以前のやり方で
今は、Windows技術にこだわらなくなったから、共存してると言われてるんだよ >>626
>まずウェブサービス。そこでしか金は儲からん。GUIアプリなんか作らない。
>（オープンソースを使って）有料サービスを提供する。
収入源は、やはりアフィリエイト（広告）ですか。
個人的には有料のウェブサービスを使ったことは記憶に無いです。
amazonやyodobashiのような通販サイトなら当然ありますが。
ウェブサービスも、百家騒乱状態ですが、実際に利益を出している場所は
果たしてどれだけあるかは疑問です。儲けようとしてウェブページ製作以来が
来るので、プログラミングの仕事はあるようですが、実際に利益が出ている
のは余り多くない気がします。GoogleやYouTubeは広告で儲かってますね。
今のところ、twitterやinstagramで広告を見た記憶は有りません。
Facebookは個人情報を売ることを利益にしているのでしょうか。 そもそも多くの開発者が望んでるのってLinuxじゃないんだよな。
Linuxを望んでいるならクロスプラットフォームなんて
Windowsでも動くアプリを作ろうと思わないはず。
多くの開発者は自分の作ったアプリがどこでも動くことを望んでいるし
Linuxを選んでいるのも、単に無料で使えるオープンソースがたくさんあって
ライセンスの点で有利だっただけのこと。
その証拠に昔からWindowsで開発して、Linuxサーバーにアップロードしていた。
それが最近MSがLinux対応をすすめて、Windowsで開発するのが
以前よりずっと楽になったんだよ。
別にMSは最初からLinuxに開発の場を移しましょうなんて言ってないし
言うわけがない。Windows技術の押しつけをやめてLinux技術と共存しただけ。
今も昔もWindowsを使って開発しましょうとしか言ってない。 >>633
> Forms開発できんだろ
正直もう誰も望んでいない。
今の開発の主役はウェブサービス。
HTML+JavaScriptか、ネイティブアプリだよ。 >>634
> 収入源は、やはりアフィリエイト（広告）ですか。
個人が作ったようなスマホアプリとかは広告だらけだけど、
大手のサービスはサブスクリプションが多い。 > HTML+JavaScriptか、ネイティブアプリだよ。
ネイティブアプリっていうのはスマホとかタブレット用の
ネイティブアプリって意味な。
WindowsデスクトップアプリもLinuxデスクトップアプリも
macOSデスクトップアプリも現在の開発の主流じゃなくなってる。 >>631
誰にいってるのか知りませんが、Linusは自分ではがんばっているでしょう。
そういう意味ではありませんよね。ようは、MSはLinuxを発展させないように
あの手この手で暗躍しているはずで、私の目線ではそれがよく分かるのです。
気付かない人が多いようですが、確実にやってます。
GoogleがAndroidを作ったのは、iPhoneだけだと、人々が使う検索エンジンが
Googleから離れて行ってしまうことを恐れたからです。そのためだけに
Android OSを作ったそうです。このことはほとんど日本人は知らないでしょう。
全くボランティアなどでは有りません。逆に事の事を知っていしまえば、
Googleが脆弱な状態に立脚していることが分かり、Googleを破滅に追いやる道も
見えてきます。つまり、Googleは検索エンジン自体は大したことが無いことを
彼ら自身が一番よく分かっているのです。これがGoogleを壊す答えです。
Googleを壊せれば、日本の景気は確実に良くなります。
他にも、Googleは、FireFoxにも、Appleにもそれぞれ一兆円程度の金を払っている
そうです。それも、ブラウザのデフォルトの検索エンジンをGoogleにさせるためです。
その金がFireFoxの開発資金になっています。その金を払いたくないから、Googleは
Chromeを作りました。逆に言えば、Googleを壊すには、Chromeを超えるブラウザを
作り、デフォルトの検索エンジンを、livedoorなどにしてしまえばよいということが
分かってきます。そうなればたまったもんじゃありませんから、Googleは、その
ブラウザ作者に金を払います。どっちにしろ、ブラウザ作者は儲かるでしょう。
最後に、私がこうやって状況把握に努めているのは、はっきりいって、MSを何とか
衰退させたいためです。 今の時代のクロスプラットフォーム開発っていうのは、実質iOSとAndorid対応だってことに
気づいてないんだろうな。時代についてこれてなさすぎる。
MSがいち早くXamarinでそれらの開発に対応してるというのに
未だにLinuxデスクトップアプリの話をしてる。
> 最後に、私がこうやって状況把握に努めているのは、はっきりいって、MSを何とか
> 衰退させたいためです。
無理。諦めな。 MSを衰退させたいなら、MSを超えるものをMSの力を借りずに実現する方向を目指せよ
いくらMSに落ちぶれてくれ〜落ちぶれてくれ〜と願っても
叶うことはないからさ。 Linuxの文化で、MSと同じ土俵で戦うのは無理なんだわ
デスクトップ環境を統一しろと言ってもできないし、
パソコンメーカーにプリインストールしてほしいなら
営業部隊を用意して大きな宣伝するべきだけど無理だろ？
どこにそんな金があるんだって言うが、それは金を取らない
オープンソースにしたのが悪いんじゃん、自業自得って話だし
昔からオープンソースのビジネスモデルは、
ウェブサービスとしてサーバーに組み込んで
プログラムを売らずにサービスとして提供するやり方だって
主張してたじゃん？
実際にそれしかビジネスにならないし、そのビジネスモデルを
うまく作り上げたのがazureだよ。
オープンソース陣営が推奨するビジネスモデルを採用したMSは大儲けって皮肉だよねｗ >>641
いいえ、直接的にMSそのものを衰退させることも同時並行的に行っていくことも
重要なのです。なぜなら彼らには、Windows OSがベース資金源としていつまでも
残り続けてしまうから、いくらMSを越える何かを作っても、すぐに豊富な資金で
追い越されてしまうからです。最近、Windowsが衰退したという人がいますが、
その見方は浅いのです。新しいパソコンが売れるたびにMSには、金が流れる仕組み
になっており、今でも年間三兆円の確固たるベース収入が彼らにはあります。
それがあるので、牙城が崩れません。何か彼らを超えるものを作ってもはっきり言って、
無理なことが多いのです。何かMSに対抗できるものを有料で作ったとしましょう。
すると、彼らは競合製品を無料にしてきます。明らかにダンピングなのですが、
いろいろな理由を付けて、アメリカは国家ぐるみでMSが行っているダンピングは
見てみぬ不利をします。ですので、MSに対抗して勝つことは今のままではまず無理なのです。
それが、マイクロソフトが衰退しない理由です。
実はGoogleも似た状況にあります。検索エンジンを何も改良しなくても、潤沢な収入が
彼らには入ってきます。これら二つの企業は実は何も仕事をしていませんが、金だけは
入ってくるおかしな構造が出来上がっているのです。 >>643
うん？全部MSに八つ当たりしてもムダだよね？
パソコンにプリインストールしてほしいなら努力しろ。
有料ソフトが売れないというのななら、売れるように頑張れ。
無料にして潰してきたのはむしろオープンソースなんだが忘れたのか？
オープンソースは無料でソフトウェア業界を壊しておいて、
いざ同じ手段で対抗されたら、文句言うとか恥ずかしいよ。
MSがダンピングにならないのは、同等の商品が無料で存在するからだよ。
自業自得じゃねーかｗ
いい商品を作れば儲かるはずだと思うのは考えが浅い
うまく宣伝したほうが勝つんだよ。
なんでもそうじゃねーか >>643
それから「ペンの力」もあります。
彼らの問題点、悪いことを辛抱強く書き続けていくと、だんだんと
彼らに不利な社会情勢が生まれてくるものなのです。 >>644
私はFOSS信者では無いと先に書きました。
FOSSとは、GPLとオープンソースを合わせたものを意味します。
MS嫌いですが、オープンソースも大嫌いなのです。
お門違いです。 >>646
お前に素晴らしい言葉を贈ろう
「何が嫌いかより何が好きかで自分を語れよ」 >>644
宣伝に関してですが、ここでMSの悪口を書き続けることは、彼らにマイナスの
宣伝効果となります。悪口は重要です。何度も言いますが、私はオープンソース
は大嫌いです。
しかし、MSも壊すこともライフワークにしています。 >>647
GPLの悪口は既に結構浸透しました。
今度はMSの版です。もっとMSの悪口を言うべきです。
どっちも日本の敵です。年金を増やしたい人は、MSの悪口を言いましょう。 何年も悪口を言いました。でもそれは無駄でした。
終 >>644
>オープンソースは無料でソフトウェア業界を壊しておいて、
>いざ同じ手段で対抗されたら、文句言うとか恥ずかしいよ。
>MSがダンピングにならないのは、同等の商品が無料で存在するからだよ。
私は昔からオープンソース反対者です。最近になって、オープンソース嫌いが
増えてきましたが、ずっと前から私は反対していました。
GPLなどのせいで、ますますMSが強くなってしまい、とんでもなく
どうしようもない状態になっています。だからMSの悪口を言う必要があります。
全国民がMSの悪口を言うべきです。
GAFAの悪口が流行ってますが、MSはもっと悪いのです。 んで、お前にとって、いいやつなんてどこにもいないんだろ？ｗ まあ要するにあれだ。
自分の実社会での鬱憤を
八つ当たりしてストレス解消してるだけ >>653
います。
アメリカのIT関連団体に悪いのが多いだけです。 >>654
いったい、マイクロソフトが何の仕事をしたというのでしょうか。
まともな仕事をしていれば認めます。
しかし、彼らのやっていることは、日本の生産性を下げるばかりで何も
良いことをもたらしていないのです。
Win95が登場したときから、日本は衰退して、今まで回復できていません。
Win95は悪魔です。マイクロソフトは悪魔です。同時期にgccも流行りだしました。 >>650
例えば、MSの株価がここ数ヶ月間横ばいだったのは、悪口の効果なのです。
しばらく悪口を休んでいたら、悪魔の力が勝って、最近また上がり出しました。
トランプ大統領がマイクロソフトに10年間で一兆円分の契約をしたからです。 ということで、こいつがキチガイであることを明らかにした時点で
俺の役目は終わりかなーと思いますｗ 余り関係ないけど、qiitaで調べてみると、game engine の Unityには興味
を持っている人が(かなり)多いが、Xamarineは余り興味をもたれてないらしい。
意外。また、Unity と似ている Unreal Engine は記事数が少ない。
cocos2d : 1,047 (2D game engine, C++)
unreal : 520 (3D game engine, C++)
Unity : 11,558 (3D game engine, C#)
xamarine : 11 (iOS, Android, (+Win?) 共通ツールキット C#)
qt : 1,935
wxWidget : 5
FLTK : 6
GTK : 1,053
wxWidget の少なさは意外。GTK が思ったより健闘。
xamarine の少なさは、天下のMSが絡んでいるとは思えないほどで理解しがたい。 MSが一から作ったならまだしも、xamarinは所詮買収したもんだから。相当うんこ。
Unoもまた外部企業だけど、また買収でもして同じ失敗するきなのか ざまりん、特に話すこともそんなないしな
3年前ぐらいのアドベントは大盛況だった気もするけど Xamarin.Forms と Xamarin.Android, Xamarin,iOS は別だそうですね。
これは不思議です。Xamarin.Forms が Android/iOS/Win 共通
ToolKit とされているようなのに。
また、Windows アプリが作れるといっても、UWP 用のもの。
すぁらに、Visual Studio では、Xamarin は、Android と iOS 用
とされていて、Windows アプリはサポートされてないようです。
それと、「Forms」の名があるので、WinForms と互換かと思いきや、
そうでもないようで、XAML を使わないといけないのですね。 >>668
なんかとおまい情報の集め方が雑すぎひん？ >>663
xamarine ではなく、xamarin なので、正しくは：
xamarin : 1478
でした。orz。 ADSLジジイ
このスレでもずっと一人でタイポしててM$表記みたいなネタでやってんのかと思ったけど
マジでスペルから間違って覚えてたのかよｗ 今までのC#と同じ感じでXamarinのプロジェクトを作ると途方に暮れるな・・・
どっかで良いチュートリアルのページは無いダウか C#のwindowsアプリしかやったこと無いのよ
後は組込とかWebアプリ・・・・
xamlで画面デザインを設計するところまではわかったんだけど、
コンテンツが別のファイルになってて、それがどのファイルにどの形式で格納されてるとか
アプリの権限とか
Androidアプリ自体初めてなんだけど、プロジェクトを作ったらいきなり俺が固まった とりあえずWebにあるAndroidSDKとAPIのドキュメント、日本語でかいてある分だけでいいから
ざっと目をとおしなさい
どこにあるかはググりなさい
グーグル製だけに >>674
Xamlでって言ってるってことはXamarinFormsでいいんか？
コンテンツが別ってのはなんのことだろう
権限てのは証明書とかのことかの？ >>674
移植しやすいってだけでAndroidでのプログラミングに精通してないと厳しいよ
当たり前だがWindowsの作法を
Androidに持ち込んだってうまくいかない
初心者向けの本でいいからJavaとAndroidのプログラミング程度理解してからやったほうが位置付けがわかるよ XamarinでMac無しでiOSアプリ開発できますとかもそうだがあんなのセールストークでしかない
各種環境を理解したうえでマルチプラットフォームで作る つかWebアプリ経験があるなら
費用はかかるが鯖立ててASP.NETでWebアプリ作ると方がまだ楽かもね Xamarin.Formで質問
Xamarin.Formでアプリを作ると最低のバージョンは
Android 8.1より小さくするとメイクするときに「そんなバージョン指定するな馬鹿野郎」的なメッセージが出てくるんだけど
小さいバージョンには出来ないの？
Google Playでリリースできる最低バージョンは8.1とかなってるんだけど
実際Google Playでリリースされてるアプリって4.4とかでも平気でリリースされてるしメンテもされてるみたいだけと
どうにかならないのでしょうか
2〜3年で過去のバージョンを切り捨て続けるとかサポートは面倒は無いかもしれないけど
友人と使うつもりのアプリなので困る・・・ targetSDKVersionとminSDKVersionがある xamarin勉強しようとおもったら結構学習コストかかりそうなんだね
それならflutterでもやったほうがいいか
unityできるからそれで妥協するか >>682
Formsって選べるの？
>>683
もしかしてマニフェストのバージョンですか？
そこで最小Androidバージョンを5.0とかにすると5.0でも動いてリリースも出来たりするの？ >>686
Nugetで古いものも選べる
が上の人が言ってるようにターゲットとか変えたら良さげ 今から始めるのはやめた方がいいよ
Blazor Nativeみたいなのが出てきてFormsは廃れゆく予感がする 既にMobile blazorきてると思うが、あれFormsの上にWASMとBlazor乗っけたキメラだろ ざまりん先生、フラッターとかに比べてモダン度が足りないとこもあるけど、あっちはあっちでネイティブとの混在とか不得手だしクロスプラット開発の中では今でも有用というかありな選択肢では リリースで制限かかるのはtargetSDKVersion もう、勝敗はflutterの勝ちだろ。
flutterモバイル出来を見てると、flutter webも期待できる。クロス開発しなくても、webアプリのクライアントつくるだけでもjavascript/htmlで触らなくてよさそうだからflutterでいいかなと思わせてくれる。 ほんとXamarin頼りでないFlutter的なものを出さないとなMSは フラッター的なのって何を指すん？
どこでも動くってあのやり方はどうしても既存ネイティブコントロールとの相性悪い。webでもそれは一緒。
ホットリロードは良い。ザムルホットリロードはちゃんと動くのか知らん
ElmライクなMVUでのUI as Codeでいい感じのは欲しい。
けど当のC#が代数型まだ使えないからはよ9持ってこいって感じ きっと、ウィジェットが提供される環境をFlutter的って言ってんじゃないのかな
Xamarin Essentialsみたいなものが求められておらず、配置するだけでアプリが大体出来あがっちゃうウィジェットが便利すぎるんでしょう
どうでもいい汎用の機能は出来合いのものでさっと作りたいよね・・・・ xamarinは品質とコントロールが足りなかったからこけたんじゃね。flutterみたいのじゃなくてxamlでもいいからマイクロソフトのやる気が足りなかった。
買収でお茶を濁そうとしただけで、流行ればラッキーぐらいで買収後リソース大量投入とかしてねぇだろ? じゃあおまえの>>694の
相性悪いだのという感想もいらないんだけど。
自分で感想書いて他人の感想は駄目とか馬鹿なのかこいつ。 >>699
他の人の感想も貼っとくわ
https://i.imgur.com/KRnK7IW.png
まあXamarinからFlutterに乗り換えるわって人もいると思うけどね
煩雑なとこもあるけど出来ることの多いXamarin、後発ゆえもあって色々モダンだけどその仕組みゆえ出来ないこともあるフラッターって構図は間違ってないんじゃ？
まあもうちょっとマイクロソフト本腰いれーやとは思うけどな バグ全然直さないもんな
samhoutsとかいうねーちゃんがタグつけて放置して終わり
やる気なさすぎだろ・・・ 楽しようとした結果、余計に苦労したのがXamarinだった
すでに直ったものもあるけどVisualStudio for Macが色々とおかしい（コード自動生成、パッケージ管理、アセンブリの参照範囲など）
ウィジェットがない
ネイティブUIを使うと意味不明のエラーだらけで、エラーを出さないためにはコツがいる
本家開発ツールでは日常的に使われているライブラリ(FB製のものなど)がXamarin用に無いことが多く、一から作らないとならない
いつサポートが打ち切られるかわからない恐怖がある >>705
ずっと張り付いてるざまりんに親殺された君かw flutterは今年はwebとmacにフォーカスし、winやuwp対応は後回しっぽいが、flutter team待たずにMicrosoftがuwpに対応させてほしい
1消費者としてなりふり構わずMicrosoftストアアプリの充実をしてくれ WinUI、もうWin32で新しいアプリとして作ることできるん？なら既存のロジック使うやつで試してみたいんだけどXAML島、てめーはだめだ XAML何でダメなん？
絵のうまい人にAdobe XDでニュルンって感じでお絵かきしてもらえばそのまま貰えるのに
つーか、マイクロソフトはBlendをなんとかしろよ・・・ >>707
>flutterは今年はwebとmacにフォーカスし
詳しく。 roadmapに書いてある。
https://github.com/flutter/flutter/wiki/Roadmap
あれ、よく見るとWebとDesktopだった。
DesktopはMac優先でwindowsは後回しぽいと思う
だから、micorosoftがアプリ増やすきあるならFlutterに乗っかるのが手っ取り早いと思う いまだにちょまど教徒の多いXamarin派が言うことじゃねえだろ いきなりちょまどとかフラッター専門用語でわめかれると怖い >>711
XDのXAML出力ってプラグインじゃ無いとだめだし
あまり使い物にならなかったような・・・
まあ一から手書きするよりは良いし、スマホで「こんな感じになります」って言うハッタリ画面をお客さんに見せるのには最高だけど
BLENDはとっくに終了した まあざまりんじゃなくていいからクロスプラットで安定して何処でも動きつつ必要な時にはネイティブとの連携も出来る奴そろそろくれよほんと。 Xamarinで開発したAndroidアプリがリリース直前なんですけど、
「リリース前レポート」の「Androidの互換性」でグレイリストにひっかるAPIが見つかりました。
レポートにはAndroidのAPI名しか出てこないから、Xamarinで何が対応しているのかわかりません。
「Androidの互換性」についての詳しい情報はありませんか？ >>721
Xamarinのソース見ればいいんじゃね？
ttps://github.com/xamarin >>722
https://github.com/xamarin/Xamarin.Forms/issues/7323
iOSの場合はUIWebViewがサポートされなくなる問題について具体的に議論されていて、Xamarin.Formsのバージョン4.5で対応すると結論が出ています。
同様に、「Androidの互換性」についても公式に何か情報が出ていないか調べたいんですけど、キーワードがうまく引っかからないのか見つかりません。 >>724
30行ぐらいのスタックトレースが出てて、どれが問題なのかがよく分からないんですよ。
スタックトレースを全部貼ることは行数制限で多分できないと思ったので、書いてません。
スタックトレースの先頭部分で検索したら、Xmalの設定を修正したら解決したと言う話を見つけました。
https://forums.xamarin.com/discussion/156523/androids-strictmode-policy-violation-warnings-aka-nonsdkapiusedviolation
他も同じようにスタックトレースの先頭部分で検索し直してみます。 vs2019と一緒にxamarinインストールしてまずハロワでもやってみるかと思ったらエミュレータがphone is starting的なメッセージのまま真っ黒で動かなくて詰んだ
mainactivityすら通ってなさそう？おま環だろうけどテンプレートまんまですら動かないとか泣きたい >>727
Android Device Managerでエミュレータを起動できますか？
そもそもエミュレータでAndroidのOSが起動していないのでは？ >>728
レスありがとうございます。
エミュレータ選択画面で開始をクリックすると真っ黒なスマホにphone is startingというメッセージが出ているだけなのですが、これはやはり起動できていないでしょうか？
エミュレータはpixel pie 9.0 api28を作成しています。 >>729
起動できてたらホーム画面が表示される。
表示されていない時点で・・・ 結局実機接続でデバッグ実行したら上手く行きました。エミュレータより早いしこっちで頑張ることにします。
お騒がせしました。 エミュも前よりいろいろ良くなったけど、ハイパーバイザーとかも関係するし実機あるならそっちの方が早いな android studioとデザイナー画面どっちが使いやすいですかね？ Xamarinってもうオワコン？Microsoftのおばさんがやたら推してたくらいしかイメージないけど ネイティブとの連携だったらフラッターよりやりやすいなどメリットもあるけどモダン度では負けてるかも
が地味にアップデートしてるしオワコンというものではないと思う >>726
アプリの使い方動画をニコニコ動画にアップロードしました。
https://www.nicovideo.jp/series/104129
ニコニコ動画には横長画面のPC用をアップロードしました Flutterみたいな二番煎じを持て囃すとかレベル低すぎて草
あんなのGoで書くReact Nativeの中途半端なパクリに過ぎん
Flutter採用するくらいならエコシステム含めて普通にReact Nativeしかないわ
BlazorはServer、WebAssembly、PWA、Hybrid、Nativeと展開するみたいやからちょっとだけ期待しよう
しかしオープンソースにしたけど結局XAMLは見捨てられ死んでしまう運命なんだよな
俺もXAMLでキャリア積んだから思い入れあるんだが流石にHTML5+CSSと比較すると面倒臭すぎるしXamarin Formsなんてクソすぎて擁護できんわ
まぁC#はUnityのおかげで生き延びてるがMSの今の主力言語はTypeScriptなんだよな
そもそもMS自体がPython、React、Electron推しなのも謎すぎる React Native には、Expo, Expo Snack がある！ React Nativeのエコシステムなんてあるようで全くないから
というのも元のJava Scriptが元々ブラウザ向けだから、もちろんDOMいじくるようなライブラリはNativeで動かねぇだろうし大半がReact Nativeでのモバイル開発で役立たず VS2019 16.5.1に上げたらMacとのペアリングに失敗するようになった... わいもバージョンあげたら証明書がうんたらかんたら6.1.2が6.1.4で〜みたいなエラーが出た
解決しようとしたら思いのほか大変でしょうがないから
Visual Studio for Macで開発すっかってやってみたら
あまりのクソっぷりに脱糞してるとこ
VSCodeでXamarin開発できないの・・・？ c#とvsの相乗効果を帳消しして余りあるクソっぷり MSがXamarinやなくて謎のReact推しやからな
FbもReactNative for WinリリースしたしXamarinマジでオワコン
そもそもXAMLがHTML5+CSSにあらゆる面でどうやっても勝てない
糞面倒くさいXML拡張てのがオワコンやね 正直jsはほんと使いたくないのでXamarinでいいです VisualStudio for Mac やばない？
日本語入力してエンターキーで確定したらIMEの確定のはずが
改行が入力されて意味分からんところに日本語が入力されたりめちゃくちゃなんだが
日本語入力できないとか全く使い物にならん >>748
アメリカのソフトは全体的に日本人が不利になるようなことを増やしてきている。 初歩的な質問ですまないがXamarinでクロスプラットフォーム開発するのと、Swift・Kotlinで分けて開発するのってどっちが吉？
もちろんひとや会社の状況によるだろうけど実際にXamarin使ってる人たち視点でここが優秀、ここが糞っていうのを教えて欲しい 100%ネイティブ
Xamarinはフロントエンドのロジック共有できるがUIはカスタマイズするなら別実装必要かつ超めんどい
あとBaaSなんかのサードパッケージがバグだらけで絶対ハマる そもそもXamarinは当時フロントエンドのUI、ロジックをクロスプラットフォームにC#だけで書けることだけがメリット
今そんなの腐るほどあってXAMLのメリットもただWPF/UWP開発してたやつはMVVMやフレームワーク含めた諸々を引き継げるでってだけ
Xamarin FormsのXAMLそのものがHTML5+CSSにあらゆる点で劣ってる時点でオワコン
今C#なんてUnityだけで耐えてるようなもんだろ B to Cのアプリいくつか案件でやったけど自分はネイティブで分けて作るとか絶対やらんわ
よくそんなめんどくさいことすき好んでやるなぁと思う
UIの作り込みが昨今だとXAMLよりいいのあるんじゃないかって話はまあ分かるけどそれでもそんな二つ別々に作るよりははるかに手間かからん
まあ別部隊が各々作るなら良いけどうちはビジネスロジックもそこそこフロントに実装してるから別言語で作り直すとかありえん
Xamarin.Formsで作ってるけどUIもアニメーション含めてそこそこ良い感じに仕上がってると思う
フラッターの方がいいんじゃ？ってのはまだ議論の余地あるけどあれはあれで闇な部分もあるしな >>753
腐るほどあるならまともなもの後何があるのか教えてくれ
後C#は言語としてまあモダンなものより劣ってるとこもあるかもだが色々頻繁に手が入って開発環境や対応できる場面含めて悪い選択肢じゃないぞ？ web 系のOSS のライブラリは、Linux サーバーを対象にしてる
Windows を対象にしていない。
Windowsで動くように作っていない
Windows で、web 系はダメ！
#!/usr/bin/env node
とか、1行目に、Linux のシバンを書いているファイルも多い もともとxamarinはC#ユーザー向けに使いやすくしましょうって始まったんだから
C#に慣れてる人間が多い会社はXamarin
そうじゃ無ければkotlinなりcordovaなりすればいいだけで
そんなにこだわるようなことじゃないだろ このスレの人間にはUnityだけで頑張るとかして欲しい気はちょっとするけども C#そのものは数ある言語の中でも個人的大好きなんよ
静的型付けとモダンさのちょうど良いバランスとか最高
今ならXamarinよりBlazorキャッチアップした方が良い なんでIPhoneはPWA対応しないんだろうか。
とりあえずはその程度のソフトでいいんだよ。 >>760
iPhoneでもPWAには最低限の対応は出来ていて、既にHome画面への追加は出来るんじゃないの？ >>760
詳しくないから分からんけど、例えば東京アメッシュはホーム画面に追加するとアプリみたいに動くよね PWAとかオワコン進めるとかど素人が知ったかしてて草
時代はWASMやしMS、GoogleはWASM推しでそのためのBlazorよ 時代の潮流は、WasmとPWAの同時対応へと進んできている。
それらは互いに排他的ではなく、同時使用したときに最も力を発揮するので。 しかしKrippすげーな
MTGAで7000人以上の視聴者数とかKrippしか見たことないわ
MPLが人気なさすぎやねんな >>762
Flutterはネイティブコンポーネントとの共存があれでしょ ReactもFlutterもカスタマイズ必要でネイティブ触る必要ある場合途端に破綻するから最初からネイティブで書くほうがゲインあるんよ
ネイティブ実装を自分でReact対応させられるスキルあるやつなんて滅多におらんし実際そこまでやるならネイティブで書くし
あとnpm含めたバージョンと依存関係でハマるからメンテもネイティブのが楽 >>772
それだてネイティブで各々書く事言ってん？
だったらないなー >>771
最近じゃFlutter pubもだいぶ充実してきたし、ほとんど自分でNative部分を書くことはないなぁ。
WebViewサポートが弱いのと、OpenGLがiOSで使えないのが難点だけど。 IMEもなんかダメみたいなこと誰か言ってたけどそれは大丈夫？
いずれにしても全部自前描画はメリットもあるけどデメリットもあるから案件次第だよなぁ swiftで作成済みのアプリ(ソース)をXamarin.iOSに移植するのって簡単？ simulationライブラリで純粋な関数式プログラミングをする
ttp://x0000.net/topic.aspx?id=3631-0
UIライブラリ (C#, 2D) を作ったよ
ttp://x0000.net/topic.aspx?id=3688-0
連続と離散を統一した！
ttp://x0000.net/topic.aspx?id=3709-0
4Dエンジン
ttp://x0000.net/topic.aspx?id=3677-0
matrixのライブラリ
ttp://x0000.net/topic.aspx?id=3711-0
ある強力なFor関数
ttp://x0000.net/topic.aspx?id=3630-0
SQLライブラリ
ttp://x0000.net/topic.aspx?id=3675-0 >>776
SwiftUIとかよく知らんのでその辺は分からんけど、ObjectiveCでも実現出来そうなら多分簡単 >>778
なるほど
まずはobjective-cで移植してる記事を探してみる
コロナ影響でテレワークのせいで顧客環境にあるソースを触って試しに移行とか出来なくて困ってたのよね
ありがとう >>779
Swiftよく知らんのであれなんだけど要は既存のUIKitとか使って実装してるものならXamarin.iOSはただそれをそのままC#で書けるので実装は可能だよ言いたかった。
SwiftUI はよく知らんのだけどあれもきぞんのUIKitを違う形でかけるよってだけ？ Xamarin、React、FlutterでUIの実装が違う
ReactとFlutterは独自実装だからカスタマイズ前提の仕様で独自UIの実装が容易
Xamarinはネイティブラッパーやからカスタマイズが超大変
ぶっちゃけアプリ案件でUIいじらないって100％ありえへんからそれだけでXamarinて択がなくなる >>782
個人的には、グラフィックの Line 文や画像描画命令でプログラムから
カスタマイズできるほうが便利だと思っているので、native wrapperより
独自描画してくれていた方が便利そう。 >>783
それと、表示だけでなく、Edit要素の5行目に文字列を挿入したいような
場合、native要素だとどれだけ互換性の問題がクリアされているか心配。
挿入後に勝手にスクロールするかどうかはWindowsだけでも非常に複雑。
でもそこが一番重要だったりする。
その辺が独自描画だとどのOSでも同じ動作になってくれるので楽。 同じ画面になってくれりゃいい場合と各プラットフォームでそれっぽい挙動して欲しい場合と色々いあるしなぁ 久しぶりにxaml触ってるけど(xamarinじゃなくてwpfだが)ほんと楽だわ(覚えるまでが大変なんだろうが)
だが、wpfで今アプリ作ると見た目が残念になるし。materialdesignxaml使うとデスクトップアプリでは不要な余分なスペースだらけになるし
いくらxamlすごくても自分でテーマつくちゃうぐらいのセンスねぇし
まぁxamlどっかで復権してほしい。チャンスあるとすればwinui 3.0次第かな なんかXamarin FormsでXAML楽チンて言ってるやつはほんまにXamarin Formsでアプリ書いたことあんのか
Entryのborderのcolorを変更するだけでiOS/AndroidそれぞれPlatformEffect継承・実装してSharedでRoutingEffect実装してくっそめんどいんやがどこにReact Nativeよりメリットあんのか教えてほしいわ
個人的にずっとWPF/MVVMで開発してたからXAMLは好きやしゴリゴリユーザー定義コントロール作ってたけどXamarin Formsはクソで少なくともUI実装においてJSX/TSXに勝てる要素がない 初めてのアプリ開発にXamarinかFlutter使ってみようかと思ってたんだが、こういう流れ見てると素人ほどネイティブで作ったほうがよさそうね
楽しようとして結局苦労しそう >>788
ちょっと作ってみるにはFlutter、ガッツリ作るならFlutterでもnativeの知識必須。 >>789
ちなみにその基準の「ガッツリ」ってどの辺から…？ >>790
ゲームのようなアプリとか、GPSやBLEをマニアックに使うアプリとか、スマホの性能ギリギリまで色々とやりたい時。
逆にスマホデバイスもほとんど使わずListViewレイアウトぐらいしか使わないアプリはFlutterのほうが早い。
mateと同じ見た目のアプリをFlutterでやろうとするとかなりシンドい。 継承・実装って言うと大げさだけど右クリからポチポチクラスつくって
2,3ステップのコード書くだけやん
大体Xamarin Formsでいけるし
ios12→ios13のSegmentedControlの仕様変更は少し大変だったけど Buttonをまったく違う形状にゴリゴリにカスタムしたい
Xamarin FormsならEffect、Visualを使ってコードビハインド
React NativeならCSSプロパティ設定するだけ
どっちが簡単かつ柔軟で実装が楽か結論でてるやろ >>791
なるほどありがとう
mateはchmateでは
使ったことないけど2chブラウザがそんな難解なデザインしてるのかな xamarinは、最小に近い簡単なプログラムでも *.apk が22MB位、
同じアプリをJavaとAndroid Studioで作ると *.apk は1.8MB位
で済むそうだ。 >>794
それはReactNativeがround buttonについて実装済みってだけじゃね？ ボタンの形とかより、なんとなくボタンを押したときのグラフィックの感じとか nativeのままだとが気に入らないことがある。 ソフトウェアの利用者は、ソフトウェアごとにお作法が違うとめんどくさい。
おまえのソフトは誰も使わないからどうでも良いけど。 Xamarin程の糞はないと3年前から言い続けてやっと時代が追いついた Xamarinはネイティブラッパーな仕様が糞すぎんだよ
RNやFlutterのように独自実装ならiOS/Android同じViewで同じ見た目にできるのにネイティブラッパーだからできない
肝心のXAMLも同じ見た目にする場合カスタムが必要でプラットフォームごとにコードビハインドで実装しないといけない糞仕様
FlutterはPlatformViewでネイティブ利用も改善されてきたがDartが糞すぎて嫌いだしWedgetsの構文がまんまJSXのパクリで草
RNは開発環境でハマるのが糞やけどXamarinやFlutterよりは好み やっぱ俺の先見の明は確かだな
Xamarin程の糞はないしクロスプラットフォームは例外なく糞 客が既にSwift/kotlinで作ってあるアプリをXamarinに切り替えるって言って聞かねーんだがどう説得すりゃいい？
ここで言われてるようにクソだからやめとけって言ってんのに全然だめだわ
切り替えたい理由は自社にネイティブの有識者はいないがXamarin経験者はいるから保守が楽になるだろうと言うことらしい お前がそのXamarin経験者より下に見られているというだけの話
人脈作りを怠ったツケだよ 歴史的過程から考えて今後長くXamarinが保守されるとは思えない。 >>803
調達したチーフプログラマーはC#が得意だったという理由だけでXamarinにするなら絶対ハマるし属人化するから100％保守が大変になると説得しろ
俺がネイティブで書けと断言する理由はおおよその企業のプロジェクトにおいて一番苦労するのは人材の調達や交代やからや
プログラマーを調達・交代できずに苦労するのが目に見えてるから先を見てネイティブで書けと言ってんねん
そら最新の言語・環境なんかのメタをすぐキャッチアップできるフルスタックな高スペックプログラマーがいくらでも社内におるなら別やから好きにすればええけどな 問題起きても客が対応するって事だろ？
Xamarinに切り替えたらええやん
ディスコンになったらまた切り替える羽目になるんだから
いっぱい稼げて美味しいじゃん 企業としてのXamarin社は当面残るだろうが、プロダクトとしてのXamarinは.NET 5(更に先の.NET 6)に統合
することをMicrosoftが言明している
中身はともかくXamarinの名称そのものは近いうちに消滅する xamlをちゃんとデザインできるようになったら
xamarinと言う名前はどうでも良いし、上手く行けばUWPを1回書いたら
Windowsでもandroidでも動くように・・・・なるのかな
AdobeのFlashはAndroidもiOSもWindowsもmacも全部同じバイナリが同じように動いたのに残念だった・・・ XAMLがすでにオワコンやねんなー
XAMLでウェブアプリ作るサードフレームワークあったけど盛り上がらずMSも買収せんかったし
んで結局アプリ・ウェブをクロスプラットフォーム開発可能なBlazorがリリースでこっち推しはじめて時代はWASM/WASIのBlazorですよと
.NETもオープンソース化に遅れてオワコン化手前までいったけどUnityなんかでなんとか耐えたけどXAMLは完全にオワコン
ウェブとモバイルを軽視しすぎたMSの失敗でXAML死んでしもうた、XAMLでウェブ開発かのうにすべきやったと思うけどASPあるからしゃーないわな >>810
それがUno。
弱小だし、Xamarin頼りな点が惜しい。
そういうのをMSが作れない、作らないのがダメダメ。 だな。MSがやらんから、他がやろうとして結局リソース不足の品質でリソース分散で共倒れ Unoもそうだしavalonia UIもそうだし。リソース分散 >>804
クッソ頭悪そう
文脈から考えて作るのはアウトソーシングで納品後のメンテは自社でやるってことだろ >>803
Forms使うんじゃなくXamarin.Native使うならありなんじゃねーの
ロジックが共有されるのは大メリットだろ ロジック共有なんてRNもFlutterも一緒やしすでにXamarinの専売特許やないねん
そもそも当事者のMSがSkypeをRN、VSCodeをElectronで書いてるからな
Blazor推すならさっさとこれらをBlazorで書き直せと、なんかMSは縦割りなんか知らんがやってることがあべこべなんよ
俺がMSの開発環境に絶望して忌避するようになった理由はそこなんや、C#そのもの今でも一番好きな言語や マイクロソフトが嫌いだからって周りにマイクロソフト嫌い菌をばら撒くとか気違いすぎる さすがにblazorで書き直せはいくらなんでも明確なメリットないと相手が大企業で高収益企業だからって無茶苦茶すぎる すまん、ネイティブしかやった事ないけどロジック共有ってどのくらいできるものなの？
ささっとググったら半分も行きゃ良い方、ＵＩ周りは結局別で作らなアカンしXamarin特有のバグもあるから旨味が消えてしまうケースも多いと出てきたんやが >>820
BtoCのアプリだけどForms使って9割以上共有してる
共有できるやつはそう書いて固有に実装しないと無理だなってところだけ個別に書くだけだからものにもよるけどほとんど共有できるだろ >>817
Xamarin,RN,Flutter各々のいいところ悪いところあんだからじぶんがつかいやすいものをえらべばいいだけでは。
MSがそれらを作り直さないのはわざわざ作り直す必要性がないしそれらを選んだのも既存コードとの関係でそうした方が都合が良かっただけだろ まあマジレスすると、Xamarinが最強とかは言わないけどロジック共有して開発できる実プロジェクトで十分問題なく使えるある意味枯れたクロスプラットフォーム開発環境として十分に選択候補としうるものだと思うけどね
js得意ならRNとかでもいいんじゃね？ >>821
Xamarin.iOS/AndroidとXamarin.Formsってどう違う？
俺もXamarin使ったことない素人だから聞きたい >>824
X.iOSと泥は各プラットフォームネイティブアプリをC#で書ける仕組み。それだとUIも各プラットフォームの流儀で書く。Xamarin.Nativeとも呼ばれる。
FormsはXAMLを使ってどちらででも動くUIコードを書けるフレームワーク。
AppDelegateとかMainActivityとかからXamarin.Forms.Init()などを呼んで動く。XAMLで書かれたコードは結局は各プラットフォームのUI,ViewControllerやら何やらに作用して動く。ので共通コードで書いても各プラットフォームっぽいUIになる。 のでFlutterが全部自前描画して共通なUIを作ってるのとはまるっきりアプローチが違う。これは強みでもあり弱みでもある。Flutterは同じ見た目のアプリを作るのは容易い。が自前描画ゆえ既存のネイティブコントロールとの混在などが苦手。
のでwebViewがらみとか弱いらしい(使ったことないので聞き齧り >>825
ありがとう
NativeはUIはそれぞれ作成、FormsはUIも共通化可能と言うことなんだね
Formsで共通化する方が利点が多そうだね >>827
共通にするが故のデメリットもあるから銀の弾丸じゃないけどハマればメリット多いと思うよ Formsはフォームにパーツを配置してデザインできないのがなぁ
開発画面はXamarin.Androidと大差ないのに
Visual Studioの機能を生かし切ってないのが不思議 c#使いが期待するのはまさにそれなのよね
だからみんなコレジャナイ感で手が進まない そんなんレベル低いやつだけだろ
ポトペタでUI作るやつなんてウェブですらおらんぞ
勝手にC#erの総意にすんなよ いちいち意図通りのUIになってるか確認する作業と調整を繰り返すんですかね？
それこそ低能なような なんのためのホットリロードなんだよ
こんなレベルであれこれ言ってんだから草 >>827
ところがどっこい、Formsは最大公約数でしかないので細かいことをしようと思ったら結局Native UI使うハメに。
それにFormsはNative UIへマッピングされてるに過ぎないので細かい挙動が違うこともしばしば。
それでも別に作るより楽だけどね。 なんかレベル低いそもそもネットで調べただけでXAMLまともに書いてないにわかが湧いてんな
XAMLをデザイナで作るやつなんていねーんだよバカそもそもExpression Blendすらそんなのあったななんて存在なのにおまえにはWindows FormsかVBがお似合いなんだよボケ
XAMLの真骨頂のControl TemplateやFlameworkElementでゴリゴリにカスタマイズするときにポトペタできないとか微調整するんですかとか無知すぎんだよにわかが
XAMLは常にデータバインド意識しながら書くんだから微調整するに決まってんだろだからMSもホットリロード実装しんたんだよにわか 総意にあらずとか無知すぎんだろ
XAMLはMVVMアーキテクチャでViewを書くために作られてデータバインドなくしてXAMLはねーんだよ
そもそもXAMLのオブジェクトはすべてDependencyObjectを継承してんの理解してんのか？HTMLのDOMじゃないんだぞ？
マジでレベル低すぎんな >>835
足りないコントロールとかはViewなりSkia使っての描画なりで共通に動くもの作ったりすると思うけどそれで足りないもの何ある？
自分とこでは一部Renderer使うぐらいで治ってるけど
>>836
最近UI側触れてないのでホットリロードあんま触ってないんだけど、あれちゃんと動く？この辺はちょっと制約があるとかあれば教えてくれ 俺もデザイナーいらんと思うわ
どうせ実機とずれるし。だったらちゃんと動くホットリロードあるならそれの方がいい WYSIWYGはいらんなぁ
デルファイかよっていう >>840
XAMLのHot Reloadは言語的制約で完全じゃないしまだプレビューだからかバグい
Viewの変更を保存したらリビルドせずにリアルタイムで反映させられるんだがもちろんロジックであるViewModel以下の変更は反映されない
まぁLive Visual Treeあれば俺は気にしないがな、これがなかった昔は実行時生成のバッキングフィールドやnameしらべるてて大変だった Unoとかも結局WasmでWebアプリ書けないからダメだな
XAMLをHTML5+Javascriptに変換するトランスパイラないと人気でるわけない
まぁXamarinをバックエンドに使ってるだけだからできんのだろうが >>844
>Unoとかも結局WasmでWebアプリ書けないからダメだな
？？ >>845
独自調べによれば、XamarinもBlazorもFlutterも人気が無いらしい。
逆に、Qt、Unity、vue、Reactが人気が有る。 不思議なことにgithubのstar数ではJSを使うものが圧倒的人気が有り、JSを使うところのvueは、C++を使うところのQtの数100〜1,000倍くらい人気。
そしてさらに不思議なことに、C#は人気だとされるにもかかわらず、GoogleTrendsやqiitaでは、C#を使うところのXamarinとBlazorは、人気が非常に低い。
その中でも特にBlazorは人気が無い。 >>849
もっと言えば、最大人気言語とされるPythonは、githubのstar数では、githubにあるPythonの中では最高のcythonでもvueの10分の1以下しかない。 >>850
スマン。2箇所間違いがあった。
1. cythonではなく、cpythonだった。
cpythonは、pythonインタプリタの処理系そのものなので、cythonとは違う。
2. star 数は vue の 1/10 ではなく、1/5程度だった。 https://news.mynavi.jp/article/20191112-922010/
↑
を見ると、2019/11時点のgithubでは、Dartが532%、Rustが235%の急上昇中。
Dartといえばflutterなので、flutterの人気も急上昇中なのではないか。
githubでの言語ランキングは、
JavaScript>Python>Java>PHP>C#>C++>TypeScript>Shell>C>Ruby.
なお、これを見れば分かるように、githubは、Webのフロントサイド寄りのプログラミング言語の利用が多い
ので、この人気順位には偏りがある。 いやクロスプラットフォーム開発とフロントエンド開発比べてどうすんの
それはそれで意味ある時もあるけどちょっとその比較は違わん？ アンチのせいで他との比較ばかりだなｗ
Xamarinもネタないけどｗ もうXamarinに将来はないから次の乗り換え先情報交換スレになってるね。 学生が作った、ブラウザでプログラミングできる、CodeSandbox が、GitHub と連携してるから
【クライアント側】
Angular、React、Vanilla、Vue、CxJS、Dojo、Preact、React+TS、Reason、Svelte
【サーバ側】
Gatsby、Next.js、Node、Nuxt.js、Apollo
Ruby on Rails でも、こういうサイトを作ってほしい Xamarin.Androidでシミュレーター実行できなくなった Android StudioがまともやったらFlutterもありなんやけどな
あのクソUIはベースEcripseなんちゃうんかマジクソ
VSで全言語対応してくれりゃ神なんやけどな >>857自己解決した。
Windows10のバージョンを1809から1909に上げたらAndroid Emulatorで実行できた 本家の開発環境で一般化しているライブラリがXamarinに無かったりするのが辛いな
小さな差が積もり積もって地味に効いてくる
例えばRecyclerViewとか直接使ってる人なんてあんましおらんだろう Firebaseのライブラリすら致命的なバグだらけで草
AuthとStore両方使うとインスタンスがNULLになるバグとか使いもにならん
GithubのIssuesにレスしてもシカトやし
現状のMS開発環境の致命的なところはOSS化が遅れたこととMSのヘイト高いことが原因でライブラリがまったくないということやねん
JavaScriptやPythonやReactが流行ったのはライブラリ含めたトータルの環境が整ってるからなんよ
もともとオワコンやったXamarinがBlazorによって産みの親のMSにトドメ刺されてワロタ まぁ厳密に言えばネイティブラッパーのXamarinをさらにラップしたのがBlazorやから開発が停止することはないやろうけどこのままやとバックエンドとして使われるだけで終わることになるやろうな ３年前から糞だと見抜いていた俺様の先見の明は凄い
オレの予想は当たる
クロスプラットフォームは総じて糞 .NET Coreあるんだから使い物にならない基本部分だけじゃなく
各OS、デバイス向けに統一的にしっかり作り上げてほしいもんだ。
個人的にはBlazorよりUnoのほうがましだな。
Xamarin抜きで作り直して。 趣味でスマホアプリ作ろうと思い色々調べてたら共通で作れるXamarinがあることを知ったのだがswiftとkotlinでそのままやるのとどっちがオススメ？
質問がふわっとしすぎて糞なのは百も承知だが他者の意見が聞いてみたい、もちろん主観で構わないので ないっす
言語経験は.NetとJavaを業務で使ってて趣味でpythonをかじってる程度 UWPのコントロールで間に合うアプリなら、Uno PlatformでUWPアプリ使ったらiOSとAndroidのアプリもついでに出来上がる感じ。
独自描画で速度追求してガリガリ描くのはiOS、Android各々作ることになるかも。 >>875
>>873じゃないがC#経験ないのにあえてマゾい開発環境のXamarinにする択がないって話やねん
選択肢多いのにC#触ったこともなくC#の資産をどうしても使用したいわけでもないのにXamarinて選択は取捨選択できないアホやなって感じ
C#という言語や.NET Core(.NET 5)やXamarin FormsのXAMLを学習したいんやったら好きにすればええけどな >>874少し修正
×UWPアプリ使ったら
◯UWPアプリ作ったら UnoとXamarinだったらどっちがええの
ASP.NET(Legacy, Core)とWin Formsはやったことある
WPFは一覧系サンプル画面写経して飽きた 飽きたじゃなくてわからんかったんやろ
WPFわからんてMVVM+XAMLが理解でけへんかったんやからXamarin FormsもUnoも無理やな
RazorしかわからんならBlazorしかないしWeb Formsしか触ったことないならMS環境諦めてReact NativeかFlutterでもやればええんちゃうか
まぁMVVM+XAML理解でけんのにJSX(TSX)+Flux(Redux)を理解できるとは思えんけど と、低レベルな質問を揶揄されて顔真っ赤な雑魚が何かもうしております とはいえUnoだとFileOpenPickerでもUWPにしか無いのね… 揶揄…？
思いっきり侮蔑してますやん
日本語が不自由すぎて悲しくなるわ 既存ライブラリで共通ソースできたら良いなという願望 まぁ、とりあえずオンラインで開催されることになったBuild 2020に望みを(xamarinの望みではない)..
まぁ、WinUI3.0のpreview出て... flutterは興味あるけどdart覚えるのめんどくちゃい dartなんてtypescriptのパクリやからバカでも書ける1日キャッチアップして理解でけへんのはやばい
FlutterもまんまReact NativeのJSXのパクリやからReact Native知ってたら余裕
どちらにしろベースはJavazScriptとかわらんから誰でも書ける つうかDartとかいうマイナー言語選択したのなんでだ馬鹿なのかな 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 MVUとかReact NativeのJSX(TSX)のパクリで草
そしてWebが含まれなくてクソなのもMSわかってねーし
WebねーからOfficeやSkypeはReact使ってんだろーが馬鹿じゃんねーの
いい加減ASP切り捨てろよ あれ、これWinUI 3ってどうなるの?
MAUIへ一気に飛び越えちゃうの? MAUIはただのUIFrameworkだが
Project ReunionでAPIも統一しちゃおうという ごめん、Project ReunionはWindows環境限定かな
さすがにクロスプラットホームでのAPIの統一はきついか WinUI 3がどういった形でリリースされるか分からんが上位レイヤからは.NET 5(.NET 6)で隠蔽されるので関係ないだろ いや、WinUI3はWindows限定っぽくってMAUIとは別物になるのかもしれん
クロスプラットホームのUIフレームワークがMAUIで
Windows限定でWindowsのAPIを統合しようというのがProject Reunion(WinUI 3含む) もしくはMAUIのWindowsの実装で内部でWinUI 3使われる?
MAUIってFlutterみたく独自描画なのか?よくわからん 下々にとってはなんもかわらん
.NET/.NET CoreとXamarin/MonoのAPIを統合しますよってだけでアーキテクトでもフレームワーク作ってるわけでもない俺らに関係ない
フロントエンドから統合されたAPIにアクセスできるってだけでネイティブ実装はプラットフォームごとに存在する
WPF/UWP(WinRT)はWindowsネイティブ実装だしXamarin Formsはプラットフォームごとのラップされてる機能だけ利用できるのもかわらん Xamarin改なのに一年以上先とは仕事遅すぎる。 やっぱり、Xamarinは廃止されたか。
買収した時点でわかりきっていたことだが。 名前が変わったということは、根本的な構造が変わったということだろう。
WinFromsを発展させるなら、Ver 2.0 で良いところを WPFとしたのも根本的な仕組みが変わったからだ。 ASPあるからWeb必要ないでしょ？ってポリシーなんやろ
Razor拡張のBlazor出てきたからASP絶対捨てないマンがMS
これはおそらく開発チームが別でお互いの縄張りは荒らさないって内部抗争やろ
.NET 5でBlazor採用してバックエンドとしてXamarin継続するならXAML捨ててReactのようにASP+MVUで全部開発できますとかでないと意味ねーんだがそれができないMS
そもそもUWPがデベロッパーにそっぽむかれた時点でXAMLは失敗してんねん BlazorもHTMLをもろに使うようだから、XAMLと似てると思う。 複雑なので全部は理解して無いが、Blazorは、HTMLコードの中に
C#コードを入れて書くような形式も有って、その形式だと、
ぱっと見、PHPを彷彿させる。
PHPの場合は、ApacheなどがサーバーサイドでHTMLの中に書かれたPHPの
コードを実行してHTMLの中に結果を足し算して合成した結果をクライアント側
にネットで伝送するような形式だった。
それと似てる感じがする。 だったらPHPでもいいんじゃないかと思ってしまうのだが、どうなんだろ？ Blazorを使いこなすには、HTMLとCSSの知識が前提らしいし、全体の構造が
PHPに似ているようだし、開発環境などのシンプルさから言えばPHPの方が
わかりやすくすら思える。
PHPなら昔から容易に学べるという定評があるけど、Blazorは複雑怪奇すぎるように思える。 ReactやVueやAngularなどを使う人は、本当に静的なHTMLにちょっこっと機能
を追加したようなページを効率よく作ろうとしている人が多い。
例えばページをおしゃれに表示して、写真をちょっとだけ左右にスクロールできる
ようにしてみたり、おしゃれな視覚的な効果を得たいとか。
それに加えて、Mobileだと画面が狭いのでそれに合わせてカラムの幅を狭くしたり、
一行に表示するカラムの個数を減らして改行して二行目に表示したりとか。
それと表みたいなものを配列データから手っ取り早く書きたいとか。
そういうことがしたいだけから、基本的にはHTMLの構造のままで良くて、
大上段に構えたC#のような言語でなくても良くてJSやPHPのようなもので
十分だと思っている人が多いはず。 オープンソースのウェブアプリはPHPで書かれてることが多いけど
そういうレベル高いのでも綺麗なコードを見たことない
誰が書いても汚いということは言語に欠陥があるんだと思う しかし、WordPressもPHPだし、PayPalもPHPだし。
ウェブプログラマのやりたいことは既にAngular/React/Vueなどでも既にさまざまなテンプレートが存在していることが多いので、既に大きなエコシステムが出来上がってしまっている。
そこに敢えてC#でやる意味があるのだろうか。 >>TdTh77Kk
おまえ毎回長文連投するがぜんぜん理解してなくてググっただけなの丸わかりでにわかすぎるから消えてほしいんやけど PHP は可読性が悪い。
基本、Ruby on Rails, Sinatra など
加えて簡単なものは、jQuery, Bootstrap, Element UI。
複雑なものは、React が多い。Vue.js もいる
Angular は、やってる人がいない そもそも静的なASPとVDOMのReactやVueはパラダイムが別やから
それもNext.jsみたいなサーバサイドでレンダリング大正義みたいに回帰してて草
今はバックエンドがなんだろうとフロントエンドなんて自由に選べるんやからその時の状況に合わせて選択するだけや
俺はASP(1.0/WebForms/MVC)からPHP(Fuel/Laravel)からReact/Vueとなんでも書けるからその都度ベストな環境を選択するだけ
フルスタックですらないプログラマがあれこれ語るんは滑稽やな >>924
Githubの諫言が俺の不満そのものやな
とにかくバグが多いしいつまで経っても放置やし多数の致命的なバグを仕様として修正しない、これはWPFの時からそうやった
そして一番の問題はMSがOfficeやSkype含めたウェブ/アプリ開発にXamarinではなくReact/React Native使っとんねん！(笑)
.NETとC#だけはリソース注ぎ込んでるがその他のフレームワークはほったらかし、そりゃ誰もフレームワークやライブラリ作らんから盛り上がらんよ負の連鎖や
ここがReactやPythonと一番違うところで開発環境ってのはトータルパッケージなんであってエコシステムがまったく機能したない開発環境とか誰も選択せんよ
,.NETやC#好きな俺がMSの開発環境使わなくなった理由はそこやねん 要員が.NET寄りならXamarin使うしそうじゃなきゃ別の探すだけだ >>925
>MSの開発環境使わなくなった
と言いながらVisual Studio Code使ってたりしてw じゃ一体何でコード書いて・・ﾊｯ！まさかメモ帳！？ コロナ接触を通知する日本版｢接触確認アプリ｣を作ったのは誰か？…｢6割普及｣への挑戦 | Business Insider Japan
https://www.businessinsider.jp/post-214726
Covid19Radar/README.ja.md at master ・ Covid-19Radar/Covid19Radar
https://github.com/Covid-19Radar/Covid19Radar/blob/master/README.ja.md 確かに接触確認アプリはXamarinで作ってるね。
今時Xamarinなんて使うんだ。 XamarinはBLEの扱いが面倒だった覚えがあるけどさっくり出来てとるところを見ると解決したのかね >>933
なぜそこでまいくろそふとクオリティとか言い出すのかねw テストが甘かったと文句つけるのはわかるけど、
なんでそこまでこだわるんだろうか マイクロソフト社員の一人が基盤作ってパーソルプロセス＆テクノロジーが最終製品作っただけなのに
マイクロソフトクオリティとはひどいな。 東京都のコロナのSPAはNextJSで評判良かったのにXamarinは・・・
MSも詰めが甘いというかMSKKが無能すぎるというか
かずきおるんやからやつに作らせればよかったものを 彼は本格的にアプリ作ったことないとか言ってったっけww >>938
マジで？あれだけ詳しいのにアプリまともに作ったことないのか？
アーキテクトとかそういう感じなんかな・・・ 1国1アプリの話が出たときからこういう騒動は起きると思っていたので、別に驚きはないな
もっとも、ワイもXamarin.Formsを業務でバリバリ使っている人やけど、Code for Japanの方が採用されると思ってたわ OSSにおいて文句だけ言って解決策をコードで示さない人は害悪でしかないので無視してok よし、誰でもXamarinを使ったOSS開発に参加できるように、詫びVisual Studioを配布しよう！ >>946
こいつGithubのIssueすら読んでもないくせにやけに上からやな(笑)
解決策をコードで提示されても対応しないと批判されてるのに何言ってんやこいつは >>948
具体的にどのissueのこと言ってる？ >>949
Comunityの存在を素で忘れてた
一般的にも知られていない気がするので、開発のはじめかた、みたいな情報は周知が必要かもね >>951
Visual Studio Comunityをインストールした後どうするのですか？
Xamarinでシングルページのプログラミングして
Androidスマホでハローワールド表示までをお願いします。 Windows Phoneなき今、MSがXamarinをサポートし続けるとは思えないなぁ。
Flutterが怒涛の勢いで勢力を伸ばしているので今からならFlutterだと思うんだけど。
そのへんどうなんだろうね？ >>953
WindowsPhoneというかWin10MobileはXamarin関係ないよ
あれはもともとUWPデバイスだったのでXamarinは不要
XamarinはAndroidとiOSのためのフレームワーク
将来的にはXamarinは.NET5(とその後継)とWinUI3に統合されることが発表されているのでその役目を終える >>954
もともとMSがXamarin始めた動機ってWindowsPhone向けアプリが開発されないことにしびれを切らしたMSが「Xamarin使えば(UWP含め)マルチプラットフォーム開発できますよ」という謳い文句でWindowsPhone対応アプリを増やそうとしたって理解してるんだけど違うのかな？
今MSがXamarinサポートし続ける動機ってなんだろう？ >>955
MSがXamarin始めたって語弊があるね。
買収したに訂正。 >>955
次のマイクロソフトの統一コードのベースがXamarinだから
Windows,Linux,モバイル系を統一したいみたい 統一コード(というと微妙だけど)のベースは.NET Coreだよ
Windows用の.NET FrameworkとLinux他サーバー系OSSの.NET Coreとモバイル向けXamarinが.NET 5で統合される計画
現在は.NET Frameworkと.NET Coreが.NET 3(最新バージョンは.NET 3.1)に一本化されつつある途中 .NET開発者コミュニティの裾野を広げる意味ではむしろ必須じゃないかな
のほほんとしてたらWinサーバーと業務アプリ専用言語でジリ貧確実だし 推しはするだろうが、この議論を見ている限り、MAUIがうまくいくか、支持されるかは甚だ疑問だけどね。
https://github.com/dotnet/maui/issues/43 ウェブがないから指示されんよ
やっとVB切り捨てるんやからASPもさっさと捨てればええのにBlazorとか斜め上に走るのがMS Blazorは絶望的にないね。
Webだけに特殊な構文とか。
WebもありのUnoのほうが良かった。 Xamarin買収してUWP推進したのになぜフロントエンドをXAML+MVVMに一本化しなかったのか
Razor(ASP)捨てずにBlazorとXAMLの二本立てなロードマップは意味不明すぎるしそらウェブもあるReactかFlutterになるわな
MSはウェブとアプリのフロントエンドをXAML+MVVMに一本化すべきやった Blazor Server Side + JSの組み合わせができて、Blazor Server Side + Blazor Client Sideができない(たぶん)ってのは、何とかならないのかな？ Xamarinじゃなければコントリビュートする気になったのに Web対応と支持云々はあまり関係ないな。
この場合、旧来のデスクトッププログラマーにすら支持されないのではという話なので。
それとは別に、Web開発をXAMLベースで行いたいという意見はわかる。
BlazorはWebエコシステムを取り込もうとして微妙なものを作っちゃった、みたいな印象。 ウェブは関係おおありやろ世の中の案件の大半がウェブやのに関係ないわけない
ウェブを蔑ろにしてコミュニティがまったく盛り上がらんからフレームワークもライブラリも増えずエコシステムが崩壊してんのよ
Pythonみたいな糞言語が圧倒的な人気なんはエコシステムが成立してるからや 言い方が悪かったか？
Web対応以前の段階での支持すら怪しいと言いたかっただけだ。 xamarinが悪いわけじゃないのに
【コロナ】接触確認アプリ、開発から無償ボランティアが離脱へ (元請けはパーソル) #OSS ★４ [雷★]
https://asahi.5ch.net/test/read.cgi/newsplus/1592956830/ デプロイ王子はメンタルやられて撤収するらしいけど、
Xamarinなんてマイナーなプラットフォームを引き継ぐ奴なんていないだろ。
どこかの下請けがババを引かされて死ぬんだろうな。 アプリストア側が1国1アプリと言ったから元々複数あった有志のプロジェクトから政府がこれを選んだわけで
あらゆる文句は開発者ではなく政府に言えよとしか思わないけど頭悪い人はなぜか開発者叩きをしたがる っちゅーかさすがにこれはXamarin云々の話やなくて日本のIT業界の常識が終わってるって話やろ
日本の客は頭が悪すぎるねん、大手メーカーのIT子会社・系列会社に丸投げしてそこから元請けもSIに丸投げで多重請負の構造でありふれたクソアプリの量産してるなんて俺らからすれば日常やろ そこに更にこのスレにも良くいる技術的な話でマウントをとりたい奴と
とにかく何でも良いから政府の批判をしたい奴からが大挙して作者のTwitterに突撃してメンタル破壊した感じだな
おーやだやだ 技術でマウント取りたければとっととプルリク送ればいいし政府批判したいのに開発者に文句言うのもおかしいし批判が生きがいになってる頭おかしい人が多いよね と、このように批判を生きがいにしている人がもうしております >>982
二位じゃ駄目なんですかとか
クラウドなら鯖要らないじゃないですかとか 既に公開中のiOS、AndroidアプリをApp CenterでTrack EventとTrack Errorを拾うように修正したら数少ないユーザーさんが使ってくれなくなってしまいました。
プライバシーには充分配慮して、万が一にApp Centerにアップロードされた内容がハッカーに見られたとしてもユーザーさんには全く影響が無いようにしたんですけど（個人的な内容を含む文字列は文字数のみを拾うようにしました）。
更新履歴にはTrack EventとTrack Errorを追加したことは書いて無いから、ユーザーさんがアプリの通信履歴を見て警戒されてしまったのかもしれないです。
アプリの改良のためだけにTrack EventとTrack Errorを追加したんですが。 MSって作りっぱなしだからな
メンテすらまともにしないから使われないのがよくわかる
しかしMSだから国内の企業での採用率の高さが悩ましい MS製品なんか使ってるから日本はIT後進国なんだ
MSとかデスクトップアプリ全盛の時代までの過去の産物だろ
今はウェブの時代AWS、GCP、スマホアプリの時代
日本はオワコン でも、オープンソースだからと言って免責になるわけではなく作者は完全な製品を提供しなければならないと Ubuntu Japanese Team の人が見解を述べてたけどな。
Ubuntu のくせにそんなこと言って大丈夫なの？って問題はあるけど。 まぁ俺は宗教的な崇拝とかまったくないからその時一番需要があったり便利だったりな環境で開発するだけだけど
MSの環境はオールインワンなのがよかったんだけど変にOSSを取り込んでて設定を自分で書くんかい！って感じでVS使うメリットが薄れてるんだよな
まぁ仮想化なんかのミドルウェアの面倒臭さをMSが解決してくれると思ってたけどAzure強要されるのもわかってないよな 誰も使わない時代遅れのデスクトップアプリでも作ってろクズ >>990
AWSの後なぜ3番手のGCPを出すのか?
2番手のMSのazureはどこ行った? 学術の巨大掲示板群 - アルファ・ラボ ttp://x0000.net
数学 物理学 化学 生物学 天文学 地理地学
IT 電子 工学 言語学 国語 方言 など
simulationライブラリで純粋な関数式プログラミングをする
UIライブラリ (C#, 2D) を作ったよ
連続と離散を統一した！
4Dエンジン
matrixのライブラリ
ある強力なFor関数
SQLライブラリ
☆ VM + ASM を書いた (C#, DX) * x86 ではない!
ttp://up.x0000.net/files/TSimulang.zip
☆ malloc / free を実装してみた (C#)
ttp://up.x0000.net/files/TMallocTest.zip クローズドなら完璧なものがリリースされてるとでも思ってるのか？ このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 1022日 7時間 43分 59秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
