Feeds:
Posts
Comments

The Windows 8 and Windows Phone developer dashboards offer some fantastic and useful metrics without developers having to lift a finger. This is great for tracking the basics such as purchases, downloads, & crashes but if you’re serious about understanding your users and improving your apps, you’ll quickly realize there are easily dozens of questions this data fails to answer. Or maybe you just want near real time information.

In a quest to improve my own apps: PuzzleTouch for Windows Phone and PuzzleTouch for Windows 8, I created the Google Analytics SDK for Windows 8 and Windows Phone and am excited to share my work with other developers. This SDK is a full featured Google Analytics client-side open source library to help your app report data to the new Google Analytics service just released last month. It supports both Windows 8 store apps and Windows Phone 7 & 8 apps and includes the same features offered in the Google Analytics SDKs for iOS and Android.

ga_realtime

Aren’t there already some great open source Google Analytics libraries out there for Win8 and WP developers?

The short answer: Yes, but they don’t work with the latest version of Google Analytics. If you want all the great new features supported today by Google Analytics or if you are setting up Google Analytics for your app for the first time, you are are required to use an SDK that supports the new Google Analytics Measurement Protocol. This new protocol is completely different from the older UTM protocol and is not backward compatible. As far as I am aware, no others libraries exist at the time of this post.

Find out more on the Google Analytics for Windows 8 and Windows Phone SDK CodePlex page about how and if this affects your existing apps.

What additional features does the new Google Analytics service include?

The ability to track and filter by app name and version.

This is extremely powerful and allows you to:

  1. Create one property for all your apps (Windows 8, Windows Phone, Android, iOS, …etc) and use filters to view them separately.
  2. On the flip side, it also allows you to compare all apps against each other.
  3. Create arbitrary filters to allow you to group certain apps (for example, you could see data for both the WP7 and WP8 version of your app as well as see that data separately.
  4. Radically change what data you track from one version to the next and create a new filter to only view data from newer versions of your app without loosing old data or having it pollute new data.
  5. Track different editions of the same app. For example, you might have a free and a paid version that you want to track together yet be able to filter on.

Track exceptions and crashes

The Windows Phone and Windows Store dashboard both offer a way to see stack traces from crashes. However, the Windows store requires some effort to see your stack traces (for Xaml based apps) and both take at least two days before data data shows up (often much longer from my experience).

When you release a new version of your app, one of the most valuable things you could possibly know is “did I break something”? The new Google Analytics service offers a great way to capture errors (handled and unhandled) in near real-time so you can analyze what went wrong and try to ship a fix before more users are affected. Don’t think you’re immune to needing this! :)

Custom dimensions and metrics

Custom dimensions and custom metrics are like default dimensions and metrics (e.g. sessions and page views), except you create them yourself. You can use them to collect up to 200 data points that Google Analytics doesn’t automatically track. These offer numerous advantages to the old custom variable feature. Read more about custom dimensions and metrics.

Screen views and more

If you’re familiar with the classic version of Google Analytics, you may remember that screen views were displayed as page views. Google Analytics classic tried to treat your app like a website and with it came irrelevant information such as bounce rate and referrers. The new version of Google Analytics knows if you’re tracking an app and the reporting tools have been overhauled to easily help you find information relevant for apps, not websites.

Additionally, there are some additional improvements to allow you to tie custom events to specific screens in your app. No longer will you have to create 2 different events and prefix the name with the name of the page from whence it came.

E-Commerce

Possibly the best new feature of all is E-Commerce tracking. Now you can treat transactions like transactions and not have to stuff them in custom events with overloaded point values. Google Analytics easily shows you how much money you’re making in your currency of choice and information about what lead up to a purchase.

Much More

Plus, there are many other new features in Google Analytics like app timings (e.g. how long did it take my game play screen to load?), social network tracking (e.g. do users like sharing on FaceBook or Twitter more?), and much more.

How do I get started?

If you have an iOS or Android app, Google has already built SDKs for you.

If you want to track a Windows Phone (7 or 8) or Windows 8 Store app (JavaScript, C++, or .NET), go to CodePlex to learn more about the Google Analytics SDK for Windows 8 and Windows Phone or download it from NuGet.

Google Analytics itself is free (at least until you reach its quota). It’s extremely easy to spin up a new account, property and profile and start testing immediately.

