Windows Mobile 6 Developer Blog

Drive App Downloads with Marketplace Deeplinking

Daniel Bouie — Thu, 25 Mar 2010 20:31:42 GMT

With this post we’re rolling out a new feature to help Windows Phone 6 developers market their applications: deeplinking with the new “Get It Now” Windows Phone logo.

A Windows Phone 6 deeplink points users directly to your application details page on either the Marketplace website, or the Marketplace on-device client. When used with the new logo, deeplinking to the Marketplace website is perfect for email marketing, or for telling users who come to your website how to find your Windows Phone 6 apps.

Deeplinking to the client is even more powerful because you can embed the link within an app. When a user clicks on a client deeplink it will open the marketplace client directly to the details page of the linked application, giving you a great way to help users try new products, or to convert free trial downloads into paid transactions.

Another great thing is that your deeplinks will always point to the latest published version of the linked apps, within your user’s home market. So, you won’t need to go back and change your deeplinks every time you publish an update. Deeplinks are currently limited to applications within the user’s market; however we expect to roll-out cross-market deeplinking in the near future.

Let’s take a closer look at how deeplinking works, starting with the web experience.

The first thing to do is download the new “Get It Now on Windows Phone” logo artwork and license agreement here. You can use deeplinks without the artwork, but it’s free, easy to access, and comes in several different languages, so why not go ahead and download it?

Now, let’s build a deeplink for a specific app. Deeplinking uses a parameter called Link ID, so let’s grab the Link ID for the app you want to link to. You can find this within the Marketplace developer portal by following these steps:

Sign into the portal at developer.windowsphone.com using your Windows Live ID and password.
Click on the “Your apps” tab to open your dashboard.
Click on View Product Details for any published app. Alternatively, you could click on View Product Details from the settings drop-down menu on the Products view. (You could also do this for apps pending certification, but the link won’t work properly until the app is published).
Scroll down to the bottom of the product details page, and copy the 32-character Link ID listed under Additional Information.

Once you have the link, create a new URL of the format:

https://marketplace.windowsphone.com/details.aspx?appId=LinkID

The Link ID is the 32-character string copied in step 4. Now, link to this URL in your app-specific marketing communications, using the “Get It Now” artwork

That’s it. When a user clicks on that link, they will go directly to the details page for your app on the Marketplace website. It’s important to remember that while the Link ID will remain constant for any updates to an app, there may be different Link IDs for Standard and Professional apps. So, if you have apps for both Standard and Professional devices, you’ll need to get the unique Link ID for each of those apps, and point your users to the different versions appropriately. Also, if they are not already signed in with Windows Live ID, users will be reminded to do so before they can download or purchase the app from the Marketplace website.

Now let’s take a look at deep linking on the on-device client. First you’ll need to grab the 32-character Link ID by following steps 1-4 in the deeplinking for web instructions above. Once you have the LinkID, the best way is to use it is to add a new button control to your app. You can even use the “Get It Now” artwork as the visual for the button control, like we did in this demo app screenshot.

Once the control is placed, add an action to launch a process from the control using:

System.Diagnostics.Process.Start("\\Windows\\WMMarketplaceFullClient.exe", "/appid:LinkID");

Where Link ID is the 32-character string you grabbed above.

When the app is compiled, a click on the button control will open the Marketplace on-device client directly to the details page of the linked application, like this:

The final step is to submit the updated .cab file for certification testing via the Windows Phone developer portal. You can do this as an update to the existing app, and remember, you can submit as many as nine free updates to each Marketplace application.

Just as with deeplinking on the web, the Link ID will remain constant for updates to an app, so you won’t need to change the control when you update the linked app. You can use this feature to up-sell free trials to paid downloads, (which by the way is a great strategy for increasing revenue), or simply to help your users find other apps you think they’d like.

Whether you use the website version, or the client version, or both, deeplinking gives you a great way to tell users how to quickly and easily find, try, and buy your applications on the Windows Phone 6 Marketplace!

Windows Marketplace for Mobile: Certification Testing, Hopper, and Multiple Screen Support

Mike Francis — Thu, 18 Feb 2010 22:41:02 GMT

You work very hard to develop, test, and market your Windows Mobile application. Failing Windows Marketplace for Mobile certification testing can be a frustrating experience, but it doesn’t have to be. Failing certification costs a submission credit (or another $99 if you have exhausted your initial five credits), you have to correct and resubmit your application – likely not what you planned. In this post, we’ll cover a few tips that should help you increase the first time pass rate and have your application published to the Marketplace sooner.

TIP NUMBER ONE: Understand the Certification Requirements

