Gregg Lebovitz's Blog

I have been on the road with the Nokia / Microsoft outreach program and we have been teaching Windows Phone 7 programming to developers in Paris, Madrid, Milan, and Berlin. This has been occupying my time and so my blog has been suffering.

A couple of weeks ago I promised that I would discuss the process of moving a Qt/QML data driven application to Silverlight. As you may recall, I did a similar series of blog posts on moving a side scrolling game from Qt/QML to XNA.

The project of moving a data driven application is somewhat more complex because you have to worry about mapping pages, page flows, and page controls from QML into Silverlight. This can be challenging if your application was developed before the release of Qt Components for Symbian and you developed your own equivalent of a page stack.

In this series, I will make the assumption that you have a page stack model for navigating pages my pushing and popping pages on the page stack. If you have a more hardwired page model, then you will have to make adjustments to your code to map your method of page navigation into Silverlight.

Some of the other challenges in moving code from Qt/QML to Silverlight is the lack of Signals and Slots in C#. There is a comparable mechanism that allows you to create and connect custom events with custom event handlers that can be used in place of Signals and Slots. There are some “gotchas”  in using events, but we will discuss those later in this series.

In moving an app from QML to Silverlight I have identified six steps that can act as a “porting” process. These steps are as follows:

1. Identify the QML or Qt Pages.
2. Determine the Page states
3. Map the Page navigation model
4. Enumerate the Page Controls
5. Identify signal and slot Connections between objects
6.  Map Pages into Silverlight visual  Page Specifications (XAML)  and C# objects
7.  Find  Silverlight equivalents for APIs, controls, and connections

It is important to understand that many of the algorithms and much of the code written in JavaScript and C++ can easily map into Silverlight code behind the Visual Page Specifications.

To understand this process, you must first understand how Silverlight works. If you have used Silverlight or Windows Presentation Framework (WPF) in another context, then these concepts can be directly applied to Windows Phone 7 programming.  If you don’t know anything about Silverlight, then you are in luck because I will spend my next blog reviewing the structure of a Silverlight application. This will include an explanation of the organization or Silverlight applications, XAML, and  the concept of C# code behind.

In response to my technical posting on moving an application from QML to Windows Phone 7 XNA, I got a private message from a developer who was asking the question, "Why Should ICare About Windows Phone 7?" If I am going to switch platforms from QML, why would I choose Windows Phone 7?

For application developers, a more relevant question is, can you afford not to care? The phone is visually appealing, feature-rich, easy to use, and offers such Microsoft exclusives as Office, Xbox and the Zune music store. The tile interface is truly innovative; it focuses your attention on, and tells you at a glance, what is happening now — like pending messages, game and friend status, and appointments — all refreshed wirelessly via the web. Email sync is also very reliable.

Here’s what AllThingsD says: “The operating system is a mix of elegance and whimsy that’s a treat to use … sprinkled with delightful animations on nearly every screen. These include icons that swing out like tiny doors when selected, and little dots that race across the top of the screen when something is loading onto the phone. The result is a playful yet functional interface.”

Then there’s the development environment. The Windows Phone 7 Application Platform is built on existing Microsoft tools and technologies such as Visual Studio, Expression Blend, Silverlight, and the XNA Framework. Developers familiar with those technologies have a head start when writing new applications for Windows Phone 7.

Another great advantage is Microsoft’s position in on-line mobile gaming, the fastest growing applications market in mobile phones. Games generate more revenue than any other application genre. With their support of XNA and XBOX Live in Windows Phone 7, Microsoft is well poised to lead this lucrative market and attract customers in the highly prized 14-to-25 year old demographic. More young owners will lead to more ad revenue from both games and traditional data driven applications.

Business users can benefit from Windows Phone 7’s support of Microsoft’s .NET framework for integrated business applications. Support of .NET simplifies the task of integrating mobile phones with core business services. Much of the client side business logic can be reused in Windows Phone 7 mobile applications.

But perhaps the biggest feature is Microsoft itself. Over the years, the company has shown enormous staying power in markets in which it wants to win — like games. Windows Phone 7 may only be Microsoft’s latest foray in the mobile phone space but that’s just more evidence of Microsoft’s commitment to what most industry watchers see as the future beyond PCs.

So — given Microsoft’s huge resources, commitment to the market and a well-executed product — it’s safe to assume that Microsoft will become at least number two in the market, after Android (which, like Windows Phone 7, comes on many phones) and ahead of iOS (which only comes on one).

