Static Library vs Dynamique vs Framework.
Bonsoir,
Ma question est dans le titre, donc je voudrais bien savoir c'est quoi la différence entre les trois concepts. J'ai vu des gens utiliser des Framework sous iOS, je veux dire q'ils créer genre une library mais c'est un .framework et ils l'intègre dans un projet
Une autre question : est-ce que y a une possibilité de rajouter des resources dans une library Static ? genre un Plist ou bien CoreData et d'accéder a ces resources en dehors de la Library.
Merci pour vos réponses.
Ma question est dans le titre, donc je voudrais bien savoir c'est quoi la différence entre les trois concepts. J'ai vu des gens utiliser des Framework sous iOS, je veux dire q'ils créer genre une library mais c'est un .framework et ils l'intègre dans un projet
Une autre question : est-ce que y a une possibilité de rajouter des resources dans une library Static ? genre un Plist ou bien CoreData et d'accéder a ces resources en dehors de la Library.
Merci pour vos réponses.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Je parle également beaucoup ici sur ce post de ce même sujet (je te mets un lien vers là où je commence à expliquer après avoir fait ma présentation, mais tu peux lire tout le sujet y'a pas mal de choses qui ont été abordées)
La vidéo de la présentation est visible ici et le détail des étapes pour faire une librarie statique propre (dans un projet dédié qui s'intègre proprement à ton Workspace) mais également pour y intégrer des ressources est dispo ici sur mon GitHub (car lors de la vidéo j'ai expliqué une méthode mais j'en ai découvert une mieux et plus propre depuis, expliquée sur mon GutHub et dans le post cité plus haut, justement)
Bref, j'ai vraiment pas mal couvert le sujet surtout à l'occasion de cette présentation et cela devrait répondre précisément à toutes tes questions ci-dessus !
J'vais lire tout ça pour comprendre les différences.
Des avis sur cocoapods ?
De quel cocoapods s'agit-il?
CocoaPods, c'est bien et c'est une bonne initiative, maintenant à installer c'est pas forcément trivial (pas compatible avec la version de Ruby installée par défaut avec Mountain Lion, du coup perso j'ai bien galéré à le faire fonctionner la première fois avec les erreurs dans tous les sens... digne d'une install d'un soft OpenSource foireuse à la mano avec Makefile ^^).
Une fois que c'est en place, le principe me semble très sympa, même si je me suis toujours demandé si on pouvait utiliser un repository de PodSpecs privé en plus de celui public de CocoaPods (pour pouvoir utiliser nos librairies internes à nous sans pour autant devoir forcément les publier sur leur repo public).
Seul point qui pourrait me gêner dans CocoaPods c'est qu'au final il fait une seule librairie libpods.a qui inclus toutes les librairies tierces parties, alors que moi j'aime bien avoir des projets et des .a séparés par librairie (pour toutes les raisons que j'ai déjà évoquées dans ma présentation CocoaHeads #12, à savoir pouvoir rechercher du texte par fmk/lib/projet, gérer les warnings par projet, éviter les conflits de macros et d'options de compilation...
Mais j'ai ouvert une issue et discuté avec le mec de CocoaPods et la communauté, et ils songent à changer ça et mettre une option, donc du coup ça me réconcilierai sûrement avec CocoaPods (même si je suis du genre à préférer tout faire moi-même et monter donc mon workspace à ma façon ^^)
J'ai aussi récemment galeré pour mètre en place sur un projet une stack fonctionnent avec Cocoapods.
Comme tu l'as dit au début on à l'impression d'être avec plein de Makefile dispatché à travers le globe.
Mais une fois en place j'ai tout de suite compris le gain.
J'ai pas joué avec toutes les options possibles, mais il est possible d'avoir un repository de podspecs privé (voir plusieurs) en plus de celui public.
J'ai aussi réussi à inclure des .a séparés, et il est aussi possible d'avoir des options par projet, et d'executer des hooks lancés avant l'installation et après l'installation des dépendances.
Ensuite il suffit de faire un:
ce qui installera toute les dépendances (et les dépendances des dépendances...) dans les versions définie dans le Podfile.
Une fois un pod install effectué sa créer un workspace intégrant leur lib et notre projet.
Ruby s'installe très facilement en utilisant rvm
@zoc : oui, maintenant je le sais, et c'est ce que j'ai fini par découvrir... mais à l'époque n'ayant encore jamais touché du Ruby, pour savoir comment mettre à jour Ruby sur mon Mac j'ai dû chercher et un peu galérer...
C'est le genre de trucs où tu cherches sur le net y'a plein de réponses/solutions sur différents sites du coup tu sais pas trop laquelle choisir ou quel tuto suivre et t'as pas envie d'installer 36 trucs et de réaliser à chaque fois que non ça ça marche pas, ça non plus, ça ça marche à moitié, y'a sans doute juste un truc qui manque à configurer mais t'y captes rien car t'as jamais touché... et t'as pas envie de finir avec un bordel monstre sur ton Mac à avoir installé 36000 trucs inutiles au final.
Alors maintenant que j'ai galéré avec, oui j'ai découvert l'existence de RVM, comment l'installer lui et ses dépendances, et comment l'utiliser pour mettre à jour Ruby, pour pouvoir enfin lancer CocoaPods... mais bon faut être patient et persévérer (et pas se gourer de tuto sur le net) !
Ouais, pour une fois, t'aurais pu poser une question sur CocoaCafé, nous étions plusieurs à avoir la réponse. Certes, il y avait le risque de te décribiliser à nos yeux et de perdre ton statut de Maà®tre de Cocoa. >:D
En même temps, Ruby c'est pas tout à fait Cocoa ... Il ne sera pas maà®tre Ruby c'est tout.
La prochaine fois je posterai sur RubyCafé