Improvements in Version 0.9.6 of the Okra App Framework

To start off I would like to announce that I have just pushed a minor fix for the Okra App Framework NuGet packages with the version number v0.9.6.1. This fixes an issue with the NuGet packaging and contains the same code base as the recent v0.9.6 release. If you have previously updated to v0.9.6 via NuGet I would recommend you update to the new packages. Anyone who has downloaded the source code releases of v0.9.6 do not need to make any changes.

Following that brief announcement I would like to use the rest of this post to discuss a couple of changes that were made with the recent v0.9.6 release of the Okra App Framework to support more advanced activation and navigation scenarios. The good news is that these changes should not affect any existing code, however you may wish to implement these changes to take full advantage of future features within Okra.

Activation of Applications via the OkraApplication class

In previous releases of the Okra App Framework the recommended way of initializing your application was to create an AppBootstrapper class that derived from OkraBootstrapper. This would then be initialized from your App.xaml.cs file’s constructor,

sealed partial class App : Application

{

    public App()

    {

        this.InitializeComponent();

        // *** NB: THIS CODE IS NOT RECOMMENDED! ***

        AppBootstrapper bootstrapper = new AppBootstrapper();

        bootstrapper.Initialize();

    }

}

Whilst this will continue to work for existing applications based on the Okra App Framework, this approach does not support certain types of activation, in particular the recently introduced share target support.

Instead the recent release has introduced an OkraApplication class that should be used to derive your App class from. The AppBootstrapper is still required and needs no further changes, however the OkraApplication class will ensure that all activation events are recognised.

The changes that you should make are:

• Change your App.xaml.cs class to read,

sealed partial class App : OkraApplication

{

    public App()

        : base(new AppBootstrapper())

    {

        this.InitializeComponent();

    }

}

• Change the type of your App.xaml definition to be derived from OkraApplication (NB: Only the changes are shown in the code snippet below),

<okra:OkraApplication

    ...

    xmlns:okra="using:Okra">

    ...

</okra:OkraApplication>

Introduction of INavigationContext

The second feature I will discuss is the introduction of the INavigationContext interface. This is designed to allow more consistent navigation code, better code reuse and better support for more advanced navigation scenarios (such as those discussed here and here).

In previous releases of the Okra App Framework you would support navigation from you view-model by importing an INavigationManager. For example,

public class MyViewModel : NotifyPropertyChangedBase

{

    // *** NB: NO LONGER RECOMMENDED ***

    [Import]

    INavigationManager NavigationManager { get; set; }

    ...

}

If you were writing a settings pane then INavigationManager would be replaced with ISettingsPaneManager, and in other cases (such as file pickers or in multiple navigation applications) you may have a number of simultaneous navigation stacks of the same type to choose from.

With the v0.9.6 release of the Okra App Framework this has all been consolidated into a single INavigationContext interface. This can be imported via your view-models constructor and will return the correct navigation manager for the current page’s context,

public class MyViewModel : NotifyPropertyChangedBase

{

    INavigationBase NavigationManager { get; private set; }

    [ImportingConstructor]

    public MyViewModel(INavigationContext context)

    {

        this.NavigationManager = context.GetCurrent();

    }

     ...

}

The advantage of this approach is that you can use the same code in any of the cases mentioned above, and even reuse the same view-model definition between different contexts.

Summary

In this post I have discussed a couple of improvements in the latest release of the Okra App Framework. Whilst existing code should continue to work using the old mechanisms, I would recommend that you adapt your code to take advantage of the benefits described above.

Version 0.9.6 of the Okra App Framework is available from the Okra CodePlex site and via NuGet (v0.9.6.1).

Okra App Framework v0.9.6 Released

The latest update to the Okra App Framework has just been released and is available from the Okra CodePlex site and via NuGet.

New Features in This Release

• Support for the share charm (more information on these in a future post),
• View-model centric share source support – by implementing ISharable on view-models they can automatically provide context specific sharing of data with other applications.
• MVVM based share target support – implement a share target to accept data from other applications via a specified view/view-model.
• Helper methods for task based asynchronous data sharing.
• New OkraApplication base class that will allow the framework to handle more advanced activation events in the future (more on this in a future post).
• Introduction of an INavigationContext that can be imported into views and view-models (more on this in a future post).
• The INavigationBase interface now has an additional CanNavigateTo(…) method that allows consumers to determine if a named page is available without performing the navigation.
• Refactoring of state persistence into the NavigationBase abstract class to allow reuse of this logic in custom navigation scenarios.
• Additional events are raised,
• upon navigation between pages (on INavigationBase)
• upon flyout opening/closing (on ISettingsPaneManager)
• All exceptions on application start-up should now be injected back into the application and not lost.

