Five Things that BlackBerry does better than iPhone

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

clouds
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

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

bbled

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

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!

Sibling CODs – or How to Make Your App Install Over The Air

It’s been way too long since I wrote a post – interesting aside for bloggers: don’t get out of the rhythm, it’s incredibly hard to start back up again once it’s no longer part of your daily routine. Anyway, I’ve been busy (more on that later) but due to demand am now committed to start posting again, and it was a recent comment on an earlier post that gave me the idea for this one: short but sweet and valuable to all aspiring BlackBerry app developers.

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:

File Size
myapp.cod 552,966

You get something like:

File Size
myapp.cod 58,016
myapp-1.cod 56,380
myapp-2.cod 57,980
myapp-3.cod 55,528
myapp-4.cod 53,816
myapp-5.cod 52,968
myapp-6.cod 50,004
myapp-7.cod 57,252
myapp-8.cod 53,772
myapp-9.cod 56,224

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

Sibling COD files

In reality what you get is:

File Size
myapp.cod 552,966

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 .http://winrar.comzip file! That’s right, http://allbeautyreviews.com/makeup – rename it to myapp.zip and open it and inside you’ll see:

File Size
myapp.cod 58,016
myapp-1.cod 56,380
myapp-2.cod 57,980
myapp-3.cod 55,528
myapp-4.cod 53,816
myapp-5.cod 52,968
myapp-6.cod 50,004
myapp-7.cod 57,252
myapp-8.cod 53,772
myapp-9.cod 56,224

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!

What would you like to know about BlackBerry development?

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

A suggestion on how to fix the BlackBerry JDE Eclipse Plugin

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 best fishing rods). 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.

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:

MIDlet vs. CLDC Application

There are many differences between the two types of application. I’ll highlight what I think are the most important ones, and point out areas where there isn’t really a difference.

Lifecycle

CLDC Applications have more flexibility in their lifecycle than MIDlets do – at least on BlackBerry. Specifically, a CLDC app can start when the BlackBerry starts (or reboots) and it’s easier to get it to run in the background to do listening, processing, etc. For many apps, this means CLDC is your only choice

User Interface

This is the big one. RIM has developed a rich UI library (in Java) for the BlackBerry. It’s designed to take full advantage of the BlackBerry input (keyboard, trackball and touchscreen on the Storm), and provides a lot of pre-built components. I’ve written about it extensively. The MIDP UI library just doesn’t give you the same power. To approach the complexity of a ‘native’ BlackBerry UI requires you to re-do a lot of the work that RIM has already done, and even then there are things you can’t do.

Some specific advantages of the BlackBerry UI library over MIDP (all in context of running on a BlackBerry of course):

  • Rich set of components, managers, screens
  • Access to trackwheel events
  • Easy access to all the BlackBerry keys (including ALT, escape, the softkeys)
  • Ability to provide the appropriate menu depending if the trackball or menu key was pressed
  • Integration of BlackBerry components (the browser, BlackBerry Maps) into a screen in your application
  • Built-in support for localization
  • Accelerometer support for Storm
  • Touch-screen events for Storm
  • Ability to change the homescreen icon

Let me know if there are some I’ve missed.

Things that can be used by a MIDlet or CLDC application

Contrary to what I’ve heard in some places, you can use a lot of the BlackBerry specific APIs in a MIDlet. These include cryptography, invoking other applications (but not embedding their UIs), extended SMS and location based services.

But – the MIDlet you build using any BlackBerry APIs will be a BlackBerry specific MIDlet. It will rely on BlackBerry APIs and so will only be able to run on a BlackBerry. If you’ve already taken that step – I’d ask why not go all the way and get a nicer UI while you’re at it?

A special note – you can, it seems, build a MIDlet for submission to the BlackBerry Application Storefront. However, you’ll have to compile it into a COD file, using the JDE (or Eclipse Plugin).

Possible advantages of going with a MIDlet

The biggest reason organizations want to go with a MIDlet rather than a CLDC application is obvious – you really write once, run anywhere. Now, this is true (barring implementation quirks with MIDP devices to be sure, but for many apps they’re not an issue) – but, you limit yourself to the MIDP lowest common denominator. This means your application doesn’t look or behave quite as nicely as a BlackBerry CLDC application. Think about what a Swing (or any pre-SWT) application looks like vs. a native Windows application and you’ll have some idea.

