This page was last modified 10:03, 15 June 2008.

From Forum Nokia Wiki

Forum Nokia employee located in Tampere, Finland.

Working as the technical lead for the Professional Support team my focus is in making sure that developers are getting the best possible service when calling on our help for solving a technical problem. I am also working on channeling developer feedback and requirements to the S60 platform.

My Blog

Lucian Tomuta's Forum Nokia Blog

• Are there any updates available for Carbide.c++ ?
  The banner above is obviously not reflecting the reality anymore. Carbide might have reached an intermediary finish line but that does not mean that it stopped running :) As you might know Carbide.c++ is able to search for software updates and when found download and install them. The process is however manual and you there are no update available notifications so the question that immediately comes to mind is: "Are there any updates available for Carbide.c++ ?" This blog post is the answer to that question. As long as everything goes well with the Yahoo! Pipes script I've put together, the Flash RSS reader below will display the latest version information for Carbide.c++'s features. Since it only looks for information about the Carbide.c++ plug-ins and does not scan all the other repositories this solution is definitely faster than a regular scan for updates from the IDE. Important note: before you start updating make sure that you read carefully the upgrade instructions from Carbide's help. The basic idea is that " ... Replacing any standard Eclipse plug-in with an updated version from a non-Nokia update site can result in Carbide.c++ no longer working as intended. ... " One thing for you to do now: bookmark this page so you can check on it every now and then. That of course unless you would prefer to use Widsets and get your notifications on the phone. If so, just click on the button below:
• Symbian preparing for a new start
  The news is hot and one needs to really take some time, let it cool down and then analyze it from all angles. But here it goes, straight from Nokia's press release: "Mobile leaders to unify the Symbian software platform and set the future of mobile free London, UK - Nokia, Sony Ericsson, Motorola and NTT DOCOMO announced today their intent to unite Symbian OS(TM), S60, UIQ and MOAP(S) to create one open mobile software platform. Together with AT&T, LG Electronics, Samsung Electronics, STMicroelectronics, Texas Instruments and Vodafone they plan to establish the Symbian Foundation to extend the appeal of this unified software platform. Membership of this non-profit Foundation will be open to all organizations. This initiative is supported by current shareholders and management of Symbian Limited, who have been actively involved in its development.  Plans for the Foundation have already received wide support from other industry leaders.   To enable the Foundation, Nokia today announced plans to acquire the remaining shares of Symbian Limited that Nokia does not already own and then contribute the Symbian and S60 software to the Foundation. Sony Ericsson and Motorola today announced their intention to contribute technology from UIQ and DOCOMO has also indicated its willingness to contribute its MOAP(S) assets. From these contributions, the Foundation will provide a unified platform with common UI framework. A full platform will be available for all Foundation members under a royalty-free license, from the Foundation's first day of operations.   Contributions from Foundation members through open collaboration will be integrated to further enhance the platform. The Foundation will make selected components available as open source at launch. It will then work to establish the most complete mobile software offering available in open source. This will be made available over the next two years and is intended to be released under Eclipse Public License (EPL) 1.0.    The Foundation's platform will build on the leading open mobile software platform, with more than 200 million phones, across 235 models, already shipped by multiple vendors and tens of thousands of third-party applications already available for Symbian OS-based devices. ..."   More info can be found in Nokia Press Releases and of course at the Symbian Foundation web site.  
