Create application manifest

[fbender]

Similar to #5, you can provide an application manifest that allows the Web App to be converted into a standalone application. This works for Firefox atm, though Chrome has a very similar format.

http://www.w3.org/TR/runtime/ http://w3c.github.io/manifest/ https://developer.mozilla.org/en-US/Apps/Quickstart/Build/For_Web_developers https://developer.mozilla.org/en-US/Apps/Developing/Manifest https://developer.mozilla.org/en-US/Apps/Developing/About_app_manifests https://developer.mozilla.org/en-US/Apps/FAQs/About_apps

(When publishing in the Firefox Marketplace you can define the target device type, i.e. desktop.)

[artursapek]

Yep, doing this for Firefox and Chrome are very high on my list.

Thanks for the resources. If you wanted to, putting together the one for Firefox would be a tremendous help.

[fbender]

Here's a basic version (based on the MDN doc, the spec seems to defer a bit):

{
  "name": "Mondrian",
  "description": "Mondrian is a free vector graphics web app like Adobe Illustrator or Inkscape, available at mondrian.io.",
  "launch_path": "/",
  "appcache_path": "/cache.manifest",
  "icons": {
    "128": "/img/icon-128.png"
  },
  "developer": {
    "name": "Artur Sapek",
    "url": "http://artur.co/"
  },
  "default_locale": "en"
}

Apart from a review, this still needs a square icon (possibly in different sizes though 128x128 is required by the Firefox Marketplace) and updates to the path values (e.g. appcache). You could add support for Web Activities ("share" etc.), a CSP (recommended!), localized values, and a version info.

Beware:

The manifest should be stored with a file extension of .webapp. App manifests must be served with a Content-Type header of application/x-web-app-manifest+json. […] must be in UTF-8 encoding […] If you serve your manifest file from GitHub Pages, GitHub will serve it with the Content-Type header of application/x-web-app-manifest+json. You must use the .webapp file extension on your manifest file. Example: manifest.webapp.

[artursapek]

I like this. Mozilla seems to have set this up well. Getting this done for both Mozilla and Chrome are the next things I'll do.

Only thing I'm confused about is how I access my apps after I've installed them?! I'm just using FF on my Mac, so the experience may be better on a Firefox OS device like a tablet. But for example, I installed this app and nothing came up to show me how to launch it. I don't see any way to access it within Firefox, except revisiting that marketplace page and clicking Launch where the Install button used to be. Am I missing something?

Chrome's app screen is a much better experience (it was even made a mandatory part of the bookmarks bar recently).

[fbender]

Check out your /Applications/ folder! (Though Gatekeeper will block you from executing the Web App. You have to right-click -> open the appliaction once from the Finder to bypass Gatekeeper. I just filed Bug 964062 about that.)

[artursapek]

Ah! That's non-obvious, but pretty cool now that I understand. Mozilla needs to be clearer about that.

I'm working on adding a simple .webapp manifest now to see how this works.

[fbender]

Yeah, it lacks some polish. Actually, the Marketplace should have mentioned where you can launch the app from. Though Firefox itself should indicate that upon successfull installation …

[artursapek]

Yeah, it silently installs it and does nothing. It's weird. Anyway, I'm working on making the app offline-friendly with a cache manifest. I'll update you when I have something working in Mozilla's marketplace.

[artursapek]

Submitted to the Mozilla marketplace! They claim it will be reviewed within one work day. I've also taken full advantage of the HTML5 application cache so Mondrian can now be accessed offline in a regular browser (after you cache all the assets once).

The caveat there is now every time the app is deployed, the latest commit SHA in this line of code must change to invalidate the cache, or returning users won't see the effects of the deploy.

Chrome store is next. I'll get to that sometime this week. Thanks for getting this started. Exciting to have this be in an official app store.

[artursapek]

We are in the Mozilla marketplace! https://marketplace.firefox.com/app/mondrian/

I installed it and it seems to work pretty well.

Best part is you can go truly fullscreen with it on Mac. In fact there's an option to have the app launch in fullscreen, I'm thinking of turning that on.

