Creating a Custom Screen BLACKBERRY

We’re actually using three screens in our UI Fun application already. Two are obvious: UiFunMainScreen and the login success screen. The third is the dialog that appears when you try to log in without entering a username and password .

The login dialog is a Screen too

The login dialog is a Screen too

A screen on the BlackBerry doesn’t have to take up the entire display; other screens can be visible below it. All screens, however, do take over the user input. That is, any keypresses, trackball presses, or touch screen taps only go to whatever screen is currently active and on top of the display stack. The active screen is also the one that controls the menu. All screens are derived from net.rim.device.api.ui.Screen. We’ll illustrate the concepts by creating a custom dialog to replace the default one, if for no other reason than we want to use our own colors and font and replace the OK button with one of our custom button fields. We’ll name our new screen CustomDialog (you should be seeing a pattern in our names by now) and directly subclass Screen. There is a PopupScreen class in net. rim. device. api. ui. container, but it adds some things that we don’t want, like a border. The basic code looks like this:

Right away, you should notice two things. First, we’re required to implement sublayout; this will actually be much easier than with a manager. Second, we’re required to pass a Manager to Screen’s constructor. This is the delegate manager.

Delegate Managers

A screen doesn’t directly lay out any of its fields. Instead, it delegates that to a manager that’s specified when the screen is instantiated. All the manager methods on the screen (add, delete, insert, etc.) actually end up invoking the same methods on the delegate manager. The only component the screen handles directly is the delegate manager.This separation of manager and screen makes it easy to change the internal layout of any screen.This also means that a screen must have a delegate manager at all times, so it must be specified at instantiation time and can never be changed.The delegate manager can be any valid Manager class, as there are no extra requirements above what a regular Manager does.

Implementing the Screen’s sublayout Method

As we’ve discussed, the screen’s sublayout method needs to worry about only the delegate manager. This is accessible through the getDelegate method.There are a couple of special methods in Screen that allow us to layout the delegate manager and position it. These methods work the same as the methods to set field position and size in any other manager. In addition to this, our sublayout method needs to set the extent of the screen, just as with any field, and set the position of the screen on the display.

The width and height parameters passed into the sublayout method of a screen will always be the width and height of the device’s display (on a device with a rotatable display, like the BlackBerry Storm, these will represent the current orientation of the screen). Note that setPosition sets the position of the screen relative to the device’s display; that is, setPosition(10, 10) will position the screen 10 pixels from the top-left corner of the display. setPositionDelegate sets the position of the delegate manager relative to the screen’s position. We’re going to give the delegate manager slightly less room than is available to us, to ensure the screen’s contents don’t take up the entire screen and to leave room for us to draw a border around the screen. When we’ve determined the size of the delegate, we set the actual size of the screen accordingly:

We’re leaving 30 pixels to the left and right of the screen and a minimum of 30 to the top and bottom, though if the delegate is small, we’ll have more space.We’re also leaving a 10-pixel border on all sides between the edges of the screen and the edges of the delegate manager to give us space to draw our border. Let’s add a LabelField to the constructor and make a change in UiFunMainScreen to see this in action. First, edit CustomDialog’s constructor:

The add method here actually delegates to the VerticalFieldManager constructed on the preceding line. Also, we’ve added the Screen.DEFAULT_CLOSE style so that pressing the escape button will close this screen. In UiFunMainScreen, modify the login method by replacing the line that shows the dialog:

Dialog.alert("You must enter a username and password");

with the following line to instantiate and show our custom dialog:

Now, run the application, and click the Login button (or menu item), and you’ll see abasic screen like the one in Figure.

Basic custom dialog

Basic custom dialog

Right now, there’s not much too it, just a white square with our LabelField on it, but it is a screen. Try typing, and you’ll notice that the rest of the application doesn’t respond. The custom dialog is intercepting all the keypresses. Pressing the escape key will dismiss the dialog.

Adding a Few Fields

We’ll modify the constructor to add an OK button and a separator field to fill out the adialog. We’ll also set the font while we’re at it. The following is the new constructor:

We’re using the same color scheme for the OK button as with the buttons on UiFunMainScreen. We’ll also have to make CustomDialog implement FieldChangeListener and provide an appropriate fieldChanged method:

Painting the Background

Just to illustrate the concept, we’ll draw a simple background consisting of a rounded rectangle in our tan color outlined in black. The paintBackground method is the place to do this; we won’t interfere with painting of the fields which is already handled just fine by the Screen class:

Now, let’s run the application again and take a look at our completed dialog.

The completed custom dialog

The completed custom dialog

The border between the outside edge of the screen and the delegate manager is now apparent by looking at the label and separator fields.Clicking OK will close the dialog, as we’d expect.

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