Is there any alternatives to Apple's crash reporter ?
25/03/07 21:24
Not being able to send the crash report directlty to the developer, no way to add specific information…
they are a number of limitation with Apple's solution…
Any other solutions ?
they are a number of limitation with Apple's solution…
Any other solutions ?
Sure:
Smart crash report (see presentation)
Uli M. Klusterer's solution (see here)
Claus Broch's one ILCrashReporter
Martin Redigton one's (see here)
The Open Source project Adium has also its own technology (see Adium project's home page)
And of course, we can't resist, ours is here...
Smart crash reports requires free registration to get the crash report to be sent to you...
Uli's one sends the crash report on "next launch"… (may be never of course…)
Martin Redigton's one has a lot of parameters to play with:
Ours is as powerfull as Martin Redigton's one, but requires a little bit more work from you: you have to (as an option) supply code inside your application to be debugged and a tool to add your own information and to do the actual reporting.
The counterpart of this small work (examples supplied) is of course a greater freedom regarding the content of the generated information and how and when to deliver it.
Two versions are supplied, one's installs as a daemon inside your application bundle and the other one is a static library to be linked into your application.
Interesting link regarding exception handlers: Mach Exception Handlers 101
Smart crash report (see presentation)
Uli M. Klusterer's solution (see here)
Claus Broch's one ILCrashReporter
Martin Redigton one's (see here)
The Open Source project Adium has also its own technology (see Adium project's home page)
And of course, we can't resist, ours is here...
Smart crash reports requires free registration to get the crash report to be sent to you...
Uli's one sends the crash report on "next launch"… (may be never of course…)
Martin Redigton's one has a lot of parameters to play with:
- More informative: the information that can be collected includes contact information, user problem description, crash logs, log files, preferences, and the output of arbitrary commands
- Highly configurable: the user interface and information to be collected can be configured via an xml configuration file.
- XML property list default output to allow easy automatic processing of incoming crash reports
- Extensible data collection architecture, so that you write plugins to collect specific diagnostics for your target application, if the existing types are not sufficient.
- Extensible delivery mechanism, to allow you to tune delivery to your requirements.
- "BugReporter" mode, that can be used to collect information for non-crashing bug reports in a standardised format.
- Can handle multiple bug/crash reports at a time.
- Reports can be saved for later delivery.
- Fully localizable, to allow users to be asked for bug reports in their native language.
Ours is as powerfull as Martin Redigton's one, but requires a little bit more work from you: you have to (as an option) supply code inside your application to be debugged and a tool to add your own information and to do the actual reporting.
The counterpart of this small work (examples supplied) is of course a greater freedom regarding the content of the generated information and how and when to deliver it.
Two versions are supplied, one's installs as a daemon inside your application bundle and the other one is a static library to be linked into your application.
Interesting link regarding exception handlers: Mach Exception Handlers 101