Skip to content
/

Not long ago I wrote a blog post about Responsive Pivot Headers in Universal Windows Platform apps. Paul responded to this post asking how to change the background of the selected item, just like the example I posted on top of the post.
It’s a great question and I’m sorry I didn’t cover this part so the pivot looks more like the example image.
An omission I want to correct with this blog post.

Not long ago I wrote a blog post about Responsive Pivot Headers in Universal Windows Platform apps. Paul responded asking how to change the background of the selected item, just like the example I posted on top of the post.
It's a great question and I'm sorry I didn't cover this so the pivot looks more like the example.
An omission I want to correct with this blog post.

The example

So to brush up on the first post, here is the example again:
Example design from pivot guidelines by Microsoft

The solution

There are only 3 small changes to make to get the Pivot more like the example.

  1. Add a dark background to the pivot header
  2. Change the color of the pivot header content to light so we can read it
  3. Add a lighter background to the selected pivot header

Adding the background

There is not really an element to set the background of the whole pivot header, so we have to add one.
In the Pivot Template we have created in the first post we add a Border to the Grid of the PivotPanel.
It gets the darker color and has to span the 3 columns.

<PivotPanel x:Name="Panel" VerticalAlignment="Stretch">
<Grid x:Name="PivotLayoutElement">
    <Grid.ColumnDefinitions>
        <ColumnDefinition Width="Auto"/>
        <ColumnDefinition Width="*"/>
        <ColumnDefinition Width="Auto"/>
    </Grid.ColumnDefinitions>
    <Grid.RowDefinitions>
       ...
    </Grid.RowDefinitions>
    <Grid.RenderTransform>
        ...
    </Grid.RenderTransform>
    <Border Background="#FF34323F" Grid.Row="0" Grid.Column="0" Grid.ColumnSpan="3" HorizontalAlignment="Stretch" VerticalAlignment="Stretch"/>
    <ContentPresenter x:Name="LeftHeaderPresenter" ... />

Lighten up the foreground

Then we go the PivotHeaderItem Style we also created before.
Here we add a Setter so we can change the RequestedTheme to Dark.

<Pivot>
    <Pivot.Resources>
        <Style TargetType="PivotHeaderItem">
            ...
            <Setter Property="RequestedTheme" Value="Dark" />
                <Setter Property="Template">

Adding the highlighted background

Now we go to the Visual State named "Selected".
Here we change the Background color to the lighter color.

<VisualState x:Name="Selected">
    <Storyboard>
        <ObjectAnimationUsingKeyFrames Storyboard.TargetName="ContentPresenter" Storyboard.TargetProperty="Foreground" >
            <DiscreteObjectKeyFrame KeyTime="0" Value="{ThemeResource SystemControlHighlightAltBaseHighBrush}" />
        </ObjectAnimationUsingKeyFrames>
        <ObjectAnimationUsingKeyFrames Storyboard.TargetName="Grid" Storyboard.TargetProperty="Background" >
            <DiscreteObjectKeyFrame KeyTime="0" Value="#FF42424C" />
        </ObjectAnimationUsingKeyFrames>
    </Storyboard>
</VisualState>

And that's it!
It's not an exact replica, but you can change all the colors and sizes to accommodate your needs.

Styled Pivot Header with selected item

Source code

The source code of the sample project on GitHub has been updated to reflect these changes.
You can also go to the specific commit to see the exact changes.

/

These days JSON is used a lot. For storing data, for storing settings, for describing other JSON files and often for transporting information between server and client using DTO’s (Data Transfer Objects).

Recently I was monitoring the data transferred from one of my own Web API controllers to a mobile app. I discovered the amount of data transferred was way more then expected. This inspired me try to reduce the size of the transferred data. In this and following blog posts I will describe the different options you can use and combine.

You can download the source code at the end of my article.

These days JSON is used a lot. For storing data, for storing settings, for describing other JSON files and often for transporting information between server and client using DTO's (Data Transfer Objects).

When using an Azure Mobile App Service or ASP.NET Web API you will see that JSON is the default format to transport data. When running apps on a PC's with a fixed internet connection data size might not be a hot topic. But for apps on mobile devices, possibly using slow, limited, or expensive connections you want to save on the amount of data that is transferred.

Recently I was monitoring the data transferred from one of my own Web API controllers to a mobile app. I discovered the amount of data transferred was way more then expected. This inspired me try to reduce the size of the transferred data. In this and following blog posts I will describe the different options you can use and combine.

You can download the source code at the end of my article.

Part 1: Default Value Handling

I created an ASP.NET Web API controller to demonstrate the default behavior. The default controller returns two objects with data, some properties are empty.
A GET request to http://reducejsontraffic.azurewebsites.net/api/default returns:

