Skip to content
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

Merged
merged 6 commits into from
Aug 10, 2022

Conversation

brandonpage
Copy link
Contributor

No description provided.

@mobilesdk-bot
Copy link

1 Error
🚫 Please re-submit this PR to the dev branch, we may have already fixed your issue.

Generated by 🚫 Danger

@mobilesdk-bot
Copy link

1 Warning
⚠️ No Lint Results.

Tests results for SalesforceSDK

Generated by 🚫 Danger

Copy link
Contributor

@bhariharan bhariharan left a 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);
Copy link
Contributor

@npars npars Aug 8, 2022

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)

Copy link
Contributor Author

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.

Copy link
Contributor

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?

Copy link
Contributor Author

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.

@brandonpage brandonpage merged commit 3da964f into forcedotcom:master Aug 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants