Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Java Development

Thank you for visiting the BlackBerry Support Community Forums.

BlackBerry will be closing the BlackBerry Support Community Forums Device Forums on April 1st (Developers, see below)

BlackBerry remains committed to providing excellent customer support to our customers. We are delighted to direct you to the CrackBerry Forums, a well-established and thorough support channel, for continued BlackBerry support. Please visit http://forums.crackberry.com or http://crackberry.com/ask. You can also continue to visit BlackBerry Support or the BlackBerry Knowledge Base for official support options available for your BlackBerry Smartphone.

"When we launched CrackBerry.com 10 years ago, we set out to make it a fun and useful destination where BlackBerry Smartphone owners could share their excitement and learn to unleash the full potential of their BlackBerry. A decade later, the CrackBerry community is as active and passionate as ever and I know our knowledgeable members and volunteers will be excited to welcome and assist more BlackBerry owners with their questions."

- Kevin Michaluk, Founder, CrackBerry.com

Developers, for more information about the BlackBerry Developer Community please review Join the Conversation on the BlackBerry Developer Community Forums found on Inside BlackBerry.

New Developer
Posts: 3
Registered: ‎07-22-2008
My Device: Not Specified

Best practices on building multi-model applications

Hey all!


I have to develop an application for several Blackberry models - Curve, Bold and Storm. It's obvious for me that I cannot use the same codebase to produce builds for each of the models because it wouldn't launch on Curve if there're mentions of Touch API that belongs to Storm and vice versa.


How do you usually work on code of multi model applications? How the code layout looks like, do you use sophisticated build routines or something else? I'd appreciate any kind of ideas and experience sharing on this matter.


Thank you a lot!


Posts: 4,764
Registered: ‎07-21-2008
My Device: Not Specified

Re: Best practices on building multi-model applications

I develop for everything from 4.2.1 through 4.7 on a single code base. This is done by coding to interfaces, using the factory method, and using the pre-processor (sparingly) in the factories to make sure that I'm not creating dependencies that will cause issues.


I have two production builds; one for 4.2.1 and one for 4.7, but a single code tree. To do this in the JDE I actually create two projects, one for 4.2.1 and the other for 4.7.


I also use a (roll my own) theme factory to handle the issue of screen resolution. There is quite a disparity between a Pearl on 4.2 and a Storm on 4.7. Graphics and other size-dependent issues are handled "under the covers" by the theme.


Check this thread for more info on the pre-processor.







Posts: 1,415
Registered: ‎07-30-2008
My Device: Not Specified

Re: Best practices on building multi-model applications

I'm still getting all the piece in place but I do just the opposite. In a limited resource java device, there

are often worthwhile gains from eliminating classes and code layers. I have not used the RIM conditional

compiler but instead rely on the g++ preprocessor under cygwin and use large conditionals

that should be familiar if you have ever looked at Windoze include headers ( #if RIM_OS_TGT> 40600  etc).

This gives me full features that I already understand I can use it easily with non-RIMM java or other

things. Sometimes #define is all you have when the compiler doesn't know much about inlining etc.

Obviously, however, if you can refer to a more generalized "thing" like "input" rather than "keyboard"

that will help but I wouldn't go overboard on OO without a little thought of the tradeoffs.



There are only a few screen sizes but I would never assume I could know about them all and would rely

on runtime or use of profile headers to tweak some things but not have a different build for each. 


While I am still expanding and fixing things, I now only have a few OS build but have loaded

4.0.2 , 4.1,4.2,4.3, and 4.7 and could build for any or all with a set naming convention ( still need

to check it works with siblings but should be easy to accomodate).


Note that in some cases, you end up with code that almost is portable except for gross things

like a package name and a few tweaks. In these cases the conditionals are great and I use

"-D" for #define switches for all kinds of build and branding options. 



I'm also starting to work more closely with version control and now routinely use subversion.

This isn't so much for collaboration as much as documentation when you start releasing stuff etc.






Posts: 343
Registered: ‎02-23-2009
My Device: 8700 | 8310 | BOLD | STORM

Re: Best practices on building multi-model applications



I've developed and built the same application on from the 7100 all the way up to the Storm.  You can use all of the fancy methods of preprocessors and all of that but at the end of the day, you want to have full control over the application on every model of the blackberry and it may require some code tweaking.  Here is what I do though:


1. I start developing for the lowest phone I want to support 4.2.1 (Anything with 320x240 resolution)

2. I keep in mind everything that would be different with the different resolutions -- which is your major issue. So things like images, displaying things based off of sizes of the screen will be handled through constants.  For instance, I have a game that uses 16x16 tiles on the 320x240 and 260x240 screens but uses 22x22 tiles on the BOLD, New Curve (8900), and Storm.  Also, what about keyboard input?

3. Once I am finished developing for the base phone, I copy the project to create the other phone models

4. I then change those constant values mentioned in step 2

5. This is the step where you must tweak the code.  My games use keyboard input for movement--you know the 2, 4, 6, 8 keys for up, lef, right, down.  As you know, the storm does have this so I had to make a custom soft controller at the bottom of the screen and you Touch that to move around.


Any method you choose will be up to you but I found that doing it this way gives you full controll over your application.