[iOS] handleNotificationReceived when app is closed

[chmiiller]

Add support for handleNotificationReceived: it detects when user opens a notification from outside the app and provides the additionalData already, but unfortunately, it doesn't work when the app is completely closed, don't know why =/

@hansemannn said: " it's because it needs to listen to the core TiApp class to get notified and linking to that required the method to be in the class method "load""

But I don't know how to implement it.

[prakash-anubavam]

I am also facing this issue. Is there is any workaround ?

check this thread, https://forums.developer.apple.com/thread/54322

@costmosf said:

`

• (void)userNotificationCenter:(UNUserNotificationCenter )center
  didReceiveNotificationResponse:(UNNotificationResponse )response
  withCompletionHandler:(void (^)())completionHandler
  {
  NSLog( @"Handle push from background or closed" );
  // if you set a member variable in didReceiveRemoteNotification, you will know if this is from closed or background
  } `

[williamrijksen]

Would you support us by giving an example how to solve this problem? @hansemannn.

[hansemannn]

See how UrbanAirship did it, as an example.

[chrishaff]

@chmiiller I successfully added the following to the bottom of the example app. That is, with the app not running I received a push. Clicking on the push opens the app and the app reports the data that was pushed.

This can be found on http://docs.appcelerator.com/platform/latest/#!/guide/Subscribing_to_push_notifications

var deviceToken = null;

// Wait for user settings to be registered before registering for push notifications
// Remove event listener once registered for push notifications
Ti.App.iOS.addEventListener('usernotificationsettings', function registerForPush() {
    Ti.Network.registerForPushNotifications({
        success : deviceTokenSuccess,
        error : deviceTokenError,
        callback : receivePush
    });
});

// Register notification types to use
Ti.App.iOS.registerUserNotificationSettings({
    types : [Ti.App.iOS.USER_NOTIFICATION_TYPE_ALERT, Ti.App.iOS.USER_NOTIFICATION_TYPE_SOUND, Ti.App.iOS.USER_NOTIFICATION_TYPE_BADGE]
});

// Process incoming push notifications
function receivePush(e) {
    alert('Received push: ' + JSON.stringify(e));
}

// Save the device token for subsequent API calls
function deviceTokenSuccess(e) {
    deviceToken = e.deviceToken;
    alert('deviceToken='+deviceToken);
}

function deviceTokenError(e) {
    alert('Failed to register for push notifications! ' + e.error);
}

[prakash-anubavam]

@chrishaff If we required the onesignal module, registerUserNotificationSettings will fired automatically and then registerForPushNotification fired. but If we manually register pushNotification from mobile app, Major functionality in Onesignal SDK may not work. Like deviceToken will not registered with Onesignal server and other tags will not saved. It should be fixed inside the SDK. Your device will not listed in Users section.

But, I have agree with one point, registerForPushNotification should be called after the UserNotification permission enabled. This should be resolved inside the SDK or Module.

[chrishaff]

Thanks for the explanation. Without knowing that API real well I thought I stumbled upon a solution. In subsequent testing I found out what you already knew and so graciously shared.

[chrishaff]

@williamrijksen I have an app going to production in about a month. Do you think this will be addressed before then or should I look elsewhere for now?

[hansemannn]

@chrishaff Use the Titanium events to receive the background events and execute the module API's from there. Guess that should work.

[williamrijksen]

@chrishaff Let me know the suggestion of @hansemannn will work so we can add it to the readme!

[chrishaff]

I went back to what I said in my earlier comment. That technique does work in the simple example app. I assume this is what @hansemannn was referring to. @prakash-anubavam implied that this should not work, but it does.

So, I think we can close this ticket and add it to the example and docs.

This technique does not work in my actual (rather large) app yet. I suspect there is a plugin conflict. I will report on that when I sort it out.

[prakash-anubavam]

@chrishaff Can you share your sample app? You mentioned sample app works fine. I just have few questions. Q1 : Ti.Network.registerForPushNotifications() - This will register your app with APN and gives deviceToken. How did you register this deviceToken with Onesignal platform.

Did you check, your device listed in "All Users" section in Onesginal.com. Q2 : If we can achieve this by adding Ti.App.iOS.registerUserNotificationSettings() and Ti.App.iOS.addEventListener('usernotificationsettings',function(e){}) Why can't you added this functionality within Onesignal SDK?

Since, above Ti calls will fire - IOS Native implementation. same implementation should be added in Onesignal SDK.

I appreciate @chrishaff for his workaround. but Instead of doing workaround, we need a correct solution.

However, I also struct with this issue. If above workaround works, I will implement the same and release my app.

[chmiiller]

@prakash-anubavam did you test the workaround? Does it work? I'm trying again to solve this problem

[williamrijksen]

@chmiiller Would this solve the problem? https://github.com/williamrijksen/com.williamrijksen.onesignal/pull/38.

[chmiiller]

Made a comment explaining my problems on the PR =)

[williamrijksen]

@chmiiller When it's after a force-quit, it's about this issue: https://documentation.onesignal.com/v3.0/docs/ios-native-sdk#section--oshandlenotificationreceivedblock-. In that case OSHandleNotificationReceivedBlock isn't supported by OneSignal at all and this issue should be closed.

[jvandijk]

38 solves the event listening problem for the open listener. As said OneSignal doesn't support the received listener in the "force-quite" state.

Closing issue!