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.

Background

Developing applications for mobile devices using HTML, CSS, and JavaScript is possible through different runtimes and frameworks. On Nokia devices, you can use the Vodafone Apps Manager (a runtime for W3C widgets) as well as Nokia Web Runtime (Nokia WRT). PhoneGap is a framework that allows building of applications for iPhone, Android, Blackberry, Windows Mobile, and Nokia WRT with web technologies. On all of this platforms you basically throw in a base HTML file (e.g. index.html) that contains references to scripts and stylesheets. Easy, isn’t it? But not on webOS …

webOS

webOS uses a concept of stages and scenes. A “stage” represents a card (similar to a window in desktop operating systems), whereas a “scene” can be imagined as a layer on a stage. Each stage consists of a stack containing at least one scene. While I really like this concept, I am of the opinion that using this model shouldn’t be obligatory. It provides an elegant possibility to develop webOS based GUIs, but gets in your way as soon as you want to deploy your app on different platforms. All porting issues pointed out in this post arise from the stage/scene model.

First Try

When trying to repackage a W3C widget for webOS for the first time, I used the palm-generate command line tool to create an empty app skeleton and copied the source code into it. After packaging with palm-package and deploying on the emulator I was happy to see that everything seemed to work just fine. Far from it!

Issue: Scrolling

When simply converting a W3C widget (or any browser-based application) to a native webOS app you will notice that everything works fine except for scrolling. If the contents of the application are longer than the viewport, they are simply cut off, and scrolling isn’t possible. To enable scrolling in webOS it is necessary to make use of a mojo-scroller Element (“Mojo” is the name of palm’s framework). The easiest way to achieve that is to “push a scene onto the stack”:

1. Include the mojo framwork into your HTML file by adding a script tag before you include any other scripts or stylesheets:

   <script src="/usr/palm/frameworks/mojo/mojo.js" type="text/javascript" x-mojo-version="1"></script>

   Mojo will add a whole bunch of webOS-specific stylesheets to your application. If you like, you can use the classes defined there to achieve a more “native” feeling by using palm-specific classes.

2. If you created the app skeleton with palm-generate you will find the constructor StageAssistant in the file app/assistants/stage-assistant.js. An instance of StageAssistant will be generated automatically on application start, and its setup method will be called. Add the call this.controller.pushScene("main"); to the empty setup method of the prototype. This will create a new scene called “main” (which is a set of div-Elements inserted into document.body).
3. Generate the scene skeleton using palm-generate:

   palm-generate -t new_scene -p "name=main" <app-dir>

   When “pushing” a scene, the corresponding assistant is being instantiated, and the contents of the scene’s main view file are made visible (while everything else is hidden behind the newly created scroller). The two files are app/assistants/main-assistant.js. and app/views/main-scene.html.

4. The last step is to transfer the DOM/HTML of your application into the scene. My approach is to remove all DOM nodes from document.body and reinsert them into the scene element. It is also possible to use innerHTML, but already registered event handlers will be lost. Change the setup method of StageController to:

   StageAssistant.prototype.setup = function() {
   	var body = this.controller.body,
   	    fragment = this.controller.document.createDocumentFragment();
    
   	while (body.firstChild) {
   		fragment.appendChild(body.firstChild);
   	}
    
   	this.controller.pushScene("main", fragment);
   }

   The second parameter passed to pushScene will be passed to MainAssistant as soon as it is instantiated.

   To reinsert the nodes into the DOM change main-assistant.js to:

   function MainAssistant(nodes) {
   	this.nodes = nodes;
   }
    
   MainAssistant.prototype.setup = function() {
   	this.controller.sceneElement.appendChild(this.nodes);
   	this.nodes = null; // unset to release references
   }

   This way, your original nodes are transferred to the visible and scrollable “main” scene. Don’t forget that any CSS selector like body > .foo will stop working as intended, because your DOM is wrapped by two additional div elements!

