Primer: The Windows Store Certification Process for Windows Phone Developers

As I travel around, I’ve met many people who are familiar with the Windows Phone application certification and submission process – it’s been around for a couple of years now!   Perhaps not surprising, though, is that few people I’ve met have the same comfort level with understanding the Windows 8 Store and understanding how that differs from traditional desktop applications and web applications. In this post, I’m looking not so much at converting an app (that will be another post) but instead looking at the certification process and any other gotchas I’ve experienced. Windows Phone 7 If you’ve stumbled on this post and haven’t considered Windows Phone development, here’s a quick way to get started.  Download Visual Studio Express for free, develop/test your app keeping the certifications in mind, create your MSDN App Hub account ($99/year), and submit your app.  I’ve been on both sides of the fence: as a developer, developing Windows Phone applications like Squeakbox, and as a tester, helping the WP app certification team test a few apps built to control Sonos music systems.   (My role as an app tester was only honorary – I’ve got a pretty big Sonos installation and could easily/eagerly try out the apps!).  Based on my experience and feedback from other developers and internal discussions, the biggest problems developers typically run into with application certification requirements relates to interfering with phone functionality, small app violation policies, and of course, technical certification requirements. Phone functionality is pretty easy to test for but often overlooked … how does the app respond when a phone call comes in?  How does it look in a light vs dark theme?    What about the back button?  App violation policies are often easily correctable – for example, with push notifications, the app must have the user opt-in and provide a way for the user to opt-out if they later change their mind.  Occasionally, there is some confusion over application capabilities, or app cap. Each application has a manifest file that includes metadata for the application – one of which lists all the capabilities the app needs.  This is important because these capabilities are displayed to the end user.  So, for example, Squeakbox allows you to record sound clips, play sound clips from the media library, respond to sensors, and uses push notifications (among other caps).  All of these are listed on the application page so the user may feel uncomfortable, say, if a simple app wants to use the phone contacts, for example. The confusion, though, is understandable and here’s why.  According to this document: For Windows Phone applications, you should specify the capabilities required by your application, such as networking, the location sensor, or the camera. If you do not accurately specify the capabilities, your application might not work correctly or it might fail the submission process to the Windows Phone Marketplace. You specify the application capabilities in the application manifest file (WMAppManifest.xml). Depending on whether you are targeting Windows Phone OS 7.1 or Windows Phone OS 7.0, you can use the Marketplace Test Kit or the Windows Phone Capability Detection Tool to detect the application capabilities. Seems simple enough.   But the manifest doc says: The application manifest file is generated in Visual Studio, and you should not edit the file manually.  <snip> Some of the values in the manifest file will be updated automatically after you submit your application to the Windows Phone Marketplace. Examples include the Author, Publisher, and ProductID attributes, and the CAPABILITIES element. So, you shouldn’t change the capabilities yourself, Visual Studio should handle it.  And even if it doesn’t, the Marketplace should be able to tell what capabilities are required, and override what you put in your manifest.  Some final considerations when testing:  It’s possible that one tester misses something another tester won’t.  That happened to me.   Above I mentioned that Squeakbox allows the user to record sound clips.  The app can also run while the screen is locked.  If you combine those features, you’re app can go into some possible eavesdropping territory.   It was something I never thought of, and something that didn’t get caught in the first submission.  So, consider how users might use your application. Finally, be sure to run the Windows Phone Marketplace Test Kit.  If nothing else, it will quickly determine if the core requirements have been met.   This can save you a LOT of time.  Links: Windows Phone App Hub (Where your account will be) Application Certification Requirements (Stuff your app will have to do, or not do!) Visual Studio Express for Windows Phone (Develop your app, if you don’t have Visual Studio) Windows 8 First off, there is no immediate way to get an app in the Windows Store, but you can create an account here to register applications for notifications.   However, if you have an app in development and would like to get it into the store, contact me.   Many apps are getting into the store via a gated review with a premiere field engineer -- a few weeks ago at TechEd, we helped do this for many people in our App Accelerator area.  The first step, though, is to have your app under development. If you haven’t seen the Windows Store yet (and why not?  You’re running the latest release, right?) then check out this video: From a certification standpoint, many of the requirements are spelled out in this document.   Most of these, particularly for WP7 developers, are expected… app mustn’t crash, limitations on advertising, opt-in consent, etc.   Some of the requirements that might require a little more thought: 3.5 Your app must fully support touch input, and fully support keyboard and mouse input Your app must provide visual feedback when users touch interactive elements. Your app must not use an interaction gesture in a way that is different from how Windows uses the gesture. The Windows 8 touch language is described in Touch interaction design. The Touch Interaction Design, which part of the UX Guidelines, does a good job of illustrating this. And: 3.6 Your app must use the mechanisms provided by the system for those features that have them Your app must support a snapped layout. In landscape orientation, your app’s functions must be fully accessible when the app’s display size is 1024 x 768. Your app must remain functional when the customer snaps and unsnaps the app. Your app must neither programmatically close nor offer UI affordances to close it. Windows 8 Process Lifetime Management closes Metro style apps automatically. Your app must suspend and resume to a reasonable state. If your app implements an app bar, that bar must show up with a bottom-up swipe. If your app implements a navigation bar, that bar must show up with a top-down swipe. Doesn’t the one about not offering a way to close itself ring a familiar bell from the Windows Mobile and Pocket PC days?  I remember the arguments then.    But seriously, having applications snap to one side is a great feature of Windows 8 and something you’ll need to keep in mind.  Some apps, like email, calendar, twitter client, etc., are naturals for this type of behavior, others are a bit more difficult.  Check out what some of the applications are doing today when you snap them beside another app. Another easy to miss requirement but not surprising, for apps that use streaming data: 4.5 Your app must protect customers from unintentional large data transfers over metered networks Notifications If you’re used to notifications in Windows Phone, there’s good news and bad news.  The good news:  conceptually, it’s the same.  Tile notifications to update the live tiles with relevant data, toast notifications that presents the info to the user that allows them to interact, and raw notifications to send data directly to the application.    Conceptually (hat tip to Nick Harris for the pic), nothing is really different: Your app requests a notification URI.  Presumably, you’ll have a web service running somewhere (preferably in Windows Azure!) that receives the channel URI and any relevant information for your app (username, zip code, twitter handle) in order to tie the channel URI to a specific user (bear in mind a user might have multiple channels if they have multiple machines). However, instead of simply requesting and using a channel URI to send a notification, you’ll need to register the application first and authenticate, via an OAUTH token, to the push notification service.  This provides a good security layer to prevent notifications from untrusted services and authenticates you as the application owner. Nick Harris has a good rundown of the procedure on his blog.  Links: Win8 App In 30 Days Generation App Windows 8 Dev Center Windows 8 Certification Requirements Windows 8 Touch Design Windows 8 Performance Best Practices

