- You send us request and we analyze your requirement
- Discuss what will fit your needs best
- You choose experts from the pool of talents we have: we provide CVs, organize interviews, ets.
Client: US-based tech company that specializes in healthcare solutions.
Objective: enhance diagnosis and treatment of heart diseases.
Solution: custom IoT device equipped with EKG sensors which detect the electrical signals of a human body and a mobile app which displays graphical data generated by these smart sensors.
Target audience: cardiologists and patients with heart diseases.
Team: Senior developer, Middle developer, PM, QA.
Technologies & tools applied: OpenGL, CoreData, Restkit.
If you're working on an IoT solution and have not contracted a smart gadget manufacturer yet, do not hesitate to contact a reliable software vendor and build software in advance (it's a great way to speed up your time to market: if your vendor successfully connects the app to a simulator, you'll have no problem pairing it to a real device
The incoming data speed was estimated at 300 data sets per second. In order to render it in real time, the development team segmented the data into separate data sets. Although native mobile app was written in Objective-C (standard iOS tech stack), the developers had to move away from Objective-C objects and store data using raw C language data structures. This approach, allowed increased data processing speed up to 10 times.
Objective-C "objectifies" each element; the R-Style Lab team simplified the incoming data by
turning to low-level data processing.
Our task was to visualize the incoming data through medical heartbeat graphs in real time. At first the developers choose to use Core Plot library (quite advanced and flexible charts plotting library; it is written in Objective-C which is a high-level programming language; the library is the most suitable for building static charts or dynamic charts which are rarely updated).
However, it proved to be unsuitable for real-time low latency charts rendering (which was an essential feature for the project), because the entire chart had to be recalculated and redrawn with each update. Not only this introduced 2-3 seconds lag between data processing and presentation, it also severely affected rendering speed, which was only 3-4 frames per second. Our developers decided to render the data using GPU and raw OpenGLES (a cross-platform graphic library for rendering 2D and 3D vector graphics; the library has bindings for basically any programming language including C, C++, Python and Ruby).
Our team used raw data to create line strips (one of OpenGL line primitives); the line strips were then transferred to the video memory and rendered directly through OpenGL. Also, our customer wanted to render some graphs with dotted lines, so we had to implement OpenGL Fragment Shaders (OpenGL pipeline stage; the library creates a "fragment" for each rasterized pixel; Fragment Shaders take a single fragment as input and produce a single fragment as output - that's how the dot effect is achieved). Additionally, the dev team applied the antialiasing to smoothen the line graphs.
As a result, the mobile app was able to render data in realtime at 1/60 second delay and at the speed of 60 frames per second.
The Core Plot library rendered data with a delay of 2-3 seconds. Using OpenGL library, the R-Style Lab team shifted some of the load from CPU (central processing unit) to GPU (graphics processing unit). We've also leveraged the technique for the project we're currently working on.
According to Pavel Shylenok, using third-party libraries is not always a good idea; sometimes it's much better to write custom code instead. Let's take Core Plot, for example. It is open source and was created by multiple contributors and became quite huge, so basically it couldn't be modified within the reasonable amount of time
However, it was listed on ECDgram project assumptions; as a result, our team spent a lot of time trying to put the library to work. Once we turned to OpenGL (low-level solution), we managed to solve the data rendering issue. Yet, we had to develop the Zoom feature from scratch (whereas Core Plot provides it by default). Of course, the solution we have at hand now is less universal and required a bit more time to reuse, but it helps with the most critical part of each project - performance.
When it comes to the Internet of Things and especially innovative software development, you might face difficulties with no ready-made solutions at hand, therefore it's important to address vendors who specialize on IoT and have thorough tech expertise. Also, don't forget that really innovative idea might need Proof of Concept to make sure it's feasible and to choose the right approach to its realization.
The so-called low-level technologies like using OpenGL, shaders, etc. can be considered niche and even old-school (these tools were released some 15-20 years ago; not every vendor even knows how to use them). If our customer had addressed a typical iOS app development agency, they would have serious difficulties with completing the project since it required unique skills. We were able to successfully employ these technologies because we've cut our teeth on game development, which uses a lot of similar low-level tech.
There are over 50 projects in our mobile app development portfolio. Although only 5% of these projects involve low-level technologies, a niche solution can be a potential game changer.
We get into the groove, sharing what we've learnt in the real-life context with the like-minded folks.
Subscribe to get the latest insights from us!
Thank you for subscribing!