Breaking Changes

There are a small number of breaking changes in this release of the framework, however most of these are unlikely to apply to users of the framework (they are mostly under-the-hood interface changes that would only be applicable in advanced scenarios).

The only important change is,

• The default OkraBootstrapper base class no longer implements the SearchManager property. If you are using the Okra search functionality then you should simply add the following code to your application bootstrapper.

[Import]

public ISearchManager SearchManager { get; set; }

For reference the other breaking changes are,

• The SearchManager implementation now includes a default search page name (specified in the SpecialPageNames class). Since search is now opt-in this should not cause problems for existing code.


• Removal of the obsolete SetupNavigationManager() method from OkraBootstrapper – this code can simply be placed in the SetupServices() method instead.


• This IViewFactory now accepts an INavigationContext when creating pages. This should be injected during the composition process (handled automatically by the default MEF implementation).


• Additional methods/properties to the INavigationBase, IViewFactory and ISettingsPaneManager interfaces. These will need to be added to any custom implementations.

Creating Authentic Looking Settings Panes with SettingsChrome

In my last post I described how the Okra App Framework allows you easily add multi-page settings panes to your Windows Store applications using the MVVM pattern.

However, the built in Windows 8 applications have a very distinctive style of settings pane and many Windows Store applications will want to recreate this style. To aid with this the Okra App Framework provides a SettingsChrome control to recreate the standard UI chrome.

Using the SettingsChrome control

If you remember from previously, you define the UI for an Okra App Framework settings pane using a standard UserControl with the PageExportAttribute applied to it.

[PageExport("MySettings")]

public sealed partial class MySettingsPage : UserControl

{

    ...

}

In the XAML we can add the Okra SettingsChrome control as the first child element (this can be done either manually in the XAML or added in the designer). SettingsChrome is a content control, and anything that you add inside it will be displayed within the content region of the settings pane. Also you may wish to set the width of the UserControl to define the size of the resulting settings pane.

<UserControl

    ...

    xmlns:ui="using:Okra.UI"

    Width="346">

    <ui:SettingsChrome Title="Sample"

        Logo="ms-appx:///Assets/SmallLogo.png"

        BackButtonCommand="{Binding ...}"

        HeaderBackgroundBrush="{StaticResource ...}"

        HeaderForegroundBrush="{StaticResource ...}">

        <!-- Insert settings pane content here -->

    </ui:SettingsChrome>

</UserControl>

There are a number of properties that you can set on SettingsChrome,

• “Title” – This property allows you to set the text that is displayed at the top of the settings pane


• “Logo” – This should point to an image resource to use as the application logo in the top-right corner of the settings pane


• “BackButtonCommand” – This can be bound to a relevant command on the view-model and will be called whenever the user clicks on the settings pane back button


• “HeaderBackgroundBrush” – This allows you to set the background colour for the settings pane header. Generally this will be a static resource set to the same colour used for application tile background


• “HeaderForegroundBrush” – This allows you to set the foreground colour for the settings pane header

Summary

To summarise, the Okra App Framework allows you to easily recreate the standard settings pane UI within your own application by simply adding a SettingsChrome control into the pane’s XAML.

A sample application demonstrating the use of SettingsChrome, as well as how to define a settings pane using MVVM is available from the Okra CodePlex downloads page.

Settings Panes and the Okra App Framework

In this post (the first of two) I will describe how you can use the Okra App Framework to add custom settings panes to your Windows Store application, in particular taking advantage of the MVVM pattern. In my following post I will show you how to easily design a settings UI consistent with the built-in Windows applications.

In Windows 8, application settings are available from any page of a running application by using the settings charm. This brings up a system-provided list of the available settings entry points, with application specific settings at the top (followed by the Windows provided “Permissions” and “Rate and review” items). If the user selects one of these application specified entry points it is the responsibility of the running application to provide the resulting settings UI.

Defining a Settings Pane with the Okra App Framework

The Okra App Framework makes it simple to add custom settings panes, following the same pattern as any other page within an Okra based application. The framework takes care of displaying the correct UI and providing a dedicated navigation stack within the settings pane.

Any element may be used to define the settings UI, however a UserControl is most commonly used. This is tagged with a page name using the PageExport attribute in the code-behind file.

[PageExport("MySettings")]

public sealed partial class MySettingsPage : UserControl

{

    ...

}

If using the MVVM pattern, the view-model is similarly defined and attributed with the ViewModelExport attribute.

[ViewModelExport("MySettings")]

class MySettingsViewModel : ...

{

    ...

}

This is all that is required to define an MVVM based settings pane.

Displaying the Settings Pane

