Blog Posts

Recently, we had a hackday at Liip, where we dived into game development with JavaScript. Our goal was to see how hard it is to produce a simple cross platform game using just JavaScript and HTML5 elements. Since we didn't want to reinvent the wheel, we decided to use a JavaScript game framework.

To make it short: we were very impressed at the state of the different frameworks around. We were able to put together a simple game in a suprisingly short time. Check it out here! (Thx to Chrigu for letting us use the graphics of his awesome iPhone game Herbert, the misanthropical fly).

Technical details

We developed our game using ImpactJS, a high-level JavaScript game framework that did a lot of work for us. While we briefly looked at some alternatives like Crafty and LimeJS, we didn't want to spend our time comparing libraries but get our hands dirty. We went with ImpactJS simply because Chrigu had already looked into it a bit, and because of their awesome demo game. The downside of ImpactJS is the fact that it's proprietary, though it's well worth the price of 99$.

In ImpactJS, one generally has three different types of objects: screens, levels and entities. Screens control the different game states. For example you could have a settings screen, a highscore screen and an actual playing screen. Because your game (unlike our demo) probably has different levels, there are simple JSON files that describe how a level looks and can be automatically loaded by ImpactJS. Background images, collision maps and entities are placed in there. Finally, entities are all interacive objects: The hero, enemies, coins, bombs and so on. Entities are distributed over the level, they are animated and interact with other entities.

In our case we put together a startscreen, the main screen with a level map behind it and an endscreen that appears when one accomplished the level. Within the game we have our hero entity, whose goal it is to navigate through the map without hitting enemies or walls. He also wants to pick up coins. Coins are entities as well and can be picked up by the hero increasing his health a little. When the hero hits a wall or an enemy, he loses health. Of course, these actions are accompanied by sounds. The hero, enemies and coins are animated, which is achieved by simply looping through different frames in a sprite sheet.

Our Experiences

- ImpactJS does a lot of work for you. It handles animations, collision detection, scene management, controls and scrolling of the screen

- ImpactJS is documented very well, and there seems to be an active discussion forum on their website

- The level editor bundled with ImpactJS ("Weltmeister") makes it very easy to set up level layouts fast. That said, the user interface isn't always intuitive (right-click to drag around the map, press space to insert something) and the level editor sometimes feels buggy

- We had quite some issues with the playback of sound, since there are still several tricks needed to have sound working in a wide range of browsers. We did not get the built in sound manager of ImpactJS running properly. We instead used SoundManager2 but we still had to do a hack to get it to work on iOS devices. The problem is, that iOS won't start the download of media until there is a user-input event, so we just required the user to touch the screen, before the game can be started

- Porting to mobile phones or tablets can be achieved by simply wrapping the game in Phonegap, but we weren't sure how to deal with different screen / viewport sizes and resolutions without making the game look distorted or blurry

- Performance was surprisingly good, even on mobile phones. That said, on an iPhone 3G, we only reached 30 FPS, which is the "lagging limit". So a game that has more elements would probably need performance optimisations in addition to ImpactJS

- We played around a bit with different ways to navigate, including using the accelerometer or touch gestures, but didn't get much support from ImpactJS in that regard

Overall we are very happy with the outcome and we are impressed, how fast a simple game could be put together. Have a look at the source code to see how straightforward it was. ImpactJS helps a lot in handling the interactive parts, allowing you to spend more time on the look and feel, which is one of the key factors for games. We're all looking forward to using ImpactJS on a customer project, but also to playing around with free alternatives and seeing if they measure up to the high bar that ImpactJS has set!

Alain, Chrigu, Colin

The Tages-Anzeiger TV-Sélection iPad app has been available for download in the Apple app store for about a week now.

Huh?

TV Sélection is an app that lets you watch TV shows on your iPad. The focus is on shows in four different categories, hand-picked by the arts and entertainment editorial staff of Tages-Anzeiger, one of Switzerland's biggest newspapers. At the same time you can watch any other show on a wide range of channels by using the search functionality, with just a few minutes delay from the time it airs on TV.

