The Gathering (TG) is one of the largest nerd fests in the world, and this Easter no less than 5000 computer enthusiasts will gather in Vikingskipet at Hamar (27th - 31st of March). Of course Comoyo will be present at TG with a team of developers to act as mentors, scout for talent and get feedback on the stuff we’re working on.

The Gathering 2009

(Foto: Eirik Solheim /, 2009)

The future of apps

As our avid readers will know, Comoyo have set up a team to work with Mozilla on developing Firefox OS (FFOS). The first phones with FFOS will be launched in Telenor’s markets in Eastern Europe in second half of 2013. To make sure there are lots of cool apps for FFOS when the first phones launch, we want to encourage app developers to experiment with making HTML5 apps that run on the OS. Since most developers already know how to build stuff in HTML, the road to building web apps is very short.

Mozilla CEO visits Comoyo Mozilla CEO Gary Kovacs visiting Comoyo in February 2013.

Make HTML5 app, win a Geekphone!

So, we want to use our presence at The Gathering to teach young developers how to create apps with HTML5. We have therefore announced a competition, where TG participants can battle by building the best HTML5 app for Firefox OS. Ten winners will receive a Geeksphone, a phone specially designed for developers, by a Spanish start-up company where the founder himself is a 20-year-old.


Useful Phone Utility Compo - How do I participate?

To make it easier for you to get started, we have made this blog post about how to make your first web app in 5 minutes!

Also, here is the official compo info at

Criterias for judging entries: To be truly useful, an app must make the life of the user more fun and/or simple. The app should showcase cool things that can be done with HTML5 in combination with native phone APIs. Plus for apps which has a global market potential. We have a sense of humor, and appreciate crazy ideas.

Hand-in: Entries must be delivered through the web-based compo system of TG. If you really want to make us happy, please hand in a ZIP or RAR file containing the entry itself, and a short text file (file_id.diz/.nfo/.txt) with information about the entry as well as contact info.

Originality: You have to make your own entry. This means that handing us a link to is not valid, and the same goes for any other software you have not made yourself.

Deciding a winner: The winner will be decided by a jury consisting of the Comoyo Data Boys, and Creative Lounge crew members.

Allowed languages and platforms: Your app must be developed in anything that compiles down to HTML5/Javascript/CSS, and must work on Firefox OS. You can test the app in the Firefox OS simulator, that can be downloaded as an add-on to the Firefox browser.

Deadline: Apps must be submitted by Friday 29th. before 23:59. Feel free to start developing apps before TG as well! Send us an e-mail if you get stuck.

Meet Comoyo at The Gathering

6 developers from Comoyo will be present during TG, and will be available for mentoring in making HTML5 apps and discussing our products. E-mail us if you wanna meet up!

Btw, if you’re not going to TG, you might be interested in knowing that we’re hosting the first App Day for Firefox OS in the Nordics, as part of the Web Rebels conference on May 25th..


Let’ssssssss get ready to rumble! In this 5 minute introduction we’ll get from zero to hero in building a Firefox OS application. Why is this cool? Well, not only is it fun and easy to get started; you can re-use your existing skills as a HTML/CSS/JS wizard, but it’s also an opportunity to witness first hand what the future will look like.

Basic principles

An app for Firefox OS is a mobile website. Nothing more, nothing less. However, to build quality apps we need to add features like offline support, and access to certain phone APIs. This is where Firefox OS comes in. A bunch of new APIs have been introduced that address the incapabilities of the current mobile web. The wonderful thing is that it’s still ‘just a website’. A website that you can also visit on your iPhone or Android device. Just for features where you need access to one of the new APIs Firefox OS gives you an edge. Just like you can create rounded corners in CSS3 that will graceful degrade in IE7.

Getting the developer tools

To get started on Firefox OS apps you don’t need a multi-gigabyte toolchain (I’m looking at you XCode!), but rather the Firefox browser, and the Firefox OS Simulator that runs as a browser plugin.

After installation go to ‘Tools’ -> ‘Web Developer’ -> ‘Firefox OS Simulator’ to get into the simulator dashboard. One little toggle of the switch here will spawn up simulator and you can experience Firefox OS first hand.

Simulator location in menu

And now getting that first app up!

So let’s get rolling! We can either start of with one of your existing mobile websites, but we can also (kinda) start from scratch by building upon an existing template. For now we’ll be using ffos-list-detail; a Comoyo built application template that shows a super simple mobile app powered by AngularJS and bundled with the same UI library that powers all system applications.

