The SoftTeq Community Site

Windows Phone 7 series Developer Preview…. Virtual Machine Fail

nick — Mon, 15 Mar 2010 18:37:26 GMT

Having sat through the MIX keynote I was excited to see the announcement of the Windows Phone 7 series development tools. These can all be downloaded from http://developer.windowsphone.com. The downloads are only compatible with VS2010 RC and so installing these on my main machine (which I haven’t had a chance to upgrade from the beta) is going to be a major effort. I thought I’d go an install them on one of my many virtual machines I have running on my Hyper-V server – FAIL… According to the release notes this is not a supported option. I also noticed that round-tripping between VS and Blend is not supported – doesn’t that defeat the whole purpose?

Scenarios Not Supported

Opening Windows Phone projects in Expression Blend® is not supported, except for Expression Blend 4 Beta with “MICROSOFT EXPRESSION BLEND ADD-IN PREVIEW FOR WINDOWS PHONE.”

Round-trip editing of the Windows Phone projects between Expression Blend and Visual Studio is not supported.

Windows XP and Windows Server® are not supported.

Virtual PC and Hyper-V™ are not supported.

I’m actually guessing the issue with Virtual PC/Hyper-V is to do with the emulator, rather than the actual developer experience. This is something that we saw with very old versions of the Windows Mobile emulator where they couldn’t be run in a virtual machine – this was fixed when the emulator was moved to true ARM emulation.

Update: I’ve just finished installing the tools on a VM and the emulator, whilst slow to load the first time did in fact load and run my hello world application. Big kudos to Microsoft – the tooling looks great so far.

Also, don’t forget to check out the following discussion documents on the platform and designing for Windows Phone 7 series.

Jamie Oliver live in Centennial Park with food from Sydney Picnics

nick — Sun, 14 Mar 2010 12:49:31 GMT

We just got back from a fantastic evening watching Jamie Oliver prepare some gourmet delights on the stage in Centennial Park. He’s got such a great stage presence. Between him, the audience and his good mate, Ben O’Donoghue, Jamie brought the full song-and-dance production to Sydney, delivering an evening that will be remembered for a while to come.

Normally at these event you’re left drooling as all the best food ends up being created and eaten on stage by those fortunate enough to make themselves noticed at the front of the event. Not to be left feeling hungry we came prepared and had our own picnic courtesy of the Sydney Picnic Co.

After looking around at a number of different picnic providers I settled on the Sydney Picnic Co because they seemed to have the same idea about food as I do – it’s there to be enjoyed rather than to just fill you up. The selection of cold meats, wild onions, risoni and of course the Valrhona chocolate pots made for an amazing feast from which none of us went hungry. In fact we got a picnic sized for 4 and walked away with enough food for lunch tomorrow (and yes, there’s going to be some arguing over who gets what….).

Anyhow, a big thanks to the Sydney Picnic Co for making a great event and unforgettable experience. If you’re looking to do a picnic in the park or at the beach I can’t recommend them enough!

Windows Phone 7 – Will it be everything Microsoft wants it to be?

nick — Fri, 12 Mar 2010 06:35:29 GMT

Charlie Kindel’s posted about some internal planning that the team did as part of building Windows Phone 7 series. I’m assuming that this isn’t an ordered list but I’m also guessing that this was the order the points were on some list somewhere (perhaps as they were written on a whiteboard during a brainstorming session). If this is the case, it’s concerning that “It’s easy to build beautiful applications users just love" falls at the bottom of the list.

For those that are familiar with Windows Mobile development you’ll have gone through the list and gone yep, yep, yep to most of the points. Most of these points we could achieve on the current Windows Mobile platform (perhaps with the exception of protecting the developers IP and until recently a single marketplace). Where Windows Mobile sucks is the ability to generate awesome applications that users really want to use – it’s not impossible by the way, just hard to do. Actually, it’s hard to do this full stop. I’d almost stake my life on it that despite Microsoft’s attempt at making it easy to build “beautiful” applications, beauty is definitely in the eye of the beholder and we are going to get some hideous creations appearing on the marketplace.

I’m looking forward to MIX next week when we’ll hear just how great we can my Windows Phone 7 series applications.

OpenGL: More on Transforms

nick — Tue, 09 Mar 2010 13:58:19 GMT

