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:

• PhoneGap
• iPhone
• Polar T31
• Arduino BT
• HRMI
• btstack
• little stuff

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

On mobile devices it is important to keep things simple, for instance to keep the number of DOM nodes low. That rules out using additional elements for the corners. On the other hand, many mobile devices are featuring recent versions of web rendering engines. Dive into CSS 3.

Modern web development techniques offer a lot of possibilities to render boxes with rounded corners: e.g. border-radius, border-image, or SVG used as background. In this post I’m going to explore the support for them across different devices and runtime environments. You can skip to the results table if all you want is a quick overview.

As stated above, I want to achieve a box with rounded corners and a gradient that reaches from top to bottom, scaling to the height of the box. The example might be simple, but it is representing a common design goal.

State of affairs

As of today, several possibilities exist to develop applications for mobile devices using web technologies. Besides Palms webOS, PhoneGap permits to develop cross-platform applications with JavaScript, HTML, and CSS for the iPhone, Android, Blackberry, Windows Mobile, and Nokia WRT (support for webOS is upcoming). On Nokia devices there are two frameworks to create applications with web technologies: the built-in Nokia Web Runtime Widgets (Nokia WRT) and Opera-based Vodafone Apps Manager, which provides a runtime for W3C Widgets (heads up! Vodafone Apps Manager is WebKit-based on the Vodafone 360 H1/M1 devices, to complicate development a little bit).

While these runtimes provide the means to build applications using well-known technology to web developers, they also bring well-known problems to the mobile sphere: inconsistencies between rendering engines. Even though most of those runtimes are WebKit-based (with the exception of Vodafone Apps Manager), there is no [single] Webkit on Mobile, as PPK has pointed out. His comparison table shows the results of testing for various JavaScript and CSS features.

Freed from the burden of “making things work in IE” we can start using advanced CSS features to build interfaces for mobile applications – but hold on, it’s not as easy as desired. Due to the differences in capabilities of rendering engines and their versions, using CSS 3 features needs a lot of testing.

Test Setup

To keep things simple in the beginning, I’ve tested on two devices: a Nokia 5800 XpressMusic and a Nokia N97 (it might have played a role that I had those two at hand when writing the article ;-)

Both devices support Nokia WRT apps natively and W3C Widgets via Vodafone Apps Manager. The HTML file consists of boxes with different set of CSS properties. I’ve uploaded the packaged Nokia WRT Widget and the W3C Widget, too. You can test them for yourself on your Nokia, if you like.

On the 5800, Nokia WRT is based on WebKit build 413 (which correlates roughly to Safari 2.0), the installed Vodafone Apps Manager uses Opera Mobile build 1265. The N97 uses Webkit build 525 (introduced with Safari 3) and Opera Mobile build 1360.

Because the two devices show no differences in rendering (with one exception), all screenshots have been taken on the N97 with the exception of one rendering bug found on the 5800. All other rendering differences are existing between runtimes only.

Test Results

Result table

The result table provides a quick overview about the tested features and platforms. Detailed descriptions of the single tests can be found below.

* background overlaps border, blurry border on the N97, circular artifacts on the 5800
** SVG backgrounds stop being rendered after the corresponding element is scrolled out of the viewport

Cases 1/2: Simple Box

Boxes 1 and 2 on Nokia WRT/Vodafone Apps Manager

Case 1 simply uses a border and a background-image:

This renders equally well on both platforms, but is not very similar to what I want to achieve: The background gradient is barely visible, because the image used is fairly high and does not scale with the height of the box.

Case 2 is a little bonus, as it does not relate to box styling: it tests for support of CSS transitions. By clicking the box, the class “clicked” is added or removed. In rendering engines supporting CSS transition the width of the box will be changed smoothly. Neither Nokia WRT nor Vodafone Apps Manager support them, though.

Cases 3/4: border-radius and border-image

Boxes 3 and 4 on Nokia WRT/Vodafone Apps Manager,border-radius on the Nokia 5800 XpressMusic

