Push notifications that trigger a background refresh before showing the push notification VS silent push

Question

I want to implement background refresh functionality in my app for when a push is received. Just before the push notification is displayed to the user I want to download the new messages from my backend (Parse.com) and save them to an array. I am following a guide from here: http://developer.xamarin.com/guides/ios/application_fundamentals/backgrounding/part_3_ios_backgrounding_techniques/updating_an_application_in_the_background/

I'm not sure how accurate this guide is. It states: iOS 7 (and greater) extends ordinary push notifications by giving applications a chance to update content in the background before notifying the user, so that the user can open the application and be presented with new content immediately.

So I tried implementing my background push like this:

- (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo fetchCompletionHandler:(void (^)(UIBackgroundFetchResult result))handler
{


    if([[userInfo objectForKey:@"aps"] objectForKey:@"content-available"]){

        NSLog(@"Doing the background refresh");
        UINavigationController *navigationController=(UINavigationController *)[[[UIApplication sharedApplication] keyWindow] rootViewController];

        MyViewController *myViewController = (MyViewController *)[[navigationController viewControllers] objectAtIndex:1];

        [myViewController.currentUser refreshMessagesArrayWithCompletionHandler:^(BOOL successful, BOOL newMiaos) {

            NSLog(@"messages refreshed the array now has %lu messages",(unsigned long)[myViewController.currentUser.messages count]);
            handler(UIBackgroundFetchResultNewData);
        }];
    }
}

The background refresh is called and the push is displayed, however the push notification does not wait for the background task to finish. It is just displayed as soon as it is received. Is this correct functionality? The tutorial above suggests that a notification won't be displayed until the background task is completed.

I then went about trying a silent notification, this triggers the app to download the messages in the background when the push is received but no notification is displayed. So I do this by firing a local notification instead after the download completes. Is this really the correct way of doing it? Do traditional apps such as whatsapp trigger a background refresh using a silent notification and then fire a local one? Seems a bit hacky. Surely the idea of a background push is to get the data ready before showing the notification but it doesn't quite work like that..

The other thing I noticed is that silent notifications are rate limited they have a lower priority than a typical push notification so surely this hinders the efficiency of the app also...

Any pointers on this would be really appreciated. Just trying to get my head around if I'm approaching this the right way or not. All seems very hacky...

Answer 1

I've been struggling with the same task in my messaging app. We wanted users to see the message right before user taps the notification. What we faced with:

• The payload size limitation. iOS 7 can have only 256 bytes for payload
• single silent notifications will not start an app, if it is not running
• content-available notifications without alert body may even not be delivered to the device
• Background fetch is not controlled by your app, so you may never receive the desired signal, so we cannot rely on this feature. But this may be helpful as an additional way to achieve what we want
• iOS 8 has a lot of space for payload - 2KB
• if you send alert body and content-available - it will be delivered in most cases and an app is able to process it

So we came to the only acceptable solution: we decided to make this feature in ios8+ only. We send visible push notifications with content-available key which allows us to process the notification payload if the process is running/frozen and both be able to present the notification if the app is not running. If an app receives push notification, it takes alert text body and writes it into local database, so the user is able to read it in conversation. According to our stats, the average size of the message is not more than 200 symbols, so most of the time no extra requests are required. If the message is longer than 200 symbols, we extend payload body with extra parameter which is used to request text body in push notification processing. The user will see a cropped version of text, but after a request is done, we rewrite a message in local database with the received value.

So, that technique allows us to show a received message to the user immediately in most of the cases + if the app was not running, we make a request to our server to fetch missing messages right after application start. This is the fastest and the most acceptable case we could get on iOS. Hope my experience will help you to implement what you want.

Answer 2

You mixed a few of things together.

From a quick look at your link, this is a guide for xamarin. There might be some correct info there but if you are not using xamarin I'd search for another tutorial.

A good approach would be to send a silent notification to the user and triggering a local notification when it's done (which is not hacky at all).

This is how whatsApp is making it work:

While whatsApp is in the background, a single push notification is received, (for example "5") That msg will not be shown to the user.

whatsApp receives it in the method application:didReceiveRemoteNotification:fetchCompletionHandler: and checks against their servers if there are any notifications prior to "5" that the user didn't receive. If that's the case, they will pull that data from their servers and will present it to the user using local notifications which is basically just a way to present data and not related to APNS at all.

You can read the full answer & context in another answer I wrote here