WatchOS Background Tasks in Xamarin

Avec watchOS 3, il existe trois méthodes principales pour qu’une application espion puisse conserver ses informations à jour :

• Utilisation de l’une des nouvelles tâches en arrière-plan.
• Avoir l’une de ses complications sur le visage de montre (lui donnant plus de temps pour mettre à jour).
• Avoir l’utilisateur épingler à l’application la nouvelle station d’accueil (où elle est conservée en mémoire et mise à jour souvent).

Mise à jour d’une application

Avant de discuter de toutes les façons dont un développeur peut conserver les données et l’interface utilisateur d’une application watchOS actuelles et mises à jour, cette section examine un ensemble typique de modèles d’utilisation et comment un utilisateur peut passer de son i Téléphone et de son Apple Watch tout au long de la journée en fonction de l’heure de la journée et de l’activité qu’il effectue actuellement (par exemple, la conduite).

Prenons l’exemple suivant :

1. Le matin, en attendant en ligne pour un café, l’utilisateur parcoure les actualités actuelles sur leur i Téléphone pendant plusieurs minutes.
2. Avant de quitter le café, ils case activée rapidement le temps avec une Complication sur leur visage de montre.
3. Avant le déjeuner, ils utilisent l’application Cartes sur i Téléphone pour trouver un restaurant à proximité et réserver une réservation pour rencontrer un client.
4. En voyageant dans le restaurant, ils reçoivent une notification sur leur Apple Watch et avec un coup d’œil rapide, ils savent que leur rendez-vous déjeuner est en retard.
5. Le soir, ils utilisent l’application Cartes sur l’i Téléphone pour case activée le trafic avant de conduire à la maison.
6. Sur le chemin de la maison, ils reçoivent une notification iMessage sur leur Apple Watch leur demandant de récupérer du lait et ils utilisent la fonctionnalité Réponse rapide pour envoyer la réponse « OK ».

En raison de la nature « aperçu rapide » (moins de trois secondes) de la façon dont un utilisateur souhaite utiliser une application Apple Watch, il n’y a généralement pas suffisamment de temps pour que l’application récupère les informations souhaitées et met à jour son interface utilisateur avant de l’afficher à l’utilisateur.

En utilisant les nouvelles API qu’Apple a incluses dans watchOS 3, l’application peut planifier une actualisation en arrière-plan et disposer des informations souhaitées prêtes avant que l’utilisateur ne le demande. Prenez l’exemple de la complication météorologique décrite ci-dessus :

1. L’application planifie d’être réveillée par le système à un moment spécifique.
2. L’application récupère les informations nécessaires pour générer la mise à jour.
3. L’application régénère son interface utilisateur pour refléter les nouvelles données.
4. Lorsque l’utilisateur regarde la complication de l’application, il dispose d’informations à jour sans que l’utilisateur ait à attendre la mise à jour.

Comme indiqué ci-dessus, le système watchOS réveille l’application à l’aide d’une ou plusieurs tâches dont elle dispose d’un pool très limité :

Apple suggère de tirer le meilleur parti de cette tâche (car il s’agit d’une ressource si limitée à l’application) en la maintenant enfoncée jusqu’à ce que l’application ait terminé le processus de mise à jour elle-même.

Le système remet ces tâches en appelant la nouvelle HandleBackgroundTasks méthode du WKExtensionDelegate délégué. Par exemple :

using System;
using Foundation;
using WatchKit;

namespace MonkeyWatch.MonkeySeeExtension
{
  public class ExtensionDelegate : WKExtensionDelegate
  {
    #region Constructors
    public ExtensionDelegate ()
    {
    }
    #endregion

    #region Override Methods
    public override void HandleBackgroundTasks (NSSet<WKRefreshBackgroundTask> backgroundTasks)
    {
      // Handle background request here
      ...
    }
    #endregion
  }
}

Lorsque l’application a terminé la tâche donnée, elle la renvoie au système en le marquant comme terminé :

Nouvelles tâches en arrière-plan

watchOS 3 présente plusieurs tâches en arrière-plan qu’une application peut utiliser pour mettre à jour ses informations afin qu’elle dispose du contenu dont l’utilisateur a besoin avant d’ouvrir l’application, par exemple :

