Blog Objet Direct

La nouvelle version du système d’exploitation Android, nommée Ice Cream Sandwich (version 4.0) a été annoncée par Google cette semaine à Hong Kong.

Cette nouvelle version de l’OS est destinée aux tablettes et aux téléphones. Pour rappel, la précédente version, Honeycomb (3.0), avait été réalisée spécifiquement pour les tablettes. Par conséquent les mobiles Android n’avaient pas vu leur OS évoluer depuis la sortie de Gingerbread (2.3), il y a presque un an. Ice Cream Sandwich va donc permettre de fusionner les deux branches (mobile et tablette) en un seul et même système.

En plus des fonctionnalités héritées d’Honeycomb (accélération 2D matérielle, framework 3D Renderscript, etc.), les mobiles en 4.0 vont profiter des nouveautés suivantes (entre autres) :

• De nouvelles possibilités de communications entre appareils (WiFi Direct, NFC)
• Des outils améliorés pour la reconnaissance vocale et l’accessibilité
• Un outil permettant de suivre et analyser la consommation data des applications
• Des performances globales améliorées, un nouveau “launcher” d’applications
• Des applications mises à jour : navigateur web, appareil photo, galerie…
• Une ergonomie globalement améliorée

Et côté framework, de nouvelles API et fonctions sont fournies :

• Une API “sociale” pour le partage de contenu avec les contacts, et l’interaction avec les réseaux sociaux
• Une API pour accéder à l’agenda. Les applications pourront par exemple créer des évènements dans le calendrier de l’utilisateur.
• Un nouveau type de vue (TextureView) permettant de manipuler des flux d’images (vidéos, OpenGL, appareil photo…) de la même façon qu’avec des vues classiques. Cela va notamment être très pratique pour les animations.
• Une API pour accéder aux services de reconnaissance vocale et au dictionnaire
• Un nouveau type de layout permettant d’organiser les vues en grille (GridLayout), à la manière des tableaux en HTML.

Pour la liste complète : http://developer.android.com/sdk/android-4.0-highlights.html

Comme pour chaque nouvelle version, la compatibilité avec les anciennes applications est respectée. Cela veut dire que la plupart des applications existantes vont fonctionner sur Ice Cream Sandwich sans que les développeurs n’aient besoin d’intervenir dans leur code. Ils seront tout de même invités à faire évoluer leurs applications ou à en créer de nouvelles pour tirer parti des nouvelles fonctionnalités offertes.

Concernant la mise-à-jour des terminaux actuels, ce nouvel OS étant assez gourmand en RAM et en ressources graphiques, seuls les smartphones haut de gamme pourront être mis à jour. Les Google Nexus S et Samsung Galaxy S II en feront probablement partie. Google a également annoncé la sortie du nouveau smartphone de la marque, le Galaxy Nexus. Ce mobile high-tech conçu par Samsung sera équipé d’Ice Cream Sandwich dès sa sortie.

3 nouveaux séminaires techniques organisés et animés par Objet Direct, en juin :
« HTML5 : quels enjeux pour la mobilité et le RIA ? ».

Etat des lieux du marché, retours d’expérience et démonstrations au cours de ces séminaires Objet Direct, avec le témoignage de Speedinfo : Venez découvrir les nouveaux usages et les perspectives ouvertes par les applications HTML5 mobiles.

=> le 16 juin à Grenoble, le 23 juin à Lyon, le 28 juin à Paris, 9h-11h (accueil petit déjeuner)
Evénements gratuits, sur réservation ferme.
En savoir plus et s’inscrire en ligne sur le site d’Objet Direct.

Objet Direct a sponsorisé la 1ère conférence Mix-IT le 5 avril à Lyon. A cette occasion, Christian Demoustier, Directeur Technique d’Objet Direct Lyon, a animé une conférence sur le thème :
« Smartphone : et l’informatique devint mobile ! »

La présentation est proposée au téléchargement ici.

