Game development with JavaScript

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

Tags: , , ,

Applying Niwea: TV Sélection iPad app

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


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.


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.

Tags: , , , , , , , ,

Exploring the Internet of Things at the “Digitalstrom Hackday”

The Internet of Things is currently being talked about a lot as the next big thing.

A group of Liipers participated in the second digitalSTROM Hacker day in order to get some hands-on experience of what the future beholds in the world of web enabled “smart devices“.

Introducing: was founded in 2007 at the Swiss Federal Institute of Technology Zurich (ETHZ) as a non-profit organization. The goal of the organization is to establish the digitalSTROM technology as a standard to allow networking of electrical devices.
The core of the digitalSTROM technology is the dS micro chip. Each electrical device that is equipped with a dS chip is turned into a “smart device”.
The smart devices communicate with one another over existing electrical wiring. Thus, it is possible turn an existing electrical network into a digitalSTROM network, without additional cabling.
In order to achieve this, you need a dSID chip for each device, fitted by the way of an electrical connector (dS terminal block), and a dS meter for each electrical circuit, fitted into the fuse box. All devices within an electrical circuit then become “addressable”, allowing them to be turned on and off, and dimmed, from any dS-enabled switch. Each circuit equipped with these components allows for some base functionality. For example, triggering pre-defined lighting “mood” configurations.

The base system can be extended by adding a dS server. The server acts as a gateway and allows networking between dS meters (i.e. communicating across electrical circuits). The dS server opens up the playing field for many new applications. For example, it’s possible to monitor the power consumption of all individual devices within a complete household, in near real-time.
The dS server (dSS) also provides a web server. Thus it’s possible to connect the “smart devices” to the local network or to the internet, allowing (secure) bi-directional communication to any device. The software of the dS server is available as open source (GPL, dual licensing). The dS server provides a SOAP web service interface, as well as a HTTP based JSON interface.
Thus, developers can use their existing know-how to build new applications, e.g. for controlling household appliances via smart phone.

digitalSTROM Hacker Day

Six Liipers participated in the second “digitalSTROM Hacker day” on July 12th.
The event was an opportunity to learn about the digitalSTROM Server, exchange ideas and experiences, and to experiment with the digitalSTROM hardware, which was provided by aizo for the duration of the workshop.

The event was kicked off with four presentations about the dS server, the AccessHUB, the dS development kit, dSS JSON Interface and an introduction on how to develop dSS applications.

Brainstorming Innovative Ideas for digitalSTROM

Over lunch, we talked about how to make best use of this exciting new technology. Someone from aizo mentioned the potential of the digitalSTROM-Standard in the management of power peaks, e.g. programming washing machines to run only during times of low power demand (at reduced energy costs).
It occurred to me that we could leverage the collective brain power of the workshop participants to come up with inspiring scenarios for the hands-on experimentation with the digitalSTROM development kits. I spontaneously volunteered to run a 3-12-3 Brainstorming session. The participants came up with some interesting use cases, e.g.:

  • A monitoring and alerts scenario: metering the power consumption of devices in a building and reacting on anomalies.  For example, a fridge has regular peaks of power use during cooling. If no peaks are measured during a certain period, this could trigger an alarm (e.g. send an sms alert) that the fridge might not work correctly.
  • A holiday housing estates scenario: The occupants of holiday resorts frequently change. The resort caretakers could centrally switch all appropriate devices – such as lights and heating – on just before the occupants arrive (and switch everything off after departure).

After each group presented their ideas, we spent the rest of the afternoon experimenting hands-on. Most people opted to build a small web app, communicating with the digitalSTROM Server via RESTful web service.

The aizo folks and the developers from the community proved to be great hosts, answering our technical questions, providing personal tours in the aizo show room and discussing uses of the technology.

Conclusion from a Business Perspective

For individuals, the digitalSTROM units (dS meters and dS server) are still too costly compared to the potential energy cost savings (since energy cost is still very low).
However, home owners and tenants benefit from the flexibility of the system. An electrical engineer can reconfigure the power network layout electronically, without costly change to the physical wiring.
For developers, the digitalSTROM system has a very web developer friendly architecture and the dS server software is open source. On the downside, the dS hardware seems (still) too expensive (for hobbyists) and is not open sourced, which might limit the adoption by technology enthusiasts and tinkerers.
It is clear though that there are lots of possibilities for innovative applications. May it be in the area of power metering as a learning tool (i.e. becoming smarter about power consumption), remote control of home devices (e.g. via smart phone) or home automation.
It turns out, with digitalSTROM, the vision of the Web of Things is already part of reality.



