BlackBerry Arithmetic Performance

Playing with some animation for a new BlackBerry product (see next post) and wondering about performance of double/float/Fixed32 arithmetic I came across this post on Blurry Words, which is exactly what I was looking for.

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

Variable Type Add/Sub (ms) Mult (ms) Div (ms)
Fixed32 153 597 776
float 317 242 550
double 514 366 1931
long 114 117 225
int 96 90 114
short 102 102 125
byte 104 107 127

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!

Custom Screen, Vertically Scrolling and more

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:

Eclipse tricks for BlackBerry developers 1 – type less, autocomplete more

If you’re a BlackBerry developer used to using the JDE (or – yes, I’ve seen this – the Visual Studio editor and Ant scripts – don’t ask, and no it wasn’t the BlackBerry Visual Studio plugin) then you might be wondering what the fuss is about switching to Eclipse. After all, there are still some problems that the Eclipse plugin has that aren’t there in the JDE.

Well, the main way you’ll gain productivity (and lose stress) is through Eclipse’s Java editor. Even those of you who are used to Visual Studio may be surprised by all that Eclipse has to offer. There are so many things to talk about, that in the interests of keeping this post short, I’ll focus on just one (but it’s a good one): Autocomplete

Autocomplete

The keystroke for autocomplete is CTRL+Space, which will autocomplete whatever you’re working on, or give you a list of options if there are more than one. So a simple example – start typing:

 

Then press CTRL+Space

 

Notice you get a list of possible objects you might have been referring to – this will include, depending on context, classes, member variables, local variables, or methods (static and/or instance depending on where you’re typing).

Not bad so far – but there are similar things in other editors. Even the JDE has a limited version of autocomplete. Ok, here’s what else it can do:

Context sensitive autocompletion

If you type something like int a = <ctrl+space>, Eclipse will sort the autocomplete choices only to things that make sense on the right side – int variables (local, instance, static), or methods that return an int!

Automatic imports

Dislike managing Java imports? Autocomplete does that too – if you type in the name of a class (or partial name) and press CTRL+Space, the import for that class (if needed) will automatically be added to the top of your source file. I haven’t typed in an import statement myself in months. When you do autocomplete, Eclipse searches through all referenced libraries for your project, and since BlackBerry Eclipse projects include the RIM APIs, you get all of them…

Autocomplete Templates

Enough yet? Well, here’s another trick. Eclipse includes autocomplete templates – this is something that’s better experienced than explained, but I’ll give an example.

Type for and press CTRL+Space and you’ll see:

 

Now selecting one of those templates will let you fill in the details interactively:

 

Not all the templates apply to BlackBerry, as J2ME is missing some of its big brother’s features. You can see a full list under Window->Preferences->Java->Editor->Templates, but other useful ones are sysout -> System.out.println(the best beard trimmer), and instanceof -> instanceof test and conditional cast

More?

Yep, even more clever tricks…

Type a class name and hit autocomplete (or autocomplete the class name and hit autocomplete again) and Eclipse will guess at a variable name for it:

 

Note there is no variable (instance or local) named mainScreen or screen in this class – those are Eclipse’s suggestions!

Autocomplete is also aware of camelCase methodNames, so if you type mainScreen.aMI, it’ll resolve down to mainScreen.addMenuItem, www.dapperbeard.com

There are some more tricks and subtleties – but start by making CTRL+Space your best friend in Eclipse and you’ll wonder how you ever lived without it. Sometimes it feels like a game to try and hit the fewest keystrokes – or maybe that’s just me. Anyway, that’s all for this post, but not by a long shot all there is to Eclipse. I’ll write about Refactoring, more auto-source code generation tricks, debugging and whatever else I can think of in future posts.