Flutterやろうよ！！！

**デフォルトの名無しさん** · 2018/06/02(土) 15:07:40.16

ようこそFlutter野郎どもよ！！！
軽い開発環境でモバイルアプリ開発ができるなんて最高じゃねえか
AndroidもiOSも両方行ける、まさに漢のためのツールだな

http://www.flutter.io

**デフォルトの名無しさん** · 2020/12/29(火) 14:27:41.79

Dartの無名関数すこ
こんなふうにしてる言語今まであったっけ
foo() {} // 有名
() {} // 無名
統一感がありすぎる
こうしてみるとなぜ他の言語こうなってないのか逆に不思議に感じるくらいの発明

**デフォルトの名無しさん** · 2020/12/29(火) 15:15:10.67

>>697
廃炉だろ？

**デフォルトの名無しさん** · 2020/12/29(火) 19:09:37.72

>>697
今月の記事、製品化はまだまだとのこと
グーグル、新OS「Fuchsia」プロジェクトを社外のコントリビュータ―に解放 - ZDNet Japan
https://japan.zdnet.com/article/35163612/

**デフォルトの名無しさん** · 2020/12/29(火) 19:17:28.07

そのうち無くなってるだろ
flutterとともに

**デフォルトの名無しさん** · 2020/12/29(火) 19:54:59.94

大体開発が長期化してるのは糞ゲーだと相場が決まっている

**デフォルトの名無しさん** · 2020/12/29(火) 20:23:21.67

flutterが失速したら次は何だろうね？今さらXamrinはないしReactの復権かなぁ？

**デフォルトの名無しさん** · 2020/12/29(火) 20:37:26.81

KotlinのKMMだろ
Netflixも採用したから伸びるぞ
言語もDartみたいなゴミじゃないしな

Flutterは今はシェア高いけどDartなんて好き好んでやるやついないし
すぐ廃れるんじゃないかな
RubyがRails専用言語で落ちぶれたように
DartはFlutter専用言語として消えていくと思う

**デフォルトの名無しさん** · 2020/12/29(火) 20:38:18.12

Kotlin KMM
Kotlin Multiplatform Mobile
https://kotlinlang.org/lp/mobile/

**デフォルトの名無しさん** · 2020/12/29(火) 20:40:02.35

XamarinはMAUIになったらMicrosoftが開発、管理するようになったら
品質あがって人気になる可能性はある。MAUI

**デフォルトの名無しさん** · 2020/12/29(火) 20:48:23.73

それ乗り越えてもmauiはもうひとつ問題がある
xamlが重い...
MVUサポートしたらxamlなくなって軽くなるのか知らんが

**デフォルトの名無しさん** · 2020/12/29(火) 20:49:14.15

kotlinはいいね
KMMには期待してるけどUI対象外だしな

**デフォルトの名無しさん** · 2020/12/29(火) 21:17:59.53

>>707
Xaml重いの根拠は？
native iOS, Androidとの比較で
Xamarinは14%しか速度落ちないようだから
XAMLだから重いってのは理解できない。
Visual Studioの重さと結び付けてないか？

**デフォルトの名無しさん** · 2020/12/29(火) 21:58:54.29

ごめん、厳密には原因を調べてない
xamlが重いのかはたまたmonoというか.netが重いのかは知らん

最近触ったのはUno Platform
androidでアプリ動かしてみたけどとんでもない重さ
ゴミレベルの重さ

**デフォルトの名無しさん** · 2020/12/29(火) 22:05:03.57

昔はUWPでタッチアプリも作ってたときも、デスクトップPCで動かす分にはいいが、タブレットPCで動かすと重い
x:Bindやらx:Loadやら試しても気休め程度

後、もちろんuno platformの実装がくそという可能性もあるね

いずれにせよ録なイメージしかない

**デフォルトの名無しさん** · 2020/12/29(火) 23:04:11.94

