Andrej Tozon's blog

In the Attic

NAVIGATION - SEARCH

NTK 2015: Slides from my intro talk on IoT and “Smart Home”

First of all, I’d like to thank everybody who attended my introductory talk at this year’s NT Konferenca (celebrating 20th anniversary this year – and back to Portorož venue).

I’ve talked about my smart home wiring and how I’m able to manage it from inside and outside my home network using my Windows Phone and Surface 2 RT. How various sensors and switches are connected to the main bus and are communicating with the actuators that control the lights, outlets, valves, blinds, etc. How little & cheap devices can help us connect our home devices to the Internet.

SurfaceHome
[Very early version of my Windows app, running on Surface 2 RT provides me a dashboard to monitor AND control my home]

My talk also aimed to feature a very simplified version of the above app (with simulating sensors instead of reading actual values) running on the Raspberry Pi. Unfortunately, due to the lack of HDMI->VGA adapters, I couldn’t show actual UI from Pi’s video output, but the app worked flawlessly otherwise (with Visual Studio 2015 debugger attached to the app running on the Pi).

Problems aside, we were able to monitor faked sensor data that was sent by the Pi to the web app and then relayed, in real time - thanks to SignalR running on Microsoft Azure – to a simple UWP monitoring app running on a Windows 10 desktop.

I’ve also shown a UI-less version of that same app, running on the Pi in headless mode (a kind of Windows service-ish mode), which I hope proved that Raspberry Pi running Windows 10 makes one very very powerful combo. Even if Windows 10 IoT Core Is currently still way from being final and it’s going to improve on its way to the release.

Some more info in the following slides…

Going forward, I’m exploring the possibilities of the internet and cloud-stored data. Computing power that it can give you. Analysis. Learning. Reaction.

What I’m learning right now is finding the right balance between private and cheap.

Pack your Windows App package yourself

A while ago, one of my Windows Store apps was in a weird stall – I’ve updated the app to support Windows 8.1 only, but published version was still targeting 8.0. After uploading new version of the app, I had to remove the 8.0 version due to some validation errors – the mistake!

I was left in a situation where I couldn’t publish my new 8,1 app because the process required having the 8.0 along the new one. Uploading 8.0 version didn’t work either because the process required that any new upload has to have its version number incremented. An option to just end the Windows 8.0 support at this point would be a helpful solution to the problem, but that option is not available until both versions of the app are validated and published.

I had to manually increment the old app’s version (targeting 8.0) and put it up there for validation to be able to continue publishing the new app (targeting 8.1).

Luckily, the application’s version is easily modified in AppxManifest.xml and Appx files are just archive files, right? Yes, but any modification made to package content will invalidate package signature so it’s necessary to recreate it.

Creating the package

Starting from existing package, I have first unpacked it to a new folder and incremented the version in the app manifest. I could’ve also changed other content files if I needed to.

To recreate package, I’ve used the App Packager tool. It’s located in Windows SDK folder (8.0 or 8.1) and it’s pretty easy to use: just point it to the unpacked folder and specify a new package path:

"C:\Program Files (x86)\Windows Kits\8.0\bin\x86\makeappx.exe" pack /d <PathToMyUnpackedAppFolder> /p <PathToNewAppPackage>\<PackageName>.appx

If the tool complains about missing resource files, add the /l option – that will disable missing file validation for cases where multiple version of the same resource is included in the package (e.g. multiple bitmap scale variations).

Signing the package

When package is created, it has to be signed. The signing is done using a different tool called SignTool. Again, the process is pretty straightforward, but you’ll need to have a certificate to sign the package. It’s best to use the certificate that was created by Visual Studio when the solution was associated with the Store application. That certificate file should be named something like <AppName>_StoreKey.pfx.

"C:\Program Files (x86)\Windows Kits\8.0\bin\x86\SignTool" sign /fd SHA256 /a /f <PathToCertificate>\<AppName>_StoreKey.pfx <PathToNewAppPackage>\<PackageName>.appx

The default hashing algorithm used to hash files when creating packages is SHA256 and since SIgnTool uses a different default (SHA1), it’s necessary to set the /fd parameter to appropriate algorithm. If you haven’t created the app package yourself and you’re not sure what algorithm was used while creating, check the AppBlockMap.xml that should be in the package. The file includes all file hashes and first element’s HashMethod attribute must specify the algorithm used.

So this is it! If you’re ever stuck with the Store application package that can’t be (re)created using Visual Studio and you only need to make a few modifications to be able to deploy it to the Store, you can do It manually.
Of course the same applies if you’re automating your app building process to create deployment-ready packages as well.

Windows Phone 8.1 – LocalCacheFolder

In one of my talks at recent NT konferenca I talked about some of the new ways of working with application data in Windows Phone 8.1. With all the exciting additions to the latest Windows Phone 8.1 APIs, the best news around application data in those new APIs is that they are now (mostly) aligned with the Windows Runtime (WinRT), so Windows 8 developers can pick up on them immediately and transition their work to the new platform, share code, etc.

