Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 25 days ago.
Improve this question
I'm developing a flutter app, in my app I have a userData model to store data about a user. I then have a profile page where it is diplayed almost all of that data. I use Firebase to store those userData objects.
As I have it right now, I have a futureBuilder() for every widgets that needs data about a user, i.e I have a text() widget that displays the user name, inside a futureBuilder which the future is a method that retrieves the name field from firebase doc.
I was wondering if it was better to have the whole page wrapped in a futureBuiler which the future in a method that retrieves the userData object instead of a field at a time, and then build all widgets inside that futureBuilder.
body: Stack(
children: [
_profileBanner(), //futureBuilder
_whiteBackgroundContainer(),
_profileImage(), //futureBuilder
_userName(), //futureBuilder
_backArrow(),
_profilePageButtons(),
_reputationBuble(), //futureBuilder
_friendsAndGamesCounter(),//futureBuilder
_personnaInformationRow(), //futureBuilder
_divider(),
_biographyTile(), //futureBuilder
_sportsList(), //futureBuilder
],
)
Well yes, when you are working with APIs or remote databases in general you need to use the approach that uses the least amount of HTTP calls, in this instance if you can fetch the user data all at once do that and have 1 big widget "the profile screen" in a future builder and use the response to populate your UI
PS: avoid using functions for UI elements instead use stateless classes
I agree with Pierre.
This is a great example where Riverpod can add value where you save writing a lot of wiring and mgmt code. Ultimately it is up to you, and your app. But if you find yourself reading the same pieces of data in many places, having to keep all these places up to date when that data changes, consider a state management solution.
Unfortunately (or fortunately?) Flutter doesn't have a prescribed state management solution, so it is more of a pick your own adventure.
But if you increasingly run into these state issues, find yourself writing and maintaining glue code that has to get the same state, notify many places when that state changes, it's a sign that a library can help.
You can use Riverpod, Flutter Hooks, use a service locator like GetX and keep this data in a single place, whatever works for your solution.
Related
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?
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.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I have a complexe request to send to the server . In sumary i am creating a feed system
So in my request i use 2 tables.
First i start with the login user id and i pull all the other users he is following from a FOLLOW table .
So now I have the logged in user plus an array of other user he is following .
Second step is i use a FEED table the complexity is i would like to pull all the action from this table that are eitheir performed by the main user or the following users.
I am using Graphql for all my other request ... however for a complxe request like this one . I am thinking that REST is more suited
I would like to know your thoughts
There's no such term as better. It all depends on what you need, what your architecture is and after all, what you know to use better.
GraphQL is great for such complex request because you can return exactly what you need and nothing more. So if you're asking if GraphQL can handle it, for sure it can!
Where is this complexity?
You can use one graphql query - user{followers{feeds{action.. and user{feeds{action... - both action arrays will be available in Apollo.
You can always combine results from these 2 arrays into one on client side from [normalized] Apollo cache [for some component needs]. You have both sets separated as they are separated in reality and universal for future needs/other app/client/admin.
If you really want/need it combined serverside just add user to his followers in resolver for query like user{userAndFollowers{feeds/action... - it can be done beside main/separated schema, just by adding additional 'branch'.
It always depends on details ... but REST better? in witch version/convention/'standard'? good joke ;) - no offence, tons of pro/cons/comparisions everywhere ... try/read/choose suitable to requirements.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
Within Delphi Seattle, I am using the Delphi Rest components to retrieve data via REST services. My data provider appears to limit results to 1000 rows at a time, meaning I need to use pagination. I know a pagination URL is returned in the REST data stream. So a couple questions...
(1) Do the Delphi components support a GetNextPage (or something similar?). If so, I could not find it.
(2) How do I retrieve the URL to get the next page? Do I then update the TRESTRequest resource property and EXECUTE again?
(3). I am using a RestResponseDataSetAdapter to access this data (via DataSource and ClientDataSet). I am assuming that there is NO WAY to "combine" the data results from multiple REST calls. For example, if I retrieve 1,000 rows via my first call, and 300 rows via the second call, there is no way to access all 1300 rows at the same time?
I have looked on Google, as well as REST documentation and did not find anything useful. Any help appreciated.
There is no single standard way to implement pagination, as different Web/REST servers implement it in their own way. It's next to impossible for these components to have built-in pagination options covering any and every possible scenario.
Whatever service you're using should provide you details of how to implement pagination. Usually, this is part of the query string. For example...
http://someserver.com/someresource?pageSize=100&page=1
...or sometimes perhaps in the resource...
http://someserver.com/someresource/1/
...or sometimes in the HTTP headers...
Page-Size: 100
Page: 1
I've also seen some servers which provide a URL in their response, pre-defined and ready for you to use to navigate to the next page of results...
{
"next_page": "http://someserver.com/someresource?pageSize=100&page=3",
"prev_page": "http://someserver.com/someresource?pageSize=100&page=1"
}
But again, every server is different. I've never seen any two REST servers which follow the exact same rules as each other.
You will just have to read the rules as instructed by this service, and implement your pagination in each and every request, as you need.
That being said, whenever I write any sort of API wrapper, the first step is to establish a standard communication layer, which implements anything which is common across all requests available on that particular service. Here, I would add pagination options, working according to how that service was designed.