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.
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.
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 �
Last year, I wrote an article for the Reg about Google’s need for a mobile web platform which has Gears like functionality. There are a couple of ways of achieving this on S60, one is the Gears plug-in (a non starter on S60), develop your own browser (Firefox are doing this, and Chrome may or may not appear on mobile), or wait for the built in browser to implement the relevant HTML5 standards which allow interfacing with client side databases.
As I mentioned previously, the support for “canvas” tag in the HTML5 spec fills the need to draw arbitrary shapes, and Google demoed the potential of dropping Gears in favour of standard HTML5.0 primitives at MWC:
So all this standards love in is all coming together nicely, with the palm Pre getting in on the action. But I found it hard to find information about S60’s web browser and HTML5 support, anyone know?
Eclipse is getting silly. What started off a fairly sensible tool for Java development now appears to have been designed for no one in particular. The problem is that every plugin thinks it’s the most imporatant thing in the system and splats itself all over the place. Sure you can say it support feature X, but and the notion of a co-ordinated design, a tool which crafted for the benefit of the developer seems to have been lost. It doesn’t even look like a tool ‘for developers, made by developers’.
Exhibit 1:
Here is the result of right clicking on an “identifier”. I was trying to look up a header file.
Woah! The list scrolls up and down on my laptop screen. And now with the Qt plugins, I now have around 50 tabs to choose from (all of which seem to jump around when i press them).
Ok, there are quite a few context sensitve options that belong in that list, but “Preferences” – that’s a global project option which doesn’t even refer to the file i’m editing, let alone the highlighted identifier, and why oh why is “Run Leavescan” there?.
I’ve made my developer.symbian.com Wiki search plug-in available on mycroft.
This plug-in adds an item to your Firefox3 or IE7 search bar, allowing you to search for FAQs, code clinics and other resources on developer.symbian.com.
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.
So, a year on and the first Android phone is on its way in the form of the G1 launched on T-Mobile.
I was kindly invited to last night’s T-Mobile’s winter showcase and got a chance to try out the G1.
Initial impressions
The hardware is solidly constructed, has a large screen and when closed offers quite an attractive form factor. The screen is lovely with the browser text readable at very low zoom levels – in landscape orientation, the whole width of the BBC news web site can be accommodated by the screen. The flip screen is fun to play with and seems to be able to take plenty of punishment.
The keyboard is capable and I was happy with the accuracy while tapping out short text messages.
The main thing that hit me was how amateurish the graphics design is: Basic consistency is broken. For example, some of the icons on the main home page are isometric with a shadow, and others are flat. Items on the screen appear scattered and unconstrained. The clock has the shadow heading south east where as the icons are north east. In fact it looks like a typical Linux desktop : designed by engineers. The only thing missing is eyes which follow your finger around. This is in stark contrast to the iPhone which forces icons into a regular grid and applies a consistent shadow/reflection whether you want it or not.
A good design often revolves around a set of constraints, and I had initial suspicions that the support for three different input methods represented a lack of design discipline and failure to commit to one input method. At first it appears to offer the user the best of three worlds; you can search with the keyboard, scroll around a web page with your finger, and then use the tracker ball to skip between hyperlinks. I’m sure you get used to it, but I really didn’t like all the switching and felt genuinely disoriented several times – I kept looking for the familiar back button on a Nokia or the meny button on the iPhone.
The initial Android SDK presented a very simple and fast phone like UI. And frankly I’m quite disappointed at the way it has grown to obfuscate simple tasks. I wasn’t obvious to me how to write a text message – which is criminal for a phone.
I initially thought that the scrolling of text messages across the top of the screen was a nice feature. However, I’ve found this to be undesirable with the iPhone : When I put my phone on the table, I don’t want other people to be able to see who’s texting me – particularly in meetings or when I’ve popped to the loo. The guy demoing suggested that it displays the notification even when the device is locked (though I can’t confirm).
I posed the following question to a number of the T-Mobile staff. “If I have all my music on iTunes, how do I get at least some of it onto the device”. No one could really answer. It sounds as if you must drag and drop content using USB mass storage which is not great.
The browser is capable and the despite the urge to pinch the screen with the finger and thumb (no multi touch support), the zoom buttons worked ok – the zoom is fast and responsive but still it feels cumbersome compared to the iPhone’s browser.
I briefly played with the Google apps, and they were pretty much as expected. Similar to the downloadable apps for Gmail and maps.
It’s clear that this is a mixed heritage device. As well as the Google applications, The hardware looks as if it was designed to accommodate Windows mobile, and there are elements Danger / t-mobile’s side cick. This is not surprising, since Android was originally a start up formed by ex Danger!’s Andy Rubin who oversaw the T-Mobile Sidekick device.
The sidekick was not widely available outside the US, so you may not have seen one in action.
The clash of different ideas about what the phone should be is evident in the final software but perhaps surprisingly, T-Mobile’s input seems limited. The only branding I could see was the the web’n'walk shortcut which appears on the home screen. T-Mobile have bravely let Google run with this, and according to them – they have no real influence on the apps which their users can download (ouch for potential support costs!).
Some thoughts
One of the problems with this device and launch is that no one is really sure what’s being launched. Is it just another HTC device which happens to run some Google software, or is it another signs of Google’s inevitable dominance of all our internet access points?
As a device, the only new feature it brings (aside from the gimmicky compass/street view) is the liberal 3rd party market and the promise of unlimited breadth of applications. Bootstrapping such a ‘killer feature’ is difficult – you need to create compelling devices which people will buy in volume order to attract developers and at the point of sale, if your main selling point is the openness of the platform, then you need to have compelling applications which really do generate the sales. It’s a very similar model to selling games consoles only that a games console is a very specific and unambiguous product.
Getting a phone to market with a new operating system is an enormous task, and I think the engineers are to be commended for their effort with this phone and platform. It’s a lot more stable and the performance is a lot slicker than many other platforms at a similar stage of maturity. Also with the Java/Dalvic split, I think the story for 3rd parties is a sound. Device manufacturers can change the guts of the phone by modifying the Linux c code and hack it to death to ship a device, while the Android APIs can evolve separately and can remain relatively static over time.
If the market is there, and if selling apps is made easy, then I’d be very pleased to develop for this platform – the architecture seems fairly sensible.
Conclusion
I don’t see the point of beating up on a version one phone for the lack features. In the current marketplace, I think it’s brave to launch a phone with less features and to get those features absolutely spot on. I think this is where Google have missed a trick – if they produced a mid entry phone with a less confusing UI then Android could have established itself as “S60 done right”, but instead by going for the iPhone form factor for the first device, they will inevitably draw comparison with shiny one and at least from my initial playing around G1 will come out unfavourably.
Moto have invested in VirtualLogix (real time virtualisation company) .
A lot of people are wondering why the hell anyone would want to run two OSes on a mobile device. Something that the majority of the public don’t do on a desktop, let alone a portable.
I don’t think moto are seriously going to allow the user to switch between OSes on the fly (the royalties would be crippling).
Virtualisation has been in use in mobiles for a long time. But it’s trendy right now innt.
Many 3G solutions on the market are 2 chip – that is one chip for the RTOS(e.g nucleus) and one for the Applications OS (Symbian/Ms mobile/linux).
Now obviously 2 chips are more expensive than one, and so there is a BOM cost penalty. However the effort to port the signaling stack to 3 different OSes is really astronomical.
So one solution is to to virtualise the device. That is, presenting the ARM chip to two OSes, with a Hypervisor taking care of OS context switches and message passing.
This means you can :
use the same RTOS (which has gone through type approval) with any application OS you fancy *on the same chip*
have one team responsible for the whole 3G stack delivery to all phones in an organisation (no expensive ports)
isolate and test the signaling stack as a black box. (No need to worry about mixing 3g and application threads)
Create better separation so that you can produce 3G/EDGE versions
Increase security since the RTOS can have a different memory region and is closed to 3rd party applications
Ease RT performance – you can verify RTOS deterministically since you are not tweaking priorities of *all* threads in your system each time you add a new feature.
Bear in mind that before Montavista released its Real time patches to the linux kernel, this technique was the only way of doing single chip handsets on linux.
Although it may seem wasteful, there are some organisational reasons why virtulising systems can lead to far less complex code. The ability to characterise and verify a crucial part of a system is really important. I know that in a development team of a few 100 staff, a problem which disrupts the whole system such as the multimedia team bumping up a realtime thread does not have to take out important threads in the RT telephony stack. On an integrated system, your whole organisation has to be aware of which threads are allowed to be at what priority. RT verification is not a skill that every engineer has (no, really).Since signaling stacks are usually well characterised, it’s usually possible to state that the OS will never use more than 10% CPU for example. The latency of the RTOS then determines the minimum latency of the application OS with good predictability.
One other possible reason for virtualisation is compatibility. By this I mean having the freedom to deploy a new BC breaking version of the OS, or even a completely new OS, but retain compatibility with old applications (simply by including the old OS ROM on storage). With mobiles shipping with a few GB of NAND, storage space is becoming less of an issue (a typical phone ROM is ~128MB).
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.