First things first. We need node.js.

Now execute the following commands in the terminal (or cmd.exe on Windows):

# Clone the template repository
git clone
# Grab the UI library
git submodule update --init --recursive
# Install server side dependencies
npm install

node server.js

We now have built a bare bone application that is excellent at showing a list, and showing a detail view! Go in any modern browser to http://localhost:8081 to see the app galore!

The app running in Firefox on the desktop

Running the app in the simulator

The ‘/www/manifest.webapp’ file is one of the major things introduced by Firefox OS. It’s a file with information (icons, description) about your application. This file is being used to publish your app to the Firefox OS Marketplace or when someone installs your app directly on their phones. We can emulate this process in the simulator. In the right column you can specify the location of the manifest file and then install your app right away. Add the following line in the textbox and press ‘Add’.


Loading the app in the simulator

Your app has now been installed on the device. It will show up immediately in the simulator, or you can start it via the homescreen (swipe to the right). If you have updated your app, press the ‘Update’ button in the simulator dashboard to reinstall the app and see the changes.

Debugging! It’s as easy as normal websites!

There will be a moment that you want to debug your app. This is easy peasy via the simulator dashboard. When the simulator is running with your app in it, press ‘Connect…’, and immediately press ‘Connect’ again. You now have the normal Firefox developer tools available to do javascript debugging on the actual simulator.

Debugging an app running in the simulator from desktop Firefox

Of course you can always use a desktop browser to debug as long as you don’t use any of the WebAPIs.

And now: go and build!

We have an app set up, it runs in the simulator, and we even have a debugger attached. Time to add some awesomness to the soup!

  1. All available UI elements can be found on (and they will also run on other devices)
  2. You can reach phone capabilites via the WebAPIs that have been described on the Mozilla Developer Network, or for a showcase view the Firefox OS Boilerplate app.
  3. Also visit MDN to learn how to add offline capabilities to your app.

Happy coding!


Broken TV box

A couple of months ago my IPTV box from Altibox broke down. It had been bugging me for a long time with a slow user interface and, not to mention, a recording function that fills up all the time and takes hours to delete…

So out it went. And as I happen to work for Comoyo, a company that offers Internet based TV and film, it was time to fully and wholly eat my own dog food.

So, the first thing you need to know is that I am not a SINK or DINK (single income no kids or double income no kids). I have a family – a wife and two young children under ten. And when you have a family, you have to discuss and inform about things in a proper manner. In this case - about what just happened to the box and how the TV was going to work going forward. So what did I say?

“Ehh - the TV box is broken. We´ll have to use the iMac in our living room or connect the Mac mini to the TV screen. At least until we get a new box or…”

“What do you mean by ‘or…’”, says my wife (she knows me well..) “Well um, maybe, eh, if this Internet TV thing works fine we´ll just never use the normal TV again. And also save a lot of money”. Her answer: “Ok, but I think I’d need a remote so I can zap. So I want the normal box back”. I tried with: “hrmph, eh, well - we´ll see”.

This was November 2012. And now it’s February 2013. We still don’t have an IPTV box. Nobody asks for it, nobody misses it. I actually think if we turned it on - we would all get the creeps! (and Altibox one is one of the better ones…)

So what happened during those months?

Huge change in how we watch

The kids found it completely natural. They’re used to on demand or time-shifted TV. At 18:00 it’s traditionally time for children’s TV in Norway - but more and more it is not actually watched at 18:00. The kids watch it when they feel like it. And sometimes they substitute children’s TV with a game or a short movie.

For us adults we NEVER watch ANYTHING live except sports (and we very rarely watch sports). So it’s ALL on demand.

Unexpected change in where we watch

The plan was to have the Mac mini connected to the 37-inch TV screen in our basement. In addition – we had our 27-inch iMac on a shelf in the living room. It was used for games, surfing, working AND watching TV/ Film – especially shorter programs.

But this turned out to be a non-optimal solution!

Learning one: The TV in the basement would rarely be used. I don’t quite know why but perhaps the 37-inch screen didn’t feel much bigger than the upstairs 27-inch iMac, where our sofa was positioned closer to the screen. To be honest, this trend had already started before the IPTV box crashed. It could also be down to the fact that as winter approached, being together as a family in the living room with a lit fireplace was cosier than a cold basement. (Or perhaps the barrier of not having a zapper was it. Who knows?)

