Part IV: “Application”

In part I, we looked at the how the phones are constructed. Part II and part III dealt with how the parts of the phone fit together, from an abstract point of view. And how the lack of a good philosophy on constructing these phones is a very serious problem. In this part, we’ll look more closely at how the software really is fitted on top of the phone, and what the issues in general are - as well as what the limitations and possibilities are when retrofitting devices with high level library support.

But - why would anyone want to retrofit a phone with anything, other than ring- tones and new pictures and games? Why not simply choose an up to date component array, and then directly use these for all operations? Why, for example, go through the trouble of creating an OS, when you’re intent on using the same platform forever, or otherwise to a large extent scrap the existing implementations whenever you do change platform? Now that’s a good question some of us ask ourselves very often.

And the answer typically appears to be “Youtube”. Or, that as long as a specific application exists on the phone, the rest doesn’t matter, except as a selling point. For example, “fundamental improvements to GUI customization and a re-drawn static memory handling that enable object- exchange” - who cares about that?

Another reason is that lack of variety on the market (there’s only a few chip designers), has made retrofitting devices with software- optimisations necessary. This has also given rise to an entire industry of “system on chip” designs, as well as the more “flexible” DSP (digital signal processing) solutions. Simply because the requirement to support multiple formats and standards was growing.

But why bother with the extra component arrays at all, then? Why not just use atomic instructions and high clock- speeds like any PC does now? Because the main idea on mobile devices in general is “parallelism”. To get as much done at the same time, in order to save clock- cycles or processor time and power. Which means that moving certain common operations from a time- shared “multitask”, and to pre- processed data areas independent of the bus suddenly seems like an incredibly good idea. Take a look at “DMA” on any computer, for example - you program the bus to read in chunks without interruption from the storage device, and then the OS picks up the full chunk when it’s ready. Quick and efficient, right?

Unfortunately, translating that theory to a mobile device is less successful. Since when a device performs more complex operations, with more varied instruction sets at the same time - any type of hardware- support runs into trouble, sooner or later. This is the case for even the most strict format and instruction set - simply because the memory- transport operations involved will incur overheads compared to the ideal and theoretical scenario. It’s also a problem that an energy- drain based on a fixed decoding process, for example, will rarely be as effective as an opportunistic variable software- algoritm. In addition, it’s not like the hardware solution doesn’t use any power on it’s own. Something that put together defeats the point of attempting to save power through direct hardware- support for even the most common tasks - such as mp3 playback or certain hardware- accelerated video formats.

But splitting functionality in this way is nevertheless chosen. Because with few clock- cycles to go on on a mobile phone chip, this was the only way to have acceptable response- times (though syncronisation issues certainly exist - popping sound, bad quality, noise - typical problems). Externalising certain instruction sets also would give the developer of that technology some “security” - as well as give the OS manufacturer the possibility to provide the specifications and the interface - and then just provide these to any 3rd party.

And this setup has been kept, with the system- on- chip designs, even though the parts of these chips now come in generic versions with programmable data- areas.

Where, then, does RISC (reduced instruction set computer) fit in this backwards summary? This is the other approach to increasing parallel processing, which, due to lack of small and flexible enough chipsets, have never taken off (even if it has been used successfully in fairly complex commercial platforms, for example PlayStation One and 2). Because in order to use a RISC system effectively - so it can save clock- cycles - the system needs to perform many similar instructions repeatedly at the OS kernel level, as well as be fundamentally based on parallelism. …!

In other words, we’ve just found the perfect use for a risc- system. A mobile phone or a pda platform, where the point is to save clock- cycles while avoiding syncronisation issues, because parallel processing is the fundamental idea - and where you want to lower the transport- overhead on the bus, as well as increase the life- span of the battery as much as possible.

And, with a well constructed system - no more would it be necessary to scrap the phone to upgrade the voice- filter, or incur enormous overhead on post- processing algoritms. Since you would be able to exploit soft DSPs for certain tasks, and then transport that data effectively. While it would still be neceesary to develop external chips for the fundamental tasks such as voice- recording or display- buffers and screens, and so on..

So - why don’t we have programmable risc- systems and a blooming multiplatform operating system industry in motion already? That is, I suppose, a good question.

—

The practical solution that was chosen, was to fit certain functionality to external chips where that would be useful (such as voice- processing, noise filters), and then employ risc- technology to the memory- transport areas. What we’ve seen mostly, however, is a generic implementation of close to atomic operations, and collections of often performed instructions that are not necessarily tailored to the tasks the device is supposed to perform. So, while increasing the amount of instructions processed each clock- cycle by large amounts, it still remains an underused technology, in an application type that is evidently perfect for it.

