Today I became the proud owner of a Nokia Lumia 928. Unlike my last razzle-dazzle for an off-contract phone, this time it was quite straightforward. Verizon has had this phone at the cheapest of any place off-contract. Only recently did prices fall at Amazon to match them. Since there’s a Verizon store just down the road from me, the choice was easy.

The struggle I had in getting this phone was that it seemed that Nokia (or Verizon) are really pushing the white model over the black one. So much so that I was told by a VZW rep that when the Nokia rep came to their store, she didn’t even know if VZW was going to sell anything other than the white version. Sure enough, try and get your eyes on a black one and you’ll see what I mean. They seem to only be available online, and rarely for “in store pickup” or anything of the like.

So I went to my local VZW with intentions of just seeing & handling a 928, knowing it’d be a white one. When I saw it I definitely knew I’d be getting one. The more I thought about it, it occurred that while I’d prefer to have black, white might just be the conversation starter that Windows Phone needs. So I opted for the white as 1) I could get it right there and then and walk home with it in my hand, 2) I think this might afford me more opportunities to show off Windows Phone to the masses, and 3) the ever-sly salesman provided me with a $20 black gel case.

Let’s get on to the first impressions, shall we?

Hardware

The outer casing is nice, buttons are pronounced enough to easily find and manipulate. After having the HTC Trophy I certainly appreciate this. The button layout on the 928 matches that of the 822 with all 4 buttons (volume up/down, power, camera) running along the right-hand side (as you look at the screen upright). The one thing I can’t for the life of me understand is what on earth made them put the micro USB port on the top of it. In some instances I can see where this might make sense, but overall it seems quite awkward. Especially when you put it in your car’s dash mount and try and plug in a charger – I’m working around this by just having the phone sit horizontal in the mount all the time now instead of vertical. If Microsoft eventually makes the Windows Phone start screen workable in landscape mode (I suggested this before WP7 Mango) this will pose much less of an issue.

The battery is freaking huge. I don’t think you really realize how much time you get out of a 2000mAh (or how long it takes to charge one) until you have it. This thing has been on the charger for seriously the past 8 hours and still isn’t full. Granted, I have been using it off and on but still – my 822 would’ve been fully charged by now I’m sure of it. I can’t wait to see just how much time I get out of a full charge!

Putting the SIM card in is no easy task. It was harrowing to watch the VZW rep do it – and I’m glad it was him doing it and not me. He was practically forcing the SIM tray back in to the top of the phone. I haven’t had the balls to open it back up and see if he actually did it right or not – just going to let it work.

Size

Big. Like, Galaxy S4 big. Keep in mind the frames of reference for me are the HTC Trophy, then the Lumia 822. Those are the only other smartphones I’ve ever owned. My wife has had the Motorola Droid, HTC Incredible, and now the iPhone 4S. All of those are also “small” by today’s standards. This thing is substantial. The upshot is that it’s not heavy.

Storage

Definitely adequate for my purposes. I am happy that they opted for 32gb of on-board memory – if it had been 16 and not expandable I probably wouldn’t have bought it. I have a 64gb Micro XDHC card in my 822 on top of its 16gb of internal storage, so I know that 16gb w/o anything external just isn’t going to cut it for me.

Camera

When I got home the first thing I did was tell my wife to take a picture of one of the boys (late afternoon, inside, cloudy day, shades drawn) without using the flash. Of course as you know I’m setting her up to see just how good the PureView camera is. The picture it took was awesome. She was impressed.

Of course my endgame here is to eventually get her off that God-awful iPhone!

About the only thing I could wish more for in this area is the stabilization that the 920 offers; the 928 doesn’t appear to bring this to the table. Or if it does maybe I have early-onset Parkinson’s.

Goodies

One thing the 928 has that my 822 doesn’t are a couple of add on apps. Or, if the 822 could get them I didn’t know and it never installed them

Storage Check

Allows me to see how my storage is being used, and clear the “Other Storage” area that annoys all us OCD WP8 owners out there. Here are a couple of screenshots of what it looks like:

network+

Looks like I can use this to turn on Call waiting and Call forwarding right from my phone. Pretty slick:

find my phone

