I'm implementing Push in a Xamarin Forms PCL project, and I'm having an issue with iOS.
If the user is actively using the app I want to display an alert to let them know they have received a notification and let them choose to View it (which changes the current page) or cancel.
If the app is not active, either in the background or not running, I want to go directly from the tap on the iOS notification to the notification page - no alert. I have this working if the app is not running.
If the app is running, either in the background or active, the RecievedRemoteNotifications function is called which will display the alert. I don't see a way in RecievedRemoteNotification to determine if the app was already active or if the user tapped the system-generated notification.
Check out the ApplicationState property from UIApplication.SharedApplication.
More information about the possible values here. There is a Background state.
Related
I have an iOS app with notifications working using the necessary delegates (DidReceiveRemoteNotification etc.) I have some user preferences set via Xamarin Essentials Preferences.
I'm looking a way to stop the delegate from firing depending on the preferences set. (i.e if the user has Preference set to get notifications about subject X, they receive the notification, but if a notification about Subject Y comes in, the notification doesn't fire).
I can't determine a way to stop the methods from firing.
My app uses push notifications (Ionic Capacitor) and when I enter the app I use getDeliveredNotifications() to get all the notifications to display. This works great if the user clicks on our App icon but when the user clicks the notification banner I get an empty array back.
Its like the notifications get wiped before getDeliveredNotifications gets called. Any thoughts on what I might try to fix? I checked this on Android and it works as expected...
I'm trying to implement Firebase Cloud Messaging in a web-app (with Polymer and a service-worker and using the custom-sw of the SDK).
It is working great (on both desktop and android) but when the user click on the notification it is always opening the click_action in a new tab even if a tab of the same origin is opened (but not focused).
click_action = "https://example.firebaseapp.com/demo/command"
Url of inactive tab = "https://example.firebaseapp.com/demo"
It seems that the getWindowClient_ method of the FCM SDK is not parsing correctly the URL of active clients and so can't call focus() on the inactive tab.
Any idea how to resolve this ?
That is how it is designed. It caught me off guard at first, but after I thought about it, the new tab/window made sense.
1) the service worker is a separate process from the browser.
2) when a notification displays it is not associated with a browser tab/window.
3) changing the url in an existing window would most likely confuse/irritate the user.
When the user clicks your button the notification assumes no active tab on the origin. So it opens a new window.
Is there any way we can sync notifications with action center in Windows 10? Below is the scenario:
The Windows 10 UWP application I am building has the UI to see all the notifications user is receiving to the app. (I am using the background task to listen to raw notifications and saving to local xml file and show it in the app UI). Now, the requirement is there are many options to user to dismiss the notification. Means, From action center:
By clicking the x icon on individual notification.
By clicking on App title directly.
By clicking "clear" next to App Title.
By clicking "Clear All" on top of action center.
In either of the above cases, I need to delete the notifications from the App UI I am building as well. Can anyone help Windows 10 SDK has the support for listening to it when app is either in foreground running or not?
thanks in advance.
I suggest you to read Notifications History with
var history = ToastNotificationManager.History.GetHistory();
and compare with your app's data. If notifications are dismissed from action center, then you cannot find them in the history, so you could delete them also from your app.
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.