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:

1. You will need to compile your application, and upload to Symbian for signing. You can only sign an application that is yours (the UID of the application must match to one of the UID that you have requested from Symbian). This will prevent a user from signing 3rd party application (which presumably a cracked application).
2. To distribute your application, you will still need to pay. As an improvement, they have provided express signing, where you can quickly sign your application without testing it. They will pickup some application for random testing.

As you can see, the development process becomes more difficult because now we must sign our application online. People keep telling others that only a small set of capabilities are restricted, but that is not entirely true, it depends on what kind of application you are developing. For example, this kind of simple applications needs more than User Grantable capabilities: VoIP applications, screen capture that can be activated by shortcut, network ping tool.

Recently, a flaw has been found in the debugging mechanism used by Symbian (AppTRK). The debug server on the Symbian side is an all-powerful application that has all the capabilities in the world, and can be controlled to do anything from the PC side when debugging. As you can guess, this can bypass all the security measures in Symbian. I tried the method, and it works very nicely. This process makes it very easy for me to test any kind of functions, including those that requires special capabilities.

I am quite sure that this hole will be plugged in the next firmware release, and it will be a shame, because this bug can actually helps developer, without risking simple end user. This hack is not so simple, so I think anyone that can do this hack is not a simple user, and can be responsible for the harm that it might done his phone. I really hope that Symbian will provide a nice, legal, documented ways for a developer to really "own" his phone to be able to develop anything, and still uses the current security method for end users.

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.

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

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.

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

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

We can also put the "constant" data in stack (it will not become constant anymore, since stack is always writeable):


//this code is inside function
char hellostack[sizeof(hellorom)]; //sizeof counts the NULL terminator
strcpy(hellostack, hellorom);


This is a bit different in Symbian:

TBufC<5> helloStack(KHelloROM);

The string "hello" will live on the stack, along with the pointer and the length, but you can not modify the data through the variable helloStack. This is a bit useless, but using the TPtr class, you can still change the data (which is strange). I will discuss about this on part 2.

And you can put the string in the heap:

const char * s = strdup(hellorom);

In Symbian:

HBufC *h = KHelloROM().AllocL();

The HBufC class points to a data in the heap (that is owned by the object), and has a maximum length. Just like TBufC, this isn't really constant String (modifiable trough TPtr).

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


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();
     }
}



void CKeyBindingView::SizeChanged()
{
if (iSettingList) {
iSettingList->SetRect(ClientRect());
}
}


The Container also needs to know about the resource change (changes in screen size/orientation):

#ifdef __SERIES60_30__
void CS60BibleMainContainer::HandleResourceChange(TInt aType)
{
CCoeControl::HandleResourceChange(aType);
if ( aType == KEikDynamicLayoutVariantSwitch ) {
TRect rect;
/*if your apps support full screen, then use EApplicationWindow else just use EMainPane*/
if (iFullScreen) {
AknLayoutUtils::LayoutMetricsRect(AknLayoutUtils::EApplicationWindow , rect);
} else {
AknLayoutUtils::LayoutMetricsRect(AknLayoutUtils::EMainPane, rect);
}
/*In app case, the model needs to be updated*/
iDocument->Model()->SetArea(rect);
iDocument->Model()->ClearVerseList();
iDocument->Model()->FillVerse();
/*Set rectangle*/
SetRect(rect);
}
}
#endif


Done, your app should now be able to resize properly. If you use your own drawing routine, then you must adjust your code (dont use absolute coordinates). You can also use new S60v3 features, such as SVG, but it will make your code nor portable to the previous Symbian version.

abld build gcce urel

But building for the Windows target is not so easy, you can use Carbide, or set your environment correctly. To use carbide, you can import your bld.inf, and just click on build. To use command line build, you can follow the instruction at http://www.sciabarra.com/blog/ or check out Webkit, and run build -e > env.bat (but adjust the EPOCROOT to the correct value, which is usually "C:\Symbian\9.1\S60_3rd_MR_X", where X is the revision number).

You need to modify the package file, you can see the sample files included on the SDK, here is a list that you must change:

1. Change target uid for 3rd edition: 0x101F7961


2. EXE and DLL should go to \sys\bin (flat, all exe and dll goes here), not \system\apps\appname anymore


3. Place resource files in \resource\apps\


4. Registration files should go to: \private\10003a3f\import\apps\

Creating the package file is easy, just type: makesis filename.pkg

Create certificate file (see the SDK, you can copy paste the command line), and sign your application:

signsis s60biblev3.sis s60biblev3.sis symbianbible.cer symbianbible.key password


OK, you are ready to install your application.

The most important change is in the function E32Dll, you must change it to E32Main:

#ifdef __SERIES60_30__
GLDEF_C TInt E32Main()
{
    return EikStart::RunApplication( NewApplication );
}
# else
GLDEF_C TInt E32Dll( TDllReason )
{
     return KErrNone;
}
#endif


