Paul Todd's Forum Nokia Blog

Why can I not use custom soft keys in global notes?

2009-08-10T12:37:23+03:00

This question often pops up on the boards and has to do with the way global notes are implemented.A global note is implemented as a notifier and as such the server for the notifier exists in a seperate process so resource files that are loaded in the client side of the notifier will not get transferred to the notifier server process and so only avkon resources (in avkon.rsc/avkon.rsg) are guaranteed to be supported in the server process* and hence the only CBA buttons that can be used are those in avkon.

Of course it is entirely possible to add a new cba structure to the data that is marshalled between the client structure and the server but this is not currently implemented and probably will never be due to issues around localization and the fact the global notes should strongly be discouraged as they block access to the device until the note is dismissed.

(*this is sort of correct, its implemented slightly differently underneath)

Using TSecurityInfo

2009-07-29T16:02:07+03:00

Ok its been a long time since I blogged since I have been overworked getting a couple of apps ready for OVI.

However there is some info on a useful little but well hidden class:

There are two basic ways of getting the process info at runtime, rather than compile time

The main method is to use the less than well known TSecurityInfo

This T class will get the capabilties, VID and SID of the current process, current message or current thread. bviously all these need to be within the scope of the current process rather than system wide if platsec is enabled.

There are some useful methods as well:

TSecurityInfo::SetToCreatorInfo()
which will set all the data to the process that created this process.
TSecurityInfo::SetToCurrentInfo()
which will set all the data to the this process's info.

There are other ways to get the creator info by using the "Creator*" methods in the User library but doing it via TSecurityInfo is a lot simpler to understand.

The process info can also be retrieved if the name, path and drive of the executable is known which is quite difficult without the "all files" capability.

RLibrary::TInfo info;
TPckg<RLibrary::TInfo> pkg(info);
User::LeaveIfError(RLibrary::GetInfo(_L("c:\\sys\\bin\\PhoNetInfo.exe"), pkg));

The creator info is quite useful as it allows the application to stop being launched by "unapproved" applications since the SID of the creating process can be checked to see if is a known one that is allowed or to ensure a creating process has the correct capabilty(ies).

Mercurial book preview

2009-04-18T11:26:08+03:00

Since the Symbian Foundation is committed to using Mercurial as its SCM (DVCS) I have been looking around for tools and training notes to get up to speed since my tools involve Subversion + Tortoise (personal) and Perforce (work).

The best reference I have found so far has been this

