Well, we are back. After a very long suspension, it is once again time to write about the cool new APIs that Windows 7 provides you for differentiating your application with compelling user experiences. I still owe you two more posts on Windows 7 Taskbar to complete the series, but the Sensor platform is way too cool to leave behind.

Before we dive into the API, I should explain the rational that went into the thinking process of the product team while building the Windows 7 Sensor and Location Platform. (I’ll talk about location in future posts.)

Why Sensors?

Lately we are witnessing the increasing role that sensors play in some very exciting scenarios. For example a mobile device that automatically changes its screen orientation from portrait to landscape based on its relative position to the earth (center of gravitation pull), or computers that automatically control their screen brightness when the lighting conditions change to facilitate a better reading experience. However, I think the best example is the automatic time zone change of a mobile device - when you travel, one of the first things you do once your plane lands is turn on your mobile device, which magically shows you the correct time, even if you crossed a few time zones.

Besides the obvious functional reasons, another good reason to have a “platform” is that it unifies the API and lowers the API and entry costs for developers. In the past, using sensors tended to be a very vertical solution. There was no specific definition of what a sensor was, what its data fields were, or how to access those fields. Lack of standardization made programming for sensors an arduous task. When using a sensor, like a GPS location sensor, you had to choose hardware from a wide range of vendors, each of whom had a specific set of drivers and APIs you had to learn about in order to work with that piece of hardware. If you wanted to change your hardware or vendor, you often had to learn new APIs to access similar information.

In Windows 7, we set out to solve this problem from the ground up (as we usually do). We addressed these problems by providing out-of-the-box support for sensors. The Windows 7 Sensor and Location platform provides a set of standard interfaces that free developers from the need to become familiar with specific vendor devices and, instead, focus on their application logic, treating sensors as just another “standard” input device. By providing these standard interfaces, the Windows 7 Sensor and Location platform offers a win-win-win situation, wherein it’s easier for developers to discover, access, and receive information from sensors, thus creating room for more developers to optimize their applications to environmental changes. In return, this creates a greater demand for sensor hardware and, if you are a hardware provider, you have a standardized way to target one set of APIs to integrate with Windows. And most importantly, end users get to experience applications that take into account the environments they are working in.

The location piece of the puzzle adds an abstraction layer on top of the Sensor platform with the sole purpose of providing an easy way to retrieve data about a geographic location while protecting user privacy.

Sensors Under the Hood

To better understand the Sensor Platform API, I want to take you through a quick overview of the platform architecture, explaining the role of the main components in the platform. The following figure illustrates the main components in the system. Note that this figure is doesn’t outline the entire platform, as it misses the location piece, but it will most certainly do for now.





The first component in the platform is the actual sensor device – shown as number 1. Usually, this is a real physical device that measures physical phenomena such as the amount of light, temperature, humidity, relative gravity force, and so on. However, a sensor can be a logical device (also known as a virtual sensor). A virtual sensor is a software-based sensor that can mimic sensor-type functionality by “impersonating” a sensor and providing data to the platform. Virtual sensors can be used to simulate real sensors to help the development process, as you’ll soon see.

Each sensor requires a driver that facilitates the connection between Windows 7 and the hardware device. This integration is achieved via a user mode device (UMD) sensor driver – shown as number 2.

To make it easier to write a device driver that exposes a sensor to Windows 7, the platform provides a sensor class extension – shown number 3. This is essentially a driver utility library that implements the common code required for sensor drivers. We are not going to talk about hardware or drivers in this post, however we have two excellent videos (Windows 7 Sensor and Location - Developing Drivers Part 1, and Part 2) with Gavin Gear describing in great detailed how to write a sensor driver.

After a sensor is installed and integrated, it becomes discoverable to the application via the sensor API – shown as number 4.

One of the main advantages that the Windows 7 Sensor and Location offers is that it enables multiple (different) applications to receive data from the same sensor at the same time – show as numbers 5 With previous Windows versions, devices usually used virtual COM ports to communicate with the system. One of the problems with virtual COM ports is that they don’t scale and can’t support multiple consumer applications at the same time; therefore, having a platform that supports multi-concurrency is a great advantage.

The last component of platform is the Location and Other Sensors dialog, which is part of the Control Panel. This dialog – show as number 6 enables users to control permission settings and other parameters the sensor provides. The following image is a screen shot of my Sensor and Location Control Panel. As you can see, I currently have two sensors installed – the Sensor Development Kit and the Virtual Light Sensor, and both are enabled.



The last topic to cover before we jump into the APIs is to explain how sensors are represented in the platform.

As we've seen above, a sensor can be either a physical device or a logical (virtual) sensor. Regardless of the sensor’s type, all sensors share similar properties, as explained in the following list:

• Category -- A collection of sensors that are somehow related. For example weather station might include temperature, barometric pressure, wind speed, and other environmental sensors
• Type - The definition of the physical phenomena that is being measured, like wind speed or amount of light
• Properties - The meta-data information that a sensor can contain, for example, the sensor-friendly name. There are read-only and read-write properties. The sensor-friendly name and its serial number are examples of read-only properties, while the requested data report interval is an example of a read-write property.
• Data Types - The actual data types a sensor reports for the defined type that it measures. For example, light is measured in LUX units, which are reported in a float variable. Location information includes latitude and longitude, and both are float variables. However as you will soon learn, location might also include civic address as a valid location, which is a set of strings. Data types change from sensor to sensor and it is assumed that you know what data types your sensor will return in its data report.
• Events - The main way the Sensor and Location platform communicates with your application, informing it when there is new data to consume or when the sensor state changes
• State - The definitions of the possible operational states for sensors, answering questions such as: “Is the sensor ready for use?” or “Has the user enabled the sensor?”

Armed with the above information, you are ready to start working with sensors and dive into the API. But to do this, you will have to read the next blog about the sensor and location platform.

More...

Posted By: z3r010
29 Jan 2010