Why you’d like to use HTML5 audio in iOS 5

It’s all about apps these days. The question is whether you want to make the commitment and investment (of learning a new language) to program natively for one platform or leverage the web dev skills you already have? HTML5 is the way to go if you sympathize with the latter.

Let’s face it: The main problem for web developers that want to make apps is to deliver a great user experience. Hence, you’d like to use as much of today’s web technologies as possible to enhance the UX. One profound way of doing this is audio feedback. For example, many twitter apps use sounds if new tweets come in and another sound if no new tweets could be found. This kind of response is intuitive to the user. This is what you should go for.

Also, imagine a game without sounds. Would be kind of boring, wouldn’t it?

Naive Assumptions: What you’d expect

Fortunately in iOS we have rich HTML5 support built into mobile Safari. Initially, Steve Jobs wanted all apps to be web apps! So what you’d assume regarding audio is the presence of the HTML5 audio tag. And guess what, there is an implementation of the audio tag in iOS. Hurray!

So what do you expect from an audio tag implementation:

• call .load(), .play(), .pause() and other methods via JavaScript
• use remote files, dataURIs, cached files and other sources
• play several audio files / tags at once
• mix audio from several sources with different volumes, etc.

Reality checks: What should work but doesn’t

It becomes clear pretty fast that it’s not that simple. With iOS it’s a disaster. The bad news first:

It is not possible to load or play audio without user interaction.

Sad, but true. Apple deliberately decided that a touch event is mandatory to load and play audio. There is no workaround for this.

If we accept the fact that we need a touch event to play the audio, is it possible to use the audio tag as expected? Hmm, no, not really. So what’s broken as well?

Latency: Loading audio files on demand (after the touch event fired) is unusably slow. The desired user experience can not be achieved using this technique.

One audio tag at a time: You can never play more than one audio tag at once. This makes it impossible to mix sounds on the fly which would be necessary for games that have a background music and must also play sounds dynamically (e.g. when the character jumps).

Audio files only: You can not use anything as the source besides audio files (uncompressed WAV and AIF audio, MP3 audio, and AAC-LC or HE-AAC audio). If you could use dataURIs then it would be possible to preload the audio.

Workarounds: How to play anyways (at least somehow)

We invested a lot of time researching the audio tag on iOS 5. If you want to know how we play audio, read on.

So what do you do with this crippled audio tag? Well, you trick it a little bit and use it as much as possible. Here are several ideas that work best for different scenarios:

Bind touchstart event to body: As you have to play on a touch event, we bind a touchstart handler on the body. So wherever the user touches first, we can use this event to load the audio file. Even better, from now on, we can load and play different sources from this audio tag.

Hot swapping sources: We can now change the “activated” audio tag’s source on the fly. So it is now possible – without user interaction (!) – to load and play different sources. But you can only play one source at a time, of course.

Use audio sprites: The guys over at Zynga use audio sprites in their Jukebox. This means that you have a huge audio file containing one sound that you want to play, then one second of silence, then another sound and so on.

Example for a sound sprite structure:
1 second silence
First sound
1 second silence
Second sound
1 second silence
Third sound

In this file you include all the audio that you possibly want to play in your app. You only load the source once (as described above) and then jump to the relevant parts in the file. So the file is always playing but most of the time it just plays silence. When you need the sound, you can quickly jump to the part in the file that you need to play. This solution is quick (much faster than hot swapping!) but requires a long preloading phase before you can play the most sounds, because the file is bigger.

tl;dr

So audio in iOS is pretty much broken. If you are using a native wrapper like PhoneGap you could use native APIs via plugins like SoundPlug. We’ll try what is possible in the upcoming versions of iOS. Please let us know your ideas and feedback in the comments.

Update:

Regarding Philip’s comment, this is how we think it could be.

Modules

AMD stands for “Asynchronous Module Definition”. So, what are modules? I’ll quote the definition from the CommonJS Module specification, as it describes it very well:

