Closed janvennemann closed 5 years ago
Thanks for the PR, @janvennemann! I'll take a look at this and see how we look.
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.
@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.
@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!
Finally I had some time to review these changes! This is looking good. I will finalize the PR and prepare for release.
So this does a few things...
Requires changes from https://github.com/appcelerator/titanium_mobile/pull/10418 to work with latest Titanium versions