Xamarin Part6

2017/10/19(木) 07:55:07.34

!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

2018/07/17(火) 00:16:47.52

ありがとうございますｓ

**875** (ﾜｯﾁｮｲ 5ee0-lhhz) · 2018/07/17(火) 11:57:46.42

とりあえず原因はわかりました。
MasterDetailPage.MasterBehavior のデフォルトが MasterBehavior.Default になっている場合、モバイル端末以外では非表示にならないようです。
UWPでも消したい場合はPopoverにすれば消えました。

2018/07/17(火) 23:20:04.83

Xamarin程の糞はない

2018/07/19(木) 18:23:35.87

「Delphi」「C++Builder」のフル機能を無償で～“Community Edition”が発表 - 窓の杜
https://forest.watch.impress.co.jp/docs/news/1133620.html

これの C# 版が求められている > Microsoft

**875** (ﾜｯﾁｮｲ bfe0-qR59) · 2018/07/19(木) 18:55:58.80

>>884
Visual Studio Community じゃダメなの？

2018/07/19(木) 19:01:38.62

>>884
おまえアホだろ

2018/07/19(木) 19:06:15.39

>>884
これ(開発ツール)のC#版ってVisualStudioのことだろ
どちらかと言えば、EmbarcaderoがMicrosoftの後を追っているだけのようにしか見えない
以前のXamarinStudioからVisualStudioへの移行時とほとんど同じ流れだな

2018/07/19(木) 19:12:36.97

>>885-887
C# だとWindows、macOS、iOS、Android向けのネイティブアプリをワンソースで開発できないやん。

2018/07/19(木) 19:18:22.68

プラットフォーム差があまりに大きいからな
完全にワンソース化も技術的にはできるがデメリットが大きすぎる。そんなもん誰も欲してない

2018/07/19(木) 20:09:17.35

馬鹿でも使えるようにスマホ基準で作ればいいだけだから。

2018/07/19(木) 20:29:16.47

>>890
それならXamarinでもできるやん。
各プラットフォーム毎に自動生成のプロジェクトはできるけど、実際のソースは一か所で済む。

2018/07/19(木) 20:37:14.38

Xamarin程の糞はない

2018/07/19(木) 21:10:40.76

>>891
ワンソースでmacは無理、Windowsもまぁ半分無理。

2018/07/19(木) 21:35:50.36

>>888
ha ?

2018/07/19(木) 21:44:16.23

Xamarin長い髪をほどいて～

2018/07/20(金) 02:44:19.93

>>893
スマホ基準でMacやWindowsを無理矢理ワンソース化するとかアホだろ
誰もデスクトップアプリをスマホ基準に合わせようとは思わないよ

2018/07/20(金) 08:06:00.04

ロジックの共有化とかは大歓迎だけどな

2018/07/23(月) 08:09:26.90

昨日動物園でタマリン猿見てきた

2018/07/23(月) 08:13:01.43

こんな優秀なクロスプラットフォームが存在したのか
凄すぎるよ全く

2018/07/23(月) 08:37:45.82

優秀なクロスプラットフォームｗ

2018/07/23(月) 10:15:22.01

Xamarin程の糞はない

2018/07/24(火) 21:00:58.25

ようするに UI は共通化するのがベストとは言えないんだよな
無理やり共通化すれば開発コストは下がるけど、ユーザーからするとプラットフォームごとに最適な UI のほうが嬉しい
コストを下げる代わりに UI は多少チグハグになることを理解してる客向けなら Xamarin.Forms は良い選択肢

2018/07/24(火) 22:37:34.20

客からiOSとAndroidでUI一緒にしてくれと言われることが多い

2018/07/25(水) 07:46:14.51

>>903
客の意見をそのまま通す、無能な営業にはお似合いだろうね。

2018/07/25(水) 08:00:37.66

働いたことのないニートの戯言聞いてるとああ夏休みかと実感するわ
あニートに関係ないかw

