Tech Talk: How to Make a Mobile Messaging SDK
Udi Dagan joined LivePerson in 2014 as our first-ever mobile developer and became the team leader a few months ago. He’s an electrical engineer with degrees in communication and signal processing. Based out of LivePerson’s Ra’anana, Israel, office, Udi currently heads development of an enterprise SDK to intercept potential user behaviors and trigger engagements between businesses and customers.
* * *
If I could offer you only one tip for the future, messaging would be it.
Mobile usage is rapidly growing, reaching a tipping point where consumer’s mobile usage is overtaking their desktop usage. It’s now clear that mobile commerce and customer care will soon follow.
From an enterprise point of view, however, this shift of mindset is much more complex. Many of the largest companies — even those that lead their respective industries — fail to adopt modern concepts such as mobile readiness, asynchronous communication, personalized customer care, and more.
Looking around, one can easily count the numerous messaging apps like WhatsApp, Kik, Line, WeChat, Telegram, and Facebook Messenger. These apps excel in connecting people with each other. They’re easy to use, stable, and so popular that their usage exceeds phone and SMS app usage combined.
Messaging apps today have already identified the trend and the need to connect customers with brands, and most of them enable texting to brands’ web pages and Facebook inboxes. Yet none connects to a platform that would enable the brand itself to develop a meaningful connection and provide a complete solution for a messaging-based “call center.”
When most corporations approach customer relations and customer support, they end up with the traditional solution of the 1-800-number IVR system. It doesn’t seem to fit the need of continuous, fast, and asynchronous (without the need to wait on the line) service.
Even if a brand wishes to become fully mobile accessible, it hasn’t been able to do so — until now.
SDK: A gateway to a bigger platform.
Consider a messaging app, from which you could contact any brand in the world. How would the brand receive and manage the data flow effectively and in an orderly fashion?
Traditionally, huge call centers employ phone representatives who work serially, attending to customers one at a time. But developing a brand-new (custom) system to support messaging, regardless of its efficiency, would be extremely expensive.
Imagine messaging capability integrated with a brand’s own mobile app along with a complete customer care messaging ecosystem that stands behind it...within a single line of code.
LivePerson developed an SDK that implements all of the APIs required to connect to its messaging platform. The SDK gives the user all of the familiar messaging capabilities while LivePerson supplies the tools that make the brand’s customer center more efficient.
Combining the two creates a better, faster, and more modern connection between brands and consumers.
In this Tech Talk, I’ll give you an inside look at how we built an entire platform in one line of code.
Easier said than done, right? We came across several challenges in doing this. But now we’re ready to get our hands dirty. Building a software framework taught us some fundamental ground rules and best practices for building an SDK. Here's what we learned.
First lesson: Third-party etiquette.
You are a guest, and, as one, you have to be polite. In a mobile software environment, this means being as invisible as you can. Blend in.
Don’t steal your host’s horsepower: Consider every instruction sent to the processor. A mobile device is very limited in CPU resources. The processor utilization must be extremely efficient. Leave heavy processing to the server and beware of expensive UI tweaks. In any case, a third-party library can’t affect the performance of the host app. Also, watch how long your code runs in the background: Don’t deteriorate the battery life, or you’ll be responsible for the host app’s removal and exposed to very bad reviews.
Ask for permissions: ...But only when you really have to. The host app has predefined rights to device permissions. Permissions are granted by the user only once, and the SDK can’t risk making this process more difficult. A third-party library should ask for such permission only at the very last second, when the user prepares to perform a specific action.
- Ask for photo gallery access — after the user chooses to attach a picture.
- Ask to enable push notifications — after a connection was established.
- Ask to use location services — when a map is about to be opened.
On that note, the messaging SDK would be rendered useless without push notifications. It's best to allow the host app to ask for permission to enable push notifications first.
Don’t kill your host: Test, then test again. Having a bug in your own app that causes a crash is one thing. As a third party, you were given the chance and the honor to run code in a host application. Don’t kill it.
Second lesson: Converse, don’t poll.
Choosing WebSocket as the “native” communication layer for a mobile was almost obvious.
Be fully asynchronous: The messaging SDK needs a two-way communication method instead of the traditional request-response model. This way, there’s no need for a polling mechanism that queries for updates. When the data is ready, both sides can publish it. Being event-driven instead of using polling queries also helps us remove boilerplate code, timers, and worker threads that were assigned only to serve the RESTFul methodology.
Minimize battery usage: Opening a TCP connection with its accompanying header is a pretty expensive operation. Instead of polling for new information during the whole app lifecycle, we use a full duplex WebSocket, which allows us to exchange small packets only when needed. This proved much more efficient.
Third lesson: One-liners that actually work.
The SDK has one access point, making it easy to initiate and manage. One can go from a simple integration (LPMessagingSDK.instance.init()) to being up and running in seconds. The SDK will take care of the rest.
After the first integration, more options are available, controlling more low-level flows and behaviors and allowing the developer maximum flexibility with the code. The UI ranges from a default skin to one that's fully customizable or even optional. A developer can choose to implement his or her own UI and use the SDK only for the business logic and handling the connection to the server.
People unanimously choose messaging as the #1 communication method in the mobile world. LivePerson is pioneering this field in an enterprise-ready standard, building a complete solution that’s well suited to the modern needs of both customers and brands.
It’s now clear that mobile messaging SDK is an essential step for every brand wishing to enhance its quality of service and connection with its consumers. LivePerson has made great strides in making this possible by tackling performance, security, and scalability in order to build a high-end messaging platform fit for the enterprise world.