Flutterやろうよ！！！ 3

2021/08/08(日) 20:18:12.79

!extend:on:vvvvv:1000:512
!extend:on:vvvvv:1000:512

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

https://flutter.dev/

前スレ
Flutterやろうよ！！！ 2
https://mevius.5ch.net/test/read.cgi/tech/1611976959/

VIPQ2_EXTDAT: default:vvvvv:1000:512:: EXT was configured

2021/10/24(日) 19:22:37.14

kotlinだったらどれほど良かったか…
Dart好きだけどね
入り口が狭くなってるよね・・・

2021/10/24(日) 19:23:27.89

>>449
ページ単位だからReact Routerみたいな使い方は無理

2021/10/24(日) 20:10:01.98

それは惜しいな。

2021/10/24(日) 22:51:08.37

パッケージ使え
go_router

getは糞

2021/10/25(月) 11:38:31.99

go_routerありだね。ぱっと見、求めてるもの全部入ってる気がする。

2021/10/25(月) 11:54:28.36

どんなアプリでも使う超基本機能なんでjsみたいにいろんなライブラリが群雄割拠するのはやだなあ

2021/10/25(月) 13:02:15.86

それはすごくわかる。あと、go_routerの弱点があるとしたら、
同じurl内のナビゲーションができなさそう？
RouteInformationのstateが使えなさそう。

2021/10/26(火) 23:21:46.75

質問なんだけど
iOS向けにリリースするときXcodeは不用？

2021/10/27(水) 06:54:39.51

>>457
ローカルビルドするなら必要。

2021/10/27(水) 09:12:51.75

ありがと
やっぱXcode要るんか
flutterにしたらでかいアプデ避けられるかな？って考えまして、、、

2021/10/27(水) 09:57:16.24

Windowsとか実質10で終わりなんだからMac買えば？

2021/10/27(水) 13:25:05.19

Mac は、CPU がM1 に変わったから、

Docker など、Linux との互換性が問題

2021/10/27(水) 15:06:54.05

まーこなれたARMベースだから問題ないでしょ

2021/10/27(水) 21:40:44.91

> Windowsとか実質10で終わりなんだからMac買えば？

iOSアプリ開発以外じゃもうMacいらね
って人が増えてきてるのにズレまくってるね

それにDockerはARMのイメージ少なすぎてつらいぞ

2021/10/27(水) 23:32:58.74

>>463
ズレてるのはおまえ

2021/10/27(水) 23:55:39.92

林檎のう○こな面がどんどん出てきてる昨今
それでも信者は信者のままだから温かい目で見てあげようよ
画面できずにクスクス笑っちゃうけど

2021/10/28(木) 00:46:50.59

Windows がなくなることはないよ
それなりの規模の企業には必要だからね

Macは、iOSアプリ開発者には支給するけど、それ以外の需要は小さい
クライアントは Flutter でサーバーは FreeBSD とかってないだろw

2021/10/28(木) 10:51:14.20

iPhone売れなくなって来たら、Macも風前の灯火になるの避けられんからなぁ。
iPhone死ぬほど売れてなおも、Macは今のシェアしかねんだしお察し。

2021/10/28(木) 12:26:36.34

PCにまでノッチつけてるだけでも正気に思えないのに
メニュー表示がノッチを避けるようになってないなんて本当にどうしたんだ笑
https://twitter.com/SnazzyQ/status/1453143510111059968
https://twitter.com/5chan_nel (5ch newer account)

2021/10/28(木) 12:48:03.30

ここFlutterスレなのわかるかな？むずかしいかな？

2021/10/28(木) 19:15:31.00

ちょっとむずかしい

**デフォルトの名無しさん** (ｽﾌｯ Sda2-hPeM) · 2021/10/28(木) 19:51:42.22

>>467
〇〇売れなくなってきたら、

Appleに限らずそんなこと言ったら何でもそうですやん笑

2021/10/28(木) 22:15:24.00

FlutterでHuaweiのアプリも開発可能ならしい

2021/10/29(金) 00:37:14.30

