I use Flurry 5.4.0 for iOS at the moment and I have a concern about being able to log more information than only an error ID when it comes to the method:
+ (void)logError:(NSString *)errorID message:(NSString *)message error:(NSError *)error;
You might wonder if I'm a bit slow, since there obviously exists a perfect parameter for just that, message:(NSString *)message. Well, unfortunately that message doesn't show up anywhere in the Flurry dashboard, which the Flurry Support Team confirmed in the answer that I got back (2014-08-30):
For error reporting, although you can pass the message in the logError function call - at the moment the dashboard doesn't have the provision to display the error message. This is something that is being considered in the long term feature road-map. Our product team is aware of this, and they would work on it, as a feature request. But, at the moment I do not have a time-line on if/when this would get implemented.
So, I don't really know how to proceed to add more important information "to" my errors. A first unsmart idea was to concatenate the information and send this in the first parameter:
errorID = errorID + errorMessage;
This to at least get the information to Flurry, but that would more or less always create unique error IDs and we would miss the great benefit of separating the errors into different kinds or errors. A really bad idea.
Apart from changing analytics provider I can't figure out a smart way to get hold of the own-created error information. Maybe I should just do that, or how do you add more useful error info to inspect at the Flurry dashboard?
Please feel free to speculate.
I asked the Flurry Team if I could get the message info from any of their ("requestable") open APIs instead and got this reply:
When checking out the recommended section I found what I have been looking for. The message is located under the sub section called 'Exception Log'. I'd say that it's a bad placement, since it's more obvious to go look for logged errors under a section called 'Errors' than under 'Technical'. Right(?)
Flurry is a nice way to go so I would re frame what you define as an error and evaluate what is more important - getting the information back or getting it back as an error.
Option 1 I would log the events as some sort of sudo error (aka - "A bad thing happened" :) and use the parameters to bring back the additional details you are wanting.
Option 2 It was unclear in your response from the Flurry team if the information is completely unavailable or just not available within their portal/dashboard.
If you download the raw data from Flurry can you see the information you wanted and create your own dashboard as appropriate from that?
Hopefully this is enough speculation to get things flowing for you.