Making a Custom Screen, Vertically Scrolling and more

It’s been a couple of weeks since my last post - I’ve been busy with a couple of projects (hopefully more on one or two of those eventually), and there are a few posts I have in the works, but they’re all long enough that I don’t have the energy to finish them. Luckily I got inspiration for a new post from this reader comment! It’s fairly simple, but led to me finding a small bug in my GridLayoutManager, and does illustrate some interesting things about BlackBerry layout managers and screens, so read on (and keep those comments coming!):

The question (from Tony Bruce) was:

What happens if you add more fields than you have vertical space? I’m a BB dev newbie but it seams like if you add more fields than you have vertical space then eventually inside sublayout it is going to call layoutChild with a negative height. Is there some extra mojo you have to add if you want the grid to be scrollable so it can be bigger than the screen and the focused field is always visible?

There are two parts to my answer. To get scrolling behavior, just do what I did in my example screen. That is, create a MainScreen, create a GridLayoutManager, and then add the GridLayoutManager to the screen using the add(Field) method. When you add enough items to make the manager layout taller than the available screen height, scroll arrows will appear and the display will scroll to show the focused field. This works because MainScreen’s delegate manager is a VerticalFieldManager with scrolling enabled. What’s a delegate manager? That’s something you need to know if you ever make your own Screen.

Delegate Managers

Although Screen is a subclass of Manager, it actually doesn’t do any of the layout of fields added using its add (and insert) methods directly. Instead, each Screen delegates layout to a manager - the delegate manager. Notice that Screen’s constructor requires a Manager - you specify the Screen’s delegate manager at construction time, and can’t change it later. This means among other things that a MainScreen will always have a scrollable VerticalFieldManager as it’s main area - so if you want other behavior you can’t use MainScreen!

Easy enough - and this explains why we don’t need to do any additional work to the GridFieldManager example to make it scrollable - it’s automatically inside a vertically scrolling manager already! A couple more things about delegate managers, if you’re thinking of making your own screen.

First, the screen gets to set the position and size of its delegate manager. This is done in the layoutDelegate and setPositionDelegate methods. (You don’t have to make your delegate use the entire size of your screen).

Second, don’t worry about laying out any fields that are added to the Screen from within the Screen itself - that’s all done by the delegate. The screen deals with those field in the add (and insert) methods, and then basically forgets about them. This should be obvious but since it derives from Manager, I feel it’s worth saying explicitly - don’t make a Screen the same way you make a Manager.

Part Two: Mea Culpa

Part two will actually be quick - as the commenter pointed out, at some point GridFieldManager might end up setting fields to negative height. As we’ve just seen, in the case where we add it to a MainScreen, this isn’t an issue as we have a huge vertical space to play with. However it is a bug when we’re not in a vertically scrolling manager. So I made a couple of small changes to check that we don’t go above the available height. The interesting change is this, which is a fairly useful convention in a lot of layout methods - it ensures you respect the height (in this case) and width given by your manager:

		setExtent(totalWidth, Math.min(y, height));

Updated in the usual spot.