I want to call a Servlet from J2ME midlet,so I've written the HTTPConnection code for the Servlet URL to call GET method.
When Midlet suites tries to connect to the Servlet URL, I've got the below message in the Emulator,
{#MyMidlet} Midlet Suite wants to connect to {#Servlet URL} using air time,
this may result in charges, Is it ok to use airtime ?
If I click either No or Yes, nothing happened,it's just got hanged, I'm using EclipseME and SUN WTK 2.5.2. And in the console there was a warning,
Warning: To avoid potential deadlock, operations that may block, such as
networking, should be performed in a different thread than the
commandAction() handler.
Which means , If I do make the HttpConnection in a separate thread, will the problem be solved?
If I do make the HttpConnection in a separate thread, will the problem be solved?
If you do it right - yes, the problem will be solved. This is a typical issue and there is standatd solution.
Warning you refer to indicates design problem in your midlet. You have "heavyweight" activity (http connection) that runs in the same thread as UI, blocking it and making it irresponsive.
Avoid heavy load in UI event thread. When there's much to do of something inside of commandAction or keyPressed or pointerPressed etc, just spawn a new thread to do that. To better understand why is that, consider studying this tutorial to find out how to do it right:
Networking, User Experience, and Threads
This article explains how your MIDlet can make network connections without compromising your user interface. It includes six iterative examples that illustrate multithreaded networking and the use of a wait screen...
PrimitiveMidlet), there is even a detailed explanation of the issue you are experiencing:
...programmer has hijacked a system thread for his own lengthy processing. The system calls his commandAction() method when the user selects a command. The thread that calls this method belongs to the system, not to the developer. This would not be a crime if the method executed swiftly, but in this case, the network connection may hog the system's thread for a long time.
In J2SE application programming and even in servlet programming, the system creates a thread for you and there are few restrictions on how long your processing can take. The rule of MIDlet threading is simple and strict: the only threads that belong to you are the ones you create yourself.
In a MIDlet, you are writing code that the system will call from one of its own threads. When your MIDlet's startApp(), pauseApp(), destroyApp(), and event handler methods are called, for example, they run inside a system thread. Your methods must return quickly so that the system thread can continue its other work. Any task that can't be completed quickly must be moved out of the system's thread.
This style of programming may take some getting used to, as you are really only writing code that is called from the system's threads. If you've done any other GUI programming, however, this technique will be familiar. AWT and Swing have an event dispatch thread that handles operating system events and calls event handlers in your code. The rule is the same: event handlers should execute quickly and return control to the event dispatch thread so that the rest of the interface doesn't lock up...