Productivité Performance Mobilité

Productivité Performance Mobilité

édito Visual Studio : de 2013 à 2015 Visual Studio a 20 ans! La première «version» date de 1995. Depuis, nous avons connu 10 versions majeures, la dernière étant Visual Studio 2015, dévoilée en automne 2014. Visual Studio a toujours accompagné le développeur, supporté les nouveaux Windows et les évolutions techniques et technologiques. Que de changements en 20 ans et pas seulement sur l ergonomie et l interface! Visual Studio 2015 (VS2015) est un concentré de nouveautés et d évolutions : nouveau framework.net, nouvelle architecture de compilation, nouveau ASP.Net VS2015 sera le compagnon idéal pour développer des applications Windows 10. Visual Studio sera, plus que jamais, tourné vers le développement mobile et le Cloud Computing (développement Azure et intégration avec Visual Studio Online). Dans ce livre blanc, nous avons voulu mettre l accent sur Mobile First, Cloud First et comment VS2015 améliore la productivité du développement et le confort de programmation au quotidien. VS2015 apporte de nombreuses nouveautés et améliorations pour le développeur : Intellisense, refactoring, tooltips, Code Analysis, Code Lens, Code Map, Smart Unit Tests, NuGet, Extensibilité Plus que jamais, Visual Studio chouchoute le développeur! Autre point fort de VS2015 : le développement multiplateforme mobile, que ce soit en natif ou en JavaScript/HTML/CSS. Et VS2015 laisse le choix : C++, Apache Cordova, Xamarin. Le développeur peut développer rapidement ses apps pour Android, ios et Windows. Mobile First n est pas que du marketing, c est une réalité! Dans ce livre blanc, d autres aspects de Visual Studio sont abordés : comment faire des builds dans le Cloud, utiliser les puissantes fonctions de Release Management, monter des scénarios de Load Testing (dans le Cloud), et découvrir la puissance, parfois insoupçonnée, du Hub and Diagnostics de Visual Studio 2013. Sommaire Build avec Visual Studio Online 3 Load Testing 4 Orchestrez vos déploiements avec Release Management 6 Visual Studio et la mobilité 8 Boostez votre productivité avec Visual Studio 2015 13 Debugging & performances 17 Visual Studio 2015 20 DevOps, Dev/Tests 21 MSDN Platforms 22 Ressources 23 François Tonic éditeur & rédacteur en chef de Programmez! Réalisation : NEFER-IT / Programmez!. Siège social : 7 avenue Roger Chambonnet 91220 Brétigny sur Orge. Directeur de la publication / rédacteur en chef : François Tonic Coordination Microsoft : Evlampia Thoreau - Maquette : Pierre Sandré - Relecture : Olivier Pavie - Imprimé en France. Février 2015. - Photos et illustrations tous droits réservés. 2

