Mozilla

Apps Articles

Sort by:

View:

  1. Phones for Apps for Firefox OS

    Update: Today, Monday, May 13 at 11:00am PDT, we closed the submission form for the Phones for Apps program. Thanks so much to all of you for your interest and enthusiasm. Your response has been overwhelming! We’ve received thousands of applications, more than we’re equipped to review in a timely fashion.

    We’ve started reviewing your proposals, and in the next few weeks we plan to notify application builders and porters who’ve been selected. 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. Please keep working on your apps. We can’t wait to see them in Firefox Marketplace.

    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.

    Apply here.

  2. 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.

  3. Announcing Firefox OS App Workshops

    Madrid, Bogotá, Warsaw & Beyond


    blaze_your_fxosFirefox OS phones will be available to consumers in several countries this summer, and they will be looking for great apps to install from Firefox Marketplace. If you know how to build mobile app experiences with HTML5 and JavaScript, we’re looking for you—especially if you’d like to develop apps in Spanish, Polish or Portuguese! If you’re fast and focused, this is the time to take first-mover advantage.

    Our first three hands-on technical workshops for skilled web app developers take place in Madrid, Spain, on Saturday, April 20; in Bogotá, Colombia on Saturday, May 18; and in Warsaw, Poland on Saturday, June 1. We hope to announce more workshops in more locales later in the season.

    You must apply to attend: We’ll ask you to show us your JavaScript expertise and/or past experience building web apps and working with web APIs.

    Who Should Apply


    We’re looking for small teams or solo developers with solid ideas and strong web development skills. If you’ve already built a successful PhoneGap, Chrome, webOS, Blackberry WebWorks app, or other open web app for mobile or desktop, we’d love to work with you on migrating your existing app or building a new one. Mozilla engineers and tech evangelists will help participants complete an app or port an existing one to the Firefox OS phone and into the Firefox Marketplace.

    Please apply now if you’d like to attend any of these workshops. We’ll be reviewing applications as they come in, with a focus on our first locations. We’ll get back to you as soon as possible.

    Moz_Ldn

    What We’ll Offer

    • A great place to hack.
    • Hands-on help from Firefox OS developers.
    • Food, drink and demos. And t-shirts, of course.
    • More code, less talk.
    • Firefox OS Developer Preview phones, really!

    How to Prepare

    There’s more than one way to start building Firefox apps. Here are a few resources to get you started:

    Firefox OS Workshop application form.

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

  5. Mozilla at Mobile World Congress & WIPJam

    It’s getting close to the end of February, and Mozilla is once again gearing up for Mobile World Congress (MWC). Last year, we made a splash talking about HTML5 and Boot to Gecko, and this year we’re back and bigger than ever, with a booth in the AppPlanet hall where we will be doing a lot of demos of Firefox OS and HTML5 apps.

    Being at WIPJam

    We will also be back at (and helping to sponsor) WIPJam , the biggest developer event at MWC. Last year Christian Heilmann spoke about HTML5; this year we will be giving talks and workshops on HTML5 apps, Firefox OS, and showing off developer tools for Firefox Marketplace and app creation. WIPJam has gotten pretty big, with 3500 people registered to attend the one day event.

    Our WIPJam schedule

    Here’s a quick overview of what we will be doing & presenting at WIPJam on Thursday, 28 February:

    1. An expert table where we will be answering questions and giving demos of Firefox OS, Marketplace developer tools and more.
    2. Sponsoring a Hackathon category for apps using WebAPis or WebRTC.
    3. Christian Heilmann will be back at WIPJam, giving an UnPanel on “HTML5 beyond the hype” and leading several HTML Discussion Group sessions (he’s going to be busy!).
    4. Mozilla CTO Brendan Eich & Robert Nyman will be giving a 50-minute workshop: Why Open Web Apps & Firefox OS are good for mobile developers.
    5. There also will be 4 DemoCamp presentations by developers we met at the FirefoxOS App Days in January. We’re excited that Untappd, Jaxogram, Reditr, & WordPress Photos will be at WIPJam showing off what HTML5 really can do.

    We’ll be posting updates on Twitter during the show, and a recap of the event here once we all get some sleep afterwards. Also stay tuned for some exciting announcements, starting with a press conference on Sunday and continuing throughout the event.

    Going to MWC?

    Going to MWC? Register for WIPJam and come visit us!

    Here’s the Full WIPJam agenda.

  6. Firefox OS App Days: It’s a Wrap!

    Over the last few weeks, Mozilla sponsored a worldwide series of hack days for developers to learn about creating apps for Firefox OS. Dubbed “Firefox OS App Days,” the events took place in more than 25 locales around the world, starting on 19 January in Mountain View, California and ending on 2 February in Berlin, Germany. The events were organized with the support of our Mozilla Reps, the Mozilla community and Firefox OS partners Telefonica and Deutsche Telekom in Africa, Asia, Europe, New Zealand, as well as North and South America.

    Hacking

    Hacking at a Firefox OS App Day

    2,500 New Developers for Firefox OS

    Our goals were to educate developers around the world about Firefox OS and open web apps and inspire them to start building apps for the Firefox Marketplace.

    We engaged with over 2,500 developers worldwide. Hundreds of apps were demonstrated at the events, and many of them have already been submitted to the Marketplace. Some of the apps developed include:

    • Bessa – An image editor for Firefox OS, demonstrated in Berlin
    • Web Sliding Puzzle – a sliding puzzle game made from the Firefox OS App Days logo, demonstrated in Paris by Mathieu Pillard
    • Ash’s Rising – a strategy game, demonstrated in Toronto
    • Travel Saver – a local travel app, demonstrated in Warsaw
    • FoxKehCalc – a Fox-themed calculator, demonstrated in Tokyo

    In addition to apps, we saw over two million impressions of the #firefoxosappdays hashtag on Twitter, and hundreds of photos from the events were posted on Flickr, Facebook and other social media sites.

    Sample of Apps Developed at Firefox OS App Days

    Sample of Apps Developed at Firefox OS App Days

    Going Forward

    Thanks to everyone who participated in the App Days, and if you haven’t submitted your app to the Marketplace yet, please do so as soon as you can. If you have a website or github repo hosting your app or a post about your App Day experience, please add your links to the comments below. We’d love to hear from you and check out your apps in progress. If you missed the events, or there wasn’t one in your area, stay tuned — our Mozilla Reps team plans to enable more in the near future.

    And if you are just hearing about Firefox OS, and want to get started developing apps on your own, the Developer Hub, the Hacks Blog and the Mozilla Developer Network are excellent places to start. To stay in touch with upcoming App Days, developer phone releases, and app development news, subscribe to our monthly Firefox Apps & Hacks newsletter.

  7. Getting started with Open Web Apps – why and how

    We’ve been talking a lot about Open Web Apps, Firefox OS and more here lately, and I wanted to cover both how to get started, and, maybe more importantly, why.

    Why a web app?

    If we look at the climate for mobile development, it has usually come down to a choice where developers had to pick their platform and skill. Maybe do iOS and Objective-C, or Android and Java.

    The big challenge here, of course, is that if you want to deliver your content on several platforms, you’ve had a few choices:

    • Pick one platform, and ignore the others
    • Learn a number of programming languages
    • Have separate development teams for each platform

    For major organizations, having multiple teams has been something they could do, while many other have struggled with that. And naturally, many mobile apps are in addition to a company/service web site, just adding more and more on top of the things that need to be maintained, supported and developed.

    Therefore, for reasons like saving costs, simplicity of one development language and more, many developers have jumped on the options like PhoneGap, Titanium and more, thus developing with HTML5 and JavaScript, and then packaging it for various mobile operating systems.

    This has been a good and interesting approach, but probably far from optimal in most cases. We at Mozilla want you to be able to use your existing skills as a web developer, but instead of having you jump through hoops to make it work, we want the platforms to evolve and give you more possibilities and power.

    This is accomplished by giving you as a developer access to a large amount of WebAPIs, Web Activities and more, to make the web layer as powerful a platform as it deserves to be.

    The idea with Open Web Apps is not to make you choose a new platform or, worse, excluding others – on the contrary, it’s about giving you means to reuse your existing code and, if desired, make small additions to make it installable as an app.

    Should I build an app?

    While many other platforms have a strong interest in getting you tied into their platform, delivering to their app store etc, I would rather say that the first question you need to ask yourself is:

    Do I really need to make an app out of this?

    In some cases, yes, definitely! But in other cases, you need to be professional and come to the conclusion that it is probably not likely to add any extra value – a few use cases where you don’t need to do an app have been outlined in articles like No, I’m not going to download your bullshit app and Packaged HTML5 Apps: Are we emulating failure?.

    I don’t want to trick you into making an app just for the sake of it, or that you’ll do it just because others do. I would rather see you make a fair assessment, and if your app idea has something additional to offer to the end user and overall user experience, then you should consider doing an app.

    So, what could those cases be? A few of them might be:

    • You want to offer a richer experience than you could offer from a web page, e.g. accessing some WebAPIs specific to the platform/device
    • You need to store a lot of information in localStorage or IndexedDB
    • The user wants to have a real installation
    • The user wants a nice icon on their home screen/desktop for easier accessibility

    Types of Open Web Apps

    There are basically two types of Open Web Apps you can install:

    • Hosted apps
    • Packaged apps

    Hosted apps

    Hosted apps are apps running from a URL, but in an app context. This means that you need to be online to run it, and all resources (e.g. files, images etc) will reside on your server and where you will host it.

    One option to avoid the need for connectivity is make sure your app works offline. This is done by adding an appcache file with listings of assets to be made available offline, and then refer to it from your main page:

    HTML file

    <html manifest="manifest.appcache">

    Appcache file

    CACHE MANIFEST
    # Version 1.0
     
    index.html
    css/base.css
    js/base.js
    js/webapp.js
    js/offline.js
     
    NETWORK:
    *
     
    FALLBACK:
    / fallback.html

    For learning more about offline support and caveats, I strongly recommend looking into these resources:

    Pros

    • You completely control the update process
    • Just run/reuse currently existing code

    Cons

    • Requires connectivity (if offline support isn’t implemented)
    • Doesn’t have as much access to APIs as a packaged app

    Packaged apps

    Packaged apps are where you put all your assets in a ZIP file, and then offer that as a complete package to be installed. This makes these files available at all times, and it also gives you elevated privileges – i.e. you can access more APIs – since all the code can be security cleared before install.

    Pros

    • Available offline by default
    • More API access

    Cons

    • More difficult to maintain
    • Update process for getting new versions out

    At the end of the day, you need to evaluate your needs, workflow, APIs you need to work with and more to make a good decision whether you want to do a hosted or a packaged app.

    Getting started with Open Web Apps

    After all that talk, what do you actually need to build an Open Web App? Not much, as it turns out. We’ve documented it on MDN in Getting started with making apps but I’d like to give you a quick run-down here as well.

    image

    Basically, all you need to do is take an existing web site/service you have and add a manifest file. Voilà, that’s it! Yes, really. And to get it installed, of course.

    The manifest file

    A manifest file describes your app, with things like name, icons, developer and such, but also localization support, path to launch, permission request for certain APIs and more. All manifest fields are available in App manifest on MDN.

    A simple manifest could look like this:

    {
        "version": "1",
        "name": "Firefox OS Boilerplate App",
        "launch_path": "/Firefox-OS-Boilerplate-App/index.html",
        "description": "Boilerplate Firefox OS app with example use cases to get started",
        "icons": {
            "16": "/Firefox-OS-Boilerplate-App/images/logo16.png",
            "32": "/Firefox-OS-Boilerplate-App/images/logo32.png",
            "48": "/Firefox-OS-Boilerplate-App/images/logo48.png",
            "64": "/Firefox-OS-Boilerplate-App/images/logo64.png",
            "128": "/Firefox-OS-Boilerplate-App/images/logo128.png"
        },
        "developer": {
            "name": "Robert Nyman",
            "url": "http://robertnyman.com"
        },
        "installs_allowed_from": ["*"],
        "default_locale": "en"
    }

    Save this file with a .webapp extension, for instance, manifest.webapp. One very important thing to note here is that this file needs to be served with the Content-type: application/x-web-app-manifest+json.

    This is something you need to set up on your server, e.g. through an .htaccess file in Apache:

    AddType application/x-web-app-manifest+json .webapp

    Once you have your manifest, make sure to validate your app to see that it has the correct format.

    image

    Installing the app

    Now that your manifest is in order and served with the right Content-type, let’s offer a way to install it. In your web page, you can add an install button that calls this code:

    var installApp = navigator.mozApps.install(manifestURL);
     
    // Successful install
    installApp.onsuccess = function(data) {
        console.log("Success, app installed!");
    };
     
    // Install failed
    installApp.onerror = function() {
        console.log("Install failed\n\n:" + installApp.error.name);
    };

    Make sure that the URL to the manifest is absolute – a simple way to do this is to extract the URL from the current page with the install button, and to have the manifest file in the same location:

    var manifestURL = location.href.substring(0, location.href.lastIndexOf("/")) + "/manifest.webapp";

    Optionally, you can also provide a second parameter to the install method, receipts, which is a JSON object. More on that in the documentation for the install method.

    Installing a packaged app

    The above solution, with a manifest file and an install call, works well with hosted apps. With Packaged apps, you need to go through some extra steps:

    ZIP all app content

    Make sure to ZIP all the files (not the containing folder), including the regular manifest file. The manifest file has to be named manifest.webapp

    Create a mini manifest

    Create another manifest file, for instance named package.webapp, and make sure the package_path is absolute to where the ZIP file is located.

    Also, developer name and info has to match between mini manifest and the regular one in the ZIP file.

    {
        "name": "Firefox OS Boilerplate App",
        "package_path" : "http://localhost/Firefox-OS-Boilerplate-App/Firefox-OS-Boilerplate-App.zip",
        "version": "1",
        "developer": {
            "name": "Robert Nyman",
            "url": "http://robertnyman.com"
        }
    }

    Installing a package

    Instead of using the regular install method, you now call the installPackage method, which points to the mini manifest, which in turn points to the ZIP file/package:

    var manifestURL = location.href.substring(0, location.href.lastIndexOf("/")) + "/package.webapp";
    var installApp = navigator.mozApps.installPackage(manifestURL);

    Turning on Developer Mode

    For this to work in the Firefox OS Simulator, you need to turn on the Developer Mode:

    Settings > Device Information > More Information > 
    Developer > Developer mode
    

    Note: this is a work in progress, and the availability of this option might vary, and not be available in your version of the Simulator or an actual Firefox OS device.

    All the releases and pre-releases of the Firefox OS Simulator are available on Mozilla’s FTP.

    Specifying permissions

    If you plan on using some APIs that only Packaged apps have access to, you need to add a couple of things to your regular (manifest.webapp) file:

    • Add type property (e.g. “type” : “privileged”)
    • Specify permission access
    "permissions": {
        "contacts": {
            "description": "Required for autocompletion in the share screen",
            "access": "readcreate"
        },
        "alarms": {
            "description": "Required to schedule notifications"
        }
    }

    There is also an interesting option, in the form of packaged-app-server, which offers zipping the files as a package when they get requested at run time.

    $ cd ~/myapp
    $ python ~/serve_packaged_apps.py

    An example app

    As an example app – if you want to check out something easy to dissect, tweak and get started with – feel free to test the Firefox OS Boilerplate App. It supports:

    • An install button, offering you to install it as a hosted app
    • Web Activities – lots of examples and use cases
    • WebAPIs in action
    • Offline support (disabled by default)
    • Packaged apps – install your app as a ZIP file

    image

    Which platforms are supported?

    Let’s look at where we are right now with Open Web Apps. They are supported in:

    Firefox OS

    You can install an Open Web App in Firefox OS (the Simulator or on a device) and most WebAPIs and Web Activities will work.

    image

    Firefox on Android

    In Firefox on Android you can install an app, and have it installed on your home screen with the correct icon. However, it doesn’t support the WebAPIs and Web Activities.

    image

    Nightly/Aurora versions on Desktop

    You can install and run a stand-alone app in Firefox Nightly/Firefox Aurora, but it doesn’t have access to many WebAPIs and no Web Activities.

    image

    The initial strong focus at the moment is support on mobile, but the hope and goal is that Open Web Apps will work on all platforms and devices, by adding support to needed APIs and more.

    Marketplace

    When it comes to Open Web Apps, you can use or install them from anywhere. Completely up to you.However, if you are interested in being listed, hosted and much more, I recommend taking a look at the Firefox Marketplace.

    image

    You can also visit the Developer Hub for a lot more information about app development.

    image

    Conclusion

    Open Web Apps aren’t here to change your developing ways – they are here to give you the option to install your existing web solutions as apps, access device-specific APIs and more.

    Don’t reinvent the wheel – just make it a bit more powerful!

  8. Writing Web Apps Quickly With Mortar

    With the introduction of Firefox OS, development of an open apps marketplace, and a push to implement powerful web APIs for closer hardware integration, Mozilla is serious about web apps. We believe that the web can deliver an experience similar to native apps, even on mobile.

    We can’t forget about the most important piece, however: a good developer ecosystem. We need to provide various tools to make it easy for both beginners and experts to write web apps and deploy them.

    This is why we’ve created mortar, a collection of app templates that provide starting points for different kinds of apps and tools to manage and deploy them.

    A few weeks ago, Pierre Richard wrote a post here about his experiences getting started writing apps for Firefox OS. There’s some good stuff in his post, including his critiques of mortar. He felt mortar was too complex and introduced a different starting point for writing web apps for Firefox OS.

    This post will loosely respond to some of his points, introduce mortar, and explain why I think it is a valuable starting point for writing web apps for both beginners and experts. A detailed walkthrough of mortar is provided at the end in a screencast.

    Why Are Templates Useful?

    Mortar is more than just a bunch of HTML, CSS, and JavaScript. As described later in this post, it comes with various other tools for automating tasks, such as deployment and minifying and concatenating JavaScript and CSS. These tools are necessary when you want to release your app and maintain it.

    If you’re someone who really enjoys simplicity, you might initially find mortar too complex. I’m definitely someone who wants to boil things down to its simplest form, rejecting unnecessary complexity. We’ve worked hard to make sure that we only include things in mortar that prove to be very useful when building and deploying a web app.

    So I encourage you to learn about the tools mortar comes with, especially if you think you don’t need it. Mortar is our expression of good web development practices, so it’s also a chance to learn about modern tools and good ways to build web apps. Just as Django or Ruby on Rails may seem complex at first, you pay off your initial investment later on.

    The Technology Within Mortar

    Mortar templates are pre-built to help you write web apps quickly. These aren’t specifically Firefox OS apps. We want you to build web apps that can run anywhere the web is. Firefox OS is a good place for a web app, but the mortar templates aren’t specifically targeting Firefox OS (even if some of the more advanced templates borrow a few styles from it).

    All of the mortar templates come with the following:

    • A project structure (folders for css, js, etc)
    • Some initial well-formed HTML, JavaScript, and files like manifest.webapp
    • require.js to manage javascript
    • volo for a development server, css/js optimizations, deployment, and other tasks
    • Some initial js libs: zepto, mozilla’s receipt verifier library, and a cross-platform library to install web apps

    In addition, an installation button is provided (but commented out by default) in case you want to test your app as an installed app (or let users install it outside of an app store). All you have to do is uncomment one line of HTML. This, in combination with the pre-built manifest.webapp file, makes it easy to build an app.

    Here’s what your app looks like when you start it from a template:

    Mortar-app-stub repo on Github

    All of the static files, like HTML, CSS, and JavaScript, are under the www directory. We live one level up from this so that we can use tools like volo and grunt, and if you need to add a server-side component it’s easier. The node_modules and tools directories are only for volo, and you can ignore them.

    We chose to use require.js, a JavaScript module system, because it’s good practice to write JavaScript in modules. It’s not an obscure library; it implements the Asynchronous Module Definition standard for writing modules which is extremely well-known in the javascript community. The module you should start writing JavaScript in is at www/js/app.js.

    Besides managing your Javacript dependencies, modules let us easily compress and concatenate all your JavaScript into one minified file, with zero extra work on your part. In fact, it’s so easy that it’s wrapped up in a volo command for you. Just type volo build in your project and all your JavaScript is concatenated into one file and minified (it also does this with your CSS).

    Volo is a tool much like grunt which simply automates tasks at the command line. We use volo because it integrates nicely with require.js. An example command is volo serve, which fires up a development server for your app. View this documentation for more volo commands available.

    Volo lets you easily deploy your site to github. After customizing www/manifest.webapp for your app, simply do:

    1. volo build
    2. volo ghdeploy

    Your optimized app is now running live on github, and is ready to submit to the marketplace!

    Games and Layouts

    Everything described above is applicable to all apps, but we also want to help people who want to write specific kinds of apps. This is why we’ve created multiple templates, each catering to a specific need:

    • mortar-app-stub: a minimal template that only has a little pre-built HTML (a blank canvas for any type of app)
    • mortar-game-stub: a minimal template that comes with some basic game components
    • mortar-list-detail: a template like app-stub but also includes a layouts library and a basic list-detail type interface
    • mortar-tab-view: a template like list-detail but the default interface is a tabbed view

    We have a blank canvas (app-stub), a game template (game-stub), and two other templates that come with pre-built layouts.

    This is what the game template looks like. It looks pretty boring, but it’s rendered using requestAnimationFrame and you can control the box with the arrow keys or WASD. In the future, we might include image loading and basic collision detection.

    mortar-game-stub template

    The list-detail template is below. It comes with a pre-built layout that implements a list-detail interaction where you can touch a list item and drill down into the details. You can also add new items. This data-driven functionality is powered by backbone.js. We are still improving the design. (The tab-view template looks similar to the list-view shown here.)

    List detail in Mortar (screenshot)

    The layouts library is mortar-layouts, and it’s something we came up with to make it really easy to build application UIs. To me, this might be the most exciting part of mortar. I won’t go into too much detail here, but it uses x-tags and other new HTML5/CSS3 features to bring a native-feeling application UI to the web. View documentation and a live demo (and the source for the demo).

    The layouts library and the two templates that come with layouts are in beta, so keep in mind there are minor bugs. The biggest problem is the lack of design, and we will be working on integrating better styles that reflect Firefox OS (but are easily customizable with CSS!).

    Future Work for Mortar

    Mortar is relatively new, and it needs time to be fully documented and fleshed out. We are working on this actively.

    We are also fine-tuning our templates to figure out what the best starting points are for each one. Admittedly, having the big blue install button be the default screen for the app-stub was a mistake, which has been fixed. Now you get a short helpful message with links of what else you can do.

    Most of the work we have left is with the list-detail and tab-view templates, and figuring out how to deliver useful layouts to developers. We don’t want to force a big framework on them, but feel strongly that we need to help them develop application UIs.

    We love feedback, so feel free to file an issue to get a conversation started!

    Screencast

    I made a screencast which walks through mortar in detail and shows you how to use require.js, volo, and other things that it comes with. Watch this if you are interested in more details!

  9. Join Us for Firefox OS App Days

    Firefox OS App DaysIf you’re a developer interested in web technologies, I’d like to invite you to participate in Firefox OS App Days, a worldwide set of 20+ hack days organized by Mozilla to help you get started developing apps for Firefox OS.

    At each App Day event, you’ll have the opportunity to learn, hack and celebrate Firefox OS, Mozilla’s open source operating system for the mobile web. Technologists and developers from Mozilla will present tools and technology built to extend and support the Web platform, including mobile Web APIs to access device hardware features such as the accelerometer. We’ll also show you how to use the browser-based Firefox OS Simulator to view and test mobile apps on the desktop.

    Firefox OS App Days are a chance to kick start creation of apps for the Firefox Marketplace, and represent a great opportunity to build new apps or optimize existing HTML5 apps for Firefox OS, as well as demo your projects to an audience of peers, tech leaders and innovators.

    We’re exciting to be working with our Mozilla Reps, who are helping organize these events, and with our partners Deutsche Telecom and Telefónica, who are supporting a number of them across the world.

    We look forward to seeing you there!

    Event Details

    The agenda for these all-day events will be customized for each locale and venue, but a typical schedule might include:

    • 08:30 – 09:30 Registration. Light breakfast.
    • 09:30 – 11:30 Firefox OS, Firefox Marketplace & Mozilla Apps Ecosystem.
    • 11:30 – 12:00 Video. Q&A.
    • 12:00 – 13:00 Lunch
    • 13:00 – 17:00 App hacking.
    • 17:30 – 19:00 Demos & party.

    Signing Up

    Firefox OS App Days launch on 19 January and continue through 2 February, with the majority of the events taking place on 26 January. This wiki page has a master list of all the events and their registration forms, from Sao Paulo to Warsaw to Nairobi to Wellington — and many more. Find the App Day nearest you and register. (N.B. Venue capacities vary, but most are limited to 100 attendees so don’t delay.)

    Getting Ready

    Plan on bringing your Linux, Mac or Windows development machine and an idea for an app you’d like to develop for the Firefox Marketplace. If you have an Android device, bring it along, too. You can see the Firefox Marketplace in action on the Aurora version of Firefox for Android.

    If you want to get started before the event, review the material below and bring an HTML5 app that you’ve begun and want to continue, get feedback on or recruit co-developers for.

  10. Weekly HTML5 Apps Developer Resources, December 19th 2012

    Weekly Resources for HTML5 Apps Developers

    Articles

    Resources

    Bonus Link

    If you find a link that you think should be included, please feel free to forward it to JStagner at Mozilla.com