Location Framework Architecture (Windows Embedded CE 6.0)
1/6/2010
The Location Framework acts as a host for plugin DLLs that are capable of interfacing directly with hardware or network services. It notifies these plugin DLLs when applications request a receive a specific report type and when applications do not need the report type anymore. Plugin DLLs will typically be written by Microsoft, OEMs, or the provider of a network service. The header file (lfPlugin.h) required to write plugin DLLs is only available in the OEM package of Platform Builder.
The primary data structure used by the Location Framework is referred to as a location report (or just a report often in this context). A report contains a representation of the physical position of the device. Location reports are generated by plugins and are passed directly up to applications that requested the specific report type.
There are two classes of plugin DLLs. The first type is referred to as a Provider DLL or as just a Provider. A Provider is capable of directly interfacing with either hardware or the network in order to retrieve some sort of position information. Examples of Providers include the GPS Provider and Wifi Provider.
A Resolver, on the other hand, is incapable of generating a location report on its own. It needs a Provider to generate an initial report that it will translate into another report type.
Consider for example a system that has a GPS Provider and a hypothetical Web Service Resolver. The GPS Provider is capable of interacting with the GPS Device (going through the GPS Intermediate Driver ). The Web Service Resolver can determine the building/room/floor that the device is in if it knows the latitude and longitude.
When an application registers for a building/room/floor report, the Location Framework looks through its list of loaded plugins to find one that can generate the given report type. It will use the Web Service Resolver. Because it chose a Resolver, the Location Framework will first start up a Provider (if not already running) that generates a report that the Resolver can understand and translate, in this case the GPS Provider. As soon as the GPS Provider returns its first report, the Location Framework will notify the Web Server Resolver of this report so that it can be translated. If the Web Server resolver can determine the building/room/floor, then it will notify the Location Framework that will signal the application that the report is available.
Should a Provider or Resolver indicate that it is unavailabe (for instance a GPS device being indoors and not being able to determine position), they will indicate this to the Location Framework. The Location Framework attempts to start another Provider or Resolver/Provider set if one is available on the system that will generate the same report type. If two plugins generate the same report type, one will be the preferred plugin based on pre-configured registry settings.
The application will receive a notification as to the plugin state being changed, but beyond this need take no further action as the Location Framework’s retry algorithms are automatic. Similarly, the details of the retry algorithms are hidden from plugin DLLs, except in so far as they will be asked to register and unregister for reports as the result of other plugins becoming available and unavailable.
Power Notice: The GPS Provider and Web Service Resolver will continue to run as long as there is at least one application dependent on them. Some technologies may consume large amounts of power, such as turning on a GPS device or running a wireless connection to do a Web Service translation. Because of this, applications should only register for location reports when absolutely needed and should immediately unregister for reports when they no longer need them.
See Also
Concepts
Location Framework Architecture Diagram
Location Framework IOCTLs