uxebu » blog » frontend engineering

My console.log() strategy

Wolfram Kriesing — Fri, 02 Sep 2011 10:00:36 +0000

This time I feel like sharing my (maybe) strange looking console.log() strategy, but I find it very effective, read on to learn why.

If I can’t debug, for whatever reason and have to fall back to console.log()s you normally see my code looking like this:

1
2
3
4
5
6
7
8
9

console.log("i = ", i);
if (i==0){
console.log(1);
// Do something here
} else {
// Do else
console.log(2);
}
console.log(3);

You can see two things here:

the first line prints out a variable’s value, simple I guess
all console.log()s are not indented at all

Let me touch on the “not indenting” first.
I don’t like to indent console.log()s because this just makes the code look ugly, and that is intentional, because console.log() normally just doesn’t belong in the code. By making the code look ugly I am quickly forced to remove them again, the latest I will stumble on it before committing, because I never commit without looking at the diff.
If I ever forget to remove the console.log() I can be sure that a coworker will be annoyed by it and hopefully either ping me or remove it. But I am trying my best not to forget it :).

Komodo macro

Back to the first console.log() you see in the code example up there, that one is actually one keystroke away for me, I have hacked a simple macro in my editor (Komodo Edit) that takes the text I selected and creates a console.log() in the line below throwing out this variable and it’s value.
This little script looks like this:

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

var s = ko.views.manager.currentView.scimoz;
var t = s.selText;
komodo.doCommand('cmd_end');
komodo.doCommand('cmd_newlineBare');

// Only if something was selected put it there.
t = t ? "'"+t+" = ', "+t+"" : "arguments";
s.insertText(s.currentPos, "console.log("+t+");");

// Set the cursor inside the "()" at the end, so we can add
// parameters
komodo.doCommand('cmd_end');
komodo.doCommand('cmd_left');
komodo.doCommand('cmd_left');

Just create a new macro with it and attach a key-combination to it and logging a variable is just one key stroke away.

JavaScript, HTML5, CSS3 workshop

Wolfram Kriesing — Fri, 10 Jun 2011 13:58:56 +0000

Uxebu is spreading its knowledge, get some of it – for 699€ if you are an early bird (999€ later)!

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

Using IndexedDB on Firefox

Jens Arps — Wed, 30 Mar 2011 14:55:00 +0000

As Firefox 4 is now stable, chances are that the async IDB (IndexedDB) API is not going to change anymore. But IDB is not localStorage – it can be a major pain to work with. So, here is a guide on how to use IDB in Firefox as a key-value store.

TL;DR
There is example code available at the end of the post. If you don‘t want to read this lengthy post and/or prefer to jump right in the middle of the action, grab the example implementation and play around with it.

Key-Value Store? But, IDB is a full-blown database!

Yes, it is. But I still argue that in WebApp context a key-value store will cover about 90% of use cases. So I won‘t cover in this post how to create fancy key ranges or how to create multiple indices. But I will cover the five basic methods that you will need to work with any store: get, set, remove, getAll and clear – this will enable you to work with IDB and give you an understanding of how it works. You‘re then of course heartly encouraged to explore it and it‘s features further!

A word on requests, transactions and events

As long as the sync API is not there, all operations are async. That means that you will make requests. All the time. These requests will have an onerror and an onsuccess property, where you can put your callbacks/handlers in. If your request was successful, you will get an event in your callback. That event contains a lot of useful and useless information, but what you will want to look at in most cases is event.target.result – this is where your result lives in. In most cases, you will have to start a transaction before; inside of the transaction, you can access the objectStore and make your request. However, there are different types of transactions, but you will get the details below.

Getting the Object Store ready to use

Yep, it‘s not that you can just start away and store your data, there‘s some work to do ahead…

Open the Database

Easy one:

1
2
3
4

var openRequest = mozIndexedDB.open(dbName, dbDescription);
openRequest.onsuccess = function(event){
//event.target.result contains a reference to the db
}

