My Experience with the Windows Marketplace for Mobile and Windows Mobile 6

• Download source code - 553 KB

Introduction

Several months ago, I registered with the Windows Marketplace for Mobile. I wanted to create a simple application and put it through certification so I could see what the process was like (and write about it!). At this point, I've seen what it is like to fail certification for the Marketplace, pass certification, and have submitted product updates.

Microsoft has been making changes to the Windows Marketplace for Mobile across its interface, rules, and procedures based on user feedback. During the course of time that I began writing this document, the interface for submitting applications went through several changes one weekend. To keep this document more relevant, I waited until after those changes settled to complete and publish this document.

What this Document Is or Is Not

This document isn't a guide for getting through certification. Microsoft already has a guide published. This document is just a collection of my experience, information gathered from others speaking of their experience, and some of my thoughts. If you think this may be helpful to you, read on. Either way, if you plan to submit an application to the Windows Marketplace for Mobile, you should visit http://developer.windowsphone.com to read on the certification process. Adjustments have been made to the Developer Dashboard and certification process over time, or that my thoughts and experience cover everything one needs to know to pass certification.

About the Code

The code attached to this article actually went through Marketplace Certification and passed. I wrote the code with the intention of making this article and not with the intention of charging money for it. In several conversations, some one at MSMobiles.com urged me to charge for the application instead of giving it away for free. To prove to him that the application would not sell, I put a price on it. Two weeks later, I had sold almost enough copies to cover the registration expense. I made an updated version of the application, and am pushing it out to those that paid for the application while the original source code is available here for your review. Though, this article has very little to do with the code at all, and I think the code is more incidental to the article than supportive of it. I'm including it because I'm sure someone will want to look at it.

Registration

For me, the registration process was easy. I live in the United States, and was registering as an individual. Since I am registering as an individual, anything that I publish must be under my legal name. My preference was to publish under the name of my website (j2i.net), but this isn't an option. In addition to filling out the forms online as a part of the registration process, I also had to print out a form that for the most part stated that I am who I say that I am and have it signed and stamped by a notary. I had this done at my bank since they notarize documents for account holders for free. A photocopy of the document along with a copy of my government issued ID was e-mailed to GeoTrust. A few days later, I received a phone call from GeoTrust in which they asked me to verify my name and a few other items of information. Two days after speaking with GeoTrust, my account was enabled and I had access to the Marketplace Dashboard.

Application Guidelines and Rules

The Submission Guidelines (PDF link) are openly available. While waiting on the identity validation, I encourage you to familiarize yourself with the guidelines. I've seen a lot of negative statements over the number of rules there are for the Marketplace. While the number of rules looks intimidating, when you actually look at what the rules are, they are not that bad. Depending on your application, you may find that several of the rules don't apply to the application that you plan on publishing to the Marketplace. Currently, the table of contents for this document lists seven requirements sections:

1. Reliability
2. Phone First
3. Effective Memory Management
4. Malicious Software
5. Respect User Settings
6. Widgets
7. Windows Marketplace Listing Criteria

I wasn't publishing a widget, so right away, I can see that the widget section of the document doesn't have anything applicable to my application. Some of the rules are for applications that are replacement Input Method Editors (such as custom onscreen keyboards). These also won't be applicable to most applications. To nail down which rules I care about, I need to decide on the nature of the application being published. Since I was only creating this application for the sake of going through the certification process, a flashlight application would have been sufficient. I decided to go with something slightly more functional; I made an application that would display one's speed from the GPS receiver. This application was going to be written with the .NET 3.5 Framework, and would run on Windows Mobile Professional (devices with a touch screen) of all screen resolutions. An application can either target all versions of Windows Mobile 6.x, or it can just target Windows Mobile 6.5. I can't see any reason that an application like this requires WM 6.5 specific functionality, so I decided to target all WM 6.x versions. (This application should also run on Windows Mobile 5. But I haven't tried this out yet.)

A few things to note about the certification process and rules: Certification testing is only done against the exact installation that you plan to deploy to customers. Questions have come up in the forums in which some one wants a version of their application to be certified with the intention of making a small tweak in the version that is going out to the customers. There were also a few questions about submitting something for testing with the plan on completing some other portion of the code before release. This can't be done. The application must be complete before being submitted for certification, and if you make any change in the application, then recertification will be required. Also note that certification testing is not quality testing. If your application starts crashing during certification, that's a sure fire way to fail, but passing certification isn't a guarantee that the application won't crash. The first version of this code to pass certification had a race condition that could cause it to lock up and crash, but the condition was so rare it never happened during the certification test. I caught it after I submitted my application, and after it passed, I never made the 1.0 version public so that I could correct the problem in the 1.1 version.

