Archive

Articles taggués ‘phonegap’

Pourquoi choisir Xamarin pour votre stratégie Mobile

Voici une présentation de Xamarin et de ce qui en fait un choix pertinent pour vos développements multiplateformes.

Lire la suite…

Formation architectures mobiles : principes et implémentation

Définir une architecture mobile nécessite, d’une part, de prendre en compte la pluralité des plates-formes mobiles dans les choix techniques afin de maîtriser les coûts de réalisation et de maintenance, d’autre part à concevoir finement la couche de médiation entre l’application mobile et le système d’information de l’entreprise.

Objet Direct propose une formation Architectures Mobiles du 2 au 4 octobre à Toulouse !

Cette formation présente les concepts et les bonnes pratiques indispensables pour :

  • Définir une architecture REST : centrée sur les données, sans état, scalable et sécurisée,
  • Cibler les principales plates-formes mobiles (Apple, Android, Windows Phone, BlackBerry) avec un unique développement HTML5 / PhoneGap,
  • Intégrer les exigences techniques : push, mode déconnecté, débit réseau souvent limité,
  • Exploiter les fonctionnalités mobiles : GPS, gestes, orientation, caméra, etc,
  • Publier les applications mobiles : interne à l’entreprise ou grand public (markets).

Programme complet et inscription sur notre site : http://www.objetdirect.com/formation/architectures-mobiles-principes-et-implementation

Formation HTML5 et PhoneGap : Développement Web Mobile

Objet Direct propose une formation HTML5 et PhoneGap du 17 au 19 juin à Toulouse !

Cette formation vous permettra d’assimiler et de maîtriser les points suivants :

  • Les fonctionnalités mobiles prises en charge (GPS, gestes, orientation, caméra, …),
  • La compatibilité des téléphones et tablettes avec HTML5 et PhoneGap,
  • Les cas d’usage optimaux de cette solution,
  • Le packaging d’applications natives avec PhoneGap,
  • La conception de plugin pour PhoneGap,
  • La conception d’interfaces mobiles (IHM) avec jQuery Mobile,
  • Les stratégies alternatives pour créer des applications multi-plateformes.

Programme complet et inscription sur notre site : http://www.objetdirect.com/formation/html5-et-phonegap-developpement-web-mobile

Human Talks Grenoble, c’était hier soir !

Hier soir, le 12 février 2013, les Human Talks se sont déroulés au sein des locaux de Col’Inn à Grenoble.

Comme d’habitude, de nombreuses personnes se sont rassemblés pour voir des présentations fortes intéressantes:

  • « Chiffrement symétrique / asymétrique et HTTPS », par Philippe Le Van
  • « NoSql, comment choisir ? », par Rémi Alvado
  • « h-ubu: modulariser votre JavaScript », par Clément Escoffier
  • « Play framework (V1) : simplicité et productivité au service du développement WEB en Java », par Xavier Nopre

Et enfin, il y avait aussi ma présentation: « PhoneGap, ou la programmation Web Mobile hybride à porter de main ».

Vous pouvez consulter les slides de ces présentations sur ce lien et n’oubliez pas: la prochaine session, c’est le mardi 12 mars ! Alors n’hésitez pas à venir et aussi proposer des sujets de talks !

Programmez: deux nouveaux articles au sein du magazine

Bonjour,

Le mois de Février a été riche, car nous avons pu constater la publication de deux articles dans le magazine mensuel « Programmez » qui viennent d’Objet Direct.

Le premier s’intitule « Créer un plugin PhoneGap, un jeu d’enfant« . Il montre que PhoneGap, la solution permettant de créer des applications Web mobile hybride, a été pensé dès le départ pour qu’il puisse gérer des plugins. Autrement dit, que nous puissions nous créer nos propres plugins si nécessaire. Pour le démontrer, l’article montre un exemple où nous voulons envoyer un SMS. Nous faisons alors étape par étape la réalisation du plugin, qui fonctionnera sous Android et sous Windows Phone 7.

Le second s’intitule « CSS3, la nouvelle donne« . Cet article tend à montrer qu’il est temps d’utiliser CSS3 dans nos sites Web, et aussi de remettre en cause la façon dont nous les développons. L’apparition d’Ajax a bouleversé la façon de concevoir nos sites. CSS3 nous amène peu ou prou la même chose.

