Coding after work Podcast featured me talking about PWAs, Open Source and AI

Back in March, the coding after work podcast interviewed me at the Techdays in Finland.

Today they released the podcast

In about 45 minutes I cover Progressive Web Apps, Microsoft and Open Source and the rise of AI as a technology for us to care about. Hope you enjoy it as much as I did recording it. Thank you to Jimmy and Jessica Engstrom for having me!

View full post on Christian Heilmann

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

All things open talk: The ES6 Conundrum (slides/screencast/links)

I just delivered a talk on JavaScript and ES6 at All things Open in Raleigh, North Carolina.

This is just a quick post to give you all the content and links I talked about.

Here’s the slidedeck on Slideshare

And the screencast of the talk on YouTube

Links I mentioned:

View full post on Christian Heilmann

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

Build and Run Firefox OS on Sony Open Devices

A few years ago, Sony released their first port of Firefox OS, for the Xperia E. Since then, Sony has started the Open Devices initiative to bring support for AOSP (the Android Open Source Project) to many more of its smartphones. The porting work described in this post is based on this effort and brings Firefox OS to a dozen different Sony devices.

Sony tablet and phone

Build from the FXP Project

Builds of Firefox OS for a number of Sony devices are now available from the FXP project. Thanks to Adam Farden for his work on improving the default look and feel of unbranded Firefox OS builds, and hosting these images. These builds also have over-the-air updates, so you can stay up to date as Firefox OS continues to improve! They’re built from the nightly branch of Firefox OS though, so make sure to back up your information regularly.

FXP Project

Read on to create your own build of Firefox OS for a Sony Xperia device…

Building Firefox OS

Before you begin, a few warnings:

  • TIME! It will take overnight to download the source code. I am not joking! Expect it to take 10 hours or more to fetch the entire source tree. Firefox OS sits atop a number of other projects, including Linux, the Android Open Source Project, and many others. Building a smartphone image is not like building the Firefox browser, or even like compiling a custom kernel.
  • DATA! Flashing your device will destroy the existing operating system and may delete your user data. Always do a complete back-up of any information you want to keep.
  • BRICKS! Flashing a new operating system on a device always comes with the risk of rendering the device permanently unusable. It’s rare, but possible. Sony provides an official tool called Emma. It works with the S1 Bootloader flashmode so the chances of completely destroying a device are indeed very low and mostly everything can be saved by this tool. It is very simple to use and documentation is available. It’s running in Windows but we have been using it successfully in VirtualBox: don’t forget that the USB IDs for S1 Bootloader mode are different. So you need to force your device to be attached to the virtual machine.

Oh, you’re still here? Great, but don’t say we didn’t warn you. Read on to learn how to build Firefox OS for your Sony device!

Device Support

Firefox OS currently has support for the Shinano and Yukon Sony device platforms. This means that you can build for the Xperia Z2, Z3, Z3 Compact, Z3 Tablet Compact, as well as the E3, T2 Ultra. Support for the Xperia M2 should be available soon. You can see the full list of devices that are supported on Sony’s website. Note that your device to be flashed must be updated to Android Lollipop (5.1) prior to flashing.

Most features of Firefox OS are tested and you can expect these to work. This includes phone, SMS/MMS, and data connections, as well as device capabilities such as Wi-Fi, GPS, Bluetooth, and NFC.

The only major exception to this is the camera. The Sony team is porting the camera, and we’ll update this post when they’ve completed that work. The FM radio is also not yet supported. Areas where you might see variable support or some bugs are in audio/video decoding and processing, and hardware acceleration. Make sure to report a bug if you see a problem in these areas. Instructions for reporting issues are at the bottom of this post.

Getting Ready to Build

Mozilla’s developer site, MDN, has extensive documentation on building Firefox OS for devices. Currently the only supported operating systems for building Firefox OS are 64-bit Linux. Start by installing the prerequisites (things like Git and the Android SDK) and setting up your build environment. Follow the directions there and you’ll be just fine.

Clone, Configure, Build

Once you’ve the build environment taken care of, you’re ready to get the source code. Remember, this may take many many hours! The code comes from many different repositories, and can take 10 hours or more even over a fast internet connection. Make sure you have at least 20gb of free disk space available for the source code and the build files that you will be generating.