A Serious Land Grab

Right now, the biggest thing slowing Windows Phone 7 adoption is a relative lack of third-party apps. On the one hand, while WP7 may not have as many as Apple, Google or even the Ovi store, it does have all the mainstream apps you would expect. On the other hand, if you are an app developer yourself, that is probably the best reason to care about Windows Phone 7. Who wants to be the third or fourth developer to market with a particular kind of application? In today’s environment, numbers 1 and 2 tend to win big and quickly while everyone else gets overlooked. Given the advantages in gaming and business applications, now is the time to invest in Windows Phone 7.

Early arrivals can also expect more help from Microsoft. As it populates its catalog, Microsoft will look to fill in the gaps first and worry less about having multiple offerings for each type of app. Developers looking for help may wish to consider partnering with their own experts in porting applications across mobile platforms. What we’re seeing now with Windows Phone 7 may be the last of the great mobile “land grabs.” Anyone who’s serious about getting their share should start moving.

In a few days, I will start a series on moving a Twitter application from QML to Silverlight on Windows Phone 7. I plan to show how the transition can be straight forward.

In my last post, I discussed how to build the “Kolobok” main character in our casual game for Windows Phone 7 from the Kolobok.qml file from the Symbian phone version.  I also discussed the method my team used to animate the fire obstacle by rotating through a list of texture images at a set frame rate.

In this blog, I will finish up the application by showing how to map the QML MouseArea inputs for the navigation buttons into the input handlers for the XNA game object. Next I will discuss how to play the sounds associated with Kolobok’s movement and collision with obstacles.

Input in the QML version of the application is strictly event driven. Normally we would place button images on the screen in the game board object and over a MouseArea to catch a user mouse event using an “anchors.fill” property. This would work for individual buttons but would not detect two buttons pressed at the same time. For this we need a MouseArea that would handle Multi-touch events.

QML does not have a predefined element for multi-touch, however the C QDeclarativeItem provides multi-touch input events. Therefore we chose to implement a QDeclarativeItem multi-touch object in C and bind it to QML as a new element. To simplify the implementation we combined the image and multi-touch elements into one element called MultiTouchItem that has an image source property and delivers user events as pressed() and released() signals. These signals are directly connected to the Kolobok characters key handling methods.

In Windows Phone 7 we will use the event handling methods and implement the multi-touch events as synchronous tests in the game object’s Update method. Multi-touch inputs will be passed onto the Kolobok character game piece’s KeyPressed and KeyReleased methods.

For each game action button in the QML game, we create a MultiTouchItem object that overrides the QDeclarativeItem::sceneEvent method and catches the QEvent::TouchBegin and QEvent::TouchEnd events.  The object also catches the Mouse Press and Mouse Release events in case a non-touch screen input device is used. The screenEvent method is shown below:

bool MultiTouchItem::sceneEvent(QEvent *event)

{

    switch (event->type()) {

    case QEvent::TouchBegin:

        emit pressed();

        break;

    case QEvent::TouchUpdate:

        break;

    case QEvent::TouchEnd:

        emit released();

        break;

    case QEvent::GraphicsSceneMousePress:

        emit pressed();

        break;

    case QEvent::GraphicsSceneMouseRelease:

        emit released();

        break;

    default:

        return QDeclarativeItem::sceneEvent(event);

    }

    return true;

}

The events emit the appropriate released() or pressed() signals that are communicated to the Kolobok Element .

In the XNA Game object Update() method, we call the buttonEvent() method that will poll for multi-touch input and then call the input methods in the Kolobok.cs file. Multi-touch input is collected in a TouchCollection container object that can be read using the touch panels GetState() method. The buttonEvent method is shown below:

void buttonEvent()

        {

            // Windows phone controls

            TouchCollection state = TouchPanel.GetState();

            foreach(TouchLocation tl in state)

            {

                // Handle key pressed

                if (tl.State == TouchLocationState.Pressed)

                {

                    if (positonInArea(tl.Position, closeBtnArea))

                        this.Exit();

                    else if (positonInArea(tl.Position, leftBtnArea))

                        gameBoard.keyPressed(GameBoard.Key.Left);

                    else if (positonInArea(tl.Position, rightBtnArea))

                        gameBoard.keyPressed(GameBoard.Key.Right);

                    else if (positonInArea(tl.Position, upBtnArea))

                        gameBoard.keyPressed(GameBoard.Key.Up);

                }

                // Handle key released

                else if (tl.State == TouchLocationState.Released)

                {

                    if (positonInArea(tl.Position, leftBtnArea))

                        gameBoard.keyReleased(GameBoard.Key.Left);

                    else if (positonInArea(tl.Position, rightBtnArea))

                        gameBoard.keyReleased(GameBoard.Key.Right);

                    else if (positonInArea(tl.Position, upBtnArea))

                        gameBoard.keyReleased(GameBoard.Key.Up);

                }

                else if (tl.State == TouchLocationState.Moved)

                {

                    TouchLocation previous;

                    if (!tl.TryGetPreviousLocation(out previous))

                        return;

                    if (positonInArea(previous.Position, leftBtnArea) &&

                        !positonInArea(tl.Position, leftBtnArea))

                        gameBoard.keyReleased(GameBoard.Key.Left);

                    else if (positonInArea(previous.Position, rightBtnArea) &&

                        !positonInArea(tl.Position, rightBtnArea))

                        gameBoard.keyReleased(GameBoard.Key.Right);

                    else if (positonInArea(previous.Position, upBtnArea) &&

                        !positonInArea(tl.Position, upBtnArea))

                        gameBoard.keyReleased(GameBoard.Key.Up);

                }

            }

        }

In both the QML and XNA versions of the game, we pass inputs from the touch device into the Kolobok object’s input methods, and then call its doMovement() method to update the Kolobok’s position on the screen and respond to any collisions with other game pieces.

Once we handle input and process game action, the only thing left to do is play the game sounds and music for each game action.

In the QML game, we create a SoundPlayer object that contains QAudioPlayer objects from the multimedia APIs in Qt Mobility. The SoundPlayer contains audio files that play the various sounds depending on the type of game action. The two main sounds are “Groan” and “Boing” generated when the Kolobok experiences health decreasing events or collisions with another game piece.

Sound player APIs are usually very similar and easy to use. We create the object, set the format, load the sound file, and when we are ready, call the play or start method.  For QML we create a QAudioPlayer and a QMediaFormat object. We then set the Format object’s media attributes, bind it to the Player object, and then call play. The code looks something like this:

QAudioFormat m_format;

m_format.setSampleRate(22050);

m_format.setChannelCount(1);

m_format.setSampleSize(16);

m_format.setCodec("audio/pcm");

m_format.setByteOrder(QAudioFormat::LittleEndian);

m_format.setSampleType(QAudioFormat::SignedInt);

m_boingOutput = new QAudioOutput(m_format,this);

m_boingtFile.setFileName(":/sounds/boink.raw");

if (m_boingOutput)

    if (collided) {

        if(m_boingPlaying) return;

        m_boingOutput->start(&m_boingtFile);

        m_boingPlaying = true;

         }

For XNA we use a SoundEffect object to accomplish the same thing. The following code provides support for the Boing sound above:

SoundEffect boingSound = content.Load<SoundEffect>("sound/boink");

if (boingSound != null)

   if (collided) boingSound.Play();

Note that the SoundEffect object doesn’t require us to set the format of the file. The reader figures this out from the content .Load method. Once we know how to generate the sounds, we can trigger them from the collision detection code discussed in the previous blog.

This posting completes my blog series on reengineering a QML casual game to XNA. Next week I will begin the steps necessary to port a simple twitter application to Silverlight.

In my previous post, I developed the Kolobok game board for Windows Phone 7 from the QML Bounce game posted on the projects.developer.nokia.com site. In this blog posting, I will discuss how my team developed the main Kolobok character along with the Cacti, Fire, and Brick Wall obstacles. In my next posting, I will discuss the input buttons and methods and how the game components are integrated into the final game.

The Kolobok character is the central component of the game. Upon input from the user, the Kolobok will roll across the current tier or bounce upward to a new tier. If the Kolobok encounters an obstacle, such as a brick wall or cactus, the Kolobok will bounce backwards to a previous position.  Fire will impede the characters progress while reducing its health.

As we discussed in the previous posting, the Kolobok character is defined in the class Kolobok in the file Kolobok.cs.  The class Kolobok is derived from the GraphicItem class that holds important common properties such as object width, height, position, texture, rotation angle, and opacity. All game pieces, including characters and obstacles, are derived from this GraphicItem class. The GraphicItem class also supports rudimentary animations for the moment of the Kolobok or the flicker of the flame obstacle.