Azure and Phone … Better Together

We had an excellent time presenting today’s Windows Phone Camp in Charlotte. Thank you to everyone who attended. Here are some resources and major points of today’s “To the cloud…” session. First, here is the slide deck for the presentation.  To The Cloud... Next, download the Windows Azure Toolkit for Windows Phone. This contains both the sending notifications sample, and the Babelcam application. Note that there are quite a few setup steps – using the Web Platform Installer is a great way to make all of this easier. The key takeaway that I really wanted to convey: while the cloud is most often demonstrating massive scale scenarios, it’s also incredibly efficient at micro scale. The first scenario we looked at was using Azure Blob Storage as a simple (yet robust) way to host assets. Think of Blob Storage as a scalable file system with optional built in CDN support. Regardless of where your applications of hosted (shared host, dedicated hosting, or your own datacenter), and regardless of the type of application (client, phone, web, etc.) the CDN offers a tremendously valuable way to distribute those resources. For MSDN subscribers, you already have access so there’s no excuse to not use this benefit. But even if you had to go out of pocket, hosting assets in Azure is $0.15/GB per month, + $0.01/10,000 transactions, + $0.15/GB outbound bandwidth (inbound is free). For small applications, it’s almost free. Obviously you need to do the math for your app, but consider hosting 200MB in assets (images, JS files, XAPs, etc.), a million transactions a month with several GB of data transfers: it’s very economical at the cost of a few dollars / month. In the second demo, we looked at using Azure Queues to enhance the push notification service on the phone. The idea being that we’ll queue failed notifications, and retry them for some specified period of time. For the demo, I only modified the raw notifications. In PushNotificationsController.cs (in toolkit demo above), I modified SendMicrosoftRaw slightly: [HttpPost]public ActionResult SendMicrosoftRaw(string userId, string message){ if (string.IsNullOrWhiteSpace(message)) { return this.Json("The notification message cannot be null, empty nor white space.", JsonRequestBehavior.AllowGet); } var resultList = new List<MessageSendResultLight>(); var uris = this.pushUserEndpointsRepository.GetPushUsersByName(userId).Select(u => u.ChannelUri); var pushUserEndpoint = this.pushUserEndpointsRepository.GetPushUsersByName(userId).FirstOrDefault(); var raw = new RawPushNotificationMessage { SendPriority = MessageSendPriority.High, RawData = Encoding.UTF8.GetBytes(message) }; foreach (var uri in uris) { var messageResult = raw.SendAndHandleErrors(new Uri(uri)); resultList.Add(messageResult); if (messageResult.Status.Equals(MessageSendResultLight.Error)) { this.QueueError(pushUserEndpoint, message); } } return this.Json(resultList, JsonRequestBehavior.AllowGet);} Really the only major change is that if the messageResult comes back with an error, we’ll log the error. QueueError looks like this: private void QueueError(PushUserEndpoint pushUser, string message){ var queue = this.cloudQueueClient.GetQueueReference("notificationerror"); queue.CreateIfNotExist(); queue.AddMessage(new CloudQueueMessage( string.Format("{0}|{1}", pushUser.ChannelUri.ToString(), message) ));} We’re simply placing the message on the queue with the data we want: you need to get used to string parsing with queues. In this case, we’ll delimit the data (which is the channel URI and the message of the notification) with a pipe character. While the channel URI is not likely to change, it’s a better approach to store the username and not the URI in the message, and instead do a lookup of the current URI before sending (much like the top of SendMicrosoftRaw does), but for the purposes of the demo is fine. When we try sending a raw notification when the application isn’t running, we’ll get the following error: Typically, without a queue, you’re stuck. Using a tool like Cloud Storage Studio, we can see the notification is written to the failure queue, including the channel URI and the message: So, now we need a simple mechanism to poll for messages in the queue, and try to send them again. Because this is an Azure webrole, there’s a way to get a “free” thread to do some processing. I say free because it’s invoked by the Azure runtime automatically, so it’s a perfect place to do some background processing outside of the main site. In Webrole.cs, you’ll see there is no Run() method. The base WebRole Run() method does nothing (it does an indefinite sleep), but we can override that. The caveat is, we never want to exit this method. If an exception bubbles out of this method, or we forget to loop, the role will recycle when the method exits: public override void Run(){ this.cloudQueueClient = cloudQueueClient ?? GetStorageAccountFromConfigurationSetting().CreateCloudQueueClient(); var queue = this.cloudQueueClient.GetQueueReference("notificationerror"); queue.CreateIfNotExist(); while (true) { Thread.Sleep(200); CloudQueueMessage message = queue.GetMessage(TimeSpan.FromSeconds(60)); if (message == null) continue; if (message.DequeueCount > 60) { queue.DeleteMessage(message); continue; } string[] messageParameters = message.AsString.Split('|'); var raw = new RawPushNotificationMessage { SendPriority = MessageSendPriority.High, RawData = Encoding.UTF8.GetBytes(messageParameters[1]) }; var messageResult = raw.SendAndHandleErrors(new Uri(messageParameters[0])); if (messageResult.Status.Equals(MessageSendResultLight.Success)) { queue.DeleteMessage(message); } }} What this code is doing, every 200 milliseconds, is looking for a message on the failure queue. Messages are marked with a 60 second timeout – this will act as our “retry” window. Also, if we’ve tried to send the message more than 60 times, we’ll quit trying. Got to stop somewhere, right?   We’ll then grab the message from the queue, and parse it based on the pipe character we put in there. We’ll then send another raw notification to that channel URI. If the message was sent successfully, we’ll delete the message. Otherwise, do nothing and it will reappear in 60 seconds.   While this code is running in an Azure Web Role, it’s just as easy to run in a client app, service app, or anything else. Pretty straightforward, right? No database calls, stored procedures, locking or flags to update. Download the completed project (which is the base solution in the toolkit plus these changes) here (note: you’ll still need the toolkit):  VS2010 Solution The final demo was putting it all together using the Babelcam demo – Azure queues, tables, notifications, and ACS. Questions or comments? Let me know.

