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

Dojo also comes with two fresh implementations for the API, a non-persistent memory store and a JsonRest store that interacts with a server through RESTful HTTP requests. You can also observe changes made to objects in the store. What is missing is a store that uses a client-side persistent backend, which would be useful for a couple of reasons (e.g., as one commenter in that post asks, to use it as chache store for dojo.store.Cache). As Kris already mentions, it’s a piece of cake to create one, so let’s go ahead and do it!

Choosing the Backend

The post mentions two possible candidates: dojox.storage and StorageJS, both already having a similar API, so making them compliant to the Dojo Object Store API is fairly easy. For this tutorial I choose StorageJS – because it is very lightweight and still provides all we need (and, well, for a couple of other reasons that don’t belong in this post). So, what is the exact API we need to comply to? Check it out in the docs. See the first sentence in that paragraph? “Every method in the API is optional, it’s presence indicating support for that feature.” Wow, that’s nice!

Basic compliance

Let’s start with the methods get(), put(), add() and remove(). That will make our store pretty usable for most store scenarios.

First, create a ‘store’ object we can work with (StorageJS creates a global variable called storage where all it’s methods reside):

‘store’ now contains everything that ‘storage’ does, but we can leave the original ‘storage’ object alone and modify our ‘store’ object if needed. Time for the first method, let’s start with get(). StorageJS works with Strings as keys and values only, so we need to parse what we get from it.

Easy one, now move on to put(). The Object Store API allows user to do stuff like this: store.put({foo: 'bar'}, {id: 3}) as well as store.put({id: 3, foo: 'bar'}). Also, StorageJS only has the method set() instead of put() and add().

Easy, as well – you could write this as a one-liner. Now, add(). It’s close to put, except that it won’t overwrite data that already exists. So we just need to check if something with the given id already exists and throw an error if so.

What about remove()? Nothing to do there, it already has the desired signature and functionality.

That’s it, we’re done with basic compliance. Our ‘store’ object now implements the basic methods of the Dojo Object Store API and can be used by anything that can work with a Dojo Object Store – and it will keep it’s state persistent in the browser.

More compliance? Querying!

There’s one interesting thing in the API: the query() method. Uh, yeah, we want that! Lucky us, Dojo already provides a query engine as well as a method that makes sure there are iterative methods and a total property containing the number of hits available in our result (well, it also abstracts away the differences between sync and async results, but as StorageJS is purely synchronous, this is not important to us). First, define a queryEngine:

So, if we want our store to be able to run queries, all we need to do is to take the store’s data and hand it over to the query engine. We use StorageJS’ getAll() method to acquire the data. It will return an array of objects in the form { key: ‘theKey’, value: ‘theValue’}, but the queryEngine wants an array containing only the objects, so we need to do a conversion.

Now we can query our store for specific data, like so: var results = store.query({ prime: true }); This will give us all objects in the store that have a property called ‘prime’ and have that property set to true.

Hierarchie and Transactions

The API also mentions methods about data hierarchie and transactions, but I’m not going to cover these in this tutorial.

Convenience and Optimization

Currently, every time we run a query, we fetch all data again from our storage engine. So, if you don’t have a massive amount of data and want to query the store a lot, it might be wise to maintain a copy of all data in memory. There are other things you could optimize as well – or you could write your own queryEngine.

For your convenience,  here’s a wrapper that creates a Dojo Object Store like we did above and accepts a useMemory parameter during instantiation that denotes whether a copy of the data should be kept in memory or not. It uses the traditional require/provide instead of the AMD format. If you want to use it, make sure you use the right namespace in the declare() call! (Or, not recommended, copy it in the /dojo/store directory.)

If you want to fool around with it in the console first, you can go here (non-memory-using) or here (memory-using), check out the source and fire up the console and try things out.

Getting StorageJS

The above code uses the features base and getAll, so you could do a specific build of StorageJS with these features or just grab a full build of it for your desired storage engine (the storage-full-[engine].js files). If you don’t know about storage engines, all modern browser support localStorage, so this is the one what you might want.

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:

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.

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:

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.

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:

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:

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

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:

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

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

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

The Prototype Chain / Inheritance in JavaScript

Inheritance in JavaScript bases on the Prototype Chain. Every object has an internal “[[Prototype]]” property pointing to another object or null. The notation with square brackets is used in the ECMAScript specification, I will stick to it in this post. This property typically isn’t accessible in a program – it is private to the JavaScript runtime, even though Gecko and some other runtimes have started exposing it through the non-standard __proto__ property.

When trying to access a property on an object (e.g. fooObject.barProp), the runtime will follow the prototype chain from object to object (using the [[Prototype]] property) until the property is found. If it is not defined throughout the whole prototype chain, undefined is returned.

The difference to class-based programming languages is, that property/method access is not resolved within a class hierarchy, but rather within an hierarchy of objects (“class instances”). Properties shared between instances (“shared properties” in ECMAScript terminology) and methods are defined on an object deeper in the chain, while “instance variables”(“own properties” in ECMAScript) are defined on the top-most object itself – the object you are working with.

Creating Inheriting Objects

The traditional method of creating objects with a specific prototype chain is to define a constructor function and set its prototype property to the desired object.

Now it is possible to create instances using the new operator:

This code creates a new object, sets its internal [[Prototype]] property to MyConstructor.prototype, and executes MyConstructor in the context of the newly created object (“in the context” means that the this keyword points to the new object).

The instanceof operator allows us to check whether an object has been created by a specific constructor function:

(instanceof checks the whole prototype chain, and works with “subclasses”, too).
This coupling of constructor and instances is rather loose; when creating a second constructor with its prototype pointing to the same object as the first constructor, an object will be instance of both constructors:

