This first Windows Phone application is not
going to do much, but we should get started and make something happen
with the phone. Since this is your first Windows Phone application,
let’s not pretend it is a desktop application but instead show off some
of the touch capabilities.
First, if you look at the text of the XAML you should see that the
first line of text shows the root element of the XAML to be a PhoneApplicationPage. This is the basic class from which each page you create will derive. The x:Class
declaration is the name of the class that represents the class. If you
open the code file, you will see this code was created for you.
<phone:PhoneApplicationPage x:Class="HelloWorldPhone.MainPage"
...
You will want to open the code file for the XAML file. You can do
this by right-clicking the XAML page and picking View Code or you can
simply press F7 to open the code file. The initial code file is pretty
simple, but you should see what the basics are. The namespace and class
name match the x:Class definition we see in the XAML. This
is how the two files are related to each other. If you change one, you
will need to change the other. You should also note that the base class
for the MainPage class is the same as the root element of the XAML. They are all related to each other.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Navigation;
using Microsoft.Phone.Controls;
using Microsoft.Phone.Shell;
using HelloWorldPhone.Resources;
namespace
HelloWorldPhone
{
public partial class MainPage : PhoneApplicationPage
{
// Constructor
public MainPage()
{
InitializeComponent();
// Sample code to localize the ApplicationBar
//BuildLocalizedApplicationBar();
}
}
// ...
}
These two files (the .xaml and the code files) are closely tied to
each other. In fact, you can see that if you find an element in the XAML
that has a name it will be available in the code file. If you switch
back to the .xaml file, click on the TextBlock that you created in Blend. You will notice in the Properties window that it does not have a name (as shown in Figure 1).
Figure 1. Naming an element in the Properties window
If you click where it says “<no name>” you can enter a name. Name the TextBlock “theStatus”. If you then switch over to the code file, you will be able to use that name as a member of the class:
...
public partial class MainPage : PhoneApplicationPage
{
// Constructor
public MainPage()
{
InitializeComponent();
theStatus.Text = "Hello from Code";
}
}
...
At this point, if you run the application (pressing F5 will do this)
you will see that this line of code is being executed as the theStatus TextBlock is changed to show the new text (as seen in Figure 2).
Figure 2. Running the application
There is an important fact you should derive from knowing that named
elements in the XAML become part of the class: The job of the XAML is to
build an object graph. The hierarchy of the XAML is just about creating
the hierarchy of objects. At runtime, you can modify these objects in
whatever way you want.
When you stop your application the emulator will continue to run. You
can leave the emulator running across multiple invocations of your
application. You should not close the emulator after debugging your
application.
Working with Events
Since you are building a phone application, let’s show how basic
events work. You can wire up events just as easily using standard
language (e.g., C#) semantics.2 For example, you could handle the Tap event on theStatus to run code when the text is tapped:
...
public partial class MainPage : PhoneApplicationPage
{
// Constructor
public MainPage()
{
InitializeComponent();
theStatus.Text = "Hello from Code";
theStatus.Tap += theStatus_Tap;
// Sample code to localize the ApplicationBar
//BuildLocalizedApplicationBar();
}
void theStatus_Tap(object sender, System.Windows.Input.GestureEventArgs e)
{
theStatus.Text = "Status was Tapped";
}
}
...
When you tap on theStatus the Tap
event will be fired (which is what causes the code in the event handler
to be called). All events work in this simple fashion, but the number
and type of events in Silverlight for Windows Phone vary widely.