2018/07/25(水) 20:09:02.38

糞みたいな職場のやつがXamarinみたいな糞を使う

2018/07/26(木) 20:42:32.24

await って必ず元のスレッドに戻る?

2018/07/26(木) 20:55:32.11

>>907
いいえ

2018/07/27(金) 06:12:30.42

async

2018/07/27(金) 21:32:07.13

>>908
UI スレッドでの await は UI スレッドに戻るけど、ワーカースレッドでの await は別のワーカースレッドに戻る可能性があるっていう理解で合ってますか?

2018/07/27(金) 21:40:06.95

いいえ、Xamarinは糞です。

2018/07/27(金) 21:55:30.33

>>910
ConfigureAwaitでググれ

2018/07/27(金) 21:56:18.23

>>910
基本そういう理解であってる。UIスレッドでのawaitでUIスレッドに戻したくなければ、TaskクラスにConfigureAwaitメソッドあるから、ひきすうをfalseにして呼び出してそれをawaitする。

2018/07/27(金) 22:36:35.47

>>910
awaitをuiスレッド以外で使う必要があるのだろうか?

2018/07/27(金) 22:56:45.91

>>914
え？

2018/07/27(金) 23:30:48.90

>>914
いやUIを固まらせないためだけのものじゃないから

2018/07/28(土) 01:52:57.96

>>913
なるほど、そういうことだったんですね。回答ありがとうございます。
Realm を使っててよく incorrect thread の例外が出ると思ってたんですが、ワーカースレッドで await してるから出るっていうことなんですね。

2018/07/28(土) 07:31:50.96

>>916
ワーカースレッドを非同期で実行させなきゃいけない場合って具体的にはどんな場合?
uiスレッド以外は待たせても問題ないと思ってるんだけど。

2018/07/28(土) 08:31:06.45

よく知らずに回答するけど、ソケット監視してるスレッドとか、ui以外でも固まったら困るスレッドはいくらでもあるんでないの？

2018/07/28(土) 10:11:20.49

ワーカースレッド内で複数の非同期処理を同時実行したいときなんて普通にあるだろ

2018/07/28(土) 11:16:19.45

>>918
待たせたらCPU無駄になるだろうが

2018/07/28(土) 16:20:52.38

>>921
ワロタXamarinは糞過ぎ

2018/07/28(土) 17:47:29.06

今回問題になったのは、とあるメソッドがタップと通知どっちからも呼ばれるケースがあったからでした
通知から呼ばれた場合には await してる部分の前と後でスレッドが違うから Realm の制限に引っかかってた
どっちからも呼ばれる作りがよくないのかな

2018/07/28(土) 20:08:07.70

>>923
いやRealmはよく知らんけど作成したスレッド以外で触るなとか制限あるの？だったら通知で違うスレッドになりうるならUIスレッドからになるように調整しろよ

2018/07/28(土) 21:02:42.65

>>920
その普通を思いつかないから聞いてるんだ

>>921
ビジーループで待たなきゃ良い

2018/07/28(土) 21:09:47.58

ID:/yDPlbZT0
なにこのレス乞食

2018/07/28(土) 21:22:26.14

なんだ答えられないのかyo

2018/07/28(土) 22:06:02.29

>>925
いやWaitしたらCPUの１つのスレッドその間死ぬんだけど。何ビジールーブしなきゃいいって。

2018/07/28(土) 22:29:42.59

>>928
CPUが無駄ってブロックされるって事か。
無駄にCPU Timeを食うのかと思ったw

スレッドがブロックされるから別スレッドにしてるんだろう。
ワーカースレッドがブロックされても問題ないだろうよ。

2018/07/29(日) 00:51:56.70

>>929
ほんと馬鹿だろお前。無能すぎて草生えるわ。
教えてやんないから一生バカのまんまでいろや

2018/07/29(日) 02:17:05.03