The bug I reported to Windows Phone Support and Nokia appears to be fixed in the firmware/core OS of the 928; ‘find my phone’ shows the correct status and expected options:

As I said above, I did end up adding a black carbon fiber-ish gel case to my phone to help cover up the white and it doesn’t look half bad. Here’s what I’m carrying around now! (Photos taken by my 822)

		Lumia 928 VIEW SLIDE SHOW DOWNLOAD ALL

Don’t forget!

If you’re as badass as yours truly and pick up a 928 between now and June 23rd, claim your $25 Windows Phone Store credit!

This tends to, however, leave a pretty good mess by the time you’re done. So… after poking around the TFS website I couldn’t find anywhere to delete projects that I had created. On the home screen there are “X”s beside each project, but that just removes them from the “quick list” that shows up there – it doesn’t delete them from the service. So… what to do next?

Did some sleuthing and discovered the easiest way to do this is via the command line. As a preface, I have logged in to my TFS account on the web, and have already attached to it in VS (though did not have VS running at the time) so I think one or both of those nails down the authentication that makes the following possible.

Fire up the VS Command Prompt from your start screen:

at the prompt that follows, simply type:

tfsdeleteproject /collection:https://[youraccount].visualstudio.com/DefaultCollection “[TFS Project Name]”

eg:

tfsdeleteproject /collection:https://contoso.visualstudio.com/DefaultCollection “Awesome Windows8 Project”

and voila, it’ll roll through removing it from your TFS Cloud account. The interesting thing to note is that the project you delete will NOT remove itself from that quick list that opens on your home page, though – so you’ll have to take care of that manually.

Enjoy a clean TFS account again, now that you’ve got it all figured out.

Plugged in, not charging? what?

I was sitting here working and had it plugged in. Every time I looked down, I saw the battery not filled up. I thought “dang this is taking a while to charge, must have a lot of capacity” so I checked the % it was at so I could keep track of if it was charging. It was sitting at 60% – and it sat there.

Turns out this is a “side effect” of a setting w/in Lenovo’s “Energy Management” utility.

If set to “Optimized Battery Health”, charging will never go past 60%. If you set it to Max Life, you’ll get it to charge fully. I’m sure this has something to do w/ battery chemistry but hey, I added a 2yr extended warranty on this thing, if the battery flakes out, I’ll get it taken care of.

Airplane mode… I can has my WiFi back?

I was playing w/ the Fn keys across the top of the keyboard and hit the one w/ the picture of the airplane on it. As expected, this turned airplane mode on. As NOT expected, when I hit the button again (and airplane mode was shut off) I didn’t get my WiFi back! Wtf? I clicked the network icon in the tray and saw simply “WiFi (Off)” w/ no option to change it. How in the…

Pretty simple fix, but definitely not intuitive. After you shut OFF Airplane mode, you have to go to PC Settings and turn WiFi back on manually:

If you decide to pick up one of these gorgeous devices, or perhaps one of the other great new ultrabooks Lenovo’s kicking out (Carbon X1, yummy), hopefully this saves you some time/headaches!

So let me save you a ton of time.

When you want to do this, you are basically adding META tags to your web site/pages that IE10 reads, recognizes, and links to the Store/OS accordingly (Store if you don’t have the app installed OS launch if you do).

Easy peasy, let’s have a look at what exactly we add to the pages:

<meta name="msApplication-ID" content="microsoft.build.App"/>
<meta name="msApplication-PackageFamilyName" content="microsoft.build_8wekyb3d8bbwe"/>

Easy enough, let’s find these pieces in our app. Fire up the manifest viewer in Visual Studio 2012 and you’re met with something like this:

Head on over to the ‘Packaging’ area:

Well that was easy enough. Package Family Name is staring you right in the face (last field on that page).

But… which one is the Application ID???

Note that if you get the package family name right and the application ID wrong, the behavior you’ll see on your site is that it will ALWAYS show “Get app in store” instead of “Switch to app” after you’ve installed it. So it’s quite easy to think you’ve got it done right when you’ve only got it done half right.

I used the Package name, Display Name, and a host of other things and never found the right one. Then I thought, “let’s see what inside the manifest looks like”. That’s when it revealed itself. To do this, right click the manifest file in the Solution Explorer and click “view code”:

And blamo:

