Gabor Torok's Forum Nokia Blog

MicroWeather for S60 goes Open Source

tote_b5 — Thu, 22 Jan 2009 10:23:18 +0100

I usually don't write about specific mobile software, but this time it's a bit different. You know, it's one thing that one of my colleagues, Jouni Miettunen, became a Forum Nokia Championlast time thanks to his active participation in Python for S60community. I'm really proud of him, he really deserved the honour.

But it seems that the spirit of open source software has "infected" another colleague of mine. Gabor Fetter, author of MicroPool (a bestseller in its category), MicroPinball and MicroWeather has now decided to make his last piece of software open source. I'm not going into praising MicroWeather, let it be enough that I use it daily. For more information, you can check out the official page at http://sourceforge.net/projects/microweathers60/. But you can do more than being in read-only mode: why not contribute to it? Any ideas, contribution are welcome!

I'm happy to see that we're that agile! ;-)

Tote
mobile-thoughts.blogspot.com

Static vs active application icons

tote_b5 — Fri, 18 Jul 2008 12:16:48 +0200

I found an interesting blog about mobile interaction design at Sender 11 (whatever that name means). The point of the article is that in order to make application icons more attractive and provide a better user-experience, the icons should refresh their content from time to time and show "relevant" information to the user instead of being passive and showing only static information.

I like the idea. As one of the comments says with Nokia S60s you can now build interfaces wiht live icons like these in web-run-time and create a whole menu as a widget. Well, I don't know much about widgets, but I can imagine that it would work. For example, the whole Application Shell could make use of Web run-time and show application entry points (i.e. icons) as widgets with their always-changing behavior. Even more, the idea of Active Idle could be replaced by an active Application Shell, too. Some pixels could also be saved from precious screen real-estate (e.g. unread messages) by letting the application icons show information.

What could different applications show to the user? Here's a by far incomplete list out of my mind:

Calendar: indication about events nearby
Messaging: unread messages (sms, e-mail, etc.)
Bluetooth connectivity: enabled vs disabled, transfer in progress
WLAN connectivity: enabled vs disabled, number of hotspots nearby
Maps: known (i.e. pre-recorded) locations nearby
Clock: time
Music Player: some information about tune being played (with scrolling, for example)
RSS reader: new, unread items
etc.

Could you add more?

Tote
mobile-thoughts.blogspot.com

Nokia to acquire Trolltech

tote_b5 — Mon, 28 Jan 2008 13:48:02 +0100

Of course, I read the press release from Nokia. I even noticed that my fellow FN Champion, Paul Todd, was faster than me to write about it. Never mind, I knew it in advance that I can't be faster than AAS, nor Simon Judge, either.

What comes as a surprise to me, though, that no-one has pointed out to an important aspect of this announcement: am I alone to think that this is Nokia's answer to Google OHA?

Nokia already had a mobile Linux platform, called Maemo, but with this $153M acquisition it has now joined LiMo, too. See brief comparison between LiMo and OHA here. It's interesting to see how mobile phone manufacturers are committing themselves to different "open" mobile operating systems (e.g. Nokia to Symbian/S60, Maemo, LiMo; Motorola to LiMo, OHA, Symbian/UIQ) just to find the ultimate revenue source. If there is such, since who said that multiple mobile OSes cannot happily co-exist? Anyway, for us, developers, it might easily become the ultimate hell.

Originally from mobile-thoughts.blogspot.com.

Tote

Tilt-O-Mania, also known as Nokmote

tote_b5 — Thu, 15 Nov 2007 15:09:37 +0100

Have you ever felt that your idea is stolen and "Damn, I wish I had been faster in doing it"? Now I feel exactly that way.

The first time I heard that another Nokia phone, N95, has a built-in accelerometer I started wondering why on Earth? Why on Earth is it worth for Nokia to put such a device in their phone? Has Nokia 5500 Sport (first Nokia device with built-in accelerometer) proven that it's worth making further experiments with? I haven't seen any analysis telling so, although I admit that it doesn't mean anything. Why on Earth has Nokia kept it secret that there was such a gadget in their hottest device? Is it a secret? Isn't it something that makes the device even cooler?

Then I started to think about what we could do with it? First, I thought RotateMe was a great software, I really liked the idea. But I felt something was missing. Then I found it: why not simulate joystick key presses (i.e. left, right, up, down + press) by tilting the device to the right direction? Since it's fairly easy to simulate key events in Symbian C++ just as if they had really occured, I thought it was easy to implement. The good thing in this idea that it works with existing software, no need to re-write or adapt anything: applications will not notice the difference between real keystroke and simulated.

