Cocoa
L'art du pontage...
14/02/08 18:58
La sortie de Leopard, m'a permis de tester une
technologie made in Apple dont j'ai toujours rêvé...
l'AppleScript sans coder en AppleScript !
Si vous êtes un développeur comme moi, complètement dérouté par AppleScript (mais ou est donc la "doc" AppleScript ? Pourquoi y'a t il 36 mots clé pour faire la meme chose ?), mais pourtant persuadé de son potentiel (c'est bien souvent le seul moyen d'interagir avec les iApps tels iTunes, iPhoto ou Mail...) alors jetez un coup d'oeil au Scripting Bridge for Cocoa.
Ce framework est un petite merveille, car il vous permet en quelque sorte de faire de l'AppleScript en Objective-C. Mieux encore, il n'est pas reservé au langage le plus mystérieux inventé par Apple, mais peut aussi être utilisé pour mélanger du Ruby ou du Python et de l'Objective-C (et donc piloter iTunes ou Mail à partir de Python!).
Non seulement vous allez coder dans un langage familier (Objective-C), mais en plus vous allez gagner en performance par rapport à AppleScript (car le runtime compile des AppleEvents de manière optimisée, et surtout les transmets à l'application cible groupés et "juste quand il faut"). Apple promet un gain entre x50 et x100. J'ai pu vérifier ces chiffres par moi meme !
Ce framework est fournit avec 2 petits binaires qui permet de générer des classes Objective-C à partir du "dictionnaire" (le fameu fichier sdef XML ou le fichier scriptingsuite) :
Dans le terminal: sdef /Applications/iTunes.app | sdp -fh --basename iTunes
sdef est un binaire qui lit (et convertit si nécessaire) le dictionnaire AppleScript de l'application cible (ici iTunes) et l'exporte en XML.
sdp lit ce dictionnaire AppleScript et génere les headers (en-têtes) d'une classe dont le prefixe sera "iTunes".
Vous obtenez un .h Objective-C qui déclare (@interface) toutes les classes présente dans le dictionaire AppleScript. Vous obtiendrez par exemple les classes iTunesApplication, iTunesTrack, iTunesPlaylist, iTunesArtwork etc... rien que leur noms doit vous mettre l'eau a la bouche :)
Voici par exemple à quoi ressemble l'interface de la classe iTunesArtwork :
// a piece of art within a track
@interface iTunesArtwork : iTunesItem
@property (copy) NSImage *data; // data for this artwork, in the form of a picture
@property (readonly) BOOL downloaded; // was this artwork downloaded by iTunes?
@property (copy, readonly) NSNumber *format; // the data format for this piece of artwork
@property NSInteger kind; // kind or purpose of this piece of artwork
@end
Alors oui ca déroute encore finalement car c'est de l'Objective-C 2.0 ... mais ca c'est une autre histoire, ca reste quand même lisible pour les maniaques du vieil ObjC...
Je n'ai absolument pas ajouté de commentaire. sdp ajoute les commentaires lui-meme, en fonction du "dictionnaire" AppleScript. C'est très fort, on dirait que cela a été écrit par un ingénieur chez Apple :-D
La prochaine fois je tenterai d'expliquer comment on utilise ces classes dans un monde Objective-C "ponté".
Si vous êtes un développeur comme moi, complètement dérouté par AppleScript (mais ou est donc la "doc" AppleScript ? Pourquoi y'a t il 36 mots clé pour faire la meme chose ?), mais pourtant persuadé de son potentiel (c'est bien souvent le seul moyen d'interagir avec les iApps tels iTunes, iPhoto ou Mail...) alors jetez un coup d'oeil au Scripting Bridge for Cocoa.
Ce framework est un petite merveille, car il vous permet en quelque sorte de faire de l'AppleScript en Objective-C. Mieux encore, il n'est pas reservé au langage le plus mystérieux inventé par Apple, mais peut aussi être utilisé pour mélanger du Ruby ou du Python et de l'Objective-C (et donc piloter iTunes ou Mail à partir de Python!).
Non seulement vous allez coder dans un langage familier (Objective-C), mais en plus vous allez gagner en performance par rapport à AppleScript (car le runtime compile des AppleEvents de manière optimisée, et surtout les transmets à l'application cible groupés et "juste quand il faut"). Apple promet un gain entre x50 et x100. J'ai pu vérifier ces chiffres par moi meme !
Ce framework est fournit avec 2 petits binaires qui permet de générer des classes Objective-C à partir du "dictionnaire" (le fameu fichier sdef XML ou le fichier scriptingsuite) :
Dans le terminal: sdef /Applications/iTunes.app | sdp -fh --basename iTunes
sdef est un binaire qui lit (et convertit si nécessaire) le dictionnaire AppleScript de l'application cible (ici iTunes) et l'exporte en XML.
sdp lit ce dictionnaire AppleScript et génere les headers (en-têtes) d'une classe dont le prefixe sera "iTunes".
Vous obtenez un .h Objective-C qui déclare (@interface) toutes les classes présente dans le dictionaire AppleScript. Vous obtiendrez par exemple les classes iTunesApplication, iTunesTrack, iTunesPlaylist, iTunesArtwork etc... rien que leur noms doit vous mettre l'eau a la bouche :)
Voici par exemple à quoi ressemble l'interface de la classe iTunesArtwork :
// a piece of art within a track
@interface iTunesArtwork : iTunesItem
@property (copy) NSImage *data; // data for this artwork, in the form of a picture
@property (readonly) BOOL downloaded; // was this artwork downloaded by iTunes?
@property (copy, readonly) NSNumber *format; // the data format for this piece of artwork
@property NSInteger kind; // kind or purpose of this piece of artwork
@end
Alors oui ca déroute encore finalement car c'est de l'Objective-C 2.0 ... mais ca c'est une autre histoire, ca reste quand même lisible pour les maniaques du vieil ObjC...
Je n'ai absolument pas ajouté de commentaire. sdp ajoute les commentaires lui-meme, en fonction du "dictionnaire" AppleScript. C'est très fort, on dirait que cela a été écrit par un ingénieur chez Apple :-D
La prochaine fois je tenterai d'expliquer comment on utilise ces classes dans un monde Objective-C "ponté".
|