Follow Slashdot stories on Twitter


Forgot your password?

An Exploration of BlackBerry 10's Programming API 100

Nerval's Lobster writes "BlackBerry 10 is completely different from previous BlackBerry operating systems — with good reason. Its core assets come from a company named QNX, which Research In Motion acquired in 2010. Blackberry 10 features include 'live tiles' that dynamically refresh with new information, as well as a revamped keyboard and security upgrades. But what really makes or breaks a phone is the quality (and quantity) of its third-party apps. Jeff Cogswell pokes through the BlackBerry 10 programming API in a quest to see what app developers can do with the platform, and how it compares on that front to Apple iOS and Google Android. His conclusion? Although some of the underlying components are showing their age, BlackBerry has 'spent a lot of time building up a foundation for a good development community.' He also goes over BlackBerry 10's viability for porting apps and building games. But will developers actually work with a platform with such low market-share?"
This discussion has been archived. No new comments can be posted.

An Exploration of BlackBerry 10's Programming API

Comments Filter:
  • Re:Garbage. (Score:5, Interesting)

    by inglorion_on_the_net ( 1965514 ) on Wednesday May 01, 2013 @02:16PM (#43602571) Homepage

    This is exactly the reason I haven't learned Android development. Why have me learn new APIs for old things? Give me the same APIs that I'm used to on the desktop to the extent that these are compatible with the mobile environment, and then I'll learn the APIs that are specific to the niche I'm developing for. And that's exactly what BlackBerry has done.

  • by Just Some Guy ( 3352 ) <> on Wednesday May 01, 2013 @07:04PM (#43605121) Homepage Journal

    On paper and in source code QNX is amazing.

    In reality it was a little "meh". RTOSes are amazing when you need them, but those low latencies come at a cost of lower throughput and higher kernel overhead. Basically, context switch counts go through the roof anytime anything interesting at all is going on. The gist of it is that you can't write a big, sophisticated interrupt handler; you have to break it up into tiny evented pieces that can return before the hard deadline expires. That has lots of design implications.

    Contrast with an end user OS where the price of too much latency is that screen refreshes aren't as smooth as they could be. The kernel can wave that away on modern hardware by making timeslices sufficiently small that no app gets to use so much CPU that others are greatly affected.

    I have nothing against QNX! It's a great OS for its niche. I have zero desire to use it as a client OS, though, because its advantages aren't significant enough in that problem space to outweight its considerable disadvantages.

Matter cannot be created or destroyed, nor can it be returned without a receipt.