Add Display Type Overrider Delegate

[Nightsd01]

• This PR adds the ability to customize the display type for individual push notifications that are received while the app is open.
• This is useful for example in messaging apps, where you do not need to show an alert/notification for messages received if you are already viewing a thread with the same person.

• This PR adds the following method to OneSignal:

[OneSignal setNotificationDisplayTypeDelegate:delegate]

• When a notification is received, the following method on the delegate will fire:

- (void)willPresentInFocusNotificationWithPayload:(OSNotificationPayload *)payload forDisplayType:(OSNotificationDisplayType *)type

• The display type is passed in as a pointer that the app can set (or not). If the developer wants to set the NONE display type for this specific notification, they would do so like this:

- (void)willPresentInFocusNotificationWithPayload:(OSNotificationPayload *)payload forDisplayType:(OSNotificationDisplayType *)type {
   *type = OSNotificationDisplayTypeNone;
}

• Setting the display type for this notification does not effect any future notifications that may be received, and the SDK will always default to whatever was set with [OneSignal setInFocusDisplayOption:]

• Adds a test to ensure that the behavior works correctly
• Adds this delegate to the demo project, it can be tested by sending overrideDisplayType in the additionalData of a push notification and setting it to 0 (none), 1 (alert), or 2 (notification)

---

This change is 

[jkasten2]

Reviewable status: 0 of 11 files reviewed, 1 unresolved discussion (waiting on @Nightsd01)

---

iOS_SDK/OneSignalSDK/Source/OneSignal.h, line 219 at r1 (raw file):

// Allows apps to customize per-notification display-type
@protocol OSNotificationDisplayTypeDelegate <NSObject>
- (void)willPresentInFocusNotificationWithPayload:(OSNotificationPayload *)payload forDisplayType:(OSNotificationDisplayType *)type;

What you think about using a callback like userNotificationCenter:willPresentNotification:withCompletionHandler: has? Instead of a pointer to forDisplayType.

This will make it possible for someone to do some work what might take longer so they don't block the main thread.

[Nightsd01]

@jkasten2 we could do that, but it would complicate things. I’m using a pointer because I’m guessing that in a lot of cases they’ll just want to use the default display type in which case they don’t need to dereference the pointer or do anything with it.

If we use a block however, that makes things a bit more complex since we’ll have to do something if they never call it, do we check after a timer? Etc. so I figured this was simpler and faster.

[jkasten2]

Hmm, true, keeping it simple is probably best. I think returning value instead of having to update a pointer would be simpler. What do you think? Also I am guess this would be easier to Swift too, since otherwise you would have to use UnsafePointer?

I think a timmer would work if we did do a callback. I can't remember if Apple documented theirs somewhere for their userNotificationCenter:willPresentNotification:withCompletionHandler: but I want to say it is 30 seconds. Anyway, probably ok to keep it a simple API. A 2nd callback typed method could always be added later.

Reviewable status: 0 of 11 files reviewed, 1 unresolved discussion (waiting on @Nightsd01)

[Nightsd01]

@jkasten2 now that I think about it a bit more, I think a callback might actually be best since it will make it easier to use with wrapper SDK’s that can’t do synchronous returns. That should make it easy to implement in the wrapper SDK’s.

I will update the PR this weekend to use a callback with a 30 second timer - that sound good? The only complexity is that multiple notifications can arrive pretty quickly so I’ll keep that in mind.

[jkasten2]

@Nightsd01 It might be worth trying to see what happens when the withCompletionHandler does not fire to get the time down for sure, then add a bit of buffer to it.

Also I wonder if iOS will wait until the app has called the withCompletionHandler callback before calling userNotificationCenter:willPresentNotification:withCompletionHandler: again. If it does do this it will save on the SDK needing to keep track of a callback list. 😄

[Nightsd01]

@jkasten2 updated the diff! I’ll be adding a test soon but it should be good to take a look at the code now

[jkasten2]

Reviewable status: 0 of 13 files reviewed, 2 unresolved discussions (waiting on @Nightsd01)

---

iOS_SDK/OneSignalSDK/Source/OneSignal.h, line 221 at r2 (raw file):

// Allows apps to customize per-notification display-type
@protocol OSNotificationDisplayTypeDelegate <NSObject>
- (void)willPresentInFocusNotificationWithPayload:(OSNotificationPayload *)payload

willPresentInFocusNotificationWithPayload 👍 on the naming, very clear on what this does!

---

iOS_SDK/OneSignalSDK/Source/OneSignal.h, line 222 at r2 (raw file):

@protocol OSNotificationDisplayTypeDelegate <NSObject>
- (void)willPresentInFocusNotificationWithPayload:(OSNotificationPayload *)payload
                           withDefaultDisplayType:(OSNotificationDisplayType)displayType

Thinking we can drop withDefaultDisplayType as I think it is something that wouldn't be used. It also wouldn't be different per notification so if it needs to be read it should be something they can read from calling something on the OneSignal class.

[Nightsd01]

---

iOS_SDK/OneSignalSDK/Source/OneSignal.h, line 222 at r2 (raw file):

Previously, jkasten2 (Josh Kasten) wrote…

Thinking we can drop withDefaultDisplayType as I think it is something that wouldn't be used. It also wouldn't be different per notification so if it needs to be read it should be something they can read from calling something on the OneSignal class.

The reason I included the default display type as a parameter here is to make it easy for developers to just call the completion block with the default value if they don't want to override it in some situations.

They could also just call the completion block with OneSignal.inFocusDisplayType but I think this is less obvious. What do you think?

[jkasten2]

Reviewable status: 0 of 13 files reviewed, 1 unresolved discussion (waiting on @Nightsd01)

---

iOS_SDK/OneSignalSDK/Source/OneSignal.h, line 222 at r2 (raw file):

Previously, Nightsd01 (Brad Hesse) wrote…

The reason I included the default display type as a parameter here is to make it easy for developers to just call the completion block with the default value if they don't want to override it in some situations.

They could also just call the completion block with OneSignal.inFocusDisplayType but I think this is less obvious. What do you think?

I think anyone who sets up this delegate will know the display type they will want to set. In both cases of if it meets some special payload or if it doesn't.

[jkasten2]

Reviewed 4 of 11 files at r1, 3 of 9 files at r2, 6 of 6 files at r3.
Reviewable status: complete! all files reviewed, all discussions resolved