Barcode reader Hackday

Last 10th of february we had another opportunity to organize a Hackday to find out how we could use a mobilephone camera as a barcode scanner.

The goal was not to have a finished implementation by the end of the day but rather to get knowledge about how to proceed and have an overview of the possibilities and available opensource products.  Adrian Schwaller was really interested about the outcomes of this hackday as he wanted to know how much work would be required to implement such a feature for a customer’s existing application. Other goals were to make it usable from a NIWEA application using PhoneGap.  Which means that basically your PhoneGap application should be able to use the embedded camera’s phone to take a picture, process it and extract the encoded information from the barcode then return it back to the calling application.

As we were near to clueless on the topic, we knew lot of time will be spent on investigating, gathering information. Instead of trying to do it in an organized manner by forming group focused on dedicated topic, we opted for a more bazar working style. Pierre proposed that we should spend the whole morning working independently one for each other and in any direction of our fancy. Doing so allowed everyone to investigate in what was appealing to him and then people gather themselves in a natural fashion. This allowed us to cover lot of different approaches and libraries/technologies in a very short time.

It also let us naturally form groups wich was a great experience.

Down below is a list of the things we came across:

Free barcode scanner: contrary to what the name implies, this one is not free at all. You will have to pay for it. Asking 2$ per scan seemed highly priced to us so we dropped it quickly. 

Quickmark: was really appealing to us after trying it for few minutes. The speed and recognition rate were really good. There again it was not free.

Redlaser: seemed also to be quite good. One has to pay for it but we couldn’t find any documentation explaining how to use it. 

Iscandit: suffers from the same problem as earlier contender. No download to be found on the website, no documentation and no pricing nor licensing information. As Bastian found out, it’s currently only available in the US. Europe is comming soon. If we would have had more time we could have contact developers and problably get more information.

Few days after announcing the hackday, we received emails from Liipers proposing ways to address the problem. Somebody suggested that we could just take a picture and send it off to a webservice for processing.  Although the idea seems to be good we had to discard it quickly. We knew in advance that this way won’t fit our needs because following two main reasons
– Working with a webservice gives a pretty long latency based on the network connection so we would use up more time for transferring the image or the image stream
– The application is not usable without network connection

Brian pointed us to the Zxing library which is a Java library for barcode recognition. This seemed to be really good and on top of that as it was written in Java, an Android version of it was available from the project home page. There was also a Obj-C/C++ port available but that one only supported QR-code barcode and was not active anymore.

We (Bastian and Jean-Christophe) thought that we could actually cross-compile Zxing to Objective-C code so that it could be used on iPhone. We found that such a cross-compiler existed already, xmlvm. After installing it we managed to produce the Objective-C code without any problem. But then when we imported the code into XCode and try to compiled it we were faced with a daunting number for compilation errors. So we just dropped this idea.

Meantime Pierre, Chrigu and Thomas made some nice progress using another library for the iPhone, named ZBar. Just before going for lunch, they managed to get a basic PhoneGap application scanning barcode using this library.

The idea then was that we should use a library specific to each plateform, Zbar for iPhone and Zxing on Android and provide a Javascript API abstracting away the libraries differences. The net result would be that you would write code against our API in your PhoneGap application and we would take care of calling the right function in the right library depending on the targetted device.

Hence we moved on trying to reproduce Pierre’s success on Android using Zxing. Things were not that easy but after many trial and errors, we managed to get it working too. Bastian had built an Android development environment quite fast but the building of a running application used up some time. Compared to the iPhone, the Android development way has many pitfalls we had to cover.

So at the end of the day we had two small PhoneGap applications, one dedicated to iPhone and another one for Android, capable of doing barcode scanning and recognition. These were really positive results.

Of course we don’t have anything close to a finished solution. There is still some work to be done in order to have a PhoneGap plugin that could be simple to use on any Android and iPhone devices. But we do know now that it is possible to do barcode scanning from within a PhoneGap application. We have selected libraries that will allow us to do it and have highlighted a way to package it as a nice PhoneGap plugin that could be used seamlessly in any PhoneGap application. With a couple of more days of work, we should be able to have this feature implemented nicely into a real application.

Tags: , ,

NIWEA Briefing Zürich

The Web is Dead? I guess not.