The Google Analytics SDK for Windows 8 and Windows Phone is free and open source under the Ms-PL license (basically don’t sue me and use it for whatever you want).

What about other 3rd party analytics services?

There are other 3rd party analytics services available today with their own SDK. Some of these might be better than Google Analytics but I haven’t had a chance to check them out personally. Feel free to post a comment from your own experience with another analytics services.

Azure Blobs is a great, inexpensive, and scalable cloud storage service that you can use to host any static file. In particular, I find it extremely useful for hosting progressive download videos (e.g. .mp4 files). Note: if you need the uber-solution (encoding, adaptive streaming, …etc) check out Windows Azure Media Services which offers a full range of services to deliver high quality video to a range of different platforms.

While Azure Blobs is very easy to setup and manage, there’s one essential configuration setting you will want to change before serving progressive download video that isn’t so obvious: byte-range support.

Let’s start with the problem. Out of the box, if you throw a .mp4 file on your Azure Blobs container and point your video player at the video, you’ll see the video play and buffer just fine. But, what happens, when you try to seek to an unbuffered portion of the content?

image

Result: Buffering, waiting, annoyance, time for a coffee break?

image

The reason is simple: by default, Azure Blobs does not enable support for byte range requests. Described with less jargon: in order to jump to a portion of the video that hasn’t downloaded yet you can either:

1) wait until the download (buffer) catches up to the new position of playback (results seen above) or

2) the solution: tell the server to skip all the data yet to be buffered prior to the new position (identified below in red) and instead start buffering from the new position.

image

Under the hood, this is supported automatically by most modern video players AS LONG AS the server serving the video supports returning byte ranges and returns the response header: “Accept-Ranges: bytes”

The good news is, Azure Blobs does support this, you just need to enable it by setting the default version of the service to a newer one.

The bad new is, this setting is not exposed in the Azure Portal nor most tools I’ve used (e.g. CloudBerry).

So how do it change it? Send a Set Blob Service Properties REST API request.

Seriously? Isn’t there an easier way? Well, there are free tools out there to do this for you. For example: Plasma AzureBlobUtility.

BlobUtility.exe -k AccessKey -a AccountName -c ContainerName --setDefaultServiceVersion 2012-02-12

Or, if you’re paranoid like me and don’t like to give the key to your house to a stranger (no offense Plasma). Here are the steps and code to do it yourself in VS2012 in <1 minute:

image

Create a new C# project. (I chose a WPF application which is probably not the best choice but I’m just going to throw this away when I‘m done).

image

Add a NuGet package for Azure Storage by right clicking on your project and choosing Manage NuGet Packages.

image

Search for “azure storage” and install the “Windows Azure Storage” NuGet Package by Microsoft.

Finally, add the following code to your app, replace the account name and secret key for your Azure Blobs account and run it…

public MainWindow()
{
    InitializeComponent();

    var credentials = new StorageCredentials("myaccountname", "mysecretkey");
    var account = new CloudStorageAccount(credentials, true);
    var client = account.CreateCloudBlobClient();
    var properties = client.GetServiceProperties();
    properties.DefaultServiceVersion = "2012-02-12";
    client.SetServiceProperties(properties);
}

Notice that we didn’t need to specify the container. This change will apply to all containers for that account.

DONE! Now all videos served from your Azure Blobs account will support seeking into the unbuffered area of the video without significant delay.

A few months ago I was speaking with a reporter and was asked which development model the industry was gravitating toward for Windows 8 apps. My impression was that Xaml + C# appeared to be strongest out of the gate but only time would tell if JavaScript+HTML would slowly close the gap.

So far, this hasn’t happened. C# (and VB) + Xaml development has held its ground as by far the most popular development model for Windows 8 Metro Store apps. In fact, preference is now over 3 to 1 over JavaScript + HTML.

Since early April, I’ve been taking random snapshots of the number of posts on the MSDN Windows 8 development forums and here are the results…

UPDATE for Oct 28: C#/VB gains even more ground…

image

image

Raw data:

Model 9-Apr 14-Jun 31-Jul 22-Aug 28-Oct
JavaScript 3645 5926 7831 8573
10631

C++ 2779 4494 5647 6263
7914

C#/VB 10030 16337 21921 24798
34562

What is the trend? If anything C# is gaining share…

imageimage

imageimage