As a Windows Marketplace for Mobile developer, you are notified via email when the Application Submission Requirements for Windows Marketplace for Mobile is updated. You can also check the Windows Marketplace for Mobile forum for important announcements including the availability of new requirements. You may be surprised the number of developers that attempt to pass certification testing without understanding the requirements. If you have any questions regarding the requirements, please post them in the very active Windows Marketplace for Mobile forum.

TIP NUMBER TWO: Run Hopper early and often

From the requirements document:

1.17. Hopper Test
The application must complete two hours of Microsoft’s Hopper test without exhibiting unpredictable behavior, hanging or crashing.

The more you run Hopper, the more confidence you will have in passing this requirement. While the requirement calls for two hours, a good benchmark is the number of hours your app runs without problems. Use this as a development metric. There is no reason your application can’t run for 20 hours or more. A suggested practice is to let your application run overnight and check it in the morning when coming into work. Ideally, Hopper and your app will still be running!

Use the correct version of Hopper

There are separate versions of Hopper for Standard and Professional. Make sure you are using the correct one for the device / emulator you are testing against. Also Hopper has been updated to support Windows Mobile 6.5. The correct version of Hopper can be downloaded here.

Starting Hopper

Hopper is brain dead stupid. That is no knock against this stress testing tool. Hopper simply ‘taps’ and ‘types’ randomly into your application. It will stress your application like no user would in the real-world. It is great for exposing bugs that are not found during normal ad hoc testing. To ensure the device or your application is not hanging, it periodically pulls down the Start screen. It does not know anything about your application, in fact you have to artificially ‘force’ Hopper to tap and type into your application. This is done via a Focus Application. The focus application periodically (the default is every 10 seconds), forces your application into the foreground. As a developer, you need to customize the Focus App for your application, changing the string constant that references to your EXE name and path. Starting Hopper and the Focus app (you don’t need to explicitly start your application, it will be started by the Focus App) can be tricky, since Hopper immediately starts tapping and typing when started, making it difficult to navigate to start the Focus App. There are a couple of solutions to this:

Use RapiStart to remotely start the Focus App (this will implicitly start your application) and then Hopper in sequence. You can download RapiStart here: Windows Mobile Developer Power Toys.
Use the Managed Focus App. This tool is hugely convenient in that you specify all of the dependencies for Hopper in a config file and then just start the one application – no building necessary! It will launch your application and Hopper for you. I recommend this tool with a big caveat as some developers have had problems (Hopper failing after less than 30 minutes) with it. It seems to activate applications differently than does the native focus app. I would recommend using the native focus app first to establish a baseline. Then use the Managed Focus App. They should behave exactly the same. If not, stick with the native Focus App.

Hopper is stressing your app, therefore your app may crash

Note that Hopper is a stress tool and as such, your application may crash during a Hopper run. This is a good thing in that Hopper is doing its job stressing your app. It is a good practice to run your application under the Visual Studio debugger when running Hopper. Especially when you are early in the development cycle. This way when your app crashes, the debugger will stop exactly where the crash is occurring. You can also inspect the state of your app to help determine the cause of the crash.

Hopper failure: Start menu dead

One of the more common Hopper failures (log files are stored in \testlog\hopper.log) is ‘Start menu dead’. See here for a good explanation and possible causes of this failure: Hopper: Start Menu Dead!. The Hopper blog is also a good source for tips on running Hopper; however the content is skewed more towards OEMs.

TIP NUMBER THREE: Adapt Your App

From the requirements document:

1.13. Multiple Device Support
Developers must identify the required device functionality during the Windows Marketplace submission process. Applications must have the ability to run on multiple Windows Mobile device platforms, for example, multiple Standard or multiple Professional devices. Although not recommended, applications can support a limited number of Windows Mobile devices.

Screen Rotation

While not previously stated explicitly, this requirement also includes the proper handling of screen rotation. Just about every Windows Mobile Professional device now supports dynamic rotation. Typically this is triggered when sliding out an on-device keyboard or titling the device.

The Adapt Your App section in the Windows Mobile Developer center is a great resource for information on how to ensure your application properly adapts to different screen orientations, sizes, and DPIs.

When changing orientation the OS will send your application a size event. Make sure you are taking action on this event: OnSize (if a managed) or WM_SIZE (for native code). For example, you may need to reposition some of your user interface elements. For a great in-depth article on this topic, check out: Adaptable Apps For Windows Mobile.

Test, Test, and Test again

Take advantage of the plethora of emulators that are included with the SDKs / DTKs. The emulators support screen rotation (press the Calendar button) and come in multiple DPI and screen sizes. See here for a blog post on how to automate this process: PowerShell and Quick UI Check for WM Applications. Best case is to test on at least one device that ships in-market as some scenarios are difficult to test sufficiently within the emulator.

