I have an app that I'd like to send push notifications to. But I understand that if I've shut down the application (especially on iOS at least until iOS 7) that push notifications won't launch it (either in the background or the foreground).
I understand the PushKit framework has been added to iOS 8+, and that one of the things it can do is cause an application to launch in the background (and I presume handle my push notification).
Is there a way to trigger this functionality in FireMonkey? Does the same sort of functionality exist for Android as well?
Related
I have noticed that when I send a push notification (Firebase Messaging Service) to my device my Application object is created. This is without clicking on the notification. Simply the act of viewing the notification creates the application. Further, it also starts the Jetpack AppStartup library. I want to be able to use AppStartup and application create. But I don't want to launch that code when a push notification occurs.
Why does Android do this? Is this part of all android notification, or is it a feature of the third-party push notification sdk I am using? And is there a way in Application.create and AppStartup to distinguish a normal app launch from a push notification triggered launch?
Again, I'm not talking about the user clicking on the notification (and launching the app because of a deeplink). I'm talking about just looking at the notification in the notification dropdown.
Why does Android do this?
Android is starting your app process to run code in your app. Creating an Application instance and calling onCreate() will be part of that, as will creating any ContentProvider objects. IIRC, Jetpack Startup uses a ContentProvider to get control early in your process, though I am not 100% certain of that.
The reason why Android is starting your app process is because your app is causing the Notification to be displayed — specifically, Firebase Cloud Messaging is doing that. If I remember the protocol correctly, Play Services is sending a broadcast Intent that Firebase Cloud Messaging in your app will respond to, and part of that code will be displaying the Notification.
And is there a way in Application.create and AppStartup to distinguish a normal app launch from a push notification triggered launch?
onCreate() of an Application subclass has no means of knowing what specifically caused the process to be created, as there can be many possible reasons. If by "AppStartup" you mean Jetpack Startup, I do not recall it having any options here, but I have not spent much time with its API.
We have a pretty common usecase with our (via Capacitor) Android generated app:
Once it receives a message via e.g. a Websocket (or third party apps like OneSignal, Firebase etc) we want to bring the app to the foreground in case the user is currently interacting with other apps (like Skype, Whatsapp etc). The reason is that we have implemented an "Alarm" scenario and if an alarm comes in, the app should come to front and show what's going on. Simple push notifications won't do the job here.
So we researched on the topic but as we're not native Android devs, we don't understand the full picture clearly.
e.g. Android bring app to foreground on Firebase notification suggests that via FLAG_ACTIVITY_REORDER_TO_FRONT it is possible to bring an app from the background to foreground.
The question is how is this going to be implemented in a hybrid app scenario (like with Cordova/IONIC/Capacitor).
In our app we are pretty far to listen to API signals via Websocket. Once an alarm is received we are able to send a signal to the App via Websocket so we can do pretty much anything. We could for example redirect the signal from the webapp back to the app container.
The question now is how can this scenario be solved either via Websocket or Firebase (FCM) and is it possible to solve it straight through the IONIC architecture?
In a cordova/ionic hybrid app I would use the cordova background mode plugin and the window_system_alert permission plugin. Those two are what I'm using and its working like a charm.
The steps I'd follow:
The first one was to include the force-start to the notification body
The second one was to give permissions to the app to be drawn over other apps. I managed to to this using this plugin: https://github.com/wryel/cordova-plugin-system-alert-window-permission. It requests the SYSTEM_ALERT_WINDOW permission.
The last one is to install the background-mode plugin (https://github.com/katzer/cordova-plugin-background-mode) and whenever you receive a notification you wake up the terminal and show your app in foreground (enable -> unlock -> moveToForeground).
Please, let me know if I misunderstood something and I can change my answer.
We have been trying for the last two weeks to get a reliable solution to try and sync our app data with a server in the background. We have tried the Background fetch mechanism but due to the iOS restrictions on when it runs it is not a viable solution.
iOS does provide Remote Notifications (https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/pushing_background_updates_to_your_app?language=objc) that we would like to use as we can use the same mechanism on Android.
The issues is that when sending a type 2 notification CN1 only delivers the notification when the app is brought to the foreground by the user.
On Android I see there is a Build Hint for android.background_push_handling that allows the notifications to be sent to the app even if it is in the background.
Is there a similar build hint that we can use for iOS?
If not, is there a way then to override the application:didReceiveRemoteNotification:fetchCompletionHandler: method that fires when the Notification arrives so that we can forward it to our app?
You can use silent push notifications for that purpose. To send a silent push notification you just have to include "content-available" : 1" into the body of the notification. More info on that here: Apple docs-silent push notifications
You should bear in mind that this will only work when your app is in the background, it won't work when the app is killed. When the app is killed the only solution is standard push notifications, unless your app has VoIP functionality, in which case you are allowed to use PushKit framework (if you use it in an app without VoIP functionality, you won't get pass the AppStore).
I have developed a chat App in Android using Firebase which has the concept of blocking push notification when my device is in lock condition. For this feature, I required to implement Foreground service because as soon as the user unlocks his device, the device receives the blocked notifications or all the blocked chat messages.
Now, I want to develop the iOS version of this App using the same Firebase but I'm not sure if I can hold the notification like the Android if my iOS device is in lock condition (with App not running in the background). So, is this feature is feasible in iOS and if yes then how I can achieve this ?
Thanks in advance
From my research, you used to be able to register for a specific Darwin notification, com.apple.springboard.lockstate . However, Apple is rejecting apps for this practice as the API is not public.
If you could explain why you’re attempting to catch notifications while the device is locked.
A thought: perhaps a silent push could be of benefit.
I'm developing viber like application using the ionic framework.
I want my app to be able to receive calls even when its on the background, just like whatsapp, the incoming call screen will pop up even if whatsapp is on the background or even when there is no instance of it at all.
I wasn't able to find anything about it.
I'm afraid there's no other way to achive this, then using Google Cloud Messaging (GCM). Although there may be other services that do the same.
When using GCM, your app will be notified with a notification even if it is not running.
But be careful! As your using Ionic, you will most likely rely on a cordova plugin to receive the notifications that are pushed to your device via GCM.
It depends on the chosen plugin how it handles the incoming notification.