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.

The Future of MarkedUp: Support for all Major Native App Platforms

MarkedUp Users and Customers,

If you’ve logged into your MarkedUp Analytics dashboards in the past day or so, you might have been surprised by the new look and feel of our site. We hope you enjoy it!

And it’s not just the look and feel of our site that’s different.

MarkedUp: No Longer Only for Windows 8, Windows Phone

The first thing you’ll see on markedup.com today is this:

Future native app plaftorms MarkedUp Analytics will support: Win32, Android, iOS

Our team has enjoyed working with WinRT and Windows Phone developers over the past year and a half, and we want to bring our services to developers working on other platforms too!

Our goal is to enable developers of all shapes and sizes ship better, more satisfying software to their end-users – and we want to do this on every platform developers care about!

Sign up for early access to Win32, iOS, and Android updates from MarkedUp

We’ll keep you updated on our latest progress for each platform, including access to early binaries and platform-specific services.

Click on any of the links below to sign up!

Coming Soon: MarkedUp Analytics for Windows Desktop Applications

win32

The first new platform that MarkedUp will fully support is Win32 – the platform used for building traditional Windows desktop applications.

We may have mobile and touch platforms like iOS and Android to thank for the resurgence of native application development over the past five years, but the Windows Desktop is the original developer platform.

The Windows Desktop economy is strong and growing, doing over $100b+ a year in license + services sales directly to end-users annually.

However, it’s a market that largely predates the Internet – and thus it’s had trouble adopting all of the software sales + marketing + product best practices that are commonly used throughout modern software development shops, largely due to lack of third party services and tools.

Modern software development practices depend on connected services like analytics and marketing automation to in order to make data-driven decisions, and it’s MarkedUp Analytics’ intention to finally make some of these services available to Windows Desktop developers.

Sign up for MarkedUp Analytics for Windows Desktop (Win32) waitlist.

The details

MarkedUp Analytics will support the following flavors of Win32 development:

  • Windows Forms: .NET 3.5 and later
  • Windows Presentation Foundation: .NET 3.5 and later
  • Native C/C++: Windows XP and later

Holy crap, you’re supporting C/C++ applications for Windows?!?!?!

Yes! Our native C/C++ components will support the all of the same APIs that are available in the .NET flavors of our Win32 SDK.

Worth noting: our C/C++ SDKs will depend on .NET.

How will your WPF / WinForms support compare to your WinRT and Windows Phone APIs?

They’re virtually identical. The only major difference is that our .NET 3.5 / .NET 4.0 / .NET 4.5 SDKs for WPF and WinForms development will expose more methods for manually handling events such as app start / termination.

Win32, by its very nature, is a much more open platform than WinRT / Windows Phone and thus the developers have a lot more options when it comes to how they manage the lifecycle of their applications.

Thus, we decided it would be inappropriate for MarkedUp to try to automate some of the things we do on WinRT and Windows Phone.

How can we access the Win32 binaries for MarkedUp Analytics?

As with our WinRT and Windows Phone SDKs, you will be able to download MarkedUp’s WinForms and WPF SDKs via NuGet.

For the native C/C++ SDKs, we will make downloads available via our CDN.

When will you make the Win32 SDKs available?

Find out.

iOS and Android

There are a ton of choices for iOS and Android when it comes to app analytics and reporting – when we were developing apps ourselves, we frankly felt that many of these services were difficult to use, had sub-standard reporting, and non-existent service.

We still feel that way.

Thus, we are making it a goal of our to provide support for iOS and Android in the near future! They’re further out than Win32 support, but we’ll keep you updated on the latest.

Best,

-The MarkedUp Analytics Team

MarkedUp SDK v1.2 for Windows Store and Windows Phone Apps: Lets You Help Your Users Manage Their Privacy

People of MarkedUp,

Today we released MarkedUp Analytics SDK for .NET v1.2, and it’s the first of many planned updates to our SDK and reporting dashboard coming over the next couple of months.

This update is for Windows Phone 8 and Windows Store developers, and it has a number of important fixes and updates – I’ll start with the minor ones:

  1. Full support for logging nested inner exceptions and stack traces in C#;
  2. Fixed a bug with capturing the app version # from the wrong place in Windows Phone;
  3. Fixed some performance issues on Windows Phone, related to reinitializing tombstoned apps;
  4. And various other minor bug fixes and improvements.

Allow Your Users to Take Control of Their Privacy with Analytics Opt-Out

Within a day or two of our initial launch a year ago, the first feature request submitted to MarkedUp’s UserVoice page was a feature to enable MarkedUp customers to allow their users to opt-out of analytics.

Well today, we’re marking that issue as resolved. With MarkedUp v1.2, you can now use the built-in AnalyticClient.OptOut method to allow users to opt-out of tracking. Users can also opt-back-in at a later date using the same method if you wish.

tracking-opt-outs

We’ve also added a new chart that allows you to see how many users opt-out of MarkedUp Analytics, which you can find under Users –> Tracking Opt-Outs.

opt-out-chart

With this tool, you can now give your users control over whether or not you collect any information on them.

How to Use Opt-Out

If you’ve installed MarkedUp into your Windows Store or Windows Phone application, you just need to call one method to opt-out a user.

Users are tracked by default, so if you want to enable them to opt out you should add an “Opt Out of Tracking” option to your settings page.

Here’s the code you need to call to opt a user out of MarkedUp Analytics tracking:

WinRT and Windows Phone (C# / XAML)
MarkedUp.AnalyticClient.OptOut(true);

WinJS (HTML5/JavaScript)
MK.optOut(true);

That’s it! Click here for more detailed instructions.

Privacy is a growing concern among native app developers and app consumers, and we heard your requests and feedback and provided you with a dead simple tool for allowing your app’s users to control their privacy.

If you have questions, reach out to us at support@markedup.com or reach out to us on Twitter (@MarkedUpMobi.) We’re happy to help!

-Aaron

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!

Available Now: MarkedUp Analytics for Windows Phone 8

MarkedUp Analytics now available for Windows Phone

Windows Phone 8 support has been a long-requested feature for MarkedUp and it we’re pleased to announce that as of today, June 19th, MarkedUp Analytics fully supports Windows Phone 8!

If you install the latest MarkedUp Analytics SDK for .NET from NuGet, it will automatically work in any Windows Phone 8 application.

Here are some things you need to know about the MarkedUp Analytics SDK for Windows Phone 8:

1. The MarkedUp SDK for Windows Phone is virtually identical to the WinRT SDK for C# / XAML – you can port all of your MarkedUp SDK calls from any XAML-based Windows Store application to a Windows Phone 8 application with no changes. See the updated MarkedUp SDK Reference for more details.

2. The SDK maintains a slim file size (~200kb) so you don’t need to worry about it affecting your app’s download size from the Windows Store.

3. The SDK automatically enables the app capabilities it needs to run during your NuGet installation, so you don’t have to do anything. See the Windows Phone 8 App Requirements for more details.

4. You can now add Windows Phone project types to your MarkedUp dashboard. Click here to add a Windows Phone 8 app to your dashboard right now.

And most of all…

It only takes 3 minutes to install MarkedUp into your Windows Phone app and see live data.

Don’t believe us? Watch our tutorial video below.

How to Install MarkedUp Analytics for Windows Phone 8 Apps

 

We’re thrilled to make our services available on Windows Phone 8, and we’re always striving to do an even better job serving the needs of app developers everywhere. So if you have any suggestions for what we can do better, please leave us a note on our UserVoice. Thanks!

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 :)