How to Build a Website NFC Tag And Use Deep Linking With NFC

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, we will show you how to use NFC tags to trigger deep linking. First, how to set up iOS for deep linking. Then, how to handle the deep linking event in React Native. And how to set up Android for deep linking. Before we dive into the implementation, let's first briefly talk about what exactly deep linking is. According to Wikipedia, the definition for mobile deep linking is, using a uniform resource identifier, URI, that links to a specific location within a mobile app rather than simply launching the app. For example, the URI here should open the Facebook app and jump to a screen about the user profile with this specific ID. This example URI can be divided into two parts, the FB and everything else. The FB is used to define which app should be launched, which we also call a custom scheme in this course. The later part of the URI can be considered as parameter for the launched app. You might wonder how the steep linking stuff related to NFC. When a mobile device discovers NFC tags without your app running in the foreground, it will parse the end-depth and try to launch an app based on the content in the first end-depth record. So, if you save a custom deep linking URI in our NFC tags and register our app with this custom URI, we can launch our app and carry data into it by scanning the NFC tags directly. For example, if you are working on a restaurant app, you can use an NFC tag to trigger actions such as order, checkout, or edit feedback form, etc. Your users don't need to open the app and click any button. They can simply scan the NFC tags. In our lesson here, our deep linking URI will use the bundle ID as our custom scheme and carry a message text as a parameter. It looks like this. For me, that will be com.richishia.tap.go. Now, you should be able to modify your code to write this URI into NFC tags. But to save you some time, let's again use NFC tools to write our deep linking URI into NFC tags. [silence] Let's go to the linking page on ReNatives website. [silence] There is a section called "Enable in Deep Links" which mentions you need to add some code into your app delegate.m. Let's do it now. [silence] In your Xcode, find appdelegate.m. First, add the import statement to import the RCT linking manager. Then, copy the open URL delegation method from the website and paste it into your code. Please make sure you add this line below the "Add Implementation App Delegate" line. [silence] In Xcode, we still need to register our custom URL scheme for this project. First, copy our bundle ID and navigate to info.pilist. There is a section called URL types. Add the button. Click "Add" and paste our bundle ID into Identifier and URL schemes. That's it. After the setup, the native site can receive the linking event from iOS. But our JavaScript site doesn't do anything yet. Let's do it now. First, import linking from "Rear Native". Then, create a new use effect hook without any dependencies. In this hook, we define a function called "handle URL" that will be called when we receive a deep link. For now, we simply do console.worn. Then, we call linking.getInitialURL. This API returns a promise, which resolves to an initial URL launching our app. It might be no if our app is launched by the user clicking the app icon directly. Next, we call linking.addEventListener. This API is used to handle the URL event when our app is already launched. So, it is different from the previous GetInitialURL API. Finally, return a "ClickUp" function to remove all the listeners. It's time to test it. Let's create a dedicated screen to display the message from a deep link. This screen will receive routing parameters called "msg". And we simply show the MSG in the center of the screen. Then, hook up the deep linking screen in the app navigator like before. The last step is, of course, to actually navigate to deep linking screen when we receive a deep link. Go back to our home screen and in the handleURL function. Call navigation.navigate. Pause the MSG from the deep link and pass it as the second parameter. Let's test it again. It works. However, we noticed one thing. In this test, our app is launched by deep link. So, we are only testing the flow from the linking.getInitialURL function. So, we still need to verify the linking.getEvenListener function by keeping the app open and tapping the tag again. Awesome! It still works. Let's also check the linking.openURL can navigate to the correct screen. For Android, the setup process can be divided into two steps. The first step is to review your package name. The second is then add some intent filters into your androidmanifest.xml. The reason for the first step is because we want to use the same Android package name as the iOS bundle ID. As well as the deep linking custom scheme. There are several places to look into. So, let's check them one by one. The first is the Android app build.gradle. The next is the Androidmanifest. Then, you also need to make sure the folder structure for your Java code. This should be the same as your package name. It might seem a little strange, but it's required for the Java language. Also, for all files in the package, normally, menapplication.java and men activity.java. You also need to make sure that the top line declares the same package as its location. Technically speaking, the above steps aren't really related to a deep linking setup. If you choose to use the same package name created by COI, then you can basically skip those checks. But they will be useful to you when you need to change the Android package name some day. It's to add some intent filters into your Androidmanifest. The first one has action name, n-deaf-discovered. This intent is for NFC only. What's the Android system scan an n-deaf message? With TNF well-known and RTD your eye, it will fire an n-deaf-discovered intent, with the custom scheme as the data. The second one is for general purpose deep linking. For example, when an ATAC with H-ReF is clicked in a browser or in our cases, when we call linking.open URL in TechDeter screen. Now let's test it on a real Android device. Linking.getInitialURLWorks Linking.addEventListenerWorks Linking.openURL also works. Linking.openURLWorks