Pourquoi une session Core NFC se termine-t-elle d'elle-même ?
Parce que le système y met fin, et dit laquelle de cinq choses est arrivée : le premier tag NDEF a été lu, l'utilisateur a annulé, la session a expiré, le système était occupé, ou elle s'est terminée de façon inattendue. La session ne peut pas être relancée ensuite, donc l'application en crée une neuve.
Les cinq façons dont elle finit
Apple les regroupe comme erreurs de session, et leurs noms disent ce qui s'est passé. readerSessionInvalidationErrorFirstNDEFTagRead arrive quand une session créée pour lire un seul tag l'a lu. readerSessionInvalidationErrorUserCanceled veut dire que l'utilisateur a écarté la feuille. readerSessionInvalidationErrorSessionTimeout veut dire que la session a expiré. readerSessionInvalidationErrorSystemIsBusy veut dire que le système l'a refusée pour ses propres raisons, et readerSessionInvalidationErrorSessionTerminatedUnexpectedly couvre le reste.
Une seule d'entre elles est un défaut de votre application, et c'est d'ordinaire la première : une session créée avec invalidateAfterFirstRead à vrai alors que l'application comptait continuer à lire, ce que démêle la page des tags multiples. Les autres sont le système et l'utilisateur qui font leur travail.
L'expiration sans chiffre
Apple documente l'erreur et non la durée. Une session qui reste ouverte sans rien devant elle se termine d'elle-même, et aucune valeur de la référence ne dit quand, donc une application qui lit une longue série prévoit d'ouvrir une nouvelle session plutôt que de supposer que la première durera.
Ce silence a une conséquence pratique : la durée n'est pas une valeur à figer dans le code d'après une mesure faite sur un téléphone et une version. Ce sur quoi le code peut compter est l'arrivée de l'erreur, et ce qu'il fait alors.
Ce que l'application fait ensuite
Une session sert une fois. Une fois invalidée elle ne peut plus scanner, donc l'application en crée une neuve, ce que l'exemple de lecteur de tags d'Apple fait lui-même après chaque invalidation. Tout ce que l'application détenait de l'ancienne session, tags compris, est périmé.
Dites pourquoi, quand l'utilisateur peut agir. invalidate(errorMessage:) termine une session avec un message dans la feuille système, et alertMessage en pose le texte pendant qu'elle dure : ces deux appels sont tout le vocabulaire dont l'application dispose à l'intérieur de la feuille, que la page de la feuille de lecture décrit du côté de l'utilisateur. Une session annulée n'a besoin d'aucun message ; un système occupé mérite une nouvelle tentative plutôt qu'une explication.
Ce qu'il faut vérifier avant d'en ouvrir une
readingAvailable dit si l'appareil sait lire tout court, et Apple demande aux applications de le vérifier avant de créer une session. readerErrorRadioDisabled existe pour une radio éteinte, et readerErrorUnsupportedFeature pour une fonction que la session ne prend pas en charge.
Et une seule session de lecteur tourne à la fois dans le système, donc une deuxième attend : une application qui démarre une session pendant qu'une autre est ouverte n'a pas échoué, elle est en file, ce que couvre avec le reste du modèle la page des sessions.
Questions fréquentes
Puis-je relancer une session invalidée ?
Non. Une session sert une fois : une fois invalidée elle ne peut plus scanner, et l'application en crée une neuve.
Au bout de combien de temps une session expire-t-elle ?
La référence d'Apple ne donne aucune durée. Traitez l'erreur d'expiration et ouvrez une nouvelle session plutôt que de dépendre d'une valeur mesurée.
Quelle invalidation est de ma faute ?
D'ordinaire la lecture du premier tag NDEF, quand la session a été créée pour finir après un tag alors que l'application comptait continuer à lire.
Que veut dire système occupé ?
Le système a refusé la session pour ses propres raisons. Réessayez une fois, et ne le dites à l'utilisateur que si cela persiste.