Post-install package (javax.microedition.location.Location)

[null99]

hi there!

i have a smartphone - htc touch hd with winmobile 6.1 - which doesnt support the javax.microedition.location.Location package. I made this out with this code

<code>
public static boolean isLAPIPresent(){
try {
Class.forName(
"javax.microedition.location.Location" );
return true;
}
catch( Exception e ){
return false;
}
}</code>

well now I'm looking for a way to post install this one to get GPS support into my java midlets. Is there a way to get such access? I have some ideas, maybe one kind user could explain which one sounds reasonable and which one is involved which less work and with compatibility in mind:

1.) install a new jre (maybe kaffe? http://kaffe.org/)
2.) is there a way to somehow statically compile my bytecode with this feature, like C compilers can? since my netbeans supports that API
3.) is there a way to pack that javax.microedition.location.Location and bundle it along which my midlet?
4.) can i create a .dll file with c++ and load it with java, so that dll file does the gps work?

the phone itself has GPS capabilities


thanks
null99

[ektasrv]

You can try making a small on device server in native windows mobile which gives the required GPS info to the requesting J2me client.

J2me client can access this server on localhost and get GPS data.

[null99]

hmpf. my last post got lost in space somehow.

thanks for the hint&fast answer. but I'd rather prefer 3.) cos if i really use another programm which communicates with the midlet through sockets, I need to write a loader which first starts the GPS provider service (ie written in c++) in order to start my midlet. on the other hand i dont really want to have OS depended programms involved in my midlet/project bundle.

i dont really get how the `javax.microedition.location.Location' package interfaces with my smartphone os? does itself has dependencies itself? could it be, if my smartphone vendor doesnt included it that there is no way for me to post install it?

greetz

[ektasrv]

Refer to this FN Wiki article, it might hep you - - http://wiki.forum.nokia.com/index.ph...API_in_Java_ME

[null99]

okay. i DONT KNOW why, but if I load my GPS midlet with phoneME (http://davy.preuveneers.be/phoneme/?q=node/10) it works just fine. although at the first glance phoneME is not as fast as the native build in Esmertec Jbed one. however, gps seem to work with this. can anybody tell me why it's up to the midlet manager if some packages work and some not? I thought if the package is stored in the classpath just every java application can use it. no matter with which loader its been started. for me the midlet manager only organize & start my midlet's with doing internally somekind like (exec("java mymidlet"))

btw, i had to install two files on my cellphone to work, from the above mentioned link
phoneME Feature - CLDC (.cab)
phoneME Feature - MIDP (.cab)

on my mobile phone:
after that i started the phoneME MIDP from `Program Files', then I installed my midlet from my SD-card. of course i copied my midlet from my developing pc to it befor that.

greetings
null9

[ektasrv]

okay. i DONT KNOW why, but if I load my GPS midlet with phoneME (http://davy.preuveneers.be/phoneme/?q=node/10) it works just fine. although at the first glance phoneME is not as fast as the native build in Esmertec Jbed one. however, gps seem to work with this. can anybody tell me why it's up to the midlet manager if some packages work and some not? I thought if the package is stored in the classpath just every java application can use it. no matter with which loader its been started. for me the midlet manager only organize & start my midlet's with doing internally somekind like (exec("java mymidlet"))

btw, i had to install two files on my cellphone to work, from the above mentioned link
phoneME Feature - CLDC (.cab)
phoneME Feature - MIDP (.cab)

on my mobile phone:
after that i started the phoneME MIDP from `Program Files', then I installed my midlet from my SD-card. of course i copied my midlet from my developing pc to it befor that.

greetings
null9

When you install phoneME Feature - CLDC (.cab), phoneME Feature - MIDP (.cab) it builds a Java Virtual environment that supports GPS JSR 179 features and then if you run a GPS enabled app with it , it works.

[grahamhughes]

can anybody tell me why it's up to the midlet manager if some packages work and some not? I thought if the package is stored in the classpath just every java application can use it. no matter with which loader its been started. for me the midlet manager only organize & start my midlet's with doing internally somekind like (exec("java mymidlet"))

In CLDC environments, the classpath is strictly controlled. It consists strictly of two parts: (1) the application's JAR, and (2) the Java Runtime Environment's classes. If you have two JREs, they won't share classes - the runtime classpath is fixed in the JRE.

Does that help?

In terms of your other questions: No, for a variety of reasons, you can't include an API in the application's JAR. Top reason is that APIs usually require some native code, and you are forbidden from including native code in your application.

Graham.

[null99]

In CLDC environments, the classpath is strictly controlled. It consists strictly of two parts: (1) the application's JAR, and (2) the Java Runtime Environment's classes. If you have two JREs, they won't share classes - the runtime classpath is fixed in the JRE.

Does that help?

yes that helps alot. after a day of crawling google and forums, i think my questions are almost answered, and I have a way to workaround that problem. but, as i saw, you can load dll files in java SE, but you cannot in java ME? is that right, or is there maybe a trick/hack how to get it work? or is the communication with other applications (written in C++) limited to filesystem read/write and network based ones?

you said that the classpath is strictly controlled. does that mean that you can't add own classes to the jre, for example classes from JSR. you always have to take what you get offered from the jre vendor?

[ektasrv]

yes that helps alot. after a day of crawling google and forums, i think my questions are almost answered, and I have a way to workaround that problem. but, as i saw, you can load dll files in java SE, but you cannot in java ME? is that right, or is there maybe a trick/hack how to get it work? or is the communication with other applications (written in C++) limited to filesystem read/write and network based ones?

you said that the classpath is strictly controlled. does that mean that you can't add own classes to the jre, for example classes from JSR. you always have to take what you get offered from the jre vendor?

Refer to the foloowing FN Wiki article it will help: http://wiki.forum.nokia.com/index.ph...vicesFramework

Yes, you cannot add more JSR's or classes to JRE.