(http://blog.medallia.com/2007/02/a_guided_tour_of_mercurial.html)

But today O'Reilly announced they are also bringing out a new book for Mercurial and there are review drafts avaliable at this link

http://hgbook.red-bean.com/

S60 running on the Intel Atom

2009-04-16T18:51:06+03:00

The guys over at the Symbian blog are showing off S60 running on an Intel Atom moetherboard, showing its possible to integrate S60 onto other chips aside from ARM.

http://blog.symbian.org/2009/04/16/symbian-on-intels-atom/

Roll on the foundation when we can do this ourselves!

Mercurial SCM

2009-03-04T10:21:54+02:00

Since it was recently announced the Symbian Foundation will be using Mercurial as their SCM.

(Instead of GIT :( ) I though I would post up a crib sheet on using mercurial to get a head start on using it.

Follow the link...

HTML Control

2009-02-25T15:28:52+02:00

Gzytom has posted up a new Symbian control for lightweight parsing and rendering of html compatible with 2nd edition up to the latest 5th edtion.

This looks to be ideal for seperating the UI and the logic layers, the hardest part of good design and should make it easier to build apps.

There are plenty of screenshots and examples provided which looks quite powerful and the source is included.

Since the source is included it should make some of the webkit issues such as getting notifications of link clicks easier and since it is not a dll, but integrated as a lib into your application it makes it easier to ship and sign.

Anyway, grab it from here and remember to acknowledge the developer in any shipping code....

http://code.google.com/p/htmlcontrol-for-symbian/

Paul

DevcertList update

2009-01-06T13:54:13+02:00

DevcertList has been updated to version 1.2

I have seen a number of people getting "Constrained by certificate" errors and say they are absolutly sure they transcribed the IMEI correctly. To fix this I have updated DevCertList to check for IMEI's that are invalid and also IMEI's that have the wrong length.

The 3GPP specification outlines the checksum digit calculation to make sure the IMEI is valid.

This was a result of this thread over at the Symbian board..

http://developer.symbian.com/forum/thread.jspa?messageID=84670&tstart=0

Get it here:

http://wiki.forum.nokia.com/index.php/Listing_IMEIs_and_Capabilities_in_a_DevCert

Reading and writing DM adapter settings

2008-12-29T18:37:36+02:00

This continues the posts on DM adapters but I have had to break it into 3 parts as its very long because some areas are rather complicated...

The DM adapter framework functions by grouping together a number of requests and then executing them when CompleteOutstandingCmdsL is called synchronously.
This allows the adapter's underlying implementation to batch process a set of commands and deliver them to a slower client as well as allowing transactioning.

To read a setting that is not a group, its a simple matter to call FetchLeafObjectL with the relevant URI and mime type and the adapter will return the value back when CompleteOutstandingCmdsL is called.When an adapter method is called, two ids are also sent with the request. This allows the data that is returned to be identified to particular transaction and the second allows the actual status of the transaction to be identified. In practise these are normally made the same.

Calling FetchLeafObjectL and CompleteOutstandingCmdsL will result in two call backs being generated for the class implementing MSmlDmAdapter that was supplied
to the adapter instance when it was created. The first callback will be the status of the call. This will be via the SetStatusL method that was implemented in callback handler. This will return the error code (if any) for that particular transaction.

The second callback will be the actual data for the call. This will be the data and the mime type of the data. Since the data being returned is in the form of a binary blob he actual type of the blob is also required so that it can be decoded by the caller into a suitable format for redelivery to the application or forwarding onto another caller.

To write a setting that is not a group, its a simple matter to call UpdateLeafObjectL with the relevant URI, mimetype and the update will occur when CompleteOutstandingCmdsL is called. (I am going to defer the discusion of GUID and LUID values for the next post)

Reading a group is slightly more complicated by the fact that the resultant data needs to be parsed. If the endpoint of the URI is a group then calling ChildURIListL will return a string in the form of child fragment1/childfragment2/childfragment3 which needs to be split using the '/' character into its individual components of the child URI. Of course there are additional commands to do the other node operations such as DeleteObjectL, AddNodeObjectL, ExecuteCommandL and CopyCommandL all of which do what they say. It is worth noting however that DeleteObjectL will delete all children as well as well as the node in the tree.

Inside the DM adapter there are additional transaction commands, StartAtomic, CommitAtomic, RollbackAtomic. These commands function in conjunction with the CompleteOutstandingCmdsL method and work in a similar manner to database transactions. If the adapter is not inside a transaction, then each of the operations in the queued operations list will be executed nd the results of the operations (failure or success) reported to the caller via SetStatusL and so cannot be rolled back if there is an error. However, if before any updates are added to the adapter, StartAtomic is called, all operations that are made via for example UpdateLeafObjectL will be queued as normal and when CompleteOutstandingCmdsL is called will they be executed. This will then execute all the deferred commands, calling SetStatusL
and SetResultsL for each of the operations. If all the operations succeeded, the caller should then call CommitAtomic and this will make all the changes to the adapter permanent. If any of the operations failed, the caller should call RollbackAtomic and the adapter will attempt to restore its state to what it was at the StartAtomic call. Note it is also possible for the Rollback to fail, in which case the results of this will be returned via the SetStatusL callback.

Some adapters also support streaming for large objects. For example if the data the adapter needs is coming from or going to a slow medium then the the adapter may request or respond with a stream to supply the data in chunks. It is easy to check whether the adapter supports streaming by calling the StreamingSupport method. This returns the size of the data above which the stream methods will be used instead of the blob methods. ETrue is returned if the adapter supports streaming.

There is one API that causes more problems than all the other API's combined. This is the FetchLinkL method and will be the subject of a subsequent post.
The next posting will be on the GUID/LUID mess that form parts of the parameter list...

Displaying something when starting up your application

2008-12-15T23:55:02+02:00

One of the commonest question that seems to be asked is how to display
a dialog or a note when the application starts. Due to the way the UI framework starts, its not suitable or even appropriate to block the main thread before any iews and the main view's container are created. This causes all sorts of problems such as the background being blank and wierd crashes and issues. Almost all of these revolve around the face that the UI is not fully constructed before being used so its not possible to safely use it at his point.

The way to address this is to create an active object that is scheduled to run
but with an idle priority. This object will be run once there is nothing to do and so this gives the UI framework the opportunity it initialize itself and allow he container view to be created and displayed.

Luckily its a simple matter to create the code to do this. The way I have chosen
to do this is to use the CAsyncCallBack object with an idle priority. Of course
you can use for example your own active object or the CAsyncOneShot object to
do the same.

I recommend that the callback object be put in the main view rather than the appui
as this makes it easier to access the current view object. Of course if you
are not using the view framework then it is suitable to put it into the appui.

Three methods are needed:
void AddInitialCallbackL();
void DoStartupCallbackL();
static TInt StartupCallback(TAny* aAny);

The first method creates the callback, links it to an object and adds
the callback object to the active scheduler

The second method is the actual callback object function. The parameter passed in
is the object so this can be cast to the correct type and then the method on
that object can be called.

The last method is the actual implementation of the callback that is in the object. This can do various things including kicking off another active object. or this example a note is displayed.

For the sample code I have have chosen to put it in the main view of the application and not the AppUI.

// This is called from the DoActivateL of the view class.
void CView::AddInitialCallbackL()
    {
    TCallBack callback(StartupCallback, this);
    iCallback = new (ELeave) CAsyncCallBack(callback, CActive::EPriorityIdle);
    // Most people forget the step below, this schedules the active object!
    iCallback->CallBack();
    }

TInt CView::StartupCallback(TAny* aAny)
    {
    CView* view = REINTERPRET_CAST(CView*, aAny);
    TRAP_IGNORE(view->DoStartupCallbackL());
    return EFalse;
    }

void CView::DoStartupCallbackL()
    {
    CAknInformationNote* note = new (ELeave) CAknInformationNote(ETrue);
    note->ExecuteLD(_L("Callback Executed"));
    }
That is all there is to getting a dialog, note or query up when your application is started

Reading DM Adapter DDF's

2008-11-30T18:21:24+02:00

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...