7 Mistakes Developers make when implementing WP Custom Controls
published on: 8/4/2011 | Views: N/A | Tags: CustomControls BestPractices
by WindowsPhoneGeek
In this article I am going to talk about 7 common mistakes that developers make when implementing Windows Phone Custom Controls. All of the examples given below are taken from real questions that we were asked or from real Windows Phone projects that we have helped developers with the implementation.
Generally, Custom Controls are skinable, themable and reusable controls that once created can be used by simply loading the assembly in any project. All controls that are used in Silverlight for Windows Phone 7 (eg., Button, TextBlock, ListBox) and UserControl are also Custom Controls. Usually Custom Controls inherit from Control, ItemsControl, ContentControl, etc.
NOTE: You can also take a look at the following article for reference: Creating a WP7 Custom Control in 7 Steps
Mistake #1: Wrong choice of whether to implement a Custom Control or a UserControl
Generally when talking about Windows Phone controls you have two options: either to implement a User Control or a Custom Control.
|
User Control: a reusable control that combines existing controls and can implement its own logic. User-Controls can be reused but cannot be skinned or themed. |
Custom Control: skinable, themable and reusable controls that once created can be used by simply loading the assembly in any project. |
|
Good for static layout |
Good for dynamic layout |
|
Easier to create |
Harder to create |
|
Usually used to compose a set of existing controls |
Usually used to create a new control |
|
Usually used to allow reusability on a larger scale |
Usually used to allow reusability on a smaller scale |
|
Provides less flexibility |
Provides greater flexibility (ex: the control template can be replaced with a completely different one) |
|
Does not require too much knowledge of Silverlight UI model |
Requires better understanding of Silverlight UI model |
Example1: Correct choice of using Custom Control
Control Description: We want our control to :
- contain a collection of items
- expose ItemsSource
- be easily reusable
- allow automatic sorting, filtering,etc. based on some condition
- have multiple Views/States, i.e. FullScreen mode, Minimized mode, Standard mode, etc.
- allow item selection
- expose custom properties
- be fully customizable
Control Usage: We will use this control multiple times in our application and in several other applications.
Our Comment: In this case we would suggest that you implement a Custom Control that derives from ListBox or optionally directly from ItemsControl. The control will be compiled into a separate assembly (.dll) so that it can be easily reused in other applications as well.
Example2: Incorrect choice of using Custom Control
Control Description: We want our control to:
- have ListBox which will be automatically sorting, filtering,etc based on some condition. For example Button click.
- consists of a ListBox, two Buttons and a TextBlock
- exposes several custom properties
- not necessarily provide great flexibility in appearance customization
Control Usage: We will use this control only a couple of times in a single application.
Our Comment: In this case we would suggest that you implement a UserControl instead of Custom Control because you will use it only a couple of times in the same project and it will be easier to implement the desired functionality in code behind rather than trying to implement a Custom Control from scratch.
Mistake #2: Deriving from an inappropriate base class
When implementing a Custom Control you need to derive from an appropriate base type . Here are some suggestions:
ItemsControl: When you want to implement a control that has multiple items usually using the ItemsControl is a good choice.
ContentControl: When you want to implement a control that displays a single element (through the Content property), possibly using different templates.
ListBox: When you want to implement a selectable ItemsControl
Control: When there is no other suitable type to derive from.
Controls such as Button, CheckBox, ScrollViewer, etc.: When you want to implement a specific type of control and need some of the properties/method of the parent control.
Mistake #3: Forgetting to set DefaultStyleKey in the constructor
It is very important not to forget to set the DefaultStyleKey in the constructor of your custom control.
NOTE: DefaultStyleKey gets or sets the key that references the default style for the control.
public class MyCustomControl : ContentControl
{
public MyCustomControl()
{
DefaultStyleKey = typeof(MyCustomControl);
}
}
Mistake #4: Control theme(default Style) in the wrong place
This is one of the most common mistakes that we have seen. In short the base structure of a Custom Control is:
MyCustomControl.cs + Themes/generic.xaml
- MyCustomControl.cs: place the C#/VB code here
- Themes/generic.xaml: place the UI here
-
NOTE: You must create a Themes folder(the name is very important) and place the generic.xaml there
For now in Silverlight for Windows Phone Mango there is no suitable VisualStudio Template for adding a XAML file or ResourceDictionary as a file in your project. So in order to add generic.xaml file you can create a new Class by choosing Add->NewItems->Class and rename it to generic.xaml.
NOTE: The name is important!
NOTE:It is very important that you remember to set the generic.xaml file's build action to Resource. This is necessary in order to make sure that the template is packed in the same assembly as the control otherwise the template wont be available.
Mistake #5: generic.xaml defined or used in a wrong way
Example1: Correct
- Themes/generic.xaml
- Build Action: Resource
- ResourceDictionary without any x:Key or x:Name
- include
xmlns:vsm="clr-namespace:System.Windows;assembly=System.Windows" if using any VisualStates
Example2: Incorrect
- /generic.xaml
- Build Action: Content
- ResourceDictionary with x:Key or x:Name
Mistake #6: Wrong Style
The default style and the ControlTemplate of the custom control determine how the control will look like.
When creating the default style(theme) of a Custom Control it is very important to consider the following things:
- You must define a valid ControlTemplate
- Add a valid TargetType
- No x:Key
- No x:Name
Example1: Correct Style
<Style TargetType="local:MyCustomControl">
<Setter Property="Template">
<Setter.Value>
<ControlTemplate TargetType="local:MyCustomControl">
..
</ControlTemplate>
</Setter.Value>
</Setter>
</Style>
where local is your new Custom Control namespace for example:
xmlns:local="clr-namespace:CustomControlSample"
Example2: Incorrect Style
Here is an example of incorrectly defined Style.
Mistake #7: Using Binding instead of TemplateBinding
TemplateBinding links the value of a property in a control template to be the value of a property on the templated custom control!
Example1: Correct
Example2: Incorrect
In this article I talked about 7 common mistakes that developers make when implementing a Custom Control in Silverlight for Windows Phone.
I hope that the post was helpful.
You can also follow us on Twitter @winphonegeek
Comments
Great post!
posted by: sloob80 on 8/4/2011 6:12:53 PM
This is a very useful post! Thanks for writing it.
Keep up with the good work
posted by: rahman on 8/4/2011 9:48:24 PM
Amazing post! Keep up with the good work.
VisualStateManager
posted by: Morten Nielsen on 8/8/2011 6:16:56 AM
I don't get why you say it's required to register vsm:... prefix for the visual state manager? You don't need that prefix to reference VisualState in XAML.
Great Post
posted by: Mike Gold on 8/10/2011 6:51:23 AM
I enjoyed this one. Especially when to create User Controls and when to create your own custom control. I agree creating custom controls is somewhat painful, but they are definitely more appropriate in a lot of situations.
RE:VisualStateManager
posted by: winphonegeek on 8/10/2011 12:10:35 PM
The "vsm" prefix is required if you are using VisualStates in this way:
<vsm:VisualStateManager.VisualStateGroups> ... </vsm:VisualStateManager.VisualStateGroups>
instead of:
<VisualStateManager.VisualStateGroups> ... <VisualStateManager.VisualStateGroups>
Although it is not necessary to use this prefix in Silverlight 4 sometimes your custom control is not editable/visible in the Expression Blend designer because of the lack of this prefix.
Our Top Articles & Free books
- Our FREE e-book: "Windows Phone Toolkit In Depth" 2nd edition
- 400+ Windows Phone Development articles in our Article Index
- 21 WP7 Toolkit in Depth articles covering all controls
- 12 WP7 Coding4Fun Toolkit in Depth articles covering all controls
- Performance Tips when creating WP7 apps
- Creating a WP7 Custom Control in 7 Steps
- WP7 working with VisualStates: How to make a ToggleSwitch from CheckBox
- What makes a WP7 App successful
- Creating theme friendly UI in WP7 using OpacityMask
- Implementing Windows Phone 7 DataTemplateSelector and CustomDataTemplateSelector
- All about Splash Screens in WP7 – Creating animated Splash Screen
- Getting Started with Unit Testing in Silverlight for WP7
- WP7 WatermarkedTextBox custom control
Our Top Tips & Samples
- All about WP7 Isolated Storage series
- WP7 Dynamically Generating DataTemplate in code
- 5 tips for a successful WP7 Marketplace submission
- WP7: Navigating to a page in different assembly
- WP7 ContextMenu: answers to popular questions
- WP7 ListBox: answers to popular questions
- WP7 working with Images: Content vs Resource build action
- WP7 Element Binding samples
- WP7 working with XML: reading, filtering and databinding
- Drawing in WP7: #2 Drawing shapes with finger
- WP7 TextBox Light theme problems - the solution
- Changing the WP7 Panorama Background Image dynamically with Animation
