Excellent news! The $99 per app was wrong. See: http://windowsteamblog.com/windows_phone/b/wpdev/archive/2010/06/07/new-policies-for-next-gen-windows-phone-marketplace.aspx Thank you, Fred!
It's possible that somebody who didn't read closely looked at the old WM 6.X app cert docs, saw the $99 per app fee there, and thought it applied to WP7. I know people who "know people" and are investigating it. I'm very hopeful it's a mistake - see the end of my next post for how someone might have gotten confused. The rest of the stuff still irks me, but it beats that fruit company's products any day of the week! I'll post a further update if/when I get any more info.
I’ve been working on more helpful posts, but it seems that I keep breaking my nose on these walls I run into. I wanted to have a helpful post tomorrow or even later today. But instead I feel that it’s incumbent upon me to post about some things that are not good.
I love Windows Phone 7. I love everything I’ve seen about it. I love the sandboxing model they’re using. After I figured out tombstoning, I found that I love it too (especially (being primarily an XNA dev) not having to worry about stuff in the background eating resources and making your game look bad. I love writing code for it. I love the development tools. I love the look of Metro.
So what in tarnation is the title of this post all about then? Simple. On multiple occasions over the past two weeks, I’ve come up against problems that either didn’t have answers or that it took me hours of searching to find an answer for (one of the things you really learn how to do well in law school is efficiently research problems in multiple forms of media and it’s something I was really good at before law school so that’s a bad sign). Let me give you a few examples.
This here is the MSDN page on the "Hardware Specifications for Windows Phone". It lists a whole bunch of things. Two things it doesn’t list are the fact that the display is only required to be at least 16-bit (5 red 6 green 5 blue) and the fact that all Windows Phone 7 devices are also required to have FM radios. To find those out, you merely have to switch to the Programming Guide and go to the Design Resources for Windows Phone page (it’s one of only 20 topics so you’re bound to trip across it eventually) and then download the UI Design and Interaction Guide for Windows Phone 7 (PDF) and then make your way to page 67 of the PDF (pages 132-133 by the internal numbering) for the display depth answer and page 68 of the PDF (pages 134-135) to find out that all phones are required to have a radio (and that no control for it is being provided so if you want to use it you have to make your own). Now I knew the display thing from earlier since I spent an hour researching it to answer a question in the XNA Community Forums a few weeks ago. But several smart, knowledgeable, and resourceful people had no clue about this. What a surprise, right? It’s not like it’s buried on page 67 (133 by internal numbering) of some PDF file four layers deep on MSDN which is titled “UI Design and Interaction Guide for Windows Phone 7” – a name which in no way shape or form could lead anyone do believe that it has a single thing to do with hardware specifications. I also knew that there was a radio. But I didn’t know until I started writing this that the FM radio requirement wasn’t listed on the “Hardware Specification for Windows Phone” page but was also only buried in the unassumingly named “UI Design and Interaction Guide for Windows Phone 7” that is buried deep in MSDN rather than displayed prominently on the front page of the http://developer.windowsphone.com/ site with blinking arrows and a glowing neon “this is important and contains a lot of stuff you don’t know but that you absolutely should know if you expect to design anything that isn’t terrible” sign. Though to be fair, there’s also no blinking arrows or glowing neon signs for the Windows Phone 7 Application Certification Requirements (PDF), which is also absolutely mandatory reading BEFORE you start developing anything since it also contains all the content restrictions and special requirements for apps that want to do things like photo editing or be in the video and music hub. (There are hubs? Sure wouldn’t know that from using the intentionally borked emulator that hides everything about the phone’s interface such that you’ll have no idea how your app or game actually integrates into the user experience in any way shape or form).
But those aren’t even the problems I faced. After all, I participated in the jump start sessions and have been reading various MS employees’ blogs and all sorts of other media accounts of the WP7 for months now and I generally have a very good memory. No the questions I had were much more difficult. Take the FM Radio. There’s a whole FMRadio class for controlling the thing. And if you check out its Frequency property you’ll see that the property is a double, that its gettable and settable, and that if you assign a value outside the allowed set of values for the current region (there’s an enum property called CurrentRegion which is one of the values in the RadioRegion enumeration) that it’ll throw an InvalidArgumentException. Woe unto you who search for what the allowed values are. They don’t exist. There is no listing. If you examine the assembly with Reflector you’ll find that it only seems to check to make sure that the value is between 0 and 1000.0, which can’t be right at all since that range represents everything from shortwave radio to microwave ovens. And then there’s the fact that RadioRegion consists of three enumerators: UnitedStates, Europe, and Japan. Live in Australia or New Zealand? Sorry. Canadians? Too bad (though Canada and the U.S. actually use the same allocations for all relevant frequencies due to the large common border and historical cooperation in such areas during WWII and the Cold War). Any other country that doesn’t fit into those three regions? Who knows? So all Windows Phones are required to have an FM radio for which there is no Silverlight control, which doesn’t necessarily even have a control within the phone itself, and for which no useable programming interface exists (guessing what frequencies are ok based on what Wikipedia tells you about how frequencies are allocated in various regions isn’t a programming interface, sorry). So after six hours of research on that, I said forget it (though I used much stronger language) and gave up on the idea of building a Radio control “screen” to integrate into the Game State Management sample for the time-being (that was one of the posts I had planned to do – a how-to on the radio along with a screen any XNA dev could plug in to the GSM and add to their options menu and pause menu to let players who didn’t want to listen to the game’s music listen to the radio instead if they’d like). I also couldn’t determine from the documentation whether the region would be set properly (in which case you wouldn’t have to pester to the user to set it) based on location or if the region would always be, e.g., UnitedStates, and you’d have to get the user to set it (or do some sort of GPS location-based thing to locate the user and then parse that data to determine their location). But that’s moot anyway since there’s no way to just jump up/down a frequency gap (in the U.S., FM radio runs from the upper 80s to the upper 100s in .2 MHz increments using odd number – e.g. 101.5 MHz) and there’s no information on what frequencies (other than negative numbers) will actually throw an exception or about what are acceptable frequencies in the various regions or even an ability to set a region for NZ or Aus.
Next up trial mode. I could provide you all sort of links again, but suffice it to say, the documentation is confusing and the application programming interface is more of an application guessing interface. In XNA, all sorts of new features have been added to the GamerServices namespace to support LIVE on WP7. This is great. Only if you aren’t a registered developer with a top-secret decoder ring, you can’t actually use many of these features. That’s fine too – LIVE is a crown jewel of sorts and they only really want top-notch games to have access to achievements and leaderboards. They’ve also removed access to Avatars from the Indies. XBLIG Avatar games have been a combination of great and terrible so I guess I can understand why they did that (though Avatars are still available to Indies making XBLIG games – just not WP7 games). They’ve also shut off access to many of the other things Indies have access to on the Xbox, even things as simple as a player’s gamertag. But the documentation of what’s still accessible and what isn’t is spotty at best. Some classes have warnings that you need to be a Registered developer to use them, but others don’t. And calling Guide.ShowMarketplace (which, it turns out, is the way XNA devs should bring up the WP7 marketplace for their games) brings up a message on the emulator talking about the LIVE marketplace. Well all good XNA devs who are targeting WP7 know that all LIVE functionality is off-limits unless you’re part of the special program that lets you make games that use LIVE functionality. So any good developer might have questioned it (and questioned whether Guide.IsTrialMode would be valid as well, especially since the description page oozes Xbox360 and LIVE and contains el zilcho mentions of WP7) and instead delved into the Creating Trial Applications for Windows Phone page found in the Windows Phone Development Programming Guide section. Of course this is a nightmare in and of itself. It recommends that you use MarketplaceLauncher to show your program’s Marketplace details page. Click on that link, though, and you’ll see that MarketplaceLauncher is already a deprecated API. ??? And its Show method contains two overloads. You’d need to use the one that takes a string context and provide your program’s GUID to bring its marketplace page up. And how do you get the GUID? Simple, you spend 3 hours searching the internet in order to find out that there’s no recommended programmatic way for doing this such that you should just copy it from AssemblyInfo.cs in the Properties folder of the Visual Studio project for your program. Might MS change the GUID as part of its whole disassembly-reassembly-signing process it goes through on submission? You’d better hope not because you really don’t want your “Runner’s Buddy” app bringing up the marketplace page for “Fart Monster 9000” or displaying some sort of “the programmer who wrote this app is obviously stupid since they sent you to a non-existent marketplace page – are you sure you really want to buy something from him or her?” page. Maybe you could spend several hours figuring out how to query it with reflection, though it could turn out to be that there’s some security attribute set on that property or find out that it doesn’t actually work because the reflection thing wasn’t picked up by the magic automated tests that are done to determine what functionality your app uses so your app wasn’t authorized to do it. Oh, and that hardcode the GUID and pray thing? It’s also the way to do it if you use the new MarketplaceDetailTask class that you should be using instead of the deprecated even though the product hasn’t been released yet and there doesn’t seem to be anything at all wrong with it MarketplaceLauncher class.
I’m used to using XACT for audio. It’s a great API. But it’s also not a lightweight thing so I can understand why it wasn’t included on the phone. Instead XNA devs have to use the MediaPlayer class (along with the MediaLibrary class and all the other Media___ classes) in order to play background music. Great. So how do I know if the user’s playing music already? XACT just takes care of that for you as long as you set the categories appropriately. After an hour of reading about how to integrate with the Music and Video hub and how none of the functionality for any of these things will actually tell you if the user is already playing music using some other application (even though the system presumably knows such things), I threw up my hands and asked another question on the XNA forums. Thankfully one of the XNA team members saw my post and provided an answer. It turns out I’d overlooked the MediaPlayer.GameHasControl property, which is what tells you whether or not you are allowed to play your game’s music. If I’d used that API before, I would’ve known it, but I didn’t and none of the XNA Game Studio 4.0 docs that I came across mentioned it, let alone explained it or provided an example of its use.
Another major problem has been the fact that, as best I can tell, none of the “usual suspects” (i.e. people who regularly answer questions) in the XNA forums has an actual developer phone. None of the MVPs who are active in the forums (and one of them is writing a book on WP7 programming) and none of the regular active members. Let’s say I had a phone. That FM radio thing I was talking about earlier? Within 2 hours I could have written a program to test it out thoroughly and provided a lot of helpful information in a blog post about it. Instead I spent 5-6 hours all told searching every forums I know of for information only to find out that the FM radio is one of many red-headed stepchildren that exist already in WP7. Nobody discusses it. Nobody knows much about it. And, as best I can determine, anyone who has gotten an actual phone device is so busy excitedly
gloating discussing it that they aren’t testing out all the actual functionality and providing help to those who don’t have one. Earlier I answered a basic knowledge question posted by someone who has an actual device. Basic. Knowledge. The kind of question where if you had never come across it before, it could only be because you never did anything with XNA before in your life. Yet… has a phone. XNA MVPs with reputation scores and post counts well into the thousands? No phones. Journalists who can easily fly around to various events to test out phones and who Microsoft could easily go to in order to demonstrate the phone? Phones. Well known and respected XBLIG developers who have already ported games to WP7 and created really impressive videos of the results? No phones. (And with the emu reportedly much better at graphics than actual phone devices, this is potentially a huge problem).
And then just a few days ago I read that it's going to cost $99 per app for certification. At the jumpstart sessions earlier this year, this all came up and what seemed to have been said was that developers who registered for the marketplace could submit unlimited paid apps and 8 free apps (after which they’d pay a fee of $20 per for the free apps). I’m sorry, but those two things don’t jive. I was led to believe that app certification (at least initially) was all rolled up in the fees for signing up for the marketplace. Indeed, if there was going to be a certification fee, what would be the point of limiting free apps to 8 after which you’d need to pay $20 per additional app? Isn’t the $99 certification fee a limiter on free apps in and of itself? And if not, does another $20 really make any difference? Microsoft wants lots of apps to make WP7 a success. Yet they want to charge developers $99 just for the privilege of saying they’re registered on the marketplace and want to
bilk charge us an addition $99 per app that we submit for certification to this marketplace of unknown size for an as-yet unreleased product the success of which is still very much up in the air? And to top it off, phones won’t be available in the US until a month after they’re available in Europe (thereby putting all US developers a month behind their peers in Europe)? Well that’s just a crummy deal. First XNA devs are told that our Creators Club memberships mean nothing in regards to WP7 and that we have to sign up separately for that marketplace. Then we’re told that our signup fee means nothing and that we have to pay separately to certify each game we submit despite the fact that many of us were led to believe that there weren’t going to be any such fees initially. And finally those of us in the US are told that we’re being knee-capped set at a month’s disadvantage to developers on the other side of the Atlantic who will be able to buy actual phones, test their apps and games to ensure that they work right, and submit them before we even have a chance to buy a phone? And that the most helpful MVPs in the XNA forums don’t get phones but random people who don’t even know what they’re doing do?
I’m really disappointed. I mean that. I feel hurt and let down and mislead. I already signed up for the marketplace. I have one game virtually complete (though nothing other than the arms-tied-behind-its-back emulator to test it on) and two apps planned. I don’t even know if it’s worth the bother of writing them at this point. I get the privilege of spending $300-500 on a phone a month after it’s released so I can test apps that may not sell at all if someone with a month’s head start has already locked up the market and for which I have to spend $100 each to vet (is it an additional $100 if it fails certification because something in the documentation was unclear or misleading or does that fee cover retests? Who knows…) after spending $100 so some company could grab a credit report, ask me a handful of questions, and accidentally send me an instant rejection letter leaving me anxious and upset for more than a week until everything finally went through and that message with a big red-circled X telling me my account was “suspended” (making me feel like some sort of criminal) went away.
Between my expressions of disappointment there’s actually some useful information for WP7 developer in here. If you aren’t as disgusted as I am and are still gung-ho and excited to make apps and games, take it and use it. As for me, I’m going to spend the next several days re-evaluating my plans and hoping that someone at Microsoft reads this, realizes that XNA developers are feeling pissed on, and takes some steps to rectify it. Or you could just let the marketing folk keep spreading stories about how developers are the “secret sauce” while flipping off US developers by delaying our access to devices by a month and crippling game developers in general by failing to make even a single device available to one of the people who answers the questions we have and which we raise in the XNA forums just like the Windows Phone Developer site tells us to.
(I really would have loved to have a radio tutorial & sample and a trial mode in XNA and Silverlight tutorial with samples for y’all, but my nose is simply jammed too far into my face with all the walls I’ve been running in to. I’ll try to figure out something I can actually test well enough to write about and work it up for this weekend. No guarantees, but I’ll do what I can…)