WP7: Checking Weather Forecast Using YQL

I touched upon yahoo query language (YQL) interface in my last post. Today, I will show some quick practical uses of YQL and demonstrate how easy it is for the programmers to tap into this information.

For today’s example, we will examine the table named ‘weather.forecast’, which is available in the YQL interface.

Head over to the YQL Console to examine the parameters to be used for ‘weather.forecast’.


As shown in the screenshot, there is one parameter named ‘location’ that is required for querying data from this table.

The complete URL would look like below:


Windows Phone Application

Create a new ‘Windows Phone Application’ project in Visual Studio.


Preparing the User Interface

The user will provide the location for which the weather forecast is to be displayed as input.

For this, I added a horizontal StackPanel with a TextBox and a Button into the MainPage.xaml.

For displaying the results, I used a WebBrowser control, as some of the data for ‘weather.forecast’ is returned as HTML.

The XAML listing for the UI is here:

Getting data from YQL

The user enters the zip code for which weather forecast has to be displayed and press on ‘GO’ button.

The program takes this location, construct the correct URL and make a web request to retrieve the data from the internet.


Windows Phone SDK provides two options to make a web request and get data from the internet, WebClient and HTTPWebRequest. See here for more information.

For this example, I used the WebClient API for it’s inherent simplicity as this is a post more to demonstrate the YQL than about performance.

Since the program did not specify a output format, JQL returns XML by default. The output format can be specified as JSON by adding  parameter to the original URL.


Parsing the XML is made simpler by the XDocument class provided in the System.Xml.Linq namespace.

Displaying the results

WebClient returns data on the same thread, so it can directly access the UI elements. On the other hand, HTTPWebRequest returns data on a different thread and the result has to be marshaled back to the UI thread. Since data is returned on a different thread, HTTPWebRequest has the advantage of not locking up the UI thread when it is processing.


The complete MainPage.xaml.cs code behind:

WP7: WebClient and HTTPWebRequest

Windows Phone 7 SDK has provided two classes for consuming resources from the web. WebClient and HTTPWebRequest.


HTTPWebRequest is a low level API for web requests. Unlike WebClient, it allows to tinker some of the HTTP aspects like cookies and user agent.

One major advantage of HTTPWebRequest is that it returns on another thread, which comes in handy for large web requests. It will not lock up the UI thread allowing the UI to remain responsive during the request. Since the response is returned on another thread the program should marshal the response back to the UI thread.

HTTPWebRequest is created by the static method HTTPWebRequest.Create().

Call the EndGetResponse() to get the WebResponse, which will contain the stream to read the response.


WebClient is a higher level abstraction of the web request. It wraps the HTTPWebRequest to provide a more easier API to make web requests.

WebClient has a built in mechanism to report progress of the request in percentage. WebClient runs on the same thread, so programs don’t have to use the dispatcher to pass data back to the UI thread.

However, since the WebClient runs on the UI thread, it can make the UI unresponsive if the program makes a long running web request.


I think there is a place for using both the classes. Being aware of these differences helps to choose the best one for a given situation.

Windows Phone 7: Navigation

Web developers will find themselves in familiar territory with the navigation in Windows Phone 7.

NavigationService Class

Navigate to another page:

Navigate to another page (with parameters):

NavigationContext Class

If a parameter was passed to the destination page using query string, NavigationContext class allows to read the query string as follows

Navigation History

Navigation history is exposed as a read-only enumeration through the property called NavigationServices.BackStack,

There are additional methods exposed for going back and forward one step at a time. It is a good practice to check for the CanGoBack and CanGoForward property before calling the navigation methods to make sure there is more in the history to go back or forward.