Recently the new WAC 2.0 Spec got out and it’s looking good.
Compared to WAC 1.0, the WAC 2.0 Spec is a shift into the right direction:
Instead of inventing new APIs, WAC 2.0 adheres to web standards like HTML5 and W3C Widget Packaging.

Let’s compare the two major spec revisions in that repsect:

As said before, the WAC 1.0 Spec described distinct APIs, e.g., for audio, messaging (SMS & email), camera and geo-location.

Taking photos, for example, involved assigning a callback to a global value inside the Camera object and invoking Camera’s captureImage method.

There’s a problem with that: What if two pieces of code both assign their own callback to that shared value?
The one which assigned its callback last will be executed. The first callback is “dead code”.
Of course this can be remedied by the app developer, but I believe it’s the library’s job to get something as essential as deferred execution right.
All WAC 1.0 APIs use this global callback model and inherit the problem.
There are better, more elegant ways to defer execution (e.g. dojo’s Deferred or node’s callback passing & EventEmitter).
And fortunately, WAC 2.0 replaced the old model with a callback passing approach.

If everything goes well, what could WAC provide developers with?

1. An easy way to package web apps “for home screens & app stores” by wrapping web apps in native container apps.
2. An extension of browsers’ capabilities to enable richer web apps. This includes APIs for camera and file access.
3. In contrast to alternatives WAC has a strong focus on carrier network APIs. This could enable purchase through carrier billing.
4. A security model to effectively protect user’s privacy and security.

So go ahead and look at what the new WAC 2.0 has to offer.
I’m excited to build apps with it once it’s running on some major platforms!

To conclude I’d like to end this post with my personal opinion on what I believe WAC needs to focus on to succeed:

1. WAC runtimes have to run at least on iOS, Android and a few other major-marketshare platforms. There’s no point in developing cross-platform web apps if you ignore major platforms.
2. WAC’s marketing & identity need to be more developer-centric. Different top-notch WAC runtimes need to be advertised by WAC. Ideally there would be an official runtime for each platform.
3. Apps built on top of WAC runtimes have to be compatible to major app stores. For example, imagine a developer is targeting Android and iOS. What if Apple rejected WAC-based apps because of, e.g., a bundled custom WebKit build? I’m pretty sure no sane developer would consider WAC if that effectively banned their app from ever going into the most profitable app store. And while there will be carrier-operated stores I am not overly confident in that. Human beings simply prefer one familiar store/market on their phone.
4. Web app developers want their code base functioning consistently across multiple platforms with little or no effort. This implies that different WAC runtimes should strictly respect the specification. If there are implementation differences it’ll result in multiple code branches in the app code to repair broken implementations. Well, if WAC wants to succeed this must not become an issue for the app developer! Most apps are going to need custom code to support physical device differences. So hey, it will be incredibly helpful if the basic APIs were consistently implemented! Please don’t screw this up, because I somehow doubt someone would develop a cross-WAC-platform JavaScript framework.
5. WAC 2.0 runtimes with the above properties should appear very soon. They also need to be advertised in an easy to understand manner.
6. WAC should stick to W3C specs & drafts for APIs. If an API becomes part of a given platform it should be removed from that platform’s WAC runtime. Think back to when Google removed Gears support from their own browser to make way for standardized APIs.

First I want to thank RIM for sending us two Torch devices. Right away I navigated to the embedJS tests and I didn’t expect it differently, the tests passed without any problem, 100% passed tests. Actually I expected the tests to pass lightning fast, the time it took was ok, but not lightning fast, unfortunately. The test suite executed in about 14 seconds, on the iPhone4 it took about 10. To be fair the processor power and the system architectures are completely different and not really comparable, but the user experience counts in the end. We have heard that the RIM guys are hard working on improvements and speeding up the device, there is some cool stuff to come.

WebKit and WebWorks

The most impressive and revolutionary thing was definitely that BlackBerry brings an 100 points ACID compliant WebKit and runs W3C widgets using it. So there are by default two ways that are even fun to get content onto this platform. You can write mobile websites expecting an a-grade browser and you can write apps, for the so called WebWorks platform (which are W3C widgets inside). All we want. The browser supports CSS transitions and transforms, not 3D though, since there is no GPU in those devices, but you never know what might come next. There is SVG on it, WebSockets, Canvas and a lot more niceties, I just browsed the objects using Object Browser, go try it yourself, on your device.
RIM renamed their widgets that existed already on BlackBerry5 to “WebWorks” and they got completely overhauled. The approach RIM went is pretty close to how PhoneGap works. WebWorks basically is a wrapper written in Java (the native language of BlackBerry) which internally instanciates a WebKit view and provides a bridge into JavaScript where the underlying native functionality is written in Java, of course. The cool thing about it is that this code is completely open source and on github. Unfortunately the build scripts are still not on github, so you would still have to figure out yourself how to use the source from github to package your apps. RIM please push them soon! Currently the executables are the most comfortable way to build your widget.
Back to the API, since the implementation is open source you can easily extend it and make functionality available into JavaScript which currently is not there. So Nikolai’s robotic JavaScript will really become fun and reality on BlackBerry too. Why RIM went this way becomes very obvious when you understand the security concept on BlackBerry. Since all APIs are, in the end, provided by a Java implementation and only “piped” into JavaScript all security restrictions apply to the widget just as if it was a native app. That means if you access GPS in your widget (using JavaScript) the Java function will be called and will be secured the same way as if it would have been called from within a pure Java app. Of course this doesn’t make your widget secure by default, since you are using web technologies you have to take care of writing apps which are not vulnerable by XSS attacs or alike. But it offers really comfortable extendability for this platform and is no workaround to get web technologies onto BlackBerries, I think it’s a very clever approach, good job RIM.

