I am new to Flutter, and I am writing a first app backed by SQLite, using sqflite.
I am familiar with the Flutter architecture, having worked with React, so I understand various patterns of keeping state - from passing down closures from stateful widgets to keeping a single immutable tree with all state and passing various branches downstream. All these techniques work well when your state is fully in memory.
But now I am persisting state into SQLite, which is the definitive source of state in my app. It is easy to do this until everything is read only: pass a handle to the DB to every widget, and every widget can query its own state.
I am trying to figure out a good pattern to handle changes. A possible approach is manual: for every change, do the relevant update in SQLite and at the same time call setState on every affected widget. But this is error prone. I would like to find a way to mark a widget as dirty, so that it is rerendered from scratch, loading its values from SQLite again. Or possibly there is yet another way I didn't think of.
What are good patterns to keepthe widget state aligned to SQLite?
Related
Im using the package flutter_form_builder
I have alredy made a few screens with forms, with stateless widgets and provider, each screen has its own provider with submit methods etc.
Everithing was working okay until i test my theme, changing to dark mode on ios from control center, rebuilds the entire app and the form loses its data, but the provider does not lose its data. This does not happen with stateful widgets.
My question is, theres a way to keep the data across rebuilds whitout stateful widgets?, i have tried storing the formkey on the provider but this doesnt work, i got errors about duplicated key. I have alredy made my test files thinking with stateless widgets. If my provider does not lose its data, i suppose there is a way to save the form state on the provider, because the need to convert to stateful widgets it the form state.
Sorry, im new on flutter and i learning english too.
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.
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.
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.
So, I am trying to create a project where I am supposed to Call Web API and store the data in my local storage. Which should still have even if the app is killed and then re-opened.
FYI, data will be large and I will require a significant amount of space in the mobile device.
i will be using firebase for login, the payment transaction and etc.
this is my first answer, I hope to help you.
BloC & Moor are not synonyms, BloC is a reactive state management solution that allows you to better manage the interaction between logic and widgets in a reactive way. Moor is a layer between sqlite and your application, it allows you to deal with sqlite using dart code by reacting to database changes through Streams and Futures
I think you do not need to choose one of the two, if your application is going to handle large amounts of data and will grow exponentially I recommend that you implement both as they complement each other, by designing a SOLID structure.