>>928
WaitしたらCPUのスレッドは別のスレッドの実行に使われるよ
普通のOSなら

2018/07/29(日) 02:58:21.55

>>928は馬鹿の予感

2018/07/29(日) 03:38:13.91

いまだによくわかってないんだけど、皆さんはイベントハンドラーが UI スレッドで実行されるのかワーカースレッドで実行されるのかってどうやって判断してるの?
ドキュメントに書いてなくない? 経験則?

2018/07/29(日) 06:32:20.60

>>933
ログのスレッドIDで確認

2018/07/29(日) 08:01:15.68

>>933
System.Threading.Thread.CurrentThread.ManagedThreadId で見れば分かるけど
ドキュメントにセカンダリースレッドで実行されるって書いてないかな。

2018/07/29(日) 08:03:41.30

>>932
マルチスレッドを使わない方が良い人だね。
async/awaitは馬鹿を量産できる仕組みかも?

2018/07/29(日) 09:36:12.11

Xamarinみたいな糞でやるから馬鹿になる

2018/07/29(日) 09:52:09.55

Xamarin関係なくね？

2018/07/29(日) 15:40:26.45

async await 便利だけど、Xamarin Android で Activity の中で使うのは注意しないと危険だねえ
いろいろやったり調べたりした結果、
使いたいなら Task.Run( async () => { .... } ) の中で使うのがいいのかなとか思った

await 指定無しで呼んで ContinueWith(() => { }) とか付けといてもいいかもだけど

2018/07/29(日) 17:30:12.55

流れぶった切って初心者質問させてください。

スライドスイッチの大きさを大きくしたいんですが
どうやってやりますか？

SwitchCell でも Switch でもどっちの場合でもいいんですが
縦横2～3倍に巨大化したいのです。

2018/07/29(日) 21:44:20.40

標準コンポーネント大きくしちゃだめなんじゃないか

2018/07/30(月) 00:01:54.17

ダメっていうか無理だろ。
WPFみたいなレンダトランスフォームあったっけ？
ネイティブコントロールには無理そうだけど

2018/07/30(月) 00:12:16.06

Androidの場合の方法
https://stackoverflow.com/questions/47056004/how-to-increase-size-of-switch-control-xamarin-forms

2018/07/30(月) 00:48:46.84

iOS/Android ともに Scale は変えられるみたいだよ
カスタムレンダラーで変えればいけると思う

2018/07/30(月) 08:40:22.88

> Xamarin.Formsはちょっと複雑なことしようとするとお得意のdependency serviceとcustom rendererの連発

2018/07/30(月) 09:37:33.81

>>944
IOSもいけるんだっけ。したら両者Effectでもいけるのでは

2018/07/30(月) 13:37:39.52

公開アプリじゃなくて社内アプリなので
iOSは無視でいいです。

デフォのが小さすぎて操作しづらいという意見があって。

2018/07/30(月) 13:39:57.45

>>943
これは自前のスイッチ作っちゃう系ですか。

スイッチ以外のテキストもろとも大きくなっても文句は出ないと思うので
スケール弄りという手段もOKです。

2018/07/31(火) 05:18:24.40

http://atsushieno.hatenablog.com/entry/2018/07/31/030110

2018/07/31(火) 09:06:02.55

atsushienoも逃げ出すXamarinの糞さ

2018/07/31(火) 12:38:30.42

ちょまどは

2018/07/31(火) 12:42:59.07

可愛い糞

2018/07/31(火) 12:49:02.43

ちょまどはもう全然Xamarinの情報発信してなくね
Xamarinみたいな糞を未だにやってるのは騙されたお前らだけ

2018/07/31(火) 13:27:53.42

騙すのが上手なのは同意

2018/07/31(火) 13:31:22.81

>>950
辞めるのはMSであってXamarinの開発はまだやると言っているんだが

2018/07/31(火) 14:20:16.76

