If I have a Firestore database that I want to constantly be updating (and listeners in my code to constantly be responding to backend updates), should the code that's responsible for updating the database belong in the android app that will be available for download to other people? Or is it supposed to be somewhere else?
For example, the code for creating a document with user info within the collection "Users" belongs in every instance of the app that I publish, because I want every user using my app to be able to write their login info to the Firestore database after they register through Firebase Auth.
But if I have a different collection of data that I want to be available to all users using my app, and I want to be updating that data constantly, should I be updating it with code that goes in with my production level app, or should that be happening somewhere else? And if it should be happening somewhere else, where should that be/how should that be done?
I'd appreciate any help with this!
Never mind, I found the answer to my own question. Firebase provides users with Cloud Functions, which can run on the server-side to respond to new data events.
You might also be interested in Realtime Database, it will mean you don't have to write any of these listeners to the data and it does it all automatically. Check it out here;
https://firebase.google.com/docs/database/rtdb-vs-firestore
Related
I am using Firestore NoSQL for iOS application. While debugging, I occasionally executed setData instead of updateData, what led to lost of all the user data (one user).
Is there a way to reverse back the changes?
How to do Versioning for Firestore, for similar cases, so there's a way to cancel/ backup. I don't quite know, but I've read that it supposed to be Versioning.
There is no option to undo changes in Firestore. I'd recommend creating a new database (project) for testing purposes so you don't accidentally write on the main database. For now if it's just a single user then I'd recommend manually add that back.
Unlike realtime database, you can only have one Firestore instance per project at the moment so you may have to create a new project but I think that'll be safe to prevent such accidental writes :)
"You can use the Cloud Firestore managed export and import service to recover from accidental deletion of data and to export data for offline processing."
That's what I've found for now: https://firebase.google.com/docs/firestore/manage-data/export-import
I have no code but only a special question regarding Cloud Firestorage by Google.
Im using currently a listener for my Firestorage within my react-native-app which I also use expo for.
I know that as long as I stay in the app and tab out of the window, all data downloaded by the listener is getting stored in a temporary cache so when I come back to the screen with the listener, the listener doesnt need to download all data again but rather the missing sample.
My question would be: Does this also apply if I close the app entirely, for example for multiple days so that my token for authentification expires and I need to log myself in again into the app or rather into my Firebase?
(I want to prevent downloading all data the listener points to only because I restarted the app.)
As explained here the firestore persistance for the web is disk persistance so it survies App and devices restarts. Multiple days should also be fine.
I have a Web App tha is using firestore and very heavily offline capabilities. We never had issues with that.
I have a flutter application in which I need to update the list in realtime every time a new child is added to the database. I have tried looking for it everywhere but nothing is working. Please provide an example code to implement it.
Check out this post about CRUD operations with firebase. What you are looking for is basically the Read part. Using a stream to listen to the changes made in your firebase reference.
I am new to firebase and firestore and would like to know if the behavior I found is a bug or by design.
I am using angularfire2 in my ionic project where the user will be offline most of the time… so offline support is a big deal.
The problem: snapshotChanges is not called in a offline batch delete of subcolletion.
I have something like this in firestore /users/{userId}/projects/{projectId}/points/{pointId}
When a user inserts a new project or point a use set and the object is written fine, my lists are updated with the new instance and it works great thanks to snapshotChanges. When the user removes a project is the problem..
I execute a batch delete in the points of a project and after that I delete the project itself. This works fine online, but not offline. My lists are not being updated even though the operation completes with success. I could reproduce it multiple times, but only if the app is offline all the time ( the inserts and deletes are only local)
am I missing something?
The documentation states here:
Batched writes have fewer failure cases than transactions and use
simpler code. They are not affected by contention issues, because they
don't depend on consistently reading any documents. Batched writes
execute even when the user's device is offline.
This "Batched writes execute even when the user's device is offline" this makes me understand that the events of removal should be propagated to snapshotChanges.
I'm thinking moving an Android app's persistent data to Firebase Database. Currently I use Sqlite with a Python HTTP REST service.
In the app, I have a big list of cities, called citiesList. Since the list is quite big and hardly updated, I don't want the app fetch the list whenever it goes online.
My current strategy is provide a citiesListVersion. When the app goes online, it checks citiesListVersion. If the server's citiesListVersion is newer, the app will fetch citiesList from server. Otherwise, the app continues working with the cached data.
My question is: can I keep my current strategy when moving to Firebase Database? As I understand, Firebase tries to sync data whenever the app goes online.