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
Related
I'm kinda new to flutter web and I wanted to know what is a good, clean way of handling this problem. So consider I have a shop app and the customer has added some products to their cart, this data is saved in my state (I use Riverpod but I reckon it doesn't mater what state management is used). When the user reloads the page, the cart will be empty as expected (since all the states will be reloaded). I wanted to know what is a good way of handling this problem? Should I use cookies, shared preferences, hive, or something else? I just wanted to know what a more experienced developer would recommend. Thank you in advance for any help you provide.
Cookies are usually created by the server, while SharedPreferences is something client specific.
From an architecture point of view, you probably want the server to know about shopping carts (e.g. when the user logs in on a different device; to indicate that product might be sold soon; ... ). This however adds one more layer of complexity and I would only recommend this if you have a good reason for the server to know about it.
The simple straightforward path I would take for a private project is to save it in SharedPreferences. You can write a toJson and a fromJson function and save/load your cart as stringified JSON.
You can later still decide to move that logic to the server over the course of your application if there turns out to be a business need for it.
I have been working with flutter for a couple of months now and it seems that there isn't really too much to work on an app for back-end or advanced functionality. I love using Flutter to help me design the UI but I want to use another language to help me do some other stuff. For example, I want to display a full-screen camera page (almost like Snapchat) or like send a direct message to another user through the app. Do I even need another language to do stuff like this? I am not an advanced programmer. I just want to create simple applications that can process and store a little bit of stuff.
You can easily do the mentioned stuff in Flutter/Dart.
Check out Firebase Messaging for direct messages and SQLite to store information on user devices.
For saving data locally,
You can use SqlFlite, a plugin with the help of which you can easily store and manage your database.
For saving data on the backend, so that other users can also access it when necessary, like the one you mentioned in a comment (..food ordering app)..you can use Firebase
Firebase has all you need.
Link to firebase :- https://firebase.google.com/
When your data is stored on a cloud, you don't need to hard code anything, for example, about the food ordering app you mentioned, you can make use of variables, in which you can store the values. So that when the owner changes the price, it gets updated.
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.
I'm new to flutter/dart and I'm trying to create a little application using a Clean Architecture design.
I read some blogs and several presentations of Uncle Bob's Clean Architecture before starting to code to get the most of it and now it's time to implement it.
I guess my application could be divided in 3 main features :
authentication
classes (get access to lessons/quizzes on specific subjects)
admin (manage user, create lessons etc..)
I started to implement the authentication feature following the clean pattern, that's to say with a domain, data and presentation layer and I guess I did it quite well. It's (almost) fully tested (I'm trying to do some TDD) and seems to work as I wanted.
Now comes the problem. I want to implement the classes feature. I wish it could be independent of the authentication but it's not the case... The classes feature need to get the authenticated user from the authentication feature. I searched a lot on the internet but I can't find how to implement Clean Architecture with multiple features that need to share some data.
So there are my 2 questions:
How to pass data from a feature to another ?
How to inject dependency in a feature that need data from another feature ? (I used get_it for the authentication feature and inject all dependencies in the main() method before building the app. Since it did not need any external data it worked well. Now it's seem not possible to do the same for the classes feature since it first needs to get some data from the authentication feature).
Thanks in advance for your answers.
Along with your 3 features you should add another called core and inside that folder you can add stuffs that need to be shared. It worked for me . Good luck
One option is if you instantiate classes after the user has already logged in, you can pass that data in as a constructor parameter.
More generally, Provider is probably the best dependency injection tool for flutter. If you "provide" the authentication class to the widget tree for the rest of the app, you can say at any point below it, Provider.of(context) to access it and any public field it has.
Hope you're still working on Flutter projects after that long time.
I've been fiddling around with Uncle Bob's Clean architecture, and I managed to implement it in Flutter few months ago.
It's perfect, it separates your code into components (modules if you're coming from a native Android development environment) and isolates your data sources, so if you want to change the way you make API requests for example, you'll only need to change the remote data source part in your app, and all your application should work as expected.
I have made a test app using Clean Architecture I just uploaded on github and added a humble readme that describes the basic architecture and components of the app, I'll work on written articles describing the code very soon.
For now you can access the repo from here
I'm trying to find an answer to this for some time now... My solution was to create some transformation methods in the model class. For example, I have an ProductModel in the home feature file (from where i can add products to the cart), and an ProductInOrderHistoryModel in the order history feature file. So in the ProductInOrderHistoryModel file I have a method called toProductModel that gets an instance of ProductInOrderHistoryModel and transform to a ProductModel. That way I can add a product to the cart directly from my history order page.
Probably it's not the best solution, and the Uncle Bom would be really mad at me. But it was how I manage to solve my problem...
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.