I came across a wonderful feature of Firebase offline feature. I integrated that in my app just by writing one line of code in my main.dart file after initializing Firebase await FirebaseDatabase.instance.setPersistenceEnabled(true);
Question 1 :
I couldn't able to understand the database.keepSynced(true) function because without using this line of code, my app is persisting old as well as fetching new updated data, so what this exactly does ?
Question 2 :
How could I prevent the write operations when a user is offline, because I read that after setting persistence enabled, it makes a queues of write operations and update them when user gets online, so how could I stop this ?
Question 3 :
Is this persistence feature going to work in IOS device as well or need some permission settings first ?
Thanks
When you call FirebaseDatabase.instance.setPersistenceEnabled(true) you're allowing Firebase to create a local file on the device where it persists any data it's recently read, and all writes that are pending while the device is offline.
When you call keepSynced(true) on a node, you are telling the SDK to always keep that node synchronized. It essentially creates a onValue listener on the node without any handler code, so you're purely doing this to keep the data synchronized for when the device does go offline.
By combining keepSynced(true) with setPersistenceEnabled(true), you're specifying that you want the app to continue working when it's offline across restarts, and which data is needed for that.
If you call keepSynced(true) on the root of your database, you're telling the SDK to synchronize all data in the database to the disk cache. While this may initially be a quick way to get offline mode for your app working, it typically won't scale when you more people start using your app.
If you only want to allow write operations while the client has a connection to the database backend, you can register a local listener to the .info/connected node, which is a true value when there is a connection and false otherwise.
Note that Firebase doesn't require this, as it queues the pending writes and executes them when the connection is restored. In general, I'd recommend working with the system here instead of against it, and also trying to make your app work gracefully in the offline scenario. In many cases there is no need to disable functionality while the app is offline.
Offline disk persistence is available on Android and iOS, but not on web.
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 working with electron js and angular. And I want to use firestore database.
As far as I know, firestore is enabled with auto persistency.
First of all, will it work with my desktop application (node base / electron + angular)?
Second, let's say my application mostly works offline. And I need to do certain CRUD operations during these uncertain offline runtimes. So, if the first question's answer is yes, can I perform above operations in offline mode and will it sync as soon as the system goes online?
Third and last, if the answer to the second question is yes, then what if my system shutdowns that is desktop?
I will be glad for a detailed explanation of answers and a detailed explanation of how persistence works and is provided.
I am new to this channel. Please don't mind if I ask my question informally.
Firebase saves all offline actions to essentially an internal transaction pool for offline persistence. When Firebase does connect back online, it will attempt to sync all previous changes including transactions, document updates, and deletes.
The issue is the local pool wasn't made for extended offline use and over time, depending on how much data, it can slow the app down to handle all the data.
I've heard it should behave fine if the device is offline for about a month or two for general use but it might be better to support your offline app with an offline-first database such as PouchDB or NeDB and sync changes with Firebase as needed.
I was able to configure the Firestore database in Firebase with my flutter app and also create and read documents from my collection but when I go to Firestore console I don't see the created data, also when I creat data manually I am unable to see it in my application.
I am using the test mode which means any user can read or write.
I hope someone can help me with this puzzle.
Thanks!!!
It sounds like the device/emulator that you are running on is not connected to the internet, or at least not to the Firestore servers. In that case, the client writes all local changes into a local database, waiting to send them to the server when it gets a connection. So the local app will work, but won't be able to synchronize its local cache with the database servers.
You might want to check the connection on your device, and any proxies that might exist between your app and the Firestore servers.
Using
FirebaseDatabase.getInstance().setPersistenceEnabled(true);
Is this guarantee to download the data only one time across the App life/App restarts even if the user has good connection?
N.B: The official docs isn't clear ( at least for me) at this point.
By enabling persistence, any data that the Firebase Realtime Database client would sync while online persists to disk and is available offline, even when the user or operating system restarts the app. This means your app works as it would online by using the local data stored in the cache. Listener callbacks will continue to fire for local updates.
The sole goal of enabling persistence is to ensure that the app continues to work, even when the user starts it when they don't have a connection to the Firebase servers.
The client does send tree of hash values of its restored local state to the server when it connects, which the server then uses to only send the modified segments back. But there is no guarantee on how much data this sends or saves.
If you want to learn more about what Firebase actually does under the hood, I highly recommend enabling debug logging and studying its output on logcat.
For more on the topic, see these questions on Firebase's synchronization strategy.
I'm just getting started with the Firebase ecosystem and doing some investigating before committing to a GCloud database implementation (Datastore vs. Firestore). My target client is Web/browser and my backend services will be in AppEngine.
Tinkering with the cloud messaging quickstart example, it seems that FCM doesn't work in several scenarios (incognito mode, Safari, if permission blocked). However, the friendly chat demo that uses realtime db updates does appear to work in these scenarios.
High level could anyone explain why?
My goal is to subscribe to events for the client to update state, etc without the use of polling. It seems overkill to put these into firestore just to bypass the notifications permission requirements. Any insight is appreciated. These events could be dispatched from several different backend services and are not exclusively bound to db records.
Update
For what I wanted to do, I was able to simply use Firestore and had no needs that targeted specific devices that merited using FCM. Firestore came out of beta since I posted this question and works well for live subscribing to queries that update local state, which is ultimately what I needed to do.
The FCM client works on the promise that it can identify your browser, even when the page is not open. So it needs to persistently be able to identify the browser. It uses an Instance Token for that, which I assume it persists in the local storage of your browser. And since an incognito window has its own local storage, it becomes a separate instance ID.
The Firebase Realtime Database itself does not persist any information about the instance. Instead you pass in all the necessary information when you initialize the FirebaseApp instance, and then get a DatabaseReference. Since the incognito window runs the same code, it's accessing the same information in the database, and thus seeing the same result.
Note that this would be different if you use Firebase Authentication in combination with the Realtime Database. Auth will persist the user token to local storage, so that won't be shared with the incognito window.