›

Aide sur une structure de "plug-in"

ObiObi Membre
14:52 modifié dans Objective-C, Swift, C, C++ #1
J'aimerais avoir votre avis éclairé sur un problème de structure. :o

Je bosse sur un projet dont le code est simple et qui n'est pas censé évoluer sensiblement. J'aimerais donc faire un système de plug-ins très simple pour étoffer les fonctionnalités.
J'ai cherché de la doc qu'il faut que je décortique mais j'aimerais savoir si vous penser que c'est une voie qui mérite que j'y passe du temps.

Alors, actuellement, j'ai une classe "Action" qui a les méthodes de bases pour traiter les données que je lui envoie. J'envoie un objet (qui contient les données) à  une instance de "Action", elle les traite et me renvoie l'objet modifié. Elle connaà®t rien d'autre, c'est vraiment basique.
Mon idée est de faire des sous-classes de "Action" qui "surchargent" la seule méthode qui est appelée et qui retourne les données qu'elle aura traité à  sa façon.

J'aimerais faire des "plug-ins" que je chargerais au lancement de mon appli, dont je proposerais une liste à  l'utilisateur et dont j'appellerais l'unique méthode.
J'y vois 2 avantages :
- ça me permettrait de ne plus toucher au coeur de l'appli et de créer / mettre à  jour les fonctionnalités plus facilement (souplesse pour moi et pour l'utilisateur final)
- ça permettrait d'enrichir le soft avec des plug-ins d'autres développeurs

Pensez-vous que ça soit une option viable ? Est-ce long à  implementer ? Avez-vous des explications-exemples-urls que je pourrais utiliser pour valider ce choix ?

Merci !  o:)

Réponses

  • BruBru Membre
    14:52 modifié #2
    Sous cocoa, une architecture de type plug-in est simple à  faire.

    Tous les élements qui doivent être sortis de l'appli (et donc situés autre part sur le disk) doivent être mis dans un bundle.

    Depuis ton appli, il suffit de charger le bundle pour y récupérer ces éléments.
    Les éléments peuvent être de tout type, et surtout, cela peut être du code (en fait des classes qui tu as écrit). Au moment du chargement du bundle, tu pourras charger ces classes, les instancier (alloc/init) puis appeller les méthodes qu'elles implémentent.

    .
  • ObiObi Membre
    14:52 modifié #3
    Merci pour cette réponse ultra-rapide  :P

    dans 1114694595:
    Au moment du chargement du bundle, tu pourras charger ces classes, les instancier (alloc/init) puis appeller les méthodes qu'elles implémentent.


    Ca marche même avec une sous-classe d'une classe qui n'est pas dans le plug-in mais dans l'appli ?
    En tout cas, si c'est simple à  faire, je commence dès maintenant !  :adios!:
  • BruBru Membre
    14:52 modifié #4
    dans 1114697794:

    Ca marche même avec une sous-classe d'une classe qui n'est pas dans le plug-in mais dans l'appli ?


    Bien sûr !

    Ca s'appelle le dynamisme, et Objective-C est profondément dynamique.
    Il faut juste que la classe mère soit déjà  chargée au moment du chargement du plugin implémentant sa "fille".

    .
  • ObiObi Membre
    14:52 modifié #5
    Merci pour ces conseils ! 
    Je vais donc me lancer dans cette structure sans hésiter. J'ai récupérer un tutoriel sur Cocoa dev central qui m'a l'air très complet et bien expliqué. Visiblement dans cet exemple, l'appli et le plug-in communiquent via un protocole et pas par système de sous-classe. Ma structure étant plutôt light, je ne pense pas avoir trop de mal à  la modifier pour coller à  l'exemple.

    Si j'arrive à  quelque chose de potable, je vous montrerais le projet. Ca vous donnera peut-être des idées de plug-ins  ;)  :P
  • ObiObi Membre
    14:52 modifié #6
    Je touche presque au but avec ma structure de plug-ins mais il me reste un problème qui me bloque  :'(
    J'arrive, depuis l'appli, à  charger les plug-ins, instancier leur classe principale et appeller leurs methodes. Le tout via un protocole dont je partage le fichier ".h" entre les projets.
    J'ai même fait un cluster pour avoir tous mes plug-ins de base dans 1 seul bundle.

    Maintenant, je voudrait créer une classe "Utilitaires" dans l'appli que les plug-ins pourraient appeler.
    Dans le projet de l'appli, j'ai les fichiers "Utilitaires.h" et "Utilitaires.m", ça compile sans problème.
    Dans le projet du plug-in, j'inclus le fichier "Utilitaires.h" mais ça refuse de compiler quand j'appelle cette classe.

    En gros j'aimerais que le plug-in puisse accéder à  certaines des classes créées dans l'appli mais sans donner le .m et le code des méthodes, juste les headers.

    Vous avez une piste ? Merci d'avance !  :o
  • BruBru Membre
    14:52 modifié #7
    Ouais...

    Mais dans ce cas, ce n'est plus vraiment une architecture plug-in que tu réalises (puisque les dépendances vont dans les 2 sens).

    Pour résoudre de manière simple et rapide ton problème, c'est d'utiliser ta classes Utilitaires dans les plug-in sans la typer : tu utilises id pour faire les déclarations, et dans ce cas, le compilateur ne fera pas de vérification de typage (donc pas besoin de .h, et encore moins de .m).

    Une fois de plus, ça démontre la puissance de l'Objective-C qui n'a besoin de connaitre le type d'un objet pour compiler.

    .
  • ObiObi Membre
    14:52 modifié #8
    dans 1114963249:

    Pour résoudre de manière simple et rapide ton problème, c'est d'utiliser ta classes Utilitaires dans les plug-in sans la typer : tu utilises id pour faire les déclarations, et dans ce cas, le compilateur ne fera pas de vérification de typage (donc pas besoin de .h, et encore moins de .m).


    Cool, ca marche nickel ! J'avais envisagé cette solution mais je pensais que c'etait un peu sale :)
    Je crée une instance de Utilitaires dans l'appli que j'envoie aux plug-ins au moment de leur init.
    Ca me mets des warnings à  la compilation à  cause du id mais le principal, c'est que ca marche !

    Merci encore Bru  o:)
Connectez-vous ou Inscrivez-vous pour répondre.