• Actualisation de l’application en arrière-plan : la tâche WKApplicationRefreshBackgroundTask permet à l’application de mettre à jour son état en arrière-plan. En règle générale, cela inclut une autre tâche, comme le téléchargement de nouveau contenu à partir d’Internet à l’aide d’un NSUrlSession.
• Actualisation de capture instantanée en arrière-plan : la tâche WKSnapshotRefreshBackgroundTask permet à l’application de mettre à jour son contenu et son interface utilisateur avant que le système ne prenne un instantané qui sera utilisé pour remplir la station d’accueil.
• Background Watch Connecter ivity - La tâche WKWatch Connecter ivityRefreshBackgroundTask est démarrée pour l’application lorsqu’elle reçoit des données en arrière-plan de l’i Téléphone jumelé.
• Session d’URL d’arrière-plan : la tâche WKURLSessionRefreshBackgroundTask est démarrée pour l’application lorsqu’un transfert en arrière-plan nécessite une autorisation ou une exécution (avec succès ou erreur).

Ces tâches seront abordées en détail dans les sections ci-dessous.

WKApplicationRefreshBackgroundTask

Il WKApplicationRefreshBackgroundTask s’agit d’une tâche générique qui peut être planifiée pour que l’application se soit réveillée à une date ultérieure :

Dans le runtime de la tâche, l’application peut effectuer n’importe quel type de traitement local, par exemple mettre à jour une chronologie Complications ou extraire certaines données requises avec un NSUrlSession.

WKURLSessionRefreshBackgroundTask

Le système envoie une WKURLSessionRefreshBackgroundTask fois les données téléchargées et prêtes à être traitées par l’application :

Une application n’est pas en cours d’exécution pendant le téléchargement des données en arrière-plan. Au lieu de cela, l’application planifie la demande de données, puis elle est suspendue et le système gère le téléchargement des données, ce qui n’entraîne que l’éveil de l’application une fois le téléchargement terminé.

WKSnapshotRefreshBackgroundTask

Dans watchOS 3, Apple a ajouté le Dock où les utilisateurs peuvent épingler leurs applications préférées et y accéder rapidement. Lorsque l’utilisateur appuie sur le bouton Latéral sur Apple Watch, une galerie d’instantanés d’application épinglés s’affiche. L’utilisateur peut balayer vers la gauche ou la droite pour rechercher l’application souhaitée, puis appuyer sur l’application pour la lancer en remplaçant l’instantané par l’interface de l’application en cours d’exécution.

Le système prend régulièrement des instantané de l’interface utilisateur de l’application (en en envoyant un WKSnapshotRefreshBackgroundTask) et utilise ces instantané s pour remplir la station d’accueil. watchOS donne à l’application la possibilité de mettre à jour son contenu et son interface utilisateur avant que cet instantané ne soit pris.

Les instantanés sont très importants dans watchOS 3, car ils fonctionnent à la fois comme les images d’aperçu et de lancement de l’application. Si l’utilisateur s’installe sur une application dans le Dock, il s’étend sur plein écran, entrez le premier plan et commencez à s’exécuter. Il est donc impératif que l’instantané soit à jour :

Là encore, le système émet un WKSnapshotRefreshBackgroundTask problème afin que l’application puisse se préparer (en mettant à jour les données et l’interface utilisateur) avant que la instantané soit prise :

Une fois l’application terminée WKSnapshotRefreshBackgroundTask , le système prend automatiquement un instantané de l’interface utilisateur de l’application.

Important

Il est important de toujours planifier une WKSnapshotRefreshBackgroundTask fois que l’application a reçu de nouvelles données et mis à jour son interface utilisateur ou que l’utilisateur ne voit pas les informations modifiées.

En outre, lorsque l’utilisateur reçoit une notification de l’application et appuie dessus pour mettre l’application au premier plan, l’instantané doit être à jour, car il agit également comme l’écran de lancement :

S’il a eu plus d’une heure depuis l’interaction de l’utilisateur avec une application watchOS, il sera en mesure de revenir à son état par défaut. L’état par défaut peut signifier différentes choses pour différentes applications et, en fonction de la conception d’une application, il peut ne pas avoir d’état par défaut du tout.

WKWatch Connecter ivityRefreshBackgroundTask

Dans watchOS 3, Apple a intégré la connectivité watch avec l’API d’actualisation en arrière-plan via la nouvelle WKWatchConnectivityRefreshBackgroundTask. À l’aide de cette nouvelle fonctionnalité, une application i Téléphone peut fournir de nouvelles données à son équivalent d’application espion, tandis que l’application watchOS s’exécute en arrière-plan :

Le lancement d’un push de complications, le contexte de l’application, l’envoi d’un fichier ou la mise à jour des informations utilisateur à partir de l’application i Téléphone réveille l’application Apple Watch en arrière-plan.

Lorsque l’application espion est réveillée par le biais d’une application, WKWatchConnectivityRefreshBackgroundTask elle doit utiliser les méthodes d’API standard pour recevoir les données de l’application i Téléphone.

