Symbian development - An alternative to embedding applications

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
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!

Tote