Single application build for multiple mobile devices

Question

Is it possible to have one application binary build for multiple mobile devices (on BREW platform), rather than making a separate build for each device using build script with conditional compilation.

In particular is is possible to use single BREW application build for multiple screen resolutions?

Note that the goal is to have a single binary build. If it would be just to have a single codebase, than conditional compilation and smart build script would do the trick.

Answer 1

I've thought about this for a while myself. It seems like a decent domain for Aspect-oriented programming techniques. I have not yet tried it, however. Sounds fun, though.

Answer 2

Yes, it is possible, we were able to do this at my previous place of work. What's required is tricky though:

1. Compile for the lowest common denominator BREW version. Version 1.1 is the base for all current handsets out there.
2. Your code must be able to handle multiple resolutions. The methods for detecting screen width and height are accurate for all handsets in my experience.
3. All your resources must load on all devices. This would require making your own custom image loader to work around certain device issues. For sound, I know simple MIDI type 0 works on all but QCP should also work (no experience of it myself).
4. Use bitmap fonts. There are too many device issues with fonts to make it worthwhile using the system fonts.
5. Design your code structure as a finite state machine. I cannot emphasise this enough - do this and many, many problems never materialise.
6. Have workarounds for every single device issue. This is the hard part! It's possible but this rabbit hole is incredibly deep...

In the end, the more complex and advanced the application, the less likely you can go this route. Some device properties simply cannot be detected reliably at runtime (such as platform ID) and so multiple builds are then required.

Answer 3

Another idea might be to have the handsets divided into 2 to 4 categories based on say screen dimensions and create builds for them. It is a much faster route too as you will be able to support all the handsets you want to support with much lesser complexity.

Another thing to see is the BREW versions on the handsets you want to launch on. If say BREW 1.1 is on one handset and that is owned by a small percentage in your target market, it doesnt make sense to work to support it.

Answer 4

I wrote a J2ME to Brew conversion that is used at Javaground. It is quite possible to write multiple resolution, single binary code. We have a database of device bugs so that it can detect via platform id the device and then generate a series of flags which mark which bugs are tagged. For example most (if not all) of the Motorola Brew phones have a bug where an incoming call does not interrupt the application until you answer the call, so I use TAPI to monitor for an incoming call and generate a hideNotify event (since we are emulating Java, although the generated code is pure C++). I do some checks at runtime for Brew version, and disable certain APIs if it is Brew 2 rather than Brew 3.

3D type games are easier to make resolution independent since you are scaling in software.

Also there are 2 separate APIs for sound, IMEDIA and ISOUNDPLAYER, ISOUNDPLAYER is the older API and is supported on all devices but doesn't have as many facilities (you can only do multichannel audio using IMEDIA). I create an IMEDIA object, and it will fall back to create an ISOUNDPLAYER object if it can't get the IMEDIA object.

The problem with a totally universal build is that there is a big difference in capability, so it can be worth having a few builds, the older devices only have under 1MB of heap (and a small screen size), and then you get a lot with 6MB+ (176x204 to larger).

With Brew you do have a fairly consistent set of key values (unlike Java), although some of the new devices are touch screen (and you have to handle pointer input) and rotating screens.

There are also some old Nokia phones that use big endian mode which mean the files are not the same as the normal mod files (UNLESS you want to write some REALLY cool assembly language prefix header that decodes the file)