Les ANE ou Actionscript Native Extensions
Depuis Flash Builder, il est possible d’intégrer des applications natives sur les supports « nomades ». Malheureusement, ceux-ci ne peuvent accéder à certaines fonctionnalités spécifiques comme la vibration ou la notification. Depuis la version 4.6 de Flash Builder (et donc de Flex), il est possible d’intégrer très facilement des bibliothèques, les ANE (Actionscript Native Extensions) qui sont des ponts vers ces fonctionnalités, utilisables directement en actionscript.
L’utilité des extensions natives
Cela permet d’utiliser des fonctionnalités spécifiques qui ne sont accessibles qu’en programmant en code natif, c’est-à-dire en ObjectiveC pour iOS ou en Java pour Android. En utilisant seulement de l’actionscript, nous sommes donc limités à l’utilisation de la bibliothèque existante.
Par exemple, AIR n’intègre pas la possibilité d’utiliser la vibration en natif. C’est là où ces extensions deviennent très intéressantes. Puisqu’en intégrant la bibliothèque correspondante, un simple appel en actionscript permet son utilisation. Il n’y a donc plus aucune limitation, si ce n’est le temps de voir fleurir sur le net ces extensions. Vous pouvez les retrouver à cette adresse : http://www.adobe.com/devnet/air/native-extensions-for-air.html.
La documentation, en anglais (je ne sais pas si une version française est prévue), permet de se lancer dans le développement de ces extensions. Si vous êtes familier avec l’ObjectiveC ou le Java, vous pourrez très facilement créer vos propres extensions natives et les intégrer dans vos projets AIR. Vous pourrez participer avec la communauté à agrandir cette liste. On peut déjà voir par exemple une extension qui utilise le Kinect.
Les extensions natives ne se limitent pas à Android ou iOs. Bien évidemment, vous pourrez développer des extensions pour tous les supports qui vous semble intéressants et qui ne sont pas compris dans la bibliothèque de base de AIR. On imagine bien le potentiel de ces extensions.
Ce qu’il faut savoir
Pour le moment, les extensions natives sont utilisables sur :
- Android 2.2
- iOS 4/5
- PlayBook
- Les supports bureautiques qui disposent de AIR 3
- Les supports TV qui disposent de AIR 2.5
Il est possible d’empaqueter plusieurs bibliothèques natives dans une seule extension. De ce fait, un seul code source, pour faire vibrer par exemple le téléphone, sera utilisé quelque soit le support sur lequel il est déployé.
Les implications
Pour l’entreprise prestataire
Cela peut avoir une réelle incidence pour le service de développement. Aussi bien en terme d’organisation qu’en terme financier (positif).
En imaginant un prestataire qui serait capable d’intégrer sur tous les supports existants de manière native, nous pourrions voir l’organisation de celui-ci évoluer :
En effet, rappelons qu’utiliser AIR implique un seul code source, suivant l’évolution de la liste des ANE sur le site d’Adobe, le développeur ANE pourrait s’investir pleinement dans le développement Actionscript. Il faut savoir également que celui-ci n’a pas besoin d’être un expert des différents langages (même si c’est un avantage).
Bien sûr, cet exemple est un cas extrême qui n’existe (sans doute) pas. Ne nous leurrons pas, les principaux développements effectués seront sur iOS et Android, même si la demande client pour apparaître sur tous les supports est bien présente.
Pour le client
C’est la possibilité d’apparaître sur tous les supports, avec des frais supplémentaires minimum.
Même si le développement est équivalent d’un smartphone à l’autre, cela ne sera pas le cas d’un smartphone à une tablette, ou encore le bureau sous Windows ou Mac. L’environnement sur lequel tournera l’application, l’interface utilisateur donc, sera la contrainte à gérer suivant le support. La présentation changera, mais le code source et les objets resteront identiques.
Le problème ne sera plus la gestion d’un code multiplateforme, mais bien de la gestion d’un code « multisupport ». Ce qui impliquera une très légère augmentation du prix de développement si le client souhaite apparaître sur plusieurs supports différents.
Les évolutions
Avec les extensions natives, on accède à toutes les fonctionnalités des supports. Mais pourquoi se limiter à Flash alors que le HTML est censé être la référence ?
Tout simplement parce que HTML n’est pas encore prêt pour remplacer Flash, il lui manque encore quelques éléments pour garantir l’expérience utilisateur qu’il ne peut pas encore satisfaire aujourd’hui. Si le but est de la présentation simple, oui, privilégiez l’utilisation de l’HTML. Si votre souhait est une application plus fournie, avec de la gestion temps réel, des jeux ou toutes activités ludiques avancées, privilégiez l’utilisation de Flash.
D’ici 5 ans, la transition que va effectuer Adobe, avec la possibilité d’exporter directement en HTML depuis le code source de Flash Builder, est une raison supplémentaire de poursuivre l’aventure avec Flash.
Il est possible d’empaqueter plusieurs bibliothèques natives dans une seule extension. De ce fait, UN SEUL CODE SOURCE, pour faire vibrer par exemple le téléphone, sera utilisé quelque soit le support sur lequel il est déployé.
Non avec une seule extension plutôt (et avec plusieurs codes sources dedans : C# pour plateformes Microsoft, Java pour Android, ObjectiveC iOS).
Oui exact, c’est exactement ce que je voulais écrire mais j’ai dû mal faire passer le message à première vue.