マルチプラットフォーム開発だと現状flutterが一番生産性とアプリパフォーマンスの点からよさそうだけど、Dartが言語として魅力ないのがなぁ

**デフォルトの名無しさん** · 2020/12/29(火) 23:26:01.28

>>710
Uno Platformは重いよ。
UWP互換レイヤーをXamarin上に組んでるんだから。
Xamarin.Formsやってみれば？
まあ軽くはないけど。

**デフォルトの名無しさん** · 2020/12/29(火) 23:46:38.79

>>712
昔ts2dartってあったけどあれ開発終わったんだっけ

**デフォルトの名無しさん** · 2020/12/30(水) 01:15:56.85

flutterの凄さと言うか他の追従を許さないのは、
描画エンジン
platformView以外、画面全体を自分で描画してるからな
あとdartはかなり洗練されてるぞ

**デフォルトの名無しさん** · 2020/12/30(水) 01:29:24.70

dartが洗練されてるとか無いわ

**デフォルトの名無しさん** · 2020/12/30(水) 09:55:56.63

>>716
どういうところが洗練されてない？
nullの話と文末のセミコロン以外でなんかある？

**デフォルトの名無しさん** · 2020/12/30(水) 11:28:43.57

>>715
そうそう、ActivityやらViewControllerのライフサイクルの違いをほとんど無視できて、個々のWidgetもかなり高品質なものが揃ってる。
アニメーションも強いし。

**デフォルトの名無しさん** · 2020/12/30(水) 20:03:28.41

Dartよく知らないけど
Dartが洗練されているならもっと言語として人気でてるはずでは？
Googleが関与してるならなおさら。

Dartは、KotlinのようにAndroidのFirst-class languageにも指定されてないってことは
機能やらなにやらが足りてないってことでしょう

**デフォルトの名無しさん** · 2020/12/30(水) 20:05:30.09

洗練されてるかどうかで言語を選べる人って趣味の人だけだろ

**デフォルトの名無しさん** · 2020/12/30(水) 20:07:29.68

>>715
前半も意味がわからない。
FlutterがOS標準のGUIを使わずに独自の方法でやってるということは
それだけバージョンアップ時に不具合が起こりやすいってことで短所にもなる。

KotlinのmultiplatformのようにGUIをOS標準に
まかせる方式のほうが問題が起きにくい。

**デフォルトの名無しさん** · 2020/12/30(水) 20:17:14.52

>>721
逆だよ。多少OSの仕様が変わっても低レベルの描画APIはそうそう変わらないし、変わったとしてもフレームワークで吸収できる可能性が高い。
例え話が適切かどうか分からないけど前にiOSで廃止になったUIAlertViewとかも独自描画のFlutterでは影響を受けなかったはず。

**デフォルトの名無しさん** · 2020/12/30(水) 20:37:03.25

>>722
使いやすいAPIを無視して使用しないなら
Flutter側で必要以上に複雑なコードで低レベルAPIを
叩いてるってことだからバグは生まれやすいと思うわ

**デフォルトの名無しさん** · 2020/12/30(水) 21:13:56.69

>>721
つreact

**デフォルトの名無しさん** · 2020/12/30(水) 21:29:38.91

>>724
なにがいいたいのか

**デフォルトの名無しさん** · 2020/12/30(水) 22:12:07.40

>>723
発想がズレてるよ。
flutterが全画面描画してるのはゲームと同じ土俵だから低レベルAPIじゃないんだ。
ゲームの土俵でUI/UXを実現してるだけ。

**デフォルトの名無しさん** · 2020/12/30(水) 22:15:27.56

>>726
低レベルAPIといったのは>>722で
俺はそれを信用してかいたわけだが。

Flutter内部のコードが複雑になってるのは事実だろ
コードが長くなればバグも生まれやすい
間違ってない

**デフォルトの名無しさん** · 2020/12/30(水) 22:19:09.06

