If you've been following my posts, hopefully you're starting to get more comfortable with creating Windows Phone apps.   It's very different from Windows Mobile, and somewhat different from regular Silverlight as well.   One big difference from other paradigms is the concept of windows/forms.   You don't just create a new instance of a window and call Show on it.   Instead, you need to tell the phone to navigate to it.   If you remember from the last installment, the phone keeps track of your navigation history to enable the hardware Back button to work.   It couldn't do this if you just created and showed forms whenever it struck your fancy.

To try this out, create a new Windows Phone Application project under Silverlight for Windows Phone.   If you don't have these templates, you need to install the Windows Phone Developer Tools.   The other application templates are useful too, but I won't be talking about them in this posting.

Once you've create the solution/project, add a Windows Phone Portrait Page.   You can place any content you'd like on these two pages, but assume that one is a menu, and the other is some form of content.   When a user clicks on (touches) a button on the main page, you'd like the second one to show.

In the first page, you can add a button by using the Button element within the Grid name €œContentPanel €.

<Button Content="Go to Page 1" VerticalAlignment="Center" />

Now you have a button that is stretched to fill the width (due to default HorizontalAlignment= €Stretch €) and height that is automatically determined by the content and centered in the provided space (VerticalAlignment= €Center €).   Of course, this button won't do anything.   To have it take some action, you'll need to wire up an event handler.   Though Silverlight supports Command binding, Silverlight for Windows Phone does not.   In the visual designer, double-click the button to create and wire up an Click event handler.   This creates the method and creates a Click element in the XAML pointing to this new method.

You might be tempted to try to create the instance of the second page here, but don't do it!   We want to let the framework handle that.   To do this, we can just tell the phone's navigation service to do the work for us:

NavigationService.Navigate(new Uri("/SecondPage.xaml", UriKind.Relative));

This causes several things to happen.   The SecondPage object is instantiated, the NavigatedFrom event on the first page fires, and the NavigatedTo event of the second page fires.   Use these events for initialization as needed.   The NavigationService object is also what builds up the history stack   This is done by keeping track of the URL's.   This is why simply new'ing up a page won't work.

If you debug the application right now, you'll go straight to the main page with the button.   If you click the button you'll get to the second page.   There's no button to return to the first screen, but you don't need one.   Remember why?   It's thanks to the hardware Back button.   Press that to go back to the main page.   Press it again to return to the start screen.

The reason why the URL starts with a slash and is marked as UriKind.Relative is because of how the application locates the page.   Relative means that it's coming from the same assembly.   The slash is the path leading to it - in this case, the root.   You can navigate to pages in other assemblies of your project as well with the proper URL.

Another benefit of using the URL-based navigation scheme is the ability to pass arguments - just like in HTTP URL's.   If you alter the above call to include a query parameter ( €œ/SecondPage.xaml?id=2 €) then when SecondPage is created, it can access that value to lookup a data object, or change its UI in some way.   To access the parameters on the page, just access the QueryString property of the NavigationContext object like this:

string id = NavigationContext.QueryString["id"];

If you need to, you can go back programmatically by first checking the CanGoBack property of the NavigationService object, then calling Back().   The Forward/CanGoForward calls aren't supported on the phone so don't get your hopes up!

Hopefully this has helped with some initial understanding of moving between screens on the phone.   On each screen, of course you can add any controls you want, including user controls that you make.   By understanding the way Windows Phone handles this navigation, you'll be able to right better applications.