Tilt-O-Mania

That would have been the name of my software. R.I.P. Now it's called Nokmote and it's not mine at all. :( Sorry guys behind the "sad smiley", I'm happy that you'll come out with an implementation, but I must tell you that I'm unhappy that you'll come out with it. :)

To be honest, I was always wondering why nobody had ever discovered the opportunity in writing such a software. As more and more S60 devices will come out with built-in accelerometer this feature could become such an integral part of user experience that even Nokia might want to use it. I dare to claim that even the joystick could be replaced by the accelerometer + this solution in the future. Not only could Nokia save some money by removing some existing hardware (i.e. the joystick), but they might even be able to use the new spare space for other purposes. Isn't it so cool?

And you know what? The solution is not Nokia/Symbian specific: any (mobile) device having a motion sensor could do on-screen navigation like this. Another Symbian phone, iPhone, gPhone even a laptop, though it would be funny to see a businessman tilting his computer at the airport just for the sake of navigation. :)

On the other hand, I was shocked to find that my(?) idea was not original at all. I mean not that now somebody has come out with an implementation for S60, but this idea was implemented years(!) ago on another mobile phone. You know, some of my colleagues have worked with a MyOrigo device and when I told them my idea they enlightened me that it had already been implemented. Check out this article from The Register and you'll see that such a device is already on the market. Okay, it is a not-really-famous mobile phone and perhaps it doesn't even make use of accelerometer data, but still the idea is theirs: user tilts software navigates.

Never mind, although I'm sorry to see that I can't be THE pioneer in this area, I'm happy to see that it'll be available to us soon. Good luck for writing the software!

Originally from mobile-thoughts.blogspot.com.

Tote

Android SDK is out - first impressions

tote_b5 — Tue, 13 Nov 2007 03:15:17 +0100

After watching the video about the introduction of Android for developers, I'm convinced that the new phone will generally be as useful and user-friendly as e.g. the-also-newcomer iPhone. Well, it came as no surprise to me, I'm just expecting a lot of innovation from the new player in mobile space. I don't expect that the new platform will offer as many features as traditional Symbian-powered devices and I can even dare to say that it's not going to be as stable, either ... yet. However, I'm pretty sure that they will catch up soon and offer real alternatives for users, phone manufacturers, operators, etc.

What has totally escaped my attention, though, was that the programming language for this platform would be Java. Based on the fact that it's going to be a Linux-based OS I kind of anticipated that the programming language would be C/C++. I don't know the rationale behind this decision, but it will definitely give a boost to the otherwise stagnating JME programming environment.

I wonder, though, how Google is planning to solve the infamous Java fragmantation problem for mobile phones. What is that? Well, even though Java is a very popular and platform-independent (aka portable) programming language, it's just the set of Java core services that is available on every mobile device. The presence of additional features, such as advanced mobile graphics, security, etc. depend on phone manufacturers' decision, whether it's worth adding them. Which makes Java mobile applications market very fragmanted (some features are available, some are not) and development very frustrating. You know, I have heard an example that a mobile Java game programmer had to make 100(!) variants of his game "just" to be able to distribute it to as many phones as possible.

Another thing about mobile Java development is that most mobile phones are running on another operating system than Java. In fact, Java is not an operating system at all, even though there have been attempts to make Java-based mobile platforms, see e.g. SaveJe for more details. But Symbian OS is similar to Android platform in that they both have their native platform (Symbian OS and Linux, respectively) meaning that platform features are usually available in native programming language first and then some JNI layer added on the top and there you are, it's ready for Java programmers. So far so good. However, it introduces some latency in the equation as it requires some time to write features in native environment first and wrap it in the second round. Will Android suffer from the same problem?

My regular readers already know that I was involved in S60 Browser development and it was very challenging and I really liked it. For that reason, I'm happy to see that Google chose WebKit for their mobile browser (S60 Browser is also based on this rendering engine) and in the demonstration it worked well. I was wondering which display method they would choose for web pages:

S60 approach that displays the web page in its entirety without scaling
or iPhone approach that scales down the web page to so that it fits to display dimensions, though it's hardly readable, but lets the user zoom it very conveniently (e.g. by double-tapping on screen)

They actually chose both: they first display the page without scaling and then user can scale it down for better navigation. I'm pretty sure that Nokia has their own IPR on MiniMap (i.e. the zooming interface) so that might be one of the reasons why Google didn't choose that option. However, what surprised me that they use the same visual history for page navigation as in S60 Browser.

