PROBLEM! #wp7dev 's: When submitting an app that uses the video recorder <"ID_CAP_Microphone"> is removed http://t.co/PU3PSv62 #wpdev

30/12/2011 18:08 via TweetDeckReplyRetweetFavorite

@lancewmccarthy

Lance W. McCarthy

Fortunately there is a way to force detection of every capability. The key is knowing what reference to use to force the detection. In this post I will show how to implement a simple workaround to ensure detection. Please note that all of this is just temporary. Microsoft’s engineering teams are working on fixing these detection issues, so these tricks should not be required anymore in the future.

Detection process

First of all it is important to realize that the Ingestion Tool does not scan the actual C# and XAML (that’s not included in the XAP package anyway). The actual scanning happens on the Intermediate Language (IL) that is generated by the compiler. This is important to keep in mind when implementing this workaround.

Detection rules

Essentially both the Marketplace Test Kit and the App Hub itself use the same set of rules to determine what capabilities are required. Fortunately those rules are supplied with the Test Kit in understandable XML format. To find out what class you need to reference to force detection it is sufficient to check this list of rules. The rules.xml can be found in “C:\Program Files (x86)\Microsoft SDKs\Windows Phone\v7.1\Tools\Marketplace” For example here’s the part on the ID_CAP_MICROPHONE capability.

<Capability ID=”ID_CAP_MICROPHONE” Type=”Security”>
<Assembly Name=”Microsoft.Xna.Framework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=842cf8be1de50553″>
<Namespace Name=”Microsoft.Xna.Framework.Audio”>
<Class Name=”Microphone” />
</Namespace>
</Assembly>

<Assembly Name=”Microsoft.Phone.Media.Extended, Version=7.0.0.0, Culture=neutral, PublicKeyToken=24eec0d8c86cda1e”>
<Namespace Name=”Microsoft.Phone”>
<Class Name=”Camera” />
<Class Name=”PhotoCamera” />
<Class Name=”VideoCamera” />
</Namespace>
</Assembly>
</Capability>

Forcing detection

The rules.xml file basically tells you what classes to reference to force the detection (I highlighted them). In any case you can just add a dummy file (either xaml or just cs) and make a reference to just one of these classes. In case of the Microphone @lancewmccarthy suggests this line:

Microphone microphone = Microphone.Default;

This is a Microphone-specific solution. Another option is to just add this line:

Microsoft.Xna.Framework.Audio.Microphone temp = null;

This is where you need to remember the code gets compiled before scanning. The compiler implements a lot of optimization which in this case would lead to discarding a variable that is never accessed. Adding another line that references the variable solves this. This can be pretty much anything, for example:

MessageBox.Show(temp.ToString());

If you would actually run this code it will always throw a NullReferenceException, but since this is a dummy file that will never happen. Although the code is unreachable the ingestion tool notices it. You can use the Marketplace Test Kit to verify this.

Conclusion

By combining the information in the rules.xml with a simple dummy file you should be able to force detection of any capability. The other way around rules.xml can also help you identify why a certain capability gets detected. Do you come across any problems when using this method? Feel free to leave a comment or send me a tweet.

Cause

We investigated the problem together with the Microsoft Marketplace Dev Support team. We figured out the crash was related to the specified capabilities. To play background audio the agent relies on the ID_CAP_MEDIALIB capability. This was specified in our manifest-file, but during the submission process the required capabilities are analyzed and overwritten. Apparently the App Hub contains a bug causing the medialib capability to remain undetected in certain situations. When using the Marketplace Test Kit the same problem shows, it does NOT detect the medialib capability. When the application tries to execute any action related to this capability it simply throws an exception and crashes.

Solution

Obviously this is a bug in the Marketplace Ingestion tool that Microsoft needs to fix. The support team states: “I can tell you that it’s a known problem at our side that Engineering Team is already investigating”. Fortunately there’s a pretty obvious and easy workaround to solve this problem. Just add a “dummy” page to your application. Add elements to this page the ensure detection of the missing capability. In my case we forced detection of the MediaLib capability by inserting a MediaElement and making sure at least the x:Name is specified( <MediaElement x:Name=”DUMMY” />). Now both the Marketplace Test Kit and the App Hub’s ingestion tool will detect the capability therefore solving the problem.

