Xcode 4.4 plus de "Static Framework" sous iOS ???

Bonjour,



Avant la version 4.4 je me rappel avoir vue la possibilité de créer un Framework Statique sur iOS. À l'époque n'ayant pas besoin de créer un Framwork Statique j'ai pas fait plus attention. À force de travailler sur iOS et Mac j'ai fini pas me monter un ensemble de classes que j'aimerai regrouper dans un Framework. L'objectif étant de réutiliser ces classes dans plusieurs projets et d'en faire la maintenance dans le Framework statique uniquement. Quand je vais dans la partie "Framework & Library" sur iOS je ne vois que "Cocoa Touch Static Library".



Est ce que c'est moi qui est cru voir la possibilité de faire un Framework Statique sous iOS ou est ce Apple qui a tous simplement décidé de retirer cette option image/huh.gif' class='bbc_emoticon' alt='???' />



Merci pour vos réponses
Mots clés:

Réponses

  • AliGatorAliGator Membre, Modérateur
    Il n'y a à  ma connaissance jamais eu de template tout fait pour créer un framework statique pour iOS livré avec Xcode. Mais bon ce n'est pas parce que le template de projet n'existe pas que tu ne peux pas le faire. Après tout, un framework n'est rien d'autre qu'une lib empaquetée dans un bundle et avec les headers à  ses côtés.



    Le problème c'est que le concept de framework à  proprement parler dans iOS n'a jamais été supporté, au delà  des frameworks officiels Apple. Xcode ne le propose simplement pas de base.

    La seule solution est donc :

    1) soit de faire un "fake framework", c'est à  dire reconstruire l'arborescence d'un framework (dossier d'extension .framework, à  la racine le binaire (ou un lien symbolique vers ce dernier) de la lib de ce .framework, et sous-dossier Header avec les .h dedans).

    2) soit de modifier Xcode pour autoriser dans les xcspecs de générer un framework statique sur iOS comme il sait le faire pour OSX. Mais ce n'est pas forcément une bonne idée car cela implique de modifier Xcode (et ton projet ne compilera donc plus sur un autre Xcode)



    Pour la solution 1, il suffit de créer une librairie statique (donc "Cocoa Touch Static Library" justement), puis de créer un script de Post-Build qui va empaqueter le tout comme il faut. L'idéal étant quand même de faire un framework universel (i386 pour quand tester sur le simulateur, et armv6/armv7 pour le device) donc de compiler dans les 2 architectures puis de combiner les binaires dans un FAT binary avec lipo.





    Ceci dit, dans l'ensemble, avec Xcode4 c'est quand même vachement plus simple de faire un workspace pour ton appli, et d'inclure les différents composants comme des projet Xcode (xcodeproj), qui se compileront automatiquement (détection auto de dépendances de Xcode4) quand tu compileras ton appli, et ce pour la bonne archi (i386/armv6/armv7), sans avoir besoin de créer un framework pour autant.



    Dans tous les cas, recherche sur le forum, il y a pléthore de sujets qui parlent de frameworks statiques, de gestion de projets, de workspaces et d'intégration de projets tierces dans tes applis.
  • Sinon j'ai écris un post a propos de la compilation de library statique pour iOS qui permet d'embarquer le support Simulateur + Device :

    http://www.pixiapps.com/blog/?p=116

    Mais la solution d'aligator est idéale si tu possèdes les sources. Et puis ça évite d'embarquer un binaire 2x plus gros du fait du double support simu/device.
  • TofTof Membre
    'AliGator' a écrit:


    Il n'y a à  ma connaissance jamais eu de template tout fait pour créer un framework statique pour iOS livré avec Xcode. Mais bon ce n'est pas parce que le template de projet n'existe pas que tu ne peux pas le faire. Après tout, un framework n'est rien d'autre qu'une lib empaquetée dans un bundle et avec les headers à  ses côtés.



    Le problème c'est que le concept de framework à  proprement parler dans iOS n'a jamais été supporté, au delà  des frameworks officiels Apple. Xcode ne le propose simplement pas de base.

    La seule solution est donc :

    1) soit de faire un "fake framework", c'est à  dire reconstruire l'arborescence d'un framework (dossier d'extension .framework, à  la racine le binaire (ou un lien symbolique vers ce dernier) de la lib de ce .framework, et sous-dossier Header avec les .h dedans).

    2) soit de modifier Xcode pour autoriser dans les xcspecs de générer un framework statique sur iOS comme il sait le faire pour OSX. Mais ce n'est pas forcément une bonne idée car cela implique de modifier Xcode (et ton projet ne compilera donc plus sur un autre Xcode)



    Pour la solution 1, il suffit de créer une librairie statique (donc "Cocoa Touch Static Library" justement), puis de créer un script de Post-Build qui va empaqueter le tout comme il faut. L'idéal étant quand même de faire un framework universel (i386 pour quand tester sur le simulateur, et armv6/armv7 pour le device) donc de compiler dans les 2 architectures puis de combiner les binaires dans un FAT binary avec lipo.





    Ceci dit, dans l'ensemble, avec Xcode4 c'est quand même vachement plus simple de faire un workspace pour ton appli, et d'inclure les différents composants comme des projet Xcode (xcodeproj), qui se compileront automatiquement (détection auto de dépendances de Xcode4) quand tu compileras ton appli, et ce pour la bonne archi (i386/armv6/armv7), sans avoir besoin de créer un framework pour autant.



    Dans tous les cas, recherche sur le forum, il y a pléthore de sujets qui parlent de frameworks statiques, de gestion de projets, de workspaces et d'intégration de projets tierces dans tes applis.


    Je suis effectivement tombé sur des articles avec les 2 solutions dont tu parles. De mon coté j'ai trouvé l'article suivant :
  • TofTof Membre
    août 2012 modifié #5
    'ldesroziers' a écrit:


    Sinon j'ai écris un post a propos de la compilation de library statique pour iOS qui permet d'embarquer le support Simulateur + Device :

    http://www.pixiapps.com/blog/?p=116

    Mais la solution d'aligator est idéale si tu possèdes les sources. Et puis ça évite d'embarquer un binaire 2x plus gros du fait du double support simu/device.


    Merci pour ton article. Il est très intéressant même si ça correspond pas à  ce que je recherche.



    Ce que je trouve intéressant avec les Framework c'est d'avoir l'exécutable proprement dit mais aussi les fichiers *.h et toutes les ressources associés au Framework. Sans ces *.h et ressources la librairie statique ne servirait à  rien. Sans compter les dépendances avec d'autres frameworks qui ne sont pas présent dans la librairie statique. Plusieurs fois j'ai du aller à  la pêche aux Frameworks qu'utilisait une de ces librairies statiques pour les mettre en tant que dépendance de mon projet !
  • C'est vrai que c'est plus simple d'un point de vue visuel, parce que tout est encapsulé dans un bundle, mais bon c'est tout aussi faisable avec une library statique + bundle de ressources et les headers d'un côté.

    Encore une fois pour ce genre de chose la solution la moins fatigante c'est celle d'ali
  • TofTof Membre
    août 2012 modifié #7
    'ldesroziers' a écrit:


    C'est vrai que c'est plus simple d'un point de vue visuel, parce que tout est encapsulé dans un bundle, mais bon c'est tout aussi faisable avec une library statique + bundle de ressources et les headers d'un côté.


    Faire un bundle avec la librarie statique et tous ce qui lui est rattaché n'en fait pas pour autant un vrai framework comme on peut le faire sous Mac OS X. Les dépendances ne sont pas supportées ce qui oblige celui qui veut utiliser la librairies de les rajouter lui-même dans son projet.
    'ldesroziers' a écrit:


    Encore une fois pour ce genre de chose la solution la moins fatigante c'est celle d'ali


    La solution d'Ali avec les workspace est idéale quand tu as les sources des librairies que tu utilise dans ton projet. Par contre si tu souhaite faire une librairie que tu veux revendre ensuite (dont tu ne fournis pas les sources) ça va être casse tête pour ceux qui voudront l'intégrer dans leurs projets. La solution dans ce cas là  est celui du Framework mais Apple ne nous offre pas cette option. Modifier nous même Xcode n'est pas une solution et faire un pseudo Framework facilite la distribution mais pas nécessaire l'intégration dans un projet (quoi que j'ai pas encore essayé cette approche).
Connectez-vous ou Inscrivez-vous pour répondre.