Carbide needs a rebuild option

     By and large, Carbide is the best IDE for Symbian development available today. Working on the shoulders of Eclipse, Nokia has spent considerable time and effort into customizing Carbide to a point where it makes Symbian development convenient for developers. Having said that, I should also point out that Nokia and Carbide both have a long way to go to provide as great an experience for Symbian development as, for instance, Apple and Xcode have for iPhone development.

     Under the hood, the Carbide camp has adopted what has become second nature for Unix and Linux developers: the “Keep It Simple, Stupid” (KISS) philosophy. Carbide heavily uses a tool-chain to perform a lot of different yet important tasks. That tool-chain includes interpreters such as Perl, compilers such as gcc, build configuration utilities such as make, powerful debuggers such as gdb, etc. When a project is built, or even cleaned, Carbide actively relies on this tool-chain to perform a set of very crucial tasks. And in the traditional Unix/Linux style, those disparate tools are linked together by the use of pipes. So, one tool performs one task that it is designed to do best, spewing its output to another tool to perform another task. This is a great philosophy to follow, I believe, because some of the best open source softwares are utilized. In other words, Carbide, among many other things, does two things in particular: it provides a polished, snazzy front-end that lives on top of powerful, command-line open source tools; and it links together a set of tools to make possible different things. If you have used Linux extensively or programmed on it, you will feel at home as this methodology is not uncommon there.

     Admittedly, I have a plethora of pet peeves with Carbide in general and Symbian development in particular. However, I have decided to gripe about one such annoyance that I have with Carbide. Carbide doesn’t have a “rebuild” option. Anyone reading this may think I am whining about a very trivial thing, but it isn’t trivial at all. Consider the fact that Carbide relies largely on piping together different command-line utilities to perform a disparate set of tasks, and presenting the results on the front-end. While Carbide does it mostly right, it falls short at many places when it comes to clearly showing what went on in the background, when, say, a project build fails due to errors. Building of a Symbian project can be divided into several parts, which Carbide abstracts under the “build” operation. These parts include, but are not limited to, compilation of resource files for UI elements, compilation of source files and linking of resulting object files, creation of binaries, packaging of binaries and resource files, creation of SIS files, signing of SIS files, etc. Carbide tries really hard to keep the user aware of anything that goes wrong at any of those steps during a project build. However, Carbide is not perfect, and as such leaves itself open to subtle problems that can become a cause of increased annoyance for the developer.

     Now, Carbide does have a “clean project” option, which is what I use before building a project every time. But I don’t know how many other developers do so — I did not use to routinely in the past, for example. If you are a Symbian developer, you must have been bitten at least once by the problem that arises from not cleaning your project before every build. Because the build process is divided into a number of different steps, with some steps producing concrete artifacts that are used by the following steps, there is a subtle, ugly problem lurking in there. Consider the step where resource files for the UI elements are built, and also the step where the package for the application/project is built. The latter has to incorporate all pertinent compiled resource files as well as binaries into one final package. And here lies the subtle problem: the tool that is used to create the package does not look at the previous steps to ensure that everything went ok. It can’t. All it does is that it looks into some directory for the presence of the compiled resource files and binaries it is looking for, picks them, and packages them up without thinking about whether the current build failed to produce any resource files or binaries, and that those that it picked are actually not from a previous, now out-dated build (which were left behind from the previous build because the build data wasn’t cleaned). This hideous problem surfaces when, after making adjustments in the UI elements and resource files, any compile time errors are introduced. Now, Carbide gets below par when it comes down to catching some of those errors. For example, for some hideous errors that crop up during resource compilation time, Carbide is only able to catch them when at the far end of the build process, the package manager fails to find compiled resource files because those didn’t compile from earlier. However, if there are older compiled resource files available, and an error is introduced in the resource files which precludes new resources from being built, those errors will be quietly lost because the package manager will quietly and happily pick up the old resource files (as it can’t tell which are new or old, or whether any of the steps that came before it actually passed). As a result, the developer will be left scratching their head for a long while, trying to figure out just why is it that their changes are not being picked up when they run their application. But, it could easily get worse than that.

     So, if you are a developer, and you are not in the habit of cleaning up your projects before compiling every time, you will one day or another get bitten by this hideous bug. And when you do, it will hurt for a long while before you are able to realize where it is hurting and band-aid it.

     This is the reason why I am in favor of Carbide having a “rebuild” option.


Does your Symbian phone take a long time to send SMS?

    I have possessed close to four Nokia S60 smart-phones in the last couple of years: an E50, E61, N80, and an N95. Beyond testing Symbian applications, I have never seriously used any of those phones as personal phones. I don’t despise Symbian phones, nor do I find the UI difficult to live with. My reluctance to use Symbian phones for my personal cellphone needs is largely because of an annoying problem I have faced on the phones that I have mentioned. The problem is that sending of SMS would become pathetically slow on the phone after a short period of use. If the phone was reset to factory settings, it would send SMS with the acceptable two to three seconds delay, but after a short while, the delay would start to gradually increase until it would get to a point where it would become painful to send SMS. Not only would the phone take anywhere from one minute to three minutes to send a single SMS, but would also freeze the phone until the process finished, leaving the phone inoperable during that time.

    Until very recently, I had no clue as to what caused those phones to exhibit such behaviour. Suspecting installed third-party applications of being the cause, I tested by keeping the phone clean after a factory reset (which wipes out all installed applications), but in vain as the problem described showed itself again. I tried resetting the phones in a number of different ways to get rid of the problem, but couldn’t. Every time that would happen, I would give up and move back to using the Sony Ericsson phone that I have.

    Pissed at not being able to figure out the cause of the problem, I decided to upgrade the firmware on one of the Nokia phones I have: the E61. The firmware update process, as painful as it was for me, will be described elsewhere in future. The firmware update upped the firmware version from 2.x to 3.x, which constitutes a major change. Reading through the number and type of things that the firmware changes and fixes, I did not find any mention of any “SMS sending slowness” issue. Dejected, I ran over Google to find something to console me. And find I did.

    I found that, after all, I was not imagining the problem I had been having. Other, real people were having similar issues with similar Nokia phones. And it was not a problem brought about by any third-party application installed on the phone. It was a bug in some models of Nokia phones, including the ones I unfortunately have. That was a relief. But, what were these people doing to circumvent the problem? Anything?

    Yes. As it turns out on a happy note, Nokia released a patch for the bug. They call it the “SMS Accelerator”. It is available lower down on the page here. It is a standard Symbian SIS file that installs an application inconspicuously in the background. This application strikes at the heart of the problem causing extremely long delays in sending of SMS. I have it running on my E61, and I can affirm ecstatically that it works. :)