This practical solution is also the reason the systems released at the present are time- shifted multitask systems that draw on processor speed, more than instruction set optimisation. And, we see that increased processor speed is the number one requirement on new devices - while it really should be quite a long way down on the list, if parallel computing was more than a funny- sounding concept. Because, as mentioned, the huge gains it’s possible to achieve in reducing the power- consumption in lesser processors, and the decreased cpu time used for any amount of processing, is well worth it.

But - no doubt it’s easier to deploy a high level (or program level) instruction set for certain technology, since this can be retrofitted to the device more easily. So Flash lite 3 will be supplied through software on the new UIQ devices, and it will be a high- level implementation using generic OS functionality to operate. Not a low- level implementation, though it might be using some instruction sets specifically tailored for generic vector- graphics. Something that of course would make it suitable for deployment on all UIQ3 devices, and so on. As well as exploit the architecture that has been there for some time. But executing the code will not be nearly as efficient as it could’ve been.

Cost efficiency also has something to do with this - it’s much cheaper to fix and expand on the platform independent of the phone construction and market deployment process. So programming a solution independent of the hardware- mess is an increasingly tempting option. But the question is really one of organisation, and of applying the available technology in a strategic way.

So two directions seem to be staked out:

1. To choose functional and programmable risc- solutions that still can be expanded upon after deployment of the device. And on the other hand -

2. to choose a component platform on beforehand, and ensure the unit is obsolete before the newer (and infinitely more customer - as well as developer- friendly) software and OS is ever thought of.

..I wonder - what sort of strange compromise will we end up with in the end?

(next: Part V, “From the user’s point of view”.)

This is what Michell wrote about this:

We are not sure right now, but all points for this device to be another UIQ device (w960 successor comes to mind).

[via USEB]

Sometime ago, we told yout x-tream from P1blog had found a reference to FL3 on the first version of G900 whitepaper. Soon after, that document was removed, and there was some speculation one of the reasons of doing that was to remove such reference.

Well, now we have the new version of G900 whitepaper and this is what we can read in page 9:

Opera™ 8.0 Web browser
Opera™ 8.0 allows full HTML browsing and supports all de facto standards. It features normal or small
screen rendering as well as full screen view. Includes Flash Lite 3 support (from maintenance release 1 of the phone software).

“I am very pleased to welcome Dr. Colin Tucker as chairman of the UIQ Technology board, said Johan Sandberg, CEO at UIQ Technology. Dr. Tucker comes with over 30 years of telecommunications leadership experience and it is great for us to get such an experienced chairman”

Dr Colin Tucker has amongst a number of other positions served as Chief Technology Officer and Group Director International of Orange Plc, Executive Director to the Board of Orange Plc, Managing Director 3 UK and Deputy Chairman of Hutchison 3G and was listed by the Financial Times as one of the eight key people to know in the Telecommunications sector.

“I have always had a passion for how people use technology, said Dr Colin Tucker. This is an excellent opportunity for me to be part of the strategic development and help UIQ becoming the innovation platform enabling the best mobile user experience”

Other directors of the UIQ Technology Board are Rob Shaddock and Alain Mutricy from Motorola and Ulf Persson and Mats Lindoff from Sony Ericsson.

Further information:
Carina Dietmann
Head of Corporate Communications
+46 708 576020
carina.dietmann@uiq.com
www.uiq.com
About UIQ Technology

UIQ Technology is an independent software provider to the world’s leading mobile phone manufacturers. The company develops UIQ, an open user interface and application development platform that is flexible and customizable. UIQ Technology is currently owned by Sony Ericsson and Motorola which each have a 50% stake in UI Holdings. www.uiq.com

Via : http://uiq.com/2888_3029.html

In March we told you the good news: MyphoneExplorer, the hugely popular SE PC Suite free alternative was starting to work really good with SE UIQ3.x smartphones (and not only with SE feature phones).

Being testing the beta, i am pleased to tell you guys that more steps were taken into the full symbian support, because now, besides file explorer, sms, and contact support, there is Calendar and Tasks support! The only major thing absent is Notes.

So, congrats to Fjsoft for the amazing work, and lets hope they can soon announce full support for UIQ3, and release this new version for all users.

“Slide two: business strategy.”

