4 ms·

Some opinions about good choices here, over a year of app development: * Don't get confused by the myriads of state management solutions. Just use GetX, it's a

by onli 5y ago

Some opinions about good choices here, over a year of app development: * Don't get confused by the myriads of state management solutions. Just use GetX, it's a sane solution that works as advertised. * There were a couple of storage plugins like hive that claimed to be better because they be native to the platform and not SQL. As with all platforms, that's bull. SQLite is available, so use that. * The routers are a clusterfuck, the recent addition of declarative routing by the flutter team was a step in the wrong direction. However, the go_router (in the list) that's based on that looks actually nice. * Evade everything with code generation, it hinders a good development workflow and the related plugins for that regularly break. For JSON-serialization that's hard though, I make an exception here, since there are many DTOs to manage. * Flutter theming is a mess. An example that says it all: If you set a colorScheme with a primaryColor, Theme.of(context).primaryColor is not automatically that color. The results of the new ColorScheme.fromSeed() were awful in my test. flex_color_scheme solves that. Be prepared for significant changes here when Material 3 gets fully introduced to Flutter (the recent release 2.10 started with that). Some things to keep in mind despite plugins: Flutter is not ready for the web (and the sites it would produce are JS abominations, so it will never be suited for the web if the approach does not change) and while the framework seems more stable than native app development, there are still breaking changes, both in the core and even more so in the plugin ecosystem. Selecting plugins based on a good stability is hard (as it's not obvious), but worthwhile. Despite its shortcomings and Google connection Flutter is really nice to build iOS and Android apps with one code base, and I'd prefer it even for just an Android app by now.

SpaghettiX 5y ago
> Don't get confused by the myriads of state management solutions. Just use GetX, it's a sane solution that works as advertised. Saying this doesn't help anyone. There are many alternatives and as you say, they compete fiercely for Github stars. GetX is popular package, but it has it's drawbacks: maintainer and bloat. - Maintainer: he's been known to make wild claims about his package, and target other alternatives with strong unbacked opinions. - Bloat: it tries to do a lot of things. Integration with other packages, concepts and tools don't work well - certainly doesn't integrate easily.
- onli 5y ago
  That's exactly what I mean - none of this matters. The maintainer does his job well and GetX does solve the problems it claims to solve nicely. Use Obx with a GetX controller and you are done. The other parts of the project, like the routing, are an option if it fits to your app. And sorry, I really think this stated clearly is helpful. It's not worth your time to even look at alternatives. Sure, that could change in the future if the plugin gets abandoned, but it has seen good maintenance so far and zero breakage. Everything else to my eyes is FUD.
  - SpaghettiX 5y ago
    The solution to the problem of having too many options is probably not best solved by picking one based on someone from the internet without evidence or comparison. The solution to many people debating is not to just pick one side of the debate because the debate doesn't matter - you think.
Comevius 5y ago
GetX is a very high-level API for Flutter, it works for simple things, but as you go on you will realize how restricting it is. It abstracts away details not meant to be abstracted away. It's just bad design, and it's anti-patterns will bite you. Just learn how to do things the proper way, because it's not that hard, and much more expressive and clean. If you go for Flutter job it's best to not mention GetX either.
- onli 5y ago
  It works perfectly for us - in a professional app nonetheless - and has not been restricting at all. No bad design or anti-pattern bit us, and it does not get cleaner or more expressive than Obx with a controller. This is unlikely to change, the process where our app got more and more complicated has already stopped. > If you go for Flutter job it's best to not mention GetX either. I wouldn't work for an employer that does not let me pick the right tool for the job, so there is no danger there.
  - Comevius 5y ago
    Not to get on your nerve, but GetX is basically a toy API, and the codebases that use it tend to evolve in the heap of spaghetti direction, but if your app is simple enough you can get away with it and save time, so who am I to knock it.
    - onli 5y ago
      Na, it's okay, if you really feel that way you should comment accordingly, especially given my strong blanket recommendation. I see it exactly the other way around, but defining things like "clean" are hard to do and we might just have completely different positions. Maybe to make it as constructive as possible, why don't you link to what is your preferred alternative approach? I assume it's not setState :)
      - Comevius 5y ago
        Riverpod is pretty good, and using the Bloc pattern without any Bloc libraries, just with StreamBuilder or your own abstraction is pretty good. The rest is just using the Flutter API as intended. https://riverpod.dev/ https://riverpod.dev/ I personally also like to practice data-oriented design, write most of the logic in C/Zig with a functional reactive Dart API, and then share the streams with Riverpod. I keep most of the state in C/Zig, but that should be a Dart-only library, I just use C/Zig because I need the core functionality of my app to be portable, for example to use it with Vue.js, or even FreeBSD, which Dart don't even support, but if that's not the case a Dart-only library for the core functionality is the way to go.
