A small touch of frontend for InMoodForLife
If you haven’t followed our precedent posts, InMoodForLife is a project to build a sleep tracking and analysing device for young people with mood disorders. We began by describing how we reverse engineered the Beddit sensor, then ourRaspberry Pi based setup to collect and analyse the data and the Eclipse Vert.x and Warp10 stack that we put into the Raspberry Pi to do it and talked about a key point of the project, the data analysis. Today we deal with the missing part of the project, a small web application to pilot the scanning process.
Defining a technological stack
If everything goes according to the plan, we will soon be able to automatically analyse the sleep of our users and extract the sleep cycles information. With this aim in mind, we had began to discuss what we would need as application in order to pilot the device and show the pertinent results.
We quickly discarded the idea of making a native PC, Android or iOS application, as we wanted our solution to be available everywhere. And as the only technology able to do it is the web, we decided to do a web application, or more exactly a progressive web application (or PWA).
PWA are like normal web apps on steroids. Or to be a bit more factual, they are web applications with some extra characteristics that make it interesting for our project:
- Progressive: they work in any web browser, and they enhance progressively according to the features of the user’s browser and device. This is a key point for us, as the project need to be inclusive but we can offer more features for the devices that support them
- App-like and installable: the app should be built to offer a native-like UX, with an fast loading app shell, no page reloads, asynchronous content calls, and a manifest file to tell the browser that the app can be installed on the device’s home screen, making it readily available. From the user point of view, it should be almost like a native app in every aspect.
- Responsive: another key point for us, as we wanted the app to be usable on any device, from a cheap 3.5 inches smartphone to a 28' 4Kcomputer screen, portrait or landscape
- Re-engageable: the app need to be able to push notifications like native apps do, sending pertinent information or reminders to the user even when she is not directly interacting with the app
Being a firm believer in the web components standard, I also pushed to use a web component technology: Polymer. That allowed use easily reuse a lot of custom elements, specially the QuantumViz, a Warp10 library for time-series data-visualisation. And the tooling added to Polymer last summer, with a command line tool, project templates and lots of helpers is fully PWA oriented, eliminating most of the heavy manual tasks to transform a normal webapp in a progressive one.
So the technological stack was chosen: a PWA with Polymer.
Under the clouds, the fog
For an IoT project like this one, where all the intelligence is done in an humble local Raspberry Pi, it wouldn’t make any sense if the PWA piloting it was served from an instance on a cloud. In order to respect the logic of the project, we had to descend from the clouds and land directly in the fog computing.
So we decided to give a new rôle to the Eclipse Vert.x on the Raspberry Pi, it won’t only receive the raw data, decode the stream, push the metrics on Warp10 and launch some WarpScript for the analytics, now it will also serve an API and the PWA that will use it.
In this way, the whole setup is fully self contained, a local environnement that can work even without internet connection.
The PWA approach shines well in this context. The app is directly loaded from the device, but with the installable properties of the PWA, the user can install it in her homescreen and use it like a normal app.
Let’s begin small
The first version of the InMoodForLife should be very simple: a small PWA that connects to the Vert.X on the Raspberry Pi and do basic piloting features: start and stop Bluetooth scan for detecting compatible devices, pairing with the selected devices and then starting or stopping the raw data recording process.
In fact, we had been doing all those operations with curl requests while we developed all the backend side, so this first version of the app was only going to give us a friendlier way to do it.
A touch of UniFlow
There are many ways to code an application in full Polymer, many possible patterns. These days I find myself deeply attired by one of those patterns, UniFlow Polymer.
The UniFlow pattern is a set of behaviors to enable uni-directional data flow in Polymer applications, inspired by React’s community Flux and Redux.
I found UniFlow after having developed apps in Polymer for more than two years, and I fully agreed with their constatation about Polymer projects:
When you start working on a new Polymer application, it’s easy to start and build the first few elements, and make them communicate via events and data binding, so everything looks nice and rosy. However, as the number and complexity of elements grows, it becomes increasingly difficult to manage relationships between them, trace where/when the data changes happened, and debug the problems
Yeah, using UniFlow can seem to add an overhead to your development process, specially is the app is still small, but believe me, then your app grows up (and in most cases it will do it) this overhead is quickly balanced by the advantages of the unidirectional data flow: a more streamlined code, easily debugged and managed, where adding a new feature is easy and painless.
The first version
So we coded the first version of the InMoodForLife PWA, a small and humble app that replaces our set of curl calls, but that is a streamlined base on which we will be able to add new features as soon as they will be made available on the API side.
