-
-
Notifications
You must be signed in to change notification settings - Fork 52
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
use 'Cancel' instead of 'Back arrow' for server settings #2247
Conversation
ec6200c
to
c436748
Compare
70dcb23
to
4ca9eaa
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! I added a few questions, but feel free to ignore them :)
deltachat-ios/Controller/AccountSetup/SecuritySettingsController.swift
Outdated
Show resolved
Hide resolved
class AccountSetupSecurityValue: SecuritySettingsDelegate { | ||
var value: Int | ||
|
||
init(initValue: Int) { | ||
value = initValue | ||
} | ||
|
||
func onSecuritySettingsChanged(newValue: Int) { | ||
value = newValue | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the reason this implementation of SecuritySettingsDelegate
is a dedicated class, while CertificateCheckDelegate
is implemented as extension of AccountSetupController
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we need two different delegates for SecuritySettingsDelegate
- i did not find out a smart way to do that as an extension. one could add some state to the delegate - but that seems to work against the idea of the delegate
thanks a lot for approval - and also, let me note, that the notes and comments atop of the approval are very welcome and on point, thanks for that as well 🙏 |
this PR fixes the issue that selecting "IMAP Security", "SMTP Security" and "Certificate Checks" are persisted in core even if no "Log In" was tried. this leads to inconsistent views. even more inconsistency was added as the text fields are persisted correctly on "Log In", so, the user never knows which field was cancelled and which not.
the reason was, that
SecuritySettingsController
andCertificateChecksController
persisted the value too soon in core when hitting "OK" in the controller.this PR calls a delegate instead which sets a value in the
AccountSetupController
. only if finally "Log In" is hit, the values are persisted in core together with the value from the text fields.the code of the whole controller is a little bit messy, this PR does not clean up there as things actually are working so far. instead, the PR fixes the issue on point, keeping other flows and conventions.
finally, the PR removes some unimportant summary which is available better in "view log", adds simple "back" buttons to subsequent dialogs and renames the main "back" button to cancel (which was the original reason of #2246, i thought the rename is easy :)
closes #2246