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!

5 Key Themes from Microsoft on the Future of Windows and WinRT from the //BUILD Keynote

Build Windows 8

This week I’m attending //BUILD conference in Redmond, WA on Microsoft’s main campus alongside thousands of other .NET / Windows developers. The keynote ended about an hour ago and I wanted to publish my thoughts on some of the important takeaways from Ballmer’s talk.

Microsoft’s Points of Emphasis

1. “Microsoft can only win by training consumers to expect consistent behavior, availability, and synchronized data across all of their different devices”

WinRT isn’t just about tablets – it’s also about fundamentally changing the way desktop software is consumed and unifying mobile / desktop / tablet and probably console apps all under one consolidated platform.

The unification of these platforms is the future of Microsoft; training consumers to expect consistent behavior and access to data across all of their devices is the only way Microsoft will be able to dethrone Apple and Google in mobile / tablet and protect themselves in desktop / console in the long-run.

Ultimately, Microsoft is really the only company that can execute well on native software, services, and devices. They are playing to their strengths (ecosystem and platform) and are doing it well here.

2. “The fate of WinRT is in the hands of developers big and small.”

Microsoft desperately needs developers to make WinRT a success.

Microsoft, for the first time since Win32 emerged as the victor in the desktop wars of old, is in a position where it needs developers more than they need Microsoft.

The unified vision behind WinRT will not work without the buy-in of developers both big and small, from Facebook to the individual hobbyist developer.

Microsoft will do the hard work of putting devices in the hands of consumers that bring WinRT applications to the forefront (which I suspect is the real reason why the ARM-only Surface shipped so far ahead of the Intel one.) But it is totally reliant on developers to put the content in-store that consumers actually want to use.

3. “Microsoft and Nokia will work themselves to death to win the support of developers.”

Compounding key takeaway #2, Microsoft and Nokia both made commitments to put hardware (Nokia phones, Surfaces for us //BUILD attendees) into the hands of developers who build apps.

Having worked at Microsoft Developer Platform Evangelism throughout the entire WP7 push, I can tell you that this is no joke – Microsoft will find a way to arm its developers with hardware now that it’s all generally available.

But they’re not stopping there – Microsoft is going to continue to push training events, hackathons, webcasts, and everything it can possibly do to train developers and make it easier than ever to learn a new platform and actually ship an app on it.

I think this is tremendously positive and every developer who’s interested in the platform will have multiple opportunities to learn it on Microsoft’s dime.

4. “Don’t ship apps that don’t leverage the platform.”

Reading between the lines in some of the keynote speeches and the first couple of sessions I poked my nose in, you can interpret the following from Microsoft:

Developers who carbon copy their work byte-by-byte from previous platforms, including web apps, are doing themselves a disservice and will have their lunch eaten by developers who take advantage of charms, live tiles, and all of the other unique built-in features to Windows 8. Please take advantage of the platform if you’re going to build an app for it!

This echoes the same general theme I wrote about in an earlier post decrying Windows 8 developers shooting themselves in the foot with respect to Windows Store economics: Windows 8 is different so treat it differently than iOS / Android / Web.

Speaking more broadly, most consumers have never interacted with Metro much, aside from perhaps the Xbox launch screen.

If Metro and WinRT are going to take off with consumers then it will be due to the highly differentiated hardware and software capabilities of the platform, not price point or any other factors.

If developers don’t take advantage of those differentiated OS capabilities, then it limits the overall differentiation of Windows 8 from everything else in market, including prior versions of Windows.

5. “Windows Phone 8 is just as important to the success of Microsoft as Windows 8.”

Extending theme #1 a little bit further… Windows Phone 8 was heavily, heavily emphasized over Windows 8 itself during Ballmer’s talk… We’d heard hardly a peep about it prior to it’s official launch yesterday.

Here’s why: the success of Microsoft’s entire consumer software ecosystem rides on consumers adopting the Metro UI and getting used to the rest of Microsoft’s services ecosystem, which includes your apps in the Windows Store.

Windows 8 will move hundreds of millions of units regardless, due to the inertia of Microsoft’s desktop / laptop business alone. The rise of Microsoft Surface devices we’ve seen on our Windows 8 launch tracker also makes the future for WinRT tablets look a lot more promising than it was a week ago.

However, without a significant presence in mobile, Microsoft and Windows will always have the threat of a unified iOS / OS X ecosystem there to sweep the desktop market out from underneath it. Windows Phone 8 is not a side show – it’s part of the core front Microsoft is forming against Apple on consumer computing.

Parting Thoughts

This is a really exciting time to be a Windows developer. The opportunities for developers to build sustainable businesses around Windows 8 and Windows Phone 8 apps are huge and there for the taking.

On top of that, the ecosystem has never been more accessible – you can build native apps for Windows 8 and Windows Phone 8 with C# or C++, and I suspect we’ll eventually see WinJS apps make their way onto Windows Phone 8 too.

That’s why our team at MarkedUp is excited to be doing what we’re doing :)