but you must include this header:

#ifdef __SERIES60_30__
#include <eikstart .h>
#endif


Since we use different UIDs, use different constants:


#ifdef __SERIES60_30__
const TUid KUidS60BibleApp = {0xF0201077};
const TUid KUidS60BibleUi = {0xF0201079};
#else
const TUid KUidS60BibleApp = {0x10201077};
const TUid KUidS60BibleUi = {0x10201079};
#endif


If you use application path for storing data, like c:\\system\\apps\\s60bible\\data.txt, you must change it to \\private\\\\data.txt. This code will set iDataPath (defined as TFileName) on 1st, 2nd, and 3rd:


HBufC *appDll = HBufC::NewLC(KMaxFileName);*appDll = iDocument->Application()->AppFullName();
TParse parsa;
User::LeaveIfError(parsa.SetNoWild(*appDll, NULL, NULL));

#ifdef __SERIES60_30__
CEikonEnv::Static()->FsSession().PrivatePath(iDataPath);
#else
iDataPath = parsa.DriveAndPath();
// If the application is in ROM (drive Z:), put settings on C:
if ( (iDataPath[0] == 'Z') || (iDataPath[0] == 'z') ) {
     iDataPath[0] = 'C';
}
#endif
Enable skin support:
On the ConstructL of your class:

#ifdef __SERIES60_30__
BaseConstructL(EAknEnableSkin);
#else
BaseConstructL();
#endif


First you need to create a new bld.inf and MMP file, usually you just need to change the target to WINSCW GCCE and add gnumakefile icons.mk if you are planning to use SVG icon (I think you should, and this article assumes that you are). Its rather difficult to explain the contents of icons.mk, just copy from the Series 60 Examples, and edit the svg filename. You can create the SVG icon using InkScape (free).

Change the MMP file as follows:

1. Change target type to EXE


2. Name the target file from name.app to name.exe


3. Map your old uid from 1xxxxxxx range to Fxxxxxx range, i.e change the first hex from 1 to F (or request a new one from www.symbiansigned.com)


4. Change the stack size just in case it is not enough for you, add epocstacksize 0x5000. If your application needs large amount of heap, change also the epocheapsize.
   


5. If your application needs special capabilites, add CAPABILITY

The creation of resource files from MMP needs to be changed from:


RESOURCE S60Bible.rss

to

START RESOURCE S60Bible.rss
HEADER
TARGETPATH \resource\apps
LANG SC
END


Add the following code to your RSS file:

RESOURCE LOCALISABLE_APP_INFO r_s60bible_localisable_app_info
{
short_caption = STRING_s60bible_short_caption_string;
caption_and_icon =
CAPTION_AND_ICON_INFO
{
caption = STRING_s60bible_caption_string;
number_of_icons = 1;
icon_file = "\\resource\\apps\\s60bible_aif.mif";
};
}


Create registration file (it must be done so your app will shows up on the menu), names yourapp_reg.rss:

include
#include

This RSS file also needs to be added to the MMP (the target is different between the emulator and the real device, why the hell are they doing that?):


START RESOURCE S60Bible_reg.rss
#ifdef WINSCW
TARGETPATH \private\10003a3f\apps
#else
TARGETPATH \private\10003a3f\import\apps
#endif
END


if you are using avkon.mbm, change it to avkon2.mbm, like this:
#define AVKON_BMPFILE_NAME "z:\\resource\\apps\\avkon2.mbm"

OK, you should be ready to change the code now.

The difficult part is how to get everything works comfortably for the user. Using Nokia 9300, in full screen mode I can still access the CBA using the hardware key, but on Nokia 7710 this is impossible (the CBA is virtual). My solution was to move some the CBA functionality (goto verse and history) to button A and B (the did not document this button, the code is EStdKeyDevice4 and EStdKeyDevice5), and to togle fullscreen I use the Escape Key (the right bottom button, the keycode is EStdKeyEscape).

You must also be careful if you are using the joystick on the Nokia 9300, the scan code for the center/fire key on the Nokia 7710 corresponds to the right joystick key on Nokia 9300 (i was surpised because hitting the fire key advances the verse one line ahead).

I am loading the font using this code:

for (TInt i = 0; i < entries->Count(); ++i)
{
Int id = 0;
tmpFontPath.Copy(KFontDir);
tmpFontPath.Append((*entries)[i].iName);
CEikonEnv::Static()->screendevice ()->AddFile(tmpFontPath, id);
}


Can it be because of the ID (I am just starting from 0). If I can change a font for other application, can I change the system font?

I will try to solve this later at home.

Update: This is the problem:

http://www3.symbian.com/faq.nsf/0/BA5F628A350FBFEB80257336001D0C68?OpenDocument