isoos 5y ago
> Don't get confused by the myriads of state management solutions... > Evade everything with code generation... It is funny to see this theme getting repeated in various domains: at the same time, you will get users who complain that there are not enough choices for them in domain X, while others complain that there are too many choices in the same domain X. And usually there is no single best solution to rule them all. E.g. in these specific items, I've found bloc + freezed-based code generation to do state works much better for me than any alternatives. ymmv.
- onli 5y ago
  > I've found bloc + freezed-based code generation to do state works much better for me than any alternatives. ymmv. YMMV definitely applies :) Since I have some experience with exactly that alternative: I see bloc + freezed as the antithesis to GetX. "Clean" abstraction over "simple" code. There might be more extreme example for both sides of course, but this has been my impression. We do use bloc + freezed for some specific flows in the app where the abstraction just fit better. A better fitting abstraction is a big plus on its own for those usecases. On the other hand, bloc had a bunch of breaking changes (nicely visible in https://pub.dev/packages/flutter_bloc/changelog https://pub.dev/packages/flutter_bloc/changelog), and that especially in combination with hydrated bloc has given us a bunch of grief. I hate breaking changes more than anything. It might still be a better solution - so really, YMMV - if your goal is maximum abstraction to be able to change frameworks (or in this case, I assume it would be about state management solutions), after all that's where the solution is coming from. For me, that was an anti-goal, abstraction = complexity, while minimal complexity with maximal development speed was what we needed. GetX fit perfectly for that. Admittedly, ignoring some things to learn with lists and at the beginning strange issues with Obx change detection, but the latter got better, either with bug fixes or experience. If Obx misbehaves now it has always been a clear fault on our side.
hestefisk 5y ago
I sometimes wonder how long it will be before Google shelve this one as well…
- mleonhard 5y ago
  Flutter team has already stopped developing for mobile, leaving a lot of things unfinished or missing: integration testing, location, iOS dark mode, iOS keyboard dismiss, iOS detail cell and other common iOS widgets, material date+time picker, navigator documentation, and others. The page is called "Awesome Flutter" but it should be called "Third-party Flutter code to fill some of the holes in Flutter".
  - hestefisk 5y ago
    It’s frustrating. Sometimes I wish Google could manage their attention deficiency and actually complete something, then stick to it.
occz 5y ago
>Despite its shortcomings and Google connection Flutter is really nice to build and Android apps with one code base, and l'd prefer it even for just an Android app by now. Have you tried building android apps with Compose? It's significantly better than the old view system in android.
- onli 5y ago
  Indeed I have not, its 1.0 release came after I had moved on from that job. Does not look as nice to me, from a first glance, but that might be misleading. Thanks for the hint.
  - occz 5y ago
    Other than being unviable for creating iOS-applications, I find it significantly nicer. Merely being able to use Kotlin instead of Dart is a huge advantage.
ratg13 5y ago
>Just use GetX This is terrible advice. GetX is great for rapid prototyping but nothing more. Once you reach a certain point you will need to re-code your entire app to get rid of this. If you choose GetX, you are no longer building a flutter app, you are building a GetX app, and you will want GetX developers to work with the code and at some point it will becomes unsustainable and you will need to start over. GetX is bottom of the barrel flutter development, and is only valuable for people who churn out large amounts of apps for customers that have no idea what they want.

by onli 5y ago

SpaghettiX 5y ago

> Don't get confused by the myriads of state management solutions. Just use GetX, it's a sane solution that works as advertised. Saying this doesn't help anyone. There are many alternatives and as you say, they compete fiercely for Github stars. GetX is popular package, but it has it's drawbacks: maintainer and bloat. - Maintainer: he's been known to make wild claims about his package, and target other alternatives with strong unbacked opinions. - Bloat: it tries to do a lot of things. Integration with other packages, concepts and tools don't work well - certainly doesn't integrate easily.

onli 5y ago
That's exactly what I mean - none of this matters. The maintainer does his job well and GetX does solve the problems it claims to solve nicely. Use Obx with a GetX controller and you are done. The other parts of the project, like the routing, are an option if it fits to your app. And sorry, I really think this stated clearly is helpful. It's not worth your time to even look at alternatives. Sure, that could change in the future if the plugin gets abandoned, but it has seen good maintenance so far and zero breakage. Everything else to my eyes is FUD.
- SpaghettiX 5y ago
  The solution to the problem of having too many options is probably not best solved by picking one based on someone from the internet without evidence or comparison. The solution to many people debating is not to just pick one side of the debate because the debate doesn't matter - you think.

Comevius 5y ago

GetX is a very high-level API for Flutter, it works for simple things, but as you go on you will realize how restricting it is. It abstracts away details not meant to be abstracted away. It's just bad design, and it's anti-patterns will bite you. Just learn how to do things the proper way, because it's not that hard, and much more expressive and clean. If you go for Flutter job it's best to not mention GetX either.

