Drawing to the Screen Using the Graphics Context - BLACKBERRY

The basic interface for displaying anything to the BlackBerry device’s screen is the net.rim.device.api.ui.Graphics class. It’s used under the hood by pretty much all elements of the BlackBerry user interface,and it gives you the tools to do anything you’ve seen in any BlackBerry application’s user interface. If you’re going to be doing any kind of user interface work with BlackBerry applications, you should get very familiar with the Graphics class. Each instance of Graphics is associated either with a Bitmap object or with a display (basically, a BlackBerry device’s physical screen).For this book, we’ll only focus on a Graphics object associated with a display.

Using the paint method

All fields (and managers and screens) get access to the Graphics object associated with the current display through the paint method. This method is called whenever the BlackBerry device determines that the section of the display containing the Field needs repainting.An important thing to bear in mind is that the same instance of the Graphics class is used by all managers and fields on a screen, and this instance is passed by the screen through its managers to the fields. This may seem a minor point, but it’s important to keep in mind, as it’ll help in determining exactly why your application is drawing to the screen in a certain way. For example, setting the color on the Graphics object will affect the color of components drawn after it, unless they explicitly set their own colors. Because it’s so important to understand how the UI is displayed by the BlackBerry platform, we’ll take time for a brief discussion here before getting to more concrete examples.

Understanding How the BlackBerry Screen Is Drawn

At a high level, things happen in two stages. First comes the layout stage, where layout and sublayout methods are called and all the fields are positioned and sized on the screen. Second is the paint stage, where paint methods are called and the fields actually draw to the display.

Laying Out the Screen

Layout involves positioning and sizing all the managers and controls on the screen. It starts with the screen itself and works down through all the nested managers and fields as follows:

  1. The screen’s sublayout(int width, int height) method is called. The width and height parameters will be the width and height in pixels of the device’s display.
  2. The sublayout method of the screen’s delegate manager is called. You’ll learn more about the delegate manager when you learn to build your own screen class, but briefly, it’s the component that actually contains and lays out all the fields and managers on the screen and is the only component directly controlled by the Screen itself. Often, the delegate manager will take up the entire screen, but there are instances, such as in a dialog with a border, where this may not be the case. So the width and height parameters passed to the delegate manager’s sublayout method will be less than or equal to the width and height parameters passed to the screen’s sublayout method.
  3. The delegate manager iterates through all the fields and managers it contains and lays out each of them, that is, positions them within itself, tells them how much space is potentially available and asks them what size they’ll be on screen.This has the effect of calling sublayout (for a manager) or layout (for a field). The width and height available to each of the fields and managers will vary depending on how the delegate manager lays out its fields. In many cases, they may be greater than the height and width of the delegate manager itself; this means that the delegate manager is a scrolling manager and will only draw a subset of its fields at any time.
  4. Each manager lays out its managers, fields, and so on.
  5. Each field lays out itself out; a field may take up less than the space available.

Painting to the Screen

The Painting stage is where pixels are actually drawn to the screen. In the same sequence as the layout stage, the screen, managers and fields are all asked to paint themselves:

  1. The screen’s paint method is called, with a Graphics context that represents the current display.
  2. The screen may do some painting itself (drawing its background for example) and then asks its delegate manager to paint itself, which has the effect of calling the delegate manager’s paint method with the same Graphics object.If the delegate manager is smaller than the screen, the screen will set a clipping region on the Graphics object to the size and position of the delegate. This prevents the delegate from drawing outside its size (set during layout) and frees the delegate from worrying about what its absolute position on screen is (which, in fact, it generally doesn’t know).
  3. The delegate manager again may do some painting itself, and then asks each of its subfields and managers to paint themselves, setting appropriate clipping regions for each of its fields.
  4. Each manager paints itself and asks its managers and fields to paint themselves.
  5. Each field paints itself.

Another important thing to keep in mind is that layout happens rarely generally when a screen is constructed or when fields are added or removed—while paint happens frequently. This means that you should be very concerned about the speed of your paint methods; slow paint methods will slow down your user interface and negatively affect your application’s user experience. You should remember, in a nutshell, that

  • ayout happens once (or rarely), and in this step fields size themselves and are positioned.
  • aint happens often, and in this step, fields draw their contents to the display.

Now that we’ve covered the framework, it’s time to fill in the details by actually implementing some custom fields, managers, and screens.Along the way, we’ll use a lot of the methods in the Graphics class and explore those as we encounter them.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status