1. Vérifiez que la session a été activée.
2. Surveillez la nouvelle HasContentPending propriété tant que la valeur est true, l’application a toujours des données à traiter. Comme précédemment, l’application doit conserver la tâche jusqu’à ce qu’elle ait terminé le traitement de toutes les données.
3. Lorsqu’il n’y a plus de données à traiter (HasContentPending = false), marquez la tâche terminée pour la renvoyer au système. L’échec de cette opération épuise le runtime d’arrière-plan alloué de l’application, ce qui entraîne un rapport d’incident.

Cycle de vie de l’API en arrière-plan

Placer tous les éléments de la nouvelle API Tâches en arrière-plan ensemble, un ensemble classique d’interactions se présente comme suit :

1. Tout d’abord, l’application watchOS planifie une tâche en arrière-plan pour être réveillée comme un point à l’avenir.
2. L’application est réveillée par le système et a envoyé une tâche.
3. L’application traite la tâche pour effectuer le travail nécessaire.
4. En raison du traitement de la tâche, l’application peut avoir besoin de planifier davantage de tâches en arrière-plan pour effectuer plus de travail à l’avenir, telles que le téléchargement d’un contenu supplémentaire à l’aide d’un NSUrlSession.
5. L’application marque la tâche terminée et la retourne au système.

Utilisation des ressources de manière responsable

Il est essentiel qu’une application watchOS se comporte de manière responsable au sein de cet écosystème en limitant son drainage sur les ressources partagées du système.

Examinez le scénario suivant :

1. L’utilisateur lance une application watchOS à 13h00.
2. L’application planifie une tâche pour se réveiller et télécharger du nouveau contenu en une heure à 2 h 00.
3. À 13 h 50, l’utilisateur ouvre à nouveau l’application qui lui permet de mettre à jour ses données et son interface utilisateur pour l’instant.
4. Au lieu de laisser la tâche réactiver l’application en 10 minutes, l’application doit replanifier la tâche pour qu’elle s’exécute une heure plus tard à 2 h 50.

Bien que chaque application soit différente, Apple suggère de trouver des modèles d’utilisation, comme ceux indiqués ci-dessus, pour aider à conserver les ressources système.

Implémentation de tâches en arrière-plan

Par exemple, ce document utilisera l’application de sport MonkeySoccer factice qui signale les scores de soccer à l’utilisateur.

Examinez le scénario d’utilisation classique suivant :

L’équipe de football préférée de l’utilisateur joue un grand match de 17h00 à 19h00, de sorte que l’application doit s’attendre à ce que l’utilisateur soit case activée régulièrement le score et il décide d’un intervalle de mise à jour de 30 minutes.

1. L’utilisateur ouvre l’application et planifie une tâche pour la mise à jour en arrière-plan 30 minutes plus tard. L’API en arrière-plan autorise l’exécution d’un seul type de tâche en arrière-plan à un moment donné.
2. L’application reçoit la tâche et met à jour ses données et son interface utilisateur, puis planifie une autre tâche en arrière-plan 30 minutes plus tard. Il est important que le développeur se rappelle de planifier une autre tâche en arrière-plan, ou l’application ne sera jamais réexéculée pour obtenir plus de mises à jour.
3. Là encore, l’application reçoit la tâche et met à jour ses données, met à jour son interface utilisateur et planifie une autre tâche en arrière-plan 30 minutes plus tard.
4. Le même processus se répète à nouveau.
5. La dernière tâche en arrière-plan est reçue et l’application met à jour à nouveau ses données et son interface utilisateur. Comme il s’agit du score final, il ne planifie pas une nouvelle actualisation en arrière-plan.

Planification de la mise à jour en arrière-plan

Étant donné le scénario ci-dessus, l’application MonkeySoccer peut utiliser le code suivant pour planifier une mise à jour en arrière-plan :

private void ScheduleNextBackgroundUpdate ()
{
  // Create a fire date 30 minutes into the future
  var fireDate = NSDate.FromTimeIntervalSinceNow (30 * 60);

  // Create
  var userInfo = new NSMutableDictionary ();
  userInfo.Add (new NSString ("LastActiveDate"), NSDate.FromTimeIntervalSinceNow(0));
  userInfo.Add (new NSString ("Reason"), new NSString ("UpdateScore"));

  // Schedule for update
  WKExtension.SharedExtension.ScheduleBackgroundRefresh (fireDate, userInfo, (error) => {
    // Was the Task successfully scheduled?
    if (error == null) {
      // Yes, handle if needed
    } else {
      // No, report error
    }
  });
}

