What three issues cause the most wasted time in Development

[Nokia Ron]

What three issues cause the most wasted time when developing S60 3rd Edition applications?

Can you estimate how much the three issues you highlighted cost you in lost development time?

What should Nokia do to make things better?

Please respond to this question in this thread.

[antonypr]

For me:

1) Symbian Signed and Platform Security. There have been a lot of discussion about Symbian Signed painfulness. This blog posting from Tommi (S60 blogger) may represent most of developers here, http://blogs.s60.com/tommi/2006/10/s..._it_be_ch.html.

Symbian Signed and Platform Security are actually broader scope than S60 3rd because S60 just inherits them from Symbian.

2) Compatibility and testing. We're having more and more S60 3rd devices on the market. It seems the compatibility between them is not as promised. As a real example, Nokia recently change the key code of some keys in Nokia E61 that makes my application doesn't work any more (break in same devices with different firmware versions).

I have posted a blog posting about this at http://mobile.antonypranata.com/2006...-of-nokia-e61/.

3) Development tool. Yes, we all know that tools for Symbian OS development are not perfect. Carbide seems to be the next integrated development tool for Symbian OS. It is better, in some areas, than CodeWarrior. But still there are many areas need to be improved. Many of us are having trouble with it (just search this forum for compilation problems or on-device debugging problems in Carbide.c++).

Sorry, I couldn't give estimation lost in cost because I didn't do an exact calculation.

Antony

[Paul.Todd]

1. Lack of debug ROMS/OS Source - we spend a lot of time tracking down stuff that plain does not work or is undocumented, e.g. Setting discoverable mode on Bluetooth, MTM's cannot be uninstalled. This can slow everything down to a crawl as we have to raise a paid support request and then it has to be reproduced by Nokia tech support then a solution or work around has to be found-minimum 3 days. Alternatively, there appears to be an API but we cannot get it from our BDM so we have to spend man weeks re-enginnering a solution. Or when an API is made avaliable it is not backwardly compatible. e.g. Profile API, - so now its documented WITH AN ENTIRELY BACKWARDLY INCOMPATIBLE API, so for the MR release where all our customers are, it does not work! Whats even more annoying is that someone actually spent their time engineering a brand new solution specifically to avoid giving the old API out.

I doubt I can get metrics for this as I don't think it is baselined, but for example the mtm issue took a minimum of 4 man weeks to fix and devise a solution. It was more annoying in that it was present in the 2nd edition but was not fixed for the 3rd edition. This now blocked us from going to Symbian signed and threw out the entire project schedule.

2. Symbian Signed process.
We have to allocate one team member to deal with all the paper work, IMEIs, certificates, capability requests etc. My estimate would be he spends 75%+ of his time just filling in dev cert requests for IMEI's, submissions to the test house, handling S/S failures etc.

3. Carbide Reliability.
Carbide.C++ seems to be a very immature product. Its very good, but it cannot cope with our current system of mmp files (esp included mmp files) that codewarrior seems to have no problems with.
a) Team members need to be trained up on carbide. It would be nice if there were some documents or webinars on starting to use Carbide, explaining perspectives, views etc, how to use the debugger

4 Lack of Responsiveness
(Personal) There are lots of know issues etc documented on the forum but no one from Nokia ever comments on them. e.g. "Saying this is a known issue and was fixed in build x.xx" or "Included in technote zzzz".

