The second day was mainly focused around mobile topics. Nikolai showed us how to think out of the box (which is your phone in this case) by talking about “Human APIs – expanding the mobile web”. I tried to give an overview about how to use web technologies for mobile apps by talking about “App vs. Widget – HTML5 Apps”. And as it seems we had hit a sweet spot there as the tweet proves. It seems we had found our slots there. It was fun to see that.
Find our slides below.

It was great to see Sony Ericcson show their PhoneGap based strategy. Since that is also part of our direction it is very encouraging to see that there is company on going this route. They showed a webbased build tool, which allows for a simple creation of runnable apps based on PhoneGap and also interesting ideas around native APIs and the security concept. A lot of triggers that made a lot of people think. Great input.
@creationix showed a cool demo using node.js, where we could all interact with his app. @divineprog showed DroidScript, which basically was a Smalltalk inspired realtime Rhino-based JavaScript runtime, that allows using native Android resources. We learned a lot around geo data, their handling and optimization in use from @tablackmore. Those are just some of the talks, they all were of high quality, so be sure to see them live next time.

At the mobile day we also heard talks about

• The New Mobile Web – A Web of Scripted Applications by @divineprog
• How to avoid the latency trap by @sh1mmer
• Handling spatial data on the web by @tablackmore
• HTML5 gives you wings by @mahemoff
• The phone in the cloud by Claes Nilsson and Thomas Bailey
• node.JS powered mobile apps by @creationix

All in all it was a great conference, I will look forward to be coming back next year.

Making your web app iPhone ready

Note: you can visit the example used in this blog post from your iPhone here.

The most well-known and really most important meta tag you need to know about is the viewport meta-tag. It allows you to define the minimum and maximum zoom-level and whether or not the user is allowed to zoom into the view. You disable zooming by setting the minimum-scale to the same value as maximum-scale. At the same time you can define the viewport width and height by setting the “device-width” or “device-height” properties. If you have a website with a width of 960px and you want it to be zoomed in to fit exactly that width, all you need to do is to set width to 960. Since your website should run on several devices though with different resolutions it is not recommended to set an absolute width and instead use the predefined device-width and device-height values. This ensures that your viewport has exactly the size supported by the device.

1

<meta name="viewport" content="width=device-width,minimum-scale=1.0,maximum-scale=1.0"/>

Now lets get to the juicy part. When creating an HTML5 app for the iPhone you can define an icon which you will see on the start screen of your iPhone. Once you set this meta tag, the user won’t be able to see a difference between a native application and a web application on your iPhones homescreen.

1

<link rel="apple-touch-icon" href="/yourIcon.png"/>

To add even another level of detail you can define a startup screen for your application. This is especially useful when your application supports offline mode using cache manifests.

1

<link rel="apple-touch-startup-image" href="/startupImage.png">

All of those features wouldn’t be complete if you couldn’t hide the browsers chrome once you start your application from the homescreen. To disable the chrome just insert following tag:

1

<meta name="apple-mobile-web-app-capable" content="yes">

Now after you have added this meta tag you want to be able to differenciate between the user launching the app from the homescreen of the browser.

1
2
3
4
5
6
7
8
9
10

// navigator.standalone
if ("standalone" in navigator){
    if (navigator.standalone){
        alert("Started from homescreen");
    }else{
        alert("Started in browser");
    }
}else{
    alert("Not supporting standalone property");
}

Last but not least you can even control the look and feel of the status bar on the top. You can either use the default status bar or a black status bar or a semi translucent status bar:

1

<meta name="apple-mobile-web-app-status-bar-style" content="black/default/black-translucent" />

These are the most important things you need to know to make a simple website be HTML5 app ready on your iPhone (note: this only works on the iPhone but won’t hurt other devices and platforms). A “normal” user won’t be able to differentiate between a native or a HTML5 app anymore. Do you know of similar features of other phones? Do you think we should standardize the discussed features? (Some are already).

If you need support getting your website or web application HTML5 app ready, feel free to contact us.

Enjoy

Dowload

• Source
• Docs