With the aligned data APIs, Windows Phone 8.1 applications (both Silverlight and Runtime) can now store their data into one of the following folders:

  1. LocalFolder – a local folder, used for storing application data, it’s persistent across application updates and gets backed up to the cloud. This folder was already available in Windows Phone 8 and it’s the same folder as Isolated Storage known from Windows Phone 7.
  2. TemporaryFolder – also a local folder, but its space is managed by the OS. Whenever the system detects it’s running low on storage space, it will start deleting files in temporary so don’t ever strongly depend on files stored in this folder. It makes a perfect place for storing cached web responses or images that can be recreated any time. This folder does not participate in backups.
  3. RoamingFolder – files, stored in this folder, will roam across devices, meaning those files will be synchronized over the cloud whenever possible. Perfect for settings and/or small chunks of state (i.e. for continuous clients). When roaming is disabled on the device, those files (and settings) will get backed up as well. The storage space is limited to 100kB – if application goes over that quota, the synchronization stops (until the total usage falls back under roaming storage quota).

LocalCacheFolder

But wait - there’s one more folder in Windows Phone 8.1, that’s available in Windows Phone 8.1 API only. Even more, unlike some other APIs that are present on both Windows and Windows Phone and will throw an exception when used from the wrong platform, this one is completely hidden from Windows. Using it from a shared project, you have to #ifdef it out of Windows platform and include in Windows Phone build only:

#if WINDOWS_PHONE_APP
    var localCache = ApplicationData.Current.LocalCacheFolder;
#endif

So what is it? Is it used for caching? Well, not exactly (though it might, but I prefer the TemporaryFolder for that).

The LocalCacheFolder is almost exactly like the good old LocalFolder, with one single, but important exception – unlike LocalFoder, the files written to this folder will never be backed up to the cloud and will always stay on the device it was originally written at. Good for storing some (semi) sensitive information or pieces of state you don’t want or need to restore later.

And while I mentioned sensitive data, there’s one more thing worth mentioning - the best place to store sensitive data is into the Credential Locker (represented by the PasswordVault class), a familiar class from WinRT APIs, that is now also available to Windows Phone 8.1 – YAY!

Summary

To finish up, here’s a quick recap – use PasswordVault for storing sensitive information, LocalCacheFolder for data you don’t want ever to leave that particular phone, TemporaryFolder for temporary, easy-to-recreate data, RoamingFolder for settings and small state to synchronize across devices, and LocalFolder for main application data that gets backed up to the cloud (and, of course – restored).

Enable automatic daylight / night mode switch with your Windows Phone 8.1 app

Sample source code is available for download.

You know those fancy car GPS navigators that automatically switch color mode to dark when it gets dark to make it easy on your eyes? The display even turns dark when you drive into a tunnel and lights back up when you’re out…

Well, with ambient-light sensor support in the latest Windows Phone 8.1 SDK, it’s possible to build something quite like that. The new API is quite straightforward and follows the same practice as with other device sensors.

When your app starts, you should first query the device for the sensor to see if it exists. The GetDefault() method will return null if sensor isn’t present on the device or the system was unable to get a reference to it (happens when device is in a connected standby):

var sensor = Windows.Devices.Sensors.LightSensor.GetDefault();
if (sensor == null)
{
    return;
}

Once having access to the sensor, it’s recommended to set its reporting interval to default value, but in cases where you need to set it explicitly, you can do it by changing sensor’s ReportInterval, but check you’re not going below MinimumReportInterval. Here’s the code for setting it to 5 minutes, but if you need more dynamic readings, just leave it at default:

sensor.ReportInterval = Math.Max(sensor.MinimumReportInterval, 5*60*1000);

[Note: don’t forget to set it back to default – 0 – when you’re done]

To start reading, you can either perform a one-time read:

var reading = sensor.GetCurrentReading();

… or subscribe to continuous reads (with read interval set earlier):

sensor.ReadingChanged += OnLightSensorReadingChanged;

Either way, you’ll get a LightSensorReading with information about the current reading. The illuminance level returned by this is in lux so it should be easy to compare with some known values. I figured 500 – 1000 would be a good value to detect a decent daylight and in this example I’m testing against a value of 1000 lux.

We have the ambient light level, now what?

There are various cases where light sensor could come in handy, here’s a couple:

1. Allow user to have it’s theme respond to light, e.g. have light theme during the day and dark theme during the night. Reading apps, for example.
Luckily, in Windows Phone 8,1, changing theme for a page (or for any specific element) is now very simple. No more 3rd party helpers. Here’s an example of a OnLightSensorReadingChange event handler for the case, where application theme will be according to the latest sensor reading:

