Basic page inheritance #1: “InitializeComponent() hides inherited member” warning

Class inheritance is one of the core features of any object-oriented language since it allows to reuse code that is available in one base class in all derived classes. Why shouldn’t we use this pattern also for XAML pages in a Windows Phone or Windows Store App? I do it all the time, and I keep doing the same mistake over and over again, so here’s the basic instructions:

Let’s assume, for example, that we want to parse all the incoming URI parameters in the OnNavigatedTo methods of all pages within a Windows Phone App, and make those parameters available as public properties. Instead of overriding each page’s OnNavigatedTo method and calling the same parsing algorithms over and over again, we could integrate this parameter-parsing logic in a base page, and let all the actual pages that will be presented to the user subclass this base page.

This is the tricky part: Since we speak of this base class as a base page, that the easiest way of creating it is to just open the Add New Item window, let Visual Studio create an empty page, remove all the content in XAML code except for the <phone:PhoneApplicationPage ...></phone:PhoneApplicationPage> skeleton, and fill the codebehind class with all the common code logic. Doing so (and then creating “real” pages that inherit from this base page) will certainly work, the code will compile and the App will start up, but we’d be stuck with a small compiler warning that won’t go away:

Compiler warning

The reason for this is that our base page that was created automatically by the Visual Studio Add New Item wizard consists of a codebehind file (BasePage.xaml.cs) and a definition of its appearance written in XAML code (BasePage.xaml). Although we removed every visual component from the XAML code, the compiler will automatically generate an InitializeComponent() method for laying out all the XAML components – it doesn’t know that there are no visual components. Now, when subtyping this class, the derived page will also get an InitializeComponent() method, and the compiler is worried about those two methods that override each other.

To avoid this compiler warning, we should create the base page as a simple C# class. We call this class BasePage and make sure it derives from PhoneApplicationPage:

public abstract class BasePage : PhoneApplicationPage
{
	// add common code for all derived pages here...
}

This base page will have neither a XAML representation nor any visual contents – but hey, it’s just a storage for code snippets and will never be presented to the user, so it doesn’t need them! It may still serve as base class for your application’s visible pages, and it will still contain all properties, event handlers, etc. provided by PhoneApplicationPage, but no visual components the compiler might worry about…

Finally, each of the pages that are actually visible in our App must inherit from our base page. The header of the C# code of such a “real” page looks as follows:

public partial class MainPage : BasePage

…and the XAML file:

<BasePage
	x:Class="TestApp.MainPage"

Of course, the same pattern can be realized in Windows Store Apps, basically the difference is that BasePage inherits from Windows.Ui.Xaml.Controls.Page instead of PhoneApplicationPage. However, there are a few additional things to keep in mind, that’s why a second blog post on this topic is coming up.