Chapter 11. A Widget Bestiary

As we have seen, there are three ways to implement a new behavior in an application. In increasing order of complexity, you can:

• Find a toolbox widget that already does nearly what you need and extend it.

• Use the handler mechanism demonstrated previously in Example 10-4.

• Override event receiver methods and implement them yourself.

Handling raw events across multiple platforms can be quite complicated. Different devices, for instance, may have radically different keypads: for instance, four-key versus five-key D-pads. Some devices still require triple-tapping to enter alphabetic information. This kind of diversity is a serious issue in the mobile environment and can be a nightmare for the developer who wants to keep her application portable.

When designing your application, it's clearly smart to let the framework do as much as possible. The best option is to find some toolbox widget that has nearly the behavior you require and extend it to meet your needs. The toolkit provides extensive tools for doing this: XML attributes, fine-grained and overridable methods, and so on.

If it isn't possible to customize an existing widget, you should consider the listener mechanism, demonstrated previously in Example 10-5. Only when it is necessary to change the existing behavior of a widget should you consider overriding event receiver methods.

User interface frameworks have different names for the components from which they're composed: the text boxes, buttons, canvases, and other components that you use to create your unique application user interface. Android generically calls them Views, and the documentation defines them simply as:

View: An object that knows how to draw itself to the screen.

So any object that draws itself is a View, and Views that can contain or group other Views are appropriately called ViewGroups. Views are arranged and displayed on the screen according to a Layout, which gives Android hints about how you'd like to see the Views arranged. In the next few sections we'll look first at simple Views, then at ViewGroups, and finally at Layouts. Since expandability is a core principle for Android, we will also look at what you need to do to define your own custom Views and Layouts.

As we've already seen, Views and Layouts both have attributes that can either be defined in Java source code or in the XML file associated with the Activity that uses the View or Layout. When the attributes are in an XML file, they are "inflated" at runtime, meaning that they are applied to their respective Views by the Android framework to determine how the Views look and operate.

There are so many attributes that it doesn't make sense to list them all in these examples. We describe the key ones, and the rest are explained in the documentation that comes with the Android SDK. A quick search for android.widget.view_name will give you the class definition for that View, including all the attributes available for it, and a description of each.