SqueakBox for Windows Phone 7

While I spend most of my time focusing on Windows Azure and cloud computing, naturally as a developer evangelist I need to dive into Windows Phone 7.   I had an idea for an app (not overly original, I admit) and thought I’d explore developing this in my spare time.  The result is an app called SqueakBox and it’s currently up in the Marketplace. So what’s this app?  It’s pretty much the next gen of fart apps.  Instead of just flatulence (which I never really found all that funny, but they are in there), the app would focus on sounds effects for different situations.   My personal favorites are the crickets (great for meetings during long periods of silence) and the police siren (never fails to make the adrenaline of the driver skyrocket). While the idea isn’t incredibly original, I wanted the implementation to be best in class.  I implemented a ton of different play modes.  It can play on a timer, it can play when the device is moved.  But more interestingly, it can play when the room is quiet, and you can play sounds remotely through   You can loop sounds, create a playlist, and fiddle with knobs and dials like delays, backgrounds, etc.  In total, there are about 65 sound effects. But wait, there’s more! :)  In all seriousness, I get a bit annoyed by seeing these 99 cent apps that play ONE sound (there are already plenty of them in the marketplace).   Not much of a value, in my opinion.  So, I put a clip recorder in there so you can record your own clips, or import your own using the Zune library.  If you see a cool clip on or elsewhere, you can bring it in.   So while I’ve done my best to get a well rounded collection of sounds, there might be something you want to include – so go for it. Sales pitch over.  I’m going to create a new series of posts on some of the development challenges and document them here.  In the first post, I’ll discuss setting up Fiddler and the phone ‘capabilities’ that applications will use.   Stay tuned. 

My Apps

Dark Skies Astrophotography Journal Vol 1 Explore The Moon
Mars Explorer Moons of Jupiter Messier Object Explorer
Brew Finder Earthquake Explorer Venus Explorer  

My Worldmap

Month List