If I get a push notification on iOS, I want to pull some related data from the Firebase database in the background, so my user can read their articles on the train.
I'm getting the appropriate onDisplayNotification event, and it's reliably triggering, but when I query the database, it doesn't load the relevant data until the app is foregrounded, by which time the user may be offline.
As I understand it, this is a deliberate aspect of react-native-firebase to prevent the app from consuming a potentially huge amount of resources in the background of the application.
So how can I retrieve entries from firebase.database() when my app is backgrounded?
Turns out this is a bug in version 4, which causes the OS to smack firebase down for being greedy.
Follow https://github.com/invertase/react-native-firebase/issues/971 for progress.
Related
How would you combine / solve the two diverging approaches of:
rtk query / graphql advising to only fetch what is needed on that screen
offline first capability
in a react native app?
Basically apollo and also rtk-query advise for small queries that are only fetching data that is relevant to what the component needs. This would mean that all data is only present when rendered, but what happens when the user does not have internet?
We don't want the user to see outdated data if they haven't visited that screen for a long time so we want to fetch this in the background and never show loading spinners. When they are offline everything should be as up to date as possible and usable.
Also mutations should be queued and performed when internet access is restored. The app should basically behave as if there is no connection issue at all.
So probably a graphql subscription would be ok but everyone strongly discourages to the subscribe-to-anything-pattern. Subscriptions in graphql still sound like they should be small and also only care about what is rendered on the screen and unsubscribe when the screen is unmounted.
At this point this whole seems like a graphql anti-pattern to me, but from a user perspective it makes sense for a (react) native app. You want stuff to be up to date because it is an app not a website where a lot of data is cached anyway and timeliness doesn't matter that much.
We are building an app for our teams out in the field that they collect their daily information using Firebase. However one of our concerns is poor connectivity. We are looking to build an Online/Offline button they can click to essentially work offline for when things slow down. We've built a workflow in which we query all the relevant information from Firestore.
I wanted to know if there was a way to tell Firestore to work directly on the cache only and not try to hit the servers directly. I don't want Firestore attempting to make server calls until they enable online again.
You shouldn't need to do this. If you use realtime listeners, they will already first return the data from the local cache, and only then reach out to the server to check for updates.
If you are performing one-time reads, the SDK will by default try to reach the server first (since it has only one chance to give you a value). If you want it to only check the local cache, you can pass an argument to the get call to do so.
You can also disable the network completely, in which case the client will never call on the network and only serve from the local cache. I recommend reading about that and more in the documentation on using Firestore offline.
I'm building a ReactNative app using Firebase Firestore.
But I want my app to have some initial content as soon as the app is opened for the first time, even if the user has no internet connection.
I know that one way to do it is to fetch the content at build time and embed it in a JSON file that will be read by the app when it's first launched and I can write down the initial content into Firestore using batch write before the initial render (or at least keep showing the splash screen while I'm on it).
I wonder if there's a better of doing that, maybe something recommended by Google or the community, but I couldn't find anything.
Firestore doesn't support any notion of initial state or database contents, nor does it support writing to cache in such a way that the written data does not attempt to synchronized with the server. What you're trying to do can only be implemented by packaging the initial data by some other means, and checking to see if that data should be queried before Firestore.
I am using angularfire's sync arrays and the javascript SDK of firebase.I need to download about 5MB of data to fill my array so the app could work offline for a short time if it loses connection. I am afraid that the way I do things, the size of this array can easily bring me a high bill at the end of the month.
What if the user refresh's or starts and stops his/her app 100 times a month? What if 100 users do it? Is there some way to cache the array offline and only apply changes to it after I refresh the app?
I suggest that you take a look at AngularFire Offline which I am using for a similar use case within an Ionic hybrid mobile app and so far it looks to handle things well.
I've build a library-style SQLite iOS app using the code in the Recipes sample app, and it works - updates on one device are (eventually) reliably propagated to all other devices running the same app. I've been testing it with multiple events per hour all day long, and all the log transactions do get to every device. However, the time for the updates to propagate is highly variable. If I bring the app up and let it sit, it could be a relatively long time before the cloud sends update transactions to the app, and so what's on-screen remains old data for that same long time. Worse, there's no indication the data is out of date.
If I cause the app to post a change to the cloud, though, updates from the cloud propagate down relatively soon. That suggests that I could put in a hack that periodically posts pointless changes to the database, but even then I won't know if I've received all the changes.
First question: Do methods that will force transactions to propagate exist? a This thread suggests not.
Second question: Is there a way to detect if the local database is out of date? I don't want to tickle the cloud copy incessantly, but doing so now and then until the database is current might not be such a bad idea.
1) if you find such methods, please let me know.
2) same stuff here. I didn't even find any reliable way to detect whether the currently running instance of the iCloud app is not the first instance i.e. other instances have already sent updates to the iCloud until the first push received (which can take some unknown time)