Does firebase have a native way to check if the app has the latest data on the second load?
Here is the app workflow.
When the app loads I get data from firebase and display it to the
user.
Data is also stored locally to be displayed later.
The user closes the app and the reopens it sometime in the future.
How do I check if Firebase had new data and get it only if it has?
What I am doing is that I am storing a TimeStamp on my device and on the database. On each app load I check if the TimeStamp matches.
If it does then I display old local data otherwise make call to get latest.
Is this the correct way?
Basically what I am asking is I want to display locally stored data, but if firebase has new data then I want to get it and display that.
Related
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 am building an android app, I remember i open the realtime database a day ago but really can't remember if I added any data before pausing the work for some rest. Now return the the firebase web console to view the database (if I did create any) or create a new one. Now the database tab doesn't show any data and if try to create one it shows that "An error occured, null" as in the screenshot image attached. Please any ideas on what to do?
I am new to Flutter and mobile development in general and currently trying to wrap my head around certain database principles. I am building an note-taking app which uses Firestore for storing note data to the cloud. Users first need to register an account and log in, after which they are able to view and store notes to the cloud. The way I initially designed this was by using StreamProvider connected to the Firestore instance to update the user's list of notes after they add a note to their list.
After some reflection and worries that my app would be 'read' intensive, I realised that what I am trying to build does not require the notes to be constantly fetched from the server, as the data is private to them and should only be fetched by the user that creates it. My solution is instead of creating notes and listening to changes on the Firestore server to update the list, when a user creates a new note, a function should run and update the Firestore server as well as a local nosql database, removing the need for a read operation on the server after writing to it. This would allow me to have a local duplicate copy of the Firestore server and to periodically update it with write operations when needed. The only read operation would be on the app's startup to fetch a copy of the Firestore server.
My questions are:
Is storing a local version of the Firestore server a viable solution to minimise the number of read operations in my app, or am I overcomplicating things?
The StreamProvider allowed me to easily access data relating to the user, notes, etc throughout the app using Provider.of<Model>(Context). How can I easily access this data regardless of where I am in the app?
Given that my Firestore database structure for accessing notes is users/{user.id}/notes/{note.id}/note , how can I get a snapshot of the current logged in user ID and all the child fields in a single request (i.e. all the user's notes in users/{user.id}/notes and user data under users/{user.id}/)
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
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.