Here it is: TouchScroll, our scrolling layer for WebKit Mobile. It is JavaScript/CSS 3 based and allows for fixed elements like headers and toolbars on web pages when viewed on the iPhone or on Android. It works on the iPad, too. Check out the demo (short URL: http://u.nu/8uvg8) to see it in action – it works in Desktop Safari (at least kind of) or WebKit Nightly (very good), but I recommend you have a look at it on your iPhone, iPad, or Android based device.

Motivation

While Safari Mobile features native scrolling, there are two reasons to re-implement scrolling with JavaScript: The original scrolling behavior is rather slow – we were looking for a solution that feels more fluid. And the viewport behavior of Mobile Safari and other mobile browsers using WebKit doesn’t allow for fixed positioned elements. It is optimized for document reading, not for building interfaces.

Our goal is to be able to deploy application interfaces to browsers of handheld devices that feel as familiar as possible for the user. TouchScroll enables developers to use fixed interface elements like headers and toolbars.

We also use PhoneGap a lot to deploy cross-platform applications onto smartphones, and we think that web based apps don’t need to feel like aliens for users. And we weren’t satisfied with existing solutions.

Usage

To add a scrolling capabilities to an element, that element must have a fixed size. Have a look at the demo for an elegant approach using display: -webkit-box.

HTML:

<div class="scroller"><!-- some great contents --></div>

JavaScript:

var scrollNode = document.querySelector(".scroller"), options = {};
var scroller = new TouchScroll(scrollNode, options);

At the moment, the only known option is elastic. Use {elastic: true} as second parameter to add the bouncing effect to the scroller.

Get it!

TouchScroll is available on github. Feel free to fork it and send patches back. You can also get a minimized file that includes the css-bezier library that TouchScroll depends on.

How is it done?

TouchScroll uses a combination of JavaScript and CSS 3. All animations are done with CSS transitions – no JavaScript intervals.

The elasticity effect when crossing the scroller bounds is achieved by dividing the bezier curve (used as timing function) into two sub-curves using my (yet to be finished) CSS Bezier library for JavaScript.

Customization/Configuration

TouchScroll allows you to customize many aspects of the scrolling behaviour: Have a look at the config object at the top of the source file.

Customizable properties include bouncing behaviour and deceleration animation. Feel free to experiment. I know that scrolling is not as close to <insert device of choice> as possible. If you think you’ve found better values, just let me know.

Configurable properties include:

• Scrolling threshold: The minimum pixel amount needed to begin scrolling
• Flicking behavior: flicking threshold, friction, and deceleration animation.
• The elasticity/bouncing effect: factor and maximum bounce length.
• Snap back behavior: timing function and default duration.

Goodies

After instanciation, each TouchScroll scroller re-adapts to its contents after orientationchange and resize events on window as well as after DOMSubtreeModified events on the scroller itself. That means, the scroller adapts to content additions and deletions.

Limitations

TouchScroll is meant to be used with touch-based devices and also works well with a stylus (tested with a Wacom tablet). Don’t use it for desktop browsers and the like. Simply add overflow: auto to the scroller element for these cases. Zero-cost compatibility.

Hiding and Showing

If a scroller is instanciated with an layer that is not beeing displayed, it needs to be refreshed manually after making it visible. Simply use the setupScroller method.

Styling

TouchScroll inserts two more <div> elements to the outer scroller container, that wrao the prior contents. That means, that the outer scroller element must not have padding. The CSS child selector (a > b) won’t work any more after instancing TouchScroll on an element for the same reason.

Android

Android has several problems that need to be solved. If you have solutions, please keep in mind that TouchScroll should remain compatible with WebKit as found on Android 1.5 and send us a patch.

• When not preventing the default action of the initial touchstart event on Android, the following touchmove events queue up and fire just before the eventual touchend event. That makes scrolling impossible.Cancelling the touchstart event results in other problems: It prevents tapped elements from beeing focused or clicked. The current workaround – dispatching a synthesized click event – hides the focus rectangle and makes the focussing of form elements nearly impossible, which is even worse.That means: at the moment it is not possible to use TouchScroll in conjunction with forms on Android.I’d like to know whether there is a solution that eliminates the need to prevent the default action of touchstart.
• Due to the lack of hardware acceleration, the rendering performance on Android isn’t nearly as good as on the Apple’s devices. We already invested a lot of work to achieve good performance. If you can do better, send us a patch!
• Support for -webkit-transform: matrix(…) is broken in Android < v2.0. That affects reading the computed style of elements. We already worked around that issue using a regex-based parsing function for those devices.

Other Devices

The browser of S60 devices is based on WebKit, too. However, apart from the fact that TouchScroll does not work on those devices, you should simply set the overflow style of the scroll container to overflow: auto for these devices and benefit from native scrolling. The same goes for Nokia WRT apps.

I’ve done a quick test on the Palm Pre. Unfortunately, TouchScroll does not work in the browser of webOS. Moreover, I’m not sure whether it actually makes sense in this particular browser, as its overlays would lie directly on top of fixed elements at the bottom. In webOS apps you should probably use the native scroller anyway. Maybe I’ll do a short tutorial on how to instanciate TouchScroll on iPhone/Android and the webOS scroller when deploying a cross platform app to all of those devices.

What other devices are relevant? Let us know!

To Do

The official to-do-list:

• Keep the scrollbars round while bouncing – I already know how to do this, so you can expect the solution in the next days.
• Add an option to completely switch off scrollbars.
• Find a solution to the event problems on Android – help greatly appreciated!

This article is quite long for such a simple topic, but anyways I just feel like writing it down, since this is how I initially used my previous blog and I must say it was very helpful for me to look up things again but obviously also for others to find information. I also feel that showing what coding guide lines to use and the reasoning behind it is really important especially also for those who have to apply them.

Good and Bad

Let me just quickly show examples for DOs and DON’Ts.

1
2
3
4

// DONT
var x = 1,
    y = 2,
    z = 3;

The above looks pretty slick. But not always! Especially when working in a team and when you will rewrite or touch the later code again, which basically is the case with all the useful code out there. The second and the third line depend on the first line. That means if a coworker comes along and pastes in his variable from his awesome and dead-simple code

1
2
3

// DONT
var y0 = 1,
    y1 = 2;

into my code above. We might get the following:

1
2
3
4
5

// DONT
var x = 1,
    y = 2,
    y1 = 2;
    z = 3;

And ouch, we have a global variable “z”. Of course he should change the trailing semicolon to a comma when pasting in his code. But his IM beeped, phone rang, coffee was done or he simply felt more like skiing and stopped hacking – and he forgot :). You know what I mean!
If the code hadn’t contained multiline variable declarations it wouldn’t have happened, like here:

1
2
3
4
5

// DO
var x = 1;
var y = 2;
var y1 = 2;
var z = 3;

Though there are cases when I still think that listing multiple variable declarations is ok, like the following. But just not on multiple lines!

1
2
3

// DO
var x = 1, y = 2, z = 3;
for (var i=0, l=arr.length, k; i<l; i++){}

Real Life Examples

Let me show you three examples where I really felt the pain of the described problem, which finally triggered me to write this article. Those are real life examples, exactly the code I experienced the problem with. And at some point it was just enough.
The first example shows that a pretty complex piece of code is just not as easy to validate by humans. There is no bug in it, it is just hard to read code.

1
2
3
4
5
6
7
8

// DONT
var g = this.getObject("group.name", test) || groupName,
    // Trim and replace all special chars, to have a proper test ID.
    group = g.replace(/^\s*/, "").replace(/\s*$/, "")
             .replace(/[^0-9a-zA-Z]/g, "_"),
    // Replace multiple underscores with just one.
    ret = ("ID_" + group).replace(/_+/g, "_")
            .replace(/[_]+$/, "");

You can see on line 3 no comma is needed, because I just split up the chained calls for better readability. This may mislead the one who wants to understand the code. On the next line though a comma has to end the line because it is the end of the variable declaration. Additionally the code above has a comment after each variable declaration, which makes it easy to read and can be understood faster. If that was not the case it would be much harder to read the code. Just remember the one reading the code doesn’t want to read every line carefully, this is just very very time consuming. Therefore following certains rules can help to make this easier.
Another issue this code shows very well is that you first have to scan the code and understand the indentions, this sometimes means reading all the way up to the first variable declaration. It’s just unnecessary brain work.
So let’s make the source code easier to read, use a var statement for every variable:

1
2
3
4
5
6
7
8

// DO
var g = this.getObject("group.name", test) || groupName,
// Trim and replace all special chars, to have a proper test ID.
var group = g.replace(/^\s*/, "").replace(/\s*$/, "")
             .replace(/[^0-9a-zA-Z]/g, "_");
// Replace multiple underscores with just one.
var ret = ("ID_" + group).replace(/_+/g, "_")
             .replace(/[_]+$/, "");

