Why the J2ME Midlet Suite and HTTPConnection needs to be in different threads

Question

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?

It worked, When I change the HttpConnection in different thread. Thanks !! — Murugesh, Jul 26 '12 at 13:47
No problemo! Although next time I'd just try it yourself without bothering to post a question here... saves a lot of time! — funkybro, Jul 26 '12 at 14:10

score 2 · Accepted Answer · answered Jul 26 '12 at 14:34

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...}

After the very first example in the tutorial (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...

Further code examples in tutorial show how to fix design mistakes like above and how to make MIDlet user interface smoothly interoperate with networking activities.

score 1 · Answer 2 · answered Jul 26 '12 at 11:37

1

Creates its connection as a separate thread like this:

Thread myConnection = new Thread(new Runnable() {

        public void run() {
            // TODO open connection here


            HttpConnection conn = null;

            try {

                        conn = (HttpConnection) Connector.open(serverURL,
                                Connector.READ_WRITE, true);

                        conn.setRequestMethod(HttpConnection.GET); // or POST method

                    } catch (Exception e) {

                // TODO: handle exception

            } finally {

                // close connection here
            }

        }
    });
    myConnection.start();

answered Jul 26 '12 at 11:37

Douglas Frari

4,167
2
22
23

Thanks, for your answer, In the similar manner I've tried and it got worked. Can you please tell me,why it is giving the message like that when both are in one thread. – Murugesh Jul 26 '12 at 13:50
Each manufacturer defines how you will handle it. It is not mandatory. In the simulator WTK 2.5.2 for example, he makes the simulation of the KVM and the main thread is responsible for the painting. As good practice is recommended but not mandatory to use a separate thread for events I / O. Imagine running an application (client / server) with only the main thread when the server does not respond to requests ... could compromise the response of paint on the screen. – Douglas Frari Jul 26 '12 at 14:57
Then, the WTK simulator is mandatory implement a separate thread method to running. But the real device is not required. However, it is good to be careful when working with events I / O. – Douglas Frari Jul 26 '12 at 14:59

score -2 · Answer 3 · answered Jul 26 '12 at 09:16

In J2ME the network operation is put in seperate thread.
U put the networking module in a seperate thread.If u put the networking module in seperate thread then the following message is not appeared.

Warning: To avoid potential deadlock, operations that may block, such as 
 networking, should be performed in a different thread than the 
 commandAction() handler.

In J2ME (sun/oracle who is the owner of j2me) gives some limitations.For security some API's need the trusted party certificates.For this some mobiles ask user for permission when user clicks yes then it will allow ,otherwise it will not allow.
The following are the some of the API is come under that scenarios are FileConnection (reading/writing to file) api,HttpConnection,HttpsConnection,etc.
U check ur device whether it is support self signed certificate.If is support means u use self signed certificate.
The trusted party certificate is costly .Its minimum cost is Ruppees 10000 per year.The following are some trusted party vendors Thawte,Verizon,Semantec,etc

All that stuff about certificates/permissions is correct but irrelevant -- the question is nothing to do with certificates. — funkybro, Jul 26 '12 at 10:24

Why the J2ME Midlet Suite and HTTPConnection needs to be in different threads

3 Answers3