>>468
アップルの技術力舐めてるの？修正なんて一瞬だよ
https://www.theverge.com/2021/10/28/22750236/apple-macbook-pro-hide-notch-fix-scale-to-fit

2021/10/29(金) 04:06:49.41

アプリ単位でしか解決できないって・・・

ノッチを付けたのはベゼルを小さくするためじゃないの？
それなのにノッチを避ける設定でベゼルが太いのと同じことになるのは
アメリカンジョークですか？笑

2021/10/29(金) 05:35:58.76

Windowsはサービス設定系がガチで使いにくいからなぁー

2021/10/29(金) 06:34:36.32

>>473
マジで笑えるなw

2021/10/29(金) 12:33:39.26

スレチすぎる

2021/10/29(金) 21:25:07.06

将来的に、アプリを多言語対応したくなった時は、このアプリを使うといいかも

flutter_sheet_localization

2021/10/29(金) 21:25:41.24

リンク貼り忘れた
https://github.com/aloisdeniel/flutter_sheet_localization

2021/10/30(土) 01:17:52.19

void main() {
var m = {
'n': [1,2,3],
};
print(m['n'].length);
print(m['n'][0]);
}

これが実行できないのですがどう書けば良いのでしょうか

2021/10/30(土) 01:47:46.62

final n = m['n'];
if (n != null) {
print(n.length);
print(n[0]);
}

安全のためにmの型指定もしたほうがいい

final Map<String, List<int>> m = {'n': [1,2,3]};
か
final m = <String, List<int>>{'n': [1,2,3]};

2021/10/30(土) 03:27:22.13

こう書いた方がdart的だと思う

print(m['n']?.length);
print(m['n']?[0]);

2021/10/30(土) 03:38:50.80

481, 482 の両方とも、エラーメッセージで教えてくれるよね

2021/10/30(土) 08:23:21.35

辞書型の値は、nullセーフの型しか指定できないのかな

2021/10/30(土) 09:09:25.98

>>482
どっちがdart的ってものじゃない
ifで確認したらその後もうnullじゃないことになるのもdart的

2021/11/01(月) 14:03:12.80

最近Riverpodのことを聞かれて調べてるんだが知れば知るほど価値を感じなくなってる
一つのことをやるにも幾つもの方法があってまあAPIが酷いこと
Remiちゃんはそういうとこ下手だね

相談してきた人がちゃんと使えてる気がしなくて見せてもらったら案の定酷かったんだがどこの会社でも起こってそうだ
あんなものをなんでみんな選んでんだ？
Providerの人が作ったんだから間違いないとか思わずに自分で判断した方がいいよ
同調圧力みたいのを感じてる人が多いのか？いかにも日本人でもうね・・・
ちらほら見かける少数のアンチの人だけがまともに見える

2021/11/01(月) 14:35:42.64

>>486
ツリー構造がめちゃくちゃになるのと、実行時にしか確認できないProvider ProviderNotFound例外がProviderの欠点なんだから、これを回避するだけに使えばいい
色んなことしようとするから複雑になる

2021/11/01(月) 14:50:12.91

それでいいはずなのにみんなあれこれ使って必要以上に小難しくするじゃん
それができちゃうパッケージがもう失敗なんだよな

Providerを組み合わせたりフィルタリングするためにProvider自体にロジックが入り込むのもよくないな
それをドキュメントでやっちゃってるからなー

2021/11/01(月) 14:55:01.53

ProviderNotFoundが嫌ならInheritedWidget使わないでStreamBuilderかValueListenableBuilder使えばいいだけなんだがな
小さい悩みを解決するために過剰な方法を持ち込まなくていいんだよ

2021/11/01(月) 15:21:40.70

>>489
じゃあそれらを使えばいい
そのstreamやlistenableをどう伝播させるかとかが今度は問題になってくる。そうならないサイズ感で使ってしまうのは確かにナンセンスだが、使用者の問題だ
多様なことができるものが失敗と言うのは難しいよ
それを言うならオブジェクト指向も失敗だ

2021/11/01(月) 17:18:41.77

状態管理パッケージは実際いらないと思ってる。こういうこというと
いろいろいわれそうで怖いけど、
InheritedWidget、InheritedNotifier、ValueListenableBuilderとか、
なんとかBuilderをうまく使いこなすだけでなんとかならね？

