We are in an interesting position in the industry, as we get to see games and apps very early in the development process. A couple of years back, the rule for the professional developers was to write as few classes as possible, and not to use a framework. That has changed РI know of at least 3 of top 5 US mobile game publishers which had recently completed, or in the process of developing an OO based development framework. With the diversity of handsets with defects and different capabilities, an OO development framework offers immense productivity increase in development, QA and porting. Of course an OO based development framework does have size overhead, but there’s where mBooster come in.

Especially for the non-game content, it is very important to keep the code base easy to understand and maintain. It is also easy to overlook the advantage of being able to quickly adapt the code-base to target a new business opportunity in an adjacent market. Although it is possible to do most optimizations by hand (though I would dispute the claim you could replicate mBooster‚Äôs size optimization in a few days , the code base would be “corrupted”. There are two answers:
1) to keep the core code base pristine, and repeat the same optimizations whenever you need to do a production release
2) to bite the bullet and “corrupt” the code base with optimizations at significant long term cost

mBooster can be very cost effective. We have a customer who had to take a game in the back catalogue to China due to a publisher’s request. They had to reduce the size of the Nokia Series 40 version (63kB) to less than 57kB because of the special constraints of Nokia Series 40 handsets in China. mBooster optimized to slightly less than 57kB, so they managed to eliminate the entire manual optimization/removal of features process. It was cheaper, quicker and much less hassle to use mBooster despite they only used mBooster a single build for this particular game. They end up with better content too since no features were removed.

Officially it’s “Java ME” now (for Java Platform, Micro Edition). I guess Sun wanted to be clear that it’s Java. After all, Java is a strong brand with positive vibes.

Can we not call it JME now? Or is that not allowed?

Adopting a one-size-fits-all approach can work for simple/ugly apps and sometimes it is forced on you when eg. you have no specialist hosting capable of delivering device-specific binaries; for these cases tools like mBooster are a particular help. However it’s the wrong approach for most mobile apps because it leads to either needlessly restricting the app for the lowest common denominator, or ignoring the mass market low-end phones and concentrating only on the easy high-end devices. Here’s an incomplete summary of differences you (may) have to factor into porting:

JAVA
– (many) handset-specific bugs, which get the most press but really once you know them can safely be ignored / abstracted away
– the exact MMAPI code needed to play sounds efficiently (one of the worst areas)
– key codes, whether release events are handled reliably, etc (though some of this can be abastracted away)

HANDSET
– UI considerations:
– pen vs QWERTY vs Suretype vs standard numeric
– available keys
– graphics optimised for the different screen sizes
– JPEG support
– alpha transparency support
– PNG loading bugs (eg. Sagem tearing, Samsung white/transparency misloading)
– supported sound formats
– optional API support
– jar sizes, and what functionality you have to drop for the small ones

mBooster is a useful tool for your arsenal which helps with the last point, good for squeezing in extra functions but not really a substitute for writing efficient code designed for a constrained platform. DashO is another alternative (though not as good), and I’ve heard if you start with the right design you can achieve most of the mBooster savings with a few days of building custom tools.
I would argue it is better to ditch 90% of what you learnt about good OOP design principals though, coding for minimum memory footprint and heap fragmentation, etc etc. If you then still need extra space, as with any other tool you then assess whether the price justifies the gains and plan accordingly. Great to know it’s there, but I have heard the price per developer is somewhere north of Photoshop so not within everyone’s budget.

There’s a wide spectrum of approaches to the porting world. APIs like Polish can help with the porting alongside mBooster, as they also address a number of handset bugs and provide a rather lardy way of making the app look prettier than an lcdui interface. Systems like Tira Wireless’ Jump platform offer the next level of automated porting if you have some VC cash to spend and want to be further abstracted from the underlying issues. Finally you can actually know what you’re doing and learn all the handset issues the hard way, abstracting into an ultra compact reusable platform, which not everyone has time for – on the plus side that gives you absolute control over everything you put on screen, but on the minus side you then have absolute responsibility to put everything on screen correctly.
Your approach is dictated by your experience, your timeframes and your budget. mBooster can help whichever approach is best for you because it’s just a tool, and only a small part of the picture.

To respond to wookie and Kiren, mBooster is similar to an obfuscator in terms of what it achieves: size reduction and performance increase. However mBooster is a full featured optimizing re-compiler, and typically deliver 10-30% on top of proguard. At the JavaOne conference this year, I demonstrated mBooster on a well known publicly available mobile app delivering 24% size reduction.

There are many contributor factors to the difficulties of porting a mobile game and application to the whole range of mobile devices, including
1. Different screen sizes and capabilities
2. JVM bugs and implementation differences
3. Size

Size is a significant factor for many serious J2ME games and applications. I am not going to claim that size is an issue for all J2ME apps – because there are some very cool apps small enough to fit into every phone. However there are many mobile apps bigger than 30kB, 64kB, 128kB, which are incidentally the application JAR size limits for DoJa 2.5, Nokia Series 40 version 1, and Nokia Series 40 version 2. These phones comprise of a large percentage of the phone handsets out there.

If you would like to address as big a market as possible, which is important for a consumer facing application such as mobile banking, email and social network apps, then it typically makes commercial sense to target as wide a range of phones as possible.

That’s how mBooster could help in porting. Porting these applications to the more constrained phone often involves removing features, replacing the graphics and sound with a lower-grade version. With an optimization solution you get more space so porting become easier as you may no longer need to remove any feature (or do less work). This saves time and money. You would end up with a better (more featured) app for the low end phones as well.