Single Account - Acquire Token Overloads provide conflicting behaviour

In Single account mode, the overloads for acquiring a token are offering different behaviors.

For example acquireToken(activity, scopes, callback) throws a NO_CURRENT_ACCOUNT exception if they user hadn’t already signed in.

See this block: https://github.com/AzureAD/microsoft-authentication-library-for-android/blob/fba4df5e50aded2370c296e25f4665549d5a5706/msal/src/main/java/com/microsoft/identity/client/SingleAccountPublicClientApplication.java#L533-L537

However, acquireToken(AcquireTokenParameters) allows acquiring token even if the user had never signed in before.

See this block: https://github.com/AzureAD/microsoft-authentication-library-for-android/blob/dev/msal/src/main/java/com/microsoft/identity/client/SingleAccountPublicClientApplication.java#L561-L596

We need to make the behavior consistent across each overload.

[shahzaibj]

@rpdome If the app is indeed expected to call signIn first in single account mode, then I think we can just modify this method to throw the NO_CURRENT_ACCOUNT_FOUND error same as the other overload.

With that being said, I’ve been thinking if we should redesign the Public Api around single account mode so that calling sign in is not required at all. Do you have historical context on why this was done this way? Or more importantly why methods like signin were even needed in addition to the acquire token methods? We can also follow on this offline if that is better.

[joshfriend]

I use single account mode and just ran into this weirdness. Also strange was the fact that acquireToken(AcquireTokenParams) totally works in place of logIn() even when no account is currently logged in.

I was upgrading from v0.2.2 which didn’t have logIn() and didn’t see anything in the wiki about it changing from acquireToken() to logIn().

Now that I think about it, I’m honestly not sure when I would ever use acquireToken().