ついでに言わせてもらうと、UICollectionViewとか、一見使いやすいように見えてcellの生成アルゴリズムを知らないとどハマりする。
flutterの場合reusableCellは無いから無限に作ろうとする。しかしscrollControllerで自由自在に生成/廃棄できる。

**デフォルトの名無しさん** · 2020/12/30(水) 22:20:54.07

>>727
間違えている。flutterはエンジンの動作をiOSが保証して成り立っているから。

**デフォルトの名無しさん** · 2020/12/30(水) 22:21:55.75

オープンソースだから気に食わなければコミットしたらいいですよ
嫌いなら使わなければいいだけ

**デフォルトの名無しさん** · 2020/12/30(水) 22:25:42.20

PlatformViewが使えない時はflutterエンジンが実画面にコピーしてたからなw
それはスピード的にコンニャクwだったなw

**デフォルトの名無しさん** · 2020/12/30(水) 22:33:49.04

iOSの描画に関してはMetal使ってるから変更にはめちゃくちゃ弱そうだけどな
Appleが仕様握ってるからほぼ完全に変更される可能性もある

**デフォルトの名無しさん** · 2020/12/30(水) 23:48:05.71

>>729
とはまともな会話が成立しそうにないからもういいや。
iOSが保証っていつからiOSが人格持ったのか

iOSがAppleの間違いだったとしてもおかしい。
Appleが動作を保証することもありえない。

**デフォルトの名無しさん** · 2020/12/31(木) 00:54:49.62

mauiとかOS標準の機能使うなら、大抵は各OSの最大公約数みたいな機能にしぼられるから、アプリがしょぼくなるか、
それを超えてやると｢自分のコードが増える｣
例えばOS毎にUI分けるはめになる

**デフォルトの名無しさん** · 2020/12/31(木) 01:05:26.16

例えば、androidでは、メインのスクロールコンテンツにあわせてツールバーが隠れたりするUIがあるが、これを例えば、OSの機能でやるxamarin.formsでは用意されてない？
で、やろうとする｢自分のコードが増える｣

flutter内部でflutter側のコードは増えるが自分のコードは少なくなる

**デフォルトの名無しさん** · 2020/12/31(木) 01:09:12.25

もちろん、iOSで他のOSのUIのお作法押し付けるのどうなのとかの問題あるが(flutterはiOSのデザインのコントロールも用意されてるが)

**デフォルトの名無しさん** · 2020/12/31(木) 07:54:02.92

>>723
描画低レベルAPIってのはskiaのことね。このあたりの仕様や挙動はOSバージョンアップしてもそうそう変わらないので影響を受けにくい。
反対にXamarinとかは各OSのNativeなGUIコンポーネントの上にさらに実行環境を構築してるので比較的影響が出やすい。
例えばNativeボタンデザインが大きく変更されたとするとXamarinは影響あるけどFlutterには影響ない。

**デフォルトの名無しさん** · 2020/12/31(木) 12:40:29.57

Flutterで良いと思ったのは
UIの描画を独自でやってる所だが...

これでかなり面倒な
os毎の画面仕様の調整から解放される。

**デフォルトの名無しさん** · 2020/12/31(木) 12:49:26.94

UI描画を独自でやってるのは割と大きいメリットだよね。
とはいえ各プラットフォームのガイドラインを無視するのか、とか、微妙な部分はあるんだけど。

バージョンアップ時に影響を受けることは、逆に少ないよ。
Androidでは、古い機種でも新しいコントロールの見た目で描画されるぐらいだし。

**デフォルトの名無しさん** · 2020/12/31(木) 12:53:13.22

reactとflutter比べるとflutterの方がUiに関してOS差分気にしなくていいから楽だしな
flutterのアーキは糞だけど現状flutter使うのがベストという悲しい状況

**デフォルトの名無しさん** · 2020/12/31(木) 13:57:40.51

>>739
各プラットフォームのガイドラインを無視する

それが良いんだよ。