event.target.result then contains a reference to the database. Store it, you will need it.

Creating/Opening the ObjectStore

That‘s a little tougher. Some operations, such as creating and deleting object stores, require the database to be in a „mutation transaction state“. Wow. Well, there‘s only one way to put the db into this state, and that‘s via a setVersion request. If you are opening the db for the first time ever, you will need to do this anyway. You can, of course, change the version of the database anytime, which might be a useful thing if you, e.g., change the structure of how your objectStore saves the data. To check what version the database in the user‘s browser has, you can check the version property in the reference to the database anytime.

1
2
3
4

var versionRequest = db.setVersion(dbVersion);
versionRequest.onsuccess = function(){
// Woohoo, the database is in a mutation transaction!!
};

Inside of the callback function, you can now check if your store already exists, or if you need to create it. The reference to your db contains an object called objectStoreNames, which is a list of existing objectStores. As this is a DOMStringList, it features the handy contains() method:

1	var hasMyStore = db.objectStoreNames.contains(storeName);

If the store is not there, you need to create it via the createObjectStore() method. It takes two arguments: the name of the store, and an object with two properties: keyPath and autoIncrement. keyPath is… well… the path to the key. Think of it as the one column that is the primary key in your data table (you all did some MySQL at some time, I bet). You can do really fancy things with the keyPath in objectStores, but it‘s perfectly fine to just use something like „id“ as the keyPath. If you want to store an object and want to provide the keyPath, all you need to do is let the object you want to store have a property with the name of the keyPath, and a unique value. Uh, it‘s not that complicated, examples will follow. AutoIncrement is, well, autoIncrement. You have the option to let the objectStore take care for the uniqueness of it‘s data‘s keyPath properties, or do it yourself.

1	var store = db.createObjectStore(storeName, {keyPath: 'id', autoIncrement: false});

You immediately get a reference to the newly created objectStore, so save it.

If the store is already there, you need to open it. Um, well, you don‘t really have to open it, but you might want to obtain a reference to it, just to make sure that it really exists. To do this, you need to start a transaction via the transaction() method. It accepts three arguments: an array of store names (the ones which you want to work with), an integer denoting whether you want to read and/or write during that transaction, and a timeout. There are constants for read/write you can use for better readability in your code, you can find them at IDBTransaction.READ_ONLY and IDBTransaction.READ_WRITE. The timeout parameter is optional. That method returns a transaction object that contains a method called objectStore, which you can use to access your store. This is the „default“ way transactions work; the mutation transaction above is an eception to this, where you need to be in the callback of the transaction to modify the database.

In our case, we can start an „empty“ transaction:

1 2	var emptyTransaction = db.transaction([], IDBTransaction.READ_ONLY); var store = emptyTransaction.objectStore(storeName);

There you have your reference to the store.

Data Manipulation

Now that the store is ready to use, it‘s time to store some data in it. To do so, you need to start a transaction, access the object store, and call the store‘s put method:

1
2
3
4
5

var putTransaction = db.transaction([storeName], IDBTransaction.READ_WRITE);
var putRequest = putTransaction.objectStore(storeName).put(dataObj);
putRequest.onsuccess = function(event){
//event.target.result contains the value of the keyPath of the data written (the „key“)
};

That‘s all. This type of transaction is what you also use for other data manipulation tasks, for example to retrieve data:

1
2
3
4
5

var getTransaction = db.transaction([storeName], IDBTransaction.READ_ONLY);
var getRequest = getTransaction.objectStore(storeName).get(key);
getRequest.onsuccess = function(event){
//event.target.result contains the data object
};

You will need to provide the key of the stored entry to get it; as you need to do when you want to remove it:

1
2
3
4
5

var removeTransaction = db.transaction([storeName], IDBTransaction.READ_WRITE);
var deleteRequest = removeTransaction.objectStore(storeName).delete(key);
deleteRequest.onsuccess = function(event){
//event.target.result contains the key of the deleted data object
};

