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 >>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センチの円を描き、中に六芒星を描きます Flutterは進化が早いから書籍は向いてないかも 進化が早いといえば聞こえがいいけどようするに
基本設計が適当で行き当たりばったりなので
毎回派手に仕様変更され続けてる言語でしょ？
正直、仕事で無ければ触りたくない言語だと思う フレームワークを言語と間違えちゃうのかわいいねっっ！！！ スマホOSが機能追加繰り返してるんだから
それに合わせて拡張していくのは当然なんだけどな
実際OSアプデの度に新機能追加したFlutterを数日以内にリリースしてるからね
Googleはかなり本気でサポートしてるよ
Xamarinなんて年1回少しだけ機能追加して後はバグ修正しかしてないからね
あの調子じゃすぐ時代遅れになるのに Xamarinの話はNG!
またあの人がきちゃうっ!!!笑 FlutterはGoogleの中の人が飽きたらなくなるが、
Xamarinはユーザーがいなくなってもなくならない
これがGoogleとMSの違い 昔のDartでさえ無くならなかったのに今のFlutter/Dartが無くなるとは思えない DirectX.NET
XNA
SilverLight
Windows Mobile
Internet Explorer
なくならないなんてあるの？ Dartの使用者が増えないのは個人開発的にかなり美味しい
みんなが参戦するとすぐ赤い海になるわ
Flutter/Dartならば、開発工程を相当飛ばせるから、
少し前なら大作と呼べるようなアプリを、個人でも現実的な期間で作れる
あとFirebaseやFlutterのAPIの応用例に、チーム開発では使えないような魔法が多いから、
個人開発でもチーム開発に対抗する余地がある
また、日本は海外に比べてレベルがかなり劣ってるから、
海外では学生がポートフォリオで作るようなクオリティーのアプリでも勝負できる >>965
.NET MAUI がリリースされるまでだね
もうすぐ終わりだよ >>967
は？flutter舐めてる？
まだ始まってもねーから！！！ >>967
は？flutter舐めてる？
まだ始まってもねーから！！！ lintを更新したら、riverpodのコードを急に咎められるようになった
これは潰しにきてるなあ。contextを暗黙に保存していたのか >>973
riverpodを潰しにきてる？
え？ま？ ごめん。上のコメントは徹夜で寝ぼけてたんだ
でも『Do not use BuildContexts across async gaps』が出てるようになり
ほんとうに困ったのはマジ
StatefulWidgetを使用しないと上手に対応できない これflutterに関係するかなあ
心配だよ
GoogleCloudの従業員100人がクビ 本人たちはメディアの報道で知る [708866696]
https://greta.5ch.net/test/read.cgi/poverty/1647849795/ 非同期関数の中でNavigatorを呼び出せるラッパークラスを作って対応できたけど
手が遅いから普通に2日もかかってしまった riverpodを使用するとUI側で非同期関数を使用する率が高そうなんだけど
非同期関数からNavigatorを呼び出すと、
『Do not use BuildContexts across async gaps』が出る問題について
皆はどう対処してる？ WPFでデスクトップアプリ作ってた頃よりもFlutter使ってる今の方がGUIとロジックの分離を意識できてる気がする >>980
正解の方法かどうか分からんけど、そのエラーはTimer.run()使ってタイミングずらすと回避できるはず。 >>982
ビルド中にmarkNeedsBuildするなってエラーと勘違いしてない？ >>982
Timer.run()で不具合回避すると、不具合が発生しないことに保証が立たないから怖いべ…
スマホアプリなら実機で動作確認できればリリースしていいかもしれないががががが こんなブログを見つけた
https://zuma-lab.com/posts/flutter-troubleshooting-called-during-build
WidgetsBinding.instance.addPostFrameCallbackを使っておけば大丈夫だと思う >>986
それも違うでしょ
BuildContextを非同期に使うとunmountされた後になるかもしれんから危険なんよ
内部の動作を知らずに使ってるの？ レス数が950を超えています。1000を超えると書き込みができなくなります。
