I am having a problem under the following circumstances:
1. Running a webapp with both firebase sdk and angularfire initiated connections
2. App has been running in background. Meaning user has launched other apps. During that time, internet connectivity could have come and gone.
3. User brings webapp back into foreground as active app. Firebase connectivity via angularfire has been lost and updates have been lost as well. Hence "2way" binds to existing views/controllers are not longer current and will not re-establish/sync. Only recovery is to actively kill the app and restart.
This is obviously undesirable. I have currently attempted a bruit force method where I am issuing a goOnline() call at the beginning of each of my controllers in an attempt to always try to re-establish a connection but for services that expect a 2way bind, I am not sure that everything will sync up?
Any thought or guidance on this would be very helpful as this is a serious issue.
Related
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.
If I have Ionic 4 app that uses the firebase JS SDK (AngurlarFire5) with firestore's offline persistence enabled, what would happen if there are pending requests and the app get closed either by sending it to background or completely closing it? Would it sync when re-opening the app or the pending requests/data will be lost?
The way offline persistence works on all platforms is like this. When data is written, the write is committed to local storage before it's synchronized to the server. Eventually, when the app is running and it's able to connecto to Firestore again, the writes will be synchronized. Killing the app doesn't change this behavior. It just delays the sync until the app is launched again and is able to connect.
I am looking for a solution to fetch geolocation periodically (every 1 minute) on mobile browser. I did some research and came to know that fetching geolocation in background (when phone is locked or webapp not active) is impossible. In foreground it works ok.
I am making a web app where I fetch user location and send it to my server. All works ok, until the point where user locks his/her phone. I tried many things for workarounds:
setInterval to get geolocation, works fine in foreground but fails in background
converted my web app into Android using cordova, but same problem existed
used https://github.com/mauron85/cordova-plugin-background-geolocation this plugin for android
works good in both foreground and background
but the same plugin does not work in iPhone (I did not tested it, I searched in Google before moving ahead)
Its not good to release my app with just one platform (android) support, thus this workaround also failed for me.
I also considered using serviceworkers for my web app but it seems issue persist for background
https://github.com/w3c/ServiceWorker/issues/745
I have another solution in mind, but before investing time in it, I wish to know if someone has tried it already.
I learnt about Push notifications:
Web app client registers to Push notification
It sends
subscriber object to my server
My server using this object sends
message to Push notification server
Push notification server
sends messages to my web app client
My web app client wakes up my
service worker for a brief period to show the notification message
As per google documentation:
Note: In the current implementation
of Chrome, whenever we receive a push message and we don't have our
site visible in the browser we must display a notification. That is,
we can't do it silently without the user knowing. If we don't
display a notification the browser automatically creates one to let
the user know that the app is doing work in the background.
I won't mind showing a permanent notification to users until my app is running. I am ready for this trade-off.
Now, my question is, at step 5, when I wake up the service worker **is there a chance I call my main.js (main web app) which might be running in background **, will fetch the geolocation and update it to my server?
Has someone tried this solution already with success or failure, please inform.
Can you try Page visibility Api, which listens for visibilitychange of a browser tab is hidden or switched to other tab (in case of browser). For mobiles, it's just a try.
src : https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API
or You can look into this answer too..
Detecting when screen is locked
I have built an application with Firebase and I've also made a desktop version available with nw.js. The point of this being to allow for better offline usage in areas with bad or no internet (and it will sync when the user gets internet again). Now, I can disconnect just fine and reconnect while the app is running, but I want to be able to fully close and reload the application. I've seen this blog post from firebase, but it appears this only works for mobile platforms.
Is this currently possible on the web platform, too?
All Firebase SDKs will handle intermittent loss of connectivity (driving through a tunnel). But disk based persistence, which allows the data to survive an app restart, is currently only available in Firebase's iOS and Android SDKs.
I have built an application with Firebase and I've also made a desktop version available with nw.js. The point of this being to allow for better offline usage in areas with bad or no internet (and it will sync when the user gets internet again). Now, I can disconnect just fine and reconnect while the app is running, but I want to be able to fully close and reload the application. I've seen this blog post from firebase, but it appears this only works for mobile platforms.
Is this currently possible on the web platform, too?
All Firebase SDKs will handle intermittent loss of connectivity (driving through a tunnel). But disk based persistence, which allows the data to survive an app restart, is currently only available in Firebase's iOS and Android SDKs.