NIWEA!

From a technical point of view, the app was implemented completely using Javascript, HTML5, and CSS, and wrapped as an iPad application using Phonegap. While we didn't take advantage of Phonegap's big selling point of being able to deploy the same code to multiple device types, being able to use HTML/JS/CSS played to our strengths. The other advantage though, was that we were able to develop and test large parts of the app directly in the browser, without having to constantly rebuild the code and run it on the device or a simulator. And that right there is the concept of NIWEA - writing code that can be re-used with no or very few changes across multiple platforms.

Where NIWEA breaks

When you're running on a device you want to take advantage of that devices native functionality. That may be the camera, accelerometer, or contacts. In our case we had three use-cases: We wanted to show notifications when not in the app, we wanted to use the devices keychain to store login details a bit more safely, and we wanted to take advantage of the fact that millions of users have their credit card information saved in their iTunes store account. We were able to do this by using phonegap plugins, one for local notifications, another to access the keychain and a third to handle In-App purchases.

And that's where the NIWEA concept cracks a little. Since these plugins rely on Objective C code to interact with the system, that functionality won't work on other devices. In some cases there may be plugins for your other device as well, and you can drop them in with little or no changes. In other cases you may have to write your own plugin, or just not offer all the features on every device. Since, again, we were only building for the iPad we weren't impacted much. We wrote a quick mock to simulate the keychain using cookies so we could continue testing in the browser. The missing local notifications hardly impacted us, and In-App purchases ended up being easiest to test on the device itself.

Look ma, no server!

While Phonegap was new to everyone on our team, it wasn't the only interesting thing from a technical point of view. One of the limitations of the whole project was that everything should run on the app - there is no backend, there are no servers.

OK, that's not entirely true - we access the tv shows and playlists through a (non-public, sorry) Zattoo API. We didn't control this ourselves though, and so anything that needed server-side code had to be planned and coordinated with Zattoo's developers. Since this obviously generates some overhead, every feature was examined to see how it could be done without requiring a backend. Want to send an email with debug information? Instead of sending it from a server, use a mailto link to open the iPads Mail app with some prefilled content. Want to use Push notifications to let the user know when his license expires? Sorry, push notifications require a server, but we can use local notifications instead, we just lose some flexibility because we have to trigger them when the subscription starts. In-App Purchases? There's a bunch of back-and-forth between Apple's servers and a callback URL to verify receipts and such - in this case Zattoo ended up extending their API to handle Apple subscriptions, with us simply passing on the receipt data we receive when the purchase is made.

More fun stuff

Other interesting details: We used WebSQL to cache the shows locally and allow you to save shows in your favorites. Probably because the WebSQL spec isn't being developed further there isn't a lot of documentation on what SQL operations you can actually use with it, so that was a bit of trial and error. Also, having database calls be asynchronous just seems like unnecessary complication.

We used the HTML5 video tag to display the video stream of the show. In general this works fine, but one thing to note is that if you use the default iOS media player instead of building your own controls, you lose the possibility to catch javascript events on the player area. For example, we were able to catch the touchmove event everywhere on the page to prevent you from being able to scroll/drag the page up and down, but we weren't able to prevent dragging on the player interface.

Finally, we used YUI3 as a javascript framework, where the main thing worth highlighting is the ScrollView module, which handles the vertically sliding list of shows. This worked well, but as the scrollable area grew, we did start seeing performance problems. To resolve this we decided not to display shows older than 30 days, which made scrolling much less jumpy! The other awesome feature of YUI3 which we used, and missed while using jQuery in another project, is the possibility to set dependencies when loading a module. The module will then wait to be initiated until all the required modules are loaded.

Let me at it!

Go ahead! The app is available for free in the App Store, and you'll receive a seven day trial in which you can watch any show. Unfortunately, you'll only be able to watch the shows if you're within in Switzerland due to licensing restrictions.