This specification addresses how modules should be written in order to be interoperable among a class of module systems that can be both client and server side, secure or insecure, implemented today or supported by future systems with syntax extensions. These modules are offered privacy of their top scope, facility for importing singleton objects from other modules, and exporting their own API.

So, modules are isolated parts of code that live in their own scope and are kind of self-contained. Well, that is pretty much how we see the individual Features in EmbedJS – we made our feature implementations as small as possible and reduced dependencies as much as possible. Many of EmbedJS’ features are also browser-independent, so why not make it possible to use some of the tools in a non-browser environment?

(If you want to learn more on modules and why we need them, I recommend @briancavalier‘s presentation on modules.)

Features in EmbedJS

So far, I didn’t really explain what I mean with “Features”, so let me do another quote, this time from the Project Page:

EmbedJS uses the concept of features: Functionalities are split up into features, as fine-grained as possible, and each feature might have multiple implementations.

Our Features are kinda small and contain only few methods, sometimes even just one. The asyc-promise feature, for example, will get you Promises, and the transport-jsonp feature will get you a method for pull in data via jsonp – and that’s it.  If multiple methods are contained within one feature, this is because they are too closely related to each other to split them up, like the html-class feature, which contains the addClass, removeClass, toggleClass and hasClass methods.

AMD vs CommonJS Modules 1.1

Now that we knew modules were the way to go, there was another, quite important question to solve: There are two common patterns for modules, so which one do we want to apply? One pattern is described in the above mentioned CommonJS Wiki, the other pattern is described in the AMD wiki.

Well, there have been some blog posts lately that compare the pros and cons of each of them, so I don’t want to repeat all of this – but I’m hiving a similar tendency towards AMD. Besides this, there was another big reason to go with AMD: Remember, EmbedJS is based on the Dojo Toolkit, and it’s a Dojo Foundation Project – and we hope that the efforts that went into making EmbedJS might flow back into the Dojo Toolkit one day. And as the Dojo Toolkit uses the AMD approach, the decision was quickly made to do so as well.

Implications for EmbedJS

There are several huge benefits for EmbedJS in using the AMD approach. The most noteworthy surely is the ease-of-use for developers. In your code, when you find you want an EmbedJS method, you look up the feature name that provides this method, add it to the require statement and there you go. Man, easy.

A second important thing is that EmbedJS now plays really nice with AMD based projects. In fact, you could see EmbedJS now as a collection of small useful modules, that can be easily integrated – and also easily extended.

The third major benefit is that we can now get rid of all the custom tools we built around EmbedJS – you can load features with any AMD loader (though we use and recommend RequireJS) and build it with any AMD optimizer/builder (we recommend r.js).

Let’s have an extra word on

Building

It was always possible with EmbedJS to create a custom build that would contain only the features you wanted/needed in your project. But, you had to use our build tool that we created. And learning & using Yet-Another-Build-Tool™ is always… well, let’s just say it would be cool to avoid it (and, not to forget, so is maintaining it). We did a lot to improve that, we created a GUI that allowed you to just “click together” the features you wanted, and we worked on a dynamic loader that would ease development. But still, the situation was far from ideal, and people just ended up going for our ready-made “kitchensink” builds that contained all of the features.

Now, we still provide those ready-made builds that contain only the implementations for a given platform (and are stripped of require/define calls), but I really hope that using the AMD approach and using an AMD optimizer to deploy will become the more adopted style.

Q: Cross-target? A: The Feature Plugin

One goal of EmbedJS is to allow for easy cross-device development. We got rid of run-time branching but instead went for an approach that held the different implementations for a given feature in separate files, so that one only has to deploy the actually needed code to a given device – and not all the alternate implementations, that sit useless in the device’s memory and never get used. We needed to achieve that with “in-house” means provided by the AMD approach. Lucky us, there’s the concept of loader-plugins, and so I created a feature-plugin for AMD loaders. The idea is simple yet effective: You create an implementation map that maps a feature name to an implementation, and if there are multiple implementations, you supply tests that tells the plugin which feature to use.

