Push Notification - iOS & Android Updates! (Now includes FCM - Fuse 1.10+)

[AndrewEQ]

19 Jun 2019 - iOS

Fixed push registration for iOS 8-9 devices

16 Nov - Android: Updated from GCM to FCM! :)

• updated android GCM components with FCM components
• added function to update token if refreshed
• updated play services detection
• updated MapView dependency (its too old!)
• updated color & lightcolor to allow for a color with or without #
• NB! This commit of updates is only compatible with the latest Fuselibs and Uno (1.10)
• requires google-services.json from firebase project to be included in root of project
• requires fuse copyfile command which can be done by making and including this file in project root:

Android.uxl

<Extensions Backend="CPlusPlus" Condition="Android">
    <CopyFile Condition="Android" Name="google-services.json" TargetName="app/google-services.json" />
</Extensions>

27 Sep - iOS & Android: Push Notification Fixes + Features

Android

Fixes

• Added default Notification Channel, so won't have to compile for API 25 to get push notifications working, so you basically don't need to define anything to get it working but its a good practice to define specific channels for a user.
  • Can configure the default channel name via unoconfig

Features

• Added setting of icon color / app name
  • Can set color via unoconfig & notification payload
• Added the ability to hide the title via unoconfig

iOS

Fixes

• Explicitly ask for permission so notifications won't be silent

Feature

• Added function to get whether or not the user has push notifications turned on or off

28 Sep - Added Push Notification Features

Android

• Notification Category
• Notification Color
• Notification Lockscreen Visibility
• Notification Priority
• Notification Sound
• No Title Style

Android 8+

• Notification Channel
• Nofitication Channel Group
• Notification Channel Importance
• Notification Channel Lockscreen Visibility
• Notification Channel Light Color
• Notification Channel Sound
• Notification Channel Show Badge
• Notification Channel Vibration
• Notification Badge Number
• Notification Badge Icon Type

This PR contains:

• Changelog
• Documentation
• Tests

[ekkotech]

In iOS/Impl.uno, the code will work today but will fail when the deprecated method registerUserNotificationSettings is removed from iOS. At that time, the if (..respondsToSelector..) clause will not execute and the else clause will crash the app due to the no longer existing method call registerForRemoteNotificationTypes.
I would recommend that you test first for the existence of the new API (iOS10+) with:
UNUserNotificationCenter* center = [UNUserNotificationCenter currentNotificationCenter];
if ([center respondsToSelector:@selector(requestAuthorizationWithOptions:)]) {
// Now in iOS10+ land
[center requestAuthorizationWithOptions: ... same code ....]
else {
// Now in pre-iOS10 land
[application registerUserNotificationSettings: ....
}

Also, in the completion callback, if you add a test for granted then registration with APNS will not occur if the user declines to give permission:
[center requestAuthorizationWithOptions: (alert | sound | badge)
completionHandler: ^(BOOL granted, NSError * _Nullable error) {
if (granted) {
[application registerForRemoteNotifications];
}];

[ekkotech]

For the Android changes for Oreo+ push notifications, there is an existing PR (#1197) waiting to be merged that addresses both the channel id and background task issue (JobIntentService).

How does this PR tally with #1197? Is it incremental to #1197?

[AndrewEQ]

hey @ekkotech, thanks for the feedback, yeah, the goal of this pr was to enhance the existing code to get it functional as it really isn't working as it stands.

iOS Issue1: I like your fallback logic, I didn't write the original but I'll enhance it with yours.
iOS Issue2: I didn't do the check for granted because I still wanted to register the user (as in get a token and register with my server side) because then if they later turned it on via their general settings, push would work straight away in the app. The other way is for the user to turn on notifications in general settings, then "turn it on" in your app, which means you would need to call register again, then actually register the token with your server side, which I found clunky in terms of user experience.

My issue with #1197 : I couldn't get it to work. I really tried, maybe there's something different between our setups, ionno, and the PR didn't seem to be moving.
Android Issue1: background notification - I haven't had an issue yet with receiving background notifications with the current build, so I didn't touch that or am I misunderstanding the issue?
Android Issue2: Push not working in Android 8(Oreo)+ - So I made the necessary changes at first (adding a channel because its mandatory). I then added a ton of missing android push notification features (see list above).
Android Issue3: We need to move from GCM to FCM by April 2019; this still needs to be done, all the android push features I added can still be used whenever that happens, they could even be added to #1197 if that goes through.

So I would say the main differences are that I broke my PR's into separate bite-sized issue resolutions; for instance the map one is a critical breaking fix, so I don't see why that needs to be held up.

Ok, so the summary break down:

iOS fix - push notifications are silent right now because we don't explicitly ask for permission
iOS feature - you can get whether or not the users push is enabled (test twitter app to see this in use)

Android fix - Android 8+ compatibility
Android features - all the new and old missing push notification features

[AndrewEQ]

@ekkotech I just updated the iOS check for versions older than 10

[kusma]

Why was this closed?

[ekkotech]

@AndrewEQ re. iOS issue2: I see where you are coming from and, from a technical standpoint it has merit, but if you look at it from a data security standpoint, I have two concerns. 1) You are leaking a user's data out to APNS when the user's expectation is privacy, 2) this is library code; applications built on top of this will get a response back from APNS and go ahead and push that out to their own application server. Now there is nothing stopping the user from getting push notifications when they said they didn't want them.

[AndrewEQ]

@ekkotech 1) I know what you're thinking but I've tested it, the notifications are turned off for the user when they say no in the dialog. 2) It was doing this, and still is before my updates. That's where I got the initial idea from. Difference is that the current implementation is silent even when the user says "yes".

