Android as an IOT platform

The term “platform” is very ambiguous when used carelessly by programmers and consultants in the information technology business. Under various circumstances, TCP/IP, Linux, Oracle and Java are all referred to as platforms even though they are neither similar nor comparable to each other. Even within the narrower definition of IOT we can look at platforms from at least three directions. First,  we have hardware based platforms like Qualcomm’s AllJoyn, Intel’s IOTivity, Apple’s Homekit  and Android/Brillo from Google. Second, we have different data transport protocols like XMPP - used in Internet Messaging (IM), MQTT - a publish / subscribe model for messages, DDS - another pub/sub model for data distribution services and AMQP - Advanced Message Queuing Protocol. Finally we have integrated, cloud based platforms from big and small companies like IBM Bluemix, Carriots, n.io, thethings.io, thingworx and many others that claim to provide end-to-end solutions to transfer information from one machine to another.

All this is very confusing for any programmer who has built traditional, multi-tier applications that have a human user in the front and an RDBMS at the back. How does he get into the exciting world of IOT? What are the components that he needs to understand and work with?

Let’s break up the problem into four components. First we need a sensor A that will detect a physical property like temperature, air-pollution or blood sugar and generate a digital signal. Second we need a mechanism B that supports data transfer. Third we need a device C, a processor with an OS, that supports a device driver for A and programming language that can interface with B. Finally, we need a program D to receive the data and store it in a persistent database. It is now our job to identify the components A, B, C and D.

A, the sensor, would be very domain specific and would have to be sourced from specialist hardware vendors. Many kinds of sensors are readily available along with their device drivers for Linux, Windows and Android.

An important requirement of component C is that it should be small, portable, have a low power consumption and yet provide continuous data connectivity. While dedicated devices can always be built to meet these requirements, IOT enthusiasts often begin with Arduino or Raspberry Pi. But an inexpensive Android device is perhaps a better option because not only does it meet these basic requirements but also supports a wide range of sensors natively. Moreover, given the frenzy around Android development, there are many tutorials available and android tagged questions in stackoverflow are answered quickly! So for the choice of C, Android is a good option.

Moving on to B, the data transport mechanism, the two simplest options are XMPP and MQTT. Both are available as open source implementations and work comfortably on the IP networks that an Android device routinely connects to using either WiFi or 3G/4G data service. XMPP, formerly known as Jabber, is the basis of all Internet Messaging or “chat” services, like Google Chat, and there are free servers and services available for building and testing applications. XMPP also offers the security of a login and a password along with the concept of authorised “friends” or “contacts”, but this can become a challenge if we have to allocate and manage IDs for each and every machine in the IOT network. MQTT, formerly known as IBM MQ Series until it was made open source, offers a convenient publish / subscribe model where any device can publish messages under a topic into a central server, like Mosquitto or HiveMQ, and which can be retrieved by any other device that subscribes to the same topic on the same server. Both XMPP and MQTT have Java and Python libraries that allow applications developed in either of these languages to transmit and receive data as text strings. These libraries are available not only for Windows and Linux platforms but so can be used for in Android apps.

With these libraries it is now entirely possible to write applications on component C that will transmit data. Corresponding applications on component D, which could be a standard Linux server running Python, Java and either SQLite or MySQL, would receive the data, decode and process it with business logic and store it in a persistent database for subsequent analysis and display.

If we leave aside the integrated, proprietary, cloud-based platforms then the Android platform with applications developed with either XMPP or MQTT libraries is a very viable option. Why do we say so? First Android devices are dirt cheap and available at retailers like Walmart for US$10. Remove the unnecessary audio and video components and wholesale prices will drop to half of that. Second the gigantic and ever expanding community of Android app developers represents a huge pool of talent and expertise that can be leveraged inexpensively. Third, Android already has native support for all popular data transfer mechanisms like 3G / 4G / WiFi / Bluetooth / NFC and is likely to support anything else that comes in the future. Fourth, Android devices routinely support many kinds of sensors for gathering biometric, motion, position and environmental data and thanks to the pressure from app builders there are many third party sensors in the market for biomedical and additional environmental data all of which are very useful for IOT applications.

But the fifth and most important reason to bet on an Android based IOT is the massive ecosystem around it. Google has not only invested US$ 3.5 billion in acquiring the home automation company Nest but has also thrown its weight behind a brand new product, Brillo, that is based on Android and extends it with Weave, a data communication platform for IOT. Of course, not all Google products are equally successful -- Google+ or Google Wave are nowhere as popular as its search engine, Gmail or Youtube -- but with an 80+% market share Android is miles ahead of the competition in the 2+ billion smartphones that are in the market today.

---

This article was originally published in theStack