Need additional Help?

Hopefully these tips will help you avoid certification testing failures, if you need help with your specific test failure, use the Support link in the developer dashboard to create an email support request. Just be sure to include all identifying information regarding your application including the product id. The Marketplace certification team will respond within 48-business hours.

Thanks,

Mike

Marketplace Momentum

Todd Brix — Tue, 16 Feb 2010 14:02:00 GMT

Being at this year’s Mobile World Congress in Barcelona has me feeling both excited and proud. I’m excited to show off Windows Phone 7 Series and eager to dig into the details with our developer community at events like GDC and MIX next month. MWC also marks the one year anniversary of the promise we made to deliver a new kind of application marketplace in Windows Marketplace for Mobile. I couldn’t be more proud of the marketplace that Microsoft, the developer community, and our MO partners established and am pleased to announce several new development tools and updates.

For the past year we’ve been working to create a new kind of application marketplace; one that delivers quality applications and a great shopping experience, while offering developers a more direct opportunity to reach customers with clear guidance and insight into certification standards and processes. Marketplace has only been available for four months and in that time I have been pleased to hear from several of our partners about their apps taking off. Where some application stores optimize for high volume and low price, we reasoned that customers and developers alike would benefit from a marketplace that offered high quality certified applications that are priced and merchandised to reflect their value to customers. So far it’s working. For the last 4 months, while the average asking price of all paid apps is $6.26, the average app sales price on Marketplace is $5.36. This low delta between average asking and sales price reflects a high symmetry between perceived and actual value. To date, we feature more than 1245 applications from more than 1325 registered ISVs.

In addition to helping developers reach customers and make money, we’ve continued to improve the predictability and speed at which we do vetting and certification. Since we launched in October, our average vetting time has dropped from 30 to 10 days and our average time to certify has dropped from 12 to less than 5 days with less variation.

Some of the biggest beneficiaries of Windows Marketplace are the winners of our Race to Market Challenge, the contest launched last summer to see whose apps could generate the most downloads and revenue in the first 100 days. For months, ISVs competed for early access to a new market of Windows Phone customers … some may also have been motivated by the grand prize, a Microsoft Surface table. Well, we’re just passed the 100 day mark, and I’m pleased to announce today our winners who have combined great applications with effective marketing and pricing strategies to win!

The winner for most downloaded app is Meon Lite from Manbolo. Manbolo did a great job of releasing early (3 days after the marketplace opened) and used a compelling free version of Meon to drive broad awareness and then converting interest into upsell sales of its full purchase product. Congratulations! Check out Meon Lite and download it now here.
The winner for highest value generated is SPB Mobile Shell from SPB Software. SPB executed its pricing strategy very well by setting a $29.99 price in the US that reflected its real value to optimize total revenue. Congratulations SPB Software! Check out Marketplace’s best selling application and download it now here.

As for the Marketplace service itself, over the next few days we will be rolling out several important updates to enhance the experience for both customers and developers.

Customer experience improvements

World View: A new World View feature will allow Marketplace users to browse and purchase applications from a different geographical catalog. For example, a customer here in Barcelona could choose to browse the English US catalog, or a customer in Canada could browse the catalog from Japan.
Installation onto storage cards: Customers are downloading a lot of apps, sometimes more than the memory available on the phone. So, we are now enabling people to install applications downloaded from Marketplace onto storage card memory.
Better application discovery. As the selection of apps grows, we want to make sure customers can find the application they’re looking for and introduce new simple ways to discover apps they might be interested in. First we’ve added a smart search function that enables users to search for apps or games that include any of the terms included to describe the apps, so customers get more relevant search results on the phone or the web. Second, we’ve added an additional viewing option we call the Themed Showcase that organizes applications by genre, interest, seasonality, theme or even an ISV specific view for those ISVs with a lot of applications or games
New store opening. We’re also now opening Marketplace for commerce in Russia, enabling Windows phone users in one or the fastest growing Windows Phone markets to buy apps, and developers and ISVs based in Russia to submit them. Welcome!

For additional exciting announcements in the consumer space, be sure to check out Liz Sloan’s blog here.

Developer experience improvements

Free app submissions to additional markets: ISVs will no longer have to pay a $10 fee for submitting applications to additional markets. Once an application has been certified for a primary market as part of the existing $99 submission fee, ISVs can now submit for free that same application to as many other catalogs as they want, as long as they meet the current Market Validation guidelines.
Applications policy changes: We are also taking this opportunity to make some changes to the existing application acceptance policies, and are now allowing VoIP applications that use a carrier network, unless explicitly prohibited by a mobile operator.
Improved registration, submission and management process. We’ve welcomed and acted on a lot of feedback from ISVs on how we can improve things. We’ve listened, and fixed a lot of the problems and annoyances you’ve told us about to make it easier to register, submit applications for multiple markets, and simplify the update process. You’ll see them all over. Tell us what you think and keep the feedback coming