Security

Everybody knows the ridiculous installation dialogs on Android which show you the APIs the app wants to access and the final question if you want to allow the app to access this functionality or not. If you say “no”, the app won’t install. That doesn’t really make me feel that the security concept is very flexible. It’s not giving the user a lot of control. Working with Opera’s widget runtimes already for a while I thought of a concept that would allow a lot kore control for the user and make apps hopefully more successful.
I will use a short example to explain it. Imagine a twitter app that you want to install and that has a lot of functionality but on the first install you only want it to be able to go online to read and send tweets. Functionality like GPS, searching my addressbook or taking pictures with the camera are built in into the app. But as long as i don’t trust the app i don’t want this functionality enabled. So I turn of access to certain APIs upon installation and enable them just when I feel secure and gained trust in the app or had been told by experts that the app is secure. But this is currently not possible on platforms like Android or iPhone. I talked about this idea and told RIM’s Tim Neil about it, in the hope to meet open ears and confirm that this is a good idea. The answer I got surprised me big time: BlackBerry already has this for a while. We got out our Torch devices to look it up, and yes in the menu under “Device / Application Management” you can edit the permissions per app (see picture). Awesome and just right, I love this.
So Opera this was my idea to improve your widget runtime and maybe to jump ahead of the crowd again, I would like it.

Overall the BlackBerry6 platform is very exciting and a lot of thought seem to have gone into it, especially with focus on the web, which is a really good thing. So, I will just step away and try to build the Object Browser as a WebWorks App.

“Modern Company” session – uxebu as the example

But before I dive into the tech sessions I would like to mention that I really felt the need to hold a session which I had called “Modern Company” where I tried to show our philosophy at uxebu, how we work together, how we use the modern media, how it all came about and why we do it this way. First I didn’t know where to start. Then I started to talk about when and how the idea for uxebu came about, that we decided online to found it and really met some months later. Thanks to our open source background and our history we wanted to continue the same spirit inside the company, I tried to show how and based on what facts we grow our team (the word “hiring” seems such a one-sided process). I realize now that I forgot a lot of the good stuff, but maybe this is the chance to make this become a separate talk to hold at other events.
I really loved the discussion and the questions that it had started, notes had been taken, a lot of critical questions came up and had been answered by Tobias and me. One interesting mentioning came up about an article which mentioned a company that pays the same salary to all employees. Thank you for all this input, I really enjoyed it and will definitely talk about this more and will prepare some more info next time.

JavaScript – a topic of big interest

We had founded uxebu purely for doing JavaScript consulting and pushing the limits and it is just really exciting to see how much interest this language is gaining in the last years. Not only jsconf the mother of all JavaScript events underlines this but also a lot of other conferences and events like fullfrontal, fronteers, js1k, 10k Apart, jQueryConf and so on which Béla Varga listed in his “JavaScript Rock’n Roll” session.
The “node.js” session and “JavaScript Rock’n Roll” (by Béla (@netzzwerg) and Tobias Schneider (@tobeytailor)) made it very obvious that JavaScript is a hot topic, the BarCamp was not necessarily overcrowded with programmers, but still those two sessions had been very well filled and the discussions had been really fun. The conclusion of the “node.js” session that Tobias drew and evangelized was “node.js is currently very hyped and just not yet ready for production, so use at your own risk, it’s not even alpha yet”. Everybody also agreed that node.js is not the new saviour and a replacement for Apache, it’s another tool you should add to your tool belt, use it when it comes in handy and be sure to know how and when to use it. Final conclusion was, as usual, if you should use it depends on what you want to do :).
Béla opened up the “JavaScript Rock’n Roll” session by giving a very good overview of what toolkits exist out there, who created them and what they are good for. He very well layed out some of the advantages and disadvantages, the rough corners and what is hard and what easy to learn. Shortly the discussion about the right JavaScript IDE came up but as usual there is no one-fits-all solution, choose yourself! Everybody was very carefully listening when @tobeytailor dove deep into the details of ECMAScript, JavaScript, the differences, the latest specification, the changes, prototypes, __proto__ and so on. Other interesting topics in those sessions had been promotejs, vapor.js, details about storage mechanisms, jQueryMobile, embedJS, apparat.io
That was real “JavaScript Rock’n Roll”!

Native vs. Web

