• BlackBerry Dynamics
  • Runtime library for iOS applications
  • 12.0.1.79
Single-Source Push Channel Listener or Delegate
Deprecated:
This class is deprecated and will be removed in a future release. Instead of setting a PushChannel delegate, register for notifications as described in the GDPushChannel class reference.

State changes that occur when using GDPushChannel are handled by creating a class that implements this protocol. The callback for handling received Push Channel notifications is also part of this protocol.

Code Snippets

The following code snippets illustrate some common tasks.

Receive Push Channel Token

-(void)onChannelOpen:(NSString*)token
{
NSLog(@"onChannelOpen token: %@", token);
myApp.pushIsOpen = YES;
myApp.pushToken = token;
[myApp sendPushToken];
}

The above snippet shows a simple onChannelOpen handler. The following takes place when the Push Channel is opened:

The sendPushToken function, which would be written by the application developer, would send the token to the application server. This could use a socket, an HTTP request, or another means of communication. From the Push Channel point of view, this is an out-of-band communication.

The server will use the token to address Push Channel notification messages back to the application. These would be received by the application's onChannelMessage handler.

Receive Push Channel notification

-(void)onChannelMessage:(NSString*)data
{
NSLog(@"onChannelMessage: %@", data);
[myApp processPush:data];
}

The above snippet shows a simple onChannelMessage handler.

The handler logs the received data to the system monitor, then calls the application processPush function. The "payload" of the notification is passed as a parameter to the processPush function.

The processPush function, which would be written by the application developer, could initiate any of the following actions:

Handle Channel Closure

-(void)onChannelClose:(NSString*)data
{
NSLog(@"onChannelClose: %@", data);
myApp.pushIsOpen = NO;
[myApp discardPushToken:data];
}

The above snippet shows a simple onChannelClose handler. The following takes place when the Push Channel is closed:

The discardPushToken function would delete the application's copy of the token, possibly after checking that it matches the whichWas parameter. The function could also initiate connection of a new Push Channel, which would have a new token. See connect .

Handle Channel Error

-(void)onChannelError:(int)error
{
NSLog(@"onChannelError: %d", error);
myApp.pushIsOpen = NO;
myApp.pushErr = error;
[myApp discardPushToken];
}

The above snippet shows a simple onChannelError handler.

The handler logs the error code to the system monitor, flags the channel's state as not connected, records the error code in the application, then calls the application discardPushToken function.

The discardPushToken function could do any of the following:

Handle Ping Failure

-(void)onChannelPingFail:(int)error
{
NSLog(@"onChannelPingFail %d", error);
if ( error == 605 ) {
[myApp resendPushToken];
}
}

The above snippet shows a simple onChannelPingFail handler.

The handler logs the error code to the system monitor, then calls the application resendPushToken function if the token was lost.

The resendPushToken function, which would be written by the application developer, would send the application's stored token to the application server. This could use a socket, an HTTP request, or another means of communication. From the Push Channel point of view, this is an out-of-band communication.

The resendPushToken function should expect that the server is not immediately available, perhaps employing a retry policy.