I’m also happy to share that we are introducing a Windows Mobile 6.5.3 Developer Toolkit (DTK) which includes support for a new generation of Windows Mobile 6.5 phones that include capacitive touch screens. For a quick summary of the differences between the SDK and the DTK, I encourage you to read this blog. The DTK comes packed with some pretty cool new features you can add to your application like a Bing Map Control, Widget VS Integration, Bubble Tiles, Auto Dialog Layout, and more. I encourage you to download the DTK here and take advantage of some new tools and new features.

Finally, I’d like to take this opportunity to tell you about a new twitter account @toddbrix, I’ve set-up to more frequently share my thoughts on commercial, merchandising and marketing best practices, opportunities and ahead of the curve insight to make the most out of your investment on Windows Phone both now and with the upcoming release of Windows Phone Series 7. Speaking of which, I’d also encourage you to follow Charlie Kindel, @ckindel as he will be sharing more about the upcoming Windows Phone 7 Series development platform. We’ll also be sharing a lot more about both our development platform and marketplace service at MIX10 hope to see you there.

We told you last year that we would deliver a new kind of application marketplace, and we told you in October that we’d continue to deliver a meaningful updates to Windows Phones and Windows Marketplace for Mobile. We are excited to stand true to our promises and look forward to an exciting year.

Stay tuned, we’re just getting started!

Todd Brix

Windows Phone 7 Series – Going Big for Developers at MIX10

Eric Urban — Mon, 15 Feb 2010 14:01:00 GMT

In a companion post on the Windows Phone Blog, we have unveiled the highly anticipated Windows Phone 7 Series. For the first time ever, we are bringing together Xbox LIVE games and the Zune music and video experience to phones. Developers are already speculating about the app platform and tools. All I can tell you is that we are going big at MIX10, March 15-17.

I will proudly say that we are about to launch a very compelling mobile development platform – arguably the best in our history. Even if you can’t join us at MIX this year be sure to follow Charlie Kindel, @ckindel for regular updates on the developer story for Windows Phone.

You can read the full Windows Phone 7 Series press release here.

Windows Marketplace for Mobile: Advanced Anti-Piracy Protection

Mike Francis — Fri, 15 Jan 2010 23:16:52 GMT

If you are developing applications for Windows phone, you have probably read about the Standard and Advanced Anti-Piracy Protection available to developers to help protect your hard developed IP. If you haven’t done so yet, check out the Windows Marketplace anti-piracy model white paper available here. Advanced Anti-Piracy Protection (AAPP) is designed to thwart the illegitimate sharing of your Windows phone applications. Even if a hacker obtains the binaries from one device, AAPP will prevent that application from running on any other device. While Standard Anti-Piracy protection does not require any intervention by the developer, AAPP does require that you integrate code into your application. We will walk through how AAPP works, how you obtain the AAPP code from Microsoft and how to integrate the AAPP code into your application.

How Advanced Anti-Piracy Protection works

Installation Time: The Marketplace Client installs a license, derived from the application id and the device id, into the registry. The license is protected using RSA security.

Application Run Time: The startup code (obtained from the Marketplace section of the Windows phone Developer Portal) in your application verifies that the license stored in the registry matches your application. You (the developer) has control over the error handling. You can choose to display an error and quit, shift into ‘demo’ mode, or do whatever you deem appropriate.

How to obtain the AAPP Code

Obtaining the AAPP code is part of the application submission process. You will see the following at Step 3 (Product Info).

Clicking on ‘Show Managed Code…’ we see the following code:

 using System.Runtime.InteropServices;
using System.Security.Cryptography;
using System.Text;
// ....
static string m_certModulus = "a26T2aaMKaafWSaI5JOaaQ7...";
static string m_certExponent = "DUPQ";
static string m_appSku = "dddddddd-70e8-4b15-9c90-46fca72d6959";
[DllImport("coredll.dll")]
private extern static int GetDeviceUniqueID([In, Out] byte[] appdata,
    int cbApplictionData,
    int dwDeviceIDVersion,
    [In, Out] byte[] deviceIDOuput,
    out uint pcbDeviceIDOutput);