So these are my first impressions after spending half an hour with Android after midnight. I'm really keen to hear your comments - just as usual! :)

Originally from mobile-thoughts.blogspot.com.

Tote

[Update]: I'm shocked, check this out: Dalvik: how Google routed around Sun's IP-based licensing restrictions on Java ME. It basically says that Android phones will NOT be JME-powered, but you can write JSE programs to them. With Android, Google has introduced their own VM, Dalvik, which eventually does not make use of Java bytecode, but their own Dalvik format. It's all to get rid of Sun being involved in licensing.
It's another question how good or bad will it be to the community. It means a new variant on the horizon, a VM incapable of running so-far-standard Java bytecode, thus your midlets will have to be re-compiled. I can see why Google is happy to have their own solution to this problem, but I can also see why developers would be unhappy due to that they'll have to take just another Java variant into consideration. Even if their pockets will be full with (Google's) money.

Symbian Platform Security - hacked?

tote_b5 — Sat, 27 Oct 2007 03:48:18 +0200

Well, 3:00am has already passed and I'm tired and sleepy. One thing doesn't let me sleep, though. I've just stumbled upon these articles (Exploring S60 with AllFiles and Goodbye S60 Platform Security, Hello CAPABILITIES!) and I can't believe my eyes: Platform Security hacked?!

Briefly, the solution is as follows:

Take a firmware update package (currently supported only by Nokia for their S60 phones).
Edit a well-isolated part of it, where all those capabilities (i.e. rights) are listed that a user can grant to a 3^rd party application upon installation. Remove existing capabilities, add new ones, whatever.
Flash it.

Now you have such a phone (software) that allows you to give so powerful rights to any 3^rd party application that they can do basically anything on the device. For example, your program can access DRM-protected content (you've downloaded it once and share it with others), browse other applications' secret folders, etc. You just need to

Extract a signed SIS (Symbian Installation) file
Add rights to it (whatever gives them more power)
Re-pack & sign it again
And install it
Although the Software Installer will notice that the application was not properly signed (== acquires for more capabilities than it can normally have), the user will be in such a position that he can grant those extra rights.

Actually, this is the approach that the author of the aforementioned articles followed with regards to a very popular file browser application: he added AllFiles capability to the program so that he could explore the entire file system, which he hadn't been able to do until then.

Unfortunately, I can't prove or disprove whether this solution really works, since I haven't even updated my N95's firmware yet (shame on me!). However, this guy seems to know what he was talking about and I sort of a believe him.

In any case, if what he wrote happens to be true, then I have a few questions:

Why on earth did Symbian publish such a confidential information that is useful solely for phone manufacturers? You know, the documentation of Software Installation Policy is a very internal thing, not anyone's business. You can see that it's enough if one talented person stumbles upon that documentation and uses it.
Why is a firmware package in such a format that anyone can edit it? I mean, locally on their machine. Okay, with such a low-level tool that very few people are familiar with, but it's still possible. Wouldn't it have made more sense to encrypt and sign the package so that
- it cannot be decrypted by 3^rd parties (well, easily at least)
- it gets decrypted only on the target device right before flashing?

You know, I'm not a security expert, so I might easily be suggesting a stupid thing, but if there's any chance to do it that way, I think it's definitely worth the effort.

But even if it's not viable, then why does the firmware package update the whole system including the most critical parts? You could see that one can change the software installation policy this way. Why not make a process consisting of two steps:
- User can download and flash a firmware package that updates the (vast) majority of the system, but it doesn't allow him to touch the critical parts
- Those critical parts can either NOT be updated at all or only at service points.

I just really don't know what I've expected from Platform Security, but I have a feeling that in my secret dreams I thought it was unbreakable (I know, I'm naive). Again, I'm still looking for confirmation as to whether this solution really works, but I'm afraid that I already feel the bitter taste in my mouth. You know, a system that Symbian is proud of, operators love (some developers hate:) and even competitors acknowledge shall not be attackable and even if a security hole is discovered it shall be closed quickly without any major impacts. Nevertheless, I think this problem can be solved - hopefully very easily. But as to injecting the fixed version on to old phones, it will just take another firmware update. :)

Originally from mobile-thoughts.blogspot.com

Tote

Update: another fellow Forum Nokia Champion of mine, Antony Pranata, wrote an article about the very same topic. I think it completes my post in addition to confirming that the solution works. Worth reading.

Symbian development - An alternative to embedding applications

tote_b5 — Sat, 20 Oct 2007 17:01:42 +0200

I usually don't write articles about actual Symbian development issues, but this time I think I make an exception, if you don't mind. If you don't speak "Symbianish" or simply are not interested, then please skip the rest of my post. Nevertheless, I hope that the majority of you will just keep on.

I was in London on last Sunday for Nokia Developer Day. I was invited, because I'm a Forum Nokia Champion. There was an interesting presentation about Location Based Services and some technical details were revealed as to what Nokia would come out with as part of their upcoming SDK, namely S60 3rd Edition Feature Pack 2. It's not secret that they're going publish Map and Navigation API and an important feature of that API is the ability of launching Maps application stand-alone or embedded.

If you speak Symbianish, then you should know what launching an application in embedded mode means: your application loses focus and hands it over to the embedded application so that you have no control over it as long as that application owns the focus. It's worth noting, though, that albeit your application has lost focus it's still the main (hosting in other words) application that just makes use of services provided by another application. This can be seen by having a look at the list of currently running applications, where it's the name of your application that is in the list and not the one you have embedded.

The advantage of launching an application embedded in your application is that you don't have to bother with how it works internally, you just start it up and basically rely on that it works properly. On the other hand, this way of using other applications' services has disadvantages, too: one is that you have no influence on the menu structure of the embedded application.

Why is that important? Well, a real use case that we had to implement recently is that an application 1: shall be able to show some points-of-interest (POIs) on a map and 2:
shall have its own menu structure. We were happy to hear that Map and Navigation API would be available for public use, however, launching Maps application to satisfy our first requirement would mean that we would not be able to satisfy the second.

Then I started wondering how it could be done. Since I was deeply involved in the development of S60 Browser application some time ago, I know quite a lot about the application and the ecosystem around it. For example, I knew that a new approach had been introduced as part of the "Browser-offering" ~2 years ago that allows an application developer to use a (CCoeControl-based) control in her application. That control is called Browser Control (its API is BrowserControl API) and basically it is capable of showing & handling a web page just as the built-in Browser application does. So essentially your application can have its own menu structure, whilst also being able to show a web page. It gives you more flexibility and freedom if you use this API in favor of launching Browser in embedded mode, however, it's also more complex - sometimes unnecessarily.

Finally, we reached the point of my article: wouldn't it make more sense for applications that can be embedded (since not each application can be embedded) to offer such a (CCoe)control-based solution as well? For example, if the newly announced Maps and Navigation framework published such a service, then I shouldn't be worried about how to solve my problem. But this question is more general than to narrow it down to this special use case. I think, if some architects and/or lead designers from Nokia read my article, then I suggest them to think about it.

As a last thought, you might be wondering how I'm gonna work out this problem eventually. Well, there happened to be another presentation on that very day (i.e. Sunday) about Web Widget development on S60. I'm just thinking about writing an S60 widget that makes use of Google Maps API so that everyone is happy. :)

Any comments are welcome!

Originally from mobile-thoughts.blogspot.com.

Tote

Time of competition - a peaceful summer?

tote_b5 — Thu, 26 Jul 2007 17:01:03 +0200

Summer is hot, silent and peaceful in Hungary. I can just sit back and watch/read what's happening around the world. And in mobile space, of course.

Well, it's not that silent as I expected. In the past few days I have noticed new signs of a tough competition between mobile- and consumer electronics device manufacturers, internet service providers, mobile operating systems. Let me go into the details!

Although Nokia is clearly a market leader, they have to listen carefully to users' demand. On smartphone market, for example, there's a new challenger who demands everyone's attention. There's been a lot of discussion over whether iPhone is a smartphone or not, but that's not my point now. They clearly showed people how easy to use a user interface (UI) can be (I also happen to know how an iPhone blends, but that's a different topic:). However, the UI is not everything: there must be great (and well-implemented) features in the phone, too. You know, just in order to make a phone smart - if that's Apple's intention at all. It's not obvious as the mass market (=biggest revenue) of mobile phones is NOT smartphones.

These times everyone is trying to imitate iPhone's behavior on their phone; even one of my friends has put a new "iPhone shell" on his Windows CE phone - just for the feeling's sake. :)
Other people, on the other hand, wonder if iPhone is really selling at the same pace how Apple claims to be. You know, it's just one thing, they say, how many phones Apple and AT&T could sell so far (not to mention how many have actually been activated), it's just the hype that keeps selling at this level. Sooner or later, however, everything (and everybody) will calm down and we'll see how successful Apple is. Let's see!

