Share via

Introducing the Location Framework for Windows CE

  • Article

We're very committed on CE to creating a great development platform for location aware applications.  The first piece of this was GPSID, introduced in WM5 and now in general embedded for CE 6.0.

In CE 6.0, I'm pleased to announce we've added another, more generic abstraction layer for retrieving location -- the Location Framework.  I think the MSDN docs cover the gist of this, but to summarize here: Location Framework acts as a host for plugin dlls which can call into underlying hardware/network services to retrieve your location.  Applications ask for say "lat/long" or even more advanced types such as "building/room/floor", and Location Framework (henceforth LF) will do its best to retrieve the position for you based on the plugins on the system.  LF manages when plugins attempt to query for data, so that when no applications need the type of reports they can generate, the plugin is turned off so as to save batter.  There are ways that applications can query to determine the underlying plugins giving them information, but the ideal is that they don't have to.  Apps just call in and effectively say GiveMeMyLatLong() or GiveMeMyBuilding() and the rest is magic as far as they're concerned.

I like to think of the evolution of our location story on CE in terms of reading data from a disk.

Very Old Days: If you go back far enough, say before device drivers in the 50's, for an application to read data from a disk it had to give the disk orders directly -- like say to move the disk head so many places.  This was bad because it was a complete pain for the application to deal with the low level grossness in reading in this data, and it meant that the app itself was not very portable.  This is analogous to the way that location on CE was prior to GPSID & LF.  OK, getting location wasn't as painful as moving disk cylinders :), but any application that wanted to get at NMEA data for instance had to open the serial port, write their own NMEA parser, etc...

Old Days: Imagine that the maker of this 1950's computer decided to create a special library so that applications could work with one specific disk drum without knowing all the gross details.  This is much better than making the application deal with this itself, since the app is much simpler now and the app dev can focus on doing whatever cool things they did back in the 1950's with computers.  However, it's not ideal.  In this scenario, if a new disk drum type came along then the library (we're imagining) wouldn't work with it.  This is basically where we were at on CE when we created GPSID.  Apps can focus on whatever they're trying to do, not parsing NMEA.  If you're targeting just one disk drum or you know you'll always have a GPS unit on the device, it's all you need.  But we're not all the way here.

Modern Times:  Fortunately, or unfortunately (I think fortunate since I like C), K&R came along and invented C and the C runtime library.  Now to get data, you'll call fopen, fread, etc... and not really care about the underlying disk technology.  On Windows at least, CreateFile() can take a "\\share\name" string so that accessing data from anywhere in the world is the same as accessing it off of an IDE versus a SCSI versus whatever hard drive. 

My hope is that Location Framework will be able to make getting location as easy as reading raw data.

[Author: John Spaith]

Comments

  • Anonymous
    November 15, 2006
    John Spaith, developer in the CE Netowrking team has posted an overview of the new Location Framework
  • Anonymous
    November 16, 2006
    So can you give an example of what you would do with the location framework?
  • Anonymous
    November 16, 2006
    The comment has been removed