Wie viel Tag-Speicher verbraucht der NDEF-Overhead?
Genug, um auf einem kleinen Tag zu zählen, und zu wenig, um auf einem großen zu beunruhigen. Speicher verbrauchen die Struktur des Tags, der NDEF-Behälter und ein Kopf auf jedem Datensatz, alles abgezogen, bevor Ihr Inhalt beginnt.
Drei Abzüge, der Reihe nach
Erstens behält der Tag Speicher für sich: die Kennung, Herstellerdaten, Sperrbits und den Capability Container, der den Lesegeräten den Aufbau beschreibt. Nichts davon steht Ihnen zur Verfügung, und nichts davon ist wahlfrei.
Zweitens legt der NDEF-Behälter seinen eigenen Rahmen dazu, damit ein Lesegerät weiß, wo die Nachricht beginnt und wie lang sie ist.
Drittens trägt jeder Datensatz in der Nachricht einen Kopf vor seiner Nutzlast.
Was Ihren Inhalt erreicht, ist die angegebene Kapazität abzüglich aller drei, weshalb ein Tag mit ausgewiesener Kapazität in einem Werkzeug merklich weniger freien Platz meldet.
Jeder Datensatz kostet erneut
Der Kopf fällt je Datensatz an und nicht je Nachricht. Denselben Inhalt auf drei Datensätze zu verteilen kostet daher drei Köpfe statt einem, und der Unterschied wiegt gegenüber einem kleinen Tag schwer.
Das ist einer der praktischen Gründe, einen einzigen Datensatz vorzuziehen. Der andere ist die Lesezeit, denn diese Köpfe sind zusätzliche Bytes, blockweise zu lesen, auf einem Kanal, auf dem immer nur eine Seite sprechen darf.
Wann es aufhört zu zählen
Schnell, sobald die Kapazität wächst. Auf einem Tag mit Platz für ein paar hundert Byte Inhalt ist ein Kopf von wenigen Byte Rauschen. Auf den kleinsten gängigen Tags, wo Sie eine URL in einen sehr engen Raum bringen, kann derselbe Kopf der Unterschied zwischen einem gelungenen und einem gescheiterten Schreibvorgang sein.
Daraus folgt, dass der Overhead eigens ein Problem kleiner Tags ist. Kämpft ein Rollout um Bytes, lautet die Antwort meist größerer Tag und nicht raffiniertere Codierung.
Mit Spielraum arbeiten
Lesen Sie den freien Platz mit einem Werkzeug aus, statt ihn aus der Verpackung zu berechnen. Werkzeuge melden, was wirklich zur Verfügung steht, und diese Zahl ist die einzige, gegen die zu planen sich lohnt.
Lassen Sie dann Raum. Inhalt wächst: Eine URL bekommt einen Messparameter, ein Name einen zweiten Vornamen, eine Kampagne eine zweite Sprache. Einen Tag zu bestellen, in den Ihr heutiger Inhalt genau hineinpasst, heißt einen Tag zu bestellen, der ersetzt werden muss.
Und denken Sie daran, dass sich eine URL auf dem Server kürzen lässt statt auf dem Tag. Von einer langen Adresse auf eine kurze zu gehen ist der billigste Kapazitätsgewinn, den es gibt, und er kostet je Tag nichts.
Häufige Fragen
Warum meldet mein Tag weniger freien Platz als angegeben?
Weil Struktur, Behälter und Datensatzköpfe alle zuerst abgezogen werden. Die Lücke ist normal und zu erwarten, und Tags vergleicht man über den freien Platz statt über die angegebene Kapazität.
Hilft eine kürzere URL wirklich?
Auf einem kleinen Tag ja, und merklich. Jedes Zeichen der Adresse ist ein Byte Nutzlast, und die Adresse zu kürzen genügt oft, damit ein Schreibvorgang gelingt, der scheiterte.
Ist der Overhead auf jedem Tag-Typ gleich?
Nein, denn die Struktur fällt zwischen Tag-Typen und Chipfamilien verschieden aus. Zwei Tags mit gleicher angegebener Kapazität können verschieden viel nutzbaren Platz bieten.
Kann ich NDEF meiden, um den Overhead zu sparen?
Technisch ja, und es kostet Sie die Zusammenarbeitsfähigkeit. Inhalt außerhalb von NDEF ist nur von Software lesbar, die den Aufbau kennt, was den Sinn für alles zunichte macht, was ein fremdes Telefon liest.