03-31-2012 11:46 PM
Hey all, I'm hoping to do some app design for blackberry and was wondering whether to either use my existing knowledge of java to design android apps that can be ported or to take my hand at getting the hang of C++ and going native. I am very eager to learn and will commit myself either way but am just wondering if it is worth it in the long run. I suppose having a multiple language background will be advantageous. Also, what will be the primary developing languages/methods for BB10?
I have dabbled at using java for BB7 but so far have found it fairly difficult and am surprised by the lack of resources/tutorials for designing apps for current BB phones. Since BB10 phones will be running a modified version of the playbook OS, will apps then shift from java to C? Im new to this and apologize for my lack of knowledge in BB development.
Thanks in advance.
04-01-2012 05:12 PM
04-02-2012 04:11 AM
It's also a question of what target Devices you want to develop for.
With Android Java (it's not J2SE) you can run your App on most Android Phones (There are different versions of the API) and with some adaption on some other devices in an emulated environment. So there are billions of devices running Android Java.
Qt is also a good (and my) choice. You can easily compile your App for different platforms like the Playbook, Windows, Linux, Symbian and Meego. Threre are also ports in progress for Android or iOs. So there are even more devices. But not so many mobile devices yet. Qt-Mobility (extension for many mobile functionallity like sensors or GPS) is not available for all platforms, but you can mostly use the native functions as a workaround.
J2ME as used by many mobile phones (don't mess it up with J2SE) is a real pain. You can do small projects, but you will end up soon in the many different supported JSR's of the different platforms, the little memory you can use etc. And J2ME is only used by mobile devices and can not be directly started run Desktops.
So it's not easy to decide wich language or platform you choose.
04-02-2012 07:09 AM
I'd go the C++ route, but don't get too carried away with language features. Avoid RTTI and exceptions and scary use of templates (depending on how many other SKUs you do).
Create yourself a cross-platform engine with only the smallest, discreet, platform dependent functions. Remove any dependencies you have on other 3rd party engines (apart from OpenGL/AL). This way you'll be able to take your technology not just to other phones but other handheld consoles should you wish and you're not waiting for any 3rd party to port boost/stl/Cocos/ etc, etc to your new device.
This frees you up to work quickly and take advantage of new opportunities.
Steve.
04-09-2012 03:19 PM
RTTI doesn't work on QNX?
04-09-2012 03:29 PM
Pretty sure it will, but it can be a performance killer.
Why take a risk that all future platforms are going to work well with RTTI?
If you're never going to do performance sensitive apps, don't worry about it.
04-09-2012 03:34 PM
Thanks for pointing out the performance degradation. I didn't realize that.
04-27-2012 07:25 AM - edited 04-27-2012 07:28 AM
I am writing a cross platform engine and I support all of that, incl. RTTI etc. I use stdc++/boost (1.42) on Win(32/64, mingw), MacOS, Linux and the BlackBerry (and when I have time will port it to Android - latest NDK supports all this, too).
You can use the full C++ feature set on an embedded platform, what comes in most handy are shared_ptrs. It works without a problem on the PB. I also compiled most of my 3rd party libs for the playbook (what I could get from the GIT repository, others from a plain gnu source which works in most cases).
I wrote a comment somewhere in here how to compile boost. Give it a shot.