This also makes understanding the indentions much easier. Doesn’t it? I just looked at the draft of this blog article and thought that the “wrong” source code above was wrong formatted because I didn’t understand the indention just by looking at the code (without thinking too much). Looking at the “fixed” source made my brain not start to think, it just looked all very clear to me.

In another real life example it took me three hours (three fucking hours) to find the bug. It was the following code in the dojo-mobile build script you can find on github. And I was debugging the code, reading it over and over again. I just didn’t find the bug. Try the following, scan the code quickly just once and read on.

1
2
3
4
5
6

// DONT
var parts = feature.split("-");
    ns = parts[0], // The namespace of the feature, like "oo" in "oo" or "oo-declare.
    f = parts.length>1 ? parts[1] : null, // The exact feature if given ("oo-declare").
    ret = [],
    data = globals.profileData;

Did you see it on first sight? Scan the code again. Believe me I read the code over and over again, I even thought there might be a variable declaration issue. But since my return variables are always named “ret” and my code was heavily asynchronously programmed I didn’t find out which declaration was the faulty one. It is fixed now (on github)!

1
2
3
4
5
6

// DO
var parts = feature.split("-");
var ns = parts[0]; // The namespace of the feature, like "oo" in "oo" or "oo-declare.
var f = parts.length>1 ? parts[1] : null; // The exact feature if given ("oo-declare").
var ret = [];
var data = globals.profileData;

Yet another example. This one actually just proved again that I definitely have to forget about the old way. You can also find it on github and feel free to follow the path of commits. My learning curve, if you will :).

1
2
3
4

// DONT
var depsData = _depsDataStack.pop(),
    dir = depsData.directory;
    file = depsData.file;

This one was not so hard to find, I agree. But still it was a bastard and stole my time. By sticking to a better convention I could have avoided it. Lesson learned.

Closing Thoughts

Just when preparing this article (which was supposed to be much shorter) I read through Douglas Crockford’s JSLint rules and funnily I found this one in there:

It is recommended that a single var statement be used per function.

I can say I disagree and I guess I gave some reasoning.

Though on the other hand I found this on the Crockford pages :)

It is preferred that each variable be given its own line and comment. They should be listed in alphabetical order.

Performance-wise, as stated above, I would leave the task to a compiler or alike tool to concatenate multiple variable statements into one, if it has an effect at all. The productivity and happiness of the programmers and not to loose time which could have been saved by just sticking to a simple convention is worth a lot more than pre-optimized code.
I am looking forward to feedback.

Is the app store concept flawed?

Lately I have been reading more and more articles, tweets and blogposts stating their concerns about the fact that Apple almost randomly removes applications and that people for some reason have distorted views of the mobile application and app store reality.

I am not in favor of allowing any kind of application into an app store by default, there is no reason why you should have to do that (a bakery also selects which producs it wants to sell). The problem really is though, that Apple is running the only official app store for the iPhone. One app store controlling the entire market for a device is plainly wrong!

Not only does it cripple innovation but it also shows one major flaw of Apples strategy – the factor of competence. How on earth does Apple, a hardware and software manufacturer think it has the competence to judge whether an application should be admitted or not? Maybe in these days when mobile applications don’t go further than simple games or information display/exchange – but what if applications are starting to come with real security implications?

An example:
Imagine you are writing an application reading your heartrate and writing an ECG (This is not too far fetched, look at our research project HumanApi). Is Apple seriously trying to tell that they can judge whether such an app should make it into the app store or not? They by far don’t have the competence of the medical industry, no way!

A much more interesting app store concept would be to have certified stores by companies I trust (or community driven in other application use-cases). Looking at the medical example, wouldn’t it make much more sense if companies like Siemens, Phillips, and other medical device manufacturers start an alliance and run their own store, so I can trust the apps I am using, so that as a developer, I know that qualified people are judging my application? Not only would this guarantee much higher quality but it also would foster competition which we are lacking here.

Companies == lemmings?

Where does this “I need an app as well” come from? Why do people care so much when their application gets rejected by the Apple app store?

An example:
On february 23rd, large German online publisher Spiegel Online wrote an article about the fact that Apple might disapprove an application of the famous yellow press publisher “Bild“. On february 24th they posted another front-page article questioning whether legal means would be the only way to go?!?