**デフォルトの名無しさん** · 2020/12/31(木) 16:36:35.60

Androidのガイドラインは守ってるだろw
iOSはAndroidにUI/UXは2周回遅れにされてるからもう無理だし

**デフォルトの名無しさん** · 2020/12/31(木) 21:00:53.70

androidの方がUIをiOSに似せてきてない？
ナビゲーションドローワからボトムナビゲーションへとか

**デフォルトの名無しさん** · 2021/01/01(金) 03:54:37.10

analysis_options.yamlでcast_nullable_to_non_nullableを指定しても
warning: 'cast_nullable_to_non_nullable' is not a recognized lint rule
って表示されるのはなぜですか？

**デフォルトの名無しさん** · 2021/01/01(金) 16:24:52.42

本来はオリジナルのUIコンポーネントを作るために、
Android/iOSが用意してる方法を使って、
Flutterは独自のUIコンポーネントを作ってるという事？

wikipeによるとDartはTSに敗れた後にFlutter向けに再始動したんだな

**デフォルトの名無しさん** · 2021/01/01(金) 16:32:37.07

Flutterは画面に色々描画できる画面に相当する1枚のCanvasみたいなのがあって、Flutterが自分でボタンならボタンっぽく描画してるってこと。

で、そのCavasみたいのは(skia)のはandroidではopen GLそれともvulkan?、iOSならmetal?みたいのを裏で使ってる

**デフォルトの名無しさん** · 2021/01/01(金) 16:40:28.24

OSは大抵はテキスト入力するコンポーネントやボタンオン/オフするためのコンポーネントなど色々なUIコンポーネントを用意してるが、そのなかに大抵自分で線や矩形などを使って自分で描画できるCanvasみたいなコンポーネント(機能)も用意されてる

FlutterはそのうちのCanvasコンポーネントを使って他のOSが用意してるボタンコンポーネントとか使わずに自前でボタンを描画してるイメージ

**デフォルトの名無しさん** · 2021/01/01(金) 17:39:15.05

>>743
要はスタンプ押すのを用意されたスタンプを使うのか自分で作ったスタンプ押すかの違い。
OSが用意したスタンプ使うとOSの仕様変更でスタンプの見た目変わっちゃって画面に入り切らなくなっちゃうけど、自分の作ったものは変わらず使えるってこと。
ここまで書いてあまり良い例えじゃないと気づいた。

**デフォルトの名無しさん** · 2021/01/01(金) 17:46:12.19

すまんな、アンカミスった。

**デフォルトの名無しさん** · 2021/01/03(日) 13:57:35.22

>>717
まず、_で可視性制御するのどうにかしてほしい
プロパティのprivateなsetterとかどうすりゃ・・
あと、finalフィールドが、initializer listでしか初期化できない・・
コンストラクタ内でfinalフィールド初期化したい

**デフォルトの名無しさん** · 2021/01/03(日) 13:58:39.90

dartはオープンソースだけど
それについてコミュニティーで問題定義しましたか？
どのようなアクションをあなたは起こしましたか？

**デフォルトの名無しさん** · 2021/01/03(日) 14:34:23.29

これもよく議論されるだろうが、
後、isolateもあるがシングルスレッド環境もどうなの・・
flutterはデスクトップも対応する予定だが、C言語ほどやるつもりは毛頭ないが、
結構パフォーマンスなどを気にかけだすと途端にウンコになる
なんにせよ、JavaScriptを引きずりすぎて、色々、制約が

**デフォルトの名無しさん** · 2021/01/03(日) 15:20:53.68

デスクトップアプリ作ったことないけど、そこまで遅くなる印象ないけどね。AOTでもそんなに速くはないなーくらいは思ったけど。

**デフォルトの名無しさん** · 2021/01/03(日) 15:59:19.99

スマホアプリ作りたい初級者はフラッター1択なの？

**デフォルトの名無しさん** · 2021/01/03(日) 16:07:12.40

