Creating an offline messaging app with the Bridgefy SDK

Is it really that easy to use the Bridgefy SDK? After working for almost two years on this project I could say “yes”, but we need to show it, and what better way to do it than implementing it on an app.

After much thought, we decided that an instant messaging app would be best, given that Bridgefy was originally a messaging app.

The main idea is to create an instant messaging app that allows communication between devices that are close to each other.

The app will consist of 2 screens:

1. ChatList: which will be a list of the devices that are or have been available nearby, and the second
2. ChatView: is where messages will be sent from, which may be direct or broadcast messages.

After generating the project in Xcode, it’s necessary to add the Bridgefy SDK. The steps for doing so can be reviewed at: https://github.com/bridgefy/bridgefy-ios-developer.

On this same page, you can download the code for this and other sample applications that use the Bridgefy SDK.

The next step is to generate the storyboard screens that will look like this:

Bridgefy Messaging App Storyboard

The first class in which we’re going to work is ChatListController that has to be created as a subclass of UITableViewController, in this class is where we’ll implement all the delegate methods of the SDK. For this we have to import the SDK as follows:

Importing the Bridgefy SDK.

The next step is to declare that our class will implement BFTransmitter’s delegated methods.

ChatListController interface.

In the last snippet there are all the variables and properties that we’re going to use, where:

• transmitter: Instance of BFTransmitter.
• peerNamesDictionary: Dictionary with the peers with which we have previously been connected, each peer is represented as another dictionary.

Peer dictionary structure.

• onlinePeers: Array with the UUID of the peers that are in range.
• offlinePeers: Array with UUIDs of peers that aren’t in range.
• chatController: ChatViewController instance that handles the chat view.

The next step is to initialize the transmitter:

BFTransmitter initialization.

We define the log type that we want to get from the transmitter, then we initialize the transmitter with the key that we obtained when registering our application on Bridgefy’s site. After that, we indicate to the transmitter that this class will be the one in charge of implementing the delegates. Next, we’ll activate background mode and finally call the start method for the transmitter to start working.

When the transmitter detects a connection with any device, it’ll let us know with the following delegate:

Delegate method to inform that a connection was detected.

When we’re notified of a new connection through this delegate, there’s no certainty that it’s a secure connection. This can only happen if a secure connection had already been made previously and the key hasn’t expired. For this example, we want all connections established between devices to be safe, so we have to implement the following BFTransmitterDelegate method:

Delegate method to ask if a connection should be established securely.

Now when a secure connection with a peer has been created, we’ll be notified by the next delegate:

Delegate method to inform when a secure connection has been established.

In this method, the first thing we do is call the processNameForUser: method, which will determine if the peer already exists on our list of peers. In case it doesn’t, it’ll create the record and save it by generating a name from the first 5 characters of its UUID and assign an unknown device type to it. In addition, within this method, a dictionary is sent to the peer with which the connection was just generated, indicating the name and type of device to be displayed in its list of peers.

The rest of the code will move the peer to the list of peers in range and update the table that shows them.

Since we have implemented the code to handle a connection, we must take care of the disconnections. For this we use the following delegate:

Delegate method to inform when a disconnection has occurred.

What we do in this delegate is move the peer from the in range peer list to the disconnected peers list and then update the table.

With this, the handling of peers is complete. Now we’re going to focus on the sending and receiving of messages. The Message class contains all the information that is saved for each message.

Message class interface.

Sending messages is done from the ChatViewController class, which is also a subclass of UITableViewController. For practical reasons, we’re only going to talk about sending messages, since the rest of the code is only used to display messages sent and received on the table.

ChatViewController has the following protocol:

Through this delegate we’ll request ChatListController to send a message, for this we have to indicate that ChatListController will implement the delegates of this protocol as follows:

To declare ChatListController as a delegate of ChatViewController we’re going to do it in the following method:

The rest of the code is used to transfer parameters from ChatListController to ChatViewController depending on whether we’re opening a conversation with a peer or a broadcast conversation.

Within ChatViewController, the method that is responsible for sending the message is:

Implementation of sendText: method.

First, the message object is created. The corresponding properties are filled and, depending on the type of conversation, the sending of the message is done through the delegated method.

Going to ChatListController, we have the implementation of the delegated method for sending messages as follows:

Implementation of sendMessage:toConversation method.

With the properties of the message object, the dictionary to be sent through the transmitter is created. When it’s about a broadcast message, the name and type of device from which the message is sent is added to the dictionary, because it’s likely that those who receive the message haven’t had a previous connection with the sending device and therefore need this information to display the message correctly.

Sending the message through the transmitter is done with the following line of code:

• dictionary: Message that is sent.
• user: ID of the device to which the message is addressed; for the broadcast case, this ID is null because the message will be able to be seen by all nearby devices.
• options: Indicates how we want the message to be sent. For direct messages, we want it to be sent encrypted and both direct and through mesh. In the case of broadcast, we also want it to be FullTransmission and BroadcastReceiver.

The last step is the reception of the message, this notified to us with the help of the following method:

Here we retrieve the dictionary, the UUID of the device that sent it and we can also know if it’s a broadcast message or not.

The validation within the delegate is used to determine if the dictionary that was received corresponds to a chat message or to the dictionary that is sent to indicate the name and type of device of a peer

With these few lines of code it’s already possible to have an app communicating with the help of the Bridgefy SDK.

If you want to better understand the internal operation of the app I invite you to carefully review the code, which is documented to get a better understanding.