The next few steps look like this:
* Clone the root repository of the project, which downloads the build scripts. This takes about a minute over a decent connection.
* Configuring for your device, which downloads all the B2G and Gonk source code and some configuration files and libraries specific to your device. This can take 10 hours or more over a decent connection.
* Compiling into a device image which can be flashed to the device. This step should take about an hour on a decently powered desktop computer.

Start by cloning the B2G repository with the command below. This should only take a minute:

git clone git://

This will have created a B2G directory, which you can now enter:

cd B2G

Before you begin the next step, connect your device through USB, and confirm that you can see it connected by executing the following command:

adb devices

You should see something like:

List of devices attached 
YT910VTPWY    device

Next you’ll configure the build for your specific device, using its code name. You can find your device code name by executing the script with no arguments:


Once you’ve found it, you can now configure the build. Here’s the configure step for the Z3 Compact:

./ aries-l

The immediate next step is to go sleep. Or drive to visit your grandmother. Or see if you can run a marathon before the source code finishes downloading.

Okay! It’s the next day, and you’ve got all the source code. You’re now ready to build:


Now go watch half of a movie, or see how many push-ups you can do in an hour!

Flash Your Device

This is the moment you’ve been waiting for. Make sure your device is connected via USB and then execute the following command:


You should see the device go into bootloader mode and then various files being copied over and then written to it:

Terminal while flashing

After the flashing process is complete, your device will reboot into Firefox OS!

Boot screen

That looks great, how can I help?

There are several ways you can contribute and stay in touch. One of the most obvious is getting access to a device already supported, and using it and reporting bugs. Another step forward is hacking the device to help maintain it, making sure bug are fixed, and providing a smooth user experience. For those of you who are brave enough, you can help bring support for more Sony Xperia devices. The list of devices supported by the Open Devices project is bigger than those currently working with Firefox OS. For example, hacking to get the Z1/Z1 Compact series (Rhine platform) would be a good start.

Got questions about running Firefox OS on new hardware or devices? Try the dev-fxos mailing list or #fxos on IRC. Thanks!

View full post on Mozilla Hacks – the Web developer blog

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

Erase and Rewind – a talk about open web enthusiasm at Open Web Camp

I just flew from San Francisco to Seattle still suffering from the aftermath of the after party of Open Web Camp 7, a gathering of enthusiasts of the web that lasted for seven years and showed that you can teach, inspire and meet without having to pay a lot. The ticket prices were $10 and even those were mostly to avoid people getting tickets and not coming. All the money left over was then donated to a great cause. Thank you for everyone involved, especially John Foliot for seven years of following a dream and succeeding. And also for moving on whilst you are still happy with what you do.

My presentation at the event, “Erase and rewind – a tale of innovation and impatience” discussed the problems I found with advocating for the open web I encountered over the years. The problems we found, the gaps I see in our storytelling and the loss of focus we suffered when smartphones became a new form factor that seemed great for the web, but became its biggest problem very soon.

There’s a screencast of the presentation on YouTube

The slides are available on Slideshare

I got a bit into a rant, but I think there is a big problem that the people who advocate about great ideas of the web clash with those who want to innovate it. There are a lot of events going on right now that want to achieve the same goal, but keep violating the best practices of others. We need to rally to keep the web relevant and alive. Not define that what we do is the one true way.

View full post on Christian Heilmann

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

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

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

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

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

A channel for Open Web Apps

We have now just opened another feedback channel on UserVoice about Open Web Apps, available at

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

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

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

Contributing is very easy!

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

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

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

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

What do you want the web to be like?

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

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

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

View full post on Mozilla Hacks – the Web developer blog

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

PlayCanvas Goes Open Source

On March 22nd 2011, Mozilla released Firefox 4.0 which enabled WebGL by default. A month later, we formed PlayCanvas and started building a game engine unlike anything that had gone before. Fast forward three years, and WebGL is everywhere. Only this week, Apple announced support for WebGL in both OS X and iOS 8. So what better time pass on some more exciting news for you:

The PlayCanvas Engine has been open sourced!


Introducing the PlayCanvas Engine

The PlayCanvas Engine is a JavaScript library engineered specifically for building video games. It implements all of the major components that you need to write high quality games:

  • Graphics: model loading, per-pixel lighting, shadow mapping, post effects
  • Physics: rigid body simulation, ray casting, joints, trigger volumes, vehicles
  • Animation: keyframing, skeletal blending, skinning
  • Audio engine: 2D and 3D audio sources
  • Input devices: mouse, keyboard, touch and gamepad support
  • Entity-component system: high level game object management

