While working on retargeting one of our existing Windows 8 apps to Windows 8.1 I ran into an issue with the SemanticZoom object. Because of the new Windows Sizes and scaling options in Windows 8.1 it’s recommend to handle the Page’s SizeChanged event to switch to your various ViewStates. Please see this MSDN page for instructions on how to implement this.

This is the piece of code that handles VisualStateTransitions:

void GroupedItemsPage_SizeChanged(object sender, SizeChangedEventArgs e) 
    { 
        if (e.NewSize.Width < 500) 
            { 
                VisualStateManager.GoToState(this, "MinimalLayout", true); 
            } 
            else if (e.NewSize.Width < e.NewSize.Height) 
            { 
                VisualStateManager.GoToState(this, "PortraitLayout", true); 
            } 
            else 
            { 
                VisualStateManager.GoToState(this, "DefaultLayout", true); 
            } 
        } 

Unfortunately there appears to a bug in the SemanticZoom object that causes a Win32-exception and crash when one of those state transitions involves Collapsing a SemanticZoom object. This only happens when executing the transition within the SizeChanged event-handler.

After messing around with this issue for a bit I figured out a simple workaround. Scheduling the VisualState transition through the UI-thread’s dispatcher performs the transition without raising any exceptions. If your “MinimalLayout” state contains said transition this code would work:

async void GroupedItemsPage_SizeChanged(object sender, SizeChangedEventArgs e) 
    { 
        if (e.NewSize.Width < 500) 
            { 
                var dispatcher = Windows.UI.Core.CoreWindow.GetForCurrentThread().Dispatcher;
                await dispatcher.RunAsync(Windows.UI.Core.CoreDispatcherPriority.Normal, () => VisualStateManager.GoToState(this, "MinimalLayout", true));

            } 
            else if (e.NewSize.Width < e.NewSize.Height) 
            { 
                VisualStateManager.GoToState(this, "PortraitLayout", true); 
            } 
            else
            { 
                VisualStateManager.GoToState(this, "DefaultLayout", true); 
            } 
        }

 

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.

Read the full story on the Windows Phone Developer Blog and check out all the events on the Windows Phone Week website.

I’m helping out the team with social media channels on Twitter and Facebook. Tweeting about one of the events? Be sure to use the hashtag #wpdevweek

 

Microsoft has just released Windows Phone App Studio, a great tool that will help you build your first Windows Phone app in virtually no time. After taking it for a short testdrive I’m sure it will help everyone (even without programming knowledge) to build an app. Ever had that feeling you wanted to build something? But you didn’t have enough time? Or you don’t think you have the required skills? Be sure to give App Studio a try! It will help you produce your first app and you’ll learn a lot while you are at it. Are you a developer? App Studio could still save you loads of time, time that you can invest in building the awesome features that’ll make your app stand out.

So what is App Studio?

App Studio is a tool that will help you build a Windows Phone app in 4 simple steps:

1. Have an idea
2. Add content
3. Choose Style
4. Use it!

As a developer that loves to write some code you can add in step 5: “Take it to the next level” App Studio is a great way to get started building your own apps. If you don’t have to knowledge or time to develop a full app it will help you put it together. By grabbing the source of your newly built app you’ll be able to extend the functionality by adding your own features. This will help you understand what it takes to develop a full app and will make your app stand out in the marketplace.

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.

Update: After the whole uproar caused by this and other posts around the web Google decided to revert back to the old situation. I hope it also showed Google that a lot of Windows Phone users do like Google’s services and that they should see if improving the whole experience is possible. Turns out they’re not that evil in this case after all. Head over to The Verge for more details.

The original article was posted when Google Maps was inaccessible to Windows Phone users.

Yesterday reports started showing up that Google is redirecting all Windows Phone users away from the mobile Google Maps website. There’s been quite some discussion on why Google is doing this. Are they doing it to mock Windows Phone users? Or is IE10 mobile just not capable of rendering Google Maps the right way?

Here’s Google’s official statement:

The mobile web version of Google Maps is optimized for WebKit browsers such as Chrome and Safari. However, since Internet Explorer is not a WebKit browser, Windows Phone devices are not able to access Google Maps for the mobile web.

I used Google Maps before occasionally (Nokia Maps for Windows Phone does it’s job, so you won’t need Google anyway) and although the experience wasn’t perfect it definitely worked. Microsoft responded to Google’s statement with a very simple and clear statement:

Internet Explorer in Windows Phone 8 and Windows 8 use the same rendering engine

I ran a few experiments to see what is really going on here.

Google Maps on Windows Phone with an Android UserAgent

Google is detecting Windows Phones by their User Agent. By running my connection through a proxy and using a script to present a different UserAgent I tried to open Google Maps. Not surprisingly it just worked. I used this UserAgent:

Mozilla/5.0 (Linux; U; Android 2.3.4; fr-fr; HTC Desire Build/GRJ22) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1