Another company is also trying to expand into this new area - at least new to them. It's been announced several days ago that Google invested in cellular technology. No surprise, we already knew they're interested in this technology area (i.e. mobile), too. What might be a sign of a new aggressive campaign is that Google makes the conditions to FCC for a wireless spectrum auction. You know, I pretty much sympathize with Google in this case and hope that not only will the rules change (free download of any applications, services or content), but the list of operators will be refreshed, too.

By the way, Russell Beattie is back. In case his name doesn't sound familiar to you, he's an American blogger (one of my favorites) from the Silicon Valley full of great ideas. This time he shared his opinion with us how he sees the future of Nokia S60 UI. He's not alone with the vision that Nokia will change to Linux from Symbian, what he adds, though, is that he expects (or rather suggests) Nokia to revolutionize their UI, too. Neither would be an easy change just a side-note.
On the Linux issue, it's been already told that royalty-free doesn't mean entirely free at all. There must be (lots of) people who customize Linux to the needs of manufacturers, operators, follow market demands, adds features to Linux that have never been implemented since Linux originally has not been a mobile OS. The interest of all the possible players is very fractioned, there're already several interest groups who are doing their own design, following their own desires, etc.
On the other hand, there're lots of things Symbian (Nokia, UIQ, etc.) could learn from Linux, especially from their developer community. For example, I'm not sure if you've heard about the service outage of Symbian Signed that happened recently. For example, one of my fellow Forum Nokia Champions, Antony Pranata, was in trouble due to this. There are other people, too, who are not too happy with the current situation and think Nokia and Symbian could make it better.
Finally, as to the UI revolution: I'm pretty sure that everybody at Nokia has already drawn the conclusion from iPhone's success. I bet they've even already started to design the new approach of a touch-based model from Nokia. I'm really looking forward to it. And finally, a side-note to Russell: not as if it was a trivial step for Nokia to get rid of their "old" UI design in a jiffy. The UI (believe it or not:) is one of the core features people love the most in their Nokia phone. They might interpret a radical change in the user interface in a way that would make Nokia, khmm, unhappy.

