In the past I did quiet a lot of porting to BREW from J2ME. I will soon need to start working on a new library that will wrap BREW and J2ME libraries so the code will port easier. As far as I can remember the same sounds and .pngs are suitable to be used on both Brew and J2ME handsets? Is that correct? Also is there anything else worth noting about handling sound or images in Brew? I remember before using a previous library that wrapped J2ME and Brew that all text was contained in char arrays because BREW did not have a proper string class? Would that be correct? If there is anything else worth noting about differences between resources handling in these to libraries please let me in on the secret ;) Thanks in advance, Woody.

It's been a while since I worked with BREW but aren't graphics files usually converted into a proprietary bitmap format?

shmoove

The standard graphics format for BREW is BMP, whereas it's PNG for MIDP. Many of the BREW handsets do support PNG, but not all of them.

BMP files are a poor choice for resources, being uncompressed, so you'd be better to go with your own bitmap format or write a PNG loader for BREW. Fairly easy unless your target handset doesn't support PNG loading or IUnzipAStream interface, in which case you'll need to write the code yourself to unzip the compressed bitmap data from the PNG.

QCP sounds are supported by pretty much every BREW handset I've used. Java handsets seem to support a mixture of QCP and AMR (and possibly other formats - i've had limited experience with sound in J2ME) From what I hear from colleagues, sound support is very non-standard and often requires manufacturer specific APIs, so an all-in-one BREW/J2ME sound solution might be a lot harder to implement than if you tailor the code for each handset.

BREW doesn't have its own string class.

Wrapping BREW and J2ME/MIDP functions is a nice idea, but in practice you may have problems on low end java handsets unless you keep classes to a minimum. Each new class in J2ME adds a few hundred bytes and that really adds up when you have <100k jar size limit. Use as few classes as possible, and if you want similar looking code throughout, wrap the BREW functions in a MIDP style wrapper for Images and so on.

BREW resource files are uncompressed and therefore not ideal. If I was in your position I'd look at implementing PNG loading and unzipping to BREW so that you can use JAR files in your BREW apps (JAR is just a zip file with a different extension)