I’ll start with a confession - I’ve been using an iPhone instead of a BlackBerry for the past little while, because my company has been focused on developing some iPhone products. The iPhone is a phenomenal device, and certainly has to have RIM worried, but having used both devices now, there are definitely a lot of things that the BlackBerry does way better. I’ve picked 5 things that I really really miss about using a BlackBerry (and probably they’ll be the reasons that I go back to BlackBerry for day-to-day use soon). I think most of these are known to most people, but I’ve omitted a few things that are commonly thought of as BlackBerry’s advantages - I’ll explain why at the end of the article.

1. Push Email

Yes, iPhone does push email too, but BlackBerry does it better. You can sync an Exchange account with your iPhone and get push email, but only one. I’ve always got a minimum of 2 accounts I want to keep up to date with - currently 5 - but even with 2, I’d have to choose a preferred one (or consolidate everything through one account, which isn’t an option).

And sure you can get 3rd party solutions for iPhone that use the push notification functionality to tell you about new email - I’m using one called Mail Notifier - but it’s not the same thing. I get notified of a new email, which includes a snippet of the text, but I then have to go into the Mail app, select the account, wait for it to connect and download, and then click the email. With BlackBerry the email is already there, and I can even set the device to pop the email client up on new emails. No going through the list of accounts, remembering which one the email came from, speaking of which…

2. Multiple Email Accounts

Handled beautifully by BlackBerry. I can view the inbox for each account separately, but never do. BlackBerry lets me view all emails from all accounts in one place, and keeps track so that when I reply it comes from the right account.

There’s more! I can have separate signatures for each account (really really irritating missing feature on iPhone), and when I compose a new email to a contact, the BlackBerry usually guesses correctly which account I want to send it from - probably based on some analysis of past correspondence.

With iPhone I have to click on mail, click on the account, click on inbox. And then back out through those screens to check my next account. Just enough extra clicks to be annoying, and I can’t see all my emails from all accounts at the same time.

Email is part of BlackBerry’s DNA - it’s initial killer app was email, and the business and devices were built around that, and it shows.

3. The Keyboard

While the iPhone’s virtual keyboard is a pretty phenomenal piece of engineering, and amazingly usable (more than I can say for BlackBerry’s attempt at the same thing - but that’s a post for another day), nothing on any mobile device has yet delivered the same instant easy usability that the physical BlackBerry keyboard has. Not much more to say than that, but I will add that I’ve noticed a change in my behavior with regards to email, and I think it’s largely because of the lack of keyboard on an iPhone:

The iPhone keyboard, even being slightly more difficult to use than BlackBerry’s real keyboard, has put enough of a barrier in place (at least in my head) that I reply to a lot less email, and so get a lot less done away from the desktop. Meaning my response time has gone down, and there’s always more email waiting for me to reply to when I do get to a desktop.

4. The notification light

Yes, this thing:

Amazingly simple, but I really miss it. I’m used to glancing down at my device to see if anything new had come in - or looking at it lying on a table. iPhone doesn’t have an LED indicator for new email, so I can’t do that. Again, email is part of the core DNA of BlackBerry, all the way down through the hardware, and this shows it.

5. Total integration - email, calendar, contacts, notes, tasks

This is probably a bunch of things, but I’ll put them all together here. BlackBerry just delivers a better experience when going between all the above applications. It syncs them more readily, makes it easier to link calendar entries to notes to tasks to contacts, etc. It’s difficult to quantify but the overall experience is just smoother - obviously this is based on years of development and user feedback from RIM. It’s core to the BlackBerry experience and they still do it better than iPhone (even with it’s super slick UI)

Runners Up

BlackBerry Messenger

Really great, and hugely popular, but I honestly never used it enough for it to make my personal top 5

Camera

The camera on my Curve 8900 blew away the iPhone (still does) but there are better mobile cameras out there than the best that BlackBerry or iPhone offer

Things I specifically left out

Security

Yes, BlackBerry email (within a corporate environment) is very very secure. But for my use, I don’t really care. Most of my email is GMail based anyway, and so I’m always sending stuff to other people via plain unencrypted protocols. If I really care about security I send an encrypted attachment or use something other than email to do it.

