Je remercie les personnes suivantes :

• les bénévoles de [developpez.com] qui permettent aux auteurs d'articles de délivrer des documents d'excellente qualité à leurs lecteurs ;
• Joachim Tahé qui a mis le document initial au format [developpez.com].

Le point de départ de ce document a été un projet étudiant de dernière année de l'école d'ingénieurs ISTIA de l'université d'Angers [http://istia.univ-angers.fr] : piloter des éléments de la maison (lampe, chauffage, porte de garage, ...) avec un mobile, smartphone ou tablette. Ce projet a été proposé par Sébastien Lagrange, enseignant-chercheur de l'ISTIA. Il a été réalisé par six étudiants : Thomas Ballandras, Raphaël Berthomé, Sylvain Blanchon, Richard Carrée, Jérémy Latorre et Ungur Ulu. Le projet a été décliné en trois sous-projets :

1. application web mobile avec JSF2 / Primefaces ;
2. application web mobile avec HTML5 / Javascript / Windows 8 ;
3. application native Android.

Le TP consiste à réaliser les sous-projets 3 et 1 dans cet ordre. Plusieurs documents sont référencés :

• [ref1] : " Introduction aux frameworks JSF2, Primefaces et Primefaces Mobile " disponible à l'URL [http://tahe.developpez.com/java/primefaces/]. Il vous servira pour construire le client web mobile ;
• [ref2] : " Android pour les développeurs J2EE : un modèle asynchrone pour les clients web " disponible à l'URL [http://tahe.developpez.com/android/avat]. Il vous servira pour construire le client Android ;
• [ref3] : " Introduction à Java EE avec Netbeans 6.8 " disponible à l'URL [http://tahe.developpez.com/java/javaee]. Il vous servira pour construire le serveur ;
• [ref4] : " Introduction au langage Java " disponible à l'URL [http://tahe.developpez.com/java/cours]. Il vous servira pour construire les serveurs et clients TCP-IP de la couche [DAO] du serveur.

L'architecture du projet Android est celle d'une application client / serveur. L'architecture du serveur est la suivante :

Wikipedia donne la définition suivante des Arduinos :

Arduino est un circuit impriméen matériel libre(dont les plans sont publiés en licence libre) sur lequel se trouve un microcontrôleurqui peut être programmépour analyser et produire des signaux électriques, de manière à effectuer des tâches très diverses comme la charge de batteries, la domotique(le contrôle des appareils domestiques - éclairage, chauffage…), le pilotage d'un robot, etc. C'est une plateforme basée sur une interface entrée/sortie simple et sur un environnement de développement utilisant la technique du Processing/Wiring.

La couche [DAO] est reliée aux arduinos via un réseau. Elle est constituée

• d'un serveur TCP/IP pour enregistrer les Arduinos qui se connectent ;
• d'un client TCP/IP pour envoyer les commandes à exécuter aux Arduinos connectés.
  Côté Arduino, on trouve les mêmes composantes mais programmées en langage C :
  La couche [DAO] peut commander plusieurs Arduinos.
• un client TCP/IP pour s'enregistrer auprès du serveur d'enregistrement de la couche [DAO] ;
• un serveur TCP/IP pour exécuter les commandes que la couche [DAO] envoie.

Un Arduino peut servir plusieurs clients. Ils sont alors servis séquentiellement.

Les échanges entre la couche [DAO] et un Arduino se font par lignes de texte :

• la couche [DAO] envoie une ligne de texte contenant une commande au format JSON (JavaScript Object Notation) ;
• l'Arduino interprète puis exécute cette commande et renvoie une ligne de texte contenant une réponse également au format JSON.

La couche métier du serveur est exposée au client via un service REST (REpresentational State Transfer) implémenté par le framework Spring MVC.

L'architecture du client Android est elle la suivante :

• la couche [DAO] communique avec le serveur REST. C'est un client REST implémenté par Spring-Android ;
  la couche [métier] reprend l'interface de la couche [métier] du serveur ;

Les versions actuelles d'Android exigent que les connexions réseau soient faites dans un autre thread que celui qui gère les interfaces visuelles. C'est ce qui explique la présence du bloc [4]. Les méthodes de la couche [métier] sont exécutées au sein d'un thread différent de celui de l'UI (User Interface). Lorsqu'on fait exécuter une méthode de la couche[métier] dans un thread, on peut attendre ou non la réponse de la méthode. Dans le premier cas, synchrone, on bloque l'UI en attendant la réponse de la tâche. Dans le second cas, asynchrone, l'UI reste disponible pour l'utilisateur qui peut lancer d'autres actions. Ici, on a choisi la solution asynchrone pour deux raisons :

• le client Android doit pouvoir commander plusieurs Arduinos simultanément. Par exemple, on veut pouvoir faire clignoter une led placée sur deux Arduinos, en même temps et non pas l'une après l'autre. On ne peut donc attendre la fin de la première tâche pour commencer la seconde ;
• les connexions réseau peuvent être longues ou ne pas aboutir. Pour cette raison, on veut donner à l'utilisateur la possibilité d'interrompre une action qu'il a lancée avec un bouton [Annuler]. Pour cela, l'UI ne doit pas être bloquée.

Les vues [2] sont les interfaces visuelles présentées à l'utilisateur. Sur une tablette, elles ressemblent à ceci :

A partir de cette vue, l'utilisateur lance une action avec le bouton [Exécuter].

Le bloc [3] regroupe les actions exécutées par les vues. La vue ne fait que saisir des données et contrôler leur validité. On part du principe qu'elle ne sait pas à quoi elles vont servir. Elle sait simplement à quelle action elle doit transmettre les données saisies. L'action lancera les tâches asynchrones nécessaires, mettra en forme leurs résultats et rendra à la vue un modèle pour que celle-ci se mette à jour. La vue n'est pas bloquée par l'action, afin de donner à l'utilisateur la possibilité de l'interrompre.

Les activités [1] sont le coeur d'une application Android. Ici on n'en a qu'une et elle ne fait quasiment rien si ce n'est d'assurer les changements de vues. On appellera ce modèle, AVAT (Activité - Vues - Actions - Tâches) et c'est ce modèle que nous allons décrire et illustrer dans ce document. On verra qu'il peut être allégé de la façon suivante :

Dans le modèle AVAT, la vue est complètement ignorante de l'utilisation faite des données qu'elle a saisies. Dans le modèle AVT ci-dessus (Activité - Vues - Tâches), la logique de l'action est transférée dans la vue. On trouve donc un peu de logique dans la vue. Celle-ci doit organiser les appels des tâches asynchrones elle-même. Cette logique est forcément faible. Si elle était importante, elle serait normalement transférée dans la couche [métier]. Ce modèle AVT est suffisant dans tous les cas. Le modèle AVAT est pour les puristes qui cherchent à limiter la vue à la saisie / affichage de données.

L'architecture du projet web mobile est également celle d'une application client / serveur. Le serveur reste ce qu'il était pour le client Android :

L'architecture du client web mobile est la suivante :

Sur une tablette, les vues ressemblent à ceci :

Le client web mobile aura les mêmes fonctionnalités que le client Android mais il aura l'avantage de fonctionner sur toutes les tablettes quelque soit l'OS (Android, IOS, Windows 8).

Nous allons tout d'abord écrire la partie serveur du projet qui est commune aux deux types de clients :

Nous allons réaliser dans l'ordre :

• la programmation des Arduinos ;
• l'implémentation de la couche [DAO] ;
• l'implémentation de la couche [métier] ;
• l'implémentation du service REST.

Puis ensuite, nous réaliserons le client Android :

L'objectif principal du TP est de réaliser ce client Android. Ceux qui le peuvent continueront le TP par l'écriture du client web mobile :

Les projets " client Android " et " client web mobile " ont tous deux été donnés en projet l'an dernier. Chaque projet a été traité par un groupe de deux étudiants sur une période d'environ 150 h. A la fin du projet, chaque groupe arrivait à allumer / éteindre une lampe connectée à un Arduino. L'objectif est de faire plus en seulement 30 h. Pour y arriver, on vous propose un cadre très contraint dans lequel des squelettes de code vous sont donnés afin que vous puissiez avancer plus vite. Vous trouverez ces éléments dans un dossier [support] :

Par ailleurs, de nombreux codes sont expliqués dans ce document. Faites du copier / coller entre ce document et vos projets Eclipse.

Il est important que vous lisiez et compreniez le document avant de programmer. Avant chaque étape importante du TP, il y a des lectures recommandées. Il ne faut pas faire ces lectures pendant le TP mais chez vous avant le TP. Sinon, vous allez perdre un temps précieux pendant le TP.

Ce TP est également un cours sur la mobilité et plus particulièrement sur Android. Vous ne devez pas vous contenter de coder sans comprendre l'architecture générale de l'application. L'étape normale suivante de ce cours / TP est que ce soit vous qui dessiniez l'architecture générale d'un nouveau projet.

Pour certains, il peut être frustrant de suivre un parcours tracé à l'avance. Vous pouvez alors, si vous le souhaitez suivre votre propre chemin pour réaliser le projet. Vous devez avoir conscience des avantages / inconvénients de cette méthode. En avantage elle est plus créative. En inconvénients, vous aurez moins d'aide de la part des encadrants. Celui-ci n'a pas la capacité de suivre des projets différents alors qu'il le peut si les projets suivent tous la même trame. Il se concentrera donc sur ces derniers. Il y a ainsi le risque de rencontrer des blocages qui peuvent vous retarder.

Voici une progression possible du TP :

Pour arriver à l'objectif final qui est de réaliser le client Android de l'application, il est probable que vous aurez à travailler en-dehors des cours. Les 12 h affectées ci-dessus au projet Android semblent en effet insuffisantes.

Chaque étudiant aura à sa disposition :

• un Arduino avec une led et un capteur de température ;
• un minihub à partager avec un autre étudiant ;
• un câble USB pour alimenter l'Arduino ;
• deux câbles réseau pour connecter l'Arduino et le PC sur un même réseau privé :
• une tablette Android.