What Nokia could do:
1. Make more API's easily avaliable, even through BDM's would be a start.
2. Better implement Symbian API's so that the Symbian code works on UIQ and S60 identically. Provide API's that work on current phones.
3. Improve fidelity of emulator, e.g. support for alignment exception errors, better debug output when something fails such as during application startup.
4. Debug symbols like UIQ has, so stack traces actually make sense. This would allow us to tie it to the devkit source code as well (which we do on UIQ)
5. Improved error reporting and handling. For example there are many errors generated in the carbide.c++ tasks pane that do not correspond to a line number, so you have to work through the output pane to identify the source of the problem.
6. More help from the emulator to tell you what when wrong, particlarly at start up. A -1 error with no information is not very useful. For example when reading resources, reporting an error such as "invalid value for field zzzz in resource yyyyy". "Cannot find application with uid zzzz"
7. Make issues that tech support are working on known (but not the company/person) so that it can be quickly checked to see if other people are experiencing the issue, rather than waiting for tech support to respond. Whilst the pro area has a search, it is not useful as these issues are for the most part already in the techlib. Even better, be able to set a watch on specific issues so progress gets reported back, even if you have not raised the issue but you think its relevant to what you are experiencing.
8. Improve generated code quality for GCCE releases to reduce size and improve speed. (Personal)
9. Improve emulator startup speed.
10. Reduce learning curve for API's by making them easier to understand and thus reducing the chance of mistakes when using them.
11. Clean up the SDK header files and examples so they build cleanly without any warnings so we can see where our code is throwing warnings. For example our log file is 1.86 meg.

[myohol]

I posted this message to the Carbide.c++ and CodeWarrior Tools discussion board before I was mentioned about this thread. In addition to the earlier message, I'd like to add debugger as a positive thing. Small things like the ability to actually see the descriptors content is truly great.

...
Hello all.

I wanted to share my experiences with Carbide.c++ Developer edition. I've been using it for couple of weeks now. I was not really familiar with Eclipse in advance.

Positive
- UI Tools
- Wizards
- On-device debugging (this rocks especially with 3rd edition)

Negative
- Emulator hangs while starting debugging (as other people mentioned also). I've noticed that it does not happen so often if I do not switch to any other application while the emulator is trying to start.
- IDE is trying to close emulator without success. Emulator process is killed but still the process is somehow owned by someone. Restarting debugging leads to notification that the process is already running. This can be fixed with exiting Carbide.C++ AND killing the process (including javaw) with task manager. For me this happens few times per day.
- Silly building system does "full build" even when it is totally not necessary (only a minor change to a .cpp file which is not used by any other units).
- Building can also hang (and then it's killing time again...).
- Lack of simple examples (more SDK problem). Like howto properly implement navigation between the Fine Views created with the UI design tool.
- Impossibility to create form with several tabs, AFAIK tabs are only at App level. And this is possible when writing your own resources etc.
- Unable to compile a single C++ unit(!).
- Missing SVG editior (would be nice for creating simple icons).
- WebServices -code generation not integrated with the IDE.

...to mention just few.

But still comparing Carbide.C++ to Visual Studio and Carbide.vs (which I previously used), I'd choose Carbide.C++ This is definetly correct direction (IMHO).
...

What comes to the three questions, I believe that I've already answered to the first one. But as a list here's my triplet:
- Examples
- Full build
- Limited functionality in UI designer

Lack of real-life useful simple examples in many things cause the most time. It can vary from one day to week(s). Finding out how some API works just by looking headers is time consuming activity.

Full build lengthens the cycle of debugging and fixing smallish problems. I'd say that combined with the emulators speed it takes more than half an hour per day.

Trying to figure out how to work around the limited functionality can also vary from one day to week(s). Depending how long it takes to come up with a working idea.

And finally what should Nokia do in my opinion:
- Write examples, there can't be too many
- Document the APIs better
This kind of documentation is technically correct but also totally useless:
...
IMPORT_C void CAknView::ActivateViewL ( const TVwsViewId & aViewId )

Activate any view in the product.

Calls CCoeAppUi::ActivateViewL( aViewId)

Parameters:
aViewId Identifies the view to activate.
...

- Continue making Carbide better (it is a very good start)

[bharath_hegde]

Hello ,

These are the problems we are facing:

Importing:

1)Our project takes 9 minutes to get imported. ( Code Warrior less than 2 mins)
2)For browsing through declarations and definitions a full C/C++ indexing has to be made.
However, a fresh full indexing takes 20-30 minutes. (CodeWarrior does this within 10 secs)

Performance:

1)Opening and closing the files is slower.
2)Browse through declarations and definitions are very slow.

Compiling/Pre process/Linking:

