Charlie Kindel (if you aren’t, you really should follow him) was nice enough to get me access to the tools about 3 weeks ago, despite the fact that he and his team have had plenty on their plate since going public with WP7. I have spent some time in the last few winks building and tinkering.

A little background on my dev skills. I can write basic applications, and have been known to favor Python when trying out new ideas. I have dabbled a bit with our ASP.NET MVC (MVC v2 just released – way to go guys!!) and taught myself enough C# to be dangerous. What coding I do, I do for fun and in my free time. I call it my nocturnal nerdiness, and have been logging some of my projects using the n00bnotes tag. Prior to 3 weeks ago, I had never written one line of Silverlight (or WPF for that matter) code, nor any XAML. I was really excited to have the opportunity to build apps for this mobile platform, as I once tried to get along with iPhone development, and while it’s clear that Apple has created tools that developers seem to love, I couldn’t get along with ObjectiveC. That’s a me issue, and not a statement about ObjectiveC. I get along famously with Python, but me and Ruby are not friends. That’s just the way my brain works.

With that as a preamble, I wanted to share what I have created in just the last 3 weeks, working largely in what spare time I could find when not doing my day job or dealing with an recalcitrant 8 month old girl who refuses to sleep. The main thing I want people to take away from this is that it in incrediblyeasy to built apps for Windows Phone 7. If I can figure it out, anyone can. The team has delivered a great development experience built on top of Visual Studio Express. When you fire up the development environment, everything you need is there and you are ready to go. It was a pretty painless experience to get the environment up and running, and it includes templates for Silverlight apps as well as XNA games. While I have only been able to deploy to an actual phone once, the emulator felt like a software version of the phone.

Over the next few days of Mix10, I am going to put up a few posts about my experiences with the development tools, highlighting some of the blockers I hit, how I solved them, and for some of them, how I should have solved them, which I eventually fixed during code refactoring.

In the meantime, I wanted to share a link to the current version of the code. This is my FriendLinks application, built for Windows Phone 7 [UPDATE: 3/24/10 – oh the joy of forgetting to remove commented code with your twitter pass. Ooops…code updated.] You will need the development tools in order to open, edit view. The only disclaimer I make is that the code works. Not all of it is pretty, and in some places I haven’t gone back to fix things I fixed elsewhere (i.e. walking XML for Bit.ly versus for Twitter).

This specific post is about some of the things that gave me the biggest problems in getting started. The app that I built is pretty simple. It’s meant to allow you to connect to Twitter, pull down your friend timeline, and parse the timeline looking for URLs sent by people you follow. I use Twitter for content discovery, and this is my ultimate time waster app. When you click on a link the listbox, some additional calls are made via the Bit.ly API, and the TweetMeme API, to get additional information like the number of retweets that article has, the title of the page referenced and the number of clicks as tracked by Bit.ly.

Making Async Calls to Web Services

Wow, what a huge pain this was for me to figure out. When you do some web searching about how to connect to web services in C#, you will invariably find yourself staring at content about WebClient class. I couldn’t make this work for me, and now that I am 3 weeks into it, I can’t remember what the specific issue was. Something about Twitter not doing Basic Auth correctly, and needing to set the username and password in the header, necessitating the use of NetwrokCredentials.

In any event, I had to use the HttpWebRequest. This is where things got challenging for me, since I had never done any async programming in C# or Silverlight. [Apologies for the wonky formatting in the code samples, but I have a narrow blog and the style isn’t doing auto wrap]

Sorting out how to correctly get the async call done, and then set up the callback, was where I completely threw a rod. Basically, you need to set up a web request to happen on its own thread, and then you need to assign a delegate function to process the response. Figuring out how to do this took me 2 days, mostly because I didn’t know what questions to ask, or what terms to use when searching online, and in this specific case, only code that I did discover was useless for me because I was trying to learn something new and didn’t understand the samples I found.

Looking at the call, you may notice that I am using the REST API from Twitter, and setting the since_id and count variables to ensure that I am getting the data that I want. This is so I can reuse this function to make subsequent calls while the app is running and only get the new tweets. Twitter makes things pretty easy to get the data you want.

Here’s how you handle the async callback function to actually issue the HTTP request and process the data which comes back:

[note – this is a code snippet, and won’t work without closing that try{} and having an associated catch block] What you end up with in the responseString is well formatted XML returned from Twitter. Once I understood how to make these async calls, I was able to write any number of functions which handled getting data from other web services.

XML Processing