When you’re ready to deploy, you have two choices: I f you really don’t know on what target your code is going to end up, you can use the dynamic implementation map containing the tests for the optimizer, and you’ll get a build that contains all of the available implementations. Then, during runtime, the feature plugin will run the tests and load the specific implementation. But, if you do know what target your code will run on, you provide a specific implementation map that doesn’t contain tests but directly maps to the according implementations, and you will only have those in your built file.

Synopsis

AMD is exactly what we needed to make EmbedJS more what we want it to be – an easy to use JavaScript toolbox that is especially handy for cross-target scenarios such as cross-platform mobile development. So, please don’t hesitate and check it out on Github, read the project page and check out the examples!

Resources / Further Reading

• EmbedJS on GitHub
• EmbedJS Project Page
• EmbedJS API Docs
• AMD-Feature plugin
• AMD Wiki
• CommonJS Wiki

Uxebu is now operating it’s business purely in the JavaScript space for about three years (oh that reminds me we should have a party!). We are convinced that JavaScript is ramping up now and we see that there are more and more things done and possible with the language. The browser landscape is developing rapidly and changing every day. The mobile industry is pushing the limits and we are helping to do our part in it. We learned a lot and are still learning. As it is in the nature of our company to spread our knowledge to allow everyone to use the technology at it’s best and push the limits with us, we think now it’s the time that we share our knowledge and pass it on to those hungering for diving into JavaScript!

We really have gathered a lot of bright, bleeding-edge people and each of us is learning from another everyday. If you want to get some of the know how (at least as much as we can pass on in a two day workshop) you are invited to join our workshops. There will be one held in Munich 29th and 30th of June and another one in Amsterdam 11th and 12th of July. We will always have at least two uxebus teaching you the latest and hottest. We might even have some of the latest bleeding-edge mobile devices for you to run the app you will develop in the workshop.

Workshop Details

In this course we will cover a broad spectrum from JavaScript essentials to the bleeding edge of cross platform HTML5 development. We start from the ground up and go step by step, depending on the level of the participants we accelerate to show you the deep and dark sides of JavaScript.

Each day of the course is split into an intensive “knowledge transfer” session in the morning and a hands on hacking workshop in the afternoon in which you will apply the contents learned during the morning. At the end you will have touched all contents not only through theory but also through intensive real life application and coding.

Note that this course will not explain you how to work with jQuery and also not how to work without jQuery. The course mainly focuses on JavaScript, mobile and HTML5.

Day 1 (part 1) – JavaScript

We start with a small overview of the history. We tackle the basic structure of the language and move on with statements, expressions, functions and objects. We touch the different operators and when semi colons are introduced.

We continue our way through the JavaScript landscape by taking a look at objects, properties and built-in functionality. At that point we’ll encounter our first major obstacles; scopes and closures. Once we conquer these we touch on the difference between functions and constructors. This is followed by our second major obstacle; prototype and the various values of the this keyword.

Day 1 (part 2) – Hackday: HTML5, CSS3

During the second part of day one, we will take what we have learned in the morning and mix it with a little shot of HTML5 fanciness. We will look at all those new APIs we can now access on our (mobile) devices to bring JavaScript to a new level. We will include cool APIs such as the Audio API, Video API, history, Canvas, SVG, File API, WebGL, DeviceMotion, WebWorkers, WebSocket, GPS – and if all ingredients fit well you might just end up with your first app written in JavaScript.

Day 2 (part 1) – The App Day

During the second day we willl continue with timers, callbacks, web workers, eval and the future of JavaScript. The speed of the course is matched with it’s participants. The important parts of the languages will be handled in the workshop. During the first part of day two we will also specifically look into topics which you want to cover after determining those during day one. This will give you the chance to get all your open questions answered so that you have your pockets full of knowledge after the workshop is over.

Day 2 – part two (Mobile)