static void Main()
{
//Pre-Initialization code
// ....
byte[] licenseBytes = 
    Microsoft.Win32.Registry.CurrentUser.OpenSubKey(
    "Security\\Software\\Microsoft\\Marketplace\\Licenses\\")
    .GetValue(m_appSku) as byte[];
string data = m_appSku.ToLower() + " " + GetUniqueDeviceID();
RSACryptoServiceProvider rsa = new RSACryptoServiceProvider();
//Create a new instance of RSAParameters.
RSAParameters RSAKeyInfo = new RSAParameters();
//Set RSAKeyInfo to the public key values. 
RSAKeyInfo.Modulus = Convert.FromBase64String(m_certModulus);
RSAKeyInfo.Exponent = Convert.FromBase64String(m_certExponent);
rsa.ImportParameters(RSAKeyInfo);
byte[] bData = System.Text.Encoding.ASCII.GetBytes(data);
if (null == licenseBytes || 
    !rsa.VerifyData(bData, new SHA1CryptoServiceProvider(), 
    licenseBytes))
{
    MessageBox.Show("Could not verify signature");
}
else
{
    MessageBox.Show("License is valid!");
}
// ...
// Post-initialization code
Application.Run(new Form1());
}
 
public static string GetUniqueDeviceID()
{
// Call the GetDeviceUniqueID
byte[] appData = Encoding.Unicode.GetBytes("Marketplace");
int appDataSize = appData.Length;
byte[] outData = new byte[20];
uint outSize = 20;
GetDeviceUniqueID(appData, appDataSize, 1, outData, out outSize);
StringBuilder resultSB = new StringBuilder();
foreach (byte b in outData)
{
resultSB.Append(string.Format("{0:x2}", b));
}
return resultSB.ToString();
}
 

Integrating AAPP Code into your Application

This code has all the basics you need to implement the Advanced Anti-Piracy Protection. However there are a few gaps that you need to fill-in. I’ve put together a sample (HelloAAPP) that has these issues worked out. You can download it from here.

The code provided by the portal does not catch NullReferenceException thrown by the Registry class if the license key cannot be found. This is most commonly caused by installing the CAB outside of the Marketplace client. This is because during installation, the Marketplace client installs the license into the registry. Most often you will see this during your own ad hoc testing. To help you avoid this error, in Debug mode, the sample installs a test license into the registry. Additionally the sample includes a handler for this exception.
In the portal code, if the validation succeeds or fails, the application will still run. In most cases you will want to notify the user and exit. The sample displays an error message and the application exits following the users response.
In the portal code, if the validation succeeds, the code will notify the user telling them so. This notification is probably not necessary in a real world scenario. The sample simply continues if the validation succeeds. Note that in the sample the same validation (VerifyData) is called in both Debug and Release modes. In Debug mode the test license is validated using the test key. In Release mode the real license is validated using the public key included in the developer portal code.
In the portal code, the error message does not have any context. A (hopefully) clearer message “License verification failed. Please install via Windows Marketplace for Mobile.” is used in the sample.
In the portal code, there is no way to test the validation logic since there is currently no way to install a license. As mentioned above, the sample creates and uses a test license that tests the validation logic. This goal of the sample is to demonstrate a way to use a test license in Debug mode and a real license in Release mode with all other code being the same.
The error message is not localized. In the sample, the message is localized in English and German (de-DE).

Please let me know in the comments if there any other gaps in the AAPP code that you have had to fill.

Thanks,

Mike

New Windows Mobile Developer Certificates

Larry Lieberman — Tue, 12 Jan 2010 19:43:52 GMT

As of 12/31/2009 the test certificates that shipped with the Windows Mobile SDK expired. However, we’ve gone ahead and generated new certificates that you can drop in to rectify this problem.

If you’re a developer you can put these certificates right into Visual Studio (or sign via command line). If you’re a tester, you can follow these instructions to create a provisioning file for a device, so that you don’t need Visual Studio to push certificates onto test platforms.

Download new certificates here.

Windows Marketplace for Mobile – a Worldwide Marketplace for Developers

Frank Prengel — Wed, 18 Nov 2009 11:35:00 GMT

Hello there, my name is Frank Prengel, and I’m a technical evangelist at Microsoft Germany, helping the Windows phone and Marketplace teams establish Windows Marketplace for Mobile in my country. Since I work with the German developer & ISV community, let me share with you some thoughts from a local perspective – they may help you develop for Marketplace, especially if you live outside the US.

Let’s first remember that Windows Mobile has always had a very active developer community, and that it gives you freedom in how software is developed and distributed. There are more than 20,000 Windows Mobile applications today which you can get and install from Web sites, software portals, forums, etc. – provided you are a tech savvy person, and you know how to do it. With Windows Mobile 6.5 we have begun addressing non-tech savvy consumers as well. This is exactly why we introduced Windows Marketplace for Mobile as an easy way for people to find and install additional software on their new Windows phones.