Build avec Visual Studio Online Build dans le Cloud Le processus de build est un élément important dans la vie d un projet. En effet dans une intégration continue, il permet de valider que le code source compile suite à chaque modification. En exécutant les tests, il est aussi le garant qu aucune régression n est introduite. Enfin il fournit un processus commun de génération des binaires et peut aussi assurer leur déploiement sur un environnement de développement, d intégration ou encore de production. C est donc un élément majeur du cycle de vie d une application. Pierre-Henri Gache Consultant senior chez Cellenza Cellenza - Software Development Done Right Blog : http://www.pierrehenrigache.com/ Michel Perfetti Consultant senior chez Cellenza MVP VS ALM Blog : http://www.buildmeimfamous.net Twitter : @miiitch Comment créer un build La première étape consiste à se diriger vers la rubrique «Builds» du «Team Explorer» de Visual Studio. Si vous avez déjà créé des builds avec TFS, le processus est identique Fig.1. Dans cette section du «Team Explorer», vous pouvez créer votre build via le bouton «New Build Definition». Ce dernier déclenchera l ouverture de l écran de configuration qui regroupe plusieurs onglets et vous permettra de paramétrer les différentes options du build. Les deux plus importants sont «Trigger» et «Process». Le premier permet de configurer la manière dont sera déclenché le build : de façon manuelle, lors de chaque check-in ou encore à un horaire déterminé par exemple. Le second quant à lui contient le paramétrage du processus de génération. Pour terminer la création, il suffit de sauvegarder le paramétrage par défaut et vous aurez alors un build manuel qui compilera votre projet et exécutera les différents tests disponibles. Pour aller plus loin, vous pouvez customiser les différents paramétrages disponibles. Pour des besoins spécifiques, vous pouvez également éditer le template de build. Vous aurez alors accès au workflow complet qui sera exécuté Fig.2. Limitations par rapport à TFS Le contrôleur de Build étant hébergé dans le Cloud, il n est pas possible de le configurer ni d avoir accès à la machine l hébergeant. De ce fait découle un certain nombre de contraintes qu il faut avoir à l esprit. Par exemple le processus de build ne pourra pas utiliser un logiciel autre que ceux installés par défaut. Ensuite le build ne devra pas excéder une heure et occuper plus de 75 Go. Enfin il ne devra pas avoir besoin des privilèges administrateurs ni être en mode interactif. Concernant le premier point, vous pouvez retrouver la liste des outils préinstallés à l adresse suivante : http://goo.gl/johe4d. Si toutefois vous rencontriez une de ces contraintes, la meilleure solution est d utiliser un contrôleur local pour les build en question, les autres pouvant être hébergés dans le Cloud séparément. Déploiement sur Azure Dans le cadre d un développement se destinant à être hébergé sur Azure, vous avez la possibilité de configurer le déploiement automatique de votre site lors de chaque check-in. Pour cela il suffit de se rendre sur la page de votre «Website» du portail Azure. Sur cette dernière vous retrouverez l option «Integrate source control». Cette dernière vous permet d associer votre «Team Project» au «Website» Fig.3. Lorsque l association sera effectuée, vous pourrez constater qu un nouveau build est disponible dans Visual Studio. Pour terminer le processus, il faut aller sur l onglet «General» pour activer le build. Ensuite, dans l onglet «Process» il faut paramétrer le chemin du «sln» correspondant à votre projet et terminer en enregistrant la configuration Fig.4. Maintenant lors de chaque commit, un build sera déclenché et votre site sera compilé et déployé sur votre «Website». Build vnext Le build de TFS n a quasiment pas évolué depuis TFS 2010 : le build est un processus sensible qui se prête mal à de grosses évolutions à chaque version de TFS. La migration de tous les builds pourrait être un frein à la migration. Brian Harry a annoncé lors de la conférence Connect de novembre 2014 une révolution : le système de build va changer pour s adapter aux nouveaux défis du développement d application moderne : Cloud & Cross Platform. De plus cette nouvelle version qui fonctionnera en parallèle de la version courante aura les avantages suivants : u Plus besoin de Visual Studio pour éditer les builds, u Historique des modifications, u L architecture des contrôleurs/agents a été assouplie, u Plus de Workflow Foundation! Conclusion Le build est la première étape dans le processus d industrialisation et d automatisation de vos développements, donc ne la négligez pas. Testez les différents modes de déclenchement, déployez en staging, activez les tests : toutes ces fonctionnalités vous feront gagner du temps et en qualité. p Fig.3 Fig.1 Fig.2 Fig.4 3