Il crée une nouvelle NSDate 30 minutes à l’avenir lorsque l’application souhaite être réveillée et crée un NSMutableDictionary pour contenir les détails de la tâche demandée. La ScheduleBackgroundRefresh méthode du fichier SharedExtension est utilisée pour demander la planification de la tâche.

Le système retourne une NSError valeur si elle n’a pas pu planifier la tâche demandée.

Traitement de la mise à jour

Ensuite, examinez plus en profondeur la fenêtre de 5 minutes montrant les étapes requises pour mettre à jour le score :

1. À 17 h 30 : 02, l’application est réveillée par le système et en fonction de la tâche en arrière-plan de mise à jour. Sa première priorité est d’obtenir les derniers scores du serveur. Consultez Planification d’une NSUrlSession ci-dessous.
2. À 7 :30 :05, l’application termine la tâche d’origine, le système place l’application en veille et continue à télécharger les données demandées en arrière-plan.
3. Lorsque le système termine le téléchargement, il crée une tâche pour réveiller l’application afin qu’elle puisse traiter les informations téléchargées. Consultez Gestion des tâches en arrière-plan et gestion de la fin du téléchargement ci-dessous.
4. L’application enregistre les informations mises à jour et marque la tâche terminée. Le développeur peut être tenté de mettre à jour l’interface utilisateur de l’application pour l’instant, mais Apple suggère de planifier une tâche d’instantané pour gérer ce processus. Consultez Planification d’une mise à jour d’instantané ci-dessous.
5. L’application reçoit la tâche d’instantané, met à jour son interface utilisateur et marque la tâche terminée. Consultez Gestion d’une mise à jour d’instantané ci-dessous.

Planification d’une NSUrlSession

Le code suivant peut être utilisé pour planifier le téléchargement des scores les plus récents :

private void ScheduleURLUpdateSession ()
{
  // Create new configuration
  var configuration = NSUrlSessionConfiguration.CreateBackgroundSessionConfiguration ("com.example.urlsession");

  // Create new session
  var backgroundSession = NSUrlSession.FromConfiguration (configuration);

  // Create and start download task
  var downloadTask = backgroundSession.CreateDownloadTask (new NSUrl ("https://example.com/gamexxx/currentScores.json"));
  downloadTask.Resume ();
}

Il configure et crée un nouveau NSUrlSession, puis utilise cette session pour créer une tâche de téléchargement à l’aide de la CreateDownloadTask méthode. Il appelle la Resume méthode de la tâche de téléchargement pour démarrer la session.

Gestion des tâches en arrière-plan

En substituant la HandleBackgroundTasks méthode du WKExtensionDelegate, l’application peut gérer les tâches en arrière-plan entrantes :

using System;
using System.Collections.Generic;
using Foundation;
using WatchKit;

namespace MonkeySoccer.MonkeySoccerExtension
{
  public class ExtensionDelegate : WKExtensionDelegate
  {
    #region Computed Properties
    public List<WKRefreshBackgroundTask> PendingTasks { get; set; } = new List<WKRefreshBackgroundTask> ();
    #endregion

    ...

    #region Public Methods
    public void CompleteTask (WKRefreshBackgroundTask task)
    {
      // Mark the task completed and remove from the collection
      task.SetTaskCompleted ();
      PendingTasks.Remove (task);
    }
    #endregion

    #region Override Methods
    public override void HandleBackgroundTasks (NSSet<WKRefreshBackgroundTask> backgroundTasks)
    {
      // Handle background request
      foreach (WKRefreshBackgroundTask task in backgroundTasks) {
        // Is this a background session task?
        var urlTask = task as WKUrlSessionRefreshBackgroundTask;
        if (urlTask != null) {
          // Create new configuration
          var configuration = NSUrlSessionConfiguration.CreateBackgroundSessionConfiguration (urlTask.SessionIdentifier);

          // Create new session
          var backgroundSession = NSUrlSession.FromConfiguration (configuration, new BackgroundSessionDelegate (this, task), null);

          // Keep track of all pending tasks
          PendingTasks.Add (task);
        } else {
          // Ensure that all tasks are completed
          task.SetTaskCompleted ();
        }
      }
    }
    #endregion

    ...
  }
}

La HandleBackgroundTasks méthode effectue un cycle dans toutes les tâches que le système a envoyées à l’application (in backgroundTasks) à la recherche d’un WKUrlSessionRefreshBackgroundTask. Si l’un d’eux est trouvé, il rejoint la session et joint un NSUrlSessionDownloadDelegate pour gérer la fin du téléchargement (voir Gestion de la fin du téléchargement ci-dessous) :

