Styling the PickerFlyout

I recently had a requirement to customise the PickerFlyout for a Windows Phone 8.1 app.  By default the Background color is the chrome color for the selected theme.  We had a requirement to have all of our Flyouts use a white background.

Problem is, PickerFlyout does not appear to be "styleable", and in fact is simply a Popup control.  Using XamlSpy we can see that the child of the Popup is a PickerFlyoutPresenter, which can be styled.  But if you attempt something like:

<Style TargetType="PickerFlyoutPresenter">
<Setter  Property="Background"  Value="White" />
</Style>

 

on a page or control level you will find that it has no effect on your Flyout.  This is because the Flyout is not a child of the page or control.  Simply move it to your App.xaml to have this style applied throughout your app.

 

 

Alternating Rows with the LongListSelector

If you are familiar with the LongListSelector control in Windows Phone, you may have noticed that it does not natively support alternating row styles.  With regards to list items, you’re left with the ItemTemplate to determine the layout and appearance of your list items.

To change the background colour of your items, one possible workaround is to use a converter to evaluate a property on your bound item, and alternate between two sets of brushes.  I’ve created an AlternatingRowConverter to do just that.

Here, the converter is expecting an integer value and by doing a simple modulus we can switch between two SolidColorBrushes, which have been defined as public properties.
Here’s what our xaml looks like:

Notice that the PrimaryRowBrush and AlternateRowBrush can be defined in a number of ways, either by named value or hex, or creating the brush directly.

Within the LongListSelector.ItemTemplate we use a StackPanel to house the item.  The Background property of the StackPanel is bound to the Index property of a business object called Fruit.  The Converter takes the integer value and returns either the PrimaryRowBrush or AlternateRowBrush.
And here’s the result:

You can download the source code here.

Code Complexity and Prism

I've recently had to review a number of problem areas of a large Prism project.  In the course of review, I had a number of realisations regarding design patterns, WPF and code complexity.  We use MVVM and MVC design patterns throughout our project.  Not surprising, many of our problem areas were related to divergence from these patterns.

In our implementation of MVVM we strive to have a complete decoupling of our Xaml views and any business logic.  So, finding views riddled with code-behind indicated a lack of understanding of:

1. The MVVM design pattern, or
2. The benefits of code separation

Or as I was to find out, a limited understanding of Xaml.  The view in question utilised over ten custom converters.  Not that converters are inherently evil, however, these converters were being used where Triggers or Data Binding could have easily gotten the job done.  But, if one is unfamiliar with these, they tend to use techniques they are familiar with -- in this case, IValueConverter.  Poor use of custom converters effectively becomes "hidden code-behind," and is difficult to debug and test.

Additionally, I found the ViewModel being underused and misused, providing a sparse selection of high level properties for binding.  This, in part, prompted the excessive use of custom converters.

The offending code-behind was an unusual solution brought about by a lack of Xaml know-how.   All of this code could have been expressed using Xaml.  Conclusion: Knowing a little about Xaml can reek havoc on a well-structured Prism project.

The hallmark of these decisions is code complexity, your first clue things have gone astray.

After much refactoring, including the removal of all the custom converters, the code-behind and reworking the ViewModel, the whole area straighten out and was greatly simplified.  It was a prime example of the power and importance of design patterns in maintaining good form and structure.

Prism Sample: Resources

An area of Prism development that often gets overlooked is the management of resources.  I mentioned in a previous blog that View reuse is unlikely, but that doesn't mean you should create unnecessary dependencies to a resource assembly.

Similar to modules, resource assemblies can have an accompanying interface assembly.  This is done by defining ComponentResourceKeys in your interface assembly and using them as resource keys in your resource dictionary and in your Views.

public static class Styles
{
    public static ComponentResourceKey LargeTextStyleKey
    {
        get { return new ComponentResourceKey(typeof (Styles), "LargeTextStyle"); }
     }
}

and in your Xaml...

<textblock text="My Sample TextBlock Style"
           Style="{StaticResource {ComponentResourceKey TypeInTargetAssembly={x:Type Interfaces:Styles}, ResourceId=LargeTextStyleKey}}" />

Taking this approach decouples your modules from the resource assembly.  The advantage to do this is not so much in the area of reuse, but more in the implementation of themes.  Any Views that require the use of a resource can simply refer to it by its ComponentResourceKey.

Additionally, I would only have the Shell load the external resources, since the View modules are now unaware of the external resource.  The only draw back in doing this is you will lose your Visual Designer when editing your Xaml, because the designer cannot resolve the resource to render it.

It is also worth setting up default styles based on control types, by using the control type as the resource key (e.g. {x:Type TextBlock}).  This does not require the use of ComponentResourceKeys.

The area of theming WPF applications is a common one and there are a number of resources on CodePlex which address this area.  One example is the Razre WPF Framework, or you can build your own ThemeManager.

Conclusion
I think this pretty much concludes the PrismSample articles.  This was meant as an introduction for developers starting out with Prism and to provide some guidelines in setting up a Prism solution.  I hope this was of some use.  I'm certain others will have differing opinions, and that's okay too.  I'm always on the hunt for new approaches and new ideas.

I think Prism has a real future in WPF development.  Once you get into it and see the benefits, it changes how you think about and view WPF development; afterwards it is difficult not to think and develop that way, which is a good thing.

As always, comments/feedback welcome...