Maybe for your application it’s not an issue – and if so, more power to you – but from experience if you’re going to target the BlackBerry as the initial platform for your brand-new mobile application (and it’s a very good choice, maybe only iPhone would be better, but with the BlackBerry Application Storefront up and coming, the game will change again) then it’s in your interest to do everything you can to succeed on that platform. If you don’t succeed, supporting MIDP – or any other platform for that matter – might become a moot point.

Common code

There’s a way to mitigate cross platform headaches somewhat. MIDP and BlackBerry CLDC do share a lot in common. Enough so that business logic, and most networking code at least can be almost identical between the two platforms. Smart division of your app and supporting libraries can definitely save work if you want to support MIDP deviced and BlackBerry handhelds.

In the end…

With the BlackBerry Application Storefront launching soon, it’s never been a better time to get into the BlackBerry application market. Hopefully I’ve convinced you to go the CLDC Application route – you’ll save a lot of headache, and end up with a much better application.

Share and Enjoy:

The Golden Rule

The golden rule of the single-threaded API model is:

Only the event thread can modify the user interface.

In fact, it’s a little more subtle – only a thread holding the user interface event lock can modify the user interface – more on that later, for now just know that almost always the event thread is the one holding that event lock.

This means, if you’re doing anything that will directly result in immediate changes to the UI – pushing (or removing) screens onto the display stack, modifying the visible state of your UI components, painting – you have to do it in the event thread.

Simple, right? Yes, in theory. In practice, it’s not much more difficult – just bear in mind a couple of things.

As I said above the thread that enters your main method is your application’s event thread. This, combined with the golden rule means that in the initial call to your main method, you can do all the UI work you want. Often you create your app’s initial screen and push it onto the stack (using UiApplication.pushScreen) there – or at least in a method that you call directly from there. However, at some point you want to call enterEventDispatcher or you’ll never get user input. How do you modify the UI after that?

Modifying the UI

Now, the golden rule doesn’t mean that you can’t call any methods on any UI component from any other thread. Anything that gets information (EditField.getText for example) is fine. Also fine is setting information that may not result in immediate changes. But for most of the built-in UI components – like EditField, or LabelField, methods like setText will result in a change and so must be done while you have the event lock.

How do I know I’m on the event thread

Easy – just UiApplication.getUiApplication().isEventThread(swift runners) (or isEventDIspatchThread, which is a static method and does the same thing – both of those methods, by the way, actually reside in net.rim.device.api.system.Application, which is UiApplication’s super class).

You will sometimes end up on the event thread – menu items are executed on the event thread for example.

How can I modify my UI?

There are two ways:

1. Use the net.rim.device.api.system.Application methods invokeLater or invokeAndWait – both of which take a Runnable. Anything in that Runnable’s runmethod will be executed by the event thread at the next available opportunity. The first method is asynchronous (which means in this case that it returns immediately) the second is synchronous (so waits until your Runnable’s run method is finished before returning).

BlackBerry UI – A simple custom field

I’ve covered creating your own field Manager on this site already. As you might guess, another very common part of BlackBerry UI implementation is creating your own Field class (or extending one of the built-in classes). Fortunately, the basics are very easy, even easier than creating a Manager. I’ll run through a simple from-scratch Field to illustrate everything you’ll need to know.

The field I’ll be creating is a button – now, there’s a ButtonField already in the BlackBerry UI library, but it has just enough drawbacks that I’ve implemented countless replacements. Plus, it’s a great illustrative example – a button needs to to do a bunch of things to be useful. Specifically:

  • Basic Drawing
  • Focus highlighting
  • Responding to user input (trackball and touchscreen clicks, and the enter key)
  • Firing events to listeners

Which basically covers anything you’d want to do with most fields. So let’s get started:

The CustomButtonField

We’ll call this class CustomButtonField. It will do the following things:
– Behave like a ButtonField with respect to focus and user interaction (i.e. show a different color when focused, fire an event when the user clicks on it with the trackball, touchpad, or presses the Enter key when the field is in focus)
– Allow us to easily set the text color and background color (yes you can do the background with Field.setBackground, but that’s only JDE 4.6 and later and there’s still no easy way to set the font color, which makes setting the background limited).

Constructor and instance variables

We’ll define these first, based on our requirements. We’ll of course need the label for the button, and foreground and background colors both for the focused and unfocused states.

So

view plaincopy to clipboardprint?
  1. private String label;
  2. private int fontColorFocused;
  3. private int fontColorUnfocused;
  4. private int backgroundColorFocused;
  5. private int backgroundColorUnfocused;

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.