My current project relies on long-lasting connections to the server. How is this best implemented with MIDP v1.0? I've implemented it with a pair of HttpConnections (one GET, one POST), which remain open for the midlet's lifetime, but that doesn't work on the phones I've tried (CSD only so far, it might still on GPRS). So I'm trying a rather nasty polling system which wastes bandwidth something chronic - is there an elegant way of doing this?
Of course, all gravy once v2 is widely supported and I can use UDP datagrams, but until then, what is everyone else doing?
I am trying a similar thing, trying to open two POST connections, one for sending and one for receiving. It works in the WTK104 emulator, but fails in various ways on various phones. Is there a recommended way of faking HTTP out? BTW, my app works fine on the phone that supports sockets.
keltonflinn: I'm not surprised. What's happening is that we're falling foul of the WAP mechanism. It's not actually HTTP, it's an encoded version of it. As a result, the entire request is cached on the gateway server, and only sent when it's finished transferring from the phone to the gateway. A phone which supports sockets will by definition support normal TCP/IP, and so will be able to start sending HTTP data before the request is finished.
Basically, sucks to be us
Sun just wasn't thinking of real-time applications when it designed MIDPv1, and it'll be a while before MIDPv2 happens. Right now, how I'm doing it is to have two versions - one with the bandwidth-minimising method which works in the emulator (and presumably socket phones, don't have one to test), and one for less intelligent phones which just polls repeatedly. If you are interested in a polling solution, might I also incidentally recommend kxmlrpc. Doesn't work when streaming, but makes life SO much easier...
One of the books I have suggested putting "really big numbers" in the Content-Length. That seems to work in the emulator, but it strikes me as a very fragile solution.
The other wierd behavior I am seeming is that one of the phones opens a new http connection every time I do a flush() on the DataOutputStream, which needless to say the emulator does not do.
I think I was not quite clear in my previous post. The "sockets" version of the midlet and the server work fine. The http version of the midlet has the above-described erroneous behavior on that socket-supporting phone.
We've just completed an Instant Messaging client which has many of the same requirements you mention.
Here are some learnings ...
1) Ignore the emulators. Their networking behaviour has nothing in common with an actual device
1a) Coz devices tend to support only a single extant connection
1b) Coz devices often (eg Series 40) map http to cWAP
1c) Which allows the network operator to munge, cache, block, timeout and drop data at their cWAP gateaway
1d) Coz Nokia devices are totally bug-infested when it comes to networking
1e) Coz networking parameters such as timeouts vary greatly and whatever you set it to, the cWAP gateway will timeout anyway
1f) Coz standard tricks such as closing an http connection to force a timeout don't work on most devices
2) MIDP 2.0 does *not* mandate Sockets or UDP. It's a reasonable expectation that most manufacturers will take the opportunity of MIDP2.0 to implement same, but it is not guaranteed
3) The use of sockets implies that your network has an Internet APN open for socket use. Dangerous assumption, especially with prepay !
The good news is that it can be done. It's just a lot like spinnig plates.
btw. In Sun's defence, they didn't screw up MIDP 1.0 all by themselves. They had some fantastic help from the handset manufacturers. MIDP1.0 doesn't say a manufacturer *can't* implement sockets. (and as I mentioned above, MIDP2.0 doesn't say they must). imho it's the JCP process that's broken, but that's another story.