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 2 years ago.
Improve this question
I am building an online shop app using Flutter, and I am wondering what is the best way to persist data after the user exit the app or when the app is killed. The data I want to persist is the cart information, which contains a complex structure.
It worth mentioning that I'm using Provider for state management.
I was thinking of the below approaches:
Creating a local file and read/write info from/to it.
Shared preferences
The new Flutter feature with RestorationMixin, (I don't know how to deal with a complex structure in addition to using Provider).
SharedPreferenceis the possible solution for you.
you can convert your object into json String by using jsonEncode(object) and save it in the sharedpreference and when you need back the object from json string you can use jsonDecode(string) to get your object back.
If you want to save the data offline. I'd suggest using sqflite. SQFlite is an sql database that will be saved locally on the device. It's easy to use and is persistant as you requested.
If you want to save data online in the cloud somewhere then I'd advice looking into Firebase (Google database, works really well with providers) or mongodart (MongoDB database)
Related
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 4 years ago.
Improve this question
I am building an app in Unity using Firebase Realtime Database and Firebase Storage. I need to add functionality in the client app that is triggered when a particular Storage directory is updated. The update could happen from the Firebase console itself, not necessarily from the client app.
I know you can monitor for changes of a database node, but there doesn't seem to be a quick way to monitor for changes of a storage directory. I could poll for changes, but it would be better to get realtime update.
Should I look into using Cloud Functions to update the database when the storage is updated so I can be notified in the client app? Or perhaps use Cloud Messaging? Please point me in the right direction.
Thank you.
There is nothing build into Cloud Storage for Firebase to inform client-side code.
The typical way to solve this is to write an update to the database whenever the file in storage is updated. That way you can keep an active listener on the database.
But sending an FCM message is also a valid option. Such a message is called a tickle, since it tickles the app to get it into action.
You could do either of those from Cloud Functions, or from within the application code itself. But if you also want to capture updates from the Firebase console, Cloud Functions is really your only option.
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 last month.
Improve this question
I am developing an app for keeping attendance records for the students and I am confused about using either SQFlite or Hive for the local database. What are the pros and cons of both? How does each perform in apps with smaller and more complex databases?
I am currently using Hive and it seems like a hassle regarding code readability.
if you want the saved data to be fetched instantly and you won't need complex queries or have relations among the saved entities then go ahead and use Hive since it loads its boxes (saved data) in the memory for instant fetching
otherwise use SQFlite as it's more readable, scalable, and customizable.
in your case and regarding the project you are working on, I believe you should go with SQFlite, maybe in the future you will add some other features not just attendance, and might need to make complex queries.
Both of them work great, but for both proper data modelling is essential.
However, I wonder whether your app can work without storing data externally. In that case, neither is a good option.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I'm new to Swift and I'm building on a simple app that relies on login/sign up functions for each user. When I wanted to learn about databases in Swift, I came across Core Data and from what I understood it's like cookies/cache that stores data in the user's phone. If that's so, what's the best way to connect the app to a regular database like SQL?
Core Data is an ORM (object-relational mapping) system. Overly simplyfied you build your data model entities and and relationships between them and Core Data cares about the rest. Under the hood it uses an SQLite database by default, but it also can handle other types of storage (e.g. binary or XML).
To answer your question, for Login/Signup purposes you should look into storing user data such as auth tokens etc. in the Keychain.
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 3 years ago.
Improve this question
Realm Database or MySQL or MongoDB or the standard Firebase.
I am curious why would anyone choose one over another. I am in a group project and one of the members in the group suggested that we should use Realm Database over Firebase. He tried to explain to me the reason but I was not able to comprehend.
What has your experience been like? Is one database more user-friendly over another?
Firebase seems to have very nice documentation.
Which one would you guys suggest?
Those are three different things.
Realm is a database for storing content locally on a device.
MySQL is usually used together with a web server. If you have a server and need to store data, you can use MySQL.
Firebase is Google's alternative for building your own server. It gives you tools that allow you to avoid having to build your own web server, such as Firestore, which lets you do CRUD operations directly from devices without needing to send that information through a server first.
If you works on small project you must going with MYSQL database. Its very simple and easy to understand. But if your project are big like that organisation type projects I recommend you to going with MongoDB.
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 7 years ago.
Improve this question
I have built an iPhone app that needs to pull data from a server. First I need to figure out what kind of server I will need. I'm a bit familiar with MySQL but was wondering if anyone had better suggestions on a backend. My app will have two tables that need to be populated by data residing on a server. Also, a user can submit data to this database which in turns populates the previously mentioned tables.
If you have any tips or tutorials, code snippets, etc. it would be really appreciated!
*Edit: I should mention this IS a remote database
Well if it's a remote server your thinking about then you should be looking into implementing some kind of service architecture like Web Services over SOAP or REST.
If the data stays on the iPhone than by all means use SQLite as it's fast and lightweight.
I would recommend starting with SQLite and local data first. Then when you have your main program logic, flow and UI complete, replacing the SQLite with Web Service calls.
Your database sounds really simple with just two tables. Perhaps you don't even need a SQL database. Perhaps a Berkeley DB would be sufficient. It has atomic commit, transactions, rollback etc. However you store data as key-value pairs.
However I am not sure if you can use it as a server. You could consider accessing the data through something like remote objects. This is done very easily in Cocoa. You could build a Berkeley DB on your sever that hosts the data as distributed objects that your iPhone app connects to.