Le mois dernier, Yannick dans un excellent billet de synthèse se demandait si la guerre de Java aurait lieu.

Une marche de plus vient d’être franchie. La fondation Apache a mis sa menace à exécution et a quitté le JCP, 2 jours après que celui-ci ait adopté les spécifications de Java 7 et 8. Pour mémoire, l’objet du litige (qui ne date pas d’aujourd’hui, cf la lettre ouverte envoyée à Sun en 2007) c’est le TCK (et plus précisément les FOU – field of use) qui permet de certifier une JVM et qui n’est aujourd’hui pas open-souce (Sun ne voulait pas le libérer… et Oracle non plus).

A ce stade nombre de questions se posent :

• le projet Harmony va-t’il être abandonné ?
• quelle conséquence cela peut-il avoir sur Android ? (Android s’appuie sur DalvikVM qui reprend nombre de classes issues d’Harmony)
• comment va réagir Google ? (Google reste désormais parmi les grands le seul « opposant » à Oracle sur le sujet du TCK)
• Oracle cherche-t-il désormais à rentabiliser Java à tout prix ? (en privilégiant les clients qui payent au détriment de la communauté libre)
• est-ce que cela va profiter à Microsoft et aux projets libres de la famille Mono ? (les différents contentieux entre Oracle et SAP conduisent déjà ce dernier à se rapprocher de plus en plus de Microsoft)
• est-ce un bien ou un mal pour Java ? (moins d’acteurs impliqués dans les choix peut peut être accélérer la roadmap)
• la communauté libre va-t-elle se reporter sur Ruby ?
• …

Prochaine étape peut être : le verdict du procès opposant Google et Oracle à propos de violations de brevets qui seraient faites dans Android.

N’hésitez pas à réagir !

Objet Direct a présenté les nouveaux usages et les perspectives ouvertes par le développement mobile, avec le retour d’expérience de CARL Software, à l’occasion de trois séminaires animés par Christian Demoustier le 19 octobre à Lyon, le 20 octobre à Grenoble et le 21 octobre à Paris : Smartphone : et l’informatique devint mobile…

La présentation est proposée au téléchargement ici.

3 nouveaux événements techniques organisés et animés par Objet Direct, en octobre :
« Smartphone : et l’informatique devint mobile… ».

Venez découvrir les nouveaux usages et les perspectives ouvertes par le développement mobile, à partir des retours d’expérience concrets d’Objet Direct qui a conduit pour ses clients plusieurs projets très innovants.

=> le 19 octobre à Lyon, le 20 octobre à Grenoble, le 21 octobre à Paris, 9h-11h (accueil petit déjeuner)
Evénements gratuits, sur réservation ferme.
En savoir plus et s’inscrire en ligne sur le site d’Objet Direct.

Annoncé le 12 juillet dernier par Google, App Inventor est un projet visant à mettre le développement d’applications Android à la portée de tout le monde. Le projet permet de concevoir en ligne des applications Android avec une interface WYSIWIG (What You See Is What You Get) uniquement par drag’n drop. Il est librement inspiré d’un projet du MIT destiné à enseigner la programmation de façons visuelle et intuitive, Scratch.

Le projet est encore en bêta fermée, mais des invitations sont régulièrement distribuée et j’ai eu la chance d’en recevoir une dans ma boîte mail. Je vous propose donc un petit retour sur l’utilisation de ce nouveau produit Google.

Installation

L’installation est très simple, elle ne nécessite que d’avoir installé une version récente de Java sur son poste. Il n’est même pas nécessaire de posséder un téléphone sous Android, puisque l’utilisation d’un émulateur est possible. Fidèle à lui-même Google propose de développer son application Android via une interface web.

En réalité seule la partie vue de l’application peut être conçue en ligne. Pour la partie contrôle, elle est réalisée dans une application JavaWebStart nommée block editor. En effet, le projet propose de ne plus coder la logique dans un fichier source mais de réaliser un emboîtement visuel de bloc logique à la manière d’un puzzle.

Utilisation

