I’ve uploaded this tutorial as a zip file. I tried to github it, but I’m inching up on 1 hour of trying to figure out what the hell I’m doing wrong.

Download this Tutorial Project

I’ve tried to make this a full featured tutorial, so if you just want to get to the code, head down to the “Let the User Login To Facebook” section.

Get Your Facebook Key

Go to http://developers.facebook.com and log in with your Facebook account. Give them the permissions they need and go to the “Apps” tab. Click on “Create new App”

Fill in the App Display Name and the App Namespace and do the verification. Then you’ll get to a page that gives you your App ID and App Secret.

Don’t worry about anything else here… you don’t need to select anything in the “how your app integrates with Facebook” section to do this tutorial. If you’re using Facebook integration to do some basic login and simple posting, you could probably just use the Website option.

Also, click the “Graph API Explorer” on the left and keep that open. We’ll come back to that in a moment.

Add Facebook C# SDK

Download the Facebook C# SDK and extract it. Go to the “sl3-wp” folder and unblock the Facebook.dll file (right-click => Properties=>click “Unblock”)

Open up your project (for the example, I used the Visual Studio 10 “Windows Phone Databound Application” template) and right-click on “References => Add References…”. Click “Browse” and navigate to the Facebook.dll and add it to your project.

Build Facebook Login UI

We’ll do this quick here (no MVVM, no bindings) but in later versions I’ll integrate this into a more formal project.

Open your project in Blend. For this quick-and-dirty tutorial, we’ll just add another page title and another panel for the UI we want to show when the user is logged in and set the Visibility to Collapsed on those. Our visual tree should look like this.

In our loginPanel, we’re going to add a button and a WebBrowser to our panel. Set the button (containing “sign in using facebook” in the content) to the top and the WebBrowser to fill the panel. For a little flare, I’m going to add “ShowFacebookLogin” and “HideFacebookLogin” animations. My login screen now looks like this (the WebBrowser will animate in when we press the button).

When we get our data back, we’re going to tell the user it worked by showing their name and their Facebook avatar. So we’ll add a Grid with an Image and a TextBlock to display the user, along with a friendly “Hello”. (Make sure to name all these things so that we can update them from the code.)

OK… out UI is simple, but ready to roll. Now let’s do something when the user clicks the sign-in button. Go to the “Click” event and add a method like “StartFacebookLogin”.

Let the User Login to Facebook

Add “using Facebook;” to your references at the top of your MainPage.xaml.cs file. Now, add the following properties:

private FacebookClient _asyncFbClient;
private string _appID = "get from your facebook app page";
private string _appSecret = "get from your facebook app page";

Now go to your StartFacebookLogin method and add the following (explained at the end).

private void StartFacebookLogin(object sender, RoutedEventArgs e)
{
    string[] extendedPermissions = new[] { "user_about_me", "publish_stream" };

    var oauth = new FacebookOAuthClient { AppId = _appID, AppSecret = _appSecret };
    var parameters = new Dictionary<string, object>
                    {
                        {"response_type", "token"},
                        {"display", "touch"}
                    };
    if (extendedPermissions != null && extendedPermissions.Length > 0)
    {
        var scope = new StringBuilder();
        scope.Append(string.Join(",", extendedPermissions));
        parameters["scope"] = scope.ToString();
    }

    var loginUrl = oauth.GetLoginUrl(parameters);

    webBrowser.Navigated += new EventHandler<NavigationEventArgs>(CheckForAuth);
    webBrowser.Navigate(loginUrl);
}

Remember how I told you to keep the Graph API open? Here is why. It has a big list of all the extendedPermissions that you can tell Facebook you want from the user. Here, we’ve asked for basic user information and the ability to publish to the user’s stream. Ask for only the permissions you need. The user can see the details of your permission request and may reject it if you ask too much.

