Comment by tmountain | Hacker News Reader

Comment by tmountain | Hacker News Reader

As someone who did Blackberry development professionally for the better part of a year, the sentiments on developer friendliness really resonate with me. Working alongside iPhone and Android developers, I truly felt like I'd been relegated to working with stone tools.

As a prime example, making a network connection is a black art using their SDK, and every developer ends up rolling their own connection manager to do so. If you join the Blackberry Internet Alliance (~$1,200 a year IIRC), they'll make this easy on you by letting you use BIS (Blackberry Internet Service). This is ridiculously constraining when it comes to creating useful apps.

Another major point of pain is their code signing tool. To produce a build that's deployable to a device, you have to sign the COD file using their remote code signing server. The server was down almost daily leaving me dead in the water during critical testing periods.

Lastly, if you decided to make use of certain API facilities like persistent storage, a device reboot was required after every deployment. Given a five minute reboot time on many devices, this could consume an hour or more each day of my dev time.

I'm not sure what RIM's future plans are, but making things easier on developers would definitely be a step in the right direction if they want to remain viable.

I have been developing for the BlackBerry platform for years and have found it very very good. Some things like the signing server can be annoying at times. There are many great things however. RIM provides all kinds of simulators that make it really easy to test out your apps on all devices. So you don't have to even purchase separate devices for testing like on Android or the iPhone. I only do final sanity tests on physical devices.

Your connection information about 2-3 years out of date. That was the old days. They have a transparent connection factory now which makes opening connections pretty easy. You can even transparently route over WiFi, etc.

I think that in the focus to make the newest, shiniest app many people in the developer community are overlooking a key thing. BlackBerry brings you users with a LOT of software purchasing power. Not just people but whole organizations. That crowd is used to spending big $$$ on software. And if it means waiting a little for the code signing server to come back up or schedule my builds outside of regular office hours, this is a sacrifice that I would gladly make. It pays off, quite literally.

Don't the emulators from Apple and Android let you test on various virtual devices too?

And if it means waiting a little for the code signing server to come back up or schedule my builds outside of regular office hours, this is a sacrifice that I would gladly make

Sure, fair enough, but that's a really bizarre thing to have to sacrifice in the first place. I hate to make assumptions about other's infrastructure, but I'm having a hard time seeing how this could be a problem that persists for months or years.

It honestly hasn't been that much of an issue for me. Sometimes the server is down for a few minutes, an hour max but then things are back up and running quickly.

The signing server is part of RIM's security system. It basically allows RIM to control the quality of applications. For example, in any software that proves malicious will get their developer's key instantly revoked - and the server won't side that developers applicaiton. Malicious apps can be instantly revoked by ALL device simply by putting that developer's certificate on a blacklist and pushing it down to all devices.

To do security like this, you need a chain of certificate signings and a controlling server.

And enterprises love security like that.

Ah yes, I'm well acquainted with the simulator. Unfortunately, the reboot time was on par with that of a physical device which lead me to the drastic measure of snapshotting a running simulator inside of virtual box since I could boot virtual box in 20% of the time it took to start a fresh simulator.

The simulator is also throttled to a paltry 10k/sec when performing network access (why?!), and the app I was working on was for music streaming which forced me to do most of my testing on physical devices.

Regarding the connection factory, I was aware of it; however, given the market share of older devices, it makes sense to support them. If you're going to do so, you're going to have to roll your own connection code since older devices can't use newer OS versions. I'm not talking about ancient devices either. The Curve 8900 shipped with the 4.6 which doesn't support the connection factory.

In our case, it didn't make sense to have two builds (legacy and modern) since we'd have to support legacy anyway. I suspect this will improve as the older devices disappear by way of attrition, but it made things difficult at the time.

Regarding the people willing to spend money on software, we never applied to get into the marketplace; however, all of RIM's competitors have similar offerings, so I see no advantage here.

The simulator has had the ability to reload an edited and recompiled app without needing to do a full reboot. This feature has been there for about 1.5 years (if you count the beta period).

Good points on the older OS 4.6 devices. Right now we have something like 95% of all app purchases done from OS 5 and OS 6 devices, so going back to OS 4.6 has not been considered worth it for many developers for some time now. I do it just to be nice to my users but I get less than 2% OS 4.6ers coming in.

In general RIM has been really good at pushing users to upgrade their devices so in practice you would see most 8900 buyers come out with OS 5 on their device.

>You can even transparently route over WiFi, etc.

Um...that's not exactly a ringing endorsement of the platform; on any OS with a modern network stack (Android, iOS, Windows 3.x...), the stack hides the details of what hardware you're connecting over.

I know, but it has been like that since BlackBerry OS 5 which came out years ago. It is the older devices especially the ones that came out way before the iPhone did that don't have this ability.

When people are faced with that kind of development pain, why don't they write their own platform on top? I mean, it seems like e.g. PhoneGap has done that, so there's no contractual reason not to, right?

It seems like if you wrote the bulk of your app in an interpreted language, you could zip new code updates over to the device as fast as your network lets you.

Building middleware hinges on the notion that your platform has enough spare cycles to execute your middleware.

iPhones can, Androids can... but have you seen the level of performance on a BlackBerry lately? I'm not sure if there's enough power under the hood, or enough performance in the OS, to run an interpreted layer on top.

Man, interpreters date back to the 1950s, if not the 1940s. There's always some stuff that needs to be compiled, and other stuff that doesn't, but the stuff that needs compiling gets smaller and smaller every year.

Reply on news.ycombinator.com