JavaScript has grown strongly into the mobile space, so we will show you how to get the app you have started building during day one onto mobile devices. You will learn about media queries, some device sensors, performance and HTML5/CSS3/JavaScript tricks and how to optimize some parts for mobile and how to make a native app out of it, so you finally could even make get it into the app store and make money with it.

Now you want to join our workshop?

Join us either

• in Munich 29th and 30th of Juneor
• in Amsterdam 11th and 12th of July

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.

You do not only get to travel in uxebu. First and foremost we want to give you the opportunity and platform to accelerate the things you can do, show it to the community and enable you to reach more than you could on your own.
It doesn’t matter where you live! We are currently flirting with San Francisco too :).

But we are also a family company! We encourage you to have fun and put the priorities right. And family and health are top priorities at uxebu. As you can also see, as long as you like traveling and hanging out with the top geeks in our community you get to do that at uxebu, a lot. Because this is the bread and butter of high quality that we offer to our customers. And in order to become a top geek (which is one goal that we have for you at uxebu, if you aren’t one yet :)) you should be around those where you can suck know how and hopefully also give back and share yours as well.
You get the hardware that you need to work as efficient as possible. You prefer working at home or in a co-working space? No problem, feel free! Once in a time we meet some place and hack together for a couple of days, talk about our roadmap, find out where each of us wants to head and we figure out the way how to achieve reaching the goal we determine together. We normally meet some nice place, like at a lake or in the mountains. The last times we had both :). And we take the families with us.

Jens Arps joined uxebu in May 2010, he is the guy behind StorageJS, he is project lead for the just new dojo foundation member embedJS and is working on a really exciting HTML5 customer project that I can not link here :(. Stephan Seidt has hacked the newest (still unreleased) apparatio API, he is the one who does the node.js stuff in our team and WebGL is what he is passionate about, really passionate! I don’t have to say much about Tobias Schneider the guy behind Gordon, he has become famous over night, spoke at the last two JSConf’s and is our hard-core optimizer. David Aurelio has created TouchScroll and if you team him up with Tobias Schneider we have ALL JavaScript knowhow in da house, and they are currently hacking together on a really awesome project. Nikolai Onken a co-founder of uxebu is our social community front man and the party goer number one and besides that he has created HumanAPI and knows all the JavaScript guys around! Tobias von Klipstein is also guilty of founding uxebu and he is our Jack of all trades, he had created the first version of apparatio almost all alone.
Me, I write blog articles, sometimes. But I get to go to all parties anyway :).

If you are a JavaScript geek, love to walk along the edge of what is possible with web technologies and think that HTML5 is the rocket ship you should send us an email with some links to some of your projects and a short, convincing reasoning why you would like to work with us. And if you think that you can’t work with us because you are not ready yet, shoot us an email anyways and let us talk first and decide later. We are made of talented individuals each. But working together as a team is what makes us really strong. Be ready for it!

And btw get ready to learn something new every day. And do also pass on your know how!

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!

• David Aurelio (of TouchScroll fame) – Interface Styling & Scripting for WebKit Mobile
• Jens Arps (our storage expert) – The hitchhiker’s guide to client side persistent data storage
• Tobias Schneider (the uncomparable Gordon author) – Not your Mother’s JavaScript!
• Nikolai Onken (a Dojo senior) – Robotic JavaScript

and if you think you have something as cool as what you will see at JSConf you should contact us and we should talk about working together. We at uxebu are putting fun in the job first, actually we are trying to have fun all day and just call that work. Family and health are the top priorities in our company and the absolute base for doing a great job … oh and JavaScript is what we love, currently we are hacking it only on mobile (or as we like to name it “embedded”) devices. “Embedded” because we think JavaScript is not only hot on mobiles, but on TV’s in car dashboards and maybe even in your washing machine :)!? You know where we are going … are you as enthusiastic as we are? Come and talk to us at the JSConf, or if you have no ticket for JSConf yet give us enough reason to invite you there and get to know your geekiness :).
Let’s rock the mobile/embedded world …
Write us to contact@uxebu.com or find us on twitter @uxebu.

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.

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.

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.

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:

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.

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:

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