Using SDK/library references in Universal Windows Apps

I’m just coming back from Build 2014 and it was a great pleasure to talk to customers/developers.  It is one of the best parts of my job right now in seeing how customers use the technology our team represents.  If you are a XAML developer and didn’t have a chance to go to Build or haven’t watched all the sessions, here’s a quick short list of recommendations I’d have:

• Common XAML UI Platform overview (Tim Heuer)
• XAML UI Controls (Shawn Oster)
• Developing across multiple form factors (Peter Torr)
• What’s new with Windows Phone Silverlight apps (Sam Jarawan and Harini Kannan)
• Using VS to build universal Windows apps (Navit Saxena)

There are many more (app model, localization, accessibility, tiles, notifications, etc.) so please do look at the event site and download/watch your favorites.  I think the list above gives you a good intro to the UI area changes and introduction to the concepts of Universal Windows apps.  If you haven’t heard of that concept yet, you can jump to the Keynote from Day 1 for the quick demo.

Add Reference

The last session above is one that I want to write about today in this post.  In current form, a Universal Windows app in Visual Studio Update 2 allows you to maximize your sharing of code/assets across your Windows Store and Windows Phone app.  If you are like most developers, you rely on a great ecosystem of libraries and SDKs to augment your app and add functionality, UI or make things easier to develop.  In our keynote sample, the app we migrated (SportsLeague app) used JSON.NET and we showed that we are able to re-use the same library (which in this case happened to be a Portable Class Library, aka PCL) across the different endpoints.

One thing that is important is that you will need to add these references to each of your project ‘heads’ (the term we use to describe each endpoint in a shared project solution).  For some that are using direct binary DLL references to PCL libraries should be okay.  For others that are using Extension SDKs and/or NuGet packages, you may find yourself into some scenarios where either the SDK is different or the NuGet package isn’t updated yet to understand the Windows Phone 8.1 project type.  There are a number of these that are already updated like JSON.NET, Caliburn.Micro, etc.  If you find yourself using a library that isn’t updated yet, you may want/need to prod the author to update.  Better yet, if it is Open Source, submit a pull request with the update yourself!

SQLite or other native Extension SDKs

The other category are things that might be platform-specific and/or native.  These things are generally more complex than something that might work in a PCL and have dependencies on various native compiler/linker options or have been compiled in such a way that are different for the Phone device versus a tablet device.  One such example is SQLite.

SQLite is an in-process library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine. The code for SQLite is in the public domain and is thus free for use for any purpose, commercial or private. SQLite is currently found in more applications than we can count, including several high-profile projects.

SQLite links against the C++ Runtime and as such needs to make sure the right linking happens for the phone and tablet CRT profiles.  Right now, the SQLite for Windows Phone Runtime 8.1 is in some testing, but since a lot of people have been asking me about it, I’ll share my private build from source of the SDK.  This comes with a “works on my machine” guarantee :-).  This is a build of SQLite from their source, which is Open Source, and modified to compile/link against the Windows Phone 8.1 SDK.  When the official version comes out you should update to that version from their site.  For now, you can download my build of  UPDATE (12-MAY-2014): SQLite team put out their official build for Windows Phone 8.1: SQLite for Windows Phone 8.1 here.

Updating your Extension SDKs and NuGet packages

If you are an author of one of these SDKs that people use, please consider doing an update to make your customers happy.  If you are an Extension SDK provider you will want to produces an Extension SDK for Windows Phone 8.1.  If you already have a WinRT SDK, then you may just be able to copy the manifest, etc. and just produce changes to your manifest so it installs to the right location.  Here is an example:

<Installation AllUsers="true" Scope="Global">
  <InstallationTarget Id="Microsoft.ExtensionSDK" 
    TargetPlatformIdentifier="WindowsPhoneApp" 
    TargetPlatformVersion="v8.1" 
    SdkName="SQLite.WinRTPhone81" SdkVersion="3.8.4.1" />
</Installation>

As you can see in lines 3,4 above the TPI/V values are different than your existing SDK which tell the SDK where to install.

If you are an author of a NuGet package, you also will want to make your package Windows Phone 8.1 aware.  Again, if you have an existing package that works with Windows 8.1, then you may just be able to duplicate the content/lib/tools to a folder labeled ‘wpa81’ and test that out.  Example NuSpec:

<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
    <metadata>
        <id>Callisto</id>
        <version>1.5.0</version>
        <title>Callisto</title>
        <authors>Tim Heuer</authors>
        <owners>Tim Heuer</owners>
    </metadata>
    <files>
        <file src="lib\portable-win81+wpa81" target="lib\portable-win81+wpa81" />
    </files>
</package>

If you see at line 11 the ‘portable-win81+wpa81’ it allows me to combine the two targets telling NuGet this applies to either.  Of course if I had any nuanced differences I could also just use ‘wpa81’ and put the phone-specific lib (or assets) there.

In both cases if you have any UI aspects, most likely you may want to do some work here to make sure that any UI assets are tailored to the device targets for a great experience.

I hope this helps clarify some of the reference questions that I’ve received and I hope that if you are an SDK author you will work quickly to help your customers realize their goals of a universal Windows app!

Hope this helps!