デスクトップだから遅くなるという意味じゃなく、デスクトップアプリだとマウス入力などでもっと生産系の凝った、複雑なアプリ開発とか視野に入ってくるわけで、
そうすると、マルチスレッドとか基本だけど、isolateだとメモリ空間分離されてるからめんどくさいし

もちろん、今のタッチ入力メインのモバイルアプリでも凝った、複雑なアプリ作れるが

**デフォルトの名無しさん** · 2021/01/03(日) 17:53:55.66

マルチスレッドなGUIフレームワークって世の中にどれだけあるの？

**デフォルトの名無しさん** · 2021/01/03(日) 17:55:15.81

すげーー普通

**デフォルトの名無しさん** · 2021/01/03(日) 18:10:19.83

>>750
privateが_なんて全くなんの問題もない。むしろそれごときに慣れる事ができないなら今後思いやられる。
finalがコンストラクタ～ってのは分からんでもないけどそれならfinal外せ。
StatefulWidgetのfinal制限ならきっと俺には分からない実装上の都合があるんだろう。
詳しい人の解説を待とう。

**デフォルトの名無しさん** · 2021/01/03(日) 18:11:12.37

普通か？
UIスレッドが複数のGUIフレームワークってなんだろ。

あと、極力、スレッド間でメモリ空間を共有しないのが最近の王道では？
isolateに振ったのは悪くない方法だと思う。

**デフォルトの名無しさん** · 2021/01/03(日) 18:12:08.79

>>744
インデントとか？

**デフォルトの名無しさん** · 2021/01/03(日) 18:14:51.43

>>759
どうせThreadレベルじゃプリエンプトされないから
MainThread.asyncで十分だよ

**デフォルトの名無しさん** · 2021/01/03(日) 18:20:09.59

>>761
スレッドでも普通にTTSでプリエンプトされると思ってたんだけど最近は違うのかい？

**デフォルトの名無しさん** · 2021/01/03(日) 18:33:08.94

>>754
ろくにプログラミング経験ないなら、
Kotlin + Android Studio
Swift + XCode
の純正で最初にある程度経験積むほうがいい。
最初からクロスプラットフォームの開発は初心者向けじゃない

**デフォルトの名無しさん** · 2021/01/03(日) 18:40:50.09

>>752
なんだDartってマルチスレッド対応してないのかよ
Dartが洗練されてるとかいってた話うそじゃないかよｗ
時間かかる処理はどうやってるの？

C#使えるUnity, Xamarin, MAUIのが長い目で見るといいんじゃないか?
あとはKotlin Multiplatform

FlutterはUIの部品はいいけど、Dart言語がいまいちってかんじかね

**デフォルトの名無しさん** · 2021/01/03(日) 18:46:38.13

なんか話が途中からずれてるな・・
俺がいったのはあくまでUIスレッドは一つだぞ・・
>>759でUIスレッドが複数になってるけど
>>756もUIスレッドが複数の意味なのかもしれんが・・

>>764
一応、ワーカースレッドのisolateってはあるが、メモリ空間が別なので
データやり取りするのがちょっと難儀がある

**デフォルトの名無しさん** · 2021/01/03(日) 18:49:39.97

flutterのUIが豊富ってだけで仕組みは死ぬほど糞だけどな
少し大規模開発になると縦横無尽にblocやらproviderだらけになってレンダリング系の問題とか出てくると手に負えなくなる

**デフォルトの名無しさん** · 2021/01/03(日) 18:50:29.08

>>764
そうだよ
dartってゴミクズよ

**デフォルトの名無しさん** · 2021/01/03(日) 19:19:11.19

他にも整数型がintしかない問題
1バイトや2バイトなどしか使わなくても8バイトのint使うと無駄多すぎ
デスクトップアプリでメモリ一杯あるし勝手にキルされないから、どんどんオブジェクトを
ため込んでいくと無駄も結構大きくなる

