Publishing Flash Apps and Games to the Chrome Web Store

Any web app that runs inside of Chrome can be published to the Chrome Web Store, and this means Flash apps are more than welcome to the party. The Chrome Web Store, launching before the end of 2010, is a publishing, distribution, and monetization marketplace for web apps. We welcome great Flash apps and games to publish and sell via the store.

This post is a Quick Start guide for getting your Flash apps into the store in the quickest was possible. Give us 20 minutes and you'll have your Flash app in the Chrome Web Store.

(Don't have a Flash app, just have an HTML or HTML5 web app? We have a Quick Start Guide for Publishing HTML5 Web Apps into the Chrome Web Store as well.)

Assumptions

1. You have a Flash .swf file ready to go.
2. You have a Google account.
1. Don't have one?  Go get one, it doesn't even have to be a GMail account.
3. You have a credit card handy or you have a credit card added to your Google Checkout account.

Two ways to do this

Sorry, I know you want to get to the good stuff, but there's something we need to explain first.  There are two ways to distribute web apps with the Chrome Web Store: packaged apps and hosted apps.  Choosing an option is not always black and white, but we'll give you some things to think about and we'll run through both options.  You may want to read more about the differences between packaged and hosted web apps.

Packaged Web Apps

• A good option for developers that want nothing to do with web servers.
• Totally downloaded and installed onto user's browser.
• Can only be up to 10MB in size.
• Can access some Chrome extension APIs
• Natively run offline.
• Easier to sell as a one time purchase, no server component required.
• Doesn't support selling as a subscription.

Hosted Web Apps

• Served from a web server.
• Your only option if entire app is bigger than 10MB.
• Can run offline via the App Cache.
• Supports one time payments, as well as monthly and yearly subscriptions.

There's no better or worse way to do it, it's really dependent on your circumstances.  We'll show you the Quick Start guide for both methods so you can make the best choice.

Publishing a Packaged Flash Web App

To follow along, check out a fully working packaged Flash example code for the Chrome Web Store.  And remember, this only works if your app's total size, once zipped up, is less than 10MB.

• Take a screenshot of your app.  The system will resize to 400x275 for you.
• We'll use this in a moment.
• Create a directory on your system, call it my_app.
• Place your .swf file into my_app.
• Create a 128x128 icon, used for the launcher button and display in the store.
• Following the image guidelines for the Chrome Web Store.
• Place the 128x128 icon into my_app.
• Create a 16x16 icon, used for the favicon.
• Place it into my_app.
• Create a manifest.json file describing your app.
• Copy the following manifest.json and change the appropriate fields.
• Place manifest.json into my_app.

• Create an index.html file to host your .swf file.
• Copy the following index.html and change the link to the .swf file.
• Place index.html into my_app.

• Zip up my_app.
• Make sure manifest.json, index.html, your .swf file, and all other files are in the root of the zip, not nested in another directory inside of the zip file.
• Sign into the Chrome Developer Dashboard with your Google Account.
• If this is the first time you've published anything (extension or web app) you'll be asked to pay $5 registration fee.  Do this now using Google Checkout.
• Click the blue "Add new item" button.
• Upload my_app.zip.
• Fill in your app's details.
• Upload the 128x128 icon again.  This is a bug that might be fixed by now.
• Choose a category.
• Choose a language.
• Upload at least one screenshot (the one you took at the beginning of this process).
• Click Publish Changes.

Congrats!  You've now published a packaged Flash app to the Chrome Web Store!

Bonus Points

• Link a verified domain in the Edit Details screen.
• Write a great description in the Edit Details screen.
• Link a YouTube video showing game play or the app in action in the Edit Details screen.
• Upload more screenshots.
• swfobject really helps embed Flash into HTML.  It's much better than the default JavaScript that Flash generates for you.
• Sell your app via a one-time purchase.
• Requires a U.S. bank account configured with Google Checkout.

Publishing a Hosted Flash App

To follow along, check out the hosted Flash app example code for Chrome Web Store.

Many of the steps here are very very similar to the above instructions for packaged web apps, however the manifest file is different.  Follow the full Quick Start Guide for Hosted Web Apps for all the details and check the example code.  The example code uses Google App Engine but of course this is totally optional.

Example manifest.json for hosted web app:

You'll also want to configure the App Cache so that your Flash app runs even when the user is offline.  The example App Cache lists every file and resource required to run the app.



Summary

The Chrome Web Store provides a publishing, distribution, and monetization platform for Flash apps.  You can quickly package up your Flash app or host it on any web server and publish it to the store for users to find, pay for, install, and enjoy.

For more information, check out the Chrome Web Store docs, join the Chromium Apps discussion group, and follow the Chromium blog.  All the code for this blog post can be found at Flash Examples for Chrome Web Store.

Publishing your Web App to the Chrome Web Store Screencast

A quick screencast showing how easy it is to publishing your web app into the Chrome Web Store. You may also be interested in the Chrome Web Store Quick-start.

Ruby, OAuth, and Chrome Web Store

The Chrome Web Store, launching by the end of 2010, integrates a streamlined payment system, powered by Google Checkout. Your apps can opt-in to use this payment system for quick and easy payments. You can check if a user has paid for the application with a call to the Chrome Web Store License API.

The License API is a REST service which returns a simple JSON format, indicating if a user (identified by a Google Federated OpenID URL) can access your web app.

For Ruby developers, a new OAuth library, Signet, has recently been released which makes signing your OAuth request to the License API very easy.

The first step is to publish a paid web app to the Chrome Web Store. I've written a Quick Start Guide for the Chrome Web Store that will make this fast and easy. Once you configure your app as paid, either via a one time payment or a monthly or yearly subscription, you will be provided with an OAuth Token and Token Secret.

The second step is to install the Signet gem, as simple as gem install signet

Here is the sample code:



An example JSON response:



Our initial set of Chrome Web Store Best Practices should also help you get started.

Looking forward to your web app in the store!

Rails, Ruby, Rack, and Google OpenID via OmniAuth

A great new OpenID library for Ruby web apps (Rails, Sinatra, Rack, etc) has recently hit the scene.  The OmniAuth library supports a plethora of authentication systems, including Twitter, Facebook, Google Apps, and OpenID.  OmniAuth is Rack based, and it's easy to slip right into your web app.

While it does support OpenID, OmniAuth requires just a bit of manual configuration to support Google's OpenID endpoint.

You can use Google OpenID with OmniAuth and your Rails 3 web app:

For your Gemfile:

gem 'omniauth'

For your config/initializers/omniauth.rb:

Rails.application.config.middleware.use OmniAuth::Builder do
  provider :openid, nil, :name => 'google', :identifier => 'https://www.google.com/accounts/o8/id'
end

What's up with the nil? That tells the OpenID gem to use the memory store, which is the default. You can use any OpenID Store that you wish (complete list of OpenID stores).

Direct your users to /auth/google

For the rest of the options and workflow, consult the OmniAuth Wiki.

Thanks to OmniAuth for making it really easy to add third party authentication to your Ruby powered web app!

For those not using OmniAuth, I've written a full end to end tutorial on Rails and Google OpenID integration.

Proposal to enhance HTML5 App Cache for Better Performance

Disclaimer: this is a very initial idea, comments most welcome.

Background

The HTML5 Application Cache is a mechanism which allows a web app to operate offline.  A web app may create an App Cache manifest file which declares a set of static resources, such as images, stylesheets, scripts, etc.  These resources are then cached locally by the user agent (eg a browser) and are not updated nor retrieved from the web server until the App Cache manifest file itself is updated.  Learn more about the basics of the App Cache.  The App Cache allows for web apps to operate even when not connected to the internet, and web apps can start quicker as they can pull assets from local cache instead of the original web server.


An example App Cache manifest:

CACHE MANIFEST
index.html
stylesheet.css
images/logo.png
scripts/main.js

Problem


While the App Cache mechanism is generally helpful for the web and its users, there is still one scenario that is less than ideal.  When the App Cache manifest file is updated, the browser will then re-fetch each resource in the manifest.  Smart browsers will perform HTTP negotiations like checking the ETag (If-None-Matches) or the date of the resource (If-Modified-Since) in the hopes that the server merely has to reply with a 304 Not Modified instead of sending the whole resource over.


This is one of the main issues with the App Cache.  When the App Cache manifest is updated, the client has to now ask the web server if each and every resource listed in the manifest is newer on the server.  Even with responding with 304's, the client must initiate one Request/Response cycle for each asset.  This can be non-trivial in large applications.

Chrome Developer Tools tells me that, even over my pretty fast internet connection, my browser is spending 300ms to ask "is there a newer version of the resource" and for the browser to say "nope, 304, not modified".  If a modern web app has 20 assets, that's still six seconds for the browser to learn that nothing has changed on the server.

While this is pretty much the standard situation with web browsers and servers today, I would like to propose an addition to the App Cache which can really speed the web up.

Proposed Solution


Imagine if we could tell the browser everything it needed to know, in a single Request/Response, in order to make smart re-fetching decisions.  We would like to help the browser make its own local decisions on which assets to re-fetch, without having to ask the web server, over and over, if each asset has changed.


I propose that we add additional meta-data to the App Cache manifest which allows the browser to decide locally if it needs to re-fetch an asset.


Specifically, I propose we optionally allow a web app to specify the ETag and/or Last-Modified date for the resources in the App Cache manifest.  For example:

CACHE MANIFEST
index.html , ETag: W/fi32323cwnewf8 , Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
stylesheet.css , Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
images/logo.png , ETag: W/99vvj39jf30fj9340f
scripts/main.js

As you can see, each asset can also declare the ETag, Last-Modified, or both.  This gives the browser all the information it needs in order to determine if it needs to contact the server for a new version of the resource.

The only requirement for the ETag is that it must be quoted, so a server component can easily create a SHA1 hash or other identifier for the resource.  It's also trivial to get the last edited date for a resource.

The assumption here is that, while this data can be entered by hand, a small server component (such as Rack::Offline) may be used to easily generate the App Cache manifest.

Providing the ETag and the Last-Modified timestamp should give the client browser enough information to make a smart decision for which assets really and truly need re-fetching.

Summary

The App Cache, part of the HTML5 spec, is a mechanism to cache a set of resources locally, enabling offline web apps.  If the App Cache manifest is updated, the browser will then conditionally re-fetch each resource in the manifest, creating potentially wasteful network access and delay.

I propose to allow an App Cache manifest to additionally, and optionally, include the ETag and Last-Modified timestamps.  By including this meta-data, the browser is now able to make local decisions and only re-fetch assets that have definitely been updated.  This reduces network bandwidth, reduces latency, and decreases web app startup time and will make the web app feel faster.