Satisfying the Reliability Rules

The reliability rules can be found on pages 4 through 11 of the rules document. This is by far the largest section of the document (all of the rules occupy a total of 14 pages of the 31 page document). There are 21 rules under reliability. I'll mention them all, though some of them aren't applicable to my application. By far, satisfying these requirements is the most important part of the certification document, so most of my time is spent here.

1.1 Installation Packages

If you are using Visual Studio to create your installation, you don't have to worry about this one. It only states that your cab must contain a _SETUP.XML. Visual Studio will do this automatically.

1.2 Installation Warning Messages

If you've ever installed an older Windows Mobile application on your Windows Phone, you may have seen an error message that states that the application was made for a previous version of Windows Mobile and may not work properly on your phone. This is addressable by setting the OS Version Max on your deployment project to an appropriate value (I've set it to 6.99 in my CAB project).

1.3 Shortcuts on Start Menu or Start Screen

In short, this rule is saying you must have a shortcut to your application available in the Start menu. The Windows Mobile 6.5 Shell can use PNG files for the icons for your application. For the PNG file that you've created to be used as an icon, there's a Registry entry that must be made. Windows Mobile 6.0/.1 uses *.ICO icons that we've all grown used to. For Windows Mobile 6.5, your application is required to use a PNG icon. There's a potential point of confusion from that requirement. Earlier on, in the MSDN forums, some developers spoke of only targeting Windows Mobile 6.0/.1 so that they didn't have to worry about the PNG icon. Since the 6.0/.1 applications would also be available to Windows Mobile 6.5 devices, avoiding the PNG icon seemed to be on the pathway of the easiest path to get an application out to customers. This misunderstanding was later cleared up.

Since Windows Mobile 6.0/.1 applications are also available to 6.5 devices, they are also bound by the 6.5 requirements. So your application is required to have a PNG icon to pass certification. There're several ways you can get this done. By far, the easiest way is to create a 90x90 PNG icon for your deployment and add the entries to the deployment project registry editor. You can see the technical details of how this is done here. Minimalistically, this means you will be making a registry entry to HKLM\Security\Shell\StartInfo\Start\<shortcutname.lnk> where <shortcutname.lnk> should be replaced with the name of your shortcut icon. You need to add a single string value to this key named Icon that contains the absolute path to the PNG file. Since you don't know the name of the folder in which the application will be installed, you don't know the absolute path ahead of time. But, you can specify %InstallDir% in place of the installation folder, and it will be replaced with the proper path at installation time.

You still need the ICO file for Windows Mobile 6.0/.1 targets. To create the ICO icon, I used IcoFX, a free icon editor. It has an option to import an image from another file, and options to create the other icons of different resolutions.

1.4 Store Files in Specified Directories Only

Only shared components can be installed in the \Windows directory. All of your application's other files should be stored in your application's folder.

1.5 Preserve in-ROM Files

Don't overwrite any of the files that were part of the device's ROM image. This is also probably a good time at which to point out that Microsoft isn't bound by the same restrictions when they are publishing their own applications. If you have installed Office 2010 Beta, the GDI+ DLL in your device's ROM is overwritten (shadowed) with an updated version of the GDI+ DLL. If you've written any GDI+ Windows Mobile applications, installing Office 2010 Beta may break them (note: while a subset of GDI+ is present on Windows Mobile applications, GDI+ was never supported on Windows Mobile, so there was never a guarantee that it would be available on Windows Mobile devices).

1.6 Application Name Length

Your application's name must be under 70 characters. Even if this were not a rule, I can't see many people even gracing this boundary.

1.7 Install and Uninstall Cleanly

Your application should install and uninstall without errors.

1.8 Clean-Up Data

Files that were created during the installation or first run should be removed. Application files that the user creates with your application can be left behind (e.g.: if you made a word processor application, the document files can be left behind). You are also allowed to leave behind the folder structure of your application. In the first version of my application that I made available in the Marketplace, I intentionally left behind a settings file so the user's settings would persist if that user reinstalled the application. By consequence, the application's folder also continued to exist after the application was uninstalled (since it contained the settings file). The types of files allowed to be left behind include:

• User data associated with the application
• Files shared by applications by the same publisher
• Files required by the OS

1.9 Installation in RAM, Don't do It!

I don't even know how to place files in the RAM file system. Honestly, I didn't bother worrying about this one. If any one else can explain it, please enlighten me.

1.10 Home Screen Files