That's it for now, I'm looking forward to reading your thoughts!

Original from http://mobile-thoughts.blogspot.com.

Tote

Protecting APIs - a different approach

tote_b5 — Mon, 19 Mar 2007 13:47:43 +0100

I have been wondering lately if the current is the most optimal way of protecting APIs in the S60 (or Symbian in general) C++ SDKs. It must not come as a surprise to any programmers that there are far more features in these SDKs than what we can use with the publicly available functions. But they are usually hidden.

How? Before answering this question, some technical details. In order to use a certain feature in C++ the following two conditions must be met:

The header file including the function to be called must be publicly available in the SDK,
The component, typically a DLL and its associated LIB file, must be publicly available in the SDK.

The first condition ensures that the code compiles, the second that the link process will succeed. The most common practice that Nokia applies when they want to protect an API (i.e. not let 3rd party use it) is that they remove the header file in question. I would call it as a lazy protection as it does not protect against reverse engineering. For example, as soon as the API becomes publicly available there is nothing that can prevent a developer from making use of that functionality. Okay, Nokia clearly forbids reverse engineering in their license agreement, but there might be people who think it in a different way.

The second type of protection, let's call it hard protection, is to remove both the header and the LIB (that we import in our MMP) from the SDK so that neither compilation nor linking succeeds. Naturally, the DLL must remain in the SDK as usually it already has clients that use the provided functionality. This workaround is also applied by Nokia and Symbian alike. Sometimes they make it so that the LIB file is missing only under emulator platform (i.e. WINSCW), but not from the target platform (e.g. ARMv5). This makes it more difficult for developers to test their software - but not impossible. Since if you cannot link against a DLL statically, then you can still do it dynamically. You just need to use RLibrary class for that purpose and call the exported methods based on their ordinals. Okay, it's by far not trivial and now we're knee-deep in sensitive and confidential data, but it IS possible.

Let's just stop here for a minute to think about why Nokia (probably) follows the above-described practice! If I wanted to protect some data and not let others use it, then I would do everything in order to impede people to make use of it. Not just invent some hackish solutions that can be relatively easily bypassed, but make it really hard for others to hack. But it might not be in Nokia's interest to do so. You know, they have partners to whom they open up some - non-published, but available - APIs every now and then. And if they can choose from simply giving access to a header file OR sharing e.g. a LIB file, too, then they naturally vote for the first option. In my opinion it's much easier to do due to e.g. traceability reasons.

