|
|
|
@ -1179,22 +1179,14 @@ static NSTimeInterval launchStartedAt;
|
|
|
|
|
- (void)application:(UIApplication *)application
|
|
|
|
|
performFetchWithCompletionHandler:(void (^)(UIBackgroundFetchResult result))completionHandler
|
|
|
|
|
{
|
|
|
|
|
OWSLogInfo(@"performing background fetch");
|
|
|
|
|
NSLog(@"[Loki] Performing background fetch.");
|
|
|
|
|
[AppReadiness runNowOrWhenAppDidBecomeReady:^{
|
|
|
|
|
// Loki: We don't want to spin up the long poller here as it is probably wasteful on resources
|
|
|
|
|
__block AnyPromise *job = [AppEnvironment.shared.messageFetcherJob run].then(^{
|
|
|
|
|
// HACK: Call completion handler after n seconds.
|
|
|
|
|
//
|
|
|
|
|
// We don't currently have a convenient API to know when message fetching is *done* when
|
|
|
|
|
// working with the websocket.
|
|
|
|
|
//
|
|
|
|
|
// We *could* substantially rewrite the TSSocketManager to take advantage of the `empty` message
|
|
|
|
|
// But once our REST endpoint is fixed to properly de-enqueue fallback notifications, we can easily
|
|
|
|
|
// use the rest endpoint here rather than the websocket and circumvent making changes to critical code.
|
|
|
|
|
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(5 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
|
|
|
|
|
completionHandler(UIBackgroundFetchResultNewData);
|
|
|
|
|
job = nil;
|
|
|
|
|
});
|
|
|
|
|
completionHandler(UIBackgroundFetchResultNewData);
|
|
|
|
|
job = nil;
|
|
|
|
|
}).catch(^{
|
|
|
|
|
completionHandler(UIBackgroundFetchResultFailed);
|
|
|
|
|
job = nil;
|
|
|
|
|
});
|
|
|
|
|
[job retainUntilComplete];
|
|
|
|
|
}];
|
|
|
|
|