Not applicable.

1.11 GAPI on WM 6.5

Not applicable.

1.12 GAPI on WM 6.1

Not Applicable

1.13 Multiple Device Support

Your application must be able to run on more than one device that meets the specifications that you communicate. For compatibility, you select the supported resolutions and the required hardware. From assisting others in the Marketplace forum, I'd say this is another potential point of confusion. To communicate the hardware requirements, there's a form with checkboxes that allows you to choose what hardware must be present in a target device. If a user's device does not have all of the features that you check here, then your application will not be visible to the user in the Marketplace. I've seen developers check the Keyboard requirement not realizing that this requirement means that the user's device must have a physical keyboard. I also know of another application that would work with and without GPS. But the developer checked the GPS requirement, making the application available only to users with a GPS receiver in their phone. If you make a mistake in this section and don't update it before submitting your application for certification, there's no way to change it until you submit an application update.

In addition to hardware requirements, the compatible screen resolutions must also be selected. Like the hardware requirements, if the user's device doesn't meet the screen requirements you've selected, the application will not be displayed in the marketplace for the user when the user is browsing the Marketplace. There are some resolutions that are only available on Windows Mobile Standard devices (devices without a touch screen) and Windows Mobile Professional devices (devices with a touch screen), and most are available on both. I selected all of the resolutions available for Windows Mobile Professional devices. Because of the way the UI in the application scales, it will work on all of these resolutions.

1.14 Single Application Instance

Only one instance of your application should be running at a time. Most of the code for this is taken care of automatically for you by the .NET framework. It's possible to create multiple instances if you start the application multiple times in rapid succession, but I wasn't worried about someone doing this. Neither were the testers. So, I didn't have to do anything for this requirement.

1.15 Recover from Power Savings Mode

If the device goes into standby and comes out, your application shouldn't crash as a consequence. There was nothing I needed to do for this. Applications I've seen that have problems coming out of standby are applications that rely on external hardware (e.g.: Bluetooth connections or communication ports). Going into standby may close the connections and file handles associated with these external devices; applications not designed to handle this may crash. If your application is communicating over a Wi-Fi connection, going into stand-by could power down the Wi-Fi adapter, and there may be a delay in it powering back up when the device comes out of standby - yet another condition that could cause problems for an unprepared application.

1.16 Task Manager

