Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-25793] iOS: No callback when not granting push notification permission (Apple bug)

GitHub Issuen/a
TypeBug
PriorityNone
StatusClosed
ResolutionDone
Resolution Date2018-06-12T02:37:18.000+0000
Affected Version/sRelease 7.0.2
Fix Version/sn/a
ComponentsiOS
Labelsapplebug, escalation
ReporterMotiur Rahman
AssigneeHans Knöchel
Created2018-02-21T05:38:07.000+0000
Updated2018-08-06T17:34:45.000+0000

Description

Hi, I am trying to enable push notifications on IOS device and when I grab token I am being asked to provide push notification permission. If I choose not to give it, error callback is not thrown. I copied code directly from Push Notifications Reference Guide: http://docs.appcelerator.com/platform/latest/#!/guide/Subscribing_to_push_notifications Here is the code: ---------------------------------------------------------------------------------------------------------------------------------------------------
var deviceToken = null; 

// Check if the device is running iOS 8 or later 
if (Ti.Platform.name == "iPhone OS" && parseInt(Ti.Platform.version.split(".")[0]) >= 8) { 

// Wait for user settings to be registered before registering for push notifications 
Ti.App.iOS.addEventListener('usernotificationsettings', function registerForPush() { 

// Remove event listener once registered for push notifications 
Ti.App.iOS.removeEventListener('usernotificationsettings', 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 
] 
}); 
} 

// For iOS 7 and earlier 
else { 

Ti.Network.registerForPushNotifications({ 
// Specifies which notifications to receive 
types: [ 
Ti.Network.NOTIFICATION_TYPE_BADGE, 
Ti.Network.NOTIFICATION_TYPE_ALERT, 
Ti.Network.NOTIFICATION_TYPE_SOUND 
], 
success: deviceTokenSuccess, 
error: deviceTokenError, 
callback: receivePush 
}); 
} 

// 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; 
} 

function deviceTokenError(e) { 
alert('Failed to register for push notifications! ' + e.error); //this is the function that never gets thrown. 
} 
--------------------------------------------------------------------------------------------------------------------------------------------------- Note that deviceTokenError never gets thrown once permission has been granted/revoked. *Expected Result:* error callback should be fired when not granting push notification permission. *Actual Result:* error callback never be fired. Thanks

Attachments

FileDateSize
push-check.mov2018-02-21T19:12:03.000+00001077373
test_push.zip2018-02-21T20:22:38.000+000032491
test_push-workaround.zip2018-04-18T15:37:09.000+000045099

