Added ErrorTextField validation #1082

OrkhanAlikhanov · 2018-05-31T22:04:35Z

First change is that, new errorLabel field is added to ErrorTextField. It will be shown in place of detailLabel when isErrorRevealed is set to true. Obviously, it's added to let botherrorLabel and detailLabel have their own style and text.

Secondly, ErrorTextFieldValidator is added which allows to set various validation criteria and to check if textField.text passes them or not. On failure errorLabel will be shown with corresponding error message set alongside the validation criterion. Basic setup is like so:

let usernameField = ErrorTextField()
usernameField.placeholder = "Username"
usernameField.detail = "You can use letters, numbers & periods"
usernameField.validator
  .notEmpty(msg: "Choose username")
  .min(length: 3, msg: "Min 3 characters")
  .noWhitespaces(msg: "Username cannot contain spaces")
  .username(msg: "Unallowed characters in username")

Validation will be checked on the sequence that's provided, so order is important.

Calling usernameField.isValid() will return boolean value indicating if validation passed. On failure corresponding error message will be shown. If developer needs to know validation status without showing show error message on fail, he can pass true to deferred parameter. usernameField.isValid(deferred: true). Note that when a validation fails others (in the sequence) will not be checked.

Custom validation closure can also be set to if provided ones does not cover developer's criteria

usernameField.validator.validate(msg: "Letter 'A' is not allowed") { text in
  return text.contains("A") == false // must not contain 'A'
}

By default auto validation is delayed until first error message appears. After first validation failure, validation will be rechecked on every change in textField:

^{Auto-validation is turned off until validation fails first time, which happens when isValid() is called on Sign Up button is tapped}
However, we have option turn auto validation on without waiting first error to occur.

usernameField.autoValidateOnlyIfErrorIsShownOnce = false //now the field will be auto-validated as user types

^{Auto-validation runs as user types}

Turning auto validation off:

usernameField.autoValidationType = .none // turned off
usernameField.autoValidationType = .default // turned on

Setting custom auto validation which will be called on every textField change:

usernameField.autoValidationType = .custom { textField in
  _ = textField.isValid() // this is default behavior, simply reruns validation 
}

OrkhanAlikhanov · 2018-05-31T22:20:38Z

Sources/iOS/ErrorTextFieldValidator.swift

+import UIKit
+import Motion
+
+open class ErrorTextFieldValidator: NSObject {


Actually there is no need to subclass NSObject

OrkhanAlikhanov · 2018-06-01T20:40:23Z

Demo project to play: demo.zip

OrkhanAlikhanov · 2018-06-02T12:41:24Z

Somewhat related to #1041 because of implementation changes.

daniel-jonathan · 2018-06-02T15:23:17Z

Adding #1017.

daniel-jonathan

Great work!
Here are a few comments for us to discuss.

daniel-jonathan · 2018-06-02T15:03:18Z

Sources/iOS/ErrorTextField.swift

      layoutSubviews()
    }
  }

