06-13-2012 02:11 PM
A few comments, mainly wrt the post from br14.
Alec Saunders is not from QNX:
"QNX is/was not a consumer products organization... "
Agreed, but then with respect to development on BB, I think the QNX people have had very little involvement. If you look at the development environments, the only one that was potentially lead by QNX people is the native SDK. HTML 5, WebWorks and Adobe Air seem to be lead by RIM employees, and of course Cascades is TAT (now RIM). So I'm not convinced that this is the explanation for the strategy.
I still think RIM can turn this to their advantage. For years they (and we) have been working hard to compete with an old architecture against the new comers. Now they have the potential to be the new comers using the latest technology. This could well work, providing the phones stand up to the competition. Time will tell.
06-13-2012 03:00 PM
"Alec Saunders is not from QNX:"
Alec Saunders was VP of Marketing at QNX. No doubt his Linked-In profile is part of his marketing approach :-)
Don't get me wrong, I have no problem with QNX executives doing what comes naturally. And the current strategy may work fine. My point is that it was the wrong strategy last year.
They have allowed negativity around legacy BB OS to cloud their strategic decision making and focussed on BB10 as if it were some kind of saviour of the company. That is far too much expectation no matter how good the devices may be.
Whether he initiated the strategy or otherwise, my guess is Dan Dodge is now the defender of this strategy as the Chief Software Architect and the original owner of QNX.
RIM's real problem developed over the past 5 years toward the end of the demand explosion for their devices. They expanded costs too quickly and profit margins were severely damaged by those increasing costs. That at least is clear from their financial reporting. Prior to that they were doing fine with excellent margins. Most of that reduction in margin had little to do with the iPhone (Android with its far lower cost base is todays problem).
However brilliant BB10 devices are, RIM will still generate most of its revenue from BB7 and related devices for at least 2 or 3 years (possibly longer) until the unit cost of manufacture of BB10 components reaches the point where they can sell a BB10 Curve for $200. BB10 may fend off the "RIM is out of date" press, but I doubt that will impact sales all that much. I hope I'm wrong.
Don' t make the mistake of thinking "compete with an old architecture against the new comers". That's the message Apple and Google have been pushing with considerable success. BB7 devices compete well in terms of their primary functions.
RIM's apparent demise in North America and elsewhere in the developed world is because Android phones cost less and make more money in data charges for carriers. Until that scenario changes (hopefully by next year if data capacity becomes a problem) RIM will continue to be in trouble in NA because the carriers would prefer to sell an Android device over a BlackBerry unless the consumer insists. Most consumers don't know the difference and will take what they're sold.
As techies we tend to see the world through our eyes. Just ask an older (non-tech) relative which phone is best and see what they say! (More to the point, see if they even care).
06-13-2012 03:20 PM
I see really much interest on Java for BB10 from people that some months ago told me that I was a java fanboy just
because I was saying that RIM has done many errors but the biggest one is to abandon Java.
06-14-2012 03:13 AM
06-14-2012 03:44 AM
With 50MB you can do magicians, I worked in a big android project for a bank in my country and I can
tell you that we realized one of the most compelling software of the market using OpenGL, SVG and Java2D,
our heap remains always over the 50MB with the correct object manipulation. The software is huge.
06-14-2012 09:03 AM
I don't understand why people would have liked RIM to continue with BB Java developement on BB10. They had to move to something efficient. The involvment of QNX guys has been monstrous, they've made a powerful OS.
And what about Data binding, MVC, continuous integration, Animations,... with former BBOS?
06-14-2012 10:04 AM
06-14-2012 10:11 AM
Supporting BB-Java (j2me+extensions) = too much efforts + licensing fees for Oracle (who bought Sun)
Supporting Desktop java (j2se) = you already have it via Android player. Most of code that runs under jdk 1.6+ will run under Android player. Plus, if you code right, you can have part of Java code shared between BBBOS 5-7 and java code for android player. Abstract view from model, use MVC pattern (model-view-controller) and limit you java language level on jdk 1.2
06-14-2012 10:18 AM
06-14-2012 03:11 PM
Hithredin, you misunderstand me.
There are actually two points:
Supporting BB-Java (j2me+extensions)
Supporting Desktop java (j2se)
The first would have been nice as a player, just to be able to migrate applications to the new system. If developers would have used it for new applications that would be up to them, but a real desktop java would be something completely different.
A J2SE java runtime plus BB10-lib would allow java developers to continue developing, and opening the system to lots of new frameworks etc as well (hibernate etc etc).
As a random thought, maybe they do not want to fragment the system UI-wise? They have BBUI.js for the html5 people and cascades for the c++ crowd, maybe a similar looking java UI was too difficult?
You are a recognized expert and I know it, I estimate your posts here, so please don't missunderstand my posts but how an expert like you can talk about framework like hibernate in mobile applications?
Do you really think that hibernate has some sense on mobile apps? MVC design pattern is completely different in mobile ecosystem because we have an additional layer. You can use the MVC pattern on mobile but you have to abstract to an higher level and you need a server side counterpart.
Leave hiberante, struts, spring and other framework, web services to the server side part please.
JSON and XML is only you need on mobiles for heavy persistence and other server side jobs, no need for additional server side framework on mobiles.