// Create new session
var backgroundSession = NSUrlSession.FromConfiguration (configuration, new BackgroundSessionDelegate (this, task), null);

Elle conserve un handle sur la tâche jusqu’à ce qu’elle soit terminée en l’ajoutant à une collection :

public List<WKRefreshBackgroundTask> PendingTasks { get; set; } = new List<WKRefreshBackgroundTask> ();
...

// Keep track of all pending tasks
PendingTasks.Add (task);

Toutes les tâches envoyées à l’application doivent être terminées, pour qu’aucune tâche ne soit actuellement gérée, marquez-la :

if (urlTask != null) {
  ...
} else {
  // Ensure that all tasks are completed
  task.SetTaskCompleted ();
}

Gestion de la fin du téléchargement

L’application MonkeySoccer utilise le délégué suivant NSUrlSessionDownloadDelegate pour gérer la fin du téléchargement et traiter les données demandées :

using System;
using Foundation;
using WatchKit;

namespace MonkeySoccer.MonkeySoccerExtension
{
  public class BackgroundSessionDelegate : NSUrlSessionDownloadDelegate
  {
    #region Computed Properties
    public ExtensionDelegate WatchExtensionDelegate { get; set; }

    public WKRefreshBackgroundTask Task { get; set; }
    #endregion

    #region Constructors
    public BackgroundSessionDelegate (ExtensionDelegate extensionDelegate, WKRefreshBackgroundTask task)
    {
      // Initialize
      this.WatchExtensionDelegate = extensionDelegate;
      this.Task = task;
    }
    #endregion

    #region Override Methods
    public override void DidFinishDownloading (NSUrlSession session, NSUrlSessionDownloadTask downloadTask, NSUrl location)
    {
      // Handle the downloaded data
      ...

      // Mark the task completed
      WatchExtensionDelegate.CompleteTask (Task);

    }
    #endregion
  }
}

Lorsqu’il est initialisé, il conserve un handle à la fois pour le ExtensionDelegate et pour celui WKRefreshBackgroundTask qui l’a généré. Il remplace la DidFinishDownloading méthode pour gérer la fin du téléchargement. Utilise ensuite la CompleteTask méthode de la ExtensionDelegate tâche pour informer la tâche qu’elle a terminée et la supprimer de la collection de tâches en attente. Consultez Gestion des tâches en arrière-plan ci-dessus.

Planification d’une mise à jour d’instantané

Le code suivant peut être utilisé pour planifier une tâche d’instantané pour mettre à jour l’interface utilisateur avec les scores les plus récents :

private void ScheduleSnapshotUpdate ()
{
  // Create a fire date of now
  var fireDate = NSDate.FromTimeIntervalSinceNow (0);

  // Create user info dictionary
  var userInfo = new NSMutableDictionary ();
  userInfo.Add (new NSString ("lastActiveDate"), NSDate.FromTimeIntervalSinceNow (0));
  userInfo.Add (new NSString ("reason"), new NSString ("UpdateScore"));

  // Schedule for update
  WKExtension.SharedExtension.ScheduleSnapshotRefresh (fireDate, userInfo, (error) => {
    // Was the Task successfully scheduled?
    if (error == null) {
      // Yes, handle if needed
    } else {
      // No, report error
    }
  });
}

Tout comme ScheduleURLUpdateSession la méthode ci-dessus, elle crée une nouvelle NSDate pour quand l’application souhaite être réveillée et crée un NSMutableDictionary pour contenir les détails de la tâche demandée. La ScheduleSnapshotRefresh méthode du fichier SharedExtension est utilisée pour demander la planification de la tâche.

Le système retourne une NSError valeur si elle n’a pas pu planifier la tâche demandée.

Gestion d’une mise à jour d’instantané

Pour gérer la tâche d’instantané, la HandleBackgroundTasks méthode (voir Gestion des tâches en arrière-plan ci-dessus) est modifiée pour ressembler à ce qui suit :

