iOS Configuration de la configuration d'arrière-plan


Exemple

Pour créer une session d'arrière-plan

 // Swift:
 let mySessionID = "com.example.bgSession"
 let bgSessionConfig = NSURLSessionConfiguration.backgroundSessionConfigurationWithIdentifier(mySessionID)
 
 let session = NSURLSession(configuration: bgSessionConfig)
 
 // add tasks here


 // Objective-C:
 NSString *mySessionID = @"com.example.bgSession";
 NSURLSessionConfiguration *configuration =
     [NSURLSessionConfiguration backgroundSessionConfigurationWithIdentifier: mySessionID];
 NSURLSession *session = [NSURLSession sessionWithConfiguration:configuration
                                                       delegate:self]

De plus, dans iOS, vous devez configurer le support pour gérer le relancement des applications en arrière-plan. Lorsque l'application de votre application:handleEventsForBackgroundURLSession:completionHandler: method (Objective-C) ou application(_:handleEventsForBackgroundURLSession:completionHandler:) méthode (Swift) est appelée, cela signifie que votre application a été relancée en arrière-plan pour gérer l'activité sur une session.

Dans cette méthode, vous devez créer une nouvelle session avec l'identifiant fourni et le configurer avec un délégué pour gérer les événements comme vous le feriez normalement au premier plan. En outre, vous devez stocker le gestionnaire d'achèvement fourni dans un dictionnaire, en utilisant la session comme clé.

Lorsque la URLSessionDidFinishEventsForBackgroundURLSession: (Obj-C) / URLSessionDidFinishEventsForBackgroundURLSession (Swift) du délégué est appelée pour vous informer qu'il n'y a plus d'événements à gérer, votre application doit rechercher le gestionnaire d'achèvement pour cette session, supprimer la session du dictionnaire et appeler le gestionnaire d'achèvement, indiquant ainsi au système d'exploitation que vous n'avez plus aucun traitement en attente lié à la session. (Si vous faites toujours quelque chose pour une raison quelconque lorsque vous recevez cet appel de délégué, attendez d'avoir terminé.) Dès que vous appelez cette méthode, la session d'arrière-plan est immédiatement invalidée.

Si votre application reçoit ensuite une application:application:didFinishLaunchingWithOptions: call (indiquant probablement que l’utilisateur a mis au premier plan votre application alors que vous étiez en train de traiter des événements en arrière-plan), créer une session en arrière avec ce même identifiant l'identifiant n'existe plus.

Si vous êtes curieux des détails, à un niveau élevé, lorsque vous créez une session d'arrière-plan, vous faites deux choses:

  • Création d'une session dans un démon externe (nsurlsessiond) pour gérer les téléchargements
  • Créer une session dans votre application qui communique avec ce démon externe via NSXPC

Normalement, il est dangereux de créer deux sessions avec le même ID de session dans un seul lancement de l'application, car elles tentent toutes deux de communiquer avec la même session dans le démon d'arrière-plan. C'est pourquoi la documentation officielle dit de ne jamais créer plusieurs sessions avec le même identifiant. Toutefois, si la première session était une session temporaire créée dans le cadre d'un appel handleEventsForBackgroundURLSession , l'association entre la session in-app maintenant invalidée et la session du démon d'arrière-plan n'existe plus.