Embed Size (px)
Citation preview
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.
Mots clés PGI, Android, Java EE, JSF.
3
Sommaire
1. Introduction ................................................................................................................................... 4
1.1. Choix de ce stage .................................................................................................................... 4
1.2. Mes attentes .......................................................................................................................... 4
1.3. Les deux sujets de stage ......................................................................................................... 4
2. Présentation de l’entreprise ........................................................................................................... 5
2.1. Création de l’entreprise .......................................................................................................... 5
2.2. Produit et service.................................................................................................................... 5
2.3. Clientèle ................................................................................................................................. 6
2.4. Organigramme........................................................................................................................ 7
3. Mes missions .................................................................................................................................. 8
3.1. L’existant ................................................................................................................................ 9
3.1.1. Architecture du PGI ........................................................................................................ 9
3.2. Développement de nouveaux écrans pour l’application Android......................................... 10
3.2.1. Outils, matériels et technologies .................................................................................. 11
3.2.2. Prise en main d’Android ............................................................................................... 12
3.2.3. Écrans de listage ........................................................................................................... 14
3.2.4. Écrans de consultation .................................................................................................. 17
3.2.5. Point technique : Création d’un système de chargement des données asynchrones ... 18
3.3. Développement de nouveaux écrans pour l’application web .............................................. 25
3.3.1. Outils et technologies ................................................................................................... 25
3.4. Prise en main de J2E ............................................................................................................. 26
3.4.1. Le framework JSF .......................................................................................................... 26
3.1. Les EJB .................................................................................................................................. 28
3.2. Création de nouveaux écrans ............................................................................................... 29
4. Bilan du stage ............................................................................................................................... 32
4.1. Bilan professionnel ............................................................................................................... 32
4.2. Bilan personnel ..................................................................................................................... 32
4.3. Bilan technique ..................................................................................................................... 33
5. Conclusion .................................................................................................................................... 34
6. Références .................................................................................................................................... 35
7. Annexes ........................................................................................................................................ 36
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.
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="match_parent" android:layout_height="115dp" >
ImageButton permet d’afficher un bouton sous forme d’image. Cette image est renseignée par la
propriété src. Ce bouton est placé en haut à droite du RelativeLayout (alignParentTop="true" et
alignParentRight="true"). La taille de ce bouton sera ajusté à la taille de l’image (valeur
"wrap_content" pour la largeur et hauteur).
<ImageButton android:id="@+id/item_devis_edit_envoyer_btn" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_alignParentTop="true" android:layout_alignParentRight="true" android:src="@drawable/ic_button_envoyer_tablette" />
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.
<ImageView android:id="@+id/imageView4" android:layout_width="15dp" android:layout_height="15dp" android:layout_alignParentLeft="true" android:layout_alignParentTop="true" android:src="@drawable/img_devis_no" /> <TextView android:id="@+id/numero_devis" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_alignRight="@+id/imageView3" android:layout_alignTop="@+id/imageView4" android:layout_toRightOf="@+id/imageView4" android:text="N° 214524" />
</RelativeLayout>
299
6 7 8 9 33 34 35 36 37 38 39 40 41 42 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 299 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151
33 34 35 36 37 38 39
114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 299 132 133 134 135 136 137 138 139 140
16
Contenu dans une liste, ce template permet de représenter le devis d’un client. Il sera donc dupliqué
autant de fois qu’il y a de devis à afficher et rempli avec les bonnes informations.
Intéressons-nous maintenant au code Java permettant de remplir le template.
La première chose est la récupération du template d’un élément devis (on dit qu’on "inflate" le
template). Il est identifié par le nom de son fichier XML
View template = getLayoutInflater().inflate(R.layout.template_item_devis);
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.
Regardons maintenant comment exécuter notre tâche:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34
21
RecupDevis recupDevis = new RecupDevis(); recupDevis.execute("dupont");
La première ligne déclare une variable nommé recupDevis qui est du type RecupDevis.
La deuxième ligne appelle la méthode execute qui ne retourne rien. Cette méthode appartient à la
classe AsyncTask et donc par héritage est aussi disponible pour la classe RecupDevis. Cette méthode
va simplement appeler la méthode doInBackground que nous avons défini plus haut.
Pourquoi alors ne pas appeler directement la méthode doInBackground de cette manière :
maListeDeDevis = recupDevis.doInBackground("dupon"); ?
Rappelez-vous, la méthode doInbackground retourne une liste de devis. Si on utilise l’instruction ci-
dessus pour récupérer nos devis, il faudrait attendre que la variable maListeDeDevis contiennent les
devis mais cela ne pourra être vrai que lorsque la méthode doInBackground se terminera et donc que
la récupération aussi. Or, notre but est de le faire de manière asynchrone. C’est pourquoi nous utilisons
la méthode execute qui va créer un nouveau Thread, lancer l’opération de récupération et
directement rendre la main au Thread principal. La question qui se pose maintenant est comment
récupérer les devis une fois qu’ils seront téléchargés et comment en être averti ?
L’AsyncTask met à disposition une méthode onPostExecute qui fournit en paramètre les données
retournées par doInBackground. Cette méthode est donc appelée lorsque doInBackground sera
terminée. Comme cette méthode se trouve à l’intérieur de la classe AsyncTask (et donc disponible
depuis notre classe RecupDevis) elle n’est pas très flexible dans son utilisation. En effet, si l’on
souhaite effectuer des traitements ou utiliser les devis retournés il faudrait le faire au sein de la classe
RecupDevis et cela n’est pas gérable car cette classe est utilisée dans de nombreux contextes
différents qui ne sont pas forcément connus à l’avance.
C’est pourquoi j’ai mis en place un système de callback (en français, fonction de rappel ou de post-
traitement) qui va permettre de passer en paramètres, à notre classe RecupDevis, les actions à faire
sur les données une fois qu’elles seront disponibles.
Pour cela j’ai tout d’abord créé deux interfaces : Callbackable et Callback dont voici les
déclarations :
Une interface est une classe qui comporte seulement la définition de fonctions sans instructions
à l’intérieur. Elle ne comporte donc aucunes variables. Les interfaces sont utilisées pour définir
un comportement. Par exemple, on pourrait créer l’interface marcher qui définirait la fonction
« avancer pied droit » et « avancer pied gauche ». La classe Etudiant implémenterait4 alors
l’interface marcher. Il ne resterait plus qu’à écrire les instructions de ces deux méthodes au sein
de la classe Etudiant pour qu’il soit capable de marcher.
public interface Callbackable<T> { public void executeCallback(T param); public void setCallback(Callback<T> cb); public void removeCallback(); }
4 Implémenter une interface permet d’indiquer que les méthodes définies dans cette interface sont codés dans la classe qui l’implémente.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56
22
La première interface Callbackable va permettre d’indiquer aux classes qui implémenteront cette
interface, qu’elles sont capables de gérer le comportement de fonction de rappel. Pour cela la classe
devra définir le corps des méthodes :
setCallback : Définit le callback (passé en argument)
removeCallback : Supprime un callback s’il existe
executeCallback : Exécute le callback. De manière générale cette fonction sera appelée
automatiquement
public interface Callback<T> { public void onFinish(T data); }
Pour la deuxième interface, Callback ne comporte qu’une méthode : onFinish qui prend un
argument de type générique (T est utilisé pour représenter la généricité) qui sera les données
renvoyées par doInBackground. Par conséquent, le type générique T correspondra au type de retour
de la fonction doInBackground qui est dans notre cas List<DevisDTO>. Les instructions qui seront à
l’intérieur de la méthode onFinish seront celles qui seront exécutées lorsque le callback sera appelé.
Regardons maintenant comment sont utilisés et implémentés les interfaces Callbackable et
Callback au sein de notre classe RecupDevis.
public class RecupDevis extends AsyncTask<String, Void, List<DevisDTO>> implements Callbackable<List<DevisDTO>> { Callback<List<DevisDTO>> mCallback; public RecupDevis(Callback<List<DevisDTO>> callback) { mCallback = callback; } protected List<DevisDTO> doInBackground(String... nom) // Code permmetant la récupération des devis depuis la base de données } protected void onPostExecute(List<DevisDTO> result) { executeCallback(result); } public void setCallback(Callback<List<DevisDTO>> cb) { mCallback = cb; } public void removeCallback() { mCallback = null; } public void executeCallback(List<DevisDTO> param) { if (mCallback != null) mCallback.onFinish(param); } }
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43
23
Ligne 1 à 3 : Déclaration de la classe avec l’héritage depuis la classe AsyncTask et
l’implémentation de notre classe abstraite Callbackable
Ligne 5 : Déclaration d’une variable qui contiendra le callback
Ligne 7 à 9 : Constructeur de la classe permettant de créer un objet de type RecupDevis en
passant en paramètre un callback
Ligne 15 à 17 : La méthode onPosteExecute sera automatiquement appelée à la fin de la
méthode doInBackround. Cette méthode ne fait qu’appeler la méthode executeCallback
définit plus bas.
Ligne 27 à 32 : La méthode executeCallback appelle la méthode onFinish du callback si elle
a été préalablement définie.
Nous avons maintenant tout ce qu’il faut pour effectuer une récupération de devis de manière
asynchrone tout en ayant accès aux devis une fois qu’ils seront disponibles. Le code permettant la
récupération est le suivant :
Callback<List<DevisDTO>> callback = new Callback<List<DevisDTO>> { public void onFinish(List<DevisDTO> listeDevis) { // Code utilisant les devis
afficherLesDevis(listeDevis); } }; new RecupDevis(callback).execute();
Ligne 1 à 7 : Créer un objet de type callback en définissant la méthode onFinish pour qu’elle
affiche la liste de devis.
Ligne 9 : Créer un objet de type RecupDevis en passant en paramètre le callback définit au-
dessus puis appelle la méthode execute.
Maintenant que tout est en place, lorsque l’application va exécuter l’instruction ligne 9, un nouveau
Thread va être créé pour exécuter la méthode doInBackground. Lorsque cette méthode retournera la
liste de devis, elle appellera la méthode onFinish de notre callback qui affichera les devis.
Pour atteindre notre objectif, faire patienter l’utilisateur, il ne manque plus qu’un élément : prévenir
l’utilisateur qu’une récupération de données est en cours et, petit plus mais important pour
l’utilisateur, afficher précisément quelles sont ces données. Pour cela j’ai développé séparément un
autre système permettant d’afficher une boite de dialogue. Cette boite de dialogue affiche une
animation de chargement et indique le nom de la donnée en cours de récupération (voir Figure 13 et
Figure 14 page suivante).
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46
24
J’ai créé ces systèmes de callback et de boite de dialogue de la manière la plus générique possible ce
qui les rend adaptables et réutilisables dans de nombreux contextes différents. Ils ont notamment été
réutilisés pour d’autres tâches au sein de l’application.
Figure 14 Boite de dialogue durant la connexion Figure 13 Boite de dialogue durant le chargement de liste des bons de commandes
25
3.3. Développement de nouveaux écrans pour l’application web
3.3.1. Outils et technologies
- Java Enterprise Edition (J2E)
J2E est une extension du langage Java qui apporte de nombreuses fonctionnalités notamment pour
des applications de taille importante. En réalité, J2E ne fait que définir/décrire ces fonctionnalités. Pour
en profiter, il faut utiliser un serveur d’application qui en fournira une implémentation.
JE2 est essentiellement utilisée pour le web avec un serveur applicatif.
- Serveur d’application JBoss
JBoss est un serveur d’application qui implémente les fonctionnalités décrites par J2E. Il est, entre
autre, utilisé pour exposer des pages web sur internet.
- Langage XHTML et CSS
Extensible HyperText Markup Language (XHTML) est un langage du web permettant de structurer une
page web. Ce langage est basé sur XML et utilise le CSS pour mettre en forme, styliser une page web.
- Eclipse
Comme pour la partie Android, j’ai continué à développer avec l’EDI Eclipse qui propose beaucoup
d’outils et de plugins permettant de faciliter le développement avec J2E.
26
3.4. Prise en main de J2E
3.4.1. Le framework JSF
JavaServer Faces (JSF) est un framework MVC utilisé pour concevoir des applications web.
Modèle – Vue – Contrôleur (MVC) est une bonne pratique de programmation qui propose de
séparer le contenu de la forme. Plus précisément, on distingue la Vue qui correspond à la mise
en page, le visuel (grâce au template, par exemple), le Modèle qui est équivalent à l’accès aux
données (utilisation d’une base de données, par exemple) et le contrôleur qui permet de faire le
lien entre les données et la Vue en fonction des requêtes de l’utilisateur.
De la même manière que l’on a vue pour la partie Android, un système de template est utilisé pour la
mise en page des informations. Il existe tout de même une différence dans l’utilisation de ces
templates.
Avec Android, nous avons vu qu’un template est un fichier XML où chaque composant est identifié
de manière unique pour être mis à jour via le code Java. Avec JSF, ce ne sont pas des fichiers XML
mais XHTML qui sont utilisés pour concevoir un template.
Comme Android, le framework JSF propose un ensemble de composants prêts à l’emploi pour
concevoir une application ou un site web. Nous pouvons cependant noter deux différences.
Premièrement ces composants ne proposent aucun style de base : les interfaces créées seront brutes
et peu conviviales. La deuxième différence est la manière dont le template est rempli par les
données. Les composants ne comportent pas un identifiant unique mais intègrent une référence vers
une variable présente dans le code. Schématiquement cette différence pourrait se traduire de cette
manière :
Template avec Android Template avec JSF
Template
(XML)
Code Java
Zone de texte
Future
donnée de la
zone de texte
Je suis la zone de
texte 1
Je dois mettre
cette donnée dans
la zone de texte 1
Template
(XHTML)
Code Java
Zone de texte Donnée 1
destiné à la
zone de texte
Je veux la valeur
de la donnée 1
27
Comme aucun stylen’est présent de base, PrimeFaces est utilisé en plus du framework JSF.
PrimeFaces est une bibliothèque de composants proposant plus de fonctionnalités et surtout
plusieurs thèmes graphiques. L’utilisation d’un thème existant permet de faire gagner du temps tout
en ayant un bon rendu graphique. Par exemple, les deux tableaux ci-dessous sont identiques. Celui
de gauche n’est pas stylisé tandis que celui de droite l’est avec PrimeFaces.
Cependant, comme nous le verrons dans la partie 3.6, les écrans que j’ai développés devaient
respecter une charte graphique très stricte. Je n’ai pas beaucoup eu recourt à l’utilisation de
composants PrimeFaces.
Regardons maintenant comment la page web va s’afficher à l’écran de l’utilisateur à partir de notre
template. Alors que le navigateur de l’utilisateur demande une page au format XHTML5, notre
template, lui, est formé de composant issues du framework JSF ou de PrimeFaces et non des
composants de type XHTML. Il y a donc une étape de conversion qui est effectuée par le framework
JSF pour transformer le template en une page web au bon format à chaque fois qu’un client
demande une page. Pour le tableau ci-dessus, le template est le suivant :
<f:dataTable value="#{donneeBean.famille}" var="personne"> <f:column> <f:facet name="header">Name</f:facet> <f:outputText value="#{persone.nom}"> </f:column> <f:column> <f:facet name="header">Role</f:facet> <f:outputText value="#{persone.role}"> </f:column> <f:column> <f:facet name="header">Age</f:facet> <f:outputText value="#{persone.age}"> </f:column> <f:dataTable>
Ici, c’est le composant dataTable du framework JSF qui est utilisé : il permet d’afficher un tableau de
données. La liste des données est passée par le paramètre value="#{donneeBean.famille}" et
chaque élément de cette liste sera accessible par la variable nommée personne. Le composant
column représente une colonne du tableau. A l’intérieur de celui-ci se trouve le composant facet
avec comme paramètre name="header" permettant de donner un titre en haut de la colonne (ici les
titres sont Name, Role et Age). Enfin l’élément outputText permet simplement d’afficher un texte
dont la valeur est passée en paramètre.
5 Un navigateur accepte plusieurs formats de page web : HTML, XHTML, XML, … Dans notre cas c’est du XHTML
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38
28
<table border="1"> <thead> <th>Name</th> <th>Role</th> <th>Age</th> </thead> <tbody> <tr> <td>Homer Simpson</td> <td>The father</td> <td>48</td> </tr> <tr> <td>Lisa Simpson</td> <td>Sister of Bart</td> <td>8</td> </tr> </tbody> </table>
Le code XHTML ci-dessus est le résultat obtenu après conversion par le framework JSF. On retrouve
bien l’élément table qui, en XHTML, permet d’afficher un tableau. Ainsi que les éléments tr et td
permettant respectivement d’afficher des colonnes et des lignes dans ce tableau.
Regardons comment les données sont liées avec le template. Dans le template, nous avons vu cette
notation : #{unNomDeVariable} que l’on appelle une expression langage (EL). Elle permet d’accéder à
la valeur des différentes variables présentes dans les EJB que nous allons voir dans la partie suivante.
3.1. Les EJB
Les Enterprise JavaBeans (EJB) sont des composants utilisés par Java EE pour développer la couche
métier d’une application. La couche métier correspond à la partie logique de l’application : c’est elle
qui décrit les opérations que l’application opère sur les données.
Dans le code de l’application, les EJB sont des classes Java qui comportent l’ensemble des variables et
méthodes qui seront utilisées pour récupérer, trier et stocker les données. Ce sont donc ces variables
qui seront désignées par les expressions langages vues précédemment.
Les EJB ont la particularité d’avoir leur cycle de vie géré automatiquement par le serveur applicatif
(dans notre cas JBoss). L’avantage est de pouvoir sauvegarder, dans le temps, les données relatives à
une page web. S’il n’y avait pas de gestion du cycle de vie, la durée de vie des données serait limitée à
la durée de leur traitement suite à la requête d’un utilisateur.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66
23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75
29
3.2. Création de nouveaux écrans
Les écrans que j’ai développés pour la partie web sont tous des écrans dit « d’affichage » c’est-à-dire
qu’ils seront affichés sur une télévision dans les locaux du client. Il n’y a donc aucune interaction avec
un utilisateur, les informations sont rafraichies automatiquement chaque minute.
De même que pour l’application Android, ces écrans ont été préalablement élaborés par un graphiste.
Cet écran permet de connaitre en temps réel les rendez-vous des commerciaux avec les prospects ainsi
que le statut des rendez-vous (honoré, reporté, etc). La ligne verticale orange représente l’heure
actuelle et facilite la lecture de l’écran.
Quand j’ai développé cet écran, chaque commercial ne pouvait avoir qu’un seul rendez-vous à un
instant T. Après coup, le client a demandé une évolution pour pouvoir superposer plusieurs rendez-
vous. Il m’a donc fallu modifier cet écran pour détecter les rendez-vous en conflit afin de pouvoir les
afficher sur plusieurs lignes.
Ecran 1 : Planning de la journée des commerciaux
Ecran 2 : Classement des prospecteurs
30
L’écran classement des prospecteurs propose deux classements : le premier sur la journée pour les
téléprospecteurs avec le nombre de rendez-vous obtenus par chacun. Le deuxième est un
classement sur le mois pour des prospections réalisées par les téléprospecteurs, commerciaux, et
commerciaux porte à porte.
Cet écran a été très intéressant à développer du point de vue algorithme. En effet, il y a beaucoup de
traitements à effectuer avant de pouvoir lister, de manière ordonnée, les différents commerciaux en
fonction du nombre de rendez-vous qu’ils ont obtenu. De plus, le nombre de rendez-vous étant
important sur un mois entier, j’ai dû faire en sorte que l’algorithme soit relativement optimisé par
souci de rapidité.
Cet écran, permettant de récapituler les rendez-vous de la semaine, a déjà été développé mais était
assez basique (voir Figure 15). Sur la première version, les rendez-vous étaient représentés par un
rectangle blanc et le récapitulatif du nombre de rendez-vous pour chaque journée était présent en
bas du tableau.
Figure 15 Ancienne version de l'écran "récapitulatif des rendez-vous de la semaine"
Après livraison de l’écran, le client a demandé une évolution de celui-ci. Dès lors, j’ai reçu le visuel du
nouvel écran créé par le graphiste (voir Figure 16 page suivante).
Cette évolution apporte beaucoup plus de précision. En effet, les nombres de rendez-vous sont
affichés pour chaque heure, pour chaque partie de la journée et pour chaque agence. Il est
également plus visuel grâce aux petites barres de progression verticale.
La Figure 17 (page suivante) montre la version finale.
Ecran 3 : Récapitulatif des rendez-vous de la semaine
31
Figure 16 Visuel de la nouvelle version de l'écran "récapitulatif des rendez-vous de la semaine" par le graphiste
Figure 17 Résultat du développement web de l'écran "récapitulatif des rendez-vous de la semaine"
32
4. Bilan du stage
4.1. Bilan professionnel
Sur le plan professionnel ce stage a été très enrichissant. En effet, ce premier contact avec l’entreprise
m’a permis de mieux appréhender le fonctionnement d’une SS2I.
Durant mes missions il y a eu de nombreuses mises en production. En conséquence, certaines tâches
devaient être terminées avant la date de livraison. Même si cela pouvait occasionner de la pression,
ces contraintes de temps étaient motivantes et forçaient à travailler rapidement sans pour autant
négliger la qualité.
Avoir travaillé sur un progiciel de gestion intégrée m’a permis d’en apprendre un peu plus sur la
comptabilité et la gestion financière d’une entreprise. Le fait de travailler sur un projet dans un
domaine d’activité spécifique autre que l’informatique est un aspect très intéressant et formateur.
J’ai également apprécié, selon les missions, d’avoir pu travailler en autonomie ou en équipe. Sur le
plan relationnel, la collaboration et la communication se sont très bien passées avec l’ensemble de
l’équipe d’AXOPEN. La bienveillance de chacun et la bonne ambiance régnantes chez AXOPEN y ont
fortement contribuées.
4.2. Bilan personnel
Les différentes missions que j’ai accomplies au cours de ce stage ont confirmé ma capacité à m’adapter
très rapidement face à une nouvelle technologie. Elles ont également affirmé ma motivation et mon
plaisir d’apprendre.
La mise en production fréquente des applications m’a permis de découvrir, au fur et à mesure, le travail
accompli et son utilisation par le client, ce qui a été très valorisant pour moi.
Je termine ce stage très satisfait et fier du travail que j’ai accompli.
33
4.3. Bilan technique
Techniquement ce stage a été très formateur. En effet, j’ai eu l’opportunité d’apprendre à développer
avec deux technologies : Java EE et Android, ayant chacune actuellement, et dans les années à venir,
un très fort potentiel. De plus, ces deux technologies utilisent le langage Java que j’apprécie tout
particulièrement et avec lequel je souhaite travailler plus tard.
Vient s’ajouter à l’apprentissage de ces technologies, l’utilisation de l’environnement de
développement Eclipse que je n’avais encore jamais utilisé. A travers Eclipse, j’ai appris à utiliser un
débuggeur qui est incontestablement un outil indispensable pour développer. Lors des phases de tests
et de recherche de bugs, le débuggeur permet d’économiser beaucoup de temps et de patience.
En plus d’être à l’aise avec ces deux technologies, j’ai également eu la chance de pouvoir étudier
l’architecture d’une application de taille relativement importante par rapport à ce que j’ai pu
connaître. Très formateur, j’ai pu en tirer quelques pistes qui me permettront, à l’avenir, de penser
différemment la conception d’une application.
34
5. Conclusion
Pour résumer les grandes étapes de mon stage, voici une liste des objectifs que j’ai atteints :
- Contribution à l’application Android du PGI
o Création de nouveaux écrans pour tablette et mobile o Création et mise en place d’un système de chargement asynchrone des données
- Contribution à l’application Web du PGI : création de nouveaux écrans
- Contribution à une documentation utilisateur pour le CRM SugarCRM
Que ce soit sur le plan personnel, technique ou professionnel, ce stage a été très positif. J’ai acquis de
nouvelles compétences en informatique et professionnellement parlant. Je pense avoir atteint tous
les objectifs et attentes que je m’étais fixés.
Pour conclure, ce stage a confirmé et a été en parfaite adéquation avec mon projet professionnel.
J’intégrerai donc, à l’issue du DUT, la Licence 3 en Informatique pour me diriger, par la suite, vers le
Master Technologie de l’Information.
35
6. Références
- Icones Pro, Bibliothèque d’images libres de droits au format PNG, www.icones.pro
- Développez, Tutoriels informatiques, www.developpez.com
- Axopen, Site internet d’AXOPEN, www.axopen.com
36
7. Annexes
Annexe 1 : Liste des figures
Figure 1 Offres proposées par AXOPEN .................................................................................................. 5
Figure 2 Clients d'AXOPEN...................................................................................................................... 6
Figure 3 Architecture simplifié du PGI .................................................................................................... 9
Figure 4 Editeur d’interface graphique d’Eclipse .................................................................................. 12
Figure 5 Exemple de fichier XML .......................................................................................................... 13
Figure 6 Capture de l’écran liste des facture (version mobile) ............................................................. 14
Figure 7 Capture illustrant un menu filtre ............................................................................................ 14
Figure 8 Capture du menu d'édition rapide d'un document ................................................................ 14
Figure 9 Template d'un élément d'une liste de devis ........................................................................... 15
Figure 10 Ecran de consultation d'un devis .......................................................................................... 17
Figure 11 Ordonnancement d’une application Android ....................................................................... 19
Figure 12 Ordonnancement d’une application Android avec deux Threads ........................................ 19
Figure 13 Boite de dialogue durant le chargement de liste des bons de commandes ......................... 24
Figure 14 Boite de dialogue durant la connexion ................................................................................. 24
Figure 15 Ancienne version de l'écran "récapitulatif des rendez-vous de la semaine" ........................ 30
Figure 16 Visuel de la nouvelle version de l'écran "récapitulatif des rendez-vous de la semaine" par le
graphiste .............................................................................................................................................. 31
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.
