The User Flow of an NFC Tag Reader and Writer App

Project Source Code

Get the project source code below, and follow along with the lesson material.

Download Project Source Code

To set up the project on your local machine, please follow the directions provided in the README.md file. If you run into any issues with running the project source code, then feel free to reach out to the author in the course's Discord channel.

This lesson preview is part of the The newline Guide to NFCs with React Native course and can be unlocked immediately with a \newline Pro subscription or a single-time purchase. Already have access to this course? Log in here.

This video is available to students only
Unlock This Course

Get unlimited access to The newline Guide to NFCs with React Native, plus 70+ \newline books, guides and courses with the \newline Pro subscription.

Thumbnail for the \newline course The newline Guide to NFCs with React Native

Hello, in this lesson, I will walk you through the NFC Pokemon app flow. Let's start from the admin side. On the home screen, the administrator user first presses the create Pokemon button. Then the administrator selects the Pokemon they want to create from the list. Our app will jump to the Pokemon detail screen, which displays the selected Pokemon info, and the user can press the create button to start the NFC operations. Let's take a closer look to see the core NFC operations. There are three major steps, password authentication, write Pokemon data, and write signature. Let's start with password authentication. This step is used to prevent a third-party application from tampering or overriding the content in our NFC text. This should protect only the write operation. We still need to allow our text to be read. The protection mechanism is a proprietary one, which can be found in most of the NXP and tag product lines. The second step is, of course, to write the Pokemon data into our NFC text. We first load the selected Pokemon's information, then perform NFC write operation. We will manipulate the NFC text internal memory directly, without using a higher level and depth operation. Unlike the previous password protection commands, the commands to read or write NFC text internal memory are not proprietary. They are defined by the NFC forum type 2 tag platform specification. They are well known and public and can be used in all type 2 tags. Recall the tag type definitions in the NFC specification overview diagram. So the idea is that every tag type can support and depth. When you are working on the and depth level, you don't actually care what the underlying NFC tag type is. But on the other hand, when you are working on the tag level, like we are in this app, you must know which tag type you are dealing with, because each tag type has its own command set and communication protocols. In this lesson in our NFC library, we often refer type 2 tags as NFC-A tags. Strictly speaking, there are differences between them. So the correct wording should be "Use NFC-A technology to send a type 2 command ". If it confuses you, don't worry, because in practice, you don't need to care about those details as a mobile app developer. The final block for our admin flow is to create digital signatures for our NFC Pokemon tags. As mentioned before, we only allow administrators to override an existing Pokemon tag, but we should provide a way to let normal users verify it. To create this digital signature, we need two inputs. The first one is our Pokemon data. The second one is a unique hardware identifier. It is different for every single NFC tag and cannot be changed after manufacturing. It is called UID. With UID as input, our NFC Pokemon tags won't be easily faked, because when people simply copy the whole tag content into another one, the signature won't match, since the UID is different. Let's move on to the normal user flow. This flow is much easier than the admin one. We don't need password auth, because the read operation is allowed for everyone . So we simply read the tag content and verify the digital signature to see if it was indeed issued by us. Now we have a basic idea of the ad flow. Let's take a look at the code structure. The admin flow is implemented in the Pokemon detail screen. Let's see the unpress handler for the create button. As you can see, I have carefully separated the core NFC functionalities into individual functions to make them easier to understand. The normal user flow is no different. Let's check the home screen and see the unpress handler for the identity button . Again, the core NFC functionalities are properly named and have been separated into individual functions. Actually, every function above is even separated into its own file and they are all in the SRC NFC UTOs directory. At this point, they are either empty or simply return a fake value. Our goal in the following lessons is to implement them one by one. So at the end of this module, we will have a working Pokemon tag maker app. . . . [BLANK_AUDIO]