1

I've gone through several tutorials on Flutter and I find that they cover basics just fine but there are some nagging aspects of good design and good architecture that are consistently missing. I'm writing my first actual (not toy) application in Flutter and find myself running into these missing points.

  1. Global data. Once a person installs the application and tries to use it, I ask them to log in / create an account, since this is an application specifically for managing groups of people. I'm using Firebase on the back end, and the package to do authentication winds up returning Future<FirebaseUser> from everything. So, yes, when it comes to building a Widget that uses the user's data, I can use a FutureBuilder. That said, it seems weird to have to keep typing boilerplate FutureBuilder code to dereference the user every place I want to use the user's ID to look up their data (what groups are they part of, what actions do they have pending, etc.). I really feel like there ought to be a way to invoke the future, get the actual user object, and then store it somewhere so that anything that wants a user ID for a query can just go get it. What's the right solution? I can't believe I'm the only person who has this problem.

  2. Updatable data. I've got a page where I list the groups the current user is a member of. The user, though, can create a new group, join an existing group, or leave a group. When they do that, I need to redraw the page. The list of groups comes from running a Firebase query, so performing an action (join, leave, etc.) should signal the app to redraw the page, which will have the side effect of re-running the query. Conceivably, one might make the page dependent (how?) on the query results and have it redraw whenever they update, and instead have some widget somewhere that keeps track of the query. There's another answer here that hints that this might be the right way to go, but that's really concerned with relatively invariant data (locale doesn't change all that often for a single user). So, again, I can't believe I'm the only one who does this sort of thing. What's the best practice in this case?

Stephen B.
  • 396
  • 2
  • 19
  • Hello! While this is an interesting topic, StackOverflow isn't the right place for such a question. There are far too many solutions. But you can take a look at BLoC, redux, or InheritedWidget/ScopedModel. – Rémi Rousselet Jan 09 '19 at 00:31
  • Personally I'm just using singletons at the moment and I've rolled my own very basic state/notifier system (so a widget can register to be notified of changes and can change the state of the other widget), but I am experimenting with BLoC which seems interesting. I do think when examining the solutions, it's worth contemplating how you can automate testing as well with the various solutions, as I think that's often overlooked and probably comes more into play with serious/larger projects. – Ian Jan 09 '19 at 10:01
  • 1
    This repo contains various examples for different types of state architectures, which might be interesting: https://github.com/brianegan/flutter_architecture_samples/ – Marcel Jan 09 '19 at 15:12

0 Answers0