2021/11/01(月) 17:59:37.52

>>490
Riverpodは色々自由すぎて好ましくない使い方ができてしまうことやAPIが良くないことがよく批判されるポイントになってるのにそこを失敗と言うのがなんで間違ってるのか

失敗じゃなくて使用者の問題だっていう白か黒かみたいな二択じゃないよ
使用者の問題だしそれが起こりやすいのはパッケージの問題でもある

2021/11/01(月) 18:02:39.26

あれこれいらないから小さく作ってくれればよかった
惜しいんだよな
Providerもあれこれ多いから作者の性格だろうな
食べ放題のビュッフェで欲張って取りすぎるみたいにせっかくだからあれもこれもってね

**デフォルトの名無しさん** (ｽﾌｯ Sd33-OsY6) · 2021/11/01(月) 19:14:22.73

>>493
必要だと思う人が使うので、そう思わない人は無視しとけば良いよ。

2021/11/01(月) 19:23:02.03

>>491
ValueListenableBuilderとか実は有能・万能

2021/11/01(月) 19:38:41.96

＞必要だと思う人が使うので

あれは必要なものじゃないねえ
ないと作れない人は基礎から勉強したほうがよろしい

必要かどうかじゃなくて使いたいかどうかならわかるけど
使いたい理由が最先端っぽいところに追いついておきたいだけの人が多そう
使えば最先端ってもんでもないのに、だれか書いてたように同調なのかな

2021/11/01(月) 19:39:07.95

シンプルなの誰か作って！

2021/11/01(月) 19:41:00.43

>>492
パッケージは汎用的に作るものだから仕方ないね
もちろん状態管理パッケージはなくてもなんとかなるが、ProviderがInheritedWidgetを包んで使いやすくしたという経緯から見えるように、生のままだと使いにくいんよ
使わないで済むならその方がいいけど、規模感や設計次第じゃないか？

2021/11/01(月) 19:56:54.95

>>494
個人で楽しんでるだけの人なら無視すればいいよな
仕事でそうはいかん
別の人がRiverpod使って書いた醜いコードが自分に回ってきたら辞めたくなるぞ

**デフォルトの名無しさん** (ｽﾌｯ Sd33-OsY6) · 2021/11/01(月) 22:38:17.33

>>499
醜いコードが自分に回ってきたら悲しいですが、それはproviderでも blocでも同じでは？

2021/11/01(月) 22:51:46.77

読んでもらったらわかるけどRiverpodだと起こりやすいって話をしてたんだよ
Hooks使うともっとね

2021/11/02(火) 02:17:40.01

そもそも醜いの定義次第でどうにでもなるから、Riverpodで起こりやすいというのも何とも言いようがない。

2021/11/02(火) 10:25:58.81

どうにでもなるってどういうこと？
定義次第で解決できるってこと？

どんな醜いコードになるかはここまでに書いたことを読んでもらったら経験者ならイメージできると思う

**デフォルトの名無しさん** (ｽﾌｯ Sd33-1NYT) · 2021/11/02(火) 13:16:45.40

>>503
ここまでで具体的な定義一つもないし、Riverpod
が自由すぎるというのもここ以外で聞いた事がない。
結局醜いとしか言わないし笑
あなたの親友とかじゃないんで、あなたの醜いの定義なんかわかるわけ無いです笑
blocでさえ利点をわかってなければとりあえずblocぽく書いてるが分離しきれてない、みたいなのはあるので結局使う側次第。

2021/11/02(火) 14:05:28.20

俺が思うに
好きな物使えば良いんじゃないかな

2021/11/02(火) 14:53:33.35

>>504
よく言われてるじゃん
国内の絶賛する意見だけ選んで見てる人にはわからんかな

>>505
個人開発前提で言わんでくれ

2021/11/02(火) 14:58:59.45

>>506
他者が決めたものに従わなければいけないのならそれに従うべきだし
従わなくていいのなら好きな物使えばいい

そういう仕事してお金もらってるんでしょ？
こんなとこで文句タラタラ言う事ではない