From my tests and according to the Apple docs:

Scenario 1 + 1.1 - current code

Scenario 1:

1. App requests registration
2. System prompts user with dialog
3. User selects yes
4. Token is received, notifications are received but silently (no sound even if turned on)

Scenario 1.1:

1. App requests registration
2. System prompts user with dialog
3. User selects no
4. Token is received, notifications can be received but are not as the notification settings for the app are turned off

Scenario 2 + 2.1 - new code

Scenario 2:

1. App requests permission
2. System prompts user with dialog
3. User selects yes
4. App requests registration
5. Token is received, notifications are received with sound

Scenario 2.1:

1. App requests permission
2. System prompts user with dialog
3. User selects no
4. App requests registration
5. Token is received, notifications can be received but are not received as the notification settings for the app are turned off

[ekkotech]

@AndrewEQ Question for you: when you were testing your code changes, what key did you use when sending to GCM? For example, here is the script that I use for pre-API26 tests:

`#!/bin/bash

curl -X POST
-H "Authorization: key=AAAACny-blah-blah-BQWtGsIl-1"
-H "Content-Type: application/json"
-d '{
"to": "APA9blah-blah-Xhr7e8",
"data": {
"notification": {
"channel": "some_channel_id" <<<<---- Is 'channel' correct? Should it be 'channelID'?
"alert": {
"title": "Alert title 4.0",
"body": "Alert body 4.0"
}
},
"title": "Test title 4.1",
"body": "Test body 4.1"
}
}'
https://android.googleapis.com/gcm/send
`

[AndrewEQ]

hey @ekkotech, this was the payload structure that I was testing with: https://github.com/fuse-open/fuselibs/pull/1220/files#diff-0aae1bdd92b0184bb9df83ff47aa3973R230

[AndrewEQ]

@ekkotech were you able to get your notification?

[ekkotech]

@AndrewEQ - I didn't get to test your stuff today. I already had #1197 changes integrated so I tested that. I have another test slot coming up on Friday so I hope to test out your stuff then
BTW - my feedback for #1197 is up there so take a look...

[AndrewEQ]

cool @ekkotech, I think I shall retest sometime and see about combining the differences of #1197 with my update in a separate PR.

[AndrewEQ]

Updated with FCM support! 🎉

[ichan-mb]

I think you should create another PR for map fix because that fix is nothing to do on what PR title said

[AndrewEQ]

I think you should create another PR for map fix because that fix is nothing to do on what PR title said

I guess I needed it as well at the time cos maps was needed too, else the compilation broke without it.

[ichan-mb]

I think you should create another PR for map fix because that fix is nothing to do on what PR title said

I guess I needed it as well at the time cos maps was needed too, else the compilation broke without it.

Ah, I see. But since there is an issue posted on forums about MapView is crashing when targeting Android 9, and the fix for it is on this PR by this commit. But this PR is not yet merged by reviewers. So my recommendation is to create another PR just to fix the MapView Issue. Since the fix is so simple, I think that PR will merge immediately by @kusma

[AndrewEQ]

@ichan-mb @kusma sure thing man: #1284

[ckarmy]

Tested on Android and iOS