Paul Todd's Forum Nokia Blog

Microsoft Airsync protocol now released

Fri, 19 Dec 2008 13:48:34 +0200

As part of Microsofts ongoing API release program, the AirSync protocol specs and docs are now avaliaible for download

Grab them here

http://msdn.microsoft.com/en-us/library/cc425499.aspx

And of course the obligatory licencing notice here

http://msdn.microsoft.com/en-us/library/cc433488.aspx

Note that there is no partnering API or support incident cost involved in getting or using them....

Mobile Firefox for Symbian just kicked off today

Thu, 11 Dec 2008 17:47:35 +0200

Mozilla have today officailly kicked off their port for Fennec (ie Firefox Mobile) for Symbian

More info over at Christian Sejersen's blog including links to the repository....

http://www.christiansejersen.com/blog/2008/12/10/fennec-mobile-firefox-for-symbian/

Various people have already started contributing.

Reading DM Adapter DDF's

Sun, 30 Nov 2008 18:21:24 +0200

DDF's can be represented as a tree structure and so naturally lead themselves to be described by recursion which most people find difficult to understand. Reading a ddf from the supplied adapter is fairly easy, the problems are the recursive nature of the solution that describes the ddf.

The two important methods on CSmlDmAdapter are DDFStructureL and the other one is DDFVersionL. The DDFStructureL function takes as an arguement, an implementation for an MSmlDmDDFObject. This will be the root node for the DDF and typically this will be the name of the DDF e.g. AP for access points)

As the adapter builds the DDF, it will call back on the methods of MSmlDmDDFObject to set the
various parameters that describe the node. You will need to derive a class from this and
CBase and provide implementations to all the methods of the MSmlDmDDFObject.
It is up to you to track the relationships between the nodes, so each time AddChildObjectL
or AddChildObjectGroupL is called, it will require a new instance of the object implementing
the MSmlDmDDFObject interface to be created. This new node will be added as a child of the
current node. If the DDF tree is being stored then it will be up to you to keep track of
the objects you create.

In order to construct the tree, AddChildObjectL is used to add a named node and
AddChildObjectGroupL is used to add an anonymous or ununamed node (these are denoted as
<x> is in the ddf specification). Both of these functions return a new instance of an
object implementing the MSmlDmDDFObject.

One of the tricky aspects to this is that some of the adapters put their name in the ecom data and others do not, so generally you need to read the DDF for the adapter in order to get the name of the adapter if you are using it to set specific settings.

A partial example to read the ddf..
For the purposes of this example, we will assume that we already have an adapter
instantiated via RECOMSession::CreateImplementationL

//This class is used to store the ddf
class CDmDDFNode : public CBase, public MSmlDmDDFObject
    {
public:
    CDMDDFNode();
    ~CDMDDFNode()
        {
        iChildren.ResetAndDestroy();
        }

public: // MSmlDmDDFObject
    .... // Implementations of the pure virtual
         // get and set methods of MSmlDmDDFObject
    MSmlDmDDFObject& AddChildObjectGroupL()
        {
        return AddChildObjectL(_L8("<x>"));
        }

    MSmDmDDFObject& AddChildObjectL(const TDesC8& aNodeName)
        {
        CDmDDFNode* node = new (ELeave) CDmDDFNode;
        CleanupStack::PushL(node);
        iChildren.AppendL(node);
        CleanupStack::Pop(node);
        return *node;
        }

private:
    RPointerArray<CDMDDFNode> iChildren;
    };

When calling DDFStructure...

CDMDDFNode* root = new (ELeave) CDMDDFNode;
CleanupStack::PushL(root);
adapter->DDFStructureL(*root);
CleanupStack::Pop(root);

const TDesC8& name= node->Name(); // the root node is the adapter name.
....

Once the DDF has been read, it is then possible to get the version of the DDF.
The DDF version is important as it allows differentiation of features as well as identifying
possible issues with bugs fixed from earlier releases.

CBufFlat* buf = CBufFlat::NewL(64);
CleanupStack::PushL(buf);
adapter->DDFVersionL(*buf);
HBufC8* DDFVersion = buf->Ptr(0).AllocL();
// .... create store this somewhere
CleanupStack::PopAndDestroy(2, buf);

Next Part...
Setting simple single values...

Scalability

Wed, 22 Aug 2007 23:47:48 +0300

One of the things engineers are going to have to think about when the new widgets api's come out is not just to think about the device, but rather to think about the server side. I mean how great is your widget going to be if your server is being hosed by millions of clients.

The biggest problem I believe is going to be dealing with scalability issues on the server side as there are plenty more phones than laptops and with wifi being cheap and data plans becoming cheaper there could be a whole load of problems dealing with orders of magnitude more connections than a regular windows based clients.

That why one of my favourite feeds is the high scalability website where they cover how the really big sites on the web work and scale.
Recently they have covered the architectures for flickr, youtube, digg and typepad.

Google Developer Day

Wed, 06 Jun 2007 14:22:18 +0300

Between moving house, two projects in crisis, no broadband and google dev day I hav'nt had the chance to do any decent coding for the blog.

I was however really impressed with what google gears potentional was on a mobile device, especially for Enterprise applications.

It makes development much simpler as the code can be written in Javascript and the code takes care of syncing it with the backend services.

Currently C++/Symbian Signed is just too expensive for Enterprise applications and whilst Red Five's .net version is awsome, its not 3rd edition compliant yet.

Hopefully Nokia will add the needed extensions to the webkit to allow native javascript addons via ecom.

Google refused to be drawn on this issue when the question was asked :(