Now that is insane, not only will it cost those folks a lot of money to run law suits against Apple, on top of that they are forcing their way into technology without future – already today, the Apple app store is not the only way to legally distribute your applications to the iPhone! Apple is a new player in the mobile industry and albeit its amazing achievements, never forget looking at marketshares.

To summarize: For whatever kind of reason, one of the biggest German online newspaper sees Apple rejecting applications as being threatening enough to write an article – how more blatantly can the reality be distorted?

What can and should we do?

Back to the surprising incident I was mentioning earlier: When the folks behind http://www.yourappshop.com showed me their application store – for the iPhone! – one thought came to my mind “Does the Adult Industry point the way (again)?” (whether you and I approve adult content or not is a different discussion, what we need to take out of this is the fact that they are showing a very viable way to go).

YourAppShop developed an app store entirely based on web technologies (lots of HTML5 which is supported by the iPhone browser and many many more devices) – which allows you to download web based applications to your homescreen, watch image slideshows, even videos. Everything works off- and online. To the well traveled mobile web developer all of this is nothing new, it is all part of HTML5. The folks of YourAppStore though were creative enough to build it so that the end-user does not feel the difference between a real native app (from the Apple store) and an application based on web technologies, payment for the service included!

Why don’t people (especially the folks in decision making positions) see that you can write amazing applications for the iPhone based on technology which also will work on other phones and which does not have to pass the QA of Apple?

If you are not too bothered about adult content (NSFW) take a look at http://www.yourappshop.com from within your iPhone browser and visit one of their stores – the way they have set up a viable ecosystem using web technologies will give you a new impression of what we actually are able to do today.

As much as people might have concerns with the adult industry, they are showing us how we can get out of the app store restrictions – technology of today can be used to write successful applications and you can be monetizing the potential (more than 8.000.000 downloads for YourAppShop should say enough), Now that sounds great doesn’t it @Bild.de and @Spiegel.de?

And as if its not enough, Apple itself is showing a great example of the potential of web applications running on the iPhone with their online help: http://help.apple.com/iphone – go visit their site, and add the application to your homescreen by clicking on the “+” button in the bottom toolbar (Not to mention the fact that iPhone applications where meant to be build using the web stack in the first place).

As an application developer/creator, your goal should not be to only run on one platform, unless you don’t care about having sustainable and solid business case or unless your target-group is only the group of iPhone users (which I can’t believe is ever true).

We showed that there is technology which allows you to write applications for more than one platform, technology which works whether there is an app store in between or not, technology which has a future, technology the web is built with – HTML/JavaScript/CSS or better, HTML5 apps. Use it and stop wasting time being afraid that Apple will ruin your business because they are rejecting an application – you shouldn’t have to care less!!

Conclusion

Jumping into the “We need to have an iPhone app” mantra without any second thought is very dangerous, its not good for your business. Analyze your requirements and check carefully if you can’t cover your needs with an application based on web technologies (which as we proved still can make it into the Apple store if they approve of your content). The advantage of applications based on web technology is overwhelming:

• Standardized technology stack (HTML5)
• HTML5 apps work in mobile browsers, can be distributed over app stores or even can be integrated into traditional websites.
• Much lower development costs.
• Huge amount of target platforms

Of course there are application cases where you need to access the devices hardware in ways the browser doesn’t yet allow you to (games or applications with extreme performance requirements for example) – but especially publishers and content driven apps should think twice.

If you are looking into building a mobile application and are not sure whether you should go for the native iPhone, native Android or any other native platform (and spend tons of money on it) or whether you should build on top of the much more open technology stack of the web, feel free to contact us and we can take a closer look at your requirements.

Back to the folks who are planning to sue Apple (VDZ) – start putting your apples into the right basket, build a web based application store as you can see with YourAppShop and you will have complete freedom over what you want to sell and what not. Your customers won’t feel the difference, they might even like it more because you can offer better prices (no profit sharing with Apple). Sueing Apple won’t help a thing, don’t waste your money and time.

What is EventNinja?

