Quitter une application Watchkit est géré par le operating system Watchkit lui-même, je n'ai pas besoin d'effacer ou de réinitialiser l'écran?

OK, c'est assez basique mais j'ai lu la documentation encore et encore et je veux être sûr d'avoir bien compris. En clair, mon application watchkit sera fermée par une interaction de l'user sortant de l'application qui est externe à mon code, non? Je n'ai pas besoin d'effacer ou de réinitialiser l'écran avec une procédure de fermeture qui le configure pour une autre exécution? Je n'ai pas besoin de créer une routine "Exit" ou "Close app", n'est-ce pas? C'est déroutant parce que la documentation implique que l'application sera désactivée une fois qu'elle n'est plus à l'écran (probablement par une action de l'user comme glisser vers une autre application) et que cela appellera la fonction didDeactivate . Mais la documentation affirme également:

Dans iOS Simulator, WatchKit appelle la méthode didDeactivate pour le controller d'interface actuel lorsque vous verrouillez le simulateur en sélectionnant Hardware> Lock. Lorsque vous déverrouillez le simulateur, WatchKit appelle de nouveau la méthode willActivate du controller d'interface. Vous pouvez utiliser cette fonctionnalité pour déboguer votre code d'activation et de désactivation.

Mais le simulateur ne semble pas libérer la memory ou réinitialiser les variables ou réinitialiser mon application de quelque façon que ce soit. Il rest persistant sur l'écran dans l'état au moment du verrou, et il revient dans cet état lorsque je le déverrouille. Ce qui m'inquiète, c'est que si je me trompe, j'ai une application créée pour une course. Mais je ne vois pas de routines pour l'arrêt, le dégagement de l'écran ou l'un des éléments auxquels vous vous attendez dans une routine d'arrêt conventionnel.

Je suis d'accord que la documentation peut être déroutante. La manière la plus simple d'y penser est que willActivate est appelé chaque fois que votre controller d'interface est affiché / activé. De même, didDeactivate est appelé chaque fois qu'il est caché / désactivé. Ainsi, si vous feuilletez des pages de controllers, chacun recevra un willActivate lorsqu'il apparaîtra et un didDeactivate lorsqu'il disparaîtra. De même, si un controller est désactivé parce que l'application n'est plus visible (par exemple, il a été suspendu), didDeactivate sera appelé. Si l'user lève son poignet pour reprendre l'application, willActivate est appelé, car le controller d'interface est affiché.

Il n'y a aucune promise quant à savoir si votre application WatchKit sera suspendue ou interrompue (cela dépend du operating system), donc vous devez considérer les deux possibilités. Basé sur l'expérience, je sais que laisser tomber votre arm appellera didDeactivate avant de suspendre votre application. Si vous relevez votre poignet, l'application reprendra et appellera willActivate. Lors de mes tests, l'application était simplement suspendue (non terminée) dans cette situation.

Vous avez raison de dire qu'il n'y a pas de méthode embeddede qui est appelée lorsque l'application est terminée. Cependant, iOS 8.2 a ajouté quatre notifications pouvant être utilisées pour surveiller l'état de l'application / de l'extension:

NSExtensionHostDidBecomeActiveNotification
NSExtensionHostDidEnterBackgroundNotification
NSExtensionHostWillEnterForegroundNotification
NSExtensionHostWillResignActiveNotification