Broadcasts for Push Notifications ON/OFF

[benvium]

Hi Paul.

We've been asked to put in a broadcast option for the Push Notifications. Is this something that you have been told about?

If so we presume there'll be a second entry in the broadcasts field (https://github.com/paulschneider/b247-api/wiki/Endpoint-SET-User-Preferences) perhaps:

 "broadcasts": [
       {
           "id": 1,
           "title": "Daily Newsletter",
           "isEnabled": true
       },
       {
           "id": 232,
           "title": "Push Notifications",
           "isEnabled": true
       },
    ]

However from our earlier conversations it appears that both the 'id' and 'title' attributes may change, so can you let us know how we'd know which one is which?

Thanks

[paulschneider]

Hi Ben,

Sorry for the slow reply. Currently in Vietnam with sporadic internet connectivity.

The push notification setting was always on the cards for the apps but I see little point in the website being aware of it. From my understanding of push notifications Im not sure this needs to be in the API at all unless its simply to record how many users have notifications turned on. If it does need to be in the API then it would work in the same way as mail notification where the id and title are provided to you as part of the call to retrieve user preferences. You would then set your input fields (or the device equivalent) to whatever values the API provides.

The values, or at least the ID's, are unlikely to change but I can imagine the name of the preference might be altered in the future so its important they are dynamic. Currently the API is set up to allow any number of preferences and the website is set up to make use of them should more than one be provided. The apps should of course follow suite.

Cheers,

[benvium]

Hi Paul. Thanks for that. The issue is that we need the app to do something as a result of the push notifications setting being on or off, so we can't just present the options to the user. The app needs to know for sure which setting is which so it can action it.

[paulschneider]

Hi Ben,

If you and Kevin can spec out what it is you need me to do I can take a look. Its not been made clear (to me at least) what this is for and how it should affect the API. I can then give you a decent answer on what you can expect to see in the API return.

[benvium]

Cheers. We're not keen on this being in the app at all as it's potentially very confusing to the user. e.g. if notifications are ON in the app but OFF in the system, they won't work. Also it requires server support (e.g. to NOT send notifications to a user if they have set the value in the app to OFF, as we can't actually turn off notifications from inside the app). Best to talk to Kevin on this.

[paulschneider]

From what I understand of Urban Airship push notifications, settings are managed via the apps which inform UA whether a user wants a particular notification type. You send the setting directly to their database using their API and that then tells content managers whether a particular user wants notifications of that type. It wouldn't make sense, I don't think, for the website to provide push notification options, just within the apps. And as push notifications are presumably handled differently by iOS and Android, Blackberry, Windows phone etc... it doesn't make sense for the B247 API to handle them either as each app would have its own own implementation.

To cut to the chase; I don't think I need to be involved in this part of the build as any stats on usage can be pulled out of UA directly and anything I build for you would be a duplication of sorts of what the UA API already does.

Leave it with you and Kevin to discuss though.