Si vous avez un magazine Programmez à porter de main, et que vous voulez lire les articles n’hésitez pas !

Bonne journée à tous !

Notre premier plugin PhoneGap sur PhoneGap-Plugins

Bonjour,

Il y a quelques temps, nous avions écris un petit billet afin de signaler la présence sur notre repository Github, nous avions placer un plugin pour PhoneGap-Android afin de pouvoir interagir avec les applications de tweets: https://github.com/ObjetDirect/phonegap-plugins/tree/master/Android/Twitter

 

Désormais, ce plugin est officiellement intégré dans le repository Github de PhoneGap-Plugins (https://github.com/phonegap/phonegap-plugins/tree/master/), qui est un repository référençant les plugins PhoneGap (et gérer par les gens de chez PhoneGap). Vous pourrez le trouver sur le lien suivant: https://github.com/phonegap/phonegap-plugins/tree/master/Android/Twitter

Objet Direct sur Github

Depuis quelques semaines déjà, Objet Direct est présent sur Github, dans le but de publier des plugins / frameworks OpenSource.

Au cours de développements en interne, lors de réalisations de prototypes, ou plus simplement lors de besoins sur nos projets, nous réaliserons des frameworks ou des plugins qui nous seront utiles par la suite, et que nous réutilisons.

Au sein d’Objet Direct, nous promouvons les solutions et les projets OpenSource. De part ce constat, nous avons décidé de publier ces frameworks / plugins afin de les rendre accessibles au plus grand nombre.

Si vous vous rendez sur notre repository Github (https://github.com/ObjetDirect), vous aurez à l’heure actuelle trois plugins:

Nous vous tiendrons informé des futures évolutions et ajouts.

Bien cordialement.

Categories: Divers, Mobile Tags: , , , ,

Mix It, fin d’après-midi

Phone Gap (Pamela Fox)

Pamela Fox@pamelafox
“ I hate the Android browser. I even prefer IE6 ”

Autant enchainer les présentations en anglais. Après Petra Cross, c’était au tour de Pamela Fox, ex Googleuse et même ex Google Advocate, avec son look si… particulier (les chaussures… J’ai adoré! ), mais surtout une énergie et un enthousiasme impressionnants. Pour l’anecdote, Petra est venue à la présentation de son ex-collègue, mais moins pour la suivre que pour prendre quelques photos, une vraie passion pour elle.

Je pensais apprendre pas mal de trucs sur Phone Gap, mais sa présentation était loin d’être axée sur ce framework. Mais je n’ai cependant absolument pas été déçu : le talk était axé sur un cas concrès : quelle a été sa démarche et ses critères de choix technologiques pour développer sa propre application mobile à utiliser pendant les repas : eat different.

Pour choisir quelles technologies elle allait utiliser pour créer son application, elle s’est notamment posé les questions suivantes :
Pour l’application : quels systèmes peuvent la faire tourner? Dois-je accéder à des couches basses du système (téléphonie, photo, GPS, etc.)? Quelle niveau de performance dois-je atteindre?
Pour l’équipe (de dev) : quels languages connait-on? Quel argent peut-on dépenser? Combien de codes source?
Elle nous a ensuite présenté les différentes familles de solutions :

Les applications écrites nativement ont tous les avantages du point de vue de l’application, mais adressent naturellement un seul système cible. Si on veut couvrir toutes les plate formes, elles cumulent donc les inconvénients pour les développeurs (languages et IDE hétérogènes, nombreux codes source, donc beaucoup de temps nécessaire)

Une autre approche est d’utiliser un framework qui va servir de source unique et permettre de compiler l’application pour plusieurs plateformes natives. Les performances restent correctes, bien que l’accès aux couches basses des téléphones soient plus limitées. Selon le framework choisi, on peut ainsi atteindre les principales plate formes du marché.

Enfin, et c’est l’approche qu’elle a finalement choisie, on peut écrire une application en HTML5 et utiliser un framework qui va servir de bridge, permettant à la fois d’accéder à certaines couches basses du téléphone, mais aussi de packager l’application web dans une application native pour chaque système : c’est ce que fait PhoneGap.

Son choix étant fait, elle nous a expliqué comment elle avait essayé plusieurs solutions et fait un petit peu son marché parmi plusieurs librairies JS et CSS. Après expérimentations, son choix s’est finalement porté sur Bootstrap et Zepto JS.

Au final, de sa propre expérience et des frameworks utilisés, Pamela a notamment apprécié le fait de ne pas avoir eu à apprendre de nouvelles technologies et donc de pouvoir réutiliser du code existant et ses propres connaissances.
Elle regrette néanmoins le temps nécessaire pour résoudre des bugs, plus long sur mobile (elle déteste notamment le navigateur d’Android), et trouve tout de même difficile avec cette approche d’avoir une IHM qui ressemble réellement à celle d’une écrite nativement.

Au final excellent talk, qui donne envie de creuser un peu tout ceci. La seconde approche me paraissait également intéressante…

Automatisation des tests : le mythe du ROI

Gilles Mantel@gmantel
“ Une minute d’indisponibilité chez un voyagiste coûte en moyenne 20 000 € ”
“ Un bug en production dans une banque de finance coûte 300 000 € ”

Et en avant pour la dernière session de la journée!  Gilles a commencé par nous résumer les différents types de tests : unitaires, d’intégration, fonctionnels, de charge, de performance, d’ergonomie, etc.
Parmi tous ces types de test, il a distingué ceux qui sont forcément automatisés, ceux qui sont forcément manuels et ceux qui sont potentiellement automatisables.

Un test automatisé a plus de chances de détecter plus tôt des bugs, mais coûte au départ plus cher à mettre en place. Pour ceux-ci, la question d’un responsable de projet va donc être : au bout de combien de temps suis je gagnant en automatisant mes tests, et donc mon ROI (Return On Investment) est-il positif?

En faisant des calculs, on peut établir une courbe montrant qu’on est “gagnant” à automatiser des tests au bout de 2-3 ans : un objectif qui peut paraitre lointain et peu motivant.

Le problème de ce calcul, pour Gilles, est qu’il n’intègre pas un coût caché pourtant indiscutable : combien coûtent les bugs? Et comment réintégrer ce coût? Pour répondre à la première question, Gilles conseille à chacun de se renseigner auprès des départements concernés (marketing, vente, etc.) pour permettre d’évaluer combien coûte un bug sur le système en production. Et en fonction du nombre de bug, ceci permet d’évaluer le coût des bugs du système.

C’est là que Gilles s’inspire du modèle des options d’achat dans le monde financier. Pour lui, la question est : combien consent-on à investir (coût de l’automatisation) pour essayer d’améliorer les choses (coût actuel des bugs), sachant que chaque bug évité découvert avec les tests correspond à un gain d’argent? Ceci donne une courbe ayant ce modèle :

L’intérêt de l’automatisation des tests dépend globalement du type de projet : un projet agile, ayant généralement 80-90% de test unitaires, 5-15% de test fonctionnels et 1-5% de tests d’interface, a moins d’intérêt à l’automatisation : on peut en effet prévoir une bonne qualité générale de code, baissant ainsi le coût qu’on est prêt à investir.

Pour des projets basés sur des cycles en V, les bugs sont généralement trouvés plus tard, et on peut avoir des projets dont les tests reposent à 80-90% sur des tests de type “End to End” à partir de l’interface, 5-15% en tests d’intégration et 0-5% de tests unitaires.
Gilles recommande sur ce type de projet de permettre d’automatiser en priorité les tests d’interface, créant ainsi un matelas de sécurité permettant de refactorer un peu le code sans prendre trop de risques, et finalement d’éventuellement constituer à terme un ensemble de tests unitaires. C’est en tout cas dans ce genre de projet que l’intérêt de l’automatisation est le plus important.

Cette vision de l’intérêt de l’automatisation m’a plû pour son orientation très pragmatique visant à permettre d’armer tout développeur à avoir un argumentaire convaincant pour pousser à l’automatisation des tests, en mettant en avant tant les gains de qualité que financiers.

Keynote finale

Pamela Fox@pamelafox
“ Teach the World to Code! ”

“Why are we here? Because we love programming!” Une bonne introduction de Pamela pour la keynote finale bien dans le ton de cette journée.
Après avoir rappelé qu’il y a tout de même environ 30 millions de développeurs dans le monde, elle a remis le chiffre en perspective avec les presque 7 milliards de personnes sur la planète.
Soutenant que la programmation est un support de la création et de l’innovation, elle espère que de plus en plus de personnes deviendront développeurs. Les façons d’apprendre à programmer sont nombreuses : pendant les études supérieures évidemment, mais Pamela nous a rappelé les nombreuses autres façons qui rendent l’accès au savoir plus facile, comme les cours en ligne, accessibles par tous, y compris de références comme le MIT, les ateliers de partage de connaissance, etc.
Tout ceci pour le petit défi qu’elle nous a lancé à tous : cette année, apprenez à une personne de votre entourage à programmer, pour que nous devenions toujours plus nombreux.

Et pour finir…

Et voilà, fin de journée! J’ai été ravi de la journée, et je remercie tous les organisateurs pour le boulot effectué et l’organisation sans failles : locaux agréables, pause repas de bonne qualité, wifi accessible et sans déconnexions intempestives, super site web (avec un excellent exemple de ce que peut apporter la “gamification” d’ailleurs), etc. Un grand merci naturellement aux speakers pour toutes ces présentations.
J’espère vous avoir donné envie d’assister à la prochaine session, en tout cas j’y serai également en 2013.
Pour information, certains slides des présentations sont disponibles sur le site du Mix It. Certaines n’y sont pas, mais sont facilement disponibles en cherchant sur Google.
A l’année prochaine!

Sexy, le développement Web Mobile ?

Le jeudi 19 Avril 2012, j’ai eu la chance de pouvoir présenter un « quickie » (présentation qui dure environ une quinzaine de minutes) à la première édition de Devoxx France, qui a lieu au Mariott Hotel à Paris.

Je vous propose ci-dessous une synthèse de ma présentation « Sexy, le développement Web mobile ? »

Commençons par un constat :

On estime que la moitié des connexions à l’Internet se feront à travers nos smartphones d’ici 2014. En début d’année, Twitter a déclaré que 30% des tweets se font à travers les smartphones, et 18% uniquement via le site Web Mobile.

Ainsi, il est devenu important, et même vital, d’être visible et présent sur le monde de la mobilité. On ne peut s’y tromper : 70% des entreprises ont soit une application mobile, soit une application en cours de développement ou envisage d’en avoir une.

A l’heure actuelle, les entreprises ont le choix principalement entre

  • le développement d’applications natives (pour iOS, Android, Blackberry),
  • le développement Web Mobile (se basant sur les technologies Web modernes comme HTML5 et CSS3)
  • ou encore le développement Web Mobile hybride (qui fait le pont entre les deux univers précédents, le framework phare étant Cordova, le nouveau nom de PhoneGap).

Il existe d’autres approches, mais elles restent « exotiques ».

Quels sont les avantages du natif ?

Le développement natif permet tout d’abord, l’accès aux couches basses  du smartphone (SMS, répertoire, etc.) ce que ne permettent pas les autres approches.

Chaque plateforme (iOs, Android, …) propose ensuite un ensemble d’outils / environnements de développement propre facilitant la conception et la réalisation d’applications très performantes.

Enfin l’approche native offre la possibilité de publication de son application au travers des « markets » (Apple store, android market) permettant ainsi sa diffusion à large échelle.

Par contre cela implique de développer la même application pour chaque plateforme cible, soit à minima 3 versions différentes (Android, iOs et BBY) afin d’adresser 95% du marché des smartphones et tablettes, ce qui coûte bien évidemment du temps et de l’argent, et amène le problème des ressources.

En effet, pour le monde Android et Blackberry, un profil de développement avec des compétences Java pourra prendre en main rapidement ces environnements, tandis que poir iOS, les compétences restent rares, et la montée en compétence est reconnue comme longue et douloureuse.

            

Le web mobile

Premier avantage : plusieurs plateformes sont ciblées ce qui permet une réduction des coûts. Il y aura cependant des adaptations à faire, notamment en ce qui concerne les IHM et le code. Mais étant donné qu’on est dans le monde du Web, on est habitué à faire des adaptions, pour les différents navigateurs et leurs différentes versions. Ainsi, on peut toujours espérer avoir un code commun à plus de 95%.

Les performances du Web Mobile sont vraiment correctes. Quand j’ai écrit ma première application il y a de cela 2 ans, j’ai été bluffé par la vélocité (je m’attendais à ce que ce soit très lent, car j’avais un très grand nombre de fichiers JavaScipts). Grâce à HTML5 et CSS3, l’interaction avec le smartphone et l’utilisateur est plutôt bonne, avec une IHM professionnelle (je peux citer le site du New York Times, qui est fait en CSS3 et qui est bluffant).

En revanche, il n’est pas possible de créer des applications nécessitant de hautes performances, comme pour la réalité augmentée. On ne peut pas accéder à toutes les couches basses. Et l’ergonomie n’est pas à 100% en adéquation avec la plateforme (ce qui est normal vu que nous faisons une application pivot).

Pourquoi alors je considère que le développement Web Mobile est sexy ? D’une part, on trouve des moteurs Web modernes et performants (pour être plus précis, on trouve Webkit !). Pour rappel, le premier moteur Web HTML5 se trouvait sur un smartphone, et plus précisément sur un iPhone … en 2007 !! Alors qu’il faudra attendre plusieurs mois encore avant de voir en apparaitre un sur Desktop. La compatibilité HTML5 et CSS3 est très bonne. Il faut juste s’assurer que les fonctionnalités ont été activées. Par exemple, WebSocket n’est pas accessible sous Android alors qu’il l’est sur iOS et Blackberry.

Une communauté de plus en plus forte s’est formée ces dernières années, autour de nombreux sites dédiés à ce sujet, comme html5rocks.com, qui fût le premier site à expliquer HTML5 et à donner des tutoriaux. Je regarde régulièrement ce site qui reste pour moi une bible.

Et tout cela s’articule autour de technologies adaptées et en évolution que sont HTML5 et CSS3. Le terme « évolution » est important ici, car si on va voir sur le site du W3C, ces deux technologiess sont encore en état de brouillon. Pour CSS3, c’est quasi-finalisée. Pour HTML5, de nombreuses fonctionnalités sont proposées de mois en mois. Par exemple, courant 2011, une API a été proposée pour accéder à la liste des contacts du téléphone. Début 2012, une autre proposait de faire vibrer le téléphone. Ainsi, le Web Mobile mute de plus en plus afin de pouvoir mieux s’intégrer à nos smartphones.

          

De plus, il est possible de faire du Web Mobile hybride ! Cela consiste à embarquer nos fichiers HTML5, CSS3 et JavaScript au sein d’un wrapper natif. Cela permet non seulement d’être présent sur les markets, mais aussi de faire un pont entre nos pages Web et le natif. On peut imaginer de pouvoir lister nos SMS sur une page Web en communiquant via JSON au natif qui lui va s’occuper de chercher les dits SMS.

Techniquement, que devons-nous utiliser ?

Pour commencer, on aura besoin d’HTML5, de CSS3 et de JavaScript. Mais il ne faut pas perdre de vue que le W3C propose des fondations ! Ainsi, on ne trouvera pas de base des widgets fancy ou sexy. On va donc utiliser des frameworks JavaScripts adaptés, comme jQuery Mobile de « The Filament Group » (que j’utilise massivement) ou encore la solution payante qu’est SenchaTouch de Sencha Labs.

          

Il existe deux frameworks assez récents qui sont prometteurs, et les deux se basant sur jQuery. Le premier est KendoUI (solution payante) qui propose des widgets assez puissant, basé sur HTML5/CSS3, qui rivalisent vraiment avec ceux de jQuery UI. Il s’adapte également pour le Web Mobile, notamment sur le style d’affichage très proche de la plateforme où le site s’affiche. Ensuite, on trouve Bootstrap, par l’équipe de Github, qui propose un framework léger, simple à utiliser et surtout Design Responsive. Un framework vraiment prometteur.

           

Si on souhaite faire du Web Mobile hybride, on va utiliser un framework comme Apache Cordova (anciennement, PhoneGap), qui propose des enveloppes natives pour de nombreuses plateformes (comme iOS, Android, Blackberry, Windows Phone 7, Bada …) et aussi une API JavaScript permettant d’accéder à une partie des couches basses. Cette API va être fortement enrichie dans sa version 2.0, et il est à noter que ce framework propose un système de plugin. Personnellement, j’ai écrit un petit plugin Android pour dialoguer avec l’application native Twitter, et j’ai pu le faire simplement grâce à cela.

     

Néanmoins, il faut faire attention lorsqu’on utilise le Web Mobile. D’une part, il faut se forger une expérience Web Mobile. Il faut évidemment apprendre de nouvelles technos/frameworks, mais également prendre en compte des problèmes qu’on a l’habitude mettre de côté, comme la taille de l’écran, bien plus petite que nos écrans de bureau (la norme maintenant est 1024 par 768, mais on estime que la prochaine norme sera la taille d’une tablette, voire d’un smartphone), ainsi que le débit du réseau (la 3G ne rivalisant pas avec la fibre d’entreprise).

De plus, il faut s’assurer de l’adéquation entre le besoin et la solution. Si votre client souhaite une ergonomie parfaitement en adéquation avec la plateforme, ou de hautes performances, le Web Mobile n’est pas fait pour vous.

Néanmoins, celui-ci peut répondre à plus de 85% des besoins qu’on peut rencontrer. Ainsi, selon moi, il ne faut pas hésiter à sauter le pas car le Web Mobile à mes yeux a un avenir prometteur et va dans le bon sens. Et je n’hésite pas dire que le développement Web Mobile est sexy !

Vous pouvez consulter les slides de ma présentation sur le lien suivant:

Analyser à distance votre application Web Mobile

Afin de cibler un public plus large – généralement iOS et Android – nombre d’entre nous avons décidé de nous lancer dans la création d’applications Web mobile.

L’outillage est souvent vu par les développeurs comme un point faible du Web Mobile par rapport à des approches de développement plus traditionnelles : Objective C ou Java. Comment par exemple déboguer et analyser une application qui s’exécute sur le mobile ?

En effet, bien que les smartphones et les tablettes utilisent très massivement le moteur de rendu Webkit (à l’exception de Windows Phone), ces derniers le configurent de manière différente. Ainsi, certaines fonctionnalités de HTML5/CSS3 sont désactivées, ou encore le comportement des pages peut varier.

Pour ma part, avant d’utiliser Weinre, je commençais par tester mon application dans Google Chrome en mode non sécurisé (désactivation de la sécurité cross-domain, accès aux fichiers locaux) et  en exploitant les nombreux outils et plugins de Chrome. Pour avoir la sensation d’être sur un mobile, j’incorporais mon application dans un template représentant un smartphone.

Enfin, je terminais mes tests en lançant l’application sur les différents émulateurs et simulateurs. Néanmoins, quand l’affichage n’était pas satisfaisant, j’étais obligé de modifier HTML, CSS et JavaScript souvent en tâtonnant et de recommencer les tests jusqu’à trouver la solution : ce qui était long et fastidieux.

Heureusement pour nous, un outil vient nous aider : Weinre !

Cet outil est intégré dans la solution Cloud de PhoneGap. Il permet d’analyser son application Web à distance ! Et cela très facilement ! Pour cela, rien de plus simple, télécharger le projet puis taper la commande suivante :

java -jar "DIRECTORY_PATH\weinre.jar" -httpPort 8081 -boundHost -all-

A partir de là, vous pouvez ouvrir sur votre navigateur de bureau deux liens :

Ensuite, il suffit d’ajouter ce bout de script en bas de votre page HTML (dans le tag BODY, évidemment) :

<!– —————————————————————— –>

<!– ————————– Weinre Part ————————— –>

<!– ——————— For debugging —————————— –>

<script type= »text/javascript » src= »http://youripaddress:8081/target/target-script-min.js#anonymous »></script>

<!– —————————————————————— –>


Et voilà ! Désormais, c’est à vous de jouer !

En vous rendant sur le lien http://127.0.0.1:8081/client/, vous ferez alors une liste de liens. Elle correspond aux pages qui se sont connectés sur notre serveur Weinre.

Nous pouvons cliquer sur l’un des liens et alors nous pourronsons naviguer dans l’explorateur de DOM et de CSS, le gestionnaire de ressources et la console JavaScript.

Et ce qui est pas mal, c’est que lorsque nous inspectons un élément DOM, l’élément est en surbrillance sur la page à distance !

Voilà comment installer et utiliser un outil tout simple qui va nous faciliter la vie.