Slashdot Mirror


With BB10, RIM Tries To Break Out of the 'Mobile Ecosystem' Model

Alt-kun writes "This past week has seen a couple of interesting articles about Research In Motion's strategic plans for BlackBerry 10. The Globe and Mail thinks that by pushing HTML5 for app development, they want to make mobile applications platform-neutral, which would let them sell devices purely on the strength of the hardware and OS, rather than on the ecosystem. And the Guelph Mercury notes that they also plan to push BB10 as the basis for a whole range of mobile and embedded devices, not just phones and tablets. One example shown off at the recent developer conference was a Porsche with a BlackBerry entertainment system."

33 of 143 comments (clear)

  1. Why HTML5 apps suck on mobile by WhiteArmor · · Score: 4, Informative

    Native apps will always work better and be less resource intensive than HTML5 based apps. You will never be able to match native code or get even close. Even Google understands this on mobiles, even though they still use the crappy Java. This is especially important on mobile phones not only for limited CPU and memory and the lack of good GPU, but because battery life is really important and already not that great.

    RIM just wants to do this because they don't have the vibrant app economy than Apple and even Microsoft has. They want others to do the work for them.

    1. Re:Why HTML5 apps suck on mobile by redemtionboy · · Score: 2, Insightful

      " even though they still use the crappy Java"

      I was going to award you some points, and then I read that. Now I dislike you.

    2. Re:Why HTML5 apps suck on mobile by Anonymous Coward · · Score: 3, Insightful

      Learn a modern language and your irrational love for Java will just fade away, fade away.

    3. Re:Why HTML5 apps suck on mobile by R0UTE · · Score: 2

      The same argument holds for any platform. A native app will always be quicker. One of the advantages of web apps in any scenario is the ease of cross platform compatibility. In the mobile world this holds true even more so than on the desktop. If they can push this kind of development (especially with the hardware capabilities of modern phones) it would be great for phone hardware in the long term.

    4. Re:Why HTML5 apps suck on mobile by postbigbang · · Score: 5, Insightful

      It would be nice, but no one's bitching that their phone isn't fast enough. Native apps are lovely. Browser apps are lovely. What distinguishes Android and iOS is that there's a business model where lots of people get paid.

      Watching videos isn't a business model anymore because the data plans are becoming mind-numbingly expensive. So what's left? Store-and-forward content viewing; low data rate interactives, including gaming. RIM has to offer something that's a monetary incentive to 1) carriers 2) developers 3) content providers 4) aggregators and CDNs and 5) all of these on an ongoing basis or no one's going to invest in doing BBx-specific stuff.

      Apple has lots of salespeople and financial partners whose employer isn't Apple. So they promote Apple. Not so for RIM.

      RIM gives no guarantees of privacy, security, or economy to increase their value from the user's context, either.

      Speed isn't an issue, as phones are throttled by data rates that the carriers can support. Instead, things like actual security and real costs are the values.

      --
      ---- Teach Peace. It's Cheaper Than War.
    5. Re:Why HTML5 apps suck on mobile by Barbara,+not+Barbie · · Score: 4, Informative

      One of the advantages of web apps in any scenario is the ease of cross platform compatibility

      Sure, because HTML always renders the same on every browser and platform, always has, always will.

      Except that it never had, and never will. Even Flash had better cross-platform compatibility (and better performance).

      --
      Let's call it what it is, Anti-Social Media.
    6. Re:Why HTML5 apps suck on mobile by jo_ham · · Score: 4, Insightful

      Yep. I've got an unexpensive Android device with a QVGA screen. Native apps are a must with such a resolution because they just fit much better than websites. BTW, how is RIM going to push for HTML5 apps on iOS?

      If that's their plan, I'm afraid you can stick a fork on RIM, they're done.

      Why would it need to push for HTML5 apps on iOS? iOS already has them - they predate the App Store, and are still supported. If BB can get this working for them, which I doubt since the BB train has long since sailed in the US market, then they might be able to salvage something.

      I think they have left it far too late, however, and they've been pushed into irrelevance by iOS and Android.

    7. Re:Why HTML5 apps suck on mobile by DuckDodgers · · Score: 2

      HTML5 is reasonably well supported by most browsers, including mobile browsers, and the support will improve with time. So if a developer writes something that works on Blackberry, he can host it at a web page and someone on iOS or Android or Windows Phone can just bookmark the page. That's what RIM (and Mozilla's Boot 2 Gecko, and the Tizen project) are trying to achieve. You draw in the developers by telling them that if they develop for your platform, bookmarks let your app work on all of the other platforms with no extra work. That's an even bigger target audience than building just for Android or just for iOS.

      A scripting language like Javascript generally won't run as efficiently as a compiled language, even against a bytecode compiled language like Java. On the other hand, Microsoft, Mozilla, Webkit (Google, Apple, Nokia, and others), and Opera are in an incredible web browser arms race to build the fastest, most efficient Javascript engine possible. I don't think any other scripting language is receiving even half the work on optimization that Javascript is getting. And in three years just about every mainstream smart phone will have over a GB of memory and a quad core ARM processor. The speed difference is not a problem.

    8. Re:Why HTML5 apps suck on mobile by A+Big+Gnu+Thrush · · Score: 2

      People said the same thing 10 years ago about web applications. The market for native Mac and PC applications is disappearing. You could do Facebook as a client-server application. There's a reason they didn't. You could do Facebook mobile app as a native iOS app. There's a reason they didn't.

    9. Re:Why HTML5 apps suck on mobile by localman57 · · Score: 3, Insightful

      It would be nice, but no one's bitching that their phone isn't fast enough.

      Speed isn't an issue, as phones are throttled by data rates that the carriers can support. Instead, things like actual security and real costs are the values.

      But they bitch a bunch about battery life. Program efficiency may not be an issue to the touch and feel of the phone. But they are a huge issue in terms of battery life. The phone's processor spends most of its time in an idle/sleep mode. If it takes more cycles to achieve the same effect, then you're going to see a proportional hit on battery life. Every instruction executed has a cost measured in Coulombs.

    10. Re:Why HTML5 apps suck on mobile by LordLimecat · · Score: 4, Interesting

      Im no programmer, but claiming something isnt modern is just a shady way of denigrating something for being well established. Essentially, where one person might say "its stable" or "time tested", youve found a way to turn that into a negative.

      Arent latest, greatest fads usually just fads? Arent the most popular programming languages generally decades old (C++, Java)? Isnt one of the most popular languages for embedded devices (C) even older?

    11. Re:Why HTML5 apps suck on mobile by Thunderbuck_YT · · Score: 2

      Java is basically a resource-sucking abstraction layer. Native code is much more efficient in every way (lower memory footprint, easier execution). That said, HTML5 isn't a bad choice for certain lightweight tasks. An accomplished developer or team can break down the needed functionality of an app and figure out which functions are best executed on which platform. Where BB10 has a chance is in the new UI, which will have all kinds of goodies baked in and written in native code. If it works (and there's still some question, for sure), it stands a chance of not just performing better than Android and iOS, but even introducing new functionality.

    12. Re:Why HTML5 apps suck on mobile by hackula · · Score: 2

      Speed is around number 10 on the list of things that matter when choosing a general purpose language...And do not even try the ole BS "b-b-but I work in the game industry and I need the speed". 1) No, you don't; I bet you are lying and 2) write the speed intensive stuff (a tiny fraction of any application) in the lowest level language you can and wrap it in a easy to use high level language.

    13. Re:Why HTML5 apps suck on mobile by tlhIngan · · Score: 2

      Native apps will always work better and be less resource intensive than HTML5 based apps. You will never be able to match native code or get even close. Even Google understands this on mobiles, even though they still use the crappy Java. This is especially important on mobile phones not only for limited CPU and memory and the lack of good GPU, but because battery life is really important and already not that great.

      RIM just wants to do this because they don't have the vibrant app economy than Apple and even Microsoft has. They want others to do the work for them.

      Honestly, the web app "economy" failed. The iPhone tried it (it's the reason why Safari for Windows was produced) as the only apps available on it were web apps. Developers cried out, jailbreaks happened and some rather good apps were developed for jailbroken devices.

      All this while Apple was pushing web apps, adding HTML5 support for sensors and location information, local storage etc so web apps could get access to a whole range of APIs. Eventually Apple relented and created the App Store. Web apps are still supported in iOS - and Apple promotes them as a way to get around the approval process.

    14. Re:Why HTML5 apps suck on mobile by LordLimecat · · Score: 2

      All high-level languages above native processor code are abstraction layers that reduce performance. The goal is to reduce the chance of errors and to speed development time, and if a language does that well it can be worth the downsides.

      HTML for example is very high level, and pretty poor relative performance compared to native, but it is simple and fast for me to create my own page, and it is unlikely that an error in my code will cause a HCF error in the processor, corrupt the memory stack, result in privilege escalation within the OS, etc.

    15. Re:Why HTML5 apps suck on mobile by aztracker1 · · Score: 4, Insightful

      Just want to point out that Java, C#, NodeJS, Python, etc. offer a very large advantage over lower level languages. That is a bit of isolation from typical issues resulting from poor memory management. It doesn't mean you shouldn't be aware, but allows you to concentrate more on the problem domain, instead of dealing with the ancillary issues of your development platform. Many operations in Java/C# in particular can be as fast as the same operations in C/C++, after JIT it is compiled code.

      Beyond all of this, the overhead for Java/C# is typically less than 5-10%, with modern smart phones commonly running Ghz processors, even multi-core, the overhead isn't that big of an issue. The bigger issue is running applications in the background that aren't resource aware, and run blocking operations, or don't offload well. I think that as the developer frameworks for mobile evolve it will be even less of an issue.

      --
      Michael J. Ryan - tracker1.info
    16. Re:Why HTML5 apps suck on mobile by MogNuts · · Score: 2

      Yet mobile web apps still end up working and looking better than the actual hard-coded apps for the respective platforms. I mentioned this in another post, but it bears repeating. I have an iPhone, and guess what:

      - Most apps are total garbage
      - Apps crash constantly, even all these years later
      - Unblockable, unstoppable, obnoxious ads (I'm looking at you CNET and IGN with your VIDEOS every other webpage on a CELLPHONE connection--3G, data caps and all)
      - Most apps are missing about 80% of the desktop/webpage's features
      - Most apps don't even do encrypted ANYTHING. You know shit is bad when a *webpage* is more secure than a hard-coded true application on a trusted system should be. See Path, Southwest Airlines App, and pretty much 70% of all other Apps that deal with logins and sensitive data.

      After all this, using a mobile version of a webpage, or using the "desktop view" in 3rd party web browsers is a GODSEND.

    17. Re:Why HTML5 apps suck on mobile by thePowerOfGrayskull · · Score: 2

      Actually rim isn't pushing html5, except for developers who want to have apps compatible with new and old platforms.

      Otherwise they're heavily pushing Cascades and their native API (c/c++ on a positive compliant platform )

    18. Re:Why HTML5 apps suck on mobile by sribe · · Score: 2

      ...after JIT it is compiled code.

      Yes. But too bad that JIT is so very resource intensive ;-)

  2. Good for developers by acoustix · · Score: 2

    With HTML5, write an app once and you're done. Currently you must create an app for iOS, Android, BB OS, Win Mobile, etc.

    Besides, most popular apps on mobile devices are fetching information from websites anyway. Look at how many websites have apps. What's the point? Why should I load an app on my smartphone to access the same content by actually using the browser? I'm tired of seeing posts on websites like "hey, I can't get to this with my iPhone app". Why deal with keeping apps updated and working. It doesn't make sense.

    --
    "A plan fiendishly clever in its intricacies"- Homer Simpson
    1. Re:Good for developers by gl4ss · · Score: 2

      well, yeah as soon as the mobile html5 device apis come standard, something that has been 5 years in the making.

      if your app is just a mobile web site to begin with then those api's don't matter. but then, eh... this isn't really news for those people anyways, like said they can just be a mobile website then.

      you really want to know why so many websites have apps? it's part of their social media strategy(tm)(r). the point is to keep reminding the user that you exist, a nifty icon on app menu is exactly that, a reminder. even if all the app does is launch a browser window.

      --
      world was created 5 seconds before this post as it is.
    2. Re:Good for developers by Tharsman · · Score: 2

      Huge issue: biggest chunk of apps moving in mobile markets are games. These games either need as much performance as possible (that can only be achieved with native code) or are forced to use hacks here and there that end up making them depend heavily on browser differences.

      Not that this matters much here, I bet BB10 will have some form of support for native apps, and this HTML5 deal is just a way to make it easier on some to develop simple apps.

      Side note: in theory you can write HTML5 apps for iOS and Android. All you need is to make a very small "shell" app with a browser view controller and redirect it to your internal HTML code.

    3. Re:Good for developers by fermion · · Score: 2
      We will see. The iPhone was initially an web based machine. Much of what has happened since was due to demand of developers. Remember that with the classic mac, Apple ignored developers, and history has shown what happened. WIth the Intel Mac and iOS, Apple has been much more responsive to developers.

      The write once run anywhere model is compelling. For suitably powerful machines, Java already provides some level of functionality. HTML 5, which to be fair did not exist when iPhone first came out, looks like it will provide that functionality across all platforms.

      I think, however, that the success is going to depend on how developers approach HTML5. Recall that HTML gave developers a chance to write context based web pages to present content to wide range of audiences on a wide range of platforms. One reason Amazon, for example, is successful is because it leveraged this ability. But many others were not willing to let go of presentation. Without CSS those who wanted a consistent application front end turned to MS and IE, which resulted in a fragmented web and MS lockin. This fragmentation and lockin, again, was the choice of developers.

      Two things might make this work for mobile devices. One is a small front end custom written for a device that abstracts the web content into an App. This seems like a small thing, but the issue to me when the iPhone first came out was the need to load safari, go to a web page, and have the whole browser structure taking up real estate and resources instead of have a custom view. Second is the ability to run offline. The need to be always connected is a major disadvantage for web apps on mobile devices. Take something like the Kindle Fire. It is not always connected. If one is going to have an app that run on anything anywhere, it can't always require a connection.

      --
      "She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
    4. Re:Good for developers by paulpach · · Score: 2, Informative

      Besides, most popular apps on mobile devices are fetching information from websites anyway

      The top grossing apps are without question games

      I have been working on making a game for mobile myself (yes, shameless plug) and I can tell you first hand that making anything beyond tic tac toe on html5 for mobile is crazy talk.

  3. Re:Sports cars at QNX by localman57 · · Score: 4, Insightful

    I think you're right. It appears that the tail is now wagging the dog. Six months ago, RIM was a handset maker that happened to be using QNX. It appears that they have now transformed into an OS maker that happens to be making Handsets. Almost as if QNX aquired RIM, not the other way around.

  4. Re:Sports cars at QNX by localman57 · · Score: 2, Interesting

    An additional thought: This sort of transformation was the beginning of the end for Palm. (Although it's pretty clear the beginning of the end for RIM was years ago. What we're seeing now is the beginning of the end of the end of RIM.)

  5. We go full circle by sinator · · Score: 3, Insightful

    QNX is seen as a stable, RTOS microkernel for a variety of embedded applications.

    QNX somehow never makes it big in the phone market.

    iOS, Android, Blackberry, PalmOS, and Symbian start duking it out.

    Blackberry starts using QNX and finally states it is going in the direction QNX should have gone 15 years ago instead of the iOpener and its "pizza button."

    I am not surprised this has finally happened, but I am also not holding my breath it will succeed.

    --
    Three Step Plan:
    1. Take over the world.
    2. Get a lot of cookies.
    3. Eat the cookies.
    1. Re:We go full circle by Anonymous Coward · · Score: 2, Insightful

      This is only half true. I've worked quite a bit with QNX, and in some ways it's beautiful to develop with, but it's missing some of the useful tools that Linux people are used to.

      I actually don't think it's a solid choice for smart phones, and it's because the bottom line at QNX is reliability and maximizing up-time without crashing. Performance is secondary to that. This is why it's popular in car dashboards, nuclear power plants (CANDU), and really big routers, but it's not so popular for personal media stuff where reliability is less critical.

      It does support a huge range of old and new embedded platforms though - surely second only to Linux.

  6. Logical extension of QNX by ArhcAngel · · Score: 4, Interesting

    QNX is the OS of choice for many auto manufacturers for their in dash hardware. Since BB 10 is QNX with a new GUI layer (Kinda reminiscent of another OS X product and its BSD/OpenStep heritage) doesn't that just seem like a logical evolutionary step?

    --
    "A person is smart. People are dumb, panicky dangerous animals and you know it." - K
  7. Re:The real question by Karlt1 · · Score: 3, Funny

    It wasn't Apple back peddling it was developers demanding native access. The same as developers for Palm demanding native APIs. Good luck with any halfway decent game running on HTML.

    So will Mozilla and Google complain that they can't write a browser for RIM?

  8. Re:Sports cars at QNX by NatasRevol · · Score: 2

    According to this, in Sept 2011,

    Acura - 10k sold
    BMW - 25k sold

    http://www.thecarconnection.com/news/1066815_september-2011-car-sales-the-needle-creeps-higher

    --
    There are two types of people in the world: Those who crave closure
  9. Bye bye RIM by Coward+Anonymous · · Score: 2

    HTML5 is a fatal architectural design mistake for developing anything other than web sites.
    HTML+CSS+JavaScript is a clunky necessary evil born of the nature of web development - not a desirable development environment.

    HTML for mobile will always be slower and clunkier than an platform using C or Obj-C or C++ or even Java.

    There is an unfounded myth that by using HTML, a wide audience of developers can be tapped while Apple has proven that the only thing that taps developers is a platform they can make money on - developers will learn whatever they need in order to eat.

    Finally, using HTML does not guarantee automatic portability across devices in the same way that Android can't guarantee it across devices - there is a limit to how much hardware variation can be abstracted away and when hardware vendors compete on features there is a very strong force working against portability.

    Palm failed because of this mistake, among others, and those who do not know their history are doomed to repeat it.

  10. Re:The real question by sootman · · Score: 3, Funny

    > So will Mozilla and Google complain that they
    > can't write a browser for RIM?

    No problem there--they can just write a browser in HTML5. :-)

    --
    Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.