Literals do not pass the **value type** test for **badge** (ios)

[macMikey]

The following code will not set the badge of a mobile app:

$notification:=New object()
$notification.title:="test title"
$notification.badge:=1

Discussion:

Inside of project method buildNotification on line 51, the value type of badge is evaluated:

If (Value type($1.badge)=Is integer)

Even the literal 1 evaluates to Is real in this code. I tried a variety of workarounds to resolve this issue, including

$notification.badge:=Int(1)

but none of the things I have tried have worked.

Workaround:

The code does allow the developer to manually build a push notification using the userInfo object, however it cannot be used to supplement the other settings (like title and body, as it will overwrite other properties, so you cannot, for example use

$notification.title:="TEST PUSH"
$notification.userInfo.aps.badge:=1

because even though $notification.aps.title is initially set, using userInfo.aps will cause the code to wipe the other properties of aps instead of appending the aps.badge property. However, you can build the entire aps object using this technique:

$notification.userInfo.aps.alert.title:="TEST PUSH"
$notification.userInfo.aps.alert.subtitle:="Test Subtitle"
$notification.userInfo.aps.alert.body:="test body"
$notification.userInfo.aps.badge:=1

Suggestions for resolving this issue:

In the buildNotification project method:

1. Change line 51 to allow any numeric
2. Change line 53 to:

   $notification.aps.badge:=Int($1.badge)

3. Change lines 98-108 so that it traverses $key and inserts $1.userInfo[$key] but does not wipe any existing property or object. This would make the code more future-proof since Apple is likely to modify the APNS Dictionary and Alert keys in the future.
4. Keep publishing components as open source, so interested members of the community can dive into the code and help find this sort of issue. As an aside, it also helped me test my code, more, and discover that the previous issue I posted, this evening, was really a false alarm.

[mesopelagique]

thank. I will look at it

3. yes could be done
4. yes, it will better, we will use the git repository (and github) as source to build 4D. (today we have a different source control system, and I have script to push to github) so a Pull Request on github with some fix or feature will be merged more easily

[mesopelagique]

For 1. and 2. I have merged a PullRequest #5 (where you can see the change) I will update 19R4 too (EDIT: 21e12fa77a06206ef0fbba611713a28e7faae443 )

---

For 3. because I could not see clearly what it is proposed, you could PullRequest just by editing on github https://github.com/4d-go-mobile/4D-Mobile-App-Server/blob/main/Project/Sources/Methods/buildNotification.4dm#L105 to propose new code (event if it not compile or not indented)

---

For 4. Yes now we could do pull request on Main branch (maybe beta branch too later, like 19R4, I will talk about that because now I must do manually code reporting)