Archive for 'Programming'

So if you’re looking for some commercial solution to stick some analytics in your app, you’ve probably heard of PinchMedia, Medialets, and AdMob, which all make money via ad insertion; and far as we can tell, nobody’s making huge sums of money off those, so we haven’t looked into those further. But here’s one you might not have heard of: Flurry, which provides nice-looking analytics for FREE! — always a good price — and does it over all major mobile platforms, no less.

The problem facing many mobile application developers is that they don’t get the best analytics information on the cross-platform software they create.

That’s why San Francisco-based Flurry has launched a new mobile application analytics tool that works across a variety of mobile platforms, including the iPhone and Google’s Android. Today, the company is announcing that more than 300 developers have used its free service since the beta launched in October.

The program also works with BlackBerry and Java ME platforms (though not Palm). Flurry lets developers see exactly how consumers use their applications, and provides information on which features of the application are used and for how long.

The software is meant to give developers a tool for monitoring application usage in real time. That way, they can fine-tune the application on the fly, said Peter Farago, vice president of marketing at Flurry…

Well, that all sounds quite interesting, so we signed up for a free account. The website appears nicely laid out, and since we didn’t notice any NDA, we’ll share the API with you here:

@interface FlurryAPI : NSObject
{
}

// Call startSession with your project apiKey in applicationDidFinishLaunching
// + This call will initiate tracking of the current user session and send any previously saved
// sessions to the Flurry analytics servers.
+ (void)startSession:(NSString *)apiKey;

// Use this instead of startSession if you want detailed location information in your analytics.
+ (void)startSessionWithLocationServices:(NSString *)apiKey;

// Call logError to track any errors in your application that you would like to view in your analytics.
// + Errors are uniquely identified and correlated by errorID so two different calls using the same
// errorID will be considered the same error type.
+ (void)logError:(NSString *)errorID message:(NSString *)message exception:(NSException *)exception;

// Call logEvent to track any custom events in your application, such as user behaviors or application
// execution points. The eventName is considered unique so two different calls using the same
// eventName will be considered the same event type.
+ (void)logEvent:(NSString *)eventName;

// You should not need this function.
+ (void)setServerURL:(NSString *)url;

@end

Well, that’s short and sweet; and they provide instructions for putting logError in your uncaught exception handler for a simple crash reporter, although we still really like the looks of the previously mentioned PLCrashReporter for that. But maybe they can coexist nicely. In any case, if you are interested mainly in usage data, we don’t see any downside to jumping on board with Flurry!

h/t: VentureBeat!