• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Application not supported!

 
Jorma Ikonen
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
First I did MIDlet by using tools on WTK2.0, but soon I found that there isn't MIDP2.0 compatible phones available yet (I thought that technology wouldn't be so young). So, I dropped the WTK104 from Sun and after some small changes the application went through from compiler without any major problems. Also Emulator on WTK104 loaded the application and I assumed that it could be loaded to MIDP1.0/CLDC1.0 compatible phone without problems. Anyway, phone started to load the application via OTA, but an "Application not supported!"-error occurs before download was completed.
This is quite desperate situation, because there is nothing to hang on (no error numbers, etc). Each used sources have been recompiled by using "javac -bootclasspath C:\WTK104\lib\midpapi.zip ..." type of command and I assume that it would warn if I'm using unsupported classes on my application.
Is this common situation that J2ME-compatible phone (Nokia) is not actually J2ME compatible, or am I facing to situation what just happened for me (marginal bugs)?
My Midlet uses some classes from BC's crypto-api, and I'm just thinking that is it possible that it could cause this error even all needed classes have been recompiled from the source and added into the midlet jar-package? MIDP-api do not support "java.security.SecureRandom" and therefore BC includes this class/source. Is allowed for application to add/extend phone's java.xxx-package by own classes? Also I'm thinking that phone might have own version of "java.security.SecureRandom" e.g. to verify signatures, but that implementation is not public.
I have exactly two choices; have an extended lunch and wait if someone here has the answer, or start to modify the code and see if the removing of cipher-module helps somehow. First, the lunch sounds very, very good idea.
Br,
Jorma
"Brilliance is relative issue, I might be stupid..." by Jorma Ikonen 09/10/2003
 
James Reilly
wrangler
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I Don't know if this helps, but it might
be worth to double check these if you haven't done so already:
It's sometimes helpful to check that your .jad and .jar files
have all the mandatory parameters (with correct values) according
to the MIDP spec. Also that any parameters that are both in the .jad
and .jar's manifest match each other (i.e. no mismatches).
At least for a .jar manifest, a quick sanity check of Manifest-Version, MicroEdition-Configuration, MicroEdition-Profile
attributes is sometimes helpful. Also any attributes in the .jar manifest
that are also in the .jad, if some don't match that might be worth
looking into further.
I think WTK may also have a mode that allows one to simulate
'OTA download' of a MIDlet from a remote web server (rather from
the local filesystem), and that can sometimes be a useful additional
check too.
br,
jim
 
Fred Grott
Ranch Hand
Posts: 346
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
check to see if you on j2se 1.3 or 1.4..
There was a binary compatibility change btween those versions that affect midlet compliation..
you can either set the binary compatibility flag to 1.3 and continue to use wtk 1.0.4 stuff or you can use wtk20 to generate the MIDP1.0 midlets and not worry about changing the binary compatibility flag to 1.3..
 
Jorma Ikonen
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hurray!!!
The magic word "Manifest" in your text solved the problem. I'm using JCreator + Batch-programs to build the package and commonly I have only to update the "MIDlet-Jar-Size" into the jad-file. So, it was easy to notice to change the "MicroEdition-Profile" from MIDP-2.0 to 1.0 in Jad-file, but couldn't remember to do that same for Manifest (was created much earlier).
I thought that I've changed, recompilied, and updated everything, but obviously one small thing was wrong, shit happens...
Thanks Jim!
Br,
Jorma
 
James Reilly
wrangler
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For my own MIDlets, I've made a short shell script
that simply prints the mandatory .jad and .jar manifest
attributes, attribute by attribute. Then I can quickly
visually inspect that the mandatory attributes
exist, have valid values, and match.
It can be useful to do a few other quick 'final checks' too:
testing that a new web server supports the MIME types needed,
removing stray files (extra .class, .png, etc. files) from the
.jar, etc.
Depending on what you are doing, having some kind of very short
checklist like this that you walk through before putting a MIDlet
onto a download server might be a useful habit and only costs a few
minutes of time.
br,
jim
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by James Reilly:
Depending on what you are doing, having some kind of very short
checklist like this that you walk through before putting a MIDlet
onto a download server might be a useful habit and only costs a few
minutes of time.

Might be worth automating as well...
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic