Applications

Building applications for Firefox OS using AngularJS

When you start developing for Firefox OS you might be underwhelmed by the tools that are provided. There is no standard UI toolkit, or a JavaScript framework that all apps build on. This is not a situation that’s inherently bad because in essence Firefox OS is the web; and thus gives you complete freedom in the toolchain you use. This gives us the advantage to use any new technology that pops up also on Firefox OS. The downside is that you’ll miss out on things you might be used to on Android or iOS, like built-in templates; view transitions and UI components.

In Telenor Digital we decided to build a ready-to-go application framework that deals with these shortcomings, built on top of AngularJS, the MVW framework by Google. The template is the result of iterating over our internal applications that we built for Firefox OS, and addresses the following things:

  1. Built on top of AngularJS, that has provides data binding; templating; routes; and code structure
  2. Built in set of UI components
    and transitions, in the style of Firefox OS
  3. Ability to publish apps as a mobile web page (hosted app),
    or as a packaged app for the Firefox OS marketplace
  4. Offline first approach. Every app built on top of the template works offline,
    also when hosted on your own web server.
  5. A build system to create release builds with one command,
    that does minification and template caching for optimal performance

Let’s look at how the demo application looks like. It’s a standard CRUD app that shows a list-detail pattern: http://janjongboom.com/ffos-list-detail/. You can click on items to go to the detail view, you can edit items, or add new items. The ‘+’ button is an install button (only visible in Firefox) and allows you to add the app to your phone (Android / FxOS).

Getting the code

To start building, do this:

  • git clone git@github.com:comoyo/ffos-list-detail.git
  • npm install
  • ./node_modules/bower/bin/bower install
  • Now you can open www/index.html in any browser, or use the app manager and add the
    www folder as a packaged app.

Structure

The application lives in the www/ folder, and is made up of the following subfolders:

  • components/, third party libraries, loaded through bower
  • css/, style sheets. List all styles used by your app in
    css/main.css.
    They will be combined into one big stylesheet, for optimal performance.
  • img/, holds the icons for the app in three formats.
  • js/, our code
    • controllers/, the code that binds data to our UI
    • lib/, external libraries that are not in bower
    • services/, data providers, or code that is not bound to UI
    • app.js, starting point of the application, contains global configuration like routes
    • main.js, bootstrap file based on RequireJS.
      Lists all the JavaScript files we use. When you create a new JS file, add it here.
  • views/, view templates
  • index.html, bootstrap file where we load the application. You probably never will touch this.
  • manifest.appcache, AppCache file.
    You’ll need to list all the images & other resources (other than CSS/JS) that your app needs here,
    to enable offline for hosted applications.
  • manifest.webapp, Firefox OS App manifest file.

You don’t need any build chain set up during development, you can just edit files in www, and refresh index.html at will. That’s the power of the web 🙂 Of course if you’re developing in the app manager, press UPDATE to refresh the app.

Now let’s add some new functionality to this application, so we can see how developing new features works in practice.

Adding a new button

Let’s say that we want to add a credits screen that shows who built the application. First thing we need to do is add a button somewhere. In our case let’s put it on the home screen of the app. The code of the view is in www/views/list.html

