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
Related
I have a working PWA application and i have tried integrating push notifications to it which worked. But those notifications happened totally in the front end, a user has to click a button and a push notifications would show up.
In my application i have a cronjob that runs every night to check if certain things are updated. If so i want to send a push notification to a user to notify them.
But i cannot find any information regarding this subject so I'm thinking it's not possible since the nodejs server doesn't have a connection to the PWA. Is there something I'm overlooking on my approach or is it simply not possible?
I am coding a vue.js app using web pushes with Firebase Cloud Messaging and I wondered if it was possible to send a web push to a user and in case the user was offline, to somehow store it for later display when the user opens the app again. Is there a principled approach to this problem, i.e. managing web pushes when the end user is offline?
The reason I am asking this is that, so far, all the web push notifications I've committed to FCM server with tokens of offline clients (i.e. desktop browsers) went into oblivion. To be sure, FCM didn't try pushing the notification again when the clients went back online.
For this reason I am considering coding a self-made dispatcher to manage web push for offline clients, but I need to make sure my efforts are worth it.
updated: I am now able to display notifications sent to an offline client after coming back online using appropriate time_to_live values. However, only the latest notification is displayed. How is there any specific reason why?
FCM's default behavior is exactly like that. From the docs:
If the device is not connected to FCM, the message is stored until a connection is established (again respecting the collapse key rules). When a connection is established, FCM delivers all pending messages to the device.
I am in the beginning stages of developing a react native mobile application. I wanted to get insights on the following on a conceptual level relating to the below.
Say the application goes into the suspended state (as mentioned here) at which point there is no application code being executed. Subsequently, the server sends a push notification based on some changes to the data. It seems that (at least on IOS) there is a way to use push notifications to initiate a download in the background. My questions are:
Is there a way to initiate this download in react native post a push notification when application is suspended?
Is there a way to synchronize the Firebase data with the application post such a push notification while the application is running in background if (1) above is possible?
Any hints on these will be of great help. Thank you.
I have a xamarin forms project that uses an azure mobile service with offline sync. The iOS client is working perfectly in that it can save things locally and sync in the background. The context of my app is a game scorekeeper. So, there are two players involved both scoring on the single device.
What I would like to happen is for the "visiting" player or the player who doesn't own the device in use (ie not the primary user) to have their device sync when new data is pushed from the device in use.
Device A pushes new content, Device B somehow knows to pull new content.
This could open the door for each player to score on their own devices in a future version.
Anyway, the question is how do I tell device B to pull? Do I use APN type notification and that triggers a sync, or SignalR to tell it to sync?
The best approach on sync scenarios like this is to have your background sync process going at set intervals but then also trigger your sync process from a specific Push Notification.
If you send a Push Notification with a "special" payload (i.e. meaning something that just means to sync to your code). Then start the sync once the device receives that.
This article might help with Azure Push Notifications with Xamarin Forms: http://www.xamarinhelp.com/push-notifications/
I have a Worklight app doing push notifications. Sending the push causes the notification to appear in the notification bar on both Android and iOS as expected. If the push is received while the app is running, it calls the message handler function as it is supposed to.
The issue I'm having is that if you launch the app by tapping on the notification on iOS, the message handler never gets called if another push is sent while the app is running. I have to exit the app and kill it completely, then relaunch the app from the launcher. Then if the push is received while the app is running, it will call the message handler.
This only occurs on iOS. The app will respond to a received message on Android while the app is running, even if the app has been launched by tapping on the notification.
EDIT:
I did struggle to verbalize the scenario, couldn't find the right words that made sense, but the steps you have done Idan are largely correct for what I'm trying to do. We are doing tag based notifications, so that is different that what you have done. We are also using PersistentCookieAuthentication as they wanted push notifications to be sent without the user having to explicitly logging in.
We are currently using WL build 6.2.0.01-20141216-0427
We've tried it on a couple of different models, an iPhone 4s running 8.0.2, and an iPhone 5 running 8.1.2.
Edit based on the edited question:
Tag-based notifications do not require any login, as it is the device that is to be subscribed to any tags that you define in application-descriptor.xml; it is not login-based, so any type of login that you are doing it irrelevant. The push will be sent to any device (app...) that was subscribed to your tag using the subscribeTag API.
I did another test in iOS using a broadcast-based notification (it's basically like tag-based notifications). I kept the app in the background and sent a notification. Tapping on the incoming notification in the notification bar brought the app to the foreground, which then displayed the alerts of the incoming notification.
You can try it with this application: https://www.dropbox.com/s/l2yk2pbvykrzfoh/broadcastNotificationsTest.zip?dl=0
Make sure to place your own .p12 certificate and pushSender password.
I've been trying to understand your scenario... I suspect you've left out something or need to better word the problem description.
Here's what I've tried using MobileFirst Platform 6.3 (no drastic push changes in iOS between 6.2 and 6.3) and iPhone 6 running iOS 8.1.2.
Launched sample push notifications app (which uses event source-based notifications) on device
Logged-in > Subscribed
Quit application
I then sent a notification by invoking the adapter in the Studio
The notification arrived and displayed in the notification bar
Tapping the notification launched application
Logged-in
The notification alerts were then displayed.
I then moved the application to the background.
Sent another notification, which was displayed in the notification bar upon arrival
Tapping this second notification brought the application to the background, displaying the alerts
I then kept the application in the background.
Sent a third notification
In this case, because the application is in the foreground, the notification did not display in the notification bar -- as expected -- and instead the alerts were displayed right away.
If your scenario is different than the above, such as: you're not even using event source-based notifications but rather broadcast- or tag-based notifications, or your application flow differs, etc then please edit the question with a more precise description.
When you edit the question, also mention the following:
Worklight version and build number
Device model
Used iOS version
I am aware of one possible issue (APAR #PI31988) that is currently under investigation, where the underlying native code dispatches the message before the JavaScript framework is ready to handle it, thus no message is displayed. This was found to happen in slower devices such as iPhone 4.