With the arrival of Windows 8 came the Windows Store, a marketplace of “third-party” applications, where anyone can sell their applications for WinRT. First of all, for “third parties” we mean all the ISVs and professionals, up to the amateur programmers, just like what happens with the various stores of Microsoft, Apple, Google, Intel, etc.
Moreover, with the definition “applications for WinRT” we mean a series of particular applications, also called Windows Store applications, which do not have the same UI of desktop applications but, above all, do not share the runtime.
In fact, the runtime of Windows Store applications is different from the runtime of traditional desktop applications. Although a Windows Store application and a Desktop application share the Windows kernel, the first rests on an infrastructure called Windows Runtime or, in short, WinRT, while traditional applications are based on .NET or Win32.
Neglecting the details of the WinRT environment, which certainly deserves a separate discussion, it is necessary to know, to be able to continue reading, at least some fundamental points for understanding this new model of development:
- The context of each application is isolated, just like on Windows Phone.
- Applications written for the Windows Store must be “touch-ready” because Windows RT is distributed on tablets.
- A WinRT application can be distributed on devices through the Windows Store (paid or for free) and can not be copied-pasted between devices.
- Development can take place in different ways, among which, of greater importance:
- Code (VB, C #, C ++) + XAML
- HTML5 + JS + CSS3
- C ++ native and / or DirectX
Going beyond the necessary introduction, one senses the potential of this new ecosystem that, taking advantage of the millions of Windows devices on the market, can generate considerable profits for the producers of applications.
Finally, by combining this factor with the Ultrabook world, the potential is even more, considering that an Ultrabook, unlike a “normal” laptop, often has:
- Motion sensors, acceleration, etc
- An NFC antenna
- A touchscreen monitor
Which make it therefore usable both as a laptop and as a tablet, as an integrated experience perceived by the user. Although the touchscreen itself already makes the “Windows 8 experience” smoother for the user, access to the devices allows complete coverage of the two Tablet + Desktop worlds with just one device.
With regard to the development environment, to develop Windows Store applications it is necessary to have installed on the Windows 8 and Visual Studio Ultrabook and activate the developer license, within Visual Studio itself.
Access to sensors
Although we do not have access and complete control of the system from the Windows Store applications, we have provided very complete APIs regarding interoperability with hardware devices, such as connectivity (WiFi, BT, NFC) and sensory (Accelerometer, Gyroscope, etc).
Accelerometer
Recall that the accelerometer provides the three components of instant acceleration of the device along the three axes X, Y and Z. To get the default accelerometer of the Ultrabook:
<pre class=”brush: php; html-script: true”>
// Get an instance of the acceleromete
var accelerometer = Accelerometer.GetDefault();
</pre>
Ambient light sensor
The brightness sensor provides a value, expressed in LuX, corresponding to the light intensity perceived by the sensor window (usually positioned near the webcam). To get the default Ultrabook sensor:
<pre class=”brush: php; html-script: true”>
// Get an instance of the acceleromete
var ambientLight = LightSensor.GetDefault();
</pre>
Digital compass
The magnetic force sensor provides an insignificant value for ordinary people, which is why it is wrapped in an angular value that indicates, precisely, the angle between the “tip” of the Ultrabook and the detected north1. To get the default Ultrabook sensor:
<pre class=”brush: php; html-script: true”>
// Get an instance of the acceleromete
var compass = Compass.GetDefault();
</pre>
Gyroscope
The sensor provides, for each axis of rotation, an instantaneous value of angular velocity, to determine the intensity of the rotating motion of the device. To get the default Ultrabook sensor:
<pre class=”brush: php; html-script: true”>
// Get an instance of the acceleromete
var gyrometer = Gyrometer.GetDefault();
</pre>
Sensor APIs
As you can see, all four sensors are accessible via the same API and also share some typical behaviors. For example, if the Ultrabook does not support the device just requested, the variable will have value null, which is why every time you ask a sensor to the operating system you need to test the actual value, before using it, in order to avoid unpleasant NullReferenceException.
Current value
Another factor common to each sensor is the presence of a common API call for the single and instantaneous reading of the sensor value:
<pre class=”brush: php; html-script: true”>
AccelerometerReading result1 = accelerometer.GetCurrentReading ();
LightSensorReading result2 = ambientLight.GetCurrentReading ();
CompassReading result3 = compass.GetCurrentReading ();
GyrometerReading result4 = gyrometer.GetCurrentReading ();
</pre>
Where the return value will clearly change, being strongly typed with respect to the type of data passed by the sensor.
AccelerometerReading will contain:
| Property | Access | Description |
|---|---|---|
AccelerationX |
Read only | normalized acceleration to G, along the X axis |
AccelerationY |
Read only | normalized acceleration to G, along the Y axis |
AccelerationZ |
Read only | normalized acceleration to G, along the Z axis |
Timestamp |
Read only | when sampling was carried out |
LightSensorReading will contain:
| Property | Access | Description |
|---|---|---|
IlluminanceInLux |
Read only | the brightness level in lux |
Timestamp |
Read only | instant in which the sampling was carried out |
CompassReading will contain:
| Property | Access | Description |
|---|---|---|
HeadingMagneticNorth |
Read only | angle in degrees with respect to magnetic north |
HeadingTrueNorth |
Read only | angle in degrees from the north |
Timestamp |
Read only | instant in which the sampling was carried out |
GyrometerReading will contain:
| Property | Access | Description |
|---|---|---|
AngularVelocityX |
Read only | angular velocity, in degrees per second, along the X axis |
AngularVelocityY |
Read only | angular velocity, in degrees per second, along the Y axis |
AngularVelocityZ |
Read only | angular velocity, in degrees per second, along the Z axis |
Timestamp |
Read only | instant in which the sampling was carried out |
Notification mechanism
All the sensors described (and also the others not mentioned) adhere to a pattern that allows a client to register with the subsequent notifications of new readings, instead of forcing him to poll the sensor. The pattern involves recording a ReadingChanged event to which you can attach the following signatures:
<pre class=”brush: php; html-script: true”>
void gyrometer_ReadingChanged(Gyrometer sender, GyrometerReadingChangedEventArgs args)
{
throw new NotImplementedException();
}
void compass_ReadingChanged(Compass sender, CompassReadingChangedEventArgs args)
{
throw new NotImplementedException();
}
void ambientLight_ReadingChanged(LightSensor sender, LightSensorReadingChangedEventArgs args)
{
throw new NotImplementedException();
}
void accelerometer_ReadingChanged(Accelerometer sender, AccelerometerReadingChangedEventArgs args)
{
throw new NotImplementedException();
}
</pre>
Where, in each of the args arguments, the Reading property is displayed that contains the reading value, wrappato by the specific types mentioned above.
Points of attention
Using sensors is simple but can lead to problems of excessive battery consumption . In order to avoid unpleasant surprises, it is better to set a fairly high value on the sensor of the ReportInterval property, in order to indicate to the operating system to notify us only when the selected period expires. This option is present on all the sensors and it is appropriate to set it before the notification delegate is used:
<pre class=”brush: php; html-script: true”>
accelerometer.ReportInterval = 1000;
accelerometer.ReadingChanged += accelerometer_ReadingChanged;
ambientLight.ReportInterval = 1000;
ambientLight.ReadingChanged += ambientLight_ReadingChanged;
compass.ReportInterval = 1000;
compass.ReadingChanged += compass_ReadingChanged;
gyrometer.ReportInterval = 1000;
gyrometer.ReadingChanged += gyrometer_ReadingChanged;
</pre>
By “fairly high” value we mean the minimum value that makes the application valid, that is the minimum interval for which it makes sense to sample that particular data.
Proximity and NFC
Ultrabooks represent a true crossover between the desktop world and the tablet/touch world, to the point that some vendors have introduced in their Ultrabook convertible range. So, just in the quality of the “two worlds” device, the Ultrabook introduces in the desktop world some features that until today we have only seen in the mobile world: the NFC radio.
NFC stands for Near Field Communication, which is why when we talk about proximity-aware applications today, we mean applications that use NFC radio. An NFC radio is a trivial high-frequency and low-speed signal receiver/transmitter (13.56MHz with 424 Kbit / s) with some interesting features. The first is that it is inspired by RFId technologies for the identification of passive devices over short distances: this means that, for example by placing a passive device near the NFC radio, it will send a current to the passive device in order to establish a communication between data in the device.
The second interesting thing (which differentiates it from the RFiD) is the possibility of establishing a two-way communication channel, allowing the radio to read and write on the remote device, all contact-less.
Proximity API
Windows 8 collects the full access API to NFC devices within the namespace Windows.Networking.Proximity. The fundamental class of access to the NFC is the ProximityDevice , which exposes a static method to obtain the default device (similar to what seen for the sensors).
<pre class=”brush: php; html-script: true”>
// Gets an instance for the NFC radio
var nfc = ProximityDevice.GetDefault();
</pre>
Once we have obtained the reference (and tested that it is not null) we can basically perform two operations: a writing or a reading. The principle of reading is to listen to a message until a device passes close to the radio; the writing is analogous and in the instant of the proximity stability data will be sent to the remote device.
Considering these two basic functions, there are three ways to use typical of an NFC:
- Payment card emulation: the recent Wallet function of Windows Phone 8 shows how, with the NFC, the phone can be used as a payment tool for many American merchants already in possession of appropriate NFC readers. In this case the radio device “behaves” as a smart-card.
- Peer-to-peer communication: two NFC devices can exchange half-duplex data if contacted so that application solutions for sharing information between physically close devices can be implemented.
- Reader / Writer: this mode requires that an active device read/write a passive device (Tag).
Now we will see how to implement the third case.
Tag Reader / Writer
An NFC Tag is an object (usually a sticker, a laminated card) that contains a microchip that can contain a modest amount of data (from a few bytes to some KBytes). Binary data can be saved within the NFC Tag, with appropriate space limitations: URLs, telephone numbers and/or “short” information are usually stored.
The format for saving data within an NFC Tag is the NDEF (NFC Data Exchange Format), a de facto standard that allows vendors to implement read/write software in a similar way on various devices.
NDEF
Once the NDEF format is understood, the process of reading / writing a Tag is completely unveiled. The NDEF format provides a single message that contains an arbitrary number of NDEF Records, which in turn are special data structures composed of payloads of variable sizes, whose metadata are provided in a special header at the top of the payload itself ( as you can see in the figure).
Analyzing the hexadecimal content of an NDEF record is the starting point for reading an NFC Tag. However, many of the high-level APIs available to us allow a “simpler” reading/writing, through appropriate wrappers.
Reading a Tag
To read a tag, you need a code like this:
<pre class=”brush: php; html-script: true”>
private void InizioAttesaContenutoURI()
{
// Gets an instance for the NFC radio
ProximityDevice proximityDevice = ProximityDevice.GetDefault();
// It continues only if the radio exists and is available
if(proximityDevice != null) {
// registration for WindowsUri type reading events
proximityDevice.SubscribeForMessage(“WindowsUri”,
// registers a Lambda when the notification has been made
(sender, message) =>
{
// It takes the string from the binary content
String uri = CryptographicBuffer.ConvertBinaryToString(BinaryStringEncoding.Utf16LE, message.Data);
}
);
}
}
</pre>
This code, however, allows registration of notifications only if you receive a WindowsUri type content, while the types currently in circulation are many. In case we want to register with the notifications of any content of the Tag, we will have to specify the Type “NDEF”, in the SubscribeForMessage method, in order to be notified in any case.
Writing a Tag
Writing a Tag from a Windows Store application is analogous to the reading operation, perhaps even simpler:
<pre class=”brush: php; html-script: true”>
private void InizioAttesaContenutoURI()
{
// Gets an instance for the NFC radio
ProximityDevice proximityDevice = ProximityDevice.GetDefault();
// It continues only if the radio exists and is available
if(proximityDevice != null) {
// Publish the message (the call is blocking)
var tagWritingMessageId = proximityDevice.PublishBinaryMessage(“WindowsUri:WriteTag”,
CryptographicBuffer.ConvertStringToBinary(uri, BinaryStringEncoding.Utf16LE,
(sender, message) =>
{
// The successful transmission and writing of the tag is established
}
);
}
}
</pre>
In this way I correctly read and write a URI inside an NFC Tag.
Conclusions
In this article, we have introduced the development of Windows Store applications, with particular reference to sensor-based applications, plus a deeper study on NFC technology and how to interact with the Ultrabook, with tags currently on the market.
