-
Notifications
You must be signed in to change notification settings - Fork 391
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
Add Screen Lock Timeout #2335
Add Screen Lock Timeout #2335
Conversation
Generated by 🚫 Danger |
Tests results for SalesforceSDKGenerated by 🚫 Danger |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought we were going to remove timeout from the connected app interface instead? Are we sure we want to add this back, especially in a patch?
boolean hasLock = sharedPrefs.getBoolean(SCREEN_LOCK, false); | ||
int timeout = sharedPrefs.getInt(SCREEN_LOCK_TIMEOUT, 0); | ||
|
||
return hasLock && (elapsedTime > timeout); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this also be checking if lastLockedTimestamp != 0
?
unlock()
sets lastLockedTimestamp to 0 but that would mean that unlock would guarantee that elapsedTime > timeout
is true (unless someone set a timeout greater than 2022 years or something)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No. I explicitly want this to return true when lastLockedTimestamp
is 0 upon initial login. If the connected app tells us the user requires the lock they should have to demonstrate it once to finish the login process. lastLockedTimestamp
should be captured on background any other time except cold boot, which should start locked.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes sense to me, but I'm still unclear what the purpose of the unlock()
function is. It looks like it will lock the app instead of unlocking, is that correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unlock()
was a bad name for that method because it was only used to setup for the next shouldLock
call on unlock. I have updated the code path where this setup was needed and deprecated unlock
. Thanks for pointing this out.
No description provided.