I have an application that needs to send a HTTP request on application exit to tell the server that the app terminated normally.
When the user presses the exit button, I issue an asynchronous request to send off a HTTP transaction and get a callback once that’s done.
Now the problem is, I want to really exit the application from my HTTP handler.
I can’t call CEikAppUi::Exit(), since this basically deletes the top level appUI and proceeds to pull the rug under the HTTP class which KERN-EXEC 3’s once my HTTP handler returns and reads/write some bit of memory that no longer exists.
Once solution is to create a CAsyncOneShot derived active object to cleanly exit, and luckily Nokia have already done this in a well hidden method:
Just call:
iAvkonAppUi->RunAppShutter();
The iAvkonAppUi is an ugly macro over CEikonEnv::Static(), so you can call it anywhere in your code.
THe app shutter allows the current call stack to unwind naturally and then exits the app.
When I joined Symbian in 1999, OOM (out of memory) and OOD (out of disk) testing was heavily engrained in the culture company’s as a continuation of the Psion product development activities.
Before I joined Symbian I was writing lots of Java code but had also written oodles of C code which didn’t bother to check the pointer from malloc().
My formative years at Symbian really taught me the value and skill of being able to write exception safe (and exception sensible) atomic/revertible state code. Although the particular dialect and naming scheme of Symbian’s exception handling framework (leaves, traps and the infamous clean-up stack) may not be the most popular, the general lessons learnt can be applied in any kind of software.
When writing software for an OS, it’s incredibly important to write robust code and consider every possible failure. As a pertinent example. I was assigned to fix a defect in customer’s phone in which the device sometimes failed to boot and had to be re-flashed – a problem that if happened on a consumer device may result in a costly replacement of the device at a service centre.
The bug was due to a customer modification of the phone application which was doing the following:
1. Write 80 bytes of data to a file during the shut down of the phone
2. Read 80 bytes of data from a file when the phone boots up
A very simple piece of code but the problem occurred when there was <80 bytes free. Lets say it managed to write 40 bytes.
When the device rebooted, it tried to read 80 bytes and got a Eofexception which propagated all the way up to the phone application’s constructor. Since the phone app is a critical process, the device tried to reboot in the hope that it would solve some issue.
Putting aside the inherent problems of having customers adding new code to system components. Once I found the offending code, It was pretty easy to deduce by sight that the code would fail under low disk, low memory and also fail in the case of a corrupted/zero length/missing file.
I probably spent a further hour or two fixing the code up and before releasing it, I wanted to test under low disk. I mapped the emulator’s C: drive to a USB pen drive and filled that drive with a dummy file which was just shy of the full capacity.
I then spent the rest of the day raising bugs against other components which stopped the emulator from loading in the OOD state.
Now you may ask what the value is in OOM and OOD testing now that mobile devices are packed with oodles of RAM and disk. And that’s a fair question. Aside from OOM and OOD still being a fairly common occurrence on mobile, the other answer is that is that it’s fairly easy to test OOM and OOD and code which deals with those conditions reliably is often better equipped to deal with any sort of failure.
This sort of thing is not very glamorous, but distinguishes* software engineering from hobby programming. As a core skill, exception safety and writing atom/transaction oriented code applies to anything from embedded code to the integrity of high bandwidth web back ends.
An astonishing amount of time is spent on phone projects trying to track down ‘mysterious’ unreproducible problems which turn out to be something similar to the above.
Just remember kids : Code that ‘mostly works’ is worse than code that doesn’t work at all.
Google is one of the best tools for a developer – particularly on mobile where APIs behave so erratically across devices. You can save an awful lot of time by searching for problems that other people have already encountered and solved (worked around or gave up).
I’m doing a bit of work on Java ME and Qt C++ at the moment and one thing that really struck me was how much easier it is to find example code, eratas and forum troubleshooting for Qt APIs.
Java APIs have fairly simple verb and noun naming scheme so you end up with very English “Object” and “Connector”, where as with Qt, all classes are prefixed with a ‘Q’.
Words beginning with anything other than ‘Qu’ are very rare in English (see here for a list of exceptions) so a search for QObject leads directly to the TrollTech site.
Forget semantic web – just come up with obscure prefixes for everything.
After setting up view outside my house like a creepy stalker, the Google street view of London is a wee bit unsettling. Still I didn’t stop me spending lunchtime ‘driving’ around looking for people I know.
The face bluring algorithm made me chuckle. It doesn’t seem to work that well on profiles/through glass but managed to scrub all instances of Mike Myers’ the Love guru logo. See picture below for a pretty clear photo of the passenger.
Ok, so it took a long time – but I always thought that Mavis Beacon (of teaches typing fame) was a real person, and an exemplar of the American dream. Her photo, -which adorned the software box- always had the confidence of a professional who had worked hard to crash the glass ceiling of prejudice in a white male dominated industry, going on to set up her own business. (Ok I was only 10 years old when it was first released).
From Wikipedia:
“Mavis Beacon” is not a real person. The original photo of Mavis Beacon was of a retired Caribbean-born fashion model named Renee Lesperance who was discovered in 1985 by Les Crane, the former talk-show host, while he shopped at Saks Fifth Avenue in Beverly Hills. Crane, who was then a partner in Software Toolworks, invented the name. Her first name was taken from Mavis Staples, lead vocalist for the Staple Singers, and from beacon, as in a light to guide the way.
In this article, I talk about the problems of wrapping asynchronous function to make them look synchronous. I first focus on the asynchronous APIs in Symbian OS and how synchronous waiting can be implement, and then discuss how Qt(TrollTech) have solved the same problem.
(This is still a bit rough, so I may make a few changes) Read the rest of this entry »
Just spotted that ‘Crayon physics’ has been ported to the iPhone. I’d be interested in how well it works with a finger.
In case you haven’t seen it. It’’s a game in which you have to get a ball from one platform to another by drawing 2D shapes which ‘come alive’ – obeying the laws of gravity. For example, if you draw a closed roundish shape with your finger at the top of the screen, it becomes a heavy boulder which falls to the ground, being deflected by anything in its path.
See here:
Some time ago I introduced the PC version of the app to a customer (a handset manufacturer) and suggested that it would make an excellent product differentiator if they bundled it exclusively with their soon to be released touch phone.
At the time, the word differentiation was on just about every power point deck with big companies craving for original ideas, encouraging “blue sky thinking outside of the box” (to use Ian Pegler speak).
Anyway, the idea was not taken up, but I thought it at least interesting to document the reasons why I think this game should have been snapped up for ROM:
It’s playful – you can waste some time at the doctor’s waiting room without really caring too much if you have to put the game down (a bit like snakes)
It has a viral quality – it’s the sort of game you want to show your friends
It offers design/UI cachet so craved by some of the handset manufacturers
It’s 2D – 3D was one of the worst things to happen to game play
I wonder if it could work on the Nokia5800 touch. I’m not sure if the screen is big enough for Crayon Physics to really work, but certainly the stylus is the perfect tool for drawing.
Box2D
Incidentally, a lot of these recent physics toys are based on the excellent Box2d algorithms and library. Box2D was originally a C++ API for simulating constraints in a 2D plane. It’s fast and visually pleasing rather than an accurate physics simulator.
It has been ported to Flash and Nintendo DS, and you can see some of the demos.here.
And for those who are interested, a Symbian/S60 port has been attempted here.
Google have brought their useless ad technology to YouTube, and it’s less than subtle. On viewing some end of the world hysteria relating to the LHC (Large hadron collider), I was presented with the following ad:
I wonder if the Emergency Survival Kit includes a gravity wave proof jacket.
I found this LHC video informative.
In cell biology, a difference between prokaryotic cells (bacteria), and eukariotic cells (plants an animals) is that eukaryotic cells are compartmentalised into structures known as organelles.
The compartmentalisation allows eukayotic cells to participate in many more complex metabolic pathways than the prokaryotes, because some reactions require acidic conditions, some require particularly high concentrations of a compound which may be toxic to the cell as a whole.
One of the most fascinating of these membrane bound compartments is the mitochondria – commonly referred to as the powerhouse for the cell. The mitochondira enable the cell to participate in aerobic respiration (oxidising glucose to make chemical energy). What’s really interesting about mitochondira is that they have their own DNA, and replicate independently of the cell (dividing as the energy needs of the cell increases).
The widely accepted theory for the origins of the mitochondria is that a bacteria, which was capable of respiration, but not able to get a good supply of glucose invaded an early animal cell. Perhaps a small fraction of animal cells which did not attack the cell gained a small advantage from the boost in chemical energy provided by the parasite – and then through natural selection, a symbiotic partnership was formed. (in the same way as nitrogen fixing bacteria invade legumes today, allowing legumes to grow in plants devoid of nitrates).
To this day, the mitochondria retain their DNA, synthesise their own proteins and carry out respiration for the cell, but have become so integrated that they cannot be called organisms and could never survive outside of the cell. However their processes are compartmentalised so as not to interfere with cell and importantly so that the thousands of other chemical reactions in the cell do no interfere with its important processes.
Single chip
Cost is the chief driver for one chip – but people often underestimate the cost of modifying and maintaining a complex platform. Software asset reuse is massively important to a big hardware company though some are slower to realise than other that software is less malleable than it seems.
It is becoming far easier for an organisation to switch hardware than software.
If you now consider the differences in hardware between a mac and a pc, all the important bits are commodities, yet the OS software and everything built on top of those APIs represents a colossal body of work.
On mobile, there are only a handful of credible 3G signalling stacks in the world, and most of them targeting a particular OS with a particular compiler.
The effort to port to a new hardware platform is not a walk in the park, but as long as the host OS supports a particular CPU (with the same endian-ness), then most of the effort is spent on verification rather than porting.
Porting a signalling stack to a general purpose OS is fraught with challenges, and poses some interesting organisational challenges when it comes to verifying the system as a whole.
In an industry with a long supply chain company semico->OS->UI->partner delivery->Phone manufacturer->Operator. The only point at which the real-time characteristics can be fully verified is at the point that the product is fully assembled.
The hardware world tends to be fairly mature when it comes to estimating Fabrication costs, Bulk order of parts, Failure rates – and cost of returns etc. A $5 or $10 BOM cost reduction over hundreds of millions of devices is well understood.
The long term cost of being tied to a particular software platform however, is very hard to enumerate.
Software though in it’s malleable form, provides a canvas for infinite creativity which allows many solutions to be attempted before it is released and sets like plaster of paris.
One way of hosting a big s/w assets such as a signalling stack is to introduce an OS emulation layer/personality layer. Essentially this what POSIX does by presenting an arbitrary OS with UNIX like services. An RTOS personality layer provides a library of mutexes, threads etc. which emulate an incumbent RTOS such as nucleus. So long as the target compiler has no problems with the code, and the OS can provide the same or better real time guarantees as the OS it’s faking, then the single chip port can be realised.
The disadvantage of personality layer is that you need one for each OS, and each has to be carefully verified.
It’s also worth bearing in mind that real time programming/embedded programming is a distinct engineering discipline – often clouded by the fact that many developers who have written mobile apps classify themselves as embedded programmers. Which means that the skill set required to do the full integration is often is short supply.
Here are some examples of typical layouts:
- The first Symbian phone which I worked on had RTOS and Symbian running on a single chip (back in 1999). Series 40 devices tend to run everything on the RTOS, but “open” OSes rarely attempt to run signaling stacks.
- The iPhone is 2 chip. It has a 2.5g daughter board which could be switched for 3G without having to modify the main ARM11 CPU and peripherals.
- Freescale’s MXC reference design is single chip, but runs most of the signalling stack on a starcore DSP.
When you start adding real time multimedia, virtual memory paging (by nature indeterministic) and a product which is assembled from many many partner deliveries, it takes an enormous amount of effort to verify the integrity of an entire system.
In summary. One chip, one OS is not a synonym for “best solution”. I think the real skill is to consider when strong compartmentalisation is beneficial, and when it is an overhead. (without intending to stir up a debate about micro verses monolithic kernel designs….hows that going by the way?)
I frequently write test code which executes in a “text shell” test harness. This is the Symbian equivalent of running from the dos command prompt.
Aside from enabling the essential automation of unit and regression tests, a key advantage of a text shell test harness is that the emulator will boot in a few seconds rather than the excruciating minutes required for the full S60 environment. In the text shell, the edit->build->run cycle frequency is vastly improved when compared with running a full UI app.
For the emulator, Symbian has a fairly convoluted way of supporting this use case and I always forget what the correct options are. So I’ve documented them here for Symbian 9.x.