EventNinja is our little ninja that goes out and collects events :-). Seriously: we had started uxebu with the high goal of playing with the best and knew from the beginning that we can reach out to the interested and passionate crowd just by meeting up with them personally, at the various real-life events. So we just needed to show up at the WebMondays and BarCamps around us. We started keeping track of them in a Google Calendar, which is publicly shared (you can find it here http://bit.ly/webdev-events), because we know that we are not the only ones interested in upcoming developer events. During a very busy phase during the summer of 2009, where a lot of dojo.beers took place around the world, the calendar already was of big use. We started to write a small web site widget to embed the calendar in our site. We had a very focused and content-oriented use case and after coming across W3C Widgets, we quickly decided to port the web site widget over to a W3C widget – the same night we had it also running on an iPhone. This got the ball rolling and we realized that we should start porting this widget to even more platforms. From thereon we felt confident that we are on the right track. And we shall be proofen to be right.

The base of it all: HTML (and W3C Widgets)

The web stack is the widest spread and most widely used technology stack. The number of developers using the web stack is just unbeaten. Now that the mobile phones are coming around the corner, we see that the diversity (others call it fragmentation) is just huge. The iPhone proved, that even a good browser on mobile phones done right, can be fun. So the web stack is coming to our phones. Browsers are a standard on the phone. And the potential is gigantic. “The mobile industry has now 4.6 Billion active subscriptions.” and “71% of all phones have a modern xTML web browser.” says Tomi Ahonen in The Big Picture “All the Stats” Total View to Mobile Industry, 2010 Edition. Enough to justify HTML as the future standard for mobile apps!

So we can surf the web. But what about app development? The iPhone requires you to learn Objective C, Android wants Java, Nokia S60 a flavour of C++, and so on. This sounds no fun. So just sum up one and one. Let’s use the web stack (HTML, CSS, JavaScript) that all the platforms bring along – since they all have a browser – and reuse this stack to build your native apps. It’s not as much magic as it sounds. There is even a specification for it, the family of W3C Widgets. W3C Widgets are self-contained mini-apps, consisting of HTML, CSS and JavaScript. Just as we know it from websites. If the widget requires no resources from the web it can even run offline. You have all the power at hand: JavaScript, AJAX, Canvas and depending on the platform you even get SVG.
But how many platforms do support W3C Widgets? In plain numbers: 4. But the number is growing. Vodafone360, Vodafone’s Nokia S60, the latest Blackberry and Windows Mobile. But that’s not all as I will explain later.
The biggest hype is made by Vodafone, definitely. They are also expressing strongly that they are supporting the open W3C Widgets standard. And it is true, take a real W3C Widget throw it on any of the newer Nokia S60 (Series 5) phones or the Vodafone360 phones and it just works. The next closest is Windows Mobile. For getting it onto a Blackberry you need to additionally sign the widget.

More devices: PhoneGap

Supporting just those four platforms would be a bit boring. But here comes the great open source project PhoneGap onto the stage. PhoneGap opens up all the other platforms. Among them, probably the one most people look for, is the iPhone. PhoneGap provides a web runtime which we just wrap around our widget and package it and we have a native app. PhoneGap even allows to access the native functionalities like Camera, Contacts, Acceleromter, GPS, etc. If there is something missing in the list, you are free to write the according adaptor. And the big advantage, since you are deploying the runtime with your app, you can even hook onto any kind of native interface available on the phone. This is very nicely shown in the ECG app @nonken has written in our uxebu labs. This app connects a heart rate monitoring device to your iPhone, all done through PhoneGap.

Porting EventNinja

So we ported EventNinja to the iPhone using PhoneGap. It was a pleasure to use all the features one of the most modern browsers support, stuff like CSS transitions and alike. And since a lot of people asked, I will answer the question before it comes up: “Yes, you need the iPhone SDK and therefore a Mac OS X machine”. But we will see what the future brings.

With EventNinja, we have also proven that such an app can be ported to the Android platform. We have tested it on Android version 1.6 through 2.1, among them HTC Magic, Motorola Droid, Nexus One. Android was the easiest platform to port it to, we “threw” the iPhone version onto an Android phone and it just worked, first as a simple website. Later, thanks to Manfred Weber as a native app and finally, as you can find it now in the Android Market, as a PhoneGap-based app.
For the Palm Pre we adjusted the style to look as native as possible. To our surprise Palm’s operating system WebOS, which itself is web technology based, has some very strange, proprietary touches which made it less fun than expected (read more in Mobile Cross-Platform Development: Palm Pre). From a bird eyes’ view it looks like porting to WebOS would not require anything, no PhoneGap, just wrapping the widget properly. Unfortunately it was more work than that. The proprietary concept of stages and scenes requires some workarounds to finally get the app running.

Cross Platform Advantages

Besides the simple obvious reasons, like easy porting, lower development costs, and that the web stack technologies are our core business at uxebu, there are other reasons that make cross platform attractive. Let me scratch the surface by mentioning some of them.

Easy prototyping. Using HTML, JavaScript and CSS a prototype can be created in no time, iterations, reconsidering various issues is way cheaper and quicker than doing it with other technologies. We can use the browser window, just size it down to match a phone’s screen size. We can debug and fix things without costly redeployment cycles and this entire process can happen remotely, it all works over the web. Not to mention that this is the easiest way to distribute your app, but that is a topic of it’s own.

Largest Reach, synchronously. We can reach multiple types of mobile handsets virtually at the same time. By reducing the need to redevelop the app for multiple devices, we can roll out to multiple stores and devices at the same time. We are basically limitted by the time that it takes the stores to run the app through their internal QA.
As the numbers in the December 2009 Mobile Metrics Report show we are covering the biggest smartphone platforms well. The iPhone is definitely the leading one (on admob) but we all know that Android is picking up speed, as shown in the Metrics Update: Android.

Multi Channel Distribution. A very interesting though still underestimated channel of distribution is what taptu called the mobile touch web. The app works natively in the browser, so there is no need to even install it locally (if no access to native phone ressources is required). This opens up the opportunity for other apps or (mobile) web sites to directly link to and still allow for a (close to) native experience for the user. If you have an iPhone, Android or just a WebKit-based browser (even on your desktop) you can try out the EventNinja web app at http://eventninja.net/webkit.

The App Store Experience

Above I listed some cross platform advantages. And I would like to pick yet another one and focus a bit on it. The various App Stores. They do not only bring the burden to have separate upload and QA processes for each (which to solve could imho serve as a business model itself) but they also allow the user on the various device to find the app. What do I mean by that? Well, simple: The app store is a very prominent way to find very focused, use-case-centered information, services, in short: apps, for your phone. It could also be seen as the pre-installed search engine and payment gateway on your phone. All the handset manufacturers, operators and a lot of service providers are setting up or already running their own App Store, their portal into the world of apps. And deploying your app to many of them, allows to create multiple ways to retreive your app, across multiple networks, stores and devices.

Sounds crazy? Yes, it is. I am not a fan of all the App Stores, but that is the current trend. Let’s ride the wave, and be prepared for the next one, which will hopefully be the pure web apps, running in the browser without the App Stores inbetween. We are prepared. And a little band aid, to make it easier to put up with the multiple stores: there are services that will leverage this problem and aggregate the statistics from the various stores.

Conclusion

With this article we are showing very important aspects of the mobile web and that all this is no dream but reality. Go to your store and download EventNinja to see it yourself!

If you want to bring your product or website to several mobile platforms to gain most possible reach, feel free to contact us to discuss your specific needs.

Disclaimer: We are working for Vodafone in their Widgets Department.

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

You can signup here:

This time we combine the official “Dojo Developer Day”, that is held online, with an on-site event in Munich.

The “Dojo Developer Day” is the last day of the first Dojo conference called dojo.connect() that will be happening 100% online. So if you want to get some deep insight and want to learn from the Dojo pros I just can recommend to signup for that conference.

dojo.connect (February 10–12, 2010)

Additionally, at the event in Munich you’ll have the chance to meet Dylan Schiemann (co-founder of Dojo and CEO of Sitepen), other european Dojo developers, and of course the whole uxebu team in person. During the event we will connect to all other worldwide spreaded Dojo developers via videoconference and you can participate in the discussion about the future of Dojo.

Because the “Dojo Developer Day” mainly takes place in the US, the on-site event in Munich will be from 3pm to 11pm. You would help us with the organization, if you signed up to the event through EventBrite. You can sign up to the event for free or for a small fee of € 30,– to support the Dojo Foundation. You can choose :)