Want to try this yourself? Use Fiddler! Through Rules -> Customize rules you get to a textfile specifying scripts dat Fiddler runs when processing network calls. Adding oSession.oRequest[“User-Agent”]=”Mozilla/5.0 (Linux; U; Android 2.3.4; fr-fr; HTC Desire Build/GRJ22) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1″; to the OnBeforeRequest part changes the UserAgent on all webrequests.

Playing around with Google Chrome

On Twitter some users reported that Google is just detecting the string “Windows Phone” disregarding any other information. This was obviously worth a try, so I moved to my desktop browser (Chrome). This is the UserAgent of Google Chrome on my desktop:

Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11

To give it a shot I added “Windows Phone” to this string:

Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11 Windows Phone

Now navigating to Google Maps again I got redirected away.

Another experiment

Matthias Shapiro uploaded a video to YouTube where he proves the same point. Using a WebView within a Windows Phone app you can manually specify a UserAgent. Here’s what happened:

 So what does this mean?

Google’s own statement suggests that not supporting WebKit is the problem here, however the experiments mentioned show that there doesn’t appear to be any real problems. Combine this fact with some other recent development like Google removing ActiveSync support for Gmail users and Google still blocking a fully featured YouTube app for Windows Phone. It just shows that Google is just mocking Windows Phone and its users, something TheNextWeb also realized. It’s just another chapter in the ecosystem war. It’s also worth noting that 3rd party Google Maps apps for Windows Phone like gMaps still work.

Do we care?

The real victims here are the regular Windows Phone users. If they happen to use GMail they want to get it on their phones, if they happen to need Google Maps they just want to access it. Fortunately Gmail still works for current users and I’m counting on Microsoft to provide a decent solution in the future. For the Google Maps part I actually really don’t care. Nokia Maps for Windows Phone is native, it has a great experience and offers practically all the features that I would use with Google Maps (maps, traffic info, local search, etc.). But for a company like Google that says:

Google’s mission is to organize the world’s information and make it universally accessible and useful.

All those moves appear to be a bit sad. Google was always praised for it’s openness, but they’re acting more and more like Microsoft was back in the 90s (and that’s NOT a good thing)

Some of you might have noticed that I’ve gone a little silent on this blog. No worries, I’ll be back writing on Windows Phone and Windows 8 soon, but for now have to focus on founding my new company Methylium. In the meantime you can follow me on Twitter to stay up to date.

Yesterday Microsoft announced that marketplaces in 13 new countries were opening up. Today I am happy to announce that support for those new marketplaces has been added to the WP7 Review Reader tool. The tool keeps helping out developers to get easy access to their reviews by simply entering the AppId and bookmarking the URL. For more information on the Review Reader, please see the previous posts on this subject. Some of you might have also noticed that I’ve gone a little silent on my blog and twitter recently. I’m trying to catch up, but there are some important WP7 projects that require my full attention at the moment. I will be releasing some brand new Windows Phone apps targeted at the Dutch market in the coming weeks. Stay tuned for more news on that part.

This post is part of a follow up series on my TechDays session on “Making Money with Windows Phone applications”. See this post for more info and an index. Why build in analytics into your mobile application? This subject has been covered in many blog posts an their conclusion is usually the same. First of all you just want to know how many people use your app and how often they do it. But knowing (at least to some extent) what part of your app is used the most and what epic feature is never found by users is also valuable. As a developer there’s plenty of frameworks to choose from:

• Google Analytics (using MSAF)
• Flurry
• Preemptive Runtime Intelligence (less interesting since their deal with MS ended)
• mTiks

Last week the yearly event for Dutch developers on the Microsoft platform took place in The Hague. Just like last year I did a session on “Making money with Windows Phone applications”. The session is targeted at an audience that is new to the platform. It covers all the subjects that are relevant for earning some money except the building of the app itself (there’s other sessions for that). Although the content is pretty basic it does give interesting insights in opportunities to make the most out of your apps. Since people keep asking me about the different subjects I decided to cover everything in some blogposts over the coming week. Some subjects have been covered in the past. This post will server as an index to those posts, feel free to suggest additions if there’s anything you would like to know. The session covered these subjects, I will update them with links when I published the relevant blogposts:

• Marketplace submissions/choosing the right name/logo/description
• Trial API
• Marketplace and Social media “Tasks”
• Advertising
• App promotion/marketing
• Reporting (App Hub, Distimo, etc.)
• Analytics (using mtiks)

The session itself was presented in Dutch and is available on Channel9. The slides are in English and are available through SlideShare.
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!

Last week I blogged about a problem I came across when beta testing a new WP7 application. My problem was related to the ID_CAP_MEDIALIB capability. Today I noticed somebody on twitter having similar issues. 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.

Those of you following me on Twitter might have noticed some complaints about the beta version of one of my new applications not working the way it should. The app implements a BackgroundAudioAgent to play an audio stream. When directly deploying the XAP to a device this works like a charm. For a last round of testing I submitted the app for private beta testing through the App Hub. To my big surprise the version downloaded through private beta instantly crashes when trying to start the backgroundagent. Apart from analyzing, signing, encrypting and repackaging the XAP nothing should be changed by the private beta process, so this should not be possible.

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.

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;

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.