public override void HandleBackgroundTasks (NSSet<WKRefreshBackgroundTask> backgroundTasks)
{
  // Handle background request
  foreach (WKRefreshBackgroundTask task in backgroundTasks) {
    // Take action based on task type
    if (task is WKUrlSessionRefreshBackgroundTask) {
      var urlTask = task as WKUrlSessionRefreshBackgroundTask;

      // Create new configuration
      var configuration = NSUrlSessionConfiguration.CreateBackgroundSessionConfiguration (urlTask.SessionIdentifier);

      // Create new session
      var backgroundSession = NSUrlSession.FromConfiguration (configuration, new BackgroundSessionDelegate (this, task), null);

      // Keep track of all pending tasks
      PendingTasks.Add (task);
    } else if (task is WKSnapshotRefreshBackgroundTask) {
      var snapshotTask = task as WKSnapshotRefreshBackgroundTask;

      // Update UI
      ...

      // Create a expiration date 30 minutes into the future
      var expirationDate = NSDate.FromTimeIntervalSinceNow (30 * 60);

      // Create user info dictionary
      var userInfo = new NSMutableDictionary ();
      userInfo.Add (new NSString ("lastActiveDate"), NSDate.FromTimeIntervalSinceNow (0));
      userInfo.Add (new NSString ("reason"), new NSString ("UpdateScore"));

      // Mark task complete
      snapshotTask.SetTaskCompleted (false, expirationDate, userInfo);
    } else {
      // Ensure that all tasks are completed
      task.SetTaskCompleted ();
    }
  }
}

La méthode teste le type de tâche en cours de traitement. S’il s’agit d’un WKSnapshotRefreshBackgroundTask élément qui obtient l’accès à la tâche :

var snapshotTask = task as WKSnapshotRefreshBackgroundTask;

La méthode met à jour l’interface utilisateur, puis crée un NSDate pour indiquer au système quand l’instantané sera obsolète. Il crée un avec des NSMutableDictionary informations utilisateur pour décrire le nouvel instantané et marque la tâche d’instantané terminée avec ces informations :

// Mark task complete
snapshotTask.SetTaskCompleted (false, expirationDate, userInfo);

En outre, il indique également à la tâche d’instantané que l’application ne revient pas à l’état par défaut (dans le premier paramètre). Les applications qui n’ont aucun concept d’état par défaut doivent toujours définir cette propriété truesur .

Travailler efficacement

Comme indiqué dans l’exemple ci-dessus de la fenêtre de cinq minutes que l’application MonkeySoccer a pris pour mettre à jour ses scores, en travaillant efficacement et en utilisant les nouvelles tâches en arrière-plan watchOS 3, l’application n’a été active que pendant un total de 15 secondes :

Cela réduit l’impact que l’application aura sur les ressources Apple Watch disponibles et la durée de vie de la batterie et permet également à l’application de fonctionner mieux avec d’autres applications s’exécutant sur la montre.

Fonctionnement de la planification

Alors qu’une application watchOS 3 est au premier plan, elle est toujours planifiée pour s’exécuter et peut effectuer n’importe quel type de traitement requis, comme mettre à jour les données ou redessiner son interface utilisateur. Lorsque l’application se déplace en arrière-plan, elle est généralement suspendue par le système et toutes les opérations d’exécution sont arrêtées.

Bien que l’application soit en arrière-plan, elle peut être ciblée par le système pour exécuter rapidement une tâche spécifique. Par conséquent, dans watchOS 2, le système peut temporairement réveiller une application en arrière-plan pour effectuer des opérations telles que la gestion d’une notification de longue apparence ou la mise à jour de la complication de l’application. Dans watchOS 3, il existe plusieurs nouvelles façons d’exécuter une application en arrière-plan.

Alors qu’une application est en arrière-plan, le système impose plusieurs limites :

• Il n’est donné que quelques secondes pour terminer une tâche donnée. Le système prend en considération non seulement la durée passée, mais également la puissance du processeur que l’application consomme pour dériver cette limite.
• Toute application qui dépasse ses limites sera tuée avec les codes d’erreur suivants :
  • PROCESSEUR - 0xc51bad01
  • Heure - 0xc51bad02
• Le système impose différentes limites en fonction du type de tâche en arrière-plan qu’il a demandé à l’application d’effectuer. Par exemple, WKApplicationRefreshBackgroundTask les WKURLSessionRefreshBackgroundTask tâches reçoivent des runtimes légèrement plus longs sur d’autres types de tâches en arrière-plan.

Complications et Mises à jour d’applications

Outre les nouvelles tâches en arrière-plan ajoutées par Apple à watchOS 3, les complications d’une application watchOS peuvent avoir une incidence sur la façon et le moment où l’application reçoit des mises à jour en arrière-plan.

Les complications sont de petits éléments visuels qui fournissent des informations utiles en un clin d’œil. Selon le visage de montre sélectionné, l’utilisateur a la possibilité de personnaliser un visage de montre avec une ou plusieurs Complications qui peuvent être fournies par une application espion dans watchOS 3.

Si l’utilisateur inclut l’une des complications de l’application sur son visage de montre, elle offre à l’application les avantages mis à jour suivants :

