I have heard lots of questions about how to develop for Android OS lately, so I’ve made a point to explore more about native Android programming. Specifically, effective and efficient (and cool looking!) methods to perform form field validation. I started by working on a small mobile application that would require individuals to enter contact […]
I have heard lots of questions about how to develop for Android OS lately, so I’ve made a point to explore more about native Android programming. Specifically, effective and efficient (and cool looking!) methods to perform form field validation.
I started by working on a small mobile application that would require individuals to enter contact information. Through this exercise, I was able to find some really great resources from all over the web that helped move the process forward. I have consolidated what I learned here to help future Android developers down the path of validation.
Read on for what I did, and the tips and tricks I learned along the way!
The first question I had to answer was “when” did I want to validate fields? I came up with four different scenarios:
The next question I asked myself was how did I want the validation messages to look? After looking at various options like Toasts, I decided that the built-in “setError” method on a TextView object was the coolest and most effective way to display validation errors:
I like the display cue of the red icon (which can be customized) and the hover text which displays when each field has focus.
So now that I knew what I wanted to do, the next important question was: how to do it? So let me answer that based on my list of “whens” from above.
Android provides a long list of “input types” that you can set in the layout XML to “set the user up for success” so that they can only enter permissible characters or numbers. For example: an input type of “phone” leads to only numbers, and characters such as -, (, ) being available for the user to enter:
The XML to achieve this is shown below:
The challenge is finding the proper list of input type values to use in the layout XML and what they make the Android device do. This link will get you started.
Next up: what you can do when the user changes the text in a field and still manages to enter something incorrect, even though we set them up for success above. Well, if it can be done unobtrusively, the next best time to validate is when the user is actually entering the text (this is also where we can implement the cool icon and error message shown in the first screen).
To do this you have to implement a TextChangedListener which must implement the TextWatcher interface. The annoyance here is that you have to do this on a field by field basis so you need a way to “homogenize” the implementation or you will have tons of repetitive code. I did this by creating an abstract class called TextValidator which implements the TextWatcher interface (credit goes to Christopher Perry on Stack Overflow for this idea).
The key method in this class is afterTextChanged. My flavor of it is shown below (I don’t pass the text separately to the validate method).
Then I created a concrete class that extends the TextValidator class and implements the validate method:
I highlighted in red the two key elements of this class, that it extends TextValidator, and how to get the cool “icon” and error message. Using TextView.setError gives us the desired visual validation.
Now, the last step is to set this validator onto the text fields of interest. Since I wanted it set in all the text fields in my Activity, I created a “factory” class to set up the validation on all the text fields:
The 3 lines of code highlighted in blue are used to retrieve a list of all the elements on the screen. The code then loops through all of them looking for text boxes (EditText). For each EditText it finds, the line highlighted in red adds the on text change listener to the text box. The listener is used to trigger the validation logic whenever the user changes the text in the field.
The setup for validation when a text field loses focus is very similar to the one described above. There are just two small additions:
The final step in the validation is to make sure that the form is only submitted for further processing if there are no validation errors. Since the Activity keeps track of the state of all of its component elements, this becomes an easy task. You just need to check if an error message is set for any of the elements or not. If it is, then the form is not valid:
I created this method in the ContactValidatorFactory class and then called it from the submit method tied to the submit button on the form.
So what do you think? How would you improve this validation? How would you handle validation of other elements on a form?
Beat the heat and head to one of our favorite meetups or conferences! Check out...
Your company has invested in data science; you’ve created data teams, invested in expensive data...