Category Archives: Windows Phone

VS2013: upgrading a Windows Phone 7/8 and Windows 8 apps

Windows 8, Windows Phone

In this post I will showcase issues I had while upgrading a Visual Studio 2012 solution containing a Windows Phone app (with both 7.8 and 8.0 versions) and Windows Store app to Visual Studio 2013.

As you probably already know, the Release Candidate version of VS2013 was released a few days ago and I decided it was the appropriate time to upgrade my 2Day todo-list application. Because 2Day for Windows will target the 8.1 release (coming October 18th, now available for MSDN subscribers) I needed to perform this upgrade before the release.

Windows Phone 7.x support

The first issue is simple and yet sad: Visual Studio 2013 is dropping support for Windows Phone 7.x app.  I guess it makes sense when given the fact the WP8 devices represent more than 65% of the total of Windows Phone device (see this AdDuplex blog post for more details).I can also confirm this trend that by looking at 2Day’s data for last week:

2Day devices chart

Since I released the first version of 2Day I submitted 14 updates. Starting from 2Day 1.4 I  released all updates for both WP7 and WP8 devices. It looks like the 2.1 update coming later this month will be the last one targeting WP7 devices.

Windows Phone support Conclusion: upgrade to VS2013 imply no more WP7 support. You can try to maintain 2 solutions but we will see in the next paragraph that there are other issues with Portable Class Libraries.

Portable Class Libraries (PCL)

2Day’s Visual Studio 2012 solution contains Portable Class Libraries to enable code reuse between Windows Phone and Windows 8 (it was also helping code sharing between WP7 and WP8 versions). In Visual Studio 2013, like we saw before, support for WP7 is now longer available, including for PCLs:

VS2013 PCL

So opening a solution that contains PCLs targeting WP7 will upgrade those PCLs and drop targeting of WP7.

Also, in order to target WP7 and have async/await support I had to use the Async BCL NuGet package:

BLC Async Support

Because the async support is now supported in the frameworks I target (Windows 8.1 and Windows Phone 8), I must remove those packages in order to prevent conflicts like the following:

Error 28 The type 'System.Threading.Tasks.Task<TResult>' exists in both 'c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETPortable\v4.0\Profile\Profile158\mscorlib.dll' and '...\packages\Microsoft.Bcl.1.0.19\lib\portable-net40+sl4+win8+wp71\System.Threading.Tasks.dll'

While doing those upgrades I also ended up target .Net 4.5, and it turns out the reflection API has some changes in the latest version of .Net.  If you’re like me you’re a fan of SOLID principles, you probably have some kind of Inversion of Control container using reflection… In my case the following code was not working anymore:

var constructor = typeof(T).GetConstructors().FirstOrDefault();

And I had to use the new reflection API:

var constructor = typeof(T).GetTypeInfo().DeclaredConstructors.FirstOrDefault();

You can read this complete post on the blog of the .Net team for more details about the evolution of the reflection API.

PCL Conclusion: be careful when you upgrade PCL projects to VS2013. Because WP7 support is gone, you don’t need the Async BCL NuGet package anymore. If you choose to target .Net 4.5 beware of possible breaking changes in the reflection API.

General conclusion: if like me your original plan was to target WP7, WP8 and Windows 8.1 withing a single Visual Studio solution, you’re in trouble. My decision is to drop support for WP7 devices for the next update of my app. I guess I could go with branching in TFS to keep compatibility but I don’t have time for that. Be also careful with PCLs and the new reflection API.

 

Using PowerShell to automate the build process of your Windows Phone app

Tools, Windows Phone, ,

Another day another occasion to share a tip which comes with the development of my todo-list app 2Day. This time, I share a small PowerShell script I use in order to build the application. Of course the script will not work out of the box for you but it could be useful if you’re thinking about automating the generation of your application.

Background: managing multiple versions

Since release 1.5.0 there are two versions of 2Day: the lite version (free) and the standard version (paid). I switch from one configuration to another using two Build Configurations. When I want to build the Lite version I build using the Release Lite configuration while for the standard version I build in Release. The difference between the two is a conditional symbol.

2Day-Configurations

I also have a WP7 and a WP8. So for each official release, I must produce 4 XAPs:

  • WP7 Lite
  • WP7 Full
  • WP8 Lite
  • WP8 Full

This is the reason why I was thinking about automating this stuff !

PowerShell script

