I've been rather quiet on the blogging front lately, but not for lack of activity! For one, I'm the full owner of the technical posts that go up on Microsoft's dev blogs for Windows, http://blogs.windows.com/windows/b/buildingapps/, which merged together the Windows and Windows Phone dev blogs back in early April. Call me the developmental editor for just about anything posted under the "Windows Apps Team" byline.

But no excuse for personal blogging! These last few weeks I haven't wanted to add anything to my blog here because I've been migrating my site from godaddy.com (where the hosting cost went up and it's hard to find discounts now) to Microsoft Azure, where my Windows Store account gives me $150/month credit! (I believe you all are enjoying that too.) The trick was to migrate and merge my old ASP.NET site content with my WordPress blog content, which also meant redirecting the blog from a /blog subfolder to the root while getting the .aspx pages to redirect properly, especially Pages.aspx, which did a database lookup for articles and such that are now WordPress pages.

If you see some bad links or broken images in any posts here, let me know (kraig(at)kraigbrockschmidt.com). I'm doing a scrub but might miss something.

One issue that I ran into was rather interesting. With WordPress I wanted to switch from default permalinks using /?p=<post ID> URIs to "pretty name" URIs with dates and such (better for SEO). At the same time I wanted to make sure that /blog/<name> got redirected to just <name> give that I pulled WordPress into the site root.

Should have been easy with an Azure virtual directory, yes? At first, that seemed to work just fine–I added an entry on the Azure web site Configure page for /blog to go to sitewwwroot. I tested it, and it was good.

But when I changed the WordPress permalinks, I started getting either HTTP 404 errors or HTTP 500 errors when using /blog. What gives?

It boiled down to the fact that WordPress was interpreting /blog as part of a pretty name and therefore trying to do a post or page lookup, and not finding one would generate a 404. The 500 errors showed up when I had some Rewrite rules in web.config (that WordPress included for pretty permalinks), which seemed to generate confusion between the permalink system and Azure's virtual directory checking.

In the end, the solution was to insert a special redirect rule in web.config for "blog" specifically, so it'd get processed first and bypass the permalink system entirely. Here's what my web.config looks like:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.web>
    <customErrors mode="Off"/>
  </system.web>
  <system.webServer>
    <staticContent>
      <remove fileExtension=".svg"/>
      <mimeMap fileExtension=".svg" mimeType="image/svg+xml"/>
    </staticContent>

    <rewrite>
      <rules>
        <rule stopProcessing="true" name="Blog Rule">
          <match url="blog"/>
          <action url="index.php" redirectType="Permanent" type="Redirect"/>
        </rule>
        <rule name="wordpress" patternSyntax="Wildcard">
          <match url="*"/>
          <conditions>
            <add negate="true" matchType="IsFile" input="{REQUEST_FILENAME}"/>
            <add negate="true" matchType="IsDirectory" input="{REQUEST_FILENAME}"/>
          </conditions>
          <action url="index.php" type="Rewrite"/>
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

 

Hopefully this helps others who run into the same thing every now and then!


In relation to my series of posts, Alive with Activity, on the Windows 8 Developer Blog (part 1 is there, part 2 will be posted today, and part 3 is in production), I’ve been working some with Windows Azure Mobile Services and am increasingly impressed with what’s being offered here. You owe it to yourself to learn something about them.

As you’ll see in parts 2 and 3 of that devblog post, Mobile Services, which I abbreviate as AMS and which is also referred to as ZUMO (aZUre MObile service), setting up push notifications is really a snap with this technology. That is, if you go through the list of things you have to do to support push notifications, there’s quite a bit on the service-end of things (as part 3 will describe), and these are many of the details that AMS takes care of for you.

The two primary tasks for push notifications are:

  • Sending channel URIs to the service: this step becomes far easier with AMS. Instead of sending HTTP requests that you have to build up yourself, you instead create a database table in the mobile service (through the Windows Azure portal) and simply insert a record into that table with the channel URI and any other key information you need to attach to it. The AMS client library takes care of the HTTP request behind the scenes, and even updates the client-side record with any changes made on the server. Furthermore, AMS can automatically handle authentication through the user’s Microsoft Account or through three other OAuth providers—Facebook, Twitter, or Google—if that you’ve registered your app with one of them. See Get started with authentication in Mobile Services.
  • Sending notification: in the raw, you have to send HTTP requests to the channel URIs used with push notification. With AMS< you can attach scripts (written in the variant of JavaScript known as Node.js) to database operations, and also created scheduled jobs in JavaScript. In these scripts, a simple call to the push.wns object with a channel URI and a payload generates the necessary HTTP request to the channel. It’s also a simple matter to capture push failures and record the response with console.log. Those logs are easily reviewed on the Windows Azure portal.

Now instead of spoiling the fun of my devblog posts where push notifications are concerned, here are other capabilities of AMS that you will want to know about.

  • The ability to authenticate the service with OAuth providers is very cool. Just as you can use OAuth providers to authenticate a user in a Windows Store app (using the Web Authentication Broker), you can also use that same provider on your service back-end. This means that having access to a unique user identity is pretty simple and straightforward, allowing you to manage per-user data in the service.
  • AMS builds on SQL Server databases hosted on Azure. Those databases are just like any other online SQL Server instance and can be accessed in the same way. This means that you can have other services, apps, web sites, etc., all talking to the same database that the Mobile Services part uses. This allows you to use that database as a central gathering point for data that you’d use for things like periodic and push notifications (OK–that’s a spoiler for Part 2…).
  • Whether or not you need push notifications in an app, the client library gives you a very easy way to save records to a database table and have any server-side modifications reflected back in the client. You can, of course, just read, delete, and update those records as well. In other words, the table-management capabilities in AMS can be used by themselves just for data management, which is super-cool. Even more so is the dynamic scheming capability with the database, meaning that you can just add columns (properties) as you need without having to separately manage the database tables.
  • You can easily do paging of data from the database, e.g. having your app only acquire so many records at once.
  • The scheduled jobs feature of mobile services lets you run code on your server whenever, for whatever purpose. You’re just setting up these jobs with little bits of JavaScript, so it’s not like you have to learn everything about server-side programming.
  • AMS works with Windows Store apps, yes, but also Windows Phone, iOS, and basically anything else that can talk to a service. Don’t think of AMS as just a Windows thing.
  • You can use AMS to send emails from the server.
  • AMS also provides mechanisms for managing server-based storage, e.g. for uploading images and other data from an app. You can use the Background Transfer APIs in WinRT to do this directly, but it means writing a service that can deal with those data streams. AMS does that for you, and employs the background transfer APIs on the client side.

And from what I hear, the story will get better in the months ahead when new features are added.

In short, it’s worth spending a few hours just looking through the AMS docs on http://www.windowsazure.com/en-us/develop/mobile/resources/#header-1. I think you’ll be pleased at what you find. ANd check back in every few months to see what’s new.

By the way, if you’ve read this and find yourself a little nervous about all this “service” stuff that takes you away from the concerns of client apps, let me say that I really do understand! Learning about HTTP, etc, well, I didn’t want to touch services for a long time, as it can be a very different world than writing apps. However, in the process of writing Chapter 13 of my book, I really didn’t have a choice. Because no one, to my knowledge, had put up a sample service to work with tiles, toasts, and badges (the Windows 8 SDK only has client-side samples), I took the plunge. Having done so, I have to say I’m really enjoying learning about this space, not just with Azure, which is very cool, but boning up more on ASP.NET, refreshing my PHP (in which I’ve worked a little), checking out Node/node.js (for writing servers), learning about the whole world of web APIs (see http://programmableweb.com), and thinking about how to use services creatively in apps.

And now that I’ve been looking into AMS, what’s so very cool about it is that you don’t have to deal with all that HTTP stuff at all!

So don’t be that afraid of it (I’m still a little iffy on OAuth…but that’ll come!). Take it a little at a time, and I’m hoping my devblog posts will help you bridge to that space as well.