メモリ絡みで弱参照もないし・・

もちろん、普段はHttpたたいて結果を表示するレベルのモバイルアプリがメインだからこんなことは
全く気にしてないけど

でも、どんどん規模が大きくなるとdartはうまくスケールしない・・と思う

**デフォルトの名無しさん** · 2021/01/03(日) 20:09:38.68

>>766
まぁいくらproviderが極少化できるとは言ってもそれを最初から設計することは困難なのでとりま全Widgetツリー更新で実装してしまって、リファクタは影響が計り知れないのでそのままにしちゃう。
ステートのライフサイクルとの兼ね合いとかわけわからんくなって誰も触れないコードの出来上がり。
理想と現実は違うよね。

**デフォルトの名無しさん** · 2021/01/03(日) 20:24:11.69

クソSwift+Rxより未来あるけどなwww

**デフォルトの名無しさん** · 2021/01/03(日) 20:35:56.13

>>768
intしかないメリットも大きい。
機器からのbyte列をUint8Listに変換すると無駄に思えるが普通はそこからModelクラスに格納するのでローカル変数でしかない、激速で処理して解放するメリットのほうが大きいw

**デフォルトの名無しさん** · 2021/01/03(日) 20:49:35.48

>>768
intに関しては今どきbyteだからと言って本当にRAMを8bitしか消費する事はないし、もしあったとしてもとっても無駄が多い。
CPUのアドレスバス幅考えればすぐに分かる事。

**デフォルトの名無しさん** · 2021/01/03(日) 21:04:35.84

swiftの方が100倍いい

**デフォルトの名無しさん** · 2021/01/03(日) 21:05:47.37

>>765
俺がいったのはって書いてあるけどいつ言ったの？

**デフォルトの名無しさん** · 2021/01/03(日) 21:14:09.29

>>774
君だれ？

>>772
ああ、そうだね。alignmentやpackingを指定できる言語もあるけど、たいていは特定のalignmentに調整されたね
そこは浅はかだった

**デフォルトの名無しさん** · 2021/01/03(日) 21:19:13.11

ああ、後出しで訂正したんだね

**デフォルトの名無しさん** · 2021/01/03(日) 22:25:59.82

>>765
なるほど
UIで多少楽できても
Dartのせいでビジネスロジックで苦労するわけか。
マルチスレッドないと微妙だな

やはりゲームまでつくれてC#も使えるUnity最強説

**デフォルトの名無しさん** · 2021/01/03(日) 22:35:07.72

Flutterなどのクロスプラットフォームを使わない場合に
モバイルアプリ開発で、
UI関連コードとビジネスロジックのコードの開発にかかる時間の
割合はどれくらいだろう？
20% + 80%?
30% + 70%?

直観でビジネスロジックで70%超える気がするんだけどそうだとすると
DartがクソなFlutter使うよりも、言語が優秀なC#系やKotlin系の
ツール使うほうが効率いいんじゃないのか？

**デフォルトの名無しさん** · 2021/01/03(日) 22:37:32.35

778 の
言語が優秀なC#系やKotlin系のクロスプラットフォーム対応ツールとは
具体的にUnityとかKotlin Multiplatformとか。
Xamarin, MAUI

**デフォルトの名無しさん** · 2021/01/03(日) 23:10:45.11

つか、しぼらなきゃいけないの？w
まあ、オールラウンダーがあればそれ一つやるに越した事はないが
俺はwin32ネイティブ,WPF,UWPやらandroid java/kotlinで今はflutterだけど、アプリの種類に応じて一番楽なの選ぶだけだし

xamarinはないがmauiは出てきてから評価しないとなんとも言えんし

**デフォルトの名無しさん** · 2021/01/03(日) 23:11:12.55

マルチスレッドだとイイって
思い込んでる低脳かな？

Viewを担当する部位に
マルチスレッドいらんだろ。

Asyncで十分

笑