2021/11/02(火) 15:12:16.66

jQuery使う仕事を振られてもやるけど使わないように世の中の人々に促して根絶したいだろ？
IEのサポートを切るように促したかっただろ？
jQueryで誰かが書いた醜くて酷いコードを渡されたら辛いだろ？
そういうのと同じだよ
仕事しないとは言ってない

2021/11/02(火) 15:24:55.74

そんな個人的な要望を他者に求められても困る
それはあなたが抱えている問題だし
他者に押し付けるものではない
誰が何を使おうと自由

ここで文句を言う前に
選定できる立場に成る様に努力するべきでは？

2021/11/02(火) 15:30:05.53

世の中に促す…？

2021/11/02(火) 15:37:34.53

過大評価されてるよねRiverpod
デメリットを伏せてメリットばかり喧伝されてる感
使う必要性はないのに、藁にすがる感じで使う人が多いのかな

新しいのが出るたびに飛びついて先端走ってるつもりになるところが
かっこつけ君の多いフロントエンドだなと感じる

2021/11/02(火) 15:46:11.53

>>509
立場的にはすでにそうなんだけどあちこちに応援で呼ばれるもんでね
自分の管轄下ならもちろん主導して選定するよ

一度も押し付けてないよな？

**デフォルトの名無しさん** (ｽﾌｯ Sd33-1NYT) · 2021/11/02(火) 17:46:09.44

>>506
いや誰なのあなた？
なぜあなたが

よく言われてるじゃん

とだけ言って私が

あ、そうですよね。

てなると思うの？
具体的にどこで言われてるの？

2021/11/02(火) 18:43:06.14

匿名の掲示板で誰なのと聞かれて答えるわけないじゃん面白いな
答えたところでどうせ知らんだろ

Redditとかコミュニティのチャットとか見てたら見てるはずだ
自分で情報収集せずにお前が出せというくれくれ君と話しても不毛だ
それになんでそんなに喧嘩腰なのかわからんな

**デフォルトの名無しさん** (ｽﾌｯ Sd33-1NYT) · 2021/11/02(火) 19:14:35.34

よく言われてて見てるはずなら言い出した本人含め誰かから具体的なソースの一つくらい挙がっても良さそうなもんだが。
くれくれ君て相手が言い出してるんだろうが、ほんとしょうもないな笑

2021/11/02(火) 19:31:24.40

夏はレジャーを楽しめていい
でも暑くて汗かいてつらいし、夏バテになって困る

みたいな意見に対して

個人的な考えを押し付けるな
汗かかないように努力しろ
誰が言ってるんだ、ソース出せ

て感じ？

2021/11/02(火) 19:36:51.80

否定的な考えの人がいてもいいじゃない
合わない意見は叩かないと気が済まないのかなあ
このスレにかぎらず社会全体がなんでも叩く風潮になってて嫌だねえ

2021/11/02(火) 19:42:17.65

アフィ野郎がわざと煽って情報引き出そうとする奴もいるからなー

**デフォルトの名無しさん** (ｽﾌｯ Sd33-1NYT) · 2021/11/02(火) 19:50:16.66

読めばわかるのでお読みください。
あなたがそう読み取ったならそれでいいと思いますよ。
わたしには何の関係もないですし。

2021/11/02(火) 20:15:11.49

https://www.reddit.com/r/FlutterDev/comments/lkznih/devs_using_riverpod_what_do_you_think_are_the
ここの翻訳コピペしてるだけだな
redditに問題の具体例まで書いてる奴居ないから
詳細聞かれても回答できないんだろw

2021/11/02(火) 21:04:50.35

https://www.reddit.com/r/FlutterDev/comments/pjj40p/riverpod_vs_bloc/

> Even though I could accomplish everything I wanted, it ended becoming messy with dependencies spread throughout the code. I don't know how many providers would I be able to manage at the same time before my head blows up and most of the providers don't make any sense on other screens so it gets messier to locate the ones you are looking for when names are similar.

