At the Columbia Windows 8 DevCamp this weekend, the topic of side-loading apps came up in a few different scenarios, but it was particularly appropriate during the app showcase. We had a number of developers working in the lab room, all competing to come up with the coolest app at the end of the day. During the showcase where developers pitch their apps to the audience, it works best to have all the apps on the same machine. Here’s the best way to do it without having to copy source code/solution files: From within Visual Studio, select Project > Store > Create App Packages: In one situation, where there happened to be multiple projects in the solution, these options were disabled. Why I’m not exactly sure, but you can also create the app packages by right clicking on the project in solution explorer, and selecting Create App Packages in a similar way: On the dialog windows that pops up, select No to build packages to upload to the store, as we’re not doing that: On the next screen, configure any path/build options (defaults are usually ok) and click Create: Once the packages are created, you’ll see the following folders: We can ignore the .appxupload files for now. For loading on another machine, we’ll need to copy either the x86 or ARM (or both) to the target machine (for the devcamps, we just pass around a USB key and have everyone copy the files there). On the machine you’d like to install the apps, run the PowerShell script (right click file, select Run with PowerShell). Of course, if you’re on a Surface or other ARM device, you’d need to run the PowerShell script from the ARM folder, otherwise use the x86: Once running, you may be prompted to install a certificate and need to accept a UAC prompt. You’ll then see the app install: Viola! The app should be installed on the Windows 8 Start Screen.
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
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.
By way of Glen Gordon: Two great community guys – Chris Eargle and Chris Williams - are setting up community led Windows Phone Garage events next week in Columbia and Greenville. Remember, at a Windows Phone Garage you get instruction on the basics of creating Windows Phone apps, but also you get a lot of time to build your app, with help from onsite experts. In addition, one attendee who showcases his app (in development or complete) at the event will win a free Windows Phone device! Register ASAP and make plans to attend this free event. Columbia, SC – Thursday, June 16 at Midlands Tech Greenville, SC – Friday, June 17 at Immedion Unfortunately I won’t be there as we’ll be in Florida doing our Azure Tech Jam events, but the events are in great hands with Chris2.
In a few weeks, my colleagues Glen and Joe will be in Charlotte (and a few other locations around that time) holding their successful Windows Phone garage events. The latest event is coming to Charlotte on May 24th! Here’s the breakdown: 9 – 10 am Introduction to Windows Phone Development No experience with Windows Phone 7 development? No problem. During this optional session at the start of the day we will cover the fundamentals of Windows Phone Silverlight and XNA Development. We'll explore the various core components and tools available, and leave you with some resources to take you to the next level. 10 – 10:30 am What’s new for Windows Phone Developers This session will highlight some of the new developer features coming for Windows Phone Developers. We’ll also take a look at AppMaker, a new dynamic new tool that enables you to generate a simple Windows Phone application from one or more online data feeds. 10:45 – 12:30 pm Windows Phone Application Jumpstart To give you a jumpstart on app development, we’ll walk through in detail building an app, styling it, and adding advanced capabilities. We’ll also cover submitting it to the marketplace and monetizing your app. 12:30 – 1:00 pm Lunch 1:00 – 5:00 pm Windows Phone Garage Open Lab Bring your laptop fully loaded with Visual Studio 2010 and the latest version of the Windows Phone Tools. Get some help with an app you are working on, or use the information from the Jumpstart to build an app around your favorite data feed. No ideas? No worries – we’ll have a few starter templates that you can build on. Other dates: New York City May 3, 2011 Cambridge, MA May 9, 2011 Alpharetta, GA May 19, 2011 Charlotte, NC May 24, 2011 Malvern, PA May 24, 2011 Tampa, FL May 26, 2011 Chevy Chase, MD May 26, 2011
I wanted to make my app experience as open as possible, so now that reporting for Windows Phone 7 app sales is out, I’m going to share my details with the world for those interested in developing for Windows Phone 7. First: device sales, as of this writing, have not been released by Microsoft. I don’t know them, and won’t speculate on what that means. As Joe B pointed out in his interview with Walt recently, it will be a process over time. But, now that reporting for trials/purchases has been implemented in the developer dashboard, let’s take a look at how SqueakBox is doing. SqueakBox is generally in the upper third of the entertainment section, getting good feedback, and providing a trial. Providing a trial is a key element that developers really should take advantage of. So, let’s log in at take a look-see: First up, when you log in to the reports you’ll see the following daily download stats: Overall I’m happy with the trend. We can also look at cumulative downloads, which is helpful to understand the trend which shows a fairly linear distribution: Next is purchase/trial information. Obviously this is important for conversion rates and, naturally, how much money I’m going to get. This is the second page of detailed sales data – the first page has more international usage, but decided to show only 1 screen above because it shows consumption in the US. As you can see, I’m doing best in my home turf and that’s not surprising. It’s an indie app, not internationalized, and while there are some sales abroad, it’s a small percentage. Now – what is the conversion? Here, we need to make an assumption the user downloaded the trial first. This may or may not be the case. A user could just click purchase (hey, it’s only 99 cents), particularly if they used the app on another phone. In that case, it would show up as a purchase – not a trial. Assuming folks downloaded a trial first, based on this page alone, we had 289 trial downloads, and 115 sales. That is a very good conversion rate if you ask me, since I download TONS of stuff with trials and many I haven’t even tried yet. I have to assume many users are doing the same. The big question I’m pondering is this: do I implement an ad in the trial mode? Currently, the app limits features/sounds hoping users will unlock them by purchasing. Optionally, I can unlock some of this, and implement the ads to bring in perpetual income, albeit much smaller. I’ve been cautious of the ad approach for the reasons I outlined in this blog post.
While this is by no means an exhaustive list, here’s what is catching my eye this week in the phone Marketplace: Shazam (Music & Video), Free Sample a few seconds of a tune, and Shazam uploads and parses what tune you’re listening to. Pretty cool. I’ll be honest, I’m much more interested in this technically than practically, wondering how the algorithms work, fuzzy matching, etc. Practically speaking, I would get a lot more use out this if radios didn’t do the “song ID” thing that is prevalent in most modern radios. Since it’s free, it’s a must download. Flight Control (Games/Strategy, Xbox Live), $4.99 (has trial) Lots of fun! You basically pilot an onslaught of aircraft and drag them to a landing strip. The game is surprisingly fun – but, what I like most about it is that it feels like it’s made for the phone – the touch interface is great. While it is upgraded from the iPhone version to contain achievements, the $5 price tag seems a bit high. BowlingXX (Games/Sports & Racing), $1.99 (has trial) The first bowling game for WP7. What I really like about the game is the controls. You can swipe your finger to set a ball path that determines trajectory/power/spin, or use the accelerometer and bowl “Wii-style.” This game would be a lot of fun to have online multiplayer, however for the price tag that’s not too feasible. OpenTable (Lifestyle), Free Great way to pick a restaurant last minute. Not too much in my local area, but I live in the sticks so I didn’t expect much. Nice, clean interface. The Eye (Games/Puzzle), $0.99 (has trial) Built by ‘softie Michael Hawker, a VERY tough puzzle game. :26 seconds is my best time, but it was purely accidental. The game has gotten a few criticisms of being too tough, but then again, so is the Rubik’s Cube. Essentially the game contains two outer rings that change color when you tap the inner ring. The idea is to rotate and change the colors until they are all the same solid color. It took me a little while to get how the game works, but I like the simplicity. BluesBox (Music & Video), $1.29 (no trial) This app has two strikes out of the box: no trial, and a (at first glance) vanilla interface. The single screenshot doesn’t help much. But, to see this in action, see this YouTube video. Looks cool! Think Guitar Hero with a bit more musical control. I think it’s worth the price of admission and seems like a lot of fun, but Mat needs to offer a trial and, since I’m sure this will sell pretty well, use the first couple hundred bucks to hire a designer :) Drum Machine (Entertainment), $0.99 (has trial) This app and BluesBox can team up! Actually, while Drum Machine isn’t quite as engrossing (IMHO) as BluesBox, DiNoGames nailed the interface and options, and was wise to include a trial. It’s pretty fun! Next time you want to nail someone with a “Ba-da-dum” you can either use my app (SqueakBox) or, drum it out yourself with Drum Machine.
This post has been updated on 21-Oct-2010 with new information contained in the last paragraph. Most developers realize you can bring in revenue through advertising, and the Microsoft Ad Control lets you do that easily in your Windows Phone 7 application. For most simple apps, you might offer a trial version that is fully functional but supplemented with ads, and a paid version that is ad free. Or you might just make your app free, supported only via ads. This is what I wanted to do with SqueakBox. I’m beginning to rethink this approach, though, and I’ll explain why. Before I explain why I’m rethinking this decision, let me explain why I thought this would be ideal. First, I’m a big believer in having trial versions of applications. This is proven with Xbox Live. To make it super simple, there is a trial API available. So this might sound harsh, but I don’t think there is much excuse for not providing a trial when it is so easy to do. I will say this: providing a trial does open you up a bit more in the ratings, since anyone will be able to rate your application. To make the trial better, I figure it should be fully functional and supported by an ad so there is no time bomb, etc. Regular users would rather pony up the 99 cents to get rid of the ad, while someone else would be content with seeing the ads – either way, the developer and the user wins. Above is a picture of the app running with the test ad (bing). If the user has the full version (IsTrial==false) we want to remove the ad – in order to do this, you must completely remove the ad control from the visual tree… you can’t just set it to disabled, set its visibility to collapsed, etc. I realized this after using Fiddler (as I mentioned in my last post) – essentially, the ad control continued to request ads even when disabled/collapsed: Obviously, this isn’t what you want to do in the full version! Fortunate that is an easy fix by removing the control. The next one, unfortunately, is why I might go back to the more traditional trial model. In the marketplace, applications list the capabilities of the phone they use. When I saw the app published, I noticed this: Whoa! Owner Identity and Phone Calls? No I don’t. Seeing an app that uses the sensors, media library, push notification, etc. – that sounds cool. But owner identity and phone calls? That sounds disconcerting to me. It turns out this is from the ad control. What does owner identity mean? I don’t know. This might be benign, like, “the ad is able to set a cookie that can identify the phone” – perhaps if you click through an ad that takes you to the marketplace, it has to know it’s *you*, so that’s what it means? Maybe the phone calls is for ads that allow you to make a phone call – like Bing 411. As the developer, I don’t know, and the user certainly wouldn’t know. (I got one factual but unhelpful internal reply which basically said, “developers can use another ad provider if they don’t like it.”) (Read 10/21 update below.) Users have no way of realizing this isn’t required in the paid version, so I’m left with a choice of leaving it in figuring users won’t really care, or taking it out to remove the requirement. What would you do? Other than the phone capabilities piece, the ad control is super nice and easy to integrate. [Edit] One thing I do want to point out: showing the features that an application uses is really a great idea. I don’t know how this works on other platforms, but seeing up front that an app needs access to data, sensors, etc., is great. [EDIT 21-Oct-2010] I just received an update from the Microsoft Advertising adCenter team. The Ad Control doesn’t use Owner Identity, and instead uses anonymized profile targeting parameters – such as age/gender). Also, it doesn’t use the “phone calls” feature but does use the dialer in “click 2 call” functionality (as I suspected). They are working with the marketplace team to get this updated so the capabilities list isn’t as alarming – when/if it will be changed? I’m not sure. So while the end user experience is still what it is, this is good info and was I happy to get the correct information.
On an internal alias, Eric Lawrence chimed in on setting up Fiddler for the Windows Phone 7 emulator. This is really useful, of course, for monitoring traffic to/from the emulator … since so many apps are use data services, this is a must have feature. The first step is to set the local machine as a proxy … in the IE LAN settings (or via the control panel) like so: In the Fiddler options, configure the Fiddler listen port and allow Fiddler to accept remote connections: In my app (SqueakBox), I display a user guide as a web page. I made this choice to facilitate changes (much easier to publish a new HTML page!) … if I open that page up in the emulator: I can see the traffic in Fiddler: Success! In my next post, I’m going to discuss two snags I ran into with the Microsoft Ad Control – one of which I discovered while using Fiddler.
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 squeakbox.net. 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 freesound.org 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.