Wireless connectivity is basically a requirement for any mobile device in this day and age. Wireless technology allows phones, tablets, and other devices to access the cloud, the internet, emails, and net-enabled apps like the ones for Facebook and other social media without the wired connections that are still common for desktops and even laptops sometimes.
Mobile technology, however, has taken Wi-Fi enabled devices a step further. Now more and more mobile devices, particularly Android ones, are able to use Wi-Fi to connect to other mobile devices through a direct peer-to-peer wireless interface. This addition to Android devices, called the Network Service Discovery (NSD) allows unparalleled connectivity to other mobile devices. It gives users access to a wide variety of features such as playing games with people who are in the same room (even if they’re not on the same network), accessing remote-enabled hardware such as webcams or microphones, or remotely logging into machines on the same network.
This article is an overview of the two key APIs that factor into peer-to-peer connections for Android devices. The first is the NSD API for discovering available connections and the second is the Wi-Fi peer to peer (P2P) API that actually runs peer to peer connections. The final section of this article talks about how to use the two of them together to connect to a device that isn’t on the same network as the one you’re using.
Network Discovery Service
The Network Discovery Service, much as its name suggests, is an API that lets users identify other wireless devices on a local network. Adding it to an app means that users with the same app can interface through the network, as long as a function like that is coded into the app. This allows for a variety of features, such as multiplayer games, sharing information, and so forth.
The basic use of this API is to discover services on the network, which means identifying and then listing all available interactions; whether it’s a wireless printer, a webcam, or a game of tic-tac-toe. Your app will listen to all the service broadcasts on the network and then interpret them into a format that can actually interact with what the app itself does. You can also register your app to the network, which essentially means that you’ll be listed when other people try to discover services on the network.
Once you’ve identified services on the network, the next step is connecting to them, which your app will need to be configured to do. If you have app configured to register itself on a network, you’ll also have to set it up to unregister when you disconnect from the network. This is a relatively simple task that can be set up to happen automatically.
The Wi-Fi peer to peer API is what lets apps connect to devices within wireless range without going through a network. This is a direct peer to peer connection that uses the signal strength of each device to connect to one another without a network hotspot or registering to a wireless network.
The first step is to set up the app’s permissions, which determine what information the app is allowed to share with other wireless devices and what kind of devices that the app can connect to. You’ll also have to set up a broadcast receiver and peer to peer manager, which offer higher-level control over displaying and categorizing broadcasts. This allows you to fine-tune your features in order to use a custom UI and interface that works for your app.
Next, you’ll use the Wi-Fi peer to peer call discoverPeers() which searches for other devices’ signals rather than a network like the NDS does. Once this task has resolved, it lists them in a directory of peers that you can connect to, configured by your earlier peer manager in order to list whatever types of peers you want that can interact with your app in ways that you need. Once that’s done, the connection process has to be set up, which resolves the task of directly connecting to another wireless device under the parameters set up by the earlier legwork.
The two APIs that we’ve already discussed basically offer parallel usages – one connects you to a network, and the other connects you directly to peers. However, it’s possible to use the two features in tandem to connect to services only available over a network, even when there’s no wireless hotspot.
It’s important to note that the code for these usages is quite different than the previous APIs, and that brushing up on it before trying to implement anything is an important background task. Generally, the process for setting up this kind of use starts with creating a manifest. This is a list of requested permissions that are outlined before the app connects to anything, similar to how peer to peer connections are managed through the peer manager.
Next, you add a local service. This is set up in the same way that a service on a network is, just that all the information is stored locally on the device rather than on the network, meaning it can be accessed outside the presence of an available internet connection. After that, you use a similar tool to the NDS to search for services or register your own. Again, this is done locally so all the information is present when it needs to be. Finally, you connect in a way that’s similar to connecting peer to peer, except that you scan for services as though you are connecting to a network.
Use these 3 API’s to enhance your app’s connectivity.