Battery Life

I’ve gotten so used to plugging my devices in every night that this hasn’t been an issue with any mobile device (even though I use my iPhone for playing music as well as email/phone/etc). As long as the battery lasts the day, I’m happy.

Expandable memory

True, BlackBerry does support micro SD cards, but the support is hobbled by two things: 1. You can’t use the SD cards for app storage, and 2. for most devices at least, you have to remove the battery to remove the SD card - no hot-swapping

Conclusion

Yes, most of my points were focused on email, but that’s kind of the point. Email is one of the things I need to do from a mobile device. Probably the thing I do the most. Much more common than talking on the phone anyway (ironically?).
The BlackBerry email experience comes from a combination of hardware and software, focused to specific tasks, along with the BlackBerry services provided by carriers and RIM. It isn’t as versatile as iPhone but the tasks that it focuses on, it does very well. BlackBerry’s email is good enough that it’s a viable alternative to a desktop email client - iPhone’s is usable, but just isn’t at the same level. Is that enough to let BlackBerry hold it’s own against iPhone? I think so, but only time will tell.

Agree? Disagree? Leave a comment and let me know!

Being a huge fan of Eclipse for BlackBerry development - despite numerous problems - I was eager to try out this version. I discovered a few interesting quirks, but overall a much more solid development experience.

Installation

Installation is significantly easier with this version, mainly because the Eclipse Update Site for BlackBerry now seems to be working properly (some people were able to use it fine with v1.0 of the plugin, but I never did get it to work). The Plug-in ships with v5.0 of the JDE by default, but you can easily add 4.2.1-4.7.1.