Comments

  1. Nikita Radaev 2018-02-21

    Tested with SDK 6.3 on iPhone 6 v11.2.1, iPhone 7 v 10.2 iPad v9
  2. Hans Knöchel 2018-02-21

    Hey there! I've validated the test-case and it works fine. See the attachment (push-check.mov) for details. I'll try to isolate if it may have issues in the (deprecated) kroll-thread or JSCore usage. *EDIT*: Those use-cases work as well. Did you ensure that your event listeners are still in your scope and not null?. Here is my test-case:
       var deviceToken = null; 
        
       // Check if the device is running iOS 8 or later 
       function checkPush() { 
         // Wait for user settings to be registered before registering for push notifications 
         Ti.App.iOS.addEventListener('usernotificationsettings', function registerForPush() { 
           // Remove event listener once registered for push notifications 
           Ti.App.iOS.removeEventListener('usernotificationsettings', 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('SUCCESS!');
       } 
        
       function deviceTokenError(e) { 
         alert('Failed to register for push notifications! ' + e.error); //this is the function that never gets thrown. 
       } 
       
       var win = Ti.UI.createWindow({
         backgroundColor: '#fff'
       });
       
       var btn = Ti.UI.createButton({
        title: 'Trigger'
       });
       
       btn.addEventListener('click', function() {
        checkPush();
       });
       
       win.add(btn);
       win.open();
       
  3. Nikita Radaev 2018-02-21

    Hi Hans, I wonder if it is because you use a simulator to test? All of my devices are exhibiting the same behavior. I am pretty sure event listeners are in scope since I am able to get token and receive and read push data when permission is granted. It is only error response that is not triggering event callback. Also, did you run it on 6.3 SDK? N.
  4. Hans Knöchel 2018-02-21

    I did not test it on the device so far, but will tomorrow morning. Testing on older SDK's will be part of it. I'll let you asap, likely tomorrow morning.
  5. Nikita Radaev 2018-02-21

    I looked up my old emails and you did recommend a workaround for this issue which was to use Ti.Network.remoteNotificationEnabled() and it works, but I'd rather get to the bottom of the problem this time around. Thanks for looking at it for me.
  6. Hans Knöchel 2018-02-21

    Yeah I remember (although I wasn't able to find the mail thread). Did I send you [this link](https://stackoverflow.com/a/38456437/5537752) and [this one](https://stackoverflow.com/a/34332047/5537752)? Especially the following sounds like a thing: {quote} iOS Note: If a cellular or Wi-Fi connection is not available, neither the application:didRegisterForRemoteNotificationsWithDeviceToken: method nor the application:didFailToRegisterForRemoteNotificationsWithError: method is called. For Wi-Fi connections, this sometimes occurs when the device cannot connect with APNs over port 5223. If this happens, the user can move to another Wi-Fi network that isn’t blocking this port or, on an iPhone or iPad, wait until the cellular data service becomes available. In either case, the device should be able to make the connection, and then one of the delegation methods is called. {quote} We really do not do anything special in handling the permissions and just invoke the callbacks that Apple calls. We'll handle this, no worries!
  7. Nikita Radaev 2018-02-21

    No, it was [this link](https://stackoverflow.com/questions/1535403/determine-on-iphone-if-user-has-enabled-push-notifications/28323624#28323624) I will ask our Wifi masters for the port and see if that is what causes it.
  8. Hans Knöchel 2018-02-21

    Wifi masters :-D Can you send one to Germany as well? My Wifi here really underperforms today. By the way, I couldn't wait and tested on the device as well. It works fine. Awaiting feedback from your masters! You may also want to test it by disabling Wifi btw. *EDIT*: I added a proper certificate and it now reproduces! I'll validate on a native project and an older Ti version next. *EDIT 2*: Reproducible on 6.3.0 as well. And the native delegate do not even fire. Checking more details ... *EDIT 3*: Bad news: It's happening for native projects (Swift / ObjC) as well (and I finally found a Stackoverflow [link](https://stackoverflow.com/a/9582638/5537752) as well). I'll file a bug at Apple tomorrow and so should you to prioritize it. See the native test-case attached to this ticket for details. Let me know if we can do more for you at this point or resolve it until Apple fixes it. Thank you!
  9. Nikita Radaev 2018-02-22

    Glad you were able to recreate it. This being iOS bug, I'd say lets see what they have to say about it. I will try to file this with Apple as well in the next couple days.
  10. Hans Knöchel 2018-04-18

    Hey Nikita! I got pinged by support if we can provide a possible workaround and I thought about a possible one. You can see the (working) solution in the "test_push-workaround.zip" attachment, which shows the workaround using a native project first. The same can be done in Titanium by listening to the "blur" and "focus" events. Let me know your thoughts about it and if we should deliver the Titanium code or you do it. Thanks!
  11. Nikita Radaev 2018-04-18

    Thanks Hans, I will try to get it tested in the next few days.
  12. Nikita Radaev 2018-04-24

    Hi Hans, I realized I did not read your comment close enough to notice it contains native code. Unfortunately, I only know a small amount of objective C, but I doubt that even that is enough to understand what is going on. Would it be possible for you to compile a sample Titanium project that I can quickly run? I've already got a sample project setup for Push so I just need a controller code. Thanks, N.
  13. Hans Knöchel 2018-05-23

    Hey Nikita! We will prepare a project later this week or early next week. Thanks for following up!
  14. Hans Knöchel 2018-06-12

    [~nradaev] Soooory, that took too long on my end! WWDC and related kept us busy. I prepared a Ti-based example of the native workaround, here you go: https://gist.github.com/hansemannn/62b67b384915d7e64c0a711b4afb1b73 We have also filed a ticket at Apple a while back and are awaiting feedback about it, but it looks like it low-prio for them as of for now.
  15. Eric Merriman 2018-08-06

    Closed as completed. If this is in error, please reopen.

JSON Source