My question to understand
if I have some data like login info that I will not change along with app live.
But I will use it in many different screens why use state management instead of using a static variable to store data and retrieve.
I hope to find an answer or guidance to the appropriate article or documentation.
State Management in simple terms is defined as 'Whatever data you need to rebuild your UI at any moment'.
State Management makes it easier to access data and helps you to keep your business logic and UI separate.
Now to your question If you use state management like Provider etc, you can access your login data globally and wouldn't have to pass a static variable to all screens. With help of state management, your rebuilds will also be smaller rather than building a whole screen again
You can certainly store it in the State of a StatefulWidget, so it can be accessed by the corresponding build() method. But to have a broader scope, you'll need something like Provider or (my preferred) Riverpod.
Related
In development we have found Flutter Navigator to be limiting to what we want to achieve. It seems very much set up for a conventional route structure however many of our user actions involve state changes that modify the existing screen rather than push a new page on top.
We have achieved this using a combination of customised CrossFaders and AnimatedSwitches with Provider handing the state management. Is there anything wrong with this approach?
I am very much new to the mobx and want to use it as state management for my application.
so far with the online tutorial and google search I know that mobx is the state management tool similar to ChangeNotifier in the flutter and best used with provider to elegantly manage the state of the widget.
So far, it makes sense to manage the state screen wise:- for that I create the store which will only be a concern for this screen only, and after declaring the #observable state variables, I wire them up with business logic and provide it to the concerned screen.
But there are states which have to be managed across the screen, where the state of the current screen is dependent on the state of the previous screen.
So, what is the best way to manage the state across the screen using Mobx? For now, I would create one global Store (the reason it is global because I want to access this store in the individual screen store also for some business logic) which will be available across multiple screens made available using provider.
And used in the individual Store to manage the state.
But somehow making state global doesn't seem right? so, what is a possible solution for this? what is the most elegant way to manage state across multiple screens in flutter using mobx?
You can use Provider and MobX together, create and provide the same instance of your MobX class to any screen that needs it.
Edit:
I guess I didn't read the whole question, what do you mean when you say a Global MobX Store?
And now that I'm thinking about it, you may want to create a GetIt instance of the store and just grab that in any screen you want, but I cannot say that one of them is better than the other and definitely not the best way.
What are the negatives to setting up streams for all the data I would need throughout my application with a MultiProvider in the root widget of the application and then using Provider.Of(context) to retrieve them in child widgets in the future?
If this question is way off the mark or I am misunderstanding some major principle behind this, please help me to understand as I am obviously new to this!
If you use this method, some providers which depend if data is available in other provider may not work.
For example you want to see if the user has an account record or not. If he doesnt have an account he will go to a profile form, and if he has an account he can see all his purchases stored in a nested collection. It will not be possible to do with multiproviders.
Except these I dont think there is any other problem.
In Flutter, I want to use a calendar from the table_calendar package in order to set shifts and assign employees to them.
Also to do so I am using a local database from the sqflite package.
I have seen a few tutorials online, e.g., Database Storage in Flutter using Sqflite, that combine the database with Bloc technology.
For my calendar, I need a Map<DateTime,List<dynamic>> to control the events. As of now, I used a static map that I would use in different classes, e.g., shift_form and shift_calendar.
The Bloc implementation would start somehow like this:
class ShiftBloc extends Bloc<ShiftEvent, Map<DateTime,List<dynamic>> {...
Why should I use Bloc instead of a static Map?
Also is it even possible to use a Bloc as a Map data structure? Edit: -> Yes it
is
But how should I implement Blocs for the Streams that I am getting from Firestore as a Map instead of a List?
P.S. I am using the Flutter Firestore Todos Tutorial structure.
As a general rule, you never "have" to use BLoC for anything.
BLoC and other State Management strategies are meant to make it easier to deal with data that multiple parts of your App need at the same time, and need to be updated when that data changes.
For simple Widgets, low dependency on data, a simple setState should be more than enough and there's nothing wrong using it.
Some people just use State Management with everything without stopping to analyze the problem at hand, this makes the code more confusing for not reason.
If your Map is local, just use it locally, if you need it in several places, than avoid using it as a global variable as this makes testing a lot harder.
Remember, a BLoC is just a class with Streams as ouputs and Syncs as inputs, the Firebase Firestore class already provides you with a Stream, so your BLoC could be just a Stream transformation adapting the data on Firestore to your Map. I can't really say how to make this as I am not aware with your data.
I am learning the bloc pattern for Flutter and there seems to be a recurring piece of advice that "every screen should have its own bloc".
But what if you queried your server for data that will be used in more than one screen? It seems redundant, and even wasteful, to hit the server several times for the same piece of data, especially if you know that data has not changed (for example, when no operations that mutate/update it have been used).
Is there anyway you can hold that data somehow to reuse it? Is it a good idea to store data used this way at the repository level? Or is this just an accepted cost of using blocs?
Architecture decisions are always highly opinionated and there is no silver bullet.
Well, here you go.
Is there anyway you can hold that data somehow to reuse it?
Offcource yes. You can architect your app like the following way.
Widgets -> Bloc -> Repository -> Local database/ Remote API
So, your bloc will never make any API call directly, but your repo layer will do. Hence, repo layer can decide whether to fetch the data from remote API or local DB or even from the in memory cache. That way, you can reuse the already cached data on multiple screens of your app.
The interesting part is that, unit testing your code will be super easy if you architect your app like this way.
Is it a good idea to store data used this way at the repository level?
Yes.