Flutterやろうよ！！！ 3
レス数が950を超えています。1000を超えると書き込みができなくなります。
!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 awaitで対応できないなら、
『非同期処理』と『チェーン』でググればいいと思う
Future.then()でも対応できないなら、Future.wait()で対応すればいい >>851
ありがとうございます。futureの使い方もう一度勉強しなおしてみます。
情報が少なく申し訳ありません。実際にやりたいことは
親widgetがapiで取得した値を２つの子widgetに引き継ぎ、子widgetがそれぞれ引き継いだ値を引数にapiを呼び出して取得した値を表示する。
といったことをやりたいと考えています。 もし誰かわかったら教えてほしいのですが
showModalBottomSheet で表示させたモーダル上のテキストの内容を更新して、
再描写したいのですが、
Riverpodを使っているため、
ベースとなっている画面がStatefulWidgetじゃなくてConsumerWidgetになっていて、setStateが使えません
こういうときってどうすればいいですかね
やりたいことはGoogleカレンダみたいな画面をつくることで、
メインの画面でカレンダを表示させて、
カレンダのどこかをタップしたら、下からモーダルが出てきて、
そこで日付とかイベントのタイトルを編集し、
確定することでDBに書き込みにいくみたいなことをしたいです >>853
そこで困るならRiverpodを使わずにStatefullWidgetにすりゃいいと思うが
モーダル上のテキストをProvider（多分StateProviderかStateNotifierProvider）をwatchして取得すれば、そのproviderのstateが変わったタイミングでモーダルも更新される 目的がスキル向上ならばriverpodを使い続けてもいいけど、
そうでないなら使用をやめた方がいい ConsumerStatefulWidget使えばいいよ ConsumerStatefulWidgetは使いどころがあんまりない印象
前に設計段階で、カスタムWidgetのようなUI寄りの状態管理をsetStateにまかせて、その他の状態管理をProviderで行う
みたいな使い分けをしようと考えたことがあるけど
実装をはじめてみると、UI寄りの状態管理もProviderでないとうまく書けないところが出てきて、
最初に決めたルールがぼやけてしまった >>842
いや、あなたがより良い/汚くないと考えている方法を聞いてるんでしょ。
それはあなたに聞かないとわかるわけないじゃん笑 いろいろアドバイスありがとうございます
対応は迷いますね
ただずっとRiverpodを使う前提できてしまったので、ConsumerStatefulWidget使うかなあと思いますが
いろいろ試してみます >>860
と底辺さんが申しております。
パッケージ使わずに何作るの。
使うけど振り回されてはいない、みたいなことか？
どうでもいいよ誰やねん！ 流石にその自演は本人以外にはモロバレなので自重した方がいいよ >>859
ConsumerStatefulWidgetは想定通りに動いてくれないことが多いから触りたくない
まじで振り回される
……とだけ忠告しておく dartってC++に近いよな
C#JavaJavascriptなんかより 色んな言語の要素を取り入れようとしたけど挫折してとりあえずJSのアンチテーゼとして型安全な静的型付けにしたってだけのかなり中途半端な言語ってイメージしかない
C++の上っ面だけをベースに開発してる癖にJavaの冗長性を随所に盛り込んだがコーディングがクソだるい言語仕様
C#をパクるかC#を採用すればいいのにGoogleお得意の模倣したりパクったけど劣化コピーになっちゃったテヘペロって言語
とにかく異常に冗長でわかり辛いキーワードや構文で書き辛く型を強制しただけのガバガバなスコープでNamespaceもないとかDart設計アーキテクトはまったくセンスを感じないしセンスないわ 私はDartは好きな言語だからFlutterも楽しい Dart :
import ‘hoge¥b.dart’;
import ‘hoge¥c.dart’;
class A extends B implements C {
@override
bool execute(){
return true;
}
と
C# :
using B;
using C;
Class A : B, C {
public override bool Execute() => true;
これだけ見ても如何にC#が簡潔かつ読みやすく書きやすいかわかるよな
なぜJavaみたいな冗長な言語仕様に寄せるのかと言えばAndroidがJavaだからという完全なるGoogleの都合だからな なぜわざわざ新言語を作ったのかねぇ
.NET MAUI がちゃんと実装されてちゃんと動けば、flutterは誰も使わなくなるよ
flutterって、あのGoogleオレオレ言語のやつでしょ？ってなる まぁみんな考えることは同じなわけでFlutnetというXamarinでFlutter開発ができるものがあるが結局ラッパーだからバージョンアップが遅れるし何より有料だからな mauiよりkotlinのcomposeの方が有力じゃね? まぁ、現状iOS向けはないし、compose for drsktopだとandroidとシングルソースはまだ無理っぽいがmicrosoftのmauiよりjetbrainsの方がやる気ありそう 数年以内に多分また新しい言語出してくるだろうな
それがいいものだといいんだが GoogleってまだGoとDart（とGAS）しか作ってない？
思ったより少ない go もみりゃわかるが、Googleの言語デザインセンスはほんとクソ
何がクソといってそもそも後発で自分が検索を牛耳ってるくせして名前が go ときたもんだバカかアホかと アロー関数はDartでもある。
読みやすいて結局ただの慣れ。
それにコード補完あるから全部タイプするわけじゃない。
初学者は冗長な方が読みやすいというのはある。
多分そういうの考えてあえて冗長にしてるような気はする。
知りませんけどね。 C#やXamarinを主張する奴が定期的に現れるねｗ 自動実装プロパティもないクソ言語を擁護できるのはJavaおじしかおらんよな >>869
C#の方のBとCはInterfaceじゃないの？
悪意を持ってDartだけextends B implements Cで長ったらしく見せようとしてる？ >>881
ググればすぐわかることだけど、Bは継承だよ。インターフェースかもしれんけど
アローを使ってないところはわざとかもしれん Javaはクラスの公開したい変数にBeansの名残りでgetterとsetterを作ることになるのが本当にクソ（作らなきゃいいと言えばそうなんだが）
Dartはそこらへん楽でいいね >>883
getterとsetterはlombok使って自動生成だよ
みんな使ってる >>884
おっしゃる通り、業務ではlombok使ってる。
でも言語仕様と昔の慣習がちょっと釈然としないんよね 変な言語で変な教義にこだわるから変なプリプロセッサがほしくなるんだよ
変な漢ならpublicにすればいい >>884
lombok使って自動生成だよ！(ｷﾘｯ
いやいやクラスの半分以上も埋めてしまう不必要なボイラープレートコード満載の言語仕様がおかしいと議論してるのにわざわざ手間のかかるアノテーションつけてLombok使って自動生成だよは草
Javaを正当化するやつってゴミみたいな言語に慣らされてすぎててバイアスかかりまくりで正常な判断や思考ができないみたいだな >>887
あなたの正常認定誰得なん？笑
あなたが気持ち良いの？
そんなのキモすぎるだけやん。 JavaもDartも過去のしがらみ引きずった鈍臭い言語仕様なんだから仲良くしろよ Dartがペストだとは思わんが嫌いじゃないな。
言語拡張を繰り返し開発案件のバージョン制限によりどの情報を参考にして良いのかわけ分からなくなってるC#より良い。
それでもC#は好きなんだけど、Javaは刺賀にもう駄目かな。
Pythonは別物過ぎて比較にならん。 いくらC#が良くても、Xamarinはコンセプト・アーキテクチャが終わっとる。
React NativeはFlutterに近い考え方と思うけど、Android対応がいまいちなのと、膨大なエコシステムが混沌としててとっつきにくい。 マルチアカウントを実装しようとして、
ひとつのアカウントの中で、オブジェクトがシングルトンであることを実現するには
どうすれば良いか悩んでいたけど
riverpodをやめて、ただのproviderを使えば良いだけだった
riverpodを上位互換と言ってたヤツ誰だよ(駄目な悪態) リバポは上位でも互換でもないですよー
意識高い系(悪い意味の)に好まれてますｗ 調べてみると、やっぱりマルチアカウントの実装はproviderでできそうだわ
>>896
riverpodは状態をグローバル・シングルトンで管理して良い時に使うライブラリだから
どちらかというと技術を必要としない人に好まれるものだと思う
意識高い系の逆じゃないか… あーちくしょー
riverpodで書いたコードをすべてproviderに書き直すのだりぃいいい Rustの時代が来るのにDartなんて話にならんのよ riverpodに限らず大体は使い方次第なきがする
ちゃんと設計してればriverpodも使いやすい >>894
フレームワークとは関係なく普通にfactoryとかfactory methodパターンじゃだめなんか？ diもnotifierもunion classも同梱されて
futureの世話みたいな開発者に任せればいい機能まであって
その子達を使った設計を考えるから
riverpodでしか使えない設計になりがちじゃない？
全部使わなくていいけどriverpod押しの人は駆使したがるよね
provider風にstatenotifierproviderだけで作りたくてもやっぱりriverpodの設計になっちゃう
refを求めてprovider地獄になっちゃって難しかったよ >>902
Factoryでも実装できるんだけど、懸念点があった
アカウントごとに分けられる処理は全てアカウントごとに分ける必要があったんだけど
モデルとリポジトリをアカウントごとに分けるために、
モデル層のインスタンスをアカウントに対応してひとつずつ用意する必要があった
それは、Factoryクラスにロジックを追加するだけで実装可能だけど、
そういう設計にしたら、今度はインスタンスのライフサイクルの問題が出てくる
バグの修正、安定化……って考えたら、
riverpodで書いたコードをproviderに書き直す方がマシにみえた 全てをriver_podからproviderに書き換えて、account_managerを実装中に気がついた
この実装、いけてないわ…
かくなる上は、クラスにメタデータを追加する独自アノテーションを実装しよう
アカウントが切り替わるたびに、インスタンスが切り替わる奴
……絶対きついわ 今のところpubが質的に貧相すぎてflutterが有利な局面は限られてる感じある 独自アノテーションの自由度が低い
リフレクションも重いし、メンテが大変そう…
Factoryの方がマシか ああ、ChangeNotifierを継承したInjectorを作って、
Injectorの中で、
アカウントとインスタンスのMAPの保存・更新と、インスタンスの生成
の責務を追わせればいいのか
InjectorはProviderの中で呼び出せばいい……4日も悩んだのに答えはシンプルだった 責務がめちゃくちゃになってそう
riverpod使ってる人って全体的な設計ってどうしてるの??
MVVM?MVHogehoge? しらんが、riverpod使ってる人みんな試行錯誤してて独自のパターンとか生み出してるのかな riverpod＋ChangeNotifierでMVVMに出来てる C#とXAMLじゃないのにMVVMとか意味ないぞ
元々XAMLとMVVMがセットで設計されてるフロントエンドフレームワークなんだが riverpodを使うとmodel側の状態の更新がviewにすぐ反映されるから
riverpod＋ChangeNotifierを使うと、コードを整理するだけで自然とViewModelができる as void Function()で関数をダウンキャストできるの楽だな
C#だとInterface定義してジェネリックにしないと危険すぎてそんなキャストやろうと思わないけど >>913
認識のあやまり
mvvmはmvpの一形態あるいは派生でしかない >>916
それな！
有名っぽいイヌの人はriverpodでは違う設計になるって言ってたけど
それはよくないんじゃないの〜って私は思ったよ
プロバイダーを束ねるみたいなriverpod独自の機能をたくさん使うと
依存した設計になっちゃうね
それに解りにくくなるから好きじゃないなー >>918
ものすごい思い込みと妄想で断定してるな嘘も100回言えば真実ってか？韓国人かよ
ちゃんとMSのホワイトペーパーかそれに準ずるソース出せるんだよなオオカミ少年？てかさっさとソース出せ MVVM関していえば君がまちがってると思う
C#とXAMLじゃなくても使えるし >>921
だからソース貼ればお前の勝ちだから早く証拠のソース貼れよ たとえばこんなのでいいの？
https://nextpublishing.jp/book/13660.html
fluterじゃないとかAndroid公式じゃないとかただの書籍じゃないかとか難癖つけられるだけな気もするけど >>925
いやだからお前は
> >>913
> 認識のあやまり
> mvvmはmvpの一形態あるいは派生でしかない
って断言してるんだがMVVMがMVPの一形態(日本語がおかしい)だって断定して>>913を否定してるんだからその証拠のソース示せって言ってんだよ
だから断言できるMSのホワイトペーパーかそれに準ずる証拠をさっさと示せよ
>>925
入門書見せてお前の妄想の証拠になるわけないだろ
さっさと思い込みと妄想とノリ嘘吐いちゃいましたごめんなさいしろや >>913の
>C#とXAMLじゃないのにMVVMとか意味ないぞ
についての反例を上げたんだがやっぱり難癖つけられただけに終わったか
ていうか俺918じゃないんだけどさあ
罵倒すること自体が目的になってるからこういう口調がデフォルトになってるんだろうねこの人は うん
そうだと思う
時間の無駄だから相手するのやめた方がいいね
俺らはMVVMは他でも使える派
彼らはMVVMはC#とXAMLでしか意味ない派
でおしまいでいいよ ソース示せず思い込みと妄想の大嘘確定で敗北して負け犬の遠吠えで逃亡してんの草
脊髄反射でレスしちゃいました勘違いして知ったかしてごめんねテヘペロってさっさとあやまればいいのにほんとアホだわ MVVMに挫折して脱落したおじさんなんじゃないかな C#のしつこい主張で老害の気配も感じてたけどホントに老害だったああぁぁああ
「ってか？」って古くて恥ずかしいからやめて〜 きゃああ 理詰めで論破されて悔しくて悔しくて顔真っ赤でIDコロコロ自演とか俺だったら恥ずかしすぎて自殺しちゃうね めんどくさい話をしてるな
はっきりしているのは、vi はクソだってことだ MVVMの発祥はMSのWPF辺りだけどC#とXAMLしかMVVMじゃないという根拠が分からん。 脱落したおじさんなんじゃないかな
と5chで妄想してるおじさんもそう変わらんやろ笑 誰かflutterのアップデートごとに内容を記事にまとめて
アフィ広告ふみますからおねがい c#のmvvmは
純粋mvvmというより
mvvmをblandで利用する為に拡張しまくった
bland.SDKであると言うのが実態 FlutterでWindowsデスクトップアプリ作れるみたいだけど、ロジック部分をC#で書けますか？
スレッド管理が超重要だけど、Dart覚えながらスレッド管理し切る自信がないのでロジックだけC#使いたいです。 >>939
C#のロジックをDLL化すればいけるんじゃね？
それかflutnetを使うか。 blandってなんだよblendだよ馬鹿w
元はMSがCreature Housewから買収したExpressionというベクターツールだよボケ
こんな無知で知ったかしてるやつが噛みついてきてんだからレベル低いとかじゃなくて論外なんだよアホ たかだかtypoでそこまで叩けるなんて凄いね
他に反論できなかったのかな？ あおり運転する人みたいなガラの悪さだね〜
こわーい Flutterをオライリーで学ぶ人は結構厳しいものがある オライリーは勉強する人のための本じゃなくて
勉強した人のための本やしなぁ オライリーは固定化された技術を系統だって理解するには良いけど、さすがに1〜2年違うとガラリと変わる風景には対応できんだろ。 >>949
せっけん１こ、釘１本、マッチ１００本、えんぴつ４５０本、
石灰コップ１ぱい、硫黄・マグネシウムつまみずつ、
水１．８リットル を用意してください 地面に石灰で直径31.35センチの円を描き、中に六芒星を描きます レス数が950を超えています。1000を超えると書き込みができなくなります。
