When in doubt, lets do what we know how to do. We know how to write
native UIs. We have used that a 1000 times before. We have one example
of using a Web-hosted UI, but its not really similar at all. Engineering
is finding simple solutions for complex problems, not fancy solutions
for simple problems. Lets not be fancy today.
Andreas
Chris Karlof wrote:
On Aug 11, 2013, at 4:35 PM, Richard Newman <[email protected]
<mailto:[email protected]>> wrote:
You asked the desktop team, but I assume we'd use this for Android
too. I am a little concerned about the flow since Android actually
has a "Sync & Accounts" area in the OS Settings. The creation and
login would likely happen without any involvement with Firefox. I
think we need to investigate what it would take to get Firefox
involved in the flow, if possible. If it's tricky, we'd need to
fallback to use a native UI, like we do now.
Embedding a GeckoView (or a WebView, which Harald Kirschner spent
some time trying to figure out last time 'round) during account
creation should be feasible. We have some control over that activity.
Some of the other account processes might be more challenging.
Doing so for everything else that lives in settings — checkboxes,
status, etc. — very much goes against the OS grain. And if we'd be
touching settings and events from elsewhere — turning on a feature
from Fennec prefs UI, from a notification, etc. — then we'd need to
make sure that all of that stuff had a pure-Java interface, had
canonical state in SharedPreferences, etc. etc.
I think that the general thrust of this conversation has been
"credentials into a webview, token out, never touch the webview for
anything else", so these complexities likely won't come up, but I
figured I'd draw a line there.
I'm not sure what the right decision is for Android, but I would leave
open the possibility of using native Android UI/components for auth.
My general POV is that you should not fight too hard against how the
platform wants you to do things. Firefox Desktop and FxOS love the
web. WebViews on Android are not first class citizens compared to
native Android components [1]. Lessons learned from other projects
that have built Android and iOS apps using WebViews suggest that it's
important to pepper in native components when the UI needs to be
highly responsive (in the "fast" sense of responsive). "Log in to
device" is one case where I think we need to be highly responsive.
That said, there may be room for the web implementation on Fx Android.
"Password reset" may be infrequent enough compared to "sign in" or
"sign up" that it's acceptable to do it in a WebView. I also think we
should consider baking in an error path that triggers the web login
flow, but we don't necessarily use it in v1. In the future, we may
offer something like two-factor authentication and it would be nice if
we had a flow for 2FA users to log in on legacy Android installs [2].
And yeah, to echo previous opinions: web content implementation would
only be for auth. The sync storage will be baked in, so the settings
and preferences for sync should be baked in on all platforms.
-chris
[1] I'm not familiar with GeckoViews, but maybe they're a better
alternative to this problem for us.
[2] Or possibly the primary way 2FA users log in. FWIW, this is how
Chrome for Android does it: native UI for mainline, falls back to web
when 2FA is enabled.
_______________________________________________
Sync-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/sync-dev
_______________________________________________
Sync-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/sync-dev
