Librairie sous licence
pistonman33
Membre
Bonjour à tous,
J'ai déjà développé quelques applications IOS pour Ipad et iphone.
Et j'aimerais développer une libraire sous licence pour des clients.
Comment dois je m'y prendre ?
J'ai déjà utilisé des librairies payantes sous licence avec des fichiers .a mais je ne sais pas du tout comment faire cela !
Y a t'il de la documentation ?
Je suppose qu'il faut aussi crypté cette partie de code...
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Et pour faire un .a, il suffit... de sélectionner le bon type de projet dans Xcode, en l'occurrence "Cocoa Touch Static Library" pour iOS et "Library" pour MacOS X.
Après il faudra livrer le .a ainsi que les .H publics (à toi de découper intelligemment les .H pour que ceux distribués avec le .a ne contiennent que le strict minimum nécessaire à l'utilisation de la lib).
Merci zoc pour ces informations et désolé pour ma réponse tardive...
J'ai recherché de la documentation concernant la création de ces librairies et j'aurais voulu savoir la différence et l'intérêt pour l'une ou l'autre de ces deux solutions:
Création d'un .framework
Création d'une librarie static avec l'exécutable .a
J'aimerais savoir qu'elle est la meilleure solution suivant le projet.
Merci Aligator pour cet article intéressant qui permet de bien comprendre la différence entre les libraries statiques et dynamiques.
Par contre, j'aurais voulu savoir aussi si je fais un framework dynamic il y a moyen de voir le code source du framework ?
L'avantage du .a compilé c'est que nos sources sont protégés si on souhaite faire une licence de notre programme.
De plus, je me pose la même question avec la création de librairie avec cocoapods en mode privé: ?
OK merci, avez vous déjà testé la création d'un pods en mode privé?
Est ce que les sources sont visibles?
On a choisi de les faire en OpenSource, ce qui fait que oui, le code source est visible, car le podspec de nos pods privés se base sur les sources .h/.m
Mais bon rien n'empêche de faire des podspecs qui, au lieu de baser nos pods sur leurs sources, les basent sur des vendored_libraries ou des vendored_frameworks. Que le pod soit un "pod privé" ou pas n'y change rien.
La seule différence d'un pod en mode privé par rapport au pod en mode public c'est que son podspec, qui expose l'existence du pod, sa version, ses dépendances, etc... est hébergé publiquement (et visible de tous) ou en interne. C'est tout. Mais après quel que soit l'endroit ou le podspec est hébergé, tu peux faire un podspec qui se base sur du code source ou sur une librairie ou un framework compilés, au choix, tout ça est indépendant de où tu héberges le podspec en question.
Tu peux tout à fait par exemple :
- Soit compiler un .a toi-même à partir des sources, puis écrire un podspec pour dire que la lib est constituée de ce .a (et non pas de sources .m). Quand un projet va vouloir dépendre de ce pod (privé ou pas, ça change rien), puisque le podspec de ce pod va lister le .a comme éléments à utiliser, ça va utiliser le .a et donc tu ne verras pas les sources.
- Tu peux aussi avoir un podspec se basant sur le code source, podspec que tu gardes en interne et n'expose pas, mais qui te permet, en interne, de travailler sur les sources, de facilement utiliser le pod en mode "OpenSource" avec le code source visible, etc... pratique pour travailler dessus en privé donc... et utiliser cocoapods-packager (ou cocoapods-rome) pour générer une lib statique (ou un framework dynamique) quand tu veux publier une librairie Closed-Source de ton code pour la distribuer à l'extérieur. D'ailleurs rien ne t'empêche alors de générer un autre podspec, qui lui ne va pas dépendre des sources mais de la lib que tu auras construite, et par contre d'exposer ce podspec au public, comme ça les autres pourront utiliser ce podspec mais qui va récupérer le code compilé de ta lib, alors qu'en interne tu continueras à utiliser ton podspec privé qui se base sur les sources de la lib...
Bref tu fais un peu ce que tu veux. Le podspec n'est qu'un fichier décrivant comment est constitué un pod et quelles sont ses dépendances et sa version. Ce pod peut être constitué d'une lib statique ou être constitué de code source visible de l'extérieur, c'est toi qui vois selon tes besoins.Merci Aligator pour toutes ces explications!
Je me suis enfin lancé dans le développement de ce framework, et je dois t'avouer que je galère depuis un moment dessus.
Donc j'ai suivi ton conseil, j'ai mis en place un podspec avec mon framework que j'ai développé et qui se charge de retourné uniquement le .framework avec la directive vendored_frameworks quand tu m'avais conseillé. J'ai donc mis en place aussi un autre projet qui va rechercher mon framework via le podfile et cela fonctionne correctement car je retrouve mon framework dans Pods > Development Pods > xxxx >Frameworks > xxxx.framework.
Par contre je me heurte à un mur (à nouveau), quand je compile et exécute mon projet j'obtiens l'erreur suivante:
Dans le podFile, j'ai juste rajouter la directive vendored_frameworks, y a t'il d'autres directives nécessaires ?