Développement iOS
  1. Développement iOS
  3. Que faire attention lors de la transition vers iOS 5
Intereting Posts
Dissortingbution ad hoc dans XCode 4 Crash sur la migration des données de base Problèmes de connection lors de l'utilisation de l'iPhone comme périphérique RestKit complexe et simple JSON RKObjectMapping fonctionne presque, mais Comment convertir JSON en object Comportement bizarre avec UISegmentedControl et UIAppearance Limites UIScreen et applicationFrame Comment identifier EKEvent de manière unique avec Sync sur les appareils Comment mettre à jour une label d'interface user à partir d'un thread non UI dans iOS AFNetworking 2.0 download plusieurs images avec l'achèvement code d'assemblage iOS Xcode 8: les types de fonctions ne peuvent pas avoir d'label d'argument brisant ma construction iOS démarre le fil d'arrière-plan Xcode 4: Mes projets iPhone sont devenus des projets Mac OS .. et je ne peux pas changer ça FB login à l'aide de Swift 3 ne renvoyant aucune valeur et ne pas récupérer l'user à l'application après la connection réussie

Que faire attention lors de la transition vers iOS 5

Résumé: Pouvez-vous append à ma list de contrôle des choses à surveiller lors de la migration vers iOS 5? StackOverflow a été d'une valeur inestimable car j'ai travaillé sur la mise à niveau vers iOS 5. J'ai découvert des choses assez basiques que j'avais manqué avant Xcode 4.2, et je me request ce que d'autres "pièges" pourraient cacher.

Détail: Avec iOS 5 expédition cette semaine, j'ai dû apporter quelques modifications à quelques unes de mes applications. Xcode 4.2 fait un travail bien meilleur en analysant le code de memory management à cause de la nouvelle fonctionnalité ARC. La mise à jour d'iOS 5 est un excellent point pour passer en revue tout votre code de memory management. Le nouveau compilateur trouve également un certain nombre d'autres problèmes que les compilateurs précédents ont manqués. Bravo aux ingénieurs compilateurs Apple. Voici les principales choses qui ont aidé (et beaucoup d'entre eux s'appliqueront également aux versions antérieures d'iOS).

  1. Assurez-vous d' appeler [super dealloc] à la fin de vos methods dealloc , pas le début.
  2. Dans viewDidUnload, certaines personnes ont signalé des bogues qui nécessitent que [super viewDidUnload] soit appelé à la fin et non au début de votre viewDidUnload.
  3. Comprenez les counts de retenue, les parameters synthétisés et quand appeler la libération ou autorelease. Le nouveau compilateur signalera plus de problèmes que les anciens compilateurs. (Je pensais que j'avais fait attention, mais apparemment je ne faisais pas assez attention.) Le guide de memory management d'Apple est nécessaire lecture – pas de raccourcis.
  4. C'est une bonne idée d' activer les zombies lors du debugging (dans Xcode, choisissez Product | Edit Scheme … et select le schéma Debug, dans l'onglet Diagnostics, cochez Enable Zombie Objects). Cela peut vous aider à find des tentatives d'utilisation de zombies (objects que vous ne devriez plus utiliser).
  5. L'instrument Leaks est également utile. Exécutez votre application en mode Profil et choisissez le model Fuites. Dans la window Instruments, select l'instrument Leaks et cochez la case «Gather Leaked Memory Contents» (Contenu de la memory perdue) et cela vous aidera à voir d'où provient la memory qui a fui dans votre code.

Il y a quelques petites choses que j'ai rencontrées:

  • Le model singleton d'Apple nécessite "oneway" ajouté à la déclaration de type de return: 
     - (un void vide) release {}
  • Vous devrez peut-être append manuellement "armv6" en tant que type d'architecture dans vos parameters de construction (et assurez-vous que Build Active Architecture Only est défini sur NO).

D'autres suggestions d'embûches potentielles que je devrais searchr? J'ai l'printing que mes applications sont plus stables maintenant, mais je me sentais très bien à leur sujet avant.

1 / Les controllers modaux se comportent différemment, si vous changez leur taille. Si vous avez besoin d'une boîte de dialog modale d'une taille différente, envisagez d'utiliser les controllers de vue enfant iOS 5.

2 / Pour une table, si vous returnniez un en-tête de section nul et une hauteur positive, dans iOS 4, l'en-tête était masqué. Dans iOS 5, vous devez returnner une hauteur nulle pour les en-têtes nuls.

3 / UDID est obsolète. Vous pouvez utiliser CFUUIDCreate pour créer un ID unique et l'save dans vos parameters, mais sachez que datatables d'un périphérique peuvent être sauvegardées puis restaurées sur un autre périphérique, vous laissant deux appareils avec le même ID. J'ai résolu la situation en enregistrant mon identifiant dans keychain avec l'atsortingbut kSecAttrAccessibleWhenUnlockedThisDeviceOnly.

A propos de votre list: [super viewDidUnload] doit toujours être appelé comme la dernière instruction de votre viewDidUnload. La logique est la même que dans [super dealloc]. Notez que vous devriez aussi appeler [self viewDidUnload] dans votre dealloc (si vous n'y libérez pas déjà votre memory) car il n'est pas appelé implicitement (bien que ce soit parfois le cas).

De mes expériences, la détection de fuite dans Instruments ne signale pas les fuites sur les propriétés qui sont synthétisées sans assigner un nom de propriété.