Basic page inheritance #2: Windows Store Apps

As an extension to the previous blog post concerning page subtyping in Windows Phone projects, this article covers the same topic in the context of Windows Store Apps for Windows 8. Basically the instructions are the same, just keep in mind that you must derive your base page from Windows.Ui.Xaml.Controls.Page instead of PhoneApplicationPage. However, there are three additional things that might lead to confusion and that are therefore worth noticing:

Compiler warnings

When using a visual page (one that contains a XAML representation) as base page by mistake, in addition to the yet familiar warning “InitializeComponent() hides inherited member…”, a second compiler warning is displayed:

Compiler warnings

Both point to a compiler-generated file *.g.cs which is a hint to the fact that both are related to the overwritten XAML representation of the base page. Replace the base page by a simple class that has no XAML file, and both warnings will disappear.

Always call base methods

If your base page adds code to one of the methods ogirinally defined in Windows.Ui.Xaml.Controls.Page (for example OnNavigatedTo(NavigationEventArgs e) as suggested in Basic page inheritance #1, all your final pages need to call base.OnNavigatedTo(e) if they also override this respective method.

The tricky thing is: In practice, you’ll often add new pages using Visual Studio’s Add New Item wizard and afterwards adapt them to inherit from BasePage instead of Windows.Ui.Xaml.Controls.Page. When doing so, keep in mind that the Add New Item wizard automatically adds an empty OnNavigatedTo(NavigationEventArgs e) method to each page – if you really need this, fill it with code and don’t forget to add the call to base.OnNavigatedTo(e)! If your page doesn’t need to override OnNavigatedTo at all, it’s safest to remove the auto-generated code snippet completely. If you miss doing one of these two options, your base page’s OnNavigatedTo logic will never be called (and it might take a long, long time to find out why – speaking from my own experience).

Using different base types

Sometimes you’ll want all the visual pages in your App to derive from another class than the simple Windows.Ui.Xaml.Controls.Page, for example from the LayoutAwarePage that is integrated in Microsoft’s Store App template project, but at the same time they should of course still inherit from your custom base page. Since C# does not allow inheritance from multiple classes, there are obviously three ways to accomplish this:

  • The simplest solution is to adapt LayoutAwarePage.cs (or the desired page template) and insert all the common code that shall be available to all pages into this class, instead of creating an extra BasePage.
  • If you don’t want to, or can not, make changes to LayoutAwarePage.cs (or the desired page template) – for example because it is contained in an external library – another simple alternative is to make your BasePage inherit from LayoutAwarePage, and then derive all your actual pages from BasePage as usual.
  • If you can’t change the BasePage class in order to subtype it from LayoutAwarePage (or the desired page template) – for example because BasePage.cs is contained in an external library – you could still adapt LayoutAwarePage and ensure it inherits from BasePage, and then derive all your visual pages from LayoutAwarePage. In this case, however, I’d suggest to double-check if all base method calls as mentioned above are maintained.For example, Microsoft’s default LayoutAwarePage overrides the OnNavigatedTo method. If your base page also contains code within the OnNavigatedTo method, you’ll need to add a base.OnNavigatedTo(e) call to the LayoutAwarePage class – otherwise your common code defined in BasePage will never be called!