Thanks to Nils Hitze for organizing the event and the EineWeltHaus for providing the room and food for all the Dojo enthusiasts.

Get started

The first one serves as an eye opener. If you are a long-time and experienced JavaScript hacker you will know how this works.

1
2
3
4

for (var i=0; i<Infinity; i++){
  if (i==47) break; 
}
console.log(i); // 47

In line 4 the number 47 is printed into the console. Even though the variable “i” has been declared inside the for-loop. Yes, it does, believe me. There is only one thing in JavaScript that creates a scope, it’s the function (in strict mode in ECMAScript5 there are more ways though). The code you put inside function(){…} does get it’s own scope, though with the access to it’s surrounding scope. Btw, this is also why you very often see the “self = this” quirk.

The actual “problem”

But let’s get to the actual code, that lead me to write this blog article. I love those tricky things, that give you insight into the language and sometimes make you read the specification. I guess JavaScript is the language where the ratio of “just-users” to “people who really understand the entire language”, is very high. I would not consider myself to understand the language entirely.

Consider the following code.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

var i = 47;
console.log(i); // 47
 
function test(){
  console.log(i); // undefined
  i = 1
  console.log(i); // 1
  console.log(window.i); // 47
  if (false){
    var i = 0;
  }
}
test();
 
console.log(i); // 47