La conception de l’interface se fait par simple glisser-déposer. Les composants classiques sont présents – Button, Label, Checkbox .. – ainsi que d’autres spécifiques aux téléphones tel que l’accéléromètre ou la localisation. Il existe aussi des composants qui font directement appels au système Android tel que le PhoneCall pour passer des appels ou le SpeechRecognizer pour utiliser les fonctions de reconnaissance vocales.

Malheureusement, il manque beaucoup de composants d’Android et il n’est pas possible d’utiliser ceux présents aussi finement qu’avec une programmation classique. Le point particulièrement bloquant est qu’il est impossible d’avoir plus d’un écrans. L’application devra donc se limiter à un seul écran …

La conception de la partie logique est la plus intéressante mais aussi la plus déroutante. Le “jeu” consiste à créer toute la logique de notre application en emboîtant les interactions de chaque composants. On retrouve donc tous les composants qu’on a  déjà positionné ainsi que d’autres “blocs” représentant les procédures, nombres, texte, listes et logique.

J’ai d’abord trouvé cette nouvelle façons de “programmer” très facile et surtout très ludique. Il est vraiment simple de glisser les blocs “do” dans des blocs “when” et de construire ainsi très rapidement les interactions des boutons avec les autres composants. Un mini débuggueur est même intégré qui permet d’espionner des variables tout en testant sur le téléphone. Mais, tout comme dans un fichier source classique, avec le nombre vient la complexité. Après avoir ajouté de nombreux widgets et interactions je me suis retrouvé avec un espace de travail très fourni, et il était difficile de retrouver les variables à positionner dans les tests et autres procédures. Entre autre, c’est au final très désorientant pour quelqu’un qui connaît la programmation classique de créer sa logique visuellement.

Voici par exemple la création et l’affichage d’une liste :

Et son équivalent en code java :

List<String>; mousquetaires = new ArrayList<String>({“Athos”, “Porthos”, “Aramis”});
mousquetaires.add(“D’Artagnan”);

StringBuilder sb = new StringBuilder(“Les mousquetaires du roi : ”);
for (String mousquetaire : mousquetaires) {
    sb.append(mousquetaire);
}

Clairement, pour quelqu’un qui connait les concepts d’une liste en java c’est beaucoup plus rapide d’écrire un code source. Toutefois, pour une personne qui n’a jamais vu un bout de code, alors là c’est vraiment intéressant pour apprendre les concepts de programmation et des structures logiques.

Conclusion :

App Inventor possède de nombreuses idées très intéressantes. La conception visuelle de la partie logique met le développement à la portée des non-informaticiens. Pour les informaticiens, cela permet de réaliser des prototypes fonctionnels très rapidement en quelques clics. Enfin, il est possible d’utiliser App Inventor instantanément et sur n’importe quelle plateforme et de déployer son application sur son téléphone sans être redevable d’une licence.

Il paraît cependant improbable de pouvoir développer de vraies applications professionnelles avec cet outil à l’heure actuelle. Les limitations par rapport à un développement classique en Java sont bien trop grandes. Il est d’ailleurs impossible d’exporter un projet réalisé avec App Inventor sous forme de code Java pour le reprendre de façon classique par la suite sous Eclipse.

App Inventor risque donc de se cantonner à de petites applications développées par des particuliers pour s’amuser avec leur téléphone et apprendre les bases de la programmation. En cela,  le projet de Google est une bonne chose s’il permet de démocratiser le développement auprès de personnes créatives mais rebutées par le code.

Par contre, ne risque-t-on pas de voir fleurir prochainement sur l’Android Market des tonnes d’applications baclées ? Mais peut-être est-ce un plan de Google pour rattraper Apple dans la course éffrenée aux plus grans nombres d’apps …

En tout cas le projet est une belle démonstration technique notamment par l’utilisation de GWT pour l’interface web et reste à surveiller. Peut-être qu’après le TDD, le DDD, le MDD verra-t-on arriver le DnDDD (Drag’n Drop Development Driven) ?

