"...packaged apps are written in HTML5, Javascript, and CSS. But packaged apps look and behave like native apps, and they have native-like capabilities that are much more powerful than those available to web apps." (from http://developer.chrome.com/apps/about_apps.html)
The additional capabilities primarily concern access to Chrome APIs and services - access that traditional web sites do not have, including acting as a network client for TCP/UDP connections, and accessing hardware devices You can charge for packaged apps as well.
The packaged app is available here on the chrome app store. Note that on my iMac, I have noticed some odd instability of Chrome itself, but clicking "Ignore" seemed to let it run without a problem. Feel free to let me know if you see the same issue as well. In fact, feel free to let me know if you don't see it happen.
 |
| A d3.js visualization running as a "packaged app" from the Chrome Store (available here) |
Why?
Why would you use this mechanism for what is essentially a web site? I am still mulling on this. Google touts that it allows apps to be less dependent on the network. I do know that for some of the visualizations I have done this year, it would have been nice to have a way for users to get all of the materials in one fell swoop, and then run it as needed. The update mechanism would handle any needed updates to the visualization. Another benefit may be the ability to ride on top of google's user-authentication/management that would be a hassle if you were managing it yourself on a website.
Nuances to Create the Packaged App
Ideally, you can just (basically) zip up a web site plus a few special text files and publish it in the chrome store. However, there were two main issues I encountered when trying to do this with d3.
The first issue concerned "violations" of the content security policy, which is a set of policies intended to prevent cross-site scripting issues. For packaged apps specifically, it looks like you can't configure the policy. The "violations" seemed to be related to some of the javascript used within the d3.js internals, getting triggered by the d3 asynchronous download calls. The workaround is to specify that the page in the packaged app run in a "sandbox". Unfortunately, this then (apparently) prevents the app from being able to use the standard asynchronous calls to load the data files. In this case, it meant that I needed to modify the data files so that instead of raw json or tab/comma-delimited format, the files were wrapped in a little javascript to create variables, which were used later in place of the data load. Note that after I did this, it could run in a non-sandboxed mode, but I went ahead and kept it sandboxed in case there were another execution path that would hit the same issue.
Publishing on the Chrome Store
It costs $5 to register on the chrome store so that you can upload apps. "Uploading the app" in this case meant creating a zip file of the directory, and uploading it through the chrome developer console.
Initial Experiences
It looks kind of cool to see the app run in a chrome-less window.
I've noticed a few times that it reported a (native) crash on an iMac when the downloaded app is run - one of the errors where Apple would like you send an error report, not google. Irritating, but apparently they can be ignored. I get the feeling that this is somewhat new technology, so there may be more things like this.
You have to specify the initial window size when the app is launched. In this case, I used 1280x800, since this was the size of the screenshot I needed to add for the chrome store in order to publish it.
Overall, this is an interesting concept. I am curious to see how it pans out.
No comments:
Post a Comment