If you are a developer, this means one thing for you: an additional great opportunity to potentially reach millions of new customers. Windows Marketplace launched with commerce in 20 markets as well as developer registration support in 29 markets, more than any other app store at launch. It offers credit card as well as mobile operator billing, and self-serve refunds of certified apps. It now supports Windows Mobile 6 and 6.1 and even allows for browsing and purchasing apps from the PC, with over-the-air synchronization to the user’s Windows phone. If your goal is to expand your business or the reach of your software, you should take the opportunity to join. For more information on the recent Windows Marketplace updates, including availability on 6 and 6.1, accessibility to browse and purchase apps from the PC and antipiracy protection benefits for developers, check out Todd Brix’s blog post at the Windows Mobile Developer Blog, and Eric Nelson’s post at the Windows Phone Blog.

As with every retail marketplace, there is a bit of administrative work involved. Windows Marketplace for Mobile is a new service and a fresh approach that improves frequently with feedback from the developers and ISVs we work with. We are committed to continually improving the entire experience as we learn more about developer and customer needs and behavior. (If you find that Marketplace is not the right distribution channel for your business model, after all, you can of course use any other channel, such as those mentioned above, as they continue to be available. Windows Mobile means freedom of choice.)

If you are in the US, signing up and getting apps certified should be pretty straightforward by now. In other countries there may be additional steps related to the business and financial processes involved. There also is localization work to be done when you want to submit products to several markets, as the application needs to be localized in the proper language (including the screenshots and descriptions). If there are any questions during this process, your first support resource is the Windows Marketplace help page. You can also use the contact form in your Windows Marketplace portal, and ask for help or information. Then, we have a dedicated forum where team members try to answer your questions as quick as possible.

Beyond all that, in some countries there are additional dedicated resources that you should know – let me take Germany here as an example: We have a dedicated Windows phone blog with news and a contact form for questions, we have our local Windows Mobile Developer Center on MSDN, a Twitter channel, a comprehensive introductory document on Windows Mobile development, a webcast series – we even have an exciting local developer contest which complements the global one!

You see, there are a lot of great resources that should help you get started with Marketplace. Don’t miss this great opportunity to expand your mobile business. Good luck!

Frank

Announcing New Features in Windows Marketplace for Mobile

Todd Brix — Wed, 11 Nov 2009 21:47:58 GMT

I’m pleased to introduce a few much anticipated upgrades for Windows Marketplace for Mobile going live today. We introduced Windows Marketplace with the launch of Windows phones on October 6^thand promised a second wave of features in November. Today, we’re adding more advanced anti-piracy protection and an improved developer portal for our registered ISVs, as well as introducing PC based shopping and account management for Windows phone customers.

Developer portal improvements and stronger anti-piracy protection

We’ve been gathering input on what we can do to improve the developer experience and have made some subtle but important enhancements to the developer portal to enable easier uploading of images, greater insight into account status and several other refinements based on feedback from developers. Today’s update also provides more advanced anti-piracy protection. While the underlying technical changes will be transparent for customers, developers will now be able to take advantage of these new protections by following the steps outlined in this anti-piracy whitepaper. As always, updates to existing applications can be submitted for free. To learn more about developing applications for Windows phones, head over to the Windows Mobile for Developers site.

Browse and buy applications from the PC
While we’ve heard great feedback on the Marketplace experience on Windows phones, sometimes people just want the benefits of a shopping on a PC. Starting today, Windows phone customers can browse, buy and download applications online at the Windows Marketplace for Mobile site. The selected applications are delivered wirelessly to the customer’s Windows phone and install the next time the Windows Marketplace client runs on the device. This creates another way for customers to easily find and purchase applications and gives developers a whole new level of exposure.

Marketplace has been extremely active and I couldn’t be happier with the reactions from both developers and customers. We’ve been open for just over one month and already we can see that there’s demand for an application marketplace that doesn’t compromise on quality or experience. I look forward to providing a more detailed update on Windows Marketplace for Mobile when we extend the service to Windows Mobile 6.0 and 6.1 customers later this month.

The Windows Marketplace for Mobile Client and your Setup code

Mike Francis — Thu, 29 Oct 2009 19:17:45 GMT

The Windows Marketplace for Mobile client provides users a streamlined experience to purchase and install applications on their Windows Mobile 6.5 devices (coming soon for 6.1, and 6.0).

As you will notice when installing applications, the user interface is different from the typical CAB file installation (see below) perhaps you are used to.

It is very important that the Marketplace install experience be uniform and streamlined. To keep it this way, no custom UI (errors, prompts, informational messages, etc.) should be displayed during installation or uninstallation.