• Le système maintient l’application dans un état prêt à démarrer, où elle tente de lancer l’application en arrière-plan, la conserve en mémoire et lui donne un temps supplémentaire de mise à jour.
• Les complications sont garanties au moins 50 mises à jour push par jour.

Le développeur doit toujours s’efforcer de créer des complications attrayantes pour leurs applications afin d’inciter l’utilisateur à l’ajouter à son visage de montre pour les raisons répertoriées ci-dessus.

Dans watchOS 2, les complications étaient la principale façon dont une application a reçu le runtime alors qu’elle était en arrière-plan. Dans watchOS 3, une application Complication sera toujours assurée de recevoir plusieurs mises à jour par heure, mais elle peut utiliser WKExtensions pour demander plus d’exécution pour mettre à jour ses complications.

Examinez le code suivant utilisé pour mettre à jour la complication à partir de l’application i Téléphone connectée :

using System;
using WatchConnectivity;
using UIKit;
using Foundation;
using System.Collections.Generic;
using System.Linq;
...

private void UpdateComplication ()
{

  // Get session and the number of remaining transfers
  var session = WCSession.DefaultSession;
  var transfers = session.RemainingComplicationUserInfoTransfers;

  // Create user info dictionary
  var iconattrs = new Dictionary<NSString, NSObject>
    {
      {new NSString ("lastActiveDate"), NSDate.FromTimeIntervalSinceNow (0)},
      {new NSString ("reason"), new NSString ("UpdateScore")}
    };

  var userInfo = NSDictionary<NSString, NSObject>.FromObjectsAndKeys (iconattrs.Values.ToArray (), iconattrs.Keys.ToArray ());

  // Take action based on the number of transfers left
  if (transfers < 1) {
    // No transfers left, either attempt to send or inform
    // user of situation.
    ...
  } else if (transfers < 11) {
    // Running low on transfers, only send on important updates
    // else conserve for a significant change.
    ...
  } else {
    // Send data
    session.TransferCurrentComplicationUserInfo (userInfo);
  }
}

Il utilise la RemainingComplicationUserInfoTransfers propriété du WCSession fichier pour voir le nombre de transferts de haute priorité laissés par l’application pour le jour, puis prend des mesures en fonction de ce nombre. Si l’application commence à s’exécuter faiblement sur les transferts, elle peut bloquer l’envoi de mises à jour mineures et envoyer uniquement des informations lorsqu’il y a une modification significative.

Planification et station d’accueil

Dans watchOS 3, Apple a ajouté le Dock où les utilisateurs peuvent épingler leurs applications préférées et y accéder rapidement. Lorsque l’utilisateur appuie sur le bouton Latéral sur Apple Watch, une galerie d’applications épinglées instantané s s’affiche. L’utilisateur peut balayer vers la gauche ou la droite pour rechercher l’application souhaitée, puis appuyer sur l’application pour la lancer en remplaçant l’instantané par l’interface de l’application en cours d’exécution.

Le système prend régulièrement des instantané de l’interface utilisateur de l’application et utilise ces instantané pour remplir la documentation. WatchOS donne à l’application la possibilité de mettre à jour son contenu et son interface utilisateur avant que cette instantané soit prise.

Les applications épinglées au dock peuvent s’attendre à ce qui suit :

• Ils recevront un minimum d’une mise à jour par heure. Cela inclut à la fois une tâche d’actualisation d’application et une tâche d’instantané.
• Le budget de mise à jour est distribué entre toutes les applications du Dock. Ainsi, moins d’applications l’utilisateur a épinglé, plus les mises à jour potentielles seront reçues par chaque application.
• L’application est conservée en mémoire afin que l’application reprend rapidement lorsqu’elle est sélectionnée à partir du dock.

La dernière application exécutée par l’utilisateur sera considérée comme l’application la plus récemment utilisée et occupera le dernier emplacement du dock. À partir de là, l’utilisateur peut choisir de l’épingler définitivement à la station d’accueil. La dernière utilisation sera traitée comme toute autre application préférée que l’utilisateur a déjà épinglée au Dock.

Important

Les applications qui n’ont été ajoutées qu’à l’écran d’accueil ne reçoivent aucune planification régulière. Pour recevoir des mises à jour régulières de planification et d’arrière-plan, une application doit être ajoutée au Dock.

Comme indiqué précédemment dans ce document, les instantanés sont très importants dans watchOS 3, car ils fonctionnent à la fois comme aperçu et lancer des images pour l’application. Si l’utilisateur s’installe sur une application dans le Dock, il s’étend sur plein écran, entrez le premier plan et commencez à s’exécuter. Il est donc impératif que l’instantané soit à jour.