>>955
他の言語やフレームワークに乗り換える可能性が高いって意味のこと書いて無い？

2018/07/31(火) 15:02:47.70

会社に所属していると自分でやりたいことができない。だから辞める。
としか取れないんだけどな・・・

>>956
>非OSS部分が無いとコードが維持できないレベルになってきたら、他の言語やフレームワークに乗り換えてやっていくつもりです。
と書いてるだけ。逆にいうと、コードが維持できるのならC#のままって事だろ。

2018/07/31(火) 15:32:10.25

>>957
その次の「～早々にそうなるかもしれません。」が目にはいらないのかな？

2018/07/31(火) 19:44:36.05

Xamarin程の糞はない

2018/07/31(火) 20:25:37.08

ちょまどはどうしてEnoさんにお疲れ様リプをしないのかな？^^

2018/07/31(火) 20:27:04.06

https://twitter.com/chomado/status/1024196690687930370

2018/07/31(火) 21:09:24.53

>>953
先月カンファレンスで登壇してたぞ食糞野郎

2018/08/01(水) 10:44:54.45

すみません、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>

で、「あ」は表示されるのですが「い」が表示されません。

2018/08/01(水) 10:58:20.65

自己解決
HasUnevenRows = "True" にしないといけないのですね。

あとはスイッチのサイズ・・・

2018/08/01(水) 12:13:55.11

Xamarin.Forms 2.5.x で作ったプロジェクトを3.xに更新すると以下のエラーが出るのですが、解決方法はありませんか？

エラー CS0012 型 'Attribute' は、参照されていないアセンブリに定義されています。アセンブリ 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' に参照を追加する必要があります。

2018/08/01(水) 12:29:01.94

これ参考にしてカスタムレンダラーつくりなよ
scaleの設定が効くと言ってるよ
https://stackoverflow.com/questions/10173590/how-to-change-the-size-of-a-switch-widget
>>964

2018/08/01(水) 13:19:21.76

自作ですか・・・
了解しました。

2018/08/01(水) 14:00:41.74

Xamarinみたいな糞でやるからそうなる

2018/08/01(水) 17:04:26.25

ロジックの組み立ては C# でラクなんだけどなぁ
Java なんて関わりたくない w

2018/08/01(水) 18:50:20.90

素晴らしい
一つの言語でiOSとAndroidの開発が出来てしまうのか
Xamarin使うしか無いじゃんコレ

2018/08/01(水) 19:00:57.70

それならFlutter dartの方が良さそうだけど

2018/08/01(水) 19:02:10.53

.Formsの方は痒いところに手が届かなかったりするけど.Nativeの方はマジ強力で使える

2018/08/01(水) 19:44:02.57

Forms程の糞はない

2018/08/01(水) 21:42:17.83

Formsで届かなかったとこ何？

2018/08/01(水) 21:46:27.64

Flutterは後発で色々良いところもありそうだけどこなれてないとこもまだ多そうなイメージ
まだネイティブコントロールとの混在はできないんだっけ？

2018/08/01(水) 21:52:19.45

Android で Switch のカスタムレンダラー書いてスケール変えれるか試してみたけど、元々のサイズまでで描画が切れちゃってダメだな
Forms 生かすなら Android の Switch 使うのやめて、Switch っぽい見た目のもの作ったほうが早そう

2018/08/01(水) 22:02:37.74

そんな無駄な実験に時間を浪費する暇があったらネイティブでそれぞれで作ったほうが早い

2018/08/01(水) 22:08:23.18

iOSだったら三点タップして拡大してくださいで済む話

2018/08/01(水) 22:26:33.26

えーとネイティブだとスケールできるの？

2018/08/01(水) 22:32:15.11

ネイティブでも結局カスタムSwitch造ることになるんだからFormsでもネイティブでも手間は大して変わらんな

2018/08/01(水) 22:43:00.96

念のため書いとくけどiOSは三点ダブルタップで画面が拡大する