Live tiles have long been a key differentiator for the modern Windows platform. Since their introduction in Windows Phone 7 Microsoft sold live tiles as “dynamically updated… breaking the mould of static icons” (source). The hope from many developers was to be able to create customised panels of information that would draw users into the app or present them with a simple overview of the information that mattered. The reality is that using Microsoft’s standard tools presents a very simple experience whereby some text, a number of images, and possibly a count can be displayed on a live tile at any one point.
Even with the expansion of live tiles in to the Windows 8 platform the standard templates available to developers often lead to a start screen of similar tiles that do not differ visually from one another. There’s nothing inherently wrong with that similarity, but there are a lot of situations the normal tile templates do not account for. For instance showing a graph of information, or a customised layout to avoid having white text over a light background image cannot be done in with the normal templates.
In Windows Phone 7 and 8 apps, based on the Silverlight framework, developers could use an image rendering method to transform XAML into a locally stored image, then update the tile in a background task. In Windows Runtime apps (or universal apps if you prefer) this is no longer supported. So how can we create customised live tiles to match a user’s expectations?
This post will explore the 3 methods of updating tiles with custom images, through foreground C# code, through background native C++ tasks, and by using remotely store tiles in an Azure component.
Microsoft presented a more consumer focused Windows 10 keynote yesterday, showing off how the operating system will scale across devices and deliver the universal experience the company has been promising for years now.
As a Windows consumer I am very excited by the new features, integration with Xbox and what seems like a renewed focus on Windows for Phones (the old “Windows Phone” name looks to be gone). Yet as a Windows developer I have a flood of questions which I expect to be answered at BUILD this year, I thought I’d share a few of the more burning ones with you.
Possibly the biggest change for modern Windows developers that comes with the Windows 10 system is that we no longer need to support just a few aspect ratios and scales, we have to support almost any possible aspect ratio at any scale. This is thanks to the ability to have Windows Store apps run in their very own windows in the desktop, which makes absolute sense for keyboard and mouse users.
We could argue that the snap view possibilities in Windows 8.1 already started this layout, but the difference with snap is we had a relatively guaranteed minimum size on the vertical plane, and could focus on layouts which showed more or less on the horizontal plane. This approach was closer to adaptive design, and had the benefit of always having a large vertical plane available (minimum of 768 pixels).
Now that users are able to resize and change the window across both axis, we have to start considering how we as developers should support this concept. This of course isn’t a new problem, just look at how web design has changed over the last few years, and even before then we have traditional Windows Forms apps which worked in the same way. That said it is at least partially new for XAML in Windows Store apps.
In this piece I will explore how we can take inspiration from Responsive web design and apply those lessons to current Windows Store apps so that they are ready for use on the desktop in Windows 10.