Nib2objc: Ou comment convertir un nib en code Objectif-C

L’utilisation d’Interface Builder s’avère très pratique pour les développeurs Cocoa Touch. C’est vrais que c’est génial de pouvoir créer ses interfaces en mode WYSIWYG. Oui mais voilà, cela peut poser quelques problèmes. Outre les cas où l’utilisation du code est nécessaire (pour atteindre la granularité voulue), on peut vouloir renoncer à l’utilisation des nibs pour des raisons de performance.

En effet, dans certains cas l’utilisation des nibs pose de sérieux problèmes de performance. On se retrouve ainsi avec un dur choix: soit on choisit la simplicité (et on utilise Interface Builder), soit on écrit ses interfaces directement dans le code et on gagne en performance. Dans certains cas, l’impact de l’utilisation des nibs sur la performance est quasi nul. La question ne se pose donc pas. Mais parfois, ce n’est pas le cas.
La suite du billet, c’est par là »

Astuces développement iPhone 8: Modifier le __MyCompanyName__

Je vois assez souvent, dans les fichiers de code qui passent entre mes mains, des en-têtes comme ceci:

//  Created by Julien on 17/01/09.
//  Copyright 2009 __MyCompanyName__. All rights reserved.

Le problème porte sur __MyCompanyName__. Il serait bien plus propre de le remplacer par une valeur personnalisée (et automatique de préférence). Pour ceci, Apple a tout prévu …
La suite du billet, c’est par là »

Astuces développement iPhone 6: Récupérer l’UDID

L’UDID (Universal Device Identifier) d’un iPhone est, comme son nom l’indique, un identifiant unique pour chaque iPhone / iPod. Si vous avez déjà eu à générer des fichiers de provisioning, vous connaissez bien cet identifiant. En effet, c’est ce dernier que l’on doit transmettre à Apple quand on veut rajouter un iPhone / iPod dans la liste des appareils autorisés pour un développement ou une distribution.

Il peut être utile, dans une application, de connaître ce fameux UDID de façon logicielle. Ainsi, on identifie de façon unique et certaine l’équipement sur lequel notre application s’exécute. Pour récupérer l’UDID, rien de plus simple:

NSString *udid = [[UIDevice currentDevice] uniqueIdentifier];

Astuces développement iPhone 5: whatis et ptype

Dans la même veine que le Print Object en console, voici une nouvelle astuce en console de debug. L’idée n’est plus de récupérer la description d’un objet, mais son type. Ainsi, il y a deux commandes: whatis et ptype. La première permets d’avoir simplement le type d’un objet. Ainsi, si on a un objet monDico de type NSMutableDictionary, voilà ce que l’on obtient avec whatis:

(gdb) whatis monDico
type = NSMutableDictionary *

ptype, quant à lui est beaucoup plus complet. Si on reprends le même exemple, voilà ce que l’on obtient:

(gdb) ptype monDico
type = class NSMutableDictionary : public NSDictionary {
} *

Là où ptype prends tout son intérêt, c’est sur les types personnalisés. Voici deux exemple concret avec des objet perso:

(gdb) ptype currentRdv
type = class MiniRdv : public NSObject {
  protected:
    NSString *startDateFormated;
    NSString *startTimeFormated;
    NSString *title;
    NSString *personName;
    NSString *personFirstName;
    NSString *personPhoneBookId;
    NSInteger dbId;
} *
(gdb) ptype cell
type = class RdvTableCell : public UITableViewCell {
  protected:
    MiniRdv *miniRdvObject;
    UILabel *topLeftLabel;
    UILabel *bottomLeftLabel;
    UILabel *bottomRightLabel;
    UILabel *topRightLabel;
    UIImageView *avatar;
} *

Bref, ptype est un outil indispensable au debug d’applications !

Astuces développement iPhone 4: Récupérer le nom de l’iPhone

Il peut être très utile de récupérer le nom de l’iPhone sur lequel notre application s’exécute (comme iPhone-de-julien). C’est le cas notamment dans des applications où on appaire deux iPhone au travers d’un réseau WiFi (par exemple). L’idée est très simple: on récupère les informations de l’hôte courant, puis on prend le premier de ses noms. Ce qui donne au final:

NSString *deviceName = [[[NSHost currentHost] names] objectAtIndex:0];

Astuces développement iPhone 3: Executer un code seulement sur le simulateur

Il peut être utile parfois de n’exécuter certains codes que dans le simulateur (ou à l’inverse: seulement sur un véritable iPhone). Concrètement, c’est le cas quand on utilise des fonctionnalités non présentes sur le simulateur (accéléromètre par exemple). Pour ce faire, il suffit d’inclure le code a exécuter sur simulateur entre des directives de compilateur:

#if TARGET_IPHONE_SIMULATOR
  NSLog(@"Bonjour, je suis sir le simulateur");
#else
  NSLog(@"Bonjour, je suis sur un véritable iPhone !");
#endif