Warum läuft ein Befehl ab, und wie lange soll Code warten?
Android lässt Code eine Wartezeit je Technologieklasse setzen und stellt sie zurück, wenn die Verbindung schließt; die Voreinstellung ist nicht dokumentiert, lesen Sie sie also, statt sie anzunehmen. iOS stellt überhaupt keine Wartezeit bereit. In beiden Fällen ist die Antwort auf einen Ablauf meist weniger Befehle und kein längeres Warten.
Was Android bereitstellt
setTimeout() an NfcA oder IsoDep setzt, wie lange transceive() wartet. Zwei Einzelheiten der Referenz entscheiden, wie es benutzt wird: Der Wert geht auf seine Voreinstellung zurück, wenn die Verbindung schließt, er wird also nach jedem connect() erneut gesetzt, und die Voreinstellung selbst ist nicht dokumentiert, getTimeout() ist also der einzige ehrliche Weg, sie zu kennen.
Ein längerer Wert ist für Vorgänge, die den Tag Zeit kosten, die Erzeugung eines Schlüssels ist das Beispiel der Referenz selbst. Er lässt keinen Tag antworten, der es nie täte, und er hilft keinem Tag, der weg ist, was stattdessen TagLostException auslöst, das Thema der Seite zum verlorenen Tag.
Der Lesemodus fügt eine zweite Uhr hinzu: die Wartezeit, mit der die Plattform prüft, ob ein erkannter Tag noch da ist, gesetzt über den Zusatz der Anwesenheitsprüfung, was die Seite zum Abgang behandelt.
Was iOS nicht tut
Core NFC hat keine Wartezeit zum Setzen. Die Anwendung sendet einen Befehl und wartet, und das Rahmenwerk meldet readerTransceiveErrorRetryExceeded, wenn zu viele Wiederholungen geschehen sind, oder einen Fehler über die verlorene Verbindung, wenn der Tag weg ist.
Die Sitzung hat ihre eigene Grenze, eine Ungültigkeit ohne dokumentierte Dauer, die die Seite zur Ungültigkeit aufnimmt. Unter iOS ist der einzige Hebel also, wie viel die Anwendung verlangt und wie schnell sie antwortet: Bei der Kartenemulation warnt Apple, dass ein Lesegerät eine langsame Antwort als Ablauf lesen kann.
Was ein Weg hin und zurück kostet
Jeder Befehl ist ein Weg hin und zurück, und das Budget für ein Antippen ist klein. Androids Leitfaden zur Kartenemulation setzt eine vernünftige Obergrenze bei etwa 1 KB an Daten, ausgetauscht in etwa 300 ms, was der deutlichste veröffentlichte Maßstab dafür ist, was hineinpasst, während eine Hand still hält.
Lesen Sie also in den Blöcken, die das Protokoll Ihnen gibt. Ein READ bei Type 2 liefert vier Seiten auf einmal, sechzehn Bytes für einen Befehl, wie die Seite zu Type 2 beschreibt; ein Lesevorgang bei Type 4 ist durch das Höchstmaß des Containers gedeckelt, und weniger als dieses Höchstmaß zu verlangen kostet Befehle, die nichts einbringen.
Innerhalb des Fensters entwerfen
Erledigen Sie die Arbeit vor dem Antippen. Holen Sie, was der Austausch braucht, bauen Sie die Rahmen, öffnen Sie die Verbindung über das Netz, und behalten Sie die Zeit des Tags für den Tag: Eine Anwendung, die einen Server aufruft, während sie einen Tag hält, hat ein Netz auf den kritischen Weg einer Handbewegung gelegt.
Behandeln Sie einen Ablauf dann als ungewiss statt als gescheitert, besonders nach einem Schreibvorgang, und lesen Sie den Tag zurück, bevor Sie irgendetwas entscheiden. Ein zweiter Versuch, der annimmt, dass der vorige Befehl nichts getan hat, ist die Art, wie ein Zähler zweimal hochgezählt wird.
Häufige Fragen
Was ist die voreingestellte Wartezeit unter Android?
Nicht dokumentiert. Lesen Sie sie mit getTimeout an der Technologieklasse, die Sie geöffnet haben, und setzen Sie Ihren eigenen Wert nach jedem connect erneut.
Kann ich unter iOS eine Wartezeit setzen?
Nein. Core NFC stellt keine bereit. Es meldet zu viele Wiederholungen oder eine verlorene Verbindung, und die Sitzung hat ihre eigene undokumentierte Grenze.
Wie viel lässt sich in einem Antippen austauschen?
Androids Leitfaden zur Kartenemulation nennt etwa 1 KB in rund 300 ms als vernünftige Grenze, was auch zum Lesen ein nützlicher Maßstab ist.
Ist ein Ablauf dasselbe wie eine Weigerung?
Nein. Eine Weigerung kommt als Statuswort oder als Fehler-Bit vom Tag zurück. Ein Ablauf heißt, dass nichts zurückkam, das Ergebnis ist also ungewiss.