It’s kind of frustrating that this isn’t easily editable anywhere as ‘App’ is kinda stupid, but hey it only shows up here and in a META tag on my site so who cares. Slap ‘App’ in the Application-ID meta tag shown above and voila!

Hope that saved you some time!

Head over to the Windows Store and install it now, or if you’re reading this from w/in the IE10 Modern application on your Windows 8 device, click the “wrench+” icon to install it right from here!

But if you’ve already installed it (YOU’RE AWESOME), you can just as easily switch to the app using the same icon!

Enjoy!

<Grid>
	<Grid.RowDefinitions>
		<RowDefinition Height="Auto" />
	</Grid.RowDefinitions>
	<Grid.ColumnDefinitions>
		<ColumnDefinition Width="Auto" />
		<ColumnDefinition Width="Auto" />
	</Grid.ColumnDefinitions>

	<GridView Grid.Column="0">
		<TextBox />
		<TextBox />
		<TextBox />
		<TextBox />
		<TextBox />
		<TextBox />
		<TextBox />
		<TextBox />
		<TextBox />
		<TextBox />
		<TextBox />
		<TextBox />
		<TextBox />
		<TextBox />
	</GridView>

	<StackPanel Orientation="Vertical"
                        Grid.Column="1">
		<TextBox Margin="10" />
		<TextBox Margin="10" />
		<TextBox Margin="10" />
		<TextBox Margin="10" />
		<TextBox Margin="10" />
		<TextBox Margin="10" />
		<TextBox Margin="10" />
		<TextBox Margin="10" />
		<TextBox Margin="10" />
		<TextBox Margin="10" />
		<TextBox Margin="10" />
		<TextBox Margin="10" />
		<TextBox Margin="10" />
		<TextBox Margin="10" />
	</StackPanel>
</Grid>

Now run it in the simulator and flip to Touch-mode.

Click the bottom-most textbox in the first column.

See what happens?

Textbox within GridView chosen, keyboard obstructs input

Textbox within StackPanel chosen, screen automatically slides up so keyboard doesn’t obstruct input

You can’t see the textbox you’re typing in to! The OS doesn’t handle the “auto-scrolling” of the page’s frame when you are within a GridView. This happens no matter WHAT other control your textbox might be within. If any ancestor of the textbox is a GridView, sayonara Keyboard Obstruction Handling.

So… why?

My thought process goes back to why the GridView exists. I feel as though it exists solely to support the Semantic Zoom capability, which you wouldn’t really be doing on an input form.

So, what can we do instead?

Well, we can do what’s shown here and replace it with a simple StackPanel, for one.

But what if you need DataBinding to a list of items? The solution there is fairly simple: Use an ItemsControl. Voila.

What the CarouselPanel brings to us is the ability to, as the name suggests, roll continuously through the list of items, looping back to the beginning or end as you go forward or backward (respectively). It’s a pretty neat trick with one little annoyance (in my opinion): it doesn’t behave this way everywhere. In addition, I had a client recently to actually wrote it up as a bug and made me come up with a way to get rid of it. I’m sure I’m not alone here, and finding the solution involved a lot of Binging, but in the end it was me poking around and figuring it all out on my own as nobody had a really straightforward solution.

Here is the problem, illustrated. Using the following snippet of code in page:

            <ComboBox Height="32"
                      Margin="100">
                <TextBlock Text="one"
                           Margin="10" />
                <TextBlock Text="two"
                           Margin="10" />
                <TextBlock Text="three"
                           Margin="10" />
                <TextBlock Text="four"
                           Margin="10" />
                <TextBlock Text="five"
                           Margin="10" />
                <TextBlock Text="six"
                           Margin="10" />
                <TextBlock Text="seven"
                           Margin="10" />
                <TextBlock Text="eight"
                           Margin="10" />
                <TextBlock Text="nine"
                           Margin="10" />
                <TextBlock Text="ten"
                           Margin="10" />
                <TextBlock Text="eleven"
                           Margin="10" />
            </ComboBox>

You can pop open the simulator and hit the ‘Basic touch mode’ button on the toolbar to see:

Touch-mode: Combobox listing wraps due to CarouselPanel

then tap out of the combobox and switch to ‘Mouse mode’, click the Combobox and you’ll be met with:

