Opera Mini 5 Beta, character map, and Nokia phones

     I am really impressed with what Opera has managed to do with what they proudly claim “the next generation of mobile browsing” in the form of Opera Mini 5 Beta. It is as good a browser as I have never before used on a mobile device. Any words that I could concoct to describe how great it is won’t by any stretch of one’s imagination do justice to the product.

     I am using it exclusively on my Nokia E61 mobile phone. The E61 features a QWERTY keyboard with a limited set of special characters available on top of the alphabets as function keys. These include characters such as hyphen, exclamation mark, double and single quotes, parenthesis, etc, among others. However, these are not all of the commonly used special characters, and in order to get to a full list, a “chr” key is provided on the keyboard, pressing which brings up a character map.

     While Opera Mini 5 Beta is still fairly robust and stable for a beta software, there is one issue I’ve found that I feel has a rather inconspicuous solution. On the keyboard of E61, the rather common underscore character is not available as a function key. In order to use that character, you have to get to the character map, and select it from there. The underscore character becomes even more common on the web, where you may tend to have it as part of usernames, passwords, or email addresses, in particular. I do. And here’s where Opera Mini 5 Beta gets a trifle quirky: If you’re editing any text box within the browser, you cannot access the character map, not through the “chr” key, not through any other key or combination thereof. When I initially bumped into this quirk, I was both sorely disappointed and pissed. I couldn’t log in to any of the websites where I had a username or email address with an underscore in it. And for a while, it kept me apprehensive about using Opera Mini 5 Beta frequently.

     However, after toying around in Opera’s settings, I was able to finally find a workaround. Inside “Advanced” options inside “Settings” menu for the browser, there is an option, turned off by default, for “fullscreen edit”. Once enabled, you can edit all text boxes in a native, Symbian-esque text editor, where the character map is easily available via a press of a key.

     Bliss!

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.

Why does wi-tribe connection shut off on the first of every month?

     I have been noticing that on the first of every month, the wi-tribe connection that I am using stops working as soon as I receive the invoice email. Browsing stops. Replies to ping requests stop. All Internet activity comes to a halt.

     When this happens, I get in touch with a customer support rep and describe my problem to them. After a while, they figure out what is wrong, tell me to try again after a brief moment, and take their leave. They never clearly explain the cause of the problem, beyond it being due to some glitch in their systems. But whatever it is that they do, works and makes me happy.

     In the early afternoon on the first of January, my connection stopped completely soon after I received the invoice over email. From that point on till an hour before midnight, I tried relentlessly to get some human to pick up the phone at the customer support site — I had the impression that the support staff got drunk and passed out over the new year’s eve, and didn’t come to work the next day. And when someone finally did, they were not able to fix my problem, promising me that a complaint was lodged and my problem will be resolved shortly.

     However, one question that they asked me during my brief conversation with them on the phone, gave me an idea about what could be wrong. Because I have come not to trust DNS resolvers that local ISPs use, I always use either OpenDNS or, recently, Google DNS resolvers. With that little detail in mind, I edited the network settings on my computer to not use any external DNS resolves but the local ones. My mail didn’t still work, nor did replies to ping requests show up. But what did half-work was any attempt to access any webpage on the browser. The browser redirected automatically to a wi-tribe internal page which told me that my invoice has been released, and this or that will happen if I don’t pay beyond the due-date. However, what caught my attention and also made me feel extremely silly was a big button in the middle of the page that read to the effect, ‘Click to continue browsing’. And clicking on that button did as advertised. I felt extremely stupid.

     So, what was the problem? The problem was that, since I was using external DNS resolvers, wi-tribe was not able to redirect me to their internal page on the first of the month when the invoice was generated. When I switched to their local DNS resolvers, I was able to see that page, click on the big button, and continue using the Internet.

     To think that I wasted a lot of money in calls to customer support, torture myself from being pissed at not being able to both use Internet and get someone at customer support to pick up, only due to a thing as silly as I’ve described, I feel an uncontrollable urge to curse out loud.