Learning two: One PC/Mac for all activities - INCLUDING watching TV and film - is not enough! Something will always develop into a fight in a modern home, even if there are several tablets, pads and mobiles. “I want to play my game on the big tv”. “I want to watch tv on the large screen”. Anything else is a compromise. So as it turns out, a kid can watch on an iPad but they would prefer to watch on a larger screen - like a 27-inch.

So what to do?

TV View from couch

This shows the solution we chose for now. The Mac mini was moved to our living room (the 37 inch TV is for sale if you want to buy it). I bought a fairly cheap 27-inch full HD IPS terminal, set it on top of a rolling Montana module, and put the Mac mini inside the module. The sweet Mac keyboard and glass mouse is on the living room table and when we don’t use the new ‘TV’ arrangement we just roll it out of the way so it stands discretely against the wall. Meanwhile, the 27-inch iMac stays where it was on the bookshelf (see in the background) and is used primarily for school, gaming and work.

This is how the new ‘TV’ looks inside:

TV Setup inside

But come on - not having a remote?

You may think that using a computer or a tablet is cumbersome and that our living room now looks like that of a teenage boy?

Nah! With a couple of twists it’s actually quite sweet (but sure – a remote would spice it up even more)

Let me show you some pictures.

This one shows how I set up the screen on the 27-inch iMac and the Mac mini that’s connected to the TV screen. I simply just dropped over URLs to the desktop. To get a nice icon is a little cumbersome on a Mac, but it’s really helpful, as my 5-year old can’t read.

TV Desktop overview

So what services are we actually using?

We have, as many other Norwegians, become heavy users of NRK web-TV and we use Comoyo TV and Film for more or less the rest. That would, with today’s price plans, come up at around 200NOK per month in addition to the broadband connection (not included the NRK licence). And that’s a very good deal compared to traditional offerings in the market! In addition we sometimes buy a weekly ticket on TV2 Sumo if we want to watch something special there.

And how is it working?

First of all, it works almost all the time. For a short while we had some hang up issues with NRK but the problem seemed to lie within the service itself. We rarely get low resolution on streaming - it usually hovers around 3 mbit/s. On Comoyo we usually get the max speed, either 5 or 8 mbit/s on HD. And we got a fat pipe - 60 mbit/s fiber with an 802.11n Wi-Fi network. I set up all my devices to prefer the 5 Ghz Wi-Fi.

From a usability point of view, passwords and usernames on the different services are a hassle. Especially the ones that has a time-out on user credentials. The ones that don’t have time-out help lowering the barrier for both my wife and my kids to use that service.

So, I recommend getting rid of the TV box. Cut the cord. It’s easy, fun, cheap and cool!


Boy, everyone is stupid except me

Sometimes, I look at where the Java developer community is heading and I think to myself: “They’re all doing it wrong!”. This leads naturally to the follow-up thought: “Or am I the only one not getting it?”

This time, I’m surprised by people’s affection of IoC containers. Spring, for example. I don’t get it. What problem is that solving? Before, we used to wire our application together in the main() method. Now, apps are wired using long, unreadable XML files, and if there’s a typo in it, you won’t know about it until run time. What was wrong with main()?

Use the compiler, Luke

The same principles spread out to other Java software as well. Take Jersey, for instance. You don’t give the Jersey server a set of resources to host. Oh no. You give it a Java package name - a string – and then Jersey searches that package for classes that presumably are resources it should instantiate and host. Jersey finds them (or not) at run time. Hopefully, your program works when you launch it.

To quote the Wikipedia article on IoC: “[…] object coupling is bound at run time by an assembler object and is typically not known at compile time using static analysis.” So, what reasons are there to do the coupling at run time, and why do people accept losing the static analysis of a compiler? I can think of one such case: Plugins. When you are developing a system where you want to be able to add or remove plugins without restarting your application. So if you’re developing a browser or an IDE, you might need support for loading code into your runtime dynamically (although this has little to do with IoC, really). But how many of the world’s Spring-based projects have this property? My Jersey-based REST service certainly won’t support adding new resource classes at run time. If I need to add a resource class to it, I’ll statically build a new release and redeploy the binary. I know up-front what parts should make up my application, so why would I want to do the coupling at run time?

