Page 1
Page 2
Don't hog the GPS - How to make your application work together with other GPS software
Handheld computers are increasingly being hooked up to GPS devices, and the number of GPS-enabled applications is steadily increasing. This leads to a situation where several applications might be competing for a single GPS connection on a device. This article describes an easy and fast way to write polite GPS applications that can run alongside less considerate popular navigational software.
GPS applications have become big business and there are great opportunities for developers that find creative uses for GPS devices. Earlier proprietary systems are being challenged by cheaper and more flexible standards-based solutions.
Amateur pilots routinely want to combine access to their flight plans with local weather data, car drivers might want to switch between the built-in route planning and speed camera position services, and navigating the seas can be made safer combining a digital nautical map with travel logs and location-based forecasts on weather and winds.
So how do you do, if you don’t want your users to have to close down one program to allow another to access a single GPS device? Sharing your GPS with other applications can be quite a challenge, and far from all applications are written with that scenario in mind.
Creating a virtual gate to the GPS
One well-known suite of GPS tools for developers comes from Franson Technology (http://www.franson.biz). In particular there is a tool called GpsGate, allowing end-users to run multiple GPS applications at the same time. With the software installed on a device, you can manually set up sharing of a GPS, and run TomTom Navigator alongside Mapopolis and other popular GPS applications.
This kind of sharing can also be accomplished programmatically by using something called the GpsGate SDK. It exposes an API to directly access the functionality of GpsGate from within your application, adding an intelligent layer between the application and the GPS. In that way, you won’t be forced to write code to connect to the GPS device yourself, and it will save you from having to be aware of the exact settings of the GPS or the COM ports, all that information is handled by the GpsGate object. It also relieves your users from the hassle of having to manually configure the setup of the GPS connection.
By using the GpsGate API you make sure that your GPS application can co-exist with other applications from scratch. When your application is using the GpsGate API, all other GPS applications running on the device can still continue using the regular COM ports, or be set up to use the virtual COM ports provided by the GpsGate API.
Generally, only one application at a time can read a particular COM port for serial data. Handheld devices of today might have just one or two available COM ports for external devices, a fact that makes it even more important to share ports. The way GpsGate takes care of this shortcoming, is to create what is called “virtual COM ports”. It is basically a program that sits on top of a real COM port, making it appear to any interested applications as one or more serial ports. GpsGate allows for several applications to use and share one single virtual COM port, as well as splitting a COM port into several virtual ports.
If you are not into low-level serial port programming, you’ll be glad to know there are just a few lines of code involved in accessing and taking advantage of the GpsGate API.
Next Page