Category Archives: Development

Tips Windows 8 Windows Phone

Dependency property registration helper

Update: the code was updated to support two additional scenarios: inherited classes and classes that cannot inherit DependencyObject<T>.

Writing dependency properties for XAML controls is annoying and contains some redundant parts. Let’s take a look at an example dependency property (generated from snippet):

public static readonly DependencyProperty PropertyTypeProperty = DependencyProperty.Register(
    "PropertyType", typeof (propertyType), typeof (SampleDependencyObject), new PropertyMetadata(default(propertyType)));

public propertyType PropertyType
{
    get { return (propertyType) GetValue(PropertyTypeProperty); }
    set { SetValue(PropertyTypeProperty, value); }
}

While the property (at the bottom) itself cannot be simplified anymore, the registration part at the top can be simplified quite a lot. Let’s take a closer look at the necessary parameters:

  • First is the property name which one should never write in string literals. The new feature in C# 6: nameof will help fix that, but for now we are stuck with this.
  • The second parameter is the type of our property, which is already written below and should somehow be inferred automatically. Reflection could help with that, but it’s a heavy artillery and is not an ideal solution here.
  • The third parameter is the type of the enclosing class, a context sensitive information that should be omitted.
  • Finally, in most cases the default value is the default value for the property type.

Our goal here is to remove redundancy, use contextual information and remove string literals all in once. And to shorten our code, of course. Luckily, we can already do that in C# 5 without the upcoming nameof feature and the final syntax for the registration part (the property, unfortunately, stays the same) can be reduced to this:

public static readonly DependencyProperty SampleProperty = Register(d => d.Sample);

read more »

Development

C# 6.0 is here and will shorten your code

In case you haven’t heard the news, the new version of Visual Studio is out: Visual Studio 2015 Preview. You can grab it here. With you’ll get:

  • A new version of C# language currently at version 6
  • .NET Compiler Platform formerly known as Roslyn: the new compiler for C# and VB.NET which is open source and exposes quite a lot of the underlying infrastructure for the user
  • New JIT compiler i.e. RyuJIT which is also open source
  • Open source subset of .NET Framework

Small things really :) This post will focus on the new features in C# 6 which can both shorten your code and make it more understandable. So let’s begin. In fact, only a couple of new features can be used to add more code to your existing code base.

Class properties enhancements

Writing immutable classes is relatively hard in C# and a few small additions to the language make things easier. Take a look at the following class: read more »

Development

XNA and Visual Studio 2013

This is definitely the coolest thing I found today: running XNA in Visual Studio 2013. Thanks to the unofficial contribution, it is possible to use XNA 4.0 in Visual Studio 2013, 2012 and 2010. Find the appropriate download links at codeplex.

This brings XNA development back in the latest version of Visual Studio, but sadly, although you can develop Windows Phone 7 XNA games in VS 2013, you cannot deploy them from Visual Studio since it doesn’t support WP 7. But that can be fixed since the final XAP is valid and XapDeploy can be used to deploy built games to emulator.

XNA 4.0 running from Visual Studio 2013

XNA 4.0 running from Visual Studio 2013

So as XNA projects can be loaded in the same solution as MonoGame projects, porting old games will be easier. Since the project promises porting XNA to DirectX 11, we now have two projects with same scope in mind.

Development

Cool feature in C# vNext – default values for automatic properties

The next release of C# is on its way and brings cool new features. One very popular request is the ability to initialize automatic properties, those without an explicit backing field, to some value without resorting to constructor. You could vote on the UserVoice here. Here is the proposed syntax:

public int X { get; set; } = x;

And if you need readonly properties:

public int Y { get; } = y;

Although a small change, this can clear up the code significantly.

Windows Phone

Simulating click event on ApplicationBarIconButton

TL;DR it cannot be done. But, if you have access to the application’s source code, there is a small workaround.

So, why would we want that in the first place? UI automation is not as uncommon as one would think. Its primary use is for creating UI tests for which you need the ability to simulate clicks.

So, how does one simulate click on UI elements? By using a derived class from System.Windows.Automation.Peers.AutomationPeer.

But there is no such class for ApplicationBarIconButton and there is no way for us to manually invoke click events. Usually we could use reflection for this purpose, but platform security forbids us from accessing private methods and fields so that goes out of the window.

Luckily, we can create our own class that inherits ApplicationBarIconButton and exposes such function. It is pretty short code to write actually:

public class ApplicationBarIconButton : ApplicationBarIconButton
{
    public new event EventHandler Click;

    public void RaiseClick()
    {
        if (Click != null)
            Click(this, EventArgs.Empty);
    }
}

And that’s it, just replace every regular ApplicationBarIconButton with this in XAML and you are done. In your testing framework find buttons, cast them to this type and call RaiseClick.

Note that this won’t actually work if you are using some bindable replacement for the regular binding-unfriendly

ApplicationBar.

Windows Phone

Nokia Imaging and Big UI Wiki Competition entry: Advanced Techniques for Big UI

I wrote about some advanced techniques for adapting Windows Phone UI for big screens and 1080p resolutions on Nokia’s Developer Wiki: Advanced Techniques for Big UI. The article was written as a part of Nokia Imaging and Big UI Wiki Competition 2013Q4 which ended two days ago. There are great entries in this competition and I recommend reading them if you want to become familiar with Nokia Imaging SDK 1.0 and developing applications for the big screen.

Here is an introduction:

Designing applications for Windows Phone 7.x (from now on WP7) was easy since there was only one supported resolution – 480 x 800 (WVGA). In addition, screen sizes did not vary that much between vendors. This “un-fragmentation” was hailed as a great feature for the young OS since applications would look the same on all devices that ran Windows Phone 7.

Windows Phone 8 introduced two additional resolutions: 768 x 1280 (WXGA) and 720 x 1280 (720p). The first is an up-scaled version of the original resolution and they share the same aspect ratio (15:9). The latter resolution actually has a different aspect ratio (16:9). This meant that applications had some extra space at the bottom for the UI, but in general if layout is done dynamically, UI does not need to be altered significantly to account for the extra space. The devices got a little larger, but this also meant little to the application design process.

However, coming with GDR3 update, Windows Phone 8 got a new resolution – 1080p. Along with the new, and currently the highest available, resolution, devices also grew in size. For the first time Windows Phone 8 is ran on devices with 6 in screen diagonal. Applications can no longer simply scale up to accommodate such large devices, they need to change their layout a bit as well.

This article presents a couple ideas for adapting the application’s UI for the large screen. It also contains some helper classes useful for detecting current resolution and current screen size. There is also a small trick used here to use 720p emulator image as a 1080p device with “faked” screen diagonal of 6. This allows for easy testing of mentioned techniques without having a physical device with either 6 screen diagonal or 1080p resolution.

Read more on wiki page.

Tips Windows Phone

Windows Phone UI Tip – Empty List Header Style

I’ve already talked about creating a so-called “empty list box template” for situations when you have no items and an empty screen area might confuse users. You could fake it by adding a little TextBlock control that would be shown when you have an empty ListBox control to tell the user that (s)he would normally have a list of items there.

To do that, I blogged about two different techniques: ListBox empty template – using visual states (part 1) and ListBox empty template – using control templates and behaviors (part 2).

One thing I haven’t talked about before is what should that text look like. In my opinion, unless you are completely reinventing your UI, you should strive for consistency. The best way to do that is mimicking the built-in apps. You already have such style in the stock applications: e.g. if you open Marketplace and search for some non-existing application, you will get the message that there are no such applications as you can see below. If you want to use exactly that style, you can use a predefined style called EmptyListHeaderStyle:

<TextBlock Style="{StaticResource EmptyListHeaderStyle}"
           Text="Some items should appear here..." />
Simple style for the "no results found" text

Simple style for the “no results found” text

If you are still targeting Windows Phone 7, you won’t be able to use that style because it was introduced in Windows Phone 8. But if you still want to use it, copy/paste the following style definitions in your favorite place for styles:

<System:Double x:Key="EmptyListHeaderFontSize">32</System:Double>

<Style x:Key="EmptyListHeaderStyle" TargetType="TextBlock" BasedOn="{StaticResource PhoneTextBlockBase}">
  <Setter Property="FontFamily" Value="{StaticResource PhoneFontFamilySemiLight}"/>
  <Setter Property="FontSize" Value="{StaticResource EmptyListHeaderFontSize}"/>
  <Setter Property="Foreground" Value="{StaticResource PhoneSubtleBrush}"/>
</Style>

UPDATE: Please not that Windows Phone 7 does not have PhoneTextMidContrastColor, but PhoneSubtleBrush is close enough. It matches the dark theme version exactly, but is slightly different in the light theme.

