williamrijksen / com.williamrijksen.onesignal

Titanium Appcelerator Library for OneSignal Push Notifications Service
Other
51 stars 43 forks source link

fix(ios): update OneSignal SDK to 2.9.3 #77

Closed janvennemann closed 5 years ago

janvennemann commented 5 years ago

So this does a few things...

Requires changes from https://github.com/appcelerator/titanium_mobile/pull/10418 to work with latest Titanium versions

joshualambert commented 5 years ago

Thanks for the PR, @janvennemann! I'll take a look at this and see how we look.

joshualambert commented 5 years ago
joshualambert commented 5 years ago

Hey @janvennemann -- I tested this using the latest 7.4.2 night TiSDK, 7.4.2.v20181106131718.

Here's what I'm seeing: 1.) If I open a push notification while the app is already running in the background, the notification opens the app and key/value pairs pass as expected. 2.) If I open a push notification while the app is NOT already running in the background, the notification opens the app, but key/value pairs do not pass as expected.

Expected behavior: 1.) Regardless of if the app is running or not running, key/value pairs specified in OneSignal should pass through.

Aside from that, this looks good.

screen shot 2018-11-08 at 1 12 37 pm

janvennemann commented 5 years ago

@joshualambert the data is available, however the notification has a different structure after launching the app from a force-closed state. The data received in that case is the raw notification stored in the launch options and custom values are under the custom key instead of additionalData in the OneSignal notification payload.

I'll try to move the OneSignal initialization directly into the app delegate since that is now possible inside native module. Hopefully that will trigger an event from OneSignal with the proper data structure.

janvennemann commented 5 years ago

@joshualambert alright, so i moved the OneSignal initialization into the app delegate method that modules can now register for. However, this alone didn't solve it because the first delegates are queued during startup and the OneSIgnal SDK is still initialized a little too late to take care of handling the notification after a cold boot. For now i took the old workaround and read the notification from the launch options and fire the notification manually once registered for it. Please give it another try!

jvandijk commented 5 years ago

Finally I had some time to review these changes! This is looking good. I will finalize the PR and prepare for release.