Load testing dans le Cloud Load testing, indispensable Dans un monde hyper connecté où les sites Web et autres Apps sont notre quotidien, tester les performances de ces derniers que ce soit avant une release ou bien régulièrement pendant le cycle de vie de l application devient indispensable. Une telle démarche permet de mesurer la rapidité d exécution du code implémenté (performance Testing), son comportement face à la charge utilisateur attendue (Load Testing), le point de rupture de l application en termes de charge utilisateur (Stress Testing) et enfin, identifier dans quelle mesure l application sera scalable pour supporter la charge future (Capacity Planning). Fig.2 Fig.1 Michel Hubert, Manager Pôle Cloud & Integration, MVP Azure, Cellenza Radoine Douhou, Architecte, Cellenza mais dans la pratique, difficile à construire En pratique, mettre en place la solution de tests adéquate peut s avérer complexe. L infrastructure hébergeant la solution de test doit être suffisamment performante pour pouvoir supporter la charge produite par les injecteurs de stress, ces derniers devront être suffisamment paramétrables pour proposer plusieurs types de scénarios de test, etc. Difficile de justifier de tels investissements (en temps et en argent) pour une solution dont l usage et la valeur ajoutée peuvent apparaître peu évidents pour des décideurs loin de l IT. Cloud load testing avec VSO, la solution Pour faire face à cette problématique, Visual Studio (depuis la version 2013 Ultimate) et Visual Studio Online (VSO) proposent une solution de test basée sur la plateforme Azure nommée Web Performance and Load Test. Cette solution est la réponse aux peines communément rencontrées lorsque l on fait du testing : u Plus besoin de construire et maintenir l infrastructure hébergeant la solution. VSO provisionne automatiquement l infrastructure le temps du test, ce qui impacte de façon très bénéfique votre TCO. u Plus de problème de scalabilité liée aux limites de l infrastructure et de la technologie de test, VSO provisionne automatiquement le nombre d injecteurs nécessaire pour pouvoir exécuter vos stress test. u Le même «script de test» que vous pouvez exécuter dans le Cloud Azure ou à demeure en fonction de vos contraintes d accessibilité à l application Web à tester. Comment ça marche? Comme le montre le schéma de la Fig.1, le projet «Load Test» implémenté dans Visual Studio 2013 Ultimate peut être publié dans votre souscription VSO, lequel tire profit de l infrastructure Cloud Azure pour provisionner les agents nécessaires à l exécution dans les conditions adéquates du scénario de test. Ces agents sont chargés de requêter l application Web alors que le Controller collecte et stocke les métriques d exécution. Une fois le test terminé, les résultats peuvent être téléchargés et visionnés dans Visual Studio ou bien dans Excel. Prenons un exemple Avant de démarrer un load test, il faut créer un projet «Web Performance and Load Test», à partir du menu «File/New Project». Après avoir créé vos tests Web, par enregistrement par exemple d un parcours Web, ajoutez un test de charge (Fig.2.) : Clic droit sur le projet, sélectionnez Add puis Load Test et suivez les directions de l assistant «Load Test» pour définir un certain nombre de paramètres comme le nombre d utilisateurs, la durée du test, le temps de «warm up», le test mix entre les différents Web tests, la répartition entre les profils de navigateurs, les bandes passantes, tout cela en fonction de votre cible. Azure, à toi de jouer Typiquement, tout commence à présent. À ce stade, l équipe de tests a besoin d une infrastructure pour lancer les tests. Plusieurs options lui sont offertes : soit elle utilise un infra on-premise, soit elle déploie des Test Agents et un Test controller dans Azure (IaaS), soit elle peut opter pour VSO Load Testing, une solution en mode SaaS de tests de charge. Pour ce faire, il faut créer un nouveau fichier «TestingSettings» et sélectionner l option «Visual Studio Online». Par défaut, les tests de charge en mode Cloud vont automatiquement démarrer un agent hébergé dans Azure tous les 500 utilisateurs. Chaque agent possède 4

