Validating Input

You've created your form so that users can enter information, and perhaps you've already created the mechanism to save the content to a database or remote server. But what happens when the user enters invalid text or no text? This is where input validation enters the picture.

Input validation validates the input before the save takes place. Assume that the user does not enter text for the title or the message and attempts to save; should she be allowed to save? Of course not!

Unfortunately, a built-in Android validation framework does not exist. Hopefully, in future versions of the Android platform this feature will be introduced. However, you have ways to validate input with the current framework.

The method in which you provide validation to the user is up to you. Here are some common methods in which I've seen developers implement validation:

• TextWatcher: Implement a TextWatcher on the EditText widget. This class provides callbacks to you each time the text changes in the EditText widget. Therefore, you can inspect the text on each keystroke.
• On Save: When the user attempts to save the form that he is working with, inspect all the form fields at that time and inform the user of any issues found.
• onFocusChanged(): Inspect the values of the form when the onFocusChanged() event is called — which is called when the view has focus and when it loses focus. This is usually a good place to set up validation.

The Task Reminder application does not provide input validation; however, you can add validation via one of the methods described previously.

Toasting the user

The most common way to inform the user that something is incorrect is to provide a Toast message to her. A Toast message pops onto the screen for a short period of time informing the user of some type of information — in this case, an error with input values.

Providing a Toast is as simple as implementing the following code, where you'd like to inform the user of the input error:

Toast.makeText(ReminderEditActivity.this, “Title must be filled in”, Toast.LENGTH_SHORT).show();

You might show this Toast message when the user does not enter a title into the title field and when the user clicks the Save button.

The only issue with Toast messages is that they are short-lived by default, yet they can be configured to display longer. If the user happens to glance away for a moment, he can miss the message because the Toast message only shows up for a few moments and then fades out.

Using other validation techniques

A Toast message is not the only way to inform users of a problem with their input. A couple of other popular validation techniques are as follows:

• AlertDialog: Create an instance of an AlertDialog that informs the user of the errors. This method ensures that the user will see the error message because the alert must either be canceled or accepted.
• Input-field highlighting: If the field is invalid, the input field (the EditText widget) could have its background color changed to red (or any color you choose) to indicate that the value is incorrect.
• Custom validation: If you're feeling adventurous, you could create a custom validation library that would handle validations of all sorts. This validation could highlight the field and draw small views with arrows pointing to the error with highlighting. Google uses similar validation for its sign-in window when you log on to a device (such as the Samsung Galaxy S) for the first time.

I've shown the most common methods of displaying input validation information. But as long as you can dream up new ways to inform users of an error, you can use those new methods. For example, in Chapter 15, I introduce you to the notification bar. I have used the notification bar in my own projects to inform users of a problem with a background service. Although this is a special case, it is a valid one, and it provides the user with feedback that he needs to make adjustments to the application or the workflow.