Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-17683] iOS8: call registerUserNotificationSettings when Ti.Network.registerForPushNotifications() is called

GitHub Issuen/a
TypeImprovement
PriorityMedium
StatusClosed
ResolutionInvalid
Resolution Date2014-09-12T22:14:43.000+0000
Affected Version/sn/a
Fix Version/sn/a
ComponentsiOS
Labelsn/a
ReporterJon Alter
AssigneeJon Alter
Created2014-09-11T22:42:59.000+0000
Updated2014-09-18T17:17:46.000+0000

Description

In a comment in TIMOB-17238, Timan said that is was confusing to have to call
Ti.App.iOS.registerUserNotificationSettings() 
before
Ti.Network.registerForPushNotifications()
We could take the types passed into registerForPushNotifications and call registerUserNotificationSettings for the user behind the scenes to make it work like it did in iOS8. I am not sure if this would be a good abstraction, but it is possible.

Comments

  1. Chee Kiat Ng 2014-09-12

  2. Timan Rebel 2014-09-12

    [~cng] Push Notifications can be made interactive at the moment, only not when using ACS Push. There are a lot of other ways to send push notifications of course. We already have working Interactive Push Notifications running in a beta version of our app, by first calling local registration and then calling push registration. That version will even be submitted to Apple today, now we can submit iOS8 apps
  3. Chee Kiat Ng 2014-09-12

    [~timanrebel] Oh yeah, you are correct there. So what we can do is: A) change according to what Jon suggest, with the method registerForPushNotifications accepting types AND categories (optional), behind the scenes the method will call registerForLocalNotifications and also call apple api registerForRemoteNotifications (required). *Advantage:* Titanium developers who use push notifications face little change and only have to call this method to register. *Disadvantage:* Titanium developers who need to use both local AND push notifications in 1 app, have to call both local and remote registration methods, that may have overlapping methods. B) change registerForLocalNotifications to registerUserNotificationSettings, and slight modifications to registerForPushNotifications *Advantage:* Titanium developers who need to use both local AND push notifications in 1 app will have no problems. *Disadvantage:* API docs have to instruct the new way to push notifications for iOS8 have to do the following steps: 1)registerUserNotificationsSettings 2)registerForPushNotifications Any thoughts?
  4. Timan Rebel 2014-09-12

    [~cng] Option A) poses a couple of edge cases, which should be prevented in native space. For example a Titanium developer call registerForLocalNotifications with categories A and B, but later calls registerForRemoteNotifications with categories B and C. I'm not sure what would happen :) Plus C would also be available to local notifications, although the developer has not requested it specifically. Option B) is the safest and clearest option IMHO towards Titanium developers, but has the disadvantage of the need to change your JS code when upgrading to 3.4.0. (Although that was also the case when switching from NavigationGroup to navigationWindow and some other cases). It could be an option to throw a warning when setting types on registerForRemoteNotifications , explaining that registerUserNotificationsSettings should be called instead.
  5. Jon Alter 2014-09-12

    +1 for Timan's thoughts on Option B
  6. Ingo Muschenetz 2014-09-12

    [~jalter] to mark as invalid.
  7. Jon Alter 2014-09-12

    Here are the essential changes that have been made: - registerForLocalNotifications renamed to registerUserNotificationSettings - when calling registerForPushNotifications on iOS8+, the types property is ignored. - if types is passed to to registerForPushNotifications on iOS8+, a warning will be logged to the console that types need to be set via registerUserNotificationSettings. - this has been added to the documentation as well. These changes have been made in the PR for TIMOB-17640 Thank you both for your input.
  8. Wilson Luu 2014-09-18

    Closing ticket as invalid. This ticket has been covered in TIMOB-17640.

JSON Source