After the international LIFT11 NIWEA workshop in Geneva, the conspiracy is coming back to Zurich: join us for the NIWEA Briefing Zürich, a TechTalk in the “Internet Briefing” series. Hannes will be introducing the idea of “native interoperable web apps”, we’ll demo and discuss that third way in between good old web pages and the “there’s an app for that” world strongly tied to Apple & Co. What do those mechanisms mean for developers, what’s a sustainably tech and business strategy in this more-than-dynamic environment?

  • When: 2011/03/01, 11.30-14.00
  • Where: Ristorante Falcone, Birmensdorferstrasse 150, Zürich
  • How much: free for “Internet Briefing” members, but 80.- for the rest of us. Sign up here.
  • Too much: we can get some of you guys on the guest list though, so leave a comment or a tweet (with a name and your motivation, perhaps). 

The Web is dead? Well if so, it’s one cute happy zombie :)


Mobile Safari on iOS 4.2 supports WebSockets

Contrary to popular believe, Apple still adds new HTML5 features to Mobile Safari in the 4.x line. With the soon to be released 4.2, it finally also supports WebSockets, one of the missing pieces for a “completer” NIWEA experience.

Still missing are Web Workers and some other, currently less widespread features like FileReader (may not make much sense on the iOS devices), the “device” element (noone supports that yet, AFAIK) and WebGL (not our area)

And Firefox 4 is gonna support WebSockets, too. IE9 beta doesn’t (yet, but I didn’t hear anything that they will include it in the final release).

Tags: , , ,

3 days with a WP7 phone

Disclaimer: this is a personal review, about what I liked and not liked about the phone, not about what you may like or not. So I miss maybe some points, but not because i think they are not important, I just don’t need or care about them.

I ordered an “Windows Phone 7” Phone for Liip for testing purposes. I just got the “cheapest” one, an HTC Trophy (but with CHF 530.- not really cheap) . I now tested it over the weekend as my primary phone and here’s some short roundup:

  • It’s a nice phone with a good build quality and good large screen, I guess it’s HTC standard stuff.
  • It’s easy to get used to. Most stuff is quite intuitive, the design is “refreshing” and if you know how to use an iPhone, you won’t have much troubles using this.
  • The built-in apps like mail, SMS, Phone, Calendar are ok and up to par with what’s one used to on smartphones. Good enough for everyday use. Certainly room for improvements, but almost every mobile OS I know has this.

= The “Hub” concept is overrated. Facebook integration into contacts for example. I don’t use Facebook much, but still if I would, it’s not that great. And integration with other services like Twitter, LinkedIn, Xing is totally missing. webOS 2.0 for example has a similar concept (with Synergy) but allows developers to add such integration into contacts.
= It’s clearly 1.0. It doesn’t have obvious bugs or crashes, but missing functionality like copy&paste
= 3rd party apps are either not there or not polished enough, but that’s maybe gonna change.
= Battery: Doesn’t look better than on the iPhone or any other Smartphone. With heavy use, you need to charge sooner than your workday is over.

  • No (3rd party) multi-tasking, not even the fake one from the iPhone (suspend the app on exit). The apps (especially 3rd party apps) always start from the beginning when re-opened, highly annoying.
  • The Web-Browser. It does a good job on displaying normal webpages (and it’s as fast as the others), but as it’s based on IE7/8 it has not a single html5 feature. On it does 12 out 300 points. Therefore html5/Niwea apps will have a hard time on this phone.

Summary: It’s a nice phone, easy to use with a good look&feel. If you “just” need it for the stuff natively included (phoning, SMS-ing, mailing with not too many accounts or folders, surfing around, listening to music and gaming) and don’t need 3rd party apps, I guess you won’t be disappointed. BUUUUT, IMHO, it does nothing better (i care about) than the other smart phones, but the other smart phones do a lot of stuff better then WP7. More 3rd party apps, more open, multi-tasking, better future-proof browsers and so on. I see no reason, why one should buy a WP7 phone, when there’s Android or the iPhone to have. You just get less and not one single aspect is better. I guess it’s around iOS 2.0 feature wise, and that’s more than 2 years old. And that sums it up pretty good: It’s a nice phone, as the original iPhone was, but in 2010 that’s just not enough to be able to compete. Microsoft has still a lot to catch up here, and I’m really wondering if that’s gonna work out.

Tags: , ,

Vanilla is a NIWEA

Yesterday we went live with Vanilla. I cooperated on the iPhone application of this project. Following Liip’s core belief that web technologies are the future, we wrote this as a Native Interoperable Web Application (NIWEA). That means that it was written in HTML, JavaScript and CSS. PhoneGap was used in order to deploy it to the AppStore.

The main advantage of this approach is the fact that the code written is almost entirely reusable when deploying the application to Android, Nokia or RIM Phones. Or it could just live in the cloud, accessible by any browser.