Mouse-mode (non-touch-enabled): Combobox has “normal” behavior due to CarouselPanel

Rather than attempt to convince the client that this is for ease of use of a touch interface – since they weren’t even familiar with Windows 8 to begin with – I took it upon myself to make scenario #2 happen outright, all the time.

Let’s have a look at the relevant part of the ComboBox default template as defined by MSDN:

    <Setter Property="ItemsPanel">
        <Setter.Value>
            <ItemsPanelTemplate>
                <CarouselPanel />
            </ItemsPanelTemplate>
        </Setter.Value>
    </Setter>

Herein lies the culprit. The ItemsPanelTemplate explicitly says that it should use a CarouselPanel to do its job. We need to get that outta there.

If you know about XAML and Control styling, then you probably already know where I’m going with this. But for those of you that don’t, here’s how I went about it:

            <ComboBox Height="32"
                      Margin="100">
                <ComboBox.ItemsPanel>
                    <ItemsPanelTemplate>
                        <StackPanel Orientation="Vertical" />
                    </ItemsPanelTemplate>
                </ComboBox.ItemsPanel>
            </ComboBox>

As you can see what this does is replaces the ItemsPanel’s CarouselPanel with a normal, everyday, StackPanel. Resulting in the following display in touch mode:

Touch-mode: CarouselPanel removed from ComboBox, replaced with StackPanel, no longer wraps

And voila! You’ve got the same experience on touch devices as you do on non-touch ones. For better or worse.

It is worth noting that one caveat I’ve found to this implementation is that you lose inertia within the scroll area. This means there’s no “flicking” to get to the first or last element as there is in the standard ComboBox implementation (using a CarouselPanel) on a touch-enabled device.

If you are able to get inertia built in to this (i.e.: smarter than me) then please pass on your solution!

With this in mind, it’s time for me to ditch Google Calendars as much as I can, so that I can still have some semblance of sanity in my life – and by that I mean know what the hell’s going on. Without a calendar always on me to provide reminders, I would forget to eat lunch. Literally.

“Why are you even using Google Calendars, dude?”
Yeah, yeah, a legit question. Suffice it to say my wife was the first one to own a smartphone in our house, and at the time it was an Android. So… there we were, like so many others, stuck in the ecosystem. We’ve since both moved on (I moved up [wp8], she didn’t [iPhone]) and so now it’s time to break out of our chains.

So how do we do this?

First I had a look at the Hotmail calendars to make sure they would serve our needs. Mainly there is only one – the ability to share with people and give them read and/or write access to the calendar.

Check and mate. Sayonara Google. Let’s do this.

In your Google calendar, head to the Settings area:

Hit the private iCal button:

Click the link shown, save to a spot on your computer (Desktop is fine, it’s temporary after all)

Now what you have is a copy of all your calendar data; enough to replicate it elsewhere. Now where could that be…

Head over to your Microsoft Account – most namely the Calendar area

Here you have two choices, you can either take the data from the ICS file and import it into a calendar you already have on Live.com, or you can create a new calendar with this data. For my purposes, I wasn’t ever using the ‘My Calendar’ that is the default calendar on Live, so I am importing the ICS in to that. The other method is trivial to accomplish once you see how this is done.

At the top of the calendar screen, click Subscribe.

Choose Import from an ICS file and pick the file you downloaded from Google. Here is where you pick whether or not you want to put the data in to a new or existing calendar:

I left everything else as defaulted. It imported all my data, recurrences and all, and now I get to drop Google for my personal calendar.

Another bonus that Hotmail gives you is the ability to subscribe to other calendars. This even works to subscribe to Google calendars. The downside here is you will only get Read access to these, even if you’ve been granted Write access by the Owner of the Google calendar to which you’re subscribing. To do this, read on.

Go to the Google Calendar you want to subscribe to, click Calendar Settings again. This time, copy the link of the Private iCal and instead of Import an ICS in Hotmail, you’ll Subscribe to a public calendar and paste this link in there. You get to give it your own name, and it’ll show up on your Windows 8, Phone, and other devices as well. Awesome.

Caveats

