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.
I’m doing some work with location based services at the moment. A colleague told me of some of the problems they had had with the software. One was related to the SkyHook system. This is the system that Apple used and helps to improve the speed of acquiring a fix by mapping the location of Wifi hotspots and cell towers.
the app would for the most part correctly report the position but during field testing- say when heading down the M25 - it would occasionally report the location as being back in central London. This erratic behaviour was a bit of a puzzle to the the engineers until they discovered that National Express have been installing Wifi access points on their buses.
Much as I adore Wilhelm spotting, it’s not as fun now that it’s so widely known about outside the film industry.
If you don’t know what I’m talking about, then you probably wondered why some people at the cinema laugh seemingly inappropriately at horrific explosions and falls.
The Wilhelm scream is a sound effect regarded with affection by sound engineers and directors alike, it’s the calling card of someone who knows their movie heritage and has been discretely slipped into 100s of Hollywood films. (See link above for a compilation).
After watching Breaking Bad Season 1, we might have alternative : The Dean Scream.(Youtube).
ffmpeg is an extraordinary program, it seems to deal with just about any video format I care to throw at it.
If you are not one of the enlightened, ffmpeg is a command line tool which supports transcoding of content from one format to another. Many of the $10 video converters on-line are simply rips offs of the ffmpeg code base with a crap UI on top. (see the mmfpeg hall of shame for uncredited use)
As with any command line tool, the complexity of the arguments kill it for most. But generally you will be encoding for a particular device or standard format and so a quick google will give you the options you need.
I’ve been using ffmpeg to convert video content (including iplayer films) for Sony Walkman NWZ-A815 (which is very particular about the video size and bitrate).
I can’t even remember what the options do, but I wrote a python script to transcode all videos in a directory and spits out about 290mb per hour of video (assumes ffmpeg.exe is in your path).
import glob
import os
fileNames = glob.glob("*.*")
print(fileNames)
commandTemplate = "ffmpeg.exe -i \"%FILENAME%\" -b 567k -s 320x240 " + \
"-vcodec mpeg4 -ab 220k -ar 44100 -ac 2 -acodec libfaac \"%FILENAME%_TRANSCODED.mp4\""
for file in fileNames:
if not "TRANSCODED" in file:
command = commandTemplate.replace("%FILENAME%", file)
print("Executing: ",command);
os.system(command)
Booking Ryan Air flights. I noticed that they have a credit card/debit card charge £5 per journey per person (£20 for a trip for two). I’m sure the debit card at least used to be free.
However, I noticed that there was no charge for a Visa Electron (the sort of card you get with your griffin saver when you come of age). Some banks will allow you to have a Visa electron as well as your mastro, but you can also apply on-line for a Halifax basic account:
If you intend to do a few trips, then it’s well worth getting one. But remember that funds must be present in the account before you book (this can take 3 days).
Good blend of medicine and computing. A footballer with a known heart condition suffers a heart attack (some sort of ventricular fibrillation/tachycardia). Luckily he has been fitted with a implantable cardioverter defibrillator which kicks in at 0:15.
The defibrillator paces the heart as needed, delivering a shock which causes the heart to stop and hopefully restart with a normal rhythm.
I’ve been wrestling with some legacy Java ME code in which the author doesn’t seem to have grasped the “do or throw” pattern.
That is, a method either returns a valid object OR throws a exception. You do not need to check the return value of a method satisfying this criterion as it can never be null.
e.g:
Thread t = Thread.currentThread();
if ( t != null )
t.sleep( seconds * 1000L );
That could be simplified to just:
Thread.sleep(seconds * 1000L);
There’s something existential about code that wonders if it’s the current running thread.
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.