The components that you see come from the Firefox OS Building Blocks, which are the same blocks that are used to build Firefox OS itself. Let’s add a new button at the bottom of the screen (below the </ul> and the </section>:

<a class="recommend" role="button" ng-tap="go('/credits', 'popup')">Credits</a>

Important here is the ng-tap attribute. When we tap this item we go to /credits URL, with animation popup. There are four built in animations: forward, backward, popup and popdown; but you can create your own using simple CSS.

Now when we look at this it doesn’t look like a button yet, because we didn’t tell that we needed the button building block. Go to css/main.css and add the following line to make it look nice:

@import url("../components/building-blocks/style/buttons.css");

All this is always documented on the page on the Building Blocks website.

Hooking it up

When we click on the button nothing happens though (well, we get redirected back to the list view), and that’s because we don’t listen on the /credits URL yet. To fix that we need to create a route handler (like in any MV* server side framework as well). Open the list of routes in js/app.js, and add a handler for the credits URL (before the otherwise handler):

.when('/credits', {
  templateUrl: 'views/credits.html',
  controller: 'CreditsCtrl'
})

Here we tell which controller we want to consult (with JS code), and which view (with HTML) belongs to that. Let’s create the view first. Add a new file called credits.html in the views folder.

<section role="region">
  <!-- Header building block http://buildingfirefoxos.com/building-blocks/headers.html -->
  <header>
    <!-- here we handle the back click and we do a popdown animation -->
    <a ng-tap="go('/', 'popdown')"><span class="icon icon-back">back</span></a>
    <h1>Credits</h1>
  </header>
</section>
<!-- The content of the view should have a 'view' class, and add the name of
     the view to easily style the view later -->
<section class="view credits">
  This application is made by {{ name }}. <!-- AngularJS does data binding for us -->
</section>

To style this view we can add some content in css/app.css, f.e. add some padding and make the text bigger:

.view.credits {
  padding: 1.5rem;
  font-size: 2rem;
}

Now write a simple controller to fill the content of {{ name }}, using standard AngularJS data binding. Add a new file called credits.js in www/js/controllers:

/* We use RequireJS AMD style modules to get a reference to the app object */
define(['app'], function(app) {
  /* Tell that we're defining a controller with name
    CreditsCtrl, and with dependencies on $scope, we specify this as string
    to not break when minifying
  */
  app.controller('CreditsCtrl', ['$scope',
    /* Implementation. AngularJS does dependency injection to fill the $scope var */
    function CreditsCtrl($scope) {
      /* Data binding to the view */
      $scope.name = 'Your name';
    }
  ]);
});

Last thing is to tell RequireJS that we have a new JS file that needs to be included in our builds, by editing js/main.js and adding a line above 'js/controllers/edit.js':

'js/controllers/credits.js',

When we now click the button in the app, everything works as expected. The view pops in, we have data, and we can dismiss by clicking the back button. What’s also great is that when you send the URL to someone else (f.e. http://your/url/index.html#/credits) they will go to the same view by default. That’s because we do proper state management through URLs by default.

Talking to a third party data source

The app currently only talks static data, so we want to hook it up to a real data source. In our case the project list should come from GitHub’s page with projects by mozilla-b2g. They have an API at: https://api.github.com/users/mozilla-b2g/repos.

AngularJS has an idea of services, that abstract data away from your controller. For this app we have a database service that currently returns in-mem data. We can modify the service to talk to a web service instead. Clear out www/js/services/database.js and replace the content with:

/*global define */
"use strict";
define(['app'], function(app) {
  /* Add a new factory called database, with a dependency on http */
  app.factory('database', ['http', function(http) {
    var getItems = function() {
      /* getItems makes a HTTP get call to github */
      return http.get('https://api.github.com/users/mozilla-b2g/repos', {
        // this is the cache configuration, we want to always cache requests
        // because it gives better UX. Plus when there is no internet, we can
        // get the data from cache and not break for the user...
        idbCache: {
          cacheKey: 'api.index',
          // expiration time in ms. from now (this is 5 minutes)
          // This is only obeyed if there is an internet connection!
          expiresInMs: 5 * 60 * 1000
        }
      }).then(function(res) {
        // Format it, sort it and map it to have the same format as our previous in mem dataset
        return res.data.sort(function(a, b) {
          return a.stargazers_count < b.stargazers_count;
        }).map(function(item) {
          return {
            title: item.name,
            description: item.description,
            id: item.name
          };
        });
      });
    };
 
    // Similar story but now for just one item
    var getItemById = function(id) {
      return http.get('https://api.github.com/repos/mozilla-b2g/device-flatfish', {
        idbCache: {
          cacheKey: 'api.detail.' + id,
          expiresInMs: 10 * 60 * 1000
        }
      }).then(function(res) {
        var repo = res.data;
        return {
          title: repo.name,
          description: repo.description,
          id: repo.name,
          date: new Date((repo.pushed_at || "").replace(/-/g,"/").replace(/[TZ]/g," "))
        };
      });
    };
 
    return {
      getItems: getItems,
      getItemById: getItemById
    };
  }]);
});

This API is now asynchronous though, but that doesn’t matter for Angular. If you data-bind to a promise, Angular will wait until the promise resolves until data binding happens.

The beauty here is now that even when there is no Internet connection, the data will still load (as long as it was loaded at least once), and the data is auto-cached. No need for the controller to worry about that.

Publishing the app

These were two ways we quickly added some functionality to this application. First, adding a new button and a new view; and second, showing data binding and offline caching of server data. Please note that this application template can be used for much more than just list->detail applications, you’ve got the whole power of AngularJS at your hands!

Now when we want to share this application with the rest of the world, we can go two ways:

  • Create a hosted application. This is an app that lives on your own server, like any mobile website. Hosted apps can still be published on the marketplace, and will work offline, but cannot use all the APIs in Firefox OS due to security limitations.
  • Create a packaged application. This is a ZIP file, similar to APK files on Android, that contain all the assets of your app, and are distributed through the marketplace.

Both of these applications can be generated using our build script. The script will create a new folder dist/ that lists all the files the app needs. If you want to publish the app to your own server, just copy over the contents of the folder. If you want to publish the app as a packaged app, ZIP up the content and publish to the marketplace.

To build, run:

  • Packaged: node build.js
  • Hosted: node build.js appcache

Happy coding!

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Custom Elements for Custom Applications – Web Components with Mozilla’s Brick and X-Tag

In this article, we will explore the use of Mozilla’s Brick and X-Tag libraries. First we’ll use Brick to rapidly prototype a simple application. Then, we’ll build a custom web component using X-Tag.

The Technology

Brick: Curated Web Components

Brick is a set of modular, reusable UI components. The components are designed for adaptive, responsive applications and are a great choice for going mobile first, which is by and large how web-based applications should be developed. This philosophy and its design patterns accomodate a wide range of devices. Brick components aren’t just for mobile apps, they are for modern apps.

Brick is kind of like a library, but really you should think of it as a curated collection of web components.

Brick’s collection of components are used declaratively in your HTML <like-this> and can be styled with CSS like regular non-custom elements. Brick components have their own micro-APIs for interacting with them. These components are building blocks. Do you like Lego? Good. You will like Brick.

Brick web components are made using the X-Tag custom elements polyfill.

What is X-Tag?

X-Tag is a library that polyfills several (and soon all) features that enable web components in the browser. In particular, X-Tag is focused on polyfilling the creation of Custom Elements so that you can extend the DOM using your own declarative syntax and element-specific API.

When you are using components from Brick, you are using web components made using the X-Tag library. Brick includes X-Tag core, so if you include Brick and then decide to make your own custom elements — you do not need to include X-Tag to do so, all the features of X-Tag are already available for you.

Download Demo Project Files

Download the demo project files. First we’ll use the material in the simple-app-with-bricks folder.

Using Bricks in an app

Here we will build a simple skeleton app using <x-appbar>, <x-deck>, and <x-card>. x-appbar provides a tidy header bar for our application, and x-cards placed as children of an x-deck give us multiple views with transitions.

First, we start with a barebones HTML document and then include Brick’s CSS and JS, along with our own application-specific code (app.css and app.js respectively in the example to follow).

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width">
    <link rel="stylesheet" type="text/css" href="css/brick.min.css">
    <link rel="stylesheet" type="text/css" href="css/app.css">
    <title>Simple - Brick Demo</title> 
  </head> 
  <body> 
    <!--- Some Brick components will go here -->
    <script type="text/javascript" src="js/brick.min.js"></script>
    <script type="text/javascript" src="js/app.js"></script>
  </body>
  </html>

Now we add some Brick elements:

<x-appbar id="bar">
  <header>Simple Brick App</header>
  <button id="view-prev">Previous View</button>
  <button id="view-next">Next View</button>
</x-appbar>

Below your x-appbar, create an x-deck with some x-cards as children. You can give the x-cards any content you like.

<!-- Place your x-deck directly after your x-appbar -->
<x-deck id="views">
  <x-card>
    <h1>View 1</h1>
    <p>Hello, world!</p>
  </x-card>
  <x-card>
    <h1>Pick a Date</h1>
    <p>&lt;x-datepicker&gt;s are a polyfill for &lt;input type="date"&gt;</p>
    <x-datepicker></x-datepicker>
    <p>Just here to show you another tag in action!</p>
  </x-card>
  <x-card>
    <h1>A Random Cat To Spice Things Up</h1>
    <!-- Fetches from the Lorem Pixel placeholder content service -->
    <img src="http://lorempixel.com/300/300/cats">
  </x-card>
</x-deck>

We have already almost completed the structure for a simple application. All we need now is a little bit of CSS and Javascript to tie it together.

document.addEventListener('DOMComponentsLoaded', function() { 
  // Run any code here that depends on Brick components being loaded first 
  // Very similar to jQuery's document.ready() 
 
  // Grab the x-deck and the two buttons found in our x-appbar and assign to local vars
  var deck = document.getElementById("views"),
  nextButton = document.getElementById("view-next"),
  prevButton = document.getElementById("view-prev"); 
 
  // Add event listeners so that when we click the buttons, our views transition between one another
  prevButton.addEventListener("click", function(){ deck.previousCard(); }); 
  nextButton.addEventListener("click", function(){ deck.nextCard(); });
});

<x-calendar> example in our demo application

Some simple CSS to style our fledgling application:

html, body {
  margin: 0;
  padding: 0;
  font-family: sans-serif;
  height: 100%;
}
 
h1 {
  font-size: 100%;
}
 
x-deck > x-card {
  background: #eee;
  padding: 0.6em
}

Ka-bam! With a little bit of declarative markup and a few tweaks, we have a skeleton that anyone can use to make a multi-view app within a single HTML document. If you check out the markup in the developer tools, you’ll see the Brick custom elements living happily alongside vanilla HTML elements – you can use the developer tools to inspect and manipulate them in the same way as regular old HTML.

Custom elements alongside HTML elements in the Firefox Developer Tools

Now let’s learn how to make our own custom element using X-Tag.

Creating Custom Elements (Your Own ‘Bricks’) Using X-Tag

Let’s say we have a mobile application in which the user takes an action that results in a blocking task. Maybe the application is waiting for an external service. The program’s next instruction to complete the user-initiated task depends on the data from the server, so unfortunately we have to wait. For the sake of our purposes here, let’s pretend we can’t modify our program too much and assume an entrenched architecture – maybe we can’t do much else other than communicate to the user until we find a way to deal with the blocking better. We have to do the best with what we have.

We will create a custom modal spinner that will tell the user to wait. It’s important to give your users feedback on what’s happening in your app when they don’t get to complete their task in a timely manner. A frustrated or confused user might give up on using your app.

You will want to switch to the x-status-hud folder inside of the demo materials now.

1. Registering Your Custom Element

X-Tag relies on several different events to detect and upgrade elements to custom elements. X-Tag will work whether the element was present in the original source document, added by setting the innerHTML property, or created dynamically via document.createElement. You should take a look at the Helpers section of the X-Tag documentation as it covers various functions that will allow you to work with your custom elements just like vanilla ones.

The first thing that we need to do is register our custom element with X-Tag so that X-Tag knows what to do if and when it encounters our custom element. We do that by calling xtag.register.

xtag.register('x-status-hud', {
  // We will give our tag custom behavior here for our status indicating spinner
});

!IMPORTANT: All custom element names must contain a hyphen. Why is this? The idea here is that there are no standard HTML elements with a hyphen in them, so we don’t trample existing namespaces and have collisions. You do not have to prefix with ‘x-’, this is just a convention used for components create with X-Tag in the Brick ecosystem. Once upon a time in the early days of the W3C specification for custom elements, it was speculated that all custom elements would have an x- prefix; this restriction was relaxed in later versions of the specification. If you were to name an element ‘bacon-eggs’ or ‘adorable-kitten’, both of these would be perfectly valid names. Choose a name that describes what your element is or does.

If we wanted to, we could choose to set what HTML element is being used as our base element before upgrading. We can also set a specific prototype for our element if we want to involve functionality from a different element. You can declare these as follows:

xtag.register('x-superinput', {
  extends: 'input',
  prototype: Object.create(HTMLInputElement.prototype)
});

The element we are building doesn’t require these properties to be set explicitly. They are worth mentioning because they will be useful to you when you write more advanced components and want a specific level of control over them.

2. The Element Lifecycle

Custom elements have events that fire at certain times during their lifetime. Events are fired when an element is created, inserted into the DOM, removed from the DOM, and when attributes are set. You can take advantage of none or all of these events.

lifecycle:{
  created: function(){
    // fired once at the time a component
    // is initially created or parsed
  },
  inserted: function(){
    // fired each time a component
    // is inserted into the DOM
  },
  removed: function(){
    // fired each time an element
    // is removed from DOM
  },
  attributeChanged: function(){
    // fired when attributes are set
  }

Our element is going to use the created event. When this event fires, our code will add some child elements.

xtag.register('x-status-hud', {
  lifecycle: {
    created: function(){
        this.xtag.textEl = document.createElement('strong');
 
        this.xtag.spinnerContainer = document.createElement('div');
        this.xtag.spinner = document.createElement('div');
 
        this.xtag.spinnerContainer.className = 'spinner';
 
        this.xtag.spinnerContainer.appendChild(this.xtag.spinner);
        this.appendChild(this.xtag.spinnerContainer);
        this.appendChild(this.xtag.textEl);
    }
  }
  // More configuration of our element will follow here
});

3. Adding Custom Methods

We need to have control over when we show or hide our status HUD. To do that, we need to add some methods to our component. Let’s add some functions to do that. A simple toggle() may suffice for some use cases, but let’s throw in individual hide() and show() functions too.

 
xtag.register('x-status-hud', {
  lifecycle: {
    created: function(){
      this.xtag.textEl = document.createElement('strong');
 
      this.xtag.spinnerContainer = document.createElement('div');
      this.xtag.spinner = document.createElement('div');
 
      this.xtag.spinnerContainer.className = 'spinner';
 
      this.xtag.spinnerContainer.appendChild(this.xtag.spinner);
      this.appendChild(this.xtag.spinnerContainer);
      this.appendChild(this.xtag.textEl);
    }
  },
 
  methods: {
    toggle: function(){
      this.visible = this.visible ? false : true;
    },
 
    show: function (){
      this.visible = true;
    },
 
    hide: function (){
      this.visible = false;
    }
  }

4. Adding Custom Accessors

Something important to note about properties on custom elements: they do not have to map to an attribute. This is by design because some setters could be very complex and not have a sensible attribute equivalent.

If you would like an attribute and property to be linked, pass in an empty object literal to the attribute. You’ll see below where this has been done for the label attribute.

xtag.register('x-status-hud', {
  lifecycle: {
    created: function(){
      this.xtag.textEl = document.createElement('strong');
 
      this.xtag.spinnerContainer = document.createElement('div');
      this.xtag.spinner = document.createElement('div');
 
      this.xtag.spinnerContainer.className = 'spinner';
 
      this.xtag.spinnerContainer.appendChild(this.xtag.spinner);
      this.appendChild(this.xtag.spinnerContainer);
      this.appendChild(this.xtag.textEl);
    }
  },
 
  methods: {
    toggle: function(){
      this.visible = this.visible ? false : true;
    },
 
    show: function (){
      this.visible = true;
    },
 
    hide: function (){
      this.visible = false;
    }
  },
 
  accessors: {
    visible: {
      attribute: { boolean: true }
    },
 
    label: {
      attribute: {},
 
      set: function(text) {
        this.xtag.textEl.innerHTML = text;
      }
    }
  }
}); // End tag declaration

If the difference between attributes and properties is unclear to you, take a look at the top answer to this Stack Overflow question. Although the question being asked is about something else entirely (jQuery), the top answer has a great explanation that will help you understand the relationship between attributes and properties.

The Finished Component

When we write code that depends on custom elements having been loaded already, we add an event listener that fires when the components have finished loading. This is sort of like jQuery’s document.ready.

<script type="text/javascript">
document.addEventListener('DOMComponentsLoaded', function(){
  // Any HUD customizations should be done here.
  // We just pop up the HUD here to show you it works!
  var testHUD = document.getElementById("test");
  testHUD.label = "Please Wait...";
  testHUD.show();
}, false);
</script>

X-Tag Status HUD Demo

There you have it. We’ve created a simple modular, reusable widget for our client-side code. It’s a good starting point. But is it really finished?

Some ways we may improve this element:

  • Have the element recalculate it’s size when the attributeChanged event is fired and have the component resize to fit the label as it is updated rather than truncate the label with an ellipsis
  • Let the developer set an image, such as an animated GIF, in place of the CSS spinner to customize the user experience further
  • Have a progress bar instead of a spinner to give the user some additional information about task progress

Use your creativity to come up with a small set of practical features and improvements beyond these as an exercise on your own.

After following this tutorial you should understand how to extend the DOM with your own custom elements. If you’re stuck, leave a comment and we’ll do our best to get you back on track. If you’re not stuck, post your GitHub repo and show us what you’ve made with Brick and X-Tag. Happy hacking!

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Applications Open for Expanded Tablet Contribution Program

Last month, Mozilla announced the Tablet Contribution Program to help deliver Firefox OS to the tablet form factor. Today, we are excited to open the Application for Hardware Support to Mozillians all over the world who will sign up to contribute to Firefox OS coding, testing, localizing, and product planning.

The first device for this program is the 10″ InFocus tablet from Foxconn, with a 1.0GHz Quad-Core Cortex-A7 processor.

Foxconn's InFocus F1 New Tab running Firefox OS Brand/Model: Foxconn InFocus
Processor: A31 (ARM Cortex A7) Quad-Core 1.0GHz w/ PowerVR SGX544MP2 GPU
RAM: 2GB
Storage: 16GB
Screen: 10.1" IPS capacitive multi-touch @ 1280x800
Camera: Dual cameras, 2MP/5MP
Wireless: 802.11b/g/n
Ports: Micro SD, Micro USB, headphone
Other: GPS, Bluetooth, Gyroscope
Battery: 7000mAh

Today, we’re also excited to announce an upcoming addition to the program, a 7″ Vixen tablet from VIA, with a 1.2Ghz Dual core Cotex-A9 processor.

VIA Vixen running Firefox OS Brand/Model: VIA Vixen
Processor: WM8880 (ARM Cortex A9) Dual-Core 1.2Ghz w/ Dual-Core Mali 400 GPU
RAM: 1GB
Storage: 8GB
Screen: 7" capacitive multi-touch @ 1024x600
Camera: Dual cameras, 0.3MP/2.0MP
Wireless: 802.11b/g/n
Ports: Micro SD, Micro USB, Mini HDMI, headphone
Other: Bluetooth, Accelerometer
Battery: 4000mAh

We have limited quantities of these developer devices so we’re looking for dedicated contributors who can commit to regular testing and reporting of defects, identifying and documenting feature gaps with competitor tablets, triaging incoming bug reports, localizing and translating UI, prioritizing work and building roadmaps, hacking on existing features and bugs, defining new features and experiences, and more.

If that sounds exciting to you, and you’ve got time and skills to work with Mozilla to make a real difference in the tablet space, apply now for free developer tablet hardware from Mozilla.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Launcher.io – Launch and run free open-source web applications in just 30 seconds – a WebFWD project

There is no longer any doubt: web apps are the focal point of the cloud. From database-as-a-service to platform-as-a-service to security-as-a-service and beyond, the entire *aaS model has the web app as its center of gravity.

If you’re a full-fledged developer, then taking full advantage of an app-centric universe is no big deal. Creating new web apps from scratch using frameworks like Ruby on Rails, Drupal, Django, or hundreds of others and then deploying those apps in the cloud is part of your daily bread and butter.

The mission

The mission of Launcher.io is quite simply to make it vastly easier for developers and non-developers alike to create and deploy their own web apps with a single click of the mouse. Launcher was founded by me, former AppFog director of product Maciej Skierkowski, and I have taken what I have learned in my time in the platform-as-a-service (PaaS) space and used that knowledge to make app deployment even more dead-simple than a typical PaaS platform does.

How it works

So how does it work? Launcher enables you to deploy so-called “jumpstart” apps with a single click. If you’ve signed up for a Launcher account, all you have to do is click on a jumpstart’s button and you’ll be prompted for basic information, and Launcher will do the rest of the work.

From there, you can manage your app however you like. Frameworks like Drupal, WordPress, or Concrete5 provide you with an intuitive in-browser interface for modifying your app, whereas frameworks like Ruby on Rails, Flask, ActionHero.js, and others will require more in-depth web development knowledge.

Launcher: great for non-developers

The benefit for non-developers is that it makes using all of these platforms easier than ever before. Want to start a new WordPress blog? All it takes is signing up to Launcher and clicking a button, and your blog is up and running in the cloud. The rest is up to you. Are you starting a company and want to set up Drupal to run your content management system and ThinkUp for social media analytics? Also a click and a few keystrokes away.

Launcher: even better for developers

For developers, the benefits of Launcher involve speedier adoption of new apps and frameworks amongst potential users. Let’s say that I’m a Java developer and I just created the most bleeding-edge CMS currently available. If Drupal is a Cadillac, then my new CMS platform is a fresh-off-the-assembly-line Maserati: it’s blazingly fast, it has a wonderful in-browser console, and it has millions of useful plugins that Just Work.

If users wanted to use my CMS in a pre-Launcher world, they’d have to do it the hard way: download it onto their machine, run appropriate configs to make it cloud-ready, learn how to use a VPS (or a PaaS, which is a very recent development), and so on. But with Launcher, potential users can give my new CMS a spin in just a few seconds and have it running in the cloud, and making my CMS Launcher-ready provides little to no modification on my part.

The app landscape is extremely competitive, and anything that can speed potential adoption that quickly is a massive win for me as a developer. Launcher is simply an unprecedentedly direct pipeline to my new SaaS product.

Under the hood

Surprisingly enough, Launcher is amazingly simple in how it works behind the scenes. When an end user clicks on a jumpstart, the browser makes an AJAX request to a remote service kicking-off a Resque worker that deploys the app with AppFog or CloudFoundry.com. Setting up an HTML page to handle a Launcher jumpstart involves simply loading the jQuery and Pusher JavaScript libraries and inserting a few lines of JavaScript (check out the docs for more info).

Your app will, however, need to be registered with Launcher to be included in the Launcher App Store. If you’re interested in doing so, don’t hesitate to get in contact with me, as I am looking to expand the range of offerings in the app store in the coming months.

He’s also looking to expand the number of PaaS providers that support jumpstarts. At the moment, Launcher enables you to instantaneously deploy apps on either AppFog or Cloud Foundry, but Launcher is in principle compatible with any Cloud Foundry-compatible PaaS API. If you’d like to add a new PaaS, simply go to the Providers page, click “Add Provider,” and input a name, API endpoint, and other information.

More on the way

Launcher is a new project, and has a great deal more in store for both developers and end users. Jumpstarts for OpenPhoto, Redmine, and SugarCRM, to name just a few are coming soon.

If you’re a developer, startup, or enterprise looking to take advantage of Launcher, email maciej@skierkowski.com for more information.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

HTML5 Web applications and libraries survey – first results

At Mozilla, we are dedicated to keep the web open and independent of a single company or technology. This means that users should have a choice of browsers and technology to use to go online and should not be blocked out because they can’t afford a certain device or are forbidden to change their browser.

In the world of mobile web development there is currently a massive debate going on about the need for support of various browsers seeing that the most successful phone systems both use the same browser engine. This is good, and we need this debate. It is not good though when developers block out users because they concentrate on targetting a browser. Sometimes this is not by choice of the developer – they are simply using tools that do that blocking for them and the usefulness of the tool outweighs the qualms developers have about that.

We are now planning to talk to library and tool developers and help them support more than one browser engine to prevent this. As a start of that process we wanted to get a glimpse of what people are using right now so we make sure we have the most impact when we help. This is why we started a quick online survey asking developers about their tools for mobile development.

We are happy to report that to date we have 480 answers and it is time to take a first stab at looking at the data.

We are very aware that this is *not* a scientifically clean research and should be taken with a grain of salt (we haven’t asked how many times people used the tools or how much of their work is building mobile apps) but it gives us a good first glimpse at what makes most sense for us to do.

So without further ado, here are the raw numbers as charts:

Platforms

Not many surprises there, iOS and Android are in the lead, quite a lot of people see the web as a must-have (but this is a survey called out by Mozilla…) and Blackberry and Windows Mobile are not that hight on people’s radar.

What platforms are you targeting with your apps – iOS
focus 208 43%
must have 168 35%
supported 43 9%
sometimes 24 5%
not at all 36 8%
What platforms are you targeting with your apps – Android
focus 147 31%
must have 183 38%
supported 85 18%
sometimes 33 7%
not at all 31 6%
What platforms are you targeting with your apps – Blackberry
focus 5 1%
must have 11 2%
supported 83 17%
sometimes 136 28%
not at all 244 51%
What platforms are you targeting with your apps – Web
focus 306 64%
must have 121 25%
supported 26 5%
sometimes 18 4%
not at all 8 2%
What platforms are you targeting with your apps – Windows phone
focus 8 2%
must have 36 8%
supported 112 23%
sometimes 137 29%
not at all 186 39%

Libraries

jQuery rules supreme but Sencha touch and Zepto also have their place. Interestingly enough a lot of answers discarded libraries completely and considered them an overhead that will cause damage in the future.

What libraries do you use to build mobile web apps/sites?
jQuery 349 73%
jQuery mobile 248 52%
Zepto.js 90 19%
JO 5 1%
XUI.js 18 4%
Sproutcore 7 1%
Sencha touch 72 15%
JQTouch 50 10%
Mootools mobile 11 2%
M project 1 0%
Nimblekit 2 0%
Lime.js 9 2%
Wink 1 0%
Uxebu Bikeshed 1 0%
Other 126 26%
People may select more than one checkbox, so percentages may add up to more than 100%.

Conversion frameworks

You do love your PhoneGap / Cordova, it seems. There is not too much competition in this market and a lot of feedback was questioning the sense of converting apps as “building them natively makes more sense”.

Which frameworks do you use to convert apps to native apps?
PhoneGap 257 90%
Appcellerator 45 16%
MoSync 2 1%
Other 31 11%
People may select more than one checkbox, so percentages may add up to more than 100%.

Visual editors

The space of visual editors seems to be not to frequented with this audience – would be interesting to see if there is already a mass market for WYSIWYG-like tools in the web app space.

Do you use any visual tools/converters to build apps? If so, which?
Adobe Edge 14 35%
Sencha Animator 9 23%
Other 18 45%
People may select more than one checkbox, so percentages may add up to more than 100%.

Webkit only?

71% of the audience saying they test on other browsers than webkit is making us happy of course, but seeing that a lot of the tools in use are webkit only makes that number questionable. Then again, we didn’t qualify what testing entices in this case.

Do you test on non-Webkit browsers?
Yes 340 71%
No 139 29%

Reasons to test for webkit only

The main reason here is a lack of time to test on other platforms which is understandable – we can assume that a lot of projects from a planning perspective have 99% iOS/Android written all over them. The “lack of incentive” number is high, too, which is understandable – if you can’t show the numbers, you don’t get the time to support.

If no, can you tell us why?
Fixed environment defined by client needs 36 23%
Lack of time to support more browser platforms 85 54%
Lack of incentive – I don’t know what the benefit of supporting more is 65 42%
Lack of documentation how to install and debug on non-webkit browsers 39 25%
Bugginess of other browsers on test platforms 24 15%
Lack of support for other browsers on target hardware 55 35%
Other 16 10%
People may select more than one checkbox, so percentages may add up to more than 100%.

More to come

These are just the numbers right now. Soon we’ll be publishing also the free-form comments we got but for now this should get some discussion going and gives us a great start.

And finally – a massive thank you for everybody who participated in this survey!

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)