Load testing dans le Cloud deux cœurs. Il est possible de modifier ce comportement avec la propriété du «RunSettings» nommée «Agent Count (Total Cores)». La version actuelle vous limite à un maximum de 10 agents ou 20 cœurs. Les tests de charge en mode Cloud requièrent également au minimum 25 utilisateurs par cœur. Ainsi si vous souhaitez 10 cœurs pour 10 utilisateurs, il ne vous sera alloué qu un agent. En lançant le test, Visual Studio vous indique le nombre réel de cœurs utilisés, mais surtout le nombre de virtual users/minutes vous permettant ainsi de connaître le coût de votre test. En effet, l unité d œuvre utilisée pour mesurer la consommation est la minute d utilisateur virtuel qui correspond au nombre d utilisateurs virtuel simulé par les agents multiplié par le temps du test. Si les agents simulent 10 utilisateurs par seconde pendant 1 minute, nous consommerons 600 utilisateurs virtuels/minutes. Visual Studio Online offre 20 000 utilisateurs virtuels/minute par mois. Au-delà de ce seuil, il vous sera facturé 0,0015 l utilisateur virtuel/minute. Un coût somme toute négligeable par rapport à l importance de ce type de tests et par rapport à une infrastructure dédiée on-premise. Données dynamiques Certes, des tests Web statiques vous donnent des informations détaillées sur la performance de vos applications, mais des tests Web dynamiques (plus proche de la réalité) vous donneront des informations plus précieuses. Par exemple, au lieu d envoyer en permanence l id 1000 pour afficher une page produit, il fait sens d utiliser différents id pendant l exécution d un test. Vous pouvez le faire avec une Fig.3 technique avancée appelée Data Binding. Pour associer des données à un test Web, vous devez tout d abord ajouter une source de données à votre test Web via la barre d outils. Les datas sources supportées sont des fichiers XML, CSV et des bases de données. Les fichiers XML et CSV sont copiés sur les machines virtuelles des agents. Donc pour les tests de charge en mode Cloud, les agents doivent être en mesure de se connecter à la source de données. Par conséquent, les sources de données de type base de données doivent reposer sur Azure SQL Database. Les propriétés de votre data source vont indiquer comment les tests vont parcourir les données : Do Not Move, Random, Sequential ou Unique. Cette dernière option n est pas compatible avec VSO. Pour finir, après avoir ajouté votre source de données, les valeurs de vos paramètres qui remplacent les chaînes de caractères fixes deviennent des listes déroulantes afin de les faire correspondre avec une colonne de votre source de données. Comprendre les tests de charge Les principales questions que vous vous posez lors d un test de charge sont les suivantes : u Est-ce que mon application est aussi performante qu attendu? u Est-ce que ma performance va se dégrader pendant les tests de charge? u Est-ce que mon code va générer des erreurs pendant les tests? Pour répondre à ces questions, Visual Studio fournit plusieurs types de rapports. Il va automatiquement les stocker avec les données d exécution à la fois pour vous et votre équipe dans VSO. Par exemple, grâce au rapport «Throughput», le graphique (Fig.3.) vous montre l exécution du test de charge et vous êtes capable en un coup d œil de vérifier le bon comportement ou non de votre application. Si des temps de réponse rapides sont couplés avec un nombre inattendu d erreurs, vous savez tout de suite qu il y a un service défaillant et vous pouvez stopper à tout moment votre test. Un autre aspect intéressant est la possibilité de travailler dans un environnement collaboratif. Les équipes agiles sont particulièrement intéressées par l impact sur la performance du sprint en cours. Pour y répondre, Visual Studio fournit deux rapports basés sur Excel qui vont vous aider à comparer deux tests et à examiner les tendances. Pour cela, téléchargez les données de VSO, cliquez sur le lien «View Report». Cela ouvrira une vue sur vos données incluant l option d ouvrir et de comparer vos jeux de tests dans Excel. Application Insights Les erreurs découvertes lors d un test de charge doivent être couplées à des techniques de collection de diagnostics. La plupart du temps il est difficile de diagnostiquer ces erreurs à cause d éléments de trace et de logs insuffisants ou incomplets. Depuis l update 2 de Visual Studio, il est possible d intégrer Application Insights avec vos tests de charge. Cette intégration avec un outil de monitoring digne de ce nom permet de tester des applications durant toutes les phases d un projet, du développement à la production. Cet outil permet aux équipes projet de trouver facilement les erreurs indépendamment du moment où elles ont été trouvées même si l erreur s est produite une semaine auparavant. Pour inclure les informations de diagnostics et de performance à vos tests de charge avec Application Insights, clic droit sur le nœud «Applications» de votre définition de tests. Ensuite, sélectionnez les composants d application insights que vous souhaitez inclure dans vos rapports de tests de charge. Conclusion VSO nous facilite la mise en œuvre de tests de montée en charge grâce à la puissance du Cloud Azure vous permettant de tester au plus tôt le comportement de votre application lors de pics de charge prévisibles ou non. Plus d excuses pour ne pas inclure cette typologie de tests dans votre démarche ALM /DevOps. Pour finir, Microsoft a mis à disposition récemment des REST APIs qui vous permettent également d automatiser l exécution de ces tests. p 5

