Moving a big gob of java server stuff to a windows mobile contraption

[paul wheaton]

About two hours ago I was handed a funny looking contraption that is running "windows mobile 5.0".

What they would like to have happen is to mash my tomcat app onto this contraption. Currently my app feeds a flex app to make the data look all fancy/hollywood. I suppose I could make something look close enough using HTML or Swing.

The contraption has 64 megs of memory. Currently about 20 megs are available to run something.

My tomcat app current consumes 38 megs, but my app fits into a a 100k war file that uses some hefty jar files. I think I could whittle things down to under 2 megs.

I'm guessing that this will need to be JME - is that an accurate guess? Would JSE even run on this contraption?

[Tim Holloway]

If this device is the HTC Mogul phone (which would fit the description), officially, it can't run Java - Sprint, in particular doesn't want to hear about it. Unofficially, I can say that I had no problems doing basic apps on its predecessor (the Apache) using the IBM J9 JVM.

Obviously, if you really want/need to make this app self-contained on the device, you're looking for some major trauma, if for no other reason than that you'd be moving from a J2EE server app architecture to a Java Midlet app architecture.

If you're content to make the base website mobile-friendly, that's easier (hint, Pocket IE is similar to regular IE in name only - it's not a very smart browser). As long as you can make it entirely web-based, it's mostly a matter of detecting the environment (or providing a mobile URL) and crunching down the page output to be endurable on a 320x240 screen.

Yes, you have a completely different set of core packages on a J2ME device. Although many of the classes and methods are the same as for its larger brethen, some items are missing to keep the size down. It's quite possible that many of the third-party libraries (such as Jakarta) may not like this more cramped environment.

Swing is not the normal UI for Midlets - there's a java.lcdui package structure for J2ME UI, in keeping with the contstraints to keep things small and UI-neutral.

The best platform for J2ME is a J2ME-friendly device. Many such devices carry specs telling which mobile profile they support and what JSR's are builtin - things like GPS and media playing/recording features such as programmatic use of the camera.

I'm afraid I've no experience in a major Java app on a Windows Mobile device . I used C#.Net for my biggest phone app. For that, of course, you need a recent-vintage Windows machine and the .Net developer's kit. J2ME development can be done under any OS that supports Java. And as a bonus, there are some Eclipse plugins to assist.

[Mark Spritzler]

I'll add, that if you need to re-write the app to just run on the Windows Mobile device, it probably would be faster and I hate to say easier to code it in .Net C# or VB.net

If you use the simple lcdui that is in J2ME, the look won't be too pretty, especially on such a device, you can go low level and code through x/y coordinates, which isn't as PITA as it sounds. There is J2ME Polish's UI components that can make an app look pretty too.

Mark

[Ernest Friedman-Hill]

Note that there are actually some not-too-shabby J2SE JVMs that run on these smallish devices; in particular MySaifu really doesn't suck at all, and targets Windows Mobile. If you could concievably move to a lighter servlet engine, you might be able to just plop the whole thing down.

Blackdown's JVMs work on Linux running on iPAQs, too, if that's an option. I have one of those babies right here (Familiar Linux).

[paul wheaton]

There is a lot of code that is all about talking to a wacky contraption and interpreting what it says. That's most of the code base. The libs that do all this talking are huge, but we use just a small slice for this need. So the obfuscator just might do the trick on that.

I'm thinking of taking out all the tomcat stuff and slapping some really basic GUI on it.