Thanks to smart sensors and powerful analytics software, tech-savvy companies automate time-consuming business processes, get a better insight into customer and employee behavior and subsequently reduce operating costs.
By 2020, the global IoT market revenue will top $1.7 trillion.
However, the process of building IoT applications and hardware is associated with certain challenges, including the right choice of a vendor, pricing model and tech stack. R-Style Lab, a software development company with a representative office in San Francisco and development facilities in Belarus, has recently worked on an iOS app for a custom heart rate monitor and is eager to share its experience with fellow developers and tech amateurs.
The challenges of the Internet of Things custom software development
ECDGram (we changed the project name at the client’s request) is a custom heart rate monitor which detects the electrical signals of a human body through smart EKG sensors and sends the data to a dedicated iOS app via Bluetooth. Our customer – a US-based IT startup – wanted to create a native iOS app supporting real-time data visualization.
Data rendering aside, ECDGram seemed to be an unremarkable IoT mobile application development project, so we suggested using the Fixed Price model and agreed to deliver the software in 11 weeks.
Amid the dev process we discovered that the Core Plot library (which was listed on ECDGram assumptions) was not suitable for producing dynamic medical heartbeat graphs in real time since the amount of incoming data was larger than we’d expected.
In order to visualize the incoming data at a speed of 300 dots per second, we segmented the Objective-C data into separate data units (raw C), partially transferred the workload to GPU and rendered sensor data using OpenGL primitives. As a result, the ECDGram mobile app was able to produce graphs in real time at a 1/60 second delay and speed of 60 frames per second.
Pavel Vaskou, senior iOS developer and head of the iOS app development unit at R-Style Lab, reflects on the ECDGram project and the challenges the dev team had to address.
According to the project assumptions, you were to enable real-time data visualization with the Core Plot library (which turned out to be unfit for the task). Was it the customer who insisted on using the library or was it your mistake?
Pavel: While the R-Style Lab team was preparing the estimate, we suggested using Core Plot as it features all the necessary functions to produce high-quality graphs. Our customer was operating on a shoestring; by using an out-of-the-box solution, we reduced the final estimate and met the budget.
We surely knew that EKG sensors would produce a large amount of data per second; however, we thought we’d average the readings and render just 20 or 50 dots per second instead of 300 dots per second. We had implemented the library while building other IoT mobile applications (including ECDGram beta) – and Core Plot did just fine.
We somehow ignored the fact that ECDGram was a healthcare gadget designed for cardiologists and patients with heart disease. In order to improve heart rate monitoring and provide a detailed picture of a patient’s condition, we needed to visualize all the incoming data through medical heartbeat graphs in real time – and that’s where Core Plot fell short. Since the library had to re-draw graphs with each update, the lag between data processing and visualization was estimated at two to three seconds. What’s more, the rendering speed staggered around four frames per second.
That’s why we opted for OpenGL instead.
OpenGL is a low-level programming solution, so you had to move away from Objective-C (which is the primary iOS tech stack) and store data using raw C language data structures. How did you do it?
Pavel: The app received the incoming data in binary format over Bluetooth, so we had to convert it into numbers in order to differentiate the types of graph points and their meaning. If we had stored the data in Objective-C, it would’ve taken us ages to process it.
How often do iOS/Android developers use the OpenGL library?
Pavel: OpenGL is a popular cross-platform API for rendering 2D/3D vector graphics. The library, for example, is widely implemented in game development and computer-aided design. The list of popular applications built with OpenGL includes several Adobe products (After Effects, Premiere Pro, earlier versions of Photoshop), Autodesk software (Maya, AutoCad and 3D Max), multimedia tools and web browsers (Google Chrome and Mozilla Firefox).
As a matter of fact, only senior developers or software engineers with previous experience in game development are familiar with the technology. R-Style Lab Software Development Company does employ such specialists. We’re currently developing an app (Rewind Radio) which uses OpenGL, too. Approximately 20 percent of all IT companies work with low-level programming solutions, so our customer certainly got lucky.
The client did not provide the gadget which had to be connected to an iPhone over Bluetooth, so you used a simulator instead. Was that a problem?
Pavel: Our customer supplied us with an application which generated a certain amount of sensor data per second. The sensor data was extracted from a source file, so we only had to parse the binary data and transform it into readable code. Once we completed the ECDgram app, the client edited the code and replaced the data file with a Bluetooth device. All in all, it wasn’t a problem.
Some customers provide mobile IoT app solutions that simulate Bluetooth connection. We’ve also worked with clients who supplied the dev team with a real device. Working with a simulator is not one of IoT app development best practices; yet, it’s acceptable.
ECDGram was a fixed price project. If you’re working on an innovative solution, however, you need to create proof of concept and do some research to make sure your idea is feasible. Wouldn’t it be more suitable to choose the time and material pricing model instead?
Pavel: The customer contacted our business development manager and listed the requirements for an iOS app. The project seemed to be a piece of cake at first. Three interfaces, basic authentication and real-time data visualization – that’s all there was to it. Obviously, the client did not expect any research or proof of concept stage and was pressed for money. We’ve made a huge mistake, too: instead of building the data rendering feature in the first place, we wasted quite a bit of time on UI design and authentication. By the time we got down to core plot, the project was halfway finished. It was too late to change the pricing model and conduct proper research. As a result, the project was only marginally profitable for our company.
If you want to develop a mobile IoT app that requires the integration with new APIs and hardware solutions or automates tasks no one has automated before, you should define its core features and devote some time to research to choose the right dev tools and filter out unfeasible ideas.
Here’s one more example from our portfolio. Back in 2015 we were addressed by a U.S. company that manufactures intervertebral prosthetic gadgets. These gadgets have unique identifiers, so the company intended to create a machine vision system to automate patients’ X-ray images processing. During the proof of concept stage we discovered that modern X-ray equipment failed to produce 4K images, so the accuracy of the machine vision application did not exceed 70 percent (which was not enough to put the software into mass production). As a result, the project was postponed for an indefinite period of time.
Relatively few vendors possess expertise in the Internet of Things software development. Although the lack of interoperability and security standards remain the key barriers to IoT adoption, sometimes innovative projects fail due to the wrong choice of a pricing/project management model or tech stack.
Also, non-tech companies tend to treat research as ordinary charts you can get on Google, somehow forgetting how much time and effort it takes vendors to get those numbers and conduct a feasibility study. Investing in research is a great way to filter out dead-end ideas and…save your money.