Version 0.3.92 is underway.
Biggest spectacle of this is cartridge saving and loading. A few moments ago i have successfully stored and restored a game of Wherigo Player Tutorial.
Technical details about the solution will follow in a separate article.
And that's pretty much it. There's the usual bunch of random bugfixes, minor improvements and extended Wherigo functionality (did i tell you that you can now see a zone map?), but probably nothing to write home about.
Oh, and i switched back from NetBeans' default proguard 4.2 (obfuscator/optimizer) to older 3.9. The new one is too aggressive in optimizing and still has some bugs. I identified and reported one, but it's not yet fixed, so i can't really continue the search. And i don't need the stress of hunting bugs that aren't there.
Showing posts with label NetBeans. Show all posts
Showing posts with label NetBeans. Show all posts
August 2, 2009
November 3, 2008
testing FileConnection with the J2ME emulator
...is difficult at best, and impossible most of the time.
UPDATE: ...CAN be very easy, IF you "specify the security domain" in NetBeans (and choose Manufacturer, for best results). All the problems mentioned below disappear, because the emulator stops asking questions. But if you want to test behavior on regular phone with no rights, you'll have to test on an actual phone - read on.
one: unlike most (if not all) phones, the emulator runs confirmation windows in the same thread as commandActions.
That means that if you try to do anything file-related from a commandAction, a security confirmation pops up and you can't dismiss it, because your command thread is (dead)locked waiting for the result of this confirmation.
Oh well, I made my file browser run the file commands in a background thread.
two: unlike all phones, the emulator wants a security confirmation for each and every method call on the FileConnection object. And it does not remember permissions. Therefore, listing a directory takes three confirmation clicks, and every time you want to re-read a file, another confirmation (which is likely to deadlock you, for reason one).
three: the emulator (at least version 2.5.2 in linux) creates a brand new tree structure for each run. And it appears that you can't choose what will appear in that structure. So if you want to test opening a specific file, you have to copy it into the proper location every time.
(although i remember that it behaved slightly differently on my notebook. i'll have to check that out too)
and all's good when the end's good, four: do not ever in your life try to "mount" parts of your filesystem into the emulator by linking them to the temporary filesystem root.
Upon exiting, the emulator happily descended into my directory and recursively deleted it. Fortunately, there wasn't anything irreplaceable, or i haven't noticed yet; but i lost a good hour of work.
Good to know, though, is that there is now a way to undelete files from an ext3 filesystem. Didn't help me, though; the software insisted on segfaulting. It's apparently a known problem with "large partitions on some 32bit systems".
UPDATE: ...CAN be very easy, IF you "specify the security domain" in NetBeans (and choose Manufacturer, for best results). All the problems mentioned below disappear, because the emulator stops asking questions. But if you want to test behavior on regular phone with no rights, you'll have to test on an actual phone - read on.
one: unlike most (if not all) phones, the emulator runs confirmation windows in the same thread as commandActions.
That means that if you try to do anything file-related from a commandAction, a security confirmation pops up and you can't dismiss it, because your command thread is (dead)locked waiting for the result of this confirmation.
Oh well, I made my file browser run the file commands in a background thread.
two: unlike all phones, the emulator wants a security confirmation for each and every method call on the FileConnection object. And it does not remember permissions. Therefore, listing a directory takes three confirmation clicks, and every time you want to re-read a file, another confirmation (which is likely to deadlock you, for reason one).
three: the emulator (at least version 2.5.2 in linux) creates a brand new tree structure for each run. And it appears that you can't choose what will appear in that structure. So if you want to test opening a specific file, you have to copy it into the proper location every time.
(although i remember that it behaved slightly differently on my notebook. i'll have to check that out too)
and all's good when the end's good, four: do not ever in your life try to "mount" parts of your filesystem into the emulator by linking them to the temporary filesystem root.
Upon exiting, the emulator happily descended into my directory and recursively deleted it. Fortunately, there wasn't anything irreplaceable, or i haven't noticed yet; but i lost a good hour of work.
Good to know, though, is that there is now a way to undelete files from an ext3 filesystem. Didn't help me, though; the software insisted on segfaulting. It's apparently a known problem with "large partitions on some 32bit systems".
May 27, 2008
four quick notes about j2me
one: Obfuscation must be handled with care.
If you choose to obfuscate your midlet, you gain two things: the final size will be reduced, and the contents will be hard to disassemble.
But. If you turn on obfuscation in NetBeans, it will be used for your local debug builds as well. Due to that, you will lose debugging information, notably filenames and line numbers in stack traces.
two: Version strings must be handled with care.
My phone (SE K610i) refused to install a midlet with version "0.2.991", or anything longer than 6 characters. A different phone (Siemens CX65) installed a midlet with version "0.2.99sync1", which then mysteriously crashed with a NullPointerException that wasn't there with version "0.2.99".
This is bad magic. If anyone can explain it, please do.
three: From what i gathered, there is no way to list files contained in a JAR at runtime.
If you want to do that, create a text index at compile time and include it in a known location.
and four: Some older phones, even though MIDP 2.0, don't call Canvas.sizeChanged event.
Or maybe they do, but not (citing the spec) "at least once before the
So don't rely on it.
If you choose to obfuscate your midlet, you gain two things: the final size will be reduced, and the contents will be hard to disassemble.
But. If you turn on obfuscation in NetBeans, it will be used for your local debug builds as well. Due to that, you will lose debugging information, notably filenames and line numbers in stack traces.
two: Version strings must be handled with care.
My phone (SE K610i) refused to install a midlet with version "0.2.991", or anything longer than 6 characters. A different phone (Siemens CX65) installed a midlet with version "0.2.99sync1", which then mysteriously crashed with a NullPointerException that wasn't there with version "0.2.99".
This is bad magic. If anyone can explain it, please do.
three: From what i gathered, there is no way to list files contained in a JAR at runtime.
If you want to do that, create a text index at compile time and include it in a known location.
and four: Some older phones, even though MIDP 2.0, don't call Canvas.sizeChanged event.
Or maybe they do, but not (citing the spec) "at least once before the
Displayable is shown for the first time." [here] Or maybe they even do that, but don't specify the proper size.So don't rely on it.
April 5, 2008
versioning in NetBeans
Subscribe to:
Posts (Atom)