> FutureProvider which worked fine for simple examples to a StreamProvider. But I need to keep track of those loaded which were previously loaded so I could keep adding when scrolling. So I had to move to a StateNotifierProvider with all the data or keep several providers very closely coupled so when the stream loads data it loads it into another provider. In the end, the complexity of using Bloc or Riverpod ended quite similar. But with Bloc I would have been able to extend functionality without refactoring so much.

https://www.reddit.com/r/FlutterDev/comments/kyd7zs/riverpod_a_better_state_management_solution_than/

> Not personally a fan of riverpod as I feel it encourages a bad antipattern of scattering shared state all throughout your widget tree. This can lead to code being very hard to find (non-centralized), and makes debugging harder to follow as there are excessive dependency chains and couplings between providers.

> the 'compile safety' of Riverpod, allows developers to safely do something that really is not a good thing to do when it comes to maintenance and debugging.

検索してランダムに選んだページだけでもこういう投稿があった
ネガティブな感想もやっぱりそれなりにあるってことかな
ここと違って人格否定とかされることはなく健全に意見を出し合ってていいな
異なる考えを示した人を異端扱いして叩いてたら偏るんだよなー

**デフォルトの名無しさん** (ｽﾌｯ Sd33-1NYT) · 2021/11/02(火) 21:15:18.90

そもそもここで自分で言い出して具体例を聞かれたら自分で調べろ、て

誰得なんだ？笑
何がしたいんだ？

という当然の疑問を尋ねたら今度は人格否定笑

**デフォルトの名無しさん** (ｽﾌｯ Sd33-1NYT) · 2021/11/02(火) 21:46:01.37

>>521
あなたがいくらググった結果を載せてもそれは結局あなたの示した結果でしかなく、言い出しっぺの人がどういう意図で自由すぎると言ってたのかはどれだけググったところではっきりしない。
そんなものを私が探して推測する義務は無い。

2021/11/02(火) 22:14:43.25

人格否定はあなたのことじゃなくてここの掲示板の全般的なこととして書いたのだよ
自分のことと勘違いしたのは自覚があるから？

ウェブ検索結果を書いたのもあなたのためじゃなくて
興味が出てきて調べて見つけて納得したから貼っただけ
言い出しっぺがそれを指して言ったかなんて自分にはどうでもよいので
そこに執拗にこだわるあなたを見て、この人何と戦ってるの？と思ってしまった

2021/11/02(火) 22:57:43.46

qiitaのadvent calendarのflutter 2.7.0(仮)について書きますって
次のリリースなにくるんだよ

2021/11/02(火) 23:04:11.01

今年は言語側でnull safetyあったがflutter側おとなしいよな
navigator 2.0やrestoration とかも今年だっけか?
次のリリースでwindowsとか正式対応になるのかな..
materia you対応はどこいった?

**デフォルトの名無しさん** (ｽﾌｯ Sd33-1NYT) · 2021/11/02(火) 23:11:54.70

>>524
少なくともflutterの議論に特にこだわりの無いあなたたちでは無いですよね。

立派な最後っ屁だけは多くの人を笑わせるので良いと思いますよ笑

2021/11/02(火) 23:40:06.13

>>526
material youはflutter2.5で対応済み

2021/11/04(木) 01:05:35.85

https://pub.dev/packages/hooks_riverpod/example

