Only save pause timestamp if app is unlocked

[CharltonSantana]

Hello,

I have identified and addressed an issue related to the didChangeAppLifecycleState behavior when interacting with Face ID. During the 'unlockWithBiometrics' , didChangeAppLifecycleState receives an inactive/paused state. This led to the unintended triggering of the lockout duration check immediately after the Face ID authentication was completed.

There seems to be an inconsistnty in how often didChangeAppLifecycleState recieves this state.

The problematic sequence was as follows:

1. The lock screen was displayed.
2. The Face ID popup opened, and the app's state was marked as 'inactive' while waiting for Face ID authentication.
3. Upon successful Face ID authentication and app reactivation, the didChangeAppLifecycleState received the resume even and 'paused timestamp' is then checked against the current time.
4. Due to the passing of the lock duration check, the lock screen was shown again.

This behavior was not isolated to our app but was also observed in your example application.

To rectify this issue, I have modified the behavior to consider the app's lock status before storing the 'paused timestamp'. It is unnecessary to execute the lock duration check if the app is already in a locked state when it goes inactive.

I'm currently uncertain about how best to retreive the current lock status so i have made a slight change to lock_controller.dart. Happy to change this ofcourse.

Your feedback on this approach and its integration into the existing codebase would be greatly appreciated. Thank you for your attention to this matter.

Best regards,
Charlton Santana

[CharltonSantana]

Adding _repository.clearLastPausedTimestamp(); to unlockWithBiometrics after a successful authentication (authenticator_impl.dart) may also solve this. Yet to do some testing on that.

[Bassiuz]

Hi Charlton, thanks for your suggestion and pull request!

I need to do some testing with this; will come back to it later. A quick question I have while observing the code; why don't you just get the .last value from the stream instead of separately saving a lock state to check in the controller?

[CharltonSantana]

Hi @Bassiuz

.last is returning a Future. At first I thought I could just await this, but it only seemingly only retreives the event when a new one is emmitted. https://api.flutter.dev/flutter/dart-async/Stream/last.html - This is due to the LockState being a BroadcastStream, it does not remember past events.

Apologies if I am misunderstanding how to get the last value from this Stream - I'm relativity new to using Flutter.

[Bassiuz]

Hi @CharltonSantana , you're right, I was making some quick assumptions on a friday afternoon (my bad :) ).

I think I like the approach as the controller itself is small enough. I was thinking about maybe a listener setup instead but that would make the controller too convoluted.

The only remark I have is that I think the if statement doesn't compile like this right?

Instead of

if (_lastState != AppLifecycleState.paused) {
            _lockController.lockState is Unlocked) {

it should be something like this

 if (_lastState != AppLifecycleState.paused && _lockController.lockState is Unlocked) {

right?

[CharltonSantana]

Hi @Bassiuz

Yes this should be an AND. I have commited a fix for the AND statement, I messed up when doing the first commit - my bad.

Yeah I've mulled it over and I too think having if on the controller itself is the best place for storing the last value.

[CharltonSantana]

Hi @Bassiuz, Any update re if this PR will be merged?