Validating Input

After you’ve created your application so that users can enter information, and perhaps you’ve already created the mechanism to save the content to a database or remote server, what happens when the user enters invalid text or no text? Input validation now enters the picture.

Input validation verifies the input before the save takes place. If a user enters no text for the title or the message and attempts to save, should she be allowed to? Of course not.

The method in which you provide validation to the user is up to you. Here are some common methods:

EditText.setError(): If you detect that the user has tried to enter invalid text in a field, simply call setError() and pass the error message. Android then decorates EditText with an error icon and displays an error message. The message stays onscreen until the user changes the value of the field or until you call setError(null).

TextWatcher: Implement a TextWatcher on the EditText view. This class provides callbacks to you every time the text changes in the EditText view. Therefore, you can inspect the text on each keystroke.

On Save: When the user attempts to save a form, inspect all the form fields at that time and inform the user of any issues that were found.

onFocusChanged(): Inspect the values of the form when the on FocusChanged() 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 provides no input validation. However, you can add validation via one of the methods described earlier.

Toasting the user

The most common way to inform the user of a potential problem, such as an error in input value, is to display a Toast message. This type of message appears onscreen for only a few seconds by default.

Providing a Toast message is as simple as implementing the following code, where you inform the user of the input error:

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

You might show this message when the user fails to enter a title in the title field and then clicks the Save button.

The only problem with a Toast message is that it’s short-lived by default. A user who happens to glance away at the wrong time will likely miss seeing it. You can configure your Toast messages to display longer by using Toast.LENGTH_LONG instead of Toast.LENGTH_SHORT.

Using other validation techniques

A Toast message isn’t the only way to inform users of a problem with their input. A few other popular validation techniques are described in this list:

AlertDialog : Create an instance of an AlertDialog that informs the user of errors. This method ensures that the user sees the error message because the alert must be either canceled or accepted.

Input-field highlighting: If the field is invalid, the background color of the input field (the EditText view) can change to indicate that the value is incorrect.

Custom validation: If you’re feeling adventurous, you can create a custom validation library to handle validations of all sorts. It might highlight the field and draw small views with arrows pointing to the error, for example, similar to the Google validation of its sign-in window when you log on to a device for the first time.

You can use these common methods to display input validation information, or you can dream up new ways to inform users of errors. For example, Chapter 14 introduces the notification bar, which you can use to inform users of a problem with a background service.