Développement de nouveaux écrans pour l’application web et Android du PGI TwentyERP Rapport de stage 2 ème année DUT Informatique Jordan Martin 31 mars 2014 au 6 juin 2014 Pierre-Antoine Champin, Tuteur pédagogique Jérôme Poussineau, Tuteur en entreprise AXOPEN Immeuble "Le Palais d’Hiver" 149 Boulevard Stalingrad 69100 Villeurbanne Université Claude Bernard - Lyon 1 Département informatique 43 Boulevard du 11 Novembre 1918 69100 Villeurbanne
41
Embed
Rapport de stage 2 année DUT Informatique - jordan … · Rapport de stage 2ème année DUT Informatique Jordan Martin 31 mars 2014 au 6 juin 2014 Pierre-Antoine Champin, Tuteur
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Développement de nouveaux écrans pour
l’application web et Android du PGI TwentyERP
Rapport de stage 2ème année
DUT Informatique
Jordan Martin
31 mars 2014 au 6 juin 2014
Pierre-Antoine Champin, Tuteur pédagogique
Jérôme Poussineau, Tuteur en entreprise
AXOPEN
Immeuble "Le Palais d’Hiver" 149 Boulevard Stalingrad 69100 Villeurbanne
Université Claude Bernard - Lyon 1
Département informatique 43 Boulevard du 11 Novembre 1918
69100 Villeurbanne
1
Remerciement
Je remercie tout d’abord la société AXOPEN de m’avoir accueillie durant ces 10 semaines de stage.
Je remercie tout particulièrement M. Poussineau, dirigeant de la société AXOPEN pour la confiance
qu’il m’a accordée au travers de missions valorisantes.
Je remercie M. Alexandre Grondin et M. Florent Tripier ainsi que toute l’équipe de la société qui m’a
aidé et beaucoup appris tout au long du stage.
Je remercie également M. Pierre Antoine Champin, mon tuteur pédagogique ainsi que tout le corps
enseignant de l’IUT de Lyon 1 dont la formation m’a permis d’acquérir de solides bases en
informatique.
Je remercie enfin AXOPEN de m’avoir permis de m’absenter une journée pour participer à la
compétition des « 24h des Iut Informatiques ».
2
Fiche technique
Nom de l’entreprise AXOPEN
Activités de l’entreprise IT Consulting, développement d’application sur mesure et intégration de systèmes.
Intitulé des sujets
- Développement de nouveaux écrans pour l’application Android du PGI TwentyERP
- Développement de nouveaux écrans pour l’application web du PGI TwentyERP
Objectifs L’objectif est de créer des nouveaux écrans, des nouvelles fonctionnalités pour la version du PGI destinée au client Immo à Neuf.
A qui le travail est destiné Le PGI est développé en interne par AXOPEN. Une version est actuellement développée pour le client Immo à Neuf sous le nom de TwentyERP.
Quel sera son devenir Ce PGI sera utilisé par AXOPEN et vendu à ses clients.
Quelles sont les contraintes de temps ?
Certaines tâches devaient être terminées avant la livraison d’une version au client.
Informaticiens présent dans l’entreprise
AXOPEN est composée de 10 informaticiens.
Travail seul ou en équipe
Pour le premier sujet, l’application Android, j’ai travaillé avec M. Alexandre Grondin qui est en alternance dans l’entreprise. Pour le deuxième sujet, j’ai travaillé seul en étant supervisé par M. Poussineau.
Langages utilisés Pour la partie Android : Java avec le framework Android, XML Pour la partie web : Java avec l’extension JEE.
Apprentissage d’un nouveau langage
Je n’ai pas eu besoin d’apprendre un nouveau langage car le framework Android utilise le Java que je connais déjà très bien.
Quelle partie du travail doit être terminé en fin de stage
Les tâches m’ont été données au fur et à mesure.
Temps supplémentaire accordé à la rédaction du rapport ?
Je n’ai pas eu de temps supplémentaire pour la rédaction du rapport.
Annexe 1 : Liste des figures .............................................................................................................. 36
Annexe 2 : Journal de bord ............................................................................................................... 37
4
1. Introduction
Etudiant informatique en deuxième année à l’IUT de Lyon 1, j’ai eu l’occasion d’effectuer mon stage
de fin d’étude au sein de l’entreprise AXOPEN du 31 mars 2014 au 6 juin 2014.
AXOPEN est une jeune SS2I située à Villeurbanne qui propose des produits informatiques sur mesure,
intégration de systèmes, hébergement d’applications ou encore conseil en systèmes d’informations.
Ce stage est pour moi l’occasion de découvrir et intégrer le milieu professionnel en mettant en
application les connaissances et compétences acquises jusqu’à maintenant.
1.1. Choix de ce stage
J’ai connu la société AXOPEN grâce à l’intervention de M. Poussineau sur le « Cloud Computing » qui a
eu lieu en novembre 2013 à l’IUT. Après m’être renseigné sur les activités de l’entreprise via son site
web, j’ai soumis une candidature spontanée. M. Poussineau m’a, par la suite, proposé un entretien
durant lequel il m’a présenté le projet sur lequel j’allais travailler, le Progiciel de Gestion Intégrée (PGI)
développé par AXOPEN.
Désirant m’orienter dans la programmation web et plus particulièrement en Java EE, j’ai tout de suite
adhéré à ce projet qui est justement développé en Java EE.
1.2. Mes attentes
Mes attentes quant à ce stage sont de mieux comprendre le fonctionnement d’une entreprise
d’informatique à travers la gestion de projets, le relationnel avec les clients, et le travail collaboratif.
Je compte également sur ce stage pour découvrir et apprendre de nouveaux langages et technologies
mais également faire bénéficier l’entreprise de mes connaissances.
1.3. Les deux sujets de stage
Pendant ce stage, deux missions m’ont été confiées :
- Le développement de nouveaux écrans pour une application Android permettant l’accès au PGI
- La création de nouveaux écrans pour l’application web toujours pour le PGI.
Afin de rendre compte de mes 10 semaines passées au sein de la société AXOPEN, je commencerai par
présenter l’entreprise ainsi que ses activités. Je continuerai en exposant le lien qu’il existe entre les
deux missions avec l’architecture dans laquelle le PGI s’inscrit. Par la suite, je serai en mesure de
présenter chacune des deux missions en détaillant un point technique de l’une d’elle. Je conclurai ce
rapport en énonçant les apports professionnels et personnels acquis durant ce stage.
5
2. Présentation de l’entreprise
AXOPEN est une SS2I située dans l’immeuble « Le Palais d’Hiver » au 149 Boulevard Stalingrad à
Villeurbanne.
2.1. Création de l’entreprise
Créée en 2007 par Monsieur Philippe AUBERTIN, la société Inforésolutions s’est destinée dans ses
débuts à assister ses clients dans la mise en place de réseaux d’entreprise, le développement sur
mesure de sites Web et de petites solutions de gestion.
Suite à l’arrivé de Monsieur Jérôme POUSSINEAU et à la volonté de Monsieur Philippe Aubertin, la
société prend en 2009 un nouveau tournant en recentrant son activité sur les métiers du conseil en
solutions informatiques, développements sur mesure et intégration de systèmes.
2.2. Produit et service
AXOPEN propose trois types de produits et services :
Figure 1 Offres proposées par AXOPEN
IT Consulting (Conseil en système d’Information)
Les Technologies de l’Information de la Communication (TIC) sont très présentes et importantes dans
une entreprise qui doit faire face aux fluctuations de son marché. Pour y faire face, l’objectif est
d’augmenter l’efficacité des systèmes d’informations de l’entreprise.
C’est pourquoi AXOPEN propose un ensemble de prestation pour aider ses clients à faire des choix
technologiques et stratégiques adaptés à leurs besoins.
6
Software Engineering (Développement logiciel)
Puisque chaque client a des besoins uniques et spécifiques à son activité, AXOPEN propose de
développer des applications sur mesure.
AXOPEN est spécialisé dans le développement d’application web ou client riche avec des technologies
reconnu sur le marché :
- Java / J2E
- Microsoft .NET
- PHP
- Adobe ColdFusion, FLEX et Air
System Intégration (Intégration de systèmes)
Pour répondre à un besoin métier commun tel que la gestion de la relation client ou la gestion
financière, il existe déjà beaucoup de solutions prêtes à l’emploi et entièrement paramétrable. Ces
solutions peuvent être Open Source ou propriétaire et offrent un coût de mise en place inférieur au
développement d’une solution sur mesure.
Dès lors, AXOPEN propose de prendre en charge l’intégration de ces solutions depuis la phase de choix
de l’outil jusqu’à l’accompagnement au changement auprès des équipes.
2.3. Clientèle
AXOPEN ne s’adresse pas spécifiquement à un secteur d’activité ou à un type de structure. Comme le
montre la Figure 2 Clients d'AXOPEN, AXOPEN intervient auprès de clients grands comptes, de
PME/PMI mais aussi d’associations dans des domaines d’activités variés.
Figure 2 Clients d'AXOPEN
7
2.4. Organigramme
Jérôme Poussineau
Direction / Commerce
Grégory Bouc
Centre de services / Directeur
technique
Thibaut Gonin
IT Consulting / RH
Développeurs
Benjamin Thomas
Consultant
DIR
ECTI
ON
Philippe Aubertin
Direction / Commerce
DIR
ECTI
ON
OP
ÉRA
TIO
NEL
LE
8
3. Mes missions
Durant le stage, les deux missions qui m’ont été confiées ont un objectif commun : l’accès au PGI à
travers deux supports différents ; un site internet et une application Android. Ces deux applications
étant déjà existantes, ma mission a été de créer de nouveaux écrans pour chacune d’entre elle.
Un PGI, Progiciel de Gestion Intégrée (en anglais, ERP signifiant « Enterprise Ressource Planning »), est
une application qui permet de centraliser et unifier la gestion des ressources de l’entreprise telle que
la gestion commerciale (portefeuille client, devis, …), les ressources humaines, la comptabilité
(factures, fiche de paie, note de frais, …).
Le PGI est développé en interne et utilisé par AXOPEN. Egalement proposé à ses client et pour répondre
aux besoins spécifiques de leurs activités, cette application peut être adaptée et personnalisée.
Actuellement une version de ce PGI est adaptée pour un client ; la société Immo à Neuf1. C’est sur
cette adaptation que j’ai travaillé durant les dix semaines de stage.
Par rapport à l’application Android, la version web du PGI étant plus avancée, les deux missions se sont
reparties dans le temps de la manière suivante : six semaines sur l’application Android et trois semaines
sur l’application web. De plus, j’ai travaillé durant une semaine sur l’élaboration d’une documentation
utilisateur pour une formation dispensée par AXOPEN.
1Immo à Neuf est une entreprise de rénovation immobilière basée à Paris
9
3.1. L’existant
Le PGI développé par AXOPEN n’en est pas à sa première version. En effet, le développement a débuté
en 2010 avec une première version, réalisée avec le langage PHP.
Cependant, PHP n’est pas un langage très adapté pour de gros projets complexes qui comportent un
nombre important d’utilisateurs. Notamment au niveau maintenabilité, il peut vite devenir difficile de
faire évoluer l’application. C’est pourquoi AXOPEN a choisi le langage Java avec sa spécification
Enterprise Edition (Java EE) pour développer la seconde version actuellement utilisée en interne.
Enfin, fort de son expérience grâce aux deux versions précédentes et toujours avec Java EE, AXOPEN
a développé une troisième version du PGI, plus performante, plus facile à faire évoluer et à
personnaliser.
3.1.1. Architecture du PGI
Le schéma ci-contre représente les principales
briques qui composent le PGI. Nous y retrouvons
une base de données MySQL et le serveur
d’application JBoss. Hibernate qui est un module
permettant de gérer la persistance des données
dans une base fonctionnant avec JBoss pour
interagir avec la base MySQL.
Ces trois éléments sont situés sur une même
machine ce qui permet une communication et un
accès aux données très rapide.
Le serveur JBoss a ici plusieurs rôles. En effet, il permet d’établir la connexion avec la base de données
à travers Hibernate, d’exposer l’application web sur Internet, de traiter les requêtes des utilisateurs et
de fournir des services web pour l’accès au PGI depuis l’application Android. C’est donc l’élément
central de l’architecture.
Dans la partie suivante, j’expliquerais pourquoi a été développé une application spécifiquement pour
Android et non une version web adaptée pour mobile.
Figure 3 Architecture simplifié du PGI
Serveur d’application JBoss
Base de données MySQL
Client WEB
Client Android
10
3.2. Développement de nouveaux écrans pour l’application Android
Cela fait maintenant quelques années que les smartphones et tablettes numériques se développent
dans le milieu professionnel. Le smartphone et la tablette permettent une mobilité totale et un accès
à l’information quasi instantané.
Il est donc normal pour une application permettant de consulter et gérer les ressources de l’entreprise
d’être accessible partout, rapidement, et avec des informations à jour en temps réel.
Etant donné qu’il existe déjà une version web, on pourrait alors se demander pourquoi concevoir, en
plus, une application Android sachant que les appareils Android possèdent tous la capacité d’accéder
au Web via un réseau téléphonique ou Wifi.
Même si chaque appareil Android est doté d’un navigateur, il existe néanmoins quelques différences
avec le navigateur web d’un ordinateur.
Tout d’abord au niveau ergonomie et expérience utilisateur, un appareil mobile, tel qu’une tablette ou
un smartphone, possède un écran de taille très réduite par rapport à un ordinateur. Cela pose le
problème suivant : comment afficher autant d’informations et proposer les mêmes fonctionnalités sur
un écran plus petit et avec la même technologie ?
La difficulté est que les langages du web (HTML/CSS/JavaSript) ne permettent pas de créer des
interfaces très avancées tout en restant fluides, rapides et ergonomiques.
Le deuxième problème d’un navigateur web d’un appareil mobile est qu’il est limité en termes de
fonctionnalités. Il ne pourra pas, par exemple, accéder à la caméra, au vibreur, au système de stockage,
ou au système de notification2.
Pour ces raisons AXOPEN a choisi de développer une application Android native (aussi appelé client
lourd) pour proposer à ses clients une solution rapide, ergonomique, et simple d’utilisation. Cette
application est prévue pour fonctionner aussi bien sur tablette numérique Android que sur
smartphone Android.
2 En réalité, les navigateurs mobiles commencent à intégrer ce genre de fonctionnalités de manière expérimentale. Ce n’est donc pas suffisamment fiable pour une application professionnelle
11
3.2.1. Outils, matériels et technologies
- Langage Java
Le développement Android est exclusivement réalisé en Java. Il existe cependant une possibilité de
développer avec le langage C++ mais uniquement pour répondre à des besoins bien spécifiques (de
performance par exemple).
- Eclipse
Eclipse est un environnement de développement intégré (EDI) permettant d’accélérer et de faciliter le
développement d’application notamment en automatisant certaines tâches.
- GenyMotion
GenyMotion est un logiciel permettant d’émuler un appareil Android depuis un ordinateur. Il permet
de tester ses applications sans avoir besoin de l’appareil Android.
- Android Development Tools (ADT)
Ensemble d’outils, plugins3, et bibliothèques permettant le développement sur un appareil Android.
Ce KIT comprend notamment des plugins pour Eclipse afin de faciliter certaines opérations telles qu’un
éditeur d’interface graphique, l’envoi de l’application sur l’appareil Android, etc…
- Tablette numérique Samsung
Comme l’émulateur parfait n’existe pas, il est nécessaire de tester ses applications dans les conditions
réelles c’est-à-dire sur l’appareil Android lui-même.
3 Plugin : Extension visant à enrichir une application avec de nouvelles fonctionnalités
12
3.2.2. Prise en main d’Android
Afin de me familiariser avec l’environnement Android, M. Poussineau m’a fourni des supports de
formation. Au travers de ces documents et des tutoriels en ligne, j’ai pu mieux appréhender Android
que je ne connaissais pas jusqu’à maintenant. J’ai également eu la chance de pouvoir travailler avec
M. Alexandre Grondin, actuellement en alternance chez AXOPEN, qui travaille sur la partie Android
depuis presque un an. De par son expérience sur le projet et sur Android, Alexandre m’a beaucoup
aidé et fait gagner du temps d’apprentissage.
Depuis sa création, cette application est en grande partie conçue pour un appareil Android de type
mobile et donc avec un écran de taille réduite. Par conséquent si l’on désire utilisée cette application
avec une tablette, le rendu graphique ne serait pas adapté et optimal. C’est pourquoi mes premiers
travaux ont portés sur l'adaptation sur tablette des écrans déjà existants sur mobile.
C’est donc avec l’éditeur d’interface graphique d’Eclipse (voir Figure 4) que j’ai commencé à adapter
ces écrans. Pour ce faire et pour chaque écran, il est nécessaire de créer un nouveau template qui sera
basé sur l’ancien.
Un template (en français, gabarit) permet de concevoir le squelette de l’écran. Il définit la mise
en page, l’emplacement des données qui composeront l’écran. L’objectif d’un template est de
pouvoir créer uniquement l’interface graphique. L’intégration des données est indépendante.
Les données n’étant pas liées au rendu graphique, il est très facile de le modifier ou dans notre cas de
créer une version différente destinée à un autre support. Par la suite, Android sélectionnera
automatiquement le fichier template le mieux adapté pour le périphérique utilisé (mobile ou tablette).
Figure 4 Editeur d’interface graphique d’Eclipse
L’éditeur est découpé en 4 parties :
- En jaune, sont listés tous les composants graphiques qui sont utilisables comme par exemple : un
bouton, une zone de texte, une image, …
- La zone bleue, au centre, permet de visualiser et modifier, en temps réel, notre template.
- En vert, une liste de tous les éléments qui composent le template.
- Pour finir la zone rose permet d’accéder aux propriétés des composants tels que la taille, la
couleur, la position, …
13
Même si grâce à cet outil il est assez aisé de créer/modifier des interfaces graphiques pour son
application, il est nécessaire de savoir ce qu’il se passe derrière. En effet, cet éditeur permet
d’automatiser la manipulation d’un fichier de type XML.
Le XML (eXtensible Markup Language) est un langage qui repose sur un système de balise
permettant de hiérarchiser, structurer des données.
L’exemple de fichier XML ci-dessous (Figure 5) pourrait permettre de représenter le contenu d’un blog
(composé, ici, d’un seul article). Nous distinguons les différentes balises (<articles>, </articles>,
<titre>, </titre>, …) qui se trouvent entre des chevrons (<, >) et qui permettent d’imbriquer nos
informations pour lui donner du sens.
<articles> <article> <titre>Le titre de mon article</titre> <contenu>Le contenu de mon article</contenu> </article> </articles> Figure 5 Exemple de fichier XML
L’exemple ci-dessus est assez simple car il permet de structurer seulement du texte. En revanche, les
fichiers XML qui permettent de créer des interfaces graphiques sur Android sont beaucoup plus
complexes.
Pour développer ces nouveaux écrans j’ai eu de très fortes contraintes graphiques. En effet, le client
attache beaucoup d’importance au rendu graphique de l’application. Il a choisi de travailler avec un
graphiste pour élaborer le visuel de chaque écran de l’application. C’est donc avec les images fournis
par le graphiste que j’ai développé les nouveaux écrans.
Nous pouvons identifier trois phases de développement pour créer un nouvel écran :
1. Création de la mise en page (template)
2. Récupération des données depuis la source de stockage
3. Affichage des données dans le template
Comme nous utilisons un template pour la mise en page, il est possible de développer n’importe quelle
phase. Elles ne sont pas dépendantes les unes des autres.
14
3.2.3. Écrans de listage
Que ce soit pour afficher les différents devis, factures,
clients, …, de nombreuses fonctionnalités du PGI
nécessite un affichage sous forme de liste. Dès lors,
plusieurs écrans seront similaires et comporteront les
mêmes élements. Comme on peut le voir sur la Figure 6
ci-contre, on retrouve :
- Un champs de recherche permettant de filtrer les
documents par nom du client
- Une liste de document, avec pour chacun, différentes
informations et boutons
- Un menu filtre (voir Figure 7) pour affiner une
recherche
- Un menu d’édition rapide (Voir Figure 8) pour changer
rapidement le statut d’un document
Avec ces trois composants, j’ai pu créer les écrans permettant de
lister les éléments suivants :
- Devis, factures et bons de commandes
- Clients
- Note de frais
- Fiches travaux
Comme nous l’avons vu précédement, un template est construit
avec un fichier XML. Ce fichier va contenir tous les composants
graphiques nécessires à la mise en page des différentes informations. Regardons maintenant un
exemple de template (voir Figure 9 page suivante) qui est un élément d’une liste avec le fichier XML
associé. Comme ce fichier comporte plus de 300 lignes, j’afficherais seulement des extraits significatifs.
Figure 7 Capture illustrant un menu filtre
Figure 8 Capture du menu d'édition rapide d'un document
Figure 6 Capture de l’écran liste des facture (version mobile)
15
Figure 9 Template d'un élément d'une liste de devis
Le RelativeLayout est un composant de type conteneur qui permet de rassembler d’autres
composants en les plaçant de manière relative les uns par rapport aux autres.
Pour afficher une image ou une zone de texte, ce sont respectivement les composants ImageView et TextView qui sont utilisés. La propriété id permet d’identifier le composant de manière unique afin d’être manipulé par le code Java par la suite. C’est de cette manière que les informations seront insérées dans un template.
Il faut ensuite accéder aux composants à l’aide de leurs identifiants uniques que l’on a vu plus
haut (R.id.numero_devis représente l’identifiant du champ de texte qui contiendra le numéro du
devis) :
// Récupère le champ texte du numéro du devis TextView numero_devis = (TextView) template.findViewById(R.id.numero_devis);
Maintenant que nous avons accès à un champ texte il est possible de modifier sa valeur :
numero_devis.setText("N° 214525");
Nous définissons ici la valeur « en dur ». Dans le fonctionnement normal de l’application, cette valeur
sera définit dynamiquement avec les données de la base de donnée.
17
3.2.4. Écrans de consultation
Contrairement aux listes développées précédemment, les écrans de consultation permettent de
consulter en détail un élément tel qu’un devis.
Au niveau conception, ces écrans
utilisent les mêmes composants pour
afficher les informations.
On peut cependant noté qu’il est
possible d’utiliser un template à
l’intérieur d’un autre template. Par
exemple, la mise en page de l’écran
comporte des informations qui seront
communes à tous les devis telles que le
nom du client, son adresse, …
En revanche, pour les prestations, même
si elles respectent une certaines
structure, leurs nombres varient selon le
devis. C’est pourquoi la représentation
d’une prestation est faite dans un fichier
template différent.
Il est donc possible d’avoir autant de
prestations que nécessaire avec
seulement un template.
Figure 10 Ecran de consultation d'un devis
18
3.2.5. Point technique : Création d’un système de chargement des
données asynchrones
Asynchrone : Se dit d’une suite d’opérations qui ne s’effectuent par forcément à la suite les unes
des autres. Ces opérations peuvent être effectuées simultanément ou dans le désordre.
Afin de toujours posséder des informations à jour, les données ne sont pas stockées sur l’application.
En effet, au cours de la journée, l’application est utilisée par de nombreuses personnes qui
interagissent avec elle. Par exemple, quand un commercial est en rendez-vous avec un client il va
pouvoir accéder à la fiche client, consulter/créer/modifier des devis ou bons de commandes. Pour cela
il est nécessaire que les données soient centralisées sur un serveur auquel tous les commerciaux sont
connectés lorsqu’ils ont besoin du PGI.
Les avantages de posséder un serveur centralisé sont multiples :
- L’information est continuellement à jour
- L’information est disponible pour tout le monde au même moment
- L’information est disponible depuis plusieurs support (ordinateur, portable, tablette)
Il y a cependant un inconvénient, les données doivent être récupérées depuis le serveur à chaque
consultation. Cette récupération est plus moins longue selon la connexion utilisée. Si l’appareil Android
est connecté à internet via un réseau téléphonique, le transfert de données sera plutôt lent
contrairement à une connexion par Wifi, généralement plus rapide. Dans tous les cas, le délai de
récupération est perceptible par l’utilisateur.
Il est donc essentiel que ces données soient chargées rapidement. Si le volume des données est
important et génère un temps d’attente, l’utilisateur devra patienter. Faire patienter l’utilisateur
signifie que, lorsqu’il demande de l’information, il doit être prévenu que sa requête a été prise en
compte mais qu’elle nécessite un certain temps de traitement.
Lorsque que j’ai commencé le stage, l’application effectuait les requêtes de manière séquentielle et
synchrone. Il était alors impossible de faire deux requêtes simultanément (augmentation du temps de
chargement) et l’application se figeait pendant la durée de chargement. J’ai donc créé un système
permettant d’effectuer des requêtes de manière asynchrone.
Pour expliquer cela il faut d’abord comprendre ce qu’est un Thread.
Un Thread (en français, processus léger) est un fil d’exécution contenant des instructions qui
seront exécutées par l’ordinateur (plus précisément le processeur) dans un ordre défini et de
manière séquentielle.
Sur une application Android, il existe un Thread principal. Ce Thread remplit trois fonctions : exécuter
le programme de l’application (écrit par le développeur), prévenir le programme de l’interaction de
l’utilisateur avec le téléphone (appuie sur un bouton par exemple), et enfin gérer ce qui doit être
affiché à l’écran. Nous pouvons représenter cet ordonnancement de la manière suivante (Figure 11) :
19
Figure 11 Ordonnancement d’une application Android
Pour que l’application soit réactive, il faut que ces trois opérations soient effectuées en permanence
et en parallèle ce qui n’est pas possible à cause de limitations physiques. L’astuce est donc d’exécuter
une petite partie d’une opération (soit quelques instructions) et de laisser la main aux suivantes
beaucoup de fois par seconde. De cette manière, chaque opération prend plus de temps pour
s’exécuter complètement mais garanti d’avoir, à un instant T, un affichage à jour et une interface
graphique qui répond aux demandes de l’utilisateur.
Les instructions qui composent ces opérations sont insécables, elles ne peuvent pas être divisées ou
exécutées partiellement. C’est pourquoi si une instruction est très longue, elle bloque l’exécution des
suivantes et c’est toute l’application qui est bloquée, elle est dite «gelée ». Pour pallier ce problème il
est possible d’utiliser plusieurs Thread. On obtiendrait alors le fonctionnement suivant (Figure 12) :
Figure 12 Ordonnancement d’une application Android avec deux Threads
Le mécanisme avec deux Thread reste le même, seulement il y maintenant deux ordonnancements.
Application
Thread principale
Exécution du programme
Vérification des interactions
utilisateur
Gestion de l’affichage
Application
Thread secondaire
Thread principale
Exécution du programme
Gestion de l’affichage
Vérification des interactions
utilisateur
Instructions
longues
Opération longue terminée
Début opération longue
20
Le premier à l’intérieur de chaque Thread et le deuxième entre les Threads eux-mêmes. De cette
manière si le Thread secondaire est bloqué le temps d’une longue instruction le Thread principal et lui
toujours actif.
Sur Android l’outil permettant de créer ce Thread est la classe AsyncTask (comprenez tâche
asynchrone).
Une classe est un élément de programmation qui permet de réunir des variables et des fonctions
(appelées méthodes) de manière cohérente. Cela permet de créer des types de données
complexes. Par exemple la classe nommée Personne aura comme attributs : nom, prénom, date
de naissance, et des fonctions pour définir et récupérer ces informations, calculer l’âge en
fonction de la date de naissance, etc.
AsyncTask est une classe abstraite qui facilite la création de Thread dans le but d’effectuer des tâches
de manière asynchrone (en arrière-plan).
Une classe abstraite permet de définir des variables et fonctions qui seront utilisées par d’autres
classes par héritage. Par exemple les classes Étudiant et Enseignant hériteront de la classe
personne pour posséder les variables et fonctions commune à une personne.
Dans la suite, je vais présenter, pas à pas, le système que j’ai mis en place à travers un exemple : la
classe RecupDevis qui permet de récupérer une liste de devis depuis la base de données.
Pour utiliser les fonctionnalités proposées par l’AsyncTask, il faut créer une nouvelle classe qui
va hériter d’AsyncTask. De cette manière, cette nouvelle classe va détenir toutes les méthodes et
variables de l’AsyncTask.
public class RecupDevis extends AsyncTask<String, Void, List<DevisDTO>> { protected List<DevisDTO> doInBackground(String... args) { // Code permettant la récupération des devis depuis la base de données } }
AsyncTask est une classe qui comporte de la généricité, c’est-à-dire que c’est le développeur qui va
définir le type de donnée (la classe) lorsqu’il va écrire son programme. Ici, la classe RecupDevis hérite
de la classe AsyncTask (c’est le mot clé extend qui nous l’indique) avec comme types de données :
<String, Void, List<DevisDTO>>.
String (chaine de caractère) : Type de la donnée qui sera passée en paramètre lors de
l’exécution de la tâche asynchrone.
Void (mot clé qui veut dire vide ou nulle) : On l’ignore car ce n’est pas utile dans notre cas.
List<DevisDTO> (liste d’objet de type DevisDTO) : Type de la donnée qui sera retournée à la fin
de l’exécution.
La méthode doInBackground retourne donc une liste de devis et prend en paramètre des chaines de
caractères (la notation String... permet d’autoriser zéro ou plusieurs arguments de type String lors
de l’appel de cette méthode). Cette chaine de caractère sera utilisée pour filtrer les devis par nom du
client. Cette méthode sera donc appelée avec comme argument un nom de client, elle effectuera
ensuite la récupération de devis en arrière-plan et retournera une liste de devis.
Figure 17 Résultat du développement web de l'écran "récapitulatif des rendez-vous de la semaine" 31
37
Annexe 2 : Journal de bord
Lundi 31 mars
Arrivé dans l’entreprise, rapide présentation de mes deux missions de stage : o Continuation du développement de la version mobile de l’ERP (android) o Continuation du développement de la version web de l’ERP (J2EE)
Première tâche : adapter des écrans (interfaces) existants de l’application mobile pour les tablettes (les écrans pour les smartphones étant déjà faits)
Installation des outils de développement pour android.
Premier contact avec android. Apprentissage du fonctionnement général.
Prise en main d’eclipse et de l’éditeur graphique pour la création d’interface graphique pour android Mardi 1 avril
Continuation de l'adaptation des écrans
Création d’un nouvel écran “Liste des contacts clients” et programmation de celui-ci pour récupérer et afficher les données depuis un service web existant.
Prise en main de l’application et du code existant
Apprentissage de l’outil de débogage d’Eclipse
Mercredi 2 avril
Programmation de l’écran “Liste des contacts”
Listage et affichage des clients : ok
Installation et utilisation d’un émulateur virtuel de périphérique Android (GenyMotion)
Jeudi 3 avril
Continuation de l’implémentation de l’écran « liste contacts »
Récupération des contacts depuis le service web
Affichage des clients sous forme de liste (avec un template)
Champ texte pour rechercher les clients par nom
Filtrage des clients par type : client ou prospect
Commencement du filtre pour filtrer par source, type de source, et type de client (moral, physique)
Vendredi 4 avril
Continuation de l’implémentation de l’écran « liste contacts »
Lundi 7 avril
Continuation de l’implémentation de l’écran « liste contacts » o Corrections graphiques
Mardi 8 avril
Continuation de l’implémentation de l’écran « liste contacts »
Ajout du bouton pour appeler le client. Affichage de tous les numéros.
Implémentation d’un menu pour filtrer les clients par appartenance aux commerciaux et rattachement d’agence.
Implémentation de contraintes pour la gestion des droits
38
Mercredi 9 avril
Continuation de l’implémentation de l’écran « liste contacts »
Finition graphique
Ajout d’un module google map pour visualiser l’adresse du client
Adaptation de l’écran d’accueil pour être optimisé tablette
Commencement d’un nouvel écran : Liste des contacts/devis/bons de commandes Jeudi 10 avril
Création des templates pour le nouvel écran liste des devis
Création des adapter pour afficher les données dans le template
Vendredi 11 avril
Continuation de l’écran « liste des devis »
Implémentation d’un “swipe” sur les devis pour accéder à des options d’édition et de validation rapide Lundi 14 avril
Continuation de l’écran « liste des devis »
Récupération des différents types de document (devis, factures, bdc)
Ajout d’un menu pour filtrer les devis par agence, commerciaux rattachés, état du document… Mardi 15 avril
Continuation de l’écran liste des devis
Ajout d’une zone de recherche pour rechercher des documents par nom de client
Mercredi 16 avril
Continuation de l’écran liste des devis
Prise en main de la partie serveur avec le serveur applicatif JBOSS
Création de nouveaux services web JSON
Jeudi 17 avril
Restructuration de l’application. Passage d’un mode de requête synchrone et bloquant à un mode événementiel et donc asynchrone.
Vendredi 18 avril
Création d’une classe générique pour gérer une “progress dialog” (fenêtre de chargement)
Mardi 22 avril
Intégration du système de chargement dans la nouvelle architecture sur les anciens écrans
Mercredi 23 avril
Création de l'écran : « liste des notes de frais »
Jeudi 24 avril
Continuation de l’écran « liste des notes de frais »
Vendredi 25 avril
En cours de finalisation de l’écran note de frais (affichage des listes)
Adaptation d’écrans développés sur mobile pour tablette.
Lundi 28 avril
Corrections de bugs sur l'écran ndf
Adaptation écran « agenda » (suite) pour tablette
39
Mardi 29 avril
Finalisation de l’adaptation de l’écran agenda
Adaptation du module de statistiques et objectifs affichés sur l’écran d’accueil
Mercredi 30 avril
Commencement de la partie affichage du détail d'une facture/devis/bdc.
Vendredi 2 mai
Corrections mineures dans le listage des factures/devis/bdc
Continuation de l’écran pour la consultation d’une facture/devis/bdc
Lundi 5 mai
Continuation de l’écran pour la consultation d’une facture/devis/bdc
Création du template
Récupération des informations depuis la BDD
Mardi 6 mai
Continuation de l’écran pour la consultation d’une facture/devis/bdc
Affichage des informations dans le template Mercredi 7 mai
Continuation de l’écran pour la consultation d’une facture/devis/bdc
Mise en forme graphique des informations
Vendredi 9 mai
Finition de l'écran consultation de devis/bdc/factures
Adaptation de cet écran sur mobile
Lundi 12 mai
Début de la partie Web
Prise en main du projet
Prise en main de JSF
Prise en main des EJB
Début de création d'un nouvel écran ; planning des techniciens. Cet écran est prévu pour être afficher sur une télé
Mardi 13 mai
Continuation template planning techniciens
Création du template écran classement prospecteur
Mercredi 14 mai
Continuation de l’écran téléprospecteurs
Création du template activité jour
Jeudi 15 mai
Continuation de l’écran activité jour Vendredi 16 mai : Participation à la compétition : 24h des IUT Informatiques Lundi 19 mai
Intégration des données dans l’écran activité jour
40
Mardi 20 mai
Intégration des données dans l’écran activité jour
Mercredi 21 mai
Corrections graphiques « écran activité jours »
Jeudi 22 mai
Intégration des données dans l’écran classement prospecteur
Vendredi 23 mai
Corrections sur l’écran activité jour Lundi 26 mai
Création d’un guide utilisateur pour le CRM SugarCRM. Cette documentation sera utilisée pour une formation donnée par AXOPEN.
o Prise en main du CRM SugarCRM
Mardi 27 mai
Continuation de la documentation utilisateur Mercredi 28 mai
Continuation de la documentation utilisateur
Création de fonctionnalités avancées pour SugarCRM avec PHP
Enregistrement automatique d’événements
Envoi d’emails automatisé
Jeudi 29 mai : Ascension Vendredi 30 mai
Continuation de la documentation utilisateur Lundi 2 juin
Finition graphique sur l’écran activité jour
Ajout d’une nouvelle fonctionnalité : affichage des rdv en conflit sur plusieurs lignes
Mardi 3 juin
Création d’un nouvel écran : Récapitulatif des rendez-vous commerciaux de la semaine
Mercredi 4 juin
Continuation écran : Récapitulatif des rendez-vous commerciaux de la semaine
Jeudi 5 juin
Continuation et finition de l’écran : Récapitulatif des rendez-vous commerciaux de la semaine
Vendredi 6 juin
Test des écrans pour rechercher d’éventuels bugs et correction si nécessaire.