Andy On WPF, Windows 8 and Beyond

Bridging the Data Divide–An Introduction to Cocoon Data Lists

2012-01-17T21:33:00.000Z

When I first introduced the Cocoon framework one of the targets was to improve the ease at which data retrieval APIs (primarily web APIs) could be integrated into modern desktop applications. In this post I will introduce two concepts, the “data list” and the “data list source”, that are used in the Cocoon framework to simplify this process when writing Windows 8 Metro-style applications, in particular those implementing the MVVM design pattern.

The Data Divide

Let us first consider a typical web API that will return a list of information in response to a web request from a desktop application. In many cases there may be a large number of items in the list, so the API will split the results into several “pages”. For example, the hypothetical web call,

public Task<PersonResult> GetEmployeesAsync(int pageNumber) {...}

Might return the resulting data for pageNumber=1,

<PersonResult TotalCount="450" Page="1" PageSize="50">

    <Person Name="Bob"/>

    <Person Name="Dave"/>

    <Person Name="Amy"/>

...

</PersonResult>

Here, whilst there are a total of 450 items in the data set, only the first 50 are returned. If you then require any further items then additional calls must be made for the second, third, etc. pages as required.

In contrast let us consider a modern Windows 8 Metro-style UI. Here the user generally expects to see a single list of all items that can be scrolled through as desired. For performance reasons this list should take advantage of data virtualisation to retrieve data on demand, filling in the UI smoothly as the results are retrieved (see my last post on VirtualizingVector for more information).

It is this “data divide” between the state-less paged result sets of web APIs and the fluid continuous lists of desktop applications that often require much code to implement correctly. This is the problem that “data lists” and “data list sources” in the Cocoon framework are desired to solve.

“Data Lists” and “Data List Sources”

The approach taken by the Cocoon framework is to separate the two concerns of the web API calls (or any other data access call) and the resulting lists to display in the UI into separate components. These can then be developed separately using their own conventions, with the Cocoon framework bridging the divide.

In this model a web API call (or calls) that return information on a list of information is represented as part of a “data list source”. This understands how to query the source API to retrieve the list of data as required. In addition it is your application’s own representation of what it knows about the list of data – the length of the data set, and any items that have already been downloaded. This can be reused amongst different parts of your application and in some ways acts as a local cache of the data. Multiple data list sources will be available, for simple cases where all data is returned at once and for data that is returned by pages, as well as the option for custom implementations.

At the other end of the chain is the “data list”. This is the IList<T> implementation that is bound to the UI, either via the code behind or through a view model. Multiple data lists can be attached to the same data list source so that the application’s view of the data is consistent. Different data list implementations can determine how the data is retrieved for display; for example,

StaticDataList – This will retrieve all the information before display to the user
VirtualizingDataList – This will use data virtualization to only retrieve the data items that are currently visible to the user
IncrementalLoadingDataList – This will initially show a fixed number of items, but allow the user to expand the list if they wish to see more items
DynamicDataList – This will start with an empty list, with items being added as they are retrieved from the data list source

Between the data list and the data list source are a number of optional processing steps. For example these could constrain the list to only the first 50 items for preview, they could filter the items based on a search term, or could group the items to display as part of a grouped grid view.

The IDataListSource Interface

All of the above is orchestrated by the Cocoon.Data.IDataListSource<T> interface.

public interface IDataListSource<T>

    Task<int> GetCountAsync();

    Task<T> GetItemAsync(int index);

You can think of this as an asynchronous version of IList<T>, albeit a minimal version. There are two methods:

GetCountAsync() – Returns a task that results in the number of items in the list.

GetItemAsync(int index) – Returns a task that results in the item at the specified index.

Note that the GetItemAsync(…) method should throw an exception if ‘index’ is less than zero, however if ‘index’ is greater than the last item it should return default(T) (for reference types this will be null).

Summary

To summarize, the Cocoon framework supplies an infrastructure designed to bridge the gap between state-less web APIs and modern fluid Windows 8 Metro style applications. Over the next few blog posts (and associated code drops) I will provide a number of generic implementations of data lists and data list sources to make consuming lists of data from the web quick and easy.

Data Virtualization in Metro-style apps with IVirtualizingVector

2011-12-14T22:25:00.001Z

In my last post I introduced an implementation of the IObservableVector<T> interface that allows Windows 8 Metro-style applications to automatically update data bound XAML items controls as the underlying data source changes. In this post I am going to delve one stage deeper by demonstrating an implementation of the IVirtualizingVector interface that enables data virtualization

A Background to Data Virtualization

To start I will provide some background to data virtualization and explain why this is becoming essential for modern applications to improve performance with large data sets. In a traditional, non-data-virtualized application, lists of data must be fully loaded into memory before they can be displayed to the user. When this data is held in a local database or file system this may mean loading many hundred items into memory before being shown in the user interface. With modern cloud-connected applications this becomes more of an issue as they must all be downloaded across what is a relatively slow connection.
In web applications this problem has been solved by the concept of paging – only a small number of items are shown at any one time, and the user can move between the pages by following links. In client based applications however the user expects a more seamless experience – a single list that can be scrolled through as desired.
Data virtualization solves this problem by only downloading and storing in memory the data that is required, deferring the download of further items until they are scrolled into view. The user sees a single list as if they are viewing the total data set, however as they move through the list any newly visible items are obtained on demand.

Data Virtualization for Metro-Style Apps

In Windows 8, Metro style applications support virtualized lists through the IVirtualizingVector interface,

public interface IVirtualizingVector : IObservableVector<object>, IList<object>, IEnumerable<object>

    bool IsPlaceholder(object item);

At first sight it is not immediately obvious how this can be used to virtualize a list, however it provides the vital link between a virtualization aware data set and a data bound user interface. An IVirtualizingVector implementation is responsible for providing any data virtualization logic,

In general the list should behave as you would expect for an IObservableVector<T> implementation
When the items are requested the list should return the actual item if this is available, or a placeholder item if it has yet to be downloaded
The IsPlaceholder(…) method may then be called with each item returned in the list, and the IVirtualizingVector implementation should return true if this is a placeholder item, otherwise false
It is also the responsibility of the IVirtualizingVector implementation to download any requested items in the background and update the list as these are available.

In return the standard Metro-style items controls will show any items for which IsPlaceholder(…) returns true as a grey rectangle,

An IVirtualizingVector Implementation

To assist with data virtualization in .Net based Metro-style applications a base implementation is provided as part of the freely available Cocoon framework. This is provided as the Cocoon.Data.VirtualizingVector abstract class, into which you simply provide your custom data retrieval logic. You will either be requested for the number of items in the list or a specific item, and once obtained should then call the UpdateCount(…) or UpdateItem(…) methods

public class PersonCollection : VirtualizingVector

    protected override void FetchCount()

        // Perform custom code here to retrieve

        //     the number of items in the dataset

        UpdateCount(itemCount);

    protected override void FetchItem(int index)

        // Perform custom code here to retrieve

        //     the specified item from the dataset

         UpdateItem(index, retrievedItem);

The VirtualizingVector class then takes care of implementing IVirtualizingVector, returning of suitable placeholder objects for items as they are requested, and updating items with real data as it is made available.

Of course this approach would still consume large amounts of memory when displaying a list with a large number of placeholder items. The VirtualizingVector class overcomes this by using the provided VirtualizingList<T> implementation. Without going into detail, this behaves as you would expect for a list with a large number of elements, whilst allocating memory efficiently to store only those items that are not virtualized.

Summary

In conclusion, the Cocoon framework provides an IVirtualizingVector implementation designed to enable data virtualization for Metro-style applications. The code is freely available for download from the Cocoon CodePlex site (to get the latest version go to the “Source Code” tab, select the first change set and use the “Download” link).
In my introduction to the Cocoon framework I stated that one of my aims was to bridge the divide between the stateless paging model of most web APIs and the “fast and fluid” interfaces of Metro-style applications. Now that I have provided the fundamentals, next time I will try to bridge this gap by introducing “data lists” and “data list sources”.

ObservableVector as a replacement for ObservableCollection in Metro-style apps

2011-12-01T19:50:00.001Z

