- English
Who am I?
I needed to boot the server for my first commercial mobile project with toggle switches and paper tape. This is more fun.
Calendar
Recently...
- New cure for what bugs you (and your code)
- Great place. Great people. Stupid story idea.
- What is your application really worth?
- Widsets turns 1,000,000
- New OpenC Topic now live
- New Start2Finish Blogs on FN
- New Start2Finish Blogs at Forum Nokia
- From the Nice Guy Department
- Series 40 5th Edition Announced
- Nokia Series 40 5th Edition Edition Announced
De-fragmentation progress?
kevinauthor | 13 September, 2006 02:20
From Forbes, here’s a developer’s experience that makes up for a lot of late nights among a lot of Nokia development teams:
S60 Developers of mobile content say that it allows them to create content for a wide variety of handsets at a reduced cost. Kansas City, Mo.-based Handmark, which aggregates content and develops and publishes wireless content, says that it ordinarily has to do more than 17 "builds" to support 20 different phones. Those are costly and time consuming. However, by using the S60 platform, it can do six "builds" to support 50 phones. That means quicker time to market and lower cost.
For as long as I’ve been working with Nokia, the various platform teams have been fighting the fragmentation monster. We all know device manufacturers like Nokia need to roll out new features and fix bugs quickly or they’re out of business. This necessity is in exact opposition to the need to deliver a stable platform on which developers can build compelling apps which, in turn, motiviate consumers to buy the newest phones. It's a constant stuggle.
So, how we doin’?
I’d like to know if your experience parallels Handmark’s. Or not. Namely, how have the efforts of the Nokia platform teams translated into your development reality as measured by two criteria:
1) For a typical software title, how many distribution packages do you produce to support Nokia devices, and how many Nokia devices do you support with those packages? Is there a big difference between your experiences in Java (on Nokia) vs. C++? Series 40 Java vs. S60 Java?
2) Do you have fewer source than distribution packages? (By using conditional compiles, etc.) If so, how many sources support your device pool? How complex is your conditionality?
As much detail as you’re willing to share about SPECIFICALLY WHERE variations in devices force your source/distribution proliferation would be much appreciated. Which missing APIs, or bugs, or variations on which devices, etc.
I’m also curious how your Nokia source/distribution/device profile compares to your experience on other platforms you support. In keeping with the “we don’t trash the other guys” ethos of these blogs, you don’t have to mention WHICH other platforms you’re talking about if you don’t want to. Howver, if you want to share that specific information, so much the better. I’ll pass it along within Nokia but will remove the competing platform name before posting your reply on the blog.
Java
, Symbian C++
|
Next |
Previous |
Comments (14) |
Trackbacks (0)
Comments
Re: De-fragmentation progress?
kevinauthor | 13/09/2006, 17:34
Michael,
Thanks for the info.
Your problems with documentation have been noted within Nokia, and I can tell you for sure that there's significant activity in the area. New hires, more funding, better processes.
What I can't tell you for sure is how quickly the activity will turn into progress. That's something you'll have to tell me.
I will try to remember to post a similar question about documentation in about six months and see how we're doin'. If I don't remember to post, feel free to ping me.
Thanks for the info.
Your problems with documentation have been noted within Nokia, and I can tell you for sure that there's significant activity in the area. New hires, more funding, better processes.
What I can't tell you for sure is how quickly the activity will turn into progress. That's something you'll have to tell me.
I will try to remember to post a similar question about documentation in about six months and see how we're doin'. If I don't remember to post, feel free to ping me.
Re: De-fragmentation progress?
Aarkham | 14/09/2006, 22:50
I can not believe that someone is surprised that anybody is unhappy about the documentation. It's true that its improving, but still it is bad (for example search for Seek in RFile, it uses an enum, TSeek, why it's not linked? ).
Respect to your question about the number of builds, I use just one for Series60 (not including v3). I'm not writing games, but it's a highly graphical application and I use a game approach. I test it regularly in ngage, 6630, 6680 and N70 and it works. I have to make a special build for the N70 thanks to its "compatibility mode" (I really couldn't believe a compatibility mode that introduces compatibility problems) for performance reasons.
The code also works in Windows, (I don`t maintain UIQ anymore) and I can tell you that the comments from Michael are real, it`s FAR EASIER to code. When I implement something, it usually works in Windows with little effort and then I have to find what's wrong in Symbian.
Thanks
Carlos
Respect to your question about the number of builds, I use just one for Series60 (not including v3). I'm not writing games, but it's a highly graphical application and I use a game approach. I test it regularly in ngage, 6630, 6680 and N70 and it works. I have to make a special build for the N70 thanks to its "compatibility mode" (I really couldn't believe a compatibility mode that introduces compatibility problems) for performance reasons.
The code also works in Windows, (I don`t maintain UIQ anymore) and I can tell you that the comments from Michael are real, it`s FAR EASIER to code. When I implement something, it usually works in Windows with little effort and then I have to find what's wrong in Symbian.
Thanks
Carlos
Re: De-fragmentation progress?
kevinauthor | 15/09/2006, 00:12
Carlos,
Thank you for the specific info. I'll pass it along.
I'd also like to extend the same offer/request to you I extended to Michael. If you provide me some contact info, you'll get a chance to talk to the people working on the issue.
Thank you for the specific info. I'll pass it along.
I'd also like to extend the same offer/request to you I extended to Michael. If you provide me some contact info, you'll get a chance to talk to the people working on the issue.
Re: De-fragmentation progress?
mgroeber9110 | 18/09/2006, 13:13
[I said this in other places, but I think it is worth repeating in this context...]
My main request for documentation would be to make the different formats converge more quickly into a coherent document. Currently, a lot of valuable information is spread out across Nokia's CAkn... reference, Symbian's own base-class reference (with a sharp break in the class hierarchies whenever one goes from Nokia to Symbian), Technical Library, Whitepapers etc.
I think that a lot of good information is "somewhere out there" on Forum Nokia and Symbian's Developer site (not even counting forums and newsgroup), but so far has practically no cross-referencing between the different parts, probably because each team insists on using its own doc toolchain.
As a result, I often find myself coming across Known Issues and FAQ documents that describe a deviation from the API docs only *after* I have thoroughly debugged the issue myself for several hours, instead of the problem being pointed out in the reference for API that has been described "for an ideal world", without mentioning the pitfalls already known in other places.
This cross-linking would be for me the single biggest improvement to the documentation as it is today.
[To add a dissenting voice, after a few years of Symbian development, I actually find it *easier* to write robust code for Symbian than for other platforms I have used, because its architecture is much more coherent, and encourages good coding practice - now if only the standard of "real life" documentation were to match this...]
My main request for documentation would be to make the different formats converge more quickly into a coherent document. Currently, a lot of valuable information is spread out across Nokia's CAkn... reference, Symbian's own base-class reference (with a sharp break in the class hierarchies whenever one goes from Nokia to Symbian), Technical Library, Whitepapers etc.
I think that a lot of good information is "somewhere out there" on Forum Nokia and Symbian's Developer site (not even counting forums and newsgroup), but so far has practically no cross-referencing between the different parts, probably because each team insists on using its own doc toolchain.
As a result, I often find myself coming across Known Issues and FAQ documents that describe a deviation from the API docs only *after* I have thoroughly debugged the issue myself for several hours, instead of the problem being pointed out in the reference for API that has been described "for an ideal world", without mentioning the pitfalls already known in other places.
This cross-linking would be for me the single biggest improvement to the documentation as it is today.
[To add a dissenting voice, after a few years of Symbian development, I actually find it *easier* to write robust code for Symbian than for other platforms I have used, because its architecture is much more coherent, and encourages good coding practice - now if only the standard of "real life" documentation were to match this...]
Re: De-fragmentation progress?
kevinauthor | 18/09/2006, 21:19
Thanks for the actionable details. Can I have someone from our documentation team follow up with you? If so, please reply with contact info -- I won't post the info to minimize your spam box.
Re: De-fragmentation progress?
kevinauthor | 14/09/2006, 20:10
Michael,
Your comments have gotten the attention of some executives within Nokia who are in a great position to make the sorts of improvements you're asking for. The Director of Technical Services and Consulting, and one of his key documentation managers, would welcome the chance to talk to you in depth about the issues you are having. One of our consultants is also interested in the problem you're having with the LowMem tool.
We'd appreciate it if you would you be willing to talk to these people. If you are, please post a comment here and LMK your email address (I'll strip the address from the post so you don't get bot-spammed.) We can finish the introductions via email.
Thank you again for the post.
Your comments have gotten the attention of some executives within Nokia who are in a great position to make the sorts of improvements you're asking for. The Director of Technical Services and Consulting, and one of his key documentation managers, would welcome the chance to talk to you in depth about the issues you are having. One of our consultants is also interested in the problem you're having with the LowMem tool.
We'd appreciate it if you would you be willing to talk to these people. If you are, please post a comment here and LMK your email address (I'll strip the address from the post so you don't get bot-spammed.) We can finish the introductions via email.
Thank you again for the post.
Re: De-fragmentation progress?
bukster1000 | 13/09/2006, 13:28
We only build MIDP 2 applications and we have 11 profiles for Nokia phones based on screen size and device type. In some cases the seperation into 2 categories probably isn't be necessary (S60.2 + S60.3 with screen size 176x208) but we do it anyway because it is realtively easy to add a new profile into our build process.
Nokia 128x128 S40.2
Nokia 128x160 S40.2
Nokia 208x208 S40.2
Nokia 128x160 S40.3
Nokia 240x320 S40.3
Nokia 176x208 S60.2
Nokia 176x208 S60.3
Nokia 208x208 S60.3
Nokia 240x320 S60.3
Nokia 320x240 S60.3
Nokia 352x416 S60.3
We have a single code base and a relatively comlicated compile process which is made easier using tools like J2ME Polish. I hope that helps. Thanks for this post.
Regards,
Jason Delport
Paxmodept
www.paxmodept.com
Nokia 128x128 S40.2
Nokia 128x160 S40.2
Nokia 208x208 S40.2
Nokia 128x160 S40.3
Nokia 240x320 S40.3
Nokia 176x208 S60.2
Nokia 176x208 S60.3
Nokia 208x208 S60.3
Nokia 240x320 S60.3
Nokia 320x240 S60.3
Nokia 352x416 S60.3
We have a single code base and a relatively comlicated compile process which is made easier using tools like J2ME Polish. I hope that helps. Thanks for this post.
Regards,
Jason Delport
Paxmodept
www.paxmodept.com
Re: De-fragmentation progress?
kevinauthor | 13/09/2006, 17:37
Hi Jason,
Thanks for the details. Single code base covers all the Nokia phones you support. Cool. That's the real key -- making sure you don't have a gazillion instances of source files you need to tweak to add features or fix bugs.
I take it from your willingness to distribute 11 profiles when you could probably distribute less that you have not had the need to get your apps Java Verified?
Thanks for the details. Single code base covers all the Nokia phones you support. Cool. That's the real key -- making sure you don't have a gazillion instances of source files you need to tweak to add features or fix bugs.
I take it from your willingness to distribute 11 profiles when you could probably distribute less that you have not had the need to get your apps Java Verified?
Re: De-fragmentation progress?
bukster1000 | 13/09/2006, 18:42
Hi Kevin,
I have never bothered with Java Verfied becuase of the cost and, to date, our applications don't get distributed through the network operators portals (therefore no requirement to get verified). I investigated the process when it was first launched and it didn't look very benficial and relevant (we build our own low level GUI components). Since then not much has been said about it so it isnt a high priority for us.
Regards,
Jason Delport
Paxmodept
www.paxmodept.com
I have never bothered with Java Verfied becuase of the cost and, to date, our applications don't get distributed through the network operators portals (therefore no requirement to get verified). I investigated the process when it was first launched and it didn't look very benficial and relevant (we build our own low level GUI components). Since then not much has been said about it so it isnt a high priority for us.
Regards,
Jason Delport
Paxmodept
www.paxmodept.com
Re: De-fragmentation progress?
kevinauthor | 13/09/2006, 18:56
Channel desires and mandates seem to be the primary drivers for JV. In time consumers and other final buyers may recognize the value.
Re: De-fragmentation progress?
coultonp | 15/09/2006, 16:03
KevinI did buy a JV certificate primarily so I could use the RFID shell but it also gets rid of some of the user verification messages on some phone models. However, I have found it difficult to find a list of what JV does then allow you to do without repeated user prompts.
Re: De-fragmentation progress?
mgroeber9110 | 18/09/2006, 13:04
For our TALKS application (http://www.nuance.com/talks/) we currently have four SIS files, all built from a shared code base:
- Series 60 3rd Edition
- Series 60 pre-3rd (everything from 3650 to N70)
- Series 80 2.0 (9500/9300)
- Series 80 1.0 (9200 series)
The Series 60 build for pre-3rd in turn contains a single dynamically loaded DLL that exists in three copies (built against different SDKs for Symbian 6.1, 7.0 and 8.0) which are selected at run-time to include all features where binary compatibility is not maintained across phone models, e.g. Skin-specific APIs or changes in the CEikEdwin handling of line endings. [As an aside, the variant DLLs are selected at run-time rather than through if exist() in the installer to support SIS-extractors like HalWin which cannot do conditional installation, of course.]
So, a full build involves six compilations of the same codebase with different SDKs (some of which only compile a bld.inf containing a sub-set the actual platform-specific code for speed). The differences are controlled through #ifdef's using our own set of macros - with a bit of trickery, these are made available everywhere from .cpp to bld.inf, ..mmp and .pkg files.
If I had two wishes to make this more easier to handle (in addition to Documentation, Documentation, Documentation!), these would be:
- A pre-defined set of macros to detect the SDK you are currently compiling with that is common across *all* SDKs, including legacy, and available in mmp, bld, cpp, rss - some v9 examples sometimes use Symbian's own macros like APP_TO_EXE which are not actually defined in Nokia's SDKs (and certainly not documented), but this area is a complete mess IMO.
- [Now obsolete] An early backport of ECom to Symbian 6.1 - ECom is a "strategic" technology for modular apps that could drive the entire design of an application, but as long as we are committed to supporting pre-Symbian 7 customers.
ciao marcus
- Series 60 3rd Edition
- Series 60 pre-3rd (everything from 3650 to N70)
- Series 80 2.0 (9500/9300)
- Series 80 1.0 (9200 series)
The Series 60 build for pre-3rd in turn contains a single dynamically loaded DLL that exists in three copies (built against different SDKs for Symbian 6.1, 7.0 and 8.0) which are selected at run-time to include all features where binary compatibility is not maintained across phone models, e.g. Skin-specific APIs or changes in the CEikEdwin handling of line endings. [As an aside, the variant DLLs are selected at run-time rather than through if exist() in the installer to support SIS-extractors like HalWin which cannot do conditional installation, of course.]
So, a full build involves six compilations of the same codebase with different SDKs (some of which only compile a bld.inf containing a sub-set the actual platform-specific code for speed). The differences are controlled through #ifdef's using our own set of macros - with a bit of trickery, these are made available everywhere from .cpp to bld.inf, ..mmp and .pkg files.
If I had two wishes to make this more easier to handle (in addition to Documentation, Documentation, Documentation!), these would be:
- A pre-defined set of macros to detect the SDK you are currently compiling with that is common across *all* SDKs, including legacy, and available in mmp, bld, cpp, rss - some v9 examples sometimes use Symbian's own macros like APP_TO_EXE which are not actually defined in Nokia's SDKs (and certainly not documented), but this area is a complete mess IMO.
- [Now obsolete] An early backport of ECom to Symbian 6.1 - ECom is a "strategic" technology for modular apps that could drive the entire design of an application, but as long as we are committed to supporting pre-Symbian 7 customers.
ciao marcus
Re: De-fragmentation progress?
kevinauthor | 18/09/2006, 21:20
Interesting tool suggestion. I've passed it on to our tools people.
Nokia Developer aims to help you create apps and publish them so you can connect with users around the world.
京ICP备05048969号
© Copyright Nokia 2013 All rights reserved
Re: De-fragmentation progress?
bitrabbit | 13/09/2006, 11:54
I have to say the results are pretty good. You have to know that we specialize on games, which means essentially full screen, fast blitting and custom sound mixer output.
With just one build, yes only one, all the S60 range is covered. This means that one sis will install and run correctly from the 7650 up to the N90 for pre Symbian 9 handsets.
However, this comes at a cost, since documentations on such features as we use is very light, and most of the time wrong. For example, the sound mixer example from forum nokia would never pass the certification. I don't even mention using the LowMem tool. This means that us, the small developers, have to spend days and days of tweaking here and there to find the correct combination of code which will work on all the devices. It's good when you finally get it - the Holy Grail - but what the hell to reach it !
To sum up, great results, but it costs a very high price. If you had to start somewhere to help developers, this would be by producing a LOT MORE and ACCURATE documentation.
I can add as well that with only half a dozen #ifdef, the code is compatible with UIQ as well. But UIQ is such a small market...
If I was to compare with the other "competitor", I can safely say it is REALLY easier to develop on the other one. Granted, it does not provide all the benefits of the Symbian OS, but in the end, how many developers correctly use all these features ? Also, it involves far less tweaking to have it running on ALL iterations of the OS.