We had a couple of goals in mind when we originally designed the engine.

  1. It had to be easy to work with.
  2. It had to be blazingly fast.

Simple Yet Powerful

As a developer, you want well documented and well architected APIs. But you also want to be able to understand what’s going on under the hood and to debug when things go wrong. For this, there’s no substitute for a carefully hand-crafted, unminified, open source codebase.

Additionally, you need great graphics, physics and audio engines. But the PlayCanvas Engine takes things a step further. It exposes a game framework that implements an entity-component system, allowing you to build the objects in your games as if they were made of Lego-like blocks of functionality. So what does this look like? Let’s check out a simple example on CodePen: a cannonball smashing a wall:


As you can see from the Pen’s JS panel, in just over 100 lines of code, you can create, light, simulate and view interesting 3D scenes. Try forking the CodePen and change some values for yourself.

Need For Speed

To ensure we get great performance, we’ve built PlayCanvas as a hybrid of hand-written JavaScript and machine generated asm.js. The most performance critical portion of the codebase is the physics engine. This is implemented as a thin, hand-written layer that wraps Ammo.js, the Emscripten-generated JavaScript port of the open source physics engine Bullet. If you haven’t heard of Bullet before, it powers amazing AAA games like Red Dead Redemption and GTAV. So thanks to Mozilla’s pioneering work on Emscripten and asm.js, all of this power is also exposed via the PlayCanvas engine. Ammo.js executes at approximately 1.5x native code speed in recent builds of Firefox so if you think that complex physics simulation is just not practical with JavaScript, think again.

But what about the non-asm.js parts of the codebase? Performance is clearly still super-important, especially for the graphics engine. The renderer is highly optimized to sort draw calls by material and eliminate redundant WebGL calls. It has also been carefully written to avoid making dynamic allocations to head off potential stalls due to garbage collection. So the code performs brilliantly but is also lightweight and human readable.

Powering Awesome Projects

The PlayCanvas Engine is already powering some great projects. By far and away, the biggest is the PlayCanvas web site: the world’s first cloud-hosted game development platform.

For years, we’ve been frustrated with the limitations of current generation game engines. So shortly after starting work on the PlayCanvas Engine, we began designing a new breed of game development environment that would be:

using any device with a web browser, plug in a URL and instantly access simple, intuitive yet powerful tools.
See what you teammates are working on in real-time or just sit back and watch a game as it’s built live before your eyes.
Making games is easier with the help of others. Be part of an online community of developers like you.

PlayCanvas ticks all of these boxes beautifully. But don’t take our word for it – head to and discover a better way to make games.

In fact, here’s a game we have built using these very tools. It’s called SWOOOP:


It’s a great demonstration of what you can achieve with HTML5 and WebGL today. The game runs great in both mobile and desktop browsers, and you are free to deploy your PlayCanvas games to app stores as well. For Google Play and the iOS App Store, there are wrapping technologies available that can generate a native app of your game. Examples of these are Ludei’s CocoonJS and the open source Ejecta project. For Firefox OS, the process is a breeze since the OS treats HTML5 apps as first class citizens. PlayCanvas games will run out of the box.


So if you think this is sounding tasty, where should you go to get started? The entire engine sourcebase is now live on GitHub:

Get cloning, starring and forking while it’s fresh!

Stay in the Loop

Lastly, I want to give you some useful links that should help you stay informed and find help whenever you need it.

We’re super excited to see what the open source community will do with the PlayCanvas Engine. So get creative and be sure to let us know about your projects.

Toodle pip!

View full post on Mozilla Hacks – the Web developer blog

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

Treat Open Source Like a Startup

What am I getting myself into?

I was never an open source contributor. I had never even filed a GitHub issue. I considered myself an entrepreneur who simply happened to be technical.

But when the startup I wanted to build needed something that didn’t exist, I followed an unprecedented whim and paused everything I was working on. I pulled a hard left, and I wound up spending three months working full-time on a project that I needed ASAP. Equally as motivating, I knew that other developers needed it too.

So, I switched hats. I became an insanely focused, sleeping-isn’t-allowed developer.

