Xamarin Part6
レス数が1000を超えています。これ以上書き込みはできません。
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でブランチを切り替えたりするだけでビルドできなくなって、
クリーン、リビルド、IDE再起動、PC再起動を頻繁に繰り返さないといけなくなる欠陥品なのが糞
大体MicrosoftはWindowsPhoneのシェアを二桁取ってからモノを言えと言いたい
MicrosoftがやっていることはGoogleやAppleの作ったパイを横取りしようとしているだけ
MVVM前提の開発環境とか言うくせに外部ライブラリを入れないと良い感じでMVVMできないのが糞
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エンジニアは全員死んだ方が良い 糞な部分を列挙してるつもりなんだろうが
読めば読むほど無能自慢してるようにしか見えないという
不思議な長文 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 がはははははははwww
MS帝国が終わる日が来るとはなwww >>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
月曜じゃないじゃんw 現地では月曜かもしれんが・・・ コードが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開発者が取り残されていると感じていたとしても不思議なことではない。
さらっといいこと言うねw 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
ありがとう
うーん、たしか上巻発売時には去年の秋くらいに下巻発売だったよな気がw
これは発売中止って考えておいたほうがよさそうかね
下巻も日本語版でじっくりと読んでおきたかったんに残念 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の1つのスレッドその間死ぬんだけど。何ビジールーブしなきゃいいって。 >>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はキングオブ糞 求められるのは高速化ではなく、効率化だな。速く組んでも無駄な動作ばかりしてたら駄目だろ。
そういう意味合いで、開発言語の共通化は部品の共通化になり、効率が上がる。 どうでもいい言葉遊びは置いといて、多くの部分を共通に作れるからトータル時間短く開発できるしメンテも楽。
決して共通化=早く開発できるではないけれど、自分の経験上は環境構築のトラブルなど考慮してもざまりんでやった方が別々に作るよりはるかにマシっていうか別々に作ることとか考えただけでもやだわ 最初にちょまどさえ使わなければこんなに粘着されることもなかったのに 粘着する基地外を叩くべきでそれでチョ窓を叩くのは基地外の思う壺 このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 290日 6時間 55分 0秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。