Remote push notifications not received until restart

[shankari]

So occasionally, we end up with no remote push notifications on iOS. This is not a problem with the remote push gateway or server code because other iOS phones do get the notification at the same time.

Example:

9101    2016-02-25 09:03:16.698750-08:00    Successfully registered remote push notifications with parse
10092   2016-02-25 15:10:07.573950-08:00    Received transition T_RECEIVED_SILENT_PUSH in state STATE_ONGOING_TRIP
10103   2016-02-25 15:10:08.314270-08:00    Received notification T_RECEIVED_SILENT_PUSH while processing silent push notification
10104   2016-02-25 15:10:08.333050-08:00    Ignoring SILENT_PUSH in the silent push handler
10125   2016-02-25 15:53:13.995960-08:00    Received transition T_RECEIVED_SILENT_PUSH in state STATE_WAITING_FOR_TRIP_START
10134   2016-02-25 15:53:15.960660-08:00    Received notification T_RECEIVED_SILENT_PUSH while processing silent push notification
10135   2016-02-25 15:53:15.987500-08:00    Ignoring SILENT_PUSH in the silent push handler
10157   2016-02-25 18:18:51.298910-08:00    Successfully registered remote push notifications with parse

and then no further notifications until at least 2016-02-26 12:00:00.

This could be due to several reasons:

• If there is no network connectivity, we will not get remote push updates until connectivity is restored. I suspect that is what happened on the 25th - there was poor connectivity in the basement of the Tech.
• But that cannot be the reason for the lack of remote push notifications from 18:18 to the next morning, when the phone was in the living room, right under the WiFi point. The code to register for remote notifications looks like this:

- (void)application:(UIApplication *)application
                    didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken {
    NSLog(@"Finished registering for remote notifications with token %@", deviceToken);
    // Store the deviceToken in the current installation and save it to Parse.
    PFInstallation *currentInstallation = [PFInstallation currentInstallation];
    [currentInstallation setDeviceTokenFromData:deviceToken];
    [currentInstallation saveInBackgroundWithBlock:^(BOOL succeeded, NSError *error) {
        if (succeeded) {
            [LocalNotificationManager addNotification:[NSString stringWithFormat:
                                                       @"Successfully registered remote push notifications with parse"]];
        } else {
            [LocalNotificationManager addNotification:[NSString stringWithFormat:
                                                       @"Error %@ while registering for remote push notifications with parse", error.description] showUI:TRUE];
        }
    }];
}

So it seems like if we start registering remote push notifications, but the background task doesn't complete, we won't log anything - neither that we started, nor that we failed. But we should still have the previous registration on parse, so it is not clear why this will fail. But maybe attempting a registration that then fails then causes remote pushes to fail.

Unfortunately, unlike #92, this is a hard problem to work around. If the push notifications are skipped because of poor connectivity, it is not clear what a reasonable solution/workaround would be. There's no point in re-registering since re-registering requires talking to a remote server and is likely to fail anyway. If the lack of remote pushes is due to something else, we could try re-registering when we get other calls - e.g. during visit notifications. But again, we can't know whether we are currrently registered, so we would need to re-register every time, which seems like overkill for a background operation.

Let's add some more logging and try to determine what exactly is going on before mucking with this further.

[shankari]

Here's the data that I'm pulling this from.

no_remote_push_withdate.log.zip

[shankari]

If there are networking issues (such as in concrete city hall type areas) then neither didRegister, nor didFailToRegister method is called. Delegate method is called once device can make connection. Is this also true if the app has been suspended or killed in the interim?

https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/IPhoneOSClientImp.html
iOS Note: If a cellular or Wi-Fi connection is not available, neither the application:didRegisterForRemoteNotificationsWithDeviceToken: method nor the application:didFailToRegisterForRemoteNotificationsWithError: method is called. For Wi-Fi connections, this sometimes occurs when the device cannot connect with APNs over the configured port. If this happens, the user can move to another Wi-Fi network that isn’t blocking the required port or, on an iPhone or iPad, wait until the cellular data service becomes available. In either case, the device should be able to make the connection, and then one of the delegate methods is called.

On the plus side, there is a method to check whether we are currently registered for remote notifications.

- isRegisteredForRemoteNotifications

Returns a Boolean indicating whether the app is currently registered for remote notifications.

- (BOOL)isRegisteredForRemoteNotifications
Return Value

YES if the app is registered for remote notifications and received its device token or NO if registration has not occurred, has failed, or has been denied by the user.
Discussion

This method reflects only the successful completion of the remote registration process that begins when you call the registerForRemoteNotifications method. This method does not reflect whether remote notifications are actually available due to connectivity issues. The value returned by this method takes into account the user’s preferences for receiving remote notifications.

So I guess we can do this check in the visit notification code and maybe exit geofence code as well, and re-register if we are not currently registered.

[shankari]

Here's some more evidence that it occurs occasionally.

4607,1456110010.9,2016-02-21 18:53:10.900470-08:00,Application launched with LaunchOptionsLocationKey = NO
4634,1456117211.14,2016-02-21 20:53:11.140850-08:00,Application launched with LaunchOptionsLocationKey = NO
4661,1456124416.52,2016-02-21 22:53:16.521670-08:00,Application launched with LaunchOptionsLocationKey = NO
4675,1456128010.2,2016-02-21 23:53:10.197720-08:00,Successfully registered remote push notifications with parse