If you want to get all data objects from the store:

1
2
3
4
5

var getAllTransaction = db.transaction([storeName], IDBTransaction.READ_ONLY);
var getAllRequest = getAllTransaction.objectStore(storeName).getAll();
getAllRequest.onsuccess = function(event){
//event.target.result contains an array of all data objects
};

And, finally, if you want to clear (i.e., delete all data objects) the store:

1
2
3
4
5

var clearTransaction = db.transaction([storeName], IDBTransaction.READ_WRITE);
var clearRequest = clearTransaction.objectStore(storeName).clear();
clearRequest.onsuccess = function(event){
//event.target.result contains undefined
};

But how‘s this better than localStorage?

It isn‘t. Yeah, well, it is, as you can store objects and don‘t have to stringify them before. But basically, to get the real advantages of IDB, you will need to dive deeper into it. Features like keyRanges remove the need to do map/reduce action when you search for items in your store. But now you have an idea of how the whole thing works. If you want to go further, browse in the spec or the MDC docs and try things out!

Example Code

There is an example page over here: http://static.uxebu.com/~jens/indexeddb/ff-idb.html.

It uses an ObjectStore wrapper I created using dojo that covers the basic methods mentioned above, the JavaScript is here: http://static.uxebu.com/~jens/indexeddb/idb-ff.js.

When you open the page, open the console and you will see some messages there. Check out the source to see what‘s going on; it‘s basically a round trip through all the basic methods.

Further Reading

The spec: http://www.w3.org/TR/IndexedDB/
The MDC article: https://developer.mozilla.org/en/IndexedDB

What is WAC and how it could help us

Stephan — Thu, 24 Feb 2011 16:53:08 +0000

At Mobile World Congress 2011 in Barcelona, @uxebu attended the WAC event to catch up with the future of WAC.
WAC, short for Wholesale Applications Community, is a group of global mobile operators.
They provide, among other things, a spec for their correspondent web application runtime “WAC”.

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?

An easy way to package web apps “for home screens & app stores” by wrapping web apps in native container apps.
An extension of browsers’ capabilities to enable richer web apps. This includes APIs for camera and file access.
In contrast to alternatives WAC has a strong focus on carrier network APIs. This could enable purchase through carrier billing.
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:

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.
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.
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.
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.
WAC 2.0 runtimes with the above properties should appear very soon. They also need to be advertised in an easy to understand manner.
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.

Travel with uxebu – We are hiring!

Wolfram Kriesing — Thu, 10 Feb 2011 16:56:04 +0000

Yesterday HP announced the new WebOS devices in San Francisco. Nikolai and Stephan had been there (and they are still there). MWC starts on Monday. Six out of seven of the uxebus will be there in Barcelona, all week, one apartment, sea view and fun. After JSConf in Portland (at least) three of us are going to NodeConf and Google IO again in San Francisco. Right after it all of uxebu will be in Amsterdam for mobilism. We have also been in London, Malmö, Bangalore and more … Yeah we are a travel company!

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!

Explaining EmbedJS

Jens Arps — Mon, 31 Jan 2011 14:02:28 +0000

Last week, we tagged the current state of EmbedJS 0.1. This is a large step for us, and something we have been waiting for and wanting to do for a long time. And with doing so, the need arises to answer a lot of questions – and we better start sooner than later. So, here it is, the first part of „Explaining EmbedJS“.

What is it?

It‘s a JavaScript Toolkit, especially aimed at embedded devices. Embedded devices, that is phones, tablet devices, TVs, car dashboards and the like. Devices that are capable of running JavaScript. We are sure that this list is going to grow over time – and will hopefully one day also include devices like your fridge. EmbedJS is based on the Dojo Toolkit.

Why?

Because the toolkits and frameworks that exist focus on desktop browsers and therefore have a different approach – an approach we didn‘t find that suitable for embedded/mobile development. And the JS frameworks that target mobile devices are flawed, too: either they target only a specific device or platform, or they provide far more than we do need and want.

