We do 2 things in the constructor. We create a QWorker object and pass it "this" and the website that we will be uploading to. The getAppProperty method gets attributes out of the JAD file. Open the JAD file in your favorite text editor and there you'll see the webpage that you'll be sending GPS data to. Notice how we're passing "this" to the GWorker object? That's the LBSMidlet7 object. Take a quick look at the QWorker class, it extends the Thread class. That's why we call worker.start() in the LBSMidlet7 constructor. We want to start our worker thread.

When you start a thread, what you are doing is creating an object and then running that object's run() method. Take a look at the run method. It has an endless loop and in the loop the first thing it does is call queue.wait(). Look at the definition of the queue. The queue is an abstract data type (ADT), it just like a queue at a bank, enter the queue at the back of the line and leave the queue when you get to the front of the line. Look at the definition of the queue, it's our vector (dynamic array). When you call wait() on an object within a class that extends the Thread class, it puts that object to sleep. Think about that a little. When we hit that line, our QWorker object is now waiting... What's it waiting for? We'll get to that in a minute. Before we do that, take a look at the synchronized keyword. Notice that it's wrapping the queue. What that does is it puts a lock on the queue and tells all other processes not to touch the queue until that little block of code is done with it.

Ok, so now we've started a worker thread and put it to sleep. Let's now go back to the LBSMidlet7 class and take a look at the startApp() method. In the lifecycle of a midlet, the constructor is called once and then the startApp() method is called next. In fact it can be called several times, like for instance when you close a flip phone and then open it again. What happens is that the app is suspended and when you flip the phone open again, startApp() is called again. In startApp(), we get our display and then we create a LocationProvider if one hasn't already been created and we create another thread... Why are we creating all these threads? Good question. It allows the user to be able to use the phone. If you didn't use threads, the phone would be locked up while it was trying to do things like send data to the website. If you do make a call while the app is running, the app will be suspended and the background threads that get gps data and send it to the website will also be suspended. You need to start the app again after the phone call to get it out of the suspended mode.

The LocationProvider is what gets our GPS data. First we create a criteria, we're using the default, but you can set stuff like accuracy, response time etc. Next we create our Location Listener. It's pretty much just what it sounds like. Here you can set the interval for how often you want to get GPS data. It's currently set to 60 which is in seconds. When data comes in, the locationUpdated() method is called. This is another one of the required methods in the LocationListener interface. Here we create yet another thread and call getLocation(). The getLocation() method gets the GPS coordinates, creates a queryString which we will send to the web server a little later and then calls worker.addToQueue in the QWorker class.

Let's go back over to the QWorker class and see what happens in that method. It add the queryString to the queue and then calls queue.notify(). Guess what queue.notify() does? It wakes up our sleeping QWorker thread and tells it to get to work! Notice that our calls to the queue are once again wrapped in a synchronized block. Please practice safe threading... When notify() is called on a thread, what it does is go back to the run() method and execute the next line of code right after where we told the queue to wait(). So now we are just about ready to send the GPS data to the web server. We have a couple of interesting lines of code there. First we call peekInQueue() which gets the queryString out of the queue but leaves it there for now. Then it sends the queryString to the getUrl method which attempts to send the queryString to our web server. If it's successful, we can remove the queryString from the queue. If not, we leave the queryString in the queue and try to send it to the webserver again later.

Why in the world do we have this complicated queue here? I'm glad you asked. There may be times when you are receiving GPS data but are not actually in an area that has a cell phone connection. If we don't have a cell phone connection, we can't send our GPS data to our web server. So we stick our queryString in our queue and wait until we get back into an area with cell phone connectability. Can you hear me now?

Well, we've spent a pretty fair bit of time explaining the phone code. It's a little complicated but it's important to know what's going on if you want to take the code and make modifications to it to suit your needs. Here's a good article on the Sun website to let you know about more capabilities of the Location Based Services API. Right about now, our queryString should be arriving at our website, let's catch up to it and see what happens.