Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

Greetings,
i want to ask does whatsapp work?

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

I have "unzip add-on for the file manager" and InfoZIP's Unzip" on my n900, so think that isn't the problem.

I will try the new version.

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

It crashed again after 2 minutes.

Here you have the output:

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

OK, I think the crash is due to the quick hack dummy JSR 135
implementation for audio playback.

Other people confirmed if they enabled audio, their app would crash.
When disabled, this did not happen.

Davy

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

Been doing page comparisons, not much difference in speed between v1202 and 2302, though there is a speed improvement when rendering small text. It was worth a try anyway to see if rendering speed improved as there may be situations where it helps. :)
When the font size and rendering settings become configurable then the right balance can be set for any java mobile app.

I did notice both versions scroll smoother in full screen compared to windowed mode. In which case I use ctrl+backspace to switch between windows.

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

I can acknowledge the speed increase when running midlets in full
screen. The rendering speed almost doubles, not only for text but other
drawing operations too. This is a qt4/graphics driver optimization, not
anything in my code.

Given you can always go back to other apps with Ctrl+Backspace,
maybe it would be good to start midlets by default in fullscreen too on
the N900?

Cheers,
Davy

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

Good point - it would be good to have it as a command line option.

If switching to full screen it would be worth sending a pop-up notification stating the full-screen and task manager keyboard shortcuts in case the user doesn't know about them
Or if starting full screen it would help to have the message appear shortly after launching the midlet,

http://wiki.maemo.org/Phone_control#Notifications

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

I deleted my icon and tried excalibur scrip.

It created the icon and i rebooted my n900, but the icon doesn't have any image, it is only a blue box.

Btw when i ran it, i saw this error on the x-terminal:

error: cannot create /usr/share/icons/hicolor/scalable/hildon/ico22.png
Permission denied
mv: cannot rename '/usr/share/icons/hicolor/scalable/hildon/ico22.png': No such file or directory

Edit:

I tried it again with sudo gainroot and it fixed the icon image.

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

In my latest online deb available from

http://davy.preuveneers.be/phoneme/public/maemo/deb/

I introduced to command line options to the /opt/phoneme/bin/cvm
binary (i.e. not yet the runmidlet binary)

-fullscreen: starts midlet in fullscreen (on N9 this option has no effect as fullscreen is automatically set to avoid the grey bar at the
bottom)

-fastfont: use the fast monospace built-in font for faster text rendering

Change your desktop shortcuts or scripts like the following to see the
effect of both options:

/opt/phoneme/bin/cvm -fullscreen -fastfont -Xmx12m ...

At some point I will also make these command line parameters available
for the runmidlet binary, as well as through a configuration file, etc.

Cheers,
Davy

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

when i play my game, i can not see the below section of the screen, so i always change it to fullscreen to be able to see all the screen.

In this version, it starts in fullscreen by default, but i can not see the below section again, even in fullscreen.

If i run it without -fullscreen, i don't have that problem.

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

Bryan maybe there's not icon on the midlet ?

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

I tried it again with sudo gainroot and now it has an image.

Maybe you need to add "sudo" somewhere in your script.

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

Did you add savegame support in the last version? because now it saves the game :)

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

Davy: did u add the sound support? becouse mine doesnt work

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

No sound support yet from what I can tell - there was a dummy hack to avoid crash.

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

I looked into the issue with this game (which was not that obvious without having access to the source code).

Based on my observations, this seems to be an issue with the game itself rather than with the VM. The game is not capable of resizing its canvas and changing the layout whenever the available screen real estate changes (e.g. display height increases when going full screen).

I think the game basically detects the width and height at the start of the game, and then assumes they stay that way. Perhaps the midlet was targeted to a particular device for which this is true, but for the N900 this assumption is not valid.

The only fix for the game is to have it support dynamic re-layouting (like e.g. Opera Mini which also uses a canvas to render its stuff).

Cheers,
Davy

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

I did not do anything particular to support savegames. Perhaps it was a side effect of another bug fix. I am guessing this game is using record stores to save games statuses, and that this previously failed due to write permission errors.

Davy

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

No, to add proper sound support I have to implement the JSR 135 spec (at least the audio playback part), and this takes (a lot of) time.

For now, the implementation only provides dummy methods so that at least some games can be played without sound (otherwise they might complain about missing classes and missing methods).

Davy

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

Can we help you in some way? you are doing a big work, we want to have a nice JVM (yet it is) but we miss some features, we want to help you in some way becouse you need time and you cannot do everything alone

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

