Windows Azure, Microsoft .NET Services – Working with Routers (II)

Windows Azure, Microsoft .NET Services – Working with Routers (II)

[This post is based on the Windows Azure Tools for Microsoft Visual Studio July 2009 CTP]

In the previous post on Working with Routers I showed how you can create a router using a Http Post.  A router is only really useful when it can actually route messages. To do this it needs one or more subscribers.  As you can imagine creating a subscriber (as with other creates) involves a Http Post.  When we created the router one of the links that was returned was the subscriptions url. All you really need to do to create a subscriber is send a Http Post to this url. Of course you need to send the url where you want messages to be routed to, and any other information that is required for the router to route messages.  The upshot is that you end up sending an entry that looks similar to the following:

<entry ot;;

    XElement content = new XElement(XName.Get("entry", "http://www.w3.org/2005/Atom"),
                            new XElement(XName.Get("link", "
http://www.w3.org/2005/Atom"),
                                new XAttribute("rel", "alternate"),
                                new XAttribute("href", "
https://blogsample.servicebus.windows.net/" + queue)),
                            ServicesElement("HttpHeaders",
                                ServicesElement("HttpHeader",
                                    new XAttribute("name","X-MS-Identity-Token"),
                                    new XAttribute("value",token))));

    using (var requestStream = request.GetRequestStream())
    using (var writer = new System.IO.StreamWriter(requestStream))
    {
        writer.Write(content);
        writer.Flush();
    }

    using (var response = request.GetResponse())
    using (var responseStream = response.GetResponseStream())
    using (var reader = new StreamReader(responseStream))
    {
        return reader.ReadToEnd();
    }
}

In this example the link url provided is the tail of the queue (ie the url where you enqueue messages).  The token is included in a HttpHeader element so that it can be routed as part of sending the message to the queue. You should expect a 200, Ok response. If you want to get a list of subscribers you can simply issue a Http Get to the subscriptions url.  This will return a feed of the subscribers.

<feed ot;;

    using (var requestStream = request.GetRequestStream())
    using (var writer = new System.IO.StreamWriter(requestStream))
    {
        writer.Write(message);
        writer.Flush();
    }

    using (var response = request.GetResponse())
    {
        return (response as HttpWebResponse).StatusCode.ToString();
    }
}

Again you should expect a 202, Accepted response. To retrieve the message off the destination queue, simply send a Http Delete message as discussed in Working with Queues (III).

Windows Azure, Microsoft .NET Services – Working with Queues (III)

Windows Azure, Microsoft .NET Services – Working with Queues (III)

[This post is based on the Windows Azure Tools for Microsoft Visual Studio July 2009 CTP]

In my previous posts, Working With Queues (I) & Working with Queues (II), I showed how you can create, query, renew and delete queues with the Windows Azure, Microsoft .NET Services. Now for the interesting stuff – let’s enqueue and dequeue messages.

As you can imagine enqueuing equates to Post(ing) a message to the tail of the queue, whilst dequeuing equates to delete(ing) from the head of the queue. In code, this is:

private static string EnqueueMessage(string token, string queue, string message)
{
    string queueUri = "
https://blogsample.servicebus.windows.net/" + queue;

    // send
    HttpWebRequest request = HttpWebRequest.Create(queueUri) as HttpWebRequest;
    request.Method = "POST";
    request.Headers.Add("X-MS-Identity-Token", token);
    request.ContentType = "text/plain;charset=utf-8";

    using (var requestStream = request.GetRequestStream())
    using (var writer = new System.IO.StreamWriter(requestStream))
    {
        writer.Write(message);
        writer.Flush();
    }

    using (var response = request.GetResponse())
    {
        return (response as HttpWebResponse).StatusCode.ToString();
    }
}

private static string DequeueMessage(string token, string queue)
{
    string queueUri = "
https://blogsample.servicebus.windows.net/" + queue + "/!(queue/head)?encoding=asreply&maxmessages=1&timeout=30";

    HttpWebRequest request = HttpWebRequest.Create(queueUri) as HttpWebRequest;
    request.ConnectionGroupName = "dequeue";
    request.Method = "DELETE";
    request.Headers.Add("X-MS-Identity-Token", token);
    request.ContentLength = 0;

    using (var response = request.GetResponse())
    using (var responseStream = response.GetResponseStream())
    using (var reader = new StreamReader(responseStream))
    {
        return reader.ReadToEnd();
    }
}

To enqueue a message you send a Http Post to the alternate link (otherwise known as the tail of the queue), ie https://blogsample.servicebus.windows.net/myqueue. You should get back a 202, Accepted response. When you are dequeuing a message you send a Http Delete to the queuehead link (otherwise known as the head of the queue), ie https://blogsample.servicebus.windows.net/myqueue/!(queue/head). You should get back a 200, Ok response, with the message in the content of the response.

As part of the Http Delete you can specify a timeout, in this case 30 seconds. This determines how long the request will wait for a message to appear on the queue before returning.  If a message appears within this timeout you will get the message and a 200 response.  If not, you will get a 204, No Content response.

And now to cover enqueuing and dequeuing in javascript:

function httpEnqueueMessage(token, queue, message) {
    http = new XMLHttpRequest();
    http.open("POST", "
https://blogsample.servicebus.windows.net/" + queue, false);
    http.setRequestHeader("X-MS-Identity-Token", token);
    http.setRequestHeader("Content-type", "text/plain;charset=utf-8");
    http.onreadystatechange = function() {
        if (http.readyState == 4 && http.status == 202) {
            var output = http.responseText;
            // Do something…
        }
    }
    http.send(message);
}

function httpDequeueMessage(token, queue) {
    http = new XMLHttpRequest();
    http.open("DELETE", "
https://blogsample.servicebus.windows.net/" + queue + "/!(queue/head)?encoding=asreply&maxmessages=1&timeout=20", false);
    http.setRequestHeader("X-MS-Identity-Token", token);
    http.onreadystatechange = function() {
        if (http.readyState == 4 && http.status == 200) {
            var output = http.responseText;
            // Do something…
        }
    }
    http.send();
}

Windows Azure, Microsoft .NET Services – Working with Queues (II)

Windows Azure, Microsoft .NET Services – Working with Queues (II)

[This post is based on the Windows Azure Tools for Microsoft Visual Studio July 2009 CTP]

In my previous post, Working With Queues (I), I showed how you can create a queue using a Http Post message against the Windows Azure, Microsoft .NET Services. Now that we’ve created a queue, let’s look at how you can query, renew and delete your queue.

To query for the existence of a queue (and remember that when a queue expires it is no longer available) you just need to send a Http Get to the parent url. So for example if you had a queue https://blogsample.servicebus.windows.net/application1/myqueue you would send the Get to https://blogsample.servicebus.windows.net/application1. In our case because the queue we created previously was https://blogsample.servicebus.windows.net/myqueue we need to send the Http Get to https://blogsample.servicebus.windows.net/.

public static string GetServicesListing(string token)
{
    string listingUri = "
https://blogsample.servicebus.windows.net/";

    HttpWebRequest request = (HttpWebRequest)WebRequest.Create(listingUri);
    request.Headers.Add("X-MS-Identity-Token", token);
    request.Method = "GET";
    request.ContentLength = 0;

    using (var response = request.GetResponse())
    using (var responseStream = response.GetResponseStream())
    using (var reader = new StreamReader(responseStream))
    {
        var output=  reader.ReadToEnd();
        return output;
    }
}

When you run this code the response (assuming it is successful) should be a 200, Ok. In addition to the 200 status, the Get also returns information about services available under the url that the Get was sent to:

<feed >https://blogsample.servicebus.windows.net/", false);
    http.setRequestHeader("X-MS-Identity-Token", token);
    http.onreadystatechange = function() {
        if (http.readyState == 4 && http.status == 200) {
            output = http.responseText;
            // Do something with the service list
        }
    }
    http.send();
}

As you will have noticed, queues have an ExpirationInstant which is the instance when your queue will expire and be unavailable.  In most cases this is not that desirable so you will want to periodically renew it.  You do this by sending a Http Put to the self link address (ie https://blogsample.servicebus.windows.net/myqueue/!(queue)).  Instead of just sending a new QueuePolicy you need to get the appropriate entry out of the service feed (retrieved using the Http Get we just discussed), update the QueuePolicy with the new expiration instant and then submit the whole entry in the content of the Http Put.

 

public static string RenewQueue(string token, string queue)
{
    string listing = GetServicesListing(token);
    XElement feed = XElement.Parse(listing);
    var content = (from entry in feed.Descendants(XName.Get("entry", "
http://www.w3.org/2005/Atom"))
                  where entry.Element(XName.Get("title", "http://www.w3.org/2005/Atom")).Value == queue
                  select entry).FirstOrDefault();
    if (content == null)
    {
        return null;
    }

    // Update the expiration time
    content.Descendants(ServicesElementName("ExpirationInstant")).FirstOrDefault().SetValue(DateTime.UtcNow.AddMinutes(30));

    string queueUri = "https://blogsample.servicebus.windows.net/" + queue + "/!(queue)";

    HttpWebRequest request = (HttpWebRequest)WebRequest.Create(queueUri);
    request.Headers.Add("X-MS-Identity-Token", token);
    request.Method = "PUT";
    request.ContentType = "application/atom+xml;type=entry;charset=utf-8";

    using (var requestStream = request.GetRequestStream())
    using (var writer = new System.IO.StreamWriter(requestStream))
    {
        writer.Write(content);
        writer.Flush();
    }

    using (var response = request.GetResponse())
    using (var responseStream = response.GetResponseStream())
    using (var reader = new StreamReader(responseStream))
    {
        return reader.ReadToEnd();
    }
}
private static XName ServicesElementName(string element)
{
    return XName.Get(element, "
http://schemas.microsoft.com/netservices/2009/05/servicebus/connect");
}

Here you should expect a 200, Ok response with the updated entry being returned in the response (you can use this to double-check the queue attributes were updated correctly). And now the same but in javascript:

function httpRenewQueue(token, queue, getResponse) {
    xmlDoc = new ActiveXObject("Microsoft.XMLDOM");
    xmlDoc.async = "false";
    xmlDoc.loadXML(getResponse);

    var entry;
    var entries = xmlDoc.getElementsByTagName("title");
    var i;
    for (i = 0; i < entries.length; i++) {
        if (entries[i].childNodes[0].nodeValue == queue) {
            entry = entries[i].parentNode;
        }
    }
    entry.getElementsByTagName("ExpirationInstant")[0].childNodes[0].nodeValue="2009-08-31T03:56:25.2951184Z";

    http = new XMLHttpRequest();
    http.open("PUT", "
https://blogsample.servicebus.windows.net/" + queue + "/!(queue)", false);
    http.setRequestHeader("X-MS-Identity-Token", token);
    http.setRequestHeader("Content-type", "application/atom+xml;type=entry;charset=utf-8");
    http.onreadystatechange = function() {
    if (http.readyState == 4 && http.status == 200)
        {
            var output = http.responseText;
            // Do something…
        }
    }
    http.send(entry.xml);
}

Note that in these examples there is NO error handling and the expiration is hard coded – you will need to adjust this otherwise you will get a 500 Internal Server error if the expiration is in the past.

Ok, so finally you need to be able to delete your queue.  This is done by sending a Http Delete message to the Self link, as follows:

public static string DeleteQueue(string token, string queue)
{
    string queueUri = "
https://blogsample.servicebus.windows.net/" + queue + "/!(queue)";

    HttpWebRequest request = (HttpWebRequest)WebRequest.Create(queueUri);
    request.Headers.Add("X-MS-Identity-Token", token);
    request.Method = "DELETE";
    request.ContentLength = 0;
    using (var response = request.GetResponse())
    {
        return (response as HttpWebResponse).StatusCode.ToString();
    }
}

One important point here is that you must set the ContentLength to 0.  You should expect a 200, Ok if the queue is deleted.  For both the renew (ie Http Put) and delete (ie Http Delete) if the queue has expired, you can expect a 404, Not found exception to be raised.  Lastly, let’s see the delete in javascript:

function httpDeleteQueue(token, queue) {
    http = new XMLHttpRequest();
    http.open("DELETE", "
https://blogsample.servicebus.windows.net/" + queue +"/!(queue)", false);
    http.setRequestHeader("X-MS-Identity-Token", token);
    http.onreadystatechange = function() {
        if (http.readyState == 4 && http.status == 200) {
            var output = http.responseText;
            // Do something….
        }
    }
    http.send();
}

Windows Azure, Microsoft .NET Services – Working With Queues (I)

Windows Azure, Microsoft .NET Services – Working With Queues (I)

[This post is based on the Windows Azure Tools for Microsoft Visual Studio July 2009 CTP]

In my previous post on Acquiring an Authentication Token I demonstrated how you can use a Http Get operation to acquire an Authentication Token.  This token can be used to create, modify, delete and send messages to both queues and routers as part of the Windows Azure, Microsoft .NET Services. Again, whilst there are .NET libraries for working with both queues and routers in this post we’ll still to the basic Http messages so that you can see what’s going on under the hood.

The first place to start is to create a queue. To do this you send a Http Post to the url that you want the queue to reside at, supplying a QueuePolicy entry.  The url has to belong to your solution url, so for example https://blogsample.servicebus.windows.net/myqueue. There are a number of attributes you can set in the QueuePolicy you supply but as a minimum you need to set the ExpirationInstant, which as you can imagine is the instant that the queue will expire and self-destruct (unless renewed). An example QueuePolicy would look like the following:

<entry >http://www.w3.org/2005/Atom">
  <QueuePolicy >http://schemas.microsoft.com/netservices/2009/05/servicebus/connect">
    <ExpirationInstant>2009-08-30T23:56:25.2951184Z</ExpirationInstant>
  </QueuePolicy>
</entry>

Now to send this:

public static string HttpCreateQueue(string token, string queue)
{
    string queueUri = "
https://blogsample.servicebus.windows.net/" + queue;

    HttpWebRequest request = (HttpWebRequest)WebRequest.Create(queueUri);
   request.Headers.Add("X-MS-Identity-Token", token);
    request.Method = "POST";
    request.ContentType = "application/atom+xml;type=entry;charset=utf-8";

    XElement content = new XElement(XName.Get("entry", "http://www.w3.org/2005/Atom"),
                            ServicesElement("QueuePolicy",
                                ServicesElement("ExpirationInstant", DateTime.UtcNow.AddMinutes(30))));

    using (var requestStream = request.GetRequestStream())
    using (var writer = new System.IO.StreamWriter(requestStream))
    {
            writer.Write(content);
            writer.Flush();
    }

    using (var response = request.GetResponse())
    using (var responseStream = response.GetResponseStream())
    using (var reader = new StreamReader(responseStream))
    {
        return reader.ReadToEnd();
    }
}

private static XElement ServicesElement(string element, object content)
{
    return new XElement(XName.Get(element, "
http://schemas.microsoft.com/netservices/2009/05/servicebus/connect"), content);
}

Note that you need to supply the authentication token using the X-MS-Identity-Token header.  Here we have built up the QueuePolicy as an XElement, you can of course use the .NET library to generate this for you. When you run this code the response (assuming it is successful) should be a 201, Created. Subsequent Posts to this url will result in a 202, Accepted – note however this does not update or alter the queue. In addition to the 201 status, the Post also returns information about the created queue:

<entry >http://www.w3.org/2005/Atom">
   <id>uuid:11cdc611-62fb-49d1-8dee-e47bf9cc93d8;id=1407</id>
   <title type="text">myqueue</title>
   <updated>2009-08-30T23:44:13Z</updated>
   <link rel="alternate" href="
https://blogsample.servicebus.windows.net/myqueue/"/>
   <link rel="self" href="
https://blogsample.servicebus.windows.net/myqueue/!(queue)"/>
   <link rel="queuehead" href="
https://blogsample.servicebus.windows.net/myqueue/!(queue/head)"/>
   <link rel="queuecontrol" href="
https://blogsample.servicebus.windows.net/myqueue/!(queue/control)"/>
   <QueuePolicy >http://schemas.microsoft.com/netservices/2009/05/servicebus/connect" >http://www.w3.org/2001/XMLSchema-instance">
      <ExpirationInstant>2009-08-31T00:14:13.2742033Z</ExpirationInstant>
      <MaxMessageSize>61440</MaxMessageSize>
      <EnqueueTimeout>PT10S</EnqueueTimeout>
      <MaxConcurrentReaders>10</MaxConcurrentReaders>
      <MaxDequeueRetries>3</MaxDequeueRetries>
      <MaxMessageAge>PT10M</MaxMessageAge>
      <MaxQueueLength>2147483647</MaxQueueLength>
      <MaxQueueCapacity>10485760</MaxQueueCapacity>
      </QueuePolicy>
</entry>

The important elements to note from this are the links.  These correspond to the urls where you will perform actions on the queue.

alternate – This is the url you will use when placing new messages on the queue.  You can think of this as the tail of the queue.

self – This is the url you will now use to update, renew and delete the queue.

queuehead – This is the url where you will pop messages off the queue.  As the name implies, this is the head of the queue

queuecontrol – Currently unused, it is anticipated that this will be used for queue message control.

We’ll come back to these in a minute but let’s first see what this would look like in javascript (again remember this will only work in the context of Gadgets and Widgets where the cross site scripting rules are relaxed):

function httpCreateQueue(token, queue) {
    var policy = "<entry >http://www.w3.org/2005/Atom">" +
  "<QueuePolicy >http://schemas.microsoft.com/netservices/2009/05/servicebus/connect">" +
    "<ExpirationInstant>2009-08-31T03:56:25.2951184Z</ExpirationInstant>" +
  "</QueuePolicy>" +
"</entry>";

    http = new XMLHttpRequest();
    http.open("POST", "
https://blogsample.servicebus.windows.net/" + queue, false);
    http.setRequestHeader("X-MS-Identity-Token", token);
    http.setRequestHeader("Content-type", "application/atom+xml;type=entry;charset=utf-8");
    http.onreadystatechange = function() {
        if (http.readyState == 4 && http.status == 201) {
            var response = http.responseText;
            // Do stuff with the response message
        }
    }
    http.send(policy);
}

One observation is that the service bus is quite sensitive when it comes to the formatting and contents of the request, and like all secure services if you get something wrong it will give you a 500 Internal Server error with no additional information to diagnose what’s going wrong.  In my case the number one thing that was biting me was the ExpirationInstant.  This needs to be UTC time and in the future 🙂

Windows Azure, Microsoft .NET Services – Acquiring an Authentication Token

Windows Azure, Microsoft .NET Services – Acquiring an Authentication Token

[This post is based on the Windows Azure Tools for Microsoft Visual Studio July 2009 CTP]

Before we jump into looking at authentication tokens, why you need them and how to acquire them, let’s take a quick refresher on how to get up and running with the Windows Azure, Microsoft .NET Services. To begin with you have to request an account; once you receive your welcome email you need to sign in to the Windows Azure portal where you can then view all your .NET Services solutions and subscriptions.

image

To start working with .NET Services you need to create a solution by selecting the Add Solution button. You will be prompted to enter a name for your solution. It’s important to think about the name of your solution as you can’t (currently at least) change it. The solution name becomes the first segment in the url that you will use to access elements of the .NET Services – https://blogsample.servicebus.windows.net/. After entering a solution name you should use the Validate Name link to see whether the name you have entered is in use.

image

Once you have successfully created your solution you will be returned to the main portal screen.  Initially your new solution will appear in the list of solutions with “Activating…” alongside it. If you hit the refresh button after a few seconds (perhaps a couple of minutes depending on how busy the server is) you will see that your solution is available for use.

image

You can use the three links alongside your newly created solution to manage permissions to your solution (Access Control Service), access the Service Bus Registry or manage the Credentials for your solution.  Before we go on you will need to go into Credentials and specify a Solution Password – this is required for you to programmatically access your .NET Services solution.

image

Now that your solution is setup, lets get into working with your .NET Services solution. Nearly anything you do with your solution requires you to supply an Authentication Token. An Authentication Token can be requested from the Microsoft .NET Access Control Service by supplying a set of credentials in a number of different forms.  For the purpose of this post I’ll be using the username/password option which will mean that you can authenticate using whatever technology stack you feel most comfortable with. Using the .NET library this can be done in just a few lines of code. However, sometimes it’s useful to see what’s going on under the covers, so let’s look at how you can acquire a token using just Http messages.

Essentially acquiring a Authentication Token can be done by sending a Http Get to http://accesscontrol.windows.net/issuetoken.aspx, supplying the solution name and password as query parameters. For example I could enter https://accesscontrol.windows.net/issuetoken.aspx?u=BlogSample&p=<password> into a web browser and would get back a page containing a token “ELp6ymQPzEiKbwgyTg+cQKvvhGVm0oOnGqO1kA==”. To do this in code you just need to create a webrequest to this url.

public static string HttpGetAuthenticationToken(string username, string password)
{
    string requestUri = string.Format("
https://accesscontrol.windows.net/issuetoken.aspx?u={0}&p={1}",
                                    username, Uri.EscapeDataString(password));

    var request = WebRequest.Create(requestUri);
    using (var response = request.GetResponse())
    using (var responseStream = response.GetResponseStream())
    using (var reader = new StreamReader(responseStream))
    {
        return reader.ReadToEnd();
    }
}

You can make a similar request from javascript (note that due to cross-domain scripting this will only work from Windows Gadgets or Windows Mobile Widgets where the normal restrictions don’t apply).

function httpGetAuthenticationToken(username, password) {
    http = new XMLHttpRequest();
    http.open("GET", "
https://accesscontrol.windows.net/IssueToken.aspx?u=" + username + "&p=" + password, false);
    http.onreadystatechange = function() {
        if (http.readyState == 4 && http.status == 200) {
            var token = http.responseText;
            // Do something with the token….
        }
    }
    http.send();
}

New Builds of Windows Mobile 6.5

New Builds of Windows Mobile 6.5

Earlier this week I noticed a post on MoDaCo talking about newer builds of Windows Mobile 6.5.  By newer, I’m of course comparing the builds to what’s publically available in the emulator images as part of the Windows Mobile 6.5 Developer Toolkit. As I’m currently wielding a HTC Touch Pro device (which for the record was one of the worst purchase decisions I’ve made due to the lack of support from both Expansys Australia and HTC) I figured I’d take a look at some of the xda-developer roms that they’ve been cooking with the latest Windows Mobile 6.5 bits.  Here are just a few screen shots from the NATF_WM6.5_TP_Lite_v5.5A ROM

Disclaimer: Please note I would NOT recommend trying cooked roms as they have the potential to brick your device – do so at your own peril. This post is just to highlight some of the new functionality that we may be expecting in production WM6.5 devices later this year.

image image

1) Notification bar – you will notice that the notification area at the top of the screen is a little smaller than before. It’s also missing the start icon.  Clicking any where in the notification area will show an enlarged notification bar (second image) where you can then click on the icon you actually want to access.

2) Start – this is no longer in the notification area, appearing instead in the SIP/Menu bar at the bottom of the screen.  This is applied throughout the device, not just the today screen.

image

3) Ok – this has also been moved out of the notification area and placed in the SIP/menu bar.

4) Gestures for Tabs –gesturing left and right navigates between tabs.

image

5) Slide Tabs – instead of tabs appearing at the bottom of the screen, they now appear as “previous and next” headings at the top of the screen.  You can use left and right gestures anywhere on the form to navigate to previous or next tabs. Note that they are cyclic so you can keep going “next” (or “previous”) to go repeatedly through all the tabs – imho not particularly intuitive as there’s no indication of what all the tabs are and how to jump straight to a specific tab.

image image

6) Start Menu – instead of the “Move to Top” option you got when you click and hold on an icon in the start menu.  Now when you click and hold you can drag the icon around the start menu to change the layout to suit you. Unfortunately you don’t seem to be able to add/remove folders, nor drop an icon into a folder.

Now I’m sure there are other new features that I haven’t come across but these are the ones that after 20secs caught my eyes.

Widget Security

Widget Security

Following my previous post on Windows Mobile Widget security I got feedback that the proposed solution wasn’t that secure and that it was easily foiled by impersonating the header information, and that the widget should be authenticating the user based on a set of credentials. This is 100% accurate and I whole-heartedly agree…. except we’re looking at two different problems here. 

-If the users of your application/widget are known to you (ie they have registered with your site/application and they have a username/password or some other form of credentials), then you should be prompting them to enter their credentials and use that to authenticate against the server.  Of course you can then cache these credentials on the device so that the user doesn’t need to re-enter them, or slightly better cache an authentication token that permits them access for a certain period – that way at least someone with physical access to the device can’t extract their actual credentials.

-If the users of your application/widget are not know to you, and you want to limit access to your data service then you need to authenticate your application some how.  Unfortunately storing any credentials on the device, unless you write a native module that hides the details, is somewhat problematic as in theory anyone with access to your application can decode the key.  In my previous post I discussed a strategy to minimise not eliminate the possibility of someone using your data source without your permission.

I’d be interested to hear of other alternative strategies for protecting anonymous data services.

Why is the HTML version in Windows Mobile 6.5 in 4.01 and Not 5?

Why is the HTML version in Windows Mobile 6.5 in 4.01 and Not 5?

One of the questions asked at the Sydney Windows Mobile Debug Day was what version of HTML does Windows Mobile 6.5 Internet Explorer Mobile, and subsequently Widgets, support? The answer is that IE Mobile 6 supports HTML v4.01 (as well as javascript 5.7). This received a bit of debate since the Palm Pre offers support for HTML 5 and as such wouldn’t Microsoft want to future proof their platform.

I think one thing to remember is that most OEMs who build and sell Windows Mobile phones do not offer regular or frequent updates to the ROMs, and unlike some platforms, Microsoft is unable to push out updates when they make changes to the core platform.  Why is this relevant? Well, if you are across the HTML standards you will know that HTML 4.01 is “a stable document and may be used as reference material or cited as a normative reference from another document” (from the W3C HTML 4.01 Specification), where as the HTML 5 “specification is not stable” (from the W3C HTML 5 Specification) and they further state:

Implementors who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways. Vendors interested in implementing this specification before it eventually reaches the Candidate Recommendation stage should join the aforementioned mailing lists and take part in the discussions.

Whilst I’m sure that Microsoft has representation on the appropriate committees/lists, I would suggest that it is a little presumptuous to implement HTML 5 on a device that is no easily updatable. I guess we can only hope that the HTML 5 specification is locked down in time for the next version of Windows Mobile.

Adding Maps to your Windows Mobile Widget

Adding Maps to your Windows Mobile Widget

One of the questions that came up at the Windows Mobile Debug Days (part of the Codemasons’ Guild) was how to integrate mapping into your application.  This prompted me to experiment with integrating the Bing Map (javascript) Control into a Windows Mobile Widget.  Whilst the javascript engine in Windows Mobile 6.5 has been given a massive injection of life, I was very skeptical that the javascript control would work out of the box. I was proven wrong with the map working with no modifications.  The following code is taken out of the online visual sdk, with the only change being the height and width of the map div to fit into the widget.

<html>
   <head>
      <title></title>
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <script type="text/javascript" src="
http://ecn.dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=6.2"></script>
      <script type="text/javascript">
          var map = null;

          function GetMap() {
              map = new VEMap(‘myMap’);
              map.LoadMap();
          }  
      </script>
   </head>
   <body onload="GetMap();">
      <div id=’myMap’ style="position:relative; width:240px; height:260px;"></div>
   </body>
</html>

The only issues I found with the javascript control relate to the gesture support within the widgets in Windows Mobile 6.5. When you pan your finger within a widget it attempts to scroll the widget itself.  Unfortunately this means that you can pan the map by dragging your finger across the map.  Instead you have to use the navigation control in the top left corner.

clip_image002

Windows Mobile Happenings

Windows Mobile Happenings

This post covers a number of “happenings” in the Windows Mobile space, so I’ll start with a list:

Wow, what a list.  Well let’s start at the top…

Codemasons’ Guild

The Codemasons’ Guild is the brainchild of the Australian Windows Mobile team.  These guys rock; at a time where I’m continually astounded by the lack of action from Microsoft in the Windows Mobile space, the action that’s coming out of the Australian team is inspiring!  Anyhow, back on topic…. the Guild is a local Australian portal for developers interested in building applications for Windows Mobile.  The idea is that by bringing together some industry names (James, Rog, Nick, Dave, and myself), partners in the Windows Mobile space, events and a forum, we can build a local community that will foster a whole industry around device applications.

Jumpstart Series

Next on the list is the Jumpstart series.  This is actually a sub-item of the Codemasons’ Guild as all the information about this series is available via the Guild website. To date there have been three sessions:

  1. Session 1: View the recorded introduction session to Windows Mobile 6.5 and Marketplace
  2. Session 2: Getting started developing for Windows Mobile 6.5
  3. Session 3: Widgets: the new Internet Application (recording not yet available)

At this stage the team is looking at how this series can be continued.  If you have any topic that you would especially like to be covered, please let one of the WinMo Oz team know.

Marketplace

The Windows Mobile Marketplace has opened for application submissions, including the Race To Market challenge. You should definitely take a read of the following documents to get ready for submitting your application to marketplace.

Note that in order to submit your application you will need to register ($99 US/$150AUD); you will then have to wait for your digital certificate from GeoTrust for application signing.  The upshot – don’t assume you’ll be able to sign up and submit in one sitting.

Debug Days

Next week the Australian Windows Mobile team, coupled with the team from the Guild are hosting three Debug Days. Well, they’re actually evenings – from 4:30pm through to around 9pm we’ll be helping you with any issues you may have in designing, building, debugging, deploying….. or anything else related to Windows Mobile development.  The idea is that you can either let us know before hand, or just rock up and surprise us, with anything you want help with.  This is going to be a fully interactive session – the more thinking/prep you do before hand, the more value you’ll get out of the session.

Anyhow, the registration links are now open and I look forward to catching up with as many of you as possible next week:

Competitions

As if I haven’t covered enough, there are a bunch of competitions you can enter related to WM6.5 and Marketplace:

Sign up now and get your mobile application on the shelves of Windows Marketplace for Mobile. When you submit your app, you’ll also be eligible to win the Race to Market Challenge and exciting prizes, including:

  • A Microsoft Surface table
  • Online marketing and promotion
  • A one-of-a-kind trophy

Ready for the challenge?

For developers – do you have a clever concept for a Windows® phone application? We’d like to help you turn it into a best-seller on Windows Marketplace for Mobile. Interested? Simply submit your brilliant concept by August 21, 2009 and you could win one of three prize packs worth $5,000 each! You can enter as many times as you like, as long as each entry is different.

The each of the 3 prizes includes a fully paid ticket to TechEd Australia on the Gold Coast (with 3 nights accom & flights).  The 3 prize winners will have their app showcased at TechEd, including at Smackdown – where we will judge the Master Codemason Application.

Are you a Student? Got a great idea for a mobile app but no way to make it happen? Submit your idea by August 17, 2009 and you could win one of two developer mentorships and share in prizes! You can enter as many times as you like, as long as each entry is different

SDNUG

If you didn’t see the Livemeeting last week on Windows Mobile 6.5 and Widgets, I’m doing a session at the Sydney Deep .NET User Group tomorrow evening.  Full details:

SDNUG Double Header:

Web and application access: supporting the needs of people with disabilities by Dr Scott Hollier

WM6.5, Widgets and Marketplace by me 🙂

Thursday 6 Aug 2009 6.00pm – 8.00pm (add to calendar)