• - Rotation & Calculation issues
• - App Resume
• - Offline availability
• - Singlepage Problem

Rotation & Calculation

• - URL bar hidden
• - URL bar out
• - URL bar overlapping (during a request)
• - Carrier bar overlapping in Add2Homescreen (standalone) Mode

 window.scrollTo(0, 1) 

 if (true === window.navigator.standalone) {

     winHeight -= 20;

     Y.one(#content).setStyle('marginTop', '20px');

 }

Rotation

Singlepage

App Resume

Scrollviews

 .scroll-x, .scroll-y { 

     -webkit-overflow-scrolling: touch; 

 }

Offline availability

Tools

Simulator

iWebInspector

Retrospective

I waited with this blogpost until slides and videos became available. Now it seems that they all are here.

A collection of slides you can find here: 
https://gist.github.com/1256066

Also the videos are online. Check them out:
http://blip.tv/jsconfeu

Each talk on the ground floor was illustrated by Anna Lena Schiller. The results are awesome! And keep in mind that she often had no clue what the speaker was talking about:
Flickr Link

The Conference

Quite some folks of the javascript community came together in Berlin on the 1th and 2th of october 2011 for the third time. With over 200 people from all around the world and around 37 speakers to various topics. There were not only well known faces but also quite a few new ones and the different topics were spread wide. From traditional website usage over javascript game development to insane crazy stuff to things everyone can use/participate. JSConf.eu has something for everyone.

It was an amazing conference and we had a damn good time over there. The conference comprised two days of talks, each followed by a big party to meet and exchange with the others.

The Talks

And while I was enthused by all talks, I like to name my personal favorites.

This is not just about the content of the talks, it is also about how the speakers presented their talks and if they were able to fascinate the audience.

- Community JS reloaded
how to rock as a movement

- How to be an open-source gangster
How to succeed in open-source by embracing the ancient art of gangster rap... Keep it real!

- 140byt.es: Building a web framework, one tweet at a time
Very impressive ways of reducing the code in javascript snippets. Nothing you really want in a real project but very sexy to show off.

- Beyond JavaScript
A new way of looking at programming languages. Whether javascript or something else ;)

- Messing with JavaScript and the DOM to measure network performance characteristics
Interesting talk on how to measure network performance characteristics with javascript. Things like bandwidth, latency, TCP connect time, DNS time, IPv6 connectivity, port scanning.

Not just the conference

After the conference our team took two days of vacation, to use the chance to be in Germany’s capital city. We went to explore the city. These days were in no way computer related and I would recommend it to everyone. Its a very good team experience and you got some time to think about what you just listened to.

Thanks!

At this point I like to send a big “THANK YOU” to the folks of jsconf.eu, for organizing such an awesome event. But not just to the jsconf organisation team, also to everyone who joined and made it to such an awesome experience.

And last but not least. Many thanks to L//P for cheering up their developers to such things by providing them an education budget.

Keep it real!

Yesterday we started working on an editor for the Symfony2 Content Management Editor, the LiipVieBundle. We use VIE and - until something non-GPL comes along - the Aloha editor. VIE is a piece of javascript on top of backbone.js that handles storing data with a REST backend. In Symfony2, this is a breeze thanks to the FOSRestBundle. Sounds complicated? Its actually quite simple, at least for the user. I made a short video to show how it looks.

You can try this out in the CMF Sandbox. Currently, its just a proof-of-concept implementation. For example, we make no authorization check whatsoever. In the upcoming weeks, we plan to do the following:

• Only activate VIE if the user has the required role (inject an authorization service into the VieController)
• Support authorization service in REST controller
• Image insert feature in aloha
• Find a way for developpers to configure what editor to use for each field
• Support binary fields / file attachments
• Autosave while editing to not lose data on connection errors