The biggest problem is there are many JSR specifications, but only few open source implementations. Many others do not exist or are closed source (the Mobile 3D Graphics API JSR 184 comes to mind which is often used in high end games). For those for which we do have an implementation, there is usually only an implementation for Windows or Linux on x86 systems. The biggest amount of work is making this work on other mobile platforms. Based on my experience with WinCE/Windows Mobile, Android and now Maemo, I can say that the most difficult part is bridging the JSR APIs with the underlying platform libraries (for the N900/N9 this would be a.o. Qt4, liblocation, etc.) and making sure that:

1) it works reliably for not just one midlet but for all midlets (in the sense that midlets may have different ways to achieve certain things and you have to support them all) as I don't have access to the Java ME Technology Compatibility Kit to test for compliance.

2) you have a framework in place that allows you to bridge new JSR apis more easily with the platform APIs. This decreases the amount of work later on if you add support for new APIs, but requires more effort at the start the get the proper foundations and abstractions right. It also helps with portability to new platforms or new platform editions.

Now, for this you need to be somewhat familiar with JavaME specs and how to compile and integrate new (platform specific) stuff in phoneME so that all features are available from Java source code (i.e. the midlet code), while ensuring there is no (significant) performance bottleneck. I have learned this the hard way through trial and error during the several years I was doing the WinMo and Android ports. Mapping Java ME text rendering methods on those that Qt4 provides is a notable example. You need to figure out how to write text on a 16-bit RGB array while avoiding copying back and forth large RGB buffers between JavaME and Qt4 because it slows down the overall rendering process.

The best way for the community to help me out is to help with the testing. I now have a N900 which at least helps me to test for performance bottlenecks (thanks again donators). However, I only use a few (freely available) midlets. So if the community can help with testing other midlets as well, that would be nice. The biggest problem is usually that we do not have the source code of commercial midlets to figure out why they don't work. Sometimes they make use of an API that is currently not yet supported, sometimes it is a bug in my port.

I am also much interested in feedback from N9 owners, because there seems to be some subtle differences with this platform compared to the N900. Various libraries (e.g. those for GPS that I need for JSR 179/Location API) are either not available or do not work on the emulators. So I only have the N900 to test on and hope that they will also work on the N9.

Another way to help me integrate new features is to provide pointers to small working examples in C or C++. For example, to support JSR 179, I need to know how to access the GPS. I spent some time looking for simple minimalistic applications with source code that I can easily compile showing how get to the data. Such example applications make it a bit easier to figure out how to integrate this code in the JavaME vm. So just pointers to the API documentations of Qt4 don't really help (I can google myself :-)). Also, I like to avoid dependencies as much as possible (so e.g. no pointers to GPS daemons written in Python). Too many components in the middle cause too much overhead and latency, and makes it very difficult to pinpoint the location of a bug when a midlet does not work the way it is supposed to. At this point I already have such examples for GPS and simple (file based) audio playback. So hopefully support for these features will soon be integrated in next release. Stay tuned!

Damn, this post is longer than I intended it to be :-)

Cheers,
Davy

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

First, thanks a lot for this!

The java midlet from the German railways runs quite well with phoneme (but of course without GPS).

However, I have trouble with the german Handyticket app, which would be quite useful to have:
http://www.handyticket.de/curr_ver/G...hPhone-dht.jar

It starts the main menu fine, but any selection results in a network server error in the layout of the app.
Log files (err and out.txt) are empty, so there is little more I can say.

For the app to be useful one would need to register, but to reproduce the error it is not necessary.
Any help would be appreciated as the midlet is much more convenient then the web version.

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

My latest build now includes a "MIDlet Settings" application (i.e. /opt/phoneme/bin/settings) which allows you to set some default properties for running a midlet. More details are available at:
http://davy.preuveneers.be/phoneme/?q=node/34

You can find the latest debian archive on the download page or at:
http://davy.preuveneers.be/phoneme/public/maemo/deb/

If you use the 'Run MIDlet' application (i.e. /opt/phoneme/bin/runmidlet) to start a midlet, it will use your current midlet settings (by default fullscreen enabled and the other options disabled)

If you create a desktop shortcut file that executes /opt/phoneme/bin/cvm (rather than /opt/phoneme/bin/runmidlet), you can override the above settings with the following command line parameters to /opt/phoneme/bin/cvm:

-fullscreen
-nofullscreen
-bitmapfont
-nobitmapfont

This is e.g. useful if you do only want to run certain midlets in full screen.

Regards,
Davy

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

I just tried a gps app called Mario advisor to see if at least it starts. But i got this error:

---------------------------

Nevermind, it works now.

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

Is there any Wiki with a list of compatible applications?

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

at the end of this page, you'll find an example to use liblocation api

Link: http://wiki.maemo.org/Documentation/...g_Location_API

