Xcode 4.0 : qu'en pensez-vous ?
muqaddar
Administrateur
Xcode 4.0 est désormais disponible en Golden Master depuis cette nuit, après une série d'activations/désactivations de cette version.
La grande nouveauté de cette version est qu'on peut désormais envoyer des applications sur l'iOS AppStore et le Mac App Store.
La grande nouveauté de cette version est qu'on peut désormais envoyer des applications sur l'iOS AppStore et le Mac App Store.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
(Sachant que ça va encore me mettre le souk dans mes tests unitaires ?)
EDIT: Déroutant aux premiers abord, mais le changement est bon. Adopté.
XCode4 est très différents des versions précédentes sur de nombreux points, et il va obligatoirement falloir un temps d'adaptation pendant lequel votre productivité va fondre...
Je l'ai testé 30 minutes la semaine dernière, et j'avoue avoir été dérouté. Cependant, l'interface est vraiment sympa, et je ne suis pas contre les fenêtres tout-en-un.
Non, en fait, c'est surtout clang qui est 30 à 40% plus rapide que GCC, ce qui, par conséquent, diminue fortement les temps de compilation. Par contre un gain de perfs de 40% sur l'exécution du code compilé par clang je n'y crois pas (même si il y a eu des démonstration allant dans ce sens à la dernière WWDC, mais, évidemment, sur des exemples de code bien choisis
C'est moi ou il n'a pas remplacé le dossier Xcode4 de la preview mais m'a remplacé Xcode 3.2 ?
Et oui, ne trouvant pas où personnaliser, je n'en étais pas sûr.
Bon, bein voilà qui va me faire l'adopter plus rapidement (ça va, j'ai pas d'urgence client en ce moment).
Par contre j'ai eu quelques plantages inexpliqués... mais bon
EDIT: Diantre... Des tonnes de bonnes choses !
Donc évitez de parler des nouvelles fonctions, parce que y'en a à la pelle... moi aussi il me tarde d'en parler !
Sinon, j'ai compilé 2 projets iOS sans soucis à part un linkage délicat avec CorePlot.
Je ne suis pas à l'aise avec la gestion des erreurs et warnings.
Vivement qu'on puisse en parler parce que y'a tant à dire !
Quel noob je suis... j'ai rectifié le tir !
En tant qu'utilisateur de mon application je peux t'assurer que, pour ce que j'en fais, j'ai noté un gain substantiel depuis que j'ai compilé avec LLVM. Je l'avais pris pour sa gestion du debugg et je ne savais pas que j'allais gagner en vitesse. C'est au chargement de mon appli, quand elle lit 600 fichiers générés par une autre appli pour créer les données que je me suis aperçu que le temps d'attente avait fondu. Une fois les données chargées on ne voit plus la différence parce que les traitements sont petits.
Donc, pour certains d'entre vous, utiliser clang devrait avoir un impact positif pour vos utilisateurs.. Il est loin le temps où les applis Mac se trainaient par rapport à leurs équivalents PC
Sûrement à la WWDC 2011...
Je bosse avec depuis 4 jours :
- Il crash pas mal mais on peut continuer à bosser souvent en cliquant sur "Continue"
- Plein de petites améliorations ajoutées ici ou là .
Du coup je ne suis plus très sûr de ça... Parce que la WWDC c'est dans 4 ou 5 mois, et qu'Apple à l'habitude de sortir des GM 2 à 3 semaines avant la version publique.
Donc sur le coup moi je dirai d'ici quelques semaines
Alors, ils ont intérêt à améliorer sacrément la stabilité et rapidement parce que c'est son plus gros défaut.
Pour eux, la stabilité n'est pas un problème du moment que c'est utilisable (donc si ça plante de temps en temps c'est pas grave...).
Par contre, je me permets un aparté sur un warning :
Quand on écrit ça :
Il nous met un warning et nous suggère un double égal si c'est une comparaison qu'on veut faire... Pourquoi pas.
Et si on veut taire le warning, on doit faire ça :
Bon, je trouve ça un peu moche...
ne provoque pas de warning...
PS: Avez vous tenté de supprimer une ligne inséré par Xcode où se trouvent encore des placeholder ? chez moi c'est plantage direct....
Dans la plupart des compilateurs c'est un warning par défaut, et en fait il est plutôt logique. Ca te force à coder proprement et t'évite de faire des erreurs involontaires.
Moi perso j'écris toujours Au moins c'est clair.
Après c'est qu'un warning, rien ne t'empêche de le désactiver dans les options de compilation.
Sinon, j'ai remarqué que j'ai parfois des erreurs et des warnings qui apparaissent dans le panneau de gauche, mais quand je clique dessus, il est incapable de les situer dans la page de code, hors ce ne sont pas des erreurs "générales" (type fichier qui manque ou autre) mais bien des erreurs de code pur et dur.
C'est très gênant.
- Toujours avoir la possibilité d'affecter des actions à mes breakpoints, car j'ai cru lire à une époque que dans Xcode4 c'était plus possible, or moi j'utilise assez souvent l'action "jouer un son" sur certains de mes breakpoints. C'est à dire qu'au lieu qu'un breakpoint donné que je place dans mon code fasse s'arrêter le débogueur, je demande pour ce breakpoint de jouer un son et de ne pas s'arrêter. C'est pratique pour tester des cas genre juste savoir si tu passes bien dans telle méthode de ton code, sans pour autant que ça interrompe ton code et donc ton test, surtout si tu testes des trucs où il faut enchaà®ner les clics et pas être interrompu tous les 4 matins. Donc si cette fonction là a disparu je serais déçu
- Avoir la possibilité de créer des "IBOutlet" (ou des IBProperty ou ils les appellent comme ils veulent, c'est vrai IBProperty c'est mieux) sur des variables ou propriétées de mon code autre que des objets du UIKit, et pouvoir ainsi exposer par exemple des NSString de mes objets dans IB pour les configurer directement de là .
Ce qui permettrait d'éviter d'avoir à rajouter plein de lignes de code dans viewDidLoad ou awakeFromNib juste pour configurer/personnaliser des cas.
Ca serait en particulier très pratique pour des classes customisées qu'on peut créer et qu'on veut réutiliser dans divers projets. Imaginez par exemple ma classe OHGridView (cf mon GitHub) qui affiche des éléments sous forme de grille, ça pourrait être sympa de pouvoir configurer directement dans la palette de propriétés de IB le nombre de colonnes et de lignes.
D'ailleurs c'est une fonction qui existe un peu dans le SDK MacOSX où l'on peut (pouvait ?) spécifier des valeurs pour des clés arbitraires (qui seront affectés au runtime par un "setValue:forKey:"), dans un des derniers onglets de la palette de propriétés de IB... Mais on n'a pas ça sous iPhone et je me demande même si ça a pas disparu depuis la dernière fois que j'ai fait du MacOSX SDK...
Du coup dans le .h en plus des IBOutlet & co (et des IBOutletCollection, qui sont nouveaux et assez méconnus donc peu utilisés) on pourrait déclarer disons [tt]IBProperty NSInteger columnCount[/tt] et [tt]IBProperty BOOL alternateRowsColor[/tt] et hop IB afficherait alors dans sa palette dans une section dédiée une entrée "columnCount" avec un champ de saisie d'une valeur entière en face, et une entrée "alternateRowsColor" avec une case à cocher en face.
Bon, je rêve sans doute, pourtant ça serait tellement utile pour toutes les classes perso qu'on développe, et puis ça contournerait le souci des palettes IB (qui ont l'air un peu abandonnées et sont assez ch**ntes à faire (on va pas en faire une à chaque fois qu'on crée une classe réutilisable qd mm !), et je pense que je suis pas le seul à qui ce genre d'ajout serait utile !
Et bé, je vais rester avec la version 3 pour un bon moment
Moi j'ai lu que l'on ne pourrait plus compiler pour Mac OS X.5... Donc X.6 OK. Ce qui est bien différent...