• S60 SDK and tools on Windows Vista - a success story
  The following is a copy of a Discussion Board post from a thread discussing - again - the level of support of the S60 tools and SDK for the Windows Vista, or more likely the lack there of.  This thread finally made me curious enough to try installing the SDK on Windows Vista. Here are my results: OS: Vista Home Premium + SP1 SDK: S60 3rd FP1 IDE: Carbide.C++ 1.3 Pro (eval) Tools: Active Perl 5.6.1 build 635, GCCE 2005-q1c 1) Install Carbide setup.exe -> next -> ... the usual ... -> finish. To be noted that the installation is done in C:\Apps rather than the protect c:\Program Files\... 2) From the html page displayed by Carbide at the end of the install download Active Perl Since Perl was already reported to be tricky (and since it will try to touch at least the %PATH% env. variable) I've made sure to run the setup.exe in Administrator mode. All went just fine. 3) SDK download Again, the SDK installs files under c:\Program Files\... so Admin mode is preferable. All went swell until I was prompted to ... 4) Install GCCE Since I was not sure if the installation is to be run in Admin mode I've decided not to perform the install at that time. Once I've answered NO to the prompt the SDK install finalized with OK status. Now, the GCCE installer can be found under %EPOCROOT%Epoc32\tools\distrib so the next step is to start the install from there with Admin rights. And all goes well. 5) Quick inspection of the tools (like in How do I start programming for Symbian OS?) and environment settings. Since all seems fine is time for ...   6) Carbide.c++ test The usual restart after detecting the SDKs. Then example project import and build for emulator. All seems ok except for some warnings about non-existing pipe, I guess they are safe to ignore. Unfortunately here I pause with the good news since I find that the emulator fails to start somewhere in the area of font loading. Resuming the good news flow the GCCE build worked just fine and I ended up having a signed SIS file. My conclusions: - Installing the environment on Vista is not impossible and, at least when it comes to the actual install sequences it does not require any extra effort, maybe just a bit of patience and environment awareness - Since there are some known problems with the emulator and certain hardware drivers I cannot blame Vista for the emulator problems. Not yet anyway :) - Despite of the relative success of the test, and even after I'll solve the emulator issue, I still do not see Vista as the OS of choice for Symbian development. If anything I'll try to get back to XP which is more stable, less bloated and more importantly fully supported by the tools. Update: Ok, solved the emulator problem too. It was the much debated "FAULT: Exception 0x10000000" problem, with the fix being a change on Vista's Data Execution Protection (DEP) settings. So, now I have a fully working environment. The next task will be to delete it, but that can wait until tomorrow. ;)       Well, I hope someone will find this useful.   
• Are you ready for more ... drives?
  It has become a reflex for Symbian developers to think of the available drives as being at best four: Z: the ROM drive where the firmware resides C: the internal flash memory drive (aka. phone memory) D: the RAM mapped drive used as a temporary fast access file cache E: the mass storage drive, usually a removable memory card but on some devices replaced by an internal flash drive or even HDD. Out of the four drives two are usually ignored, one for being read-only and the other one for being volatile. So the developers are focusing on the C: and E: drives, the ones used for storing application's files, the ones where the user stores the mp3 collection that the application needs to scan for. The N96 phone was announced some long time ago but I have not seen many comments regarding the fact that this is the first phone to have both internal mass storage drive (16GB flash) and support for removable SD cards (up to 8GB). Good news for the end-user but how is this feature seen from the developer perspective? Is your application ready to handle one more drive? But wait, there's more. N96 is a S60 3rd Edition phone, supporting Feature Pack 2. That means it supports another nice but rather ignored feature that this platform release brings: Remote drives, the network drives based on the WebDav protocol. More drives for your applications to handle. So, how should an application handle all these drives? Well, to start with, one should simply stop assuming and start querying. How many drives does the device have? What type of drives are they? Can I use them? The answer to all this question is dynamic and so should be the code that handles it. Remove all the hardcoded paths, all predefined drive enumerations. The APIs needed for adding support for multiple drives to your application are now available as a dedicated SDK plug-in. Documentation and example application are included so … Happy coding! ;)
• S60 SDK API Plug-ins
  The S60 SDK API Plug-ins have been updated today. One change affecting all the plug-in versions regards the click-through Limited License Agreement (LLA), updated to reflect developer's concerns about the use of the provided APIs in 3rd party projects, both closed and open source. The LLA template can be viewed online (also included in each package) and one of the Discussion Boards threads discussing it, and the need for change can be found here. The plug-in targeting the S60 3rd Edition SDK, supporting Feature Pack 2, is now in its "final release" version. One of the big changes in the package is that the Audio Proxy Server (APS) is deprecated and while the old releases are expected to be still fully functional developers are encouraged to use the new VoIP Audio Service API in their projects. The VoIP Audio Service API as well as the Call Audio Control API are also available for S60 3rd Edition SDK, supporting Feature Pack 1, therefore the corresponding plug-in has been also updated. I am sure VoIP applications developers will find these two APIs quite interesting. Should you find any of the APIs useful do take them into use but remember that there is no binary compatibility promise for these non-SDK APIs. If you still need access to features which are not accessible with the SDK or with APIs from these plug-ins you can still use the S60 API Partnering process and request access to the needed features.  
• Leo Laporte knows the truth about S60 ?
  I've hear it so many times that I surprise myself for not believing it by now. Bashing S60 is by now the most popular sport, at least until the Olympic Games are started in Beijing. S60 is said to be difficult to learn (when compared to the Finnish language), difficult to understand (compared to the string theory) and definitely uglier than Miss South Carolina. This week Leo Laporte had something to say about S60, you would not believe what he had to say in his "this Week in Tech" podcast, episode 139: 4-TWiTty. If you want to go straight to the chase forward to minute 59:50 (easier with the Nokia Podcasting application than on his web site). So, is he right?