Update: The support team also provided me with some other workarounds that are easier and cleaner, but still force detection of the missing MEDIALIB capability. If your app is referencing any of these libraries just add the one line of code to your app.

I don’t know if anybody experienced problems with apps crashing after going to the marketplace submissions process, but the first place to search for errors appears to be the detected capabilities. The Marketplace Test Kit performs the same analysis the marketplace does, so it’s easy to check. The engineering team is working on fixing the issues, but for the time being forcing detection by adding dummy elements is easiest workaround.

An important aspect of every mobile application that uses the internet connection is the way it handles slow connections. As a developer you cannot predict if you are app will be used over high-speed UMTS or slow GPRS. In WP7 development there are some API’s available to determine the connection type, but you can never be sure about the exact speed. To ensure the best experience for your users testing some scenarios is very important. Unlike the Android emulator, the Windows Phone emulator does not provide any functionality to limit the network speed, but there are some alternatives that don’t require you to take your phone to the middle of an empty desert. In this post I will cover throttling of the network connection using NetLimiter.

NetLimiter is an advanced software suite that allows analysis and shaping of bandwidth. It can be used to limit the bandwidth on a specific process. This is exactly what we need to limit the network speed of the Windows Phone Emulator. Download and install NetLimiter from their website, unfortunately this requires a reboot. After launching NetLimiter limiting the speed is pretty easy. First make sure you find the Windows Phone Emulator process in the list.

The UI shows the current transfer rate, but the second number both for DL and UL can be used to limit the speed. Double clicking opens a dialog where a limit can be specified and enabled/disabled. Hitting save will immediately apply the limit to the connection.

So what connection speeds should you test for? As a reference I looked up the different presets the Android emulator offers, this includes al relevant connection types. Please note that this is kilobits per second.

Good luck with testing and please let me know what issues you encountered with slow speeds.

Two days ago the biggest Windows Phone 7 developer event to date in the Netherlands took place. With the official launch of WP7 in our country and the recent addition of Nokia phones to the line-up developer interest is rising. A total of about 300 attendees showed up for a full day of sessions including a basic introduction the dev platform and tools, more advanced topics like push notification and fast application switching and a session on app monetization. The sessions where presented by Maarten Struys, Fons Sonnemans and myself. A big thank you goes out to Microsoft’s Matthijs Hoekstra, the Dutch WP7dev evangelist, who organized the event at the High Tech Campus in Eindhoven.

Here’s the full program for the day:

Here’s a list of interesting links for those who attended my sessions:

• Entry on Matthijs Hoekstra’s blog containing all content
• Windows Phone App Hub – THE place to get started
• Distimo Monitor – The tool I demonstrated to analyze your apps performance
• Dreamspark – Microsoft’s program to get free software and App Hub access to students
• Surfspot.nl & Slim.nl – Required for Dutch students to access Dreamspark
• Windows Phone 7 for Absolute Beginners – Great video series to get started

Thank you all for attending the sessions. If you any questions related to my presentations or getting started with WP7 development in general you can use the comments, find me on Twitter or use my contact form

Gisteravond tijdens Night of the Nerds heb ik drie presentaties gegeven over het ontwikkelen van smartphone applicaties. Night of the Nerds is een evenement gericht op middelbare scholieren van 14-18 jaar oud met interesse in techniek. Het evenement is open voor alles en iedereen die het leuk vindt om met techniek bezig te zijn. Tijdens een clinic van 45 minuten heb ik kort de wereld van smartphones en apps geintroduceerd en aansluitend een demonstratie gegeven van het bouwen van een simpele twitter applicatie. Veel bezoekers reageerden enthousiast en wilden graag thuis aan de slag met het bouwen van een eigen app. In deze blogpost vinden jullie alle benodigde informatie om de eerste stappen te maken als app-ontwikkelaar.

Voor geinterreseerden zijn de slides van gisteravond terug te vinden op SlideShare:

Verder heb ik de broncode van de voorbeeld-Twitterapplicatie ook online gezet. Zodra je de Windows Phone ontwikkeltools geinstalleerd hebt (zie de links verderop in deze post) kun je broncode downloaden en zelf gebruiken. Ik heb de code voorzien van commentaar met extra uitleg. De broncode is hier te downloaden.

