This article is a reworked abstract from my book Firefox OS in Action. The first few chapters are currently available under early access at http://manning.com/jongboom/. You'll get 50% off with code 'dotd082714au' if you buy it on August 27.

The launch of Firefox OS phones in India yesterday made a lot of buzz. Major reason: for the first time a smartphone was launched for a price under 2,000 rupees (¤25 or $33). This might seem insignificant in the 'first world', where every teenager runs around with a $700 iPhone in their pockets, but will make a huge impact in the third world. In this article I'd like to talk about the reasons why we have focused on breaking the price barrier, and about the choices in architecture that we made to facilitate this.

While internet is a commodity for most readers of this article, this is not the case for the majority of people on this planet. At the moment of writing an astonishing 4.2 billion people do not have access to the greatest source of information that humankind has ever created. There are more people that do not have access to the internet, than those who do. One of the main goals (for me *the* main goal) of Firefox OS is to change this.

Working as an evangelist for Telenor, a telco that has a number of subsidiaries in poor countries, this directly affects me. I have the opportunity to travel to a lot of these places, and the thing that strikes me the most every time I'm down in South-East Asia is the curiosity and willing to learn that people show. Every time we host a seminar, a training session or a Firefox OS app day there are 5 times more people that sign up than that we have room for. We have not even launched in Bangladesh and there are over a hundred apps in the Firefox OS marketplace already. It's astonishing.

For me this is the ultimate proof that the biggest difference between us, the Silicon Valley induced Hacker News crowd, and them is just plain simple opportunity. Internet is the way to level that playing field. With internet everyone has access to the best education programs; health care information; and communication channels. And on top of that it allows people to sell their product to the global market. Internet is going to have a direct impact on the lives of these 4.2 billion people.

The foundation

To accommodate these goals Firefox OS is built on two pillars. First: be able to run on the lowest hardware possible, because cost is a big factor. And second: put the open web first, as there is ten thousand times more information available on the web than in app stores.
Optimizing a phone to run the web as fast as possible on cheap hardware means that some interesting changes are made in the architecture of the OS. When you want to view a web page on Windows or on Android you'll do this through a browser like Mozilla Firefox or Google Chrome. The browser then runs on top of the operating system (Windows, Android, etc.), the operating system then runs on top of the hardware.

That means that running a web page will always be slower than running a native application on these operating systems, because it has one less layer of abstraction (App -> OS -> Hardware, versus Web Page -> Browser -> OS -> Hardware). But Firefox OS takes a new approach. Web pages should run as fast as possible, so the OS layer that sits between the browser and the hardware is just a factor that slows that down.

When you are designing an OS from the ground up you can change the way this works. Firefox OS takes a new approach, where there is no separate OS layer and the browser runs directly on top of the hardware. That way the heavy step in between is gone and we have a cheap and fast web browser on a mobile device.

This approach has one big drawback. The OS layer contains a lot of useful stuff that is not present in the browser. For example access to hardware sensors, the ability to place a phone call, and access to the SD card. Those features are not included in the browser. To make up for this, Mozilla added new JavaScript APIs to the browser that allow you to access all these things. This means that you can now write some JavaScript to place a phone call.

