MarkedUp Analytics is now Available for Universal Apps and Windows Phone 8.1

It’s that time of year again, when //BUILD comes, goes, and invents a totally new way of writing native apps for the Windows Store yet again.

This time around the big announcements were the general availability of Windows Phone 8.1 (AT&T, could you please hurry up and make the bits available please?) and the introduction of “Universal Apps” for Windows and Windows Phone devices.

We’re pleased to announce that the latest version of the MarkedUp Analytics SDK for .NET, MarkedUp 1.3, supports both as of this morning.

You can install the latest version of MarkedUp via NuGet inside Visual Studio – just use this command inside the Package Manager Console:

PM> Install-Package MarkedUp

Now for some details.

Windows Phone 8.1 (Silverlight) vs. Windows Phone 8.1 (Windows Store)

Microsoft introduced some important but unfortunately, confusing changes in the release of Windows Phone 8.1.

There are now two different distinct platforms that you can use for building a Windows Phone application:

  • Windows Phone 8.1 for Silverlight and
  • Windows Phone 8.1 for Windows Store.

Given that you can actually already call many of the WinRT APIs inside Windows Phone 8.0 applications, what exactly makes these two platforms different?

The biggest difference between these platforms isn’t the code used to write the applications (although that’s different too,) it’s the that the Windows Phone 8.1 (Windows Store) gives you the ability to sell your app in any marketplace where WinRT is supported – which are the Windows Phone and Windows Store marketplaces today, and includes the Xbox and other platforms tomorrow.

The Windows Phone 8.1 (Silverlight) platform is just an upgrade for existing Windows Phone-only applications, and doesn’t do much beyond give you access to the new APIs introduced in Windows Phone 8.1. We wouldn’t be surprised if Microsoft deprecated Silverlight-based applications in their entirety within the next couple of releases.

Here’s a comparison chart that we put together which makes it easy to figure out which project type (Silverlight or Windows Store) you need for your specific use case:

Windows Phone Silverlight vs Windows Phone Windows Store

MarkedUp Analytics has 100% feature parity on both platforms as of this release, so no matter which flavor of Windows Phone application you pick, you can enjoy full support from MarkedUp Analytics.

Universal Apps

Universal Apps are a new addition to the Windows Store family, although the concept itself is not new – iOS and Android have both had support for universal phone/tablet applications for some time.

If you install the latest release candidate for Visual Studio 2013 (Update 2), you will get access to Windows Phone 8.1 projects and the Universal App project type. Here’s what a basic C# / XAML universal app project looks like in Solution Explorer in Visual Studio:

universal app in visual studio

You can create universal applications in any of the supported WinRT languages: C#, JavaScript, and C++.

Installing MarkedUp into a Universal App is identical to installing it into a stand-alone WinRT or Windows Phone application – the only difference is that you have to install MarkedUp into both the Windows 8.1 and the Windows Phone 8.1 project.

Once that’s done, you can call MarkedUp inside the Shared/App.xaml.cs file.

shared app xaml

Then we initialize the SDK using an API key – this will use the same API key across both Windows Phone and Windows Store versions of your app.

initialize markedup universal app

If you want to be able to track the installs and downloads of your Windows Phone and Windows versions of the same app separately, you can accomplish this easily using the WINDOWS_APP and WINDOWS_PHONE_APP built-in pre-compilation directives that Universal Apps make available to you:

initialize markedup separate api keys for universal apps

Please remember that the MarkedUp SDK also supports multiple reporting streams, so if you wanted to be able to have a separate bucket of data for each platform in addition to a consolidated view, our SDK makes it easy to accomplish that.

All of the MarkedUp APIs are identical to what’s in our SDK reference for Windows Store applications – we’ve updated some of the code under the hood to reflect some of the changes introduced in Windows 8.1, but these are all invisible to developers like you.

So install the latest version of MarkedUp Analytics off of NuGet and sign up for a free analytics account.

WinRT and Windows Phone 8 Code-Sharing Pitfalls

