Symbian Programming

Symbian security is very useful for users. Currently there is no virus that I know of that can run on the new Symbian 9.0 because of the new security framework. From the developer point of view, this security framework is sometimes frustrating. The developer needs to sign his application, and then he have to specify what capabilities are needed for the application. We can categorize the Symbian security capabilities to 4 sets. The first one is the default one, which doesn't need any user intervention, the second is User Grantable capabilities which can be granted by the user (the installer will ask the user that the program needs some capabilities), the third one is the one that the developer must ask from Symbian, and the last one is the one that the developer must ask from the device manufacturer.

The problem starts to appear when you need additional capabilities other than the default and User Grantable. For example we will need NetworkControl capability to create a ping application. Here is how you would do it according to the old process:

1. You will need to get a certificate from Symbian, then you can test it only on one device.
2. To be able to distribute it, you must submit your application to be tested by Symbian (this process is not free). The last process will take several weeks.

The old process have some loophole that is being used by crackers. For applications for which they can not generate the serial number, they patch the application, and the user that wish to use the cracked application will need to get a certificate from Symbian, and sign the cracked application so that it will work on his phone. Now they revised the process:

Quite many people found the message "Missing Separator Error" when building GCCE target. Usually this happens because the path to GNU CSL ARM compiler is not correct. The line that causes the problem is usually generated by cl_bpabi.pm, in sub GCCLibPath. The subroutine will try to execute this:

arm-none-symbianelf-g++ -print-libgcc-file-name

to find the path to GCC include files.

So in case anyone else is having the same "missing separator. Stop",
just check if you can run:

arm-none-symbianelf-g++

If you can not run it, then somehow "arm-none-symbianelf-g++.exe" is not
on the path or the path that you set in the system is wrong/mistyped.

After using Carbide C++ for about 8 months, I think Carbide is not so bad. For my main open source project (Symbian bible), I still prefer Linux with my custom Makefile. The good thing about Carbide is that you can easily debug your project in the emulator. This is still impossible to do in Linux. For the commercial version (Professional onward) you can even debug on the device.

For the commercial version, the GUI designer is quite OK for many kinds of applications. You can create dialogs in minutes which usually takes hours. The GUI designer will not be too useful if you are building games, or applications that only have one view ("one screen"). The GUI designer is extremely useful for developing application with many data forms. As for the advanced features like performance tools or tools for the OEM, I have never tried it.

So is Carbide C++ for you? This tool is useful at least for one thing: debugging using emulator. If you need to do on device debugging or designing many applications with many data forms, the it might be useful for you to upgrade to the non free version. For me, I think I will do most of my project using the command line. If I can do debugging or use the emulator in Linux, then I would probably use Linux.

I was seriously considering buying a professional license to Carbide C++, but now I am not sure anymore. C++BuilderX 1.5 Mobile Edition was a great product by Borland, or at least is was going to be great, but the decided not to continue with it. With the Carbide C++ professional edition (and with C++BuilderX mobile)  I can develop simple GUI for Symbian very quickly. Building a GUI in Symbian involved editing resource files, and writing many classes.

I am a bit disappointed with many bugs in Carbide 1.2. The bugs are also inconsistent, so I can't get myself used to it. Sometimes the GUI editor spits out error messages, and it is not clear on how to workaround it. Most of the time, I can not find an easy way to add an event handler. The default action for a view is to exit from an application, and there is no easy way to override the action.

I thinkI am going to write more, once I use this thing more.

When I released my utility: LogExport, I didn't think that many people will use it, but I was happily surprised to know that many people use it, and give comments on my blog. LogExport is just a very simple application, it reads your call/sms log, and export them to a CSV file. In this post, I will explain the inner working of LogExport.

