Detailed preview of the XPERIA X1 with plenty of hands-on photos.
Mobile Tech Addicts has published one of the first reviews of the HTC Touch Pro (via msmobiles).
While checking out the recently released JSR 226 benchmark, JBenchmark SVG, I noticed that the Samsung Omnia was the (so far) top performer in the database. Windows Mobile handsets are a total hit-or-miss kind of a deal when it comes to J2ME support. There is half a dozen different JVM for WM and some of them are absolutely terrible.
Esmertec Jbed has been for the past year the top performer and most estable of them and has been showing up on more and more devices. Aplix JBlend is the other manufacturer favorite. It's good to see competition in this area: the wide JSR coverage that JBlend features can put pressure on Jbed to improve its support for more JSRs. The Omnia is probably the first WM handset with Mobile Service Architecture support, as evidenced by its JBenchmark profile (the full report is behind a pay wall.)
How current smartphone platforms deal with background apps
Developers and the Apple faithful are still arguing about Apple decision to block third party apps from running in the background on the iPhone. I'm going to try to offer a bit of perspective on the issue by explaining how current smartphone platforms deal with background apps.
Going by the classic definition of smartphone, both Google Android and the Blackberry JDE are arguably not smartphone platforms and feature phones with J2ME are sure as hell not one. But I am going to include them for the sake of comparison.
Palm OS
Lacks background process. Anything running "in the background" is in fact an OS interrupt handler or some other hackery. Palm OS is simply obsolete in terms of operating system design, and has been for years.
Symbian
Symbian allows full GUI background processes. When the device runs low on memory the operating system will start shutting down background processes. Additionally many of its APIs have explicit error conditions related to low memory errors and resource sharing. The operating system notifies the application when it needs to close it for memory reasons by sending the EEikCmdExit message.
Windows Mobile
Windows Mobile is similar to Symbian w.r.t. background apps. It allows full GUI applications to run in the background and uses its standard message delivery system to notify the application before closing if it runs out of memory (messages WM_HIBERNATE and WM_CLOSE).
Feature phones with J2ME
Sony Ericsson first, and recently Nokia have added background running for J2ME applications. Midlets are by nature usually very frugal on memory consumption so it works fairly well. In addition J2ME also supports termination notifications issued by the OS, so applications can save their running state on low memory conditions. That said the majority of J2ME feature phones are not from Sony Ericsson or from the high end Nokia range, so in general background running midlets are not supported.
Blackberry JDE
I am not experienced on Blackberry development, but as a platform it has supported background applications since day 1 and they are explicitly supported in the API.
Android
Android probably features the best and most balanced background application support. It has memory warning callbacks, like Symbian, and the explicit guarantee that the operating system will try its best to keep the application around, like Windows Mobile. But its defining feature is the the concept of Services: UI-less processes that run in the background and can be spawned on request by applications or by URI schemes:
A Service is a body of code that runs in the background. It can run in its own process, or in the context of another application's process, depending on its needs. Other components "bind" to a Service and invoke methods on it via remote procedure calls. An example of a Service is a media player; even when the user quits the media-selection UI, she probably still intends for her music to keep playing. A Service keeps the music going even when the UI has completed.
iPhone OS
The iPhone OS is a full Unix-like operating system, with a full blown kernel with memory protection and demand paging, running on a powerful CPU that has full support for all these features. In terms of OS design and features it leaves everything else in the dust. Which only makes the way Apple has chosen to cripple third party applications more painful to accept. The iPhone OS has full support for background applications if you are Apple. If you are not then it will kill your application the moment the user jumps out of it.
How Apple could add backround apps on the iPhone
The official reason is that background apps would kill the iPhone battery in no time, so they are not supported. But there is another way. Instead of keeping the full blown GUI of the application have the OS support the Google Android concept of Services. UI-less processes with access to certain features like the sound and network system, working under CPU and I/O quotas so they play nice to each other. They would be still under a "can be killed anytime" policy, but since they don't need to keep a GUI around they would be much easier on the RAM and CPU of the device.