The Cost of Building BlackBerry Apps | Hacker News Reader

The Cost of Building BlackBerry Apps

spin.atomicobject.com

20 pointsfogus11 comments

Everything in this post is inline with my experience working on the platform over the past 10 months.

But they miss one of the worst offenses in my opinion: Applications which access certain APIs are required to be signed. If you want to run code on the device you must sign your app, even if it's just for testing during development. The signing process requires connection to THREE different RIM servers, which are notoriously flaky. This results in extreme delays (hours) which are hard to account for while developing. RIM has recently upgraded their servers or otherwise addressed this issue, but it is far from solved

Take a look at the 7-day (the times are mislabeled, I believe) charts on this page, set up by a third party, not RIM, for an example of their uptime: http://isthesigningserverdown.com/beta/

Money quote:

"BlackBerry code must be compiled at the Java 1.3 level. This means that developers cannot utilize any of the improvements made to Java since 2002"

> "Common utilities such as java.util.ArrayList and java.util.HashMap are also not available."

I've never written anything native for BB, but have done some webapp development (holy usability nightmare Batman! Their browser is horrific in a level that even IE isn't)... but this revelation is scary.

Being forced to write Java 1.3 is like digging a trench with a rusty old spade.

Being forced to write an app without java.util.ArrayList and java.util.HashMap is like digging that trench with your teeth.

Note that starting with the torch bb's have a webkit browser.

Yeah, that was an "about damned time" thing. What's the word on the non-touchscreen BB's though? Are the new ones sporting a WebKit browser?

Anything that runs OS6 has a webkit browser. I believe thats everything starting from the 9700, but official 9700 OS6 builds are probably a looong time from coming.

I think the best point made by the authors is that creating native apps is often avoidable, regardless of what OS you might develop for. Often a website optimized for mobile devices would more than suffice, and would also avoid the proprietary pitfalls of developing for just one OS.

When there's no concrete need to use a device's native abilities, it's foolish to waste time creating a proprietary, limited utility browser for just one device. Even if that device is running Android or iOS.

The question is, does it even matter? RIM's customers are business, who don't really care about the access to apps, but whether they get fired for choosing the wrong brand. And nobody gets fired for choosing RIM.

RIM can't keep a stranglehold on having decent Exchange integration forever. Many corps already want additional tools to use on the BBs than just exchange integration. You'll have stuff where people want to be able to check inventory for anywhere, hook into the company ordering/ticketing system, whatever. And they're willing to have these apps developed for them (usually in house).

Whenever RIM loses their edge in exchange integration, if corporations ability to create custom apps is still crap, then it'll just be inertia keeping them as the 'not wrong' brand. And that inertia will fade.

As it stands now, I've seen two corporate teams developing BB apps for two companies from a distance. And it sounds painful. I mean, just running the simulators is kinda painful. I swear that the simulator can take longer to boot than the actual handhelds sometimes.

> I swear that the simulator can take longer to boot than the actual handhelds sometimes.

Agreed.

And the devices need to be rebooted for totally trivial things like changing security settings or deleting apps.

Nobody ever got fired for choosing IBM...

Nobody ever got fired for choosing Microsoft...

Nobody ever got fired for choosing RIM...

Notice a pattern? Taking the "safe" bet is fine for a while, but nothing stays the same forever. Businesses who take advantage of new technologies gain an advantage, not only in the technology department, but in the staffing department. Smart, driven employees want to work at a place where the tools are interesting and current. Burying your head in the sand and reciting, "business users don't care about apps", is about as wrong-headed as sticking to the AS400 platform for new development in the nineties.

Reply on news.ycombinator.com