Tijdens de clinic gaf ik al aan dat het ontwikkelen van smartphone applicaties op de verschillende platformen (iPhone, Android, WP7) vergelijkbaar werkt, maar dat wel elk platform een andere taal en andere tools gebruikt. Zelf ben ik gespecialiseerd in Windows Phone development, maar verderop in deze post geef ik ook wat aanwijzingen om aan de slag te gaan met de andere platformen. In ieder geval heel veel succes met het bouwen van je eigen applicatie. Ik hoor het graag als je met je eigen project bezig bent of als je een probleem tegenkomt. Ik ben altijd te bereiken via Twitter, Facebook of de contact form van deze weblog.

Windows Phone 7

Een echte aanrader is de videoserie Windows Phone 7 for Absolute Beginners op Channel9. Dit is een collectie video’s die begint vanaf het allereerste begin, het installeren van de benodigde software en het gebruik van die software. Stap voor stap gaat het daarna van het bouwen van je eerste applicatie naar steeds een wat hoger niveau.

Verder is er overal op internet meer informatie te vinden over het ontwikkelen voor Windows Phone 7, hierbij een kleine lijst met wat nuttige links om mee te beginnen:

• WP7 App Hub, hier download je de tools en upload je eventueel je apps naar de marketplace. Ook is er veel lesmateriaal over WP7 te vinden
• WP7 Developer tools, directe link naar de download
• WP7 op MSDN, pagina op MSDN met informatie over WP7 development
• Programming WP7 eBook, een volledig eBook van 1000 pagina’s waarin alle aspecten van WP7 development behandeld worden
• WP7 Design & Interaction Guide, een uitgebreid document over het ontwerp van de verschillende onderdelen in de WP7 onderdelen en hoe je die in je eigen app zou kunnen toepassen
• WP7 Photoshop Design Templates, een aantal Photoshop templates die helpen met het ontwerpen van WP7 apps in Photoshop

Android

Op AndroidWorld.nl wordt op dit moment een 10-delige serie van tutorials over het ontwikkelen van Android applicaties geplaatst, elke week een nieuw artikel. De tutorials worden geschreven door Wouter Vegter, met wie ik heb samengewerkt voor de EHBO applicatie die ik gisteravond heb laten zien. In deel 1 van de serie wordt uitgelegd welke tools je nodig hebt en hoe je die installeert, in de artikelen die daarop volgen worden verschillende onderdelen van Android development geintroduceerd.

iPhone