1)No option to right click a file and say compile. (each time a file is changed, the project has to be rebuilt. Not a great solution, since extra time is required for linking and creating .exe)
2)Each time the project is imported, the include paths order has to be rearranged. (note that even though paths are changed in MMP, Carbide rearranges them)
3)Is there a way to pre process a particular file?
4)Can’t create the .exe with GCCE linker. Linker exists saying that path is long. Looks like there is a work around,
That, symbian release directory can be mapped to X: and X drive can be used in the paths. But this is untidy.

Debugger:

1)Faced a strange problem. The behavior of the debugger depends upon workspace path! Initially I chose the workspace as C:/SymbianWork . I got a strange error like “-98932427432” (by the by error message is only this text). However If I change the workspace to C:/Symbian/CarbideWork , ondevice debugging works well.

2)Debugger crashes randomly while debugging. Note that here I am not trying to debug into the .dll file.

Building:

1)We have around 45 .pkg files in the project directory. While building, Carbide tries to create .sis out of all .pkg files even though it is not told do so.Hence build does not get through. However there seems to be a work around. I can remove the createsis command from the project properties
and build will pass.( even here .pkg files will be processed, but errors are ignored)

Misc:

1)When the project files are updated from the Perforce, Carbide does not recognize that files are changed. Hence each time a file is updated from
Perforce, project has to be cleaned and built again.

[mgroeber9110]

My personal top-three list for my current project would be this (this changes over time, depending on the features used and the experience of the developer...):

1. Inaccurate documentation - cases where a certain part of current documentation (e.g. from the latest SDK) describes an API in a way that is clearly inconsistent with real behaviour (such as audio callbacks or required capabilities), or leaves out an important warning. Finding the issue in the FAQ or on a Forum after I have already debugged it is no solution. I would put that at about 10% of total development effort...

2. Remaining emulator/device differences - debugging on the device is still an order of magnitude more difficult than debugging on the emulator, so obviously any behaviour difference is *bad*. Accounts for perhaps another 10-20% of development time; with less experienced developers this can easily be more, because people tend to look for bugs in many other places (mainly their own code) first.

Top of the list for me would be...

• stack checking (especially as default stacks are relatively small, compared to some bread-and-butter classes such as TFileName, and can be easily forgotten about...)
• directory layout (especially binary and "z" drive locations)
• audio behaviour
• alignment (only when porting existing code bases)
• problems around writable static data in DLLs, especially has we have recently seen (unconfirmed) incidences with GCCE where code with missing "const" declarations compiles fine, but breaks only at run time

3. Symbian Signed "artifacts" - by this I don't mean the process as it looks on paper, but ts real-world application. In this first 3rd Edition project it would again be 20% of development time (admittedly with relatively complex Capability requirements):

• communications overhead in co-ordinating testing, payment, contract signatures - compared to the effort of developing the software itself in a small team, this suddenly means juggling a lot more balls, but on the other hand is still too closely tied to the technical details to be handled (or at least closely watched) by anyone but an experienced developer.
• evangelizing about the Symbian Signed process with partners, customers and in-house sales: "we have tested your software, and it looks ready, why can't we ship it???" - debugging installation failures with external testers, explaining about certificate validity, why the new phone cannot install the software without an update to the developer certificate etc.
• teething troubles of the process: problems with incorrect ACS certificates - inefficiencies of the Symbian Signed website, e.g. being told of incorrect UIDs or other submission failures only after filling in all the other screens, and even then only one-by-one - lack of experience in all sides involved about "streamlining" the process (still a lot of "pulling teeth" to get at straightforward, but valuable information...)
• "unexpected" demands on the design and build process: submitting results of the same build multiple times if embedded SIS files are used - mixing Protected and Unprotected UIDs in several places, depending on the signing status of the application - additional test criteria beyond Symbian Signed if manufacturer-approved capabilities are needed, which impact basic user experience choices

[iti_jha]

I think these three are the major issues that are wasting hell lot of time while development in 3rd edition:
1)Signing of the application.There should be proper documentation for this and proper guidlines of the procedures to be followed should be given
2)Most of the API's and Classes are missing so while porting the application from 2nd edition to 3rd edition its wasting lot of time
2)For creating SVG icons and scaling of UI, proper documentation and examples are not provided.

REgards,
Iti Jha

[jimgilmour1]

