Saturday, October 20, 2007

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

Tote

4 comments:

Anonymous said...

In the world of Windows, OLE and OLE 2 (later a bit extended and rebranded as ActiveX) solve this problem to the point that any office-like application is expected to produce the object embeddable to anywhere.

Nokia's ECOM is not quite OLE2, but can be used for similar purposes and can be extended to do a bit more. What I think is crucial for the efficient embedding is commonality, standardization and Nokia-provided pack of applications supporting the approach. It might be too much of effort to implement custom OLE-like approach for any single application, it would be much easier is common stuff could be shared and reused.

Gábor Török said...

First, I'm sure you know that ECOM is not Nokia's, but Symbian's. :) Nevertheless, I agree with you that there should be a common, efficient solution for this problem. I'm not sure, though, who should provide that solution: Nokia or Symbian. Of course, I'm aware of that applications are written by phone manufacturers (i.e. not Symbian), however, I'd like to see Symbian in a leading role to provide at least the framework for a generic solution that could be used on other platforms than S60, like UIQ and MOAP. That could be based on ECOM, too, but please also note that currently embedding has nothing to do with (ECOM) plug-ins.

Anonymous said...

I meant Nokia's offer of ECOM, though currently it's equivalent to the Symbian's ECOM :)

I am not sure if Symbian is able to provide a foundation for such a UI-dependent dependent and mandatory for many apps thing as embedding. It is more for a final platform manufacturer. Currently ECOM indeed has nothing to do with embedding. However, it has a potential for becoming what Windows COM became for OLE2 - the low level foundation that works across the whole system.

Daniel said...

Hi! I found this article very interesting. Do you have some new input on how to make an application that shows a map with POI, and has the possibility to view mediafiles for a specifik POI? What I´ve read the Map and Navigation API was dropped. So, would you recommend to wait for JSR-293 (me doing Java), use a Browser Control as you mention, or use web widget? An answer would mean a lot for me.