Als je nog geen programmeerervaring hebt is het waarschijnlijk erg lastig om direct te beginnen met het ontwikkelen van een applicatie voor iPhone of iPad. De achterliggende programmeertaal is wat gecompliceerder en vereist meer kennis dan de talen die voor Android (Java) en Windows Phone (C#) gebruikt worden. Als je het toch wil proberen zou je om te beginnen kunnen kijken naar dit artikel op iPhoneclub.nl, daar worden links gegeven naar een paar goede websites met informatie over het bouwen van iPhone apps.

Notice the missing "Delete submissions" button

So what do we need to get the job done?

• Fiddler, it needs to be set up to catch HTTPS traffic. See my previous post for more info
• A list op appids and appinstanceids of the beta’s to remove
• A few minutes

To get a list of the required appids just open up an empty notepad file and open up the detail view for the apps you want to remove. Check the url in your browser and save the part that is formatted like this: applicationId=<appid>&applicationInstanceId=<appinstanceid>. While you are at it make sure you end the beta by using the appropriate button if you haven’t done so already. If you have your list we are ready for the actual removal process. Before moving on do note that I don’t know what actually happens on the server side when pulling this trick. I haven’t noticed any strange consequences but we’re still screwing with the App Hub, so take care. Ready? Let’s go.

To get started just start submitting a new application. All you need to do is enter a name, upload a random XAP (doesn’t even have to be valid) and hit “Save & quit”. Now fire up Fiddler if you haven’t done so already and verify that HTTPS traffic gets captured. If you go back to the detail page of your random app you should notice a “Delete submission” button.

This time there actually is a delete button

Hit the delete button and confirm deletion of the app. This will remove your submission. Notice that a delete request should show up in Fiddler. In Fiddler select the request builder in the upper right and drag the delete request into the request builder. It should look like this:

Now notice the familiar applicationId=<appid>&applicationInstanceId=<appinstanceid> in the request URL, just replace these with the ones you just noted. Now hit execute and keep a look on Fiddler traffic. A request should show up and turn green after a while. This means the request has been received and accepted. Your app should not show up in the list of apps anymore. You can repeat this last steps for every application you want to remove

So what are the improvements that I noticed:

• Tax information can be entered for 17 countries
• Payment can be requested for 12 countries
• PubCenter accounts can be created based in 12 countries

To save some frustration in the future I will just share my dummy artwork. I did not try to give it any kind of design so it’s ugly, but at least it will be accepted by the App Hub. Feel free to use it in your beta tests. Here’s a zip containing all the files.

Happy beta testing!

So first of all, why would you want to use private beta testing instead of just sending over the XAP to your testers? There are some big advantages:

- The tester does not need a developer unlocked phone, every phone connected to the marketplace can be used for beta-testing
- No need to worry about your IP. The tester gets the app on his phone without ever gaining access to the XAP. The test license automatically expires after 90 days so again no worries here.
- It’s way more convenient both for you and the tester. Instead of passing over the XAP and manually deploying it all a tester needs to do is visit the link you provide to them.
- All you need from a tester is his/her marketplace Live ID

So lets take a quick step-by-step walkthrough. The process is equal to submitting and app for actual publishing, with just a few minor differences.

1. Log in to the App Hub en select “Submit a new application”
2. Enter an application name, just for your own reference within the App Hub
3. Choose private beta instead of submit to marketplace
4. Upload your XAP
5. On the next page enter the application information. Remember this information is meant for you testers, you will redo the submission process for final publication. (Here’s some dummy artwork, in case you don’t have artwork yet)
6. After finishing all the metadata and artwork you now get to the actual part of granting access to your testers. You will need the Live ID your tester uses to connect to the marketplace. Enter the Live ID for every tester and make sure you separate them using a semicolon, just newlines won’t do the job (I found that one out the hard way) Remember that the amount of testers is limited to 100 and the list can be updated at any time.
7. Submit your application. It will now be published through Microsoft’s CDN which will take a few hours. You will get an e-mail notification once it’s done. This e-mail will contain the application ID you need to contact your testers.
   
8. Now send your testers an e-mail with test instructions. Note that although you provide the Live IDs to Microsoft it is still your job to send test instructions and a download link to the testers. There’s a few things to include in the e-mail to your testers:

• Test intructions. On what aspects do they need to focus. Also mention functionality that does not work yet to prevent irrelevant feedback
• Explain how you would like to receive feedback. Do you want it through e-mail or for example through the marketplace review system which is also available to test apps
• The link to the marketplace, required to actually download the application. Some users have problems with the zune link, replacing it with http://windowsphone.com/s?appid=<appid> will always work.
• Of course some thanks in advance for taking the time to test your application

Some remarks that require emphasis:

• The direct link provides access to your app’s page in the marketplace. This is available to anyone with the link, even when their live ID has not been granted access. The permission check will occur when installing the app. If there is anything confidential in your app, don’t disclose it in your test app’s description or screenshots. Since there’s no certification involved dummy data will do just fine.
• The regular update process does not work for test applications. Every new version requires a new marketplace submission and new e-mail with link to the testers. This is something that hopefully will be improved in the future, for now please take it into account.

Microsoft deserves some credits for getting this beta testing infrastructure in place. It is not perfect yet, but is a big improvement compared to the manual exchange of XAP files.

It’s also worthwile to note a few changes to the new App Hub that impact checking your reviews. Within the App Hub it is now possible to view reviews and average for one marketplace at a time. This is an improvement, but MS isn’t quite there yet when they want to provide easy and efficient access to reviews.  Compared to the App Hub my review reader still offers this extra functionality:

- Overview of all marketplaces

- No-nonsense interface

- Excel/CSV export

- A try at contacting the reviewers

- Average ratings since last update

I still hope Microsoft will improve this experience in a future update, in the meantime my tool will stay available for all WP7 devs out there. Please let me know if you have any feedback or feature suggestions. You can find me on Twitter.