Wie erkennt man, dass ein Tag das Feld verlassen hat?

Unter Android

Der gewöhnliche Ablauf kennt kein Ereignis für das Entfernen. Die Plattform prüft, dass ein erkannter Tag noch da ist, und der Lesemodus lässt eine Anwendung über EXTRA_READER_PRESENCE_CHECK_DELAY einstellen, wie oft, was die Referenz zu NfcAdapter als die Wartezeit beschreibt, mit der die Plattform die Anwesenheit prüft. Was die Anwendung sieht, ist ihr nächster Aufruf, der mit TagLostException scheitert, einer Unterklasse von IOException.

isConnected() beantwortet die Frage nicht. Die Referenz zu TagTechnology sagt, dass es wahr zurückgibt, wenn connect() durchgelaufen ist, close() nicht aufgerufen wurde und der Tag nicht als außer Reichweite bekannt ist, ohne jede Funkaktivität: Es meldet, was die Plattform bereits weiß, und keine frische Prüfung.

Für einen Tag, der an seinem Platz bleibt, etwa einen in einer Halterung im Auto, ist NfcAdapter.ignore() ab API-Ebene 24 das Werkzeug. Es hält die Verbindung mit dem Tag an, solange er in Reichweite bleibt, und ruft einen OnTagRemovedListener auf, sobald der Tag debounceMs lang außer Reichweite war; ein Tag, der früher zurückkommt, wird nicht erneut zugestellt. Die Referenz nennt drei Grenzen: Der Controller sucht alle 100 bis 500 ms, sodass ein Tag, der in und aus der Reichweite gerät, erneut zugestellt werden kann, obwohl er nie wirklich weg war; ein anderer Tag bricht den Aufruf ab; und ein Tag mit zufälliger Kennung hebelt ihn aus.

Unter iOS

Jeder Tag, den Core NFC übergibt, erbt von NFCNDEFTag, dessen isAvailable falsch wird, wenn der Tag aus dem Feld entfernt oder getrennt wird, laut der Referenz zu isAvailable. Kein Aufruf des Delegats meldet es: Eine Anwendung, die es wissen muss, liest die Eigenschaft, oder erfährt es aus einem Befehl, der mit readerTransceiveErrorTagConnectionLost scheitert.

Eine Verbindung kann auch enden, während der Tag bleibt. Ein Tag bleibt verbunden, bis die Anwendung sich mit einem anderen verbindet oder die Suche neu startet, laut der Referenz zu connect, und Apples Hinweis zu restartPolling() sagt, dass vorher erkannte Tags ungültig sind.

Eine NDEF-Sitzung wartet selbst. Mit einem Delegat, das Nachrichten erhält, startet die Sitzung die Suche neu, sobald die erkannten Tags außer Reichweite sind, wie die Seite zu mehreren Tags erklärt, sodass ein an seinem Platz gehaltener Tag nicht zweimal hintereinander gelesen wird.

Warum es immer zu spät kommt

Das Entfernen wird aus dem Schweigen erschlossen. Ein Telefon erfährt, dass ein Tag weg ist, wenn eine Anwesenheitsprüfung oder ein Befehl keine Antwort bekommt, und die Referenz zu NfcAdapter setzt den Abstand der Suche des Controllers auf 100 bis 500 ms. Die Anwendung hört vom Entfernen, nachdem die Hand sich bewegt hat, nie in dem Augenblick, in dem sie es tut.

Entwerfen Sie die Oberfläche um diese Verzögerung herum. Ein Schreibvorgang, der als erledigt gemeldet wird, bevor sein Aufruf zurückkehrte, ist eine Vermutung: Zeigen Sie den Abschluss, wenn der Aufruf zurückkehrt, und behandeln Sie eine Ausnahme als unbekanntes Ergebnis, wie die Seite zu abgebrochenen Schreibvorgängen erklärt.

Hier beginnen die doppelten Lesevorgänge

Ein Tag, der geht und zurückkommt, ist eine neue Entdeckung. Unter Android kommt er als neues Objekt Tag an, da die Referenz zu Tag jedes Mal eines anlegt, wenn der Tag in Reichweite kommt; unter iOS erkennt die Sitzung ihn erneut, sobald er weg war. Die Seite zum doppelten Auslösen beschreibt, wie eine Hand das ungewollt erzeugt.

Eine Anwendung, die je Antippen einmal handeln muss, entscheidet daher selbst, was als Wiederholung zählt. Die Kennung mit der zuletzt gelesenen zu vergleichen, innerhalb eines von der Anwendung gewählten Zeitfensters, fängt den häufigen Fall, und ignore() tut unter Android dasselbe für einen Tag, der an seinem Platz bleibt. Keines von beiden arbeitet mit zufälligen Kennungen, wo die empfangende Seite Wiederholungen aushalten muss, der Schluss, zu dem die Seite zum doppelten Auslösen für Server kommt.