Flutter/Dart which architecture for App and potentially web app?

[Jonas Sander]

-- Question:
So I heard of many different approaches to structure flutter apps and it just really overwhelmed me.

There is MVI or MVU or MVP-based architectures, Redux, RxDart, scoped_model, just lifting state up, ... and 100 more structure i don't know and can't get to grasp.

What are recommended structures for my use case/What are the pros and cons of different approaches.

-- My situation/ use case: (If I include unrelevant information i'm sorry)

My team and I want to build an potentially "large-scale" app for Android and IOS with flutter and maybe implement this also as a web application.

We will be using Google Firestore as a Database and in our use Case we often like to utilize streams, as there can potentially be many changes from other users for the elements of the current users page.

Until now we just did some prototyping, but now want to really have an structured approach to developing. Also we want to emphasize testing, which we didn't really until now.
Additionally we want to have internationalization, probably with the intl package.

I heard in certain structures code could also be used for a web app in dart, which would be really beneficial, as we potentially want to create an web app in the future.

--Backstory/more optional insight:
So me and my group are a startup in Germany and just won a price in our category in a big national competition.

Our Idee is a digital school assistant, where in a nutshell students create/join courses, where one can place homework, Dates/Events and files into the course. Once created, content will be directly synchronized with the other students in this course.
So for example if a user would be on the homework page, and if another user creates a homework, then the first user should see the new homework directly, without needing to swipe to refresh for example. So i think streams probably, right?

At the moment we are only 6 people, where 4 can develop in flutter, me included ;).
So atm we are only a small team, and have no tests, code-reviews etc.

After the winning, with the help of our prototype, I am now responsible to create a structure for our app, which should be scalable to a big team and many users (maybe from different countries).

Also like I said we may want to implement an web app in the future, with the same functionalities as the app.

I hope someone could help me, I would be very grateful :).

[Ілля Романенко]

Congrats on you win Jonas! I think the recommended by Google approach would be to use BLoC.

Here is a nice video on how to do something like you want - mobile app & web site that can reuse code across: https://www.youtube.com/watch?v=PLHln7wHgPE

вт, 10 лип. 2018 о 14:42 'Jonas Sander' via Flutter Dev <flutt...@googlegroups.com> пише:

--
You received this message because you are subscribed to the Google Groups "Flutter Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flutter-dev...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jonas Sander]

Thank you, I'm gonna look into it! :)

[Kisakye G. Charles]

Am currently having the same issue as what you had previously, could you advise on what you finally used.

[Maurice McCabe]

Check out https://github.com/brianegan/flutter_architecture_samples which has 2 examples of using the Bloc pattern and examples of running on Google Firestore using streams. It also includes unit, widget and integrations tests, and how to use a CI to automatically run unit and widget tests, code coverage reports and run integration tests on iOS and android emulators. 

Can automatically deploy to both stores using https://github.com/mmcc007/fledge, and automatically generate screenshots using https://github.com/mmcc007/screenshots. 

As your app gets more traction, you can (automatically) run integration tests on hundreds of real android and iOS devices using https://github.com/mmcc007/sylph

--Maurice

[Aryeh]

Hi Jonas,

My suggestion is to use the simplest thing possible, while ensuring that choice doesn't limit changes in your product's future.

All of the "state" alternatives are really attempts to overcome a disadvantage of Flutter's (and React's) tree-based component structure.  Components can be wonderful because they can be reasoned about independently, and combined to form more complex things.  However, what if two components want to rely on something in common?  This isn't a problem if a Component represents a user-interface element with internal state, i.e. a checkbox that is checked or not. However, it is a problem if multiple components need to rely on or reflect something between them, and the plethora of alternatives reflects the many ways one might address it.

So two or more Components need to rely or reflect something in common.  The logical solution is to have something shared somewhere they all can access.  Other than using a global location with access for all, the simplest solution is to add a Component near the top of the tree (or some other common tree location) that others can access.  One which also supports Flutter's reactivity where if something in that common Component changes, it get reflected in any other participating Components.

While you could write this yourself, I suggest you use "scoped_model".  It does just this, and is simple enough for all to be able to understand and use, yet robust.  Nearly everything else adds to the basic model by introducing complex abstractions, you likely will not initially need.

Aryeh