LogExport uses Symbian API to access the call log (the classes are: CLogClient, CLogFilter, and CLogViewEvent). Because there might be many entries, I must use Active Object and progress bar to show the export progress. Nothing fancy here, but to find format of each field, I needed to do some experiments (e.g: does the field contains a comma, if so it must be escaped to display properly in CSV). I also need to find the event type for Wifi, which was not documented when I wrote the app (I don't know whether they have document it now), The value of event.EventType().iUid should be 0x1000595F for Wifi.

You can download the source code here.

RBuf is an interesting descriptor class introduced in Symbian 8.0. Based on RBuf, Penrillian has created RStringBuf which provides functions very similar to the other descriptors - but which manages its own memory allocation for all the common string operations (e.g. no need to extend the descriptor manually for Append or Insert).

I am currently rewriting the rendering engine for my Symbianbible, and I need a class that is similar to RStringBuf. My bible reader supports multiple Symbian platform (UIQ 2, UIQ 3, Series 60, Series 60 3rd edition, Series 80, Series 90) so I can't use the RStringBuf from Penrillian since it depends on RBuf.

Rather than rewriting RStringBuf from scratch using existing descriptor, I decided to write my own RBuf class that is similar to Symbian's RBuf. It is not difficult, since the source codes of other descriptors implementation are available in file UC_DES16.CPP and UC_DES8.CPP on old EPOC SDK (although it is incomplete). I only implemented the RBuf16, but implementing RBuf8 would not be so different.

You can download my implementation here: RStringBuf_1_1.zip

I have ported S60Dict to 3rd edition. There is no special steps involved in porting this program since it does not use any strange stuff. You can download the source code and binary from: http://tinyhack.com/freewarelist/s603rd/2007/02/26/s60dict-for-3rd-edition/.

The easiest way to learn about the descriptor is trough the equivalent code in C. In this post, I will write a short comparison, this article is inspired by the explanation about Symbian Descriptor on the the Professional Symbian Programming (I said inspired, my explanation is different, and the code in the copy of the book that I have is sometimes incorrect). In this part I will talk only about constant/immutable strings.

In C, if you define something like this:

static const char hellorom[] = "hello";

Then the string "hello" will be on a non-modifyable memory space (may be in ROM or RAM, but it can not be modified).

The equivalent code in Symbian is:

_LIT(KHelloROM, "hello");

Everything is still easy to understand here: you can not modify the contents of KHelloROM or hellorom. Something to note is that in Symbian the string is not NULL terminated, the length of the string is recorded in KHelloROM.

Now, in C, you can also have a pointer to the same location:

const char *helloptr = hellorom;

We can have that in Symbian:

TPtrC helloPtr(KHelloROM);

helloPtr contains a pointer to KHelloROM, and the length of the descriptor pointed by that pointer. You may think it is a bit strange: why do we need to store the length again?. The reason is that we can have a pointer to the first n part of the string, like this:

TPtrC ptr2(KHelloROM().Ptr(), 2);

If you try to display/print ptr2, it will say the string "he".

On Series 60 3rd edition, pressing the END key will kill your application instead of bringing it to the background. In some applications, this behaviour is unwanted (e.g: Instant Messaging application), and the old behaviour is preferred.

To handle the END key, you can create a method HandleWsEvent, and intercept the KAknUidValueEndKeyCloseEvent, you can save the state of the of the app then exit, or saving the application state then go to background, or just go to background.

#ifdef __SERIES60_30__

void CS60BibleAppUi::HandleWsEventL (const TWsEvent &aEvent, CCoeControl *aDestination)
{
  
switch (aEvent.Type()) {
        case KAknUidValueEndKeyCloseEvent:
        {
            /*do something, like saving the state.
If you want your program to exit, call  CAknAppUi::HandleWsEventL(aEvent, aDestination);*/
            break; /*or just go to background*/
        }
        default:
        {
            CAknAppUi::HandleWsEventL(aEvent, aDestination);
        }
    }
}
#endif


S60 3rd edition phones comes with different screen size (unlike thre previous editions that has fixed size screen or has a compatibility screen mode), so you must make your code resizeable, and some series 60 phones can have their orientation changed (by twisting the phone).

In your AppUI class, add HandleResourceChangeL method:

void CS60BibleAppUi::HandleResourceChangeL(TInt aType)
{
     CAknAppUi::HandleResourceChangeL( aType );
     if ( aType == KEikDynamicLayoutVariantSwitch )
     {
         /*call sizechanged on all views*/
         iSettingView->SizeChanged();
         iKeyBindingView->SizeChanged();
     }
}