onli 5y ago
It works perfectly for us - in a professional app nonetheless - and has not been restricting at all. No bad design or anti-pattern bit us, and it does not get cleaner or more expressive than Obx with a controller. This is unlikely to change, the process where our app got more and more complicated has already stopped. > If you go for Flutter job it's best to not mention GetX either. I wouldn't work for an employer that does not let me pick the right tool for the job, so there is no danger there.
- Comevius 5y ago
  Not to get on your nerve, but GetX is basically a toy API, and the codebases that use it tend to evolve in the heap of spaghetti direction, but if your app is simple enough you can get away with it and save time, so who am I to knock it.
  - onli 5y ago
    Na, it's okay, if you really feel that way you should comment accordingly, especially given my strong blanket recommendation. I see it exactly the other way around, but defining things like "clean" are hard to do and we might just have completely different positions. Maybe to make it as constructive as possible, why don't you link to what is your preferred alternative approach? I assume it's not setState :)
    - Comevius 5y ago
      Riverpod is pretty good, and using the Bloc pattern without any Bloc libraries, just with StreamBuilder or your own abstraction is pretty good. The rest is just using the Flutter API as intended. https://riverpod.dev/ https://riverpod.dev/ I personally also like to practice data-oriented design, write most of the logic in C/Zig with a functional reactive Dart API, and then share the streams with Riverpod. I keep most of the state in C/Zig, but that should be a Dart-only library, I just use C/Zig because I need the core functionality of my app to be portable, for example to use it with Vue.js, or even FreeBSD, which Dart don't even support, but if that's not the case a Dart-only library for the core functionality is the way to go.

isoos 5y ago

> Don't get confused by the myriads of state management solutions... > Evade everything with code generation... It is funny to see this theme getting repeated in various domains: at the same time, you will get users who complain that there are not enough choices for them in domain X, while others complain that there are too many choices in the same domain X. And usually there is no single best solution to rule them all. E.g. in these specific items, I've found bloc + freezed-based code generation to do state works much better for me than any alternatives. ymmv.

onli 5y ago
> I've found bloc + freezed-based code generation to do state works much better for me than any alternatives. ymmv. YMMV definitely applies :) Since I have some experience with exactly that alternative: I see bloc + freezed as the antithesis to GetX. "Clean" abstraction over "simple" code. There might be more extreme example for both sides of course, but this has been my impression. We do use bloc + freezed for some specific flows in the app where the abstraction just fit better. A better fitting abstraction is a big plus on its own for those usecases. On the other hand, bloc had a bunch of breaking changes (nicely visible in https://pub.dev/packages/flutter_bloc/changelog https://pub.dev/packages/flutter_bloc/changelog), and that especially in combination with hydrated bloc has given us a bunch of grief. I hate breaking changes more than anything. It might still be a better solution - so really, YMMV - if your goal is maximum abstraction to be able to change frameworks (or in this case, I assume it would be about state management solutions), after all that's where the solution is coming from. For me, that was an anti-goal, abstraction = complexity, while minimal complexity with maximal development speed was what we needed. GetX fit perfectly for that. Admittedly, ignoring some things to learn with lists and at the beginning strange issues with Obx change detection, but the latter got better, either with bug fixes or experience. If Obx misbehaves now it has always been a clear fault on our side.

hestefisk 5y ago

I sometimes wonder how long it will be before Google shelve this one as well…

mleonhard 5y ago
Flutter team has already stopped developing for mobile, leaving a lot of things unfinished or missing: integration testing, location, iOS dark mode, iOS keyboard dismiss, iOS detail cell and other common iOS widgets, material date+time picker, navigator documentation, and others. The page is called "Awesome Flutter" but it should be called "Third-party Flutter code to fill some of the holes in Flutter".
- hestefisk 5y ago
  It’s frustrating. Sometimes I wish Google could manage their attention deficiency and actually complete something, then stick to it.

occz 5y ago

>Despite its shortcomings and Google connection Flutter is really nice to build and Android apps with one code base, and l'd prefer it even for just an Android app by now. Have you tried building android apps with Compose? It's significantly better than the old view system in android.

onli 5y ago
Indeed I have not, its 1.0 release came after I had moved on from that job. Does not look as nice to me, from a first glance, but that might be misleading. Thanks for the hint.
- occz 5y ago
  Other than being unviable for creating iOS-applications, I find it significantly nicer. Merely being able to use Kotlin instead of Dart is a huge advantage.

ratg13 5y ago

>Just use GetX This is terrible advice. GetX is great for rapid prototyping but nothing more. Once you reach a certain point you will need to re-code your entire app to get rid of this. If you choose GetX, you are no longer building a flutter app, you are building a GetX app, and you will want GetX developers to work with the code and at some point it will becomes unsustainable and you will need to start over. GetX is bottom of the barrel flutter development, and is only valuable for people who churn out large amounts of apps for customers that have no idea what they want.