We have now finally reached the point where I can talk about my idea on a (probably) better way to protect APIs. You know, there's a rule of thumb in Symbian C++ programming as of the introduction of Platform Security: if you have sensitive information (I mean, data) to protect, then you're suggested to write a server and let it guard that data. This solution also enables you to smoothly control who and how can access the protected resource. I believe that Nokia has already re-factored their code according to this pattern so that all sensitive data is taken care of by various servers. These servers may then check against capabilities, secure and/or vendor IDs. Ideally, there is no sensitive data by now that is not protected by a server.

And this is the point where I ask: why not make every API public so that everyone can use it? Following from all above, security must not be a concern here, since access to sensitive data is already under control. On the other hand, developers could greatly benefit from having access to DLLs that have been hidden from them so far. You know, I'm talking about a big bunch of features that have been written by some talented developers at Nokia, Symbian, etc. and hidden unnecessarily. Why not let others make use of those features if it doesn't harm?

There's an exception, though. If the piece of information to be protected is not data, but an algorithm, for example. If it's not of big importance what data we work on, but how. Garnished possibly with some IPR issues. If this is an issue and the executing code is in a DLL (i.e. not behind a server), then we can't expect too much from Platform Security. We can assign some strong capability to the DLL so that using it would not be trivial for anyone, but we'd have no option for fine-tuned secure/vendor ID check, for example. Perhaps even capability constraints would not be sufficient, either. I think that we (err, I mean Nokia, Symbian and others) could re-use the existing approach in this case, that is, not publishing header and/or LIB files in the public SDKs. You know, I don't think we should fully get rid of the current solution, but at least suggest to use it moderately.

Wishing to read your comments!

Original from mobile-thoughts.blogspot.com.

Tote

Cost monitoring

tote_b5 — Fri, 02 Feb 2007 10:44:12 +0100

I've started wondering just recently why there is no support at all for cost monitoring on our phones? Okay, on S60 phones there are two applications where you can monitor
- how much time you've spent with speaking on the phone,
- how much data you've up/downloaded.

You've spotted that neither tells how much money you'll have to pay at the end of the month, right?

Obviously, one of the main reasons why there is no such an application on your phone is that there is no such application on the market. Neither built in your phone. Is it that simple, huh? Not really. Let's think about it how our application should work:
- it either keeps track of how much time you've spent with speaking (you called someone or someone called you while you're abroad) and also monitors how much data you've exchanged (up/download, SMS, MMS, etc.).
- or connects to your operator's site and download data from there.

Let's examine these two options in more depth:
- Keeping track of everything on client side: it makes sense to do it as most of the required features are already present. I guess, at least as I presume here that the APIs Logs and Connection Manager applications make use of are publicly available. What is missing, though, the information that could be used to figure out the actual costs. Okay, the tariff could be retrieved from various places and eventually could be typed in into our fictitious Cost Monitor application as well, but first users are usually pretty much lazy to do that, second it's not even trivial to find out which rate we should apply when. For example, how do you know what rate to apply when you're abroad? You can't expect that the user will do all these operations as it's pretty much laborious. Even I would not do that. :- Not to mention the fact that even though it's kept track of e.g. how much data you've downloaded, but I doubt that I could figure out which bearer (e.g. 3G, WLAN) I used each time. As usually we use public WLAN service free of charge or pay for it when we're there, I wouldn't like to see those figures in my calculations. And I'm sure that there are other issues as well that we would need to tackle to get a correct end result.

Briefly: it would be pretty much challenging, if not impossible, to write such an application and even if it was possible it would put a big burden on users' shoulders to manage the application.

- On the other hand, if Cost Monitor application was only a thin client that could connect to the operator's site, then we could put all the burden of implementing the calculation logic on operators' shoulders (can you imagine an operator with shoulders?:). Which, in fact, has already been implemented as operators always know it pretty well how much money they can pull out from your pocket. I guess, some of you have already found it out that there is a little problem with this approach. Not implementation-wise, but from strategic point of view. And well, the problem is not only little, but HUGE: operators will never make such a service (e.g. a Web Services API) available publicly. It's simply not in their interest as it might inspire their clients (i.e. us) to have better control over their costs.

Finally, I did not go into details as to the features of our Cost Monitor application. The obvious one would be to give visual representation of the user's costs. A non-obvious, but very useful, one would be to be notified upon reaching/approaching a pre-set limit. I'm sure that everyone can immediately see why this feature would be opposed by operators - whose help we would rely on, btw.

Looking forward to your comments!

Tote