Executing actions when notification is received with background/killed state app (iOS)?

[TommyLeong]

Anyone.. quick check with people who's working/worked with push notification. My backend is sending Data-Only message.

Sample payload received from server

{
    aps =     {
        alert =         {
            body = "msg";
            title = iOS;
        };
        sound = default;
    };
    deeplink = "myapp://profile";
    "gcm.message_id" = maskedData;
    "google.c.a.e" = 1;
    "google.c.sender.id" = maskedData;
    mediaType = image;
    notificationid = "maskedData";
}

For now, my method setBackgroundMessageHandler is not called when banner (notification) kicks in when app is in Background/Kill state. This happened because my payload does not contain contentAvailable: true I guess, since it's stated here 😖

Anyway, my app will show the banner notification (in both Background and Killed state) still but no code is running behind the scene when app receive banner notification. Meaning if the user decides to open my app without tapping the banner, I'm unable to store the notification content hence user will never see the notification content in app.

Unless he opens the app via the banner (notification), my app gets the notification content. Hence I'm able to do certain processing behind (storing content, append into my notification list)..

My questions:

• How can we wake the app and does certain processing (store content, etc) as soon as notification banner is received?

• How can we update Badge number when app is in Background/Kill stated? (I planned to do it via the "behind process" as well when notification is received. But for now, I don't get notify until user taps the banner)

Of course, here goes my version "@react-native-firebase/messaging": "^7.8.4",

[TommyLeong]

@mikehardy maybe? 😅

[mikehardy]

For precise discussion I/we really need to see the exact JSON you post, and the exact steps you took to interact with the phone to get it to the state you describe. I find the "background/kill state" description to be imprecise as I recognize those as two different states in the iOS application state progression

[TommyLeong]

Hmm.. I thought I have given quite some detail information. Apparently it's not. Well, the JSON payload is exactly what I have received. I'm using the "background/kill state" here because I understand both the states are handle by the method setBackgroundMessageHandler

For steps, I don't have much to tell actually. Very straight forward...

[Background state]

1. Deploy my app on Physical Device (iOS 12.1.2 - iPhone7)
2. App runs.
3. Tap on home button
4. Push notification from backend website portal
5. App received notification banner (Console.log has nothing printed, there's no code running behind)

• At this stage, if user decides to open the App by tapping the app icon. He will not see the notification banner in my notification listing screen.
• However if user open the app by tapping on the notification banner, he will see the notification banner in my notification listing screen.

[mikehardy]

Quit != kill. Those are distinct states and the table should really have a 4th column called "Force Close / Kill" where the user has swiped the app away. It's a distinct state from Quit and in Kill / Force Close nothing works. So I am specific with my words yes - pursuing wakes-up-on-messages solutions for "kill" state is fruitless

I see you aren't swiping the app away though (thanks for providing the steps) so you are likely in the actual "Quit" state, so there is potential.

I don't want to discuss an FCM pushed from the portal. I want to see the JSON, use a curl script and POST JSON to the REST API endpoint provided by FCM, that's required in order to have a precise discussion and control your testing. Of course do not post the API keys or device token, but the JSON is critical to inspect

[TommyLeong]

I actually read the link you shared. Well, I did more reading and searching about force quit yesterday. It seems you are right, swiping it away by user (force quit) is telling the system that the user no longer wishes this app to be running, also in the background.

But i'm puzzled, in this case why is the Notification Banner still showing?
Is this actually handled by RNFirebase SDK? or the OS itself?

[mikehardy]

If you send a notification payload the system handles it differently with different APIs, this is done in the underlying SDKs and OS itself. At no time during notification payload handling do you get the chance to execute code - that's the critical distinction.

[mikehardy]

This is all kind of irritating, or at least it is to me anyway. Very hard to be a high quality mobile programmer with predictable app behavior when this is how the systems are designed, but notifications etc have been so abused (and drained batteries, spammed users etc) that this is what we're left with

[TommyLeong]

For my case, we are sending data-only message payload. Is there a way for us to identify surely whether the notification banner is actually handle by SDK or OS itself?

To be honest, I'm still puzzled about this (KILL state + unable to awake app and perform background action). I have tested myself on Whatsapp with the 3 states of Background, Quit (app terminate by system) and Kill (user swipe the app away). In turns out, all these 3 states get to show Notification banner as well as getting the notification to be "store" in the app itself.

I'm certain on this because, I actually tested the following...

**FORCE QUIT State + WiFi & Cellular data turned OFF** 

1. Open Whatsapp, double tap Home button, swipe app away
2. Send a text message in device, banner notification appear
3. Turn off WiFi & Cellular data is off. (Confirm and tried to access website via Safari)
4. Open app by tapping app icon, message is there in app.

The only "explanation" I'm able to explain myself is, they are using PushKit notifications Framework instead of User Notification Framework

[mikehardy]

Notification payloads are I believe handled by the OS itself in response to notification payload items in what arrives on the device as an APNS payload. You can construct these and drag-n-drop them yourself onto an emulator to play with them now I think (worth a google to see how, there are articles). You may be deceived by clever coding, unless you know exactly what WhatsApp is doing. It's possible to put enough information in the notification itself (a mixed notification + data payload) such that once tapped your app can behave exactly how it likes. When I send mixed payloads I do that, and when the user taps I don't necessarily need to fetch anything from the network in order to provide a rich experience

[TommyLeong]

Thanks for being specific with the wording, perhaps let me add on another steps example.

Example 1: [Background state]

1. Deploy my app on Physical Device (iOS 12.1.2 - iPhone7)
2. App runs.
3. Tap on home button
4. Push notification from backend website portal
5. App received notification banner (Console.log has nothing printed, there's no code running behind)

Example 2: [Kill state]

1. Deploy my app on Physical Device (iOS 12.1.2 - iPhone7)
2. App runs.
3. Double tap on home button, mobile shows recent apps. SWIPE away my app.
4. Push notification from backend website portal
5. App still received notification banner (Console.log has nothing printed, there's no code running behind)

Same situation for example 1 and example 2

• After step 5, if user decides to open the App by tapping the app icon. He will not see the notification banner in my notification listing screen.
• After step 5, however if user open the app by tapping on the notification banner, he will see the notification banner in my notification listing screen.

I'm not aware about whats the difference using Portal / curl script to push the notification. In fact, I have never try with curl script. Anyway, here's my first try...

Script

curl -X POST --header "Authorization: key=maskedData" \
    --Header "Content-Type: application/json" \
    https://fcm.googleapis.com/fcm/send \
    -d "{\"to\":\"maskedData\",\"notification\":{\"title\":\"Hello\",\"body\":\"Yellow\"}}"

Since my portal is sending data-only message, I suppose I should replace notification with data? 🤔 but ... i don't receive banner after that.

JSON

{
    aps =     {
        alert =         {
            body = Yellow;
            title = Hello;
        };
    };
    "gcm.message_id" = maskedData;
    "google.c.a.e" = 1;
    "google.c.sender.id" = maskedData;
}

[mikehardy]

If you could figure out the exact JSON you need to send to match the portal that would help, as I'm not sure what portal you are using and you can see how important it is to get it right, as the behavior of the underlying SDK and this module varies based on notification-only, notification+data mixed, and data-only payloads, along with all the little toggles inside (like content-available)

[game8149]

I'm having the same problem, when my app its on background/foreground everything works fine, but when app is killed, onBackgroundMessagin handler do nothing.

[mikehardy]

@game8149 you'll have to be very very precise on terms as I indicate above. If your app is actually killed, it's not a problem, it's the design of the operating system. It's a feature. You don't get to run on a user's phone when they kill your app.