• Private URLs in Google Calendar are only available if you’re given full access to the calendar. That is, you share “admin/owner” privileges with somebody else, or you own the calendar yourself. The former is my case – I share privileges with my wife. The downside is that in Hotmail you’ll only get read access, not read/write.
• If you’re viewing a calendar in Google Calendars that you’ve only been given read access to, you won’t get the ability to expose a Private Calendar URL. Only the owner can do that. You can expose the public one, but will only see whatever the owner has exposed to public view. It doesn’t appear as though you can get a URL that gives you the equivalent privileges on a different platform. Bummer.
• Google Apps users (businesss) may or may not be able to expose Private calendar URLs. I am not my job, but it might be a function of permissions set up by the account manager – I’m not sure.

That’s about as good as it gets, folks. I’d suggest family meetings and/or pre-configuration of your loved ones’ devices to ease the transition.

Enjoy!

Something that is troubling developers more and more as Windows Phone 8 and Windows 8 really stretch their legs in both the consumer and enterprise spaces is how to make the most of their codebases. This rises to the forefront of development very quickly when you see just how similar developing for these two platforms is, from the dev environment, code structure, and available API hooks all the way up to the design and flow of the applications themselves.

Enter Visual Studio 2012’s awesomesauce – the Portable Class Library project type. If you haven’t played with this yet, it really is pretty cool and I highly recommend considering it FIRST when you’re writing a library you intend to reuse. I think most people avoid it because it does what is necessary when it comes to writing code that’s cross-platform: restrict to the lowest common denominator across the platforms you’re targeting. Unfortunately this often takes away things that you wanted to use, but fortunately it assures you that your code – in one library – WILL run on all the platforms you’re targeting. And if you can make it work, it’s a pretty good tool in your back pocket.

To be honest it’s kind of a bummer that I even have to write this post; the Azure team doesn’t appear to know about PCLs. Instead, what they’ve done is created two separate SDKs for Windows Phone 8 and Windows 8 – they are not using a common one to span them both. What this forces us to do is avoid exposing or using those Azure SDKs at the “common” layer of our app. This means we have to abstract it. And in this case it basically means we duplicate/map each of the Windows Phone and Windows 8 versions to a common one in our codebase. If there’s one thing that I hope can come out of this blog post, it’s that Microsoft really needs to start dogfooding their PCL stuff if they want WP and Win8 to start taking over in tandem.

So let’s see how this would apply to Federated login through Azure, and how you can create a quickly-reusable Federated Login library across both Windows Phone 8 and Windows 8.

First step, create a PCL project that targets both Windows Store and Windows Phone 8:

Note the tidbit at the bottom. Pretty clever, “Yo, we know that you just want these two, but the common parts match up with .Net 4.5 so we’re just going to add that as part of the project settings too” – thanks Microsoft!

Now comes some of the ugly business. This Common library is what we’re going to have our client code reference, so that means we can’t be calling out any of the Azure SDK stuff because those are either specific to Windows Phone, or to Windows 8. So here’s where we roll our own versions of the commonality we want out of each of those. In reality, we’re creating the portable subset of the AMS Authentication portion of the Azure SDKs!

Here’s what my code ended up looking like:

	public enum FederatedLoginProvider
	{
		MicrosoftAccount = 0,
		Google = 1,
		Twitter = 2,
		Facebook = 3,
	}

	public interface IFederatedLogin
	{
		Task<FederatedLoginUser> DoLoginAsync (FederatedLoginProvider provider);
		Task<FederatedLoginUser> DoLoginAsync (FederatedLoginProvider provider, string jsonToken);
		Task<FederatedLoginUser> DoLoginAsync (string authenticationToken);
	}

	public class FederatedLoginUser
	{
		public string UserId { get; set; }
	}

Now then, it’s time to wire in the actual AMS Auth to what we’ve got.

Create a new Windows 8 Class Library to put your Win8 Federated login in to:

Add the appropriate references:

Here’s where it gets a bit dicey. Remember we want to share as much as possible to reduce the amount of code we’re writing and maintaining. With that in mind, let’s create a shared file that we’ll Add as Link to both our Win8 and Windows Phone projects. Here’s what that file looks like:

	public partial class FederatedLogin : IFederatedLogin
	{
		MobileServiceClient _mobileClient;

		#region Constructors
		public FederatedLogin (string azureAppUrl) : this (new Uri (azureAppUrl)) { }
		public FederatedLogin (string azureAppUrl, string applicationKey) : this (new Uri (azureAppUrl), applicationKey) { }
		public FederatedLogin (Uri azureAppUrl)
		{
			_mobileClient = new MobileServiceClient (azureAppUrl);
		}
		public FederatedLogin (Uri azureAppUrl, string applicationKey)
		{
			_mobileClient = new MobileServiceClient (azureAppUrl, applicationKey);
		}
		#endregion

		async public Task<FederatedLoginUser> DoLoginAsync (FederatedLoginProvider provider)
		{
			MobileServiceAuthenticationProvider azureProvider = (MobileServiceAuthenticationProvider)(int)provider;
			var azureUser = await _mobileClient.LoginAsync (azureProvider);
			return new FederatedLoginUser
			{
				UserId = azureUser.UserId,
			};
		}

		async public Task<FederatedLoginUser> DoLoginAsync (FederatedLoginProvider provider, string jsonToken)
		{
			MobileServiceAuthenticationProvider azureProvider = (MobileServiceAuthenticationProvider)(int)provider;
			var azureUser = await _mobileClient.LoginAsync (azureProvider, CreateJsonObject(jsonToken));
			return new FederatedLoginUser
			{
				UserId = azureUser.UserId,
			};
		}

		async public Task<FederatedLoginUser> DoLoginAsync (string authenticationToken)
		{
			var azureUser = await _mobileClient.LoginAsync (authenticationToken);
			return new FederatedLoginUser
			{
				UserId = azureUser.UserId,
			};
		}
	}

A couple of points to note here:

1. Not all the possible ways of doing Login are supported – there is one that Win8 allows that Windows Phone doesn’t. So we have to scrap it.
2. The FederatedLoginProvider enumeration maps 1-to-1 to the MobileServiceAuthenticationProvider enumeration exposed by the Azure SDK, but remember we can’t expose it because that would bind us to either Windows Phone or Windows 8.
3. Our FederatedLoginUser doesn’t have the AuthenticationToken property. This is because the Windows Phone Azure User doesn’t have that property.
4. Note the ‘public partial’ at the top of this class and the CreateJsonObject() calls within it. This will be important in the next step.

In each SDK, the Json Objects used are different. In Windows Phone they are using Json.Net, while in Windows 8 they are using the Win8 data stack. So that means that instead of passing those Json Objects as parameters as the Azure SDK does in its formal methods, we have to abstract that to a string which we’ll convert to the respective Json object for the platform. Here’s how we do that.

The ‘shared’ file above should be put in a place that isn’t necessarily specific to either platform. I’ve placed it in the same folder as the ‘Common’ library, but it’s not included in the Common library itself.

So before we move on let’s create the Windows Phone 8 class library as well:

Now for both the Win8 and WP8 class libraries, add the shared file as a link:

The last step is to implement those Json mappers. In the Windows 8 project, create this:

	public partial class FederatedLogin
	{
		private JsonObject CreateJsonObject (string fromString)
		{
			return JsonObject.Parse (fromString);
		}
	}

and in the Windows Phone one:

	public partial class FederatedLogin
	{
		private JObject CreateJsonObject (string fromString)
		{
			return JObject.Parse (fromString);
		}
	}

therein lies the beauty of partial classes. We just extended one shared class to do two different things in two different projects.

Now the whole solution should build. What you now have is a way to have your common business logic layer perform the necessary login operations required by your application layer by going after our custom-created Interface (IFederatedLogin). In other words, your View (Windows 8 or Windows Phone 8) should register its version of FederatedLogin to a spot in the ViewModel layer that is referencing & using only IFederatedLogin. Now your ViewModel on down is cross-platform between Windows 8 and Windows Phone 8, all thanks to the fancy-dancy PCL. This same pattern is one you can follow throughout your Windows 8 and Windows Phone 8 development.

If you’d like to see the usage at the View layer for these feel free to post a comment and I’ll make that next on the list of .Netitude awesomeness.

Enter Azure’s new Mobile Services offering. Along with a database for your app to store stuff, AMS provides another sweet little tool: Authentication.