The installer is available on the developer zone (http://www.blackberry.com/developers) - newly redesigned (and in a way which does make things easier). Click on development beta software on the left hand nav bar, the download is right there.

This version of the plug-in runs on Eclipse 3.5 Ganymede (1.0 ran on Eclipse 3.4) available free from eclipse.org/downloads. Not much difference between 3.5 and 3.4 in my experience (I’m sure the Eclipse team would beg to differ) aside from a few things in different places, including the software updates feature, which we can use to get older JDE versions installed with the plug-in.

The basic installation process itself is self explanatory - just run the wizard and follow the prompts - I won’t go into details.

Installing older JDE versions

JDE 5.0 is great, but is only shipping on a few devices right now, so you’ll likely need to get at least one of the older versions. You can do this by going to Install New Software from the Eclipse Help menu. Click the Add button and enter http://www.blackberry.com/go/eclipseUpdate/3.5/java in the Location field for the Add dialog. Then name the site something meaningful (RIM suggests BlackBerry Java Plug-in Update Site, I just used BlackBerry Updates):

Adding the BlackBerry Update Site

Once this is done and you’ve clicked OK, you’ll see a list of the JDE versions available from the site. I just selected all - figuring that I might as well get everything over with at once:

Selecting the earlier JDE versions

Click Next and then Next again, accept the license agreement and let the downloading commence. A warning - this is not a fire-and-forget installation: You will be asked for your developer zone login (email and password) and not right away, so at least make sure your computer is in sight so you’ll see the dialogs (yes, one for each JDE version) when they pop-up. You’ll also be asked to restart Eclipse when finished. It only takes a few seconds, so definitely a good idea.

Ch-ch-ch changes

If you’re familiar with the earlier JDE Plug-in, a lot of things have changed - pretty much all for the better, and all much more in keeping with the Eclipse way of doing things. I’ll go through the list that I’ve seen so far. I was tripped up on some of these - maybe I just don’t read documentation well - but hopefully I’ll save someone else the trouble.

Difference 1: Project-specific JRE versions

You now specify a different version of the JRE (Java Runtime Environment - basically the JDE) for each project in your workspace. This is a cleaner implementation in many ways, and probably more in keeping with Eclipse, but can be a bit annoying - after all, if you have more than one project in one workspace, don’t you often want to have them all running on a simulator at once? Ah well. There are a couple of places where you can specify this. First is in the new project dialog box:

Create a new BlackBerry project by clicking File->New->Project... and selecting BlackBerry Project. You’ll notice a field called JRE Version which is pre-populated with BlackBerry JRE 5.0.0. All of the JRE’s we selected from the BlackBerry Update site are available here:

Selecting the JRE version for a new project

What about changing the version for an existing project? I had a little trouble finding this (anyone else?). It’s available in a couple of spots, but the easiest one that I’ve found is right clicking the JRE System Library item under your project and selecting Properties:

Right Click JRE System Library and select Properties

The properties dialog box will allow you to select a different JRE/JDE version:

The JRE System Library Properties dialog

Difference 2: Location of resources in a compiled application

A huge fix in this version of the Plug-in is that folders besides src now work correctly all the time for source & resource files! In fact by default there’s a res folder in every new project for your resources. So to emphasize, I’m much happier dealing with the following quirk than the way things existed before - and great job RIM for fixing this.

The problem is that stuff placed in these folders ends up at the root level of your COD file. That is, if you have a setup like the following, with an image under res:

An image under the res folder

The following code (which may have worked under the older plugin):

		Bitmap bmp = Bitmap.getBitmapResource("res/icon.png");

		// bmp is null, so the following will throw an Exception
		int height = bmp.getHeight();

Will now cause problems, because res/icon.png will not be found. Instead you have to load the image from the root:

		Bitmap bmp = Bitmap.getBitmapResource("icon.png");

		// this works now
		int height = bmp.getHeight();

Just something to get used to - and you may want to update your build scripts according to the new reality.

Difference 3: Verification Errors

This one really tripped me up - there are some differences in the way things are compiled and/or run on the simulator with this version, which can cause obscure verification errors. While I’m sure several things can cause this, the problems with my applications had to do with using the Java class keyword in certain ways in static contexts. Specifically as a parameter to another constructor seemed to cause problems. I’ll illustrate:

One of our apps, Super Baby GO, uses a pattern similar to the following (admittedly rather contrived) example:

public class HelloWorldMainScreen extends MainScreen {

	static String className;

	static {
		className = new String(HelloWorldMainScreen.class.getName());
	}

This did work in previous versions, and causes no problems on device (when built using Ant for example). When deployed and run in the simulator from the 1.1 Plug-in, you get a RuntimeException with the message Verification Error 1756 at some offset (the offset changes depending on your program):

RuntimeException Verification Error 1756 with the BlackBerry Eclipse 1.1 Plug-in

Some hint to what causes this can be found in the simulator Event Log (hold the CTRL key on your keyboard and type L G L G). Look at those VM:VECMm, VM:VECCs etc. lines. They tell you where the error happened (in this case I’ve already given it away, it’s in the static class initializer - represented by clinit below):

The Event Logs around the Verification Error 1756

The problem is that using the class keyword as a constructor parameter in a static (class initialization) context causes problems with this version of the Plug-in. Fortunately this is easily resolved by using a temporary variable:

public class HelloWorldMainScreen extends MainScreen {

	static String className;

	static {
		String strClass = HelloWorldMainScreen.class.getName();
		className = new String(strClass);
	}

No significant problems doing this, the real time-waster for me was figuring out what caused this in the first place!

There are still a few things to talk about, including differences to debug configuration setup, and signing key management, but I’ll leave that for another post on another day.

Here is my GPS class that I use:

import javax.microedition.location.Location;
import javax.microedition.location.LocationException;
import javax.microedition.location.LocationListener;
import javax.microedition.location.LocationProvider;
import javax.microedition.location.QualifiedCoordinates;
/**
 *
 * @author Justin
 *
 */
public class GPS extends Thread {

	private double latitude;
	private double longitude;
	private String satCountStr;
	private float accuracy;
	private double heading;
	private double altitude;
	private double speed;

	private int interval = 1; // time in seconds to get new gps data

	/**
	 * This will start the GPS
	 */
	public GPS() {
		// Start getting GPS data
		if (currentLocation()) {
			// This is going to start to try and get me some data!
		}
	}

	private boolean currentLocation() {
		boolean retval = true;
		try {
			LocationProvider lp = LocationProvider.getInstance(null);
			if (lp != null) {
				lp.setLocationListener(new LocationListenerImpl(), interval, 1, 1);
			} else {
				// GPS is not supported, that sucks!
				// Here you may want to use UiApplication.getUiApplication() and post a Dialog box saying that it does not work
				retval = false;
			}
		} catch (LocationException e) {
			System.out.println("Error: " + e.toString());
		}

		return retval;
	}

	private class LocationListenerImpl implements LocationListener {
		public void locationUpdated(LocationProvider provider, Location location) {
			if (location.isValid()) {
				heading = location.getCourse();
				longitude = location.getQualifiedCoordinates().getLongitude();
				latitude = location.getQualifiedCoordinates().getLatitude();
				altitude = location.getQualifiedCoordinates().getAltitude();
				speed = location.getSpeed();

				// This is to get the Number of Satellites
				String NMEA_MIME = "application/X-jsr179-location-nmea";
				satCountStr = location.getExtraInfo("satellites");
				if (satCountStr == null) {
					satCountStr = location.getExtraInfo(NMEA_MIME);
				}

				// this is to get the accuracy of the GPS Cords
				QualifiedCoordinates qc = location.getQualifiedCoordinates();
				accuracy = qc.getHorizontalAccuracy();
			}
		}

		public void providerStateChanged(LocationProvider provider, int newState) {
			// no-op
		}
	}

	/**
	 * Returns the terminal's course made good in degrees relative to true north.
	 * The value is always in the range (0.0,360.0) degrees.
	 *
	 * @return double
	 */
	public double getHeading() {
		return heading;
	}

	/**
	 * Returns the altitude component of this coordinate.
	 * Altitude is defined to mean height above the WGS84 reference ellipsoid.
	 * 0.0 means a location at the ellipsoid surface, negative values mean the
	 * location is below the ellipsoid surface, Float.NaN that no altitude is
	 * available.
	 *
	 * @return double
	 */
	public double getAltitude() {
		return altitude;
	}

	/**
	 * Get the number of satellites that you are currently connected to
	 *
	 * @return String
	 */
	public String getSatCount() {
		return satCountStr;
	}

	/**
	 * Get the Accuracy of your current GPS location
	 *
	 * @return float
	 */
	public float getAccuracy() {
		return accuracy;
	}

	/**
	 * Returns the latitude component of this coordinate.
	 *
	 * Positive values indicate northern latitude and negative values southern latitude.
	 *
	 * @return double
	 */
	public double getLatitude() {
		return latitude;
	}

	/**
	 * Returns the longitude component of this coordinate.
	 *
	 * Positive values indicate eastern longitude and negative values western longitude.
	 *
	 * @return double
	 */
	public double getLongitude() {
		return longitude;
	}

	/**
	 * Get your current ground speed in meters per second (m/s) at the time of measurement
	 *
	 * @return double
	 */
	public double getSpeed() {
		return speed;
	}
}

Once you have added the GPS class to your project you can then use it the following way:

GPS gps = new GPS();
gps.start();

I like to start my GPS class as soon as my application starts up because it can take anywhere between 2 to 10 minutes for the BlackBerry to get a GPS lock. It will depend where they are. If you are outside with a clear view of the sky it works best (line of sight). Once you have the GPS option you can just pass the object between your screens or, if you want or you can just start a new GPS object, and if the first GPS object already has a lock then the new GPS class will get a lock right away.

Like I said before I like to use a Timer Task to update my screen UI. The reason for this is that it give me more options. This way I can tell the applciation how often I want to update the screen with the new data. I do it the following way:

import java.util.Timer;
import java.util.TimerTask;
import net.rim.device.api.ui.component.RichTextField;
import net.rim.device.api.ui.container.MainScreen;

public class GPSScreen extends MainScreen {
	GPS gps;
	Timer timer;
	RichTextField txtGPS;

	public GPSScreen(){
		gps = new GPS();
		timer = new Timer();
		timer.schedule(new CheckGPS(), 100, 1000);  //check for GPS every 1 second;

		String textGPS = "";
		txtGPS = new RichTextField(textGPS, RichTextField.NON_FOCUSABLE);

		add(txtGPS);

	}
	public boolean onClose()
	{
		timer.cancel();  //cleanup
		this.close();
		return true;
	}

	public class CheckGPS extends TimerTask{
		public CheckGPS() {
		}

		public void run() {
			double lat;
			double lng;
			lat = 0;
			lng = 0;

			lat = gps.getLatitude();
			lng = gps.getLongitude();

			if (lat != 0.0 & lng != 0.0) {
				synchronized (MyApplicationName.getEventLock()) {
					double acc = gps.getAccuracy();
					txtGPS.setText(lat + ", " + lng + " (" + gps.getSatCount() + ") (" + (int) acc + ")");
				}			

			}
			else
			{
				String thetxt = txtGPS.getText();
				synchronized (MyApplicationName.getEventLock()) {
					if(thetxt.length() > 10)
						if(thetxt.length() > 25)
							txtGPS.setText("Waiting for GPS.");
						else
							txtGPS.setText(thetxt + ".");
					else
						txtGPS.setText("Waiting for GPS.");
				}
			}
		}
	}
}

Here is a screen shot from my simulator:

GPSScreen in use with the GPS class

So within my Timer Task that runs once every second I use my get methods to get the Lat and the Long from GPS and I check to see if they are set. You could also add some more logic into the GPS class with a boolean flag to see if we have a GPS lock before you even get the values.

This GPS class will work with (almost) any BlackBerry Smartphone device that is GPS enabled. It will not work for Verizon 8130, 8330, and 8830, but it does work with the Verizon Storm and Tour. This Class will work with any 4.2 device that has a Bluetooth GPS receiver, including the Verizon devices listed above (8130, 8330, and 8830) as a workaround to the Verizon GPS lock-down.

Here is some related GPS information:

Java Doc: javax.microedition.location.Location
GPS and BlackBerry Maps Doc from RIM

Enjoy!

Justin

Justin is a BlackBerry developer (among other platforms) and has created a couple of great BlackBerry applications, including BBGPSGolf, a great free golf application for BlackBerry that uses the device’s GPS to show a map and give you information about golf courses (distances to the green, etc) on your device while you’re on the course.

Anyway, he graciously offered to share some of his GPS expertise with us so read his post and if he gets enough good feedback maybe he’ll share some more of his BlackBerry development expertise!

Faithful readers may have noticed how the frequency of my posts has dropped off rather sharply in the last few months. There are two reasons for this.

First, I’ve started a company called Zeebu Mobile doing - what else? - BlackBerry application development, specifically in educational and early childhood applications. We just released our first product, Baby GO!, which is free and runs on all BlackBerry devices with OS 4.2.0 and higher.

Second, I’ve been writing a book called Beginning BlackBerry Development which will be published (hopefully!) in late October.

No worries about the book - it doesn’t restrict me in any way from posting, except that it’s taking up a lot of my time. I’m still free to write about the topics I cover in the book on this blog.

The really good news for anyone reading this, is there are a couple of new things coming along soon that should result in more posts to the blog in the very near future. So bear with me and stay tuned! Thanks.

-Anthony

Basically performance depends on the type of arithmetical operation you’re doing (though double is always slowest, usually by a wide margin). For addition and subtraction, Fixed32 is faster, for multiplication and division float wins out. Some sample results:

BlackBerry Bold

The net.rim.device.api.math.Fixed32 class is interesting - I’ve mostly used it in scaling EncodedImages. It packs a fixed decimal representation of a number into a 32 bit int datatype, using the leftmost 16 bits for the whole part, and the rightmost 16 bits for the fractional part. This has the result that the normal + and - operators work as expected, but multiply and divide are handled through special functions.

Though I’ve gotta disagree with the poster’s conclusions - Fixed32 is not strictly legacy, it’s only been available since OS 4.0, at which time float and double were available on BlackBerry.

There’s a lot more interesting discussion and more results for different devices just in this post, so I encourage to read the original!

Big CODs

BlackBerry applications are compiled using the RAPC tool (which is called automatically by the JDE or the JDE Plug-in for Eclipse) into .cod files (pronounced like the fish by most developers). A .cod is basically a .jar file, which is further compressed, optionally signed, and has any unused code removed. They’re only usable by the BlackBerry - no other J2ME devices.

Because of some deep technical reasons (I think to do with the way the flash file system used to work on the device) a .cod file can only be a certain size. Or more correctly, a .cod file can only have a certain amount of code or static data (resources mostly). That limit is about 64k - so theorietically a .cod file could be almost twice that limit, with 64k each of code and data, but in practice that never happens, and in fact there seems to be another limit. In any case, the exact number isn’t all that important - the point is that most modern applications have no trouble breaking through either or both of those size barriers.

So what happens when you make an application that produces a .cod that’s too big? The RAPC compiler breaks the .cod into smaller .cod files, and renames them based on your initial .cod file. So instead of having:

You get something like:

Or at least - that would make sense. Actually it’s something slightly different.

Sibling COD files

In reality what you get is:

So what gives? Well if we take a closer look at that big cod file, what you’ll notice is this: it’s actually a .zip file! That’s right - rename it to myapp.zip and open it and inside you’ll see:

Those similarly-named files inside the big .cod/.zip file are called sibling COD files.

So What?

So, ok all your .cod files are packaged up into a .zip. Sensible, right? Just load that one file and everything works. Well, that’s true, except if your trying to download your app to your BlackBerry without using a BES. Understand that sentence - you can load one big .cod file if you’re doing it through the desktop manager, or if you’re downloading through a BES, but if you’re not attached to a BES and want to download it directly to your device, you’re out of luck.

Fortunately the solution is relatively simple - just unzip that big .cod/.zip and post all the individual files to the same directory, along with the .jad file. Then things will work fine - the browser will even know enough to show the user the total app size before downloading.

In fact, if you want to automate all that, I recommend the excellent (and free) bb-ant-tools, which includes a nice Ant task called jadtool that does the unzipping of the sibling cods for you.

So there you go - sibling CODs!

I’ve gotten several good ideas for posts from the readers of this blog, so I’ve decided (based on a user comment) to put a sticky post up solely for the purpose of soliciting new post ideas.

So here it is: What would you like to see me write about? Any area of BlackBerry development is fair game. Leave comments below and I’ll pick the ones that are most in demand or that I think would make the best posts.

I’ll start off with some ideas:

• BlackBerry networking - TCP/BIS/BES - what are they and how do you use them?
• Resource bundles and localization
• Debugging with the Eclipse debugger
• Debugging your application on a real BlackBerry using the Eclipse debugger (or the JDE debugger)

Thanks!

Anthony

But - there are some pretty significant quirks.

Big ones that I haven’t found good workarounds for include:
- src is the only ‘officially’ recognized source folder. I don’t know why or how RIM overrode this, but the bug is: You can set any folder to a source folder (as with any Eclipse project) and things will work, until you shut down and restart Eclipse, at which point only src will still be a source folder. The workaround is to manually re-add your source folders to the build path each time you restart Eclipse (which may not be that often) which works, but is obviously not great (read: very, very annoying)
- you can’t add 3rd party .jar files to a BlackBerry project in Eclipse (mentioned here). The only way around this is to use source files (for KXML/KXML-RPC, the most common one I’ve seen, source is thankfully available, though you have to dig)
- importing from a .jdw (BlackBerry JDE Workspace) file is broken - you get a bunch of symbolic links to your files in your Eclipse project. Just means you have to rebuild your project, making the Import feature pretty useless.

There are others, but you get the idea

Don’t let these scare you away (unless one really is a showstopper) - Eclipse is still the best way to go.

Now, here’s my suggestion for fixing things:

Open source the BlackBerry JDE Plugin for Eclipse!

That’s right, open source it. Please. Listen, RIM, if your’e reading: There’s a big and growing community of BlackBerry developers yearning for a better way to build BlackBerry apps. And you have very strong competition in the form of iPhone and Android, both of which have stunning development environments. They both came to the game late, and they’ve leapfrogged you, and you’re falling further behind.

You don’t have to make it GPL or even LGPL. Something less idealistic would be fine. You don’t even have to open-source parts of the Plugin that we know work (like RAPC). Just as much as you can, as soon as you can, so some enterprising BlackBerry developer out there with good knowledge of the Eclipse platform (and believe me, there are enough) can figure out what’s wrong and FIX IT.

Thank you!

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.