BrightContext and Titanium Mobile: Simple real-time messaging

If you’re looking for a way to easily enable your client software to send and receive low latency messages with a server or other clients, BrightContext‘s service may be just the thing you’re looking for.

BrightContext provides you a shared message queue to which clients can submit messages and subscribe to receive all messages sent to the queue.

As of version 1.6.0, the BrightContext Javascript API supports Titanium Mobile out of the box, making it very easy to integrate into your application. All you need is the bcc library and the Ti websocket client library.

Back-end basics

To use the API, you need an API key. You can get a free key by signing up at http://www.brightcontext.com/. Once you’ve got an account and a key, you can set up a channel. BrightContext defines two types of channels, a Thru Channel and a Quant Channel.

A Thru Channel broadcasts each message received to all listeners on the channel. The data is passed along, unmodified. A Quant Channel performs data processing like filtering and aggregation on the data as it flows through the channel.

The free API key entitles you to one Thru Channel and one Quant Channel. You can send 70,000 messages/day on the thru channel and 35,000 messages/day on the quant channel. You’re limited to 20 simultaneous connections, which should be enough to build a proof-of-concept and do testing on your app. The good news is that if you’re trying to get an app off the ground, the “Small sized” plans give you a pretty large number of messages and connections. If you start exceeding those limits, one would hope that you’re finding a way to monetize your app or at least getting enough value out of the app to be able to justify an upgrade.

For the purposes of this example, we’ll use a Thru Channel. We’re just building a simple chat application, so we don’t need the server to perform any processing on the messages that are sent through the channel. We create a project and a channel within the BrightContext developer tools on their web site.

Initialize the feed

Once we’ve done the back-end setup, we’re ready to work on the client code. The first thing we have to do is to get an instance of the BrightContext API object by requiring the bcc javascript (download the hosted bcc library here and save it to bcc.js in the util directory underneath Resources):

Next, we have to provide a WebSocket and XHR for the library, since the library was originally designed to run in a web browser and would normally get those capabilities from the browser:

There’s a little more configuration that has to happen:

And now we’re ready to go. We initialize the library with our API key and get a project object:

Using this project object, we can set up the channel:

Within the call to create the feed, we point at the appropriate channel which we’ve defined in the back end. In addition, we can set up event callbacks for various events in the lifecycle of the channel, like onopen, onclose, etc. Most importantly, we can provide a callback for onmsgreceived:

Since I’m wrapping the bcc library in a CommonJS class (“BCFeed”), I’m going to handle onmsgreceived by firing an app-level event. My application won’t interact directly with the BrightContext API, but instead will create a BCFeed object. It can use BCFeed.send() to send a message, and it can listen for the BCFeedMsgReceived application event to handle incoming messages. Once the bcc API class is wrapped up like this, the message sending and receiving in your application code is extremely simple.

Wire up the UI

In my example code, the BCFeed object is created in the FirstView class (I just used the Single Window template in Ti Studio).

When the view is initialized, we compute a UUID so that we can identify messages that come from this client instance and those that come from other users.

When the user enters a message in the TextField and clicks the button, we take the text from the TextField and wrap it with the UUID in an object to send to the BrightContext channel:

When a message is received, we add it to the list of messages in the TableView. Messages from this client instance will get a “> ” prepended to the message text in the list of received messages. This helps the user distinguish his own messages from the messages of others.

You can get the full code at GitHub.

Do more

This app is obviously simplistic. It barely scratches the surface of what you can do with BrightContext’s channels. The good news is that doing more with the channels would really just mean more complexity in your client code, not more complexity in the back-end.

Some ideas for extending this code:

  • send user’s name and display it with the message
  • let the user select from a list of built-in avatars; send the avatar ID# with the message and display it in clients
  • send user’s location, display messages on a map
  • filter messages in the client so that user only receives messages in his metro area
  • real-time “sentiment” tracking using a quant channel

Leave a Reply

Your email address will not be published. Required fields are marked *