The application must show up in the Task Manager while it is running (note: if your application has no title in the title bar, it won't show up in the Task Manager). I know of a developer that failed certification on this because he made his application terminate as soon as it lost focus. To the testers, this appeared to be an application that wouldn't show up in the Task Manager.

1.17 Hopper Test

The Hopper test is a stress test for the application. It generates random key presses and screen clicks. Your application must be able to survive 2 hours of testing against the Hopper application without crashing. You can find the download for Hopper here. While this is part of the certification, this is not a QA test. An application that passes Hopper could still have code paths that result in crashes.

1.18 Don't Disable Error Reporting

Your application should not disable Windows Error Reporting.

1.19 Graceful Shutdown

The application must be able to shutdown without crashing. The shut-down could have been initiated by the user or by a low memory condition closing the application. I failed application certification on my first attempt because of this. While the application had no problems when the user closed it, if the application were killed by the Task Manager (the tester's method of simulating the Shell killing an application), the application's worker thread wasn't killed and continued to run. When it attempted to marshal calls over to the UI (which was killed along with the main thread), it would crash. To correct this problem, I only had to kill the worker thread during the Closing event of the main form.

1.20 Wait Cursor Support

If the application is busy doing something long enough to make the UI appear to be non-responsive or locked, you must display the wait cursor. Not something I was worried about for this application.

1.21 Applications that Use MFC must Statically Link to the MFC Runtime

Once again, not applicable since this is a .NET application.

Other Rules

There are some other rules in the certification guide. To summarize, applications should not interfere with the phone's ability to receive calls. The software should not be malicious. The software shouldn't change system settings/preferences. And, the software must notify a user before opening a data connection.

Uploading the Application to the Marketplace

Note, there is also a video of the upload process available.

You can start filling out the submission forms before you've begun to write your application. Before uploading the application to the Marketplace, there are some thing's you'll want to gather:

• A CAB for the application
• 4 icons to represent your application in the Marketplace
• 1 to 6 screenshots of your application
• A short description for your application that users browsing from a phone will see (limit: 500 characters)
• A long description of your application that users browsing from a computer will see (limit: 2000 characters; can be the same as the short description)
• 3 to 5 features to point out about your application
• Any waivers that your application needs
• Have a support e-mail address and possibly a support page or phone number
• Know the hardware and screen resolution requirements for your application
• Have a price in one or more currency that will be applied to your application
• Have a category in mind for your application

Once you've collected this information, log into the Developer Dashboard from http://developer.windowsphone.com and select the button to "ADD PRODUCT". You'll be prompted to specify if you are adding a widget or an application. I selected application, and was taken to a form where I could select the name of the application, the Windows Mobile versions it supports, and the version number for my application.

For the minor version number, *always* select 0 as the initial version. You can update your application for free up to version x.9 of your application. If you were to start on version x.7, then you would only be able to make two more updates before consuming a submission credit. A consequence of this is the internal version number of your application could end up out of sync with the version as stated in the marketplace. If you are only distributing through the Marketplace, then you should have no problem keeping these numbers in sync. If you display the version number for the application within your app, you may want to add code to extract the version number from the assemblies meta data to reduce the number of places in which you must update it.

The next form to fill out in the submission process contains the product descriptions and features. Here, you can enter your short and long descriptions for the application along with entering the three to five features you want to point out about your app.

On step 3 of the submission process, you'll be able to upload your application binary and provide support information. On this same page, if your application's installation requires elevated privileges, you'll be able to select "Privileged mode digital signing" here. For my application, I was able to leave this setting on its default of "Normal Mode Digital Signing."

On step 4 of the submission process, you'll upload your product artwork. This will always include 4 PNG icons and at least one screenshot for your application. Previously, this was a point at which one could easily fail certification. If you uploaded images of the wrong size, you would have essentially wasted a certification attempt (worth 99 USD). Now, this page will validate the size of the icons you upload, and prevent you from going any further if they are incorrect. The four icons you upload must have the dimensions 45x45, 64x64, 36x36, and 60x60. I made these the same images as what I was using for my program's icon in the Start menu, but there's nothing requiring that these images be the same. There are also size restrictions on the screenshots. All of my screenshots were 240x320. They could have also been 315x420.

Step 5 of the submission process is specifying the requirements for your application. I spoke about the requirements earlier. The one item I've not mentioned is that here you can specify the version of the .NET framework that your application needs. If the required version is not present on the user's device, the Marketplace will take care of installing it. Of course, if your application is written in native code, then you can specify that the .NET framework is not needed.

Step 6 of the submission process is specifying the category and price for your application. The price information you enter will impact the application's visibility to customers in other nations. If you only want the application to be available to customers within the market to which you are uploading your application, you only need to select a price for that region. If a user from another region browses the catalogue in which you've uploaded your application, if no price was specified for their region, then the application will not display.

Once all of the information is entered, you can submit your application for certification. Once you submit the application, it is out of your hands. There's no way to cancel the process without a submission credit being used. So, make sure that you are truly prepared to release the application to testing before you click on this button. If you submit the application and then realize a few moments later that you submitted the wrong version or that something needed to be changed, there's nothing you can do. You could request that your application not be tested, but this wouldn't prevent you from loosing the certification attempt credit. So, if you submit and then realize that something needed to be changed, it's best to just let it complete certification testing so you can get feedback on anything else that might not be in compliance.

The certification process time can vary. I've sent this application through certification 4 times (one failed attempt and three passing attempts). On average, it took about 5 days to pass certification. It has taken as long as 10 days. When the application certification process is complete, passed, or failed, an e-mail is sent notifying that the application's status has changed.

The application's status is displayed upon logging into the developer dashboard. If the application passes certification, its status in the dashboard will be "Ready to Publish". Once the application achieves this status, you can make it visible by selecting "Submit to catalog". After submitting the application to the catalog, it will be visible to users within anywhere from a few minutes to 12 hours.

I was submitting my application to more than one Marketplace. I waited until *after* the application passed certification, and then went to the products tab of the Developer Dashboard and found my application. The settings icon on the right side of the application line item has an option to submit to additional marketplaces. Selecting this option causes the CAB and application requirements to automatically copy over. Unfortunately, it doesn't cause the product description or screenshots to copy over, so it was necessary to upload these again. I found submitting a passed application to another market to be faster than submitting a new application for certification. On average, it took about 5 to 6 working days for the application to pass certification for the new market.

Once the application sold enough copies to pass the 200 USD payout threshold, I received a notification in the Dashboard that looks a lot like an error. The error is "Bank data pending validation". At first glance, this error was alarming to me.

When I looked into the details of the error, things made more sense. The details of this error say the following:

Your banking information has been received, but we have not attempted to deposit royalty 
funds in your account. Once we are able to successfully fund your account, 
this message will no longer appear.

In other words, the final form of validation on the bank account information that you've provided to Microsoft is whether or not funds can successfully be deposited into the account. Once I successfully receive my first payout, I won't see this error anymore.

Reports

There are two types of reports available in the Developer Dashboard: fulfillment reports and royalty reports. To generate a report, you fill out a form asking for basic parameters such as do you want your report to be based off of a single market or all markets in which you have products, or selecting whether the report is based off of the last seven days, month to date, 30 days, or 90 days. When you select all the parameters and request the report, you'll receive a notification telling you that the report is being generated. When the report generation completes, you receive an e-mail notification. So far, generation of the reports hasn't taken very long. After requesting the report, I've been able to go to another area of the dashboard and then return to see my report waiting. The reports are in XML format, and open directly into Microsoft Excel.

The fulfillment reports are good for knowing how many people downloaded your application and when they were downloaded. The royalty report contains information on payments that you've received. While I'm eligible for my first payment since I've not yet received it, this report is blank for me (after receiving it, I plan to update this article to include the type of information it contains).

Requesting Support

There's a "Contact Support" link in the first page of the Dashboard that opens a form for submitting a support request. I've only submitted a single support request, and heard back from some one later in the same day. Based on messages from other developers that I've read in the MSDN forums in the earlier stages of the Marketplace, the support link was not quite so reliable.

For general questions, I would advise posting a question in the MSDN Marketplace Forum for Developers (don't make the mistake of posting in the user's forums). When you post your question, if it is about an application that has been submitted and approved, you will want to include the name of your application, the market in which you are experiencing an issue, and the product ID for the application (the product ID displays at the bottom of the page when you view the information on your application in the Dashboard). When someone posts a question such as "I can't find my app in the Marketplace, where is it?", it is difficult for any one to give assistance and will always result in requests for more information. A question with all the information needed could be worded like the following: "I can't find my application, SpeedTracker, in the en-US Marketplace. The product ID for my application is 9038f34f-2cda-4a3e-9bbb-81978b88a6bb." If you start a question in a Marketplace forum thread and decide to elevate the question to a support request, remember to reference a link to the thread in your support request.

User Ratings and Support

I'm active in the Microsoft support forums, and from reading through the user forums and the developer forums for the Marketplace, there seems to be a prevailing set of behaviours among users. Users that are unhappy with an application tend to be more likely to make a rating on an application than users that are content with it. Also, users that encounter a problem with an application don't seem to be aware that the developer of the application has provided support information. I've encountered a number of users that run into a problem with an application and respond by either asking a question in the user forums (in which case, I try to direct the user back to the application's publisher) or will just vote a bad rating on the application and move on. I've got no tested solutions for this, but seeing the behaviour makes me wonder if raising the visibility of the support information within the application would motivate users to interact with the application's publisher before giving an application a bad rating.

Application Availability Questions

There's one thing about the Marketplace for which I still have questions. What happens when an application is no longer available? There's no sanctioned way for users to get their hands on the CABs for reinstalling applications. Instead, if a user needs to reinstall an application, they can re-download it through the Marketplace client. But, what happens if the application is effectively removed from the Marketplace? Application removal can happen for a number of reasons. The ISV/developer could decide to remove the application. If the developer/ISV doesn't renew their Marketplace account every year, then their applications will automatically be removed. Also, if an update is made to an application and that update has different requirements than the previous version of the application, that could make the application incompatible and thus unavailable to some of the previous purchasers. I've not been able to find a definite answer on these questions, though I have been able to find instances of such things occurring.

When will the Marketplace be Available in My Area

Every so often, a user or a developer will post a question asking when the Windows Marketplace for Mobile will be available in their area. Developers also ask if they can register to sell applications in other areas since the Marketplace is not yet available in their area (e.g.: a developer from Israel wanted to register to sell in the USA). For these questions, the most common response from Microsoft employees is that Microsoft is looking to expand geographical coverage and more information will be available when the time comes. It seems the schedule for expanding the Marketplace footprint isn't publically disclosed. So far, it seems that one's eligibility register to sell or purchase applications is dependent on whether or not the Marketplace is supported in their region. If the Marketplace is not available in your region for purchasing applications, then you will also be unable to register to sell in your region or any other region.

Questions?

I've highlighted my thoughts, experiences. If there's anything on which you would like for me to expand, put a question in the comments area and I'll try to answer it. If you have questions about the Marketplace in general, the best place to ask those would be in the Microsoft Windows Marketplace for Mobile Developers Forum.

History

• 21 March 2010 - Initial publication.