If you have feedback or inputs to this, please tell! And if you can contribute, you are more than welcome to do pull requests or comment on commits. Whatch the LiipVieBundle and the sandbox to see what is happening.

We already hosted a well received and interesting YUI3 introduction training. You can read about it here.

We will host a training about the "YUI Building Blocks"  in a half day workshop on the 9th of June in Zurich. This workshop will take place twice once in the morning and once in the afternoon. They are open to the public, please get in touch with us if you want to join. Places are limited, first come first served.

Sometime in July we will host a full day of YUI3 training which will repeat the introduction and the building blocks workshops. This will only take place if enough people are interested so please leave a comment.

Earlier this year one of my colleagues told me during the daily scrum that he plans to attend the PHP conference PHPDay in Verona, Italy. I thought that was an excellent idea and bought a ticket the same day. It turned out that at the same time and place also the JSDay would take place, the first Javascript conference in Italy ever. That was just perfect since so far I was always a little scared of writing Javascript because I had basically no experience in doing so. I'm not saying that I became a Javascript expert just by attending a JS conference, but I surely learned a lot :-).

JSDay

PHPDay

Caching

RESTful web services

Profiling your PHP application

Conclusion

Earlier this year I was invited to speak at the Linuxwochen in Vienna first in May. The Linuxwochen is a conference taking place in different time slots at different cities in austria. Besides Vienna these are Graz, Linz, Krems, and Eisenstadt.

This years Vienna conference was hosted by the FH Technikum Wien, not only providing the accommodation and infrastructure for the conference, but also a very stable and reliable wireless network which is not too common on conferences.

What did I talk about?

PHPUnit

I was asked by the organizers to talk about PHPUnit. Preparing the talk I thought about bringing some lesser known features, assertions, and annotations to the audience attention. Starting with a selection of command line switches (like --filter, --group, --testdox) I pointed out that some switches only work in combination with previous set annotations and how to use them in a clever way.

This brought me directly to the annotations part. This section of my talk introduced the usage of annotations and highlighted a number of imho most useful annotations provided by PHPUnit. So do the @ticket or @group annotation relate a test directly to a ticket inside of an issue tracker if the value of the annotation is the identifier of the ticket provided by the issue tracker. Using the --group switch, only the tests registered in the requested group are run. This makes it very easy to verify if the bug had returned or not.

In the third section of my presentation I spend some time on some well overseen assertions of PHPUnit. Since I am a big fan of XML/XSLT and the Document Object Model in general, it was a pleasure to find out that PHPUnit has quite a number of assertions verifying the XML string or DOM-object returned by a method or service. Per example expecting two DOMNodes, assertEqualXmlStructure() is able to identify the differences between them and shows them in a diff-like report. By providing true as the third argument, this assertion will also take the attributes into account. This makes it very easy to spot changes or inconsistencies in the response.

Last, but not least I talked about different ways to test for expected exceptions. Therefore I showed some tipps and tricks using the mocking library of PHPunit.

JavaScript/jQuery

As usual on conferences some speakers get ill or cannot attend on short notice. This is were Jakob Westhoff and I were asked to talk about something JavaScriptish. After a short discussion with the audience we agreed on talking about some of the features of jQuery 1.6.

Having no slides we improvised using the provided black board and chalk in order to make things more clear to the audience. It turns out that this is definitely a way of presentation I should do more often ;)

In our presentation we spent most of the time explaining the concept of promises, futures, and defers. This fantastic concept to make asynchronous request ways work together is actually an old one, but was raised again by the commonJS group back in 2009.

This concept makes it very easy to manage asynchronous work paths of your script and, which is the best part, make race conditions disappear. It would be too long to tell you all about the concept right now, but for further reading the commonJS specification is a good place to start.

Will there be a next time?

Certainly. I had so much fun meeting and talking to really nice people and since the Linuxwochen are an annual event I think I will be back next year. Keep up good work fellows!

The Flash way

The JavaScript way

Conclusion