Release Management Orchestrez vos déploiements avec Release Management Gagner en fiabilité et en efficacité lors des déploiements est devenu un point fondamental dans la réussite d un projet informatique. Pour ce faire, les méthodologies sont souvent à adapter, et l aide d outils est parfois nécessaire. La réponse de Microsoft à cette problématique est Release Management! Ce dernier permet d orchestrer facilement et efficacement le cycle de déploiement de n importe quelle application. Jérémy LANDON Consultant ALM - Infinite Square Pourquoi s outiller devient indispensable pour le déploiement? Parce qu une application peut être multienvironnements, avec de nombreux critères de validation et de nombreux intervenants : u Les besoins de backup de l intégration sont nettement inférieurs à ceux de la production, u L environnement d intégration ne sera basé que sur une seule machine, contrairement aux autres qui nécessitent un environnement plus riche, u Un système permettant de garder la continuité du service de l application doit potentiellement être mis en place lors de la migration sur la production, etc. Chaque étape du déploiement a son propre workflow, ses propres critères de validation et ses propres validateurs. Bref, sans une bonne organisation, cela peut devenir extrêmement complexe et anarchique. C est d autant plus vrai lorsque l on désire mettre en place du déploiement continu. En effet, la gestion du déploiement de l application est bien souvent chronophage et nécessite l intervention de nombreux acteurs. De plus cette tâche est risquée, stressante et conflictuelle. Chaque intervenant travaille en silo, suit sa propre procédure, et mobilise tous ses efforts dans cet instant où tout échec entraîne une perte de temps et de ressources. La conclusion est simple, un déploiement coûte cher, est très risqué, et demande une très bonne organisation. Un orchestrateur devient vite indispensable pour fournir un déploiement stable, modulable et évolutif. Microsoft propose depuis 2013 sa solution qui a l avantage d avoir, tout comme Visual Studio, un cycle de développement très court. Tous les trimestres, de nouvelles fonctionnalités sont livrées sur Release Management. L outil est compatible avec Team Foundation Server 2010, 2012, 2013 et Visual Studio Online! Comme sait le faire Microsoft, ces fonctionnalités s intègrent parfaitement avec les autres outils de la compagnie. Microsoft mise énormément sur cet outil et les évolutions ne cesseront d arriver. C est aujourd hui une valeur sûre pour améliorer efficacement la fluidité du déploiement des applications. Avec Release Management il est aisé d adapter son processus de déploiement en Fig.2 Fig.1 fonction de l environnement cible (backup, chaînes de connexions, plateforme de déploiement, etc.). L un des buts étant d automatiser au maximum le processus de déploiement afin de gagner en productivité et en fiabilité. La solution est décomposée en trois modules distincts à savoir : u L agent de déploiement est un service à installer sur les serveurs cibles. Il permet de réaliser un déploiement sur ceux-ci depuis une machine distante. Par contre, il est facultatif! En effet Release Management propose deux façons pour déployer : via l agent ou via du WinRM (Powershell DSC), cette dernière est nommée VNext. Fig.4 Fig.3 6