also, when changing the prototype property of a constructor to another object,

yields a different result:

The explanation is simple – since MyConstructor.prototype is not in the prototype chain of myInstance, the operator yields false

Object-Based inheritance

The latest edition of ECMAScript – ECMAScript 5th Edition – gives us a powerful new tool to create objects with a specific prototype: Object.create(). The method takes two parameters: The object to use as [[Prototype]] and an object containing property descriptors for the new object to create. Using Object.create allows us to short-circuit object creation and avoid the usage of constructor functions.

Creating two objects sharing a common prototype is easy:

Building an inheritance chain is also possible, but might get a little bit tedious when using property descriptors to add new properties:

You may have noticed two things in this example:

1. Creating “instances” of an object or “subclassing” it are basically the same process: We create a new object with its prototype set to the base object. Personally I like this fact; it just feels natural in an prototype-based inheritance model like the one in ECMAScript/JavaScript.
2. Not using a constructor function shows how useful such an initialization function would be for instance creation.

Inheritance System Based On Object.create()

For me, using Object.create() felt incredibly natural compared to fiddling around with constructor functions and the prototype object attached to them – that doesn’t mean having a constructor is bad; they are really useful for setting up an instance. But the coupling of constructor, constructor.prototype, and instances is too loose in my eyes, and makes it unnecessarily hard to understand inheritance in JavaScript.

What I don’t like is the verbosity of the descriptor syntax. Granted, it gives us a lot of possibilities, but for most cases it is too cumbersome. In addition, I wanted to have a constructor when creating objects that are supposed to be used like a class instance in a class-oriented programming language.

I came up with a light-weight inheritance system that provides separate methods for the two cases where I use Object.create(), object extension and instantiation.

Have a look at this gist.
[gist id=838778 file=base.js]

You can use BaseObject as base for your inheritance/object tree, or simply copy all of its methods onto your own base object. Both instantiation and extension are done through Object.create, but work pretty differently. Let me go into detail and explain the four methods present on BaseObject.

• The _construct method acts like a regular constructor: It is executed in the context of a newly created instance right after creation in the context of that instance (this works as you would expect). You may overwrite this constructor as often as necessary. You can access parent constructors through the _super convenience method (see below for details). The dangling dash suggests you should regard this method as private. Usually, you never need to call it manually.
• create is used for instantiation. Whenever you need a new “instance” of a base object (that you might use like a class), you’d simply call “create()” on it: var myInstance = MyBase.create(arg1, arg2);. The instance is created, and its “_construct” method is called with all arguments passed to “create()”. Eventually, the instance is returned. Normally, you might not need to overwrite the base create method, but you may do so for complete control over the instance creation process if needed.
• Use the extend method to create “subclasses” – it differs from creating instances in two aspects: the constructor isn’t called, and you can easily create additional properties on the new object: The first parameter is a simple object. All of its properties are copied onto the new object (you may also pass null). The second (optional) parameter is an object containing property descriptors for properties to be created on the new object. Check the example below for details. This system allows it to use simple properties without taking the power of property descriptors away from you.
• _super is a convenience method to call overwritten parent methods in the context of the current object. It works similar to python’s super and takes three arguments: A reference to the object that overwrites a method (not the name of the parent object), the name of the overwritten method (as string), and an array of parameters/an arguments object. Just take a look at the example to get the idea how it works.

Generally, you should not overwrite the “extend()” and “_super()” methods. “create()” may be overwritten for more control over the creation process of instances. “_construct()” can be defined as often as needed.

This example is a rewrite of the Person/Employee/Manager example using BaseObject as parent of Person:

What’s Nice

What I really, really like is the fact everything feels just natural – we’re dealing with a set of objects, not with a constructor/prototype construction (which might be one of the reasons inheritance in JS is so difficult to understand when coming from a class-based language). For example: Where would you define a “static” member in the classic approach? On the prototype? It’s in the inheritance chain and can be overwritten by “subclasses”, but might be hard to reach from other places (think of Shape.prototype.SQUARE. Not cool. On the constructor? That’s nicer for access (Shape.SQUARE), but places the property outside of the inheritance chain, thus making it impossible to overwrite it. In addition, I feel that using this.SQUARE from methods feels more natural.

Using a hierarchy of objects solves all that little inconsistencies. Yum!

Extending incredibly flexible: since extend() is present on every object created by extend()/create(), you can extend everything with new properties.

What’s Not So Nice

Since the objects we use in a “class” role are objects, not functions, we can’t use the new operator. After years of using it, I really have to adopt to the use of create() instead.

Also, instanceof only works with constructor functions. Use the .isPrototypeOf() method of ECMAScript 5 instead.

Compatibility is still an issue. The browser/runtime must support the new ECMAScript 5 features Object.create(), Object.getOwnPropertyNames(), Object.getOwnPropertyDescriptor(), and Object.getPrototypeOf(). Browsers supporting the required functionality include: Firefox 4, Safari 5, Chrome 9,
Internet Explorer 9 (untested). Opera has no support for these features yet.

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.

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!

Further reading

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

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

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

. Declaring multiple variables using one var-statement accross multiple lines is a NO GO! I consider this evil. And I learned it the hard way. It might look pretty nice, looks like less code and more efficient. But it definitely is not so when writing code. If it results in more speed let your build tool, compressor or compiler do it. But don’t write code which spreads multiple variable declarations in var-statement across multiple lines!
PERIOD.

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

Good and Bad

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

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

into my code above. We might get the following:

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

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

Real Life Examples

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

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

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

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

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

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

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

Closing Thoughts

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

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

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

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

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

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