Looking for a bit of advice regarding some flutter architecture. I'm building an app that has about 10 screens all stored as named routes and using onGenerateRoute.
I'm trying to implement blocs and streams so that I can broadcast to one page when another page, say, creates a new record (all handled in an online SQL db).
So I have two pages that use one bloc, another 3 pages that need access to another bloc... etc.. Does this mean that only way to provide access is to put a bloc provider for all blocs at the top of the widget tree, making all blocs available to all pages?
I tried to provide access to one bloc individually on two pages by using a provider at the top of each of those two pages... however, I guess this means I am actually creating two separate BloC objects? rather than both pages actually using the same one. So when page B creates a new record, it is not calling page A to reload...
I'd rather not have all pages accessing all BloCs, but is the only way to do it to put the Bloc in a place where it is a single ancestor of any page that needs it?
I'm also rather confused about why we close streams... I thought the point is that they are a continuous source of data... if we close them, are they no longer available to broadcast to subscribers?
Utterly confused, and 3 hours of YouTube videos later, I'm no clearer.
Thanks in advance...
Check this out https://bloclibrary.dev/#/recipesflutterblocaccess?id=generated-route-access
When the Widgets that need the blocs are disposed, the blocs are also should be disposed. Otherwise you're consuming resources unnecessarily by keeping it alive.
Related
I currently create a prototype project which implements a lot of features like navigation management, errors management, storage management etc etc
I'm facing now a question with blocs.
I want to know which is the best practices using blocs, in fact, imagine I have a product system like list of products, product detail, select product.
Does I need to have only one bloc which can take 3 events like
Get List Products
Get Product Id
Select Product
with differents states like GetListInitial, GetProductInitial, SelectProductInitial and others for "loaded", "finished" for example
And then in my 2 pages I can use a BlocConsumer which listen, in the listProduct page GetListInitial, GetListFinished and the product Detail page GetProductInitial, GetProductFinished ?
I can also use 2 BlocConsumer in the same page which are listening differents states for example listing products and then select one.
Or
Does I need to have three differents blocs which can take 1 event and do the same process with each bloc.
We can consider that the 1st solution can group events by features but in fact does not respect what Flutter want like works with widget because in my example 3 BlocConsumer will be handle if one event occured, but only 1 will do things.
But in the 2nd solution, it means that if I got a huge application so I will have a very very lot of blocs, right ?
Which is the best solution?
Thanks
I think a good way is having a bloc for each feature, and one repository or storage.
I usually make navigation by passing object's unique id to widget's constructor and then opening modal page with its own bloc, that handles loading description etc.
For example I need to load a list of products. I wrap my main product screen with RepositoryProvider, which provides Product repository. Repository contains all logic i need (fetching, sorting, taking one item from item list with unique id, etc.)
Then, I wrap my page with bloc provider, and pass my repo by constructor, so now bloc whould have access to my repository. Bloc only manages repo to ui connection.
In my list of item i pass item's id, so if i tap on item, i can pass its id to another bloc, that does different logic (for example, opening modal page with description)
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 a student and very new in flutter app development and still trying to learn flutter. If I have more than one flutter application (As Backend in php, mysqli) and I want to merge in a single application so what I need to do, I researched so much on google but I didn't get any better solution, I want know:
is it possible?
is it very difficult?
what is the requirement?
It depends. You can do it as long as the resources don't conflict.
Everything is a widget in Flutter. An app itself is also a widget. You can take your whole app and put it inside of another widget. The problem is dependencies. Widgets are just lightweight representations of render objects, they declare how the UI looks (size, layout, hittest etc.). The data that populates them comes from business logic. So the answer depends on the business logic of the apps. It is possible if they don't conflict.
For example if there are two apps that creates a TCP socket with the same port, they will conflict. Another example can be Firebase. An app can not be integrated with multiple Firebase projects.
A working example could be multiple RESTful apps. Two apps that makes HTTP request to get data from the backend will not conflict. They will make seperate requests and have seperate states. It is just like having two pages that fetches different data from the backend.
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.
I am new to the BlOC style of programming (I usually use mobx, but I want to listen to a collection in firestore and it seems like BLOC is the best way to do this). After reading half a dozen tutorials, I am thoroughly confused. There seem to be API calls, repositories, providers, models, and (most confusing of all) blocs involved in even a simple todo app. I am making a chat app. All I want is a way to listen to the chat collection in firestore, and add new messages to the bottom of the listview containing messages when one is added. Could someone please help me with the bloc structure/code for this? Thanks!