Debugging for the New Blackberry 9800

Debugging for the New Blackberry 9800

Hopefully, a helpful hint:

Use the Blackberry SDK version of the 9800 simulator, and not the one that you can download separately from the Blackberry website.

The SDK simulator seems to work fairly well; the separate download version tends to lock up when trying to access embedded web controls.

This may be a very temporary thing. But for now, I can say at least anecdotally this has been my experience.

Windows Phone 7 – Some Initial Thoughts

Windows Phone 7 – Some Initial Thoughts

I’ve just started playing around with the Windows Phone 7 SDK. Here are some of my initial thoughts:

  • The Windows Phone 7 UX / UI tools make what’s available on Android and Blackberry look lame by comparison (Android’s UI tools: slim; Blackberry’s: none). In fact, I would even go as far to say that Microsoft Expression Blend is a more powerful design tool that Apple’s Interface Builder.
  • The overall UI itself is taking me some getting used to. It’s a little on the spare side for my tastes.
  • The simulator is rock solid. Love the fact that I can compile and test without restarting the simulator each time, and even if I DO have to start the simulator each time, it takes only seconds to start and not minutes (** cough cough ** android ** cough ** blackberry ** cough ** cough **).

I’m still wading through the documentation and working through the labs, but I have to say my initial impression is… very favorable.

I have yet to do anything substantive (create an HTTP connection, start a thread, download an image, cache / persist data, etc.). What I see so far is causing me to rethink whether Microsoft may yet have a chance in the “phone wars.”

Playing a Sound File in a Blackberry Java App

Playing a Sound File in a Blackberry Java App

Without a lot of undo fuss, here’s one way to play a sound file in a Blackberry Java app:

Class cl = null;
try {
cl = Class.forName("com.mycompany.myapp.MyAppMainClass");
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
if (cl!=null) {
InputStream is = cl.getResourceAsStream("/someSoundFile.mp3");
try {
Player player = Manager.createPlayer(is, "audio/mpeg");
player.realize();
player.prefetch();
player.start();
is.close();
} catch (IOException e) {
e.printStackTrace();
} catch (MediaException e) {
e.printStackTrace();
}
}

I usually create a package under the res (resource) package, name it sounds, and plop my sound files there.
Easy Peasy.

Hiding Blackberry Background Processes

Hiding Blackberry Background Processes

If you’ve ever developed a Blackberry app that has an Alternate Entry Point and runs in the background, you’re familiar with this typical scenario in your main application class (or something very much like it):

public static void main(String args[]) {

if (args.length>0 && args[0].equals("autostartup"))

{

MyApp app = new MyApp();

app.registerPushApplication();

app.enterEventDispatcher();

}

else

{

new MyApp().showGUI();

}

}

But wait a minute… how come I can ** still ** see my application’s autostart instance in the “Switch Applications” dialog?!?

This isn’t what I wanted.

Here’s the additional “secret sauce” you need:

First, declare a private global boolean in your main application class. I call mine (usually) _acceptsForeground and set it to false initially.

Next, in your main application class handle the UIApplication.acceptsForeground callback and code it like this:


protected boolean acceptsForeground() {

return _acceptsForeground;

}

Finally, in your showGUI() method (or whatever you call your analogous implementation) you need to add the following two (2) lines of code at the beginning of the method:

_acceptsForeground = true;

UiApplication.getUiApplication.requestForeground();

And that’s that. No longer will your application’s autostart instance appear in your task switcher.

The Alternative to the Blackberry Battery Pull

The Alternative to the Blackberry Battery Pull

Tired of yanking your Blackberry battery out when things go wonky?

Fear not, friends.

I have a tip.

There is a Blackberry equivalent to the Windows Ctrl-Alt-Delete three-finger salute.

Press the Alt, Right-Shift, and Del keys and hold them down.

It’s the little things, right?

A nice little BES / BIS “gotcha”

A nice little BES / BIS “gotcha”

A funny thing happened while testing today.

Well. It really wasn’t that funny.

Just strange.

I was testing a new Blackberry app to run solely over BIS and / or solely over BES.

And all hell started breaking loose.

JSON wouldn’t parse. Calls broke. Dogs and cats lied down next to each other.

After a little digging, I discovered that when an app makes calls over BIS or BES, there’s a good chance the data you get back will be a mixed stream of UTF-16 and UTF-8 data.

Not just a good chance. In my case, it ALWAYS returned mixed data.

Talk about your basic cluster smuck.

The fix turned out to be simple enough. I just had to set x-rim-transcode-content in my HTTP headers to none and voila! Problem solved. Nothing but good ol’ pure UTF-8.

I can’t imagine how many people out there are having this problem. Β But I hope this little “heads up” can save someone a little grief.

Blackberry BrowserFieldListener downloadProgress

Blackberry BrowserFieldListener downloadProgress

The downloadProgress event for BrowserFieldListener never fires.

Let me repeat.

The downloadProgress event for BrowserFieldListener never fires.

So, this is causing me to put together a dirty hack. And it will work.

But once again, spending development time to fix documented Blackberry “features” that simply don’t work.

Like isFocus.

And now, downloadProgress.

The Blackberry NullField

The Blackberry NullField

If you’ve ever perused the Blackberry Java documentation on a Friday evening (and who here hasn’t?), you may have come across the NullField.

NullField is a field that has no dimension, can’t be set in any meaningful way, and you can’t see it on the screen.

What the hell good is it for?

Well. This.

One of the annoying things you may have noticed when declaring a long LabelField (say, longer than the height of the screen) followed by some element that can take the focus (a TextEditField or a ButtonField), the user doesn’t get a chance to see the top of the LabelField.

Worse, they can’t scroll up and see it.

Some people resolve this by making the LabelField a RichTextField (so that it can accept the focus and can scroll).

Ah. But this is what NullField was designed for.

So that you could stick a NullField at the very front of a screen that would never be able to get the focus, and start there with the focus.

NullField is not the perfect solution. For example, scrolling is not smooth from visible focusable elements to hidden focusable elements. But at least you can set focus at the beginning (or the end) of long screens that otherwise have no elements that can be focused.

I can’t really understand why one can’t simply scroll all of a screen that is painted, regardless of whether the elements can have focus.

I know, right?

You just can’t.

So just use NullField and stop griping about the Blackberry SDK. Again.

Keeping up with the Joneses

Keeping up with the Joneses

Gowalla has just implemented a new set of API calls for checkins.

Facebook is reportedly also very close to have a set of location specific API calls available soon.

Is Location in 2010 the Augmented Reality of 2009?

Feels like it.

GPS Best Practices for Blackberry: First, Don’t Use GPS

GPS Best Practices for Blackberry: First, Don’t Use GPS

I’m approaching the half-way point on a new Blackberry Project that is heavily dependent upon location services for basic operation.

Having just completed work on an iPhone version and an Android version of the same application, one would think that there shouldn’t be any surprises third time ’round.

One would be wrong.

If you’re using the Location Manager for Blackberry, and you intend to use the device outdoors, everything is copacetic.

If, however, you intend on using GPS and Location Manager inside… well, let’s just say you better think again.

Doesn’t work. Can’t work. No line of sight to at least three GPS satellites.

All is not totally lost; provided you simply give up trying to use GPS on Blackberry.

What is a developer to do, then, that needs – desperately – to use location based services on Blackberry?

The answer is that you have to do what Google Maps does; namely, use the nearest cell tower and local area code to determine location.

In the next day or so, I’ll include sample code for pulling this little feat off.

The bad news is that you lose the promise of the accuracy of true GPS with this approach. But the great news is that this approach will always work, provided you have a cell signal.

Stay tuned.