Month: April 2014

In a previous post, Debugging Internet Explorer on Windows Phone 8.1, I covered how you could use the new debugging support for IE on Windows Phone to diagnose rendering issues. What I didn’t cover is how you could debug web pages when they’re hosted within an application using the WebView control.

As we’re now building for Windows XAML, we can actually use the same mechanism that’s available for Windows 8 applications (see http://www.jonathanantoine.com/2013/04/05/win8-xaml-app-how-to-debug-the-javascript-in-a-webview/ for instructions). All we need to do is change the Application process option under Debug.

Set this to Script and when you debug your XAML application Visual Studio will attach to the WebView allowing you to debug your script and DOM.

The desktop version of Internet Explorer now has quite a good selection of developer tools available on any site by just pressing F12

Unfortunately on Windows Phone it’s been quite difficult to debug websites and so developers typically had to resort to alert(‘hello’); style debugging. With Update 2 for Visual Studio 2013 there is a new Debug menu item “Debug Windows Phone Internet Explorer”

This gives you the option to select the device/emulator and specify a launch site to debug.

The debugging experience is pretty cool as it’s actually in Visual Studio and includes the ability to set breakpoints and inspect variables.

Do also get the DOM Explorer

And the Javascript Console

This has got to make our jobs easier!

In my previous post on Windows Phone 8.1 Developer Power Tools I looked at the developer power tools that are available from within Visual Studio. In this post we’ll look at the new Windows Phone 8.1 emulator and how it is an enabler for building better applications. The first thing to note is that there are a number of different emulator images available:

In this brave new world of varying screen sizes Windows Phone 8.1 departs from the fixed addressable width of 480 units. Instead each device has a scale factor which results in an effective resolution – in essence this means that two devices of the same size but differing hardware resolution will display the same amount of content, whereas two devices with the same resolution but differing size, will show more/less content depending on their relative size. What this means is that we now need emulators that not only vary in resolution but also in size.

Here you can see both the WVGA 4inch and the 1080p 6inch alongside each other – the beauty of it being in an emulator is that it can then be resized on the screen. The thing to notice is that the 1080p emulator has an additional column of tiles which will be a typical behaviour within applications when dealing with a higher effective resolution.

The next thing to note are the additional tools that are available. Here is a quick set of screenshots – we’ll go into more details on each of these in coming posts:

 

By far the most common way to build Windows Phone applications is to use XAML and C# (or VB). In this case the XAML is a variant on Silverlight, which made it very easy for developers building Silverlight applications to switch across to building Windows Phone applications. 4 years on and the number of Silverlight developers has dropped (well at least the appeal of being a Silverlight developer has), and all the focus now is on becoming a Windows developer.

Unfortunately somewhere along the lines the Windows team decided that having three XAML frameworks (WPF, Silverlight and WP) wasn’t enough and that they needed to come up with another, only marginally different, framework. This we’ll refer to as Windows XAML.

With the announcements around Windows Phone 8.1 we’re entering a new time of convergence between phone and desktop applications where we can reuse not just the code (eg Portable Class Libraries and code file sharing) but also the XAML markup. This doesn’t come for free and relies on migrating our applications, or starting new applications, using Windows XAML instead of Silverlight.

So where does this leave us? What it means is that there are now three ways to develop for Windows Phone 8.1:

1) Windows Phone 8.0 Silverlight

Use this if you want maximum reach from a single application package; you don’t need or want to use any of the new platform features. This type of application will run on all Windows Phone 8.0 and 8.1 devices.

2) Windows Phone 8.1 Silverlight

By running the  “Retarget to Windows Phone 8.1” option after right-clicking on your application in Solution Explorer, your application will be migrated forward and will run against the new runtime. This means you can take advantage of some of the new platform features without having to redevelop your application. Whilst in most cases the retargeting process doesn’t modify the behaviour of your application, you will need to verify your application functionality before publishing the new version.

Once retargeted your application will only run on Windows Phone 8.1 devices, so it is recommended that you take a backup or a branch of your code and keep the 8.0 version alive to support those users who haven’t upgraded.

3) Windows Phone 8.1 Windows XAML

New applications, not wanting to maintain backward support for Windows Phone 8.0, can be created using Windows XAML. Ideally this would be all new applications as it allows for reuse across phone and tablet. The Universal projects concept introduced into Visual studio makes it easy to share code between projects, whilst still having platform specific functionality included in the “head” projects (ie the Windows and Windows Phone projects).

There is one thing that isn’t being highlighted is that each option has some limits on what you can and can’t do. 8.0 SL projects can’t access any of the new platform features. Windows XAML can’t do things like lock screen background provider….. it’s worth reading up on this before you make a decision

Last week at BUILD, Microsoft announced the availability of Visual Studio 2013 Update 2 RC, which includes the new Windows Phone 8.1 SDK.

I’m sure there will be a lot of blog posts talking about the new Universal project, the additional capabilities introduced in Windows Phone 8.1, Windows Phone XAML applications, the new application lifecycle model etc. I want to take a different approach and talk about some of the additional tools that come with the SDK.

One of the benefits Windows Phone development aligning with Windows app development is that more of the experiences along the development lifecycle will be similar. For example from the Project menu, Windows Phone developers now have the Store sub-menu with the ability to Create App Package.

One of the other additions is under the Tools menu, where there is a Windows Phone 8.1 sub-menu. This includes the Developer Power Tools, Developer Unlock and the Application Development tools. Whilst the last two are not new to Windows Phone development, they can now be reached from within Visual Studio.

The Developer Power Tools, not to be confused with the Windows Phone Power Tools, is a standalone tool which can be used to inspect what’s going on across either emulator or device. Help is available via MSDN. 

One of the most interesting thing about these tools is that you can start them, disconnect your device, put your application through its paces in real world scenarios, then reconnect and review the data at a later stage. For example, using the Performance Recorder you can check the data you want to record (eg CPU and Power) and hit Start. You can then disconnect the device, or in this case the emulator, open and run your application, and then reconnect and Stop the recording. This will prompt you to save a .etl file which includes all the data recorded.

The .etl file can then be opened using Windows Performance Analyzer (just double-click the file in Windows Explorer).

Hopefully these tools will help you track down issue in performance and usage of your application