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.
Related
The problem I'm dealing with is performance issues when needing to perform multiple Firestore queries in order to reach a result similar to to joins in SQL.
In my Flutter app, which uses Firebase and Firestore, I use Cloud Functions for serving my REST API. My API is the only thing that actually interacts with the Firestore database, not the Flutter app itself. I was always taught to design apps like this (not allowing the client to interact directly with the database) and so continued with that approach.
A potential solution I've seen are the official Firestore plugins for Flutter and have seen people designing their clients to interact directly with Firebase, however I haven't found any official documentation explicitly saying this design is preferred or even ok, and since it goes against when have been taught I haven't tried it yet. Can anyone confirm this or point me to documentation confirming this?
Edit
Perhaps it's worth noting that the reasons I've been told not to have the client connect directly to the database are 1. Security and 2. It would require business logic for managing data to be in the client and that should be handled server-side.
I'm working on a complex application using react-native, and I'm struggling on how to manage states and persist-states.
I'd like to achieve something like instagram, loading posts one time in redux and then save a bit of them in local-memory, to show something when the user open the app without internet connection.
Now to handle states across the app I'm using react-redux even if it cause some lag on react-navigation transition, and to save data locally suggest me to use redux-persist for low-complexity apps and realm for medium/hight-complexity apps.
What's exactly the practical difference between redux and realm?
(excluding the fact that the former doesn't persist when app is closed).
Is it right to use both redux and realm? If so what's the best implementation?
Thank you.
Please no useless question, I've been clear.
I am also working on messaging app (consider complex app?) and here is my answer to your question.
Redux is state management library and Realm is just database solution. I guess you are trying to say redux persist/asyncstorage. redux persist allows you to store key-pair value in your app while realm is way more efficient when storing large amount of data.
Yes, it is right to use redux and realm together. Redux is used as state management, managing all the UI state, while Realm is served as database to store your data.
Example (Messaging App)
When load messages from API, store it in realm directly.
Add a listener for realm, listen the data changes and expose them in redux state.
You may whitelist/blacklist your state in redux persist by destroy these state when you killed the application.
Here is my small explanation.
For my next flutter project,
Please suggest to me, which will be the best option to implement DB
Moor or ObjectBox
Thanks in advance
It mostly depends on the kind of data you'll be working with. Since the data I'm working with is all relational (stored in Postgres on the back-end) I use Moor. It requires some more setup to join and get the correct data together in the app, but the watch/StreamBuilder capabilities of Moor make it worth it for my use-case. If any data changes in the background, the UI will update accordingly.
If your data exists only within the app or your backend uses a NoSQL solution like Firestore, using NoSQL (Objectbox) to store the objects likely requires much less effort, and is probably preferred. See also this Moor FAQ remark about Firebase.
In the end, as with so many questions in computer science, the answer boils down to "it depends".
Note
I have worked with Flutter + Moor, I do not have experience with ObjectBox. I have worked with Firestore in combination with a React web app before.
As a beginner I need an architectural advice for following scenario.
My application writes a tiny amount of data and return a tiny query result to the user interface (from sqflite) for each user interaction (click).
There can be at least three ways to do so;
Future Provider (Most appropriate way as I see)
ChangeNotifierProvider & Future Builder
Using Flutter List and do all db operations in the background with using future-then functions.
I couldn't succeed on Future Provider and couldn't find a similar example. (almost all future provider examples are related with web services not sqflite)
Because of this I started asking which way is right or can be another way? Future Provider can be the most appropriate way if you say, I will focus on this.
Thank you very much in advance.
Best regards.
If you want to return query based on the user input, you need to go with the second option, i have personally developed a production level app using this strategy and it works like charm.
Here's the link to my github repository for that app, if you feel any difficulty in implementation you may ask.
Code that contains `ChangeNotifierProvider' for DateTime
https://github.com/asadamatic/Daily-Todo/blob/master/lib/main.dart
Code that contains Consumer for ChangeNotifierProvider for DateTime
https://github.com/asadamatic/Daily-Todo/blob/master/lib/Screens/HomeScreen.dart
You nay want to check out the app and see if you can relate to it,
https://play.google.com/store/apps/details?id=com.legacyllc.dailytodo
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.