http://fasttrack.uiq.com/

The UIQ Developer Fast Track events that were planned to take place in Boston (15th and 16th May) and San Francisco (19th and 20th May) have been canceled unfortunately due to a low level of registrations.
(…)
We want to create the best environment for our developer community to meet people, interact and learn lots of new fantastic news and details and hence we’re already creating an event later in the year that you won’t want to miss! Your feedback and help in creating such and event is always more than welcome at fasttrack@uiq.com.

If you have any question, don’t hesitate to contact us as fasttrack@uiq.com.

..I have a few suggestions for you.

1. Don’t hire Telecommunication business people into the company. Not even as figureheads. Paying someone a million dollars a year isn’t necessary for infinitely reinventing the importance of “subscription- based services”, “portal services”, the “pay per button- click” concept, or for making sure UIQ pays proper homage to the customisation needs of the telecom suits. Neither is it necessary for divining the whims of the telecoms in general. Yes, I know you’ve all been lamenting that you don’t have the ability to sell yourselves to the telecoms and still maintain your dignity - but what UIQ needs to do is to grow out of the idea that it’s impossible to create a good product, and then shape the market without the help of the telecoms. Specifically, a company that can lead when it comes to using available technology in a smart (bleh) way will not need to finance itself (in the short term) by crippling the functionality of an otherwise well- constructed framework before it hits the market - and so telling the general developer- community and the users UIQ wants (and needs) to charm, to f.. look elsewhere.

2. Maintain ability to release new OS- versions directly to devices. Waiting at least a year before releasing a device with the newest UIQ version is one part of what will keep UIQ in purgatory - the other is allowing it not just to be branded by phone- makers and telecoms, but crippled by their requirements of centralised release of software (a demand they cannot, and are not willing to meet at the moment, nor in the foreseeable future. Something that UIQ discovered years ago). Neither of these are strong selling points on their own, and worse than the sum of their parts together. So why maintain a collaboration that serves no one?

Does changing any of this mean concessions, or maybe “welcome consolidations of interest” on the part of shareholders and the involved telecoms? Does that mean increasing the company’s number of employees? Does it mean expanding the 3rd party development into forbidden ground such as the phone- tools, and even the optional portal- service programs? Obviously - but on the plus side, maintaining the ability to release versions directly to devices will ensure minimum platform- breaking limitations (for as long as the partnership lasts), and a modern platform and developer framework that makes use of the latest technology and the latest standards. It will also place UIQ in a position of being able to influence the direction of the underlying platform: UIQ will be able to suggest the requirements for such and such technology, and say that if we would like to see this type of animated red button in 3d on the devices, then we need this and that to effectively make it happen.

Example: using the programmable areas on the ARM architecture for native implementation of certain standards - how much is that actually used on Symbian- devices currently? Not a whole lot. What about OpenGL ES through the PowerVR instruction set? The iPhone demonstrated some possibilities - but where are the rest of the “giants” on this one?

Also, what about looking ahead for new platforms and platform- configurations in general? Instead of deploying these technologies at random in the hopes that someone will happen to use them, like the phone- manufacturers are doing now - UIQ has an option to shape the way this is done, and use it effectively. And - perhaps - actually manage to make that technology accessible, fast and supported on the devices UIQ is deployed on, to: *cough* “further enhance an outstanding product”, and [insert favourite trope here].

Deploying directly to devices will also, magically, do wonders for the licensed deals involved with certain developers of in- built software, as the companies who program them won’t be dissolved and their ledgers won’t end up on a flea- market, before their programs are actually used for more than a concept- demonstration.

3. Talk to customers.

4. Listen to customers. (And answer your mail once in a while.)

DreamSpring released a vast improvement of DreamConnect 3, featuring finger friendly navigation as introduced in Sony Ericsson’s Developer World, and feature and performance enhancements which make the already intuitive DreamConnect 3 even more user-friendly.

New to DreamConnect 3 v3.60 is gesture support, providing quicker and more convenient access to contact details. Users can simply swipe their finger or thumb either to the left or right to scroll through contact details or up and down to scroll through the contact list. On the upcoming Sony Ericsson G700 and G900, this even takes advantage of their accelerated scrolling feature.

[credits of this text go asri over at simplysymbian]

UIQ3.x´s only true VOIP solution, fring, is was choosed by UIQ Technology as May´s Application of the month.

Go to mobile-review for the full set of photos. Credits go to  gliatiotis.

[thanks to benitorios from estato for the heads up]