5 Things to Consider About App-to-App Communications

The average American smartphone user has 33 apps and spends two and a half hours on his or her mobile device per day. A hefty 86 percent of this time is spent engaging with apps. We scroll through Facebook feeds, read news, play games, get directions, check to-do lists and bank accounts, browse Yelp and send Snapchats. These apps are ingrained into our everyday lives, and we can feel lost without them. 

Underpinning all this amazing functionality is an intricate web of communications. Regardless of whether the communication is between an application and a server to connect a service, or between applications to provide an interaction, all apps must communicate. However, enabling this communication isn’t always easy. Mobile signal strength varies from place to place, and remote or heavily crowded locations readily cause loss of connectivity. Your end-to-end system needs to plan for failure, not for the best case of a perfect network.

Some forces are beyond developer control, but there are a number of best practices that make implementing communication between devices a little easier.

Here are five things you need to know about app-to-app communication.

1. There aren’t enough addresses to go around

IPv4 routes the most traffic on the Internet. It was first deployed in 1983 in a very different time technologically, when most people didn’t have one IP-connected device, much less multiple devices. IPv4’s available pool was exhausted in 2011, which triggered concerns that Internet connectivity would be hampered for everyone and demand for IP addresses would skyrocket.

This turned out not to be the case, as major Internet players developed ways to stretch those available numbers. However, it does mean that your mobile device does not have a globally reachable IP address. It has a local IP address that is translated by a Network Address Translation (NAT) entity within your network. Network connections that you initiate from your phone work well (for example, when you are reading a webpage), but the protocol doesn't support inbound network requests initiated from outside the carrier network to your device. Most of the time, that limitation is good for you, but in the case of peer-to-peer apps, it is a definite obstacle.  

The best way to overcome this issue is to use a server that acts as an intermediary. The sender passes a message to the server, which can then forward it on to the destination. Use a free service when you’re in early stages--you don’t want your development budget being chewed up during initial testing.

2. Registries keep the endpoints organized

Your mobile device may not be able to connect to another Endpoint, but something has to. A registrar will help. Registrars are like telephone directories combined with exchange operators for the Internet. They keep a record of all registered endpoints and the address that should be used to reach them. All endpoints have to register with these entities, which can then route requests to the destination and responses back to the originator.

Tracking an IP address and port number, or maintaining a persistent connection, will not work. Generally, this approach supports rapid delivery of messages, but is otherwise impractical for mobile devices. Instead, you should store a user’s push notification details. This will allow rapid delivery in a more battery efficient manner. (See No. 5.)

3. It’s not as easy as “What’s your number?”

Registrars may know where endpoints are, but the rest of us don’t. Back in the day, “exchanging endpoints” was as simple as asking for a phone number. This process is much more complicated in the world of mobile apps.

Before we had smartphones with apps, there was only one way to uniquely reach another phone: the phone number. Today’s profusion of apps has provided a richer collection of identifying endpoints for networking. While WhatsApp and Viber still use the phone numbers in your address book to discover users or potential users, Facebook has defined usernames, and other apps integrate with Facebook for user Authentication.

If you do use an email address or phone number as your identifier, be sure to verify them. It would be very easy for a user to masquerade as someone else if he or she could just pick an email address or phone number. To verify an email address, send an email with a verification link to your Web Service. To verify a phone number, send an SMS with a one-time password that users enter into your application.

4. Offline matters, too

What happens if you’re trying to send data to a recipient who is offline? This data shouldn’t disappear into thin air. No one will be happy. Set up a server-based delivery system with a store-and-forward engine that takes the data from the sender and agrees to deliver it to the destination--even if the destination is initially unavailable.

The vital part of store-and-forward systems is the guarantee that no message is ever lost. So your server will need a database that reliably holds messages that have been sent but not yet delivered. This can usefully be combined with the registrar's database, if you support that feature.

There are a few things to consider here: the "no lost messages" guarantee; the contractual obligations of your message; and the cost of building hardware redundancies that reduce failures to an acceptably low level.

Once a message is securely stored, it can still be lost if your server experiences a hard disk failure. To protect against this failure, keep your database on RAID-protected storage media. If a single disk or Flash memory unit fails, your messages will not be lost. If you are using virtualized servers, keep in mind that they may be hosted on a single physical disk. Check with your hosting provider. It may even guarantee your data as a part of its service.

5. Push notifications are your friend

As mentioned above, a persistent connection from a mobile device to a message delivery system is not practical. It drains the battery and creates avoidable load on your server and data charges.

Push notifications are the best way to deliver content to mobile devices. Apple Push Notifications and Google Cloud Messaging can be used to alert the app that there are new messages on the server. The application can then connect to the delivery node to retrieve them.
Implement push notifications for all mobile platforms that you are supporting and track which Platform each of your customers uses. You'll need that data when designing the registrar.

Stop. It’s server time.

All of these steps take a lot of coding, which is time consuming. To tie it all together, you will need a server that is globally routable, can act as a central point at which all endpoints register, can distribute endpoint details for user discovery, can store and forward messages, and can leverage push notifications. Once that legwork is done, app-to-app communication will flow more freely.

Be sure to read the next Mobile article: iPhone NFC Limitations A Lost Opportunity For Apple Developers