Dans la lignée des annonces du Google I/O 2010, il y a bien sur Android 2.2 alias Froyo qui apporte son lot de fonctionnalités.

On retiendra surtout la machine virtuelle Dalvik qui intègre le Just In Time ou compilation à la volée ce qui permet d’améliorer la performance des applications de 2 à 5 fois mais aussi l’intégration du moteur javascript V8 au navigateur embarqué qui met les performance devant l’iphone 3G et même l’ipad.

Il y aussi le support du Flash en version 10 qui permet de se démarquer de la concurrence

On notera aussi le partage de la connexion 3G avec un ordinateur, l’amélioration du market, la possibilité de stocker les applications sur la SD card et de nouvelles APIs.

Plus d’informations ici : http://android-france.fr/2010/05/20/android-2-2-froyo-est-officiel-voila-la-liste-des-fonctionnalites/

Pour information, la mise à jour est disponible sur le mobile de Google ou Nexus One. Pour les autres mobiles sous Android, on pense aux derniers HTCs, il faudra attendre que les constructeurs s’adaptent ce qui montre aussi les limites de la stratégie de Google en terme de diversification du marché.

Ce billet présente mon retour sur la demi journée de séminaire que j’ai pu suivre mardi chez nos confrères de Valtech Training animé par Olivier Penhoat.

Le marché du smartphone.

Android arrive sur un marché difficile étant donné la place prépondérante des OS historiques. Là où l’iPhone a percé avec insolence, révolutionnant les standards, Android peine à démarrer.

Dans un premier temps, n’oublions pas que l’on parle de deux sujets différents : d’un côté il y a toute une stratégie marketing avec un OS destiné à un objet unique, et de l’autre un OS disponible sur de multiples plateformes intégrant chacune des périphériques différents qu’il faut pouvoir orchestrer de façon identique.

De plus, cet OS n’est pas destiné spécifiquement aux smartphones comme on aurait tendance à le penser en premier lieu mais à une multitude d’appareils mobiles (tablettes, GPS, ordinateur de bord automobile, …).

Contrairement à ce que l’on peut penser à première vue, il semblerait que le marché à venir concerne ces divers appareils encore plus que les smartphones !

Google nous propose donc ici un système qui se veut ouvert :

• Applications (internes et tierces) toutes logées à la même enseigne (accès à toutes les ressources)
• Personnalisation poussée du bureau
• Applications modérées à postériori
• Pas d’IDE/OS imposé pour les développements
• Développement sur des standards du marché (Java/XML)

Comment cela se présente-t-il ?

Le système

L’architecture est basée sur un noyau Linux récent, agrémenté des divers drivers fournis par les constructeurs. Ensuite il y a une couche de libraires dont le « runtime Android » contenant une VM optimisée (Dalvik), puis une couche identifiée comme le SDK Android permettant un accès via le langage Java aux développeurs.

Attention néanmoins, la VM Dalvik est assez spécifique :

• Bytecode propriétaire
• Fonctionne sur un registre et non une pile pour optimiser la mémoire.
• Une instance de VM par processus.

L’outillage

Il est plutôt complet, on note entre autres :

• Android Debug Bridge : envoi de commandes sur l’appareil (ou son émulation).
• Un émulateur (permettant de simuler les différentes versions, matériels) avec déploiement à chaud.
• Dalvik Debug Monitor Service : affiche notamment les logs de la VM.
• Android Development Tools : plugin pour IDE au choix permettant de gérer une structure de projet Android et de mettre en place les IHM visuellement.

Composition d’une application

Le fichier manifest

Il sert de contrat pour l’application. Toutes les ressources que l’application va utiliser doivent y être déclarées : géolocalisation précise ou non, accéléromètre, appels, …

Une orchestration via des « intentions »

Les intentions sont très similaire à REST, il s’agit d’une ressource identifiée par son URI liée à une action simple (MAIN retourne à l’accueil, PICK sélectionne la ressource, EDIT …).