Here the API to make phone calls is located under navigator.mozTelephony. This API has a moz prefix because other browser vendors have not agreed upon the API yet. We can call the dial function to initiate a phone call (#a). The API returns a standard JavaScript object where we can attach event listeners. In this case we wait for the call to be connected (the other party picks up the phone #b), and instantly hang up (#c). This gives us the opportunity to interact with real life, straight from JavaScript!

The web is great

Now the ability to place a phone call from JavaScript might seem trivial but it's actually a big deal. Developers love building for the web. The web is open by nature; there is no gatekeeper or app store that puts restrictions on what you do. You are free to publish what you want, and when you want. And your applications are also available instantly, no need to install applications locally, and available on every device with a web browser.

But seen from the users perspective, mobile web applications often give a sub par experience, because the web is lacking some very important features. When people want mobile apps they don't want desktop apps scaled down to work on a smaller screen. They want apps that are a lengthening piece of their own lives.

Some examples, Shazam can detect which song you're listening to by using the microphone in your phone. Fitness trackers use the accelerometer to detect if you're walking or biking. News apps send push messages when breaking news happens. These are all apps that are impossible to build on the mobile web. Until now.

Because Firefox OS adds new APIs for all the features in your phone, you can create web applications that leverage all these new techniques. And for the first time you can write mobile web apps that have the same functionality as native apps. And it doesn't stop at sensors, there are facilities for dealing with the SD card, push notifications, offline, etc.

STANDARDIZATION

And because Firefox OS is in essence nothing more than a browser running on hardware, these new features are implemented in the Firefox browser. A lot of these new APIs will therefore also come to Firefox for Android. And that's just the start. The goal of Firefox OS is to make the web a better place, so other browser vendors are encouraged to also implement these new features.

Therefore, it proposed all new APIs to the W3C (World Wide Web Consortium), the main standards organization for the web. W3C members include browser vendors, big Internet companies, governments, and non-profits.

The benefit of going through W3C is that vendors have a say in the choices Mozilla made and in the APIs it had implemented. W3C acceptance is very important and indicates a strong chance other browser and OS vendors will implement the API as well. If that happens it will also be possible to use phone-specific features on those platforms using one standard API. This is the reason one web site will work on all web browsers.

Standardization of new APIs does not happen overnight though, as people will use them as soon as they're available. Because of that it is important to get consensus across all vendors, as it's almost impossible to change an API. But there already has been progress. For example, the W3C has accepted the API to vibrate the phone and the API to show notifications in the OS. And now they work in Chrome for Android as well. And that makes the web as a whole a stronger alternative to native.

More information

If you'd like to learn more about the architecture of Firefox OS, how we do process isolation, and how we route SMS from HTML all the way down to hardware, check out my talk at Simonyi Konferencia.

For information on how to create applications for Firefox OS you can get my book (remember 'dotd082714au'), or watch the free video series me, Sergi Mansilla and Christian Heilmann made called App Basics for Firefox OS.

About 9 months ago an acquisition editor from Manning Publications first approached me, asking whether I was interested in writing a book about Firefox OS app development. Being a contributor, module peer for keyboard, and evangelist for Telenor, that actually made sense. Even when almost everyone in my environment that ever wrote a book said: "Yeah, it sounds fun, but actually its horrible". In a way they were right, especially the start was though; but during the process I actually had more and more fun. The fruit of the labour has now been bundled in an early access version of my book "Firefox OS in Action".

So if you're interested in getting started on developing apps for Firefox OS, get a quick start and buy the early access version. New chapters will be added when they are done, and you'll get the final and fully edited copy when it comes out. To put it in the words of a reader:

Thank for writing a great book. I read the "Welcome to the Future" part of your book it is just awesome. Every developer who want to develop app for Firefox OS is confused and don't know how to start. I think this book provide a content at one place and clear the all the doubts of developer. Information about UI is also great. I am eager to read your whole book.

BUY BUY BUY! And if you don't care about Firefox OS, just buy it for the beautiful images that I created in paint for the early access version. I'll also buy you a beer when you're in Amsterdam.

Plus it's the deal of the day so you get 50% off today with code: dotd072914au

If you're an avid smartphone user there will be times when there is behavior on your phone that just doesn't make sense, and that annoys the crap out of you. Well, you're not alone! Same thing happens to me, and I'm even a full time developer on Firefox OS. One of the things that bugs me the most is the behavior of the address bar in the browser. When you scroll enough down, it will disappear, but the content jumps up under your finger. And content jumping is the @#*&*#@&#&$ annoying.

Time to fix it!

So Firefox OS is built on top of open standards, HTML, JavaScript, blah, blah, blah, but the only real important thing here is, is that every (system) app is built on top of web technology. And thus, it's not compiled. That's actually pretty cool, because what I could do is grab the source code of the whole frontend of the OS; make changes; and then push to my phone. Sure. But that takes long, and maybe you miss a build prerequisite, etc. Luckily, because the browser app is basically a website, we can just pull the app from the phone and edit it.

Chances are that if you have a large javascript application that you'll need an EventEmitter at one moment or another because events are great to wire separate modules together without them having to expose implementation details. Too bad that you'll need to pull in dependencies, another library, extra risk, etc. Especially if you're testing some simple scenario or small app that's a lot of boilerplate. Behold: a dependency-less event emitter (1 line of javascript!):

JavaScript:

1
2
3

functioncreateEventEmitter(){returndocument.createElement('div');}

All DOM elements implement DOM Level 3 events, which you can abuse as a nice event emitter. Great thing is that you get cancelation and bubbling as well. Bad things:

It's about 5x times as slow as EventEmitter.js (source), but you can very easily swap out this by EE if required in a later stage.

Dispatching events is a bit cumbersome because you need to use this syntax: `new CustomEvent("eventname", { detail: "eventdetail" })`

Every now and then I end up in a code base where I don't have a clue about the flow yet; like today when testing out the new keyboard application that we're developing for Firefox OS. To see whether the flow is actually sane I plug in a simple function logger that allows me to see which functions are called and with what arguments.

JavaScript:

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

functionlog(args){varSTRIP_COMMENTS=/((\/\/.*$)|(\/\*[\s\S]*?\*\/))/mg;// stole this from http://stackoverflow.com/questions/1007981/how-to-get-function-parameter-names-values-dynamically-from-javascriptfunctiongetParamNames(func){varfnStr=func.toString().replace(STRIP_COMMENTS,'');varresult=fnStr.slice(fnStr.indexOf('(')+1,fnStr.indexOf(')')).match(/([^\s,]+)/g);if(result===null)result=[];returnresult;}console.log(args.callee.name,getParamNames(args.callee).reduce(function(obj,k,ix){obj[k]=args[ix];returnobj;},{}));}

Now you can take advantage of this by putting a call to this function on the first line of any function you want to trace:

JavaScript:

1

functiona(b,c){log(arguments);}

When calling the a function, it will log the function name and an object with argument names and values:

JavaScript:

1
2

a(4,5);// a { b: 4, c: 5 }

Remember to disable "use strict" because accessing callee is not permitted anymore.

About

Weblog of Jan Jongboom. Currently Developer Evangelist IoT for ARM, before that Telenor, Firefox OS, Cloud9 IDE, funda. I publish a lot more than is listed here, an overview of all my posts can be found at blog.janjongboom.com.