mAuthTaskFactory

[larroy]

mAuthTaskFactory

[nhinds]

You're talking about the fix in b6d7da1 - I see that in your fork you removed the code which resets mAuthTaskFactory to null, and removed the null check in attemptLogin.

The null check was originally to prevent trying to perform 2 logins at the same time. That won't cause any issues at the moment, because since I added that null check the UI has been modified and I don't think it's possible to trigger attemptLogin while the app is trying to log into LastPass.

However, keeping this field non-null won't actually benefit you since nothing references it except the OTP code, and in b6d7da1 the null assignment is moved to the block that's only called if we're switching back to the login screen instead of the OTP screen. When a login is performed, a new UserLoginTaskFactory is always created anyway.

I don't think that creating the factory is particularly resource-heavy - the underlying library lastpass-java creates a few objects and reads the first few items from the cache (username, iterations and account version); it doesn't perform any calculations until the password store itself is requested (see UserLoginTaskFactory.loginWithOtp and UserLoginTaskFactory.loginWithoutOtp). Caching the UserLoginTaskFactory should not improve the time taken to decode the blob because the task factory itself doesn't cache anything in memory.

I'm closing this issue because I don't see that it's a problem - the current state works for me. You've also got so many changes in your fork (to remove maven and inline lots of .jars, ick) that I can't tell whether one of those was causing or fixing the issue. If you can consistently reproduce performance problems by only nulling out mAuthTaskFactory without making other changes, let me know and I'll reopen this to take a closer look, because that shouldn't be happening.