This document reflects many of the issues that have been discussed on the Smartphone developer's newsgroup. There is a strong feeling among the mobile developer's community that the concept of M2M as currently defined is flawed in several ways (technical problems in the Smartphone 2002 logo document as well as pricing issues). This may explain why few developers have taken advantage of the recent "free logo certification offer".
We sincerely hope MS will be sensitive to the market realities faced by ISV's developing mobile software for the Smartphone, and will take step to change and improve M2M so that it will promote development of quality software for Microsoft mobile devices without creating un-justified cost-burden and technical restrictions on what innovative ISV's can do for these new platforms.
On the other hand, we think the M2M logo certification process should define and enforce more requirements in order to guarantee that all certified applications will work well on all Smartphones.
As M2M stands now, we are not seeking to be in the M2M catalog, and we have even turned down the offer for free logo certification, because we don't want to endorse a system that we (and many other ISV's) consider to be seriously flawed (some nice people only say it's a half-baked job).
In case you don't know us, we develop PocketTV, a video application that has become the most popular third-party app on Pocket PC with close to a million registered users. We would love to become one of the most popular applications on the Smartphone M2M catalog, but not until all the M2M problems are addressed and resolved by MS with the broad support from the mobile ISV community.
By the way, PocketTV Classic for Pocket PC is distributed as a *free* but high quality application, and we intend to do the same on the Smartphone. But distributing a free application like PocketTV Classic with M2M is clearly not possible if we need to spend $3,000 each time we release a bug fix (in ten languages).
Mobile2Market is a catalog of applications that have a "seal of excellence" approved by MS and that MS will promote to the operators. The "seal of excellence" is the Smartphone 2002 logo certification.
Logo certification is supposed to guarantee that the application :
- Follows some basic UI rules that are consistent with built-in applications on the device.
- Does not interact negatively with other applications or with the OS.
- Works properly on any "Smartphone 2002" device.
Internationalized versions of an application are generally obtained by replacing all the text (menu, dialogs, messages etc) and other localized resources by just another set of resources, extracted from a different resource-only dll file. Usually the application code is the same (literally), and there is one resource-only dll for each language.
The current logo certification model requires that each localized language for an application must be tested as an independent application, even though, in the majority of cases, the application itself will be identical, only the resource-only dll will differ for each language.
Proposed solution: In case an application uses resource dll's for internationalization, logo certification should apply globally to all different language versions and should be tested only with the version using the default language (e.g. English).
The certification model requires re-certification of each application (in each regional language) each time the ISV wants to release a bug-fix or a new version that contains minor changes or improvements. The cost of re-certification becomes rapidly unbearable in case of applications localized in multiple regional languages (see point above), and it certainly discourages ISV from releasing frequent updates and bug-fixes. The cost of fixing even a minor bug (e.g. just a typo or spelling mistake in a message) can be several thousand dollars.
Discouraging ISV from releasing bug-fixes will probably not help in getting quality software available on the platform.
Proposed solution: MS should review the logo certification process and pricing so that it does not discourage ISV from releasing frequent bug-fixes and upgrade of their products. logo-recertification should not be necessary for minor bug-fixes and upgrades of applications. Only new signatures are required in that case (naturally, since the files are changed).
3.1 "Done" requirement not consistent with the use of some standard Smartphone UI features.
The logo requirement document states that in order to quit a screen, "Done" must appear on the left soft-key.
Problem: The default Infos and Alert boxes displayed by the Smartphone when an application calls the standard MessageBox routine appear in the form of a screen that has the left soft-key mapped on "OK" (not "Done"). MS people acknowledge that the logo requirement document was never meant to prevent the use of the standard Smartphone Infos and Alert boxes.
Proposed solution: Either explicitely list standard Infos, Alert and other standard message boxes created by calling MessageBox as exception to this rule, or allow using "OK" as an alternative to "Done".
3.2. Some requirements (e.g. "Done") only apply to english-language software.
For example, the logo requirement document states that in order to quit a screen, "Done" must appear on the left soft-key. This requirement clearly cannot apply to an application in Chinese or French.
Proposed solution: Clarify requirements that are language-related.
3.3. Various important requirements missing, necessary to enforce that applications will not interact negatively with each other or with the OS.
The logo document requires that applications have no "Exit" item in the menu, but it is missing some of the other requirements that applications must implement in order for automatic memory management to work well on the Smartphone.
For example, it is a requirement that applications call SHCloseApps when they cannot obtain the memory that they are trying to allocate, so that the Shell can cause background applications to either hibernate or terminate, to free some memory. If they don't call SHCloseApps, some applications may not be able to run while other applications sit, idling and inactive in the background. The only workaround in that case is for the user to power the phone OFF then ON (to kill all background applications) or to use a third-party task manager.
Also, another requirement is that applications that are not actively using a file when they are inactive should close it, so that the file could be updated/sync even if the application that was using that file is still running (but inactive). Unfortunately this requirement is not even implemented by some built-in MS applications, e.g. the Windows Media Player. If the WMP has a video file opened (but not playing), other applications cannot access this file as long as WMP is not killed. This is a problem, since there is no way to "Exit" manually WMP. The only way to cause it to close a file is to have it open another file!
Of course this requirement to close all files does not apply to applications that need to actively use the file when in the background (e.g. playing an MP3 file). The requirement that inactive applications should close all files that they don't actively use should probably be extended to other global resources than just files.
Proposed solution: add the requirements described above. If not, remove the "No Exit in Menu" requirement.
3.4. Missing requirements to guarantee that the application will work properly on any "Smartphone 2002" device.
It should be a requirement that an application (in any language) works well on any Smartphone 2002 device regardless of the language used by the device. For example, an English applications should work on a Chinese Smartphone.
In particular, applications should use SHGetSpecialFolderPath, SHGetSpecialFolderLocation and SHGetPathFromIDList to get the names of the various special folder paths on the device, and not use hard-coded stribgs like "\Windows\Start Menu\". Unfortunately SHGetSpecialFolderPath does not work as it should of the Smartphone 2002 (e.g. no way to access the name of some folders like \IPSM\Program Files\, \Windows\Start Menu\Games\ and \Windows\Start Menu\Accessories\).
Proposed solution: add the requirements above.
3.5. "Clear registry keys when un-installing" causes problems with commercial applications.
There is a requirement everything in the registry or files that was installed or created by an application must be removed when the application is un-installed, except shared registry keys or shared data files.
This requirement causes problem is when a commercial application must save some code/key information in the registry. If un-installing the application causes those information to be removed from the registry, then installing an update of the application will require that the user re-register the application (i.e. the user must obtain a new key/code from the ISV), and this is not acceptable. That's because installing an upgrade causes the Smartphone app CAB installer to first remove the old application.
Proposed solution: transform those requirements into "strongly advised" guidelines, i.e. there should be a valid justification not to follow those guidelines.
3.6. Requirements to not use ellipsis not quite consistent with Home Program list.
Ellipsis are used in the Home Program list ("More...") to indicate that this selection will bring more choices.
Proposed solution: Maybe you should authorize the use of ellipsis with the word "More" if it appears in a menu or list, to be consistent with Home Program list.
3.7. Requirements to not use numerical accelerators in menus is un- justified.
The Home Program list uses numerical accelerators, and this is considered convenient. Why not allow numerical accelerators in menus ?
The OS implements automatically numerical accelerators in menus, and some polls have showed that early Smartphone users prefer to have numerical accelerators visible, provided that they don't "clutter" the menus (e.g. they can be placed on the right side of menus using the "\t" (tab) separators, like on http://www.pockettv.com/images/sp/main-menu.gif .
When we asked MS for the technical justification regarding this requirement, someone at MS told us "that's because in some future version of Smartphone, the OS *may* automatically add numerical accelerators in the application's menus". So this requirement should not apply to the logo document for "Smartphone 2002", since thi version of the Smartphone OS does *not* automatically add numerical accelerators in the application's menu. When applications will be addapted to future versions of the Smartphone platforms, their menus can be changed and the accelerators can be removed if the new Smartphone OS adds them automatically.
Proposed solution: Remove this requirement, or change it to authorize numerical accelerators placed on the right edge of the menu, using the "\t" (tab) separator in the menu text (e.g. "Options\t4" to get "Options 4"), so that menus are not cluttered.
3.8. Requirements on BACK button should be clarified.
The BACK button should allow to edit text backward only when a text-edit control is in focus (i.e. when text can be typed-in).
When no text-edit control is in focus, the BACK button should always act as "Cancel", i.e. return to the previous screen without validating any change in the current screen.
The problem is that the way the BACK button works is not consistent in the buit-in applications (e.g. in the Settings screens, the BACK button never returns to the previous screens, even when there is no text-edit boxes on the screens. MS people told us that the Settings applications was not following the general UI guidelines of the Smartphone, and that this was a design choice.
Proposed solution: The BACK button must allow to edit text backward when a text-edit control is in focus. When no text-edit control is in focus, the BACK button should always act as "Cancel", i.e. return to the previous screen without validating any change in the current screen.
3.9. Requirement that applications should work on all screen bit depths including B&W is un-testable with developemnt tools and devices or emulators.
This requirement is not realistic because it is completely un-testable, as there is so development environment (available to ISV) that allows to test if an application runs properly on all screen bit depths including B&W.
Proposed solution: Transform this requirement into a guideline or strong suggestion.
3.10. "Timer OFF when application in the background" should be clarified/refined and extended
Current requirement seems to apply only to timers used for "visual elements". We think it should be extended to timers and other actions (e.g. polling) that can use significant CPU resources. But clearly this requirement cannot apply to applications that remain active when in the background, such as MP3 player (like WMP) that can play music while in the background.
Proposed solution: The requirement should state that "Unless they are performing an active task", applications in the background should turn all their timer OFF and they should not perform any actions causing significant CPU resources to be used (e.g. polling).
3.11. "Non-interference with incoming calls" must be refined, e.g. what about earpiece volume ?
There is currently no guidelines regarding the handling of audio Volume. For example, if an application allows the user to change the volume (e.g. while playing a video file), should the earpiece volume be restored if an incoming call arrives ? We think it should, but WMP does restore the volume of the earpiece, and that may cause an interference with the incoming call functionality.
Proposed solution: Applications that can change the volume settings must restore the original earpiece volume setting when an incoming call arrives.
3.12. GAPI requirement does not make sense, as "gx.dll" is in the ROM on Smartphone 2002
Document states: <<Additionally, if an application installs GX.dll (GAPI), it must install that DLL in the application directory, not in the Windows directory. Apps that use GAPI, must install this DLL.>>
Since gx.dll is in the ROM of the Smartphone 2002, applications that use GAPI should *not* install this DLL!Proposed solution: Remove this bogus requirement regarding gx.dll, probably inherited from an old Pocket PC logo document.
3.13. Recommendation to use the common dialogs to save and load files does not apply to Smartphone 2002
Document states: << In general, it is recommended that applications use the common dialogs to
save and load files.>>
The problem is that the common dialogs (GetSaveFileName and GetOpenFileName) are not implemented on Smartphone 2002.Proposed solution: Remove this bogus recommendation, probably inherited from an old Pocket PC logo document.
3.14. Applications that install shared dll's (e.g. in \IPSM\Windows) must use dll reference counter
This important requirement is missing from the logo document. Applications that install any shared files, such as shared dll's (e.g. in the \IPSM\Windows folder ) should use the CAB installer reference counter, i.e. they should set the flag CE_COPYFLG_SHARED (0x80000000) for the shared files in the cabwiz .inf file. See:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcesetup/htm/_wcesdk_copyfiles.asp
This requirement was missing in Pocket PC and that caused many problems: Some downloadable updates of MS apps (WMP) did not set the flag properly for the shared gx.dll that they would install in \Windows. This missing reference counter caused the following problem: Un-installing other applications sharing this dll would remove gx.dll, thus breaking WMP!
Proposed solution: Add the requirement: Applications that install shared files such as shared dll's (in \IPSM\Windows) must use the CAB installer reference counter (CE_COPYFLG_SHARED).
3.15. Issues with the "No Exit" Requirement.
We (as developer) totally understand why "Exit" should not be necessary, provided that all the applications installed and running on the device comply with a series of strict requirements that guarantee that they will all behave properly without requiring the user to explicitly "Exit" them.
Those requirements can be summarized as:
- Applications must call SHCloseApps when memory allocation fails.
- Applications must release all un-necessary allocated memory when they get a WM_HIBERNATE message and they must gracefully terminate when they receive a WM_CLOSE message.
- Applications must close all files and release all global resources when they are inactive in the background, except when they do some active task that require otherwise (e.g. playing MP3).
- Applications must stop all timers and not use any CPU resources when they are in the background, unless they perform some active task (e.g. play MP3)
Unfortunately, the world is not as perfect as it should, and:
- Many applications do not implement properly the requirements above (including some logo-certified applications and even some MS built-in applications). In some cases, it is even impossible to call SHCloseApps when memory allocation fails (e.g. memory allocated by "new", because the _set_new_handler routine is not implemented on Smartphone).
- Users don't understand why Smartphone applications don't have an "Exit" command, and this causes additional un-necessary customer support issues for developers. Developers must explain users that they don't need an Exit command ("just press HOME and the application will disappear!"), but user will say that in fact they do, and most of the case they are right, because of the point above! For example PocketMVP (which does not call SHCloseApps as it should) will refuse to run (not enough memory) because other applications (e.g. WMP) are running but inactive in the background, and those applications cannot be terminated other than by powering the phone OFF.
- On Pocket PC, users are "fooled" by MS placing an "X" looking like a close-box in the Nav Bar. Most users think that this "X" actually closes the application, while in fact this "X" merely pushes it in the background (and the application is generally not even aware that "X" was tapped, it is only aware that it is de-activated). But on Smartphone, the OS has no similar way to fool the users to even believe they Exit the application.
- Developers all agree that having an "Exit" command does not hurt or create any problem. In the worst case, it forces an application to restart (which is a bit slower that just re-activate) in case the user explicitly exited the application instead of just letting it become inactive in the background.
So the consensus is that, although the "No Exit" philosophy is, in theory, a good idea, in practice it is not such a good idea, mostly because it requires applications do conform to very strict guidelines that cannot be enforced by the OS or by development tools, and because consequently many applications do not behave well in a "No Exit" scheme.
At the end of the day the user will find that his Smartphone becomes slow and un-responsive, or that some applications (that are not calling SHCloseApps) are unable to start because of low memory, and they will blame (rightfully):
- MS for not providing a task manager allowing them to kill inactive applications.
- ISVs for not providing an Exit command.
- Smartphone in general for becoming rapidly sluggish and requiring frequent reboot when numerous applications are used.
Proposed solution: Since it is impossible to force all applications (in particular those that are not logo certified) to implement all the necessary requirements for the "No Exit" philosophy to work well, there are several (non-exclusive) solutions that can be combined to improve the current situation:
(by decreasing order of importance, according to our jugement)
- Change the implementation of the memory allocation library so that the requirement to use SHCloseApps is removed from the application level and handled automatically at the OS level.
- Provide a good built-in task manager allowing users to see all the background tasks running on the phone (including the mount of memory and CPU resources that they use) and to decide themself which of those inactive task(s) must be manually terminated. Terminating inactive tasks should no require rebooting the phone, as it currently does.
- Allow developers to include an Exit command if they desire to do so.
Naturally we are aware that none of this solutions (except maybe #3) will be included in Smartphone 2002.
3.16. Missing requirements to guarantee that the application will behave properly when user change the system color scheme.
It should be a requirement that an application behaves properly when the user changes the Color Scheme using Settings > Home Screen > Color Scheme.
Changing the Color Scheme causes the global system colors to change. Applications must handle properly the WM_SYSCOLORCHANGE message and change accordingly the colors of all their standard controls (menus, buttons, etc).
Note that there is a Shell bug related to WM_SYSCOLORCHANGE that applications need to be aware of.
Applications that do not handle properly the WM_SYSCOLORCHANGE message usually end-up with controls displayed in the wrong colors, i.e. different from the color scheme selected by the user.
Proposed solution: add the requirements above.
tristan@mpegtv.com (please use plain-text email only, no HTML)