+  open var isErrorRevealed: Bool {


I think we should rename this to isErrorMessageRevealed. This will allow the isError... prefix to be used and helpful when searching for flags through Xcode's code completion.

Actually isErrorRevealed name was in ErrorTextField even before my changes. I kept the name same. Also note that errorLabel.text has convenience field var error: String? just like detailLabel.text can be changed by var detail: String?. I mean that field is error not errorMessage. Should I still rename to isErrorMessageRevealed?

It is fine. It can stay. I thought we were introducing a new piece and so the format should be discussed in general. A style guide needs to be developed from the current code base, and changes we would like to make for future releases.

Sources/iOS/ErrorTextField.swift

daniel-jonathan · 2018-06-02T15:07:56Z

Sources/iOS/ErrorTextFieldValidator.swift

+//
+//  Created by Orkhan Alikhanov on 30/05/2018.
+//  Copyright © 2018 CosmicMind, Inc. All rights reserved.
+//


The header file comment needs to have the Material license added, and the default header comment removed. You can add your name as the originator at the top in the license if you like. Everything else would need to be the same. For example:

/* * Copyright (C) 2018, Daniel Dahan and CosmicMind, Inc. <http://cosmicmind.com>. * All rights reserved. * * Original Inspiration & Author * Copyright (c) 2018 Orkhan Alikhanov <[email protected]> * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions are met: * * * Redistributions of source code must retain the above copyright notice, this * list of conditions and the following disclaimer. * * * Redistributions in binary form must reproduce the above copyright notice, * this list of conditions and the following disclaimer in the documentation * and/or other materials provided with the distribution. * * * Neither the name of CosmicMind nor the names of its * contributors may be used to endorse or promote products derived from * this software without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */

daniel-jonathan · 2018-06-02T15:12:35Z

Sources/iOS/ErrorTextFieldValidator.swift

+    self.textField = textField
+    super.init()
+
+    textField.addTarget(self, action: #selector(checkIfErrorHasGone), for: .editingChanged)


Let's always move all preparation code to their own prepare function called in an instance prepare function. Material follows this setup pretty much everywhere. Mainly, it is to give clear insight into code changes. For example, if I comment out a prepare function, I know that all prepare logic is contained. Where if we scatter the logic, it could lead to undesirable behavior.

By the way, should I call removeTarget somewhere, like in deinit? I couldn't find answer. Note that textField is weak.

No you don't need to call that. The reference to target is not long lived, so you don't need to detach from it.

daniel-jonathan · 2018-06-02T15:13:43Z

Sources/iOS/ErrorTextFieldValidator.swift

+    case .custom(let closure):
+      closure(textField)
+    case .default:
+        _  = textField.isValid() // will hide if needed


If we add @discardableResult to isValid we can remove the _ = .

daniel-jonathan · 2018-06-02T15:15:39Z

Sources/iOS/ErrorTextFieldValidator.swift

+
+  open func isValid(deferred: Bool) -> Bool {
+    guard let textField = textField else { return false }
+    if !deferred { textField.isErrorRevealed = false }


Let's change deferred to isDeferred. The is... prefix is helpful when Xcode's auto completion pops up, as it will display all boolean or similar is... flags, which is an easy way to investigate an API.

daniel-jonathan · 2018-06-02T15:17:53Z

Sources/iOS/ErrorTextFieldValidator.swift

+
+open class ErrorTextFieldValidator: NSObject {
+  public typealias ValidationClosure = (String) -> Bool
+  open var closures: [(code: ValidationClosure, msg: String)] = []


Shortening variables is okay in function bodies, but for function definitions, let's use full variable names. For example: msg: String. It is more helpful when searching API definitions and it is more clear to the reader.

You mean it should be like this?

(code: ValidationClosure, message: String)

I actually changed my mind, I think all msg parameters in the function signatures should be in full form. What do you say?

Yes that is correct, and agreed :)

OrkhanAlikhanov · 2018-06-03T10:14:50Z

@DanielDahan Regarding #1041, does setting isErrorRevealed have to fire UIAccessibilityAnnouncementNotification? Can it have some side effects?

We can add option something like shouldPostAccesibilityNotificationWhenErrorRevealed: Bool, or maybe add a method like setErrorReveal(_ isRevealed: Bool, postAccessibilityNotification: Bool) to control posting that notification. Or we can simply delay it until someone asks for.

OrkhanAlikhanov · 2018-06-03T15:46:09Z

@DanielDahan we can merge autoValidateOnlyIfErrorIsShownOnce to autoValidationType by introducing new case there. What do you think?

daniel-jonathan · 2018-06-04T13:46:52Z

@OrkhanAlikhanov We will need to add comments to the function definitions and any class/instance variables.

daniel-jonathan · 2018-06-04T16:33:32Z

@OrkhanAlikhanov for the auto validation, you mean making an enum of different types? Yeah, I think that it would be a better approach.

daniel-jonathan · 2018-06-04T17:00:59Z

@OrkhanAlikhanov I think for UIAccessibilityAnnouncementNotification, I think we need to look at accessibility as a separate issue. Come up with an entire solution for the framework. Let's leave it out for now and make a note that we need it here.

…pe case

OrkhanAlikhanov · 2018-06-04T22:00:17Z

Latest demo project. demo.zip

OrkhanAlikhanov added 2 commits June 1, 2018 01:42

Added errorLabel to ErrorTextField

5cbae5d

Added ErrorTextFieldValidator

92bfca2

OrkhanAlikhanov commented May 31, 2018

View reviewed changes

OrkhanAlikhanov mentioned this pull request Jun 1, 2018

Can we make the error detail for textfields dynamic ? #1017

Closed

daniel-jonathan self-requested a review June 2, 2018 14:56

daniel-jonathan self-assigned this Jun 2, 2018

daniel-jonathan added enhancement in progress material labels Jun 2, 2018

daniel-jonathan requested changes Jun 2, 2018

View reviewed changes

OrkhanAlikhanov mentioned this pull request Jun 2, 2018

TextField Detail Label not Layed-Out correctly with Left-Image #1053

Closed

OrkhanAlikhanov added 3 commits June 4, 2018 21:47

Applied better naming and structure to ErrorTextFieldValidator

e34e503

Changed autoValidateOnlyIfErrorIsShownOnce flag to AutoValidationTy…

f5ea7a8

…pe case

Documented ErrorTextFieldValidator

ef8c327

daniel-jonathan approved these changes Jun 6, 2018

View reviewed changes

daniel-jonathan closed this Jun 6, 2018

daniel-jonathan reopened this Jun 6, 2018

daniel-jonathan merged commit 7a1adf1 into CosmicMind:development Jun 6, 2018

OrkhanAlikhanov mentioned this pull request Aug 9, 2018

TextField isErrorRevealed error #1131

Closed

OrkhanAlikhanov mentioned this pull request Oct 19, 2018

ErrorTextField doesn't reveal errors after upgrading to swift 4.2 #1175

Closed

OrkhanAlikhanov mentioned this pull request Nov 14, 2019

How to set max characters limit for material textfield? #1282

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Added ErrorTextField validation #1082

Added ErrorTextField validation #1082

OrkhanAlikhanov commented May 31, 2018 •

edited

Loading

OrkhanAlikhanov May 31, 2018

OrkhanAlikhanov commented Jun 1, 2018

OrkhanAlikhanov commented Jun 2, 2018

daniel-jonathan commented Jun 2, 2018

daniel-jonathan left a comment •

edited

Loading

daniel-jonathan Jun 2, 2018

OrkhanAlikhanov Jun 2, 2018

daniel-jonathan Jun 2, 2018

daniel-jonathan Jun 2, 2018

daniel-jonathan Jun 2, 2018

OrkhanAlikhanov Jun 2, 2018

daniel-jonathan Jun 2, 2018 •

edited

Loading

daniel-jonathan Jun 2, 2018

daniel-jonathan Jun 2, 2018

daniel-jonathan Jun 2, 2018

OrkhanAlikhanov Jun 2, 2018

daniel-jonathan Jun 2, 2018

OrkhanAlikhanov commented Jun 3, 2018

OrkhanAlikhanov commented Jun 3, 2018

daniel-jonathan commented Jun 4, 2018

daniel-jonathan commented Jun 4, 2018

daniel-jonathan commented Jun 4, 2018

OrkhanAlikhanov commented Jun 4, 2018

Added ErrorTextField validation #1082

Added ErrorTextField validation #1082

Conversation

OrkhanAlikhanov commented May 31, 2018 • edited Loading

Choose a reason for hiding this comment

OrkhanAlikhanov commented Jun 1, 2018

OrkhanAlikhanov commented Jun 2, 2018

daniel-jonathan commented Jun 2, 2018

daniel-jonathan left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

daniel-jonathan Jun 2, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

OrkhanAlikhanov commented Jun 3, 2018

OrkhanAlikhanov commented Jun 3, 2018

daniel-jonathan commented Jun 4, 2018

daniel-jonathan commented Jun 4, 2018

daniel-jonathan commented Jun 4, 2018

OrkhanAlikhanov commented Jun 4, 2018

OrkhanAlikhanov commented May 31, 2018 •

edited

Loading

daniel-jonathan left a comment •

edited

Loading

daniel-jonathan Jun 2, 2018 •

edited

Loading