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.
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
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
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
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: