This is the second part in this blog series detailing my experience writing my first Windows Phone 8 (WP8) application.
In Day 1, I decided what the application will be — a ToDo application — and set up my development environment.
Now I need to get myself familiar with the world of WP8. I could start off by creating a blank project and searching around, but whenever I’m in a completely new situation, I prefer to find an existing project, read the code. I find that gives me a much better idea of what to expect.
Fortunately, Visual Studio comes with several project types to pick from. These include an empty project, a pivot layout, and a project with data-binding. I knew I would be doing a fair amount 0f data-binding, so I decided to go with that project.
The first thing I noticed is a nice preview of the main application page, not only that, but it looks like there is some sample data to help visualize the layout. I’ll look into that a little more later, but before we do anything else, we have to actually get this application to show this page, that is the job of the App class located in the project.
In the App.xaml.cs file there was a decent bit of plumbing and good comments to describe what is going on. Four events that I spent a little bit of time looking into were the “Launching”, “Closing”, “Activated”, and “Deactivated”. I knew understanding exactly when each of these events is invoked will be important in properly manging my application state and resources.
Next I moved on to MainPage.xaml. Looking at the XAML, I found nothing surprising. Some namespaces I wasn’t familiar with, but they were fortunately pretty well-named (i.e. Microsoft.Phone.Controls seemed pretty obvious what its main purpose is). If you haven’t worked with XAML before, then that will likely be what you spend most of your time on. I put off learning XAML for a long time because my initial experiences with it were confusing. It certainly has a learning curve, but once you’ve gained an understanding, it is elagant and very powerful.
Aside:
It is outside the scope of this series to dive into XAML, but I will outline a quick suggestion path on how to learn XAML, as I feel that would have helped me greatly.
First, read up on Dependency Properties – I like to think of them as Property++. They are properties, but they can notify the world when their value changes and also allow data binding. The type that declares the property must derive from DependencyObject
Second, read up on Attached Properties – This is essentially a dependency property, but the property is defined by another type, so you can essentially add a dependency property to any class that inherits from DependencyObject, even if you didn’t write the class.
Third, read up on Data Binding – This is very powerful, more importnatly, read up on the syntax. Understand that when you see “{Binding Path=Name}”, what is really happening is an instance of Binding is being created, and the Path property is being set to “Name”. If you can find a good article explaining how to do binding programatically (i.e. not in XAML), this starts to make a lot more sense.
Finally, take my suggestion from the beginning of this post. Find a simple application someone has written that has also provided the source code. I plan to release my code once I’m done with this series, so if you are lucky and this series is finished, skip to the last entry, there should be a link to my code. With the source code you found in hand, look at the application, make changes to the code and see how it affects the behavior.
I noticed that the XAML uses some static resources for things like style. I searched the entire solution and could not find these resources defined anywhere. These sounded pretty important, especially if I want to build an application that has a native Windows Phone experience. After some quick searching, I found the answer. Windows Phone defines some static resources by default. These do not need to be defined in your application. You can think of them as being “global”. This page is a good resource on what is available to you as a developer.
I mentioned earlier that the preview screen has some mock data on it. This isn’t something I had never done before myself, and quite honestly, I wish I had. I took a closer look and it looks fairly simple on how it was accomplished. A ViewModel class was written that the various controls on the page bind to for their data. If you take a look at the root tag in the XAML of MainPage.xaml, you will see the following line:
“d:DataContext=”{d:DesignData SampleData/MainViewModelSampleData.xaml}””
The line before declares what “d” is, it is a prefix that the runtime will ignore. This means that any property that is prefixed with “d” will not affect the application at runtime, it will; however, be respected at design time, so this means that the DataContext that is set will only be in effect at design time. DataContext is a property off of the page. It is of type object. It exists to assign an object to it that will be used for data binding. There is no requirement that this property is ever used or even assigned to, but if you intend to do any data binding, it will make your life much easier if you use it.
Back to the explanation, the above line assigns a value to DataContext as long as the application is not being executed. It assigns the MainViewModelSampleData.xaml to the data context. If you look at the file, you will see it simply uses an instance of the MainViewModel and assigns a collection of items to its Items property.
Looking at the code behind — MainPage.xaml.cs — I can see that navigation between pages is done via Uri. A call to the Navigate method of the NavigationService property will take the user to the specific page. Query strings can be used to pass data. In the provided application, the user can select an item from a list, and that causes the application to navigate to a details page. The Uri contains not only the path to the details page, but also a query string with the ID of the item selected. The details page will no doubt read this value from the query string, and display that item to the user.
Naturally I looked at the DetailsPage.xaml file next. The XAML looks pretty standard. Next I move over to the code behind file and see that a method called “OnNavigatedTo” has been overridden. That method looks at the query string to determine which item to display to the user.
The last thing I did to familiarize myself with the environment was to launch the application in debug mode. When I did this, an instance of the phone emulator started. At first it just looked like the standard WP8 interface, and it looks like it wasn’t doing anything. I then looked at the status bar of Visual Studio and noticed it was in the process of deploying the application. After playing around a bit, it turns out it takes a bit of time to start up the emulator and to load the application in the emulator.
What I found works best is to not close the emulator if I want to makes changes to the application. Simply stop debugging in Visual Studio, make your changes, then run again, the application deploys much faster which is nice if you are having to make a lot of changes in a small period of time. Note that doing it this way isn’t exactly the same as closing the emulator, but for most cases, it works just fine.
OK, enough of just poking around, it’s time to actually write some code — but that will need to wait until Day 3.