For those of you who have had previous experience in making WPF and Silverlight applications you are probably familiar with the ObservableCollection<T> class. This represents a list of items (implementing IList<T>) whilst also raising the INotifyCollectionChanged.CollectionChanged event whenever items are added, removed or moved within the collection. When such collections are databound to the various list controls in WPF and Silverlight the UI will automatically update to reflect any changes.

ObservableCollection<T> and Metro-Style Apps

If you have followed the same technique when writing Windows 8 Metro-style apps you will have found that this no longer works. There are a couple of reasons for this behaviour,

In the Developer Preview version of Windows 8 the INotifyPropertyChanged interface is duplicated in both the System.ComponentModel and Windows.UI.Xaml.Data namespaces. Whilst ObservableCollection<T> implements the former, the new Metro XAML framework uses the latter.
Rather than INotifyCollectionChanged as implemented by ObservableCollection<T>, WinRT uses the IObservableVector<T> interface.

Observable Collections in Metro-Style Apps

Whilst this issue is likely to be addressed prior to release of Windows 8, for the time being there are a few workarounds.

The Windows 8 SDK Data Binding sample includes an ObservableVector class that takes an existing object that implements INotifyCollectionChanged, and wraps it in an IObservableVector<T> implementation.
Colin Eberhardt has posted a similar solution on his blog.
Avi Pilosof has taken a slightly different approach by deriving a new class from ObservableCollection<T>, implementing both INotifyCollectionChanged and IObservableVector<T>.

Whilst these solve the problem, they all involve wrapping the existing ObservableCollection<T> class, resulting in events being raised for both the old and new approaches. This is ideal for cases where you wish to write interoperable code for both existing and Metro applications, but is an added overhead when you are natively writing a new Windows 8 application.

A Metro-Designed Observable Collection Class

In response to this I have written a ground-up ObservableVector<T> class for use in Windows 8 Metro-style applications that does not have the overhead of an underlying ObservableCollection<T>. The code has been released as part of the freely available Cocoon framework. You can use this class by creating a new instance directly,

IList<Person> list = new ObservableVector<Person>();

list.Add(new Person("Andrew", "Wilkinson"));

or by deriving a custom class,

public class PersonCollection : ObservableVector<Person>

...

It is important to note however that in the current Windows Developer Preview there is a bug which means that databinding only works correctly to lists when the implement ObservableVector<object> rather than strongly typed collections. This is likely to change in the future.

In both cases the behaviour is designed to match that expected by WPF and Silverlight developers. There are a small number of subtle differences with respect to the previous ObservableCollection<T> class,

Since IObservableVector<T> does not have the same concept of moving items it does not implement the Move() method. Instead you should remove the item and then add it to its new place in the collection.

The constructor of the ObservableVector<T> class optionally accepts an IList<T> that is wrapped by the implementation rather than copied internally – the reason for this will become apparent in later posts.

Currently no attempts are made to stop VectorChanged event handlers from modifying the original collection.

Summary

In conclusion, the Cocoon framework provides an IObservableVector<T> implementation specifically designed from the ground-up for Metro applications. The code is freely available for download from the Cocoon CodePlex site (to get the latest version go to the “Source Code” tab, select the first change set and use the “Download” link).

Next time I will discuss data virtualisation and the IVirtualizingVector interface.

Cocoon – A new framework for Windows 8 Development

2011-11-27T20:07:00.001Z