Release Management u Un client WPF pour administrer le serveur Release Management et modéliser et configurer les chaînes de déploiement. u Un serveur Release Management, comprenant une base de données SQL et exposant différents services utilisés par les autres composants. Comme pour l agent, il est facultatif, en effet Microsoft propose Release Management en mode SaaS via Visual Studio Online, c est ce dernier qui fera office de serveur Release Management dans le cloud.. Chaque module étant indépendant, la solution de Microsoft offre l avantage d être flexible, et ces deux modes de déploiement permettent d offrir une solution adaptée à tous. De plus Release Management offre à disposition des utilisateurs différents outils pour aider à la mise en place d un déploiement (installer ou désinstaller des composants, interagir avec SQL Server, déployer des rapports dans Microsoft SQL Reporting Services, gérer les fichiers, interagir avec Azure ). Des outils sont fournis par défaut, mais ils sont facilement extensibles, cette souplesse offre des possibilités infinies à l outil. Quelles applications profitent au mieux de Release Management? Toute application a besoin d assurer la qualité de son déploiement, de ce fait Release Management s applique à tous les types applications hébergés dans Team Foundation Server ou Visual Studio Online. Comment Release Management fonctionne-t-il? Le principe de Release Management est simple et part d une logique adaptée au déploiement d application; afin d assurer l intégrité d une application, chaque environnement utilisera les mêmes binaires. Le processus est donc : u Team Foundation Build génère l application et place le résultat dans un drop, u Les binaires de ce drop sont fournis totalement, ou en partie, à chacun des environnements, en fonction de ses besoins Fig.1. Les mêmes binaires, donc le même applicatif! La gestion des environnements est totalement gérée grâce à Release Management, et cette tâche, bien souvent difficile, est simplifiée. Comme évoqué précédemment, Release Management propose deux modes de déploiements : u Basé sur les agents de déploiement, u VNext (WinRM). Pour le premier mode, il suffit d installer l agent de déploiement sur la machine de destination. Lors de la configuration de celui-ci, il suffit d entrer l adresse du serveur Release Management : Fig.2. Release Management possède également une très bonne intégration avec Azure. La plateforme Cloud de Microsoft offre de nombreux avantages : flexibilité, coût, rapidité et stabilité. Configurer un serveur par agent est simple, en passant par Azure la tâche est encore plus simple! L outil va se baser sur un compte de stockage Azure, il suffira de fournir la certification de la souscription, le nom de stockage Azure et la clé de souscription. Une fois cette configuration réalisée, Release Management pourra détecter et utiliser les machines virtuelles Fig.3. La notion d environnement est très flexible et aisée à mettre en place dans Release Management; il est d autant plus simple de créer un workflow de déploiement. Release Management offre la possibilité de définir un environnement par étape, et de définir les règles d acceptation de chacune de ces étapes; il est aussi possible d y assigner un utilisateur ou un groupe (issu de Team Foundation Server ou Active Directory). Ces derniers devront valider les différentes phases du déploiement. Le déploiement d un applicatif sur un environnement est composé de 4 phases : u L étape d acceptation : permet d approuver ou rejeter la phase de déploiement [peut être automatisée], u L étape de déploiement : phase durant laquelle l application se déploie, u L étape de validation : phase durant laquelle un utilisateur ou un groupe d utilisateurs valide l applicatif déployé [avec Microsoft Test manager par exemple pour la recette], u L étape d approbation : dernière phase. Assignée la plupart du temps à une personne [mais il est possible de l affecter à plusieurs intervenants], elle permet de valider complètement le déploiement sur l environnement et donne la main à l étape suivante dans le workflow Fig.4. Release Management offre donc une grande flexibilité dans la réalisation de la chaîne de déploiement. Ne reste plus que la dernière phase : la mise en place du workflow de déploiement par environnement. Comme évoqué précédemment Release Management propose deux solutions : l'une basée par agent et l'autre sur VNext. Avec la première solution, Release Management propose une série d outils d aide au déploiement sous forme d actions, d une manière semblable à ceux offerts lors de la réalisation de process de build pour Team Foundation Build [déploiement de DacPac, copie de fichier, Rollback ]. Dans le mode VNext, il sera possible d utiliser un script PowerShell de déploiement ainsi que DSC pour configurer l environnement Fig.5. Au-delà de la technique, Release Management offre, sous forme d un Web access, une interface simple et à la portée de tous pour gérer les approbations des environnements Fig.6. Conclusion Le Release Management est un point important dans la réalisation d un logiciel, au-delà de la méthodologie un bon outillage peut apporter une énorme plus-value. Microsoft fourni avec Release Management un outil simple, flexible et surtout suivi pour aider dans la gestion de déploiement d applications. Enfin le plus gros avantage : que ce soit par Release Management On Premise ou par son homologue Release Management as a Service accessible via Visual Studio Online, mettre en place la solution de Microsoft demande un faible investissement tout en offrant un bénéfice immédiat et durable. p Fig.5 Fig.6 7

