A few months ago I wrote a piece about The Frustrations of Java, which you left a lot of comments about. My post was a rant about what a bitch Java Platform, Micro Edition (or J2ME as it used to be called) is to develop for, with a huge amount of work going into porting the application, once you’ve finished the initial build. In fact, I’d suggest that 20% of the work goes into the initial iteration of the code and 80% into the porting, which can be a shock for the uninitiated.
This is causing real pain in the market and where there’s pain, there’s opportunity. So it was interesting to hear from long-time MobHappy reader and fellow mobile veteran, Jon Beverley, who escaped to New Zealand a year or two back. His company sound like they’re on to something pretty big, at least to people who are involved in porting Java apps.
Innaworks have developed a product called mBooster and they’ve been successfully signing up a whole bunch of big name game developers as first clients, who seem to be getting great results. This has resulted in significant savings in time and therefore money. As well as helping many engineers all over the world sleep at night and their commercial colleagues hit those deadlines that they foolishly promised prospective partners.
How it works is obviously way over my head. But the principle is that it reduces the size of the midlet JAR files, while simultaneously increasing the performance. This allows the developer to maximise the handsets the application runs on, with the minimum effort. And in some cases, the additional space can be used to cram a few extra features in.
Innworks claim to already be talking to most leading games developers, so if you’re one and you’re not talking, get in touch and put their claims to the test. If you don’t, your competitors could be enjoying a significant reduction in fixed overhead that will be denied to you.
But I know there’s thousands of you out there who are non-gaming Java developers and you face the same pain and heartache. Be nice to yourself and your team and check out what these guys can do. You have nothing to lose but your pain.
I’d be interested to hear any feedback anyone has over the Innworks solution and I’m sure other readers would welcome your insight - so please leave a comment. And maybe send this post to anyone you know who looks haunted and goes around muttering about Java under their breath.
If you want us to write about your mobile tech product or service, just drop us a line using the link on the right. I can’t guarantee we’ll write about it, but we’ll certainly consider it. Stating the bleeding obvious, no Jonathan, we don’t charge for writing this kind of stuff and no you can’t pay us to do it. Now go away.
[tags] java, innworks, mbooster [/tags]
having done some j2me for an art project called radarFunk, I’ve been going through the pain of doing it, and I have to say that it’s sometimes everything but easy.
sure, I’ve not ported my app to other devices, as it runs on a Nokia, but it’s painful to achieve many tasks that might seem easy in the beginning.
besides, I’m a mac user and a really stubborn one (having switched from pc after 11 years), hence I want to develop on mac.
I don’t know what the innworks solution is going to achieve, but sure compressing and optimizing the code is not going to solve many problems, unless we’re just talking about some quick and easy java games to be ported between devices from different vendors.
to target different platforms, I used J2MEPolish, which works as a preprocessors targeting specific platoforms, as well as containing several engines and libraries to ease the j2me developer life.
a very good game engine is included, and the opportunity to style menus using css is there too.
I’m not a long time experienced j2me/java developer, but if you have to jump on the wagon, I advice you give it a shot
http://www.j2mepolish.org
Hi Russell,
I want to agree whole heartedly with you, but, I guess my experience with porting applications from one device to another have not been all that bad - I don’t know how many people remember or still use Appforge to develop on Palm OS and WinCE but the porting that the IDE allowed was pretty darn good. I remember creating an application with support for a Symbol Scanner on a Handspring Treo and it ported effortlessly onto a Windows CE device.
Now, that leads me to believe that if its possible to port across OS’s and seamlessly across languages within Appforge it must surely be easier to port a J2ME app from one device onto another given the virtual machine is exactly the same. I am not trying to belittle the work that goes into it - I am merely trying to point out the fact that the problem lies not with the VM but with the IDE that does not do it justice.
On an aside, we’re launching MoMo Chicago with a bang and our inaugural meeting will focus on precisely this - J2ME & Linux/Eclipse and a senior person from Motorola will be speaking to momo’ers about how they are supporting this fledgling movement.
Could you advertise this event on your site? its listed on the home page @ http://www.momochicago.com
Cheers,
Kiran
Really, Innoworks offers just a more advanced obfuscator [than open source ones]. I can’t see how it really can ease the task of porting application to various handsets.
Declaration of interest: I am the CEO and co-founder of Innaworks (www.innaworks.com).
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.
All of you are right: size if only a small part of the porting issue. At the beginning, it’s not really speed or size which is the major issue, it’s more difference in handsets and VM implementations. To solve this, then you start to add code in your application to try to manage with a single code base these differences…Then the code size increase, and that’s where a solution like this one is interesting.
Another approach is something like J2mepolish, right. But remember that if you want to have a signed app, that’s a cost per binary, and not per application if I remember well, plus all the extra added value to have a single binary (one runtime for different platform). Even without being signed, the pain of managing hundreds of binaries IS big!
Unless you are writing a very trivial or ugly app no IDE will be able to seemlessly port across all devices, and a lot of the reasons for that are not specific to Java. Claiming that the restrictions imposed by handsets are tied into Java is disingenious - Java has become so widespread because some flexibility had to be given in the specs, and this has made it the only *mass market* platform worth developing for (except BREW in a few countries). Any open platform which becomes deployed on multiple vendor’s devices starts to fragment, as Flash Lite is doing despite having tiny market penetration split between two largely incompatible versions.
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.
I used mBooster in a previous capacity and it was very impressive. It made porting much easier because it created more space to squeeze everything into the 64Kb max for Nokia S40.v1 devices (MIDP 1… urgh). That being said the real skill in porting ultimately comes from device knowledge and experience assisted, of course, by wonderful tools like J2ME Polish and Antenna.
Can we not call it JME now? Or is that not allowed?
“Can we not call it JME now?”
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.
Raddedas, although an automated optimizer does assist in the porting process as Russell and Thomas has pointed out, that’s not mBooster’s biggest value. We believe the biggest values of mBooster are to increase sales and to increase productivity, and not to reduce porting cost and certification costs (if you end up with less builds). However if you are using just to reduce porting cost, we are not going to complain
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.
There is no automated solution to this problem. A combination of MobileComplete (remote access and automated testing for mobile devices) and labor-intensive app porting (through Indian outsourcing company Small Devices http://www.small-devices.com) will do the trick.
Sorry, that is http://www.small-device.com
Some rich games, using lots of memory and other resources would need a careful manual porting methods instead of automated tools. As the memory usage has to be perfectly tuned for each device knowing it capablities. Such projects are better cost effective when outsourced to Porting labs like http://www.smackall.com