TUTORIAL: Control issues of Java MIDlets – all secrets of button handling - Windows Mobile Development and Hacking General
Lately, with the advent of Opera Mini and the really excellent and highly recommended Gmail MIDlet and some quality games (see their list in the 10/19/2007 update of my 3D MIDlet article), there has been a tremendous increase in the demand for MIDlet-related information. This is certainly shown by the sheer number of MIDlet-related questions asked at XDA-Developers, probably the best, most lively Windows Mobile hardcore user community with the most posts. For example, today, I’ve answered at least 20 different MIDlet-related questions there. Quite a few, isn’t it?
Let me give you all another modest present: in addition to my already-published previews (for example, the 3D Gaming Bible, the 4pda.ru Download Bible etc.), another excerpt – a full chapter – from the forthcoming Bible. Yes, it’s coming and yes, I do try to get it ready tomorrow or the day after – everything, all accompanying screenshots and charts (the main chart; 3D games Compatibility Chart and JBenchmark Chart) are ready, I only need to consolidate all my thoughts into an all-in-one, still-somewhat-comprehensive Bible, which will, I promise, be MUCH better, will contain MUCH more information and MUCH more up-to-date than that of the Russian-only 4pda.ru. Now, look at the length of the 4Pda tutorial (and all the linked-in ones) to see how much information it contains Not very easy to come up with something that has even more info, is it?
Note that the MIDlet managers I refer to in the article can all be found in the main chart of the Bible.
1. Control issues
If you stick to either IBM J9 or TAO Intent (two well-known, established MIDlet managers with versions running even under WM2003(SE)), you’ll inevitably encounter major control problems with several titles. Either the WM5 softkeys or the D-pad won’t work, or none of them. If you, for some reason, stick to these MIDlet managers (also referred to as Kilobyte Virtual Machines, KVM’s), this chapter will be of extreme importance to you. Note that now that all WM5+ devices, Smartphones (Windows Mobile Standard), plain Pocket PC’s (Windows Mobile Classic) and Pocket PC Phone Edition (Windows Mobile Pro) devices alike support the, in general, vastly superior Esmertec and Jblend KVM’s, you should only do this if you really don’t have any chance of running Esmertec’s KVM’s or Jblend – that is, for example, if you have a WM2003 or WM2003SE Pocket PC or Smartphone.
However, even with the, in this regard, flawless Esmertec KVM’s and Jblend, you may still encounter problems with titles (mostly games) not supporting the D-Pad or situations (most importantly, Opera Mini and its modded version) where a MIDlet heavily depends on the hardware buttons. This means the chapter will be useful for non-TAO / J9 users as well.
There are three related (two of them being pretty huge and thorough) articles / tutorials at 4pda.ru explaining these problems and the way you can fix them. They all are linked from the main, first article in the main MIDlet manager thread. In general, they recommend the usage of a Chinese tool JavaMagic, which is supposed to help J9 and/or TAO users run their titles. In addition, the also recommend some always-on-screen numeric keypads to help numeric input and, finally, two other tools as well for MIDlet conversions. We’ll soon see whether JavaMagic is able to help at all and what you should do instead of using on-screen virtual keyboards. In addition, I – a veteran Java programmer and instructor – also explain what the control problems are caused by and why TAO and IBM J9 behave so strangely.
1.1 How it does work behind the curtains & fixing the problems with external hardware button assignment
First, let’s take a look at what problems you will face. This section will contain some references to Java; that is, the language the MIDlets are written in. Note that you can safely skip this section if you don’t know the language. If you do know it, or, at least, have some knowledge of how programming languages work, you might find this section pretty interesting.
A MIDlet, in general, implements the callback method ("function" in the traditional, non-OOP parlance) keyPressed(), which is called back when a button is pressed. This method is passed an integer (numeric) parameter denoting the actual ASCII character (or, with non-character input, scan, denoted by negative numbers) code of the button that has been pressed. If you’ve done any actual programming in any language (or are just computer-savvy), you will certainly recognize the ASCII character code values 48, 49, 50 etc. it typically has: yes, they correspond to the 0, 1 and 2 buttons, respectively (and the list continues).
Most MIDlets don’t directly act on this direct code, but give a call to the getGameAction() (a method in the superclass javax.microedition.lcdui.Canvas) to make the MIDlet manager convert this code to a symbolic constant. This is, in most cases, a much safer way to decide what has happened (what button was pressed). The sole reason for this is the following: D-pad-less phones (and many users) use dialpads (2 for up, 8 for down, 4 for left and 6 for right) instead of D-pads. This, unfortunately, results in different ASCII character / button scancodes returned. Using getGameAction() guarantees that these different codes (for example, except for TAO, the scancode -2 (with TAO, -57378) for the down arrow of the D-pad and the ASCII code 56 for the numeric button on the dialpad) are reported as DOWN events, independent of their original (numeric) value.
There are, unfortunately, some MIDlets that, at least in the menus, don’t adhere to this convention – that is, they don’t give an additional call to getGameAction() but try to directly process the parameter passed to keyPressed(). One example is Andreotti Racing (see "!!!3D_Andretti_ Racing_240x320.jar" in the main game compatibility chart), where the menus MUST be controlled by the dialpad (or numeric hardware keys), NOT the D-pad.
Also note that, regarding the special case of TAO, some games (for example, "!!3D_Micro_Counter_Strike_Beta.jar") might be hard-wired to both, most common D-pad and dialpad codes (again, -2 and 56 for downwards), instead of calling getGameAction(). These games will work just great with most MIDlet managers utilizing; however, TAO, which uses special D-pad scancodes (for example, -57378 for the "down" arrow, as opposed to the standard -2), D-pad-based control won’t work, only that of the (even virtual) dialpad. This is why this particular game can’t be controlled by the D-pad, only the hardware dialpad (or any software button input solution) under TAO, while, under all the other M3G-capable MIDlet managers (Nokia N95, Jblend, Jeodek M3G), you can use the D-pad for steering the car.
Fortunately, there is a very easy solution for all these problems. If you encounter a MIDlet that can only be controlled by (virtual) numeric keys (because, again, the game doesn’t use the additional getGameAction() call to be compatible with as many different KVM’s as possible), you might still add D-pad controllability by just using a button enhancer tool capable of redefining the four D-pad directions (currently, they’re PQzII, AEBPlus and the non-WM5-compliant buttonMax) and either the (slower) MortScript or the faster VJKeyPress to generate the actual keypresses – or, if you go with PQzII, the built-in keypress simulation feature.
This also applies to the great Web browser MIDlets Opera Mini and Opera Mini Mod, which add a lot of (with the Mod version, freely redefinable) shortcut functionality to (numeric) phone buttons. As they are inaccessible on Pocket PC’s without any kind of keyboard and pretty hard to access on phones with a slide-out keyboard (you always need to slide it open to be able to access the numeric row), in these cases, you WILL want to use external tools to simulate the dialpad button press using the hardware application buttons.
You can find extensive information on all this (assigning the simulation of dialpad keypresses to hardware application buttons or D-pad arrows) in the Button Enhancer Bible. Please do make sure you read it very thoroughly. Here, therefore, I don’t spend more time on this question.
1.1.1 On-screen dialpads – are they of any use?
As has already been mentioned, one of the 4pda tutorials (original (volta_john, 26.11.06 10:19:44); Babelfish; Google Translate) recommends installing on-screen dialpads for inputting numerals. I don’t think this is a good idea. First, you’ll need to run significantly smaller MIDlets than the native resolution of your screen so that the active MIDlet area and the always-displayed keyboard don’t overlap. This means you’ll need to stick to (at most) 176*220 MIDlets on your QVGA and QVGA or 352*416 (the hi-res version of Nokia’s traditional 176*208 screen) titles on your VGA Pocket PC’s. And, of course, you won’t be able to run MIDlets that stretch themselves dynamically to fill in the entire screen. This alone would make you forget the entire thing. Second, you’ll need to click on-screen buttons instead of just pressing the D-pad directions – as you otherwise would prefer. A pretty awkward way to control particularly games, isn’t it?
Note that you can avoid having to stick to significantly smaller MIDlets than your screen estate really is if you, as opposed to what the 4Pda tutorial recommends, a numeric input panel (or, if you don't mind the horizontal layout in no way representing a real phonepad) only brought up when necessary. I recommend assigning it to a hardware button (just assign <Input Panel> to a hardware app button in Settings / Buttons; this doesn't even require that you read and understand the Button Enhancer Bible); this will be particularly important with MIDlet managers that, on Pocket PC's, don't dispay the bottom bar and/or the icon to bring up the on-screen input panel any time (not only when a text input field has the focus.)
1.1.2 A full chart of all MIDlet manager scan/character codes & the return values of getGameAction()
I’ve also written a small MIDlet to display what the passed code before and after the getGameAction()-based translation are. As usual, I also provide you with the source of the MIDlet. The deployable JAR file is HERE. It’ll, first, display the numeric, and, then, the symbolic name of the return value of getGameAction(); finally, the original, unprocessed, original keycode. It also makes the system dynamically assign "Exit" to one of the two softkeys; the scancode of the other softkey (and, with Jblend, also the one which results in exiting; this is because of the differences in the callback processing order) will be displayed.
For example, upon pressing "2" on the dialpad, hardware or on-screen keyboard, if you see "1: UP: 50" printed on the screen, this means the following: getGameAction() returned the integer 1, which corresponds to the constant "UP". The original character code (it’s a positive number; therefore, it’s a real ASCII character code) 50 ("2" in ASCII). This is what you will see in all cases, with all MIDlet managers, except IBM J9, where this button, as with all other keypad numeric buttons, are unhandled and, therefore, no matter what numeric dialpad button you press, getGameAction() returns 0 ("Unknown"). Yes, you’ve read this right: the dialpad handling in IBM J9 is severely messed up: IBM J9 can ONLY be controlled via the D-pad, unlike with all the other MIDlet managers.
If you press the button 1, "0: Unknown: 49" means getGameAction() returned 0, which corresponds to the unhandled (unknown) case and the original character ASCII code was 49. This is the case with all MIDlet managers except Esmertec’s managers and Jblend, which assign one of the four gaming buttons, GAME_A, to the first dialpad button.
If you press the up direction on your D-pad, you’ll see the following with all MIDlet managers except TAO (the latter uses special scancodes):
"1: UP: -1"
This means getGameAction() returns 1, which, as we’ve already seen, corresponds to the "UP" symbolic constant. Finally, the scancode (it’s negative so it’s not a "real" character code) of the given D-pad direction is -1.
As has already been stated, TAO is behaving differently in this case (too); it’ll return
"1: UP: -57377"
instead. This, as has already been pointed out, is caused by TAO’s using entirely different scancodes than all the other MIDlet managers. Fortunately, this is correctly translated by getGameAction(). Still, if you try to play a game (for example, the already-mentioned Micro Counter Strike 3D Beta) that doesn’t give a call to getGameAction() but directly parses the actual argument of the keyboard handler (for "up", the ASCII code (50) of the dialpad 2 and/or the D-pad "up" scancode -1), it will most likely not work under TAO.
Note that the chart below, which shows how the different Windows Mobile (and, in addition, as a well-implemented, high-quality reference, the MIDlet manager coming with the Nokia’s current top-of-the-line, flagship model, the N95 and its newer versions like the N95-3 and the N95 8GB) MIDlet managers fare in this respect. Now, based on all explanations above, you’ll be able to understand what this all means.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
1.2 Strictly softkey issues & JavaMagic results
OK, now, from the D-pad and dialpad-related questions, let’s move on to the question of the WM5 softkeys. As you’ve probably realized if you’ve ever tried to deploy MIDlets under TAO, the right/left softkeys simply won’t work with most of them.
Note that the 4pda.ru folks state the TAO 11.x series, finally, fixed at least the softkey problems (as opposed to the 10.1 series); in this regard, I don’t think they are right.) Unfortunately, this is impossible to fix using the same method as above - that is, just assigning a scancode generator to the two soft buttons with a softkey-assignment-capable button enhancer or, if you don’t necessarily want them to be assigned to hardware softkeys, with any button enhancer – and even the built-in Buttons settings applet. The sole reason for this is that MortScript is only able to pass positive "scancodes" (that is, real characters) and the other two solutions, namely, PQzII and VJKeyPress, aren’t able to pass these particular scancodes either.
Unfortunately, these softkeys,
with several MIDlet managers (namely, the one coming with the Nokia N95, IBM J9, later – non-M3G-enabled – Esmertec Jeodek versions and TAO running on Pocket PC’s (but not on Smartphones)) don’t cause a callback to keyPressed() and,
in the rest of the MIDlet managers (that is, the ones where keyPressed() is called back) getGameAction() returns zero ("Unknown") upon trying to identifying them,
unlike with "traditional" direction, action and/or fire buttons where getGameAction() is the preferred way to see what really has happened and to guarantee compatibility with as many different MIDlet managers as possible. This all means MIDlets themselves must deal with direct scancodes and there're no helper methods (no getGameAction()-alikes) to guarantee cross-KVM compliance. As these codes are pretty much standardized, they have no problems with the Nokia / Esmertec / Jblend ones; this is why they do work. TAO, on the other hand, is, again, an exception, as it uses vastly different scancodes than any else MIDlet manager. This is why the softkeys of the vast majority of MIDlets, unless they have specifically been developed keeping TAO compliance in mind (the case with high-quality business / productivity apps like Opera Mini, the Gmail MIDlet etc.), will NOT work under TAO.
1.2.1 JavaMagic – is it really any good?
The related 4PDA.ru tutorial ((volta_john's post at 23.05.07 08:25:07) ; Babelfish; Google Translate) recommends the use of JavaMagic to fix this problem.
I’ve thoroughly tested JavaMagic with several games running on TAO with TAO unable to handle their softkeys (see their list in the main game compatibility chart). As it has turned out, in no configuration did TAO Intent become compatible with these titles. It was only in one case that the Action button became usable after the translation (TAO Intent uses a different keycode – it passes the ASCII code 13 instead of the industry-standard -5 scancode). In no other cases did any of the keys, let alone the softkeys become usable. Again, these tests were VERY thorough and, in most cases, I’ve tried to make the MIDlets compatible with TAO Intent with at least two (Nokia and Sony-Ericsson source compatibility mode) input configurations. The output configuration, of course, was that of TAO.
Because of these very bad results, I don’t think you should waste any time with JavaMagic. It simply won’t work. This is why I don’t present you any tutorial for JavaMagic either. Even if you don’t know Russian, you’ll be able to follow the really thorough tutorial in the above-linked post, particularly now that I’ve provided you with two different "translations". But, again, it’s highly unlikely it’ll work with you.
Following is the chart of my JavaMagic tests:
Note that there are two other MIDlet conversion suites, Motomidman and FullJava, explained HERE (rendor, 30.10.06 00:35:31) (Babelfish; Google Translate). They, however, seem to help even less than JavaMagic.
1.3 Summary
In this chapter, I’ve given you a detailed description of why
the left/right softkeys of the vast majority of MIDlets refuse to work under TAO Intent and the fact that this can't be helped
there are MIDlets that can only be controlled with dialpads but NOT D-pads in all KVM's
there are MIDlets not controllable with anything, not even dialpads, under J9 (again, J9’s getGameAction() returns "Unknown" for all dialpad buttons – a very bad KVM implementation in this respect)
why some MIDlets don’t support the D-pad under TAO, while they do support it under all the alternative KVM’s
To fix all these problems (except for the softkey problems of TAO Intent, which, based on my tests, do seem to be unfixable), I’ve also explained you’ll need external button enhancer and/or ASCII and/or keycode "injectors", as opposed to what, so far, has been recommended (that is, on-screen keyboards / dialpads).
Midlet Adaptation
Well, I asked Menneisyys about posting this, and was told to go ahead, so why not. One of my only posts here, and first time writing a guide for something like this so please bare with me.
Note: - Credit for the information in this guide goes out to Adolescent of HowardForums, UncleRUS, and the developers of JAM. I just compiled it in a more user friendly form with my own notes and shortcuts added.
Many people have complained before about installing this or that Java game on their phone, only to find that the keys partially work, or won’t work at all. Fear not! There is a way to solve this for those willing to put in a little effort and time.
There's no way to do it without modifying the game classes themselves (and inserting a bit of your own code), but the end result is well worth it. I’ve personally adapted well over 60 games for my Motorola E815, and then re-adapted them to work on my HTC Titan. I’ve included with this post a copy of the Keycode chart we compiled to aide in adapting these games.
In a nutshell, you must create a new class based on the javax.microedition.lcdui.Canvas (or GameCanvas, depending on what the game in question is using). Then you handle the keyPressed, keyReleased, keyRepeated, and getGameAction methods catching the PPC’s keycodes and passing the game class whatever keycode it's expecting.
For examples of what that means, refer to the post above this one. Thankfully, most java games use a standard template, and most JVMs for the phones, also use that template. (I know if a game runs fine in the Emulator I’ll be explaining, then it will work just as well on my Titan) If you haven’t yet, get a Midlet to show you your keycodes. I’ve included one in this post as well. Install it on your device and check what the directional keys/soft keys are. Chances are they’ll match up with either the “Emu” ones, or one of the other phones listed in the included chart.
Here's were the fun begins. Do not read beyond this if you don’t have patience, or the time to tinker and figure things out. You’ll only frustrate yourself.
Tools Used: (what I use)
Java SDK 1.5 (Or whatever the latest one is)
The latest JRE (Java Runtime Environment, free from Java’s website)
Sun Java Wireless Toolkit 2.5 for CLDC (free off the Java Website.)
Hex Editor (XVI32, freeware)
Archiver (WinRAR, trial version works fine)
JadMaker (Freeware)
So, first off, install everything. Personally, I kept it all in one spot, and made shortcuts to everything there so I could have my own little workspace.
Launch JadMaker, click and drag your Java game (the jar file) into it to get a proper working Jad file.
Launch the Java Wireless Toolkit, and go to “File” – “Create Project from Jad/Jar File”, and pick your new Jad.
This will create a folder with your games name in the “Apps” folder wherever you installed the toolkit. I installed mine to C:\Key Fixer\, so my path is “C:\Key Fixer\WTK25\Apps\<Game>\”
Click “Run” and give the game a shot, see if it works. Most games will work as is. You may get an error on same games about a missing “Nokia/mid/ui/FullCanvas.class” file. If you get this, refer to the “Other Notes” below.
Now we need to find out what class your game uses for its keys, and what style Canvas to use. So we switch over to XVI32.
After you load up XVI32, navigate over to \WTK25\Apps\<Game>\Classes. There may be a few, or there may be many. Don’t let it intimidate you. Start with the first class file, and do a search for “key”. If it doesn’t find any results, move on to the next. What your looking for are the keyPressed, keyReleased, or keyRepeated sections. Once you find a file with one or more of those, start over in that file and look for Canvas. You may find Canvas, or GameCanvas, and that will dictate what template to use. (Note: if you find BOTH Canvas and GameCanvas only work with the GameCanvas file.)
In the file your in, you need to make these changes now.
Search and replace: (case matters)
keyPressed
with
KEYPRESSED
keyRepeated
with
KEYREPEATED
keyReleased
with
KEYRELEASED
Now change one of the following.
If you’re working with “Canvas”,
javax/microedition/lcdui/Canvas
with
com/motoroladapter/patch/CANVAS
If you’re working with “GameCanvas”,
javax/microedition/lcdui/game/GameCanvas
to
com/motoroladapter/patch/game/GAMECANVAS
Once the changes are made, save the file and close the editor. Then copy the appropriate text file (canvas.java, or gamecanvas.java) into the \WTK25\<Game>\src folder. Open it with notepad, and make sure the key mappings match your findings for your device.
Back in the Wireless Toolkit program, click the “Build” button to compile the new class file, then click “Run” to test it out. This will load up a nice full phone emu, so play to your hearts content to make sure all is well. (This is also a great way to see if the game is one you’ll like before flooding your phone with it!)
Assuming everything is working okay now, use WinRAR to open the ORIGINAL .Jar file (NOT the one in the \WTK25\<Game>\Bin folder!), move that window to the side, and go into the \WTK25\<Game>\Classes folder, and click drag the new “com” folder, and the class file that you modified earlier with XVI32 into the WinRAR window.
Now you have a modified Jar file to put on your phone!
Other Notes:
When you try some games you may see an error about a missing nokia/mid/ui/fullcanvas.class file. If this is the case, use the attached rar file to place the “com” folder inside of your \WTK25\Apps\<Game>\Classes folder, then try the game again. It’s the Nokia API the game is looking for. When you do this, be aware that you will still have to edit the keyPressed, keyReleased, and keyRepeated sections, but that the file with the Canvas lines you’re looking for will be the FullCanvas.class file you just added in.
If you're getting IllegalArgumentExceptions it's because getGameAction is getting illegal values sent to it by the new code. (Some games work fine and ignore these, others don’t) Try changing the getGameAction method to this:
public int getGameAction(int i)
{
return i;
}
(In the files I included, the getGameAction function alread has both versions of the return in place, just one is commented out with “ // “, so just take those off and put them before the other one)
Hope that helps someone with getting some new games up and running! If you have questions, let me know
Artlan, you're GREAT! Thanks for the tutorial!
hi
first thanks for the good job
now i did as you said but in the part that i save the modified myclass.class after that i don't see any canvas.java files being created, i even tried the saved as but the created file is not readable
can you help me out thanks
(trying to run burnout on my i-mate jasjar)
aminfri said:
hi
first thanks for the good job
now i did as you said but in the part that i save the modified myclass.class after that i don't see any canvas.java files being created, i even tried the saved as but the created file is not readable
can you help me out thanks
(trying to run burnout on my i-mate jasjar)
Click to expand...
Click to collapse
IIRC (can't really chck it now because I'm writing this on my N95, using a slooooow GPRSD connection) several KVM's run Burnout without key problems. that is, you don't need to use TAO. Did you read the MIDlet Bible?
The 'canvas.java' file doesn't get created, it's a pre-generated text file I included in the archive attached to the post. Hope that helps
Artlan,
Thank you very much for your amzing tuturial, it really works with i-mate.
just a little addtion for tolls, you will need also java sdk 1.5 for wireless toolkit to work
Thank you again
Thanks, I completely forgot about the SDK because I already had that installed for other things Glad you got it working on the i-mate!
Related
Opera on the Pocket PC - a setup tutorial & quick review
A lot of PPC users have noticed on all the PPC boards that an already-usable preliminary version of the Opera browser has become available. As it's Java MIDP-based, people had serious problems with installing/running it. This is why (I'm a Java guru, so, I made it work in some seconds) I decided to write a tutorial and, being an avid PPC browser and compression service user, also a quick review of the app, comparing it to the other Pocket PC Web browsers. 1, download the IBM J9 (you can also give a try to the CrEme JVM (see the above-linked Java article) - I haven't tested Opera with that JVM. With the IBM J9, it's woking just great). Go here, choose the link "Trial: IBM Workplace Client Technology, Micro Edition 5.7" and navigate thru the 3 pages, by loging in / registering with IBM. On the third page, scroll down to "WebSphere Everyplace Micro Environment MIDP 2.0 for Windows Mobile 2003" and download it. Alternatively, you can download the same package from Handango, but it's much bigger in size than the one at IBM, so, you may want to stick to the latter. Note that the HTC PDA + mobile combo has its own MIDP JVM (see the XDA-Developers thread). It's not available for non-HTC branded devices, however (AFAIK!), so, you'll need to stick to third-party solutions (and it's pretty futile to go to http://www.dmmh.nl/xda/files/ , as recommended in the XDA-Developers thread, to look for the JVM). Install (you may want to install it on a storage card) and everything will be OK. (Contrary to what most people say, you will NOT need to download WebSphere Studio Device Developer in its entirety! The Handango download may also include parts of it; hence the size.) 2, get Opera from here - sorry, as I was told this distro isn't necessarily legal (even if it's an early beta version, which may be much worse than the final), I've removed the direct link to it. 3, if/once you have Winrar on your PC, just enter winrar opera-mini.rar. Click the 'Extract' icon in Winrar and press Enter. The files will be extracted in a directory named opera-mini. 4, transfer the files Opera_Mini_low.jad and Opera_Mini_low.jar to your PPC; to, say, \My Documents 5, invoke File Explorer on the PDA, and click Opera_Mini_low.jad (the smaller file). 6, IBM J9 will automatically be invoked and the MIDLET installation started; just keep pressing OK/Yes: { "lightbox_close": "Close", "lightbox_next": "Next", "lightbox_previous": "Previous", "lightbox_error": "The requested content cannot be loaded. Please try again later.", "lightbox_start_slideshow": "Start slideshow", "lightbox_stop_slideshow": "Stop slideshow", "lightbox_full_screen": "Full screen", "lightbox_thumbnails": "Thumbnails", "lightbox_download": "Download", "lightbox_share": "Share", "lightbox_zoom": "Zoom", "lightbox_new_window": "New window", "lightbox_toggle_sidebar": "Toggle sidebar" } 7, after this, highlight Opera at the top: and press the Launch button at the top. Opra will be started and some Noregian text displayed; just click OK in the lower left corner. 8, go to Meny/Verktøy/Innstillinger and click the Norsk at the bottom of the list in the top of the window. Choose English from the top of the list. Click Lagre. 9, now, you can start browsing. You'll get used to the interface very fast. It's pretty different from other browsers (there're no Some remarks: - it's astonishingly fast, especially at rendering small images, which has always been one of the weakest point of PIE - don't be afraid of the lack of 'traditional' form components. Everything is a simple text field here, even text areas, as can be seen in the following screenshot: - if you install opera.ja* instead of Opera_Mini_low.ja*, it won't be able to communicate with the server, for some reasons (dunno why; didn't really have the time to track the cause for the bug. The 'full' version isn't much better than the 'basic' - it has a graphical command bar and - pretty slow - character antialiasing features. Upon popular request, I may look into the problem, even on the Java source level. Let me know if you want it to work.) - upon the first request, it asks whether it should use the "airtime". Just leave the default 'Yes' intact: - use some kind of task manager to return to the app (for example, the built-in Task Switcher in Spb Pocket Plus 3.0 - incidentally, if you use it, you may want to relocate it from the RAM - see this thread) if you minimize the J9 window by mistake - native VGA mode works great: - dynamic Landscape orientation change doesn't work with IBM J9; just restart J9 in Landscape and everything will be OK - everything is one column-only, but still very nice to read, much nicer than the output of, say, Skweezer or its online alternatives. And the speed difference is just breathtaking! - JavaScript support is good; however, don't expect Google Maps to run, however - inter-session cookie handling is good; they are stored in \My Documents\recordStores - I couldn't spot any kind of local caching (Thunderhawk/Minimo doesn't use any local cache either) - there is no Java support either - no in-page find, not even text select/copy. Copy/paste works great in text fields, though. - don't try to force the two IBM J9 EXE files (IBM MIDP20\bin\emulator.exe / IBM MIDP20\bin\j9midp20.exe) into forced VGA. It'll result in the disappearing of the upper/lower bar; the lower bar being the command bar with buttons to use, you won't be able to use the app at all: 10, upon subsequent starts, you don't need to re-click the jad file again; just run "MIDLet HQ" and go to step 7 above. I've tested it on both WM2003 (iPAQ 2210) and WM2003SE (PL720) with J9; works great so far. Even in its current form, this application is great and, despite its being Java-based, incredibly fast. You may also want to read my article on the other browsers available and the above-mentioned Reducing Internet bandwidth usage on the Pocket PC - A complete roundup & comparison of Toonel, OnSpeed, Skweezer, WebWarper and the like so that you can compare. Especially compared to the solutions (Skweezer et al) in the latter category does Opera excel.
not tested yet, but you did pretty nice job! thanks
Dude, if you take the "inverted commas" out of your URL tags then they'll come up as links properly. Little hard to follow the top section!
jimmy-bish said: Dude, if you take the "inverted commas" out of your URL tags then they'll come up as links properly. Little hard to follow the top section! Click to expand... Click to collapse Yup, removed them.
Since this is in the Magician section of the forum, here is how I did it on mine: I installed the Java Midlet Manager that was in my Extended ROM untill I did the Big Storage thing. If you still have an Extended ROM instead op Big Storage, then you don't need to install this one. I just downloaded it from the ftp and installed it on my MDA Compact. Then I downloaded the Opera-mini.rar, unrarred it on my pc, copied the 4 files to my Magician's storage and opened the Opera_mini_low.jad. Opera was installed and every time I open my Midlet Manager, Opera is there. One click and it gets started. Maybe this is easier then installing the IBM solution? Perhaps I am way off, but installation like this seems much easier to me...
Koksie said: Since this is in the Magician section of the forum, here is how I did it on mine: I installed the Java Midlet Manager that was in my Extended ROM untill I did the Big Storage thing. If you still have an Extended ROM instead op Big Storage, then you don't need to install this one. I just downloaded it from the ftp and installed it on my MDA Compact. Then I downloaded the Opera-mini.rar, unrarred it on my pc, copied the 4 files to my Magician's storage and opened the Opera_mini_low.jad. Opera was installed and every time I open my Midlet Manager, Opera is there. One click and it gets started. Maybe this is easier then installing the IBM solution? Perhaps I am way off, but installation like this seems much easier to me... Click to expand... Click to collapse Yup, I've also emphasized this. This article is just a cross-post of a post I've also posted to other PPC forums - this is why it doesn't contain much Magician-related stuff. (I know - I should have posted this in a generic forum here too and not "just" to the Magician forum.)
Not working in landscape? I get some weird screen draw on the right hand side?
CAB installer IBM Workplace Client Technology? Is there a CAB installer IBM Workplace Client Technology, Micro Edition 5.7 as the 40mb installer does not seem to install on my machine?
Re: Opera on the Pocket PC - a setup tutorial & quick re Menneisyys said: A lot of PPC users have noticed on all the PPC boards that an already-usable preliminary version of the Opera browser has become available. Click to expand... Click to collapse Since i'm one of the official Opera translators (i translate the italian version for windows, unix, series60, ezx, archos, opera mini, etc) i'd like to point out that the version we're talking about is called Opera Mini. Opera Mini is a java application (or midlet, i'm not a Java guru!) intended to run on any MIDlet-capable mobile device out there (most mobiles are). The final official (and localized) release will be available very soon (i've been translating it in these last days). As Menneisyys correctly pointed out, there exist two versions: a low-mem and a high-mem one. I think the high-mem should work on our magician (the low-mem is intended for those slow and memory-limited mobiles) however the beta currently available may have some problem (or, maybe, the MIDlet manager you're using). Now, I wish to make clear that Opera for PocketPC is a completely different product from Opera Mini. It'll be a PPC native program and will be released soon after (AFAIK) Opera Mini. I wasn't able to get more information about it (but i'm still trying!), so I cannot say whether it'll be WM 2003 SE compatible or it'll run on WM 5 only. Opera for PocketPC will be ways better than Opera Mini and won't require any MIDlet manager (it's not a Java application!). From this point of view, it'll be more similar to Opera for smartphones or Opera for Series60 (Nokia, Symbian) than to Opera Mini. As soon as i'll know more about Opera for PPC, i'll keep u informed. Bye bye, Isidoro
Opera8.5 for WM2005 is available now.So i guess the 2003 version is not far...
Available for the smartphone ...the WM5.0 and 2003 versions on their way according to website....you can try the beta version however
"Wrap" a Today plugin
I have a little project in mind, but would like some input from the pros to cut research time: Is it possible to "wrap" a Today plugin dll with another, providing a "pass through" for operations (such as screen taps, etc)? What I'm trying to accomplish is this: Add selectability and other one-handed d-pad operation to an older plugin that is not selectable. What do you think?
it's possible but the problem is that the plugin have to keep track on what plugins it include and which handles it have to pass to them could end up big and slow
Rudegar said: it's possible but the problem is that the plugin have to keep track on what plugins it include and which handles it have to pass to them could end up big and slow Click to expand... Click to collapse This is specific to a single plugin - it would only keep track of one. Perhaps plan B would be easier - a plugin that manipulates another plugin. Such that it would "appear" the older plugin was selected, etc. I guess I'd better go study some more...
Actually its really simple. Any plug-in DLL exports a function called InitCustomItem. In this function the plug-in does all its initialization, and creates its window. The return value is the handle to this window which you can subclass to add functionality. as for selection, there is a value in the registry for each plug-in (HKLM\Software\Microsoft\Today\Items) which controls whether the system passes selection events to the plug-in or not. it has three settings: 0 - non selectable, item will be skipped by the system. 1 - Automatic, the system will paint the item and handle selection on / off 2 - Manual, the system will pass the selection event to the item and the item will take care of the rest. In this mode the return value of the WM_ACTION determines whether the selection is moving on. This is good for multiline plug-ins that don't want to give up focus when arrow keys are pressed.
levenum said: Actually its really simple. Any plug-in DLL exports a function called InitCustomItem. In this function the plug-in does all its initialization, and creates its window. The return value is the handle to this window which you can subclass to add functionality. as for selection, there is a value in the registry for each plug-in (HKLM\Software\Microsoft\Today\Items) which controls whether the system passes selection events to the plug-in or not. it has three settings: 0 - non selectable, item will be skipped by the system. 1 - Automatic, the system will paint the item and handle selection on / off 2 - Manual, the system will pass the selection event to the item and the item will take care of the rest. In this mode the return value of the WM_ACTION determines whether the selection is moving on. This is good for multiline plug-ins that don't want to give up focus when arrow keys are pressed. Click to expand... Click to collapse Hey, thanks for the response! I've set the Selectability registry item for the older plugin, and it's ignoring it - that's what started me on this little project. I'm a software developer by trade, but not with C++, so I don't want to waste people's time here asking a lot of dumb questions. If you could point me in the right direction on a couple of things, I'll go off and learn: 1. If all I have is a dll and nothing else (no .defs, etc), can I determine all of the functions it exports (other than InitCustomItem)? 2. Process check: My custom plugin's InitCustomItem would call old-plugin's InitCustomItem, snagging old-plug's hwnd. New-plugin would then initialize it's own window - transparent(?) and pass that hwnd back to windows. Also, my custom plugin would pass all messages to old-plugin, etc. Theoretically, old-plug would look and operate like normal? If this is already written, just sent me the code!
Well I am afraid it will be difficult to do all this without C++. As far as WM based devices are concerned you need to use something that translates in to native code to create system components like the plugins son ,no .NET languages, and embedded VB doesn't do well on anything never that WM 2003 (not even SE), plus I am not sure if you can make DLLs with it at all. To your questions: 1) There is a tool which comes with VS 6 called Dependency Walker. It shows you what functions a given DLL exports, what it imports from other DLLs and what DLLs it is link to. Woks on EXE files as well. If you can't get that, download a demo of IDA 5. It's the most powerful disassembler for WM devices out there. 2) Not sure, I never tried anything like that. The thing is, the system resizes the plugins, on initialization (it controls height) and when screen rotation changes so if you pass back HWND for a window other than the one visible, it might cause some problems. I think what you should do is learn about subclassing. It's when you replace the procedure of an existing window with your own (just replace the function, not create new window). You then get all the messages for that window, you can do what you want and call the original function when you done. By the way, if you want to learn about writing plugins there is an article with code samples on this site: www.pocketpcdn.com and a lot of other interesting stuff. Good luck.
What plugin is it? It might be easiest just to rewrite the plugin if you've got the code. V
levenum said: Well I am afraid it will be difficult to do all this without C++. Click to expand... Click to collapse I should have been more clear - I am using C++, I'm just have to learn how to program with it first! vijay555 said: What plugin is it? It might be easiest just to rewrite the plugin if you've got the code. V Click to expand... Click to collapse I don't have the old-plugin source code. My little project is to add some sort of d-pad operation to the WeatherPanel plugin, which you're probably familiar with. Progress: I've written and deployed my first little plugin - based on the source code samples available in the internet. Next step: In my InitializeCustomItem, I thought I'd try to call WeatherPanel's InitializeCustomItem (instead of creating my own window). Thing is, I don't yet know how to properly link the WeatherPanel dll to my project. As expected, it only exports two functions: InitializeCustomItem and CustomItemOptionsDlgProc (I used dumpbin.exe) I'll keep plugging away - any input would be appreciated. Thanks for your help!
It's real easy: Use LoadLibrary and GetProcAddress functions to call functions in other DLLs without linking them.
levenum said: It's real easy: Use LoadLibrary and GetProcAddress functions to call functions in other DLLs without linking them. Click to expand... Click to collapse What a coincidence! My studying led me to the same functions. From within my plugin's InitializeCustomItem, I was able to successfully load the dll with LoadLibrayl, GepProcAddress of its InitializeCustomeItem (at ordinal 240) and call it. But it whacks the Today screen so that none of the plugins load. Next I thought I'd try FindWindow and EnumChildWindows to find it and all it's children. Then manipulate them by sending messages...
storyr said: What a coincidence! My studying led me to the same functions. From within my plugin's InitializeCustomItem, I was able to successfully load the dll with LoadLibrayl, GepProcAddress of its InitializeCustomeItem (at ordinal 240) and call it. But it whacks the Today screen so that none of the plugins load. Next I thought I'd try FindWindow and EnumChildWindows to find it and all it's children. Then manipulate them by sending messages... Click to expand... Click to collapse Update: So far, so good. As it turns out, EnumChildWindows doesn't work on the PPC, so I used GetWindow to find the plugin's handle. I can successfully send messages to it and initiate various actions. Question: I'd like to visually indicate (on the old-plugin) what's being clicked (such as drawing a box around it). Is it possible to draw things outside of my own window?
It is, but it's tricky. You can always use the GetDC function to retrieve the DC for another window and paint on it, but the problem is that unless you subclass the window you have no way of knowing when it repaints it self and all your changes are erased.
levenum said: It is, but it's tricky. You can always use the GetDC function to retrieve the DC for another window and paint on it, but the problem is that unless you subclass the window you have no way of knowing when it repaints it self and all your changes are erased. Click to expand... Click to collapse I tried that exact thing (GetDC) and drew a rectangle in it, but it didn't do anything. I realized the reason was the WM_Paint event wasn't firing on old-plugin, and when it did, my stuff was erased (just like you said). Next idea - open my own dialog window than overlays old-plug. The entire window needs to be transparent - except for the visual indicators that I position where I want. When the user ok's, I close the window and send the click to old-plugin... Thanks again for keeping tabs on my progress..
No offence, but with all these rather advanced programming tricks you are attempting just to "sup up" an old weather plugin it looks to me like you would be better off just writing the whole thing from scratch. It you are familiar with WinInet and / or sockets this should be pretty easy and it will look and work much better than the hack you are attempting now. Plus you can make it exactly the way you like.
levenum said: No offence, but with all these rather advanced programming tricks you are attempting just to "sup up" an old weather plugin it looks to me like you would be better off just writing the whole thing from scratch. It you are familiar with WinInet and / or sockets this should be pretty easy and it will look and work much better than the hack you are attempting now. Plus you can make it exactly the way you like. Click to expand... Click to collapse No offence taken. I thought of that, but I figured this would be a good way to cut my teeth a little. Once I complete this little project, I may pursue that route... Question: Do you have a favorite forum (or forums) besides this site that you use for your research/programming questions?
This is my favorite forum But here are couple more sites I found very valuable: www.pocketpcdn.com - They have tips and tricks with code examples arranged in categories like how to make MFC dialogs not full screen or the one I used in LVMTime to put the clock back on the taskbar. www.codeproject.com - It's not specific to WM development but has tons of interesting stuff including entire sources. You should also check out www.buzdev.net If you're not familiar with the great work of buzz_lightyear you should see some of the stuff he did for this forum like grab_it - the invisible ROM dumper.
OT Just a quick OT question: If I would move some of the plugin-dll's from \Windows to \Storage Card, would it be enough to change the adress within the corresponding item in the registry entry HKLM/Software/Microsoft/Today/Items ? Of course I'm not talking about plugins like tasks a.s.o but rather third party plugins Cheers hrb
It won't work. The problem is that the SD card is mounted too late so if you put the plugins on it they will not be loaded when device boots up. You can move them to the extended ROM this way or to a folder other than windows but there is no way to move start-up stuff to SD.
Thanks for the help with this "little" project. After many hours, the product is out for beta testing. When it's released, I'll post more info...
Finished! It's finished. The app is called WP-Pilot and it provides one-handed operation of WeatherPanel. If anyone's interested, it can be found here. Here's how it ended up: There's a plugin (WP-PilotPlugin.dll) with an options dialog, and an executable (WP-Pilot.exe). When the plugin gets selected, it looks for Weatherpanel. If it finds it, it fires off WP-Pilot.exe WP-Pilot.exe opens. It does this stuff: Look for WeatherPanel, and get it's screen coordinates. Read the registry and determine which layout file WeatherPanel is using. Open the layout file and read it: Record the coordinates of each "clickable" item found. This was a real PITA because of Unicode. Sort the coordinates for left-to-right, top-to-bottom order. Select the first coordinate and position a tiny window (10x10) at that x-y position. Draw a "pointer" in the window (the type and color depends on what's selected in the options). Show the window and process input: [*]Left/right pressed - selected the next/previous coordinate and move the window to that location. [*]Up/down pressed - close WP-Pilot and tell the plugin we're done. [*]Center button pushed: [*]Send a mouse click to the WeatherPanel plugin at the coordinates [*]Close WP-Pilot and tell the plugin we're done. Thanks again for your help!
Smart KeyCaps Facility for TyTN
Disclaimer (1): I posted this previously on a Hermes specific forum in late 2006, but I'm sure that's pretty much for users who tend to look for finished solutions, not programmers looking for challenges. Disclaimer (2): I used to program back in college and in the first 10 years of my professional career (some of my code is still in the kernel of commercial U*X boxes from IBM and the base 486 AT&T SVR4 distribution). Also, I'm referenced a lot in the Lisp language newsgroups. Will this at least get my grandfather rights to post a request on this forum? I'd love for the Hermes to have the same power as my Treo 650 keyboard did. There was a program called TreoCaps. It operated thusly.... When typing letters, using the normal keyboard press, a normal key was inserted (usually lower-case, unless auto-caps was on). If you pressed the key down for like 300ms, it would change into an upper case. If you held it down for 600ms, it would change to the symbol character assigned to that key. The blackberries have a similar function (which the TreoCaps program actually stole the idea from). Has anyone written such a hack for the Hermes or WM5 w/ keyboard devices in general. I've gotta believe so, since in my recent experience with wm5, it's (a) a real multi-tasking operating system, and (b) it's loads more extensible than POS is. Thanks, -Humbert
Kinetic Scrolling Demo **Updated** KListControl with source
Hi New around these forums.. I've posted a in-progress of a project I'm working on. It's a kinetic scroller (you know that flick scroll effect). Remember this is a demo it doesn't actually do anything useful apart from amuse me! Not as fluid/cool as iContact, but it's my first PPC application. The grand plan is to turn it into a library based MP3 player with a decent looking interface. It's written in CF .NET so if you really need the source reflection is your friend. Tested on a WM6 blueangel device @ 400Mhz. Runs in the WM2003 emulator ---- I've updated with source. No license, do whatever you want with it. Although a mention somewhere would be nice Chad get this media player out the door now! ------- New optimized demo released, source now updated. Removing old source as the file name is confusing. Thanks for all the comments. ------------------------------------------------- ************************************** UPDATE: gingercat has done some fantastic work loosely based on the original source and created a user control. Unlike my old code it doesn't use one big bitmap and just better written in every aspect. I'll leave my old source up just for reference as to how /not/ to write a kinetic scroller
I can't try it right now because I don't have my device, but it's nice to know that at least a few people still support WM2003/SE...
jackbnymbl said: I can't try it right now because I don't have my device, but it's nice to know that at least a few people still support WM2003/SE... Click to expand... Click to collapse ...especially on wizard..
LOVELY! Why don't we work together to bring your scrolling routine, into my existing mp3 player "Melody". I've got playback and that sort of thing sorted out. Please PM me if you're interested.
anyone care to post a vid plz
slow scrolling and not as responsive as other scrolling software out there... but the idea is there ... i would also love to see smtg similar implemented in chad's media player (just my simple opinion)...
thundershadow14 said: LOVELY! Why don't we work together to bring your scrolling routine, into my existing mp3 player "Melody". I've got playback and that sort of thing sorted out. Please PM me if you're interested. Click to expand... Click to collapse Thanks for the offer! This is a hobby project and I'd like to work on my own. However I'm now going to release the source so you can use it..
Kinetic scroller, officially a part of Melody.: http://forum.xda-developers.com/showthread.php?t=325223
Development Hi I was just wondering, how long will it take for you to make your product compatible to play Mp3 Songs, because I'm tierd of waiting for a Music Player, which is easy to use and fast. And by the way, I think your player is so far the best, it just has to get a litle better UI!!!
Well, here I am with release 002 of my kinetic scroller demo. I've added alot of optimizations and its silky smooth on my 400Mhz device! It even runs great underclocked at 200Mhz. Source to follow (once its cleaned up, probably tommorrow)
Thanks for this! Once again shows how it just takes one person to come up with a great idea (apple (or whoever initially came up with smooth scrolling)) then we all wonder how we lived without it! I've just been reflecting over it and note that you are relying on .NET garbage collection to clean up e.g. all the graphics and brush objects you create - you need to be careful about this because this isn't deterministic and you can quickly run out of resources before it gets round to cleaning up. I know you say you're going to clean up the code anyway, but just thought I'd add my tip!
The holy grail would be if we can figure out how to hook mouse events, because then mouse movement can be processed independently of the form (and any other items on it). Unfortunately, CE doesn't support this (that I know of). The form approach only works if everything is semi-custom drawn.
This new version scrolls as good as or better than iContact, so you can remove that message on the first post. on the other hand, the version currently implemented in melody v0.6 doesn't seem as good as this one. btw, once you upload the new source, i'll see if i can make it stop selecting the first touched item when you are trying to scroll. when thundershadow and i were making our own one we found the way to do this was to do something like listbox1.selectedindex = -1 it should be pretty easy to do. also, something like this instead of the random number generator could get a list of the files in the current dir: Code: string[] r = System.IO.Directory.GetFiles(System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().GetName().CodeBase),".mp3"); klist = new KList(0, 20, screenX, screenY, "All Tracks"); for (int i = 0; i < r.Length; i++) { KItem ki = new KItem(i + ". " + r[i] + ".mp3"); klist.addItem(ki); } dunno if that is accurate or not.. haven't used c# that much.. but it should be easy todo.
Source is now up. I've starting playing around with MP3 playback but please ignore it (Using the FMODCE .NET wrapper)
dosfan said: Source is now up. I've starting playing around with MP3 playback but please ignore it (Using the FMODCE .NET wrapper) Click to expand... Click to collapse if you're intending on making it a practical-use app, probably the best way to go about it is using the shell execute function to open the mp3's in whatever player they associated mp3's to (cos people will want features they prefer than other media players). and then later on you can add an option to customize the command so the user can use it with a different media player without changing the associations. so they'd have to make something like: "\SD Card\TCPMP\player.exe /open %mp3path%". then the app just has to replace "%mp3path%" with the variable for the path to the selected mp3, and launch everything before it to shell. you'd also need to add something like the code in my last post to get a list of the mp3's (tried it on my ppc and it doesn't work, so it needs to be fixed up though).
chrismrulz said: if you're intending on making it a practical-use app, probably the best way to go about it is using the shell execute function to open the mp3's in whatever player they associated mp3's to (cos people will want features they prefer than other media players). and then later on you can add an option to customize the command so the user can use it with a different media player without changing the associations. so they'd have to make something like: "\SD Card\TCPMP\player.exe /open %mp3path%". then the app just has to replace "%mp3path%" with the variable for the path to the selected mp3, and launch everything before it to shell. you'd also need to add something like the code in my last post to get a list of the mp3's (tried it on my ppc and it doesn't work, so it needs to be fixed up though). Click to expand... Click to collapse Yes, that something I was already considering. To be honest, I'm not impressed with FMOD's performance. Even just initalizing the library is causing performance issues (without even playing a MP3, does fmod.init() spawn a thread or something???) I'm looking for a port of MAD that I could interop with. If anyone knows of a libmad.dll for ARM WINCE point me in the direction!
dosfan said: Yes, that something I was already considering. To be honest, I'm not impressed with FMOD's performance. Even just initalizing the library is causing performance issues (without even playing a MP3, does fmod.init() spawn a thread or something???) I'm looking for a port of MAD that I could interop with. If anyone knows of a libmad.dll for ARM WINCE point me in the direction! Click to expand... Click to collapse afaik, performance-wise fmod would be the best library to use. but the problem is that most people would rather use their own player like tcpmp or wmp that does what they want, rather than just a basic player with a third-party library in .net cf.
New UserControl version Hi dosfan, I have modified the source to create a new KListControl which is a UserControl you can add to any .NET form. All the scroll functionality required is all contained within the new control. This control doesn't pre-render everything up-front, so should be less memory hungry (especially with long lists) at the slight expense of some speed (runs fine on my hermes). Each item is now custom drawn, and only needs to support an IKListItem interface - this enables each item to draw whatever it wants, whenever it wants (well, by nicely asking its parent to invalidate it when visible). I have created a basic KListItem object that supports string name, object value (and has the same functionality you provided). I also updated the project to still compile with the new source, so (if you like the changes) you can continue work from there. Updates I will still make are: Better use of statics incase multiple lists are used (currently the background selection image is static) Common timer between multiple instances of the control (for performance). Hope you don't mind my changes! Chris.
i've just modified gingercat's version to launch the selected mp3 using the windows shell. to test it out you need to create a directory called "\\SD Card\\My Music", or change the variables in form1 and the klistcontrol to where your music dir is. if the directory doesn't exist it will browse for mp3 files in the app's directory, then grab the folder of the one selected. this is not a practical idea, and it won't change the variable in the klistcontrol, so it wont be able to launch it through shell if you use the browsing method. a better way would be to make it a folderbrowser dialog instead of a file one, then make the folder variable in form1 a global variable, and the klistcontrol just grabs it from form1. that still wouldn't work for subdirectories though. for that you'd need to tag each klistitem with it's full file path or directory when it's being added. also it should be pointed out that gingercat's version scrolls a bit too fast. it's smooth so there aren't any performance issues. it just goes too far with the tiniest tap up or down.
is there any way to capture all mouse events of the system?
The (Java) MIDlet Bible
(Note that this Bible does NOT discuss Java applets or applications. For more info on running applets under Windows Mobile, see the Web Browsing Bible; for application-related info, see my generic Java articles.) You may have already heard at least of Java games (more precisely, MIDlets) running on almost all current “dumb” phones. These games are all the rage today, especially with teenagers, which also means there are thousands of sometimes really high-quality games for ordinary phones, all written using the portable Java language, ready to be played on (almost) any kind of mobile phone. Just an example: in THIS HowardForums thread, the topic starter post lists some (but not all!) games available for the Samsung QVGA 240x320 phones (d600, d900, e900 etc – not only Windows Mobile ones!). Quite an impressive list, isn’t it? And it’s just the tip of the iceberg – there are a lot more games, all waiting for you to purchase, download and run! No, don’t think MIDlets are only for gamers and are absolutely useless otherwise. You can make a good use of them in the enterprise too. There are several solutions already for, for example, mobile payment, reservations etc. done using a MIDlet as opposed to the Web, which is, in a lot of cases, is much harder to access / operate on a small-screen device. Controlling for example your bank transfers via SMS can also be less intuitive and/or require a lot more work / data entry than using a GUI to do this. Other, known enterprise-related MIDlets are Jupiter, which is basically a financial data streaming program (also see THIS) and Betfair (also see THIS). Should you be interested in these “MIDlets in the Enterprise” questions, I really recommend Michael Juntao Yuan’s excellent book “Enterprise J2ME: Developing Mobile Java Applications” – I’ve learnt a LOT from it. Highly recommended! 1.1 Microsoft and third party MIDlet manager developers Unfortunately, Microsoft doesn’t support Java (and its, in this Bible discussed subset, MIDlets) at all. The sole reason for this is the fact that Java is a direct competitor to the .NET (Compact) Framework, and is (also) supported by almost all major competitors of Microsoft; in the telco area, most importantly, Nokia and Sony-Ericsson (S-E), the two major players in producing “consumer”, “entertainment”, “not-strictly-enterprise” handsets. This, unfortunately, means that, under Windows Mobile, MIDlets are not as widely supported as on competing mobile platforms; most importantly, Symbian. Nokia, S-E and the rest have spent a lot of $$$ on implementing really usable and top-notch MIDlet runner environments (MIDlet managers or KVM’s) in the last few years. Microsoft didn’t do the same, only third-party developers, who, because they considered Windows Mobile not to be a gaming platform, didn’t pay much attention to implementing a very good MIDlet manager on the platform (back then, there were far fewer enterprise / productivity MIDlets than today). Just an example: while the mid-2003 Nokia N-Gage certainly lacked at the MIDlet department (very few current games run on it and if they run – for example, the River Storm chopper simulator -, they are almost unplayably slow, as opposed to current Nokia handsets like the N95), the year 2005 Nokia 6680 already had almost flawless MIDlet support. For example, it even supports Bluetooth, which still (as of late 2007) hasn’t made it to the Windows Mobile MIDlet managers, “thanks” for the third-party, uninterested, unmotivated software developers’ neglecting the platform. 1.2 Is it worth it for gaming? The lack of Microsoft’s commitment to the decent support of MIDlets, unfortunately, means Windows Mobile users are, generally, in a far direr situation than owners of phones from manufacturers involved in developing Java further and spending a lot of $$$ on making their Java support as good as possible. A perfect example of this is, as has already been stated, Nokia. Nokia’s latest, gaming-enabled, top-of-the-line smartphones (most importantly, the PowerVR 3D-accelerated N95 (-3 / 8GB ), the N93(i) (the jBenchmark page is HERE) and E90; the complete list of current phones, based on their 3D benchmark results, can be found HERE) run truly three-dimensional (and, therefore, hardware accelerated) MIDlets considerably faster and FAR better than anything on Windows Mobile. S-E, with its 3D accelerated, touchscreen Symbian UIQ 3 models like the W950, the P990 and the M600, shouldn’t be forgotten either.
1.2.1 3D support Currently, I don’t know of any Windows Mobile devices with 3D hardware accelerated Java (MIDlet) graphics. The Aplix folks (developers of Jblend) told me their KVM does support the underlying 3D hardware accelerator. Unfortunately, the (very few) models available outside Japan that it comes with preinstalled do not have 3D acceleration and the (comparatively old) Jblend version available for installing on any device don’t show any kind of 3D acceleration support (I’ve tested this on my 3D accelerated, 2700G-based Dell Axim x51v). Therefore, I’m not really sure it will indeed work with, say, future GoForce 5500 (currently, the O2 XDA Flame and the Toshi G900 has the CPU (neither of them come with Jblend)) and/or the new Qualcomm 7200 chipset, which is to be found in several last-generation HTC and just-announced I-Mate handsets. I don’t think they’ll come with Jblend (why would HTC change their MIDlet manager OEM again, only about a year after switching to Esmertec from the dying TAO?) either. Let’s hope for the best (for example, Esmertec’s (re-)introducing M3G support with support for hardware acceleration into Jbed), though. The situation, now that – unlike with the 2700G and the GoForce 5500 – the Qualcomm MSM7200 chipset will be a de facto standard in many current- and most next-generation WM phones, will surely change in the future. I’m, however, pretty much sure you won’t see a 3D accelerated MIDlet manager any time soon under Windows Mobile. Again, software developers still consider Windows Mobile a non-gaming platform not really deserving 3D MIDlet acceleration. What does this all mean? If you’ve got used to the quality of game MIDlets on your favorite Nokia N93(i)/N95/E90 or Sony-Ericsson handsets, you’ll be pretty much disappointed; particularly if you want to run 3D and/or Bluetooth (multiplayer)-based games. 1.2.2 Bluetooth support Yes, the lack of Bluetooth is another major problem with all current Windows Mobile MIDlet managers. Don’t think of only multiplayer games – there are other uses of Bluetooth used from MIDlets; an example of them is Blooover (a great Bluetooth Sniffer), data exchange over Bluetooth and so on. You can find more information on the latter for example HERE. Note that, as opposed to what the 4pda.ru folks stated, few games refuse to deploy / run because of the lack of the Bluetooth support. (See the main games compatibility chart for more info on these titles.) 1.2.3 Sound issues There will be other problems too if you plan to play the HUGE library of MIDlet games available today. The most important of them is the bad sound emulation, which is quite big a problem with some MIDlet managers severely affecting the gaming experience. Actually, currently, it’s only Esmertec’s Jbed that didn’t have any problems playing back ALL the midi music I’ve thrown it at (and, of course, that of Nokia on Symbian); all the other (Windows Mobile) MIDlet managers had a much worse sound. In many cases, the music they produced was very hard to even recognize – in a way, they sounded like for example an SNES emulator running on a not-fast-enough Windows Mobile or Symbian phone. 1.2.4 Control issues Furthermore, you’ll surely be faced control problems. Depending on the MIDlet manager you use AND the game you’re trying to run, you will face sometimes severe control problems. Either the two softkeys won’t work (not even on Pocket PC’s, where you can also try to use the stylus to “press” them) or the D-pad / Action button, or both. Note that there are some solutions to this problem (particularly if you have a Smartphone (or an, in this regard, similar Pocket PC phone like the Asus A525) with a hardware phonepad). I’ve elaborated on these questions in a separate article HERE (cross-posted to PPCT, AximSite, XDA-Developers - 1, XDA-Developers - 2, XDA-Developers - 3, FirstLoox, BrightHand, HowardForums, SPT, MoDaCo, PocketGamer.org, PocketGaming.de).
1.2.5 Screen size issues The question of the screen size and MIDlets displayed in full screen mode should also be mentioned. As MIDlets are, generally, written for a multitude of different devices (to maximize revenue and minimize developing costs), they, generally, support three screen resolutions: 176*208 (the traditional Nokia screen size), 176*220 (the traditional Sony-Ericsson screen size which is, incidentally, the same as that of the traditional Windows Mobile Smartphone) and, finally, QVGA (240*320) – the screen size of the latest Nokia / Ericsson handsets and, of course, higher-end MS Smartphones. And, naturally, Pocket PC’s as well, which, in addition, may also have VGA (640*480) or even WVGA (800*480) screens. MIDlet games come in two flawors: either dynamically stretching themselves to fill in the entire screen estate of the device they run on in-game (while, in most cases, using the least common denominator, that is, 176*208, to display menus), or fixed to a given resolution. Of course, using the former is preferable (when possible) because you will have a great chance of being able to run it on your even WVGA Pocket PC full-screen. Interestingly, the game speed will, in many cases, remain acceptable even at such high resolutions. This was one of the best surprises I’ve encountered during my thorough tests. As opposed to the, technically, much more superior and mature Nokia MIDlet Manager, Windows Mobile KVM’s aren’t, generally, full-screen, which, unfortunately, mean some 20-25 or even 40-50 pixels at the bottom of MIDlets hard-coded to the QVGA resolution will be not shown on QVGA screens, depending on whether the actual MIDlet manager shows both (top and bottom) screen bars (TAO, IBM J9 or Jeodek M3G on the Smartphone platform) or “only” the top bar (Jeodek M3G on the PPC platform; non- M3G-capable Jeodek on both WM platforms, Jblend). Nevertheless, there will be missing information; in most cases, the softkey labels, but, with many games, also status messages, speedometers and the like. You can find a lot of comparative screenshots in both the previous 3D MIDlet article and the main game compatibility chart. In all these cases (when the missing information does get into your nerves), you will want to try very hard to, first, find a KVM that does full screen (Jbed or, if you can live with the bad or non-existing audio support, the full screen version of Jblend) and if they turn out to be unable to run your title, switch to a MIDlet version written for a device with a smaller screen (for example, the 176*220 version instead of the QVGA one). In the latter case, however, a large part of your screen estate will remain unused. As far as application programs (Opera Mini, Gmail, Google Maps etc.) are concerned, they all dynamically stretch themselves to make use of the available screen estate; therefore, you won’t have problems with them on any device, with any MIDlet manager. 1.2.6 (Free) alternatives to MIDlet gaming As several MIDlets are just rewrites of old classics like Bonk, you may find it useful to look around any online console ROM or abandonware game repository for versions of the game you plan to play. In a top-notch emulator like SmartGear, they might run FAR better than ANY MIDlet manager on your particular handset. Make sure you read ALL my previous, emulation-related articles (the Emulator category of my blog is HERE) to see what gaming console platforms there are and how they are emulated by Windows Mobile. Just an example. The recently released Bonk’s Return runs MUCH slower (and/or using MUCH more battery) on all my test Windows Mobile devices than the same title under a PC Engine emulator like SmartGear. All in all, if you find a MIDlet that you find a bit on the slow side, make sure you look around on, say, WikiPedia to see whether the game (originally) had handheld / desktop console versions (or, for that matter, a home computer one – even many home computers of the eighties and the early nineties are better emulated than MIDlets, particularly if you can’t use Jbed because of the compatibility issues). If it did, make sure you check out the console version first, under an emulator. Again, it can’t be stressed enough how important it is for you to thoroughly read through my console/computer emulation-related articles so that you know what emulators there are, how the original titles are emulated under Windows Mobile, what platforms to prefer when there are ports to multiple platforms of a given title etc. Yeah, I know you’ll end up having to spend hours to read all those articles, but, if you’re a hardcore gamer, you’ll certainly find it useful. 1.3 Is it worth it for non-gaming? It definitely is; most importantly, for Web browsing with the brand new Opera Mini 4 (current, recommended version: beta 2) reviewed HERE. Opera Mini 4 is a freaking good and, what is more, FREE Web browser – in many cases, it’s preferable over all the other Web browsing solutions available for Windows Mobile. There are other productivity MIDlets meant for non-vertical markets too; the most important example of this is the Gmail MIDlet, which offers a very nice alternative to browsing, searching, answering etc. your Gmail mailbox from your handheld, including Windows Mobile ones. It’s WAY better than any Web-based solutions (see the Web Browsing Bible for the why’s) and, given that it allows for using some really advanced functionality (for example, searching) on the server side (this wasn’t available before; now, Gmail has just implemented IMAP access (another, related PPCT thread), which might let do this from a capable IMAP client as well – see my IMAP Bible for more info), it might still be preferable on a device that, otherwise, is properly configured to access Gmail via POP3. You may also want to take a look at THIS, THIS, THIS, THIS and THIS thread / article too. Note that now that Google has released an excellent, native Windows Mobile version of the client, (as of the current, 1.2.0.13 version) the need for the MIDlet version of Google Maps is decreased. The native version works just great on both WM platforms and is accessible HERE for download as a directly installable CAB file. Note that there may still be cases you will want to prefer the MIDlet (that is, non-native) version of this program; see for example the comments HERE, where user “fixup” complains of the native version’s keeping the backlight and the connection on (as opposed to running the Java version under a MIDlet manager), which both may lead to (vastly) increased battery consumption. Finally, as you most probably WILL want to run at least Opera Mini (or its modded version) on your device, the answer is YES.
2. Available MIDlet managers In this chapter, I give you a thorough overview of what current (!) MIDlet environments there are, how they compare to each other and which one you should prefer. As you’ll see, particularly if you’re a power user and/or player, you will want to keep different KVM’s on your Windows Mobile handheld simultaneously so that you can make use of the functionality of each of them (there’s no “best” KVM – unfortunately, the otherwise best Jbed lacks some functionality only provided by other KVM’s). Note that I don’t provide you download /purchase links here. You can find all of the download sources and / or accessibility remarks in the main chart, in the second, “Price / availability” row. Also note that this is just a sketchy list of what KVM’s there are and what (dis)advantages they have. For a full list of tips, tricks, capability and problem lists, you MUST consult the above-mentioned main chart. Note that, in Chapter 4, I will also elaborate on the meaning of the rows in the chart. 2.1 Esmertec Jbed This is by far the best and most recommended KVM for Windows Mobile, (QVGA; NOT 176*220 – on the latter, it refuses running deployed MIDlets) Smartphones and Pocket PC’s alike. Its only problems are the lack of M3G (3D gaming) support and the inability to run more than one MIDlet concurrently. As with the other products of Esmertec, it isn’t compatible with pre-WM5 operating systems and needs to be “hacked” in order to be able to run it on non-Phone Edition Pocket PC devices. (See the “Platform compatibility: non-phone PPC” row in the main chart to see how this hacking must be done.) Note that the latest, currently available Jbed version has problems with the cookie handling of Opera Mini 4 beta 2. This means you can’t log in to many (but not all; for example, Yahoo Mail works) Web sites with OM4b2 running under Jbed. As this isn’t an issue with Opera Mini Mod 2.04/2.05, this seems to be a problem exclusively with the given Opera Mini version and not that of Jbed. If this is a problem, consider switching to another MIDlet manager (for example, Jeodek), where the cookies of Opera Mini 4 beta 2 do work. 2.2 Esmertec Jeodek There are, basically, two versions of this KVM. The non-M3G-enabled, newer version isn’t really recommended (Jbed is definitely better in almost every respect, except for the Opera Mini 4 beta 2 cookie issues). There is, however, an older, M3G-enabled version out there, which allows for playing a wide variety of games. I’ve explained how the latter should be used HERE, in the 10/11/2007 update. That is, if you’re into gaming, you might want to go for the M3G version; otherwise, I recommend upgrading / switching to Jbed. 2.3 IBM J9 This is a well-known but, now that both Jblend and the two product lines of Esmertec are considerably better in most respects (except for some deliberate questions like the ability to run multiple MIDlets at the same time, in which it’s, together with TAO Intent, is clearly better than Esmertec’s products), not any more recommended KVM. You should prefer Jbed to it and only consider using it if you do need J9’s special capabilities or its compatibility with pre-WM5 operating systems. Note that, lately, IBM has made much harder to download a trial version of J9 if you’re situated outside the States. 2.4 TAO Intent This is the MIDlet manager having come with almost all HTC-manufactured WM5 Pocket PC’s and Smartphones. Now that the developer no longer exists, the HTC folks have switched to Esmertec Jeodek / Jbed instead (and independent MS Smartphone / PPC PE manufacturers like Sharp or Samsung prefer Aplix JBlend instead). However, this still means there’s a HUGE number of installed userbase of this MIDlet manager. Currently, two major releases of these titles are widely used: the 10.1 series (also compatible with WM2003(SE) and the MS Smartphone platform) and the latest 11.1 series (the latter being only WM5+ & Pocket PC-compliant). In general, you will want to prefer Jbed to this title. It has only few areas where it’s clearly better. Just like with IBM J9, in addition to WM2003(SE) support, it also supports running MIDlets concurrently. If you have a (non-rebranded!) HTC WM6 Pocket PC device, go for the latest, .1036 version; otherwise (you have a rebranded and/or WM5 device), go for .1034. Should you have a plain (non-phone) Pocket PC, make sure you apply the SMS.dll / Phone.dll hacks already mentioned with Jbed. Note that, at 4pda.ru, there is a separate “turbo” version. While I haven’t really measured remarkable speed increase with the jBenchmark tests, many users have reported generic speedup with at least starting / loading MIDlets. This is because many library files have been decompressed by the creator, meaning no decompression needed in runtime. This may indeed result in some speed increase. (Note that this trick doesn’t work the 10.1-series TAO Intent MIDlet managers (MM’s); this is why only the new series has a separate “turbo” version.) Note that this also means this version occupies about two times more storage than the non-turbo one; therefore, if you have little built-in storage, consider installing it on a storage card. Also, it’s a bit older (version 1023) than the – currently – latest, 1036 version. 2.5 Aplix JBlend This OEM MIDlet manager comes with, compared to Esmertec’s KVM’s, very few Windows Mobile models. Compared to Jbed, it has both advantages and disadvantages; for example, it supports M3G (and, therefore, far more games) BUT it doesn’t support midi / MP3 playback (that is, you won’t really hear music anywhere) and has a messed-up security model making it pretty useless for Net access like Opera Mini or Gmail. This means you will only want to use it for gaming – if the other two, decent alternatives (the M3G-enabled Jeodek or Jbed) don’t work or work slower. In THIS HowardForums thread, you’ll find many titles compatible with this MIDlet manager; and, of course, my main games compatibility chart will provide you with a lot of additional compatibility information with current MIDlets. 2.6. Not recommended KVM’s Note that the charts (and this tutorial) don't elaborate on the following MIDlet managers: 2.6.1 NSICom CrE-ME This manager is still (as of version 4.12) pretty weak (MIDP 1-only, really low resolution, problems with connecting to the Net, pretty complicated to install a MIDlet etc.). This means it, in most cases, should not be used. Strange the developers still call it "the world's most reliable J2ME/CDC Java Virtual Machine technology for Embedded platforms". While CrE-ME is without doubt the BEST JVM out there right now for running individual applications / applets (which are vastly different from MIDlets), its MIDlet support is really bad. 2.6.2 Coretek Delta Java Manager This MIDlet manager is only slightly better than NSICom's above-mentioned CrE-ME. While it's compatible with quite a few games, it has severe problems; most importantly, its utilized screen estate is tied to 176*220 (fortunately, it’s pixel doubled on VGA devices). This means you won't be able to run your MIDlets using the real, full screen estate of your QVGA / VGA / WVGA Pocket PC's or QVGA Smartphones. Therefore, I only recommend it if you want to run MIDlets tied to 176*220 (or smaller) screen sizes and/or you have a 176*220 MS Smartphone. A related (Russian) thread is HERE (BabelFish HERE) 2.6.3 Mitac JVM This is an old (2003), pretty bad and not recommended MIDlet manager. Related thread: MoDaCo Working midlets and non-working midlets.
3. Introduction to using MIDlets Now, let’s see how you can install (deploy) MIDlets on your Windows Mobile device and how you can use them. Fortunately, doing this is very simple. First, make sure you do have a KVM on your handheld. If you don’t, install one. If you have a non-phone Pocket PC and want to use any MIDlet manager (except for IBM J9), make sure you install the SMS.dll and Phone.dll hacks and / or if you have a pre-WM5 device, you’ll need to choose from either IBM J9 or old versions of TAO Intent. After this, your life will be pretty easy. 3.1 Two ways of deployment (installation): online vs. offline In general, there are a lot of MIDlets available online. In general, if you click them on the Web from your Windows Mobile device (preferably, using a built-in Web browser), they get downloaded to your handheld and automatically deployed in your device. The same happens with JAR files you copy to your handheld and, then, deploy them locally by either making your KVM explicitly search for it or clicking it / pressing the Action button from a local file manager. In the following two subsections, I elaborate on these questions. Note that, generally, there are two kinds of files you’ll run into: JAD files and JAR files. When you download a MIDlet to your desktop PC so that you can, later, deploy it into your handheld’s KVM, only download JAR files, not the JAD ones. If there’s no way of directly accessing JAR files, only JAD ones (as is, for example, the case with the Opera Mini 4 beta download page HERE - note that you should visit it from a Wap-capable desktop browser (Opera), that is, NOT from IE!), the “Download high memory version” download link will download you a JAD file, not a JAR one. You can directly copy this file to your handheld but, then, it’ll need to have Internet connection to be able to download the JAR file referenced by the small JAD file. If you can’t guarantee this or prefer collecting the JAR files offline, do the following: open the JAD file you downloaded with a text / file viewer (editor) and look for the attribute named “MIDlet-Jar-URL”. Copy the URL after the colon (for example, http://mini.opera.com/dl/1B8GM15aEP5uj-jE8A4AACMhDw8C/mini.jar) to your desktop Web browser. Now, you’ll have direct access to the JAR file – you can already safely save it. Note that some KVM’s support separating MIDlets into different folders. Some allow for selecting the folder at deployment time (an additional step in the deployment process; this is what, initially, the “root” screen stands for when deploying into Esmertec products), the others after deployment. (And, on the Nokia, as it has no MIDlet manager interface at all but all deployed MIDlets are listed as regular applications, you can use the system file explorer tools to move them elsewhere, in another folder. This is slightly different from the way MIDlets were handled or early MIDlet-capable Nokia phones like the N-Gage, where there was a separate folder for them.) Also see the “Possible to use folders for better MIDlet separation?” row in the main chart for more info & screenshots. Also note that, during the deployment process, you will also need to let the installation continue, particularly when the given MIDlet isn’t signed with a trusted certificate. (The vast majority of MIDlets are like this.) This, in general, only means you will need to press the left softkey some times on both Windows Mobile and Symbian. 3.1.1 Offline: originating the deployment from inside the manager vs. doing the same from the outside There are two ways of deploying a local MIDlet JAR file to your MIDlet browser. The easiest is the default way of just clicking / pressing the Action key while viewing it from a local file explorer tool. This, as long as the file associations are correctly set (which may NOT be the case if you install more than one KVM’s on your handheld – more on this later), will automatically invoke the JVM and deploy the MIDlet. Another way to select the related menu item inside the given KVM is to search for JAR files in the local file system (for example, Menu / Install / Local with TAO and Menu / Install / Local Files with Esmertec’s KVM’s). Unfortunately, it’s pretty flawed with most of the KVM’s; for example, the lack of alphabetical sorting, some of them can’t display all the files at once if there are more than 200-250 of them, some are only looking in a given directory or have no search capabilities at all, which is the case with IBM J9. The latter, as it doesn’t allow for browsing the file system for a given JAR file, forces you to enter the full (local, that is, Error! Hyperlink reference not valid. ) URL of the JAR file, which is really a pain in the back. Finally, Jblend doesn’t offer any local file browsing / deployment at all – with it, you must initiate the deployment from any file explorer tool. The latter is “only” highly recommended with other KVM’s because of the other annoyances and bugs they have. 3.1.2 Online This is much easier: you just navigate to the given page with the MIDlets online and just click the JAD (or JAR) files. Note that some KVM’s may not allow for installing Web-based JAR’s directly; with them, you will need to click the JAD file instead. This is in stark contrast with the local install: all the tested (non-disqualified) browsers allow for the direct installation of JAR files and no local JAD’s are needed. 3.2 Running the already-deployed MIDlets After your MIDlet is deployed, you will need to click it from inside the KVM if it’s not started automatically: most current, recommended KVM’s ask the user whether the MIDlet should be started right after the deployment. Otherwise, you just start the KVM environment (it’s, in general, in the main Start Menu / Programs folder (except for the HTC Kaiser / Tilt, where it’s in the Tools subdirectory there) and is called “Jbed”, “Java”, “Jeodek” or “Esmertec Jbed/Jeodek” with the Esmertec products, “MIDlet Manager” with TAO Intent, “Midlet HQ” with IBM J9 (linking emulator.exe) and “Jblend” with Jblend) and simply double-click the given, already-deployed MIDlet. With IBM J9, you must select the uppermost “Launch” menu item in Actions instead, after highlighting your MIDlet. Now that I’ve made it clear it’s only Nokia’s (Symbian) MIDlet manager that puts the deployed MIDlet icons in the traditional Applications folder, you may also want to know whether you can also hack the Windows Mobile KVM’s to do the same. This, as you may have already guessed, also greatly speeds up starting a given MIDlet: you don’t need to start an additional layer of managers. The answer is: yes, with most KVM’s (except for Jblend), you can. Then, you won’t need to separately start the KVM interface to gain access to the deployed MIDlets. See the “Direct, system-level links (shortcuts) to MIDlets” row in the main chart for more info on this. Note that, as opposed to Nokia’s system-level links (or, for that matter, the way the excellent Palm OS emulator, StyleTap, works on Windows Mobile), all these links will have the same icon, unlike under Symbian – not that of the icon of the MIDlet itself. This is a definite disadvantage if you prefer looking for a MIDlet based on its icon and not its name / position. 3.3 Security issues Unlike with native Windows Mobile (or Symbian) applications, you’ll always run into security prompts. Therefore, it’s worth knowing a bit about what they are all about. Java programs, in general, put a lot of weight on security measurements. This is why they continuously prompt the user when they try to access “sensitive” resources like the Net or the local file system. Fortunately, you can, in general (except for Jblend), easily get rid of this problem: - if you have any of the Esmertec KVM’s, use the MIDlets signed by the MXit LifeStyle-signed JAR’s available in THIS thread. Note that I’ve separately linked in the most common non-game (games, in general, aren’t affected by these issues, unless they want to use Bluetooth) MIDlets you may want signed. Then, you’ll be able to set their security model for “Blanket”, which means you’ll never be prompted for permission. It’ll certainly be easier for you than with the default “Session” (you’re asked once per session – that is, after starting the MIDlet) and the even more restrictive “One Shot” security model. Incidentally, Jblend employs exclusively the latter model with accessing the Net; this means it’s pretty much useless for applications like Opera Mini or the Gmail MIDlet. This is particularly true with the Gmail client, where it prompts the user to allow going on upon downloading every single mail (header). That is, never use Gmail under Jblend. - if you have a KVM where you can “hack” the security descriptor files (all Esmertec KVM’s and IBM J9 belong to here; TAO Intent is also said to be but the opinions do differ on the latter and I haven’t tested this hack), do the hacking to get rid of the annoying security prompts. See the “Security: Allow permanent Net access without prompting ("Blanket" security model, as opposed to "Session" / "Oneshot")?” row in the main chart for more info / links.
3.4 Runtime issues: concurrent (parallel) and background execution The KVM’s slightly differ in how they handle concurrent execution of MIDlets – or, simply running something in the background. Some (TAO and J9) allow for the concurrent execution of MIDlets, while the rest don’t. This means the, otherwise, excellent Esmertec KVM’s will only run one MIDlet at a time, while the certainly, in most respects, inferior J9 and TAO Intent will run any number of them. TAO, in addition, also supports the in-environment switch between running MIDlets, unlike J9. Support for parallel MIDlet execution can be very useful; for example, the Gmail MIDlet could continuously check Gmail for incoming messages, while, in another MIDlet, you could browse the Web. You can find some other uses for example HERE, in the comment section (the comments HERE are also pretty instructive and shed light on related issues). The ability to execute a MIDlet in the background is also very important. Just an example: you start downloading a Web page in Opera Mini but quickly realize the download will take ages. In order to save time and do something useful in the meantime, you decide to minimize the Opera Mini task, do something else in another program and only return later, expecting Opera Mini has already finished downloading and rendering. All the tested WM and Symbian KVM’s support this kind of operation; the only exception is Jblend, which immediately pauses when it loses the focus. Incidentally, Jblend’s behavior also has some other consequences; for example, in no way can you use external character injectors to it (unless they’re continuously running and, therefore, don’t result in executing a new process; PQzII is one of these) and you will even have problems uploading Jbenchmark results to the server (because it constantly thinks the MIDlet has been paused and prompts you for resuming). I also recommend Solnyshok’s excellent article for more information on the advantages of parallel execution of some MIDlets. Also note that the article contains an excellent hacking tutorial on how multiple instances of the same MIDlet can be executed at the same time. 4. The main chart Again, this is where you’ll find most information. It contains an order of magnitude more information than the article you’re just reading in a well-condensed, tabular, easy-to-compare form, packed with tons of screenshots helping in finding out how a given feature should be enabled / used. I’ve already elaborated on several (for example, security-related) of the rows this chart has; now, let me elaborate on the rest. In the “Price / availability” row, as has already been stated, you’ll find where to get / download the given KVM from. In the “Platform compatibility” group, I’ve listed three rows: compatibility with non-phone Pocket PC’s, Pocket PC Phone Edition devices and, finally, touchscreen-less Smartphones (abbreviated as SP’s). As has already been pointed out, you MUST apply the SMS/Phone DLL hack explained in the Jeodek column if you have a phone-less, “classic” Pocket PC. Also, if you have a MS Smartphone (as opposed to Pocket PC’s), pay special attention to the compatibility remarks here as, unfortunately, not all titles are Smartphone-compliant or, if they are, you may encounter some problems when trying to run them. The “Generic compliance with standards” group is more for techies: people that would like to know everything about the standards support of the given KVM. As can clearly be seen, the Nokia N95 KVM blows all the other KVM’s out of the water (in this respect too); this is particularly true of, under Windows Mobile, never (except for some very old and long-discontinued IBM J9-specific add-on projects I’ve elaborated on HERE) implemented, for, for example, multiplayer gaming (give a try to the MIDlet version of 3D Constructo Combat in multiplayer mode on even slower / older Nokias like the 6680 – you’ll LOVE it! The same stands for for example the infamous Naval Battle: Mission Commander) Bluetooth support. The same stands for other goodies like support for camera: all WM KVM’s lack the support for it, as can clearly be seen in the “MMAPI Video-capture” cell of the “JVM Multimedia (JSR 135)” row. It could be VERY useful; see for example the posts HERE, seeking for support for barcode reader applications. Audio capture (which isn’t really supported by many apps either) is also pretty useful; see for example the TellMe MIDlet for a real-world usage example. Yeah, you can clearly see MIDlets are in no way for gaming only – there have a LOT of enterprise uses and are particularly useful when you have a lot of different platforms you need to quickly develop a business solution for! In the “JVM Memory” row, I’ve listed the appropriate heap (free memory) size available for each KVM. The more, the better for running memory-hungry MIDlets – unless the given KVM uses dynamic (de)allocation of memory when the need arises. Then, it’ll be able to run even the most memory-hungry MIDlets (for example, a full JBenchmark category, in High Quality, packed into one JAR). Unfortunately, only Nokia’s KVM and Jbed support the latter. Also note that you can set the memory allocated for Jblend in the Registry. Support for “JVM M3G”, that is, the Mobile 3D Graphics API is the dream of most Java MIDlet gamers. As can be seen, several KVM’s support it. (Speed, without hardware acceleration, is another question.) The “JVM File Connection” group is also very important, particularly with applications like Opera Mini Mod, the unofficial (and, unfortunately, illegal; therefore, I cannot provide a link to it either) “hack” of Opera Mini, adding a lot of goodies like (pretty rude, but still working) page saving and IEM favorite import / export. These all require access to the file system, which, unlike with real Java, isn’t built-in or required by the basic standard. This is why so few WM KVM’s support it: IBM J9 with an additional hack (I’ve elaborated on the installation in the chart) and Jbed. Interestingly, some real-world tests were failed by Jbed, while IBM J9 passed all of them. The support for accessing the local file system is certainly a big plus with IBM J9 – one of the very few advantages of the environment, along with, for example, the ability to run several MIDlets at the same time. The “Storage usage” group is very important because internal storage memory is doomed to fill up very quickly (especially with low-end WM devices only having 64M of Flash ROM – an example is the HTC s310/Oxygen WM5 Smartphone), particularly if you install sizable games (current games are 300-600 kbytes in size). In this group, I’ve explained the following: Where can a given MIDlet manager KVM be installed to – that is, can it be installed to a storage card? All of them can (note that we’re, mostly, dealing with XDA-Dev-created installers and hacks in here!), except for Jbed, which MAY require some additional manual file copying (also explained in the chart). Where the deployed MIDlets are kept: This is also highly important. Fortunately, it’s only IBM J9 that is doomed to store the deployed MIDlets in the internal storage (I’ve tried to hack it to a card very hard – see my related article – but in vain); other MIDlet managers, when installed to a storage card, don’t. Note that, should Jblend and TAO be an OEM-installed KVM on your handset, you can still easily “hack” them to store their MIDlets on a storage card with a simple Registry edit.
In the “Text input” group, first, I’ve listed the copy / cut / paste capabilities of the KVM’s. One of the biggest problems with TAO is the complete lack of copy / paste functionality in any of its textboxes. This is a real pain in the back. Note that some 4pda users have implemented an external, not very reliable way of pasting text to the TAO textboxes (via MortScript), it’s still far from perfect. “Known text input-related bugs? Maximal editable pre-populated text area size?” elaborates on the text input-related bugs of the tested KVM’s. The most important of them (without any exception – not even Nokia’s implementation did fare well in this respect) is the text input areas’ limited size. This means the following: when you, for example, post an answer in a forum using the “QUOTE” button, you may end up not being able to enter anything and/or your answer getting completely deleted. In general, the threshold is between 1 and 8 kilobytes, depending on the actual KVM and the Web browser you use (Opera Mini fares far better in this respect than its modded version; I think because the latter uses 16-bit Unicode for input, which take up double the memory as the 8-bit input of Opera Mini.) Therefore, make sure you either quote VERY short answers and try to remain under the threshold or try not to quote anything. In addition, TAO has a very bad, additional bug: if the quoted (and/or, original) text contains line breaks, you won’t be able to edit it at all. I really recommend giving the test HTML page I’ve created for this test a thorough try to see what restrictions there are, whether your input is retained (after you exit the edit mode) etc so that you can be absolutely sure you don’t mess up anything when you do start filling in Web forms or post to forums with Opera Mini (Mod). The “Display” category contains information on the usage of font smoothing technologies like ClearType (also see THIS request). As can clearly be seen, it’s only when using the smallest character size and only with some KVM’s that there is font smoothing (with OM4b2) I’ve devoted two separate rows (and a lot of screenshots) to demonstrate the font sizes of Opera Mini 4 beta 2 in both VGA and QVGA because a great deal of misinformation is all around the Net on the different font sizes of each. For this test, I’ve also created a test page. As can be seen, the font sizes are roughly equal with all KVM’s, as opposed to what some people state. Also note that I’ve also published how you can increase the font size in TAO with a simple Registry edit (I’ve also attached the import file) – the ability to do this is clearly is a definite advantage of TAO. As far as the “Keyboard, SIP, softkeys” group is concerned, please read THIS for a very thorough explanation. I’ve already elaborated on most rows of the “MIDlet installation, separation, direct invocation, uninstall” group; therefore, I won’t go into this once more. It’s probably only “Registry import files to quickly reassociate JAR / JAD files” that still hasn’t been explained. Please see the “2.4 Co-existing on the same Windows Mobile devices” section in the Definitive Guide to Running 3D-enabled Java MIDlets on Windows Mobile to see why you might need these Registry import files if you plan to use more than one KVM’s on your Windows Mobile device and want to retain (or, quickly restore) the ability of a given KVM to deploy a MIDlet you click on in an external (Windows Mobile) Web browser or in the file system. The “Security” group has already been explained above. The “Misc (sound, compatibility with some popular apps, proxy, etc)” group contains some miscellaneous tests and rows like support for full screen: as can clearly be seen, in this regard, Jbed is the best (it indeed offers full screen) and Jeodek is the second (it only displays the upper task bar but not the lower menu bar; Jeodek M3G being the only exception when run on the MS Smartphone platform). So does Jblend. TAO and IBM J9, unfortunately, both display the two bars at the top and bottom. Needless to say, Nokia’s KVM also makes use of the full screen estate. Sound support: as has turned out during the tests, Jbed (along with Nokia’s KVM) is by far the best KVM when it comes to playing in-game music. Note that I’ve tested it being stereo by running Doom RPG, a very famous MIDlet (even PocketGamer.org’s infamous Sponge likes it). Strangely, while Jbed does support stereo, Nokia has failed the stereo test: it only plays music in mono. At last something that Nokia’s KVM gets beaten at Proxy support is also very important and in high demand among Opera Mini users (as Opera Mini, by default, doesn’t support proxies, unlike Opera Mini Mod, where you can enter the proxy address right in the browser settings). In these tests, I’ve used my custom-written Web client MIDlet and Web server to easily find out which of the several possible ways Opera Mini (or, any other Web browser not supporting custom, local proxy settings) can be made use a proxy. As can clearly be seen, only Jbed and IBM J9 support this. (I haven’t tested Nokia’s KVM in this respect; I assume it works OK.) the compliance test of three highly popular productivity (non-game) MIDlets: Gmail, Opera Mini and Opera Mini Mod. 5. jBenchmark Benchmark Results I’ve also made some serious benchmarks with the well-known jBenchmark suite. First, it’s worth pointing out that, while Esmertec Jbed does promise speedup by compiled code, in reality, it doesn’t mean THAT big a speed increase. That is, you won’t even see a twofold speed increase in everyday apps / games – if there will be any speed difference at all. In the charts, I’ve emphasized the tests where Jbed produced FAR better results than other MIDlet managers running on the same device. I’ve used plain bold to emphasize differences up to two; to emphasize even bigger differences (for example, the Chess test), I’ve additionally used Italic and <u>Underline</u>. It’s also worth pointing out that while high-resolution (VGA) devices (in the test, the Dell Axim x51v and the HTC Universal) tend to run standard 2D graphics tests (at times a LOT) slower than standard-resolution (QVGA) models like the HTC Wizard or the HTC Vox / s710, with 3D (with the only currently available, 3D-capable MIDlet manager, the TAO Intent 11.x series), the differences aren’t that big. As far as the 3D benchmarks are concerned, which show a clear, sometimes 20-fold speed difference in favor of the 3D hardware accelerated Nokia N95, don’t think Windows Mobile devices are THAT bad at playing the currently available 3D games. While M3G games indeed run pretty much flawlessly on the Nokia N93(i), N95 and E90 (the current Nokias with 3D hardware acceleration), the currently available, non-accelerated Windows Mobile KVM’s don’t produce MUCH worse results either – most 3D games still remain playable under WM too. In practice, the 20-fold difference in these synthetic tests reduce to two to three-fold difference with currently available, tested 3D MIDlets. Never ever believe anyone that states the opposite – he or she, then, hasn’t compared (unaccelerated) Windows Mobile and (accelerated) N95. I did and know the difference, which is certainly not even tenfold, no matter what the JBenchmark results suggest. Note that the reason the Nokia N95 scores so good in 3D is not because the built-in PowerVR 3D chip would be so much faster than, currently, the 2700G. It’s just because the former is supported by the built-in MIDlet manager and the latter isn’t supported by any Windows Mobile MIDlet managers. Otherwise, speed-wise, there’s no clear winner. In general, all MIDlet managers have their strengths and weaknesses; there isn’t a single one with the best speed / efficiency (not even that of Nokia). Also note that, in general, the Nokia benchmarks don’t differ much from those of the WM KVM’s – of course, the M3G results are completely different. But, again, with real MIDlets, this difference is far less pronounced than one would think based on the synthetic JBenchmark 3D results. Note that the columns are a bit different from the first chart; now, I’ve also listed the device I’ve run the given MIDlet manager on.
6. Game compatibility reports I’ve also thoroughly tested some hundred (!) popular, well-known games; both 2D and 3D titles. (More on these games in THIS article – my previous and, now, slightly outdated article on 3D gaming.) As has already been emphasized with the benchmarks, there’s no clear winner here either. As a rule of thumb, however, you should always try to run a given title under Jbed first. It’s the least compatible with existing games, but has three real advantages over both the M3G-compliant version of Jeodek and Jblend: if it does work then, generally, it’s the fastest; of the three, it has the best sound emulation and it supports full screen mode. If you do encounter problems, give a try to alternative MIDlet managers: to IBM J9, TAO Intent, Jeodek M3G or Jblend (or, JblendFullScreen if you don’t need M3G and/or decent music but do need full screen because of, for example, the hard-coded screen size used by the MIDlet). Note that it’s pretty useless to try to run a title not running under Jbed under the non-M3G-capable Jeodek either. Doing the same under the M3G-capable Jeodek version, however, is a completely different issue. As has already been emphasized, these MIDlet managers can co-exist on the same device and if you’re really into gaming as many MIDlets as possible, you will want to put at least three (Jbed, Jblend and Jeodek M3G) on your handset. Note that there is an earlier version of this chart HERE. As the chart doesn’t contain for example the Nokia N95, the M3G-capable Jblend (only its full screen, old and pretty much incapable version) and lists far fewer titles than the main games compatibility chart, it’s in no way as important as the main compatibility chart listing the, for gaming, most recommended WM KVM’s (along with Nokia). However, it also contains some info on how different hardware (520 MHz XScale-based VGA HTC Universal vs. 195 MHz TI OMAP-based QVGA Wizard, for example) compare when it comes to running (graphics-intensive) games. As can be seen, the, otherwise, for gaming not really recommended Wizard behaves pretty OK even at the default 195 MHz CPU clock speed. Highly recommended articles TUTORIAL: Control issues of Java MIDlets – all secrets of button handling. Crossposts: PPCT, AximSite, XDA-Developers - 1, XDA-Developers - 2, XDA-Developers - 3, FirstLoox, BrightHand, HowardForums, SPT, MoDaCo, PocketGamer.org, PocketGaming.de. The Definitive Guide to Running 3D-enabled Java MIDlets on Windows Mobile (note that its discussion of some of the apps is a bit outdated; that is, consider the info in the current Bible of higher priority than in there. Also note that the comments (at the bottom) are really worth checking out, just like with the comments arrived at THIS article. Crossposts: PPCT, AximSite, XDA-Developers, XDA-Developers - 2, FirstLoox, BrightHand, HowardForums, SPT, MoDaCo, PocketGamer.org, PocketGaming.de The Button Enhancer Bible & great button config tips for Opera Mobile / Mini users – it has a LOT of MIDlet-related info. Crossposts: PPCT, AximSite, XDA-Developers - 1, XDA-Developers - 2, FirstLoox, BrightHand, HowardForums, SPT, MoDaCo. 4PDA thread; translations HERE 5 things noobs should know about java mobile games The MIDlet reviews at Mobile Critic and Midlet Review The homepages of Fishlabs, Gameloft, Glu and Xendex My old, outdated, related articles What TAO Intent versions there are? - this article has been written before Risidoro’s releasing the 1034/1036 versions and the release of the generic SMS / phone.dll hacks. The latter means you don’t need to install the somewhat older version .1023 of the MIDlet manager on your phone-less PPC any more. Running Motorola-specific Midlet games on the Pocket PC? YES!! IBM releases new, 6.1.1 version of great Midlet runner J9; now, it’s fully compatible with Google Maps! Great, Free Java/Midlet Environment IBM J9 New, 6.1 Version is Out – a Full Compliance & Bug Report & Never Before Published Tweaks that Help Using It Much Easier (in there, I’ve also reported on my effort of trying to relocate the IBM J9 deployed MIDlet repository from the main memory). Java Midlets on the Pocket PC - the Complete Tutorial (outdated, but nice for some additional tips)
UPDATE (11/23/2007): in the meantime, thanks to XDA-Devs user defcomg, a new, third-party, free Bluetooth (JSR-82) library, BlueCove has been found, which supports IBM J9. In the second part of this article, I elaborate on how you can “hack” some Nokia classes into MIDlets so that they have a chance to run. I also explain how you can force the installation of MIDlets that, otherwise, are refused to be deployed because of missing library (for example, Bluetooth under Jbed) support. 1. BlueCove Let’s start with the compatibility issues. 1.1 Real-world (!) compatibility First, it’s only IBM J9-compliant (NO TAO, NO Jbed, NO Jblend). Even under J9, unfortunately, it’s (as of this writing) pretty much far away from REALLY working. While it correctly implements Bluetooth discovery, in general, it doesn’t go further and just crashes at actually connecting (not only discovering). I’ve tested this with both the Microsoft and the Widcomm Bluetooth stack, using version 6.1.1 (that is, the latest one) of IBM J9. My compliance test results are as follows: Super Bluetooth Hack 1.07 (note that the two (2nd/3rd) versions are exactly the same): doesn’t even start (IncompatibleClassChangeError with Vector) Blooover discovering works; the actual connection doesn’t (IncompatibleClassChangeError with javax.microedition.io.Connection). 3D Constructo Combat: The same: it is able to discover other devices: { "lightbox_close": "Close", "lightbox_next": "Next", "lightbox_previous": "Previous", "lightbox_error": "The requested content cannot be loaded. Please try again later.", "lightbox_start_slideshow": "Start slideshow", "lightbox_stop_slideshow": "Stop slideshow", "lightbox_full_screen": "Full screen", "lightbox_thumbnails": "Thumbnails", "lightbox_download": "Download", "lightbox_share": "Share", "lightbox_zoom": "Zoom", "lightbox_new_window": "New window", "lightbox_toggle_sidebar": "Toggle sidebar" } but, upon actually connecting to them (or, when you start it in server mode), it immediately crashes and exits. 1.2 Downloading, installing If you still want to give it a try (again, it’s pretty much useless as of now!): Get bluecove-2.0.1.jar (version as of 11/23/2007) from HERE if you have WinRAR on your desktop Windows machine, enter the WinRAR bluecove-2.0.1.jar command; otherwise, rename bluecove-2.0.1.jar to bluecove-2.0.1.zip and click it so that its content is shown; extract bluecove_ce.dll and intelbth_ce.dll from the root of the archive; transfer them to the \bin subdirectory of your IBM J9 installation. Note that if you don’t want to hunt for / extract these files yourself, I’ve made them available HERE as a standard ZIP file. Just unZIP it and transfer the two DLL's. copy bluecove.jar to the \lib\jclMidp20\ext directory of your IBM J9 installation. If “ext” doesn’t exist, create it. you’ll need to use special link files to start your Bluetooth-enabled MIDlets. This also means you don’t need to deploy your MIDlets under J9 at all as direct links of this type don’t require the MIDlets to be deployed beforehand. A typical link file looks like this: 255#"\Storage Card\ibm\bin\j9.exe" -jcl:midp20 -Dmicroedition.connection.pkgs=com.intel.bluetooth -cp MIDletName.jar "-jxe:\Storage Card\ibm\lib\jclMidp20\jclMidp20.jxe" MIDletName.jad (An example link file is HERE as a real file.) In here, change MIDletName to the filename of the MIDlet and, of course, change \Storage Card\ibm to the actual path of your IBM J9 installation. Note that you’ll also need the JAD files in this setup. Should you not have them, use the free JADMaker to create them from JAR files (see the link for more info). If you don’t provide any absolute directories in the link file to the JAR / JAD files, then, you’ll need to copy the JAR file to the \lib\jclMidp20\ext directory of your IBM J9 installation before invoking the MIDlet through the link file. This is the same directory where bluecove.jar should reside. Also, the JAD file must be in the same directory as the lnk file itself. 2. Some additional hacking 2.1 Nokia classes missing in the game If you try to run 3D Constructo Combat under J9 (I’ll elaborate on other MIDlet managers later), you’ll notice at once it doesn’t run. The sole reason for this is the lack of some Nokia-specific libraries in the MIDlet manager. You can, however, easily “hack” these classes into the JAR file of the MIDlet itself. To do this, first, download THIS archive and unZIP it. Second, get WinRAR and, after installing it, enter the WinRAR jarfilename command to open the JAR (the main MIDlet) file. Now, just drag-and-drop the com directory (with all its subdirectories, of course) to the opened JAR file – making sure you don’t drop it on a directory, but in the root. That’s all; now, your MIDlet might start. Note that this definitely works with 3D Constructo Combat and J9 but will NOT work with Jbed, not even with the permission hacking I’ll explain in the following section. (also see THIS Russian-language post for more info if interested. It doesn't contain much additional info, though.) 2.2 Permission hacking As has been explained in the MIDlet Bible, some (very few!) MIDlets can’t even be deployed under Jbed (and other, less recommended) MIDlet managers. The reason for this is the deployment-time permission checking. An example of these MIDlets is 3D Constructo Combat, which is refused to be deployed because of the unavailability of a library (here, a Bluetooth one): You can easily help this and make MIDlets at least deployable (being actually runnable is another question). To do this, enter the WinRAR MidletFileName.jar command and extract the META-INF\MANIFEST.MF file. In there, look for the MIDlet-Permissions: row. For example, with 3D Constructo Combat, it’ll be the following: MIDlet-Permissions: javax.microedition.io.Connector.bluetooth.client,javax.microedition.io.Connector.bluetooth.server Just delete it and overwrite the original META-INF\MANIFEST.MF file with the new version, all this in the JAR file. Again, the new file no longer contains the MIDlet-Permissions: row. Now, the MIDlet at least becomes deployable as can also be seen in THIS screenshot. (This, again, doesn’t mean Jbed will be able to run it as well. It won’t, not even with the above-explained Nokia class hack.)
UPDATE (11/24/2007): At last: an M3G-capable, much more gaming-friendly Jbed version is out! As is stated in the Bible (as can also be seen in the main game compliance chart), the recommended, current version of Jbed has very limited game compatibility. If you do want to use it and do need to run for example M3G titles, so far, you needed to turn to alternative and, in many respects, inferior MIDlet managers. Now, this has changed: thanks to XDA-Devs forum members viperj and defcomg, a brand new and really great version has been posted. This is version 070524.2.1 - that is, slightly older than the current, 070802.2.2 version. The major disadvantage of this version, compared to the 2.2 one, is the complete lack of sound emulation. It runs all the games running under the old, M3G-capable Jeodek (see their list HERE) and is very fast. Furthermore, it isn’t affected by the locale bug of version 2.2 – that is, the inability to run under any locales using a language with a non-Western alphabet (for example, most East-European languages). I’ve tested it with I-Play’s FIA World Rally Championship 3D, Namco’s Arcade Golf and High Speed 3D. All these worked flawlessly (except for, of course, the complete lack of sound), unlike under 2.2. Under 2.2, they didn't even start or crashed later. If you really need sound emulation and it’s indeed able to run the given title, you will still want to version 2.2 of Jbed, though. For example, it runs Simcity Societies with great sound. Installation To install it, just grab THIS file, unRAR it to, preferably, the “J” subdirectory on your storage card (so that jbed.exe is right in the “J” subdirectory) and import THIS Registry import file (change all occurrences of "Storage Card" to the name of your card if it has another name). You might also want to copy a link to the main executable, jbed.exe, to \Windows\Start Menu\Programs (or, just \Windows\Start Menu\ on MS Smartphones). I’ve created the link file HERE.
UPDATE (01/16/2008): In the meantime, it has turned out that you can use the non-M3G-specific version of Jbed (that is, Cloudyfa's 20070802.2.1) with any localizaton setting if and only if you start your specific MIDlet directly; that is, via a system-level shortcut. I've also been using Opera Mini 4 on the Blackberry 8800, using the default MIDlet manager coming with the device. Note that, unlike the built-in Web browser and the mailer, you MUST specify the APN of your operator for it to work. Otherwise, it'll just report being unable to connect to the Net after starting (and a lengthy installation process). To do this, go to Options / Advanced / TCP?IP and enter your APN (for example, "Internet" with T-Mobile.)
UPDATE (02/01/2008): There are new builds of both Jbed and Jblend (two excellent MIDlet Managers – see the Java MIDlet Bible for more info). Due to lack of time, I haven’t tested them. Both has been done by Da_G (his projects’ homepage is HERE) and are accessible HERE. Note that you MUST register yourself (it’s free and is done quickly) in order to access the page above (along with the download). I hope I’ll be able to test them some time – along with the default Blackberry MIDlet manager. (I might wait with testing the latter until version 4.5 of BB OS is released, though.)
UPDATE (02/06/2008): Another Jbed MIDlet Manager version has been released: JRebeiro_EsmertecJbed_20071119.3.1. It’s available HERE (at the bottom of the first page). As I don’t have the time to thoroughly test it, feedback is REALLY welcome!
Menneisyys said: UPDATE (02/06/2008): Another Jbed MIDlet Manager version has been released: JRebeiro_EsmertecJbed_20071119.3.1. It’s available HERE (at the bottom of the first page). As I don’t have the time to thoroughly test it, feedback is REALLY welcome! Click to expand... Click to collapse There is a hacked version of 3.1 that: - increases heap size - disables all permission prompting - enables midlet filesystem access - installs anywhere cab I only use Opera Mini so I don't see much of a difference with 3.1 compared to 2.1, but I like like not having do hex editing to disable the permission prompting for each new midlet installed. I guess the main thing that 3.1 has over 2.1 is 3d game support, but the 3.1 application size is much bigger and someone did mention that 2.1 may run faster than 3.1 in certain things. Does anyone have a link to how we can introduce the same hacks to 2.1 for those of us that just need a light-weight jvm? I did a little write up on these hacked jvm's here: http://www.modaco.com/content/HTC-J...-com/265919/A-few-JVMs-for-you-to-play-with-/
Downloaded the WM 6 version for my LG KS20 and finally it's showing fullscreen and games working that didn't work with the orig. embedded java However, the 2 softkey-buttons are no more available. These 2 are important for most games/apps and the KS20 doesn't have a keypad. Is it possible to display the 2 softkey-buttons again? Or a hack to map those keys to the Accept/Decline Hardware Buttons if Java is active?!
UPDATE (03/09/2008): Sun to develop MIDlet manager for Apple's iPhone? NOTE: this isn't strictly a Windows Mobile news item (albeit it also contains Windows Mobile references; see for example the Sun MIDlet Manager on some new HP’s). However, now that I've spoken to the Sun reps at MWC (I'm a Java guru and have also worked for Sun as a lecturer for their Java programming courses) and also spotted their own MIDlet manager on the HP iPAQ 610 series, I found it necessary to report on this. Finnish mag Tietokone has just reported on Sun's wanting to develop a JVM for iPhone so that it can run the vast number of MIDlets out there (including, for example, Opera Mini and thousands of games, some of them - like Simcity Societies - of very high quality). Interestingly, Steve Jobs (of Apple), who still haven't commented on Sun's announcement, earlier stated in NYT "noone uses Java any more". Sour grapes? (It was, so far, impossible to run third-party apps on iPhone - except for some, just-released titles like CorePlayer.) I pretty much think he quickly changes his opinion - after all, a decent MIDlet Manager would be more than welcome on iPhone, which still lacks third-party apps / games. It's nice to see Sun indeed plans to port their stuff to iPhone. While their Windows Mobile implementation, according to some Opera Mini users, has a lot to be desired (I haven't personally checked the validity of their claims so I may be entirely wrong), I really hope Sun starts to take mobile platforms more seriously.
UPDATE (03/13/2008): New MIDlet manager in development: PhoneME; Jbed for WM2003(SE) released! There are two pieces of news for everyone interested in running Java MIDlets. The first will be having a pre-WM5 device and wanting to run Java MIDlets (for example, Opera Mini) on it. Yes, at last, some Russian hackers made Jbed, the industry-leading MIDlet manager work under WM2003(SE)! The second (and, for most people, not that important) piece of news concerns a brand new MIDlet manager port for Windows Mobile. 1. Some Russian hackers, including the 4pda.ru folks, have, at last, managed to make Jbed, the best MIDlet manager, work under WM2003 and WM2003SE. The importance of this just can’t be stressed enough: so far, you only had the really inferior IBM J9 and the 10-series TAO MIDlet Manager to run MIDlets on pre-WM5 operating systems. Now, this has dramatically changed. Now, nothing will stop you from using Opera Mini on your pre-WM5 Pocket PC. The direct link to these WM2003(SE) MIDlet Managers are as follows. There are three versions: a modded one, a non-3D one and a 3D one; all with a heap size fix. JBed3dMod_HeapSizeFix Esmertec Jbed heapfix Esmertec Jbed3d heapfix They have also made a MAJOR update to their 4PDA.ru MIDlet article, linking to all the contemporary Esmertec, TAO etc. versions (including ones with heap fixes, with and without 3D support etc.); the above links can also be found in their article. You can see the translation of the new page HERE (Google) and HERE (Babelfish). Note that I’ve kept the original page HERE (Google) and HERE for historical reasons for people interested in the pre-Esmertec times. 2. Now, the other piece of news, which, again, won’t be of that much interest to non-WM2003 / non-Java hackers. Java is a really viable programming platform. Not only several high-quality games make it worthwhile, but also probably the best and, if you’re lucky enough with your geographical location, fastest and most bandwidth usage-friendly mobile browser available for mobile phones (including Windows Mobile), Opera Mini 4. I’ve already devoted an entire all-in-one Bible to running Java on Windows Mobile (and Symbian). Now, let me introduce the latest Windows Mobile KVM: PhoneME. PhoneME is another "let’s bring Java to various platforms” projects (official homepage HERE), which has recently received Windows Mobile support. The main homepage of the Windows Mobile port is HERE (do NOT get the ones at the official download page of the project - they’re outdated!) Should you want to download the MIDlet manager, get the file starting with "phoneME Feature – MIDP” from the download page. Get the CAB file; install it. (I assume you install it in the main storage of your handset; my MIDlet manager main lnk file and registry import file will be tailored for this install location.) After this, you’ll need to associate JAR files with the app; to do this, you’ll need THIS file (import it into the Registry!). You might also want to invoke the MIDlet manager directly; for this, you’ll need THIS file. Unfortunately, currently, the MIDlet manager is pretty much useless; for example, it seems to be impossible to deploy Opera Mini 4 under the current (8525) MIDlet manager version: (Interestingly, the 4PDA.ru folks reported they managed to deploy an older version of OM; however, they didn’t particularly like the way it ran. That is, they also state the current version has a lot to be desired.) All in all, you will NOT want to check it out in its present form. I’ll try to let you know when a considerably better, more advanced version is released. Still speaking of the project, the Personal version (not to be mistaken for the MIDP MIDlet manager!) seems to run standalone (Personal profile) apps OK (it does NOT have an Internet Explorer Mobile applet plug-in, though). An example of running the Hello World application available on the homepage as a separate download: (Should you want to give it a try, assuming you installed the MIDlet manager in the built-in storage of your handset, use an invocation .lnk file with the following contents: 254#"\phoneme\personal\bin\cvm.exe" -cp "\phoneme\hello" Hello Also make sure you unZIP the contents of the archive to \phoneme\hello.) That is, if you’re into running Personal Profile applications (and not MIDlets), you might want to give it a more thorough try. (Thanks to my blog reader thevery for drawing my attention to the project!) Additional info A related forums.java.net discussion (not very interesting for anyone not interested in recompiling the sources) 4PDA.ru’s related discussion (translated) HERE (Google) and HERE (Babelfish).
UPDATE (03/14/2008): a. unfortunately, the WM2003(SE) Jbed version has turned out to be only compatible with Pocket PC Phone Edition devices, NOT plain (phone-less) Pocket PC’s. There still aren’t WM2003(SE)-compliant SMS.dll and phone.dll files. These two files are needed on WM5+ standard (“classic”) Pocket PC’s to make Esmertec’s products / Jblend work. While the “hacked” DLL’s are compatible with WM5+, they aren’t with previous operating systems. That is, you’ll need to wait for a WM2003(SE)-compliant set of “hacked” DLL’s to be released. Also note that there are some WM2003SE Phone Edition models that seem to be completely incompatible with; most importantly, the Qtek 2020i. Also note that some? all? of the (again, currently, only WM2003(SE) Phone Edition-compliant – do NOT bother if you only have a phone-less PDA!) contain wired-in paths. For example, the one linked to from THIS page (see daemonpnz’s post at 10.02.08 10:22:56) must be extracted to “\Storage Card\jbed0524\”. Should you want to put it somewhere else (because, for example, your PPC PE device is a non-English one), you’ll need to hexedit Jbed.exe inside the RAR file and change the two occurrences of the above path to your liking. An example showing changing the space character to a B in "Storage Card". (Incidentally, the reason for this was the following: I’ve tested it on my HP iPAQ 2210, which is a dual-slot machine, using the card names SD Card and CF Card. As you aren’t allowed to create a directory named “Storage Card” in the root of the file system, I had to hexedit the file so that it uses another name. “StorageBCard” can already be created. Note that, as the HP iPAQ 2210 is a no-phone device, this didn’t help much as it still refuses to run. Again, because of the still-missing, WM2003(SE)-compliant SMS.dll and phone.dll files.) I let you know when Jbed becomes compatible with non-phone pre-WM5 devices. b. I’ve also tested some of the versions linked from the 4PDA.ru thread on my HTC Vox (s710) to find out whether they’re any good compared to the old MIDlet managers; particularly Cloudyfa’s version - the version that, so far, I’ve recommended to all MIDlet users (unless in need for M3G (3D) support.). These two are both “fixed heap” versions; some of the less simple games (for example, DoomRPG) and benchmark apps with large memory requirements are stated to run much better / more reliably in the fixed heap versions than in the regular ones (for example, that of Cloudyfa) because of the much bigger available memory. I haven’t tested the effects of this myself. 1. JBed3dMod_HeapSizeFix (that is, 3D-capable Jbed version, based on 20070524.2.1, with fixed heap) I was really interested in how this (and an additional, hacked file available for download HERE - just overwrite JBed.exe of the original, already-installed version with JBed3d_SreenFix.exe after renaming) worked because, at 4PDA.ru, there’s a version that promises flawless, screen problem-free functionality on MS Smartphones also compatible with the excellent Gmail client MIDlet. (Also see THIS (original HERE) for more info; see freesunny's post at 10.01.08 10:56:06.) So far, it seemed impossible to make the latter (the Gmail MIDlet) flawlessly work on MS Smartphones under any version of Jbed. An example of the display problems the non-hacked version (or any Jbed version) can be seen in the following screenshot: Unfortunately, the hacked version (after overwriting the EXE file with the separately downloaded JBed3d_SreenFix.exe) doesn’t really work with Gmail: while indeed the entire screen estate is used, the three lowermost menu items (Search, Compose New, Exit) aren’t visible, just like with the non-hacked case: Note that essentially the same results from the 4pda.ru folks can be HERE. The same problem also exists in Portrait mode, not only in Landscape. All in all, while it’s certainly a step in the right direction, you will still have problems with (at least) the Gmail MIDlet. If you absolutely hate the missing display area in the MIDlet listing on MS Smartphones with the old Jbed versions, you might want to consider upgrading, though. 2. I’ve tested JBedModHeapFix (02.01.08) too – a somewhat extended and fixed Jbed version. While it does have certain advantages over Clodyfa’s version, it entirely lacks music support and is based on the 20070802.2.1 version – that is, the same “old” version as that of Clodyfa and not anything newer. I don’t really recommend it if you need sounds / music, which is excellent in the Cloudyfa version – again, unlike any other (earlier!) versions I’ve tested, including earlier Jeodek versions like the 20070425.1.1 version coming in the original (and just-updated) firmware of the HTC Vox / s710 and having very bad and distorted sound. Note that the Jbed version lacks the the English jbed.exe.0409.mui file – it only has the Russian localization, that is, jbed.exe.0419.mui. This means, unless you copy the (standard) jbed.exe.0409.mui file from, say, the Cloudyfa version to the new one, it’ll have messed-up, invisible menus. I’ve also tested whether these two versions, finally, fix the two biggest problems with the Cloudyfa version: it’s not possible to install Cloudyfa’s version on the storage card: with the new Jbed version, it’s possible – without any manual hacking. In this regard, it’s much more recommended than Cloudyfa’s. (Haven’t tested the Jbed3D version in this regard.). That is, you can safely direct the CAB installers to install the managers onto a card: they WILL be installed there, not taking up any built-in storage. with Cloudyfa’s version, it’s not possible to start MIDlets from inside the Jbed interface if you use a localization using not strictly Western characters: Fortunately, both the non-3D and the 3D versions available at 4PDA.ru are compatible with non-Western regional settings, unlike Cloudyfa’s version. (Note that, in the original Cloudyfa version, you can still execute MIDlets via a direct invocation link file if you have an otherwise incompatible regional setting, circumventing the standard interface listing all your MIDlets. This, however, needs some additional tinkering and, again, you won’t be able to select the MIDlet you’d like to run from the built-in list of the MIDlet manager. Also note that I’m speaking of the generic Regional settings, NOT the language of MS Smartphones (you can easily change the entire interface language of MS Smartphone devices.). Your MS Smartphone language may be, say, East-European; if you still use some non-Eastern regional setting, the apps started from inside Cloudyfa’s version will still run and you won’t need to use direct invocation link files.) Also note that neither of these versions have any sound emulation. This, again, isn’t a change from the previous 3D (M3G)-compliant version but can be VERY bad news for plain non-M3G-compliant Jbed users, as, again, the Cloudyfa version has excellent music / sound emulation. That is, stick to the latter if you need music.
UPDATE (some 5 hours later): I’ve also tested the latest Jbed version, JRebeiro_EsmertecJbed_20071119.3.1. I’ve already mentioned it HERE but, then, I didn’t have the time to thoroughly test it. The bad - not possible to install it to a storage card by default - display problems on MS Smartphones (as with all the other Esmertec Jbed versions – except for the M3G-specific, hacked 4pda.ru version). Note that, again, this doesn’t have any effect on how Opera Mini 4 or games work; only the main MIDlet manager MIDlet lists and, for example, the Gmail MIDlet are affected The good - the latest version; reported to be very fast - M3G compliant - has sound (as with Cloudyfa’s version)!! All in all, highly recommended for gamers. It’s available HERE (mirrored HERE so that you don’t need to search / register). Also see THIS German language Pocket Players Reloaded article on the games it’s compatible with.
UPDATE (03/20/2008): 1. THIS and THIS posts in THIS thread (from an iPAQ 210 user) might be of interest to, for example, Opera Mini users. 2. I’ve published a review of SHAPE Services’ TSMobiles: Terminal Service Client for Mobiles (cross-posts: AximSite, XDA-Developers - 1, BrightHand, HowardForums, MoDaCo), a Java-based remote desktop accessor, RDP-compliant client. It works pretty well on Windows Mobile, both Pocket PC’s and MS Smartphones, under (the latest, 3.1 version of) Jbed, the best MIDlet manager for Windows Mobile. (Incidentally, this also shows what’s Java is capable of – this MIDlet is REALLY nice and fast, even by Windows Mobile standards!) 3. Pinned (sticky) at the highly popular MoDaCo Smartphone General Discussion (screenshot of this HERE)