SDK 3.0 : Compatibilité et problèmes ?
AliGator
Membre, Modérateur
-
Bonjour à tous,Ayant adhéré au programme à $99 et ayant donc accès au SDK 3.0, je n'ai encore fait que parcourir la doc, mais je compte installer le SDK 3 sous peu sur mon mac de dev.Cependant j'ai lu/entendu à gauche à droite sur le web et ailleurs quelques petites choses qui me freinent :
- Il semble que lorsqu'on installe le SDK 3.0, on ne peut plus compiler pour le SDK 2.2.1, en fait ça fait foirer la compilation avec les autres SDKs ? C'est toujours d'actualité ça ? (pb dans les fichiers de conf installés par le SDK 3 ou je sais plus trop ce que j'avais lu) ?
- Si je compile du coup mon appli pour SDK 3.0, pour la tester sur device je vais devoir passer ledit device en OS 3.0, on est bien d'accord ? Je veux dire on ne peut pas développer une appli avec le SDK 3.0 en gardant une compatibilité 2.2.1, genre avec des if pour tester si telle fonctionnalité est dispo car l'utilisateur a l'OS 3, mais si c'est pas le cas et qu'il est encore en 2.2.1, faire autre chose ou juste afficher une alerte...?
(Parce que vu que si on passe un device en OS 3.0 on ne peut pas revenir en arrière en version 2.2.1 ensuite... et comme en plus il parait que l'OS 3.0 beta est encore pas mal plantogène...)
Comme je vais avoir à faire des devs sous OS 2.2.1 et OS 3, on aura un device, de chaque, mais pour ce qui est du SDK, si l'installation du SDK 3.0 pourrit l'install du 2.2.1 et qu'il est impossible de compiler après pour ce SDK 2.2.1, ça m'emm...bête pas mal quand même.... qqun peut confirmer ou infirmer ce souci ? Ou me dire s'il a été résolu depuis ?
Merci !
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Foirer non . J'ai le SDK 3.0 depuis déjà longtemps. Le seul inconvénient notable que j'ai eu c'est que les Templates des applis viennent en 3.0, et qu'il faut faire attention avec les réglages (Instruments, doc, ...).
Mon device est en 2.2.1
On note des différences conceptuelles également. par exemple la méthode
- (void)presentModalViewController:(UIViewController *)modalViewController animated:(BOOL)animated
dépendra de la property UIModalTransitionStyle(cover,flip,dissolve)
Je l'ai lu comme cela aussi et c'est pour ça que je suis resté en 2.2.1
Et quand tu fais des essais de dev en 3.0 tu les fais sur le simulateur, quoi. Mais ça t'empêche pas de développer avec les deux ?
Donc le pb dont j'avais entendu parler comme quoi l'install du 3.0 faisait buguer la compilation en 2.2.1 a dû être résolu depuis...
Je n'ai pas encore essayé d'utiliser 3.0 (comme toi j'étais curieux de la doc), mais effectivement il ne me resterait que le simulateur.
Je fais un petit essai pour voir ..
Je fais une Utility Application sous 3.0 (le template seulement, mais avec le truc de la nouvelle property UIModalTransitionStyle) avec le simulateur 3.0. Je lance ==> Ok
Je lance mon projet actuel (assez conséquent) sous 2.2.1 . Le simulateur semble un peu mouliner, mais ça passe.
Tout marche sans problème.
Je ne sais plus d'où me vient cette info comme quoi l'install du SDK 3.0 pourrissait la 2.2.1 (empêchait la compilation avec le SDK 2.2.1), mais si c'était d'actualité à une époque, ça a l'air d'avoir été résolu donc... très bonne nouvelle
Merci pour ces retours d'expérience rassurants
Je remonte ce sujet car j'ai un souci : sur un nouveau MacMini (Intel Core2Duo 2GHz) tout frais sorti de son emballage ce matin (je sais pas si l'installation "fraà®che" joue mais bon), j'ai installé le iPhone SDK 2.2.1, puis ai compilé pour tester un projet que j'avais fait pour la 2.2.1, qui s'est installé sur le device (iPhone) sans problème (après avoir installé le certificat et sa clé privée et le provisionning profile).
Puis j'ai à la suite installé le iPhone SDK 3.0àŸ5 (et ai fait passer le même iPhone en OS 3.0àŸ5 aussi), et là , autant je peux compiler pour le simulateur, autant :
- Dès que je choisis "Device", il n'arrive à rien compiler car il essaye d'inclure des fichiers système inexistants... en regardant un peu en fait ce sont des fichiers qu'il essaye d'inclure se croyant sur i386 (d'après les #ifdef...) et non sur processeur armv6 de l'iPhone
- Dans les menus "active architecture" & co, je n'ai en effet que "i386" et "ppc"... même si je choisis la compilation pour le Device !
- Impossible de trouver nulle part l'architecture "armv6" dans les menus
- En plus une fois que j'ai sélectionné "iPhone Device 3.0" à la place de "iPhone Simulator 3.0" dans le menu... bah "iPhone Simulator 3.0" disparait, ne me laissant que "iPhone Device".... et "Mac OS X" ??? (alors que sur mon mac perso, pour les projets iPhone j'ai que des SDK iPhones dans le menu, et bien un par version du SDK installé)
Donc je capte pas ce qu'il me fait comme délire, que je puisse pas choisir autant de SDKs que ce à quoi j'ai l'habitude, et surtout qu'il se croit sur i386 mm pour le device et du coup foire la compilation sur device >:( Surtout avec la première installation en 2.2.1 ça a marché...
Bien évidemment j'ai lancé le script de désinstallation (en ligne de commande) des DevTools puis essayé de réinstaller le SDK 3.0... même problème.
Ce soir j'ai re-désinstallé les DevTools, mis le dossier Developer à la poubelle... et je verrai demain, mais si vous avez des pistes, je suis super preneur parce que là ça m'inquiète...
- Alors qu'hier soir j'avais désinstallé tous les DevTools et jarté le dossier /Developer
- Ce matin installation du SDK 2.2.1 dans /Developer puis redémarrage (pour être sûr)
- Puis installation du SDK 3.0àŸ5 dans /Developer3 puis redémarrage
Résultat, tout est OK :
- le Xcode dans /Developer fonctionne et n'a bien que les SDK 2.2.1 et précédents (2.0, 2.1, 2.2) mais pas le SDK 3.0, avec les configurations "simulator" (->i386) comme "device" (->armv6)
- le Xcode dans /Developer3 fonctionne et a bien le SDK 3.0, et me propose bien les configurations "simulator" (->i386) et "device" (->armv6), et j'ai enfin pu compiler une appli SDK 3.0 et surtout la mettre sur mon device maintenant que les configs (archi arm) sont ok
- Et tjs dans ce Xcode de /Developer3, si j'appuie sur la touche option en cliquant dans le menu Overview pour choisir le target/platform/sdk/archi, j'ai bien toutes les possibilités (et pas que les choix SDK 3.0)
Par contre j'ai renommé du coup mes dossiers pour voir : j'ai renommé /Developer en /Developer221 et laissé /Developer3 tel quel (donc je n'ai plus de dossier nommé "/Developer" tout court) et... ça continue apparemment de fonctionner (alors que je croyais que même si on pouvait choisir un emplacement lors de l'install, certains trucs étaient obligatoirement installés dans /Developer quand même ?)
Est-ce gênant du coup de ne plus avoir de dossier nommé "/Developer" ? Dans le PDF ReadMe fournis sur l'image disque d'install du SDK ils disent que par exemple les "System Tools" sont obligatoirement installés dans /Developer, même si on choisit un autre emplacement pour les "Developer Tools Essentials" et le reste... Et c'est vrai que dans /Developer3/Applications/Performance Tools/ j'ai pas de dossier CHUD par exemple... mais bon
Vu mes déboires j'hésite à renommer /Developer3 en /Developer et relancer l'installeur du SDK3.0, j'ai peur qu'il me recasse tout...?
Tout marche à merveille.
Je compile donc en 3.0 sur le simulateur ou en 2.2.1 sur le device.
Et je n'ai qu'un seul dossier Developer Ali...
En passant au 3, je n'ai eu qu'un seul warning sur une méthode deprecated.
Oui au fait j'ai oublié de vous tenir au courant, mais j'ai fini par prendre mon courage à 2 mains et j'ai osé le test :
1) Renommer mes dossiers en /Developer221 et /Developer3 et ne plus avoir de /Developer --> ça marchait (mais j'ai noté que dans /Developer3 je n'avais pas les CHUD et autres Performance Tools, normal vu ce qui est dit dans le PDF et la procédure que j'ai suivie). A ce stade je n'avais donc plus de dossier nommé /Developer
2) Relancer l'installation du SDK 3.0àŸ5, en laissant l'emplacement par défaut /Developer. Cela m'a donc recréé une 3e installation (une 2e installation du SDK 3.0)... et cette fois-ci elle fonctionnait.
3) Mis à la poubelle /Developer221 et /Developer3, redémarré (on sait jamais je sais qu'il y a des .kext qui trainent dans l'installation des DevTools), croisé les doigts, lancé le Xcode.app de /Developer, compilé en 2.2.1 et en 3.0 pour le Device... aucun pb, j'avais bien i386 pour Simulator et armv6 pour Device... ouff
4) Vidé la corbeille, redémarré again, prié
Ouf ! Donc je sais pas ce qui a cafouillé avec mon installation, mais bon maintenant je suis retombé sur mes pieds, avec un unique dossier /Developer et la possibilité de compiler pour le SDK 3.0 comme les SDK 2.x, pour Simulateur comme pour Device, et tout fonctionne
Bingo ! T'es trop fort !
Faut la remplacer par quoi (je suis pas encore allé voir la doc là -dessus, mais si t'as la réponse...) ?
Ravi que t'aies réglé tes problèmes.
Je le sais car la seule appli 2.2.1 que j'ai essayé de compiler avec le SDK 3.0 pour voir si elle passait avait une UITableView et j'ai eu ce warning, donc je suis allé voir par curiosité (mais bon, j'ai pas changé mon code qui n'a pas pour vocation de tourner tout de suite sur 3.0, c'était juste pour voir)
Justement j'ai fait exprès de poser la question parce que par exemple, dans la doc 3.0, il est écrit en rouge dans la doc de UITableViewCell :
– initWithFrame:reuseIdentifier: Deprecated in iPhone OS 3.0
et aucun warning ni erreur quand je compile pour le 3.0 alors que j'en ai 10 dans mon projet ! (j'espère qu'on peut parler de cela librement car ça ne concerne pas les nouvelles fonctionnalités)
En effet normalement Apple utilise des constantes #define, justement quand on regarde la définition dans les headers de l'iPhone SDK 3.0 de cette méthode, on voit : et de fil en aiguille au final ça devrait être résolu par le précompilateur en donc positionner l'attribut [tt]__attribute__((deprecated))[/tt] normalement pris en compte par gcc. Reste à savoir s'il n'y a pas une option pour ignorer ces attributs et les warnings associés... ou pas, tout comme on peut régler le "niveau" de warning. J'ai pas cherché encore (pas le temps là ) mais ça serait intéressant de creuser.
Je n'ai pas trouvé sur le site ADC la meilleure méthode pour créer des conditions en fonctions de l'OS utilisé, ou plutôt de la version utilisée.
Je cherche un truc du genre :
Par exemple, j'ai un bouton à créer avec des méthodes deprecated :
- button.font n'existe plus en 3.0
- button.titleLabel.font le remplace
Comment récupérer la version de l'OS, que ce soit avec le simulateur ou le device ?
Je pensais à autre chose que : [UIDevice systemVersion] ...
Par exemple [tt]__IPHONE_3_0[/tt] est défini dans ce header du SDK 3.0 alors qu'il n'est pas défini dans .../SDKs/iPhoneOS2.2.1.sdk/...
Après je sais pas s'il y a des macros "plus officielles", mais faut creuser dans les parages.
J'ai donc fait ceci :
Cela semble fonctionner sans problème, et devrait m'assurer compatibilité avec les prochains SDK 3.x également.
J'ai un problème curieux avec la bêta d'iTunes 8.2 livrée avec le SDK 3.0. Je l'ai téléchargé et installé pour mettre l'OS 3.0 sur mon iTouch. Parfait, rien à redire.
Ensuite j'ai dus reformater mon disque dur à la suite d'un problème. Heureusement j'avais une copie du SDK 3.0 et d'iTunes 8.2 sur une clé USB. Mais surprise.. iTunes 8.2 ne fonctionne plus !
Au lancement, il affiche "L'application iTunes n'a pas pu être ouverte. Mémoire disponible insuffisante.".
Je l'ai re-chargé à partir du site d'Apple, sans aucun changement. Toujours ce message d'erreur au lancement !
Avez-vous une suggestion sur la manière de régler ce désagrément ?
Pour ma part, je me pose cette petite question : quand on ajoute des frameworks à son projet (quartzCore par exemple), on peut ajouter la version 2.2.1 ou 3.0... pour ma part je reste en 2.2.1 pour la compatibilité, même quand je lance la compil en 3.0 dans le simulateur. Il en est de même avec sqliteLib par exemple, que je vais chercher dans le SDK 2.2.1 et non 3.0.
Je pense avoir bon ?!
Soit tu mets un chemin d'accès absolu et du coup il ira toujours chercher le même framework (celui du SDK 2.2.1 par exemple, même si tu compiles pour la 3.0), soit tu mets un chemin d'accès relatif au "Current SDK" et il ira chercher le 2.2.1 quand tu compiles en 2.2.1, et le 3.0 quand tu compiles pour la 3.0.
Je viens d'activer mon iPhone Dev Program.
J'ai donc installé le SDK 3.0 et remplacé les methodes deprecated par les nouvelles. Jusque là tout va bien.
Mon problème, c'est une "EXC_BAD_ACCESS" error qui intervient soudainement alors que tout marchait bien en 2.0, et le NSZombieEnabled ne me donne rien...
En fait, je présent une view controller avec une méthode de type
- (void)foo {
MyViewController *controller = [[MyViewController alloc] initWithNib bla bla...];
controller.delegate = self;
[self presentModalViewController:controller animated:YES];
[controller release];
}
Mon View Controller appelle son delegate quand il a fait ce qu'il devait faire, et dans la méthode delegate, self fait donc :
[self removeModalViewController];
Et là , si je fait un deuxième appel à Foo, et bien ça crashe avec un EXC_BAD_EXCESS ! Et je ne comprends vraiment pas pourquoi !.
Si quelqu'un a une idée, je suis preneur.
J'ai trouvé plein de références à ce probleme en cherchant sur google, mais je n'ai trouvé aucune solution...
Tu dois appeler une méthode sur un objet releasé ou pas instancié.
Tu dis que le même code marche sur l'OS 2.2 ?
Le principe c'est que j'appui sur un bouton " +" pour ajouter un nouvel élément à ma table view. Pour ce faire, le "+" associé à ma fonction foo lance un modal qui permet d'entrer les propriétés du nouvel objet. Quand j'en ai fini, je peux soit valider et revenir à ma table view. (et là ça marche), soit valider et immédiatement générer un nouveau modal view (pour éviter à l'utilisateur de répéter plusieurs opérations). Dans mon code, je ne fait que faire un appel à foo directement après avoir fait appel à [self removeModalViewController].
La différence avec une opération entièrement manuelle, c'est le temps nécessaire à la disparition du modal view controller de l'écran (je sais pas si je suis clair...)
En gros, si je le fait "manuellement" ça marche. Si j'évite à l'utilisateur de le faire en rechargement dans le code un nouveua modal view et bien ça plante... Le code appellé est le même, mais je pense qu'au niveau de la mémoire le fait que mon controller n'est pas encore disparu quand j'en appelle une nouvelle instance change tout...
Je vais donc essayer de procéder autrement... en espérant que vous aurez à moitié compris ce que j'essaye d'expliquer (pas évident).
Au lieu de supprimer mon view controller pour en créer un autre tout de suite après, je réutilise le même. C'est tout de même plus logique.
J'y ai en plus ajouté un petit effet de "CurlDown" qui s'y prête très bien.
ça veut dire que mon simulateur simule l'iPhone vidéo.
Si mon application compilée en 2.2.1 n'a pas de bugs et qu'elle n'utilise pas les fonctionnalités de l'OS3; il n'y a pas vraiment d'intérêt à résoudre les bugs d'affichage qui apparaissent si on compile en v3.
Soumettre une appli en 2.2.1 ne devrait donc pas poser de problèmes pour les iPhone vidéo si il n'y en a pas sous le simulateur 3 lorsqu'on compile en 2.2.1.
Quelqu'un peut-il valider ce raisonnement et confirmer que j'ai mis du temps à me réveiller?
EDIT: en me relisant ça me parait évident