Wie schreibt und sperrt man einen NDEF-Tag aus einer iOS-Anwendung?
Öffnen Sie eine NDEF-Sitzung, die nach dem ersten Lesen nicht endet, verbinden Sie sich mit dem Tag, den das Delegat erhält, und fragen Sie Zustand und Kapazität ab, bevor Sie die ganze Nachricht in einem Aufruf schreiben. writeLock macht den Tag dauerhaft nur lesbar. Alles geschieht in einer Sitzung, also hält die Hand das Telefon still, bis die Anwendung fertig meldet.
Eine Sitzung, die offen bleibt
Das Schreiben geschieht innerhalb einer Lesesitzung, die Sitzung darf also nicht beim ersten Lesen enden. Apples Hinweis zum Initialisierer verlangt falsch für invalidateAfterFirstRead in einer Sitzung, die schreibt, was sie aktiv hält, bis die Anwendung fertig ist.
Das Delegat setzt readerSession(_:didDetect:) um, verfügbar ab iOS 13, um Objekte vom Typ NFCNDEFTag statt Nachrichten zu erhalten, und ruft dann connect(to:) für den gewünschten auf. Ein Tag bleibt verbunden, bis die Anwendung sich mit einem anderen verbindet oder die Suche neu startet.
Zwei Tags im Feld sind ein wirklicher Fall. Apples Beispiel eines Tag-Lesegeräts zählt die Tags vor dem Schreiben, bittet über alertMessage darum, alle wegzunehmen, und startet die Suche nach einer kurzen Wartezeit neu, statt den falschen zu beschreiben.
Zuerst Zustand und Kapazität
queryNDEFStatus gibt zwei Werte zurück, die entscheiden, ob es weitergeht: einen Zustand, notSupported, readOnly oder readWrite, und die Kapazität, die größte NDEF-Nachricht, die der Tag ablegen kann, in Byte.
Vergleichen Sie die Kapazität vor dem Schreiben mit der Nachricht. Eine Nachricht, die nicht hineinpasst, scheitert mit ndefReaderSessionErrorTagSizeTooSmall, nachdem die Hand das Telefon umsonst still gehalten hat.
Der Schreibvorgang
writeNDEF(_:) legt die ganze Nachricht in einem Aufruf ab und meldet an seinen Rückruf, oder wirft in seiner asynchronen Form. Seine Referenz bindet ihn an den Zustand: nur schreiben, wenn queryNDEFStatus readWrite zurückgegeben hat.
Die Fehler sagen, welcher Schritt misslungen ist: ndefReaderSessionErrorTagNotWritable für einen nur lesbaren Tag, ndefReaderSessionErrorTagSizeTooSmall für eine zu lange Nachricht, ndefReaderSessionErrorTagUpdateFailure für eine Aktualisierung, die nicht durchlief, und readerTransceiveErrorTagConnectionLost, wenn der Tag das Feld verlassen hat.
Lesen Sie den Tag nach einer misslungenen Aktualisierung oder einer verlorenen Verbindung erneut, bevor Sie es noch einmal versuchen. Das Schreiben kann auf halbem Weg stehengeblieben sein, der Fall, den die Seite zum Abbruch auf halbem Weg von der Seite der Nutzenden behandelt.
Sagen Sie es im Fenster, wenn das Schreiben gelingt, und beenden Sie die Sitzung mit invalidate(). Bis dahin weiß niemand, dass das Telefon bewegt werden darf.
Das Sperren ist dauerhaft
writeLock() ändert den Zustand des Tags auf nur lesbar. Seine Dokumentation erklärt, dass er das Byte der Schreibzugangsbedingung in der NDEF-Dateisteuerung des Tags aktualisiert, und nennt ihn eine dauerhafte Handlung, die sich nicht rückgängig machen lässt.
Halten Sie ihn vom Schreiben getrennt und führen Sie ihn aus, sobald der Inhalt zurückgelesen und auf der anderen Plattform geprüft ist. Ob überhaupt zu sperren ist, behandelt die Seite zum Sperren.
Was die NDEF-Aufrufe nicht können
Die NDEF-Aufrufe hören bei der Nachricht auf. Ein Passwort, ein Zähler oder eine Konfigurationsseite sind Befehle an den Chip, erreichbar über eine Tag-Sitzung und das eigene Protokoll des Tags, etwa sendMiFareCommand auf einem MIFARE-Tag, mit den Befehlen aus dem Datenblatt des Chips.
Diese Arbeit verlässt die NDEF-Sitzung vollständig, weshalb die Wahl der Sitzung zuerst kommt, auf der Seite zu den Sitzungen.
Häufige Fragen
Warum scheitert mein Schreibvorgang mit ndefReaderSessionErrorTagSizeTooSmall?
Die Nachricht ist größer, als der Tag ablegen kann. queryNDEFStatus gibt die Kapazität in Byte zurück, vergleichen Sie also beides vor dem Schreiben.
Lässt sich ein gesperrter Tag unter iOS entsperren?
Nein. Apple beschreibt writeLock als eine dauerhafte Handlung, die sich nicht rückgängig machen lässt.
Kann eine iPhone-Anwendung ein Passwort auf einem Tag setzen?
Nicht mit den NDEF-Aufrufen. Ein Passwort wird mit Befehlen an den Chip gesetzt, in einer Tag-Sitzung über das Protokoll des Tags, mit den Befehlen aus dem Datenblatt des Chips.
Warum muss die Sitzung nach dem Lesen offen bleiben?
Das Schreiben geschieht in ihr. Steht invalidateAfterFirstRead auf wahr, endet die Sitzung nach dem ersten Lesen und lässt nichts übrig, womit geschrieben werden könnte.