Runtime Intelligence is a powerful tool that is able to illustrate in great depth how your applications are actually being used. But of course, with great power comes great responsibility. While individual developers are free to collect analytics data in any way and in accordance with any privacy policy they wish, allowing your users to opt-in to collecting usage information is not only standard in the industry, it’s also the right thing to do for your users. With Runtime Intelligence, we’ve make this important functionality easy to implement via the OptInSource properties of the SetupAttribute. Simply specify the name and owner of the property, method, field, or method argument that will contain the user’s opt-in setting at runtime, and the instrumented Runtime Intelligence code will retrieve the opt-in setting before any attempt to send analytics data.

If the user has opted-out, no data will be collected or sent in nearly all cases. The exception to this rule is that if you have chosen to use Tamper Detection and Notification, and you have configured it to send Runtime Intelligence messages when tampering is detected, these messages will always be sent regardless of the user’s opt-in choice. Additionally, the Exception Reporting feature contains a mechanism that allows the user to specify an explicit opt-in for an individual exception report, which will override the Runtime Intelligence opt-in setting for that message only. The default exception reporting dialog that Dotfuscator can inject makes use of this mechanism, and the specifics of how to provide this explicit opt-in are detailed in the manual so that developers rolling their own solution using Exception Reporting can do the same.

As a quick example, let’s say I wanted to persist the user’s opt-in setting using Isolated Storage. For simplicity’s sake, I am using the IsolatedStorageSettings class available in Silverlight and Windows Phone 7, but applications that target other frameworks can perform the same operations in a slightly more verbose way. Your business requirements would of course drive the value of RIOPTIN_DEFAULT; for this example I have chosen to opt-in the user by default.

public static class UserPrefs {
    public static bool RIOPTIN_DEFAULT = true;

    public static bool RIOptIn {
        get {
            bool optIn;
            if (IsolatedStorageSettings.ApplicationSettings.TryGetValue("rioptin", out optIn)) {
                return optIn;
            } 

            return RIOPTIN_DEFAULT;
        }
        set {
            IsolatedStorageSettings.ApplicationSettings["rioptin"] = value;
            IsolatedStorageSettings.ApplicationSettings.Save();
        }
    }
}

Now all I need to do is set the following properties on my SetupAttribute (either in code, or via Dotfuscator’s Instrumentation tab), and my users will be able to rest easy, knowing that they have control over whether and how their activity data is shared.

[Setup(
    ...,
    OptInSourceElement = SourceElements.Property,
    OptInSourceName = "RIOptIn",
    OptInSourceOwner = "UserPrefs",
    ...
    )]

You can see a complete example by checking out the awesome open-source OneBusAway app at http://onebusawaywp7.codeplex.com. The Runtime Intelligence opt-in preference is wired up via data binding to a toggle in the app’s settings scene, and is persisted in the same way as my sample above (property backed by isolated storage). They’ve included their Dotfuscator config file in source control, so you can take a look at a real-world example if need be. The OneBusAway project is also a great example of our exciting partnership with CodePlex that provides free, integrated Runtime Intelligence analytics to all the projects they host, so definitely check it out!