On Saturday, the first day of the BarCamp, I had offered a session “Mobile: Native vs. Web” but didn’t see too many hands raised, so I just didn’t put it in the schedule, later some people asked me when this session would take place and that I should hold it on Sunday, which I fortunately then did together with Florian Detig. And I have to say I am very glad we did so, because 1) we (at uxebu) have a lot of awesome stuff to talk about and 2) it was really fun interacting with the audience and passing on all this information. It is always amazing again how much there is to say about how to create an app which can also be submitted into any of the various app stores by just using web technologies (the adult industry proved that again). HTML, CSS and JavaScript are just way to underestimated for being of good use in the mobile world. Florian first showed his awesome slides (I think they are really cool!). I continued the talk and dove a bit deeper into the mobile web topic, after my try of explaining the different movements in the native API space with players like W3C’s DAP, BONDI, JIL, WAC we deeply went into answering and discussing web technologies on mobile devices, I talked about our experiences, showed some projects we realized and answered a couple questions.
Not really a surprise but still impressing was the positive feedback we got when I showed of apparat.io, our soon to be launched service that will be able to convert a web app into a native app (You want to know about it first – follow @apparatio). The release date for the private beta will be the 25th October 2010, people who follow @apparatio will get accounts first. I also showed our project embedJS a toolkit (based on dojo) optimized for mobile usage.

All in all the BarCamp just made it obvious again that we are playing in an very interesting field and that we at uxebu are pushing the limits, that is fun, as much as the BarCamp was big fun, we will be back next time, for sure!
Thanks again and keep up the good work!

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.

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.

The day started as planned with coffee and snacks and a Dojo introduction giving everybody who wasn’t really familiar with the Dojo Toolkit a better idea of what it actually is. A few demos such as xRay where shown to show some of the advanced features of Dojo such as live charting, custom themeing and much more.
After a short break we continued with a talk on how to design mobile architectures with the Dojo Toolkit for platforms such as PhoneGap, W3C widgets and other mobile platforms supporting JavaScript/HTML and CSS. This is a very interesting topic and it was great to share the experience we made at uxebu on finding viable solutions for the challenges we face. The third talk was a quick overview of the current documentation efforts for Dojo and different ways of finding the information you need when you are stuck or simply looking for API docs or similar.
Before the break, Tomer Mahlin from IBM in Jerusalem, who is working on the BIDI implementation in Dojo, gave a very interesting talk on the challenges, developers face when writing applications supporting BIDI. Not having to deal with the issues you get confronted with when having to develop BIDI applications, this talk was eye opening and very interesting.
After a great lunch we jumped into a hands on session building a very simple mobile app running on both PhoneGap and devices with a widget runtime supporting W3C widgets installed. This gave the audience a glimpse into mobile development and the challenges but also really exciting features.

In total there were about 45 people attending the event which is an amazing amount of people for such a first time event, thanks again to everyone attending and especially to Yoav Rubin and the folks at IBM to make this happen.

I am already looking forward to the next Dojo event in Israel and hope that we can be part of it again.

Following are the slides to give you a little impression of the events content.

The topics covered at those three conferences are not as bleeding-edge as we like them to be :-). But this is ok, since it is a more business-oriented conference. Though there are quite some old facts around and the mobile world just moves much faster than some of the talks at this conference do. It was also funny that relatively old facts e.g. about the features and some of the fun apps that exist for the iPhone still seemed to amuse the people.
But probably the worst fact about this conference is that there is no free WLAN, you have to pay 24€ for 8h, and that is the Internet World Congress? Hallo? Sorry, but this is really not state of the art, I hope the discuss&discover will do better there.

Rely on Cloud Service?

I just heard that google analytics was guilty for bringing down pages like bild.de for a day. Because the page relied on google analytics to be loaded fully, but due to the down time of this google service the page never loaded in the user’s browser. Sorry, but in this case the solution is not the SLA or kicking out the JavaScript, just look at the Dojo module dojox.analytics, which Pete Higgins wrote and which does what should be done in this case, load the script after the relevant content was loaded, asynchronously. So please make the developers responsible, not the service provider. If you are relying on this service, make sure that failure is a case you planned for. Don’t use the cloud if you don’t know what the implications are!

W3C widgets

Since Mobile Vision is one of the conferences and we are also active in the mobile space, I need to state that the W3C widgets, as e.g. Vodafone is already pushing them, had been very much ignored here. How much (mobile) vision do you get here?
Read the Introduction to W3C Widgets by PPK to get an overview of what these things are. So let me just summarize the advantages and differences of W3C widgets compared to the usual native apps.

• Allows deployment to multiple mobile platforms (and the browser of course too)
• Rapid prototyping is much faster and cheaper
• Uses the standard technologies HTML, CSS and JavaScript
• Therefore a much larger potential developer base

Of course there are new things to consider. You need to learn about the distribution ways (AppStores, etc.), how to deploy and you mostly have to sign your apps. But all those things easily outweigh the pains you need to go through when learning all the native technologies.

Well, maybe we are too spoiled from conferences like Ajax Experience, Ajax in Action and Mobile2.0.