The most notable feature of this application is its capability for mobile payment. Barcodes are used to identify single usage credit cards. These are scanned from the phone by the cashier, just like your common bonus card. If you are interested in the features of the application, I’ll let you surf vanilla’s faq (in german).

Now, let’s have a look at how we built this baby.


If you go to the PhoneGap homepage you can read the following tagline:

PhoneGap is an open source development framework for building cross-platform mobile apps. Build apps in HTML and JavaScript and still take advantage of core features in iPhone/iTouch, iPad, Google Android, Palm, Symbian and Blackberry SDKs.

PhoneGap basically provides us with a structure for Xcode in order to deploy our NIWEA. It also wraps certain core functions of the Cocoa framework into JavaScript functions. That way, we can set a native menu, that has the expected look and feel doing the following:

The wrappers also offer a native network activity notification, the little spinning wheel in the top statusbar (where the time, reception, and battery status are displayed):


We also used PhoneGap’s non-blocking alternative to alert() and an access to the device’s Universally Unique Identifier (UUID). PhoneGap provides much more, like access to the camera or the address book.


Apart from these four wrappers, the entire application was written in native JavaScript and HTML 5. We used both, the Local Storage and the client-side database storage.

Local Storage is nothing but a key-value storage. It accepts strings for both, the keys and the values and is very simple to use:

Once you need more structured data or relational data storage, you have to consider a DB. An interesting thing about the client-side DB is that the API is not completely implemented yet. Only the asynchronous part of the API is available on Safari. This seemed a bit painful in the beginning and forced us to think asynchronously about our data storage and retrieval. But in the end it lead us to a clearer separation of tasks in our code.


All of the testing during the development of the application was done in a browser. Hence we choose a deep linking strategy to dispatch the various actions of our application. That way we could use the URL to access every part of the application at any given time.

We chose to use jQuery Address as a library for our deep linking strategy. As you can see in the following code, we use a combination of local storage and deep linking in order to send the users to their last visited page when the application starts:


Most of the standard Crypto algorithms have a JavaScript implementation. All of the communication with our servers goes over SSL. That way we can already forget about a big part of the encryption, as the browser takes care of this. Only thing to remember is, that you need a certificate that is supported by the browser, as you can not set exceptions from within the WebView that PhoneGap offers.

As we are dealing with mobile payment, we needed some additional security with our data. Both, data stored on the device and payment relevant data are encrypted using RSA or AES, depending on the scenarios. As these are standardized crypto algorithms, we found fairly good open source JavaScript implementations.

One thing that amazed me is the speed of the JavaScript evaluation on these devices. RSA/AES encryption and decryption just isn’t a problem anymore.


If you wanna read up some more details on how we wrote this application I’d recommend you look at my slides from the presentation on PhoneGap I gave at the Liip Techday.

Tags: , , ,

The Tagi iPad App done in NIWEA aka html5/CSS

Some weeks ago, I was pondering if it would be possible to do a native App like the Tagi iPad App (a typical newspaper app) in pure html(5)/CSS/JS (aka Niwea). So I did what a Liiper often does when he wants to explore an idea: Organize a Hackday.

Last Wednesday, Gerhard, Pierre, Fabian and I sat together and started from scratch with the project. To make the content and design part easier, we simply took the Tages-Anzeiger App as the guide. We didn’t want to do something completely new, we just wanted to proof, that you can deliver a very similar experience to the end user with “just” an optimized website as with a native app.

It uses localStorage for saving the content locally (it doesn’t work totally offline yet, but that would be doable in another day :)), fancy CSS stuff and some heavy magic on the swiping stuff. It also uses Pierre’s excellent dispatcher library for Javascript based apps (see his talk about PhoneGap for more about that) and Hyphenator.js for more readable text, something the iPad App doesn’t provide. It also has different layouts for landscape and portrait. The “app” of course could use some polishing here and there, but for only one day work with 4 persons, I’m pretty pleased with the result.

The code is published on github.

Btw, we didn’t ask the Tages-Anzeiger, if it’s ok to use their content for this “Proof Of Concept”. I hope it is for them, if not, we will certainly find other interesting feeds (it takes RSS feeds as input and converts them to JSON on the server, so it would basically work with any feed, maybe some adjustments needed for the pictures).

Tags: , , , ,

Techday Slides: PhoneGap

Pierre talked about the PhoneGap work we did for an unpuplished project. He also talked a lot about JavaScript in general and some concepts there. Actually, it’s more about JavaScript, than PhoneGap. But that was fine and very interesting and entertaining (most of the fun is missing in the 99 slides, but there are still some gems). Get his slides.

Tags: , , ,