Il peut arriver que le système décide qu’il a besoin d’un nouvel instantané de l’interface utilisateur de l’application. Dans ce cas, la demande d’instantané n’est pas comptabilisée par rapport au budget d’exécution de l’application. Les éléments suivants déclenchent une demande d’instantané système :

• Une mise à jour chronologie de complications.
• Interaction utilisateur avec la notification d’une application.
• Passage du premier plan à l’état d’arrière-plan.
• Après une heure d’état d’arrière-plan, l’application peut donc revenir à l’état par défaut.
• Quand watchOS démarre pour la première fois.

Meilleures pratiques

Apple suggère les meilleures pratiques suivantes lors de l’utilisation des tâches en arrière-plan :

• Planifiez aussi souvent que l’application doit être mise à jour. Chaque fois que l’application s’exécute, elle doit réévaluer ses besoins futurs et ajuster cette planification selon les besoins.
• Si le système envoie une tâche d’actualisation en arrière-plan et que l’application ne nécessite pas de mise à jour, reportez le travail tant qu’une mise à jour n’est pas réellement nécessaire.
• Considérez toutes les opportunités d’exécution disponibles pour une application :
  • Ancrer et activer au premier plan.
  • Notifications.
  • Mises à jour des complications.
  • Actualisations en arrière-plan.
• Utilisez-le ScheduleBackgroundRefresh pour le runtime en arrière-plan à usage général, par exemple :
  • Interrogation du système pour obtenir des informations.
  • Planifiez l’avenir NSURLSessions pour demander des données en arrière-plan.
  • Transitions de temps connues.
  • Déclenchement des mises à jour de complications.

Meilleures pratiques en matière de capture instantanée

Lors de l’utilisation des mises à jour d’instantanés, Apple apporte les suggestions suivantes :

• Invalider les instantanés uniquement si nécessaire, par exemple lorsqu’il existe une modification significative du contenu.
• Évitez l’invalidation d’instantané à haute fréquence. Par exemple, une application de minuteur ne doit pas mettre à jour l’instantané toutes les secondes, elle ne doit être effectuée qu’à la fin du minuteur.

Flux de données d’application

Apple suggère les éléments suivants pour utiliser le flux de données :

Un événement externe (tel que Watch Connecter ivity) réveille l’application. Cela force l’application à mettre à jour son modèle de données (qui représente l’état actuel des applications). En raison de la modification du modèle de données, l’application devra mettre à jour ses complications, demander un nouvel instantané, éventuellement démarrer un arrière-plan NSURLSession pour extraire plus de données et planifier d’autres actualisations en arrière-plan.

Cycle de vie des applications

En raison de la station d’accueil et de la possibilité d’épingler des applications favorites à celui-ci, Apple pense que les utilisateurs vont passer d’une autre application, beaucoup plus souvent, puis ils l’ont fait avec watchOS 2. Par conséquent, l’application doit être prête à gérer cette modification et à se déplacer rapidement entre le premier plan et les états d’arrière-plan.

Apple propose les suggestions suivantes :

• Vérifiez que l’application termine toute tâche en arrière-plan dès que possible lors de l’activation au premier plan.
• Veillez à terminer tout travail de premier plan avant d’entrer l’arrière-plan en appelant NSProcessInfo.PerformExpiringActivity.
• Lors du test d’une application dans le simulateur watchOS, aucun budget de tâche n’est appliqué afin qu’une application puisse actualiser autant que nécessaire pour tester correctement une fonctionnalité.
• Testez toujours sur le matériel Apple Watch réel pour vous assurer que l’application ne fonctionne pas après ses budgets avant de publier sur iTunes Connecter.
• Apple suggère de garder l’Apple Watch sur le chargeur tout en testant et débogueur.
• Vérifiez que le lancement à froid et la reprise d’une application sont soigneusement testés.
• Vérifiez que toutes les tâches d’application sont terminées.
• Variez le nombre d’applications épinglées dans le Dock pour tester les scénarios les plus optimaux et les pires.

Résumé

Cet article a abordé les améliorations apportées à Apple pour watchOS et la façon dont ils peuvent être utilisés pour maintenir une application espion à jour. Tout d’abord, il a couvert toutes les nouvelles tâches en arrière-plan qu’Apple a ajoutées dans watchOS 3. Ensuite, il a abordé le cycle de vie de l’API en arrière-plan et comment implémenter des tâches en arrière-plan dans une application Xamarin watchOS. Enfin, il a abordé le fonctionnement de la planification et a donné quelques bonnes pratiques.