Oh man, what a complete cluster this was for me. The Twitter API is well documented, and so I figured it would be pretty easy to parse the XML. Unfortunately, I didn’t know what was available to me in Silverlight on Windows Phone 7 Series, so I started by asking Bing.

First things first, especially for those who are not well versed in Silverlight or Visual Studio. If you want to parse XML, do yourself a huge favor and add a reference (“Project/Add Reference”) to System.Xml.Linq in your project. Do that first. With that, you can use XDocument. Do it not, and you will have code that looks like this (focus on the while loop at the bottom):

Let’s talk about what’s going on here. It turns out that if you ask Bing “.net read XML,” you will get posts and articles that talk about how to use XmlReader. The first 10 links that come back all seem to point to this as a pattern for reading XML in .NET. Not knowing what I was doing, I figured that this was the way to do it. And so I set about building the code that would read XML and check for certain elements along the way.

This is not the right way to do this. Absolutely, unequivocally not the right way. As in, please, please, please don’t put yourself through this. Never mind that if you get back poorly formed XML you have problems. Or that sometimes the reader just decides not to work correctly. Or you get some weird data back, and you throw an exception, which is non-deterministic to find because the bug only surfaced when Dave McClure posted something strange in his stream. Oh, and the fact that Twitter use an “id” both for users and status, which makes the stream read a bit strange and easy to get the wrong value for statusID or userID. Or that you end up with an unwieldy set of IF statements to parse your XML. So to recap, don’t read XML this way. Bad. Very bad.

The right way to do things is to put the resposeString into an XDocument, and then perform a LINQ query against it. You gain access to the XDocument via System.Xml.Linq, which is why I suggested adding that as a reference to your project.

Isn’t that just so much prettier? I had used LINQ before, but it was to access SQL objects, and for whatever reason I didn’t think to use LINQ to XML. Shame on me. n00bnotes hall of fame for sure.

Exceptions on the UI Thread

This one is very simple to understand and fix once you know what is going on, but a complete pain if you don’t understand why. The “why” is that there is one UI thread in Silverlight. If you want to update anything that is UI related, and your code isn’t being executed by the UI (for example, a delegate callback function), then you need to get that code onto the UI thread. This is very, very simple to do, but I didn’t know how to ask the question to get the answer, and so it took me a little while to find the answer.

Dispatcher.BeginInvoke(() =>
{
//these are some basic UI changes that you can make once on the UI thread
grdTweets.Visibility = System.Windows.Visibility.Collapsed;
grdLogin.Visibility = System.Windows.Visibility.Visible;
txtPassword.Password = String.Empty;
twitHelp.SetUserPass(txtUsername.Text, txtPassword.Password);
});

The lambda function off the Dispatcher is how you get your UI updating code onto the UI thread. Just put your code in between the {} and you are all good.

My next post will talk about how I built out the listbox, which is the main piece of UI functionality, and the fun and interesting discovery process on how to use data binding. I now love data binding. A couple of days ago I hated it with a passion, but mostly because my code was wrong, I didn’t understand exactly what I was doing – more like just enough to sort of make things work, but not quite right enough that I noticed, and didn’t know how to debug. So much fun. 🙂

You bet Donn. I will be posting more later this week. I don't claim to be the best developer in the world, and my code may not be 100% “right” but I hope that what people take away from this is that it really is that easy to build apps for this platform.

You say “Something about Twitter not doing Basic Auth correctly, and needing to set the username and password in the header, necessitating the use of NetwrokCredentials.”

The problem really isn't with Twitter, the spec defines that Basic authentication is carried out by sending a Base64 encoded “username:password” string in the HTTP headers as a part of an authenticated request (http://en.wikipedia.org/wiki/Basic_access_authe…).

As far as I know your problems are caused by a bug in WebClient, where webclient does not correctly process the Credentials property. I am sure they will fix it in the coming days, but the current problem with WebClient and credentials extends to all services which support basic authentication, not just Twitter.

@Aurojit – thanks for making that clear. I will go back in and fix the post this evening. I also found another bug which I plan to post later tonight once I get clearance from the dev team, but for this use case, it's important to know it's a bug and how to handle.

I'd like to think that Windows Phone 7 will get develoeprs excited about building new experiences and applications, and customers excited about experiencing their mobile phone in a new, and more personal, way. Time will tell, but I am a believer.

Don't you think it would be better to load an XDocument or XElement with an XmlReader instead of reading the stream to end first. This would use the advantages of using a stream.Thanks for posting your experiences.