Hacker News Reader

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.

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.

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