Implementación de TestFlight.com y Flurry.com Manejo de excepciones

Question

Estamos utilizando tanto TestFlight.com SDK como SDK de Flurry.com para rastrear excepciones no controladas. El problema es que Flurry no recoge excepciones después de agregar el SDK de TestFlight.com.

El método activado cuando se produce una excepción no controlada se ve así:

void uncaughtExceptionHandler(NSException *exception) 
{
    [FlurryAnalytics logError:@"ERROR_NAME" message:@"ERROR_MESSAGE" exception:exception];
}

- (BOOL) application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions 
{    
    #if !TARGET_IPHONE_SIMULATOR
    NSSetUncaughtExceptionHandler(&uncaughtExceptionHandler);

    struct sigaction newSignalAction;
    memset(&newSignalAction, 0, sizeof(newSignalAction));
    newSignalAction.sa_handler = &signalHandler;
    sigaction(SIGABRT, &newSignalAction, NULL);
    sigaction(SIGILL, &newSignalAction, NULL);
    sigaction(SIGBUS, &newSignalAction, NULL);

    [FlurryAnalytics startSession:kFlurryKey];
    [TestFlight takeOff:kTestflightKey];    

    [[UIApplication sharedApplication]
     registerForRemoteNotificationTypes:(UIRemoteNotificationTypeBadge |
                                     UIRemoteNotificationTypeSound |
                                     UIRemoteNotificationTypeAlert)];    
    [UIApplication sharedApplication].applicationIconBadgeNumber = 0;    
    #endif
    .
    .
    .

No estoy seguro de cómo lo hace TestFlight.com, pero parece que interceptan la excepción y registran los datos por sí mismos sin dejar que se ejecute el método registrado.

¿Hay alguna forma de que ambos coexistan?

Answer 1

Recibí la confirmación del equipo TestFlightApp.com de que este es un problema conocido. Esperan arreglar en la próxima versión que dijeron.

Answer 2

No puedo probar esto directamente, pero el Documentación de TestFlight parece decir esto:

Si utiliza los manejadores de excepción o señal no capturados, instale sus manejadores antes de llamar al despegue. Nuestro SDK llamará a su manejador mientras el nuestro se está ejecutando.

Incluso dan algunos código de ejemplo Lo que podría ayudarlo a que esto funcione.

Answer 3

He encontrado una solución en un blog, no estoy seguro de si también funciona para Flurry, lo que dice es llamar al método UninstallCrashHandlers (declarado en TestFlight.h) dos veces después de [TestFlight Takeff:@"Key"] y luego registrarse Otro servicio para el que desea usar para informes de bloqueo. Ver código de ejemplo para TestFlight vs Crashlytics

Deshabilitar los informes de bloqueo de TestFlight es bastante simple. Agregue el siguiente código que incluye en AppDelegate.m:

...
#import TestFlight.h

// Function prototype for UninstallCrashHandler
extern void UninstallCrashHandlers(BOOL restore);

En didfinishlaunchingwithOitions llame primero este método con no y luego con sí, como:

- (BOOL)application:(UIApplication *)application
        didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
  [TestFlight takeOff:@"<TestFlightKey>"];

  UninstallCrashHandlers(NO);
  UninstallCrashHandlers(YES);

  [Crashlytics startWithAPIKey:@"<CrashlyticsKey>"];

  return YES;
}

árbitro: http://www.grahamdennis.me/blog/2012/10/21/how-to-disable-testflights-crash-handlers/