• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

testing http connection code on WirelessToolkit?

 
Terence Doyle
Ranch Hand
Posts: 328
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I'm trying to test out some code to practice for the exam on the J2ME Wireless Toolkit 2.1
When my code gets to

A message appears on the emulator screen asking for permission to use the network but when I say yes nothing happens...

Any ideas? Or is the kit for local testing only.
Thanks,
 
Theodore Casser
Ranch Hand
Posts: 1902
Hibernate Netbeans IDE PHP
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I get the same thing, but when I click 'OK', it continues onwards like it should. Check the rest of your code to see if it's doing everything it should.
I found really silly incompatibilities when I first ran into this using the first edition of Knudsen - a out.flush() in the Jargoneer MIDlet was seeming to cause a problem, and removing it made the application work. So, basically, double-check your code for any snafus.
(Edited to clarify what I'd found)
[ February 12, 2004: Message edited by: Theodore Casser ]
 
Terence Doyle
Ranch Hand
Posts: 328
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well it's working now :roll:
Guess it was my ADSL connection...
Thanks,
 
sha liba
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Two ways to get around this "feature", one is to start a thread in commandAction() for the open() call, the other is to change the protection domain from "untrusted" to trusted under the preference menu.
WTK's release note mentioned this problem, claiming the cause is that accessing a protected API from commandAction() will lock the UI thread. I just could not figure out how that can be the case if the WTK control the thread properly.
 
Michael Yuan
author
Ranch Hand
Posts: 1427
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by sha liba:
WTK's release note mentioned this problem, claiming the cause is that accessing a protected API from commandAction() will lock the UI thread. I just could not figure out how that can be the case if the WTK control the thread properly.

It is not a "problem". The spec says that commandAction() should "return immediately". So, to use a thread is the only correct way to do this.
cheers
Michael
 
sha liba
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've seen so many code examples from both Sun and IBM developer sites where net work connection are done within the commandAction()....
While it is a good practice to aways start a thread for calls that may block especially in UI application, I still don't understand why failing to do so would "lock up" the UI thread indefinitely.
 
david goose
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A thread for communication is advisable ? The reason is that
if you are waiting for I/O operations the system cannot perform any paint
operations /and or other events. Older J2ME implementations { < 2} seemed to
service this differntly , but if you think of it the newer model is safer
and provides more control for the vm to interupt or advise of any events , for instance push registry etc... Other than that I dont think there is any other
explanation.

Hope this helps

Goose
 
Ko Ko Naing
Ranch Hand
Posts: 3178
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I used to play around with networking-related examples coming along with the Sun Java Studio Mobility Trial Version... The examples are really great... I do recommend that IDE, if you want, to prepare for the exam...
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic