Warum endet eine Core-NFC-Sitzung von selbst?
Weil das System sie beendet und sagt, welches von fünf Dingen geschah: Der erste NDEF-Tag wurde gelesen, die Nutzenden haben abgebrochen, die Sitzung ist abgelaufen, das System war beschäftigt, oder sie endete unerwartet. Die Sitzung lässt sich danach nicht neu starten, die Anwendung legt also eine neue an.
Die fünf Arten, wie sie endet
Apple fasst sie als Fehler der Sitzung zusammen, und ihre Namen sagen, was geschah. readerSessionInvalidationErrorFirstNDEFTagRead kommt an, wenn eine Sitzung, die zum Lesen eines Tags angelegt wurde, ihn gelesen hat. readerSessionInvalidationErrorUserCanceled heißt, dass die Nutzenden das Fenster weggewischt haben. readerSessionInvalidationErrorSessionTimeout heißt, dass die Sitzung abgelaufen ist. readerSessionInvalidationErrorSystemIsBusy heißt, dass das System sie aus eigenen Gründen verweigert hat, und readerSessionInvalidationErrorSessionTerminatedUnexpectedly deckt den Rest ab.
Nur einer davon ist ein Fehler in Ihrer Anwendung, und es ist meist der erste: eine Sitzung, die mit invalidateAfterFirstRead auf wahr angelegt wurde, während die Anwendung weiterlesen wollte, was die Seite zu mehreren Tags entwirrt. Die anderen sind das System und die Nutzenden bei ihrer Arbeit.
Der Ablauf ohne Zahl
Apple dokumentiert den Fehler und nicht die Dauer. Eine Sitzung, die offen bleibt, ohne dass etwas vor ihr liegt, endet von selbst, und kein Wert in der Referenz sagt wann, eine Anwendung, die eine lange Reihe liest, plant also eine neue Sitzung zu öffnen, statt anzunehmen, dass die erste hält.
Dieses Schweigen hat eine praktische Folge: Die Dauer ist nichts, was sich aus einer Messung auf einem Telefon und einer Fassung fest eintragen ließe. Worauf Code sich verlassen kann, ist, dass der Fehler ankommt, und was er dann tut.
Was die Anwendung als Nächstes tut
Eine Sitzung ist einmalig. Einmal für ungültig erklärt, kann sie nicht erneut suchen, die Anwendung legt also eine neue an, was Apples eigenes Beispiel eines Tag-Lesegeräts nach jeder Ungültigkeit tut. Alles, was die Anwendung aus der alten Sitzung hielt, Tags eingeschlossen, ist veraltet.
Sagen Sie warum, wenn die Nutzenden handeln können. invalidate(errorMessage:) beendet eine Sitzung mit einer Meldung im Fenster des Systems, und alertMessage setzt den Text während ihr: Diese beiden sind der ganze Wortschatz, den die Anwendung im Fenster hat, was die Seite zum Lesefenster von der Seite der Nutzenden beschreibt. Eine abgebrochene Sitzung braucht überhaupt keine Meldung; ein beschäftigtes System verdient einen zweiten Versuch statt einer Erklärung.
Was vor dem Start einer zu prüfen ist
readingAvailable beantwortet, ob das Gerät überhaupt lesen kann, und Apple bittet Anwendungen, es vor dem Anlegen einer Sitzung zu prüfen. readerErrorRadioDisabled gibt es für einen abgeschalteten Funk, und readerErrorUnsupportedFeature für eine Funktion, die die Sitzung nicht unterstützt.
Und es läuft immer nur eine Lesesitzung im System, eine zweite wartet also: Eine Anwendung, die eine Sitzung startet, während eine andere offen ist, ist nicht gescheitert, sie steht in der Warteschlange, was die Seite zu den Sitzungen mit dem Rest des Modells behandelt.
Häufige Fragen
Kann ich eine für ungültig erklärte Sitzung neu starten?
Nein. Eine Sitzung ist einmalig: Einmal für ungültig erklärt, kann sie nicht erneut suchen, und die Anwendung legt eine neue an.
Wie lange dauert es, bis eine Sitzung abläuft?
Apples Referenz nennt keine Dauer. Behandeln Sie den Fehler des Ablaufs und öffnen Sie eine neue Sitzung, statt sich auf einen gemessenen Wert zu verlassen.
Welche Ungültigkeit ist meine Schuld?
Meist der erste gelesene NDEF-Tag, wenn die Sitzung so angelegt wurde, dass sie nach einem Tag endet, während die Anwendung weiterlesen wollte.
Was heißt, dass das System beschäftigt ist?
Das System hat die Sitzung aus eigenen Gründen verweigert. Versuchen Sie es einmal erneut, und sagen Sie es den Nutzenden nur, wenn es anhält.