Fragmentation
On the Nokia Forum blogs, Kevin Sharp, Technical Editor of Forum Nokia asks how Nokia are doing with respect to fragmentation.
I have worked on almost all the Series 60 devices since the 7650. Prior to this I did a large amount of work under Windows CE. I have also written applications for some companies under J2ME. Here are my thoughts.
In order to assess fragmentation, Kevin asks how the number of distribution packages varies across the platforms. However, things are not as simple as this. Not many projects tend to need to support all phones. The number of distribution packages can also be reduced by careful thought (by design) early on in a project.
Let’s take the Symbian OS and UIQ/S60. I have purposely widened this out from just Nokia S60 as this is more realistically what people think about when starting a project. If the application is designed well, it’s possible to isolate the differences between UIQ and S60 which tend to be mainly in the UI. I tend to use preprocessor symbols for this. This (obviously) leads to different builds. However, excessive use of preprocessor based code tends make the code unreadable and it’s for this reason I prefer another approach when programming across SDKs in the same family (e.g. across Series 60).
For Symbian, most (but not all) of the differences between successive SDKs are additions of functionality. When APIs have changed, Nokia (and/or Symbian) have tended to provide the old and new API so that old code continues to work. This means that it’s possible to program for the lowest common denominator (earliest SDK) and it will work on the latest phone. This leads to one distribution for all phones. Obviously, it’s frustrating to have to code something that’s provided by a later SDK - but you are going to have to do that anyway if you want to support an earlier phone. The key is to convince people that they don’t really need support for the early phone as they are not being sold/used as much anymore.
By the way, Symbian 9.1 and Series 60 3rd Edition is a ‘monster fragmentation’ which breaks all this and will always need a new build. It’s also why more effort is required to upgrade an application than people might think - most have been written to much older SDKs and it’s a case of using all the newer intervening APIs.
In the Java ME (J2ME) world things are much more frustrating. It’s not possible to build on an ‘old’ API to provide newer API functionality. The functionality either is or isn’t there. Also it’s possible for a device to declare that it supports an API (JSR) but in fact implements just a fraction of it. An example from Nokia is JSR 135 which is barely implemented on early Series 40 phones. Now this really is bad. To compound the problem, each device has it’s own memory, screen size and performance constraints which have to be worked around. Java ME on a large number of different devices is programming hell (or a sink for money depending on how you look at it).
I have mainly programmed Windows Mobile in C++ rather than with the compact framework. Again, Microsoft tends to supply deprecated APIs to allow programming of later devices using earlier SDKs. I would put this capability on par with Symbian OS.