1. mikelcal's Avatar
    Attachment 108312Well well, how the times change. Almost 3 months ago, Kayak said they would discontinue support for BlackBerry devices. The trend has continued, more and more companies are finding excuses to drop offering BB apps. Yahoo, Google, Barnes & Noble just to name a few. Just this week, kayak, the same company that said "no" to BB Smartphones released a Kayak app to the PlayBook App World. Wether we like to admit it or not, it seems like at this point all apps are "good" apps to help spark some competition on App World and either bring in the "Big Dogs" or create new ones.

    Sketch with Friends is a great example of this. Over a relatively short period of time, xLabz have managed to create a viable alternative to that other sketching app, and in the processed also benefitted from creating a cross-platform solution. Although it may seem like counter productive that "big content providers" are ditching the current BB offerings, there may be a light at the end of the tunnel.

    If more companies spend the energy to port their Android Apps to the PB, it just means that there will be more apps people want on BB 10. Which in turn opens the door for devs to potentially turn their source code to native cascades apps with the help of the feedback button. Its just up to RIM to not only make cascades appealing, but stupid easy for an android dev to be able to jump over. In the mean time let's take in all the android apps with open arms, and genltly and politely request that they take the time to look at the dev tools provided by RIM, much more so after BB World.
    ericrangel76 likes this.
    04-21-12 10:10 PM
  2. BuzzStarField's Avatar
    Attachment 108312 Its just up to RIM to not only make cascades appealing, but stupid easy for an android dev to be able to jump over. In the mean time let's take in all the android apps with open arms, and genltly and politely request that they take the time to look at the dev tools provided by RIM, much more so after BB World.
    I agree with your post except for the fact that it is just not realistic to expect RIM to make it "stupid easy" for Android devs to jump to NDK. There is quite a learning curve for a Java coder to become competent using C++. Like you, I hope that the developers take up the challenge and bring their apps to PlayBook. Unfortunately many of them will calculate that the rewards do not justify the effort required to re-write their apps.
    bbfan1040 likes this.
    04-21-12 11:14 PM
  3. mikelcal's Avatar
    well, considering that TAT are Android themselves, and that they are ultimately responsible for cascades, I don't think its far fetched to expect them to make it as easy as possible for devs to "jump right in" and start coding.


    I know that it is challenging to work with the NDK, I've been trying to learn to code for a while now and hope to have an app I can call my own.
    04-22-12 01:45 AM
  4. bldshd's Avatar
    TAT are android? Did I miss that somewhere? (not being sarcastic) TAT is RIM Sweden
    04-22-12 02:28 AM
  5. f0xG3's Avatar
    I think this is inevitable... the BBOS is getting old and will surely lose a share of developers. RIM must complete the BBX SDK to gear up the developers. I consider this as a Reboot of RIM.
    bbfan1040 likes this.
    04-22-12 03:04 AM
  6. bounce007's Avatar
    TAT are android? Did I miss that somewhere? (not being sarcastic) TAT is RIM Sweden
    I think (well, I hope) what mikelcal meant by saying TAT are Android, is that they developed substantially for Android and made some really good developments for that platform (eg TAT designed Android's Pull down notification bar)

    I hope that's what he meant lol.
    bbfan1040 likes this.
    04-22-12 06:39 AM
  7. mikelcal's Avatar
    I think (well, I hope) what mikelcal meant by saying TAT are Android, is that they developed substantially for Android and made some really good developments for that platform (eg TAT designed Android's Pull down notification bar)

    I hope that's what he meant lol.
    Oopsies on my part, that is exactly what I meant. TAT, from what I understand, got their beginnings on the Android platform and If I'm not mistaken, were pushing cascades for Android runtime. Since RIM bought them out, they have been working on porting their cascades framework to QNX.
    04-22-12 10:08 AM
  8. Andrew4life's Avatar
    I agree with your post except for the fact that it is just not realistic to expect RIM to make it "stupid easy" for Android devs to jump to NDK. There is quite a learning curve for a Java coder to become competent using C++. Like you, I hope that the developers take up the challenge and bring their apps to PlayBook. Unfortunately many of them will calculate that the rewards do not justify the effort required to re-write their apps.
    No there isn't. Any good programmer can easily pick up another programming language provided they know the basics of one. There is a learning curve, the syntax is different, certain functionalities may no longer exist, the framework may be different, but in the end, programming is programming.

    Besides, if anything I think Java is much more difficult to code in than C++ is.
    Last edited by andrew4life; 04-22-12 at 12:25 PM.
    ambarmetta likes this.
    04-22-12 10:23 AM
  9. BuzzStarField's Avatar
    No there isn't. Any good programmer can easily pick up another programming language provided they know the basics of one. There is a learning curve, the syntax is different, certain functionalities may no longer exist, the framework may be different, but in the end, programming is programming.

    Besides, if anything I think Java is much more difficult to code in than C++ is.
    Are you an actual developer or are you just engaged in wishful thinking? Changing from one language to another is never going to be "stupid easy". I have some experience in this area. I made the switch between Java and Air last year and I am moving to NDK right at this moment.

    Yes it's true that "programming is programming" but the devil is in the details. Java has a whole lot of standard libraries and Google has implemented more than a few APIs of their own. Finding and learning how to use the equivalent functions in the NDK is a fair amount of work. For most non-trivial apps, large portions have to be redesigned to fit into the new paradigm.

    Even experienced programmers will make beginner mistakes and these take time to correct through trial and error. The prospect of expending a large effort for little financial reward will be a show-stopper to a good number of Android developers. They will be content to stay where they are.
    Last edited by BuzzStarField; 04-22-12 at 11:40 AM.
    ambarmetta likes this.
    04-22-12 11:36 AM
  10. Andrew4life's Avatar
    Are you an actual developer or are you just engaged in wishful thinking? Changing from one language to another is never going to be "stupid easy". I have some experience in this area. I made the switch between Java and Air last year and I am moving to NDK right at this moment.

    Yes it's true that "programming is programming" but the devil is in the details. Java has a whole lot of standard libraries and Google has implemented more than a few APIs of their own. Finding and learning how to use the equivalent functions in the NDK is a fair amount of work. For most non-trivial apps, large portions have to be redesigned to fit into the new paradigm.

    Even experienced programmers will make beginner mistakes and these take time to correct through trial and error. The prospect of expending a large effort for little financial reward will be a show-stopper to a good number of Android developers. They will be content to stay where they are.
    I didn't say it is stupid easy. I was countering the point about it being a big learning curve.
    Yes, the details is the hardest part to adjust to. Yes it has to be redesigned.

    My point is, to go from an Android or an iOS app, to a blackberry app, people complain that the costs outweigh the benefits and it's not worth the time to port it to the playbook for example. But I've seen many apps that were taken straight from Android, and sideloaded to the playbook and pretty much everything works.
    On the other hand, to recode an app to BB native, is hard the first time, but it gets easier over time. Developers should know that they work in an extremely volatile field. If they do not update themselves on the newest programming languages, APIs, operating systems, etc, they'll risk falling behind.

    Am I an actual developer? Yes as in I've developed apps, no as in it's no Angry birds, or Asphalt 6 app. So experience wise, maybe I don't have a lot, but I've worked with Java, C/C++, VBA, SQL, so I can relate to the different programming languages. Definitely not wishful thinking.
    04-22-12 12:45 PM
  11. app_Developer's Avatar
    No there isn't. Any good programmer can easily pick up another programming language provided they know the basics of one. There is a learning curve, the syntax is different, certain functionalities may no longer exist, the framework may be different, but in the end, programming is programming.

    Besides, if anything I think Java is much more difficult to code in than C++ is.
    Well, from the perspective of someone who used to teach both beginning and advanced C++ courses, I would say true intermediate level C++ programmers are a lot more difficult to find nowadays than Java programmers. So for companies, that is something to consider in deciding to take on a native BB10 app.

    The other issue is that this will now be the one platform where you always need to explicitly manage memory yourself. On iOS, the compiler will do that for you in 90% of cases now. And of course in Android and WP7 and BB7 (and Air) you have a garbage collector.

    In native BB10 code, you have to manage that yourself and in my experience a lot of programmers have forgotten how to do that consistently. Combine this with the facts that (a) PB OS doesn't seem to offer any API support for "slimming down" as you go into the background (like Android, WP7 and iOS all do) and (b) the penalty for running out of memory is a hard crash and (c) there is no swap file. So I think there is some learning there for a Java developer, for example, who has been spoiled by the nanny collector who comes and cleans up after her.

    Now, having said that, Qt and Cascades development doesn't exactly need expert level C++. But things like memory management and templates may seem simple at first glance but take experience to do consistently (or to debug! Beginners usually struggle with debugging these things which adds buckets of time to a project)
    Last edited by app_Developer; 04-22-12 at 01:07 PM.
    BuzzStarField and ambarmetta like this.
    04-22-12 01:02 PM
  12. tinker2000's Avatar
    I didn't say it is stupid easy. I was countering the point about it being a big learning curve.
    Yes, the details is the hardest part to adjust to. Yes it has to be redesigned.

    My point is, to go from an Android or an iOS app, to a blackberry app, people complain that the costs outweigh the benefits and it's not worth the time to port it to the playbook for example. But I've seen many apps that were taken straight from Android, and sideloaded to the playbook and pretty much everything works.
    On the other hand, to recode an app to BB native, is hard the first time, but it gets easier over time. Developers should know that they work in an extremely volatile field. If they do not update themselves on the newest programming languages, APIs, operating systems, etc, they'll risk falling behind.

    Am I an actual developer? Yes as in I've developed apps, no as in it's no Angry birds, or Asphalt 6 app. So experience wise, maybe I don't have a lot, but I've worked with Java, C/C++, VBA, SQL, so I can relate to the different programming languages. Definitely not wishful thinking.
    I disagree, it is very difficult to migrate between some languages
    04-22-12 01:04 PM
  13. BuzzStarField's Avatar
    I didn't say it is stupid easy. I was countering the point about it being a big learning curve.
    Yes, the details is the hardest part to adjust to. Yes it has to be redesigned.
    Herein lies the problem, you were not responding to my main point, which was this: That there is a significant learning curve that will be a barrier to many Android developers adopting NDK apps as a secondary source of income. The poster that I was responding to expressed hope that RIM would make Cascades "stupid easy" so that devs would not have any excuse not to make the jump. In my opinion, this is wishful thinking and I stand by my response to you.
    tinker2000 likes this.
    04-22-12 01:34 PM
  14. mikelcal's Avatar
    Maybe I'm over-simplifying the problem, since I have no real experience as an app developer. But from where I'm standing, it seems like android apps and ios apps are almost interchangeable. How similar (or dissimilar) is an android app from an ios app?

    I know ios apps can be coded in cocoa, which to my understanding is an object based language derived from either C or C++ and android apps can also be written in C++ with different api's and libraries.

    Again, I'm a beginner to all this and just figured there had to be some common ground. Please help me understand the different dev platforms better.

    Why is it that an app can go from ios to android fairly quickly, and viceversa?
    04-22-12 11:17 PM
  15. app_Developer's Avatar
    The short answer is yes, you are over-simplifying this.

    So first there are different types of apps written in different ways with different requirements. One, you have immersive games like Angry Birds which are written to popular third-party 2D and 3D frameworks and/or OpenGL ES directly. Two, you have apps that are written to cross-platform kits like Titanium, Phonegap, etc. Three, you have apps that are just very thin shells around an embedded browser and the meat of the app is HTML and JavaScript. These three categories of apps are fairly easily portable to new platforms as long as the underlying frameworks they use have been ported. This is why Angry Birds was easy to port to Playbook.

    Then 4th you have native apps that are written specifically to Cocoa Touch or Cascades/Qt/BB10 or Android or WP7 Silverlight, etc. Kayak is an example of this type of app. Twitter is another. Instagram and Flipboard are two more.

    So Twitter and Instagram on iOS are different apps than Twitter and Instagram on Android. It is definitely not easy to port such an app to completely different native frameworks on a new platform. It wouldn't be easy even if all the different native frameworks were written to support the same language. Of course, they aren't written that way. The Android API's are Java. Cocoa Touch is mostly Objective-C (with some C APIs). WP7 is .Net. Cascades/Qt/PBOS/BB10 is C++/C.

    So because of this you have two issues. (a) completely different APIs and (b) the need to staff the project with competent Java developers versus C++ versus C# versus Objective-C. A developer who is good at one of these is not necessarily even competent at another without serious work.

    Further, a developer who is good at C++ isn't automatically competent with Qt or Cascades, just as fluency in French doesn't automatically make you an expert in French real estate law.
    Last edited by app_Developer; 04-23-12 at 05:25 AM.
    BuzzStarField and mikelcal like this.
    04-23-12 03:31 AM
  16. BuzzStarField's Avatar
    So because of this you have two issues. (a) completely different APIs and (b) the need to staff the project with competent Java developers versus C++ versus C# versus Objective-C. A developer who is good at one of these is not necessarily even competent at another without serious work.

    Further, a developer who is good at C++ isn't automatically competent with Qt or Cascades, just as fluency in French doesn't automatically make you an expert in French real estate law.
    I would add one other issue to your excellent post. Most developers have created extensive private libraries that make full use of language specific object oriented capabilities. The libraries contain generic re-usable components and make it comparatively simple to create a new app on a given platform. This is because existing generic components can be extended through inheritance to accommodate new functionality. Most apps built using this model exist as a thin veneer of new code built on a vast foundation of re-usable code.

    However when moving to an entirely new platform all of the private libraries have to be ported before the app-specific code can be started. Subsequent apps become easier to create but the first app on the new platform takes considerably longer to bring to market.
    app_Developer likes this.
    04-23-12 07:04 AM
  17. mandony's Avatar
    There are 'apps' and no need 'apps'

    When you use a phone or tablet specific 'app' which requires web access to a website then you are just as well to use your browser. Sometimes you can use the site's mobile pages such as m.domain.com

    If the native browser does not give content then use one of the free Browser+ that allow setting the browser type.

    For example, I don't use a CitiBank 'app' to access my accounts, I log-in through the PB browser.
    Simply make a 'favorite' from your browser on your desktop for the 'app'
    Last edited by mandony; 04-23-12 at 09:53 AM.
    04-23-12 09:50 AM
  18. mikelcal's Avatar
    I am aware of some of the development options out there, I reallyappreciate your thorough explanation, just makes me appreciate devs more. Still, I'm super excited for BB World.

    Sent from my BlackBerry Runtime for Android Apps using Tapatalk
    BuzzStarField likes this.
    04-23-12 08:54 PM
LINK TO POST COPIED TO CLIPBOARD