And I noticed two bugs:

• The + and - hotkeys don't work (for zoom in and zoom out).
• The app doesn't launch when I'm offline even though there's an appcache and everything. (This might be Mozilla's fault because I think I support it correctly).

[fbender]

The app manifest validator shows no issues (apart from missing 32px and 256px icons).

The + and - hotkeys don't work (for zoom in and zoom out).

Can you file a bug on that at bugzilla.mozilla.org? Maybe it's a platform bug – unless you are sure it's your fault ;). Can you point me to the code?

The app doesn't launch when I'm offline even though there's an appcache and everything. (This might be Mozilla's fault because I think I support it correctly).

File a bug as well, please. If you don't want to setup an account (it's pretty easy though using the BrowserID / Persona service), I can do that for you, though I may need more details first.

[Fishrock123]

37 Relates to this.

@fbender ~~The keys are registered here. The listener is here. The zoom method called is this. (It feels like I'm missing something..)~~ Yep, I was. Seems like those are duplicates, I'll look into removing them.

[Fishrock123]

@fbender Nope, I was indeed missing something. It's defined in the menu and a little contrived right now. Here's where the actual zoom is called. It uses the standard zoom method, found here.

[artursapek]

They're not duplicates, @Fishrock123. I call @refreshAfterZoom() on key-up because it's an expensive operation that only has to happen once after several sequential zoom level changes, so if you hold down the plus sign and it fires multiple times this happens:

zoomIn()
zoomIn()
zoomIn()
refreshAfterZoom()

as opposed to this which would be slower:

zoomIn()
refreshAfterZoom()
zoomIn()
refreshAfterZoom()
zoomIn()
refreshAfterZoom()

Perhaps it's worth writing a comment explaining this.

[artursapek]

It's hard to test things on Mozilla's platform because there's no dev tools available within their little standalone environment (that I'm aware of). I know there's a Firefox OS simulator. I'll try to investigate in there. I'll assume it's my fault until I can prove that it's theirs, but right now I can't imagine why those hotkeys would be the only ones that don't work.

[Fishrock123]

(This is off-topic here, but oh well.) @artursapek Then these are duplicates?

[Fishrock123]

Did you guys check if the zoom tool worked in the Mozilla app environment?

[artursapek]

Ah, yes. I think you're right. I'd remove the ones in hotkeys.coffee and keep those.

[fbender]

Yeah, it silently installs it and does nothing. It's weird. Anyway, I'm working on making the app offline-friendly with a cache manifest. I'll update you when I have something working in Mozilla's marketplace.

So the Nightly (Fx 29) and Aurora (Fx 28) builds seem to work perfectly here: There is

1. an info in the Marketplace,
2. a progress report during installation (doorhanger notification at the identity icon),
3. a (Notification Center) notification when installation is complete.
4. Apps launch as any other signend app (no Gatekeeper notification preventing me from launching the app), so UX is almost exactly like in the App Store.

Beta (Fx 27) has 1-3 but not 4.

It's hard to test things on Mozilla's platform because there's no dev tools available within their little standalone environment (that I'm aware of).

Bug 966667

This leaves:

The app doesn't launch when I'm offline even though there's an appcache and everything. (This might be Mozilla's fault because I think I support it correctly).

I cannot find a bug for that. Did you try with the most recent Nightly?

Also, your appcache manifest seems to be sent with the wrong Internet Media Type:

~ $ wget http://mondrian.io/app/mondrian.appcache
--2014-02-01 22:17:42--  http://mondrian.io/app/mondrian.appcache
Resolving mondrian.io... 66.228.45.178
Connecting to mondrian.io|66.228.45.178|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1907 (1.9K) [application/octet-stream]
Saving to: ‘mondrian.appcache’

100%[======================================================================================>] 1,907       --.-K/s   in 0s      

2014-02-01 22:17:43 (65.0 MB/s) - ‘mondrian.appcache’ saved [1907/1907]

