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

[00:00 - 00:13] Hello! In this lesson we will deep dive into n-depth.

[00:14 - 00:44] 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.

[00:45 - 00:55] Everything uses n-depth. From mobile operating systems, n-depth is fully implemented for both iOS and Android.

[00:56 - 01:12] 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.

[01:13 - 01:38] 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.

[01:39 - 01:50] 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.

[01:51 - 02:01] So in short, the n-depth record is the actual building block. Here is the structure of a n-depth record.

[02:02 - 02:12] In this diagram, one row represents 8 bits or 1 byte of data. A n-depth record has a fixed length header.

[02:13 - 02:24] Some people might call it FLAGS or TNF, but we call it HADDER for short. Enter the fixed length headers, comes variable length data.

[02:25 - 02:34] Conceptually, the data part of a n-depth record could be further divided into three kinds. Type, payload, and ID.

[02:35 - 02:45] The type and payload are pretty self-explanatory. As for the ID, it's used to let other n-depth records identify themselves.

[02:46 - 02:50] Hence, it is complex, but rarely used. We won't talk too much here.

[02:51 - 03:02] Let's observe the header part in more detail. The first bit is called MB, which refers to message begin.

[03:03 - 03:22] 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.

[03:23 - 03:41] 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.

[03:42 - 03:50] In practice, it's rarely used. The fourth bit is SR, which stands for short record.

[03:51 - 04:12] 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.

[04:13 - 04:26] 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.

[04:27 - 04:39] 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.

[04:40 - 05:00] 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.

[05:01 - 05:09] Here is the TNF mapping table. Among these values, the value O1 is most important.

[05:10 - 05:36] 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.

[05:37 - 05:50] 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.

[05:51 - 06:07] 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.

[06:08 - 06:17] Let's go back to our n-depth record structure. As we just discussed, the first byte is the header.

[06:18 - 06:28] And there is a short record bit in it. If the SR bit is 0, we use this original structure.

[06:29 - 06:43] 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.

[06:44 - 06:55] 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.

[06:56 - 07:09] 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.

[07:10 - 07:25] 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.

[07:26 - 07:35] First, check TNF. Since it is 1, we know that we should search RTD for the value-filled.

[07:36 - 07:46] Our type-filled is 85 in decimal or 55 in hex. So we know that the payload type is a RTD URI.

[07:47 - 08:01] 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.

[08:02 - 08:13] And the following byte is UTF-8-stream. So we are finally getting our HTTPS-renetive.dev back.

[08:14 - 08:31] 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.

[08:32 - 08:53] 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.

[08:54 - 09:17] 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 .

[09:18 - 09:22] In the next lesson, we will see all this in action. I will see you there.

[09:23 - 09:24] Bye. for now.

[09:25 - 09:29] in the next lecture. You You