When I browse code in a new project, I want to see how stuff is wired together. “Who instantiates this class, and when?” The IoC container approach leads to code that is “detached”; you can see a class being active at run time, but you can’t see a single code line in your project actually mentioning that class. You don’t know the instantiation order, the lifecycle, nothing. You simply don’t have control.

Wisdom of the crowds

Googling the web for answers, it seems to me that people confuse IoC with DI - Dependency Injection. It’s all over stackoverflow if you look. People ask what IoC is, and they’re shown an example of DI. People are taught that to do DI, you need an IoC container.

Don’t get me wrong

I’m all in favor of DI. I use it all the time. I easily inject mocks, test units of code in isolation, with minimal plumbing and setup time - all without a container in sight. And I wire the program together in the main() method. You can figure out what my program does from start to end solely by reading Java code, and you don’t have to switch contexts or make assumptions to understand how it works. So I’m not against the concept of inversion of control in programming as such. I’m against the container approach that people tag onto the concept.

There’s no configuration like code

I’d argue not only that IoC containers are unnecessary for DI and testability, they’re even harmful: Most of the out-of-the-box container injection I’ve seen is inherently static, meaning they have a one-instance-fits-all ideology. Dependencies are only declared by type, so there is this assumption that different instances is not an issue. If Foo needs an instance of Bar, the container might use a BarProvider or BarFactory (that it also locates at run time - bleh!) to create an instance of Bar and give it to Foo. But what if there’s a Baz that also needs a Bar, but not the same Bar that Foo got, but one that is configured differently? BarProvider doesn’t know much about the context in which it is being called - whether it is asked to make a Bar for Foo or Baz. Now suddenly the looks-good-on-a-slide IoC container usage example doesn’t look quite so beautiful anymore. Enter ugly config files with something that looks suspiciously like code with conditional logic encoded into XML. It’s a DSL, another special-purpose language and framework you have to learn. What was wrong with Java as a programming language? What’s more flexible than main() as a place to declare initialization order and inject dependencies?

Sure, IoC containers may be viewed as a tool to turn imperative setup into a declarative setup. And declarative is better than imperative, right? Many times I agree. But a Java program is unavoidably imperative, and when you introduce a framework to make a small (but important) subset of your program declarative, you’re not only increasing complexity, you’re mixing paradigms. This adds a lot of WTF-ness to your program.


As all mobile developers should know Weinre is the best thing to have happened to mankind since American Idol got cancelled. It allows you to connect the Chrome Debugger Tools to a remote mobile device and use awesomeness like Element inspection, CSS manipulation and javascript execution to do debugging on steroids. No more alert style debugging your mobile websites. Speed++.

On the other hand Firefox OS, the best thing to have happened since the invention of in-plane WiFi (guess where I’m writing this blog post), lacks a proper way to debug applications after deploying them to your shiny new phone.

By combining these two facts, plus given that the Firefox OS UI layer is completely written in web standards, it’s only natural that we at Telenor Comoyo (ok, ok, Kevin Grandon came up with the original idea) started hacking on superawesomeincrediblegreat integration of Weinre and Firefox OS. That means: live viewing and manipulating your app markup; live editing of styles and live code injection. All from your desktop and directly accessible on your developer phone. Now try that on any other mobile platform. But Jan, how do we know that it actually works? Well dear folks, here is a video:

Great, I want it!

Sure, here’s how you’ll get started:

  1. Install node.js
  2. Install Weinre via npm install -g weinre
  3. Start Weinre via weinre --boundHost -all- --httpPort 9090
  4. Check out the Comoyo build Gaia, the UI library for Firefox OS (git clone git//
  5. Build Gaia with the Weinre extension: WEINRE=your.internal.ip:9090 make
  6. Grab the Firefox OS system
  7. Now start the emulator from your Gaia directory: f.e. on OS/X: /Applications/ -profile $PWD/profile
  8. Go to the Weinre debug interface on your workstation and see the magic happening.

When you’re ready to debug an application, add the following line to your index.html and restart the emulator:

<script src="shared/js/weinre_app.js"></script>

Lessons learned

For 15 years we built software to develop, design and debug on the web. It’s incredible to see that we can leverage all this existing technology and integrate them into our Firefox OS build chain with hardly any effort. I you had any doubt whether Firefox OS was the number one choice for developers, this is the moment for you to reconsider.

This debugging process has also been written up by Mozilla