… while it should have text/cache-manifest. That could be the reason the manifest is ignored.

[fbender]

(The original issue is fixed now. Thanks a lot!)

[jokeyrhyme]

5 is closed with instructions to discuss this further here. Yet #13 is now closed too.

Can we open one of these to continue tracking the progress of the Chrome Web App? I'm assuming that is still a work in progress as there is not yet a Mondrian presence at https://chrome.google.com/webstore

[artursapek]

@fbender I fixed the nginx config.

M ∆ wget http://mondrian.io/app/mondrian.appcache
--2014-02-02 20:04:48--  http://mondrian.io/app/mondrian.appcache
Resolving mondrian.io... 66.228.45.178
Connecting to mondrian.io|66.228.45.178|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2114 (2.1K) [text/manifest]
Saving to: 'mondrian.appcache'

100%[====================================================================================================================================================================================================>] 2,114       --.-K/s   in 0.004s

2014-02-02 20:04:48 (572 KB/s) - 'mondrian.appcache' saved [2114/2114]

However this appcache thing is more of a pain in the ass than I expected. I've found a quirk in its behavior that may be a deal-breaker - I'm going to stop using it unless there's a way to fix that.

If we keep it, we also need to do something so that the appcache doesn't get served when developing locally, while keeping it a static site; I don't want to move to a dynamic server of any kind for performance reasons.

Not very happy with how the appcache API works, as far as I understand it.

And @jokeyrhyme, I'm working on getting it in the Chrome app store now. If I don't get it in tonight I'll open an issue to track progress.

[fbender]

You can disable appcache (iirc) in the site preferences → permissions tab in Firefox (at least for development). Application cache is a douchebag (please also read the sites linked in that article!) if you're not using it cleverly, either way it's all we have at the moment. Please use the API to your advantage (see the spec as well).

(BTW: The ALA article makes use of localStorage which has its own performance implications. Consider using localForage instead.)

Length: 2114 (2.1K) [text/manifest]

It's supposed to be text/cache-manifest!

[Fishrock123]

... I'm going to make this thing generate itself for each new build. That way we can untrack it and fire-at-will.

(I'm assuming that git stuff is stored in .git on windows too...)

[Fishrock123]

Ok, I have it so that it generates itself, but if we keep with SHA's that doesn't work for between-commit-test-builds.

I propose a move to build revision as a number, with a separate comment for the SHA. (or even keep the revision and add a line with # Build <number>)

[artursapek]

If it just has to be unique, md5 the current timestamp or something. You don't even necessarily need the SHA.

[Fishrock123]

I would be in favor of having it by build number then, though with comments for the sha and build date, for our own reference.

[artursapek]

Sounds okay to me. Only other thing we need here is the ability to update the file paths of the appcache to all forks through git. Looking at your work so far it seems like you're planning to just untrack the file, right? We still need some source it gets created from that is tracked. I see three options.

1. Embed the content into the Cakefile in the form of a multi-line string and write the .appcache file using that content every time cake build runs
2. Same as above, but embed it into a separate .coffee file that gets require()d by Cakefile
3. Have another .appcache file that never gets served (template.appcache or something) , and essentially cp template.appcache mondrian.appcache every time cake build runs

My vote goes for number 3, it seems cleanest and I dislike embedding long multi-line strings inside files - it's hard to read and edit.

Then after whichever of these we choose, we run the code you have for writing the build revision number and SHA. So the template content probably shouldn't contain either of these - they should be prepended to the head of the .appcache file by cake build.

The goal here is to make it so every contributor can keep their appcache file in sync with master. We need some origin of the file tracked in git because its content will change.

[artursapek]

It's supposed to be text/cache-manifest!

@fbender updated nginx config. Thanks.

Length: 2114 (2.1K) [text/cache-manifest]

[Fishrock123]

I went away from untracking it because we'd need to know what the previous build number was.

Essentially, as it stands, this primarily fixes #37.

[artursapek]

Just keep track of the build number locally. It's only required on a per-server basis, not across all forks. We should still untrack the file.