[
    {
        "AString": null,
        "AnInt": 0,
        "Fourteen": 14,
        "ANullableByte": null,
        "AStringArray": null,
        "NoUri": null,
        "SomeUri": "http://reducejsontraffic.azurewebsites.net/api/",
        "TheDate": "2015-11-05T17:11:29.0809876+00:00",
        "AnEmptyDate": "0001-01-01T00:00:00",
        "AFixedDate": "2015-07-02T13:14:00+00:00",
        "SingleObject": null,
        "SomeEmptyObjects": [],
        "SomeObjects": [
            { "ADouble": 0 },
            { "ADouble": 3.14 },
            { "ADouble": 1.23456789 }
        ]
    },
    ...
]

(formatted for readability)

As you can see every property is present, despite it doesn't have a real value.

In ASP.NET Web API Microsoft has chosen to use the JSON.net serializer. The serializer has a setting called DefaultValueHandling which is set to Include by default. To quote the documentation:

Include members where the member value is the same as the member's default value when serializing objects. Included members are written to JSON. Has no effect when deserializing.

And we can confirm this is the case when we look at the result from the first example.

If a property already gets the default value when deserializing, why would we want to transport that value anyway?

Changing the Default Value Handling

Another option for DefaultValueHandling is Ignore (and for the serializing part IgnoreAndPopulate acts the same). The documentation states:

Ignore members where the member value is the same as the member's default value when serializing objects so that it is not written to JSON. This option will ignore all default values (e.g. null for objects and nullable types; 0 for integers, decimals and floating point numbers; and false for booleans). The default value ignored can be changed by placing the DefaultValueAttribute on the property.

So when we set this option properties with default values will be removed from the data transferred.

The documentation also mentions the DefaultValueAttribute. So we can describe a different default for a property.

[DefaultValue(14)]
public int Fourteen { get; set; }

Now the property Fourteen will only get serialized when its value is not 14.

I created a second controller with the modified setting. This controller demonstrates this new behavior.
A GET request to http://reducejsontraffic.azurewebsites.net/api/defaultvaluehandling returns:

[
    {
        "SomeUri": "http://reducejsontraffic.azurewebsites.net/api/",
        "TheDate": "2015-11-05T17:30:02.3206122+00:00",
        "AFixedDate": "2015-07-02T13:14:00+00:00",
        "SomeEmptyObjects": [],
        "SomeObjects": [
            { "ADouble": 0 },
            {},
            { "ADouble": 1.23456789 }
        ]
    },
    ...
]

(formatted for readability)
That's quite a reduction! But are all values recovered after deserialization?
Yes, if we didn't use the DefaultValueAttribute anywhere in our DTO it will work right away. Otherwise we will need to tell the serializer explicitly we want to populate the default values on deserialization using the same DefaultValueHandling setting we used on serialization.

I wrote a small console app as a client to show you everything is restored correctly.
When we look at the watch in the debugger we see all properties not present in the transferred data are populated with either null or their correct default value.
Visual Studio Watch showing a deserialized object with default value handling

Conclusion

In this example we managed a reduction of 41%.
Of course the reduction depends heavily on how often default values are part of your transferred data. But it's an easy diet on transferred data that the other side can reconstruct on itself.

Source code

You can download my Reduce Json Traffic sample project on GitHub.

Filed under C#
Last update:
/

My PC just got upgraded to the latest Windows 10 Insiders build (slow ring, build 10565) and suddenly a couple of VM's were missing from the Hyper-V Manager. I first suspected the security settings on the directories were the problem, but my changes didn't fix anything. After browsing around the internet I found a couple […]

My PC just got upgraded to the latest Windows 10 Insiders build (slow ring, build 10565) and suddenly a couple of VM's were missing from the Hyper-V Manager.
I first suspected the security settings on the directories were the problem, but my changes didn't fix anything. After browsing around the internet I found a couple of fixes that might help you if you have the same problem.

Save your machine

The post Windows 10 Preview - VMs Missing In Hyper-V Manager by Rhoderick Milne shows he was still able to see the Virtual Machines using PowerShell.
He got the Virtual Machines to show up again after saving them from the command line:

Get-VM | Where { $_.State –eq "Running" }  | Save-VM

Get a heartbeat

Although he could see them again in the Hyper-V Manager, some were stuck when starting up.
The problem is the integration service is reporting a corrupt heartbeat. He fixed this by disabling the heartbeat service for these machines.

Get-VM  | Where { $_.Heartbeat -eq "OkApplicationsUnknown" } |
                                              Disable-VMIntegrationService Heartbeat

Adjust the registry

The command were not sufficient for my situation. The VM's were still missing.
Then I ran across the article PSA: Missing Hyper-V VMs on Windows 10 - Build 10547 by Ben Armstrong.
He indicates that it's a registry problem in this build of Windows.

Set-ItemProperty
           -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization"
           -Name "CurrentVmVersion" -Value "6.2"
Restart-Service VMMS

Conclusion

This fixed it for me.
3 Simple PowerShell statements can rescue your VM's from oblivion on the Windows 10 preview.