PreEmptive Analytics Supports Xamarin Developers
Xamarin lets a developer write in C# and then generate native iOS, Android, Windows Phone, and Win8 applications. With PreEmptive Analytics API for Xamarin, the PreEmptive Analytics API (C#) can be consumed by Xamarin to produce fully instrumented native Android, iOS, Windows Phone, and WinRT apps.
However, PreEmptive Analytics Instrumentation for Xamarin establishes an important precedent – it is the first application analytics instrumentation API built to work within an application generator rather than the target runtime itself. ...like the rest of the Xamarin experience, application instrumentation can be a "code once" and "deploy to a heterogeneous set of optimized native apps" many times experience...
Application Instrumentation: a cornerstone of application analytics
In addition to data analysis, Application Analytics solutions must provide specialized instrumentation and telemetry transmission functionality. General purpose analytics solutions are typically built to “Ingest everything” providing “adaptors” that translate external data sources into a proprietary analytics framework. While flexible, this approach is predicated on the assumption that a safe and reliable means to collect and transport raw data is available; with application analytics, this is rarely the case.
In addition to the functional requirements to capture the right kinds of runtime telemetry, an application instrumentation solution must meet a host of performance, privacy, quality, and security requirements as well – requirements that vary wildly by industry, use case, and target audience.
Incomplete instrumentation solutions force development to instrument a single app multiple times or omit valuable telemetry from their analytics solution.
PreEmptive Analytics instrumentation is optimized to efficiently, securely, and reliably capture application telemetry without compromising user experience, privacy or compliance obligations.
PreEmptive Analytics Instrumentation for Xamarin
Is there a catch? Not really - but if you really want to avoid licensing fees entirely, you will want to install the Community Edition of PreEmptive Analytics for TFS (included with all SKUs of Visual Studio & TFS other than Express). You will need this to serve as the endpoint that receives your application telemetry. For a general overview of this SKU and Application Analytics in general, check out my article inside MSDN's Visual Studio 2013 ALM site: Application Analytics: What Every Developer Should Know.
If you're interested in scaled up capabilities, you may want to consider PreEmptive's commercial offerings:
- PreEmptive Analytics Workbench offering real-time, role-based insights into application adoption, usage, performance and impact, or
- PreEmptive Analytics for Team Foundation Server (Professional) that monitors production incidents in near real-time and automatically creates TFS work items based upon user-defined patterns and thresholds.
In EVERY case - these endpoints can be installed on-premises and are always development managed (PreEmptive can't touch your data).
Here are a few more technical details around the new API;
REMEMBER – code once in C# and have all of this functionality manifest inside your native iOS and Android apps!
Tracking Feature Use
The most common usage of analytics is to track which features are popular among users and how they interact with them. You can indicate that a feature was used by using the FeatureTick method. You can track the duration of a feature's use by using FeatureStart and FeatureStop.
Sending Custom Data
You can send custom data to the configured endpoint with any type of message. To send over the data you construct an object to hold key-value pairs. One common use case is to report the arguments a method was called with and what the method will return.
The API provides a simple way to report exceptional conditions in your application. The exception reports can be used to track exceptions reported by your application or from third party software. The report can also have user added information added to it to aid support staff. And of course you can always add Extended Key information to track application state.
Your application is not required to always have network connectivity. By default, the API will store messages locally when the configured endpoint cannot be reached. The messages will automatically be sent and removed from offline storage once the endpoint can be reached.
Message Queuing and Transmission
Messages are not immediately sent to the configured endpoint. The API queues messages and sends them either when a certain amount of time has elapsed, or when a number of messages have accumulated. On platforms where transmission may have a performance impact, such as on mobile devices, the transmission of messages can be directly controlled by your program.