Whenever a user opens the settings pane, the currently running application is notified via the ‘SettingsPane.CommandsRequested’ event and asked to return the settings to display. In Okra based applications the recommended place to register for this event is in the SetupServices() method of the application bootstrapper. In the event handler you can add any number of settings commands in the order they are desired.

The Okra App Framework provides an ISettingsManager interface and default implementation to handle the resulting navigation to a settings pane. By calling the ‘NavigateTo(…)’ method the settings UI will be displayed in a slide-in pane at the edge of the screen.

public interface ISettingsPaneManager : INavigationBase

{

    void ShowSettingsPane();

}

public interface INavigationBase

{

    bool CanGoBack { get; }

    INavigationEntry CurrentPage { get; }

    event EventHandler CanGoBackChanged;

    void GoBack();

    void NavigateTo(string pageName);

    void NavigateTo(string pageName, object arguments);

}

To make this even easier, the Okra App Framework provides a helper extension method on any INavigationBase instance named ‘GetNavigateToSettingsCommand(…)’ which takes as arguments the name to display to the user, and the page name we defined in the previous section. Therefore a typical bootstrapper will look as follows,

public class AppBootstrapper : OkraBootstrapper

{

    // *** Imported Properties ***

    [Import]

    public ISettingsPaneManager SettingsPaneManager { get; set; }

    // *** Overriden Base Methods ***

    protected override void SetupServices()

    {

        // Register with Windows to display items in the settings pane

        SettingsPane.GetForCurrentView().CommandsRequested += SettingsPane_CommandsRequested;

    }

    // *** Private Methods ***

    void SettingsPane_CommandsRequested(SettingsPane sender, SettingsPaneCommandsRequestedEventArgs args)

    {

        // Add each settings item in the order you wish them to appear

        args.Request.ApplicationCommands.Add(SettingsPaneManager.GetNavigateToSettingsCommand("Settings", "MySettings"));

    }

}

Navigation Within the Settings Pane

Whilst in many cases a custom settings pane will self contained, multi-page settings are possible. Consider an “Accounts” setting where a link takes you to a further “Add account” settings page. This is fully supported in the Okra App Framework by calling the ISettingsPaneManager.NavigateTo(…) and .GoBack() methods to navigate between sections. In addition, calling ‘GoBack()’ on the first page in the navigation stack will redisplay the system provided settings list.

Summary

To summarise, the Okra App Framework makes adding settings panes to your application simple. The steps are,

1. Create a UserControl with the desired UI and set the PageExport attribute.
2. Optionally add a view-model attributed with the ViewModelExport attribute.
3. In the application bootstrapper register for the SettingsPane.CommandsRequested event and use the GetNavigateToSettingsCommand(…) extension method to return a SettingsCommand.

A sample application demonstrating custom settings panes is available from the Okra CodePlex downloads.

Of course it is up to you to provide a suitable UI for the displayed settings pane. In my next post I will describe how to use Okra’s SettingsChrome to present a UI consistent with the standard Windows experience.

Okra App Framework v0.9.5 Released

The latest update to the Okra App Framework has just been released and is available from the Okra CodePlex site and via NuGet.

New Features in This Release

• Settings support
• The framework now includes support for the Windows 8 settings charm. Custom application settings panes can be defined using the MVVM pattern and Okra will handle the wiring required to show the settings pane – I will write about this in detail in an upcoming blog post.
• A SettingsChrome control is included to allow developers to easily match the settings UI of the default Windows 8 applications
• The NavigationManager class has now been refactored to derive from a NavigationBase class with the base functionality. This allows the creation of custom navigation managers (for example the SettingsPaneManager)
• Updated to support MEF v1.0.16
• Minor improvements and bug fixes

App Search and the Okra App Framework

One advantage of the Okra App Framework over other MVVM-based application frameworks is that it is designed from the ground up to work great with Windows 8. Over the next few versions this will become more evident as features are added to support the various Windows 8 system contracts – search, settings, sharing, etc.

In this post I will describe how the Okra App Framework makes it easy to add search to your application using the same MVVM principles that you are using for the rest of your application.

The Search Contract in Windows 8

When developing Windows Store applications many developers will want to take advantage of the Windows 8 search charm. This allows users to search across all applications from a single, consistent entry point. In order to add search functionality you would generally override the OnSearchActivated(…) method in the App.xaml.cs code-behind. In fact the standard Visual Studio search page template will add the code required to do this. For a great Windows Store application however you would want to,

• Fully follow the Windows search design guidelines (available here)
• Preserve the existing application state and correctly handle back navigation from the search page
• Navigate to a suitable page (normally the application home page) if an empty search is performed
• Improve performance by attaching to the SearchPane.QuerySubmitted event where possible
• You may also want to implement the search page using the MVVM pattern