4 composants proposés comme cadre :

• Les activités : le cœur de l’application, en général une activité est fortement liée à un écran.
• Les fournisseurs de contenu : le nom est plutôt explicite, il va géré les accès aux différents contenus pour  donner un accès simplifié à l’application.
• Les services : ce sont les processus lancés en tâche de fond, tournant même quand l’application n’a plus la main.
• Les récepteurs d’intention : prennent en compte des évènements extérieurs (appel entrant).

Limites

La fragmentation

La première limitation vient de l’objectif même d’Android : la multiplication des appareils sur lesquels il est amené à fonctionner et donc des configurations différentes à gérer par le développeur, notamment les tailles d’écran, présence d’accéléromètre, …

On appelle cela la fragmentation et elle se multiplie encore avec les différentes versions d’Android proposées par les constructeurs : v1.5 : 30%, v1.6 : 54%, v2.0.1 : 15% …

Il faudra donc composer avec toutes ces configurations !

Android Market

La place de marché pour les applications Android, mis en place par Google souffre de nombreuses lacunes mettant un frein à son développement :

• Mauvaise gestion des commentaires
• Achat uniquement via le système de paiement Google (Checkout)

Conclusion

Olivier nous a fait une démonstration rapide et efficace de la mise en place d’une application Android. Le résultat est flagrant, il parvient très rapidement à afficher une carte Google Maps avec notre dernière position géographique donnée par le GPS …

Pendant la session, il nous a confirmé plusieurs fois que le développement était très simple malgré la fragmentation, qui est plutôt bien gérée par le SDK, pour faire des choses simples. Le pendant de ce système ouvert reste sa complexité quant on veut faire des choses qui sortent du cadre.

De plus, il ne faut pas oublier que l’on déploie une application sur un mobile et non un serveur d’application ! Il faudra donc, même si l’on travaille en Java, repenser notre façon de développer afin d’optimiser certaines structures de code.

Le mardi 10 Novembre 2009 a eu lieu le JUG parisien sur Google, JUG qui s’est temporairement transformé en GUG !

Trois thèmes abordés lors de cette soirée : Androïd, GAE et Wave. Les présentations furent intéressantes bien qu’inégales, mais globalement toutes étaient trop courtes (environ 40 minutes pour chaque sujet, c’est peu).

Androïd

Je ne reprendrai pas l’historique d’Androïd, seulement la partie dév. Il faut savoir qu’Androïd est basé sur un noyau Linux 2.6 et un environnement Java, sauf que ce n’est pas du vrai Linux et qu’il n’embarque pas une JVM, mais une Dalvik VM, allégée et spécifique à des processeurs et unités mémoire de téléphone portable. De ce fait quand on veut développer une appli, on utilise un simili Java SE (AndroïdSDK, en v3 pour Androïd 2.0). Google livre donc un outillage spécifique : l’Androïd Development Toolkit (ADT) qui s’intègre sous Eclipse, qui offre un joli émulateur/debugger de Google Phone (Androïd Virtual Device) qui permet de visualiser le rendu de notre appli. L’environnement de développement offre une interface WYSIWYG (on peut sinon faire du declarativeUI, ou encore du programmaticUI), et manipule essentiellement 4 types de composants :

• les activités : composants graphiques, comparables à des widgets (une activité correspond à un écran)
• les services : comme son nom l’indique, il s’agit de services (fonctionnement comparable aux threads)
• les broadcast receivers : réception de message broadcast (exemple : message de batterie faible)
• les content providers : fournisseurs d’accès aux données publiques

On voit donc apparaître une notion de message, qui semble être une notion capitale dans le dév Androïd : on parle alors d’ « Intent ». Un intent, peut être soit explicite (cible un composant au sein d’une application) ou implicite; il s’agit alors d’un message qui circule entre toutes les applis Androïd (pas de couplage fort entre les applis ). Par manque de temps, la présentation s’est arrêtée ici, mais vous pouvez voir le support complet là.

La suite dans le prochain billet !