Tips Windows Phone

Windows Phone UI Tip – 95px padding at the bottom

I’ve found this tip recently that isn’t documented at all, and yet is important for every Windows Phone designer and developer. If you have scrollable content on your page, you should put 95px bottom padding at the end of your content. This way the content doesn’t reach all the way to the very bottom of the page.

For example, here is a simple page that is slightly higher than the visible area:

Simple scrollable page with zero padding at the bottom

Simple scrollable page with zero padding at the bottom

If user scrolls to the end of the page, the rubber band effect will come into view and the content will be pulled slightly above the bottom. But once the scroll is released, the content bounces back down to the edge of the screen once again.

Simple scrollable page with zero padding at the bottom scrolled all the way up

Simple scrollable page with zero padding at the bottom scrolled all the way up

While it doesn’t poke your eyes and it generally works OK, having content stretched all the way to the bottom is not ideal. The quick fix for this is adding 95px margin to the bottom to move your content away from the bottom – regardless if it is bottom of the phone chrome or the application bar. The final result is more pleasing to the eye.

Scrollable page scrolled to the bottom with 95px padding

Scrollable page scrolled to the bottom with 95px padding

You can see the same padding in effect if you check the profile and history pages on any of your contact. It is also present on the new appointment page in the Calendar app and in the Internet Explorer’s settings page. Speaking of settings, scroll down to the bottom in the Settings application.

Like every other design tip – the effect is subtle, but it works :)

Windows Phone

Shorter way of writing Grid row and column definitions

If you are using Grid based layout in your application, you know how writing row and column definitions can quickly become tedious. And it also occupies a lot of space. Since I needed a less verbose way to quickly define the layout, I quickly thought of writing a custom attached property that will generate those definitions.

On the image below you can see the result: a 2×2 grid containing another 2×2 grind inside one of its cell.

A simple grid based layout

A simple grid based layout

And the shorter code for that? Here it is:

<Grid a:GridEx.RowDefinitions="*,*"
	  a:GridEx.ColumnDefinitions="*,*"
	  Grid.Row="1" Margin="12">

	<Grid a:GridEx.RowCol="*,*|*,*">
		<Rectangle Fill="Red" />
		<Rectangle Fill="Green" Grid.Column="1"/>
		<Rectangle Fill="Blue" Grid.Row="1" />
		<Rectangle Fill="Yellow" Grid.Row="1" Grid.Column="1"/>
	</Grid>

	<TextBlock  Text="Upper left"/>
	<TextBlock Grid.Row="1" Text="Lower left"/>
	<TextBlock Grid.Column="1" Text="Upper right"/>
	<TextBlock Grid.Row="1" Grid.Column="1" Text="Lower right" />
</Grid>

The first two line show the shorter way for writing row and column definitions independently while in the line 5 you can see how to quickly define both row and column definitions in a single line. These two attached properties parse the strings and fill the right definitions.

Full source code can be found at github: tpetrina/wp-helpers. You can also use the above syntax in your projects by adding a NuGet package WindowsPhone.Helpers.

Windows Phone

Data binding: Windows Phone 7 cannot access private/internal functions, but Windows Phone 8 can

I’ve previously noticed a particular problem with reflection differences between WP7 and WP8 and I noted them when I wrote about quickly generating JSON from anonymous objects. It appeared that on Windows Phone 7 reflection cannot access private/internal functions and thus cannot serialize anonymous objects.

This is also true when using data binding to private/internal view model. On a recent Stack Overflow question – Binding on Windows Phone 7 does not work, a user encountered a problem with his code not working on Windows Phone 7 while working on Windows Phone 8.

The issue was that the view model is not public. This is really easy to reproduce, just create an internal view model and use it as a DataContext.

class MainViewModel
{
	public string Text { get { return "Hello world"; } }
}

As for the view, simply bind to the Text property:

<TextBlock Text="{Binding Text}" />

The project will correctly work on Windows Phone 8 devices and emulators, but it won’t work on Windows Phone 7 devices and emulators.

Expected result - only on WP8

Expected result – only on WP8

Turning on breaking on every thrown exception in the Exceptions dialog (as seen on the image below) will ensure that his error is caught during debugging.

Enabling breaking whenever an exception is thrown

Enabling breaking whenever an exception is thrown

Until next time, happy coding :)