Symbian: AKNFEP 23 panic

In an earlier post, I touched upon a means to switch the language of the Symbian emulator, popularly known as Epoch. I wanted then, but forgot, to mention one slight issue that crops up unexpectedly after the emulator makes a language switch. The thing that rears its ugly head is called an AKNFEP 23 panic. You may find a trifle relief searching for anything against it on the web, but the official SDK documentation—at least the 3rd edition MR documentation–swears ignorance. For these reasons, and because I wrote a post describing what appears to be the source of this issue, I feel I should plug in the loose ends properly.

There are two things that need to be told apart on the Symbian emulator. One is “changing the language of the emulator”, which changes the overall language of the simulator, a task that is akin to changing the language of a mobile device from English to Chinese for someone who only understands Chinese. The other is “selecting a writing language”. The writing language is what you write text in, say, for example, when you are composing an SMS message. It can be different from the language of the emulator or the phone, but it must be supported by the device—the latter condition being redundant as a device does not allow you to switch to writing languages it does not support.

You would ask, “Why is this distinction important?”. Often if not always, when you change the language of the emulator, you would also want to change the writing language, so that, for example, you may be able to write SMS messages in Chinese. Neither the emulator nor the phone is smart enough to automatically switch the writing language to the global language that is set. Whether it is a design decision or a feature not deemed necessary, I cannot say. However, on the emulator, when you change the language from English to a more exotic language like Chinese, and back, if the writing language is not also changed to reflect that language, you will confront an ugly AKNFEP 23 every time you try to open any of the applications.

Yes, the solution is that simple: Simply change the writing language. Here is a link to a discussion of the cause of AKNFEP 23 panic.

Symbian: Changing language of Symbian Emulator

The biggest hurdle in writing mobile applications for Asian markets, in particular, is providing multi-lingual support. From hunting down people for translations to acquiring phones that actually support a big, diverse set of languages in common use in Asian countries, it is an all-round big challenge for mobile application developers. It is almost frustrating to the point of throwing in the towel, but if you want to tap into the markets, making headway, especially since Asian markets tend to be more competitive than any others, you have to persist and expend serious effort. There is also no question of demonstrating your product in English to potential customers in Asian markets — they would always want the product translated into whichever language they speak and read, and if you do give a demo of the English version of your product, by the time you have a localised version ready to market and sell, some smart aleck would already have bootlegged your idea, developed a localised version and sold it. That alone is a troublesome drawback when marketing your products to Asian markets. Therefore, as a rule of thumb when diving into Asian markets: Have a localised version of your product ready and fully tested before going in.

I am falling off on a tangent. I wanted to talk about multi-lingual support on the Symbian emulator. The symbian emulator by default is in English. For testing and debugging a multi-lingual application, you would naturally want the emulator to be converted into whichever language you are testing your application on. Once inside the emulator, you will find that there is support to change the writing language to any from a large set of languages available. However, if you do that, you would notice that the emulator crashes with a panic. This happened when I tried to switch writing language to Chinese. I cannot say if the panic is reproducible for other languages as well.

Even if you can change the writing language to any language that works well on the emulator, it isn’t sufficient. In order to test multi-lingual applications, you have to convert the emulator to look and work exactly how a mobile phone would for someone who can only understand, say, Chinese. How do you do that? If you look under Program Files > S60 Developer Tools > 3rd Edition SDK > 1.1 MR > Languages, you will see few links to languages to which you can switch the emulator. Unfortunately, clicking on any does nothing. It is possible the options are fixed in recent releases of the SDK. But if they are broken on yours, here is a way to change the language of the emulator.

You must have javaw.exe in your system PATH. If not, you will have to explicitly give out the complete absolute path to the javaw.exe binary. On the windows command shell, jump to the \Epoch32\tools\ecmt\ directory (which can be found inside where ever you’ve installed the SDK on your system), and run the following command:

C:\Symbian\9.1\S60_3rd_MR\Epoc32\tools\ecmt>javaw -classpath unzip.jar;plugins/general.jar;lib/log4j-1.2.8.jar -Dsource=language -Ddestination=..\..\.. -Dlanguage=en_us -Dplatform=winscw

C:\Symbian\91.\S60_3rd_MR\ is where I have the Symbian SDK installed on my system. I also have javaw in my PATH, thus eliminating the need to put down the absolute path to the binary.

Pay close attention to the -Dlanguage=en_us argument. This is the value you have to change to suit your requirement. If, for example, you have to switch the emulator to Chinese language, you will have to change “en_us” to “zh_cn“.

Look inside the \Epoch32\tools\ecmt\language for information on which language packs come with the SDK by default.

Always remember to change the language back to English after you are done with testing your localised application.

Before I close this off, I would like to give credit to this post on Nokia Developer Forums from where I picked this solution.