See how to use the popular BLoC pattern to architect your Flutter app and manage the flow of data through your widgets using Dart streams.
Regarding your following note, do you have an example of the best practice in Flutter?
Note: It’s a best practice for production apps to not store your API keys in source code or in your VCS. Better to read them in from a config file that is read in when your app is built.
That’s actually an interesting question. I don’t think there is an official best practice. You have to decide what works best for your team.
In the case of this tutorial, since the code is open source, its probably not a good idea to publicly share your api keys. The keys that Zomato generates have a limit on how many calls they can make in a day, so it is theoretically possible that if I published my API key, the tutorial would stop working.
A simple solution would be to have a dart file where you write your keys that is added to your .gitignore. This would effectively be a the same as having a local.properties file
On internal projects where the code is not open source, this is less of an issue. It might even cause more annoyances for your team to since there will be extra hoops they’ll have to jump through to get their environment set up. For these kind of projects I would just try to avoid committing your deployment keys and keep those separately in a safe place.
At the end of the day, just have a conversion with your team to decide what strategy works best.
Creating the dart file and .gitignore was exactly what I was thinking, but I wasn’t sure if it was a good idea. I’ve not worked with API keys in my existing iOS apps, so I’ve not had to deal with it (my “team” is currently a team of 1).
Guys, nice tutorial. Well done.
Are you going to be doing a similar one on Provider? I feel BLoC is a steep learning curve for new beginners to Flutter where Provider might be easier to understand.
Hi Mattnz. You are correct, BLoC is certainly not a beginner architecture. When you are first getting started with Flutter and just learning your way around widget composition, BLoC should probably be the last thing on your mind.
We do have some other tutorials in progress about Provider and ScopedModel that will be published in a few months. Stay tuned!
One aspect of this tutorial that is probably even more important than BLoC is the concept of layering. With this structure you can use BLoC, Provider, Redux, MVVM, whatever. As long as you are keeping a clean separation between your view layer and data layer, you’ll be off to the races. I think its more important to focus on a clean separation of concerns and then chose more advanced design patterns based on the requirements of your project.
Hi Brian,
following the Google best pratices about BLoC pattern, you should never expose a bloc method making it public, as I have understood the only allowed inputs and outputs are streams and sinks.
I have seen that you are using methods such as
locationBloc.selectLocation(location);
Am I missing something?
Many thanks
BackboneJS application to Flutter migration. Which design pattern to use?
We have developed an application using BackboneJS. Now we are planning to migrate this project using Flutter.
Our Project folder structure is like below
Navigation from one view to another happening at root level, sub-levels(Eg: Jobs, Modules in the above screenshot). We have to trigger notifications between multiple classes.
We are planning to support all 3 platforms (iOS, Android and Web)
Could some one suggest me the best architecture or design pattern to implement this BackbnoneJS application in flutter.
It’s an excellent article, a minor detail I notice is that you are not following dart naming convention, any reason for doing that? Effective Dart: Style | Dart
naming packages and files with lower case and underscore, etc.
Hi Chris. Thank for your feedback. You are correct, this is technically an error. This is no good reason why Dart file naming convention was not followed in this article, other than the fact that is was an accidental oversight. All future Flutter articles on our site will make sure to follow Dart’s convention.
Flutter newbie here! I was going thru an older tutorial on the same subject and they discussed having their BlocProvider rely on InheritedWidget for performance. Does this tutorial take that into account or is that no longer an issue with how Flutter/Dart has evolved?
Yes InheritedWidget is better for performance because finding the widget with the bloc in the parent tree is an O(1) operation. The downside to using an InheritedWidget is that it does not have a dispose method which is necessary for disposing blocs in order to prevent memory leaks.
A Stateful widget has a dispose method so that solves the problem and the ancestorWidgetOfExactType method of the BuildContext class was used to access the bloc up in the tree.
The downside to this approach is that the operation is O(n) but this was the approach used in the tutorial.
Now, you might be asking so whats the solution since both of them have downsides.
Well, you could combine the best of both worlds to solve this problem.
You’ll need to use an InhheritedWidget to pass the bloc down and return it inside a Stateful widget so the bloc can be disposed.
I know that sounds intimidating but it is fairly simple 
You could also use the provider package for the dependency injection if you want to use a library.
Note: ancestorWidgetOfExactType has been deprecated after Flutter v1.12.1
@shogunkaramazov i’m new on the video team and i don’t know if i could provide links to outside materials where i show this or would the tutorial be updated?
Just need to know how things work.
@fleepgeek Thank you for your feedback. I’ve updated the article to reflect the api depreciation.
In terms of the question of performance, yes I agree that findAncestorWidgetOfExactType is not the most efficient methods and the Flutter documentation even points this out. But in practice, this has turned out to be a mostly moot point. You can certainly go much further in optimizing this widget. However the article was already quite long so I chose to keep with the naive approach so that the focus didn’t shift away from core concepts the article was trying to teach.
We could always write a follow up article on optimizing Flutter, but it when it comes to that topic it is critically important to never pre-optimize. We should only spend time fixing this if it become a noticeable performance issue and is causing jank in your app.
This tutorial is more than six months old so questions are no longer supported at the moment for it. Thank you!