AMS’ authentication allows you to tie Microsoft Account, Google, Facebook, AND Twitter authentication in to your app. Now, a couple of those will limit your app and make you pay past a certain point (ahem: Google (1mil/day), Twitter (100k all-time)), but the other two are pretty sweet.

For the most part, setting these things up is pretty simple, but there are enough nuances that I thought a blog post might help some folks out.

Let’s get started. Microsoft is really pushing Azure as of late and the coolest thing is that you an actually get a FREE Azure account at the “pay-as-you-go” price level just to play with these kinds of things and see how they’ll work out for you and/or how far you want to take your Azure backend.

My opinion? I think that Azure doesn’t have much to stand on when it comes to indie developers like myself due to the lack of a steady, affordable, cost. If I create a free app using the backend and it takes off like nobody’s business, I could very well end up with a $1000 bill for month X that I could never afford. That would suck. But, things like Federated Authentication might just be “light,” powerful, and useful enough that hobbyists might pick it up more readily once they see what it can do.

First, sign up for a free Azure 90-day trial by starting at the signup page.

You’ll need a phone and credit card – they swear it’s only for identity verification. A quick text message and input of a verification code and:

Now head to your portal by clicking

in the upper-right hand corner of the screen.

Feel free to read through the tutorial to get the full gravity of what you’re about to play with

Now behold the wonder of the beautiful, fluid, web experience the Azure team has created. Seriously, it’s gotta be one of the more impressive parts of using Azure. It’s just damn sexy.

Start by just following the suggestion:

Go ahead and ‘Create an Item’

Choose ‘Compute’ | ‘Mobile Service’ | ‘Create’

Pick a subdomain name you’re proud of and a region closest to where you’re at, just for sanity’s sake:

When creating a new SQL instance, pick that you want a new SQL server and a user/pass you’re comfortable with as well. For Authentication services you won’t need to be using the SQL server that Azure sets up by doing these steps, but it’s part of the setup so we’ve gotta go thru it. If you pick a different reason than what you chose for your Mobile Services, you’ll get a warning. Don’t bother with the Advanced Settings for now.

You’ll now see this awesomesauce at the bottom of your Azure Portal screen:

Hey what can I say, I’m not a web developer so these kinds of tidbits impress me.

Once that finishes up, you’ll have your service staring you in the face, begging to be messed with:

Time to start playing. Click the name of the service, which will launch in to its configuration pages. The cool part here is that not only has Azure set you up with your mobile service, their Quick Start page actually GIVES you a FULL SOLUTION for Windows 8, Windows Phone, or *bah* iOs that is pre-configured with your service’s URL and Authentication Key. Pretty sweet as far as getting up and running goes.
You don’t need to bother downloading that just yet, though.

The part of our new AMS we want to set up is the Identity part. So click that:

Once you’re there you’ll see what information we require to set up the Authentication points from Microsoft, Facebook, Google, and Twitter. This is the part that hung me up for a while. It was easy to find these pieces from those sources, but not the most intuitive to set up my AMS instance to work with them. That is, it’s easy to know how to plug them in to AMS, but not easy to know how to plug AMS in to them. So lets walk through each of the services now.

For Microsoft Account, your developer portal is located at dev.live.com. Once there, log in with a Microsoft Account that you’d like to associate w/ this (only used to manage applications that utilize the Live SDK) and head to the “My Apps” page. If this is your first app, you’ll be taken directly to the ‘Create’ page.

On the Create page, pay attention to the instructions. Some of the fields you’re filling out will be displayed to your end users (i.e.: “Application X wants to access your data, are you cool with that?”).

After creation, you’re taken directly to the API Settings page for your new application, where you’re given all the information you need to wire this up to your new AMS instance.

Take the Client ID and Client secret and punch those in to the right spots in the Identity area of your AMS instance that’s staring you in the face on your other browser tab:

Now at first glance you think you’d be done, but you’d be wrong. In your Live API settings, leave ‘Mobile client app’ set to ‘No’ and place your AMS Instance’s URL in the Redirect URL box

Click ‘Save’ in your Live app’s API settings.
That’s it. Microsoft Account integration is now wired up – which we’ll see in a bit.

