Développement iPhone - Mon application se bloque lorsque je change d'orientation

Question

Je me heurte à ce problème, où mon application reçoit l'erreur EXC_BAD_ACCESS et stucks / stops. J'utilise " Rotation à gauche " & amp; "Rotation à droite" options de simulateur pour simuler le comportement de changement d'orientation. Quelles peuvent être les raisons possibles de cette erreur? Puisque je ne reçois pas de détails sur l'erreur, je ne peux pas la localiser.

Toutes mes classes de contrôleurs ont:

- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation {
    return (interfaceOrientation == UIInterfaceOrientationPortrait);    // Return YES for supported orientations
}

Des idées, des indicateurs? Merci.

Mais mon code n'a pas d'appel à la méthode [UIDevice setOrientation:].

C’est la trace que j’obtiens dans la fenêtre de débogage:

objc_msgSend
-[UIWindow _handleDeviceOrientationChange:]
_nsnote_callback
__CFXNotificationPost
_CFXNotificationPostNotification
-[NSNotificationCenter postNotificationName:object:userInfo:]
-[UIDevice setOrientation:]
-[UIApplication handleEvent:withNewEvent:]
_[UIApplication sendEvent:]
_UIApplicationHandleEvent 
SendEvent
PurpleEventTimerCallBack
CFRunLoopRunSpecific
CFRunLookRunInMode
GSEventRunModel
GSEventRun
-[UIApplication _run]
UIApplicationMain
main

Notez que l'erreur apparaît lorsque ma vue contient une barre d'onglets. Comme personne ne répond, j’imagine que ce n’est pas un problème courant et que je ne trouve aucune ressource permettant de résoudre ce problème.

  

Puis-je dire en quelque sorte à mon application de s'exécuter dans une orientation unique (portrait) et de ne pas envoyer d'événements pour le changement d'orientation? Cela pourrait résoudre mon problème, mais c’est l’alternative que je recherche.

Merci Paul, votre commentaire a été utile et j'ai pu résoudre le problème, mais avec le coût de conservation de la mémoire pour la vue dont je n'ai pas besoin. Voici ce qui se passe:

J'ai une vue (vue A) qui ouvre une autre vue (vue B). La méthode App Delegate est responsable de l'ouverture de View A et de View B. L'application ne plante pas sur View A. Je supprime View A de la fenêtre, libère son objet contrôleur et ajoute View B à la fenêtre. Je crois que c'est là que je fais quelque chose de mal. Pouvez-vous m'aider avec le code?

Voici le code permettant de libérer la vue A et d'ouvrir la vue B:

- (void)openViewB {
    [UIView beginAnimations:nil context:NULL];
    [UIView setAnimationDuration:1.0];
    [UIView setAnimationTransition:UIViewAnimationTransitionFlipFromLeft forView:window cache:YES];

    // Remove viewControllerA from the window's view
    [window removeFromSuperview];

    // !-- Commenting out this block fixes the issue --!
    // Release memory wired for viewControllerA view
    if(viewControllerA) {
        [viewControllerA release];
        viewControllerA = nil;
    }       

    // We call window:addSubView to add the viewB to the main window. 
    // You can use this call to add other views as child views not only to windows
    // but to other views as well. (UIWindow is a subclass of UIView).
    [window addSubview:viewControllerB.view];
    [UIView commitAnimations];

    // Override point for customization after application launch
    [window makeKeyAndVisible];
}

J'ai lancé l'application avec le modèle d'application de barre d'onglets et viewControllerB est du type UITabBarController . Je fais vraiment quelque chose de mal ici. Des pointeurs?

Answer 1

Il n'est pas rare que le code de la bibliothèque système se bloque en raison de quelque chose que vous n'avez pas configuré correctement. Il se peut que votre UIWindow ou sa vue de contenu ou votre instance de contrôleur de vue n’aient pas été conservés ou aient été libérés d’une manière ou d’une autre.

Cette méthode shouldrotate ne vous aidera pas si votre contrôleur n'est pas toujours là.

Les suggestions de

rpetrich peuvent toujours être utiles pour identifier quel objet a été libéré. ??

Pour les problèmes particulièrement épineux, vous pouvez ajouter des méthodes release, rétention et dealloc (qui enregistrent et appellent super) à une de vos classes suspectes et voir ce qui le libère. Enregistrez le -retaincount pour garder une trace (je l’utilise uniquement à des fins de diagnostic et non pour gérer la mémoire dans une application d’expédition).

Answer 2

Définissez un point d'arrêt sur - [UIDevice setOrientation:] et parcourez votre code dans le débogueur.

Pour faciliter le débogage, vous pouvez taper call (void) instrumentObjcMessageSends (YES) dans la console du débogueur pour commencer la journalisation objc_msgSend s dans / tmp /, puis < code> continue et le suivi de tous les messages envoyés jusqu’au crash.

Answer 3

Moi aussi, je suis confronté au même problème. Je pense que si le contrôleur de vue est publié à l'aide de [Version de ViewController], mais qu'il utilise toujours l'affichage et à ce moment-là, si vous modifiez l'orientation, l'application se bloque.

Vous devez savoir exactement quand vous devez relâcher le contrôleur de vue [à la sortie, probablement].