03-15-2009 04:46 PM
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!
03-15-2009 06:03 PM
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.
03-15-2009 07:06 PM
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.
03-15-2009 10:46 PM
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.