Sergii Baidachnyi

In the previous post we started to discuss features and approaches to build Universal Applications. I am going to show that already today you may build applications which will be ready for Windows 10. And today we are going to discuss XAML.

Full Screen and Snap mode

When Microsoft introduced Windows 8, Windows Runtime and Modern UI patterns, there were three things which developers needed to know about applications: all Modern UI applications work in full screen mode; 1024×768 is minimal supported resolution for Windows 8 devices; for resolutions 1360×768 and more Windows 8 allows to show applications in Snap mode with fixed width in 320 pixels. Based on these assumptions many developers designed interfaces for their applications in 1024×768 resolution using these parameters like minimal amount of available space for application. In case of Snap mode, many developers ignored it and tried to avoid to design something for 320×768 resolution. Frankly speaking I didn’t like Snap mode as well. Usually I showed a message like this: “Application doesn’t work in Snap mode. Please, move the application to Full screen mode to continue”. This messages helped me to pass certification.

But everything is changing and Windows 8.1 added some more pixels to Snap mode. Today, default width of Snap mode for Windows 8.1 is 500 pixels. This amount is harder to ignore and that’s more important – Windows 10 allows to run Modern UI applications in window mode like legacy desktop applications.

So, if you are going to create the best UX in your application you should think about different resolutions in advance. Windows 8.1 already doesn’t support events which let the user see that application is in Snap mode, instead, Windows proposes the SizeChanged event. This event is related to Page and you can easy get access to page width and height in order to understand the current size and change layout according to it. The event handler can look like this:

void Page_SizeChanged(object sender, SizeChangedEventArgs e) 
{ 
    if (e.NewSize.Width <= 500) 
    { 
        . . . .           
    } 
    else if (e.NewSize.Width < 1024) 
    { 
        . . . .           
    } 
    else 
    { 
        . . . .           
    } 
} 

So in order to guarantee the best UX in Windows 10 you should think about smaller resolutions. But there is a trick: if you already implement application’s layouts for small resolutions, can you apply it for Windows Phone application – I believe, so.

Therefore, in case of XAML and layouts you can think about resolutions only because both platforms support almost the same set of controls.

ViewState manager

Right now, we are ready to change layouts depending on width of the window. So, it’s time to think how to make it.

The best way to change layouts is using ViewStateManager there. You can use it in XAML to define different visual state groups. Each group can contain Storyboard with animations inside. You can use these animations to hide or show some controls, change ItemTemplate, change controls’ properties etc. It’s easy to declare several groups for different resolutions and, thanks to animations, specify different look for each layout.

<VisualStateManager.VisualStateGroups>
    <VisualStateGroup>
            <VisualState x:Name="DefaultLayout">
            . . . .   
            </VisualState>
            <VisualState x:Name="Layout500">
            . . . .
            </VisualState>
            <VisualState x:Name="Layout1024">
            . . . .
            </VisualState>
      </VisualStateGroup>
 </VisualStateManager.VisualStateGroups>

As I mentioned before, you can change Visability properties, assign new ItemTemplate value etc.

<ObjectAnimationUsingKeyFrames Storyboard.TargetName="itemListView" 
    Storyboard.TargetProperty="Visibility">
    <DiscreteObjectKeyFrame KeyTime="0" Value="Visible"/>
</ObjectAnimationUsingKeyFrames>
<ObjectAnimationUsingKeyFrames Storyboard.TargetName="itemListView" 
    Storyboard.TargetProperty="ItemTemplate">
    <DiscreteObjectKeyFrame KeyTime="0" 
        Value="{StaticResource smallItemTemplate}"/>
</ObjectAnimationUsingKeyFrames>

Onc, you defined all needed visual states, you can implement code, which allows to change visual state based on windows size. You can do it in SizeChanged event handler using this line of code:

VisualStateManager.GoToState(this, "Layout500", true);

I believe that we can finish for today but I am going to continue the series and next time we will discuss DPIs and images.

Several Days ago Microsoft made a first look at Windows 10 App platform. Of course, it’s great to have one developer platform and one core but we still have two months before Build. Therefore, many developers wonder, if they can do something right now to be ready for Windows 10. That’s why I decided to make a series of posts about Universal Applications to help developers start porting their applications right now. In order to do it I am going to describe several topics, which are most important for Universal application development for Windows 8.1 and Windows Phone 8.1. So, let’s start with templates and directives.

Universal Apps Template

Since Windows Phone 8.1 announcement developers got a chance to use Windows Runtime for both platforms. It allows to use the same application model, the same set of controls, the same async/await patterns etc. Of course, there was partial support for Windows Runtime since Windows Phone 8.0 but there was no chance to forget Silverlight and use Windows Runtime only. Windows Phone 8.1 brought Windows Runtime to the new level and developers may forget about Silverlight.

Therefore, developers got a chance to develop applications for both platforms with minimum amount of work. Of course, you still need to compile your application for Windows Phone and Windows separately and you need to upload two (or more) packages to the Store but, in many cases, you may use the same code and it relates not just to business logic but to interface as well.

In order to help developers get better experience there, Microsoft introduced Universal Apps template in Visual Studio (Visual Studio 2013 Update 3 and later), which helps to create applications for both platforms at the same time.

In fact, when you are creating applications using this template, Visual Studio is creating three projects: Windows Phone project, Windows 8 project and Shared project.

The idea is very simple. All things that you are adding to the Shared Project will be precompiled to Windows and Windows Phone projects. Therefore you can put there common resources, business logic and XAML pages, if you believe that they are common for both projects.

Many developers believe that it’s all that you need to know about existing Universal Apps template and that the best way to make universal applications is creating business logic in a Shared project and different pages for Windows Phone and Windows. But this is not true and this approach will not help you to be ready for Windows 10.

Directives

If you are going to make real Universal applications you need to know how to build universal pages and page logic as well. So, I will start with directives, which should help you to tune your code for different platforms.

Of course, Windows Phone and Windows 8 have some differences. For example, Windows Phone supports just buttons and menu items in applications bar but Windows can present any containers there; Windows Phone contains hardware or software emulated back button but Windows doesn’t and so on. So, from time to time you need to create code snippets just for Windows Phone or Windows. You can do it using #if…#endif directive. It’s possible thanks to WINDOWS_APP and WINDOWS_PHONE_APP constants. Of course you can define your own constants but I recommend to use these ones because it should be clear for many developers and Visual Studio Intellisense mode already supports possibility to switch between two platforms based on these constants.

So, if you are going to create platform specific code, you can use the following lines:

#if WINDOWS_PHONE_APP

//your code

#endif

Next time I am going to discuss common XAML pages for both platforms.