[TIMOB-17683] iOS8: call registerUserNotificationSettings when Ti.Network.registerForPushNotifications() is called
GitHub Issue | n/a |
---|---|
Type | Improvement |
Priority | Medium |
Status | Closed |
Resolution | Invalid |
Resolution Date | 2014-09-12T22:14:43.000+0000 |
Affected Version/s | n/a |
Fix Version/s | n/a |
Components | iOS |
Labels | n/a |
Reporter | Jon Alter |
Assignee | Jon Alter |
Created | 2014-09-11T22:42:59.000+0000 |
Updated | 2014-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.
[~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
[~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?
[~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.
+1 for Timan's thoughts on Option B
[~jalter] to mark as invalid.
Here are the essential changes that have been made: -
registerForLocalNotifications
renamed toregisterUserNotificationSettings
- when callingregisterForPushNotifications
on iOS8+, thetypes
property is ignored. - iftypes
is passed to toregisterForPushNotifications
on iOS8+, a warning will be logged to the console that types need to be set viaregisterUserNotificationSettings
. - 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.Closing ticket as invalid. This ticket has been covered in TIMOB-17640.