PushKit support

[morozkin]

To test PushKit notifications on your local machine change bundle id of the project to im.vector.pushtest. Perform changes in initMatrixSession to allow calling [accountManager prepareSessionForActiveAccounts] even in background mode. Also you will need a pem certificate which can be provided to you by me or Dave. To send pushes i use Houston.

Initially PushKit must be used only for VoIP notifications, but then it was decided to use it for all types of notifications in Riot. So the purpose of this is PR to provide this level of support.

The flow of registering for notifications didn't change a lot. There're new methods which replaced the old one. All of them belongs to PKPushRegistryDelegate protocol:

pushRegistry:didUpdatePushCredentials:forType:
pushRegistry:didInvalidatePushTokenForType:
pushRegistry:didReceiveIncomingPushWithPayload:forType:

To be able to handle PushKit notifications we create a PushRegistry instance, set AppDelegate as its delegate and hold for entire life of the app.

We subscribe for events from MXNotificationCenter instance of active MXSession when a new push is received. On arriving of each event an alert body string is created and then local notification is displayed.

Since we have a deal with network i add a delay for two cases:

1. There is a pushNotificationHandlingTimeoutBlock which is called when server sync takes a lot of time.
2. pushNotificationHandlingCompletionBlock is called with delay after push event has been successfully processed. I added delay here to support handling of series incoming pushes. Push1->Push1 has been handled->Schedule Push1 completion block->Push2->Cancel Push1 completion block->Wait for Push2 event...

I set a random constants for these delays, so i'm glad to hear your proposals.

The list of possible cases we can meet:

1. Receive push -> start listening for push events from server sync response -> schedule timeout block -> cancel timeout block -> handle push event -> schedule completion block -> execute completion block -> end

2. Receive push -> start listening for push events from server sync response -> schedule timeout block -> execute timeout block -> end

3. Receive push -> start listening for push events from server sync response -> schedule timeout block -> cancel timeout block -> handle push event -> schedule completion block -> receive new push -> cancel completion block -> schedule timeout block -> wait for new push event from server

4. Receive push -> start listening for push events from server sync response -> schedule timeout block -> new push -> cancel timeout block -> schedule new timeout block -> cancel timeout block -> handle push event (from 1st push) -> schedule completion block -> | WAITING TIME | ->

We have two ways to continue:
-> execute completion block (1st push event) -> end (2nd push event won't be handled) PROBLEM
-> cancel completion block -> receive new push event (from 2nd push) -> schedule new completion block -> end

If we won't receive any events before completion block of first push event would be called we will lose second push event.

5. Receive push -> start listening for push events from server sync response -> schedule timeout block -> cancel timeout block -> handle push event (contains event for future push) -> schedule completion block -> receive push -> cancel completion block -> schedule timeout block -> execute timeout block -> end

Signed-off-by: Denis Morozov dmorozkn@gmail.com

[morozkin]

@giomfo Similar situation

[SwiftCrew]

@morozkin But Apple guideline says you have to call reportIncoming Call in pushKit Delegate otherwise application will crash.

[morozkin]

@giomfo We need to decide which value will be appropriate here and i think it'll be better to assign this value to a constant

[morozkin]

@giomfo Maybe it also will be better to pause MXSession when we've ended with push handling?

[morozkin]

Receive push -> start listening for push events from server sync response -> schedule timeout block -> new push -> cancel timeout block -> schedule new timeout block -> cancel timeout block -> handle push event (from 1st push) -> schedule completion block -> | WAITING TIME | ->

We have two ways to continue:
-> execute completion block (1st push event) -> end (2nd push event won't be handled) PROBLEM

@giomfo wdyt?

Also have a look at other scenarios

[morozkin]

If #1472 will look good to you, we will need to merge it with this PR

[manuroe]

The PR was merged even if some issues has been detected. See https://matrix.to/#/!dBmmlOkhBOeZNEAfDK:matrix.org/$1504019660293757xpuGS:matrix.org

Step by step improvements will follow.