The deadline I gave myself of the end of August really pushed me to complete TextQuick. There were many late nights and I was really quite tired afterward. I am still happy to have made the dead line, but it was a bit of hard work. This was the first time I have released any thing commercially myself and it was a great learning experience. There was so much more to do than just the development of the application, getting set up with Handango, packaging and placing TextQuick on their web site, etc. But it was all good fun, and now after a short break to recharge the batteries I'm back looking at missing features, internalisation and more bugs.
I released the original beta in an effort to discover as many bugs as possible, and the feed back I received was fantastic, I managed to find and fix a number of issues. However with the release of the commercial version of TextQuick came a number of new bug reports. Issues which had existing within the beta were only getting reported after the application had been released commercially.
I think this is because people have lower expectations for free / beta software and so they put up with the smaller bugs. However once you've paid for something your expectations are greater, you expect these small issues to be resolved. This is one of the reasons I've offered free upgrades to all who purchased a copy of TextQuick via the handango site. So now I'm starting to study the bug reports I've received since the application was released. These latest bugs are the trickier and harder to reproduce, so it's taken me a while but I think I've managed to nail two of them.
Unable to call space.
Those people who synchronise their smartphones with PC's often have contacts from their PC transferred to their phone. An S60 device's user interface prevents us as users from entering invalid characters for people's telephone numbers, however applications on the PC are often not so strict. Apparently once such application is Outlook. Some people who had created contacts on their PC using Outlook had entered the space character in their phone number, for instance “+353 1 23456” instead of “+353123456”. The API provided to me by Symbian / Nokia to make phone calls has issues with spaces. It returns an error and doesn't make the call if you give it a number with spaces inside it. I have resolved this issue by removing spaces from the telephone number before I make the call.
Can't call in an emergency.
Before I discuss this bug let me give you a little background to how Symbian's telephony subsystems are structured. Symbian needs to give all applications a standard API to make phone calls. This API needs to stay the same across many different devices, however on each device the actual way the phone is made can be completely different – for instance what about making a CDMA phone call verses a GSM ? Or what about making a phone call on Nokia's phone and Panasonic's ? To solve this issue Symbian provide a server which has the API to make phone calls, and then they ask the manufacturers to supply a plug-in which talks to the hardware and actually makes the phone call. The front end API is called the Telephony Server, and the back end is a Telephony Server Plugin or TSY as it's know.
The API I'm given to make phone calls is closely guarded Symbian, Nokia and etc don't want a 3rd party application to start making calls to the emergency services. So they have put some checks in to prevent 3rd party applications from doing this. If I try to call an emergency service number, such as “911” (US), “112” (EU), or “999” (UK & Ireland) the phone returns an error to make and doesn't make the call. This makes sense, if the checks were not in place a virus writer could produce an application that would repeatedly call the emergency services and clog up the phone lines.
However I tried to call a friend of mine in the UK using TextQuick, their number ended in “+44xxxxxxx911”, but the phone would not let me – instead it returned an error. A little bit of investigation revealed that because the number I was trying to call had an emergency telephone number as a sub-string (the last 3 digits “911”) the phone was freaking out thinking I was calling 911 directly. This was obviously a bug with the phone rather than with my application. After all I can remove spaces from a phone number, but if I change the phone number completely who knows who you would end up talking to ?
My first though was that this bug was with the Symbian code, as it's their API I call to make the phone call, I'd have imagined that it was their code that was looking for the emergency telephone number attempts and blocking them. That way they could pass through to the TSY only valid telephone numbers. I contacted some people I know at Symbian and reported this bug to them. Both Sophie and Chris were great. They did some testing and examination of the Symbian code and discovered that they could call telephone numbers containing emergency strings. It transpires that this is a bug with the TSY from the manufacturer. Symbian leave it up to the TSY to do the checking for emergency telephone numbers and it was a bug within Nokia's TSY that was causing the issue. I have a Nokia E50, but the TSY's can change from device to device, so the TSY on the N95 is different.
Others who have more modern S60 devices have reported that this bug does not exist on their phones. So it looks like Nokia have already spotted this issue and have resolved it for their future devices. In the mean time I hope they roll out fixes for their older devices.
The next release of TextQuick includes some checking for this issue, if TextQuick encounters this issue it pops up a little box to explain what has gone wrong. If you encounter this problem I would suggest updating your firmware, you never know Nokia may have fixed this issue already.
That's enough of a description of the bugs I've been looking at – now I think it's time I got back to preparing my first update of TextQuick 1.4.