The original QML file kolobok.qml is an Ellipse Element that contains the “Kolobok’s” properties and its Image, a non visible Timer element, Key handlers, and javascript methods that respond to user events, moves the Kolobok character, detects collisions, and updates the game statistics based on the collisions with obstacles.

import QtQuick 1.0

import Shapes 1.0 

Ellipse {

    id: kolobok

    // properties
    …

    Image {

        id: kolobok_image

        objectName: "kolobok_image"

        x: 0; y: 0

        width: 100; height: 100

        source: ":/images/face-smile.png"

        smooth: true

        opacity: 1.0

    }

    Timer {

        id: timer

        interval: 25; running: false; repeat: true

        onTriggered: doMovement()
    }

       Keys.onPressed: { 

        if (event.isAutoRepeat)

            return;

        keyPressed(event.key);

    }

    Keys.onReleased: {

        if (event.isAutoRepeat)

            return;

        keyReleased(event.key);

        }

        // methods
        …
}

QML does not have an Ellipse Item defined, so we have defined an EllipseItem class that draws an Ellipse in the C file level.cpp and registered this class in the “Shapes” library as an Item named Ellipse.

The KeyPressed and KeyReleased methods referenced above will respond to use input events. If the input is one of the arrow keys, then the doMovement() method is called, which will move the Kolobok character accordingly.

Collision detection in the QML application is handled by the Qt Graphics View built-in collision detection mechanism. The doMovement() method in kolobok.qml will call into a method in the level.cpp file that will extract the list of items that collide with the Kolobok and then update the state of the Kolobok accordingly.

The newly created Kolobok.cs file will also contain the Ellipse, the Kolobok’s properties and its image, key handlers, and support methods. The timer is an integral part of the main event loop in XNA and so it is not explicitly defined in C#. Because graphics objects are not implicitly self drawn or updated in XNA, we will need to implement the Kolobok’s Initialize, Draw, and Update methods. The remaining support methods are based on the original Javascript code, but rewritten in C# using the XNA libraries.

The Initialize method is very simple and merely initializes the Kolobok’s properties to their starting values. The Update method will call doMovement() which will check the user input for an arrow key press and will move the Kolobok character accordingly. The update() and Draw() methods are shown here:

        public override void Update(GameTime gameTime)

        {

            base.Update(gameTime);

            // TODO: Add your update logic here

            doMovement();

            if (health <= 0)

                health = 100;

        }

        public override void Draw(SpriteBatch spriteBatch)

        {

            // Set up the color

            Color color = new Color(opacity, opacity, opacity, opacity);

            // Set up the origin point

            Vector2 origin = new Vector2();

            origin.X = Texture.Width / 2;

            origin.Y = Texture.Height / 2;

            // Set up the render rectangle

            Rectangle rect = new Rectangle(Rect.X + Rect.Width / 2,

                                           Rect.Y + Rect.Height / 2,

                                           Rect.Width, Rect.Height);

            spriteBatch.Draw(Texture, rect, null, color, RotationAngle, origin,

                              SpriteEffects.None, 0f);

            // Draw the health

            spriteBatch.DrawString(healthFont, "Health:" + health,

                                    new Vector2(20, 20), Color.White);

        }  

Key input is handled through the KeyPressed() in KeyReleased() called by the input handler in the game object’s update method. The remainder of the method, called collisionDetection(), uses the XNA collision detection library to determine if the Kolobok character is colliding with an obstacle and then updates the Kolobok state.

The doMovement(), keyPressed() and keyReleased(), and updateCollisions() methods from kolobok.qmls javascript code are simply re-implemented in C#.

In QML, the code to read the game layout database and present it to the game board is written in C in the file level.cpp. The method load() in the C file uses the Qt QXmlStreamReader to parse an XML database file and for each vertical level on the game board stores a string containing a character for each obstacle. The vertical level strings are stored in QVector container called “map”. These level strings are used to build the game board as described in the previous blog. The load method is shown below:

bool Level::load()

