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)
Related
I'm building a very simple e-commerce screen that shows multiple row of products from different categories (shoes, coats, t-shirts).
I wondering how should I use Cubit in terms of loading that products and pull to refresh them.
I'm thinking about having one Cubit that handles the data fetching of the entire page, but something in me tells me maybe to make a Cubit for every row of products in my home, however this is feels to much boilerplate.
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 need an advice concerning an architectural solution. My app has 5 screens that use information from the same JSON file.
(1) List of companies,
(2) List of companies on the Google Map,
(3) Detailed information about a company,
(4) Search of a company by name,
(5) Comparison of prices provided by each company.
The prices change every minute and can be fetched by a user.
Additionally, I have other screens, that do not depend from this first JSON data:
(6) favorites,
(7) about project, and
(8) one page that shows information from other JSON file.
Also, I keep in mind global variables for whole app such as:
language,
type of device.
What would you recommend:
1) Make 4 separate blocs for:
language and type device
5 screens that depend from the first JSON
Favorites
One screen that depends from other JSON
2) Make separate bloc for each screen
3) Any other more suitable solution?
Thank you very much in advance!
I'd create a separate bloc for each screen, but only if that screen has a logic. If a screen simply displays some info, like yours (3) Detailed information about a company, then bloc isn't required.
language,
type of device.
These aren't global variables, and can be accessed from BuildContext. For example, you can get the current platform by accessing Theme.of(context).platform
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.
The objective of this query is to know:
What are the alternatives available to achieve a scenario where for example there are 3 drop downs in dialog say country, state and city. Upon selection of a country, the items are auto-populated into state's drop down and similarly upon selection of a state by author the items are made available in the city's drop down.
What among these alternatives should be preferred and why?
Thanks.
There is no preferred approach towards this, the key factors to consider are -
What is the source of the information? Is information available in one go or multiple calls are required?
How is dropdown filtering achieved?
Is the information available in source hierarchical or independent which would require association logic?
What ever be the case you would need to implement your own logic to enable related behavior of the dropdown. This will be achieved by writing your own listener on each of the dropdowns. Outside the listener logic you will have to implement the enable/disable logic i.e. First dropdown is enabled by default but the subsequent dropdowns are enabled only on the prior dropdown selection.
Case 1: The information is available via related webservice call - In this case each drop down will make a service call and the filtering may happen based on passing the selection item from the previous dropdown (usually the case with country/state/city/zip logic).
Case 2: All information is available as hierarchical JSON or XML, you could implement path based selection logic where in options for the related dropdown is available as subtree of the parent selection.
Case 3: Information is not associative - In my opinion this is the worst scenario as you will have to write down the logic to implement information association and then relate it as Case 2 option.
If you have option of storing information, i would suggest to ingest the information as hierarchical structure in nodes forming an associated tree and then implement dropdown source as path.json (parent dropdown), path/.json as the first related dropdown as so forth.