I have numerous opinions about why this is the way it is, but I’ll leave this speculation for another day. Why do you think C# and Xaml are more popular for Windows 8 development? Or is counting forum post a poor way to measure?

In case you missed the news, Microsoft just hit a major milestone on its road to shipping Windows 8 with the public launch of the Release Preview version. With this new version comes new features and as expected: a number of trivial, yet importing changes that will affect app developers and their apps.

Meanwhile, here at Vertigo we’ve been toiling day (and sometimes night) to help developers and clients prepare for this update so they can hit the ground running and create some of the first apps to ship on the new platform.

One such effort that we were proud to release alongside the launch of Windows 8 Release Preview is the update to the Microsoft Media Platform Player Framework (an open source video player component for Windows 8 metro style apps).

win8_pf.jpg

While Windows 8 includes some essential and great components to help building top notch media apps (namely the MediaElement for Xaml developers and the Video tag for JavaScript/HTML developers), the purpose of these components is primarily aimed at providing the fundamentals and low level support for playing audio and video. We here at Vertigo Software know video and we know that there is still a mountain to climb before you can ship a great media app. In a joint effort with Microsoft, we’ve worked hard to fill this gap by building a media player framework to make it simple and straightforward to accomplish the vast majority of your media app needs in Windows 8.

The Microsoft Media Platform Player Framework ships with a JavaScript and Xaml version of the framework that offers out of the box features to build great video apps without the fuss and months of development required to build your own media player. Besides support for the Windows 8 Release Preview, our latest update also includes support for major features such as player DVR controls (scrubbing, FF, RW, play/pause, …etc), player styling and branding, closed captioning, and just released today: video advertising!

Video advertising is very different from traditional banner advertising – which is already included with the Microsoft Advertising SDK. Video advertising allows you to seamlessly connect to video ad servers and stitch together commercials, overlays, and companion ads with your own content.

Advertising is an extremely important monetization strategy for many media companies and an equally significant undertaking to build from scratch. With the latest version of the player framework, you can simply add the new advertising plugin, schedule when ads should play and point your app at a VAST standards compliant ad server to play ads with your content. Ad scheduling, downloading, playback, and tracking is all handled for you by the player framework using IAB recommended standards such as VAST and VPAID.

Download everything you need today to start (or finish) your media app for Windows 8:

Microsoft Media Platform Player Framework

Windows 8 Release Preview

Visual Studio 2012 RC

Smooth Streaming SDK

PlayReady DRM SDK

 

Enjoy!

Need to build an app that plays video? This week we released a new version of the MMP: Player Framework (formerly the Silverlight Media Framework) made for Windows 8 Metro style applications.

With guidance the Windows 8 and IIS teams, we (Microsoft Media Platform team & Vertigo Software) created an open source media player framework that you can use for both HTML-based and XAML-based Metro style applications.

image

Support for HTML and XAML

The player framework supports both HTML/JavaScript and XAML/C#/VB based Metro style applications. Technically, there are two different components (one for HTML and one for XAML based apps), but they share very similar APIs, feature sets, and in some cases even share the same source code. Under the hood, the XAML version is built on top of the MediaElement that ships with .NET and similarly, the HTML version is built on top of the HTML5 <video> tag.

Our primary goal was to ensure both flavors felt natural and familiar to both HTML and XAML developers. If you are an HTML/JavaScript developer, using the JavaScript version will be very similar to using the other JavaScript controls that ship with Windows 8 as well as those already familiar with the HTML5 <video> tag. If you are a XAML/managed code developer, you can expect the XAML version to adhere to the practices and patterns of .NET & Silverlight controls.

Extensibility

The framework: We refer to the player framework as a framework as opposed to a control or component because it is intended to be a mini-platform in it’s own right. While these details will be hidden to the majority of developers using it as is out of the box media player, the player framework is built on a plugin style architecture that enables the feature set to be expanded and evolve after the fact without touching the core code base. In fact, many of the features currently in the framework are implemented as plugins. For example: the main control bar that the user interacts with is technically a plugin that could be swapped in our out for a radically different implementation.

Styling: One of the most common requirements in building a media player is to be able to skin the UI to match your brand. By default, the player framework ships with a Metro style skin, but you can easily modify the look and feel of the player from CSS or XAML without having to build a custom player.

Open source: the player frameworks ships with full source code under the liberal Ms-Pl license. Crack it open and see how it ticks or make changes to suite your needs.

