Building a colour palette for your app

Posted Thursday, April 10, 2014 by

When creating your app on both the phone and tablet almost all guidelines will tell you create a consistent colour palette. There's a lot of tools out there to help you design your palette, Kuler from Adobe is a good example. But what's the best way to use our palette in your app?

There's a couple of goals here, the first is we only want to have to define our colours once for the entire app. This way if we need to tweak them or do a wholesale replacement we're not spending hours hunting for every instance of that colour.

The second is to provide an easy way to override existing theme resources.

What I tend to do is create a separate resource dictionary for the palette, this is because it's usually imported into other dictionaries and I want to keep the repetition low. The other resource dictionary I'll create at this point is a theme overrides one, this contains all the redefinition of the built in resources using the new palette of colours.

In our palette dictionary we'll want to define the colours and brushes separately, this is because despite most of the time we'll be using the brush there will be times the colour is required. Naturally the brush definition refers to the colour so we're sticking with our goals. Typically a colour / brush definition will look like:

<Color x:Key="MajorAccentColor">#FF2980B9</Color>

<SolidColorBrush x:Key="MajorAccentBrush" Color="{StaticResource MajorAccentColor}"/>

Sometimes your designs may make use of the same colour but with different alpha (or opacity) values. For me if this brush is going to be used through the app I'll define it within the palette like so:

<Color x:Key="MinorAccentColor">#FF80B929</Color>

<SolidColorBrush x:Key="MinorAccentBrush" Color="{StaticResource MinorAccentColor}"/>

<SolidColorBrush x:Key="MinorAccentOverlayBrush" Color="{StaticResource MinorAccentColor}" Opacity="0.5"/>

However if it's a one off I'll probably define the brush as inline XAML referring back to our colour resource.

<controls:Sidebar x:Name="Sidebar" IsExpandedChanged="OnIsExpandedChanged">

    <controls:Sidebar.Background>

        <SolidColorBrush Color="{StaticResource SidebarBackgroundColor}" Opacity="0.5"/>

    </controls:Sidebar.Background>

I try to name the colour / brush pairs in generic names more along the lines of their usage than what they look like colour wise. This is because they'll often be tweaked and it can look rather silly to have a resource named "RedColour" that's actually blue.

Now our palette is defined let's make use of it, the first thing I go through and do is redefine quite a few of the out of the box theme resources to make the controls more in line with the rest of my app. It's these little bits that really polish an app, I die a little on the inside when I see the default purple in combo boxes and progress rings. I swear Microsoft chose that colour so people would be forced to deal with it but a lot don't.

In my theme overrides resource dictionary I import the palette and start to define styles for the controls in terms of colours from the palette. We don't need to redefine every single resource, typically only the ones that add the accent colour. For instance with the ComboBox control the overrides are:

<ResourceDictionary.MergedDictionaries>

    <ResourceDictionary Source="/Resources/Palette.xaml"/>

</ResourceDictionary.MergedDictionaries>

 

<SolidColorBrush x:Key="ComboBoxItemSelectedBackgroundThemeBrush" Color="{StaticResource MinorAccentColor}" />

<SolidColorBrush x:Key="ComboBoxItemSelectedPointerOverBackgroundThemeBrush" Color="{StaticResource LightMinorAccentColor}" />

<SolidColorBrush x:Key="ComboBoxSelectedBackgroundThemeBrush" Color="{StaticResource MinorAccentColor}" />

<SolidColorBrush x:Key="ComboBoxSelectedPointerOverBackgroundThemeBrush" Color="{StaticResource LightMinorAccentColor}" />

That's pretty much it, a nice easy way to define your colour scheme realistically in any XAML app and reuse it well.

Caliburn.Micro and Universal Apps

Posted Thursday, April 3, 2014 by

There’s been a lot of announcements here at Build today, including the availability of the Windows Phone 8.1 SDK. This release brings a common Xaml UI framework between Windows Phone and Windows and some tooling support to enable you to easily share C# and Xaml between the two platforms called Universal Windows apps.

I’m also really pleased to say I’ve recently pushed the code to enable you to use Caliburn.Micro on the new frameworks. It’s available on GitHub and on Nuget under version 2.0.0-beta2, this version adds the new Windows Phone 8.1 platform to the Portable core assembly and appropriate Platform assembly.

Because the new Windows Phone platform is closely aligned with the Windows platform you’ll notice that we build the app like it’s a Windows 8.1 app. For CM this means a few changes from Windows Phone 8, such as using CaliburnApplication rather than Bootstrapper, but for the most part most of the tutorials for using CM on Windows 8.1 will apply to Windows Phone 8.1.

