Mini Project — Android EditText Validation

Ben Daniel A.
3 min readApr 8, 2017

--

Image credit: http://www.androidhive.info/wp-content/uploads/2015/09/android-material-design-floating-labels-error-messages.png

Most Android apps have at least one form which require users provide inputs that will allow them to continue using the app. It could be a login form or a sign up form. All the apps that I’ve created has both forms. It is important to ensure that users input the correct type of data for each input field that exists in the form. To give users the best user experience, some developers highlight wrong inputs before requests are pushed to the server. This way, users won’t have to see validation error messages from the server about wrong inputs. It is annoying, and a waste of time and resources.

I have encountered different forms of validation for text fields (EditText) from online examples. The most basic being the one newbies always start with (I did too).

The above checks if the EditText passed as an argument has at least one input. It returns true if it does.

This method is usually put in a Validator class where other methods like isValidEmail(EditText), isValidPhoneNumber(EditText), isInRange(Range, EditText), etc are found. After checking for these rules in the submitted form inputs, we usually show some sort of feedback to the user, sometimes highlighting the affected fields so that users may edit them.

Notifying users directly on the fields, some developers prefer to show a list of errors on top the form.

I later found some libraries on github that simplified the process of validation. Some of these libraries required using custom EditText to enable and customize the validation. I’ve been discouraged from using third party custom views except they are absolutely necessary. That’s why I didn’t use them.

I embarked on a mini project to create a simpler validation framework based on the knowledge and experience I’ve garnered. I came up with a simplified and customizable version that can perform validations and give feedback by highlighting the affected fields. This framework is one of the key modules of appcommons; the library that I’ve created that contains the some Android development utilities which I use in my projects. Say I have a log in form with two input fields: username and password. Since these two inputs are both required for signing in, I’ll simply add the validation logic like this

Notice how simple and neat the validation, error feedback and clearing of error is handled in lines 3–5

EditTextUtils is a utility class where I put methods which perform the frequently used actions that I’ve been carrying out on input fields. The method EditTextUtils.isInvalid(…) loops through the supplied validation rules and tests each rule based on the input supplied in the input fields. If they pass, the error marker on the input field is removed otherwise an error marker is set on that input field. The error marker logic will use the EditText.setError(…) method. And if the EditText was placed inside a TextInputLayout it will use the TextInputLayout.setError(…) instead.

I was even able to take it further by adding more validation rules into the project:

  1. EditTextEmailValidator
  2. EditTextNumberRangeValidator
  3. EditTextPhoneNumberValidator
  4. EditTextTextLengthValidator
  5. EditTextRegexValidator

And many more. This arsenal has come in handy for me most of the time, other times, I simply extended EditTextValidator and provided the custom validation suitable for that exceptional case.

Recently, I have been introduced to the android saripaar validation library that supports robust rule-based validation. It looks easy to set up and provides a declarative style validation using Annotations. I’ll try it out in my next Android project.

Validation of input fields cannot be overemphasized, I believe that’s why most teams implement the validation on the front end (mobile app) and the back end (server). Validation becomes a painful experience for users if they end up being confused as to what was wrong with their input. This is why every validation framework must cater for both validation and feedback, including clearing the error feedback when the user has corrected a previously incorrect input.

--

--