One of the things Microsoft promised and touted highly prior to and during BUILD 2012 was that it would be possible to share reams of code between your Windows Store and Windows Phone 8 applications.

From MSDN’s “Windows Phone API Reference” here’s what Microsoft made available, taken directly from the article:

 

The Relationship between WinRT and Windows Phone 8 APIs

The diagram has three distinct areas and these are described as follows:

  1. The set of Windows Runtime API not supported on Windows Phone 8. The API surface area of Windows Runtime is very large, with over 11,000 members. We’ve adopted a subset for Windows Phone 8 that allows you to build compelling phone scenarios. Area 1 in the diagram above represents the APIs that are not available on Windows Phone 8.

  2. The set of Windows Runtime API adopted for Windows Phone 8. This is represented by area 2 in the above diagram and consists of approximately 2,800 members. For some types, we have not implemented certain members. For others we have added additional members to support phone-only features. In both cases, these differences are noted in the API reference documentation.

  3. We’ve added key APIs needed to build great apps for the phone. These are represented by area 3 in the diagram and total about 600 members. For example, we have brand-new APIs for speech synthesis and recognition, VOIP, and other features. Creating these as Windows Runtime style APIs means you can use them regardless of the programming language you use for your app.

Naturally there are portions of code that can’t be shared easily, such as device-specific / sensor capabilities and user interface.

However, Microsoft promised that a significant number of WinRT APIs would be made available on WP8 and for a long time touted that “copy and paste” portability would be achievable.

MarkedUp’s SDK technology doesn’t interact directly with the UI or sensors on either WinRT or Windows Phone 8, so the majority of the APIs we use are ones you’d expect to work with both platforms, such as:

  • File system and storage;
  • Serialization;
  • Networking;
  • Globalization;
  • the Windows Store APIs;
  • Licensing;
  • Async and multi-threading; and
  • Unit testing with MSTest.

