Just a quick note on the Windows Phone Week event that’s kicking off in two days. A while back my Windows Phone Dev MVP friends Joost, Matteo and Rodolpho had the crazy idea of organizing some wpdev events around the world together. The event started growing and with the first event kicking of this monday we have a total of 19 events scheduled around the world.
Posts Tagged ‘wpdev’
So what is App Studio?App Studio is a tool that will help you build a Windows Phone app in 4 simple steps:
- Have an idea
- Add content
- Choose Style
- Use it!
What do I need to get started?App Studio is a fully web based tool, all you need to get started is a Microsoft Account. It would also make sense to have a Windows Phone to actually test your apps, but it isn’t strictly required. That’s basically all you need, now head over to http://apps.windowsstore.com to get started. There’s some resources to help you get started:
- Recent blogposts on the official Windows Phone Developer Blog
- Windows Phone App Studio forums
- Windows Phone App Studio UserVoice (if you have feedback)
Next steps?This post marks the start of a series of blogposts that will help you make the most out of your App Studio experience. Give it a try yourself and come back over the course of the next days for more tutorials.
- Google Analytics (using MSAF)
- Preemptive Runtime Intelligence (less interesting since their deal with MS ended)
- Marketplace submissions/choosing the right name/logo/description
- Trial API
- Marketplace and Social media “Tasks”
- App promotion/marketing
- Reporting (App Hub, Distimo, etc.)
- Analytics (using mtiks)
If you would like to contact me feel free to do so in the comments, the contact form or Twitter. And do share your WP7 succes stories!
Detection processFirst 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 rulesEssentially 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=18.104.22.168, Culture=neutral, PublicKeyToken=842cf8be1de50553″> <Namespace Name=”Microsoft.Xna.Framework.Audio”> <Class Name=”Microphone” /> </Namespace> </Assembly> <Assembly Name=”Microsoft.Phone.Media.Extended, Version=22.214.171.124, Culture=neutral, PublicKeyToken=24eec0d8c86cda1e”> <Namespace Name=”Microsoft.Phone”> <Class Name=”Camera” /> <Class Name=”PhotoCamera” /> <Class Name=”VideoCamera” /> </Namespace> </Assembly> </Capability>
Forcing detectionThe 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.
ConclusionBy 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.
CauseWe 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.
SolutionObviously 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.
|If it’s referencing:||Then add:|
|Microsoft.Phone.dll||Microsoft.Devices.MediaHistory history = null;|
|Microsoft.Xna.Framework.dll||Microsoft.Xna.Framework.Media.MediaLibrary lib = null;|
|none of the above ones, so very likely it’s at least referencing System.Windows.dll||System.Windows.Controls.MediaElement me = null;|
Would you like this feature to be integrated into the WP7 emulator? Vote here!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.
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.