If you still want to build using the Windows Phone 8 Silverlight platform then WP8 version is still available from the same package and works just as it did before.

To show off how powerful it is now the repository has a sample Universal app where we share views and view models across both platforms, but still enable us to have custom views for shared view models. This coupled with Portable class libraries enables a variety of strategies to share code over many number of platforms. I’ll hopefully be covering a lot of these in the near future.

As we get to grips with some of the stuff still to be announced over the coming days there should be more to add to this.

On a related note I just want to thank Marker Metro, I wouldn’t have been able to get this release ready so quickly without their support.

DVLUP available in New Zealand

Posted Tuesday, April 1, 2014 by

It's been a long time coming but I'm really happy to say the Nokia developer reward program DVLUP is now available in New Zealand. We at Marker Metro have been working with Nokia to set up a launch here in Auckland. Come along to find out more about it and get a recap of the news and announcements from Build. RSVP here.

If you already want to sign up then use this link and score me some bonus XP.

Using value converters by convention

Posted Thursday, March 27, 2014 by

The application of a convention in Caliburn.Micro is a bit of a pipeline with multiple steps, almost all of them we can modify, let's look at bringing value converters into the equation.

Most of the time the default conventions tend to bring like-minded types together. That's natural in that conventions should be reasonably intuitive, like a string property on the view model being bound to the Text property of the TextBox.

Sometimes these types don't always line up, which is where value converters typically come in. The most common of these being converting between boolean and visibility properties.

Caliburn.Micro does a little bit of work here already, if a convention calls for properties of the two above types (boolean and visibility) then it automatically adds a BooleanToVisibilityConverter to the Binding.

We can extend this through the modification of the ConventionManager.ApplyValueConverters method, but why would we do this? In an app I'm currently working on I want to use relative dates through the app, I'm using a value converter that leverages the Humanizer library (check it out if you haven't already) to do the conversion. This means everywhere I want to out put the date I need to dispense with the normal convention using x:Name and set up the binding with the value converter. A bit of a pain and there's always a chance I could miss one.

What we need to do is modify Caliburn such that when it applies a convention between a DateTime (or DateTimeOffset) property and a TextBlock's Text when add the converter to the process.

The code is pretty simple, the only weird part is taking a reference to the default implementation first so that we can keep the default behavior as well.

var baseApplyValueConverter = ConventionManager.ApplyValueConverter;

 

ConventionManager.ApplyValueConverter = (binding, bindableProperty, property) =>

{

    baseApplyValueConverter(binding, bindableProperty, property);

 

    if (bindableProperty == TextBlock.TextProperty && typeof(DateTime).IsAssignableFrom(property.PropertyType))

        binding.Converter = new RelativeDateTimeConverter();

 

    if (bindableProperty == TextBlock.TextProperty && typeof(DateTimeOffset).IsAssignableFrom(property.PropertyType))

        binding.Converter = new RelativeDateTimeConverter();

};

Now whenever a convention on a TextBlock is wired to a DateTime it will display a relative date time. We can remove all our bindings and converters from code and go back to simple x:Name conventions.

Some thoughts about custom Uri Protocols

Posted Thursday, March 20, 2014 by

I've seen a lot of content around lately discussing the use of custom uri protocols in your Windows Tablet and Phone apps. They're a great way to have other apps launch your app in a deep link kind of way, however I don't think developers are really using them to their full potential.

Matt Lacey has a great post listing some of the 300 or so apps that implement custom uri protocols and their protocol name. Looking through the list a couple of things jump out at me.

The first is that there's no documentation about the protocol itself, even with the protocol name from the list I have no real idea about how to use it. Some developers like Lazyworm Apps have documented their metrotube protocol but the amount that have are few and far between. There needs to be a central resource for this list including documentation.

My second observation is that almost all the protocols are completely unique to that app, usually derived from the app name. This means that any other app is limited to launch that and only that app. The end user also doesn't have a choice of which app they want to use to handle that protocol.

This problem is caused by a lack of global protocols besides the usual suspects of http, mailto etc. There are no established protocols for things like "watch a youtube video" leaving all the protocols as their own little islands.

What I'd love to see is the whole app protocol thing expanded so we can have a rich ecosystem of apps plugging into to fill different parts of a workflow, probably not going to happen but a guy can dream right?

Page 1 of 1412345>

Professional Windows App Development