• Feeling inspired ?
  As Ugur was making the point recently you do not need [always] the latest hottest technology or the biggest ever budget to add the wow effect to your application. Some times all you need is 50$ ... and a lot of brain. Here's another proof of that idea:    
• Platform Security and Symbian Signed
  Here's another "mind map" that I hope will help developers understand what are the implications of Platform Security on the Symbian Signed process. To me it is self-explanatory but I would happily answer any questions you might have on the topic.   Updated on 25.03.2008: Now showing some hints with regards to the signing/certification costs. This however is a complex story as the fees charged by the test houses are variable, e.g. based on the targeted market. For more details (including prices) see the wiki article on Test houses. Updated on 11.06.2008: Click the following link to download the mind map.
• What PlatSec capabilities does my application need?
  Still looking for an answer to this question? The new release of Carbide.c++ comes with the "Capability Scanner" tool, a static code scanner that will identify the APIs used in your code, map them against a database of known APIs and their capability requirements and then provide you will a balance of what you have and what else should be added. Here's a screencast demo of what the tool can do for you. As we know a static scanner cannot solve the problem completely since some of the capability requirements are dynamic and can only be determined at run time. We all know that Platform Security warning and error messages are logged in %temp%\epocwind.out when the application is run in the emulator. Now, with Carbide.c++ 1.3 you can capture those messages using the new "Epocwind.out Scanner" plug-in. More details about these new plug-ins can be found in the Carbide.c++ Help Update 21.03.2008: Here's a Known Issue about the Capability Scanner support on the S60 3rd Edition FP2 SDK. Luckily it also has a fix for the identified problem.
• An unexpected malware application
  A background note first: I wrote this post on 09.03.2008, right after ending the talk on this discussion board thread. It was visible for a few minutes but then I took it back, with the hope that I am wrong, and Jeepy/Domi will not go ahead with his plan. But he did, and now so do I. I'll have to tell you from the start that I'm going to talk about a rather nice and useful application, one that has more than a million downloads (according to its website) and which was always on my “must have” list of applications for S60 2nd Edition. Also it has to be clarified that the classification as malware is a personal opinion and that to my knowledge there is no anti-virus application that has this application on the threats list. So, which is the application and what crime is it accused off. Well, it is the FExplorer, by Dominique Hugo, and if you've read my post on "(Ab)using Symbian Signed" you know already what the crime is: devcert abuse. The application is available for download in unsigned version with a nice list of declared capabilities: PowerMgmt, ReadDeviceData, WriteDeviceData, TrustedUI, ProtServ, SwEvent, NetworkServices, LocalServices, ReadUserData, WriteUserData, Location, SurroundingsDD and UserEnvironment. I have to confess to you that I don't know any APIs that would require the use of the SurroundingsDD capability. I am curious what is Dominique's reasoning for having it there. How about Trusted UI, ProtServ, PowerMgmt? How many of these capabilities are a true requirement for the application and how many would only enable some rather nice to have feature(s)? I've modified the application's binaries so that it only uses the five user-grantable capabilities: NetworkServices, LocalServices, ReadUserData, WriteUserData and UserEnvironment. N.B. the application has the UID3/SID in the proper range for self-signed applications, 0xAxxxxxxx, and therefore in the wrong range for the capabilities used. Now I was able to self-sign it and use it on my phone. Of course there are some small issues and some minor features are not working. The application panics in some rare cases, sign that the permission denied error is not always properly handled. Or maybe it has nothing to do with that, but rather with the fact that the application is still in beta phase. So, here come the critical questions: what was so important about this application's extra features that justifies its release in unsigned version? Is it bringing that much extra value to the end-user to justify the pressure it helps create on the Symbian Signed? Combined with the effect of the other applications with similar "release" behavior this pressure is tantamount to a DoS attack. This is just an example, there are other applications guilty of the same offense. And of course there's nothing much one can do against them. Except maybe for Symbian Signed to blacklist these applications and its developers. Ok, back to present days: there was an update on the site hosting FExplorer; the sis file, still unsigned, is now available with a development range UID3, 0xE00012DF. No change in the "required" capabilities, no attempt of providing a self-signed release of the package. I for one find it difficult to accept any justification for those who are releasing these apps and for those who have made an industry out of breaking the rules. I find it even harder to understand it when it is clear that the very same application could be properly released either self-signed or through Symbian Signed for Freeware.