The view class represents the basic building block for user interface components. A View occupies a rectangular area on the screen and is responsible for drawing and event handling. Subclasses of the view class also offer fully implemented UI objects like text fields and buttons; these are often called widgets.

A View object handles its own measurement, layout, drawing, focus change, scrolling, and key/gesture interactions for the rectangular area of the screen in which it resides. As an object in the user interface, a View is also a point of interaction between the user and the activity(s) that is reacting to the interaction events.

Multiple views can be grouped together in view groups. These view groups can also contain other view groups. This arrangement can be visualized as a hierarchical tree-structure where the group view nodes are branches, and the view nodes are leaves (refer to image to right, taken from android developer guide).

One important thing to remember is that a view can refer to the canvas that contains all of the graphics on a screen, or to a single button within a menu. This structure is enables parent views to influence child views. This is important considering that the android OS runs on so many devices with such divergent specs.

Standard Views
Android applications can be built using standard views or custom views, or they can contain both. Standard views are composed of buttons and other standard elements. These types of views are easy to create but provide limited opportunities for customization. Therefore, their use is limited in the realm of mobile games.

Standard views are created using XML layout templates that are saved in the layout folder in the package resources. These standard view definitions are usually simple documents that include only a short list of attributes such as screen orientation, width and height, and text. When an activity is linked to a standard view, the attributes in the XML document determine how objects (buttons, text, etc) from that activity appear on the screen.

Sometimes classes are created to extend the functionality of a standard view. However, I will not explore any examples of this practice here.

Custom Views
Custom views can be created in many different ways. Unlike standard views, they are always defined using both XML code and class extensions. For my application I created a custom view by extending the SurfaceView class, and defining a simple view layout using XML. I initially selected this approach because I was using Matt’s sample application as my guide. Upon further investigation I’ve confirmed that this is the best approach.

Here is an overview of how this approach works. It is pretty complex, so here is a link to an official description from the android site.

SurfaceView is a special subclass of View that offers a dedicated drawing surface to an application’s secondary thread, so that the secondary thread can draw to its own Canvas at its own pace (without needing to wait for the main thread).

Here is how you set-up an application to use this class. First,  create a class that extends SurfaceView and implements the SurfaceHolder.Callback interface (named GameView in my app). This class will serve as a link between the thread class that will perform all the drawing procedures and the canvas itself.

This new view class needs to include an instance of the secondary thread (named GameThread in my app), which contains all drawing procedures. Then, to enable the secondary thread to access the drawing surface, create an instance of the SurfaceHolder object. This object functions as the connector between the view and thread classes.

Next initialize the SurfaceHolder variable so that the new view class receives callbacks related to surface activity. Lastly, we need to override all the callback methods from the SurfaceHolder.Callback interface. I know this is a lot of information to keep straight, and we’re not done yet.

Now that you’ve set-up the new view class, here is what you need to do in the thread so that it can draw to the canvas/surface. First, we need to pass the SurfaceHandler object from the view class to the thread class. Then, each time we want to draw to the canvas we need to retrieve the canvas using the lockCanvas() method from the SurfaceHandler object. Then the thread can draw to this canvas.

Once done drawing, we need to pass the updated canvas object back to the SurfaceHolder object using the callunlockCanvasAndPost() method. The Surface will now draw the Canvas.

To clear the previous state of the Canvas you need to fill it with a color using drawColo() or set a background image with drawBitmap(). Otherwise, you will see traces of the drawings that were previously performed.