During the Oredev speakers dinner last November, I was having an interesting discussion about the car industry and how Google in one swipe mangled up the turn-to-turn navigation market. During this discussion and other interesting conversations at the following JsConf, it it became more and more clear that we (web developers) should be able to write applications for instance for cars, write applications for phones we can plug into cars, and write those applications using web technologies – meaning JavaScript, HTML and CSS.

Since that discussion, the idea developed further and after some time, things started to take shape.

Lets take a look at the first prototype of a web based application (is this the first JavaScript ECG ever?) which reads your heart rate, sends it to the mobile phone via bluetooth and displays it in a native application driven by PhoneGap, meaning – the actual application is written using JavaScript, HTML(5), CSS.

Because the quality of the above video isn’t that good I have recorded a screencast from the iPhone simulator. This video only shows the applications look and feel since the simulator is not connected to the Polar hardware via Bluetooth.

More videos are available here

After I got a first prototype running, the thoughts of what this could potentially mean would not stop popping up in my mind – the consequences for the web-development community are immense and the challenges we as web developers can face are broadened in a way that tons of exciting new things are lying ahead of us.

In this blogpost I will give you a quick outline the features of this prototype and the components I used.

Setup

To get the HumanApi ECG running I used following components:

Lets take a quick look at each of the components:

PhoneGap

PhoneGap is one of the really cool projects out there. It not only allows you to deploy JS, HTML and CSS based applications on a range of mobile phones but it also gives you great APIs to access features of the phone. Because the iPhone SDK allows us to evaluate JavaScript from within Objective C it is relatively simple to execute JavaScript calls within the webkit webview. This essentially allows you to communicate with for instance bluetooth. If more widget runtimes would give us possibilities to inject APIs into the runtime (W3C?) and make available in JavaScript we would be able to write very cool apps! (More on that in a different blogpost soon).

iPhone

besides the fact that Apple is blocking certain functionality of the phone (bluetooth for instance), it is an amazing device and allows you to do all kinds of stuff (e.g. inject JS into the webkit view). Its performance is very good as well and therefor makes a great prototyping device. To get this HumanApi prototype running I unfortunately had to jailbreak the device. We are slowly reaching a point in time where blocking device functionality will hurt Apple and other manufacturers/operators, they are locking their devices out from an amazing amount of possible application usecases.

Polar T31

The Polar T31 is a simple heart rate transmitter which you can use to monitor your heart rate when doing sports. This device is perfect for our prototype because we indirectly can send the data to our iPhone.

Arduino BT

Because I can not communicate between the iPhone and the Polar T31 directly I had to create a bridge using the Arduino BT. Essentially the Arduino receives the heart rate (using the HRMI) from the T31 and sends it to my iPhone via bluetooth.

HRMI

The human heart rate interface is a great little project by Dan Julio, who developed this hardware to receive the heart rate signal from the T31. Furthermore you can easily connect the HRMI to the Arduino BT and therefore send the heart rate to your iPhone via bluetooth.

btstack

As I wrote before, Apple does not allow to access the full bluetooth stack on the device – even though the hardware is available. Luckily Matthias Ringwald has developed a library for the iPhone which lets you access the different bluetooth profiles – without his amazing work this HumanApi prototype never would have been able to exist.

Your own HumanApi

If you want to develop your own application accessing hardware, feel free to contribute to the HumanApi project. There would be nothing more amazing than seeing for instance the ECG app running on Andriod and other platforms.

A good start are the articles on humanapi.org, the forum, the GIT repository or these folks on twitter: @nonken, @humanapi, @uxebu.

Conclusion

Essentially we are at a point where we as JavaScript developers could be writing applications we never thought of a few years ago. It is to us and to the industry now to demand that we get better and more access to the devices hardware – there is no reason why JavaScript developers get “discriminated” over native developers in the way how we can access device features

I want to close this article with a short comparison:

Often mobile developers, using web technologies, are compared to native developers on the example of games. “Ohhh but you can not write amazing 3D games using JavaScript” – funnily enough I even hear JavaScript developers trying to “defend” themselves agreeing to the above stated fact – “Yes we can’t write games, but phones are getting better so one day we will”.

We don’t need to make these kind of comparisons and should start demanding better access to the devices hardware. What stops us from saying “We don’t have to develop games, we can write home automation systems, medical applications (#mhealth), apps for the cars industry and so much more amazing stuff – and we can do it cross platform! (And WebGL is on its way btw. ;) )”?

Right now it is not the language which is stopping us. App store policies, manufacturers and operators are stopping us because we have to hack our way into the devices!

Enjoy hacking