A few additions to this. Apologies in advance for this sounding negative, but I wanted to dump some of the non-obvious costs on the page.
> I'm a fan of this approach myself, partly for the quick development cycle and > because I'm bullish on us A/B testing our interface in the wild. +1. > But with FHR we ended up shuffling problems around. For example, building > mobile-friendly FHR jelly took about as long as building desktop-friendly FHR > jelly. There are UI issues -- we've had problems with font sizing, reflow > and zoom, event handling, AZPC scrolling inconsistencies, and misleading back > button handling on Android -- but my assertion is that these can be > satisfactorily addressed. Part of this is that it's hard enough to get a good user experience across the range of devices with a native Android UI, let alone from web content: four DPI levels; a range of screen sizes; tablet, phone, phablet; different themes for different combinations of device and OS (should your buttons be grey or white?). And there are interactions with the OS: you'll need to link to wifi settings, or help, or open Fennec's preferences, or show a notification, or perhaps require some control over task affinity, whatever. That's a challenge from content. The wrapper starts accruing bullshit messages like "am I running on a Motorola Honeycomb device?" I understand the temptation to say "oh, we'll just throw in some HTML"… and I'm not disputing the advantages. It's a great approach for the short term (and, as you say, to get some feedback -- on one handset model and one OS revision!). But to reach a good user experience across our supported devices requires much more iteration than one might expect, typically without any of the support that Android offers. It might well be cheaper, and result in a better experience, to "go native". >> So as I look at the UX mocks that we need to implement, I wonder why we >> wouldn't use the same approach here? Namely, the "setting up sync" window >> could be entirely implemented in HTML, and the only desktop client work >> would be to raise a container. > > This seems misleading to the point of obfuscation. The "only [desktop] > client work" will be to actually do the auth dance and create an Account and > all the other related setup. (On Android, there's a good deal of plumbing to > create and manage the Android Account: no jelly that is in any way /secure/ > is going to let us rev the interesting bits. It is technically possible to > allow the jelly to call Java directly via the JNI, but forget that I > mentioned it.) Have to second this. Really going through the motions of setting up state will involve fairly tight coupling to, off the top of my head: * The existing Android account system and shared preferences to achieve migration * Same again for new account creation * Picking data types, which will depend on the capabilities of the local device * A background service to show progress notifications for background first sync * Whatever local and remote data stores we use to track storage provisioning and capabilities * … We'll hit all of the same tight coupling problems that lead to the decision of shipping code in the same product from the same source repo. Putting in a username and password is really the iceberg tip of account creation. > If we have the jelly do the auth dance (and return some set of tokens to the > client?), then I think we're changing the TOFU + SRP security model of the > auth server pretty significantly. But I suppose such issues are well enough > understood from the Persona shim case that we'd be comfortable having served > jelly handle user passwords? I'm scared. > > Also, now we have a versioning problem on two axes. The client version and > the server version have to agree. So now all of our jelly-wrapper messages > need to be versioned. This also implies a backward compatibility cost. Plenty of the non-Google app stores are slow in updating Firefox, so things have to still work when a 2014-02-01 jelly page is requested from a 2013-09-01 wrapper. _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
