Wednesday, 21 September 2011

Using IActiveAware and INavigationAware

prism[Concrete/Little bit interesting] The Microsoft Prism framework provides a couple of very useful interfaces for managing awareness of view activation and navigation.





IActiveAware is a simple interface you can implement on your views to indicate that you want the view to be notified when it is made active or inactive. It looks like this:

public interface IActiveAware
    /// <summary>
    /// Gets or sets a value indicating whether the object is active.
    /// </summary>
    /// <value><see langword="true" /> if the object is active; otherwise <see langword="false" />.</value>
    bool IsActive { get; set; }

    /// <summary>
    /// Notifies that the value for <see cref="IsActive"/> property has changed.
    /// </summary>
    event EventHandler IsActiveChanged;

The IsActive flag lets you know if your view is active, and the IsActiveChanged event will fire when that state changes.

If you implement this on your view class, then you need to ensure the event gets fired when the state is changed by the region behaviour. You do this by adding the IActiveAware interface to your View-Model:

public class LoginViewModel : NotificationObject, IActiveAware, INavigationAware

An example of the implemented interface is shown here:

#region ViewModel activation
private bool _IsActive = false;
public bool IsActive
        return _IsActive;
        _IsActive = value;
        if (value)

public event EventHandler IsActiveChanged;

In the above example I use the changing state of IsActive to trigger the private methods OnActivate() and OnDeactivate(). These methods are thus called when the view active state changes.

IActiveAware Example - Managing Devices

A good example of the use of IActiveAware is the subscription to an control of devices. We use event aggregation to interface with physical devices, that is, we subscribe to device notifications. The simplest scheme is to subscribe to all the device events in the View-Model constructor:

//Subscribe to device events

Of course, this means that the View-Model will be called back on device events during the entire lifetime of the module housing the View-Model and the associated views.

To ensure you only act on the device events when your view is the active view, simply use the IsActive property appropriately in the event callback:

private void ScannerInputReceived(ScannerEventParameter param)
    //Handle input if active and OperatorId has focus
    if (IsActive == false || OperatorHasFocus == false)

    if (!string.IsNullOrEmpty(param.Barcode))
        OperatorId = param.Barcode;
        ValidateLoginInput(false, null);
        ProgressMessage = Resources.Message_InvalidInput;

OnActivate() and OnDeactivate()

These methods when implemented should be used to handle the View-Model initialisation and termination state. For example, in a Login screen, during OnActivate(), the View-Model should initialise the various entry fields and properties used to control the view:

private void OnActivate()
    ProgressMessage = String.Empty;
    ChangingPassword = false;
    NewBiometricEntry = false;
    LoginWithPassword = configurationManager.GetBool(ConfigurationNames.LoginWithPassword);


Here we are setting the title through a published event, clearing the progress message, clearing some flags (used to control the visibility state of page elements), resetting the OperatorId and Password and ensuring we are logged off. These operations will be performed every time a view in this module is activated.

IActiveAware Limitations and INavigationAware

Responding to IActiveAware works fine in a module that supports a single view. In this scenario, the View-Model activation is one-to-one with the View activation. However, if there are more than one view associated with a View-Model, you will have to implement INotificationAware:

public interface INavigationAware
    bool IsNavigationTarget(NavigationContext navigationContext);
    void OnNavigatedFrom(NavigationContext navigationContext);
    void OnNavigatedTo(NavigationContext navigationContext);

This interface when implemented provides callbacks to handle the navigationContext switch in the form of OnNavigatedFrom() and OnNavigatedTo(). A typical implementation here is to keep a copy of the navigationContext passed to the OnNavigatedTo(). This can be used later to perform view-to-view navigation:

#region Navigation Aware for view switching in this module
private IRegionNavigationService navigationService;

public bool IsNavigationTarget(NavigationContext navigationContext)
    return true;

public void OnNavigatedFrom(NavigationContext navigationContext)

public void OnNavigatedTo(NavigationContext navigationContext)
   navigationService = navigationContext.NavigationService;

and to perform view-to-view navigation (for example, Go Back):

private void onGoBackHandler()
    if (navigationService.Journal.CanGoBack)

Note that in the above implementation of the interface we are returning true from the IsNavigationTarget() method. This method is called by the framework to determine if the current views should be reused for the navigation target. Returning true indicated the views should be reused. Since we pre-create all our views, you should return true.

Thursday, 8 September 2011

This is a test Article on the blog



Here is a picture

Like it?



Actually, this is a test for using Windows Live Writer to publish to SharePoint Wiki. Which sounds easy, but you guessed it, it’s not.

I’ll let you know how I get on.


Frankly, it’s all rather disappointing. I guess someone at Microsoft, looking to make SharePoint a little more useful thought “well it’s good at lists and HTML docs, if you add a template with an on-page editor, hey presto, you’ve got a Wiki”. Only, it’s not that simple and the editor is far too lightweight.

Windows Live Write (WLW) on the other hand is a well thought out, powerful tool. Clearly the best Blog editor in my mind. It’s the reason I have a Windows VM on my Mac.

So I gave it a go and WLW doesn’t want to talk to the Wiki because it’s not a blog, doesn’t support the APIs, just a list with an editor.

However, it was suggested that I could author my pages against my SharePoint blog. Great. It worked brilliantly. WLW talks to SharePoint blogs and does an excellent job of it.

Once published, all you have to do is open the blog in SharePoint for editing, copy the raw HTML and paste it to the Wiki.

It works, but it’s far from perfect

The main advantage of this is the editor in WLW. It’s excellent, support plug-in for styles, adopts site templates. I’m using it now and what I type is what I will see on the blog site.

A very useful benefit of this approach is image publishing. It’s a royal pain in the arse when editing on the SharePoint Wiki. Using this method, images are published to my blog and can be referenced in the Wiki without need to upload anything or mess around.

But the main problem is I’m publishing to a blog and have a second copy in the Wiki. I may even have a third local copy on my Mac saved by WLW. These copies can easily get out of step.

Worse still, the images are associated with a my blog and my account, not the Wiki. If my account gets deleted, I guess these resources will disappear.

Finally, the point of a Wiki is that the documents are live and through collaboration, the Wiki will change over time. So my copy on my blog is very likely to be out of step. This could result in changes being lost as the WLW view of the document is that of the blog, not the Wiki.

You could of course create a shared blog and keep this as the master document site. I thought of this and it occurred to me that if I was to do this, I might as well try to use that as my Wiki. Well that made the whole exercise seem pointless.

Improved on-page Editing

You can of course change the Wiki template to use a more advanced editor. This is a very satisfactory solution. One of the recommended ones is the Telerik RadEditor that can be integrated into SharePoint 2010:

Problem is, it cost about $800. And I’ve already spent half that purchasing a better Forum web part because the out of the box solution from Microsoft is just rubbish. Starting to sound like throwing good money after bad,

Microsoft SharePoint Designer 2010

Ok, time to bring the big guns out. I’m only trying to update pages on the Wiki!

Well, this is a powerful tool. It’s also typical of the development/management tools from Microsoft. Yes, I can edit the Wiki, but it’s not easy. Ultimately, this tool provides a Visual Studio / Microsoft Expression type of view on the site and site document. Not really what you want.



I’ll keep looking for a better solution to editing on-page in SharePoint. Maybe Microsoft will provide a link between WLW and SharePoint Wiki.

However, until a solution is found, the SharePoint Wiki experience will be very disappointing.

Given that for a Wiki, the ease of authoring and content creation is as important as the content itself, you might just decide that SharePoint doesn’t even qualify as a Wiki.