Feature: allow changing backgroundLockLatency

[jakobleck]

Small feature suggestion: Allow to change the backgroundLockLatency during runtime.

Possible usecase for that: You're using a zero-latency app lock, but want to use a file picker, which puts the app in background. On return from the file picker the user should not have to enter a pin, unless maybe after a certain timeout, which would require changing backgroundLockLatency before and after using the file picker.

A relatively minor change to app_lock.dart, and I've added a possibility to test it in the example app.

[tomalabaster]

Thanks for this! Will review (at some point) with the aim of merging it in 👍

[Bptmn]

Hello,

Is this feature planned to be in prod?
It would be really interesting to enable the user to choose the backgroundLockLatency on its app settings.
Thanks for you work !

[tomalabaster]

Thanks @Bptmn! Out of curiosity, this call to change the background lock latency, you'd also need to pass it through when instantiating AppLock anyway, as changing the background lock latency in this manner at runtime won't persist across app launches 🤔

Which also makes me think that the enabled constructor arg is named incorrectly and should actually be initiallyEnabled (Navigator does similar with initialRoute as an example).

So with that I also wonder if being able to control background latency is something that should be done by a descendant of AppLock 🤔 I'm thinking while it might have been convenient I don't think it's the right approach...

[Bptmn]

Thanks for your answer @tomalabaster.

I am not an expert in Flutter so my following thoughts should be treated cautiously.

To enable or disable AppLock, the method "AppLock.of(context)!.enable()" works while being in runtime, so it does have an effect to the AppLock constructor, right?
It would be great to be able to perform the same kind of change, but for the backgroundLockLatency value.

For example, the value of the backgroundLockLatency would be a persisted app state with a default value. Given the app state is initialized first, the backgroundLockLatency will have a value at launch, and if the value of the appstate is changed at runtime, it will persist across app launches.
But the challenge is to be able to change the value at runtime without error, and that it has an effect on the AppLock constructor.

What I already tried:

• setting the backgroundLockLatency value according to a persisted app state -> it works
• changing the appstate value at runtime -> it well persists for the next launch (closing the app and relaunching it), but does have effect at runtime for the current session. ChatGPT advises me to add a changeNotifier for the app state and to wrap the AppLock with a builder that can listen to this change notifier, but I am not at ease with that, I did not succeed.

Do you think it would be possible?

[jakobleck]

So with that I also wonder if being able to control background latency is something that should be done by a descendant of AppLock 🤔 I'm thinking while it might have been convenient I don't think it's the right approach...

Could you elaborate? If enabling and disabling is possible, so - and in the same way - should be editing the latency, I think. I.e. for both settings we need both a constructor parameter of AppLock and the ability for a descendant to edit via AppLock.of(context)..... If you do not think this is the right approach, then what would be?
Editing those properties at runtime should be possible. Given the way mobile applications work, we cannot expect the user to restart the application for such a setting to become active.

Prefixing the constructor parameter with an "initial" is possible, but probably not necessary.

And the issue of persistence shouldn't be part of this discussion. You (as an app developer) would use a storage solution (isar, shared_preferences, whatever you like) for that and pass the value to AppLock. Storing the value should not be part of the flutter_app_lock package, I think.