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?"
Re: (Score:3, Insightful)
Re:Crack (Score:4, Funny)
did you know that the US and Canadian versions of the Z10 are different? In the US it's the zee 10 and in Canada it's the zed 10. Amazing!
Re: (Score:1)
The zed 10's dead baby, the zed 10's dead.
Re: (Score:1)
In a month and a half in the US and 5 months in Canada. The iPhone 4S did that in its first day and the iPhone 5 did 2 million its first day.
The Q10 will be the true metric though. There are a ton of people out that that have been waiting 2-3 years for the next physical keyboard phone. Q2 should be a good one for BB. However, once that initial flood comes through...
Re: (Score:1)
Correct, volume isn't always everything. However, that is only the case when there are large differences in profit margin. In this case, there isn't much difference. The Z10 (which I've used a little bit, not every day) is an average device these days with some neat features. Nothing earth shattering. Its as average as an iPhone or any number of Android devices. The sales however, have been disappointing. The largest factor, is that without any large distinguishing feature, most people have already m
Re: (Score:1)
Blackberry doesn't have idiotic users waiting in line, throwing their old phones in the garbage just to have the new shiny each year because of some software based feature (that's been available on it's own store for every single one of their devices but apparently it's just too difficult to update and so it's arbitrarily restricted to the last 1 or 2 generations of devices.
Re: (Score:2)
Given that no-one is admitting to that purchase, is it beyond the realm of belief that they brought those themselves?
Re: (Score:1)
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
I can only speak for myself here. I ported my (fairly successful) app to Windows Phone. My reasoning was that MS was big enough, and Nokia committed enough that they would do whatever it takes to make WP work.
It was a very bad use of my time, I get a bit of cash from WP, but it is a rounding error compared to iOS, or even Android.
It may be that Windows and Nokia will do better in the future, but for now, it is an unrewarding platform.
Blackberry have spent a bunch of time trying to convince me to transfer my
Re: (Score:1)
There are 80 million BlackBerry users and growing. You don't think you can sell even a few hundred copies out of 80 million users? Even if you make 10x more money on other platforms, it never hurts to add an extra few % to your bottom line.
Re:Garbage. (Score:5, Interesting)
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.
Re:Garbage. (Score:4, Insightful)
Being consistent with the API is more or less meaningless if you've only got a few dozen users.
Re: (Score:1)
Having a few thousand users is meaningless if they don't pay for you using the API. Blackberry users have consistently shown they have money and are willing to pay for quality apps and games.
Re: (Score:2)
A few thousand? Developers don't seem to be having any trouble making money on Android and iOS even with free games. And the good games tend to have a much larger number of people playing them.
Sure it isn't like the early days of the platforms where it was basically just printing money, but there's still plenty of money to be had if you're providing something that people want.
Re: (Score:3, Insightful)
It's funny, a study last year from Evans Data Corp (surprisingly?) showed that BB developers earned significantly more than their iOS and Android counterparts -- with a full 13% netting over 100k.
To your comment, a consistent complaint from Android developers is how difficult it is to make money on the platform. You can see this reflected in the results of the earlier mentioned study.
For the big-name players, BB might not be as attractive. For small and medium sized shops, however, targeting BB10 is clearl
Re: (Score:3, Informative)
Source Link for you [yahoo.com]
Same study also found that "Android Market" was the most used, so it's attractive for volume (once your app is actually visible on the play store--as noted in the link I provided, that's the largest complaint about it).
Re: (Score:2)
Erm... That says the study polled 400 commerical developers. In a random sample of commercial developers I'd be surprised to find a more than 1 Blackberry developer. Lets be generous and say there were 8. What significance then is "13% earn over $100,000? It means one developer earned over $100,000. Statistical significance? None.
Now, was it one of these surveys where they get a list of telephone numbers, and ring them up and ask if they'll cooperate with a survey? Or was it one of those ones where you g
Re: (Score:2)
I thought some of the same things. I haven't bothered to sign up with EDC to see the details, so I'm not personally sure at all about the details of the study. I just thought I would at least provide a source for the data narcc posted.
Re: (Score:2)
Also, that article is from September, 2011... more than a year and a half ago. So how valid is that still today? I didn't find a nice chart for BlackBerry's market share in a quick Google search, and I would think that would be a relevant thing to look at in this. I did find that it was dropping after this article, and reached its lowest in February of this year. If BlackBerry's market share kept decreasing since then, however, it would be a safe hypothesis that app developers probably weren't making as muc
Re: (Score:1)
Depends on how much those users pay you.
Re: (Score:3)
It depends on who those users are. Believe it or not, not every "app" developer is trying to create some consumer-level app that reaches millions and millions of people. I own plenty of software from companies that may have only a few hundred customers, but they're doing just fine. Not every successful business has to cater to all people In fact, some of the most profitable businesses I know don't cater to
Re: (Score:2)
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.
That depends entirely on what "the same APIs I'm used to on the desktop" means.
iOS includes large chunks of the Mac APIs, making it a great fit for Mac developers. Even if you aren't a Mac developer, you get all the C/C++ chunks. I'm pretty sure there is even a build of Qt for iOS. And if you're a Java developer? Blackberry might as well be another planet compared to Android.
So again, your definition of "new" API varies depending on where you are coming from.
Re: (Score:2)
your definition of "new" API varies depending on where you are coming from.
Yes, of course. I think iOS is good in this respect.
Android, no. Java isn't the native API for anything, and Android's flavor of Java isn't the same as the other flavors of Java. Having said that, it's obviously a viable platform.
Most other smartphone OS announcements start out by saying "you will develop in HTML and JavaScript", and at that point I stop listening to anything else they have to say. While these APIs are universal, they really aren't good for developing applications in.
Re: (Score:2)
Re: (Score:2)
The C standard library is insufficient for writing real user level applications. It is more for low level applications, systems programming, or simple non-graphical applications. Have fun with your CLI smartphone.
If the platform provides additional C libraries to interface with their device you have already lost the "universal" part of the requirement.
Re: (Score:2)
Android, no. Java isn't the native API for anything, and Android's flavor of Java isn't the same as the other flavors of Java. Having said that, it's obviously a viable platform.
True, but if you're a Java developer, what's going to look more familiar: Blackberry's barely OOP C, or Android's Java-like API?
Re: (Score:2)
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.
Yeah, it's pretty ridiculous that in this day and age cross platform software developers like myself have to create an OS Abstraction Layer to get their stuff to port programs. I mean, OS's are supposed to BE the Abstraction Layer. Ugh. However, in most cases (Linux and Unix being exceptions via POSIX), the proprietary vendor thinks its in their best interest to create incompatible APIs and leverage vendor lock-in. Sometimes it's just out of sheer ignorance though, other times malice.
Re: (Score:3, Insightful)
My opinion is like this, but less antagonistic. Developers go to three places as far as APIs are concerned:
#1. Where the money is. Sorry blackberry you missed that train. iOS or android is going to be far better in that regard.
#2. Where it's fun. Something about business oriented phone software doesn't call me in that regard.
#3. Where it's really, really, really easy to whip out applications. Maybe, but I doubt it.
Re: (Score:3)
Someone mentioned this above, but part of the problem with assuming BB missed out on #1 is in assuming that there's only money in greater market share. Remember that Blackberry's niche is more business than consumer. If someone can come up with an app that's attractive to business they can charge more, making up for the lack of market share.
It's similar to a discussion that cropped up the other week about the cost of medical software. It can often cost 10's or 100's of thousands of dollars because of a smal
Re:Garbage. (Score:4, Insightful)
It's pretty hard to make money selling $0.99 games on Android too when you're up against hundreds of other games being released per day.
Most of those games are crap, or fun but unpolished hobby projects, but some of them are serious and polished with hundreds if not thousands of man-hours of development gone into them. I suspect few of them come close to recouping their team's time investments even when you consider that many of the teams are working out of India and other countries with similar income levels. There are plenty of fun, quality games with fewer than 100,000 downloads of the free version and fewer than 1000 purchases of the paid version, which means the devs can't have made much more than $2000 on the market, less when you subtract Google's cut and even less when you subtract taxes. A team of, say, three Indians can't live six months on that.
Developing a game is a long shot on any platform unless you're a studio with a proven team of good developers and designers and marketers.
Re: (Score:2)
My opinion is like this, but less antagonistic. Developers go to three places as far as APIs are concerned:
#1. Where the money is. Sorry blackberry you missed that train. iOS or android is going to be far better in that regard.
And surprisingly you (and most everybody else) would be wrong [yahoo.com]
#2. Where it's fun. Something about business oriented phone software doesn't call me in that regard.
#3. Where it's really, really, really easy to whip out applications. Maybe, but I doubt it.
If you know C, C++, QT, HTML5, [html5test.com] Adobe AIR, or JAVA you can code for BB 10. [blackberry.com] If you don't want to code for BB 10 specifically but you already publish apps on Android it doesn't get much easier than uploading an APK [unker.net] (yes there are limitations)
Re: (Score:2)
I agree with your point, but would perhaps add a few extra bullet points.
#4. Where they already are. Tons of young coders started writing software for whatever type of computer was available in the living room rather than any rational assesment of which platform had the best dev tools. Tons of people will be handed blackberries by their corporate overlords, and have an itch to scratch. Those people already have full time jobs, so they won't be as prolific as full time mobile developers, but a lot of use
bad_management() (Score:1)
Is the API that includes bad_management() public or private? Either way the return value is doomed
Re: (Score:3)
Bad management is always protected. You can get at bad management when you inherit from Bad Management.
Re: (Score:2)
. . . if only there was a way to deprecate it . . .
So where is the customer demand? (Score:4, Informative)
Our mobile app, we have built native for Android and iOS. We've had a grand total of one person ask for BB and one ask for WP8. We simply have no interest in investing the money to build for something no one cares about.
Re: (Score:2)
If BB pitch is to corporate clients (still) - how do they plan to attract all these devs who certainly don't care about the enterprise and much, much smaller target market.
As I understand it, a large fraction of Android apps can be ported over in binary form, so even end-users can do so.
Re: (Score:2)
Really want this to suceed (Score:5, Insightful)
I really want this to succeed. First of all, QNX is awesome. I had the pleasure of working with it back in the day when they had the 1.44M demo disk [toastytech.com] (http://www.youtube.com/watch?v=K_VlI6IBEJ0 has a video). At a time when GNU/Linux was working on getting POSIX-compliant and X was clunky and required some expertise to set up, QNX offered an OS with POSIX-compliance, real-time capabilities, a package manager, a GUI that worked out of the box, and managed to produce a 1.44M bootable diskette that showed off the OS with GUI and web browser.
Secondly, I want my software to be efficient. I'm sure you can do great things with J2ME, Dalvik, or even HTHL and JavaScript. But if you want the best performance or resources are at a premium (hello, battery-powered mobile devices!), you can do better by being closer to the metal. And we have APIs and programming languages that allow us to program closer to the metal. BlackBerry allows us to use those APIs and languages. The author of TFA makes fun of the BlackBerry APIs being in C. I see that as an advantage. You can easily build abstractions on top of low-level APIs. Getting efficiency back once it's been lost in someone's abstraction layer isn't as easy.
So, while it seems popular to make fun of BlackBerry these days, I really want them to succeed. I think they've made a great product that deserves our consideration. Of course, they have low market share and strong competitors - but then again, so did Apple when they launched the iPhone, and Google when they launched Android.
Re: (Score:2)
Yes, we all want our mobile apps to be efficient, but please don't lump Davlik in with javascript. I concede that Java/Davlik are not quite as efficient as native code, but running an Android app on your phone is not in the same league of inefficiency as using a web app.
While I admire Google's continued to push to improve and promote the web, their continued insistence that web apps are the future even for mobile - in spite of Android doing so well - seems crazy to me.
Re: (Score:1)
This is true on the desktop with big fat caches and CPU cycles to burn. But JIT on mobile has a long way to go yet. Most things on mobile run interpreted mode only, maybe you can not tell the difference? because it is fast enough.
Qt (one of the APIs of the BB10 platform) does do well to make C++ difficult to write code that crashes easily.
Re:Really want this to suceed (Score:5, Informative)
First of all, QNX is awesome.
It is. It's a real-time microkernel based OS. The kernel is about 60K bytes. All it does is manage memory, timers, and message passing. Everything else is in user space. There is a hard upper bound on interrupt lockout time, and it's around a microsecond.
This is what you want to control complex real-time systems that need tight coordination. All the Boston Dynamics robots, BigDog, ATLAS, etc. run QNX. The servo loops are running at 1KHz on those robots. Tight real-time coordination of all those complex motions requires a true real-time OS. (The robots that run ROS/Linux are more sluggish.)
But, after totally botched marketing, the death of the main designer, two sales of the company (to Harmon and then RIM), and transitions from closed source to open source to closed source to open source to closed source again, QNX, the company, has blown it.
None of this has any bearing on smartphone sales. They're not a hard real time problem. You could write the entire UI in HTML/CSS/Javascript and it would work fine on current processors.
Re: (Score:2)
That's what I was thinking. I was a sysadmin at a small EE firm building testing stations. All the CNC systems we built that had to be extremely precise and relied on the high end microcontrollers and actuators invariably ran QNX. The systems that could be cheaper and less robust overall tended to run National Instruments controllers with LabView applications on Windows XP, which were cheaper both to develop and to deploy.
Re:Really want this to suceed (Score:4, Interesting)
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.
Re: (Score:2)
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.
You're not supposed to do much in a QNX interrupt handler except activate a thread to handle the event. I've written hot-plugging support for FireWire and USB devices, which is much easier to do when it's done in a user process.
You take about a 10%-15% performance hit for extra context switches and message passing. But it's all constant-time overhead. You don't have all those things that cause monolithic kernels to stall.
Re: (Score:2)
Re: (Score:2)
You could write the entire UI in HTML/CSS/Javascript and it would work fine on current processors.
Just after I wrote that, it's demoed. [slashdot.org]
Re: (Score:2)
Of course, they have low market share and strong competitors - but then again, so did Apple when they launched the iPhone, and Google when they launched Android.
Apple and Google both succeeded for different reasons. Apple succeeded because they introduced a revolutionary device. When everybody else was moving to full QWERTY keyboards and sliding form factors, Apple went with a single, simple, touch screen. They effectively created a completely new segment of the phone market for themselves. That, coupled with Jobs' reality distortion field, launched the iPhone into history.
Google saw Apple's stragglehold of this new market, and decided they wanted a piece of that m
Re: (Score:1)
"Apple and Google both succeeded for different reasons. Apple succeeded because they introduced a revolutionary device. When everybody else was moving to full QWERTY keyboards and sliding form factors, Apple went with a single, simple, touch screen. They effectively created a completely new segment of the phone market for themselves. That, coupled with Jobs' reality distortion field, launched the iPhone into history.
Google saw Apple's stragglehold of this new market, and decided they wanted a piece of that
Re: (Score:2)
First of all, QNX is awesome
That will not get you a user base. You need to add Bling.. lot's of big fat, cpu grinding Bling. Users want Pretty and they want it Fast. .. a few poniez on the wallpaper selections help too. I'm not kidding.
UI (Score:2)
Re: (Score:2)
It's a programming API. This obviously means that RIM will let people make assemblers, compilers, and interpreters that compete with the likes of C, Objective-C, Python, and Scratch. ;)
When is BB10 coming out for playbook? (Score:1)
Their tablet is really fast and slim but with no update to BB10, devs can only port older droid apps (from what I understand 2.3 and older) Comon bring out BB10 for the PB.
Re: (Score:1)
Blackberry's CEO says Tablets will be dead in 5 years so that is not giving me the impression that supporting their aging tablet is something they'll put a priority on.
The other issue is the Playbook specs. Seems the processor and memory in the Playbook are below those of the Z10 so some fear the BB10 Os may not run very well on the Playbook.
I do hope I am wrong as I am also a Playbook owner and quite happy with it.
Re: (Score:3)
Supporting Obj-C isn't much good unless they also have Cocoa-Touch.
Blackberry - Enemy of Open Source (Score:1)
Apps?? (Score:2)
Pundits keep saying this (over and over and over), but I tend to disagree. I and everybody I know who have Windows Phones generally don't see "apps" as a problem. Personally, there aren't any "apps" that are a deal breaker for me, because I use my phone for business. Games and "apps" are for the laptops.
Re: (Score:3)
The Nokia N9 had built-in terminal and SSH, though I think you had to activate developer mode before the icons showed up on the home page.
Re: (Score:2)
There's productivity apps though. You SHOULD be able to find almost anything you need for all iOS, Android and Windows Phone at this point, but the quality differs widely.
On tablets, you have Penultimate for iOS for example. I'm an android user. We have semi-equivalent apps, but none are as good.
Exchange support: On Android, the best one is Touchdown. It works, but it looks like crap, and drains battery like crazy. The Windows Phone support is better (amusingly enough, not as good as Windows Mobile was thou
Even most BB developers won't use these. (Score:2)
Compatibility is a two edged sword. Being able to easily port Android apps makes that the easy path - develop for Android, still get BB support.. why would you bother writing for the BB API? That means your platform gets more apps to start, but very few unique ones - and many that don't make best use of your unique features/APIs.
No (Score:2)
Long answer: NO.
Cross-Platform (Score:2)
BlackBerry support QT4.8, and 5.0 can be compiled. Digia (who now own QT) have ported it to Android and IOS, with Win8 on the horizon.
Finally, portable C++ apps.
And if you prefer something standards-compliant, you can code in HTML5 and embed that as an app.
Btw if you you do create web apps, BlackBerry own and develop the Ripple emulator.
What's not to like?
criteria shifts (Score:2)
"But what really makes or breaks a phone is the quality (and quantity) of its third-party apps."
Oy, this makes me feel really old. I remember when what made or broke a phone was its ability to make and receive calls well. What's worse, maybe, it's what I still select phones by.