A Deep Dive Into NDEF and NdefRecord to Share Data via NFC

Hello! In this lesson we will deep dive into n-depth. n-depth stands for NFC Data Exchange Format. As the name implies, it is used as the standard way for n-c-enabled devices to exchange data with each other, especially NFC readers and NFC tags. Recall from the NFC specification over view diagram, no matter which operation mode or tag types. Everything uses n-depth. From mobile operating systems, n-depth is fully implemented for both iOS and Android. When talking about n-depth, there is a common confusion between two terms, n- depth message and n-depth record. n-depth message can be considered a container for n-depth records. From a software developer's perspective, n-depth message is an array of n-depth records. However, unlike most media containers such as MP4, which has its own format to decouple from the actual data it contains, n-depth message is more like a logical concept. n-depth record itself decides how to group several n-depth records together to form one n-depth message. We will see this idea in practice soon. So in short, the n-depth record is the actual building block. Here is the structure of a n-depth record. In this diagram, one row represents 8 bits or 1 byte of data. A n-depth record has a fixed length header. Some people might call it FLAGS or TNF, but we call it HADDER for short. Enter the fixed length headers, comes variable length data. Conceptually, the data part of a n-depth record could be further divided into three kinds. Type, payload, and ID. The type and payload are pretty self-explanatory. As for the ID, it's used to let other n-depth records identify themselves. Hence, it is complex, but rarely used. We won't talk too much here. Let's observe the header part in more detail. The first bit is called MB, which refers to message begin. This means this n-depth record is the first record for a new n-depth message. The second bit, called ME, which stands for message end, means that this is the less record of the current n-depth message. So we can build n-depth message by examining multiple n-depth records sequ entially. The third bit is CF or chunk flag, which is used to group multiple payloads into one, across multiple n-depth records. In practice, it's rarely used. The fourth bit is SR, which stands for short record. This means the actual payload in the n-depth record is less than 256, so we can use a single byte to represent the payload length to further reduce the total record size. On the other hand, a normal n-depth record uses 32-bit or 4 bytes for the payload length. The fifth bit is IL, which tells whether this n-depth record has ID or not. Again, ID is mainly used to let other n-depth records identify themselves. We won't talk too much about it, since it is rarely used. The final three bits are grouped together and called TNF, which stands for type n-field. It is an important one, essentially the category for the n-depth records payload type. So to correctly identify the actual payload type for n-depth record, we should see both the TNF-filled and type-filled. Here is the TNF mapping table. Among these values, the value O1 is most important. We often call it well-known TNF. When we encounter this well-known TNF, it indicates that the type-filled contains a value that follows the NSC4-in record type definition specification, or RTD in short, which defines a lot of commonly used payload types, such as text or UI. Let's do a quick recap. In order to know which type of payload is in the n-depth record, we have to first check the TNF-filled, then check the type-filled. And once we see the TNF is 1, which means it is a well-known TNF. We know that we should look up the type-filled with another mapping table called RTD. Let's go back to our n-depth record structure. As we just discussed, the first byte is the header. And there is a short record bit in it. If the SR bit is 0, we use this original structure. On the other hand, if the SR bit is 1, we will use this alternative layout. The major differences between these two layouts is the payload length. In the short record layout, we only use one byte to encode payload length, no matter which layout we are using. They will both have type and payload. The type tells us what kind of data is carried by our payload. Again, in order to decode the type, we need to first cancel the TNF-filled in the header. As we mentioned before, once we know exactly what type of data contained in our payload, we can process it accordingly. Let's take our HTTPS-renetive.dev as an example. First, check TNF. Since it is 1, we know that we should search RTD for the value-filled. Our type-filled is 85 in decimal or 55 in hex. So we know that the payload type is a RTD URI. The next step is to decode the payload according to the RTD URI specification. Our first byte in the payload is 4, which maps to HTTPS. And the following byte is UTF-8-stream. So we are finally getting our HTTPS-renetive.dev back. Since we don't expect to decode or encode N-deaf manually, let's see what our N SE library offers us. As mentioned before, our NSE library contains a useful N-deaf module to help you deal with N-deaf. For encoding, you can use it to create a common N-deaf record by calling an individual N-deaf record factory method. It also provides an encode message function to let you group multiple N-deaf records into one N-deaf message. For decoding, we expose all TNF values for you, as well as the most commonly used RTD values. Once you confirm what type of payload is actually inside your N-deaf record, you can call the corresponding payload type.deco payload function to decode the payload . In the next lesson, we will see all this in action. I will see you there. Bye. for now. in the next lecture. You You