Open jrmsklar opened 8 years ago
A temporary hack that you can use is to use .RemovePasscode
which doesn't have any added functionality at the moment. This will help your team on keep using this repo and not your own fork.
We have to handle this with own of your suggestions indeed for the next release.
@ziogaschr I'm hesitant to use the .RemovePasscode
case, as if the pod is updated later and that functionality is added in, I don't want unexpected behavior to occur off-the-bat (ie. without updating any code).
Do you have any idea when 2.0.0
will be released?
Nope.
And I am not sure who can decide this. It will be nice if we can form a group of maintainers and then have a call about it.
Currently I am contributing only with the things I find during implementing the framework to our App.
On 16 Jun 2016, at 00:00, Josh Sklar notifications@github.com<mailto:notifications@github.com> wrote:
@ziogaschrhttps://github.com/ziogaschr I'm hesitant to use the .RemovePasscode case, as if the pod is updated later and that functionality is added in, I don't want unexpected behavior to occur off-the-bat (ie. without updating any code).
Do you have any idea when 2.0.0 will be released?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/velikanov/SwiftPasscodeLock/pull/34#issuecomment-226318694, or mute the threadhttps://github.com/notifications/unsubscribe/AAw_jDZgOAEXKFzI2wlYo5_37StlJZkaks5qMGgLgaJpZM4I2oKK.
@ziogaschr are you looking for volunteers to help maintain the project? If so, drop me a note at jrmsklar@gmail.com. I'd love to help out!
I am suggesting this and I am willing myself to be a volunteer, but I can't take the lead as it is @yankodimitrov project. If @yankodimitrov agrees then we can decide which code from this fork can be merged in his master repo and we all continue our efforts there. On top of that we can set a milestone and the features for the next release
Our team would like the option to be able to cancel out of the
LockState.EnterPasscode
state.I thought of a couple different ways to do this:
isCancellableAction
onEnterPasswordState
totrue
isCancellableAction
onPasscodeLockStateType
settableLockState.EnterPasscode
to allow for that state with or without a cancellable action.While all options had their pros and cons, I felt that the most flexible way to do this was option (3). Keep in mind that this breaks backwards compatibility, so it may be a good idea to wait for the next major release to add this in, but of course, it's up to the owners of this repo.