Note: Testing this will only work in the browser, not in the console, since “window” is only declared in the browser context!

The most interesting part is definitely line 5. I will dive into it deeper later. Line 7 and 8 show that we are operating on two different variables, both with the name “i”. The one printed out in line 7 and the one printed in line 8. The variable referred to by “window.i” is the one we declared in line 1, this is no suprise. But that the assignment in line 6 didn’t override the value of it with 1 is interesting though, right?
Let’s break it down a bit further.

1
2
3
4
5
6

var i = 1;
function test(){
  console.log(i); // undefined
  var i;
}
test();

This is the essence of the code above. Even though the variable declaration takes place in line 4, after the console.log() call, the variable is already declared when console.log() is called. It is not referencing the global variable with the value 1 though!
After reading through various parts of the ECMAScript specification, this might be the one that indirectly says that this is specified as stated above:

For each VariableDeclaration and VariableDeclarationNoIn d in code, in source text order do …

ECMAScript Spec (version 5), section 10.5, page 59.
This is from the section that explains how to setup bindings and knowing that a VariableDeclaration is “var i” this can be understood as: upon creating a function do just the variable declarations found in code.

What the heck? Ok, let’s approach from another angle, which I find even more interesting. It is the fact, that the statement “var i = 0″ is effectively broken apart in the following code:

1
2
3
4
5
6

var i = 1;
function test(){
  console.log(i); // undefined
  var i = 0;
}
test();

On line 3 it will still print out “undefined”, because the interpreter did find the variable declaration in line 4. We know that because it prints “undefined” and not 1. But it did not do the variable assignment, which is also contained in line 4. So it actually broke apart the code on line 4 “var i = 0″ into 1) “var i” which it executes when creating the function and 2) the assignment “i = 0″ when the execution comes to line 4.
The ECMAScript Spec (version 5) states the separation of those two cycles explicitly too, page 87:

A variable with an Initialiser is assigned the value of its AssignmentExpression when the VariableStatement is executed, not when the variable is created.

Get trapped

In our actual example above we had another nicety, which I will try to dissect in the following examples:

1

console.log(i); // ReferenceError: Can't find variable: i

This will throw an error “ReferenceError: Can’t find variable: i”. Though

1
2

console.log(i); // undefined
var i;

will not throw an error, it will print “undefined” peacefully, we know that and have learned that before and read that in the spec too. (Just wanted to make it clear again :-))

But if we do the following

1
2
3
4
5

console.log(i); // undefined
i = 1;
if (false){
  var i;
}

we still get “undefined” in line 1. Ooops. Did you expect that? Does the “if” in line 3 not nest the variable declaration and create it only inside the scope of the “if”? No it doesn’t. As mentioned before, there is only one thing that creates scope, that is a function. So even, this meaningless condition is relevant here.
It would be interesting to test what JavaScript compilers, like shrinksafe and Google’s closure make out of it. If the removed the code from line 3 through line 5 than this would change the semantics of this code dramatically.

Have fun playing around with this code and twisting your brain.

Testing on the console

Please note! Watch when just copy+pasting the code above into the console of your browser, they have each different behavior depending on which browser you are using. If you always wrap the code in an extra (function(){…})() you will be save, but otherwise the console will give you differing results. Or, the best way, is to put the examples in a website to test it.