With J2ME there is always the trouble with lots of JAR and JAD Files to handle device differences. It's theoretically possible to write a one-fits-all application in J2ME - but only with a lot of drawbacks. One big problem ist the usage of special APIs or profiles. The other big thing is that you have to include different ressources for the same thing to (really) 'work' on the device. Handling these problems on the device leads to very big and slow applications. Keep in mind that some people still pay a lot of $$$ for mobile bandwith and/or have slow devices. Thats why one-fits-all jar's are very rare and DUBwise isn't one of it. But it leads to problems in finding the right jar/jad for a lot of people. And until now this problem was solved by a human (me) by answering questions from users. But I like the idea of letting computers or machines do the monotone work ..-)
The most common solution to this problem out there are device lists - but these lists are never complete and need a lot of maintenance (there are a lot of devices emerging every month). The solution for DUBwise is the "DUBwise Installer" which is a small (<10kb) one-fits-hopefully-all application which assembles information about the device, selects the right jar/jad combination and gives the possibility to install it.
This is an easy way for users, but the coders side had some stepping stones. Now i had to build all possible combinations - and this was more of a problem than it sounds because there are 3456 combinations possible actually:
6 - sound packs
*6 - image packs
*3 - firmware packs
*2 - bluetooth usage
*2 - cldc1.1 or cldc1.0 usage
*2 - jsr179 usage
*2 - FileConnection API usage
*2 - deviceControl usage
----
=3456 Jars
This is more than one Gigabyte of jar and jad files and took ~6 houres to build on my Core Duo. Reducing the diversity was not an option for me - so i had to work on Filesize ( i didn't want to crash the svn server on the host project) and on compiling speed.
First tests with my standard packers bzip/bzip2 where very disappointing because they did not siginificantly decrease the size - the very minimum i got where ~800MB - and i had a lot less in my mind because i thought that the entropy is not very high and i can compress this content very good (i could explain why verbally but im not able to write it down ..). Then i searched the net a bit to find a better packer - i stumbled over 7zip - but the tests on the site i found only showed a small difference (which is anyway good for the content they tested - but not the jump i searched for). So i gave it a try and the results where amazing - I got a 17MB File with the default settings and compressing/decompressing are rather fast.
The next problem was the build time - until now i had no problem with it because it was less than 10s/build which is ok for building an app - but not ok for building an app 3456-times ..
The most time consuming part were the jumps to ANT where the sources are preprocessed, compiled and stuff. Now i do this only when the code is changed and just bring the right ressources into the jar otherwise.
Links:
- jar and jad of the Installer
- Source Code of the Installer
