Mobile device applications have become a huge part of our lives. There are apps for almost any conceivable service. And we all have our favorites. Those apps that we use everyday and which we would now simply struggle to do without. Go on disable your favorite app. See how long you last :)

5 things to know about App to App communicationsby Ian Harris, Developer Evangelist, Golgi.

Underpinning all of this functionality is an intricate web of communications. Whether the communication is happening between an application and server to connect a service or between an application and application to provide an interaction--all apps must communicate. And that communication isn’t always easy to provide because of the uncertainties around mobile signal strength. A decreased connection in a remote or heavily crowded location can serve as the breakdown in this communication. But there are best practices that make the implementation of communication between devices a little easier. Let’s take a look at the (slightly) more complicated example of app to app communication. Here are the five things you need to know and the one thing that will tie them all together.

The IPv4 address space was conceptualised in a very diff erent time technologically. People often didn’t have a single IP connected device, never mind multiple. Today, this means that your mobile device will not have a globally reachable IP address. It will have a local IP address that is translated by a NAT* entity (or entities) within your network. So even if I knew the IP address of another device (or end-point) I wanted to connect to, well that connection ain’t gonna happen.

1. There simply aren’t enough addresses to go around

So my mobile device can’t connect to another end-point but something will have to? It sure will. A network entity known as a registrar would be required. A registrar is an entity that keeps a record of all registered end-points and the address that should be used to reach them. All end-points would register with the registrar. The registrar would then be able to route requests to the destination end-point and responses back to the originator.

2. Where are all those end-points?

Great the registrar knows where all the end-points are but I don’t. That’s where a discovery mechanism comes in. They may not be obvious, but all app to app communication systems have them. Traditionally, exchange of end-point addresses was done manually. “Can I have your number?” Modern mechanisms are usually more automated, however. A presence system can be built into your app. There are many models on which to base yours. WhatsApp and Viber use the phone numbers in your address book and discovery is automatic. Facebook use user names and discovery is via a “friend request.” Pick the model that best suits your application and its intended users.

3. Help users fi nd other users

4. Store and forward engine to power your communications

What happens if I try to send a message to someone who is offl ine? Allowing the sender to send a message only to have it disappear into the ether would defi nitely be a bad user experience. A delivery system that includes a store and forward functionality is the ideal solution to this problem. Such an entity is an intermediary that takes the message from the sender and agrees to deliver it to the destination. This allows the destination to be offl ine when the message is sent. When the destination comes back online the store and forward entity is notifi ed and message is delivered.

5. Push Notifi cations are your friend

Apple Push Notifi cations and Google Cloud Messaging push notifi cations are a highly effi cient mechanism for delivering content to mobile devices. Maintaining a persistent connection to the message delivery system is unfeasible. A user’s battery won’t last long in this scenario. Push notifi cations can be used to alert the app that there is a new message or messages to be delivered. Your application can then connect to the delivery node and retrieve the messages.

By now you’ve probably guessed what you will need to tie all of these requirements together. You’re going to need a server. A server that:

• Is globally routable • Can act as a central point where all end-points register• Can distribute end-point details for user discovery• Can store and forward messages• Can leverage APN and GCM push notifi cations

I know what you’re thinking. All of that seems like a lot of coding and really we are here to implement app to app communication not build a detailed server side infrastructure. The Golgi SDK can help solve most of these requirements instantly, with a solid platform that is already processing 1 Billion transactions ever day. The only exception being the discovery mechanism, which really is a personal choice for app developers. Features such as security and scalability are also met by the platform. Golgi kills the spinning wheel that causes so much frustration for users and often leads to apps being uninstalled. Golgi takes care of the critical aspects of app to app communications, leaving you to focus on your app features. Best of luck.

Register at www.golgi.io

*NAT stands for Network Address Translation. NAT is a mechanism for extending the IPv4 address space and hiding internal network topology. NAT is ubiquitous within IP networks.