What we wanted was a toolkit that offered a unified API across different platforms, but with the best implementation that was available for each platform. And we didn‘t want to ship code that implemented a certain feature for, say, an old Blackberry device to an iPhone. Plus, we wanted that API to be small – enough to assist us in our daily work, but not that bloated that we would ship code to a phone that we wouldn‘t need in most of our projects.

The Dojo Toolkit

We at uxebu have a strong affinity to the Dojo Toolkit – most of us are committers – for a good reason: we believe that it has done many things right, and that it has an excellent code quality. Thus, finding a starting point for our venture to what was later to be EmbedJS was pretty easy: It was the very core of the Dojo Toolkit, dojo._base.

We examined the code and split it into its smallest parts (features, how we call them in EmbedJS). After having the features all nicely separated, we could look for the best implementation for each of the platforms we wanted to support, and put it into a separate file. Then we optimized our code, tweaking here and there, but also using the code from dojo._base as it was, because it already was the best implementation.

And we needed to find means to put all these tiny parts together again, respecting any given dependecies, to create a file that then contained all the feature‘s implementations for a given platform – so the EmbedJS Tools were born, including our highly flexible build system.

API

EmbedJS‘ API is a small subset on Dojo‘s API. It provides around 70 methods, from the fields language enhancement (like Array manipulation or JSON), OO (like classes and inheritance), transport (like JSONP or XHR), event system (like connecting to DOM events or methods), DOM manipulation (like style or node creation) and misc things like Promises or pub/sub.

We kept the method signatures intact so that you can import your existing knowledge from working with the Dojo Toolkit to EmbedJS. There are only a few minor changes where we
a) found a new name highly useful, e.g dojo.io.script.get() is embed.jsonp()
b) we needed to strip given functionality for the sake of code size.

All methods in EmbedJS are available under the embed namespace as well as under the dojo namespace. I.e. to call the connect method you can use dojo.connect() and embed.connect().

The full API documentations is here, though it‘s undergoing some updates right now.

Summary

I didn‘t want to dig too deep in the first article on EmbedJS, but I guess you got the point: EmbedJS is a highly optimized Dojo core, and offers you a specialized, optimal build for a given platform. To explain how the build system works, how we manage dependencies, how we separate our features and our implementations and how one can create a project-oriented custom build will need another blog post – but if you are too curious, you are invited to take a look at the source code at github; a lot is self-explenatory there. A further source of information is the EmbedJS project page, as well as the EmbedJS Tools source.

indexedDB Updates – FF4.09b

Jens Arps — Mon, 17 Jan 2011 15:52:26 +0000

IndexedDB is all the buzz right now, but it is pretty hard to find information about it’s implementations. In addition to that, the impls change on a weekly basis. So I figured it would be nice to summarize every now and then what has been happening around IDB in the last time.

And as Mozilla released a new Firefox 4 beta these days, and introduces changes to it’s IDB impl, let’s start the series with a brief summary of the most important of these changes.

Changes in 4.09b

The indexedDB object has been renamed: moz_indexedDB is now mozIndexedDB.
When opening a database, the event handed over to the onsuccess callback no more has a property called “result”, where a reference to the databasse used to be; it is now available at event.target.result (event.target contains the IDBRequest).
This applies to many (all?) cases, where you’d expect the result of a request to live in event.result, where it now is in event.target.result.
When creating an object store, the second argument, keyPath, now has to be passed as a property inside of an object: {keyPath: "keyPathName"}
When creating an objectStore, the third argument, autoIncrement, is dropped and now has to be part of the second argument: {autoIncrement: true}
Methods that read from an objectStore now only seem to work inside of a transaction; before, it was allowed to call methods like get directly.
keyRange support seems to have increased. However, I’m not really interested (right now) in keyRanges and queries, so I did not play around with these.

Note that the changes for the createObjectStore arguments are against the spec – the 4.08b was compliant, the 4.09b is no more. But, on the other hand, it is now closer to the Chrome impl, which also expects an object as second argument (but has no support for autoIncrement).