If you absolutely must display custom UI, there are some things you should know about the Marketplace client.

The Marketplace client achieves a streamlined experience by suppressing the normal user interface, displaying a client specific progress bar and providing feedback when the installation has completed. This can cause problems for applications that have custom prompts implemented in the setup dll. For example, you may want to prompt the user to start your application after installation has completed. This is easily done by adding the appropriate MessageBox prompt to the Install_Init export of your setup dll. However, there can be problems with this.

The foreground display of your MessageBox or other custom UI, depends on knowing the window handle of the calling process. When your application is installed with the Marketplace client, no window handle is passed to your setup DLL’s exported functions. This can cause your custom UI to not be displayed in the foreground. This causes confusion for the user since it looks like the installation is still running, but there is no UI feedback. The only recourse for the user is to use task manager to locate the prompt window and select it to bring it to the foreground. This is a very poor user experience.

You can resolve this by using the MB_TOPMOST | MB_SETFOREGROUND flags when calling MessageBox or WS_EX_TOPMOST when creating a window for custom UI.

Have you tried the Marketplace client yet? No? Don’t have a 6.5 ROM update or device yet? No problem. Download the Windows Mobile 6.5 standalone emulator images here. These come with a fully functional Marketplace client you can download and install apps with.

Hope this helps.

Mike

Widget Anatomy – Touch and D-Pad inputs, oh joy!

Jorge Peraza — Wed, 28 Oct 2009 01:00:00 GMT

This is fifth and final part of my Widget Anatomy series that described the ins and outs of the Widget Framework that shipped with windows mobile 6.5. In this installment we will discuss the different ways a Widget can receive inputs from the user and how best respond to them.

First the easy one: Touch

Touch is the primary input for all our professional devices and it looks like they will be a significant percentage of our device offering. Handling this is fairly easy since the browser engine translate the touch event into a mouse click which can be handled by using the onclick event handler as shown in the following example:

        1: <html>

       2: <head>

       3:     <script type="text/javascript" src="js/ImageSearch.js"></script>

       4: </head>

       5: <body>

       6:     <div id="SearchBox">

       7:         <input id="SearchQuery"/>

       8:         <img src="images/search.png" class="searchIcon" 
               onclick="doSearch();" />

       9:     </div>

      10: </body>

      11: </html>

It is important to note that, since there is no “mouse” for widgets most of the other mouse related events like onmouseover, onmousemove, etc will not be triggered in a reliable enough way to use them.

Now the hard one: The Directional-Pad

I been making special emphasis to the fact that Widgets work seamless across all Windows Phones so, we need to ensure that the can be used correctly when the user interacts with it using the directional path.

It is important to note that, unlike IE6, a The widget framework will respond to a D-Pad input event by moving the focus to the closed actionable element in the direction of the user click. This behavior is similar to the old pocketIE and among friends we call it “Link to Link navigation”.

An actionable element is defined as any DOM element that can receive focus (Like a form field) or an element that implements its onclick event handler. When an actionable element gain focus the onfocus even is triggered, the same way, the focus is moved away from the element the onblur event is triggered. Now we can easily use those events to show the user where the focus is since the Widget Framework does not automatically highlights the focused element. We do this because we don’t want to inhibit the creativity of the widget creator to design his/her own focused highlight strategy.

The only “little” extra detail is that all elements that can gain focus need to have the tabindex property defined (the value is not important). This is easily forgotten but if not set, the focus and blur events will not trigger,

    <html>

    <head>

    <script type="text/javascript">   1:     2:     function OnFocus(element) {   3:         element.style.backgroundColor = "red";   4:     }   5:        6:     function OnBlur(element) {   7:         element.style.backgroundColor = "white";   8:     }</script>

    </head>

    <body>

    <div onfocus="OnFocus(document.getElementById('one'))"

         onblur="OnBlur(document.getElementById('one'))"

         onclick="alert(1)"

         tabindex=1>

            <p id="one" style="font-size:medium:">1</p>

    </div>

    <div onfocus="OnFocus(document.getElementById('two'))"

         onblur="OnBlur(document.getElementById('two'))"

         onclick="alert(2)"

         tabindex=2>

            <p id="two" style="font-size:medium;">2</p>

    </div>

    </body>

    </html>

In this example, we created two divs that can receive the input focus, you can move from one to the other using the D-Pad, the element that receives focus changes the color of its background to red.

Conclusion

Writing Windows Mobile applications is now as easy as writing a web page, and, by following some best practices your widget can be as functional and attractive as any other native application on the platform.

This is the end of this blog series and since Windows Phones are now available on many countries, you should go get one and write many cool widgets for it. Don’t forget to share the results with the world by uploading them to the marketplace!

