Mozilla

Apps Articles

Sort by:

View:

  1. Launching Open Web Apps feedback channels – help us make the web better!

    About three months ago we launched a feedback channel for the Firefox Developer Tools, and since it was a great success, we’re happy announce a new one for Open Web Apps!

    For Developer Tools, we have, and keep on getting, excellent suggestions at http://mzl.la/devtools, which has lead to features coming from ideas there being implemented in both Firefox 32 & 33 – the first ideas shipped in Firefox only 6 weeks after we launched the feedback channels!

    Your feedback as developers is crucial to building better products and a better web, so we want to take this one step further.

    A channel for Open Web Apps

    We have now just opened another feedback channel on UserVoice about Open Web Apps, available at http://mzl.la/openwebapps

    It is a place for constructive feedback around Open Web Apps with ideas and feature suggestions for how to make them more powerful and a first-class citizen on all platforms; desktop, mobile and more.

    What we cover in the feedback channel is collecting all your ideas and also updating you on the different areas we are working on. In many cases these features are non-standard, yet: we are striving to standardize Apps, APIs, and features through the W3C/WHATWG – so expect these features to change as they are transitioned to become part of the Web platform.

    If you want to learn more about the current state, there’s lots of documentation for Open Web Apps and WebAPIs on MDN.

    Contributing is very easy!

    If you have an idea for how you believe Open Web Apps should work, simply just go to the feedback channel, enter a name and an e-mail address (no need to create an account!) and you’re good to go!

    In addition to that, you have 10 votes assigned which you can use to vote for other existing ideas there.

    Just make sure that you have an idea that is constructive and with a limited scope, so it’s actionable; i.e. if you have a list of 10 things you are missing, enter them as a separate ideas so we can follow up on them individually.

    We don’t want to hear “the web sucks” – we want you to let us know how you believe it should be to be amazing.

    What do you want the web to be like?

    With all the discussions about web vs. native, developers choosing iOS, Android or the web as their main target, PhoneGap as the enabler and much more:

    Let us, and other companies building for the web, know what the web needs to be your primary developer choice. We want the web to be accessible and fantastic on all platforms, by all providers.

    Share your ideas and help us shape the future of the web!

  2. Time to get hacking – Introducing Rec Room

    It’s no secret that the best frameworks and tools are extracted, not created out of thin air. Since launching Firefox OS, Mozilla has been approached by countless app developers and web developers with a simple question: “How do I make apps for Firefox OS?” The answer: “It’s the web; use existing web technologies.” was—and still is—a good answer.

    But if you don’t already have an existing toolchain as a web developer, I’ve been working on extracting something out of the way I’ve been creating web apps at Mozilla that you can use to write your next web app. From project creation to templating to deployment, Mozilla’s Rec Room will help you create awesome web apps in less time with more ease.

    Rec Room is a Node.js utility belt you can wear to build client side web apps. It includes:

    • Brick to add components like appbars and buttons to your UI.
    • Ember for your app’s controllers, models, and views.
    • Handlebars to write your app’s templates.
    • Grunt to run the tasks for your app, including building for production.
    • I18n.js to localize your app.
    • Mocha to test your app.
    • Stylus to write your CSS.
    • Yeoman to scaffold new code for your app’s models and templates.

    In this post I’ll walk through how to create a simple world clock web app with Rec Room, how to deploy it, and how you can try out Rec Room for yourself.

    Where Does Rec Room Come From?

    Much of Rec Room came from a recent rewrite of the HTML5 podcast app. I started working on this app well over a year ago, but its original version wasn’t as easy to work on; it had a lot of global state and a lot of by-hand data-binding. I liked the look of Ember for app development, but back when I started it didn’t quite feel mature enough. These days it’s much better, and I’ve tweaked it in Rec Room to work perfectly without a server.

    I tried to take the best from that system and extract it into a set of tools and documentation that anyone can use.

    Create your own Rec Room app

    Rec Room has just recently been extracted from my experiences with Podcasts; it hasn’t been tested by more than a handful of developers. That said: we’d love your help trying to build your own app for Firefox OS using these tools. They integrate well with tools you probably already know and use–like Node.js and Firefox’s own Web IDE.

    To get started, install Rec Room using Node.js:

    npm install -g recroom

    Clock App

    We’ll create a simple clock app with (minimal) time zone support for our example. The app will let you have a clock and compare it with a few time zones.

    The recroom binary is your entry point to all of the cool things Rec Room can do for you. First, create your app using recroom new world-clock. This creates the basic app structure. To see the basic app skeleton that Rec Room creates we can now enter that directory and run our app: cd world-clock and then type recroom run. The app will open in your default browser.

    First, we’ll add the current time to the main tab. Rec Room supports Ember’s MVC app structure, but also offers simple “pages” for a controller without a 1:1 relationship to a model. We’ll generate a new page that will show our actual clock:

    recroom generate page Clock

    We can edit its template by opening app/templates/clock.hbs. Let’s change clock.hbs to include the variable that will output our local time:

    <h2>Local Time: {{localTime}}</h2>

    That won’t do much yet, so let’s add that variable to our ClockController, in app/scripts/controllers/clock_controller.js:

    WorldClock.ClockController = Ember.ObjectController.extend({
        localTime: new Date().toLocaleTimeString()
    });

    You can see that any property inside the controller is accessible inside that controller’s template. We define the 1ocalTime property and it gets carried into our template context.

    Now our clock app will show the current local time when we navigate to http://localhost:9000/#clock. Of course, it just shows the time it was when the controller was initialized; there is no live updating of the time. We should update the time every second inside the controller:

    WorldClock.ClockController = Ember.ObjectController.extend({
        init: function() {
            // Update the time.
            this.updateTime();
     
        // Run other controller setup.
            this._super();
        },
     
        updateTime: function() {
            var _this = this;
     
            // Update the time every second.
            Ember.run.later(function() {
                _this.set('localTime', new Date().toLocaleTimeString());
                _this.updateTime();
            }, 1000);
        },
     
        localTime: new Date().toLocaleTimeString()
    });

    Now we can go to our clock URL and see our clock automatically updates every second. This is thanks to Ember’s data-binding between controllers and templates; if we change a value in a controller, model, or view that’s wired up to a template, the template will automatically change that data for us.

    Adding Timezones

    Next, we want to add a few timezones that the user can add to their own collection of timezones to compare against local time. This will help them schedule their meetings with friends in San Francisco, Buenos Aires, and London.

    We can create a timezone model (and accompanying controllers/routes/templates) with the same generate command, but this time we’ll generate a model:

    recroom generate model Timezone

    We want each timezone we’re to include in our app to have a name and an offset value, so we should add them as model attributes. We use Ember Data for this, inside app/scripts/models/timezone_model.js:

    WorldClock.Timezone = DS.Model.extend({
        name: DS.attr('string'),
        offset: DS.attr('number')
    });

    Next we’ll want a list of all timezones to offer the user. For this we’ll grab a copy of Moment Timezone. It’s an awesome JavaScript library for dealing with dates and times in JavaScript. We’ll install it with bower:

    bower install moment-timezone --save

    And then add it to our app inside app/index.html:

    <!-- build:js(app) scripts/components.js -->
    <!-- [Other script tags] -->
    <script src="bower_components/moment/moment.js"></script>
    <script src="bower_components/moment-timezone/builds/moment-timezone-with-data-2010-2020.js"></script>
    <!-- endbuild -->

    Adding that tag will automatically add moment-timezone-with-data-2010-2020.js to our built app. We’ll add a tab to the page that lets us edit our timezones, on a different screen than the clocks. To add a tab, we just need to open app/templates/application.hbs and add a tab. While we’re there, we’ll change the main tab from the useless {{#linkTo 'index'}} and point it to {{#linkTo 'clock'}}. The new application.hbs should look like this:

    <x-layout>
      <header>
        <x-appbar>
          <h1>{{t app.title}}</h1>
        </x-appbar>
      </header>
      <section>
        {{outlet}}
      </section>
      <footer>
        <x-tabbar>
          <x-tabbar-tab>
            {{#link-to 'clock'}}Clock{{/link-to}}
          </x-tabbar-tab>
          <x-tabbar-tab>
            {{#link-to 'timezones'}}Timezones{{/link-to}}
          </x-tabbar-tab>
        </x-tabbar>
      </footer>
    </x-layout>

    Side note: notice the root URL points to a useless welcome page? We probably want the default route to be our ClockController, so we can set the index route to redirect to it. Let’s do that now, in app/scripts/routes/application_route.js:

    WorldClock.ApplicationRoute = Ember.Route.extend({
        redirect: function() {
            this.transitionTo('clock');
        }
    });

    Interacting with Timezone models

    We’ll keep things simple for our example and allow users to select a timezone from a <select> tag and add it with a button. It will show up in their list of timezones, and they can delete it if they want from there. The clock tab will show all times. First, we’ll add our timezone data from Moment.js into our TimezonesController in app/scripts/controllers/timezones_controller.js. We’re also going to implement two actions: “add” and “remove”. These will be used in our template:

    WorldClock.TimezonesController = Ember.ObjectController.extend({
        init: function() {
            var timezones = [];
     
            for (var i in moment.tz._zones) {
              timezones.push({
                  name: moment.tz._zones[i].name,
                  offset: moment.tz._zones[i].offset[0]
              });
          }
     
          this.set('timezones', timezones);
     
          this._super();
      },
     
      selectedTimezone: null,
     
      actions: {
          add: function() {
              var timezone = this.store.createRecord('timezone', {
                  name: this.get('selectedTimezone').name,
                  offset: this.get('selectedTimezone').offset
              });
     
              timezone.save();
          },
     
          remove: function(timezone) {
              timezone.destroyRecord();
          }
      }
    });

    So we create a list of all available timezones with offsets. Then we add methods that allow us to add or remove timezones from our offline data store. Next we modify the timezones template in app/templates/timezones.hbs to use the actions and variables we created. All we need to utilize these variables is the Ember SelectView and the {{action}} helper to call our add and remove methods:

    <h2>Add Timezone</h2>
     
    <p>{{view Ember.Select content=timezones selection=selectedTimezone
           optionValuePath='content.offset' optionLabelPath='content.name'}}</p>
     
    <p><button {{action add}}>Add Timezone</button></p>
     
    <h2>My Timezones</h2>
     
    <ul>
      {{#each model}}
        <li>{{name}} <button {{action remove this}}>Delete</button></li>
      {{/each}}
    </ul>

    Now we have a Timezones tab that allows us to add and remove Timezones we want to track. This data persists between app refreshes. The last thing we need to do is show these times relative to our local time in our clock tab. To do this we need to load all the Timezone models in the ClockRoute. They’re automatically loaded in the TimezonesRoute, but it’s easy to add them in the ClockRoute (in app/scripts/routes/clock_route.js):

    WorldClock.ClockRoute = Ember.Route.extend({
        model: function() {
            return this.get('store').find('timezone');
        }
    });

    Because of the way our Ember app is wired up, we load all our models in the route and they are sent to the controller once the data store has asynchonously loaded all of the models. The request to find('timezone') actually returns a Promise object, but Ember’s router handles the Promise resolving for us automatically so we don’t have to manage callbacks or Promises ourselves.

    Now we have access to all the user’s Timezones in the ClockController, so we can make times in each timezone the user has requested and show them in a list. First we’ll add each Timezone’s current time to our ClockController in app/scripts/controllers/clock_controller.js using Moment.js:

    WorldClock.ClockController = Ember.ObjectController.extend({
        updateTime: function() {
            var _this = this;
     
            // Update the time every second.
            Ember.run.later(function() {
                _this.set('localTime', moment().format('h:mm:ss a'));
     
                _this.get('model').forEach(function(model) {
                    model.set('time',
                              moment().tz(model.get('name')).format('h:mm:ss a'));
                });
     
                _this.updateTime();
            }, 1000);
        }.on('init'),
     
        localTime: moment().format('h:mm:ss a')
    });

    Our final app/templates/clock.hbs should look like this:

    <h2>Local Time: {{localTime}}</h2>
     
    <p>
      {{#each model}}
        <h3>{{name}}: {{time}}</h3>
      {{/each}}
    </p>

    And that’s it! Now we have an offline app that shows us time zones in various places, saves the data offline, and updates every second without us having to do much work!

    Command Line Tools

    The old Podcasts app used a (rather awful) Makefile. It wasn’t very useful, and I don’t think it ran on Windows without some serious effort. The new build system uses Node so it runs comfortably on Windows, Mac, and Linux. Commands are proxied via the recroom binary, also written in Node, so you don’t have to worry about the underlying system if you don’t need to modify build steps. recroom new my-app creates a new app; recroom serve serves up your new app, and recroom generate model Podcast creates a new model for you.

    To build your app, you just need to run recroom build and a version with minified CSS, JS, and even HTML will be created for you in the dist/ folder. This version is ready to be packaged into a packaged app or uploaded to a server as a hosted app. You can even run recroom deploy to deploy directory to your git repository’s GitHub pages branch, if applicable.

    See the app in action!

    This entire sample app is available at worldclock.tofumatt.com and the source code is available on GitHub.

    Try Using Rec Room for Your Next Web App

    You can try out Rec Room on Github. Right now some docs and tools are still being abstracted and built, but you can start building apps today using it and filing bugs for missing features. We’d really love it if you could give it a try and let us know what’s missing. Together we can build a cohesive and polished solution to the all-too-common question: “How do I build a web app?”

  3. Turn your Facebook page into a Firefox OS mobile app

    Whether you are a business or community page owner, what would be better than increasing your page reachability by offering your standalone mobile app?

    Apptuter is an open source framework to help you achieve that, with minimum coding knowledge and easy to follow steps you would be able to produce your own app. The framework currently supports Facebook pages as a content source and is capable of producing apps for Firefox OS and Android platforms.

    How it works

    Let us take a test drive on how this is supposed to work. In our example we will generate a standalone app using Mozilla’s Facebook page as a content source.

    Clone the repository

    First step would be to download or clone the Apptuter-Firefox directory from the Apptuter repository:

    git clone https://github.com/egirna/apptuter.git
    

    Directory structure should look like this:

    Get the Facebook numerical id

    Then we will need to get the Facebook numerical page id. If you have assigned a friendly page name, the page ID will not be visible from the page URL, in this case we will need to visit the following URL to retrieve it: https://graph.facebook.com/mypagename

    In our example this would be: https://graph.facebook.com/mozilla

    Page ID will be visible on the first line of data returned.

    Create a Facebook app

    Next step would be creating a Facebook app: You will able to get App ACCESS TOKEN by combining APP ID & APP SECRET so that the requested URL should be in the following form: http://graph.facebook.com/endpoint?key=value&access_token=app_id|app_secret

    Requesting Page Info (Info.js) is where we are going to define those parameters, replace PageID with the numerical that can be found at /Apptuter-Firefox/js

    var Main = function () {
        this.pageName = ‘pageID’;
        this.name = null;
        this.category = null;
        this.description = null;
        this.photoArray = null;
        this.postArray = null;
        this.infoArray = [];
        this.accessToken = 'AppID|AppSecret';
        this.pictureUrl = null;
        this.paging = 'https://graph.facebook.com/' + this.pageName + '/posts?limit=20&amp;access_token='+this.accessToken;
        this.pagingNext = 'https://graph.facebook.com/' + this.pageName + '/posts?limit=20&amp;access_token='+this.accessToken;
    }

    Let us define our new app properties in the manifest.webapp file found at the directory root:

    {
      "name": "Mozilla App",
      "description": "This is an example app of apptuter framework",
      "launch_path": "/Shared/index.html",
      "icons": {
        "32": "/images/app_icon_32.png",
        "60": "/images/app_icon_60.png",
        "90": "/images/app_icon_90.png",
        "120": "/images/app_icon_120.png",
        "128": "/images/app_icon_128.png",
        "256": "/images/app_icon_256.png"
      },
      "chrome": {
        "navigation": true
      },
      "version": "1.0.1",
      "developer": {
        "name": "Egirna Technologies Limited",
        "url": "http://www.apptuter.org"
      },
      "orientation": [
        "portrait"
      ],
      "default_locale": "en"
    }

    Artwork

    Only thing left is the artwork. From the repository, go to /Apptuter-Firefox/images and replace the default images with those of our example logo with matching dimensions and file name.

    Success!

    And we are done! Let us test what the app would look like using Firefox OS Simulator:

    You ultimately are responsible to use this software in compliance with Facebook, Google and Mozilla terms of service and end user license agreement. This applies to any service this software may integrate with.

  4. 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!

  5. Firefox OS Apps run on Android

    At Mozilla we believe that apps and browsing are best viewed as cooperative and symbiotic, each better when working together. We are working to strengthen that relationship by building an apps ecosystem that is built using the Web technologies that so many developers are already familiar with.

    We built Firefox OS as a mobile OS that puts the Web and Open Web Apps at the centre of the mobile experience. The efforts to reduce the performance gaps between the Web and native are paying rich dividends and our work on exposing device capabilities to the Web via WebAPIs, have made web first app development a viable alternative to native platforms.

    Build Open Web Apps, run out-of-the-box on Android

    Now, with Firefox for Android 29, Mozilla is extending this open Open Web Apps ecosystem to Android. Over the past few months, we have been working on providing a “native experience” for Open Web Apps. What this means is that as a user, you can now manage your web app just like you would a native app. You can install/update/uninstall the app and the app will also show up in the App Drawer as well as the Recent Apps list.

    As a developer, you can now build your Open Web App for Firefox OS devices and have that app reach millions of existing Firefox for Android users without having to change a single line of code!

    Check out the video to see an Open Web App in action on an Android device,

    Better yet, if you have installed Firefox for Android try one or build an app and submit it to the Marketplace.

    We also recommend reading Testing Your Native Android App.

  6. Testing Your Native Android App

    It’s an interesting time to be a web developer!

    For years Apps have been eating the web and now we are seeing the Web eat the OS. Mozilla is pushing for a world where you can write standards-based, Open Web Apps. These apps should install as native apps and just work, regardless of the platform.

    Packaged App on Firefox OS

    With the new Firefox for Android, we will now automatically convert your Open Web App into a native Android app.

    Packaged App on Android

    But how can you test you app on Android, before you submit it to the Marketplace?

    We have a new tool to add to your lineup!

    Introducing mozilla-apk-cli

    If you have NodeJS as well as zip/unzip installed, then you can use our new command line tool to build testable .apk installers.

    mozilla-apk-cli is a command-line application, so the commands below would be run from a terminal application.

    Getting setup is easy:

    npm install mozilla-apk-cli

    This will give you a new program mozilla-apk-cli available in ./node_modules/.bin/

    You can also globally install with

    npm install -g mozilla-apk-cli

    I’ll assume you put ./node_modules/.bin in your path or installed globally.

    Open Web Apps come in three flavors and the CLI can build them all:

    • hosted app
    • packaged app zip file
    • packaged app from a directory of source code

    Let’s assume you have a packaged app you are working on.
    You have a directory layout like this:

    www/
       index.html
       manifest.webapp
       css/
           style.css
       i/
         icon-256.png
         icon-128.png
         icon-60.png
       js/
          main.js

    You can build a testable Android app with the following:

    mozilla-apk-cli ./www my_test_app.apk

    This will produce my_test_app.apk which can be side-loaded to your phone in either of the following ways:

    • Put in on the web and download/install form a browser on your Android device
    • Use adb to install the app
    adb install my_test_app.apk

    Setting up adb is out of scope for this blog post, but the Android SDK site has some good resources on adb.

    adb using USB

    Distribution

    Do not distribute this test .apk file!!!

    If you change your app, rebuild and send the APK to your users, the update will fail to install. With each new version of your app, using Android’s app manager, you have to remove the test app before installing the 2nd version.

    mozilla-apk-cli is only for testing and debugging your new Android app locally. When you are happy with your app, you should distribute the Open Web App through the Marketplace or from your website via an install page.

    You don’t need to manage an .apk file directly. Just like you don’t need to manage Mac OS X, Windows or Linux builds for your Open Web App.

    We’ve baked native Android support deeply into the Firefox for Android runtime. When a user chooses to install an Open Web App, the native app is synthesized on demand using the production APK Factory Service. This works regardless of the website or Marketplace you are installing the Open Web App from.

    How does the CLI work?

    Back to our new test tool. This tool is a frontend client to the APK Factory Service. It takes your code and sends it to a reviewer instance of the service. Reviewer as opposed to the production release environment.

    This service synthesizes an native Android app, builds it with the Android SDK and lastly signs it with a development cert. As mentioned, this synthesized APK is debuggable and should not be distributed.

    The nice thing about the service is that you do not have to have Java, ant, the Android SDK and other Android development tools installed on your local computer. You can focus on the web and test on whatever devices you have handy.

    Hosted and Packaged Zip files

    We just looked at how to test a packaged app which is a directory of source code. Now lets look at the other two modes. If you already have built your packaged app into a .zip file, use:

    mozilla-apk-cli ./my_app.zip my_test_app.apk

    If you are building a hosted app, use:

    mozilla-apk-cli http://localhost:8080/ my_test_app.apk

    No Android Devices? No stress

    Perhaps you are saying "Sounds cool, but I don’t have any Android devices… How am I supposed to test?"

    Good point. We’re enabling this automatically.

    On the one hand, don’t worry. One thing mobile first development has taught us, is that there are way more devices and platforms that you will ever have testing resources for. The web is about open standards and progressive enhancement.

    Your web app is just going to be a little bit nicer as a native android app, fitting into the OS as the user expects.

    It doesn’t use native UI widgets or anything like that, so extensive testing is not required. The rendering engine is gecko from the already installed Firefox for Android.

    On the other hand… open standards and compatibility is a nice story, but as web developers, we know things tend to have platform specific bugs. I’d recommend the traditional grading of supported platforms and if Android is a high priority, definitely get a device, Firefox for Android and test your app.

    As we make native experiences automatic across platforms (Android, Mac OS X, etc) we are all ears for feedback. What do you think?

    mozilla-apk-cli Resources

    The source code for the CLI tool is on GitHub. If you need a sample packaged app, here is a demo version. The source code for the APK Factory Service is also on GitHub.

    Join us in with ideas, feedback and questions and please file bugs in Marketplace Integration.

    Thanks to Wil Clouser for the illustrations.

  7. Build Your Next App With a Flame

    Earlier this week, we introduced Flame, the Firefox OS reference device for developers, testers and reviewers from T2Mobile, and announced the opening of the everbuying.com pre-order page. The Flame retails at $170 (USD), global shipping included.

    Wanted: Engaging apps for Firefox OS

    Flame2If you are an experienced HTML5 app developer with a published, well-rated app that you’d like to port to Firefox OS, we’d love to hear from you! It’s always exciting to discover topnotch apps (such as PhoneGap app Find the Movie, pictured to the right running on a Flame) and see them ported from native platforms to Firefox OS. We currently have a small inventory of Flame phones for qualified HTML5 app developers with published, well-rated apps.

    How to qualify

    Through our ongoing Phones for Apps program, there’s an opportunity now for a limited number of invited app developers to receive Flame devices in exchange for a commitment to port their qualifying HTML5 apps within a month of receiving the device. Please apply here.

    There are only three ways to qualify:

    1. You’ve built a successful, well-rated HTML5 app on another platform (such as Amazon Web Apps, Blackberry WebWorks, Chrome Web Store, WebOS, Windows Phone or the PhoneGap store) and are ready to port it now to Firefox OS.
    2. You’ve built a successful, well-rated native app for iOS or Android using a cross-platform wrapper like Cordova or PhoneGap and are ready to port it to Firefox OS. Be sure to indicate the cross-platform tool you used.
    3. You’ve already published a well-rated app in Firefox Marketplace, and you have a second app in progress or already built, and are ready to port it now to Firefox OS.

    Resources

    • Learn more about the Flame (Mozilla Developer Network)
    • Get started with Open Web Apps (Mozilla Developer Network)
    • Mark your calendars for Marketplace Day, June 26 – it’s all about Apps and how you can contribute – as app developers, testers, reviewers and localizers. Hope you can join us!
  8. Introducing TranslationTester and localization support for Open Web Apps

    When building Open Web Apps, one important factor is to make your content available to as many possible, and one way to do that is to make it available in more than one language. Therefore we want to make it as easy as possible for you, both with a complete code repository to get started and updated documentation and possibilities to get translations for your apps.

    We are now also offering a way to have your app set up and to get connected to localizers directly!

    Presenting TranslationTester

    Based on the great work and content by Jason in Localizing Firefox OS Apps and Christie in Localizing the Firefox OS Boilerplate App, I’ve been working on simplifying the set-up for localization.

    Above articles describe many facets and possibilities available, and to complement that, I wanted to be able to offer the most basic code and structure for most use cases: basically, just add translations and you’re good to go!

    This lead to the creation of the TranslationTester code repository, available on GitHub.

    From no translation to localized app in less than 4 minutes!

    Based on the TranslationTester, Will Bamberg has put together a nice and short screencast showing the exact process of going from no translations to having support in just a few minutes!

    In the app-l10n-example repository you have versions of the before and after stages in this screencast, and all of the localization process is described on MDN.

    How to localize an app

    These are the things needed to localize an app. All of them are included in the TranslationTester repository, but included here to show easy it is to get started, or continue to build on the TranslationTester platform for your app.

    Mark up the HTML

    For any element that you want to have its text localized, add a data-l10n-id attribute to the desired element. For example:

    <p data-l10n-id="winter-for-real">Winter for real</p>

    Create translations

    In the locales directory, you have a directory for each language, and can just add new ones for new languages. In each language directoy you create an app.properties file which will contain all your translations for that language (optionally you can also create a manifest.properties file for the name and description of the app, unless you edit it in the main manifest.webapp for your app).

    Include l10n.js

    By including the l10n.js file, the translations for respective language’s app.properties file will be applied to element with the corresponding data-l10n-id attribute.

    Add “name” and “description” translations

    The translations for the name and description for your app could be added to the main manifest.webapp file, or in an optional manifest.properties under each locale’s directory.

    How to view different locales

    To view your app with a different locale, change the language in Firefox/App Manager:

    All platforms
    Set the desired locale to test in JavaScript, e.g:

    document.webL10n.setLanguage("es");
    App Manager/Firefox OS
    Language setting in the Settings app
    Firefox
    Choose language under Preferences > Content > Languages. More information in Set content language in Firefox

    Get help with translations

    We have a Mozilla localization app pilot offered through the Transifex service. As part of that, we’re offering you to add your apps as part of this pilot, to be connected to localizers and quickly offer your app in more languages, to more people.

    Please apply in the Localize My Firefox App form to get started!

  9. Firefox OS App Workshop Prague

    Update:This event will be rescheduled for Autumn 2014. We are designing the workshop with a new regional focus and aim to re-open the invitation request form with a confirmed date and venue before the summer starts. Please stay tuned here on the Hacks blog.

    Back in March, Mozilla tech evangelist Frédéric Harper visited Prague in the Czech Republic and gave a talk at the local Prague JavaScript meetup. His presentation, Empower Mobile Web Developers With JavaScript and WebAPI introduced a roomful of Czech JavaScripters to Firefox OS, Open Web Apps, and our recent integration with Apache Cordova and Adobe PhoneGap. PhoneGap/Cordova developers who’ve built native apps for other platforms and stores can now port PhoneGap-built apps to Firefox OS.

    Just as sure as the coming of summer, Firefox OS is coming to the Czech Republic in 2014, and Fred and friends are heading back to Prague to host a full-day, invitation-only Firefox OS App Workshop on Saturday, June 28. There will be phones! All participants will receive a developer device to test and demo their apps, and to keep for future app development. For free.

    Requirements: Show us your app

    REQUIRED: To qualify for this free hands-on, technical workshop, you must be able to show us a published HTML5 app that you’re porting to Firefox OS or a working Firefox OS app in progress. Show us a link to your existing app or to working code for the app you’re building.

    Apply now for the Prague App Workshop, June 28, 2014.

    FoxSay500


    NOTE: If you do not provide relevant links to working app code we will not be able to consider your application. Firefox Marketplace currently offers plenty of tic-tac-toe games, sliding puzzles, calculators, and to-do list apps. We love to be impressed by new, original, and locally relevant apps, for work and play.

    In the Czech Republic, we need apps that are in Czech. And if you want to extend the reach of your app by translating it to other languages, we have a pilot localization program to help you.

    What to expect

    This workshop is open to individual developers and teams of up to 4 people. The workshop begins with a technical introduction in English in the morning; the rest of the time is for coding and testing your app using the App Manager that’s built in Firefox Developer Tools. Bring laptops and devices.

    At the close of the day, there will be demos of all the apps in progress. After demos, we’ll all go to dinner. Mozilla will provide food and drink throughout the day of the workshop, but travel and lodging arrangements are up to you. And after the workshop, we will stay in touch while you complete your apps and submit them to Firefox Marketplace.

    Resources

    If you don’t have a Firefox OS app in progress, here are some resources to help you get started. There’s never been a better time:

  10. HTML out of the Browser

    Amongst my friends, I’m known as something of a Star Wars nerd. My longtime nick has been cfjedimaster (a combination of two passions, the other being ColdFusion), I work in a room packed to the gills with Star Wars toys, and I’ve actually gotten inked up twice now with Star Wars tats. That being said, it was another movie that had the most influence on my current career – Tron.

    Tron_poster

    I had already discovered an interest in computers before then, but it was Tron that really crystallized the idea for me. All of sudden I imagined myself being the programmer – creating intelligent programs and dominating the grid. Yeah, I know, I was a nerd back then too.

    My dreams, though, ran into reality rather quickly during my time as a Comp Sci major in college. First – I discovered that “Hey, I’m good at math!” means crap all when you hit Calculus 3, and secondly, I discovered that I really wasn’t that interested in the performance of one sort versus another. I switched to English as a major (always a good choice) but kept messing around with computers. It was during this time that I was exposed to Mosaic and the early web.

    I quickly jumped into the web as – well – I’ll put it bluntly – easier programming than what I had been exposed to before. I can remember LiveScript. I can remember my first Perl CGI scripts. This wasn’t exactly light cycle coding but it was simpler, fun, and actually cutting edge. I’ve spent a good chunk of my adult life now as a web developer, and while I certainly have delusions of the web being a pristine environment, it has been good to me (and millions of others) and I’m loving to see how much it evolves over time.

    One of the most fascinating ways that web technologies have grown is outside of the web itself. In this article I’m going to look at all the various ways we can reuse our web-based technologies (HTML, JavaScript, and CSS) in non-web based environments. While it would be ludicrous to say that one shouldn’t learn other technologies, or that web standards work everywhere and in every situation, I feel strongly that the skills behind the web are ones open to a large variety of people in different disciplines – whether or not you got that PhD in computer science!

    Mobile

    This is typically the point where I’d discuss how important mobile is, but it’s 2014 and I think we’re past that now. Mobile development has typically involved either Java (Android) or Objective-C (iOS). Developers can also use web standards to build native applications. One solution is Apache Cordova (AKA PhoneGap).

    Cordova uses a web view wrapped in a native application to allow web developers to build what are typically referred to as hybrid applications. Along with providing an easy way to get your HTML into an app, Cordova provides a series of different plugins that let you do more than what a typical web page can do on a device. So for example, you have easy access to the camera:

    navigator.camera.getPicture(onSuccess, onFail, { quality: 50,
        destinationType: Camera.DestinationType.DATA_URL
    });
     
    function onSuccess(imageData) {
        var image = document.getElementById('myImage');
        image.src = "data:image/jpeg;base64," + imageData;
    }
     
    function onFail(message) {
        alert('Failed because: ' + message);
    }

    You can also work with the accelerometer, GPS, contacts, the file system, and more. Cordova provides a JavaScript API that handles the communication to native code in the back end. Best of all, the same code can be used to build native applications for multiple different platforms (including Firefox OS, now supported in Cordova & PhoneGap).

    To be clear, this isn’t a case of being able to take an existing web site and just package it up. Mobile applications are – by definition – completely different from a simple web site. But the fact that you can use your existing knowledge gives the developer a huge head start.

    Another example of this (and one that is hopefully well known to readers of this site) is Firefox OS. Unlike Cordova, developers don’t have to wrap their HTML inside a web view wrapper. The entire operating system is web standards based. What makes Firefox OS even more intriguing is support for hosted applications. Firefox OS is a new platform, and the chance that your visitors are using a device with it is probably pretty slim. But with a hosted application I can easily provide support for installation on the device while still running my application off a traditional URL.

    Consider a simple demo I built called INeedIt. If you visit this application in Chrome, it just plain works. If you visit it in a mobile browser on Android or iOS – it just works. But visit it with Firefox and code will trigger to ask if you want to install the application. Here is the block that handles this.

    if(!$rootScope.checkedInstall &amp;&amp; ("mozApps" in window.navigator)) {
     
        var appUrl = 'http://'+document.location.host+'/manifest.webapp';
        console.log('havent checked and can check');
        var request = window.navigator.mozApps.checkInstalled(appUrl);
     
        //silently ignore
        request.onerror = function(e) {
            console.log('Error checking install '+request.error.name);
        };
     
        request.onsuccess = function(e) {
            if (request.result) {
                console.log("App is installed!");
            }
            else {
                console.log("App is not installed!");
                if(confirm('Would you like to install this as an app?')) {
                    console.log('ok, lets try to install'); 
                    var installRequest = window.navigator.mozApps.install(appUrl);
     
                    installRequest.onerror = function() {
                        console.log('install failure: '+this.error.name);
                        alert('Sorry, install failed.');    
                    };
     
                    installRequest.onsuccess = function() {
                        console.log('did it');
                        alert('Thanks, app installed!');    
                    };
                }
                $rootScope.checkedInstall=true;
            }
        };
     
    } else {
        console.log('either checked or non compat');                
    }

    Pretty simple, right? What I love about this is that the code is 100% ignored outside of Firefox OS but automatically enhanced for folks using that operating system. I risk nothing – but I get the benefit of providing them a way to download and have my application on their device screen.

    FF OS prompting you to install the app

    Desktop

    Of course, there are still a few people who sit in front of a gray box (or laptop) for their day to day work. Many desktop applications have been replaced by web pages, but there are still things that outside the scope of web apps. There are still times when a desktop app makes sense. And fortunately – there’s multiple ways of building them with web standards as well.

    So you know the code example I just showed you? The one where Firefox OS users would be given a chance to install the application from the web page? That exact same code works on the desktop as well. While still in development (in fact, the application I built doesn’t work due to a bug with Geolocation), it will eventually allow you to push your web based application both to a mobile Firefox OS user as well as the other billion or so desktop users. Here’s the application installed in my own Applications folder.

    INeedIt as a desktop app

    As I said though – this is still relatively new and needs to bake a bit longer before you can make active use of it. Something you can use right now is Node Webkit. This open source project allows you to wrap Node.js applications in a desktop shell. Executables can than be created for Windows, Mac, and Linux. You get all the power of a “real” desktop application with the ease of use of web standards as your platform. There’s already a growing list of real applications out there making use of the framework – some I had even used before what realizing they used Node Webkit behind the scenes.

    As an example, check out A Wizard’s Lizard, a RGP with random dungeons and great gameplay.

    Screen shot - Wizard's Lizard

    Native App Extensions

    In the previous section we covered applications built with web standards. There are also multiple applications out there today, built natively, that can be extended with web standards. As a web developer you are probably already familiar with Firefox Add-Ons and Chrome extensions. There is an incredibly rich ecosystem of browser extensions for just about any need you can think of. What interests me however is the move to use web standards to open other products as well.

    Did you know Photoshop, yes, Photoshop, now has the ability to extended with Node.js? Dubbed “Adobe Generator”, this extensibility layer allows for a script-based interface to the product. One example of this is the ability to generate web assets from layers based on a simple naming scheme. If you’ve ever had to manually create web assets, and update them, from a PSD, you will appreciate this. The entire feature though is driven by JavaScript and all makes use of a public API you can build upon. The code, and samples, are all available via GitHub.

    Generator running within Photoshop

    What Next?

    Coming from the perspective of someone who has been in this industry for way too long, I can say that I feel incredibly lucky that web standards have become such a driving force of innovation and creativity. But it is not luck that has driven this improvement. It is the hard work of many people, companies, and organizations (like Mozilla) that have created the fertile landscape we have before us today. To continue this drive requires all of us to become involved, evangelize to others, and become proponents of a web created by everyone – for everyone.