Next, let’s tackle Facebook. In much the same fashion, we’ll repeat what we did for the Microsoft Account integration but put the Client ID and Secret from Facebook in to the relevant fields of our AMS’ Identity area, and give Facebook the correct Redirect URL so that the auth flow works as desired.
Disclaimer: I don’t have a Facebook account so the setup and screenshots are from me being logged in to my wife’s so forgive the lack of showing everything on the page

Head to developers.facebook.com, log in, click Apps. Create a New App, fill it out much like we just did for our Live API application.

For Facebook, you put the AMS’ URL in to another spot, the “Website with Facebook Login” area:

And that’s it. Facebook done.

NEXT, Google. Head to the Google API Console, log in, and Create a new Project.

Google by creates an “API Project” which is fine for our purposes. On the left side, choose “API Access” and then Create an OAuth 2.0 Client ID:

Here’s where we, again, put in our Application information that users will end up seeing when they attempt to log in. But with Google there is one important difference so observe these screens closely:

Notice the little bit on the end of our AMS instance’s base URL – without that the Google API won’t work properly. Go ahead and create the Client ID then, and you’ll get your, now familiar, Client ID and Client Secret which we put in the usual places of our AMS’ Identity area.

And last but not least, Twitter. Head to their developer portal’s app management area and log in. Then Create a new Application. You know what you’re doing by now, right?

There we go, pre-setup complete! Now let’s head back to have a look at that slick little Windows 8 Visual Studio Solution that our Azure AMS Instance pre-fabbed for us.

To get back to that handy Quick Start screen, click this little dude:

Now go ahead and download the pre-fabbed Windows 8 solution:

The pre-fabbed solution will give you the ability to read, insert, and update records in the “TodoItems” table that is created by that first green button there. No matter, we’re going to write completely new code to exercise our authentication flows. We won’t worry about securing the data in this blog post – I just wanted to show how to get this wired up since some of it is a bit unintuitive.

So, once you have the solution downloaded, extracted, and building, we’ll make some code changes. When you initially get the app, it looks something like this:

We’re going to change it to this:

So to do that, add the following code to the XAML:

            <Grid Grid.Row="1"
                  Grid.Column="0"
                  Grid.ColumnSpan="2"
                  HorizontalAlignment="Center"
                  Margin="0,0,0,30">
                <StackPanel Orientation="Horizontal">
                    <Button Name="MSLoginButton"
                            Click="MSLoginButton_Click"
                            Content="Microsoft Login" />
                    <Button Name="TwitterLoginButton"
                            Click="TwitterLoginButton_Click"
                            Content="Twitter Login" />
                    <Button Name="GoogleLoginButton"
                            Click="GoogleLoginButton_Click"
                            Content="Google Login" />
                    <Button Name="FBLoginButton"
                            Click="FBLoginButton_Click"
                            Content="Facebook Login" />
                </StackPanel>
            </Grid>

And adjust the other Grid.Row properties of the other items accordingly, of course.

Now wire up the code behind:

		async private void MSLoginButton_Click (object sender, RoutedEventArgs e)
		{
			await Authorize (MobileServiceAuthenticationProvider.MicrosoftAccount);
		}

		async private void TwitterLoginButton_Click (object sender, RoutedEventArgs e)
		{
			await Authorize (MobileServiceAuthenticationProvider.Twitter);
		}

		async private void GoogleLoginButton_Click (object sender, RoutedEventArgs e)
		{
			await Authorize (MobileServiceAuthenticationProvider.Google);
		}

		async private void FBLoginButton_Click (object sender, RoutedEventArgs e)
		{
			await Authorize (MobileServiceAuthenticationProvider.Facebook);
		}

		async private System.Threading.Tasks.Task Authorize (MobileServiceAuthenticationProvider mobileServiceAuthenticationProvider)
		{
			try {
				var user = await App.MobileService.LoginAsync (mobileServiceAuthenticationProvider);
				if (user != null) {
					var d = new Windows.UI.Popups.MessageDialog (user.UserId);
					await d.ShowAsync ();
				}
			} catch { }
		}

Boom that should do it!

Microsoft Account:

Twitter:

Google:

and finally Facebook:

And that’s it, folks! Hope this helps out aspiring Windows 8 & Windows Phone developers looking to wet their chops with Azure and AMS!