By simply using the Okra App Framework search manager it will take care of these requirements.

Adding Search to Your Application with the Okra App Framework

The Okra App Framework provides a search manager to handle the process of activating search in your application. This is represented by the ISearchManager interface,

public interface ISearchManager

{

    string SearchPageName { get; set; }

}

By default the SearchPageName property is set to null, and Okra will not handle search activation. To opt-in to the search integration you should set the page name for search in your application’s bootstrapper SetupServices() method.

public class AppBootstrapper : OkraBootstrapper

{

    protected override void SetupServices()

    {

        SearchManager.SearchPageName = "Search";

    }

}

By adding this single line your application has been enabled for search, and a page named “Search” will be navigated to when the user performs a search within your application (note that you will also need to declare that your application supports search in the application manifest).

Defining Your Search Page

Because search uses the standard Okra page discovery mechanisms you define your search page and view-model as you would any other page within your application,

[PageExport("Search")]

public sealed partial class SearchPage : LayoutAwarePage

{

    ...

}

[ViewModelExport("Search")]

public class SearchViewModel : NotifyPropertyChangedBase, ISearchPage

{

    ...

}

One thing to note is that the search view model implements the ISearchPage interface (this could also be implemented by the page if you are not using the MVVM pattern),

public interface ISearchPage

{

    void PerformQuery(string queryText, string language);

}

This method will be called whenever the page should show a new set of search results. In this method you provide the application logic to perform the search operation and display the results to the user. Note that this may be called multiple times for a single page as the user performs subsequent searches and you should refresh the content with the new results.

Summary

In the above discussion I have shown how the Okra App Framework makes it simple to implement search functionality in applications based on the MVVM pattern.

A sample search application is available from the Okra CodePlex downloads section. This is based on the Visual Studio search template, but modified to correctly implement the MVVM pattern.

Convention Based Page Discovery With The Okra App Framework

One of the key features of the Okra App Framework for developing Windows 8 apps is the navigation framework with its support for the MVVM pattern. By default pages and view-models are marked with attributes so that the framework can locate them. In this post I will describe how you can enable an alternative convention based approach.

The Default Attribute Based Approach

When using the Okra App Framework navigation support all pages are represented by a page name. So that the framework can locate the associated pages and view-models these are normally attributed with either the PageExportAttribute or ViewModelExportAttribute respectively (for more information see my previous post). For example for a page named “Foo” the classes would be attributed as,

[PageExport("Foo")]

public sealed partial class FooPage : LayoutAwarePage

{

    ...

}

[ViewModelExport("Foo")]

public class FooViewModel

{

    ...

}

A Convention Based Approach

Often however there will be a common naming pattern throughout the application. In the example above all pages are named XxxPage and view-models named XxxViewModel, where “Xxx” is the associated page name. In a convention based approach you no longer need to apply attributes to classes. Instead they are automatically discovered based on a common naming system.

Since the standard Okra bootstrapper uses MEF for composition (for example when using the Okra.MEF NuGet package), we can use the MEF convention based discovery. To enable this we need to add the following code to the application bootstrapper,

public class AppBootstrapper : OkraBootstrapper

{

    ...

    // *** Overriden base methods ***

    protected override ContainerConfiguration GetContainerConfiguration()

    {

        ConventionBuilder conventionBuilder = new ConventionBuilder();

        conventionBuilder.ForTypesMatching(type => type.FullName.EndsWith("Page"))

                         .Export(builder => builder.AsContractType<object>()

                                                   .AsContractName("OkraPage")

                                                   .AddMetadata("PageName", type => type.Name.Substring(0, type.Name.Length - 4)));

        conventionBuilder.ForTypesMatching(type => type.FullName.EndsWith("ViewModel"))

                         .Export(builder => builder.AsContractType<object>()

                                                   .AsContractName("OkraViewModel")

                                                   .AddMetadata("PageName", type => type.Name.Substring(0, type.Name.Length - 9)));

        return GetOkraContainerConfiguration()

                .WithAssembly(typeof(AppBootstrapper).GetTypeInfo().Assembly, conventionBuilder);

    }

}

With this code in place we can greatly simplify our page and view-model definitions to the following. Note that since we follow the convention we no longer need to add any attributes.

public sealed partial class FooPage : LayoutAwarePage

{

    ...

}

public class FooViewModel

{

    ...

}

Summary

As I have shown, when using the Okra App Framework navigation support you can simplify app development by using a convention based approach to defining pages and view-models for the MVVM pattern.

A sample application demonstrating this is available from the Okra CodePlex downloads.