The third test adds border-radius to the CSS declaration. This comes closer to the styling goal, but is not usable on both platforms: While it’s not rendered at all in the Opera-based Vodafone Apps Manager, the older WebKit engines of the 5800’s Nokia WRT adds circular artifacts to the corner, and the background overlaps the border on the N97. In addition, the border drawing is blurry on the N97 as soon as border-radius is added to the declarations.

Case 4 uses the same background image, but as border-image. Again, Opera doesn’t support the property, but the WebKit-based Nokia WRT displays the box as intended: Sharp border, rounded corners, gradient from top to bottom. (Note: in contrast to the label on the box, the background property is set to white in this example).

Interestingly, the WRT application crashes, when the combined offset/border-width syntax (e.g. -webkit-border-image: url(box.png) 15/15px stretch).

Cases 5/6: Gradients and SVG

Boxes 5 and 6 on Nokia WRT/Vodafone Apps Manager

The fifth box uses a different approach for styling the box: It uses a browser-rendered gradient (<a href="http://webkit.org/blog/175/introducing-css-gradients/">-webkit-gradient</a>) for the background:

Support for gradients in WebKit was introduced in april 2008, but is not supported on the Nokias. As expected, it doesn’t work in opera, either.

Case 6 uses a SVG as background-image which always scales to the available width and height. This technique has been described more than two years ago for Opera, and works well in Opera based environments. Even though this example doesn’t make use of CSS 3 , only Opera seems to be able to use SVG graphics as background images as of today. This holds true for browsers with built-in SVG rendering capabilities, too.

Cases 7/8/9: Cross-Platform Solution and Advanced Features

Boxes 7 and 8 on Nokia WRT/Vodafone Apps Manager

Examples 7 and 8 represent the attempt to combine the approaches from boxes #4 and #6: They use an SVG background-image and a pixel graphic as border-image:

Because both WebKit and Presto (Opera’s rendering engine) only support one of the approaches, the box renders fine in both engines (also, border images always lay on top background images).

This would be a perfect cross-platform solution, if Vodafone Apps Manager wouldn’t show a nasty bug: The first time boxes with an SVG background are scrolled into the viewport, they are rendered properly. As soon as all boxes using the same SVG are scrolled out of the viewport, and then scrolled in again, the SVG won’t display any longer. I’ve added a video showing this behavior.

Case 8 just adds opacity to the boxes, which is only supported in Opera, but slows down scrolling noticeable. Case 9 tests for support of box-shadow, which is not supported by any of the runtimes used in this test.

Conclusion

In our small test, we actually found a solution that runs in both WebKit and Presto. Sadly, this solution is only viable if the box isn’t ever scrolled out of the viewport. The rendering problems affecting the solution can only be found in mobile versions of the rendering engines tested.

That means, support of a certain feature in the desktop version of a browser does not imply bug-free support in mobile versions. Drawing can be fuzzy or faulty. Examples are border-radius in older Nokia WRT releases or the SVG rendering bug in Vodafone Apps Manager.

Despite the fact we don’t have to deal with “legacy rendering engines” on mobile devices, it is not possible to rely on modern features like SVG graphics or CSS 3 yet. Due to many forks of WebKit, and Operas restraint in implementing CSS 3 features, each usage of such features should be thoroughly tested across all different target platforms. Write code your device can handle, don’t try to bend the browser.

Another problem are slow rendering speeds on mobile devices. It might be impossible  to use certain features, just because animations and scrolling get choppy, thus killing the snappiness of the user interface.

The Future

The newest version of Operas rendering engine, Presto 2.4 is already in beta state for mobile devices with Opera Mobile 10 (while the newest desktop version still uses Presto 2.2), and adds support for many CSS 3 features like border-radius, border-image, background-size, and CSS transitions. This will enable us to use all of the techniques that have been shown for WebKit in this post (border images, border radius, and box shadow). Using a combination of background-image, background-size, and border-image could provide a solution that degrades gracefully on older devices.

