All posts by Jeremy

WinRT: introducing the AppBarHint control

Windows 8

Windows 8.1 is has a lot of improvements in the OS, for XAML and HTML developers but also changes some paradigms introduced with the release of Windows  8. One of them is to make more obvious UI elements that were hidden behind gestures users could miss.

If you take a look at the music app for example you will notice that the search bar is now always visible (in the top left corner):

xbox music 8.1

Whereas in the original version it was accessible only from the search charm (thus harder to find):

xbox music 8.0

In the mail app, many actions were hidden in the bottom application bar and the 8.1 version now displays a visual indicator that there is something hidden here:

app bar

With a bottom bar with “…” in the bottom-right corner:

app bar hint

In the upcoming version of 2Day for Windows 8, I decided to follow this path and I built a simple control I called the AppBarHint control for this exact purpose. The code is more than trivial but I thought it worth a blog post more because of the idea of using it rather than the actual code.

2day appbar hint 12day appbar hint 2

The control is actually just a Button with a custom template applied to it. The source code is available on GitHub. Here is the template applied to the Button:

*

Enjoy,

WinRT 8.1: this is why you will use the Properties pane in Visual Studio

Visual Studio, WinRT

If like me you are a XAML lover they is good chance you spend most of your time writing your XAML by hand in Visual Studio.  From the day I started working in XAML I rarely use the Visual Studio designer (even thought it has been improved with each release of Visual Studio). Today, I’m sharing a very good reason to use the Properties pane if you are targeting Windows 8.1 in Visual Studio 2013 !

Meet the new AppBarButton control

Windows 8.1 introduces a new set of controls (full list here on MSDN), among them there is the AppBarButton control:

AppBarControl

This control help designing an application bar with the proper looks for the buttons in it. In Windows 8, you could specify the icon of a button by using the appropriate code of the Segoe UI Symbol font. For example, using this XAML

[code language=”xml”]
<TextBlock
    Text="&#xE104;"
    FontFamily="Segoe UI Symbol"/>
[/code]

Will produce this kind of icon:

SegoeUISymbolSample

It was kind of cumbersome to look for the appropriate code on MSDN and type it in XAML. This is the good part about the new AppBarButton control and the properties pane which make it works nicely together because the editor handles the Symbol property perfectly:

PropertiesPaneAppBarControl

Now I have at least one good reason to use the designer !

VS2013: upgrading a Windows Phone 7/8 and Windows 8 apps

Windows 8, Windows Phone

In this post I will showcase issues I had while upgrading a Visual Studio 2012 solution containing a Windows Phone app (with both 7.8 and 8.0 versions) and Windows Store app to Visual Studio 2013.

As you probably already know, the Release Candidate version of VS2013 was released a few days ago and I decided it was the appropriate time to upgrade my 2Day todo-list application. Because 2Day for Windows will target the 8.1 release (coming October 18th, now available for MSDN subscribers) I needed to perform this upgrade before the release.

Windows Phone 7.x support

The first issue is simple and yet sad: Visual Studio 2013 is dropping support for Windows Phone 7.x app.  I guess it makes sense when given the fact the WP8 devices represent more than 65% of the total of Windows Phone device (see this AdDuplex blog post for more details).I can also confirm this trend that by looking at 2Day’s data for last week:

2Day devices chart

Since I released the first version of 2Day I submitted 14 updates. Starting from 2Day 1.4 I  released all updates for both WP7 and WP8 devices. It looks like the 2.1 update coming later this month will be the last one targeting WP7 devices.

Windows Phone support Conclusion: upgrade to VS2013 imply no more WP7 support. You can try to maintain 2 solutions but we will see in the next paragraph that there are other issues with Portable Class Libraries.

Portable Class Libraries (PCL)

2Day’s Visual Studio 2012 solution contains Portable Class Libraries to enable code reuse between Windows Phone and Windows 8 (it was also helping code sharing between WP7 and WP8 versions). In Visual Studio 2013, like we saw before, support for WP7 is now longer available, including for PCLs:

VS2013 PCL

So opening a solution that contains PCLs targeting WP7 will upgrade those PCLs and drop targeting of WP7.

Also, in order to target WP7 and have async/await support I had to use the Async BCL NuGet package:

BLC Async Support

Because the async support is now supported in the frameworks I target (Windows 8.1 and Windows Phone 8), I must remove those packages in order to prevent conflicts like the following:

Error 28 The type 'System.Threading.Tasks.Task<TResult>' exists in both 'c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETPortable\v4.0\Profile\Profile158\mscorlib.dll' and '...\packages\Microsoft.Bcl.1.0.19\lib\portable-net40+sl4+win8+wp71\System.Threading.Tasks.dll'

While doing those upgrades I also ended up target .Net 4.5, and it turns out the reflection API has some changes in the latest version of .Net.  If you’re like me you’re a fan of SOLID principles, you probably have some kind of Inversion of Control container using reflection… In my case the following code was not working anymore:

var constructor = typeof(T).GetConstructors().FirstOrDefault();

And I had to use the new reflection API:

var constructor = typeof(T).GetTypeInfo().DeclaredConstructors.FirstOrDefault();

You can read this complete post on the blog of the .Net team for more details about the evolution of the reflection API.

PCL Conclusion: be careful when you upgrade PCL projects to VS2013. Because WP7 support is gone, you don’t need the Async BCL NuGet package anymore. If you choose to target .Net 4.5 beware of possible breaking changes in the reflection API.

General conclusion: if like me your original plan was to target WP7, WP8 and Windows 8.1 withing a single Visual Studio solution, you’re in trouble. My decision is to drop support for WP7 devices for the next update of my app. I guess I could go with branching in TFS to keep compatibility but I don’t have time for that. Be also careful with PCLs and the new reflection API.