-
Notifications
You must be signed in to change notification settings - Fork 309
Add a login flow #11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Splitting this issue in two: this one will track just the login flow itself, and I've added #34 for storing the resulting credentials on the device. To get a reasonable user experience we'll need both. But the login flow is a nontrivial enough UI, and starting to do on-device storage is a large enough infrastructural task, that I think I'll want to merge the one without blocking on the other. So this is the issue we'll close on merging the login flow, and then #34 is an important followup. |
There's plenty more to do to improve the UX of this, and I've filed several follow-up issues. Most critically, we'll need to store the resulting credentials on the device, so you don't have to repeat the login each time you start the app. But this is enough that it becomes possible to log in at an account of your choice, making the flow testable end to end. In particular this makes a useful bootstrapping step toward the task of storing data locally: with this, there's now some useful data we could store. Fixes: zulip#11
There's plenty more to do to improve the UX of this, and I've filed several follow-up issues. Most critically, we'll need to store the resulting credentials on the device, so you don't have to repeat the login each time you start the app. But this is enough that it becomes possible to log in at an account of your choice, making the flow testable end to end. In particular this makes a useful bootstrapping step toward the task of storing data locally: with this, there's now some useful data we could store. Fixes: zulip#11
As explained in the README, this prototype currently requires baking in a set of account credentials at build time.
By using an appropriate test account, that works fine for development and even for distributing a build among a handful of people. But it'd get unwieldy for distributing a build to more people, especially now (after #9) that the app's functionality isn't all read-only.
So we should add the ability for the user to log in in a normal way, and should then remember the resulting credentials in the app's storage.
The text was updated successfully, but these errors were encountered: