views:

118

answers:

2
+1  Q: 

j2me networking

I am producing a basic j2me application that collects gps information and then sends it out over a wireless network.

It seems like I need a thread to read GPS and a thread to send the data over the network. This seems like a producer/consumer pattern with some sort of queuing mechanism on teh consumer side that will allow the data to be held if the connection is not available.

I have never done an application like this. Does this seem like the correct approach? I have tried to find some samples, but have not been able to find anything other than a very, very basic sample.

Any leads on good info or comments is appreciated.

Cheers.

A: 

Depends on the performance criteria

A lot would seem to depend on the performance requirements of the entire system. Since reading a local GPS fix would seem to be a very low-cost and low-latency operation, I'm wondering if some application requirement complicates things to the point of needing threads. Why not just read the fix whenever the network process needs it?

Is your GPS reader going to be a complete location manager, with privacy policies, power saving logic, and other complexities? That would certainly change things...

DigitalRoss
eventually yes.. the application with have power management and other considerations. I was hoping to get the basic framework in place so that adding additional functionality would be easier.
J. Scarbrough
A: 

You don't really need a separate thread for reading the GPS, since you can use setLocationListener in the location provider, to get it to call your code whenever it has a new GPS location. (But you need a thread for the call to setLocationListener, since that call may block!)

Thomas Padron-McCarthy