Hi,
So I am not into $,£ Euro etc, but I am quick,clean use.
1. S60 Symbian Emulators are SO SLOW. S60 3rd ED FP1, well I documented some testing in emulator and I suggested dont count emulator frozen/hung for 120 seconds.
I came from J2ME which was Sun Wireless Toolkit, Version 2.5 latest toolkit has lots of extra new Multimedia JSR's. Takes about 30 seconds to start. Thats four times as fast! to just start the emulator. Just look at Carbide.J 1.5 another 90 to 120 seconds boot. Surely Nokia 6230i emulator was the best ever for accuracy of emulation and comparable speed.

2. Single step debug. Carbide Developer is now single stepping on device debug for GCCE. Carbide J 1.5 is just about useable for single step but its SLOW. The real winner is NetBeans 4.1 for java and superb for single step and when I put .jar on Nokia E61 it works just the same.

3. Documentation. Really good example here Multi media player Streams fine on Nokia E61, but who out there knows that the Real player has advanced setting for through put on WLAN, and UTMS 3G hidden in second level below the Access point. This is because there is not documentation.

3a) Api error documentation. Famous Error in class Player.Manager.prefetch whilst streaming is code -45. "Permission denied when attempting operation
". Now this only happens in J2ME MIDP, AND S60 3rd Ed any version and only when you use RTSP:// from a stream closer that 9000km away!.
The prefetch operation carries out lots of operations, which one why do I need to create a Darwin Streaming server to debug this problem.

3b) I have of course been very vocal about documentation, most amusingly I said that several features were missing in Carbide Developer. Lots of discussion with the writers of Carbide Developer resulted with my embarrasement as all the features were in the new release the problem was the Help search index engine did not index in alphabetical order!. Hence I could not find the functions.
The correct setup of Help index, needs a document on how best to set up your help search options. Yes. Help on Help.

Summary
--------
So my cost and measure is in wasted hours searching for a setting or flag which should have been documented. s60 C++ is much slower that J2ME because the documenation is out of date or plain wrong!. That why I prefer Java J2ME.

I strongly agree with other posters in this thread that if something changes so the the N80 and N73 S60 3rd edition devices and the Nokia E61 and Nokia E62 devices are different this should have been CLEARLY documented

Thanks,
Jim

[sysctl]

• Multiple issues with the emulator were already pointed out, just one more example from me: default configuration with Winsock rather than real Symbian IP stack.
• Debugging takes a lot of time without the support of ODD in free tools. I maybe in minority, but it is still a bummer.
• And last but not least, DOCUMENTATION. Incomplete, inconsistent, lack of cross-referencing.

[zdenko]

1. Signing - Developer certificate has limited set of capabilities
2. Decent development tool. I have used MS VS/MSDN lib for years, when switched to Symbian realized the real quality of MSDN Lib
3. Documentation

[navjotsingh1979]

Issues that face on OS 9 are

1. Emulator speed very less.
2. Finding capabilities for APIs , gettings them in developer certificate and finally getting symbian signed.
3. A lot lot of APIs to learn in Symbian C++ as compared to J2ME , J2ME architecture is very simple and easy , although very less things can be done in J2ME .
4. If OS 9.0 applications for release must must be symbian signed , when why to pay twice , one for devbeloper certificate with advanced capabilities and then for symbian signing process.


A few more headaches i face on symbian , not in my mind now !


Regards
NEo'

[xorrox]

Problems:

1. Error Reporting and Reporting
When due to natural factors, your sheer incompetence, or both you err - the OS lets you know pronto by a panic.

Only problem the panic code gets you nowhere in terms of discovering the cause of the problem.

2. Simulation Tools
The difference in terms of behavior between the simulator and device causes much pain and suffering.

Having the code go through MWCC for the simulator and GCC is also a big hurdle to start.

3. Obscure OS API in general and UI API in particular.
Finding your way around the Symbian gazillion classes is difficult. Without proper documentation is even harder. With often-misleading often omitting documentation, its more often than not damn difficult. And lets not forget helpful examples, i.e. ones that work.

HTTP Engine (now revised thanks the lord) is one example that did not work as it should.

