Confusing login screens for certain actions that require authentication

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Select power connected as root event
2. Select +Action > Gmail -> Screen appears asking for username & password
3. Proceed and select send mail -> The screen appears with field for username & 
password

What is the expected output? What do you see instead?
Two screens asking for user credentials in a single task is confusing. Only  
one of them should be used.

Original issue reported on code.google.com by renc...@gmail.com on 24 Jun 2010 at 4:10

[GoogleCodeExporter]

My proposal for this one is to remove the first login screen and slightly 
modify the fields for the second one in anticipation for issue 89 (Twitter 
mentioned that it will stop supporting username/password means of 
authentication through their web API in June 2010, but it still works 
yesterday).

The attached diagram also shows the basic flow for my proposed change. The acct 
in the diagram is a drop down list of accounts previously created by the user 
applicable to this app (gmail, twitter), the new button is basically a button 
for creating a new account and will display different type of activity 
depending on the authentication method.

I would be glad to hear any comments. Thanks!

Original comment by renc...@gmail.com on 24 Jun 2010 at 4:21

Attachments:

• proposal.jpg

[GoogleCodeExporter]

By the way, I was also thinking whether we should allow the users to have 
different accounts for different actions (currently, you can create 2 gmail 
send actions sending messages from 2 different accounts) or just have a single 
account for each application?

Original comment by renc...@gmail.com on 24 Jun 2010 at 6:26

[GoogleCodeExporter]

What if we store the account information and when the user goes to create a new 
gmail event, it gives you the option of choosing pre-configured accounts or 
using a new one?

Original comment by case.and...@gmail.com on 24 Jun 2010 at 9:04

[GoogleCodeExporter]

Sorry, I guess my post was a bit confusing. What I mean to ask is whether we 
should allow the behavior that allows users to have different accounts for 
different actions. I was asking because a normal user to me would use only a 
single account for sending emails or tweeting. If yes, I was thinking of 
replacing the username and password parameters with an account ID, which will 
be a foreign key to a new table UserAccount. The UserAccount would then have 
the following attributes: accountID, username, credential (the password or 
token), fk_appID (foreign key to RegisteredApp table).

Original comment by renc...@gmail.com on 25 Jun 2010 at 1:46

[GoogleCodeExporter]

One account per application sounds like a safe assumption for now, but long 
term we may want to provide a way for multiple.  For example the standard Email 
application supports multiple accounts, users may want to process each of those 
accounts individually.  I don't see a problem with your database schema though 
that would prevent this in the future.

I'm unfamiliar with how the twitter/gmail app store that username/password 
currently.  Is it with params/attributes?

Also, we should continue to consider and do further evaluation on Android-5's 
AccountManager to decide if we'll be duplicating a lot of that functionality 
and if we'd rather migrate to higher API version in the near future.  I'll post 
a message to the group about this.

Original comment by case.and...@gmail.com on 25 Jun 2010 at 4:42

[GoogleCodeExporter]

Actually, I have not yet fully understood how to use the AccountManager. It 
seems like you need to implement some of the abstract classes related to the 
AccountManager to make it work. I am still trying to figure out how these 
classes relate with each other (There's a sample project using AccountManager 
here - 
http://developer.android.com/resources/samples/SampleSyncAdapter/index.html).

Original comment by renc...@gmail.com on 25 Jun 2010 at 8:58

[GoogleCodeExporter]

Actually after looking through some of the source for that, it seems a bit more 
promising as a way to handle authentication since the we get to implement the 
AuthenticatorActivity 
(http://developer.android.com/resources/samples/SampleSyncAdapter/src/com/exampl
e/android/samplesync/authenticator/AuthenticatorActivity.html) we can probably 
integrate it pretty seemlessly.

Original comment by case.and...@gmail.com on 25 Jun 2010 at 10:25

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Code review:
http://codereview.appspot.com/1702048

Summary of changes:
1. Decided to stick with the proposal and removed the first login screen from 
the flow. The same login screen is then reused to ask for the user's credential 
when the user clicks the "setup account" button at the action parameter 
activity (please refer to screenshot.png).
2. Each application is limited to one user account. This means that whenever 
the user uses the "setup account", the user account in saved rules will also be 
changed to the new account. The account credentials are stored in the 
RegisteredApp table. The decision to store to that table was just a matter of 
convenience since there are existing infrastracture to read/write on it.
3. When a user installs this new upgrade and the had existing rules that uses 
gmail or twitter accounts, the most latest entry of these accounts will be 
retrieved and set as the current account.

Test Cases:
1. Checkt that migration works properly.
  1.a. Existing rules with gmail and twitter actions should have the user account set to the newest account and other parameters should be kept intact.
  1.b. Other rules not related to gmail and twitter actions should be kept intact.
  1.c. Check the sqlite database file for data integrity.
2. Check that user can setup accounts for Twitter and Gmail indepedently.
3. Check that gmail send and twitter actions can be created, viewed (from Save 
Rules), edited and executed.

Original comment by renc...@gmail.com on 28 Jun 2010 at 6:12

Attachments:

• screenshot.png

[GoogleCodeExporter]

checked-in on r782.

Original comment by renc...@gmail.com on 30 Jun 2010 at 1:56

[GoogleCodeExporter]

Original comment by renc...@gmail.com on 30 Jun 2010 at 1:56

• Changed state: Fixed