Conditional value change

[eddiesTime]

Firstly, thank you for the package! It has been a great help at the beginning of our project.

In a later phase of our project, we've stumbled upon a missing feature conditional changing of the widget's value. To be more precise, we use a SwitchSettingsTile to manage in-app permissions including the initial request for these permissions.
After a user hits the switch we ask him for his permission for the feature and based on the result of the request we want to adjust the widget's value. Currently, when the user denies the permission, the SwitchSettingsTile's value still changes from false (initial value) to true even though the user declines these permissions.

As a suggested solution, we have added an optional value parameter to some widgets where conditional value changes could become handy. This way we can handle the state from within the parent widget.

We are unsure if the suggested solution fits your intentions for the package and the coding style you've used. We'd appreciate it if you would take the time to review the PR and if desired propose a solution that is ok with you.

[GAM3RG33K]

I am glad you liked this library. One of my main focus was in providing a simple approach to creating settings screen without losing focus on what to add for setting instead of how to add it.

Regarding this pull request, I am glad you found a way to add the confirmation in between value change events.
However, This is one of the features I am planning to include in All the possible widgets, not just switch or checkbox.

I might be using a different approach to it, but the end goal is same more or less. I'll try to include your contribution to it as much as possible.
However the approach you provided seems to be very specific to a use-case, which can be improved to meet a general use-case.

I am really glad you liked & helped improving this library. I am hoping to see more contributions from developers like you in future.

[GAM3RG33K]

https://github.com/GAM3RG33K/flutter_settings_screens/tree/feature_confirm_on_change

You can give your input in this branch for the same feature. I have made this branch very quickly so that I can get your feedback on this, if you find anything to improve on let me know.

I know there's much to improve in this feature which I will do eventually, but with your help it might get done quickly.

[eddiesTime]

Hey,
sorry that it took me so long to answer.

I've looked into the branch and changes you proposed. I think we have different ideas about the problem in mind. Even though the additional dialog adds a conditional value by adding a dialog the user has to manually accept/deny, you don't want to use a dialog after the user either accepted/denied the OS dialog.
Unfortunately, this does not work as a solution to the original problem. Let me try to describe it once more using the switch as an example:

The current switch always switches from true to false and from false to true when the switch is tapped. Additionally, a callback can be assigned to run additional logic using the value that the switch returns.
When assigning a key to the switch and finishing the proper configurations, the switch's value on app start is assigned from the shared preference implementation.

We ran into our problem by setting the shared preferences key's value to false when the switch's callback proposes true (the initial state of the switch is false and we tap on it). What we expected to happen is that after the tap on the switch the switch's value would stay on false, since we assigned the value false to the storage key. To our surprise, the value of the switch changed from false to true. After we restart the app at this point, the switch's value is false as intended.

Now I'll describe the behavior/feature we are looking for:
After we tap on the switch we want to run some logic that can propose a value for the switch that should be used instead of the value the switch wants to assign. For example, the switch wants to change from false -> true but we want it to change from false -> false. Our proposed value can either be true (the switch value should change value) or it can be false (the switch's value stays false).

To support this behavior, I can think of three solutions:

1. either add the widget's value to the public API as an optional value
2. add an optional parameter to the onChanged callback that internally uses the other value, e.g. instead of setting the switch to true, it sets it to false.
3. instead of toggling from true -> false it always checks the storage's value and prefers the storage's value

I've got some time to spare in mid-February and will give it a go

[GAM3RG33K]

That's totally different than what I though this would be. Thanks for explaning but just to be sure the End goal for your condition is to always prefer the given value for some widgets, right?

Can you give me a small working example with some explanation in this use case?
A simple gist or dart pad link would also work.

I just want to understand the complete use case before moving forward or else I might end up adding some random feature again. 😛

[maltemedocs]

Thanks for explaning but just to be sure the End goal for your condition is to always prefer the given value for some widgets, right?

Right! So that if something got triggered in the onChange that basically says "No, don't change the setting to true", depending on how the user reacts, the setting does not change. A possible API for that could be:

SwitchSettingsTile(
	leading: const SvgIcon(path: 'assets/alarm.svg'),
	settingKey: 'key-use-permission-switch',
	title: 'A setting the user should confirm',
	enabled: true,
	onChange: (value) async {
	    // confirm dialog as from https://pub.dev/packages/confirm_dialog
	    // Where user has to confirm that click was intentional, when enabling something
           if (value) {
                return await confirm(context));  // set the switch and the stored setting to either true or false, depending on dialog result
           }
           return value;  // set the switch and the stored setting to `value`
	}
)

The API of "use the return value of onChange" is just one option. It could also be a separate handler. Or, as in this PR, a value attribute set externally (but I personally think that's a bit less clean).

This would really be helpful! :)