Also down here attached you have a Qt example about the Maemo Location that uses liblocation, reference is here: http://maemo.org/api_refs/5.0/5.0-final/liblocation/

add this to your .pro file

to build

gcc main.c `pkg-config --cflags --libs gtk+-2.0 hildon-1 liblocation`

one question: do you have a way to print a bug report? i mean. can you implement a way to log all the classe error on a file? to help you in this way will be nice a bugreport button on phoneme. something like send a bug. just becouse i tryed many games/apps free and copyrighted..

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

Yep, I already found that one for accessing the GPS. I was able to compile and run it without problems (not taking into account the
long time for finding a GPS fix). Thanks, anyway :-)

About the bug reporting: have a look at the "MIDlet Settings" and enable the redirecting of all console output. After running your app
you will hopefully find some useful info in the err.txt and out.txt log files in the /home/user/MyDocs/ directory.

Davy

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

There is yet another new build (20120227) online at:

http://davy.preuveneers.be/phoneme/public/maemo/deb/

With this build, you should be able to select a jar or jad in the File
manager, and phoneME should automatically open it (rather than going
through the 'Run MIDlet' application). It took me a while to figure out
how filenames were passed along through dbus and how to set up a
service to handle the JAR/JAD file types. I also added two icons to
better distinguish the JAR and JAD files.

However, I am not sure if this works on the N9. It is quite likely that the
service, mimetype and icon files should be put in a different folder
(compared to Maemo).

Could N9 owners please check whether they can find other xml mime
package descriptions in /usr/share/mime/packages/ and service
descriptions in /usr/share/dbus-1/services/

Thanks
Davy

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

(just deleted the old .desktop )

EDIT: I can confirm it works but another problem appeared that the run-midlet doesn't run properly and just a blank screen . In other words .jar filetype is directly accessible but run-midlet don't work thererfor nothing appear (using N9 )

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

Didn't work for me on the n900 not from file manager (the icons are there but don't open) neither the run middlet app
although running as usual from x-term with the comand
anyone else with this problem?
Thanks

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

Yep, my bad. The 'Run MIDlet' application accidentally triggered the
DBus service that is associated with jar/jad files. I will look into it.

Davy

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

editi the desktop file and remove the line X-Osso-Service=....
it works like that ;)

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

I test some java games but none of them works.
Does the games must have some specified resolution or whatever to run??

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

I can confirm the error, but without the sources it is quite difficult to
figure out what the app is trying to do. Decompiling the sources
won't help much either as the J2ME Polish based app is
obfuscated :-(.

Davy

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

I think it is a https related issue. If I modify the manifest in the jar file and replace the "PortalUrl:" field to "http://www.handyticket.de/portals/dataportal" (replacing https with http), I seem to be making some further progress.

However, as all communication is now unencrypted I would not recommend using the midlet for making real ticket orders.

Davy

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

I updated my 20120227 build. Hopefully the mime type and dbus
service association error is now fixed.

http://davy.preuveneers.be/phoneme/public/maemo/deb/

Davy

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

The bug is fixed, but with the above hack you indeed avoid the
dbus system from triggering the wrong service.

Davy

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

Depends on the game. If it requires certain features (like Mobile 3D Graphics), then they won't work.

See if you have some more success with the latest deb (see link above) as there were some issues with the previous build.

Davy

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

DavyP is it possible to resize the touch keyboard layout? it's streched

some apps like ebuddy don't work, maybe caused by the jsr support? mig33 works but the layout is strange.. one more thing, in some text areas the keyboard doesnt work, i mean the hardware keyboard and the touch (build in ) keyboard; one more thing that i see is that in some apps, where you can select the Area typing like "italy" to select the area for example, the T key is assigned to the i key, and viceversa.. here is a zipped jar file of the app, if you try to "send a message to suggest the app" and search in the Area box the word "italy" you will see what i mean

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

eBuddy 1.5 does not work because it needs a class from JSR-234:
javax.microedition.amms.control.ImageFormatControl

Not sure what is wrong with mig33 (I just ran the app until you
have to login etc).

I installed and ran the Facebook chat app. I am not an avid
Facebook user, and I am afraid I do not entirely understand your
problem. Perhaps a screenshot would help.

However, I am aware that the built-in virtual keyboard is pretty
broken (all keys are aligned to the left side of the screen). The
idea is to use the Maemo native virtual keyboard, but it is a bit
tricky to implement without any Qt4 text input widgets that would
trigger it automatically.

On Android, I drew a virtual software input panel button at the
bottom with which the users could pop up the native virtual
keyboard. I am going to try to achieve the same with Maemo.

Cheers,
Davy

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

Do you plan to support audio DavyP ?
Thank you :)