Author Archives: adifah

In our last blog article Vivien pointed out how Web 2.0 / Social Media changes learning. In addition to that I will write some lines about how web 2.0 affects software development (or just to add a new buzz word: “developing in the cloud”). Vivien said “The main feature of Web 2.0 applications is, that so far conventional applications for PCs are shifted into the world wide web.” This is true for software development, too.

Within the last year Cloud9ide has raisen a lot of attention because it shifted the development environment from the desktop into the browser. Thus collaborating with other developers had become easier then ever before. Together with cloud based databases, deployment servers and online repositories, the developer has everything he needs within his browser. The main reason for this paradigm shift is, that browsers (and their javascript engines) had become faster and more responsive.

Within this project I’m going to find out, if it’s possible for me to develop and deploy a web app only with the help of a browser. This means:

  • no local Editor or IDE, just my browser
  • no usage of own servers, repositories or infrastructure
  • no usage of services with costs

Below I will introduce all services I’m going to use for this project to fulfill the above requirements:

jsfiddle for the visual prototypes of the mini-games
  • online edtior for snippets build from html, css and Javascript
  • supporting all actively developed frameworks (jQuery, bootstrap, ExtJs,..)
  • code can be shared
  • good for isolating bugs and testing compatibility (e.g. css3 browser-support)

cloud9ide as a replacement for a desktop-ide/editor

  • online web-based Cloud Integrated Development Environment for Javascript and Node.js development  (It is written almost entirely in Javascript, and uses Node.js on the back-end)
  • code is accessible from anywhere on the web
  • teams can collaborate on projects and run/debug them within the browser
  • easy deployment on different servers (e.g. heroku)
  • free for open source projects

github as a public repository

  • web-based hosting service for software development projects that use the Git revision control system.
  • Includes source-code browser, in-line editing, wikis, and ticketing.
  • free for open source projects

heroku for hosting our app

  • cloud platform as a service (PaaS) supporting several programming languages.
  • Agile deployment for Ruby, Node.js, Clojure, Java, Python, and Scala.
  • Run and scale any web or background process with any web framework or worker type in minutes
  • first Node and a small Database is free
  • one-click-deployment-button in cloud9ide

Have a look:


In this blog entry we will give you a summary of the technical side of our flag app: “What technologies are we going to use and why do we choose them.”

First of all we had to make a decision: “Are we going to make a native app, or a web app”.

We already summarized the differences between this approaches in an older blog post [1]. Due to the big workload (because of the many mini-games) and my lacking experience with native app developing we decided to do it the web-app-way. Common web technologies (html/css3/js) paired with a mobile-web-framework will cover all our requirements and thus our app can even be used with desktop browsers.

The Client Side
For best user experiences on mobile browsers we will use the web-app-framework jQuery mobile [2]. This way the mobile user gets a native feeling whereby there are also optimization possibilities for desktop users (with css3 media queries). We favour jQueryMobile over Sencha Touch because of the wider device support of jQueryMobile and the fact, that everything can be done in Html and css3 (JavaScript will mainly be used for the game logic). Furthermore we have the option to make our app native as well later (phonegap [3] for example, transforms any web app into a native iOS or Android App).

The Server Side
On the server side we primary need user handling/authentication, a database for storing informations like the user’s score. There are many ways to implement user handling, one is oAuth [4]. This way the user can login with his twitter/facebook/whatever-account and we don’t have to struggle with the registration part.
Besides, the majority of the game logic should be computed on the server. The advantage of this approach is that there is no way for the users to cheat (like looking up the sourcecode of the memory game to get informations about a card’s backside). Since we have to split the game logic into server and client parts it would be fine if we can use the same programming language on both sides.

Based on this requirements we are going to use node.js [5], a server-side javascript environment in combination with express [6], a web framework for Node.js. The authentication with oAuth (twitter) will be handled by everyauth [7]. The persistance layer can be filled with a nosql databse like couchDB [8] for data storage, but for the prototype we will use dirtyDB [9], a tiny & fast key value store with append-only disk log.

Communication between client and server
There are several informations that have to communicate between the clients and the server (e.g. user moves or highscores).
To archive a asynchronous real-time communication between the server and the clients we will use socket.io [10], which works perfectly together with nodejs. Socket.io is compatible with a wide range of browsers and in combination with json [11], a data interchange based on javascript, it’s a fast websocket solution  (with fallbacks for older browsers) with a minimal data overhead.

Server:

  • Node.js (JavaScript Server)
  • DirtyDB (file-based DB)
  • Express (Web-Framework)
  • Jade (Template-Engine)
  • Less (dynamic Stylesheets)
  • Everyauth (Twitter oAuth)
  • Socket.io (real-time Communication)
Client:

  • jQueryMobile (Mobile-Framework)
  • HTML5 (generated by Jade)
  • CSS3 (generated by Less)
  • jQuery (for game logic)
  • Socket.io (real-time Communication)

[1] https://fsln12group3.wordpress.com/2012/04/16/web-hybrid-or-native-app/
[2] http://jquerymobile.com (jQuery mobile example: http://www.professorcloud.com/supercharged/mobile/)
[3] http://phonegap.com
[4] http://en.wikipedia.org/wiki/OAuth
[5] http://nodejs.org
[6] http://expressjs.com/
[7] http://everyauth.com
[8] http://couchdb.apache.org/
[9] https://github.com/felixge/node-dirty
[10] http://socket.io
[11] http://en.wikipedia.org/wiki/JSON


Some thoughts on the pros and cons of the basic approaches to develop apps for mobile devices. Feel free to give some feedback.

Web App / Mobile Website (jQuery Mobile, Sencha Touch, Kendo UI, …)

  • Runs in the phone’s browser (HTML5, CSS, Javascript and/or local storage for the data) 
  • Uses the same codbase to support all devices and os (depends on the chosen framework) 
  • Updates installed in real time 
  • Found through google web search and accessible by desktop browsers 
  • User has to wait until the app is loaded (slow/no connection can ruin the experience for the user)
  • No full integration of all phone features (accelerometer, push notification, camera, compass, etc.)
  • Extensive use of javascript effects and Ajax may have bad effects on the performance and the CPU and battery usage.

Native App (Objective-C, .Net/C#, Java)

  • Using native UI-Components and OS-Api (best user experience) 
  • Fully utilize all phone features (accelerometer, geolocation, push notification, camera, compass, etc.) 
  • Because the app is downloaded on the device it can be accessed at any time 
  • Good for high performance applications (e.g. games)
  • Requires implementation specific to handset OS (using local database and filesystem) 
  • Must be downloaded and installed from the Apple iTunes Store, the Android Market and other similar services 
  • The consumer has to upgrade to get new versions 
  • IPhone native apps must be approved by Apple

Hybrid App (PhonegapRhomobileTitanium)

  • Using Phonegap every Web App can be wrapped into a native app packed for appstore distribution, without the need of lower-level languages such as Objective-C
  • Natively target all smartphones with a single codebase 
  • Access to the device API (http://phonegap.com/about/features) 
  • All layout rendering is done via the webview instead of the platform’s native UI-Framework, so the performance issues remain the same.