How similar is it to the existing HTML5 or Silverlight versions of the player framework?

You may already be familiar with the existing HTML5 for the web or Silverlight for the web/desktop and phone versions of the player framework. The Windows 8 version of the framework should feel familiar and is in fact based on much of the same code. However, you should not expect full compatibility. We wanted to make sure the player framework felt like it was made for Windows 8 Metro style apps and it’s respective development model (HTML vs. XAML). We also wanted to meld the two versions and their APIs when it made sense. Lastly, we used this opportunities to make architectural improvements that would better position the framework for a long and bright future.

Features

You’ll find that the player framework has an extensive API chocked full of many useful hooks and features. From 30,000 feet, here is a sampling of features you will find in v1 of the player framework.

  • VOD
  • Progressive video
  • Smooth streaming
  • Rich DVR (Play, pause, stop, fast forward, rewind, skip next & back, seek-able timeline, volume, slow motion, instant replay)
  • Full screen
  • Closed captions (plain text for Xaml and WebVTT for js)
  • Styling support
  • Buffering and error/retry visual states.
  • Poster image
  • Click-to-play UI to let the user choose to start watching.
  • All features already included with the MediaElement and <Video/>
  • Playlist
  • Chapters
  • Timeline markers
  • Support for localization
  • Compact UI for snapped view
  • Support for DRM (e.g. PlayReady)

What’s next?

The fun doesn’t stop here. We’re already hard at work on more features. Here are some prominent ones in the cards.

  • Adaptive streaming APIs
  • Advertising
  • Audio player
  • TTML closed captions
  • Audio track selection (multi-language audio)
  • Live video

Got feedback?

We’d love to hear your feedback and make sure the player framework offers the features and functionality you need in your apps. We encourage developers to check out the player framework on CodePlex and post feedback on the CodePlex forum.

Hope you enjoy!

In my earlier post I created a high level breakdown of the APIs shared by both Silverlight and WinRT…

image

Here I’m providing a complete reference of all 6,585 public types and 15,248 members included in Silverlight 5 and/or WinRT and where they overlap.

My hope is that this will serve as a reference to Silverlight developers trying to get up to speed with WinRT.

Click here to see the WinRT Genome Project results.

image

 

Note: Please let me know if you see an errors or have requests. I’ve only begun to comb over these results myself and will be looking for ways to improve it going forward. Enjoy!

What is the hardest part about learning a new programming language? I’ve often argued that learning a new language is easy, it’s learning a new framework is can be time consuming.

In case you’ve been living under a rock lately, you probably already know that Windows 8 Metro style apps can be built with Xaml & C#. This means that .NET & Silverlight developers can leverage their existing skillset to easily build Win8 Metro Xaml style apps. But just how similar is Silverlight to WinRT?

In an effort to get some real numbers, I created a program to iterate over all the default assemblies included WinRT and compare with those found in Silverlight 5. Here’s what I found:

image

 

Of those 1,582 matching types, here is a look at the members (properties, method, & events) they have in common:

image

 

Comparison details for those interested:

  • I included all Silverlight 5 assemblies installed as part of the SDK. Other assemblies such as RIA services and the Silverlight Toolkit were not included.
  • The public Silverlight 5 RC was used. IMO it is highly unlikely any numbers will change once the final version is released.
  • Differences in namespaces, type accessibility, and base classes were still counted as a match. For example, I ignored differences such as a type being sealed or implementing ISerializable.
  • Similar liberties were taken with members.
  • Property get & set methods and event add & remove methods were not counted as unique members.

My key takeaways:

  • WinRT includes a ton of new types. Some of these are certainly for new features such as the marketplace, accelerometer support, …etc. Time to start learning!
  • Approximately 1/4 of the types in Silverlight are not present in WinRT. Some of these are no longer relevant like the types associated with the DOM bridge or Out of Browser support.
  • When comparing just the shared types, SL5 starts to look very close to an actual subset of WinRT. This is good news for Silverlight developers because it means most of your existing code should easily port.

Coming soon: I also have a side-by-side comparison of the entire WinRT and SL5 API so you can explore each and every difference in their respective APIs. Check back soon.

Update: Detail now available, here’s a complete comparison of every single public API in WinRT and Silverlight 5 and where they match.

Follow

Get every new post delivered to your Inbox.