Gestion de développement
GG
Membre
Bonjour à tous,
je cherche le moyen de faire des développements un peu plus factorisés, mais je ne connais pas encore le moyen de le faire.
Je cherche par exemple à faire une petite librairie contenant une fenêtre graphique et un objet cocoa utilisant cette fenêtre graphique. (Son rôle est de chercher un type de fichier et de les stocker dans un NSArray, la fenêtre n'a pour unique rôle que d'arréter la recherche et de visualiser l'état de la recherche).
Dans quoi puis je stocker ce fichier nib et ma ou mes classes cocoa, que je pourrai ensuite utilisé dans un projet plus important ?
Bonne journée à tous.
je cherche le moyen de faire des développements un peu plus factorisés, mais je ne connais pas encore le moyen de le faire.
Je cherche par exemple à faire une petite librairie contenant une fenêtre graphique et un objet cocoa utilisant cette fenêtre graphique. (Son rôle est de chercher un type de fichier et de les stocker dans un NSArray, la fenêtre n'a pour unique rôle que d'arréter la recherche et de visualiser l'état de la recherche).
Dans quoi puis je stocker ce fichier nib et ma ou mes classes cocoa, que je pourrai ensuite utilisé dans un projet plus important ?
Bonne journée à tous.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
En gros je ne voudrais pas que le nouveau projet nécessite l'installation de ce framework
Une classe qui crée et fait le design du panel ou de la window ....
Une sous-classe de NSWindow/NSWindowController , et à l'utilisation, on attribue dans IB cette classe?
Le package ( nib pour le panel + classe associée ) je ne connais pas si ce n'est à importer/copier les deux.
Oui, un Framework peut être intégré à une application dans les ressources (encore que j'ai pas retrouvé comment faire avec Xcode 2.5 et Leopard).
Un plugin est complètement indépendant du bundle application qui le contient.
Il se stocke dans le bundle de l'appli dans un sous répertoire Plugins.
Dans l'appli principale, le plugin se charge par programmation ([[NSBundle mainbundle] builtInPlugInsPath]+nom_du_plugin pour récupérer le chemin du plugin à charger, puis [[NSBundle bundleWithPath:] load] pour le charger).
A tout moment on peut savoir si le plugin s'est réellement chargé ou non.
Si c'est non, ça n'empêche pas l'appli de fonctionner.
Quand au lien, on peut faire du weak-linking avec les Frameworks mais peu d'intérêt dans ce qu'il veut faire je pense.
Le plugin est complètement indépendant de l'appli qui l'utilise.
Il peut être utilisé par une ou plusieurs appli s'il est bien conçu (soit en l'incluant dans le bundle de chaque appli, soit en passant par les répertoires plugin communs du user ou du système).
Avec le weak link, c'est possible (sous certaines conditions, dont le version OSX et GCC) d'avoir une lib absente au lancement de l'appli.
Mais ce n'est plus vrai pour la compil de l'appli où le framework est indispensable.
Le plugin est par nature indépendant, donc aucun souci : il peut être développé dans un projet à part, par un autre programmeur, sur une autre machine.
L'inconvénient du plugin est d'être "statique", c'est à dire d'avoir son code dupliqué par chaque process qui le charge (alors que le framework peut être dynamique, donc en mémoire partagée).
Plugin on nous tous !
Cela contient donc un ou des objets d'interface graphique que l'on rajoute à la librairie de IB, et le framework qui va avec.
Ta définition du plugin est un peu stricte...
C'est surtout la phrase "En gros je ne voudrais pas que le nouveau projet nécessite l'installation de ce framework" de GG qui me faisait pencher vers le plugin.
De toute façon, plugin ou framework ont la même structure (même si des différences existent dans le binaire), donc c'est à GG de trancher.
Soit pas morveux, respire et explique sans te moquer... C'est un forum, non ?
Cela s'utilise très simplement :
Dans un nouveau projet, vous importez le framework (il contient les "objets IB" nécessaires via le plug-in).
IB complète automatiquement alors sa librairie avec le plug-in, c'est à dire le ou les objets que vous avez définis, que l'on peut alors utiliser dans son interface. 8--)
Ceci dit, par rapport à la spécification du problème, une simple classe semble pouvoir suffire à circonscrire le problème, avec une interface dynamique.
plug-in -> qui se branche
Si une application a "besoin" de son plugin pour fonctionner, pour moi c'est pas un plug-in :P
On peut faire l'analogie avec le hardware et les accessoires.
Et justement, au niveau du binaire avec un Framework c'est quasiment comme si c'était une classe et un nib interne.
Par exemple, WebKit.framework intègre ses classes, et son panneau d'authentification dans un .nib
Pour ne pas avoir à l'installer, on peut l'inclure dans les ressources et faire le lien relatif.
Il me semble bien à ce que tu dis que Webkit.framework est un IBPlugin "standard", et on se retrouve d'accord.
C'est un vrai Framework avec de nombreuses classes et quelques .nib
Par contre, y a un IBPlugin lié pour les WebView je crois effectivement.
Je n'ai jamais fait ce genre de projet :
On ouvre un projet "Framework" et les fichiers .nib s'archivent avec ?
Ci-joint une utilisation d'un ibplugin : dans la librairie, on ne voit pas vraiment la différence entre la webframe et le custom ibplugin ClosingBox.
Framework
Plugin
IBPlugin
Ce sont trois choses très différentes ???
La construction d'un IBPlugin (anciennement IBPalette), c'est-à -dire l'ajout à IB d'objets d'interface personnalisés, se fait avec le code des classes corrrespondantes à ces objets.
Désormais, le packaging se fait par un framework contenant en ressources un fichier .ibplugin qui est utilisé par IB pour faire sa sauce. (dans l'ancienne technologie, il y avait séparation du framework et des "palettes" pour IB)
 Â
Pour l'utilisation, voir plus haut
Dans mon /System/Library/Frameworks, j'ai trouvé ceux-ci (et pas de trace de WebView)
Dans IBPlugin Guide, Apple autorise tout aussi bien le mode package décrit ci-dessus que le mode framework/plugin séparé, la manip est un peu moins automatique dans ce dernier cas.
voir documentation
En fait, le framework nécessite qu'il soit installé sur le système.
Je pensais que l'on pouvait compiler de manière statique un framework, et donc ne pas être obligé de l'installer.
En gros je voulais factoriser mes développements, et faire une bibliothèque à la manière d'une archive .a en C (compilation statique possible, pas besoin d'installation de cette dite bibliothèque).
Comment faire pour créer une bibliothèque possédant un fichier nib (ou xib avec Xcode 3.1) et du code, et l'incorporer d'un nouveau projet en le compilant et l'incorporant de manière statique.
Vous avez une idée ?
Si vous voulez tester ce que j'ai fait je peux mettre une archive ici avec les deux projets.
Bonne soirée à tous.
Et un framework privé ne ferais pas l'affaire? L'utilisateur n'en voit rien. Il est installé à l'intérieur de l'application.
Jettes un oeil par ici
Ben ça a déjà été dit un peu tout le long du sujet ; le framework tu le mets dans les ressources de l'appli et tu fais le lien (dynamique) avec celui à l'intérieur de l'appli.
-> rien à installer ???
Ca fonctionne par contre lorsque je mets le framework dans ~/Library/Framework (mais déconseillé par la documentation d'Apple).
Xcode refuse de copier le framework lorsque je suis sur Target ( de l'application ), et que je fais New Build Target -> New copy file build et que je choisis l'onglet Framework et le chemin du framework qui se situe dans le projet.
Est ce un problème de version de Xcode ?
Le chemin du framework dans la 'New copy file build phase' veut dire "sous-chemin de destination du fichier à partir d'un répertoire relatif au bundle de l'application tel qu'indiqué dans l'onglet".
Donc dans ton cas, il faut faire: onglet: "Framework" - subpath: rien.
Et il faut surtout ajouter le framework à la build phase par glissage/déposage.
Après, plus qu'à modifier le build setting 'install path' dans la target du framework en suivant les indications données dans la documentation accessible dans xcode à la suite d'une recherche 'embedded framework' par exemple ... et le tour est joué.
Il me reste un truc à faire, c'est de donner le bon path à l'execution de l'application car elle cherche toujours en ~/Library/Framework/.....
Je regarde dans la configuration de l'application (pour le framework j'ai suivi les instructions de la doc à savoir @executable_path:../Frameworks).
Tu es sur qu'Apple déconseille cela ? Il s'agit du chemin d'accès au répertoire standard pour les Frameworks d'un utilisateur donné ~ .
Bingo. Je voulais pas le dire par timidité ...
(juste une petite typo que tu as sans doute déjà corrigée: il faut remplacer ':' par '/'.
Normalement, l'appli devrait chercher toute seule le framework dans son dossier Framework, donc pas besoin de le lui dire.
C'est peut-être à la compilation que ça coince mais dans ce cas il faudrait plus de précisions ...