Warum scheitert ein Lesevorgang mit dem Fehler Tag verloren?
Weil der Tag das Feld verlassen hat, bevor der Austausch fertig war, was eine Hand in einer halben Sekunde tut. Android wirft TagLostException aus jedem Vorgang, der den Funk berührt, iOS scheitert mit einem Fehler über die verlorene Verbindung, und ein so abgebrochener Schreibvorgang hinterlässt ein Ergebnis, das noch niemand kennt.
Was jede Plattform auslöst
Unter Android kann jeder Vorgang, der den Funk berührt, ihn auslösen. Die Referenz zu TagLostException macht ihn zu einer Unterklasse von IOException, und connect(), transceive(), readPages() und writePage() deklarieren ihn alle. Ein anderer Fehler heißt ein anderes Problem: Ein Objekt Tag nach dem Verschwinden seines Tags wiederzuverwenden löst SecurityException aus, da dieses Objekt zu einem einzigen Erscheinen gehörte.
Unter iOS kommt dasselbe Ereignis als Fehlercode an. readerTransceiveErrorTagConnectionLost sagt, dass das Lesegerät die Verbindung zum Tag verloren hat, und seine Nachbarn benennen die anderen Fälle: readerTransceiveErrorTagNotConnected, wenn der Tag nicht im verbundenen Zustand ist, readerTransceiveErrorSessionInvalidated, wenn die Sitzung unter ihm geendet hat, readerTransceiveErrorRetryExceeded, wenn zu viele Wiederholungen geschehen sind.
Zuerst die Hand, dann der Code
Die körperlichen Ursachen kommen zuerst, weil sie die häufigen sind. Ein Schreibvorgang dauert länger als ein Lesevorgang, eine Geste, die verlässlich liest, kann also zu kurz zum Schreiben sein, was die Seite zum Abbruch auf halbem Weg von der Seite der Nutzenden beschreibt. Eine dicke Hülle, ein kleiner Tag oder ein ungünstiger Winkel lässt keinen Spielraum, und der Tag gerät mit einem Millimeter Bewegung außer Reichweite.
Die Ursachen im Code sind feiner. Jeder Befehl geht hin und zurück, eine Folge von zwanzig lässt also zwanzig Gelegenheiten, den Tag zu verlieren, und Arbeit zwischen zwei Befehlen, eine Berechnung oder schlimmer ein Aufruf über das Netz, hält den Tag ohne Grund offen. Mitten in einer Folge eine andere Technologieklasse zu öffnen kann die Plattform den Tag neu auswählen lassen, was die Seite zur Authentifizierung dort behandelt, wo es am meisten kostet.
Was mit dem verlorenen Tag zu tun ist
Behandeln Sie einen während eines Schreibvorgangs verlorenen Tag als ungewisses Ergebnis und nicht als Fehlschlag. Der Befehl kann den Tag erreicht haben, bevor die Antwort verloren ging, der nächste Schritt ist also, den Speicher zurückzulesen und nicht erneut zu schreiben, und eine Reihenfolge, die nichts halb Gültiges hinterlässt, macht das lesbar: Die Seite zu abgebrochenen Schreibvorgängen legt sie dar.
Beginnen Sie dann von vorn. Der Tag, der zurückkommt, ist eine neue Erkennung, ein neues Objekt Tag unter Android und eine neue Erkennung unter iOS, jede Authentifizierung ist weg, und eine Folge lässt sich nicht aus ihrer Mitte fortsetzen. Code, der einen Zustand über einen Verlust hinweg hält, muss ihn mit dem abgleichen, was er zurückliest.
Das Fenster weit genug machen
Verkürzen Sie den Austausch, statt die Wartezeit zu verlängern. Lesen Sie in den größten Blöcken, die das Protokoll anbietet, halten Sie die Zahl der Befehle klein, und erledigen Sie alles, was den Tag nicht braucht, vor dem Antippen, die Rechnung, die die Seite zu den Wartezeiten ausschreibt.
Entwerfen Sie dann die Oberfläche für eine Hand. Sagen Sie, wann das Telefon wegzunehmen ist, zeigen Sie den Abschluss erst, wenn der Aufruf zurückgekehrt ist, und prüfen Sie in einer Hand statt mit dem Telefon flach auf einem Tisch, wo sich das Fenster nie schließt und der Fehler nie erscheint.
Häufige Fragen
Ist ein Fehler über einen verlorenen Tag ein kaputter Tag?
Fast nie. Er heißt, dass der Tag das Feld mitten im Austausch verlassen hat. Derselbe Tag liest meist beim nächsten Versuch, wenn das Telefon still gehalten wird.
Kann ich einen Austausch fortsetzen, nachdem der Tag zurückkommt?
Nein. Der Tag, der zurückkommt, ist eine neue Erkennung, und jede Authentifizierung ist weg. Beginnen Sie bei der Erkennung, und lesen Sie zurück, bevor Sie erneut schreiben.
Warum scheitert ein Schreibvorgang öfter als ein Lesevorgang?
Er dauert länger, er braucht also ein längeres Halten. Eine Geste, die verlässlich liest, ist regelmäßig zu kurz zum Schreiben.
Was tut SecurityException hier?
Sie heißt, dass der Code ein Objekt Tag aus einem früheren Erscheinen wiederverwendet hat. Jede Erkennung gibt ein neues Objekt, und nur das neueste arbeitet.