Next, we create our OAuth client using out AppID and AppSecret and create a Dictionary of parameters communicating to Facebook the details of our request (for example, setting “display”, “touch” tells Facebook that we want the mobile interface.

We write out permission request into our parameters and then get a login url, which we will direct to our webBrowser. Here is what we will should get.

At the point Facebook walks the user through their login and, when they are done, it hands us back the access token we’ll need to get the user info and let the user make posts through our app.

This is why we attached the CheckForAuth event handler to our webBrowser. When we navigate to a new page, we’ll check to see if we got an access token using this code:

private void CheckForAuth(object sender, System.Windows.Navigation.NavigationEventArgs e)
{
    FacebookOAuthResult result;
    if (FacebookOAuthResult.TryParse(e.Uri, out result))
    {
        if (result.IsSuccess)
        {
            IsolatedStorageSettings Settings = IsolatedStorageSettings.ApplicationSettings;
            if(Settings.Contains("MyFacebookAccessToken"))
                Settings["MyFacebookAccessToken"] = result.AccessToken;
            else
                Settings.Add("MyFacebookAccessToken", result.AccessToken);
            Settings.Save();
            _asyncFbClient = new FacebookClient(result.AccessToken);
            _asyncFbClient.GetCompleted += new EventHandler<FacebookApiEventArgs>(_asyncFbClient_GetCompleted);
            _asyncFbClient.GetAsync("/me");
        }
    }
}

If the Uri does contain a Facebook OAuth result and it is a success, we save the access token to our settings and then immediately use it to get the most basic user information.

The problem we have right now is that we have no class to structure the data that comes back. So get that all squared away.

First, right-click on “References” and select “Add Reference…”. Select “System.Runtime.Serialization”.

Next, add a class to your project (I added mine in a folder called “Models”) and name it FacebookUser.cs.

In that class, add the following code

[DataContractAttribute]
public class FacebookUser
{
    public FacebookUser() { }

    private string _id;
    [DataMember(Name = "id")]
    public string ID
    {
        get { return _id; }
        set { _id = value; }
    }

    private string _name;
    [DataMember(Name = "name")]
    public string Name
    {
        get { return _name; }
        set { _name = value; }
    }
}

The sample project has a much larger (although still incomplete) version of this model. But this one will do for our purposes.

We’ll make our “GetCompleted” event handler (remember that?) look like this:

void _asyncFbClient_GetCompleted(object sender, FacebookApiEventArgs e)
{
    FacebookUser _fbUser = e.GetResultData<FacebookUser>();

    Deployment.Current.Dispatcher.BeginInvoke(() =>
    {
        fbName.Text = _fbUser.Name;
        BitmapImage bi = new BitmapImage(new Uri("https://graph.facebook.com/" + _fbUser.ID + "/picture"));
        fbAvatar.Source = bi;
        HideFacebookLogin.Begin();
    });
    _asyncFbClient.GetCompleted -= _asyncFbClient_GetCompleted;
}

What we’ve done here is shove our data into a FacebookUser model. Then we use BeginInvoke to bring ourselves back to the UI thread and set all the properties we want.

Finally, we start the animation that hides the login data and shows that our Facebook login was a success.

Boom!

“Operation not permitted on IsolatedStorageFileStream.”

And I couldn’t find anything about it other than a very generic “Looks like a threading problem” answers.

Long story short:

I was, in rapid succession, running the same save code twice. What I think happened was that the IsolatedStorageFileStream was still open and trying to save when I tried to get it to save again on another thread.

That’s my guess. I figured I’d toss up this short post on it before I forgot what the problem was.

Most of the .NET code I look at uses WebClient to do HTTP requests. But using WebClient can negatively affect the UI thread in Windows Phone 7, so we have to do something a little more like this:

   1:  public void MakeSomeHTTPCall()

   2:  {

   3:      var request = (HttpWebRequest)WebRequest.Create("http://my.awesomewebsite.com");

   4:      request.Method = "GET";

   5:      request.BeginGetResponse(new AsyncCallback(GetSomeResponse), request);

   6:  }

Easy enough, right?

Not so fast!

If the user starts a request and then hits the “power” button on their phone, this will cancel that request. How can we tell when this has happened?

Well, we handle the response to this request in the “GetSomeResponse” method, so let’s take a look at that.

   1:  private void GetSomeResponse(IAsyncResult MyResultAsync)

   2:  {

   3:      HttpWebRequest request = (HttpWebRequest)MyResultAsync.AsyncState;

   4:      try

   5:      {

   6:          HttpWebResponse response = (HttpWebResponse)request.EndGetResponse(MyResultAsync);

   7:          if (response.StatusCode == HttpStatusCode.OK && response.ContentLength > 0)

   8:          {

   9:              using (StreamReader sr = new StreamReader(response.GetResponseStream()))

  10:              {

  11:                  // This result string below is going to be whatever I get back,

  12:                  //   be it JSON or XML or whatever

  13:                  string result = sr.ReadToEnd();                        

  14:              }

  15:          }

  16:      }

  17:      catch (WebException e)

  18:      {

  19:          if (e.Status == WebExceptionStatus.RequestCanceled)

  20:              MessageBox.Show("Looks like your request was interrupted by tombstoning");

  21:          else

  22:          {

  23:              using (HttpWebResponse response = (HttpWebResponse)e.Response)

  24:              {

  25:                  MessageBox.Show("I got an http error of: " + response.StatusCode.ToString());

  26:              }

  27:          }

  28:      }

  29:  }

OK… let’s walk through this.

First, we get our request from the MyResultAsync.AsyncState (line 3), which we’ use to get our response (line 6). Now we can get a HTTP status code (like “200 – OK” or “404 – Not Found”) from this response, right?

No, we cannot. If the response is something other than OK, it will trigger an error and we will jump to the “catch” with a WebException error (line 17).

If we’re coming back from a tombstone (or Fast Application Switching, which will also cancel the request), the WebException status will be “RequestCanceled”. We test for that case and do something special for it (depending on the app, we may want to automatically re-do the request to ensure that we don’t put the user out of sorts by an errant power button press). Otherwise, we know it’s a normal HTTP status code and we can deal with it that way.

So… you want to add a cookie to your Windows Phone 7 Silverlight HttpWebRequest. Guess what? It sucks to be you! Or, at least, it sucked to be me because I couldn’t find anything on how to do this that worked.

I was working on a project that requires the user to authenticate and, on authentication, sends back a token (unique to that user) to be attached as a cookie for further authentication. However, when I attached the cookie and made my next request, it made that request without the authorization header. Our server said “Hey, looks like you’re not authenticated, I will now forget about that last cookie because you obviously didn’t get it. Have a new one!”

First I’m going to show you things that don’t work.

Didn’t Work: Adding An Empty Cookie Container to the Request

public void DoSomeCRUD(string userName, string pass)
{
    HttpWebRequest request = System.Net.HttpWebRequest.Create("https://myurl.com") as HttpWebRequest;
    if (HasSavedCookieContainer)
        request.CookieContainer = SavedCookieContainer();
    else
        request.CookieContainer = new CookieContainer();
    request.Credentials = new NetworkCredential(userName, pass);
    request.BeginGetResponse(new AsyncCallback(GetMyResponse), request);
}

private void GetMyResponse(IAsyncResult MyResponseAsync)
{
    HttpWebRequest request = (HttpWebRequest)MyResponseAsync.AsyncState;
    HttpWebResponse response = (HttpWebResponse)request.EndGetResponse(MyResponseAsync);
    // this method save the cookie container to IsolatedStorage 
    // so I can attach it to the request the next time I open the app.
    SaveCookieContainer(request.CookieContainer);
}

The saving worked, the cookie container came back just as I saved it. And then… it didn’t work. It was as if the cookie didn’t exist.

Didn’t Work: Ripping The Token Out Of the “Set-Cookie” Header

public void DoSomeCRUD(string userName, string pass)
{
    HttpWebRequest request = System.Net.HttpWebRequest.Create("https://myurl.com") as HttpWebRequest;
    if (IsolatedStorageSettings.ApplicationSettings.Contains["MyToken"])
    {
        string myToken = (string)IsolatedStorageSettings.ApplicationSettings["MyToken"];
        Cookie c = new Cookie("MyCookieName", myToken, "[valid path]", "[valid domain]");
        request.CookieContainer = new CookieContainer();
        request.CookieContainer.Add(new Uri("http://myurl.com"), c);
    }
    else
        request.CookieContainer = new CookieContainer();
    request.Credentials = new NetworkCredential(userName, pass);
    request.BeginGetResponse(new AsyncCallback(GetMyResponse), request);
}

private void GetMyResponse(IAsyncResult MyResponseAsync)
{
    HttpWebRequest request = (HttpWebRequest)MyResponseAsync.AsyncState;
    HttpWebResponse response = (HttpWebResponse)request.EndGetResponse(MyResponseAsync);
    // this method looked for "Set-Cookie" information in the header
    // and the pulls out the token data by brute force and save the
    // token as a string
    if (ResponseHasSetCookieInHeader(response))
    {
        string rawToken = GetTokenFromResponse(response);
        IsolatedStorageSettings.ApplicationSettings["MyToken"] = rawToken;
        IsolatedStorageSettings.ApplicationSettings.Save();
    }
}

The save worked here too, but the same result… it was like the cookie didn’t exist.

This Worked: Adding the Cookie as a Header

Finally we added the token and the credential information as header items. This finally worked.

public void DoSomeCRUD(string userName, string pass)
{
    HttpWebRequest request = System.Net.HttpWebRequest.Create("https://myurl.com") as HttpWebRequest;
    if (IsolatedStorageSettings.ApplicationSettings.Contains["MyToken"])
        request.Headers["Cookie"] = "MyTokenName=" + (string)IsolatedStorageSettings.ApplicationSettings["MyToken"];

    request.Headers["Authentication"] = "Basic " + Convert.ToBase64String(StringToAscii(userName, pass));
    request.BeginGetResponse(new AsyncCallback(GetMyResponse), request);
}

private void GetMyResponse(IAsyncResult MyResponseAsync)
{
    HttpWebRequest request = (HttpWebRequest)MyResponseAsync.AsyncState;
    HttpWebResponse response = (HttpWebResponse)request.EndGetResponse(MyResponseAsync);
    // this method looks for "Set-Cookie" information in the header
    // and the pulls out the token data, saving it to Isolated Storage
    if (ResponseHasSetCookieInHeader(response))
    {
        string rawToken = GetTokenFromResponse(response);
        IsolatedStorageSettings.ApplicationSettings["MyToken"] = rawToken;
        IsolatedStorageSettings.ApplicationSettings.Save();
    }
}

For the sake of giving credit, here is the StringToAscii method for the Authentication, tweaked from this StackOverflow answer from Hans Passant

public static byte[] StringToAscii(string userName, string pass)
{
    string s = userName + ":" + pass;
    byte[] retval = new byte[s.Length];
    for (int ix = 0; ix < s.Length; ++ix)
    {
        char ch = s[ix];
        if (ch <= 0x7f) retval[ix] = (byte)ch;
        else retval[ix] = (byte)'?';
    }
    return retval;
}

Here’s Nick Harris with a handy set of static methods for getting the following unique IDs:

• Device Manufacturer ID
  • DeviceExtendedProperties.TryGetValue(“DeviceManufacturer”, out someObject);
  • example: “HTC”
• Device ID
  • DeviceExtendedProperties.TryGetValue(“DeviceUniqueId”, out someObject);
  • requires ID_CAP_IDENTITY_DEVICE in the app manifest which will trigger a warning to users when they install the app
  • a byte[], converter to a string will looks like
    “12345678901234567890123456789012345678901234567890123”
• Anonymous Windows Live ID
  • A 32 character subset at offset 2  of the results of
    “UserExtendedProperties.TryGetValue(“ANID”, out someObject)
  • requires ID_CAP_IDENTITY_USER in the app manifest which will trigger a warning to users when they install the app
  • looks like “00FF00FF00FF00FF00FF00FF00FF00FF”

However, if you just need any unique identifier (not necessarily a device ID), you can always set and store a new global unique identifier using:

Guid.NewGuid();

which will return a 128-bit integer that will look something like this:

“e81644f1-46b6-4994-2903-1d1f1440c130″

This will not cause warnings to appear when the app is downloaded because it isn’t a constant identifier to that specific device.

Windows Phone 7 Push Notification Project Files (github)

The goal of this post is to provide a sample Push Notification application that is

• easy to test
• good architecture
• provides a sample web app for testing your push code (part of the delay has been because I’ve been trying to be a perfectionist on that web app. I’ve decided I’m never going to get around to making it perfect so this is the best I can do with the time I have)

Too many of the sample apps I’ve seen shove the push notification code in the xaml code-behind, leaving it to us to separate out the bits and translate it into a real project. This project uses MVVMLight binding and an event-driven architecture to get the push stuff working.

So… let’s dig into it.

I created a class called PushNotificationService that held a number of helpful little variables and objects. The most important variable here is

private static string _pushChannelName = "SampleAppNotification";

This name will delineate our push service from other services. If something weird happens and your push service stops working, the first thing you should do is change this string.

Next, we have a method that allows us to control when we get the push notification Uri. As an overview of what we’re doing,

1. See if we already have a valid HttpNotificationChannel (the object that will control the push permissions and handle information from the Microsoft Push server)
2. If we do have a valid HttpNotificationChannel, make sure we got the channel Uri correctly (the uri we will send out push notifications to). If we did, SUCCESS! Otherwise, go to step 3.
3. Set the event handlers so we can handle when we get a new channel Uri back from the Microsoft Push server.
4. Ask the Microsoft Push server for a new channel Uri.
5. Set the HttpNotificationChannel up to handle the right kind of push notifications.
6. Handle the returned uri from the Microsoft Push server & send it to the rest of the app.

Step 1

_notificationChannel = HttpNotificationChannel.Find(_pushChannelName);

Step 2

if (_notificationChannel.ChannelUri != null)
{
      // Success! We run the event to send that info back to our ViewModel 
      RaiseGotPushUri(_notificationChannel.ChannelUri);
}

Step 3

else
{
    _notificationChannel = new HttpNotificationChannel(_pushChannelName);
    _notificationChannel.ChannelUriUpdated +=
         new EventHandler<NotificationChannelUriEventArgs>(_notificationChannel_ChannelUriUpdated);
    _notificationChannel.HttpNotificationReceived +=
         new EventHandler<HttpNotificationEventArgs>(_notificationChannel_HttpNotificationReceived);
    _notificationChannel.ErrorOccurred +=
         new EventHandler<NotificationChannelErrorEventArgs>(_notificationChannel_ErrorOccurred);

}

Step 4

_notificationChannel.Open();

Step 5

BindNotifications(_notificationChannel);

Binding Details

In the pre-Mango push notifications, there are 3 kinds of push notifications and we have to announce what kind of notifications we plan on handling.
First, there are toast notifications, which look like this (stolen from Shawn Wildermuth):

Toast notifications consist of

• a title (“Toast Message” in the example above)
• a message (“This is from the server”)

To bind them, we simply type:

_thisChannel.BindToShellToast();

Tile notifications will only show up if the user has pinned the application to the front application tile board on the phone. I like to split Tile notifications into two types because we have to handle them differently in the code.

The first kind of tile notification is what I call “simple” Tile notifications. With simple Tile notifications, we can change a number and title on our app tile. The new title will show up where the title always shows up (at the bottom left) and the number will show up in a black circle at the top right.

Doing this much is simple:

_thisChannel.BindToShellTile();

But then there are Live Tiles, which allow us to send a whole new image to the tile to change it in a more holistic way to represent some push data. (We can still update numbers and titles too.) Live Tiles, however, require that we whitelist all the websites that might want to send an image to our phone. So we need to create a collection of whitelisted domains and add that to our tile binding.

System.Collections.ObjectModel.Collection<Uri> permittedImageHosts = new System.Collections.ObjectModel.Collection<Uri>();
permittedImageHosts.Add(new Uri("http://www.designersilverlight.com"));
_thisChannel.BindToShellTile(permittedImageHosts);

If you’re going to use my handy-dandy WP7 Push Tester, make sure you whitelist the exact domain above.

And that’s it… that’s all we need to do to get everything bound and ready to go! All we need now is to get the Uri from the Microsoft Push server so we know where to send our Push Notifications to.

Step 6

void _notificationChannel_ChannelUriUpdated(object sender, NotificationChannelUriEventArgs e)
{
      RaiseGotPushUri(e.ChannelUri);
}

This will run when we get the updated Uri back and we just send it in our event, which the ViewModel is listening to.

I’ve really streamlined the code in this blog post to deal with just the bare essentials. If you want to look at the project in detail, you can download it here.

Now, all we have to do is start testing it.

You can test it using my WP7 Push Notification web app. I’m also working on another post that walks through creating a push notification system using PHP, but in the meantime you might want to check out this PHP library that I used.

1. Windows Phone 7 Push Notifications (10,000 Foot View)
2. Implementing Push Notifications on a Device (with Project code)
3. Testing Push Notifications On My Device Without Writing a Goddamn Web Service (Also, How To Write A WP7 Push Service in PHP)

Windows Phone 7 Push Notifications (10,000 Foot View)

The Windows Phone 7 push notification is actually an extremely elegant way of doing push notifications. Personally, I love it. I’ll walk through the steps conceptually here and then mirror the steps in the code post.

(Note to experts: I may be getting some of the details about how this works in the underlying architecture wrong. However, this is how it seems to me that it works and it makes sense this way.)

Step 1: Say “Hey, phone! I want to send you push notifications about some stuff.” When you do this, you’re doing it with a couple of conditions. The first is that you’re giving your specific push service a name (like “Bob” but hopefully a little more specific).

Next, you’ll need to determine if you want to use the “Toast” notification or the “Tile” notification or the “Raw” notification or some combination of these three. When you know what kind of notifications you want, you’ll basically write a magic piece of code which communicates to the magical push notification fairy, who, in return for your good deeds, gives you a device/application specific URL that you will use to send notifications to your phone.

You think I’m kidding. I’m not. As a preview, the code you need to write is: “myPushStuff.Open()”. And that’s it. Then you just wait for the magical push notification fairy to give you the URL you’ll use to send notifications to your phone.

You don’t actually need to send information about toast and tile to the push registration service. However, if you decide later on thatyou actually wanted to send a toast notifications, not a tile notification, your old URL won’t work… you’ll need to save a new one. Don’t know why or how exactly this happens… just passing along helpful information.

If you’re looking for information about the difference between tile, toast and raw notifications, the image below was stolen from the msdn article that talks about the differences. Go read about it there… I won’t stoop to copying and pasting all their excellent information into my blog post.

Step 2: Once you have your magical URL, save it in such a way that whatever webservice you’re using can recognize which phone it’s tied to. Maybe you’re saving it along with a username or with a zip code (like with a weather service). In any case, you’ll want to be able to send the right push notifications to the right phones.

When the time comes to send the notification, your webservice will need to send an XML chunk created for your notification (see details here) to the phone-specific URL. Then, the Microsoft Push Notification Service handles your push request and forwards it to the phone, sending a response telling you that it worked (or didn’t work).

I’ve got my gripes with Windows Phone 7, but the push notification implementation ain’t one of them. It’s very straightforward and can be implemented on the phone with very little code and on a server with similar ease. If you’re a newbie mobile developer and this looks complicated, go try to implement push notification on Android or iOS. For all you Android and iOS people out there I would like to say:

Ha.

The next post will walk through the steps to register your app for push notifications. I’ll post a link to it in this post when I get it up.

Also, check out the MIX Outsider website, built with loving care by Jason Alderman (Twitter: @justsomeguy)

If you download the app above, you’ll notice it is in the *.xap format, which is the format for all Silverlight based Windows Phone 7 mobile apps. Perhaps you’ve never side-loaded a WP7 app before or perhaps you don’t have a Windows Phone 7 device. Fear not! If you have the Windows Phone 7 developer tools, you can load the app to your emulator and just run it from there.

The following 90 second video show you how. It really is so easy that it takes less than 90 seconds.

Sideloading the MIX11 Outsider App To The Emulator from Matthias Shapiro on Vimeo.

Have fun and I’ll see you at MIX11!

Download MIX Outsider (for sideloading)

MIX11 Outsider is the MIX11 app that doesn’t care about your schedule. It cares about something more important: the people you want to talk to, meet, or otherwise hang out with at MIX. Using a map of the conference floor and a simple “battleship” mapping metaphor, you can tweet, email or text your position at the conference. Don’t eat alone in awkward silence… instead find that Twitter friend who doesn’t have a clear picture of themselves in their avatar. Don’t spend half your pre-keynote time waving your hands in the air. Just tap where you are on the map and send out a link like this one.

http://mixoutsider.com/H60

And a quick video of the application in action

MIX11 Outsider Windows Phone 7 App Screencast from Matthias Shapiro on Vimeo.

I wish I could introduce this app with a bit more fanfare, but I’ve been waiting since Monday for my app to get through the submission process. I was hopeful that, if I got it in a week before MIX, I would make it in time for the conference. At the moment, that hope fades. As a result, until I can get the app into the Marketplace, it will be available here for download so Windows Phone 7 devs can sideload it onto their phones

MIX Outsider (for sideloading)

(Don’t know how to sideload an app? James Ashley has a great post on sideloading to the emulator or to a device.)

The funniest thing is that the “big idea” in this app isn’t really even the app itself. The app is really just the most complete extension of the original idea.

You see, last year at MIX 10, there was a massive coordination effort among my colleagues to try and sit together during the keynote talks. This led to e-mails, text messages, phone calls, and tweets with hard to understand directions like

“We’re 12 rows from the back in the middle of the far right side as you come in (stage left).”

But my decision to do something about it came when a friend spent 10+ minutes with his lunch plate in hand trying to find our table. I thought, “This is absurd… there must be a better way to find people.”

Unfortunately, my GPS did not work very well inside the conference… which didn’t really matter since (I assume) no one wants to open up a Google Maps or Bing Maps to find people inside a building.

So Jason Alderman and I discussed the problem and thought that it might be fun to do a “Battleship” metaphor for finding people at MIX11, laying the grid on a map of the conference floor. Based on that concept, I wrote a little application that allows user to tap to see where they are and send that information out. It then collects all the messages sent out with the app and shows them on the map with the users’ twitter avatars.

Users can send public messages using Twitter or private messages via text message or e-mail. Private messages are not broadcast and cannot be seen by anyone. They contain only the helpful link to the MIX Outsider reference website (designed by the aforementioned Jason Alderman) without any identifying information.

But my biggest hope is that this application gives people a point of reference so that even people who don’t have a Windows Phone 7 device can see the tweets, reference the website and still find the people they want to meet at MIX11.

So I created a little XAML icon that is a very rough approximation of the front Windows Phone 7 screen. I used shapes and theme-variant brushes so that the icon changes to represent whatever theme the user has in place on their phone.

Because the the icon is so small (48-by-80 px), I used only basic shapes and one custom path shape to represent the “maps” application. I also did everything on a “Canvas” in order to try to trim off as much layout computation time as possible. You could make it with a Grid and then scale it to your heart’s content. Probably won’t make a huge difference, but I’m paranoid about resources in my phone apps these days.

Here are a couple examples of how the icon could look, depending on the user’s theme choice:

All from the same XAML.

For the ShopSavvy version, I put a tiny little ShopSavvy icon at the top. In the code below, I took it out so the top right-hand will simply be a blank box. Or you would put a tiny version of your own app icon there.

Not much. Just something fun that I thought might be fun to share