Cost:
Overall, IMHO, I estimate that the cost of developing a Symbian C++ application is around 4 times higher than developing for J2ME devices, including BlackBerry. Further more, even among C/C++ devices, such as PalmOS-based and BREW the cost is more than twice the time.

PalmOS isn't the best platform, design-wise (though I think its better than Symbian), but the SDK comes with gazillion examples, well documented SDK, free guides, first class simulator/emulator and the OS lets you know what's wrong before terminating your application.

3 Possible Solutions:
1. Error Handling and Reporting
I don't see a reason why error reporting should be so limited. Why can't the OS versions log useful debug information?

2. Reliable Simulator Tools
More reliable and above all faster simulator tools could make life much easier. Right now loading the simulator takes a long time and even so it is often not reliable in simulating device behavior, or worse, introducing new problems - ones that do not show up on the device.

Why can't I have a full-fledged N73 simulator that really works?

3. Documentation.
Given the advances and rise in popularity of web applications such as Wikipedia I see no reason why content similar to Microsoft's MSDN2 wiki can't be available to Symbian developers. I would gladly share my "pearls of wisdom" with those who wish.

The doxygen-generated content is limited, often missing, misleading, or omitting import examples.

And yes, finally I wish there was a cookbook recipe/template for commonly used code, such as lists, dialogs, etc.

[essoess5705]

1) Obscure, lacking, plain wrong and useless ("Executes the command", "Runs" and other such meaningless method summaries) documentation.
2) Lack of a good IDE. Carbide.C++ is a step in the right direction, but lots of work is still needed. CoreWarrior is just horrible.
3) Bad error reporting and debugging support. The same "Panic? Good luck finding out what caused it!" issue that was reported here already. Detailed logging or at least some detailed error messages could be useful.

[magnez]

1. Building - The time it spends making the dependency information is forever. Also the fact that RVCT and WINSCW doesn't support incremental linking AFAIK. (I got 1500+ .cpp files to link each time)

Last week though, I patched my Symbian SDK and added support for using the -ND option in both the RVCT and the WINSCW compiler, and it works great - generating dependency information at the same time as it compiles, perhaps I can post the script here later...

It takes 30 minutes to link our project when compiling for ARMV5 UDEB, which makes logging statements faster than MT for on-device debugging (I can compile 20 times moving the statements around in the time it takes to link for UDEB)

~= 30 minutes/day?

2. Navigating source code - Can't use Carbide because our project is too large to compile in eclipse, also, probably because of the size of the project. Now using Visual Studio 6 for debugging and compile on command line. I have no debugging information, so I can't use the jump to declaration/definitions, which is very very handy in such a large project as ours.

Hard to estimate cost on this one ...

3. Developer certificates etc - it is a real pain to develop for Symbian 9 because of all the signing needed, also since we have loads of devices, I need to find the right devcert to sign with, or apply for a new one all the time... also the fact that you have to install the program each time to run it slows development alot, on Sym8, you could just copy the executable onto the device and run

~= 1 hr/week?

[rburgst2]

Hi

I just can repeat of what my pre-posters said (documentation, symbiansigned, developer certificates when working with external clients, ...). However, I want to stress 2 things as a summary

1. no proper IDE available for large projects (waiting for 1 min + for "go to declaration" just does not cut it). CW kind of works but has the usability of notepad
2. Emulation/Simulation: Currently we are struggling with 4 variants
a) the way the app runs on the emulator
b) the way the app runs on phone X with firmware Y1
c) the way the app runs on phone X with firmware Y2
d) the way the app runs on other phone with other firmware
This means that there is no real compability between different firmware versions/phones having the same platform. It happened to us more than once that with a new firmware version functionality ceased to work which has worked fine for older firmware versions / other phones with older firmware versions. Since the emulator performs completely different its no use at all. Debugging these kinds of problems takes usually person weeks since they can only be approached by trial and error.

Summarizing I have to agree that developing for Symbian C++ takes about 3-4 times the effort compared to doing j2me or WindowsMobile (there you can run the phone binaries in the emulator, hint hint). Clearly J2me has less capabilities therefore there are less pitfalls but in general they do a pretty good job.