Until next time

Jorge Peraza

Widget anatomy series at glance

#1 The manifest

#2 The keys for a great user experience

#3 Performance and battery life

#4 Security insights

#5 Touch and D-Pad inputs, oh joy!

Widget Anatomy – Security Insights

Jorge Peraza — Thu, 15 Oct 2009 22:45:00 GMT

Previous post: Widget Anatomy – Performance and battery life

This is part four of my Widget Anatomy series which which will explain the ins and outs of the Widget Framework that is shipping as part of Windows Mobile 6.5. In this installment I will discuss the Widget Framework’s security model..

Inside the sandbox – The Widget Framework security model

It is true, Widgets are executed inside a sandbox, and because of this, there are bounded to a rather strict security policy but can be summarized as follows:

Widgets can’t read files from the device nor can access the registry directly. A notable exception are all files that are part of the Widget package itself.
Cookies can be used as temporary storage but developers are encouraged to use the persistent storage API instead. Cookies, browser history and local cache are isolated per widget and completely separated from the browser.
Widgets can’t navigate their main frame to any URL with the exception of fragment inside itself. You can use an iframe to open a web URL though.
Widgets can navigate to the following specific purpose URIs

URI	Description	Example
SMS:	Starts composing an SMS message addressed to the given phone number	sms:1111111111
mailto:	Starts composing a mail message using the specified parameters (Like destination, subject and body)	mailto:test@test.com?subject=Hello?body=From%20Here
callto:	Initiates a voice call to the given number	callto:1111111111
tel:	Initiates a voice call to the given number	tel:1111111111
http:, https:	Opens the specified URI using the default browser.	http://www.microsoft.com

Widgets and the Marketplace

Windows Mobile 6.5 restricts distribution of Widgets to trusted sources only. This means consumers will only be able to install widgets from the Marketplace and, on some cases, Mobile Operator stores directly. This restriction was implemented because we don’t currently support digital signature verification for widget files which prevents users from being able to verify the origins and authenticity of any given widget. This might seem a little restrictive but I believe it provides the right balance between security and flexibility, specially if you consider that there are ways to allow enthusiasts and developers to install widgets from non-trusted sources, as long as they acknowledge and understand the risks of doing so. Use your best judgment :).

Other important security considerations

The local persistent storage is unencrypted, use caution when storing information that should be protected in clear text.
The widget ID is sent to the server as part of the user agent string if you would like to use it on your server for any reason.
Widget files are stored unencrypted on the device file system so anyone with device access can potentially read them.
Cross domain data access is allowed, this is super important for widgets since they can be used to mash up data from multiple sources.

That’s it for now, feel free to comment about any other security related questions that were not covered.

Next post: Widget Anatomy – Touch and D-Pad inputs, oh joy!

Marketplace Client, Your Applications, and Registry Keys

Mike Francis — Tue, 13 Oct 2009 00:25:42 GMT

The Windows Marketplace for Mobile is off to a great start since its release October 6th. One issue that has tripped up a few developers submitting their applications has been the use of internal registry keys used to determine the location of the application. Some clever developers have discovered that there is a list of installed applications stored in the registry under: HKEY_LOCAL_MACHINE\Software\Apps. Under the application name, you will find the directory in which the application has been installed. For example:

HKEY_LOCAL_MACHINE\Software\Apps\Company Application Name
InstallDir=”\Program Files\Application Name”

a similar list can be found here:

[HKEY_LOCAL_MACHINE\Security\AppInstall\Company Application Name]
InstallDir=”\Program Files\Application Name”

Since Windows Mobile does not support the concept of a current working directory, this has been one way to determine where the EXE is running from. A better approach, that is not dependant on these registry keys, uses the following code (See Chistec’s blog post):

GetModuleFileName(GetModuleHandle(NULL), pszFullPath, MAX_PATH);

For managed code (See Chistec’s blog post):

using System.Reflection;

private string GetApplicationExe()
{
  // Determine the full path to the application executable
  return Assembly.GetExecutingAssembly().GetName().CodeBase;
}

You can then parse out the application path from the returned file name.

So what is wrong with using these undocumented registry keys? When your application is installed by the Marketplace client, it creates these registry keys, but not with the names you would expect. Therefore, if your application is relying on any of these keys, if will fail to find them, because they will not exist. This has tripped up a few developers because this issue does not surface unless you install the application after it has gone through the Marketplace ingestion process. (The processing of your application after it has passed certification testing.)

To summarize, if you need to get the directory in which it was your application was installed, use either the native or managed APIs above. Also, make sure you are not using either of these undocumented registry keys.

Thanks,

Mike