**デフォルトの名無しさん** · 2021/01/03(日) 23:22:43.49

後、ビジネスロジックってビジネス次第だがhttp叩いて表示するくらいならどの言語でも基本はそこまで苦痛にならん

それよりもUI絡みのコードは、例えば独自ビューを作ったりするとそのUIフレームワークについて詳しく知る必要があるから自分では相当苦痛

だから、基本、言語がいくら糞でもUIフレームワークが充実してる方を選ぶかな。ということで、flutterは品質いいから普通に使うけど

**デフォルトの名無しさん** · 2021/01/03(日) 23:36:27.40

RxとかMVVMとかユーザーメリット皆無だからな。
オナニーしてないでとっととプロトタイプ作れよ by 客

**デフォルトの名無しさん** · 2021/01/03(日) 23:45:07.82

いつまでクラサバやってんのか！
って感じのがマジ多い。

ロジックはサービス側で完結してくれ。

>>783
RxはUI側で有効に使えますよ。

**デフォルトの名無しさん** · 2021/01/03(日) 23:50:16.03

>>784
もうそんな時代じゃないと思うんだよね。
表示系はrebuild、入力系はForms。
streamSubscriptionとかはRxを隠蔽して分かりやすく使う。

**デフォルトの名無しさん** · 2021/01/03(日) 23:57:22.04

ビジネスロジックは要件。
UIは偉い人の好みでさらに偉い人の好み←ここが難題w

**デフォルトの名無しさん** · 2021/01/04(月) 00:02:50.73

UIは速攻で作って
技術ものとも使い捨てですよ。

使い捨てできなそうな実装は、
コードも読みづらいし、
View側のコードにロジックがてんこ盛り...

**デフォルトの名無しさん** · 2021/01/04(月) 10:04:58.27

>>783
確かにMVVMはViewをわざわざXMLとかの別言語で書く意味がわからん。ある意味強制的な分離にはなるんだろうけどアーキ設計者の自己満足としか思えん。

**デフォルトの名無しさん** · 2021/01/04(月) 10:18:46.78

>>784
web appsも
web api使ったmobile appsも
client-serverだろう

**デフォルトの名無しさん** · 2021/01/04(月) 10:22:38.76

>>778の
ビジネスロジックの意味誤解されてるけど
UIに関連しないコードはビジネスロジックと思っていい。
日本語の「ビジネス」とは関係ない。
要件とも関係がない>>786

**デフォルトの名無しさん** · 2021/01/04(月) 10:33:16.46

>>780
SwiftとばしてDartにいったのか。
Swift, Kotlin, C#の純正の開発も
Web APIやらDBのも継続的に学習必要だから、
cross-platformだけで何種類も追いかけてられないわ

アプリの種類に応じて使い分けることなく開発できるツールを
なるべく選びたいだろう
学習はするが楽はしたい。つまり効率

**デフォルトの名無しさん** · 2021/01/09(土) 20:58:24.77

Swiftはうんこ💩だよ

**デフォルトの名無しさん** · 2021/01/09(土) 21:10:39.50

>>792
swiftがdartより劣ることはないだろう。

**デフォルトの名無しさん** · 2021/01/10(日) 00:00:05.06

dartは何も決めなさすぎでウンコだろ
もうちょっと標準パッケージを充実させろよ
今は非同期のキャンセル処理を自分で適当なクラス作ってやるか..
kotlinなら一番豊富でJobやらDispatcherやらややこしい
C#だと、CancellationTokenがある
Dartも適当なの用意しとけよ

**デフォルトの名無しさん** · 2021/01/10(日) 01:03:30.16

>>794
subscribe.cancel()じゃあかんの？

**デフォルトの名無しさん** · 2021/01/10(日) 01:04:40.92

SwiftはUIKitから逃れられないから、いつか消えて無くなるだろう。。

**デフォルトの名無しさん** · 2021/01/10(日) 01:27:39.96

Stream使ってない部分では使えないよね?