Writing NFC Tags in an Android Business App: Verify the New Message Before Locking the Tag

If staff need to prepare NFC tags for equipment or jobs, commission a writing workflow, not just a tag reader with an extra button. Agree what existing message may be overwritten, whether the new message fits, how the app verifies what is now on the tag, and whether anyone is allowed to make it permanently read-only.

This is about preparing supported NDEF tags using an Android app. It is not about choosing which app opens when a customer taps a tag, and it does not make a tag an identity credential or a tamper-proof business record.

Treat preparation as a separate staff task

Start with the intended record and a preview of the exact message the app proposes to write. My recommendation is that the staff member deliberately selects the equipment or job before bringing the tag into the writing flow. A general tag-detection event should not quietly overwrite whatever happens to be nearby.

Decide who can perform this operation and how the screen makes the target record recognisable. Use tags and records owned by the business for acceptance testing. Existing labels from other organisations are not suitable practice targets.

The Android Ndef API reference describes writeNdefMessage as overwriting the NDEF message on a tag. That is the important commissioning distinction: writing is not simply adding a harmless note beside the existing message. If the business wants to preserve or combine existing content, specify that handling explicitly and have the developer assess it for the supported message types.

Check the tag's state and actual message capacity

The same reference provides isWritable to determine whether the tag is writable and getMaxSize to obtain its maximum NDEF message size in bytes. These are separate questions. A tag may be writable yet too small for the proposed message.

Ask the developer to check the encoded message size against the supported tag's capacity rather than comparing only the visible text length. This is a practical implementation requirement: the API's capacity is expressed in message bytes, not a customer-facing character allowance.

Define clear outcomes for unsupported tags, read-only tags and messages that do not fit. None should produce a generic “Tag prepared” confirmation. If your project also needs to format tags that do not yet support NDEF, scope that separately; this article does not promise that the Ndef writing operation formats arbitrary blank hardware.

Verify using a current read, not discovery-time data

The reference distinguishes two ways to obtain a message. getCachedNdefMessage returns what was read when the tag was discovered, and its documentation says that later I/O modifications do not update that cached result. getNdefMessage reads the current message stored on the tag.

That distinction matters in a writing station. A screen showing the discovery-time message after a write is not a verification of the new content.

My recommended acceptance rule is to read the current message after writing and compare it with the approved intended message before reporting verified completion. Agree what counts as an equivalent result for the message format you support. The reference supplies the read and write operations; the comparison and the user-facing completion policy are requirements for your app, not an automatic guarantee supplied by the API.

Also distinguish tag verification from updating the business database. If the project records a tag-to-equipment assignment on a server, define how that record is reconciled with the physical write. Neither operation alone demonstrates that both have completed.

An interrupted write needs an unresolved state

Android documents tag-loss and I/O exceptions for writing, and describes the operation as blocking work that must not run on the main application thread. Ask for an interface that remains responsive while the operation is in progress and explains when the tag needs to stay in place.

If the tag moves away or an I/O operation fails, recommend showing an unresolved outcome rather than assuming either that the old message survived or that the new one was saved. When the tag is available again, inspect its current contents before deciding whether to retry or accept it.

For a batch of tags, retain which intended assignment is unresolved. Do not advance the screen to the next equipment record while the previous physical tag still has an uncertain result. This is workflow guidance, not a claim that every error leaves the tag in a particular state.

Permanent read-only is a separate decision

The API reference describes makeReadOnly as setting the tag's read-only indication and, where possible, permanently setting lock bits. It explicitly calls this a one-way process that cannot be reverted. The method can return false when making the tag read-only is not possible and can also fail with documented exceptions.

Do not hide that operation inside an ordinary Save button. My recommendation is a separately authorised step, a plain warning about irreversibility, and verification of the intended message before the locking attempt. Agree how the app reports an unsuccessful or uncertain locking result.

Read-only status is not evidence of who wrote the message, who owns the equipment or whether the tag has been copied. This workflow does not certify authenticity. If authenticity is a business requirement, it needs its own security design rather than stronger wording beside the lock button.

Demonstrate the physical workflow before acceptance

Use supported test hardware and synthetic records in the project's acceptance criteria:

• An existing message is detected and handled according to the agreed overwrite policy.
• A read-only tag and a too-small tag produce distinct, truthful refusals.
• A successful write is checked using a current read rather than the cached discovery message.
• Moving the tag away mid-operation creates an unresolved task that can be inspected and reconciled.
• A separate business-record assignment does not claim completion solely because the physical write returned.
• Making a test tag read-only requires the agreed deliberate action and reports the actual result.

Only use expendable test tags for irreversible locking checks. These are proposed tests, not a claim that hardware has been exercised for this article.

Bring the tag type, intended message and replacement process to an Android app project discussion. The deliverable is a recoverable preparation workflow with honest evidence of its outcome, not merely a successful tap or a reassuring animation.