Our experience in porting our code from WinRT (C#) to Windows Phone 8 (C#) was largely good, although we found some nasty pitfalls along that way. In light of BUILD 2013 and all of the new features coming to Windows Phone and Windows 8.1, we thought it would be a good time to share these.

Networking

System.Net.HttpClient – By far the biggest and most vociferous WinRT & WP8 compatibility issue echoed from the development community is the fact that System.Net.HttpClient, Microsoft’s modern HTTP client that is built from the group up to work with async, advanced media types, RESTful APIs, and so forth. HttpClient is a huge boon to our productivity in the course of working with WinRT.

For reasons that I am not privy to, Microsoft did not include HttpClient in the core framework for Windows Phone 8, so MarkedUp uses System.Net.WebRequest wraps it with the appropriate async and error-handling decorators.

One of the major pitfalls of WebRequest is that it throws an exception whenever you receive an HTTP code that isn’t in the 200 (“Success) category. Trying to handle these exceptions asynchronously complicates things considerably, but it can be done.

It should be noted that HttpClient for Windows Phone 8 is available as a separate NuGet package. We can’t use any third party dependencies in our SDK but you are certainly free to use these inside your apps.

System.Net.WebRequest APIs are different across .NET 4.5 / Windows Phone 8 and WinRT – One strategy for dealing with the lack of HttpClient availability on Windows Phone 8 is just to use System.Net.WebRequest everywhere, including WinRT. This is something we tested since standardizing on a single HTTP layer helps reduce our QA overhead.

Our experience was that while vanilla .NET 4.5 and Windows Phone 8 have 100% reuse and compatibility when it comes to WebRequest, this is not the case with WinRT.

For instance, WebRequest does not have any directly settable ContentLength or UserAgent properties in WinRT; WebRequest has a different interface altogether for forming HTTP request bodies in WinRT. Additionally, the System.Net.WebException enum implementation in WinRT is missing a number of options that make it difficult to perform error-handling consistently across platforms.

We ultimately determined that it was less expensive to maintain two different network stack implementations for Windows Phone and WinRT than to try to work around all of the incompatibilities and different behaviors with WebRequest in WinRT.

File System

Windows.Storage.Search is not fully implemented on Windows Phone 8 – For most WinRT developers, Windows.Storage.Search is probably used for one specific purpose inside any given app: determining whether or not a file exists.

Since there isn’t an equivalent to File.Exists in the Windows.Storage namespace, most developers (us included) have to resort to something like this:

One issue that we ran into early on in our QA for Windows Phone is that not all search options which use a Windows.Storage.Search.CommonFileQuery enumeration are implemented in Windows Phone 8. For instance, CommonFileQuery.OrderByName will throw a NotImplemented exception.

However, you can work around most of these issues by just using CommonFileQuery.DefaultQuery if the ordering of the files returned isn’t particularly important.

Licensing

CurrentApp.LicenseInformation doesn’t actually tell you if your Windows Phone 8 app is running as a trial or not – WinRT developers rely on CurrentApp as the single source of truth for all things Windows Store and licensing on Windows 8, and the class is available on Windows Phone 8 and is what developers use for executing in-app purchases.

However, for reasons unknown, the data returned from CurrentApp.LicenseInformation doesn’t have the IsTrial flag set in accordance with the actual licensing status on Windows Phone. Instead, you have to use the legacy API from Windows Phone 7, new Microsoft.Phone.Marketplace.LicenseInformation().IsTrial(), to get that information.

In order to make things more tenable for our x-platform development with WP8 and WinRT, we wrapped CurrentApp into a class called CurrentAppProxy and have it call the appropriate WP8-specific method when inferring licensing information.

Commerce

CurrentAppSimulator does not exist for Windows Phone 8, thus there’s no built-in way to test in-app purchases – We depend on CurrentAppSimulator when testing anything that touches a trial conversion or in-app purchases, so we were a little shocked when we discovered that it isn’t included in Windows Phone 8.

Microsoft subsequently shipped their own mock in-app purchase library for Windows Phone 8, but since we have a shared testbed between WinRT and WP8 and can’t use any third party dependencies anywhere in our SDK we ended up writing our own. We will likely open source it on Github eventually.

No ListingInformation.CurrentMarket – One of the really handy features of ListingInformation in WinRT is the ability for it to tell you the current marketplace of any given user right off the bat using ListingInformation.CurrentMarket; this is important from an analytics point of view and really important if you manage your own commerce engine and want to localize prices in different currencies.

In Windows Phone 8, this method throws a NotImplemented exception. So how do you look up this information on WP8? Thanks to some smarties at StackOverflow, it turns out that System.Globalization.RegionInfo.CurrentRegion can’t be changed by the end user and is the culture reported by the phone to the store for any in-app purchases.

Globalization

RegionInfo uses different constructor arguments on WinRT and Windows Phone 8 – in WinRT, you can construct a new RegionInfo object by passing along the two-character ISO country code that you might receive from a marketplace method. This works great particularly when coupled with CurrentApp.

In Windows Phone 8, you’ll get an ArgumentException every time – in WP8 RegionInfo only accepts the culture name itself, i.e. “en-US,” as the constructor argument, not the region name.

GlobalizationPreferences.HomeGeographicRegion does not exist in Windows Phone 8
when try to establish the local time and culture for a user in WinRT, GlobalizationPreferences.HomeGeographicRegion makes this a breeze if you need to account for local time or any other globalization preference. This API does not exist in Windows Phone 8, but because a user can’t change their region settings you just just use RegionInfo.CurrentRegion.

Serialization

DataContractJsonSerializer doesn’t actually respond to EmitTypeInformation flags – one of the lesser-used features of DataContractJsonSerializer is its ability to control whether or not it includes type information in its outbound JSON payloads via the EmitTypeInformation property; this feature is really useful if you’re sending data to an ASP.NET MVC service and want to disable type hints so the model binder doesn’t fail.

Unfortunately, in Windows Phone 8 they never implemented the control flow that responds to this flag, so you get type information always whether you want it or not. Ultimately, we had to parse out type information using a regular expression upon serialization in order to resolve this issue for Windows Phone 8.

We hope this has been information – let us know if you have any feedback in the comments!

Gaining Access: Making Sure Your Windows 8 App Background Task Has What It Needs

Overview

In Windows 8, Windows Store (formally known as metro style) apps have the ability to define background tasks that can perform tasks that run even when the app isn’t in the background. Though to make sure the user’s battery doesn’t cry uncle prematurely these background tasks are resource constrained. In this post we’ll take a look at how Windows 8 does resource management for background tasks.

The Constraints

Windows 8 performs resource management for background tasks through the use of resource constraints. There are two main types of constraints a background task needs to worry about: CPU time and network usage. The amount of CPU time and network usage an app’s background task is allocated depends on if the app is on the lock screen or not.

A Windows Store app is considered a lock screen app if it occupies one of the seven available lock screen slots on the lock screen.

When your app is a lock screen app Windows will give your background tasks a higher quality of service over resources then a non-lock screen app. The CPU time constraint is enforced regardless of the current power state of the device but the network usage constraints only come into play when PC off of AC power.

 

Note: Windows will dynamically adjust the network usage constraint based on the power usage of the active network link. Typically, Wi-Fi connections use less power than the cellular connections and will be allowed to send more over the link over a given period of time than cellular connections.

The Elite

Among all the possible triggers available to an app to trigger their background tasks the following triggers are considered “critical” as far a Windows is concerned.

  • Push notification trigger
  • Control channel trigger

These triggers are meant to be used during real time scenarios like receiving a VOIP call. These background tasks are given guaranteed app resource quotas according to the resource quotas listed previously. Meaning Windows will not try and terminate these tasks early even if the system becomes resource constrained. These triggers require an app to be a lock screen app in order to be used.

The Hook

If your app doesn’t require the increased resources or trigger capabilities of a lock screen app you’re better off sticking with triggers that don’t require lock screen capabilities. It’ll simplify things but from a programming and certification standpoint and from a user standpoint in terms of battery life.

If you do require lock screen capabilities for your background tasks here’s what you need to know. To be on the lock screen you’ll need to provide an additional image asset, a 24 by 24 pixel png image, for the badge that gets displayed on the lock screen. As there are only 7 slots available on the lock screen for apps you’ll be competing with other apps for those slots so you’ll have to make a compelling case to the user to add your app. Which brings us to our next point, the app will needs to be added to the lock screen explicitly by the user.

That last point is key, there is no programmatic way to add an app the lock screen. Windows does toss the app a bone by giving a way for the app to programmatically ASK the user to add the app to the lock screen though the BackgroundExecutionManager.RequestAccessAsync() method but it comes with a big caveat. It’s a one shot deal. No matter the outcome: yes, no or dismissed it will only work once.

Making the Connection: Lighting up Metro IE’s Ability Direct Link to an App in the Windows Store

How do I make users aware that my app exists? That’s most likely one of the most prominent questions a developer’s ask themselves when they release an app, and for good reason. No one likes to see their hard work go to waste. A little known feature in Metro IE is its ability to advertise the availability of Windows Store app (also known as a Metro style app) for the current website in the Windows Store though Metro IE’s appbar.

Metro IE allows a website to specify the following actions for an app:

  • Install an app if it’s not already installed
  • Switch to an app if it’s already installed

A website can choose to have just one of the options active or both depending on their needs. The way Metro IE recognizes a website has an associated Windows Store app is through the use custom meta tags in the header area of a website’s page.

The minimum required meta tags to light this up are:

  • msApplication-ID
  • msApplication-PackageFamilyName

Both of these can be found in the app manifest of the project once the app is associated with store though Visual Studio and are used to link the website and Windows Store app together.

When an app is launched though Metro IE in this manner a custom argument can be specified through another meta tag with the name “msApplication-Arguments”. The app can then read this argument from the OnLaunched method in App.xaml.cs.

As actions speak louder than words, if you want to see this behavior in action you just visit Relay’s website in Metro IE and give it a try. For context, Relay is our sample notification app, feel free to give that a try too while you’re at it :)

The Bing homepage also has this integration setup if you want to see another live example.

Until next time!