Regular followers of my blog will know that over the last year I have been discussing a framework that I introduced for Windows Phone 7 development named Chrysalis (http://chrysalis.codeplex.com/). Whilst not a Model-View-ViewModel (MVVM) framework itself, allowing the use of your preferred framework for this purpose, it was designed to enable view models to interact with the phone lifecycle and hardware in a simple and natural manner.

Following the announcement of the Windows 8 Metro-style application programming model at Microsoft’s //build conference, it became clear that many of the same challenges would present themselves for Windows 8 applications.

The Cocoon Framework

To assist with Windows 8 Metro-style applications I would like to announce the Cocoon framework (http://cocoon.codeplex.com/). This aims to build on top of the learning from the Chrysalis project to provide a simple way to develop Metro-style applications in a manner that fits naturally with the MVVM design pattern.

It is likely that many Metro-style apps will be connected applications, downloading data from across the internet in response to user navigation. Modern applications are expected to do this in a seamless manner, retrieving data on demand and populating the user interface in response. In some ways this is at odds with the web API programming model that is based upon individual request-response calls, with paging used to retrieve large datasets. One of the first targets of the Cocoon framework is to simplify this process – bridging the world of stateless web API calls, with the “fast and fluid” interfaces expected by users.

Cocoon Framework Development

Since Windows 8 is currently at an early stage, it is anticipated that the Cocoon framework will evolve alongside further releases. If functionality is introduced in the platform that duplicates that within the Cocoon framework, efforts will be made to migrate to the platform support whenever possible.

It is an exciting time for Windows developers, with the upcoming release of Windows 8 ushering in a new ecosystem of applications. The Cocoon framework will allow you to focus on your individual business logic, whilst ensuring that the user experience fully supports the richness of the platform.

Summary

To conclude, the first source-code drops of the Cocoon framework are freely available on CodePlex (http://cocoon.codeplex.com/). As the project evolves, new functionality will be explained on this blog so stay tuned.

Chrysalis – Injection of Application Services and State

2011-10-25T22:05:00.001+01:00

In my last post I introduced the concept of application and session state within a Windows Phone 7 application, and described how the Chrysalis framework makes it easy to share state between multiple pages (and hence view models) within an application, including full tombstoning support. As usual, all the source code is available on the Chrysalis CodePlex site under the “Source Code” tab.

Application Services

To recap, Chrysalis allows multiple view models to share the same state between multiple pages by using one of the two ChrysalisService.GetService methods,

   1: public class ChrysalisService

   2: {

   3:      ...

4:

   5:      public T GetService<T>() { ... }

   6:      public object GetService(Type serviceType) { ... }

7:

   8:      ...

   9: }

The first time one of these methods is called, a new instance of the specified type is created (calling the default parameter-less constructor). Any subsequent calls will return the same “singleton” instance. As the method names allude to, this can be used not only for general state, but for any services that may wish to be shared throughout the application.

Furthermore, Chrysalis makes it simple for these services to persist state when the application is tombstoned. All that is required is for the service to implement the IHasSessionState interface,

   1: public interface IHasSessionState

   2: {

   3:     // *** Methods ***

4:

   5:     void Initialize(object state);

   6:     object SaveState();

   7: }

The first time the service is created within a session the Initialize method is called with the state parameter set to null. In this instance default values can be set along with any other initialization required by the service. Upon tombstoning the SaveState method is called from which you can return any state you wish to persist. Upon reactivation this state is passed back to the newly created instance of the service (remember – during tombstoning the application process is killed and all objects are lost) via the Initialize method.

Chrysalis and Dependency Injection

Whilst the ChrysalisService class provides the GetService methods, this is only one way in which your view models can obtain such state information. Another method is “dependency injection”. This refers to a situation where external dependencies (in our case the state objects) are injected into our view model, rather than the view model itself having to seek them out.

In Chrysalis this is done by defining public properties for each of the services that we wish to inject into the view model. To indicate that these should be injected we add the [ChrysalisImport] attribute to the property. Finally, in the constructor we check whether Chrysalis is initialised and tell the ChrysalisService to satisfy any imports by calling the SatifyImports(…) method.

For example within the sample CalculatorViewModel included with the source download,

   1: public class CalculatorViewModel : ViewModelBase, IHasSessionState

   2: {

   3:     // *** Constructors ***

4:

   5:     public CalculatorViewModel()

   6:     {

   7:         if (ChrysalisService.Current != null)

   8:             ChrysalisService.Current.SatisfyImports(this);

   9:     }

10:

  11:     // *** Properties ***

12:

  13:     ...

14:

  15:     [ChrysalisImport]

  16:     public CalculatorSessionState SessionState

  17:     {

  18:         get;

  19:         set;

  20:     }

21:

  22:     ...

  23: }

This defines a property called SessionState that is marked with the [ChrysalisImport] attribute. In the constructor we notify Chrysalis that it should inject any dependencies, which when it returns will have set the property to an instance of CalculatorSessionState. As with the GetService calls this will return the same instance across all view models, creating a new object only if this is the first such reference. Note that you can define any number of properties to be injected and they will all be satisfied by the one SatisfyImports(…) call.

Using Interfaces for Dependency Injection

Whilst being able to declaratively inject singleton instances of classes is useful, there are a number of reasons that you would wish to decouple such properties from the concrete implementations – for example to inject mock implementations for testing purposes. This is usually done by specifying an interface rather than a class type, and this too is enabled in the Chrysalis framework.

For example in the ChoosersViewModel sample included in the source code,

   1: [ChrysalisImport]

   2: public IChooserExecutionService ChooserExecutionService

   3: {

   4:     get;

   5:     set;

   6: }

However, we now need a way to link the interface to the concrete implementation. In the Chrysalis framework this is done by simply attributing the interface with the ExportImplementationAttribute specifying the concrete type to use.

   1: [ExportImplementationAttribute(typeof(ChooserExecutionService))]

   2: public interface IChooserExecutionService

   3: {

   4:     ...

   5: }

Comparing Chrysalis with Other Dependency Injection Frameworks

Before I conclude I would like to take a moment to contrast dependency injection in the Chrysalis framework to other implementations. Dependency injection within Chrysalis was designed to support the very basic injection of services (to enable unit testing, etc.) and integration with the rest of the Chrysalis model – this it performs well. If you require more advanced services then it is recommended that you use a full dependency injection container implementation.

Chrysalis – Application and Session State

2010-12-14T21:55:00.001Z

In my last few posts I have focused on the tombstoning features of the Chrysalis Windows Phone 7 application framework. In this post I will look at the related role of application and session state, and how these can ensure that data is persisted during tombstoning using the Chrysalis framework. As usual, all the source code is available on the Chrysalis CodePlex site under the “Source Code” tab.

Application and Session State

All examples of state I have discussed so far have been associated with a single page of a Windows Phone 7 application (view state), ensuring that any data entered is persisted during navigation and application tombstoning. In real applications much of the data crosses across multiple pages, and hence multiple views and view models. Application data is data that stores settings and information that is reused between multiple application instances. This includes user settings, user details as well as any downloaded data that rarely changes. Session data on the other hand is data that crosses multiple pages of an application, but is not reused between application instances, such as session keys for web services or some transient state.

When, and how the data is different for each of these types of state,

View state – Persisted on navigation to/from the page to the page state bag.
Application state – Persisted and restored upon application shutdown/startup and also during tombstoning using isolated storage.
Session state – Persisted during tombstoning to the application state bag.

Storing Application and Session State with Chrysalis

When working with data that crosses several pages (and therefore view models) we need a way to ensure that we can store and access the same data from each page. In the ‘Calculator’ sample provided with Chrysalis, this data is stored in the CalculatorSessionState object,

   1: public class CalculatorSessionState

   2: {

   3:     // *** Properties ***

4:

   5:     public string Operator { get; set; }

6:

   7:     ...

   8: }

This simply stores the current operator (+, –, / or *) that the calculator is using as a string. This is also displayed on the Calculator information page, and is true session state in that navigation back from the calculator page, and then returning will persist the value chosen.

Since we need to access the state from both the CalculatorViewModel and the CalculatorInformationViewModel, we need to be able to create a single instance of this state to share across both of these locations. Chrysalis provides a simple and straightforward way of creating such “singleton” objects by calling one of the ChrysalisService.GetService methods,

   1: public class ChrysalisService

   2: {

   3:     ...

4:

   5:     public T GetService<T>() { ... }

   6:     public object GetService(Type serviceType) { ... }

7:

   8:     ...

   9: }

This method will return a single instance of the requested type, initializing a new instance if this is the first such request (note that this will call, and requires, a public parameter-less constructor). Now we can call this method in the constructors of the CalculatorViewModel and the CalculatorInformationViewModel and be sure that we have the same instance in each case.

Supporting Tombstoning

So far I have shown how to share state between pages, but what happens when the application is tombstoned (see here if you wish to refresh yourself on what this means)? Since the process is killed, any state will be lost. On restart we have an entirely new process so Chrysalis will create a new instance with default values.

To provide a seamless user experience, we should persist any session state and restore it when the application is reactivated. Chrysalis makes this easy. All you have to do is to ensure that your state object implements the IHasSessionState interface. For example, the full code for CalculatorSessionState is,

   1: public class CalculatorSessionState : IHasSessionState

   2: {

   3:     // *** Properties ***

4:

   5:     public string Operator { get; set; }

6:

   7:     // *** IHasSessionState Methods ***

8:

   9:     void IHasSessionState.Initialize(object state)

  10:     {

  11:         SessionState sessionState = state as SessionState;

12:

  13:         if (sessionState == null)

  14:             Operator = "+";

  15:         else

  16:             Operator = sessionState.Operator;

  17:     }

18:

  19:     object IHasSessionState.SaveState()

  20:     {

  21:         return new SessionState()

  22:             {

  23:                 Operator = this.Operator

  24:             };

  25:     }

26:

  27:     // *** Sub-classes ***

28:

  29:     public class SessionState

  30:     {

  31:         public string Operator { get; set; }

  32:     }

  33: }

Now when the class is first initialised, Chrysalis will call the IHasSessionState.Initialize method. If the application has just been launched the ‘state’ parameter will be null and we can initialise with default values. When the application is subsequently tombstoned Chrysalis will call the IHasSessionState.SaveState method, from which we can return some state to persist until later reactivated. When this does occur a new instance of CalculatorSessionState is created, but this time our previously returned state is supplied as the parameter which we can restore.

Summary

We have now seen how Chrysalis can easily allow you to share session state between pages. By using the Chrysalis tombstoning support on the view model and the IHasSessionState interface on any shared state, we should no longer worry about what will happen if our application is tombstoned. Chrysalis will ensure that any state is restored to that before we were tombstoned, and your users will have a seamless experience.

Once again, you can download a zip file of the entire source code for Chrysalis and the associated sample application from the “Source Code” tab at the Chrysalis CodePlex site.

Chrysalis – Tombstoning support (Part II - Implementation Details)

2010-11-21T21:04:00.001Z

In my last post I introduced the tombstoning features of the Chrysalis Windows Phone 7 application framework. To summarise, this allowed developers using the Model-View-ViewModel presentation pattern to easily ensure that their ViewModels could maintain their state during tombstoning. In this post I will provide an overview of how Chrysalis implements this feature. As usual, all the source code is available on the Chrysalis CodePlex site under the “Source Code” tab.

The Chrysalis Service

One of the first steps when using the Chrysalis framework is to register the ChrysalisService in the App.xaml file’s ApplicationLifetimeObjects section (see my last post for details). This takes advantage of Silverlight’s application extension services (see MSDN) which allow you to register services that run at start-up of the application. The advantage of this approach is that once registered, the rest of the application can take advantage of the features of ChrysalisService without having to use any custom base classes of pages, View Models, etc.

The bulk of the initialization of the ChrysalisService happens within the StartService method, which Siliverlight calls during application start-up.

   1: void IApplicationService.StartService(ApplicationServiceContext context)

   2: {

   3:     // Set this as the current ServiceManager via the static property

4:

   5:     ChrysalisService.Current = this;

6:

   7:     // Attach to the PhoneApplicationService lifetime events

8:

   9:     PhoneApplicationService phoneApplicationService = PhoneApplicationService.Current;

10:

  11:     phoneApplicationService.Activated += new EventHandler<ActivatedEventArgs>(PhoneApplicationService_Activated);

  12:     phoneApplicationService.Deactivated += new EventHandler<DeactivatedEventArgs>(PhoneApplicationService_Deactivated);

  13:     phoneApplicationService.Closing += new EventHandler<ClosingEventArgs>(PhoneApplicationService_Closing);

14:

  15:     // Attach to the page navigation events

  16:     // NB: We set off a DispatcherTimer since we need to wait for the RootVisual property to be set before we can access this

17:

  18:     ExecuteViaDispatcherTimer(() =>

  19:         {

  20:             if (Application.Current.RootVisual != null)

  21:                 PhoneApplicationFrame_RootVisualLoaded((PhoneApplicationFrame)Application.Current.RootVisual);

  22:         });

  23: }

Firstly we store a static reference to our service so that we can find it at any other point within the application execution. After this we get the current PhoneApplicationService (added by default to all Silverlight Windows Phone 7 applications). Since Silverlight will initialize all application services in the order we have specified in the App.xaml file, this will already have been initialized. We then attach to the Activated, Deactivated and Closing events. Note that we do not need to attach to the Launching event since we can identify this if our service has been initialized without the Activated event.

The next step is to attach to navigation events to and from pages within the application. Normally you would do this by using the NavigationService class accessible from the current page, but since at this point of application execution no page is present (and hence the application’s RootVisual property is null) we have no way to access this. The ChrysalisService class overcomes this problem by queuing a request using a DispatcherTimer with a delay of 0ms. Although this sounds like it should execute immediately, the contract for the DispatcherTimer merely states that it should call the callback at least the specified time after starting. In fact this is queued up when the dispatcher next becomes free, conveniently after the RootVisual has been initialized.

   1: private void PhoneApplicationFrame_RootVisualLoaded(PhoneApplicationFrame frame)

   2: {

   3:     // Attach to the navigation events

4:

   5:     frame.Navigating += new NavigatingCancelEventHandler(NavigationService_Navigating);

   6:     frame.Navigated += new NavigatedEventHandler(NavigationService_Navigated);

7:

   8:     // Set the current page

9:

  10:     CurrentPage = frame.Content as PhoneApplicationPage;

11:

  12:     ...

  13: }

We can then use the RootVisual (which we know for Windows Phone 7 Silverlight applications will be a PhoneApplicationFrame) to attach to the Navigating and Navigated events. We also store a reference to the current page for future use, which is also updated on any successful navigation events.

Notifying the ViewModel of application events

Now the ChrysalisService is able to identify all the application events of interest, we need a way to pass this to the current ViewModel. This is done via the two interfaces, IPhoneLifetimeAware and IPhoneNavigationAware.

   1: public interface IPhoneLifetimeAware

   2: {

   3:     void Activated();

   4:     void Closed();

   5:     void Deactivated();

   6:     void Launched();

   7: }

   1: public interface IPhoneNavigationAware

   2: {

   3:     void NavigatingFrom(NavigatingCancelEventArgs e);

   4:     void NavigatedTo(NavigationEventArgs e);

   5: }

Since we are tracking the current page at any point of time, we can identify the ViewModel associated with it by using the DataContext of that page. If the returned object implements either of the above interfaces then we can call the relevant methods in response to application events.

Storing application page state

We have not yet addressed the main use of this feature, for storing state relevant to the ViewModel during tombstoning. This is done via a third interface that the ViewModel can implement (as is done by the provided ViewModelBase class), IHasSessionState.

   1: public interface IHasSessionState

   2: {

   3:     void Initialize(object state);

   4:     object SaveState();

   5: }

The SaveState() method is called by ChrysalisService whenever the application is Deactivated or when navigation occurs away from the respective page. From this method the ViewModel can return some state that will be automatically persisted during tombstoning.

Similarly, the Initialize(…) method is called by ChrysalisService whenever the application is Activated or when navigation occurs to the respective page. The ViewModel can then reinstate any state required to recreate the page prior to tombstoning.

Summary

I have now described how the Chrysalis application framework allows developers to easily manage any state relating to individual ViewModels (and therefore to individual pages of an application). In my next post I will describe how Chrysalis allows applications to store application state that may span several pages, and how this can easily be persisted between tombstoning and application restarts as is required.

Chrysalis – Tombstoning support (Part I - Introduction)

2010-09-24T20:36:00.001+01:00

As I discussed in my previous post, when you are writing Silverlight (or XNA) based Windows Phone 7 applications, one of the considerations you must make is regarding supporting the “tombstoning” of your application. At any point during its execution your application may receive notification that you must save any state and exit, to possibly (but not always) be restarted at a later point. This however is you application’s view – to the user they must believe that you application was waiting patiently in the background, unaware of the tearing down and restarting that is actually occurring.

If you are following the Model-View-ViewModel presentation pattern then the best placed entity in the system to know about what state to persist when tombstoning is the ViewModel. You have to firstly ensure that the application subscribes correctly to the PhoneApplicationService.Deactivated and PhoneApplicationService.Activated events. These must pass the requests onto the ViewModel which must store its state in the correct locations. Upon reactivation the ViewModel must know that it has some stored state, retrieve it and then restore the UI to that before the deactivation.

Transparently handling these steps is one of the key features of the Chrysalis framework.

How to use Chrysalis for Tombstoning?

Supplied with yesterdays drop of the Chrysalis framework is a sample calculator application. Whilst not particularly useful, it is intended to show how Chrysalis simplifies tombstoning. At its heart is the CalculatorViewModel.

   1: public class CalculatorViewModel : ViewModelBase

   2: {

   3:     // *** Fields ***

4:

   5:     private int numberX = 10;

   6:     private int numberY = 5;

7:

   8:     // *** Properties ***

9:

  10:     public int NumberX

  11:     {

  12:         get

  13:         {

  14:             return numberX;

  15:         }

  16:         set

  17:         {

  18:             numberX = value;

  19:             OnPropertyChanged("NumberX");

  20:             OnPropertyChanged("Total");

  21:         }

  22:     }

23:

  24:     public int NumberY

  25:     {

  26:         get

  27:         {

  28:             return numberY;

  29:         }

  30:         set

  31:         {

  32:             numberY = value;

  33:             OnPropertyChanged("NumberY");

  34:             OnPropertyChanged("Total");

  35:         }

  36:     }

37:

  38:     public int Total

  39:     {

  40:         get

  41:         {

  42:             return NumberX + NumberY;

  43:         }

  44:     }

  45: }

This derives from Chrysalis.ViewModelBase base class and includes three properties. The properties ‘NumberX’ and ‘NumberY’ are editable and both bound to TextBoxes in the associated UI (CalculatorView.xaml). The ‘Total’ property simply returns the sum of the two other values and is bound to a read-only TextBox in the UI. Property changed notifications are raised by calling OnPropertyChanged(…) on the base class.

At this stage everything will look familiar to the Silverlight or WPF developer, and the application will run as expected,

The problem occurs if we now deactivate and reactivate the application. In the emulator provided with the developer tools you can do this by clicking the “Start” button to return to the start page, then clicking “Back” to return to your application. This will result in all values being reset to their initial values as we are not persisting any state. Remember though that the user should believe that the application has been sitting patiently in the background, and expects all the values to be consistent with that.

To solve this problem Chrysalis.ViewModelBase provides a couple of virtual methods that you can override.

protected virtual object SaveState() {...}

protected virtual void RestoreState(object state) {...}

The SaveState() method is called when your application is being deactivated and can return some state to be persisted. The RestoreState(…) method is called when your application is being activated and returns the state so that you can restore the property values, and hence the UI.

Also, to enable the Chrysalis support we need to add a couple of lines to the App.xaml. Firstly an ‘xmlns’ definition at the top of the file to reference the Chrysalis.Services namespace, and the <csv:ChrysalisService/> item in the ApplicationLifettimeObjects section. Appart from those changes (shown in the code below) ,the rest of the App.xaml file can be left as is.

   1: <Application

   2:     ...

   3:     xmlns:csv="clr-namespace:Chrysalis.Services;assembly=Chrysalis">

4:

   5:     <Application.ApplicationLifetimeObjects>

   6:         ...

   7:         <csv:ChrysalisService/>

   8:     </Application.ApplicationLifetimeObjects>

9:

  10: </Application>

For our calculator sample we do this with a class ‘CalculatorViewModelState’. Note: This class must be declared with public scope. Since this will be serialized transparently by the phone for the duration of deactivation, we need it to be public otherwise we will receive a SecurityException when the phone tries to deserialize it.

   1: // *** Overriden Base Methods ***

2:

   3: protected override object SaveState()

   4: {

   5:     return new CalculatorViewModelState()

   6:     {

   7:         NumberX = numberX,

   8:         NumberY = numberY

   9:     };

  10: }

11:

  12: protected override void RestoreState(object state)

  13: {

  14:     CalculatorViewModelState vmState = (CalculatorViewModelState)state;

15:

  16:     if (vmState != null)

  17:     {

  18:         NumberX = vmState.NumberX;

  19:         NumberY = vmState.NumberY;

  20:     }

  21: }

22:

  23: // *** Sub-classes ***

24:

  25: public class CalculatorViewModelState

  26: {

  27:     public int NumberX { get; set; }

  28:     public int NumberY { get; set; }

  29: }

We simply set the properties and return the state within the SaveState() method, and restore the values in the RestoreState(…) method. If you now try to tombstone the application, the state will be persisted on exit, and on returning the UI will look and perform identically to how it did prior to deactivation.

Success!

Navigation and Storing State

You may notice that in the sample application we have a button that takes us to a second page of the application – CalculatorInformationPage.xaml. We should also be able to restore any application state if we navigate to this page, tombstone, return to the application, and navigate back to the calculator page.

No need to worry though, since the Chrysalis framework ensures that this occurs transparently without having to write any further code. This works by calling SaveState()/RestoreTo(..) when a user navigates away from and back to the page, and handling the persistence of the state as required.

Summary

As you will have seen, the Chrysalis framework allows Silverlight developers using the MVVM pattern to simplify the persistence of state during tombstoning on their applications. By simply overriding two methods, the ViewModel itself can specify what state to persist, and the framework handles all the plumbing required to store and retrieve this.

In my next posts I will be discussing how this all works under the covers and when you should be returning state vs when you should be using isolated storage. After that, I will be releasing and describing the next feature currently being added to Chrysalis related to choosers.

Update 17/10/2010: With the latest version RestoreState(…) should check for a null state & MainViewModel is refactored to CalculatorViewModel.

Introducing Chrysalis

2010-09-24T16:53:00.001+01:00

In this post I am going to introduce the new Chrysalis framework available now from CodePlex at http://chrysalis.codeplex.com. Chrysalis is in an open source framework designed to simplify the development of Silverlight based Windows Phone 7 applications. Whilst it is primarily focused on Model-View-ViewModel (MVVM) related presentation patterns, it can be applied to other designs.

Many times it has been commented that if you are a Silverlight developer (and to some extent a WPF developer), then you now have the skills to write Windows Phone 7 applications. And this is almost true – with the introduction of Windows Phone 7 you can now write Silverlight applications that run on the phone as native apps (with XNA the other option for more graphically rich apps). But at the same time there are a number of new concepts that you will need to consider to write high quality software that runs within the constraints of a mobile device.

Tombstoning

The first consideration that everyone who works with Windows Phone 7 (both in Silverlight and XNA) should be aware of is the interestingly named “tombstoning”. The MSDN documentation has an excellent section on the “Execution Model Overview for Windows Phone” so I will not go into this in detail. In summary, you have to be aware that your application may be exited automatically at any point during its execution (for example when a phone call comes in) – not pushed to the background, but killed outright. At some later point you application may be reactivated, and it is you job as a developer to ensure that all application state is restored. The end user should believe that the app was sat there in the background all the time, even though you know that it was killed and restarted.

The Windows Phone 7 framework will warn you that you application is being deactivated with the PhoneApplicationService.Deactivated event. This is your opportunity to save any state required, either to one of a couple of state bags, or to isolated storage. When the application is restarted then you will receive the PhoneApplicationService.Activated event, and you can restore the UI to its former state.

In reality there is a lot to think about. Firstly you have to ensure that if you are using MVVM then your ViewModels receive the activation and deactivation events. This is complicated by the fact that the PhoneApplicationService.Activated event is often fired before your ViewModel is even created. In addition there is a lot of control state that may need to be maintained – currently focused control, position of scroll bars, etc.

Chrysalis aims to greatly simplify this process.

Choosers

In Windows Phone 7 there are a number of points at which you may need to interact with the built in phone UI, for example to take a photo with the camera, or to retrieve contact information. This is done using “Choosers” (MSDN article).

When you show a chooser we once again experience tombstoning. For the duration of the user interacting with the phone UI, our application is exited, to be restarted later when the interaction has completed. Not only do we now need to restore any state within the application, we must remember that we were calling into a chooser and what we were intending to do with the result – for example if we have multiple sets of contact information on the screen, which were we updating?

Chrysalis aims to allow you to specify a callback within your ViewModel that will receive the result from the chooser. Combined with the tombstoning support, your application should be barely aware that the application was killed and restarted. Instead the chooser will look like any other method call and callback.

Access to Hardware

Although the programming model for Windows Phone 7 is entirely managed code, there are two “flavours” of application – Silverlight and XNA. In several cases features exist within XNA, but not within Silverlight. Whilst these can be accessed by simply adding the XNA assembly references, the APIs sometimes require a different mindset.

Chrysalis aims to provide wrappers where required to make connecting to the hardware available through the XNA framework as simple as using any of the native Silverlight controls.

Summary

To conclude, the Chrysalis framework is now available at http://chrysalis.codeplex.com. While this is only a first release I encourage you to take a look at the basis provided and keep an eye on this blog as I will describe the usage and implementation of new features as they are introduced.

And please provide feedback on existing or new features, either through this blog, or on CodePlex.

How small can you go? - Part III

2007-04-15T21:16:00.000+01:00

In part one of this series of posts ("How small can you go?" 22 Jan 2007) I described how you could design a Windows Presentation Foundation (WPF) control that altered the visibility of specific areas of a UI when then containing window was resized. Compare this to the behaviour of the Office 2007 ribbon, which will hide itself to show more of the edited document when the window is below a certain size. In part II ("How small can you go? - Part II" 15 Feb 2007) I detailed an alternative approach that allowed a trigger to be used when any bindable property (e.g. the width of a window) was below a certain size. In this post I will complete the implementation.

To summarise part II, we implemented an IValueConverter that would return a boolean value indicating whether a specified binding was less than a certain value. This could be used as follows,

<... .Resources>
<cvt:LessThanConverter x:Key="LessThanConverter"/>
</... .Resources>

<DataTrigger Value="True" Binding="{Binding RelativeSource={RelativeSource Self}, Path=ActualWidth, Converter={StaticResource lessThanConverter}, ConverterParameter=200}">
...
</DataTrigger>

While this allowed defining a trigger for when the width was below a specific threshhold, we would have to define the trigger again for the height of the window. What we really need is some way to combine two bindings with a 'logical OR' operation.

Introducing the IMultiValueConverter...

An IMultiValueConverter is similar in principle to an IValueConverter, whereas the latter allows the conversion of a single value into another form (in our case, a double into a bool indicating whether the value is below a threshold), the former will take several values, and combine them into a single output value that is then used as a trigger. We therefore need an IMultiValueConverter that will take a number of booleans and output a single boolean that represents a 'logical OR' of all the input values. We can then use the following XAML,

<... .Resources>
<cvt:LessThanConverter x:Key="lessThanConverter"/>
<cvt:MultiValueOrConverter x:Key="multiValueOrConverter"/>
</... .Resources>

...

<DataTrigger Value="True">
<DataTrigger.Binding>
<MultiBinding Converter="{StaticResource multiValueOrConverter}">
<Binding RelativeSource="{RelativeSource Self}" Path="ActualWidth" Converter="{StaticResource lessThanConverter}" ConverterParameter="200"/>
<Binding RelativeSource="{RelativeSource Self}" Path="ActualHeight" Converter="{StaticResource lessThanConverter}" ConverterParameter="200"/>
</MultiBinding>
</DataTrigger.Binding>
...
</DataTrigger>

This snippet declares two objects, our LessThanConverter from before, and a new MultiValueOrConverter. Following this we have a DataTrigger who's binding is a MultiBinding that takes two bindings that will return true if the width or height is less than 200. By default the MultiBinding will only trigger if all the child bindings are true (a 'logical AND'). We change this behaviour to a 'logical OR' by specifying our multi-value converter. The trigger will now fire if either the element width OR height are less than 200.

The actual code for the multi-value converter is similar in principle to that of a single-value converter. We take an array of input values that we will assume are all boolean values. We then perform a foreach loop over them and if any are true, we return true, otherwise false. Therefore the resulting code is,

using System;
using System.Collections.Generic;
using System.Text;
using System.Windows.Data;
using System.Globalization;

namespace SizingApplication2
{
public class MultiValueOrConverter : IMultiValueConverter
{
public object Convert(object[] values, Type targetType, object parameter, CultureInfo culture)
{
foreach (bool value in values)
{
if (value == true)
return true;
}

return false;
}

public object[] ConvertBack(object value, Type[] targetTypes, object parameter, CultureInfo culture)
{
throw new NotSupportedException();
}

}
}

If we combine this with the XAML snippet above and include a suitable setter to hide the desired parts of the UI, we now have all the behaviour we require. Advantages of this approach include not requiring any extra elements, and being able to adapt the value converters to any situation where the UI changes based upon a certain value (for example, to display a warning message when a slider is moved above a certain value, or even change its colour as a warning).

The full code for this post and an example usage is available here.

It's all in the Blend

2007-03-04T15:35:00.001Z

Recently I've been experimenting with the new software tool Expression Blend. For those of you who do not know, Expression Blend is Microsoft's design tool for XAML and WPF applications and is available as I write in Beta 2 form. It provides a visual design workspace where you can lay out all the elements that make up a UI, and adjust their properties as required.

I have been making extensive use of it to style all the elements in my ribbon UI framework that I am currently developing. For someone who has previously edited the XAML directly it provides a much quicker environment for laying out the UI, with instant feedback on all changes. It also simplifies the introduction of triggers (changes on IsMouseOver, IsPressed, etc.) and animation. As an example, shown below is the application menu button for the ribbon UI. Of course since this is WPF this is all vector based, and smoothly scales up (NB: This screen grab is from an actual live UI - rollover animations, opens a menu when clicked, etc...).

In its current incarnation (beta 2) there are some issues I have had. First of all I have been unable currently to get the whole of my ribbon UI in the designer. To be fair, I haven't really tried fixing this, and it is a large composition of custom controls in a WPF rendered chrome window. It also takes a bit of learning to get used to the way it places elements by default. Of course I never read the help when I started using it which could of helped, and once you understand the basic ideas it is very easy to build up the control structure desired.

My favorite features apart from the ease at which the UI can be styled... One item I'll definitely add here is the gradient eyedropper tool. This is similar to the standard eyedropper, which can pick up individual pixel colours from the screen. However, when the gradient eyedropper tool is dragged across a region of the screen it will automatically pick up entire gradient fills. Great for designing smooth user interfaces. Also I like the simplicity by which you can apply property changes and animation upon events.

Let me know below if anybody else has any experiences of Expression Blend...

Update: After a request for the XAML code I have attached the basic code below (copy and paste into XamlPad to see it). The actual Expression Blend generated XAML is significantly more complex (and much less readable!), and includes all the roll-over behaviour etc.. This is the main reason I chose a designer over hand crafting the XAML. Hopefully the attached code will give you an idea how to approach such designs.

<Page xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:sys="clr-namespace:System;assembly=mscorlib" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" >
  <Page.Resources>
    <Style TargetType="{x:Type Button}" x:Key="RibbonApplicationMenuButton">
      <Setter Property="Width" Value="37"/>
      <Setter Property="Height" Value="37"/>
      <Setter Property="HorizontalContentAlignment" Value="Center"/>
      <Setter Property="VerticalContentAlignment" Value="Center"/>

      <Setter Property="Template">
        <Setter.Value>
          <ControlTemplate TargetType="{x:Type Button}">
            <Grid>
              <Border BorderThickness="0,0,0,0" CornerRadius="100000,100000,100000,100000" Opacity="1" Margin="0,0,-1,-1" x:Name="ShadowBorder" Background="#39000000"/>
                <Border x:Name="OuterBorder" BorderBrush="#FF6E7D95" BorderThickness="1,1,1,1" CornerRadius="100000,100000,100000,100000">
                  <Border ClipToBounds="False" x:Name="InnerBorder" Width="Auto" Height="Auto" BorderBrush="#FFDDE2EC" BorderThickness="1,1,1,1" CornerRadius="10000,10000,10000,10000">
                    <Border.Background>
                      <LinearGradientBrush EndPoint="0.505,0.489" StartPoint="0.512,-0.004">
                        <GradientStop Color="#FFF3F5F8" Offset="0"/>
                        <GradientStop Color="#FFC0CADB" Offset="1"/>
                      </LinearGradientBrush>
                    </Border.Background>
                    <Grid Width="Auto" Height="Auto">
                      <Path RenderTransformOrigin="0.499999990968993,0.0833333333333333" Stretch="Fill" Margin="0,15,0,0" x:Name="path" Width="Auto" Data="F1 M16.5,15.5 C22.163836,15.5 27.559435,15.738094 32.466614,16.168823 L32.5,16.5 C32.5,25.336555 25.336555,32.5 16.5,32.5 7.663444,32.5 0.5,25.336555 0.5000006,16.5 L0.53338605,16.168823 C5.4405661,15.738094 10.836165,15.5 16.5,15.5 z">
                        <Path.Fill>
                          <RadialGradientBrush MappingMode="RelativeToBoundingBox" GradientOrigin="0.5,0.5">
                            <RadialGradientBrush.RelativeTransform>
                              <TransformGroup>
                                <ScaleTransform CenterX="0.5" CenterY="0.5" ScaleX="1.077" ScaleY="1.748"/>
                                <SkewTransform AngleX="0" AngleY="0" CenterX="0.5" CenterY="0.5"/>
                                <RotateTransform Angle="0" CenterX="0.5" CenterY="0.5"/>
                                <TranslateTransform X="-0.002" Y="-0.025"/>
                              </TransformGroup>
                            </RadialGradientBrush.RelativeTransform>
                            <GradientStop Color="#FFFFFFFF" Offset="0.375"/>
                            <GradientStop Color="#FF93A5C2" Offset="1"/>
                            <GradientStop Color="#FFF2F4F7" Offset="0.529"/>
                          </RadialGradientBrush>
                        </Path.Fill>
                      </Path>
                      <ContentPresenter HorizontalAlignment="Center" Margin="0,0,0,0" VerticalAlignment="Center" Width="Auto" Height="Auto"/>
                    </Grid>
                  </Border>
                </Border>
              </Grid>

            </ControlTemplate>
          </Setter.Value>
        </Setter>
      </Style>
    </Page.Resources>

    <Button Style="{StaticResource RibbonApplicationMenuButton}"/>
</Page>

How small can you go? - Part II

2007-02-15T21:40:00.001Z

Updated: 19 March 2007 to resolve some errors

In my last post ("How small can you go?" 22 Jan 2007) I presented a custom control that allowed you to determine if the control was below a specific size, and to alter its visual appearance based upon this. There are many cases however where altering appearance based upon size is important (for example, to make the thumb grips on scrollbars disappear when they become too small), and I felt a more generic method of performing this calculation was required.

Ideally this method would not require a special base class as described in my previous post. It should also be as general as possible, allowing bindings to any available dependency properties.

So let us consider how we currently implement triggers,

<Trigger Property="IsMouseOver" Value="True">
...
</Trigger>

<Trigger Property="Width" Value="150">
...
</Trigger>

The first of these examples makes perfect sense. The IsMouseOver property is either true or false. We apply the default style when it is false, and apply any changes specified within the Trigger when it is true. However, the Width property does not have a small number of distinct values. Whilst the above trigger will apply if the width equals 150, it will not if it is 149,148,147,etc. or 151,152,153,etc. If only we had a less-than trigger...

Now let me introduce the IValueConverter interface. This according to the MSDN documentation "Provides a way to apply custom logic to a binding." Basically it allows you to include some logic that alters the value of the property before the trigger performs its comparison.

For example,

<DataTrigger Value="True" Binding="{Binding RelativeSource={RelativeSource Self}, Path=ActualWidth, Converter={StaticResource addTenConverter}, ConverterParameter=150}">
...
</DataTrigger>

Here we specify a custom converter, whose logic simply adds ten to a value. Therefore if the Width of our element is 140, the binding will first call our converter, which will of course return 150. Since this matches the Value attribute, the trigger will be applied. The converter just sits between the Property and the comparison to Value and provides some conversion.

So how does this help us? Well, there is one more attribute we need to introduce. The ConverterParameter attribute allows us to supply an additional parameter to our converter when it does its stuff. Now we can envisage,

<... .Resources>
<cvt:LessThanConverter x:Key="LessThanConverter"/>
</... .Resources>

<DataTrigger Value="True" Binding="{Binding RelativeSource={RelativeSource Self}, Path=ActualWidth, Converter={StaticResource lessThanConverter}, ConverterParameter=200}">
...
</DataTrigger>

Note that we create an instance of the converter as a static resource. The actual code behind the converter is relatively straightforward. All we do is take the supplied value, compare it to the supplied parameter, and return true if the value is less otherwise return false. In fact this is slightly more complex. Whilst a ValueConversionAttribute may be applied to the converter class specifying the type for the parameter, when written in XAML as shown above this is ignored and a string is supplied anyway. Therefore the resulting code is,

using System;
using System.Windows.Data;
using System.Globalization;

[ValueConversion(typeof(double), typeof(bool), ParameterType = typeof(double))]
public class LessThanConverter : IValueConverter
{
public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
{
double doubleValue = (double)value;
double doubleParameter;

if (parameter is double)
doubleParameter = (double)parameter;
else if (parameter is string)
{
if (!Double.TryParse((string)parameter, out doubleParameter))
throw new FormatException("The parameter for this LessThanConverter could not be converted to a System.Double");
}
else
throw new ArgumentException("The parameter for this LessThanConverer is of an unsupported type", "parameter");

Console.WriteLine("{0} < {1}", doubleValue, doubleParameter);

return doubleValue < doubleParameter;
}

public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
{
return new NotSupportedException();
}
}

So now we can trigger when any dependency property that is defined as a double is less than a specified value. The original problem from part 1 however involved changing the appearance of a window when either of the Width or Height properties were below a certain threshold. We can specify two separate triggers, but this requires duplication of all the setters within them. What we really need is some way to apply a 'logical OR' operation to two or more triggers. Next time... The IMultiValueConverter interface.

Technorati tags: WPF, IValueConverter, Triggers

How small can you go?

2007-01-22T22:51:00.001Z

In the past, creation of fully sizable user interfaces was a tedious job involving writing complex and bugging "pixel-counting" code to layout controls upon a window resize event. Windows Presentation Foundation (WPF) has made the job of creating such UIs much simpler by including a straightforward layout engine within the framework. But sometimes there is a limit to how small you can resize the UI before it becomes unusable.

One solution is the approach used by the 2007 Microsoft Office System, whereby the ribbon control will disappear from view if the window is resized too small, allowing the document content to fill the space. In this post I'll describe how to implement this effect in WPF applications. I will discuss how to implement dependency properties in your custom controls and the strange world of read-only dependency properties.

As a very simple example we will start with a custom control that is styled with a content area, and a toolbar that when sized below a certain size will be hidden (in my WPF ribbon control this is actually a styled Window, however for simplicity here I will use a control).

public class SizingControl : Control
{
}

Now we will add a "dependency property", a special type of property used for WPF applications that allows additional functionality such as data binding, animations and styling. We define these with the DependencyProperty.Register static method, supplying a property name, property type and owner type. In addition, metadata may be added defining addition information such as default values. In addition we add a standard CLR property of the same name, passing the value to and from the property system with the DependencyObject.GetValue and DependencyObject.SetValue methods. In this case we add a dependency property to specify the size below which the control will display a different UI.

public static readonly DependencyProperty SmallSizeProperty = DependencyProperty.Register("SmallSize", typeof(Size), typeof(SizingControl), new UIPropertyMetadata(new Size(0.0, 0.0)));

public Size SmallSize
{
    get
    {
        return (Size)GetValue(SmallSizeProperty);
    }
    set
    {
        SetValue(SmallSizeProperty, value);
    }
}

Next we add a read-only dependency property that indicates whether the control is below the specified size. The Windows SDK warns against using read-only dependency properties in many cases, and suggests that such properties should only be used "for state determination". Think of this as properties of the form "IsXXX" (such as IsMouseOver).

To register a read-only dependency property, we use the DependencyProperty.Register.ReadOnly static method, which rather than a DependencyProperty, returns a DependencyPropertyKey. To set the value we can use this with the respective override of DependencyObject.SetValue, however no suitable override of DependencyObject.GetValue exists. In fact, the property system does not allow us to get a value of a dependency property that is marked as read-only. So how do we obtain this value? The answer is that we have to include a private field to contain the property value. Since by its very nature a read-only property may only be set by the owner class, we can always ensure that the value in the field is synchronized with that of the dependency property. To avoid writing code that breaks this rule, I tend to encapsulate this logic into a private property setter (note that property setters and getters with different accessibility is a feature of C# 2.0).

private bool isSmall;

public static readonly DependencyPropertyKey IsSmallPropertyKey = DependencyProperty.RegisterReadOnly("IsSmall", typeof(bool), typeof(SizingControl), new UIPropertyMetadata(false));

public bool IsSmall
{
    get
    {
        return isSmall;
    }
    private set
    {
        if (value != isSmall)
        {
            isSmall = value;
            SetValue(IsSmallPropertyKey, value);
        }
    }
}

Now all is required is to override the OnRenderSizeChanged event of our control, and determine whether the control is small or not.

private void UpdateIsSmall(Size newSize)
{
    IsSmall = (newSize.Width < SmallSize.Width || newSize.Height < SmallSize.Height);
}

protected override void OnRenderSizeChanged(SizeChangedInfo sizeInfo)
{
    // Calculate whether the window size is smaller than the specified values
    UpdateIsSmall(sizeInfo.NewSize);

    // Call the base method
    base.OnRenderSizeChanged(sizeInfo);
}

The XAML below shows how to use the control to hide a toolbar when the window is too small. We style the control with the desired content, and set a trigger on the IsSmall property to show or hide the toolbar as required.

<Window x:Class="SizingApplication.Window1" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" Title="SizingApplication" Height="300" Width="300" xmlns:local="clr-namespace:SizingApplication" Background="Silver">
    <Window.Resources>
        <Style x:Key="MySizingRegion" TargetType="local:SizingControl">
            <Setter Property="SmallSize" Value="200,200"/>

            <Setter Property="Template">
                <Setter.Value>
                    <ControlTemplate TargetType="local:SizingControl">
                        <DockPanel>
                            <ToolBar x:Name="toolBar" DockPanel.Dock="Top" Height="50">
                                <Label VerticalAlignment="Center">My ToolBar</Label>
                            </ToolBar>
                            <Border Margin="10" Background="White"/>
                        </DockPanel>
                        <ControlTemplate.Triggers>
                            <Trigger Property="IsSmall" Value="True">
                                <Setter TargetName="toolBar" Property="Visibility" Value="Collapsed"/>
                            </Trigger>
                        </ControlTemplate.Triggers>
                    </ControlTemplate>
                </Setter.Value>
            </Setter>
        </Style>
    </Window.Resources>

    <Grid>
        <local:SizingControl Style="{StaticResource MySizingRegion}"/>
    </Grid>
</Window>

The full code for this post is here.

Ribbon controls are legal!

2006-11-24T22:48:00.001Z

Here is the news that Microsoft have launched a licensing program for those who wish to clone the Office 2007 UI (from Jensen Harris' blog). This is a royalty-free scheme whereby anyone wishing to use part of the Office 2007 user interface (e.g. the ribbon) can recreate it in their applications (note that this offering does not provide any code).

There are some restrictions applied however, in particular that the interface must adhere to the supplied UI guidelines. These are very detailed so places quite a burden on the programmer implementing the controls; however this should at least ensure that the end user can confidently use a ribbon-enabled application with the existing knowledge of how the UI should work. Microsoft have done a great job in explaining the requirements - for example they describe exactly how the ribbon should resize - so I'm looking forward to having an accurate check-list of requirements to implement in my controls.

For more information check out the links in Jensen' blog post...

From the shadows

2006-11-05T16:44:00.001Z

When styling controls that have a Popup element (e.g. menus, combo boxes, etc.) a common visual cue is a drop-shadow below the pop-up. WPF contains a DropShadowBitmapEffect that will do this all for us, hence,

The result is shown on the left below. However, the DropShadowBitmapEffect is a bit overkill for our needs. It is designed to add drop-shadows to arbitrary shapes (for example the text below) whereas a pop-up is generally rectangular.

If you inspect the default WPF styles you will find that a drop shadow is applied via a Decorator called Microsoft.Windows.Themes.SystemDropShadowChrome. This however is hidden away in PresentationFramework.Luna.dll and designed for use by the default styles.

For my controls I have developed my own decorator to do a similar job. Firstly I have decided to make some assumptions to improve performance - namely that the drop-shadow colour is always black, and that it is always to the bottom-right. All that is required then is to implement a custom "Decorator". Decorators are controls that add some additional rendering to a single element (of course that element may be a Panel that contains several other elements). We can then draw a drop-shadow in the OnRender method consisting of a set of linear and radial gradients to mimic the shadow.

using System;
using System.Collections.Generic;
using System.Text;
using System.Windows.Controls;
using System.Windows.Media;
using System.Windows

class ShadowChrome : Decorator
{
// *** Fields ***

private static SolidColorBrush backgroundBrush;
private static LinearGradientBrush rightBrush;
private static LinearGradientBrush bottomBrush;
private static RadialGradientBrush bottomRightBrush;
private static RadialGradientBrush topRightBrush;
private static RadialGradientBrush bottomLeftBrush;

// *** Constructors ***

static ShadowChrome()
{
MarginProperty.OverrideMetadata(typeof(ShadowChrome), new FrameworkPropertyMetadata(new Thickness(0, 0, 4, 4)));

CreateBrushes();
}

// *** Overriden base methods ***

protected override void OnRender(DrawingContext drawingContext)
{
// Calculate the size of the shadow

double shadowSize = Math.Min(Margin.Right, Margin.Bottom);

// If there is no shadow, or it is bigger than the size of the child, then just return

if (shadowSize <= 0 || this.ActualWidth < shadowSize*2 || this.ActualHeight < shadowSize * 2)
return;

// Draw the background (this may show through rounded corners of the child object)

Rect backgroundRect = new Rect(shadowSize, shadowSize, this.ActualWidth - shadowSize, this.ActualHeight - shadowSize);
drawingContext.DrawRectangle(backgroundBrush, null, backgroundRect);

// Now draw the shadow gradients

Rect topRightRect = new Rect(this.ActualWidth, shadowSize, shadowSize, shadowSize);
drawingContext.DrawRectangle(topRightBrush, null, topRightRect);

Rect rightRect = new Rect(this.ActualWidth, shadowSize * 2, shadowSize, this.ActualHeight - shadowSize * 2);
drawingContext.DrawRectangle(rightBrush, null, rightRect);

Rect bottomRightRect = new Rect(this.ActualWidth, this.ActualHeight, shadowSize, shadowSize);
drawingContext.DrawRectangle(bottomRightBrush, null, bottomRightRect);

Rect bottomRect = new Rect(shadowSize * 2, this.ActualHeight, this.ActualWidth - shadowSize * 2, shadowSize);
drawingContext.DrawRectangle(bottomBrush, null, bottomRect);

Rect bottomLeftRect = new Rect(shadowSize, this.ActualHeight, shadowSize, shadowSize);
drawingContext.DrawRectangle(bottomLeftBrush, null, bottomLeftRect);
}

// *** Private static methods ***

private static void CreateBrushes()
{
// Get the colors for the shadow

Color shadowColor = Color.FromArgb(128, 0, 0, 0);
Color transparentColor = Color.FromArgb(16, 0, 0, 0);

// Create a GradientStopCollection from these

GradientStopCollection gradient = new GradientStopCollection(2);
gradient.Add(new GradientStop(shadowColor, 0.5));
gradient.Add(new GradientStop(transparentColor, 1.0));

// Create the background brush

backgroundBrush = new SolidColorBrush(shadowColor);

// Create the LinearGradientBrushes

rightBrush = new LinearGradientBrush(gradient, new Point(0.0, 0.0), new Point(1.0, 0.0));
bottomBrush = new LinearGradientBrush(gradient, new Point(0.0, 0.0), new Point(0.0, 1.0));

// Create the RadialGradientBrushes

bottomRightBrush = new RadialGradientBrush(gradient);
bottomRightBrush.GradientOrigin = new Point(0.0, 0.0);
bottomRightBrush.Center = new Point(0.0, 0.0);
bottomRightBrush.RadiusX = 1.0;
bottomRightBrush.RadiusY = 1.0;

topRightBrush = new RadialGradientBrush(gradient);
topRightBrush.GradientOrigin = new Point(0.0, 1.0);
topRightBrush.Center = new Point(0.0, 1.0);
topRightBrush.RadiusX = 1.0;
topRightBrush.RadiusY = 1.0;

bottomLeftBrush = new RadialGradientBrush(gradient);
bottomLeftBrush.GradientOrigin = new Point(1.0, 0.0);
bottomLeftBrush.Center = new Point(1.0, 0.0);
bottomLeftBrush.RadiusX = 1.0;
bottomLeftBrush.RadiusY = 1.0;
}
}

This may then be used as shown in the following XAML. Note that the Margin property is used for two uses. Firstly it provides an area around the element to render the drop-shadow (this is important in a Popup since it ensures the drop-shadow is within the pop-up window), and also specifies to ShadowChrome the size to render the drop-shadow.

DropDownButtons in WPF

2006-10-29T12:06:00.001Z

Whilst Windows Presentation Foundation (WPF) provides good support for menus, one omission is a drop-down button. By this I mean a button, that when clicked will result in a menu dropping down from the control.

So I started to write my own. Easy I thought, just style a MenuItem to look like a button. Well, this doesn't work as the MenuItem control will only work if it is a child of a Menu control. I could just wrap all my DropDownButtons in Menus, but that becomes a little messy wrapping everything in extra menus. I tried a number of other approaches, none of which worked as I would like.

This was several months ago. Recently however I was informed of a couple of related blog articles at Sheva's Techspace and Lester's piece on WPF. In particular I liked Lester's approach. This is to use the Button's ContextMenu to apply add a context menu, and then to use code to open this on a left mouse click. A simple solution that works well. But what if I wanted to have a real context-menu too?

Solution: Well, in fact ContextMenu doesn't need to be attached to a control to work. All you need to do is create a new ContextMenu object, add your MenuItems, and set IsOpen to true. So I put together the control as below.

public class DropDownButton : ToggleButton
{
// *** Dependency Properties ***

public static readonly DependencyProperty DropDownProperty = DependencyProperty.Register("DropDown", typeof(ContextMenu), typeof(DropDownButton), new UIPropertyMetadata(null));
// *** Constructors ***
public DropDownButton()
{
// Bind the ToogleButton.IsChecked property to the drop-down's IsOpen property
Binding binding = new Binding("DropDown.IsOpen");
binding.Source = this;
this.SetBinding(IsCheckedProperty, binding);
}
// *** Properties ***
public ContextMenu DropDown
{
get
{
return (ContextMenu)GetValue(DropDownProperty);
}
set
{
SetValue(DropDownProperty, value);
}
}
// *** Overridden Methods ***
protected override void OnClick()
{
if (DropDown != null)
{
// If there is a drop-down assigned to this button, then position and display it
DropDown.PlacementTarget = this;
DropDown.Placement = PlacementMode.Bottom;
DropDown.IsOpen = true;
}
}
}

This control derives directly from ToggleButton so we inherit the full behavior and styling of a button. We then provide a DropDown dependency property that takes a ContextMenu to show for the drop-down. In the OnClick event we simply position the menu under the control, and open it by setting IsOpen to true. Finally to tidy up, we bind the ToggleButton's IsChecked property to the drop-down menu's IsOpen property to ensure that these are synchronized.

To use this in your own code you simply use,

<ctrl:DropDownButton Content="Drop-Down">
<ctrl:DropDownButton.DropDown>
<ContextMenu>
<MenuItem Header="Item 1"/>
<MenuItem Header="Item 2"/>
<MenuItem Header="Item 3"/>
</ContextMenu>
</ctrl:DropDownButton.DropDown>
</ctrl:DropDownButton>

Technorati tags: WPF, DropDownButton, Ribbon

An Office 2007 style Ribbon in WPF?

2006-10-29T11:34:00.001Z

For a while now I have been working on reproducing an Office 2007 Ribbon style application in Windows Presentation Foundation (WPF). This includes not just the ribbon itself, but also the full window chrome.

Whilst the official documentation has been in progress, blogs have been a great alternative source of information. However now I thought would be a good time to start my own blog discussing, amongst other things, how I am writing my Ribbon control.

Hope over the coming months you enjoy my posts and find something of interest to your own development needs. I'll focus on some of the issues that I have encountered, and will post some images of the fully working Ribbon control.

Technorati tags: WPF, Ribbon