The script itself is very straightforward: I use MSBuild to build the Visual Studio Solution File (*.sln) using the 2 configurations I described earlier. Once a build is complete I move the generated XAPs to an output folder. As I said this script will NOT work out of the box for your but it could be used as an example. Here is the code:

# usage is ./ScripName -version 1.5.0
param([string]$version = "version")

$solution = "2Day.sln"
$msbuild = "C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe"
# get the location of the script
$rootDir = [System.Io.Path]::GetDirectoryName($MyInvocation.MyCommand.Path)
# build the location of the sln file. In my case this is under /Branches/WindowsPhone/versionunmber/
$baseDir = $rootDir + "\Branches\WindowsPhone\" + $version + "\"
# and the ouput is in a Build folder
$outputFolder = $rootDir + "\Build\"

# if the output folder exists, delete it
if ([System.IO.Directory]::Exists($outputFolder))
{
 [System.IO.Directory]::Delete($outputFolder, 1)
 [System.IO.Directory]::CreateDirectory($outputFolder) | Out-Null
}
else
{
 [System.IO.Directory]::CreateDirectory($outputFolder)| Out-Null
}

Write-Host "Building 2Day version: " $version
Write-Host "Solution is at: "  $baseDir$solution

# make sure our working directory is correct
cd $baseDir

$configurations = "Release", "Release Lite"
foreach($configuration in $configurations)
{
	# prepare build command line
	$options = "/noconsolelogger /m /p:Configuration=""" + $configuration + """ /p:Platform=""Any CPU"""

	# prepare output path
	$releasePath1 = $baseDir + "2Day.App.WP7\bin\" + $configuration + "\_2DayWP7.xap"
	$outFile1 = "2Day_" + $version + "_WP7_" + $configuration.Replace(" ", "_") + ".xap"
	$releasePath2 = $baseDir + "2Day.App.WP8\bin\" + $configuration + "\_2DayWP8.xap"
	$outFile2 = "2Day_" + $version + "_WP8_" + $configuration.Replace(" ", "_") + ".xap"
	
	# clean
	Write-Host Perform cleaning...	
	$clean = $msbuild + " " + $solution + " " + $options + " /t:Clean"
	Invoke-Expression $clean | Out-Null
	
	# build
	Write-Host "Building with configuration"$configuration"..."
	$build = $msbuild + " " + $solution + " " + $options + " /t:Build"
	Invoke-Expression $build | Out-Null
	
	# move the files that were built to the output folder
	$out1 = $outputFolder + $outFile1;
	$out2 = $outputFolder + $outFile2;
	[System.IO.File]::Copy($releasePath1, $out1)
	[System.IO.File]::Copy($releasePath2, $out2)
	
	Write-Host "Output: " $out1 $out2
}

cd $rootDir
Write-Host "Done"

A Reactive Extension (Rx) use case in a Windows Phone app

Rx, Tools, Windows Phone, ,

While working on my todo-list application 2Day, I encountered a situation where Rx came to the rescue. Rx (Reactive Extension) is a framework which has been available for a couple of years now. It is possible to use it on the phone very easily. In this blog post, I share a piece of code which use Rx to implement a specific feature in 2Day.

2Day’s users have requested a search feature. The idea is simple: give the user a new page where he can type some text which then filters his tasks. Here is the feature in action in 2Day:

2Day - global search

Even though it seems very basic, I wanted to add an extra feature: perform the search a couple of milliseconds after the user actually stops typing. This prevents the search result to blink while the user types. It turns out it’s very easy to implement this using Rx which is dedicated to manipulate stream of observable items. Here is the code:

var seq = Observable
    .FromEventPattern(this.textbox, "TextChanged")
    .Throttle(TimeSpan.FromMilliseconds(500))
    .ObserveOnDispatcher()
    .Subscribe(e =>
    {
        this.viewmodel.SearchText = this.textbox.Text;
    });

The first step is to create the observable sequence using the FromEventPattern method which can turn an event into an observable stream. Then the Throttle method allows to “calm down” the stream, by requiring the specified amount of time to be spent before sending the item in the output stream.

This can be shown using the following diagram:

RxExampleThrottle

If the user presses quickly the letters “p”, “a”, “i” and “r” we will start the search only after the specified amount of time and not for each new letter. Notice that the subscribe method does not do a lot of things: it only sets a property on the ViewModel layer which actually performs the search.

Here is a simple yet useful use case for Rx. It’s very nice to have the library available out of the box on the phone. Hope it helps 🙂