After these steps, scrolling finally works in apps ported to webOS. The code shown here is very generic. It can be used for every application. You should be aware that scrolling via window.pageYOffset is not possible, because the scrollable element is the mojo scroller, not the body element.

Event listeners

Developers who like registering event listeners on document.body will notice that those quit working after cut’n’pasting the DOM nodes to the scene elements. The reason is simple: in webOS, events only bubble up to the scene element (the inner one of the DIVs mentioned above). Simply don’t do that. And if you are using jQuery’s live(), stop using it. Sorry. Don’t blame it on me.

Scrolling, Part Ⅱ

Everything seems to work pretty well now, right? Well, there’s one more thing …

When you scroll (or drag) your app, and stop dragging above a clickable element, that element will be clicked. It took me quite some time to figure out the reason, because the same HTML/JavaScript will work flawlessly in the browser built into webOS. You need to listen for the “mojo-tap” event rather than for the “click” event. The “click” event will be fired after a drag has ended, but the tap event will only be fired when a “true” tap has taken place. I really can’t understand why it has to be that way, and if it wouldn’t have been easier not to alter the default behavior of WebKit.

The method I’m using is to have a variable containing the name of the event to bind to. That way, an application can still run on different platforms:

var myapp = { CLICK_EVENT : "click" };
 
if (typeof Mojo != "undefined") {
	myapp.CLICK_EVENT = Mojo.Event.tap; // contains "mojo-tap"
}
 
/* snip */
somElm.addEventListener(myapp.CLICK_EVENT, function() { /* … */ }, false);

Why?

When I was hearing about webOS for the first time, I really looked forward to have “it [the Web] as the SDK” of the OS (quote from Dion Almaer). And while the SDK offers some nice features – like the stage/scene architecture – it really gets in your way as soon as you don’t want to code exclusively for it. Unfortunately, you don’t have any choice, say some sort of “compatibility mode” to the web (couldn’t resist this one). You have to bend to webOS and stick to its rules.

Apparently Palm is working on better compatibility. On Ajaxian you can find an article stating that “The company [Palm] is involved with the BONDI and W3C widgets standardisation effort” (quoting Ben Galbraith and Dion Almaer). Honestly: Shouldn’t somebody have considered that in the first place?

To me, the web is a universal platform. We’ve had many issues with proprietary “solutions” in the past millennium and still have them. I don’t like seeing proprietary features being introduced once more. It is obvious that functionality of the operating systems must be accessible in some way. But does that imply breaking things that have worked before?

I would love to see the possibility of making simple applications run on webOS without too much efforts. At least it should be possible to run W3C widgets without big hassles.

Sometimes one might be supposed to think that Palm isn’t really interested in compatibility. The acceptance criteria of their “App Catalog” state that “They [the applications] need to be written specifically for webOS and not delivered through the browser.” Whatever that may mean.

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:

background: #b0b0b0 url(box.png) no-repeat scroll -15px -1px;
border: 1px solid #4a4a4a;

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.

.transition {
	transition-property: width;
	transition-duration: 250ms;
	-webkit-transition-property: width;
	-webkit-transition-duration: 250ms;
}
 
.transition.clicked {
	color: #0f0;
	width: 270px;
}

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.

border-radius: 15px;
-webkit-border-radius: 15px;
-moz-border-radius: 15px;

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).

.border-img {
	border-width: 15px;
	background: #ffffff;
	border-image: url(box.png) 15 stretch;
	-webkit-border-image: url(box.png) 15 stretch;
	-moz-border-image: url(box.png) 15 stretch;
	padding: 0;
}

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 (-webkit-gradient) for the background:

background: red;
background: gradient(linear, left top, left bottom, from(#666661), to(#b0b0b0));
background: -webkit-gradient(linear, left top, left bottom, from(#666661), to(#b0b0b0));

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:

background: url(box.svg) -15px -15px repeat;
border-image: url(box.png) 15 stretch;
-webkit-border-image: url(box.png) 15 stretch;
-moz-border-image: url(box.png) 15 stretch;

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.