Also, CPU and rendering power of mobile devices will increase in the next years, providing faster rendering of HTML/CSS with smooth animations.

Thanks to the fact that developers don’t have to account for the market leader, the mobile browser/rendering engine market evolves way faster than the desktop browser market does. I am excited about the possibilities we have today and looking forward to the possibilities we’re going to have after the next releases of browsers an built-in rendering engines.

To Do

The plan is to make the tests more complete. One the one hand that means adding tests (e.g. the current test series lacks a test for -webkit-/-o-background-size, which would allow to scale the background image with the size of the box). Another interesting topic is support for CSS transitions.

On the other hand I would like to deploy the tests on as many platforms as possible. The next steps could cover packaging for platforms supported through PhoneGap and webOS.

If you would like to see a certain feature tested, I would appreciate a comment very much. Follow me on Twitter (void_0) to be kept up-to-date about my random findings in the mobile web dev sphere.

Well, call me pedantic for even discussing this and seeing this as relevant. But everybody knows that adhering coding styles make programming in a team way more pleasant and it is just way more efficient to just code and not to style! Which includes not having to think about how to style the code, though I realize that a lot of programmers have a problem adapting to coding styles.
We at uxebu basically defined that we are applying the coding guide lines of the project that we possibly contribute stuff back to. This means our JavaScript code applies the dojo coding style guide and our python stuff (we use internally) applies the django coding style guide.

But let’s look at the for-loop now.

The default

The most common usage of a for loop is the following.

Nothing spectacular here. But let’s take it apart a bit. There are two things that are commonly known that can be optimized.

1. The comparison “i<nodes.length” in line 1 evaluates the length of nodes on every iteration, if the nodes array is not modified while looping over it or the change to it is not relevant, this can be optimized.
2. Also the declaration of the variable “node” in line 2 is done multiple times, so this is just a small unnecessary thing to do.

So let’s optimize the things we just found out.

Version 2

Another step on our way was to optimize the variable declarations and reducing their count from three down to one. In some code you can then see the following.

Version 3

Actually we have already skipped a tiny step in between, very often you can see multiple var-statements as opposed to the already “squeezed” one-liner in line 1 above. The way of writing it as seen here, is reasonable if there are a couple other variables to be declared, you just need one var-statement. This will basically reduce the code size, if your minifier doesn’t already do that for you. As stated here it seems to be specified to be irrelevant to performance. So event the argument under 2. against the first version (see above) is not very strong.
Just a small side-note: the one line var-statement evaluates in declaration order, so something like this will work!

The “len” and also “x” variables contain the proper content as you are expecting. The comma-separated var-statement evaluates the assignment expression by expression and steps on to the next assignment. Therefore “len” and “x” will have the proper values 3 and 2.
But let’s go back to our for-loop.

Version 4

If the var-statement is outside the for-loop and especially if other variables (outside of the scope of the for-loop) are declared there the source code get’s blury and harder to read. For example:

The first two variable declarations (someVar and anotherVar) have nothing to do with the for-loop context, but the others do, so this blurs the source code and is prone to errors. Also if you separate this source code onto multiple lines like so:

it is still a possible point of failure. I for example, forgot the comma on line 1 which made this source code

still work. But and this is a big but, the code get’s a different meaning now! First, line 1 will work, since the semicolon at the end of the line is not mandatory. And second (if not declared inside this scope before) the variables on line 2 are now defined in global scope. And that can really cause a hard to find bug!
Another good reason for not doing this, is that extending the code may lead to developers adding code in between the var-declaration and the for-loop, for whatever reason. Then the variable declarations for the for-loop “drift away” and loose their context even a bit more. And the source code becomes harder to understand.

So we rather put all the variable declarations into the for-loop’s var-statement. Like so:

Now we have a pretty compact and well context-focused syntax for declaring variables needed within a for-loop. This code is nicely readable and has no impact on performance, even if in most cases good and maintainable code is worth more than the fastest code, but that’s a use case based decision! We are taking this as a standard for uxebu code.

What do you think? Let us know if you see potential for optimization.