What it does not have (yet)

The sync API. Alas. To me, the snychronous implementation is exactly what makes indexedDB that attractive – I’m not a fan of databases and I don’t like to start transactions, iterate over resultSets and the like… I want a store with easy access. Seriously, in most real life scenarios, an async approach won’t get you anywhere but displaying a waiting message to your user, because you can’t go on until you have the data from the store.

More info?

If you want to stay in touch with what happens around the indexedDB impl, the best place to go ist the Mozilla bugtracker. Um, yeah, reading browser source code can be no fun at times, but it gets you as close as you can get. Or, check what happens in the test files.

Need working code?

The *only* place to get reliable, working code is the test files in the repository. Seriously, there’s so much code out there claiming to work, but it simply doesn’t. And even if it did one day, it might break the other day, after changes have been made to the impl. And there will be *lots* of changes in the future.

Where are these test files?

In the repo. To see them online, go here: http://hg.mozilla.org/mozilla-central/file/ and then navigate to dom/indexedDB/test.

Something else?

Nope, not really. There don’t seem to be any *major* changes for 4.09b – I hope you still found this short summary useful.

I hope to continue this series about IDB and post about different IDB topics every now and then – so if you want to know more about indexedDB in general, or something specific, just drop a line in the comments!

BlackBerry6, WebKit, WebWorks, DevCon10, etc.

Wolfram Kriesing — Mon, 25 Oct 2010 08:59:59 +0000

The BlackBerry DevCon 2010 closed it’s doors a couple of days ago and to put the conclusion first, I have become a new evangelist for the BlackBerry6 platform. It supports W3C widgets, well … in a way ;). The core message I took away: web technologies have become first class citizens on the new BlackBerry platform. And we from uxebu really love this, as you can imagine.

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.

uxebu is hiring

wolfram — Sat, 18 Sep 2010 20:17:05 +0000

JSConf is just around the corner and all the JavaScript geeks are meeting there. We from uxebu are going there too, of course :). We are going to give four cool talks

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.

Forgotten tricks for iPhones Safari

Nikolai Onken — Wed, 28 Apr 2010 14:18:21 +0000

Safari om the iPhone is an incredible powerful browser and comes with a whole bunch of features.
Besides the amazing support for CSS3, a superfast rendering engine and great JavaScript support, there are a few hidden gems I want to explain in this (and maybe following) blogposts. If you are interested in mobile web development, maybe you will find a few features you haven’t seen before.

Making your web app iPhone ready

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

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

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

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

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

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

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

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

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

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

1
2
3
4
5
6
7
8
9
10

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

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

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

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

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

Enjoy

Dowload

Source
Docs

uxebu » blog » frontend engineering

My console.log() strategy

Komodo macro

JavaScript, HTML5, CSS3 workshop

Uxebu is spreading its knowledge, get some of it – for 699€ if you are an early bird (999€ later)!

Workshop Details

Day 1 (part 1) – JavaScript

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

Day 2 (part 1) – The App Day

Day 2 – part two (Mobile)

Now you want to join our workshop?

Using IndexedDB on Firefox

Key-Value Store? But, IDB is a full-blown database!

A word on requests, transactions and events

Getting the Object Store ready to use

Open the Database

Creating/Opening the ObjectStore

Data Manipulation

But how‘s this better than localStorage?

What is WAC and how it could help us

Travel with uxebu – We are hiring!

Explaining EmbedJS

What is it?

Why?

The Dojo Toolkit

API

Summary

indexedDB Updates – FF4.09b

Changes in 4.09b

What it does *not* have (yet)

More info?

Need working code?

Where are these test files?

Something else?

Further reading

BlackBerry6, WebKit, WebWorks, DevCon10, etc.

WebKit and WebWorks

Security

uxebu is hiring

Forgotten tricks for iPhones Safari

Making your web app iPhone ready

Dowload

What it does not have (yet)