In OpenGL- Rotate, Scale and Translate I took a very simple example of transforming some text but what happens if you want to do something more complex. For example you want to have a pair of strings that you can transform around the screen together (ie not have to worry about transforming individually. To do this we can use a form of layering in our rendering where each layer can contain any number of items that will be rendered together. Each layer can be transformed with the resulting transform being applied to each item in the layer.

We’re going to start off by defining an abstract class called ScreenWidget. I’ve used widget because I couldn’t think of a more “correct” name to call items that are going to be displayed on the screen. If there is a better name, do tell me as I’m keen to stick with a vocabulary that is well understood.

abstract class ScreenWidget
    {
        public Vector3f Position { get; set; }
        public Vector3f Anchor { get; set; }
        public Vector3f Scale { get; set; }
        public float Angle { get; set; }
        public Vector3f RotationAxis { get; set; }

        public ScreenWidget()
        {
            Scale = new Vector3f(1, 1, 1);
            RotationAxis = new Vector3f(0,0,1);
        }

        public unsafe void Draw()
        {

            gl.PushMatrix();
            gl.Translatef(Position.X, Position.Y, Position.Z);
            gl.Scalef(Scale.X, Scale.Y, Scale.Z);
            gl.Rotatef(Angle, RotationAxis.X, RotationAxis.Y, RotationAxis.Z);
            gl.Translatef(-Anchor.X, -Anchor.Y, -Anchor.Z);

            DrawComponents();
            gl.PopMatrix();
        }

        protected abstract void DrawComponents();

        public virtual void Setup() {}

        public virtual void Update(float secondsSinceLastUpdate){}
    }

In the ScreenWidget class we can see that it tracks values for position, anchor, scale, angle and rotation axis. It’s worth noting that the position is actually the position of the anchor point within the containing widget. If the widget isn’t nested within another widget then the position will be the position of the anchor point on the screen.

The Draw method on the ScreenWidget is called in order to render all items contained within the widget to the screen. Before doing so it applies a sequence of transforms to scale, rotate and position the widget correctly with respect to its containing widget (and thus subsequently the screen).

What’s interesting is that all these transforms and the call to DrawComponents (which by the way is what an overriding class has to implement in order to actually render items to the screen) are wrapped in a pair of PushMatrix and PopMatrix method calls. Essentially this ensures that the OpenGL model matrix (ie the matrix that is used to transform items being rendered) is the same when the method ends as when the method started – failure to do this may lead to unexpected results with items being incorrectly positioned, scaled or rotated further on during rendering. PushMatrix pushes the current matrix onto a temporary stack, whilst PopMatrix pops the top matrix on the stack off and makes it the current matrix.

We’ll start by creating the simplest of widgets, the TextWidget:

class TextWidget:ScreenWidget
{
    OpenGLFont font;
    GlyphRun title;
    public override void Setup()
    {
        font = new OpenGLFont(new Font(FontFamily.GenericSerif, 12, FontStyle.Regular));
        title = new GlyphRun(font, "Hello World!", new Size(int.MaxValue, int.MaxValue), OpenGLTextAlignment.Left, true);
        this.Anchor = new Vector3f(title.Size.Width / 2, title.Size.Height / 2, 0);
    }
    protected override void DrawComponents()
    {
        title.Draw();
    }
}

As you can see the TextWidget simply creates a GlyphRun object that can be draw during the DrawComponents method. Also note that the Anchor property has been set based on the size of the title. This will ensure that if this widget is rotated or scaled it will be done based on the centre of the text, rather than a corner.

Next is a simple container widget, funnily enough called ContainerWidget:

class ContainerWidget : ScreenWidget
    {

        TextWidget text;
        TextWidget text2;
        public override void Setup()
        {
            text = new TextWidget();
            text.Position = new Vector3f(10,10, 0);
            text.Angle = 30;
            text.Setup();

            text2 = new TextWidget();
            text2.Position = new Vector3f(20, 20, 0);
            text2.Angle = 50;
            text2.Setup();
        }
        protected override void DrawComponents()
        {
            text.Draw();
            text2.Draw();
        }

    }

You can see that the two TextWidget instances have been position and rotated by different amounts. Before we can see this we’ll need to go back to our MainForm and create an instance of the ContainerWidget. The Draw method will then be called on this instance in order to draw the two nested GlyphRuns.

public partial class MainForm : ApplicationForm
{

    public MainForm()
    {
        InitializeComponent();
    }

    ContainerWidget widget;
    protected override void SetupScene()
    {
        base.SetupScene();

        widget = new ContainerWidget();
        widget.Position = new Vector3f(0, 0, 0);
        widget.Setup();
    }

    protected override void DrawScene()
    {
        base.DrawScene();

        widget.Draw();

    }

    protected override void UpdateScene(float secondsSinceLastUpdate)
    {
        base.UpdateScene(secondsSinceLastUpdate);

        widget.Update(secondsSinceLastUpdate);
    }
}

As you can see this keeps both the MainForm and the ContainerWidget very clean in terms of the code than needs to be written to display elements.

This image isn’t particularly great as the two pieces of text are mostly off screen. So lets modify just the position of the ContainerWidget in the DrawScene method of the MainForm:

gl.PushMatrix();
gl.Translatef(100.0f, 100.0f, 0);
widget.Draw();
gl.PopMatrix();

This gives a much clearer picture of the two pieces of text but note that we only needed to translate the container widget.

OpenGL: Rotate, Scale and Translate

nick — Tue, 09 Mar 2010 04:28:49 GMT

In my previous post, OpenGL ES Wrapper- Your First Application, you would have seen that we were creating a GlyphRun that we then draw. This is actually a wrapper class that handles all the processing required to draw the text on the screen. However, it doesn’t handle the positioning of the text on the screen – by default it is located at the origin ie (0,0,0).

To move this text around the screen we can specify an amount to translate, scale or even rotate the text by using the appropriate OpenGL commands. One thing to note here is that the order in which you do these operations may change the result you see. For example in the following images the original text (first image) is translated by (50,50,0) and then rotate around the z axis by 40 degrees.

Now apply translation and rotation – note the order of the gl.Translate and gl.Rotate method calls.

gl.Translatef(50.0f,50.0f,0);
gl.Rotatef(40.0f,0,0,1.0f);
title.Draw();

Now apply translation and rotation in the other order.

gl.Rotatef(40.0f,0,0,1.0f);
gl.Translatef(50.0f,50.0f,0);
title.Draw();

You can see that the order that rotate and translate are applied makes a difference. Interestingly they almost appear in the wrong order. In the second image the original image has been translated by (50,50,0) then rotated to get the text to where it appears, whilst in the previous image the text has been rotated by 40 and then translated. This is a result of the way OpenGL uses matrix multiplication to apply transforms to what you are drawing. Each time you issue a transform the corresponding matrix is multiplied against the current matrix to calculate the position of the items you drawing.

The other thing you’ll notice is that the text appears to be rotating around the top left corner of the text. To get it to rotate around the centre of the text, you need to apply a translate function to position the text with its centre at the origin, prior to rotating it and then translating it back into it’s final position.

Update – here’s the code for doing this additional translation (again, note the order that they’re done in)

gl.Translatef(50.0f, 50.0f, 0);
gl.Rotatef(40.0f, 0, 0, 1.0f);
gl.Translatef(-title.Size.Width/2, -title.Size.Height/2, 0);
title.Draw();

OpenGL ES Wrapper: Your First Application

nick — Mon, 08 Mar 2010 13:12:42 GMT

In my previous post on Getting Started with OpenGL on Windows Mobile I talked about taking the existing OpenGL ES wrapper by Koushik Dutta and extending it to make it easier to work with. In this, and subsequent posts, I’ll show you how you can take this wrapper and start building out an application.

To get started create a new Smart Device project in Visual Studio 2008.

Note that I’ve created this against the Windows Mobile 5 SDK – if you can find a legacy device still running WM5 which supports OpenGL then this application will still run. I only bother building against the later SDKs if I particularly need one of the few features that were added since WM5.

Next, copy the two OpenGL projects from the this link into your solution folder and add them to your solution within Visual Studio. Also, go ahead and add a project reference from your application to both OpenGL projects.

You won’t be needing the designer support for your form but you do need some of the initialization values set in the Form1.designer.cs file. It’s up to you whether you move the InitializeComponent method from your Form1.designer.cs file into your Form1.cs, and then delete Form1.designer.cs, or just leave the designer.cs file there and ignore it.

At this stage I’d recommend renaming Form1 to something more descriptive. In this case my application is only going to have a single form so I have used MainForm. In the MainForm.cs file I’ve modified the class to inherit from ApplicationForm, rather than just Form – this gives me all the OpenGL initialization I talked about previously, as well as some virtual methods that can be implemented to setup, draw and update the current scene:

public partial class MainForm : ApplicationForm
    {
        public MainForm()
        {
            InitializeComponent();
        }

        protected override void SetupScene()
        {
            base.SetupScene();
        }

        protected override void DrawScene()
        {
            base.DrawScene();
        }

        protected override void UpdateScene(float secondsSinceLastUpdate)
        {
            base.UpdateScene(secondsSinceLastUpdate);
        }
    }

In this case we’re going to simply implement Hello World by creating a Font and GlyphRun in the SetupScene method:

OpenGLFont font;
GlyphRun title;
protected override void SetupScene()
{
    base.SetupScene();

    font = new OpenGLFont(new Font(FontFamily.GenericSerif, 12, FontStyle.Regular));
    title = new GlyphRun(font, "Hello World!", new Size(int.MaxValue, int.MaxValue), OpenGLTextAlignment.Left, true);
}

Then to draw the text on the screen, simply update the Draw method:

protected override void DrawScene()
        {
            base.DrawScene();

            title.Draw();
        }

Not the worlds greatest demo, but surprisingly simple for an OpenGL application. In the next post we’ll start to investigate what you can really do with OpenGL that you can’t do easily with traditional Windows Forms application.

Note: In the InitializeOpenGL function within ApplicationForm you need to include the following call otherwise your text will appear as a solid white rectangle:

gl.BlendFunc(gl.GL_SRC_ALPHA, gl.GL_ONE_MINUS_SRC_ALPHA);

Getting Started with OpenGL on Windows Mobile

nick — Sun, 07 Mar 2010 00:52:54 GMT

There are a number of good posts on working with OpenGL on Windows Mobile via the .NET Compact Framework but one thing I’ve noticed is that they don’t really try to wrap the OpenGL functionality in a way that makes it reusable as an application/game framework. Mostly the logic for rendering was intermingled with windows forms logic, such as OnPaint, which was intermingled with logic for updating the current scene. If you look at say XNA you notice that the model is very simple – essentially they have a single run loop consisting of Update and Draw. I set out to update the OpenGL ES wrapper initially provided by Koushik Dutta and since extended with some great examples across at XDA Developers. Here’s what I came up with to start with.

If you grab the OpenGL ES wrapper you will notice that at its core is essentially a single Windows Form that handles the OnPaint method in order to draw using OpenGL primitives. Nearly all the computation and rendering is done in this method. In the constructor and subsequent initialization methods there are a number of OpenGL ES calls in order to setup the display, surface and context required in order for OpenGL to draw to the screen. In order to create a reusable framework that would be a starting point for any project undertaken in OpenGL all this code would have to be wrapped in a way that it doesn’t need to be duplicated for each project.

I decided to go down the path of creating an abstract form which I called the ApplicationForm. This form has three virtual methods that the overriding form needs to implement:

protected virtual void SetupScene(){}

protected virtual void UpdateScene(float secondsSinceLastUpdate){}

protected virtual void DrawScene(){}

As you can imagine these form the basis of the Draw-Update rendering loop. Of course SetupScene is called prior to the first iteration of this loop to ensure the scene is correctly setup before the first call to Draw. Unlike some implementations which rely on a For/While loop and DoEvents (to allow windows events to be processed) I went with the approach that works in conjunction with the existing windows message pump. When the form needs to be painted the OnPaint method is invoked:

protected override void OnPaint(PaintEventArgs e)
       {
           base.OnPaint(e);

           // Draw the current scene
           RunDrawScene();

           egl.SwapBuffers(_display, _surface);
           gl.Clear(gl.GL_COLOR_BUFFER_BIT | gl.GL_DEPTH_BUFFER_BIT);

           // Update the current scene
           RunUpdateScene();
       }

As you can see this does a single pass of the rendering loop. What’s interesting is the implementation of the RunUpdateScene method:

private void RunUpdateScene()
       {
           // Check for running instance - exit if already running
           if (Interlocked.CompareExchange(ref isUpdating, 1, 0) == 1)
           {
               return;
           }

           // Only instance running, so create the thread in which to
           // invoke the UpdateScene method
           ThreadPool.QueueUserWorkItem((async) =>
           {
               try
               {
                   // Calculate the time in seconds since last update
                   var seconds = (float)Environment.TickCount/1000.0f;
                   var diff = 0.0f;
                   if (this.lastUpdate > 0)
                   {
                       diff = seconds - this.lastUpdate;
                   }
                   this.lastUpdate = seconds;

                   // Invoke the virtual UpdateScene method
                   UpdateScene(diff);
               }
               finally
               {
                   // Make sure this method can be re-entered
                   Interlocked.Decrement(ref isUpdating);

                   // Invoke "Invalidate" on the control which will cause
                   // the control to be refreshed (ie OnPaint called) leading
                   // to another iteration of Draw and Update
                   this.BeginInvoke((Action)(() => { Invalidate(); }));
               }
           });
       }

Essentially this method wraps the actual call to UpdateScene for three reasons:

To ensure only one instance of UpdateScene is being invoked at any time
To push the call to UpdateScene onto a separate thread. This prevents the UI from blocking whilst it’s in running.
To invoke Invalidate once UpdateScene has completed. This ensures that OnPaint will be invoked again and that the draw-update loop will be invoked again.

In the next post I’ll show you how to get started with this wrapper by overriding the ApplicationForm. In the meantime, try it yourself….

OpenGLESWrapper.zip

Breaking Changes: Windows Phone 7 series Development Story

nick — Fri, 05 Mar 2010 21:47:39 GMT

Well the cat’s out of the bag… actually no all that’s happened is that Microsoft has confirmed that one of the cats that was in the bag is now dead: The rumour that legacy applications will run on Windows Phone 7 series is officially dead with Charlie Kindel confirming the lack of backwards compatibility in a post entitled Different Means Better with the new Windows Phone Developer Experience.

What’s interesting is just how well the whole Windows Phone 7 series announcements have been. If you look at other blogs from Microsoft, they all have similar posts talking about the decisions that were made in order to give developers an awesome platform to start building applications on. For example the following blogs all have posts coinciding with Charlie’s post:

Andre Vrignaud: www.ozymandias.com

Break with the Past, Bright New Future: Windows Phone Application Development Platform built on XNA and Silverlight

Christian Schormann: electricbeach.org

Windows Phone 7 Series for Designers and Developers

Shawn Hargreaves: blogs.msdn.com/shawnhar

Backward compatibility

Anand Iyer: www.artificialignorance.net/blog

Windows Phone 7 Series – Developers, Developers, Developers

Michael Klucher: klucher.com

Gaming Development for the Go!

Also confirmed in a twitter Q&A at @WP7dev was support for both Silverlight and XNA development for Windows Phone 7 series. Hopefully this will provide a much more consistent rapid development environment for building phone applications whilst still making them perform.

Currently on Windows Mobile we have a number of technologies to choose from, none of which provide a great experience to both developer and consumer without a lot of cycles invested in making your application look good. The worst part about this is not the cycles spent working out what the application should look like (eg working with a designer to make it look awesome), it’s the wasted cycles having to code it from the ground up each time.

Native C++: Sure you can do nearly anything you want but you take a major productivity hit. Not to mention building a team of top notch c++ developers is becoming very difficult.

WinForms: This just sux for anything other than a mundane LOB application. Sure you can use some of the transparency tools out there to get stylish buttons, or override OnPaint to DIY it to make it look reasonable but you aren’t really going to be doing much in the way of animations, rotating elements etc.

Direct3D: Well this is a technology flop in so far as there is little hardware rendering support out there on a lot of devices. Best to ignore this one….

OpenGL: This is an interesting beast. You can write all your code in C#, yet you have the power of doing nearly any sort of animation, rotation, translation, in fact there is a lot you can do with vectors, triangles and quads. Documentation on getting started and troubleshooting is a little light on but once you get things up and running the results are quite good. You do of course have to think in matrices, projections etc which for those not familiar with these constructs can pose a bit of a learning barrier.

So, if you were going to build a mobile application today, what would you do….. Well contrary to Charlie’s post in which he suggests that developers will continue to build for Windows Mobile, I suspect the reality is that nearly every mobile developer out there will start building Windows Phone 7 series applications as soon as the tooling arrives.

OData SyncClient for MIX

nick — Tue, 02 Mar 2010 22:14:19 GMT

Yesterday Charlie Kindel tweeted about this session planner that can be used for MIX. What’s really interesting about this Silverlight application is that it has the ability to synchronise data and work offline.

Having noticed this (which you can hardly miss given the “Sync” icon in the top right corner) I wondered if there was a session on Sync. Sure enough there is a session called “Building Offline Web Apps Using Microsoft Sync Framework” with the following abstract:

Come learn about offline web applications and how they can provide a better experience to your users. Windows Azure, Microsoft SQL Azure, and Sync Framework are the core technologies that enable web developers to create offlien applications. See how to use these three technologies to produce great applications. We also introduce our upcoming support for offline Microsoft Silverlight clients and show you how you will have the flexibility to use any platform for your offline applications, device or desktop.

Coming from “mobile-land” where we take doing synchronisation (whether it be DIY webservices, RDA, Merge, Sync Services) for granted the idea that finally web developers might get the concept of offline applications is quite laughable. But, leaving that aside what interested me is what this “upcoming support for Silverlight” is going to be – well they kind of let the cat out of the bag with the session builder. Whilst there is a pseudo attempt at hiding what’s going on in the sync (I’m guessing more out of privacy concerns rather than hiding the sync technology) this is easily broken using Fiddler (you’ll have to enable https tracing in Fiddler and add the Fiddler certificate to your trusted cert list – see http://www.fiddler2.com/Fiddler/help/httpsdecryption.asp for instructions).

A typical sync session looks like this:

Notice that each request to either GetChanges or UploadChanges has the same suffix:

/ODataSync.svc/GetChanges/377d1869-e69a-4b67-9ddd-392169e9b06e?userToken=d39ea0f0e5104c4aad457b897a7b4b62

/ODataSync.svc/UploadChanges/377d1869-e69a-4b67-9ddd-392169e9b06e?userToken=d39ea0f0e5104c4aad457b897a7b4b62

The response to the first GetChanges call (which doesn’t contain any data) looks something like:

In this we can see that there is an anchor and then there are a list of entries. Each entry, under the content node, contains a series of properties. As you can see sync is using odata to transport entity information.

Each successive GetChanges call sends the anchor back to the server – I’m guessing this anchor value is used to track the synchronization state of the client with the server.

“eyJLbm93bGVkZ2VCbG9iIjoiQUFBQUJRQUFBQUFBQUFBQkFBQUFBQUFBQUFVQUFCQUFBQUFDTjMwWWFlYWFTMmVkM1RraGFlbXdidGxzQU1rZkowNyt1MHNWYXE1YVBDNEFBQUFZQUFBUUFTZ0NBQUFCQUFBQUZRQUFBQUVBQUFBQkFBQUFBQUFBQUJjQUFBQUJBQUFBRmdBQUFBRUFBd0FBQUFBQUFBQUFBQUFBQUJrQkFBQUFBQT09IiwiVGFibGVXYXRlcm1hcmtzIjpbeyJLZXkiOiJTY2hlZHVsZUl0ZW0iLCJWYWx1ZSI6MTcwNTZ9XX0=”

Of course, the session planner must be storing data in Silverlight’s isolated storage. After a little poking I managed to find some of the data being stored:

{"Anchor":"eyJLbm93bGVkZ2VCbG9iIjoiQUFBQUJRQUFBQUFBQUFBQkFBQUFBQUFBQUFVQUFCQUFBQUFDTjMwWWFlYWFTMmVkM1RraGFlbXdidGxzQU1rZkowNyt1MHNWYXE1YVBDNEFBQUFZQUFBUUFTZ0NBQUFCQUFBQUZRQUFBQUlBQUFBQkFBQUFBQUFBQUFFQUFBQUNBQUFBQUFBQUFBQUFBRWswQUFBQUFRQUFBQUFBQUVrekFBQUFGd0FBQUFFQUFBQVdBQUFBQVFBREFBQUFBQUVBQUFBQUFBQUFHUUVBQUFBQSIsIlRhYmxlV2F0ZXJtYXJrcyI6W119","Data":[{"Key":"speaker","Value":[{"__type":"ItemChangeOfDbSpeakerzgKIiSuC:#Microsoft.Synchronization.Offline","IsCreate":false,"IsDirty":false,"IsTombstone":false,"Item":{"Bio":"Beginning life as an art student, then after a stint in the military joining the world of technology, Adam Kinney feels right at home in that sweet spot between Designer and Developer. Always at least a part-time evangelist, Adam has traveled the trail of UI technologies. First HTML\/CSS, then Flash, WPF and now Silverlight, the one client technology to rule them all, he has enjoyed learning, experimenting and teaching them all.\r\nAdam’s current focus is Expression Blend, the first interactive design tool that’s really made him happy as a designer and developer.","SpeakerDisplayName":"Adam Kinney","SpeakerFirstName":"Adam","SpeakerID":"b5056969-1f9f-4268-8cbd-64a2fcb7080f","SpeakerLastName":"Kinney","SpeakerName":"Adam-Kinney"}},{"__type":"ItemChangeOfDbSpeakerzgKIiSuC:#Microsoft.Synchronization.Offline","IsCreate":false,"IsDirty":false,"IsTombstone":false,"Item":{"Bio":"","SpeakerDisplayName":"Akash Patel","SpeakerFirstName":"Akash","SpeakerID":"cd381f2f-cdca-469a-a937-dae1ad6f72d6","SpeakerLastName":"Patel","SpeakerName":"Akash-Patel"}},

Sure enough as you can see the anchor is being persisted, along with a series of entities. There are typical fields that you’d expect with synchronization such as IsCreate, IsDirty, IsTombstone but very little in the way of date time or versioning stamps. This again points towards the server doing the bulk of the synchronization logic.

Well that’s enough poking around with the session builder for one day – I can’t wait to see this session at MIX and see what the sync team have been working on.

LINQ to SQL generator fails due to custom code

nick — Mon, 01 Mar 2010 04:21:12 GMT

Today I decided to do something quite innocuous, or so I thought, on an existing application that happened to use LINQ to SQL. I needed to add an additional field to an existing table which I did quite easily via SSMS. However, when I came to update the LINQ to SQL model file I ran into all sorts of issues. The easiest way I’ve found in the past to update the LINQ to SQL model is to simply delete the table that you need to update and drag it onto the design surface from Server Explorer. Normally this updates the model and doesn’t usually break anything (unless you say delete a field that is in use in your code in which case the compile error is an artefact you want).

Today this process seemed to go completely haywire for no reason. I was getting 10-15 compile errors – since I was just adding a field I shouldn’t have seen any. Thinking that I’d broken something accidentally I reverted back to the version in subversion and tried again. Same result. Looking in Solution Explorer it was clear why these errors were being generated – there was no .designer.cs file to go alongside the .dbml LINQ to SQL model file.

I right-click on the dbml file in Solution Explorer and selected “Run Custom Tool” (for those unfamiliar with the Visual Studio custom tool model this is essentially an external executable that is called to automatically create or modify files in your solution – in this case create the .designer.cs file). This time I at least got an error message:

Error: The custom tool ‘MSLinqToSQLGenerator’ failed. Unsepecifed error

Interestingly it also opened up a file in which I had added some custom properties for my LINQ to SQL entities. I found that if I excluded this file from my solution I was again able to run the custom tool to generate the .designer.cs file. So, in order to make schema changes from now on I need to:

-Exclude my custom properties file

-Make changes to my LINQ to SQL model

-Run the Custom tool to generate the .designer.cs file – this is automatically run if you save or close the model designer

Update: Actually, you need to do a build of the project that contains the LINQ to SQL model prior to adding the custom properties file back into the project. Otherwise Visual Studio decides to nuke the .designer.cs file again.

-Include my custom properties files

-Rebuild my solution.

Hope this helps anyone else seeing the same issue

Does Windows Mobile 6 Smell (part II)?

nick — Sat, 27 Feb 2010 06:49:41 GMT

In my previous post I talked about Microsoft and the enterprise and how it had help shape Windows Mobile 6.x. Now I want to look at some of the implications of this strategy, specifically looking at how the attitude towards touch input has changed over time.

Touch v’s Non-Touch v’s Multi-Touch

One of the things that really differentiated Windows Mobile was it’s ability to work on multiple different form factors, from your non-touch txt friendly devices with keyboards through to your candy bar devices through to your pda-style devices with on-screen keyboards. Track back a few years and you would have seen the names Pocket PC and Smartphone being used to describe devices with and without a touch interface. With a move to align the two operating systems these came to be known as Windows Mobile Professional and Windows Mobile Standard – personally I think this did more than confuse the market who were already confused by the double use of the word Smartphone.

But this post wasn’t supposed to be a Windows Mobile history lesson, instead it was to look at our opinions on touch have evolved. If you recall back to the Pocket PC days there were very few people who actually used “touch” to interact with their device. Most uses whipped out their stylus and used that to push and poke at the screen. They would tap at the on-screen keyboard or even learn how to use the quirky text recognition capabilities of the device. This process was quite painful, particularly if you were responding to a text message or email. This is in part why both hardware keyboards and the Smartphone increased in popularity – both these addressed the problem of how to quickly navigate and type on the device.

The challenge with a physical keyboard is that no matter how to position it you end up with a tiny keyboard that simply adds weight and size to the device. Text entry, whilst quickest using a full qwerty keyboard was still a far shy from entering it on the desktop and often the extra hassle of sliding out a keyboard, waiting for the screen to reorientate and then entering text was enough to put off a lot of users.

The challenge with Smartphone is that it just sux – ok, you have me, I’m not a Smartphone advocate. Whilst I find that the interface is quick to navigate nearly all the applications are somewhat lacking or clumsy to use. Take internet explorer for example – you either have a little arrow cursor that you drag around the screen using a dpad or you jump from link to link, often making the text of the website very difficult to read. Personally I’ve never liked this style of device and it was scary a couple of years ago because it seemed that 90% of all new devices being released by OEMs were a Smartphone, rather than having a touch screen.

From a development perspective we saw the convergence of Smartphone and Pocket PC into Windows Mobile as a good thing. It meant we could build a single application that would work on both styles of devices. Unfortunately, this is a bit like building a desktop application and running it on the device – great idea, but results in an aweful user experience as either the desktop application is limited to display what’s available on the device (ie small screen real estate) or the application has to scale down to fit to the device (resulting in small controls that are hard to use). Guidance from Microsoft even suggested that developers should build to target Smartphone so it will work on both devices.

This whole topic became even more interesting when Apple released the iPhone and multi-touch came into the mainstream. Unfortunately the Windows Mobile team failed to get it and released 6, 6.1 and 6.5 without any support for multi-touch. In fact it’s only been with the release of the HTC HD2 that we’ve even seen capacitive screens for Windows Mobile which would effectively allow multi-touch. I believe this was because there was a misunderstanding on how users wanted to use their device. Too much research focussed on looking at ways to improve what users were currently doing (eg using a stylus), rather than exploring more innovative ways for the users to do things (eg making all controls larger so that the user can use touch instead of a stylus).

Now, finally Microsoft has awoken and we are seeing a new era of devices and operating systems heavily geared towards making touch (and I’m sure in the future multi-touch). Windows Mobile 6.5.3 has restyled controls, repositioned Start menu and Ok buttons, specifically geared to making it easy to navigate with touch and gestures. Windows Phone 7 series is all about touch, swipe, gesture and motion in general. It’s clear to see that this is the way forward and that the old Blackberry style non-touch devices are a thing of the past.

Does Windows Mobile 6 Smell?

nick — Thu, 25 Feb 2010 22:12:25 GMT

If you ask most users what they think of Windows Mobile they either don’t know what it is (most non-techie consumers) or they shudder saying that slow, overly complex phone that I never use now I have…. Anyone would think that Windows Mobile smells. I’d like to put forward some points that at least explains why it looks and smells the way it is. You may even decide to give the current generation of Windows Mobile 6.5.3 devices a go.

Microsoft and the Enterprise

I think the first point I’d like to make is that I doubt at any stage Microsoft decided that the end user wasn’t the highest priority when designing and building Windows Mobile. The whole “end-user-first” message that’s coming from Microsoft is just another re-hash of the “Age of User Experience” message that we saw a couple of years ago. What I do buy is that Microsoft has changed focus on which end user they’re putting first, or at least, what end user activities should come first.

In the past the design of Windows Mobile was geared towards an end user who worked for an enterprise, was connected to Exchange server and the reason for having a device was to make phone calls, send sms, triage email, work with contacts, calendar and tasks to get their work done. Now we’re seeing a new era where Windows Phone 7 is about supporting end users in every facet of their lives – helping them stay in contact, entertain them, help them relax, get work done, oh and of course make a phone call. Actually the latter seems to have been almost an after thoughts as there is not even a hardware call and/or hang up button according to the specs released by Microsoft last week.

So I guess the question has to be asked as to why the focus was on the enterprise user? Microsoft’s entry into the mobile phone market came as an extension of their embedded operating system. In fact Windows Mobile is essentially Windows CE in a specified configuration, with additional modules, such as Office Mobile and of course a phone stack. As such it seemed logical for them to enter this space in order to support enterprise users.

Once in this space it appears that Microsoft saw RIM as one of the main competitors with their Blackberry devices. Those familiar with Microsoft codenames will know that Crossbow was one of the code names used internally for one of the previous versions of Windows Mobile – this happens (probably coincidentally) to be the name of a pesticide that can be used to get ride of the blackberry plant (ref Website). The Blackberry OS has traditionally been menu centric, so as long as Windows Mobile only had as single “Start” menu it was considered to be a safe bet. Also, since Blackberries didn’t have touch screens, supporting touch (rather than stylus, and definitely not multi-touch) input wasn’t really considered a core use case. Again the result was that Windows Mobile continued to evolve towards a dpad/keyboard driven interface – in the enterprise this resulted in some very effective office worker devices that could be used to rapidly triage email but they weren’t the nicest consumer devices.

More on this discussion in future posts….

Windows Phone 7 Series Development – What Do You Want?

nick — Thu, 25 Feb 2010 12:35:09 GMT

Since it’s announcement over a week ago the question on all our lips is “what’s the development story going to be?” Whilst there has been countless rumours regarding support for Silverlight (perhaps third time’s like for this can of worms….) and XNA it won’t be until MIX that we’re going get a good look at what Microsoft has in store for us mobile developers going forward.

In the meantime, I took a little bit of time out to think about the current generation of development tools. Now, I’m going to overlook the obvious failing around stylish controls for building Windows Mobile applications (which in my opinion is one of the fundamental reasons the iPhone is trumping Windows Mobile applications at the moment, after all it sure as hell isn’t the development language!). What I’m interested in is the development/debugging/testing/deployment story, so here’s a list of the tools/frameworks etc that we have at the moment. I’ll start this list but I suspect it may have to be continued as I remember things that I’ve omitted.

Microsoft

IDE - Visual Studio

- Support for Native, C# and VB.NET development
- Visual Designer for Forms and Controls, including designer skin
- Intellisense, Code completion
- Debuggin support
>> Breakpoints
>> Watches and variable inspection
>> Datatips
>> Step through/over

Managed Frameworks

- .NET Compact Framework
- Windows Mobile managed libraries
>> POOM (contacts, calendar, email, tasks)
>> Camera
>> Contact picker
>> State and Notification Broker
[missing APIs could be p/invoked to native APIs]
- Rich networking stack (sockets & httprequest)

Data Story

- SQL Server Compact
- Multiple Synchronization Frameworks (RDA, Merge Replication, Sync Services)
- Designer support for connecting to web services

Support Tools

- Device Emulator
>> Able to change configuration
>> Able to adjust system state
>> Able to connect to ActiveSync/WMDC to simulate docking real device
- Cellular Emulator
- Hopper

3rd Party

- Smart Devices Framework (OpenNETCF)

- Mobile In The Hand

- Mobile Client Software Factory

- Orientation Aware Control

- NLog

With this list in mind, what do you feel is missing? If your answer is nothing, then think harder – after all there must be a reason why Windows Mobile 6.x was failing to attract users and developers alike.

Motorola Devour is yet another average Android device

nick — Wed, 24 Feb 2010 22:59:11 GMT

On the way from the airport into the Melbourne CBD I read the ZDNet Review of the Motorola Devour and I think it confirms my view that Android, whilst perhaps a great operating system for OEMs to build on, lacks anything at all that would draw me to the platform. The Devour seems an overly unimpressive device both in terms of the hardware spec and the software.

From looking at the hardware I can’t get away from the feeling that Android devices, pretty much across the board, have been designed with your average “google-loving-geek-boy” in mind. The ZDNet review comments that the design of the Devour could be considered “retro” (from Wired’s Priya Ganapati) and that it’s the “next chapter of Motorola’s signature industrial design” but I think the hardware appears chunky and uncomfortable, and lacks any sense of true style.

From the software perspective it of course features the standard Android home screen featuring icons (urgh, so last year – get with the program, it’s all about square updating tiles now…. we’ll probably come back to that to determine whether Microsoft’s gamble pays off there). What’s interesting is that like other Android devices it supports the latest version of Google Maps. With Google increasingly leaning towards providing the latest features (such as navigation) only on the version of Google Maps for Android, it will be interesting to see what other players like Microsoft bring to the table.

[As an aside – the recently released Windows Mobile 6.5.3 DTK includes a mapping framework sample. The sample is written in native code but has a managed wrapper so can be used in either a native or .NET Compact Framework application. This sample is a great starting point for anyone wanting to build an application making use of mapping on the Windows Mobile platform. No information yet as to whether there will be a similar control/framework for Windows Phone 7 series development. More to come on this topic…]

Is Windows Phone 7 series going to be great for developers?

nick — Tue, 23 Feb 2010 22:16:42 GMT

As you’ve no doubt seen Microsoft announced Windows Phone 7 series last week at Mobile World Congress in Barcelona. I guess I’ll start off with the mandatory “here’s what it looks like” piece: Here’s a couple of screenshots for you to go “oh-ah” over – if you want more you can head over to Rob’s blog where he’s got some more images, as well as the official Windows Phone 7 Series website.

Now the reason for this post is a way of providing commentary following the Focus, Focus, Focus post by Charlie Kindel. Firstly, I want to say that I love the fact that there appears to be such a high level of “focus” from the Windows Phone team. It would appear that despite severely dropping the ball with Windows Mobile 6.x I think the departure from this platform to Windows Phone 7 series will definitely be a positive move and will position Microsoft in a strong position in the mobile market.

Yes, I know everyone’s (well at least a large proportion of the techie crowd) going on about Android this and Android that but they’re seeing the same issues Microsoft saw 5 years ago with market fragmentation and a UI that is already very dated. Unless Google does something remarkable prior to Windows Phone 7 hitting the stores I suspect we’ll see an un-remarkable end to Android phones being the alternative to buying an iPhone.

Coming back to Charlie’s post – What I found particularly interesting is the priority list regarding the developer audience, which essentially puts us enterprise developers close to the bottom of the heap. Initially you might look at that and say “but enterprise has been Microsoft’s staple when it comes to WM” but you have to remember this is NOT Windows Mobile, it’s Windows Phone 7, it’s a new era of devices and with that comes all the issues you’d expect to see with a v1 product. Actually as an aside I’m surprised they went with 7 – this is so radically different they could have just gone with Windows Phone and be done with it. Alternatively they could have just picked a single manufacturer and released the Microsoft Phone but that’s a completely different topic altogether.

So, where does that leave us enterprise developers? Well the first thing you should do is realise that Charlie’s list is only a priority list, it doesn’t imply that you can’t do enterprise development. In fact, I’m guessing that in order to support the Pro and non-Pro developer audience in their ability to create awesome applications for consumers, a large proportion of the enterprise capabilities will be there.

So what may be missing for enterprise developers? If you consider enterprise as including line of business applications such as stock management, then it is highly likely that when Windows Phone 7 ships there won’t be hardware out there to support barcode scanning etc. This isn’t actually a new problem as hardware manufacturers for LOB devices typically take 6-12 months (or more in some cases) to update their devices with new operating system versions.

Microsoft also hasn’t talked about what the deployment story will be for applications and the extent of the programming apis that will be available for application developers to interact not only with other services on the device (eg camera or the phone), storage, other applications, PIM data (eg contacts, calendar) and whether there will be developer libraries for connecting to Windows Azure, Live Id and other hosted services. My guess is that like previous versions of Windows Mobile there will be apis for accessing some of these – how this affects enterprise development is really dependent on what apis are there and which are missing. For anyone interested in this story, you should be heading to MIX where they’ll be disclosing the developer story.

Windows Mobile 6.5.3 DTK (not SDK or 6.6) download available

nick — Wed, 17 Feb 2010 00:24:00 GMT

Get it while it's hot from the download center. The content in my original overview of the Windows Mobile 6.5.3 SDK is still accurate. However the installation issues have been resolved and there is a bunch of things (like the help files and the Map Framework sample) are now installed correctly. The installation of the DTK should not affect any of the existing emulator images you have installed. Stay tuned for more information on what's in the DTK.

Windows Mobile 6.5.3 DTK - Ready, Set….. Oh wait, hang on….. Go!

nick — Tue, 16 Feb 2010 18:35:19 GMT

As some of you will be aware there was a first attempt at releasing the Windows Mobile 6.5.3 DTK (now missing) earlier this month. Despite a number of bits being missing or not installed correctly there are definitely some good bits coming in the DTK (take for example the Widget development story within VS2008). According to Todd in his Marketplace Momentum post we should see the real version of the DTK later this week. Check back with this blog to find out more about the actual release when it happens.

Windows Mobile 6.5 SDK is now Missing In Action

nick — Mon, 25 Jan 2010 22:04:24 GMT

According to Twitter, which Microsoft clearly believes as the best way to communicate to its developer community, the Windows Mobile 6.5 SDK has been pulled.

Note that whilst this acknowledges that the SDK wasn’t properly tested there is apology to a developer community that collectively has probably wasted thousands of man hours installing, uninstall and reinstalling SDKs to get machines back to a working point.

I totally agree that the SDK should have been pulled as soon as there was a known issue with it but for Microsoft to continue to insult its developer audience is just one slap after the other.

Windows Mobile 6.5 SDK Overview

nick — Sat, 23 Jan 2010 00:44:14 GMT

The first thing to note about the newly released Windows Mobile 6.5 SDK is that it effectively comes in two parts. If you want to build applications for both the professional (ie touch screen devices) and standard you need to get both versions of the sdk. This way you will get all the emulator images.

For all those who have started working with Visual Studio 2010 the news is not great. As you are not doubt aware from the beta versions there is currently no support within VS 2010 for doing mobile development. This SDK release does not change this, you will continue to have to use Visual Studio 2008 for doing Windows Mobile development, with the exclusion of widgets, which you can do as a web site in VS 2010 and manually package it up for deployment.

Post install I thought I’d take a look at the readme file to see what’s changed in this SDK. Doh! Someone forgot to check this as the title reads “Windows Mobile 6 SDK Refresh”. The contents seem to make the title which made me think that I’d installed the wrong SDK but no, there’s a Start Menu item for “Windows Mobile 6.5 SDK” so I’m guessing that I didn’t get it wrong.

Following the readme “fail” I decided to launch Visual Studio 2008 to see whether I could spot the differences myself. From the New Project dialog (below) you can see that there is a new node “Widgets for Windows Mobile”. Given my recent set of blog posts on building Windows Mobile widgets I was really eager to see what this would entail.

After selecting the SimpleWidget option I was presented with a basic web site layout containing sub folders for css and script files. Personally I would have liked to see another sub folder for images.

Looked like a good starting point so I thought I’d try running it. Before doing so I went to start up a Windows Mobile 6.5 emulator image. I ran up the Device Emulator Manager only to discover that none of the 6.5 professional images (that were all there from when I’d install the 6.5 emulator image pack released last year) were there. Thinking I must be missing something I installed the Standard edition of the 6.5 SDK. This only made matters worse, now I have no Windows Mobile 6 or 6.5 images.

Thinking that something must have gone wrong I uninstalled both 6.5 SDKs and rebooted my machine. After installing the Windows Mobile 6.5 Professional SDK the professional emulator images reappeared (phew!) and I returned to my SimpleWidget project. I noticed that the device toolbar wasn’t enabled, so the widget project doesn’t understand, or wants to use a device/emulator to debug with after all. This got me thinking about what the debug experience was going to be. I pressed F5 to debug and wow, I got the following debugger experience within IE:

After enabling the ActiveX control I got the following output – looks very similar to what I’d expect on the device. Unfortunately the ActiveX prompt appears every time you start the debugger. The simple work around to this issue is to not stop the debugger. Because you are effectively working with a mini web site you can change content (ie htm, css, js) and just refresh the browser to see your changes.

What’s cool is that you can do the following:

Set breakpoints and then walk through your code inspecting variables.

Use the “hide” (which changes to “show” when clicked) button to mimic the widget going into the background. The onshow and onhide events get invoked.
Change the resolution and orientation of your widget to see what it would look like in different perspectives. Changing resolution is particularly important as you need to cater for these devices differently otherwise your widget will be either unusable or look childish.
You can change most of the System State properties to see what effect it has on your device. See my post on System State (aka Notification Broker) and Device Information for more information on working with this information.
Even the menus are simulated:

Of course, whilst this is convenient for development, you must and I repeat must test your widgets on real devices.

Returning to Visual Studio, I took a further look at the widget project itself. If you go to Properties on the project you get the following:

I’m not entirely sure what all the parameters mean yet but I’m sure they’re in the help files somewhere (actually, no it appears not. The help files seem to be the standard WM6 SDK files). What does interest me is the Output Path parameter. If I navigate there I notice three files: the first two, Harness.html and Harness.js are what make the debugger happen, the last, SimpleWidget1.widget is of course the widget file which you can copy and install on your device or emulator to see how it runs on your device.

I must admit I expected to see a manifest file editor as part of the project properties. Not seeing it there I thought I’d double-click the config.xml files (which of course is the manifest file for a widget). Wow – notice the nice editor it displays, rather than a basic xml editor.

My only criticism here is that the team haven’t really thought this through. For a widget you would typically supply two icons if you are going to deploy to both professional and standard devices, one being a png, the other being an ico.

That’s enough about widgets. Let’s take a quick look at the emulator. Notice that this isn’t the 6.5 we’re used to see in the emulator. In fact if you look in the second image you’ll see that this is build 23090 which is around the build number that everyone has been talking about for Windows Mobile 6.5.3.

In brief you’ll notice that the start and ok/X buttons are at the bottom of the screen. A number of the menus are now graphical. The notification area drops down to be a graphical set of links and the tabs are no longer tabs, they’re more of a scrolling system (left-right) at the top of the page. These are all moves to better support touch input and going forward capacitive screens.

I’m sure there’s plenty more in the Windows Mobile 6.5 SDK that I haven’t discovered yet. Other than the major FAIL around the installation process (I would recommend uninstalling any previous WM6.5 emulators first) and the readme/help documentation I’m glad to see Microsoft starting to release new tools for us mobile developers.

Windows Mobile 6.5 SDK Available for Download

nick — Fri, 22 Jan 2010 22:51:00 GMT

Just posted to MSDN Downloads is a brand new SDK for doing Windows Mobile development. The SDK is coupled with new emulator image downloads for the following languages GER, FRA, ITA, JPN, CHS and ESP. Go download the bits from the Windows Mobile 6.5 SDK Download page.

Windows Mobile Widget 101 - Persistence

nick — Sun, 17 Jan 2010 22:00:25 GMT

Prior posts in this series:

Out of the box the Windows Mobile widget API provides only basic support for saving and retrieving data. The documentation on MSDN shows how you can read and write basic key-value pairs for values up to 4000 bytes but what happens if you want to store more than that? And, what do you do if you want your widget to run as a gadget or on a desktop browser? The following code, which we’ll add to widget.js handles all these scenarios.

-----------------
widget.js
-----------------

//-----------------------------------------------------------------------
// Storage
//-----------------------------------------------------------------------

        // saves key-value pair (length restricted, use persistData for long string values)
        saveKeyValue: function (key, value) {
            if (window.widget) {
                window.widget.setPreferenceForKey(value, key);
            }
            else if (isGadget && isGadget == true){
                return System.Gadget.Settings.writeString(key,value);
            }
            else {
                return Cookie.set(key,value,365);
            }
        },

        // retrieves key-value pair
        retrieveKeyValue: function (key) {
            if (window.widget) {
                return window.widget.preferenceForKey(key);
            }
            else if (isGadget && isGadget == true){
                return System.Gadget.Settings.readString(key);
            }
            else {
                return Cookie.get(key);
            }
        },
        // Persists Data (any length)
        persistData: function (key, value) {
            if (!value || value == null) {
                WidgetAPI.saveKeyValue(key, 0);
                return;
            }

            var str = value;
            var i = 0;
            var j = 0;

            while (j < str.length) {
                var inc = 2000;
                if (j + inc > str.length) {
                    inc = str.length - j;
                }
                var tmp = str.substring(j, j + inc);
                j += inc;
                WidgetAPI.saveKeyValue(key + i, tmp);
                i += 1;
            }
            WidgetAPI.saveKeyValue(key, i);
        },
        // Checks to see if data exists
        dataExists: function (key) {
            var count = WidgetAPI.retrieveKeyValue(key);
            if (typeof(count)=="undefined" || count == null || count <= 0) {
                return false;
            }
            else {
                return true;
            }
        },

        // Retrive data (any length)
        retrieveData: function (key) {
            var count = WidgetAPI.retrieveKeyValue(key);
            if (!count || count == null || count <= 0) {
                return null;
            }
            var str = "";
            for (var i = 0; i < count; i++) {
                str += WidgetAPI.retrieveKeyValue(key + i);
            }
            return str;
        }

And of course we need some sample code added to main.js and main.htm to demonstrate this in action:

-----------------
main.htm
-----------------
        <div id="welcome">Welcome....</div>
        <div id="persistenceDemo">Name:
            <input id="nameTextbox" type="text" />
            <input id="submitButton" type="button" value="Save" onclick="saveName()"/>
        </div>

-----------------
main.js
-----------------

function onLoad() {
    // Code omitted as same as previous posts

    sayWelcome();
}

function sayWelcome() {
    var welcome = $get("welcome");
    var name = WidgetAPI.retrieveData("Name");
    if (!name || name == null) {
        name = "...";
    }
    welcome.innerHTML = "Welcome " + name;
}

function saveName() {
    var txt = $get("nameTextbox");
    WidgetAPI.persistData("Name", txt.value);
    sayWelcome();
}

When you run the widget you can enter a name, which will be persisted across runs of your widget. The following screenshots are from the widget running as a widget, gadget and in the desktop browser. Note that the gadget is unique in that if you close the gadget and open another instance it will not remember your settings. This is because each instance of the gadget has its own unique storage (so you can run multiple instance of the gadget at once). However, if you restart your computer with your gadget running you will notice that it remembers the values. This is because it is the same gadget instance!

Windows Mobile Widget 101 – System State (aka Notification Broker) and Device Information

nick — Sat, 16 Jan 2010 05:31:49 GMT

Prior posts in this series:

Whilst Windows Mobile widgets are great, they definitely have their shortcomings when compared for true mobile application. One such area is in the ability to interact with device hardware and information. Further, it appears that every OS provider seems to be tackling this differently. If you look at S60 they have expose a wealth of device and user information via their widget API. Unfortunately one of the weaknesses of the current Microsoft implementation of widgets is that there are only a few pieces of device information you can query (out of the box) and no user information (ie contacts, calendar…). If you want to do more, you have to build and deploy ActiveX controls to assist your widget.

Returning to the Windows Mobile widgets and out of the box you get the following pieces of system information. All are exposed via the SystemState object.

CradlePresent

A Boolean value indicating whether the device is cradled.

DisplayRotation

An integer value indicating whether the display is in portrait or landscape mode.

PhoneHomeService

A Boolean value indicating whether the device is presently registered on its home network.

PhoneOperatorName

A string indicating the name of the device’s mobile operator.

PhoneRoaming

A Boolean value indicating whether the device is currently roaming.

PhoneSignalStrength

An integer indicating the phone signal strength, expressed as a percentage of full strength.

PowerBatteryState

An integer indicating the current state of the battery, such as whether the battery level is critically low or if the battery is charging.

PowerBatteryStrength

An integer indicating the current battery strength, expressed as a percentage of full strength.

And here’s an example of how you would access one of these properties. You first need to create an instance of the SystemState object. Next, query the actual property you are interested. Finally, if you want to receive notification when that property changes, you need to add an event handler to the “changed” event, passing in the callback method as the second parameter.

var systemState = widget.createObject("SystemState");
var cradledState = systemState.CradlePresent;
cradledState.addEventListener("changed", cradled);

Note, that the SystemState properties and the callback event are all exposed via the Windows Mobile Notification Broker that has been around since Windows Mobile 5. What I don’t get is why only this limited set of properties?

One of the frustrating things about working with widgets is determining whether your widget has a connection, firstly to a network and secondly to your server. Whilst there is no “IsConnected” property exposed via the SystemState object, you can use a combination of properties to try and deduce if there is a network connection.

Lets start with the widget.js file. You have to be careful when working with the widget API to ensure you don’t break your cross-platform capabilities. Of course if you don’t want your widget to run as a gadget you can eliminate quite a bit of the following code.

-----------------
widget.js
-----------------

var WidgetAPI = function () {
    return {
        // Code omitted as same as previous post
        systemState: null,
        stateEvents: null,
        createSystemState: function () {
            if (WidgetAPI.systemState != null) return;

            if (window.widget) {
                WidgetAPI.systemState = window.widget.createObject("SystemState");
            }
            else {
                WidgetAPI.systemState = {};
            }
        },
        getCradleState: function () {
            WidgetAPI.createSystemState();

            if (!WidgetAPI.systemState.CradlePresent) {
                WidgetAPI.systemState.CradlePresent = true;
            }

            return WidgetAPI.systemState.CradlePresent;
        },

        listenForCradleStateChanged: function (callback) {
            WidgetAPI.listenForStateChanged(WidgetAPI.getCradleState(), callback);
        },

        getPhoneStrengthState: function () {
            WidgetAPI.createSystemState();

            if (!WidgetAPI.systemState.PhoneSignalStrength) {
                WidgetAPI.systemState.PhoneSignalStrength = 100;
            }

            return WidgetAPI.systemState.PhoneSignalStrength;
        },

        listenForPhoneStrengthStateChanged: function (callback) {
            WidgetAPI.listenForStateChanged(WidgetAPI.getPhoneStrengthState(), callback);
        },

        listenForStateChanged: function (state, callback) {
            if (window.widget) {
                state.addEventListener("changed", WidgetAPI.createSafeListenerCallback(callback));
            }
        },
        entered: false,
        createSafeListenerCallback: function (callback) {
            try {
                WidgetAPI.stateEvents = new Date();
                WidgetAPI.stateEvents.setTime(WidgetAPI.stateEvents.getTime() - 60 * 1000);
                var func = function () {
                    if (WidgetAPI.entered == true) return;
                    try {
                        WidgetAPI.entered = true;
                        var lastInvoke = WidgetAPI.stateEvents;
                        lastInvoke.setTime(lastInvoke.getTime() + 1 * 1000);
                        if (lastInvoke < (new Date())) {
                            WidgetAPI.stateEvents = new Date();
                            if (callback && callback != null) {
                                callback();
                            }
                        }
                    }
                    finally {
                        WidgetAPI.entered = false;
                    }
                };
                return func;
            }
            catch (e) {
                alert(e);
            }
        }

    };
} ();

The other thing you will notice about this code is that there is a wrapper used for calling the event callback. When certain system events are raised (eg PhoneSignalStrength) a number of events will be raised within a short period of time. This wrapper protects against this. Warning: Some events will be hidden by this wrapper, so only use it if you don’t mind if some events are missed. In our case we are only using the change in state to prompt the application to check if it still has connectivity.

In the utils.js file we’re going to add a simple Ping routine that can be used to detect if a server is reachable. It does so by downloading a specified image within a given timeframe. Note that you should use a small image as you don’t want to waste network bandwidth.

-----------------
Utils.js
-----------------

var Ping= {};
Ping = {
    img: null,
    imgPreload: null,
    timer: null,
    success: null,
    fail: null,
    hasFailed: false,
    init: function (imgUrl, pingCallback, failCallback) {
        Ping.img = imgUrl;
        Ping.success = pingCallback;
        Ping.fail = failCallback;

        Ping.imgPreload = new Image();
        Ping.hasFailed = false;
        Ping.imgPreload.onload = function () {
            clearTimeout(Ping.timer);
            Ping.timer = null;
            if (Ping.hasFailed == false && Ping.success != null) {
                Ping.success();
            }
        };

        Ping.imgPreload.src = Ping.img;
        if (Ping.fail != null) {
            Ping.timer = setTimeout(Ping.fail_to_ping, 10000);
        }
    },

    fail_to_ping: function () {
        clearTimeout(Ping.timer);
        Ping.timer = null;
        Ping.imgPreload = null;
        Ping.hasFailed = true;
        if (Ping.fail != null) {
            Ping.fail();
        }
    }
};

Now, to bring these together we’re going to introduce a new file, network.js, that registers for changes to the cradle and phone signal strength, and then based on those changes calls the Ping function to determine if the server can be reached. Note that as we don’t have any WiFi state information we can’t just assume that because the device is not cradled and there is no phone signal there is no data connection. As such, we just use the change in state to invoke ping the server. Again, there is some time checking around the Ping function to make sure it isn’t called too frequently.

-----------------
Network.js
-----------------

var Network = function () {
    return {
        isConnected: false,
        connectionTestUrl: "http://www.builttoroam.com/ping.gif",
        lastPing: null,
        minimumPingSeparationInSeconds: 30,
        connectionStateChanged: null,
        init: function (stateChangedCallback) {
            if (stateChangedCallback && stateChangedCallback != null) {
                Network.connectionStateChanged = stateChangedCallback;
            }

            WidgetAPI.listenForCradleStateChanged(Network.cradledStateChange);
            WidgetAPI.listenForPhoneStrengthStateChanged(Network.phoneStrengthChange);

            Network.testConnection();
        },

        cradledStateChange: function () {
            Network.testConnection();
        },
        phoneStrengthChange: function () {
            Network.testConnection();
        },

        testConnection: function () {
            var pingOk = false;
            if (Network.lastPing == null) {
                pingOk = true;
            }
            else {
                var pingTime = new Date();
                pingTime.setTime(Network.lastPing.getTime() + Network.minimumPingSeparationInSeconds * 1000);
                if (pingTime < (new Date())) {
                    pingOk = true;
                }
            }

            if (WidgetAPI.getCradleState() == false || WidgetAPI.getPhoneStrengthState() <= 0) {
                pingOk = true;
            }

            if (pingOk) {
                Network.lastPing = new Date();
                Ping.init(Network.connectionTestUrl, Network.connectionTestSuccessful, Network.connectionTestFailed);
            }
        },

        connectionTestSuccessful: function () {
            var isConnected = true;
            Network.setConnectedState(isConnected);
        },

        connectionTestFailed: function () {
            var isConnected = false;
            Network.setConnectedState(isConnected);
            Network.lastPing = null;
        },

        setConnectedState: function (connectedState) {
            if (Network.isConnected != connectedState && Network.connectionStateChanged != null) {
                Network.connectionStateChanged(connectedState);
            }

            Network.isConnected = connectedState;
        }
    };
} ();

Some minor changes to main.htm and main.js in order to display the connected state. Add a div, isConnected, to main.htm, and add a call to Network.init and a callback function to main.js.

-----------------
Main.htm
-----------------

<div id="isConnected">N/A</div>

-----------------
main.js
-----------------

function onLoad() {
    // Omitting code from previous post
    Network.init(connectionStateChanged);
}

function connectionStateChanged(isConnected) {
    var connected = $get("isConnected");
    if (isConnected == true) {
        connected.innerHTML = "Connected!";
    }
    else {
        connected.innerHTML = "Not connected!";
    }
}

After deploying this widget, you should see that the connected status is displayed below the rest of your content. Of course, you may want to use a nicer icon/image to represent the connected state.

Windows Mobile Widget 101 - Menus

nick — Thu, 14 Jan 2010 21:43:13 GMT

Prior posts in this series:

One of the reasons that widgets are an interesting alternative to mobile web sites is their ability to integrate into the Windows Mobile shell similar to native or managed applications. Menus are one of these integration points. When designing your widget you should consider using the menus in additional to placing links within the content on your html page. Menus are a great way of controlling navigation within your application as they are always at the bottom of the screen, regardless of where the user has scrolled to (like mobile websites, widgets tend to be elongated, allowing vertical scrolling but eliminating horizontal scrolling where possible).

For example, the menu may contain items such as Home, Exit, About – items that are will be there regardless of where the user is in the widget. This is not to say you can’t dynamically control what’s displayed in the menu, in fact far from it as you can easily add and remove, enable and disable menu items.

In the previous post you saw how we can display manifest information to the user. Whilst this was useful in demonstrating how to read information from the manifest, it’s not likely that we always want that information to be displayed. Lets add a menu item that will toggle the visibility of this information.

To start with, we need to encapsulate the manifest information in the main.htm file into a single div that we can hide and show. This way we only need to toggle a single div, rather than each of the manifest information divs.

-----------------
Main.htm
-----------------

<div id="about" style="display:none;">
<div id="manifestVersion" class="manifest"></div>
…
</div>

The next thing we need to do is add some helper methods to make working with widget menus that much easier. Note that this code will create menu items when running as a widget but it will also create div elements for menus when running in a standard browser, this aids debugging as you can test the navigation/event handling of your menus from within Visual Studio.

-----------------
widget.js
-----------------

        // Creates a menu with specified label and click handler
        createMenuItem: function (label, handler) {
            var mi = null;
            this.LAST_MENU_ID ++;
            if (window.widget && window.widget.menu) {
                var mi = window.widget.menu.createMenuItem(this.LAST_MENU_ID);
                if (mi) {
                    mi.text = label;
                    if (handler) {
                        mi.onSelect = handler;
                    }
                }
            }
            else if (isGadget != true) {
                mi = document.createElement("div");
                mi.innerHTML = label;
                mi.text = label;
                if (handler) {
                    mi.onclick = handler;
                }
                mi.id = "menu" + id;
            }
            return mi;
        },
        // Returns a menu item whose ID is specified
        getMenuItemById: function (id) {
            var mi = null;
            if (window.widget && window.widget.menu) {
                mi = window.widget.menu.getMenuItemById(id);
            }
            else {
                mi = $get("menu" + id);
            }

            return mi;
        },
        getMenuText: function (mi) {
            if (window.widget && window.widget.menu) {
                return mi.text;
            }
            else {
                return mi.innerHTML;
            }
        },
        // Appends the menu item to the main menu at the end. If the id of the menuitem to be added already exists in the menu, an exception will be thrown.
        appendMenuItem: function (mi) {
            if (mi && window.widget && window.widget.menu) {
                window.widget.menu.append(mi);
            }
            else {
                    var right = $get("rightSoftKey");
                    right.appendChild(mi);
                    right.parentNode.style.display = "block";
            }
        },
        // Appends the menu item to the parent menu at the end. If the id of the menuitem to be added already exists in the menu, an exception will be thrown.
        appendSubMenuItem: function (parent, mi) {
            if (parent && mi && window.widget && window.widget.menu) {
                parent.append(mi);
            }
            else {
                if (parent.childNodes.length == 1) {
                    var list = document.createElement("div");
                    list.style.margin = "10px";
                    parent.appendChild(list);
                }
                parent.childNodes[1].appendChild(mi);
            }
        },
        // Removes the menu item from the main menu. If the specified id does not correspond to an item in the menu, an exception will be thrown.
        removeMenuItem: function (mi) {
            if (mi && window.widget && window.widget.menu) {
                window.widget.menu.remove(mi);
            }
            else {
                var right = $get("rightSoftKey");
                right.removeChild(mi);
            }
        },
        // Removes the menu item from the sub main menu. If the specified id does not correspond to an item in the menu, an exception will be thrown.
        removeSubMenuItem: function (parent, mi) {
            if (parent && mi && window.widget && window.widget.menu) {
                parent.remove(mi);
            }
            else {
                parent.childNodes[1].removeChild(mi);
                if (parent.childNodes.length == 1) {
                    parent.removeChild(parent.childNodes[1]);
                }
            }
        },

        // Sets the softkey of the widget. Currently we supprt setting the left softkey and right soft key.
        // If there is an error setting the soft key, exception will be thrown. If the softkey index is invalid, exception will be thrown.
        setSoftKey: function (mi, softkeyIndex) {
            if (mi && window.widget && window.widget.menu) {
                window.widget.menu.setSoftKey(mi, softkeyIndex);
            }
        },
        // Sets the left softkey for the widget menu item
        setLeftSoftKey: function (mi) {
            if (mi && window.widget && window.widget.menu) {
                window.widget.menu.setSoftKey(mi, widget.menu.leftSoftKeyIndex);
            }
            else {
                    var left = $get("leftSoftKey");
                    left.appendChild(mi);
                    left.parentNode.style.display = "block";
            }
        },
        // Sets the right softkey for the widget menu item
        setRightSoftKey: function (mi) {
            if (mi && window.widget && window.widget.menu) {
                window.widget.menu.setSoftKey(mi, widget.menu.rightSoftKeyIndex);
            }
            else {
                var right = $get("rightSoftKey");
                right.removeChild(mi);
                right.parentNode.style.display = "block";
            }
        },
        // enable/disable a menu item
        toggleMenuItem: function (id, on) {
            var mi = this.getMenuItemById(id);
            if (mi) {
                mi.enabled = on;
            }
        }

And of course we need to add code to main.js in order to actually create the menus:

-----------------
main.js
-----------------

function onLoad() {
    // Omitted code as it is the same as previous posts
    createMenuItems();
}

// Create the menu items
function createMenuItems() {

    // create Refresh as left soft key for the main page
    createLeftSoftKey();

    // create right soft key and its sub menu items
    createRightMenuItems();
}

// create Blog link as left soft key
function createLeftSoftKey() {
    // Add the Back menu item and set it to disabled
    var mi = WidgetAPI.createMenuItem("Blog", onNavigateToBlog);
    if (mi && mi!=null) {
        mi.enabled = true;
        WidgetAPI.setLeftSoftKey(mi);
    }
}

function onNavigateToBlog() {
    window.open("http://community.softteq.com/blogs/nick");
}

// Add sub menu items to right soft key "Menu"
function createRightMenuItems() {
    // Add the Home menu item and set it to disabled
    aboutMenu = WidgetAPI.createMenuItem("About", onAbout);
    if (aboutMenu && aboutMenu != null) {
        aboutMenu.enabled = true;
        WidgetAPI.appendMenuItem(aboutMenu);
    }

}

Lastly, returning to the main.htm file we need to add two hidden divs which will be used during testing to display the menu items when the widget is run on the desktop. These divs will remain hidden when the widget is run on the device.

-----------------
Main.htm
-----------------

        
            <div style="display:none;">
                LEFT:
                <div id="leftSoftKey">
                </div>
            </div>
            <div style="display:none;">
                RIGHT:
                <div id="rightSoftKey">
                    <div onclick="window.close()" >Exit</div>
                </div>
            </div>
    </body>
</html>

Here’s the widget in action – you can see that the left menu (which used to read Exit) now reads Blog and that the right menu includes both the standard Exit item and an About item. Clicking the About item displays the hidden manifest information.

If you run this from within Visual Studio, what you will see is that the left and right menus are simulated by divs that are created at the end of the page. In the same way as the widget running on the device, clicking the About will display/hide the manifest information area.

HelloWorldWidget2.zip

Windows Mobile Widget 101 – The Manifest File

nick — Thu, 14 Jan 2010 06:11:40 GMT

Prior posts in this series:

In this post we’re going to drill a little further into the config.xml file (ie the Manifest file) that is shipped with your widget and how you can access its content from your widget javascript code. In the post Widget Anatomy – The Manifest, Jorge covers a number of points about working with the manifest file. Here I’m going to add code to our on going example which you can use to wrap the widget object, allowing you to use the same code regardless of whether your widget is running in a normal browser, as a gadget or as a widget.

Let’s start with the html page. We’re just going to add some div tags into which the values from the manifest file will be inserted.

-----------------
Main.htm
-----------------

<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <title>Hello Widget</title>
        
        <script type="text/javascript" src="js/utils.js"></script>
        <script type="text/javascript" src="js/widget.js"></script>
        <script type="text/javascript" src="js/main.js"></script>
    </head>
    <body onload="onLoad();">
        Hello Widget World!
        <hr />
        <div id="manifestVersion" class="manifest"></div>
        <div id="manifestId" class="manifest"></div>
        <div id="manifestName" class="manifest"></div>
        <div id="manifestDescription" class="manifest"></div>
        <div id="manifestAuthorEmail" class="manifest"></div>
        <div id="manifestAuthorName" class="manifest"></div>
        <div id="manifestAuthorURL" class="manifest"></div>
        <div id="manifestHeight" class="manifest"></div>
        <div id="manifestWidth" class="manifest"></div>
        <div id="manifestLocale" class="manifest"></div>
        <div id="manifestIconSource" class="manifest"></div>
    </body>
</html>

Next, let us add code to widget.js to wrap the calls to the widget API:

-----------------
widget.js
-----------------
var WidgetAPI = function () {
    return {
        // gets the widget id
        getId: function () {
            if (isGadget && isGadget == true) return System.Gadget.path;
            return window.widget ? window.widget.identifier : "http://builttoroam.com/invalidid";
        },
        getVersion: function () {
            if (isGadget && isGadget == true) return System.Gadget.version;
            return window.widget ? window.widget.version : "0";
        },
        // gets the widget name
        getName: function () {
            if (isGadget && isGadget == true) return System.Gadget.name;
            return window.widget ? window.widget.name : "Not a Widget nor a Gadget";
        },
        // gets the widget description
        getDescription: function () {
            return window.widget ? window.widget.description : "Default description....";
        },
        // gets the widget author Information
        getAuthor: function () {
            if (window.widget) {
                return { name: window.widget.authorName,
                    email: window.widget.authorEmail,
                    url: window.widget.authorURL
                };
            }
            else {
                return { name: "Nick Randolph",
                    email: "nick@builttoroam.com",
                    url: "http://community.softteq.com/blogs/nick"
                };
            }
        },
        // gets the widget height
        getHeight: function () {
            return window.widget ? window.widget.height : "n/a";
        },
        // gets the widget width
        getWidth: function () {
            return window.widget ? window.widget.width : "n/a";
        },
        // gets the widget locale
        getLocale: function () {
            return window.widget ? window.widget.locale : "unknown";
        },
        // gets the current icon information for the widget
        getIconInformation: function () {
            return window.widget ? window.widget.currentIcon : { height: 0, width: 0, src: "n/a" };
        },

        // The rest has been omitted as it is the same as in the previous post

Now to update the main.js to iterate through the div tags and set their values:

-----------------
main.js
-----------------
function onLoad() {
    // Code in this method omitted as it is the same as in the previous post
    setupAboutInformation();
}

function setupAboutInformation() {
    updateManifestDiv("manifestVersion", WidgetAPI.getVersion());
    updateManifestDiv("manifestId", WidgetAPI.getId());
    updateManifestDiv("manifestName", WidgetAPI.getName());
    updateManifestDiv("manifestDescription", WidgetAPI.getDescription());
    var author = WidgetAPI.getAuthor();
    updateManifestDiv("manifestAuthorEmail", author.email);
    updateManifestDiv("manifestAuthorName", author.name);
    updateManifestDiv("manifestAuthorURL", author.url);
    updateManifestDiv("manifestHeight", WidgetAPI.getHeight());
    updateManifestDiv("manifestWidth", WidgetAPI.getWidth());
    updateManifestDiv("manifestLocale", WidgetAPI.getLocale());
    var icon = WidgetAPI.getIconInformation();
    updateManifestDiv("manifestIconSource", icon.src);
}

function updateManifestDiv(divName, information) {
    var div = $get(divName);
    if (div != null) {
        div.innerHTML = information;
    }
}

In the updateManifestDiv method you’ll notice we are using $get. This method is not defined by default so we need to define it in utils.js (the name of this file is not important so long as you include it into your Main.htm file).

-----------------
utils.js
-----------------

// gets the element from the dom
function $get(id) {
return document.getElementById(id);
}

Lastly, don’t forget to define the .manifest class in the css files (both high and low res):

-----------------
highres.css & lowres.css
-----------------
.manifest
{
width: 100%;
}

And that’s it, now when you run it you will see information about your widget/gadget:

HelloWorldWidget.zip

New Development Certificates for Windows Mobile

nick — Thu, 14 Jan 2010 02:24:48 GMT

As indicated by Peter Foot’s post on Expired Development Certificates the certificates that ship with the Windows Mobile 6 SDK have now expired. So you either need to play around with your system clock or, you can now download (yes I know, yet another Windows Mobile development download) the new certificates from the following blog post http://windowsteamblog.com/blogs/wmdev/archive/2010/01/12/new-windows-mobile-developer-certificates.aspx