Mozilla

Apps Articles

Sort by:

View:

  1. r2d2b2g: an experimental prototype Firefox OS test environment

    Developers building apps for Firefox OS should be able to test them without having to deploy them to actual devices. I looked into the state of the art recently and found that the existing desktop test environments, like B2G Desktop, the B2G Emulators, and Firefox’s Responsive Design View, are either difficult to configure or significantly different from Firefox OS on a phone.

    Firefox add-ons provide one of the simplest software installation and update experiences. And B2G Desktop is a lot like a phone. So I decided to experiment with distributing B2G Desktop via an add-on. And the result is r2d2b2g, an experimental prototype test environment for Firefox OS.

    How It Works

    r2d2b2g bundles B2G Desktop with Firefox menu items for accessing that test environment and installing an app into it. With r2d2b2g, starting B2G Desktop is as simple as selecting Tools > B2G Desktop:

    B2G Desktop Menu Item

    To install an app into B2G Desktop, navigate to it in Firefox, then select Tools > Install Page as App:

    Install Page As App Menu Item

    r2d2b2g will install the app and start B2G Desktop so you can see the app the way it’ll appear to Firefox OS users:

    B2G Desktop

    Try It Out!

    Note that r2d2b2g is an experiment, not a product! It is neither stable nor complete, and its features may change or be removed over time. Or we might end the project after learning what we can from it. But if you’re the adventurous sort, and you’d like to provide feedback on this investigation into a potential future product direction, then we’d love to hear from you!

    Install r2d2b2g via these platform-specific XPIs: Mac, Linux (32-bit), or Windows (caveat: the Windows version of B2G Desktop currently crashes on startup due to bug 794662 795484), or fork it on GitHub, and let us know what you think!

  2. Better integration for open web apps on Android

    Up until now, developing web apps on mobile has been a little tricky.

    After spending the time developing your app, getting your users to install it is difficult, especially when the concept of “installing a web app” is not very well defined.

    The most popular method is synonymous with adding a shortcut to the homescreen. This is problematic on a number of fronts, not least because the management of web apps – especially around launching, switching between and uninstalling web apps – differs significantly from that of native apps.

    The web app “exists” only on the homescreen, not in the app drawer.

    When it’s running, it is not clearly marked in the Recent Apps list.

    Even once you get something like a smooth user-flow of installing your app onto the user’s phone’s homescreen, you often find that your app is running in a degraded or out-of-date web view, missing out on compatibility or speed optimizations of a desktop class browser.

    What we as developers would like is a modern, fast web runtime, which is kept up-to-date on our devices.

    Wouldn’t it also be nice for our users to launch and manage their web apps in the same way as native apps?

    Introducing APK Factory

    We have been working on making web apps be real on the desktop for some time. On the desktop, if you install a web app, Firefox will repackage the app as a desktop app so that it will integrate perfectly with the rest of your system – as outlined in more detail in Progress report on cross-platform Open Web Apps.

    That means being in the Start menu on Windows, or in the Launch Control screen on Mac OS X.

    From Firefox 29, that will apply to Android too.

    This means that as a web developer, you can rely on a modern, up-to-date web runtime on Android to run your web apps. Even better, that web runtime is provided by an ordinary Android app, which means it will stay modern and up-to-date, and you can finally say goodbye to the Android Browser.

    A web app, called ShotClock. Notice its icon in the top right of the screen.

    The user will experience your web app as if it is a real native Android app:

    • The app appears in the App Drawer, the Recent Apps list, with its own names and icons,
    • The app can be installed and uninstalled just like a native Android app,
    • The app can be updated just like a native Android app.

    In the App Drawer

    In the Recent Apps list: all these apps are web apps

    Installed with certain permissions

    Best yet, is that we make these changes without the developer needing to do anything. As a developer, you get to write awesome web apps, and not worry about different packaging needed to deliver the web app to your users.

    So if you’re already making first-class apps for Firefox OS, you’re already making first-class apps for Android.

    The Technical details

    On Firefox, you can install an app using the window.navigator.mozApps.install(manifestUrl) method call. Any website can use this API, so any website can become an app store.

    The manifestUrl is the URL of a manifest.json document which describes the app to your phone without actually loading the app:

    • The app’s name and description, translated into any number of languages.
    • The app’s icon, in various sizes for different pixel densities.
    • The permissions that the app needs to run.
    • The WebActivities that the app wants to register.
    • For packaged apps only, this provides a URL to the zip file containing the app’s code and resources.

    On Firefox for Android, we implement this method by sending the URL to a Mozilla-managed service which builds an Android APK specifically for the app.

    APKs created by the Factory use Android’s excellent Resource framework so that the correct icon and translation is displayed to the user, respecting the user’s locale or phone screen.

    Web app permissions are rendered as Android permissions, so the user will have a completely native experience of installing your app.

    For packaged apps, the APK also includes a copy of the packaged zip file, so that no extra networking is required once the app is downloaded.

    For hosted apps, the first time the app is launched, the resources listed in its appcache are downloaded, so that subsequent launches can happen as quickly as possible, without requiring a network connection.

    And if you want to detect if the app is running in a web app versus in a webpage, checking the getSelf() method call will help you:

    if (window.navigator.mozApps) {
      // We're on a platform that supports the apps API.
      window.navigator.mozApps.getSelf().onsuccess = function() {
        if (this.result) {
          // We're running in an installed web app.
        } else {
          // We're running in an webpage.
          // Perhaps we should offer an install button.
        }
      };
    }

    Keeping your apps up-to-date

    For hosted apps, you update your apps as usual: just change your app on your server, and your users will pick up those changes the next time they run your app. You can change as much as you want, and your users will get the latest version of the app each time they launch and connect to your servers.

    For anything needing changes to the app’s manifest, your users will get an updated APK sent to them to update their existing installation.

    For example, if you want to change the app’s icon, or even name, changing the app’s manifest will cause the APK Factory service to regenerate the app’s APK, and notify your users that there is a new version available for install.

    For packaged apps, the same mechanism applies: change the app’s package zip file, then update the version number in the app’s manifest file, and the APK Factory will pick up those changes and notify your users that an updated app is available. Your users will get an notified that there’s a new APK to install. Simples.

    Is that it?

    This is an exciting project. It has very little web developer involvement, and no extra API for developers to use: however, it should represent a step forward in usability of web apps on Android.

    Now that we have taken the step to generate APKs for web apps, this gives us a platform for further blurring the lines between web apps and apps. Check it out for yourself and help us improve the feature: get Firefox Beta from the Google Play Store, install apps from the Firefox Marketplace, and let us know what you think!

  3. Phones for Apps for Firefox OS

    Update: Today, Wednesday, June 19, we began inviting app developers with winning Firefox OS app proposals to join the Phones for Apps program. We will begin shipping Geeksphones to app developers who’ve committed to building and porting apps for Firefox OS. Congratulations.

    Thanks to everyone who participated by sending a proposal. The open mobile web needs your interest and enthusiasm. And your apps!

    Whether or not you receive an invitation now, the Marketplace is open and there’s never been a better time to submit your apps. We regret we can’t respond to the thousands of you with great ideas for apps for Firefox OS. There will be other opportunities to get access to the the Developer Preview device. We can’t wait to see what you build.

    Hello HTML5 app developers, the open mobile web is calling.

    We know you’re out there, chomping at the bit, coding, testing, reading documentation, downloading and running the Firefox Simulator. And you’re ready to ‘Send to Device.’ You just need to get your hands on a device.

    Today we’re announcing a new program with you in mind. We call it: Phones for Apps for Firefox OS.

    Firefox Marketplace on the Geeksphone

    Firefox Marketplace on the Geeksphone Keon

    Maybe you’ve built apps in the past for Chrome, webOS, Blackberry WebWorks, or the PhoneGap store. Maybe you’ve created beautiful web apps for a desktop environment and now you want to port them to mobile. Maybe you’re a student about to start a summer break. We know you may not live anywhere near Bogota, Colombia or Warsaw, Poland, locations of upcoming App Workshops.

    Wherever you are

    Wherever you are, if you can show you’ve got a great app idea and the skill to build it, we’d love to see your apps in the Marketplace when the Firefox OS launch begins later this summer. And to sweeten the deal, we’ll send a Firefox OS Developer Preview device for you to work with now.

    When Firefox OS phones become available to consumers in select locales this summer, you’ll have an opportunity that only comes around once—a first-mover advantage in Firefox Marketplace. End users in Latin America, Eastern Europe and other launch locations will be on the lookout for playful and practical apps to install: games, tools, and utilities as well as locally relevant news, sports, travel, entertainment, review apps, and social sharing experiences. And you can build and submit them now!

    Apply now

    Tell us about the Firefox App you’d like to build or port. If your proposal is accepted, we’ll send you a Geeksphone Keon. Our device inventory is limited and our launch dates are approaching fast, so act now. This program will close at the end of May or when our limited supply of Geeksphones runs out. There’s a limit of one phone per app proposal. We can’t wait to see what you’re working on. There’s never been a better time to get started.

    Note: We are not accepting applications for the Phones for Apps program at this time.

  4. Introducing navigator.mozPay() For Web Payments

    What’s wrong with payments on the web? Any website can already host a shopping cart and take credit card payments or something similar. The freedom of today’s web supports many business models. Here’s what’s wrong:

    • Users cannot choose how to pay; they have to select from one of the pre-defined options.
    • In most cases, the user has to type in an actual credit card number on each site. This is like giving someone the keys to your expensive car, letting them drive it around the block in a potentially dangerous neighborhood (the web) and saying please don’t get carjacked!
    • Merchants typically have to manage all this on their own: payment processor setup, costly processing fees, and possibly even PCI compliance.

    There are services to mitigate a lot of these complications such as PayPal, Stripe, and others but they aren’t integrated into web devices very well. Mozilla wants to introduce a common web API to make payments easy and secure on web devices yet still as flexible as the checkout button for merchants.

    As a first step, Mozilla will introduce navigator.mozPay() in Firefox OS so that web apps can accept payments.

    How Does It Work?

    navigator.mozPay() is a JavaScript API inspired by google.payments.inapp.buy() but modified for things like multiple payment providers and carrier billing. When a web app invokes navigator.mozPay() in Firefox OS, the device shows a secure window with a concise UI. After authenticating, the user can easily charge the payment to her mobile carrier bill or credit card. When completed, the app delivers the product. Repeat purchases are quick and easy.

    In an earlier article I talked about purchasing an app and receiving a receipt. navigator.mozPay() is different in that there is no concept of what product is purchased, it’s just an API to facilitate a payment for a digital good or service, whatever that may be.

    The payment starts and finishes in the client but further processing and notifications happen server side. This article briefly explains how it all fits together. For complete, in-depth documentation read the Firefox Marketplace guide to in-app payments.

    Integrating With A Payment Provider

    Multiple providers will facilitate payments behind the scenes of navigator.mozPay(). For example, the Firefox Marketplace will be able to facilitate payments.

    As a developer you will essentially grant permission to each provider that you would like to sell through. In the current design of the API, you do this by asking each provider for an Application Key and an Application Secret so that you can digitally sign payment requests. A signed request prevents unauthorized parties from selling your products and prevents users from tampering with the price, etc.

    Initiating A Payment

    When the user clicks a Buy button in your web app, you create a JSON Web Token (JWT) with your Application Secret. If you have agreements with multiple providers, you would create a JWT for each provider. Starting a payment looks roughly like this:

    document.querySelector('button.buy').onclick = function() {
        navigator.mozPay([mozillaJWT, otherJWT, ...]);
    };

    Defining A Product

    A JWT is a signed JSON object that defines details like the product name and price. Here is an example with some attributes removed for brevity:

    {
      "iss": APPLICATION_KEY,
      "aud": "marketplace.firefox.com",
      ...
      "request": {
        "name": "Magical Unicorn",
        "pricePoint": 1,
        "postbackURL": "https://yourapp.com/postback",
        "chargebackURL": "https://yourapp.com/chargeback"
      }
    }

    You define prices as price points so that the payment provider can handle currency conversions for you in each region. In this example, pricePoint 1 might be €0.89 or $0.99, etc. Micropayments in small amounts will be supported. Consult the navigator.mozPay() spec for details on how to construct a payment request JWT.

    Completing a Payment

    To complete the payment, you need to wait for the provider to POST a result to your server’s postbackURL (on success) or chargebackURL (on failure). A more complete example of requesting a purchase in JavaScript would involve waiting for the postback to arrive, like this:

    var request = navigator.mozPay([mozillaJWT, otherJWT]);
    request.onsuccess = function() {
      // The payment window has closed.
      whenPaymentResultReceived(function() {
        console.log('Success! User has purchased a Magical Unicorn.');
      });
    };

    To implement whenPaymentResultReceived() you might open a web socket to your server, wait for the payment result, and verify the incoming JWT signature. The navigator.mozPay() spec has details on how postback and chargeback notifications work.

    Try It Out

    Payments aren’t fully live yet in the Firefox Marketplace but you can simulate a payment to test out your code. Log into the Firefox Marketplace Developer Hub and generate an Application Key and Application Secret for simulations. With those keys you can add a special parameter to the JWT like this:

    {
      "request": {
        "name": "Magical Unicorn",
        "pricePoint": 1,
        ...
        "simulate": {"result": "postback"}
      }
    }

    This will show a payment window on Firefox OS but it won’t charge you real money. It will let you test your client side JavaScript code and your server postback handlers to make sure everything is integrated smoothly. When you go live, just remove the simulate attribute. If you’re new to Firefox OS development, check out the Firefox OS Simulator.

    If you’re already working on a game or a web app for Firefox OS try thinking about using navigator.mozPay() to offer premium content.

    This Would Be Way Easier With A Library

    We thought so too! We built libraries for Node.JS and Python to make the server side logic for navigator.mozPay() as easy as possible. Libraries for more languages are on the way. We also are experimenting with removing the server prerequisite entirely.

    Current Status

    As you can probably tell by the prefix, navigator.mozPay() is an experimental API and might change drastically or become unprefixed without notice. It will process live payments on the first Firefox OS phones and evolve quickly from real world usage.

    Mozilla plans to work with other vendors through the W3C to reach consensus on a common API that supports web payments in the best way possible. After shipping in Firefox OS, Mozilla plans to add navigator.mozPay() to Firefox for Android and desktop Firefox.

    New Business Models

    Advertising has been the primary business model on the web for a long time but users have made it clear that they don’t want to see ads. Mozilla isn’t trying to directly disrupt the ad business but it is trying to fix serious privacy issues relating to ad networks.

    What if users explicitly paid for content instead? navigator.mozPay() enables this kind of direct payment model: if something is good on the web, you can pay for it. It already seems to be working well for existing mobile apps. Will mobile ads even generate the same revenue for content producers as they do on desktop? I don’t have answers to these questions but one thing is for certain: the web should support businesses of all kinds and payments should be a first class feature of the web.

    Is It Webby?

    Mozilla’s main goal with navigator.mozPay() is to give users and merchants choice, security, and an easy to use payments system. The details about how merchants interact with payment providers is not yet specified in the API and that is clearly a gap. The first Firefox OS phones will ship with a whitelist of allowed payment providers which is also not ideal.

    In a more webby model, all parties involved in the payment would be fully decentralized so that innovation can occur naturally and unknown payment providers could emerge. Who will be the next M-Pesa? An elegant API would support that. Building a secure decentralized payment API is an ambitious challenge; the solution would need to address these core trust issues:

    • How can customers trust that they will receive the goods after paying?
    • How would customers ensure that their payment credentials are handled securely?
    • How do merchants guarantee that they’ll get paid after delivering goods?

    As with anything related to money, there is incentive for fraud every step of the way. BitCoin is a digital currency that solves some of these trust issues with block chains and PaySwarm is a web payment protocol that solves some of these issues with decentralized assets, public keys, etc. Mozilla will be watching PaySwarm as well as other models and hopefully navigator.mozPay() can incorporate some of these concepts eventually.

  5. Calling All Porters: Phones for App Ports to Firefox OS

    Back in May we launched a program for app developers called Phones for Apps for Firefox OS. We heard from thousands of developers in all corners of the world– thank you for your overwhelming interest.

    Developers at BrazilJS by holmes.josh
    Since then we’ve shipped out heaps of Geeksphone Keon Firefox OS Developer Preview phones and we’ve listed many new apps in Firefox Marketplace, including games like Rooftops and Yatzy, and L’Arrosoir, a lovely French language garden app. If you’ve built and submitted your app, thank you! Hope the rest of you are making good progress.

    Phase 2 now open

    Today we’re opening up the second phase of Phones for Apps for Firefox OS. This phase is about sending you a device (for keeps!) to make it easier for you to PORT and test your existing HTML5 app. We’re hyper-focused on getting Firefox OS phones into the hands of porters – developers who’ve already built and shipped an HTML5 web app and have the time now to port that app to the new Firefox OS platform.

    Help Mozilla bring the open web to the world of mobile — and gain yourself a first-mover advantage in the Firefox Marketplace.

    First step: Apply.

    Guidelines

    Here’s what you need to know when you apply.

    • We expect to see a URL for a web site, a code repository, or an app platform such as Amazon Web Apps, Blackberry WebWorks, Chrome Web Store, webOS, or the PhoneGap store. If you wrapped an HTML5 app with a native skin to distribute it to iTunes, Google Play or another app market, please indicate the tool you used (e.g., Appcelerator, PhoneGap, Sencha).
    • You must be able to get to work quickly. We are looking for completed apps in September and October.
    • Don’t wait to hear from us. Get started now by downloading the Firefox OS Simulator.
    • REMINDER: If you can’t point us to a live HTML5 app, you will not be eligible for this program.

    Introducing Firefox OS

    Apply

    We look forward to reviewing your application. We’ll send an email confirmation when you complete the form. Then we will be in touch only if you are selected to receive a phone. Otherwise you will not hear from us. Thanks for your understanding. (We’re a really small team.)

    Can’t wait to see your awesome ported apps. Apply now!

    Photo credits: Thanks to Josh Holmes for the great shot from BrazilJS and to MozillaEU for the image from the Firefox OS Debut Poland.

  6. Announcing the prototype Firefox OS Simulator

    Firefox OS (and the Boot2Gecko (B2G) project on which it is based) has been written about extensively on Hacks already, but the brief summary is that Mozilla is building a mobile phone operating system where the whole user interface is built on web technology (HTML, CSS and JavaScript). Part of the magic in making that happen is that we’re giving the web platform new superpowers that enable it to access more device capabilities and data sources. Using the web as a basis for apps means that you can build a single app that works on many platforms and with a lot more freedom as a developer.

    Getting Started

    If you’re thinking “that all sounds great, but how do I get started?”, you can check out Luca Greco’s detailed “Hacking Firefox OS” article. In this article, I’m going to cover some of the specifics of working with the Firefox OS Simulator, which Luca mentions in his article.

    The Firefox OS Simulator was introduced in a Hacks post last month as r2d2b2g, a prototype Firefox add-on that makes it really easy to install B2G on your Windows, Mac or Linux computer. B2G is undergoing heavy development, and the Firefox OS Simulator makes it easy to stay up-to-date (the 1.0 release will automatically update… for now, it’s a simple install that doesn’t require restarting Firefox).

    We’re angling for a “1.0” release of the Simulator soon. Our main goal with 1.0 is to make it easy to run B2G and install apps that you’re working on into it, and we’re a good way toward that goal right now. You can try out the Simulator right now by downloading it from Myk’s r2d2b2g page.

    The Simulator Manager

    To get going with the Simulator, you’re first going to open up the “Simulator Manager”. The Manager lets you control the Simulator and manages the apps that you have installed into it. Start up the Manager by selecting “Firefox OS Simulator” from the Web Developer menu, or using the firefoxos manager command from the Developer Toolbar’s command line.

    Here’s what the Simulator Manager looks like:

    On the left, you’ll find some navigation controls including a switch that lets you start and stop the Simulator. You can also start and stop the Simulator using the firefoxos start and firefoxos stop commands in the Developer Toolbar. The “Console” checkbox allows you to start up with an Error Console window so that you can spot errors that might arise while you’re working on your apps.

    Working with your apps

    In the screenshot above, you’ll see that I’ve already installed a couple of apps. You can add apps by providing a URL to a site (with autocompletion based on your open tabs) or, even better, a URL to a manifest (so that the app can have a proper icon and such). You’ll need a manifest file anyhow to submit to the Firefox Marketplace, so you might as well start out with that early on.

    You can also locate a manifest file on your local computer so that you can create a packaged app (no web server required!).

    In the screenshot above, you’ll see that I installed James Long’s Weather Me app straight from GitHub and Fred Wenzel’s Serpent game from a local clone of its git repository. I’ll note that I did have to tweak the manifest for Serpent a little bit, because it was set up to deploy to GitHub rather than from its local directory. Changing just a couple of fields was all it took and then it worked great!

    With those set up, I clicked the switch that says “Stopped” to fire up the Simulator. Then, I unlocked it with a swipe of the mouse, and swiped left on the home screen to get to my apps:

    As you can see, the Weather Me and Serpent apps are installed and ready for testing! One feature I’d like to point out is the home button at the bottom of the Simulator. You can press the “Home” key on your keyboard to do the same function, but it’s nice having an on-screen button to mimic the physical button a phone would have.

    While hacking away on these apps, if I make changes I just have to follow some simple rules to see my changes. Hosted apps follow the usual rules for website caching and for working with appcache (which you should!). You can update packaged apps just by clicking the Update button in the dashboard. The Simulator is updated, restarted and your app is brought into view right away.

    Once you’re done working with an app, you can remove it from the manager, which will also remove it from the Simulator (though you made need to restart your Simulator to see the icon disappear).

    The Firefox OS Simulator is the easiest way to try out Firefox OS apps today and to verify how they’ll look before submitting them to the Marketplace.

    How the Simulator works

    The Firefox OS Simulator is different from some mobile environment simulations in that it doesn’t create a virtual computer. Instead, it is actually B2G Desktop, a version of the Boot2Gecko project that is built for desktop operating systems. This allows the Simulator to run very quickly and with minimal startup time on your computer.

    Get it today!

    Though we’re still cleaning things up for a 1.0 release, you can install it today, give it a try, and let us know if you run into any problems.

  7. Progress report on cross-platform Open Web Apps

    Here in the Hacks blog we’ve written a lot about building apps for Firefox OS using HTML, JS, and CSS. We’re working to ensure that those same apps can also run on Android, Windows, Mac OS X, and Linux devices. If your app can adapt to those screen sizes, CPU’s, and device capabilities, then we’ve got a plan to ensure that your apps install, launch, quit, and uninstall as native apps on each of those platforms.

    I’ve created a short video that shows how Open Web Apps from Firefox OS will work on any platform where Gecko is available.

    Firefox OS is our benchmark platform for Open Web Apps. On Firefox OS, users can discover apps in the Firefox Marketplace and install them directly onto the phone’s home screen. As an example I’m using my app Shotclock, an open web app for computing sun angles for outdoor photographers. Let’s find out what happens when we install this app on other platforms.

    Android

    Android users discover apps in Firefox Marketplace using the Firefox for Android browser. Firefox Marketplace has approved Shotclock for Android, so we just click the install button as we did on Firefox OS. We will automatically repackage the Open Web App as a native Android app to give our users a native app experience for Open Web Apps.

    Because we installed it from an android APK, we can manage it from the recent app list and we find it in the app drawer like every other app.

    Windows

    Windows users discover apps in the Firefox Marketplace using desktop Firefox. Firefox Marketplace has approved Shotclock for Windows laptops too, so we just click the Marketplace install button. We will automatically repackage the open web app as a native Windows app.

    Here’s Shotclock running on Windows, just like a real app. Our repackaging will mean that users can launch their open web apps from the Windows Start menu and quit them from the File menu. Users will also uninstall them from the Programs control panel.

    Mac OS X

    Mac OS X users also discover apps in the Firefox Marketplace using desktop Firefox. We will automatically repackage the open web app as a native Mac OS X app. When the user clicks the install button, we install Shotclock in the Mac OS X Applications folder.

    From there, it launches and runs just like a real app. The native packaging means users can switch between open web apps by pressing Control-Tab, and quit them from the File menu. How much code did the app developer rewrite? Zero.

    Privileged Apps

    So far we’ve looked at unprivileged Apps. We will also support privileged apps on all these platforms. Here is Kitchen Sink, our app for testing the Firefox OS privileged APIs. What happens when we install it on Android?

    The experience of discovering and installing privileged apps will follow the Android convention of presenting a list of permissions to the user at install time. These permissions are copied from the open web app manifest. After the user completes the installation process, the App is ready to use, and is able to access the phone hardware.

    Linux Desktop

    The email application that comes with Firefox OS is basically a privileged App that uses the Socket API for networking. Marco Castelluccio, our open web apps intern, got it running on it on his Linux laptop.

    He copied over the app package from Gaia and made one tweak to the app manifest. So, if you like the apps that come with your firefox os phone and want to run them on your other devices, cross-platform open web apps can make that happen.

    iOS

    We’d love to support Open Web Apps on iOS devices, but iOS does not, at this time, include the option to install a Gecko-based web browser, which is currently needed to support Open Web Apps.

    Edit: We’re working with the Cordova community, both to allow Cordova apps to run unmodified on Firefox OS and to allow Open Web Apps packaged by Cordova to run on iOS. For more details see the Cordova Firefox OS project page and the Cordova Firefox OS GitHub repository.

    Timetable

    Desktop — You can install hosted, unprivileged apps on your desktops and laptops using Firefox 16 or newer. Privileged app support should land in Firefox Nightly in the next two months.

    Android — You can install apps using Mobile Firefox Aurora, but you won’t get a native app experience yet. The native app experience should land in Mobile Firefox Nightly in December.

  8. Firefox OS for developers – the platform HTML5 deserves

    Over the next few weeks we will publish a series of short videos here that explain what Firefox OS means for developers and how you can be part of the revolution it brings to the world.

    be-the-future

    In various conversations we’ve repeatedly heard from developers that they view Firefox OS as simply a third player in the mobile space next to Android and iOS. This is not exactly what we are trying to achieve. Firefox OS is unique in its approach as it doesn’t target the high-end markets already saturated by other platforms. Instead its goal is to replace feature phones in markets that have no access to high-end smartphones or aren’t even considered in closed application mechanisms like marketplaces. Furthermore we wanted to create the first truly open and web-standards based ecosystem and mobile operating system – nothing in Firefox OS is closed or alien to the Web.

    This is why we recorded this video series to explain in a short and simple fashion where you can go to get started as a developer for Firefox OS and how this means writing HTML5 without the limitations other platforms have in place for web-standards based applications.

    Today we start with a short video featuring Chris Heilmann (@codepo8) from Mozilla and Daniel Appelquist (@torgo) from Telefónica Digital/ W3C talking about the goals of Firefox OS. You can watch the video here.

    Resources mentioned in the video are:

    We hope you enjoy this and that it answers a few of the questions you had about Firefox OS. Watch this space for more videos in this series.

  9. 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?”

  10. Building A Paid App For Firefox OS

    At first glance the Firefox Marketplace for Firefox OS may look similar to the Apple Store or Google Play Store but there is a key difference: it does not lock you into Mozilla or lock you into your Firefox OS phone. It enables you to sell a web app that will run on any open web device by way of the receipt protocol. Non-Mozilla marketplaces can participate in selling apps on Firefox OS out of the box by implementing the receipt format and users won’t notice anything different when running a paid app from either store.

    When other devices support the receipt protocol then theoretically you could pay for an app once and run it everywhere. There is, of course, a chicken vs. egg problem here so Mozilla hopes to be the egg that helps prove out the decentralized receipt concept and iterate on the protocol. Mozilla invites other vendors to help us work on getting receipts right so that paid apps are as portable and “webby” as possible.

    For Developers

    It’s the responsibility of each paid app to validate its own receipt. If you’re a developer thinking about selling your app on Firefox OS, this post should give you a head start on implementing the receipt validation bits. This post may also be interesting for those who wish to build a compliant web runtime or a compliant marketplace.

    The navigator.mozApps JavaScript API exposes device receipts to your application. The simplest way to validate a receipt is to include a client side library like receiptverifier.js and use the hosted verification service URL found in the receipt. The receiptverifer docs go into detail but it’s as easy as calling this JavaScript code when your app starts up:

    mozmarket.receipts.Prompter({
      storeURL: "https://marketplace.firefox.com/app/your-app",
      supportHTML: '<a href="mailto:you@yourapp.com">email you@yourapp.com</a>',
      verify: true
    });

    That’s it! This is a high-level shortcut that also displays a prompt on the screen within your app if the receipt is missing or invalid. The docs for the verifier show how to do low-level validation.

    For a more complete example, you can check out the code to the Private Yacht app which we’ve been using in testing. This app shows you how to do client side checking with the receiptverifier.js library as well as server side checking via Node.js. We also have a Python library (and one specifically for Django) that you can use on a server to check receipts.

    How does it work? Each receipt is a mash up of JSON Web Tokens. One of the properties is a link to a hosted verification service that you can use to check the receipt. You also have the option of verifying receipts offline but this requires periodic key synchronization and some details like refund and reissue handling are not well supported yet for offline validation.

    By default, a receipt is only allowed to originate from one of the store URLs in the installs_allowed_from parameter in your app’s manifest. As a developer you’ll create explicit payout relationships with each marketplace and will thus want to limit who can claim to sell your app. This acts as a whitelist for who can provide receipts for your app. Due to the loose nature of client side JavaScript, you can get tighter control over this whitelist by validating receipts server side (that is, on your own app server).

    Paid apps for Firefox Marketplace aren’t fully live yet but they’re coming very soon. If you integrate a receipt checker into your app now, you’ll be ready when the submission flow supports payments.

    Fraud Protection

    Enabling any party on the web to sell apps is crucial to Mozilla’s vision of open web apps. However, making receipts decentralized while fully protecting app assets (without DRM) is challenging. There are currently attacks users can use in their clients, like a DNS proxy, to access paid apps but there is mitigation to this with CSP, CORS, and HSTS, just to name a few. The state of today’s paid iOS / Android apps is actually not much different. There is an open issue right now that will help make marketplace whitelists more effective and Mozilla expects to evolve the system further as more developers and more stores participate. Switching to a signed, packaged app may also offer another layer of asset protection but this was designed more to address permission issues.

    As always, if you run into issues please file bugs! If it’s an Apps platform bug select Core (component: DOM: Apps) or select Marketplace (component: Payments/Refunds).