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.
I’ve just started playing around with the Windows Phone 7 SDK. Here are some of my initial thoughts:
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.”
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.
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.
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 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.
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.
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.
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.
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.