Mobilité Visual Studio et la mobilité : quoi de neuf dans la version 2015? Lorsque l on souhaite créer une application à destination des stores mobiles, il est souvent nécessaire de devoir cibler les trois plateformes majeures : Android, ios et Windows Phone. Cela implique de devoir développer trois applications, avec trois langages différents, sur trois plateformes différentes. Chaque nouvelle version de l application nécessite une mise à jour des trois développements, chaque correction de bug nécessitant également de repasser sur les trois plateformes. Sebastien Ollivier, Kevin Albrecht, Arezki Saba, Maxime Frappat, Jonathan Antoine Consultants, Infinite Square Plusieurs outils permettent de répondre à cette problématique de développement et Microsoft a décidé de prendre le problème à bras le corps en les intégrant dans Visual Studio. Dans cet article, nous étudierons notamment Apache Cordova, les possibilités de développement en C++ dans la version 2015 de Visual Studio, ainsi que les possibilités offertes par Xamarin. Apache Cordova Apache Cordova est un Framework opensource développé par la fondation Apache, permettant de créer des applications mobiles cross-plateformes en utilisant les langages HTML / CSS / JavaScript. L idée est de pouvoir cibler toutes les plateformes mobiles majeures en développant une seule application et en s émancipant des langages natifs comme Java, C#, Objective-C, ou autre, pour pouvoir interagir avec le device. Apache Cordova met à disposition un ensemble d API JavaScript permettant d accéder aux fonctionnalités natives. Comment cela fonctionne? Le principe Le principe d une application Cordova est de développer une application Web, en HTML / CSS / JavaScript, et de la packager sous la forme d une application native. Pour que le rendu de l application Web s adapte à tous les devices, il est nécessaire de développer une application Web responsive, par exemple à l aide du Framework CSS Bootstrap. Pour proposer un rendu plus fini, il est également recommandé de créer une application Web de type Single Page Application (SPA), par exemple à l aide des Fig.1 Fig.2 Frameworks AngularJS ou KnockoutJS. L idée est donc ici d avoir un seul code métier et un design unique sur toutes les plateformes Fig.1. Techniquement, le principe du Framework Cordova est de créer une application native composée uniquement d un composant WebView, propre à la plateforme ciblée. Ce composant WebView naviguera simplement sur l application Web, dont les fichiers (HTML, CSS, JavaScript, font, images, etc.) auront été embarqués en tant que ressources locales de l application native Fig.2. Accès aux fonctionnalités du device Pour pouvoir accéder aux fonctionnalités natives du téléphone, l application ainsi développée va pouvoir s appuyer sur les plugins Cordova. Un plugin Cordova permet d exposer une fonctionnalité native du device via une API JavaScript, qui sera utilisable depuis l application Web. Le rôle du plugin est alors de faire le lien entre l appel JavaScript et l exécution du code natif, en fournissant une implémentation par plateforme. L interface JavaScript étant la même pour chaque plateforme, l utilisation d un plugin se fait de manière identique, quelle que soit la cible. Par exemple, l accès aux contacts du téléphone se fait en utilisant le plugin «Contacts», qui expose les fonctions create, find et pickcontact, permettant respectivement de créer un contact, de rechercher un contact et d afficher un composant natif de sélection d un contact. Apache Cordova met à disposition un ensemble de plugins permettant d accéder aux fonctionnalités basiques du device, comme les notifications, la caméra, les contacts, l accéléromètre, etc. D autres acteurs ont également créé des plugins, y compris Microsoft via sa filiale «Microsoft Open Technology», avec notamment un connecteur Cordova pour Azure Mobile Services, disponible pour les plateformes Windows 8, Windows Phone 8 mais aussi ios et Android. Apache Cordova s appuie également sur une communauté active pour développer de nombreux plugins, majoritairement sur GitHub, comme un scanneur de code barre 8