The outcome was an animation engine that drastically improved UI performance and workflow across all devices. See it at It’s a powerful JavaScript tool that rivals the performance of CSS transitions. The trick? Simple: In contrast to jQuery (which was initially released in 2006), I was building an engine that incorporated 2014’s performance best practices from the ground-up. No legacy layers; no bloat. Not a Swiss Army knife; a scalpel.

But, throughout my solitary confinement, I was genuinely concerned that I was building something for a customer base of one — myself.

I eventually came to realize that switching hats was actually the wrong approach. I was never supposed to take my startup hat off. (Since normal people don’t wear two hats at once, this is where my metaphor breaks down.)

This is the story of that realization.


Let’s momentarily jump ahead three months — to the time of Velocity’s release. Pardon me for a moment while I gloat:

  • Within three days, Velocity reached the top of Hacker News and programming subreddits a total of four times.
  • Within nine days, Velocity amassed 2400 GitHub stars.
  • Within two weeks, Velocity topped the CodePen charts with multiple demos reaching 10,000 views each (, and
  • Countless business, front-end platforms, and web agencies migrated to Velocity (examples:,,

How was this possible? Because I treated Velocity like I treated my businesses: First, there’s development. That’s 10%. Then, there’s marketing. That’s 90%.

The perspective shift I underwent midway through development was to commit to the following mantra: However much time I wound up spending on development, I would spend even more time on marketing.

After all, that was the time-split I experienced with my startups. I didn’t see a single reason why it should be different for this project. User acquisition is user acquisition.

Ultimately, if you develop a startup or an open source project intended for public use, and nobody uses it… you failed. It doesn’t matter how clever it was. It doesn’t matter what technical challenges you overcame.

Unfortunately, however, the peculiar reality of OSS growth hacking is that there’s a stigma attached to it: The act of marketing invokes pitching, rubbing shoulders, begging, and bribing. It’s stereotypically personified as an overeager, two-bit hustler wearing a cheap shirt and an even cheaper tie. This clashes with our ideals of open source — which itself is stereotypically personified as a headstrong and idealistic code warrior wearing a cheap shirt and an even cheaper haircut.

I’ll quote GitHub’s Zach Holman to get to the root of the dichotomy, “We like to think that open source is pure; that it’s unadulterated. That marketing an open source project is silly. That’s just silly.” –

To put it bluntly, if you want your open source project to have an impact, you need to step out of your coder bubble. After all, if you build something amazing — and you market it effectively — you’re doing everyone a favor. Not just yourself.

The best part is, the more people that know about your work, the more people there are to contribute: Bugs get discovered sooner. Useful features get pitched more often.

And don’t worry — being seen publicly marketing your project doesn’t frame you as an egotistical developer. It frames you as someone who’s passionate. If you take the time to appreciate the fact that more people benefiting from your hard work is a major motivation in your pursuit of open source, then you’ll realize that hustling on behalf of your project fits exactly within your pre-existing ideals.

Open source growth hacking

If you look closely at the current open source landscape, those who most often reach the top of GitHub’s charts are developer figureheads with pre-existing followings, and major companies sharing components of their internal stack.

Looking at this month’s GitHub’s trending chart, the top ranking projects that aren’t educational resources (link collections, tutorials, etc.) include: Pop (Facebook), Atom (GitHub), Quill (Salesforce), Velocity (Me!), Mail-in-a-Box (individual), Famous (Famous), syncthing (individual), betty (individual), Isomer (individual), Bootstrap (Twitter), Angular (Google), PourOver (NY Times).

There’s a fair representation of individuals in there, but it’s typically corporations that dominate open source marketing. The reality, however, is that these corporations employ developers that are no better than you or I. There’s no inherent natural selection driving the popularity of their projects versus yours

Fight to get your project out there. Or sit back and watch the marketing teams of huge companies drown your voice out.

Velocity.js CodePen Demo

That’s enough with waxing poetic and analyzing the current landscape. Let’s dive into the meaty details: How exactly did I market Velocity?

  • I pre-wrote advanced drafts for major web development blogs to consider publishing. By presenting the editors with the full goods upfront — not a pitch, not an outline — I minimized their workload, making it very easy for them to say “yes.” I also made sure to wait until I had enough GitHub stars (from Hacker News coverage, etc.) before pitching. And, most importantly, I had a strong thematic focus for each article: One article was exclusively about performance, and the other was exclusively about UI workflow. In both cases, I minimized the amount of attention spent pitching Velocity, and focused instead on educating readers about the respective topic. Blogs don’t want to publish a giant ad on your project’s behalf; they want content that their readers will thank them for.
  • I found out where my power-users were. This advice is common in the startup world: Find your core 1,000 early adopters. It’s no different with open source. Who were the users that craved for a performant animation engine — that would do amazing things with it then show off their exploits to the world without me prompting them to? Web animation demo-sceners — that’s who; the passionate, hard-core devs who explore the intersection of technology and design. And, where do they hang out? I reached out to the demoers whose work I greatly admired, and I gave them access to a pre-release version of Velocity. Sure enough, they eventually pumped out something amazing for me to share.
  • To ensure that new developers always stumble into Velocity.js — even far past the point that I’m still proactively marketing the project — I embedded Velocity into every popular web developer resource that I could find. I pull-requested and the popular GitHub repo for front end bookmarks. I pitched the Treehouse video blog guys. That was all just the start. I also have upcoming codecasts on Velocity’s workflow that code schools will be presenting to their students. Simply put, I made sure that every developer trying to master web animation would at some point hear about Velocity.
  • Most importantly, I wrote great documentation. To quote GitHub’s Zach Holman once again, “Documentation is marketing. The best part is that documentation is linkable. It’s indexable. It’s tweetable. Particularly if you have a nice, coherent one-page overview of your project that lets people jump in and immediately ‘get’ it.” To expand on Zach’s thoughts, I would frame an open source project’s documentation as what a landing page is to a startup. And make no mistake, you do have to pitch; you can’t merely document your API and call it a day. The developers reading your documentation are no different than anyone else; they have limited time, and they need to be convinced that your project is worth considering.

When you have great documentation, posting to Reddit and Hacker News will take care of itself. Developers recognize their peers’ hard work, and they’re happy to spread the word.

On this topic, do you know what the best-kept secret about open source marketing is? That it’s 100x times easier than startup marketing. It’s less work, and you’ll see success with a much greater degree of certainty. Why? Because developers — as compared to the average web user — are more willing to listen, are more willing to retweet, and are generally less skeptical of your marketing claims. Whereas most web users are tired of being pitched with trite social media products, developers are always on the hunt for better tools. Similarly, the web development press is much easier to get a response from than the mainstream tech news press is. The former is scrounging for good content to share with their users whereas the latter is drowning in a sea of half-backed startup pitches.

Because of the marketing efforts I put into Velocity, and because of the project’s ensuing success, I have become highly motivated to continue working on open source projects.

I am only just getting started: Velocity is the first in a trilogy of libraries that aim to change the way we visually interact with software. If you’re interested in staying on top of my UI exploits, say hello on Twitter: @Shapiro.

View full post on Mozilla Hacks – the Web developer blog

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

Open Web Apps – a talk at State of the Browser in London

state of the browser panel

On my birthday, 26th of April 2014, I was lucky enough to once again be part of the State of the Browser conference. I gave the closing talk. In it I tried to wrap up what has been said before and remind people about what apps are. I ended with an analysis of how web technologies as we have them now are good enough already or on the way there.

The slides are available on Slideshare:

The video recording of the talk features the amazing outfit I wore, as originally Daniel Appelquist said he’ll be the best dressed speaker at the event.

Open web apps – going beyond the desktop from London Web Standards on Vimeo.

In essence, I talked about apps meaning four things:

  • focused: fullscreen with a simple interface
  • mobile: works offline
  • contained: deleting the icon deletes the app
  • integrated: works with the OS and has hardware access
    responsive and fast: runs smooth, can be killed without taking down the rest of the OS

The resources I talked about are:

Make sure to also watch the other talks given at State of the Browser – there was some great information given for free. Thanks for having me, London Web Standards team!

View full post on Christian Heilmann

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

Introducing TranslationTester and localization support for Open Web Apps

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

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

Presenting TranslationTester

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

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

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

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

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

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

How to localize an app

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

Mark up the HTML

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

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

Create translations

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

Include l10n.js

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

Add “name” and “description” translations

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

How to view different locales

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

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

App Manager/Firefox OS
Language setting in the Settings app
Choose language under Preferences > Content > Languages. More information in Set content language in Firefox

Get help with translations

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

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

View full post on Mozilla Hacks – the Web developer blog

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

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!

View full post on Mozilla Hacks – the Web developer blog

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