{

    m_rowCount = m_columnCount = 0;

    m_map.clear();

    QFile file(":/level/level.xml");

    if (!file.open(QFile::ReadOnly | QFile::Text)) {

        qDebug() << Q_FUNC_INFO << file.errorString();

        return false;

    }

    QXmlStreamReader xml(&file);

    if (xml.readNextStartElement()) {

        if (xml.name() == "level") {

            while (xml.readNextStartElement()) {

                if (xml.name() == "layer") {

                    const QString text = xml.readElementText();

                    m_map.append(text);

                    m_rowCount;

                    m_columnCount = qMax(m_columnCount, text.count());

                }

            }

        }

    }

In the Windows Phone version of the game, level.cs contains a very similar load function. Here we use the XmlReader class to read the XML data file and a List container class to store the level strings. Note the similarities between the two methods:

public static bool load(string filePath)

        {

            // Clear the level's old data.

            mRowCount = 0;

            mColumnCount = 0;

            mMap.Clear();

            // Open the level xml file

            XmlReader reader = XmlReader.Create(filePath);

            while (reader.Read())

            {

                if (reader.Name == "layer")

                {

                    string text = reader.ReadInnerXml();

                    mMap.Add(text);

                    mRowCount ;

                    mColumnCount = Math.Max(mColumnCount, text.Count<char>());

                }

            }

            return true;

        }

Now that we implemented the Kolobok character and the movement logic behind the game, the only remaining parts are to process input from the user and play background music and sounds. In my next blog, I will pull the rest of the application together and show how I completed the port.

In my last blog post I described two environments for developing Windows Phone 7 applications:  XNA for games and graphical applications, and Silverlight for more traditional touch-based, data oriented applications.

In this blog I will demonstrate the beginnings of re-engineering a QML causal game application for the Windows Phone 7 XNA framework. This blog will concentrate on the setup of the game board and definition of each game component.

The demonstration application is a game called QML bounce. It is an animated interactive version of the Russian fable “Kolobok,” which is about a ball of dough that grandma is preparing for baking bread that comes to life and leads grandma and grandpa in a game of cat and mouse across the countryside. In our game, the “Kolobok” will move or bounce around the game board and avoid obstacles that can block its way or diminish its health. To make the game fit on a small screen, “Kolobok” is allowed to bounce vertically in addition to moving across the screen. The vertical direction is divided into 4 or 5 levels with each containing obstacles such as walls, cacti, or fire. To make the game visually appealing, the fire is animated to give it a burning effect. The source for the game can be found at https://projects.developer.nokia.com/qmlbounce.

The image below shows the QML Bounce game board:

The QML version of the game is broken into several files. Each one of these represents a game component. The main QML files are:

• gameboard.qml - the game board and all of the static game board components such as rocks and cacti
• Fire.qml – the animated fire obstacle
• Kolobok.qml – the animated “Kolobok” character that interacts with the user
• Menu.qml – the on-screen menu for performing in app purchases
 

The QML Bounce game also requires three C++ support files for reading the game board obstacles from a “game level” database and providing the level’s obstacles to the QML game board. These files include: 

• level.cpp - the current game board’s level, containing obstacle locations, and methods for detecting collisions between the  obstacles and the “Kolobok”
• levelmodel.cpp – the object and methods for accessing the game level database
• levelcontroller.cpp - which provides the means for purchasing new game board levels from the OVI store.
 

To re-engineer the QML Game to the Windows Phone, we must re-engineer each of these files. We will begin the process by moving the functionality of each QML file into a corresponding XNA C# file. Next we will add the objects and methods to implement the game level, game level model, and the ability to purchase new game levels within the application. Finally, we will implement the game board update and draw methods to handle the rendering of the game board and user input.

The next few blogs will concentrate on re-implementing the QML files in C# XNA.

One of the more noticeable differences between QML and XNA is that QML visual elements are self displaying, whereas XNA objects must be drawn by the XNA game object. To re-engineer the game for Windows Phone 7, we start by creating an XNA game project in visual studio that will generate a file game-1.cs which includes an XNA graphics component, derived from the class Microsoft.Xna.Framework.Game. This class contains a “GraphicsDeviceManager” and “SpriteBatch”. The GraphicsDeviceManager will be managed by XNA itself. The spriteBatch will provide a context to the drawing method for rendering the game graphics onto the screen. We will modify this file to create all of the top level components including the game board, pieces, controls, and menus.

The XNA game file includes three main virtual methods that must be implemented for the game to operate. These are the Initialize, Update, and Draw methods. The initialize method is called after the game object is constructed and allows the game to perform any initialization it requires before starting to run. The Update method will be called whenever we need to update the state of the game and collect input from the user. For our game, the Update method will be called at the game frame rate of 60 times per second. After each update, XNA will call the Draw method to update the game graphics. Usually Draw will be called at the frame rate, unless an update occurs before Draw is called. This might happen if an Update takes too long and extends beyond the period of the frame rate.

We will handle input and call methods to update the game board in the Update method. We will call methods to re-draw the game board from the Draw method. The game board, in turn, will update and draw all the lower level game components.

In my next blog I will demonstrate how to re-engineer the QML game board in gameboard.qml and the Kolobok character in kolobok.qml to  corresponding XNA / C# files for Windows Phone 7. The following blog will show how I animate the fire obstacle and process input.

A couple of months ago I wrote that I was learning to program in Silverlight on the Windows Phone 7 platform and share my experience with porting applications from QML to Silverlight. Since then my team and I have ported two demonstration applications from QML on Symbian to Silverlight.  As promised, I am going to share my experience to encourage others to do the same.

During the past few weeks my team ported two applications from QML to the Windows Phone. The first is a simple side scrolling casual game and the second a simple Twitter application. While both applications are complete, we are still working on the notification piece of the Twitter app that will update the home screen tile with the count of unread tweets.

The casual game application, called QmlBounce, was originally written in QML and is available from the URL https://projects.developer.nokia.com/qmlbounce. We implemented the game using the Windows Phone 7 XNA framework. If you are not familiar with XNA, it is a C# set of classes and libraries that simplifies the creation, transformation, and animation of graphical items rendered as Sprites. The programming model for game components is very similar to Graphics View in that both provide lightweight objects that draw themselves. Graphics View items are painted in the paint method, while XNA game components draw themselves in their Draw method.

To simplify the porting process, we created a new C# class called GraphicsItem that implements many of the properties and methods of the Qt QGraphicsItem. We then could use this class to easily implement each of the graphics objects created in QML.

The Twitter application port was straightforward. Our graphics team implemented the window, pages and dialogs using the Windows Phone Visual studio designer. We chose to use a Pivot element , because it closely mirrored the multi-page look and feel we implemented in QML. The original QML implementation was hard because we needed to implement each of the controls along with the page and page stack ourselves. The release of the Qt Quick Components simplifies this effort as it provides these higher level Elements as base components.

In my next blog, I will provide a step by step description of how we implemented the Casual Game. I will start with overall game design and then work my way though the individual objects, properties, and methods.

At MIX Microsoft is giving us the scoop on the next version of Windows Phone 7, code named Mango. It really is adding some of the important features that were missing from the current release. Mango is adding support for Silverlight 4, TCP Sockets, XNA integration, and access to the Camera APIs.

Silverlight 4

Windows Phone 7 is current running Silverlight 3, while Microsoft is already announcing the beta for Silverlight 5. This makes it difficult to move applications between the desktop and the phone. Mango will support Silverlight 4 include implicit Styles, RichTextBox, along with all its added support for TCP Sockets, and XNA integration.

TCP Sockets

 Missing from the current version of Windows Phone 7 is access to the low level TCP socket APIs. While this is not critical for Web integrated applications, it does make it hard to provide real time services such as Skype. Mango will provide full access to these APIs, so expect to see support for real time VoIP and media applications.

XNA Integration

Currently, applications on Windows Phone 7 can support either XNA or Silverlight. This means that it is not possible to mix 3D modeling into your Silverlight based application. Mango will provide programmers with access to the XNA APIs from Silverlight allowing applications to support both 2D based controls and 3D based models.

Camera APIs

The only way to access the camera in the current version of Windows Phone 7 is to launch the camera application and let the user manually capture an image. This is not useful for capturing QR and Bar Codes, and video capture for Video conferencing.  Mango will provide access to the camera APIs allow the application to use the camera as an in application capture device. This will enable the important video conferencing features require by applications such as Skype.

There are many more new features in Windows Phone, but the addition of these features will bring Windows Phone 7 to parity with the capabilities currently available and expected in the current Symbian phones.

This is really good news to application developers.

With Nokia's new strategy in full force, I decided to buy a Windows Phone and attend the MIX conference in Las Vegas. This is a great meeting place for Nokia and Microsoft developers to come together and learn about the developer tools.

Programming the Window's phone is not a big leap from using Qt and QML. The programming model for Windows phone uses a Declarative XML Language called XAML that uses tags and attributes in the way the QML defines elements and properties. XAML is part of Silverlight and is available on both the phone and desktop. XAML also includes the idea of binding between tags and binding C# classes to XAML tags. XAML includes all of the concepts of QML including models, positioners, views, and delegates, but with different names. For instance, a QML delegate maps into a XAML templated item. Models and views are implemented in XAML and C# using the Silverlight MVVM (model - vew - viewmodel) framework. This is roughly equivalent of using delegate components with different views.

The tools for Windows phone developers include Visual Studio and Expression Blender. Many Qt developers have been using Visual Studio for Qt development so many of us understand the power and flexibility of this tool. Expression Blender is similar to QML Designer and provides the tools to style, manage, and animate declarative elements specified with XAML tags.

The main differences between QML and XAML is that QML includes javascript as an expression language, whereas XAML interfaces with C# to implement expressions. This means that there is usually a one to one mapping between a C# class and a element declared as a tag in XAML.

I plan to provide more indepth information on Windows Phone development in this blog. In particular, I want to focus on developing Apps for both QML and Windows Phone. This will help developers maximize their coverage on both Nokia Symbian and Windows Phones.

A good place to get started with Windows Phone development is the App Hub Getting Started Page .

I built several simple examples that used Qt 4.7 features and ran on my N8 phone. What was more interesting to me was downloading some QML programs to the phone and running them using the qmlviewer included in the zip file above that contains the device libraries. 

Here are the steps I used to get Qt 4.7.0 on Symbian working with the abbreviated SDK that comes with the Nokia Qt SDK version 1.0.1:

1) Download the Qt 4.7.0 for Symbian 3 SDK and device libraries from the Qt and Forum Nokia Sites:

Qt 4.7 Open Source for Symbian S60

Symbian Qt 4.7 SIS files 

2) Download and install the NokiaQtSDK version 1.0.1 from the forum nokia site:

Nokia Qt SDK Version 1.0.1

3) Once it is installed copy the directories c:\nokiaqtsdk\symbian\SDK\epoc32 and c:\nokiaqtsdk\symbian\SDK\perl to another SDK directory. I installed mine in c:\Qt\4.7.0\Symbian\SDK.

4) run the qt-symbian-opensource-4.7.0-s60.exe installer and select the option to install into other sdks. You will be given a list of empty install locations. Enter your SDK directory into the first one. This will overwrite Qt in that SDK\epoc32 directory (e.g. enter c:\Qt\4.7.0\Symbian\SDK) and install Qt into C:\Qt\4.7.0.

5) run creator and under the tools menu, select options and navigate to the qt tab on the left. Add a new version of Qt to creator. The qmake file will be in c:\Qt\4.7.0\bin\qmake.exe.

6) Fill in the remaining fields (leave the carbide field blank). The SDK field should be c:\Qt\4.7.0\Symbian\SDK and the CSM/gcce field should be c:\nokiaqtsdk\symbian\SDK\gcce (there is no reason to copy the gcce directory.)

7) unzip the Qt_4_7_for_Symbian_3_Developer_Version_v1_0_en.zip file. Inside are two more zip files. Unzip the Qt 4.7 for symbian^3.zip file and install all the sis files to your phone. If you have OVI suite installed, you can do this by double clicking on each sis file and then following the install directions.

Now you have a complete setup. If you installed the qmlviewer.sis you can download QML applications to your phone and run them. To download the qml files, exit from OVI suite and use your phone as a mass storage device. 

Throughout the fall I will be teaching a series of workshops on Qt for Symbian using the N8 around the U.S. and Canada. We have already held two well attended classes in Boston and Toronto. More information about the workshops can be found below If you live and/or work in North America, I hope to see you at one of the remaining workshops.

Forum Nokia and Integrated Computer Solutions (ICS), a Qt certified training and consulting partner, are providing an intensive two day hands-on, classroom style coding workshop that will train developers how to use Qt to develop mobile applications for the new Nokia N8. Attendees will learn how to create mobile applications with Qt by using an actual N8. Workshops are currentlyscheduled for Boston, Toronto, NYC, Austin, San Francisco, Seattle, and Vancouver with more cities being added soon.

 The workshop schedule: 

More info can be found at http://www.ics.com/learning/qtforn8

 Additional Qt training can be found at the ICSNetwork Site at http://www.ics.com/learning/icsnetwork