このサンプルのreturn Scaffold(が実行される前に
increment()を実行したいのですが

final count = useProvider(counterProvider);
context.read(counterProvider.notifier).increment();
return Scaffold(
と書いたら大量のエラーが発生しました
どうやればウィジェットをreturnする前にincrement()を実行できますか？

E/flutter (23139): [ERROR:flutter/lib/ui/ui_dart_state.cc(209)] Unhandled Exception: setState() or markNeedsBuild() called during build.
E/flutter (23139): This UncontrolledProviderScope widget cannot be marked as needing to build because the framework is already in the process of building widgets. A widget can be marked as needing to be built during the build phase only if one of its ancestors is currently building. This exception is allowed because the framework builds parent widgets before children, which means a dirty descendant will always be built. Otherwise, the framework might not visit this widget during this build phase.
E/flutter (23139): The widget on which setState() or markNeedsBuild() was called was:

2021/11/04(木) 01:16:09.49

エラーメッセージのとおり

**デフォルトの名無しさん** (ｽﾌｯ Sd33-1NYT) · 2021/11/04(木) 11:24:29.07

>>530
このエラーメッセージ理解できる人はここで質問しないだろうけどな。

2021/11/04(木) 12:41:44.25

GetXわかりやすくていいじゃん

2021/11/04(木) 15:29:02.04

>>529
useProvider(counterProvider.notifier).increment();

にするとうまくいくと思う

2021/11/05(金) 11:12:18.64

>>532
必要なコード数が他のライブラリより断然少なくて済むんだよな
そりゃ人気出るわ

2021/11/06(土) 19:21:10.23

GetXは作者のよくない行いによって完全にスルー対象になってるよ
知らない新参者や気にしない人が使ってるみたい

自分は最近知ったけど、それより前からフレームワークっぽい全部入りがイヤで使ってない

どっちも解決することはないから今後も変わらないよ

コミュニティーのメジャーなメンバーに嫌われてる状況は
大物に干されてテレビから消えた芸人がYoutubeで客層変えてやってるのに近い

2021/11/06(土) 19:25:20.52

RiverPodはシンプルなProviderの位置に取って代わることはないと
Googleの人が言ってるから第一の推奨はProviderのまま

2021/11/06(土) 22:28:52.01

状態管理ライブラリのLike数ランキング
getXが一位だね
https://twitter.com/rydmike/status/1454040986590535687
https://twitter.com/5chan_nel (5ch newer account)

2021/11/06(土) 22:57:57.61

>>535
良くない行いってなんだよw
身内で揉めてんじゃねー

2021/11/07(日) 11:17:08.25

個人開発だとriverpodの方がコードをシンプルに書けて使いやすいけど
チーム開発だと自由度が高すぎてデザインを壊しそう

2021/11/07(日) 18:27:02.48

画面遷移で引数渡すためにこんなことしないといけないの？
なんか汚いコードに見える
https://zenn.dev/sgr_ksmt/scraps/f2437c38594ba1#comment-282f014392399a

> ProviderScopeを使えば、引数が必要なProviderでもFamilyを使わず、引数を子Widgetにバケツリレーしなくてもよくなるので、場所によってはこのアプローチを考えても良いかなと思う。

汚いコードになるよりバケツリレーの方がいいんでないの？
どうなのかしら
RiverPodの良さがいまいち分かってないけど、こういうのを見ると不安になるな

2021/11/07(日) 18:35:03.00

スクラップ見るとウィジェットのツリーっぽくない書き方になっちゃってるね
Flutterは宣言的なのがいいはずなのに、RiverPodだと手続き的な書き方になっちゃう？
なんか抵抗感があるっていうかセンス合わない感があるんだけど、みんなそのへん抵抗ないのかな

>>539のデザイン壊すっていうのはめっちゃありそな気がする

2021/11/07(日) 19:45:28.90

>>540
流石にこねくり回し過ぎだな

画面遷移用のProvider一個用意すればやってること変わらん

2021/11/07(日) 20:34:42.24

状態管理のクラスを細かい粒度でやるから、バケツリレーするのが大変になるのであって、大きな粒度でやればバケツリレー上等

2021/11/10(水) 02:06:57.54

>>531
初心者の頃これよく出したなw

2021/11/10(水) 09:00:41.50

>>158
地雷が多い

2021/11/11(木) 10:27:39.83

>>540
めんどくさそう・・・

2021/11/11(木) 18:57:08.00

>>542-543
二人は同じこと指してるのかな
その具体的な書き方がわからないけど、とりあえずありがとう

2021/11/11(木) 19:01:02.25

>>546
でしょ？
余計にめんどくない？使う意味あるん？ておもた

2021/11/11(木) 23:07:22.97

Riverpodなんて使うから面倒なことになる

2021/11/11(木) 23:38:19.82

>>547
Riverpod1.0.0からはScopedProvuderじゃなくてもoverrideできるようになったし、あんまりややこしいことしなくても　選択したデータを保存する用のProvider（記事でいうとselectedAirticleProviderみたいな）を作ればそれをDetail画面から参照するようにすればいい