Find Your Device:
Or Continue to Thread: The (Java) MIDlet Bible
21st April 2008, 04:43 PM |#76  
Senior Member
Thanks Meter: 0
202 posts
Join Date:Joined: Mar 2005
Originally Posted by Menneisyys

UPDATE (04/19/2008):

1. Unfortunately, it seems none of the Jbed 3.1 versions are able to run Opera Mini 4.1 beta on touchscreen-less MS Smartphones (but NOT on Pocket PC's!!!) if you switch to other apps (for example, the home screen) and, then, back, you will no longer be able to control Opera Mini. I've tested this on my WM5 s310 / Oxygen (major problems) and, with HTC's recently-released ROM upgrade, upgraded WM6 s710 / Vox (not that frequent problems but still annoying). At XDA-Devs, other people have also reported the same problem with their Smartphones.

If you do encounter problems like this and can't refrain from task switching, you'll want to downgrade to the Cloudyfa 2.1 version available HERE. Note that it can safely co-exist with 3.1 if you've installed the latter in another directory (for example, on a storage card or a flash disk) - then, it's only the file associations that will be needed to, say, quickly switched if you don't want to manually deploy a MIDlet from inside the GUI of the specific MIDlet manager. That is, you don't need to delete Jbed 3.1 if you plan to keep it for example for M3G gaming.

Note that touchscreen-equipped Pocket PC's do NOT suffer from this problem!

This is not something specific to just Opera Mini as the gmail applet has the same issue. So I'm guessing it's a JVM issue and not a midlet issue.

One thing you may want to investigate is Jbed's background running option. If I run jbed, turn on background running, then launch opera mini, the problem seems to not occur with my limited testing. Since I prefer to directly launch opera mini, it would also be nice to have a way to enable background running by default.

If enabling background running really fixes the issue, then I guess it's a bug with jbed 3.1 restoring itself from its own suspend mode.