void OnLightSensorReadingChanged(Windows.Devices.Sensors.LightSensor sender, Windows.Devices.Sensors.LightSensorReadingChangedEventArgs args)
{
    Dispatcher.RunAsync(CoreDispatcherPriority.Normal,
        () => RequestedTheme = args.Reading.IlluminanceInLux < 1000
              ? ElementTheme.Dark
              : ElementTheme.Light
        );
}

[Notice the relevant line is wrapped in a Dispatcher call – the LightSensorReadingChanged event will always be fired on a background thread so we have to get back to the UI thread to set a visual property properly]

2. Any app that displays a map could use this feature. Navigation apps, locators, running apps, …
And the Map control has a vary handy property to support this, let’s have a look at Map’s ColorScheme:

void OnLightSensorReadingChanged(Windows.Devices.Sensors.LightSensor sender, Windows.Devices.Sensors.LightSensorReadingChangedEventArgs args)
{
    Dispatcher.RunAsync(CoreDispatcherPriority.Normal,
        () =>  Map.ColorScheme = args.Reading.IlluminanceInLux < 1000
               ? MapColorScheme.Dark
               : MapColorScheme.Light;
        );
}

One final note – the same API is available to Windows Store apps as well. Build for both, it’s great Smile

Download sample source code.

Launch Windows Phone 8.1 Podcasts app from your app

Latest Windows Phone update, called Windows Phone 8.1 will bring us a new app for managing podcasts. The Podcasts app, similar to what we previously had in Music+Videos hub’s podcasts section, will let users subscribe to their favorite shows to be played later on.

The good things for developers here is a fact that we’ll be able to integrate the new app in our applications’ workflow by launching the Podcasts app by one of the following URI schemes: itpc:, pcast: and podcast:.

For example, this is how you launch the Podcast app:

await Launcher.LaunchUriAsync(new Uri("podcast:"));

But it doesn’t end here. By specifying an Url pointing to a specific podcast feed, the app will fetch that feed and display podcast overview page and make it easy for the user to subscribe to that feed. Here’s an example of how to make it display the Hanselminutes feed:

await Launcher.LaunchUriAsync(new Uri("podcast:feeds.feedburner.com/HanselminutesCompleteMP3"));

image

Fun fact: the above screenshot was taken from my phone (device) using the Project my screen app, which was released today. Read more about it here.

Upon launching the app, the user has quick access to playing the latest episode (Podcasts app supports streaming) or subscribe to the series.

When user is done with subscribing or playing podcasts, navigating back will get her back to your app where she can continue her work with it.

Of course other apps can now move to supporting those URI protocols as well so, each user could choose her favorite podcast app to integrate with on her device.

re//rebuild/ Slovenia, 11.12.2012: Windows Phone 8

I’ve just posted slides from today’s re//build Slovenia event, where I talked about Windows Phone 8. Download the source code from here.

Voice speech/recognition demos were the fun part and they actually worked better than I had expected. What surprised me is a lot of people still haven’t heard of (or used) the MVVM pattern, which, in one form or another, can help you a XAML world of development a lot. And lately it’s getting quite popular on the HTML side as well.

Let’s change that.

Windows Phone 8 and our “localized” keyboard layout

This is a rant (somewhat).

Windows 8 features a nicely convenient on-screen keyboard, which is mostly useful when using on a touch device, like a tablet. I’m quite often using it on my Surface, when my touch cover is not attached.

Now, let’s take a look at a Slovenian layout of this keyboard:

win8keyboard

The keyboard layout is QUERTZ, with South Slavic layout, standardized in the 80’s and used in Slovenia, Croatia, Serbia, Bosnia and other (at that time) republics of former Yugoslavia. That means there are five additional letters on there. Letters č, š and ž (circled green) are part of all South Slavic alphabets, while đ and ć (circled red) are not in Slovenian alphabet.

Although this is a Slovenian keyboard layout, the presence of non-Slovenian characters is far from annoying or discomforting – besides the fact that there are also other (English) characters present, we’re used to this layout and have adopted it a long time ago, plus sometimes those characters come in rather handy.

But again, those red characters are not part of Slovenian language and that’s why I was surprised to see the Slovenian on-screen keyboard on my Windows Phone 8 (taken on my Nokia Lumia 920):

wp8keyboard1

It struck me weird that Microsoft would, out of five Slavic characters, pick the two that are not part of the Slovenian alphabet.

Taking another look at the above Windows 8 keyboard layout - notice how š and č are right next to  p and l? Wouldn’t it be natural to take this exact layout  to the Phone keyboard? So now, out of 28 letters on Windows Phone keyboard, there are 6 of them that aren’t in Slovenian alphabet – q, w, y, x (English), and ć, đ (Croatian/Serbian Latin/Bosnian).

Weird.

Of course, you can also (besides typing a combo of c and ˇ) access all letters by pressing and holding down the base letter, which gives you more options – and - behold č as the first option:

wp8keyboard2

Weird.

Fix please?