Projet de groupe 2013 Application Android Phelma - Projet 58 - Sous la direction de Luc Salvo

 
CONTINUER À LIRE
Projet de groupe 2013 Application Android Phelma - Projet 58 - Sous la direction de Luc Salvo
Louis Drouard - Niels Grataloup
Vincent Guiu - Antoine Le Breton
Rémy Mansour

                     Projet de groupe 2013
                   Application Android Phelma
                    Projet 58 - Sous la direction de Luc Salvo

                     Projet de groupe numéro 58 – 2012-2013 – Application Android Phelma - 1/20
Projet de groupe 2013 Application Android Phelma - Projet 58 - Sous la direction de Luc Salvo
Les technologies de l’information sont aujourd’hui primordiales dans le monde de l’éducation car elles
permettent de rendre les connaissances accessibles en permanence. Dans le cadre du groupe Grenoble-
INP, ses écoles s’appuient sur un outil commun appelé Dokeos/Chamilo, qui permet aux enseignants de
communiquer à grande échelle les supports de cours mais aussi de tester les connaissances des élèves
au travers de QCM en ligne. Toutefois, la démocratisation des smartphones a rendu nécessaire de
pouvoir porter facilement le contenu de cette plateforme Internet sur le téléphone. Pour cela, des
élèves de PMP ont réalisé une première application pour téléphone Android l’année précédente.
L’objectif de notre projet était donc de reprendre le code existant pour améliorer l’expérience de
l’utilisateur selon les souhaits du maître d’oeuvre Luc Salvo.

Sommaire

Table des matières
                           Sommaire...........................................................................................2
                           Objectifs du projet...............................................................................3
                           Cahier des charges.............................................................................3
                           Amélioration de l'ergonomie................................................................3
                           Amélioration de l'interactivité des questionnaires................................4
                           Création d'un système de saisie de questionnaires intégré à
                           l'application.........................................................................................4
                           Fonction téléchargement....................................................................4
                           Schéma fonctionnel et présentation d’Android....................................4
                           Réalisation des modules.....................................................................7
                           Amélioration de l’ergonomie...............................................................7
                           Étude et réalisation de l'activité de téléchargement..........................10
                           Réalisation de nouveaux QCM.........................................................13
                           Conclusions techniques....................................................................15
                           Gestion du projet..............................................................................16
                           Apport personnel du projet................................................................17
                           Annexes............................................................................................18
                           Annexe 1: Schéma fonctionnel de la lecture de fichier QCM............18
                           Annexe 2: Schéma fonctionnel de DownloaderQcm.java.................19

                         Projet de groupe numéro 58 – 2012-2013 – Application Android Phelma - 2/20
Projet de groupe 2013 Application Android Phelma - Projet 58 - Sous la direction de Luc Salvo
Objectifs du projet
          Le projet consiste en l'amélioration d'une application pour téléphone Android déjà existante
réalisée par les élèves de PMP durant l'année universitaire 2011-2012. En effet, si l'application livrée par
ces derniers est fonctionnelle, il est possible de la rendre plus ergonomique autant pour l'utilisateur que
pour l'enseignant souhaitant générer le contenu.Tout d'abord, on rappelle que le cahier des charges
initial établi pour l'année dernière faisait part des demandes suivantes:
– L'application doit être destinée aux étudiants de Phelma.
– L'application doit être pédagogique.
– L'application ne doit pas déjà exister sur Internet.
– L'application doit se destiner au système d'exploitation Android.

A cela s'ajoute:
– La réalisation et la soumission de questionnaires et de résumé de cours aux enseignants,
– L'importation des QCMs sur Chamilo/Dokéos.

Androïd est un système temps-réel conçu par Google qui a l'avantage d'être libre. C'est
pourquoi il a été préféré par rapport à ses concurrents, où l'accès aux informations utiles à la
conception est restreint. Ce système est basé sur une architecture GNU/Linux, et utilise le langage JAVA
pour ses applications. La particularité du développement sous Androïd repose alors non seulement sur
la maîtrise du Java, des particularités d’un système temps réel qui nécessite de comprendre que chaque
tâche peut continuer à être éxecutée en même temps que d’autres, mais aussi sur le XML permettant de
lier le code de l'application et l'environnement graphique souhaité.
La rédaction du contenu des questionnaires est quant à elle basée sur l’utilisation d’un autre logiciel
libre, appelé Hot Potatoes, qui est déjà utilisé pour la rédaction des QCM pour Chamilo. Toutefois pour
être exportés sur Android, il est nécessaire de procéder à une transformation lourde et fastidieuse du
fichier généré par Hot Potatoes.

Suite aux retours sur la première version il a été décidé d’ajouter cette année les demandes suivantes:
- l’ergonomie de l’application doit être la plus accessible possible,
- la rédaction des questionnaires doit être la moins lourde possible en terme de manipulations,
- le logiciel pésant 8Mo lors de son téléchargement, il a été demandé de trouver une solution pour
alléger le téléchargement de l’application. Il a été retenu que seule l’application nue sera initialement
téléchargée, puis que l’utilisateur téléchargera le contenu qui l’intéresse via une interface de
téléchargement propre à l’application, connectée à un serveur distant tel Chamilo.

Cahier des charges
        Amélioration de l'ergonomie
L'application actuelle a selon notre tuteur les points noirs suivants:

                           Projet de groupe numéro 58 – 2012-2013 – Application Android Phelma - 3/20
Projet de groupe 2013 Application Android Phelma - Projet 58 - Sous la direction de Luc Salvo
– L'accueil est jugé par le maître d'oeuvre comme étant trop sommaire car il a été réalisé avec le design
« basique » proposé par l'environnement de développement Android.
– Lors des questionnaires, il est possible de connaître son score total sur l'avancement, mais il n'est pas
possible de savoir si l'étudiant a eu faux à la question précédente. Luc Salvo souhaiterait que « l'info
bulle » qui apparaît en cas de réponse fausse, ne disparaisse pas automatiquement de manière à laisser
le temps à l'utilisateur, mais aussi qu'elle soit capable de supporter des images par exemple. Toutefois,
nous rappelons que ce commentaire doit alors contenir un indice expliquant à l'étudiant pourquoi celui-
ci a eu faux, mais ne doit pas donner la réponse exacte. Il nous faudra par conséquent, implémenter ces
informations d'aide dans la réalisation des nouveaux questionnaires, ainsi que d'étudier l'intégration
d'image dans les commentaires.

        Amélioration de l'interactivité des questionnaires
Réaliser une application est déjà bien, la rendre attrayante est mieux. Pour cela, on propose quelques
activités pouvant donner du challenge aux étudiants en utilisant les périphériques intégrés à leur
appareil mobile. Par exemple, l'utilisation des accéléromètres du téléphone permet de détecter une
secousse. On pourra donc proposer un « questionnaire aléatoire » à partir de l'activité de choix des
questionnaires, où la secousse lancera un choix aléatoire du questionnaire, avec, si l'utilisateur le
souhaite, un mode contre la montre.

       Création d'un système de saisie de questionnaires intégré à
l'application
A l'heure actuelle, chaque QCM doit-être saisi sous un logiciel tableur en respectant une structure qui
sera abordée plus tard. Il se révèle vite fastidieux pour l'enseignant (qui doit nommer les fichiers images
à la main, et connaître les codes des types de questions par coeur). Notre tuteur nous a ainsi proposé, si
le temps nous le permet en fin de projet, de tenter de coder un système de type WYSIWYG (What You
See Is What You Get), permettant de générer de manière intuitive et simplifiée les fichiers QCM dédiés à
la plateforme Android. Cela sera finalement apporté par l’utilisation des fichiers générés par
HotPotatoes qui sont directement exploitables par Chamilo et l’application.

        Fonction téléchargement
Cette fonction reprend les besoins exprimés dans la partie précédente.

Schéma fonctionnel et présentation d’Android
         Après reformulation du projet, il a été décidé d’expliciter le fonctionnement de la nouvelle
version du logiciel via le schéma fonctionnel donné en figure 2.1, représentant le déroulement global de
l’application ainsi que les différentes interactions entre activités. On appelle activité (ou activity) un
écran qui permet de réaliser un ensemble d’interactions entre l’utilisateur et une partie de l’application.

                          Projet de groupe numéro 58 – 2012-2013 – Application Android Phelma - 4/20
Projet de groupe 2013 Application Android Phelma - Projet 58 - Sous la direction de Luc Salvo
Figure 2.1: schéma fonctionnel de l’application une fois remodelée.

Android étant un système temps réel, il est alors nécessaire que chaque activité respecte la structure
donnée en figure 2.2. Dans ce projet, l’interaction entre les activités est alors réalisée par trois fonctions
essentielles:
- onCreate() qui contient le code d’initialisation de chaque activité mais qui permet aussi de récupérer
les paramètres passés par l’activité précédente nécessaires à la nouvelle activité.
- onClick() qui permet en fonction de l’appui sur des boutons, de réaliser des tâches dédiées mais fixées
définitivement pour n’importe quel contenu.
- La majorité des données dynamiques sélectionnable sont transmises à l’utilisateur via un système de
liste cliquable appelé ListView. Un départ vers une autre activité à partir d’une sélection effectuée sur
cette liste se réalise au travers de la fonction onListItemClick(), qui permet à partir du numéro
d’identification donné à l’élément choisi, de transmettre l’élément qui y est associé (obtenu via un jeu
de tableau ou de variables internes à l’activité) et d’initialiser l’activité suivante avant de se détruire elle-
même. La transmission de l’élement et la sélection de la nouvelle activité sont effectuées grâce aux
systèmes d’intent.

                            Projet de groupe numéro 58 – 2012-2013 – Application Android Phelma - 5/20
Projet de groupe 2013 Application Android Phelma - Projet 58 - Sous la direction de Luc Salvo
Figure 2.2: Cycle de vie d’une activité sous Android.

Projet de groupe numéro 58 – 2012-2013 – Application Android Phelma - 6/20
Projet de groupe 2013 Application Android Phelma - Projet 58 - Sous la direction de Luc Salvo
Réalisation des modules
        Afin de répondre aux différentes demandes du cahier des charges, il a été choisi de diviser le
projet en plusieurs modules. Ainsi, nous étudierons dans un premier temps la réalisation de
l’amélioration ergonomique, puis du système de QCM. Enfin nous étudierons la réalisation du système
de téléchargement distant, puis la réalisation des nouveaux questionnaires.

Amélioration de l’ergonomie

Le premier projet était peu attrayant du point de vue graphique, puisque les élèves avaient dû tout
apprendre et construire depuis le point zéro. Notre travail a été de rendre plus attractif l’aspect
graphique de l’application, et de l’adapter à notre génération. La solution évidente fut la couleur globale
de l’application. Le noir initial était trop sombre, nous avons donc tenté une version sur fond blanc. Le
résultat était très satisfaisant. mais cette modification a engendré des problèmes avec notamment les
listview. Originellement sur fond noir, la police était blanche, et il s’est avéré très compliqué de changer
la couleur de la police. Le problème venait de l’aspect dynamique de l’affichage : les chapitres, matières
et qcm ne sont pas définis dans l’application directement mais à travers une structure de liste à qui on
commande “d’aller chercher” ces informations et de les afficher. C’est donc à l’intérieur de cette
structure qu’il fallait changer la police. Nous avons finalement résolu le problème en changeant le
thème général de l’application en “Theme.Light”.
Le deuxième point important a été l’ajout de son, qui fait partie des aspects attrayants d’une
application. Nous avons donc inclus une expression de motivation au départ du qcm “challenge
accepted”, tiré d’une série populaire chez les étudiants, qui apprécieront le clin d’oeil. De la même
manière, un son issu des “experts à miami” récompensera un score de 100%, et une image apparaîtra en
toast.
Le dernier point d’amélioration est l’accueil de l’utilisateur. L’ancienne application était trop simple et
plate. Pour la dynamiser , nous avons suivi un tutoriel pour mettre en place une page “splash” : une
page qui s’affiche avant la page de menu, qui permet de faire attendre l’utilisateur, et qui disparait au
bout d’un timer que l’on définit dans la page java.
Notre dernière modification s’est portée sur la page de menu. Ce fut notre première modification, et
c’est elle qui nous a permis d’appréhender l’environnement de travail. Nous avons remplacé l’affichage
“rubriques empilées” par des menus sous forme de bouton image, qui dynamise un peu plus
l’application. Le résultat final donne ceci :

              Page “Splash”                    Page “Menu                           si 100%

                           Projet de groupe numéro 58 – 2012-2013 – Application Android Phelma - 7/20
Amélioration du principe de rédaction des qcms

L’un des défauts que présentait l’application concernait principalement les rédacteurs qui souhaitaient
ajouter de nouveau qcms. En effet pour créer un nouveau qcm une certaine structure devait être
respecter, les questionnaires devaient être rédigé avec une mise en page particulière pour que le fichier
texte soit lu correctement par l’application.
Les professeurs étaient donc obligés de passer par un logiciel de feuilles de calcul comme Microsoft
Office Excel pour ensuite extraire la page en .txt ce qui s’avère très contraignant et chronophage.
Par exemple :

                              Figure 3.1: exemple de qcm rédigé sur Excel.

Chaque question occupe une ligne,le premier chiffre correspond au type de la question.
On peut distinguer 4 types :
     1. L’énoncé et les réponses sont du texte
     2. L’énoncé est une image, les réponses sont du texte.
     3. L’énoncé est du texte les réponses sont des images.
     4. L’énoncé et les réponses sont des réponses.
Suit l’énoncé de la question, puis le nombre de réponses,les réponses, le nombre de bonne réponse et
le numéro de la bonne réponse.
Quand nous avons repris l’application, nous avons souhaité changer ce systeme peu pratique, nous
avons donc eu l’idée d’utiliser le logiciel Hot Potatoes qui est spécialement conçu pour la rédaction de
qcms et est compatible avec la base de donnée Chamilo ce qui s’accorde donc bien avec notre souhait
de pouvoir télécharger les qcms. Par ailleurs nous avons découvert que le logiciel Hot Potatoes offrait la
possibilité d’exporter directement les qcms en fichier webCT lisible en tant que fichier texte.
Il a donc fallu adapter le code de l’application pour qu’elle puisse récupérer les informations à partir du
fichier webCT. L’étape de rédaction des QCMs à la main était donc sauté au profit de l’utilisation du
logiciel          Hot          Potatoes,          chose           bien          moins          fastidieuse.
Cette page présente une mise en page et une structure propre à hot Potatoes :

                          Projet de groupe numéro 58 – 2012-2013 – Application Android Phelma - 8/20
Figure 3.2: exemple de fichier.txt généré par Hot Potatoes.

Pour récupérer les informations, la démarche est la suivante, l’application compte le nombre de “TYPE”
ce qui donne le nombre de question dans le qcm et sait ainsi exactement le nombre d’itérations
nécessaires,puis il cherche les mots tels que “ANSWER”, “REASON” pour obtenir les réponses et
questions. On peut également lire ci-dessus “ANSWER2:100:H” le “100” indique que la réponse “2” est
une bonne réponse. Par ailleurs la présence des “.png” est caractéristique des images au format png ce
qui donne donc le type de question (1,2,3 ou 4).
Cf annexe1 pour consulter le schéma de la fonction correspondante.
Enfin il a fallu raccorder ces informations recueillies au code traitant ces données écrit l’année dernière.
Bien que cela a été fait avec l’aide de notre tuteur, l’application refuse de fonctionner et plante au
moment où elle doit afficher les questions. Le nouveau code présente donc des erreurs,
malheureusement pour le moment nous ignorons comment les corriger mais nous continuons à
chercher. Il s’agit de la dernière correction à faire pour rendre l’application remaniée entièrement
fonctionnelle.

                           Projet de groupe numéro 58 – 2012-2013 – Application Android Phelma - 9/20
Étude et réalisation de l'activité de téléchargement
L'un des premiers objectifs fixés par le maître d'œuvre était d'alléger l'application de manière à ce que
le téléchargement du programme principal pensant originellement 8Mo soit beaucoup plus rapide, et
que l'ajout de contenu ne nécessite plus de retélécharger l'application à chaque fois.
Nous avons constaté que l'essentiel du poids de l'application repose dans les fichiers dédiés aux cours
(PDF) et aux QCM qui pèsent à eux seuls au moins la moitié du poids final de l'application initiale. Il a
donc été proposé de placer ces fichiers sur un serveur distant, en utilisant Chamilo en guise de dépôt
par exemple, et de proposer une interface de téléchargement à l'utilisateur, lui permettant de n'avoir
que les fichiers qui l'intéresse sur son téléphone.
Le choix de Chamilo comme plate-forme d'hébergement a été choisi de manière de proposer aux
enseignants une méthode facile et motivante pour partager leurs QCM déjà existants avec l'application.
L'arborescence sur le serveur distant reste la même que celle dans le cadre du dossier assets
Sur le plan de la réalisation technique, le système repose sur 4 activités:
    ● downloader.java qui permet de choisir la matière des QCM à installer, il lit qcm_phelma.txt.
    ● DownloaderQcm.java qui permet de choisir quel chapitre l'utilisateur veut télécharger, lisant
        qcm.txt présent dans un sous-répertoire attribué à la matière.
    ● downloader-lessons.java qui permet de choisir la matière du cours à installer. Il lit qcm_doc.txt.
    ● downloader-lessons-sub.java qui permet de choisir le chapitre du cours à installer. Il lit doc.txt
        présent dans un dossier attribué à la matière.
Android propose naturellement un service interne de téléchargement permettant à toutes les
applications de télécharger un fichier au travers d'une seule connexion 3G ou Wifi. Ce service,
DownloadManager, utilise un système de file (FIFO) pour gérer les demandes de téléchargement et
utilise un sémaphore contenant l'ID qu'il a attribué à la requête pour nous prévenir que le
téléchargement est terminé. Le système proposé est donc schématiquement le suivant:

                                 Schéma fonctionnel de downloader.java
Définition: un sémaphore est, en système temps-réel, une sorte de drapeau qui est activé par une
fonction du système afin de confirmer par exemple, qu'une opération a bien été réalisée. Les
sémaphores permettent ainsi de mettre en pause une activité quelconque du système Android lorsque
celle ci attend qu'une autre tâche soit effectuée, afin de libérer l'utilisation des ressources système.

                         Projet de groupe numéro 58 – 2012-2013 – Application Android Phelma - 10/20
Afin de rendre accessible l’organisation des fichiers pour le commun des mortels, la structure suivante a
été retenue:
(en gris les répertoires, en bleu les fichiers)

                    FIgure 3.3: schéma de l’arborescence des fichiers QCM et cours
                                           pour l’application
Les fichiers qcm_phelma.txt et doc_phelma.txt doivent être structurés de la manière suivante:
(en bleu, les commentaires)

3                     Nombre de matières
elec:Electronique     La matière Electronique est stockée dans le répertoire elec/
phyq:Physique Quantique       La matière Physique Quantique est stockée dans le répertoire phyq/
logic:Logique         etc...

                         Projet de groupe numéro 58 – 2012-2013 – Application Android Phelma - 11/20
Exemple du contenu du fichier qcm_phelma.txt ou doc_phelma.txt

Les fichiers qcm.txt doivent être structurés de la manière suivante:

2
nom_fichier_qcm1:Intitulé du contenu de fichier_qcm1
nom_fichier_qcm2:Chapitre 2

 Exemple du contenu du fichier qcm.txt ou doc.txt présent à la racine de chaque répertoire de matière

ATTENTION: libre à l’auteur du questionnaire de donner le nom qu’il veut à son QCM. Toutefois, il faut
impérativement que le nom de celui-ci soit donné dans le fichier qcm.txt en racine du répertoire de la
matière. Il est aussi impératif que les images propres au questionnaire soit placées dans un sous-
répertoire portant le même nom que le fichier texte du questionnaire, sans le .txt à la fin.

Toutefois, l'activité utilisateur ne termine pas forcément l'activité dans le cadre de DownloaderQcm.java
et downloader-lessons-sub.java. Ces dernières proposent, si l'utilisateur clique sur l'un des noms de
fichiers, de télécharger le fichier si il n'existe pas sur la carte SD, et alors se remet en pause en attendant
que le téléchargement soit terminé, et procède alors au téléchargement des dépendances (images
nécessaires au bon fonctionnement du QCM, etc). Dans le cas où le fichier existe déjà, il sera alors
supprimé, avec ses images.

La gestion des dépendances de chaque fichier QCM a été réalisée à partir du constat suivant:
il nous est possible de savoir lorsque le fichier qcm a été reçu via un sémaphore qui lui est dédié. On
appelle alors une fonction de téléchargement des dépendances dédiées qui scanne le contenu du fichier
questionnaire reçu. Il est alors possible, en analysant chaque ligne du fichier, de détecter les noms de
fichiers images, car ils sont appelés par le fichier via leur extension en .png. On ajoute alors dans la liste
d'attente de DownloadManager, sans demande de sémaphore afin d’éviter une boucle infinie, les noms
des fichiers images à télécharger. Son fonctionnement est schématisé en annexe 2.2 page 21.

Une amélioration ergonomique a été proposée en utilisant les layout ExpandableListView. Après de
nombreuses heures de réécriture du système il s'avère que son utilisation se révèle peu pratique dans le
cadre de la réalisation d'un système de téléchargement distant. En effet, ExpandableListView n'est pas
capable:
    ● de gérer une liste dynamique de sous rubriques (ici les chapitres). Il nous oblige à réquisitionner
       un espace mémoire fixe et qui peut se révéler gourmand face à l'utilisation demandée;
    ● d'être mis à jour après une activation de la fonction d'affichage par un sémaphore. La logique du
       layout d'ExpandableListView repose en effet sur le fait que si le contenu ne peut-être généré
       immédiatement lors de la création de l'activité lors de l'appel de la fonction onCreate(), alors il
       applique le layout défini en cas de contenu vide.

                          Projet de groupe numéro 58 – 2012-2013 – Application Android Phelma - 12/20
Nous avons donc préféré revenir à la réalisation précédente, nécessitant 4 activités au lieu de 2.

Le maître d’oeuvre nous a toutefois fait part de sa volonté à pouvoir mettre en avant les nouveaux
questionnaires. Pour cela, il a été décidé de signaler à l’utilisateur quels sont les questionnaires qu’il a
déjà sur sa carte par un affichage de couleur verte. Les nouveautés se distinguent du fait que ce sont des
questionnaires qui n’ont pas encore été testés, et donc dont le score n’est pas enregistré dans
/mnt/sdcard/PHELMA/score.txt . Par conséquent, tout fichier non présent sur la carte, mais dont
l’empreinte existe dans le fichier score.txt sera considéré comme ancien et sera donc affiché en couleur
gris. Les nouveautés garderont donc la couleur par défaut du ListView. Cela est réalisé grâce à la
fonction checkThemAll(), présente exclusivement dans le fichier DownloaderQcm.java.

Enfin, nous constatons que si tous les tests se sont passés sans encombre si les téléchargements sont
effectués sur un serveur distant autre que celui de Chamilo, ce dernier nécessite que DownloadManager
soit capable de prendre en compte les redirections HTTP mises en place par le service informatique,
comme le montre le log d'un wget depuis un shell Linux (figure 3.4). Cela nous empêche donc de
télécharger des fichiers directement depuis Chamilo, même si le répertoire contenant les fichiers
nécessaires au bon fonctionnement de l’application sont accessibles au public.

   Figure 3.4: capture d’écran d’un wget détaillé sur un fichier texte quelconque hébergé sur Chamilo
                                       depuis une machine Unix.

Réalisation de nouveaux QCM
        Les QCMs sont le contenu de l'application, certain ont déjà été réalisés par le groupe de l'année
dernière, notamment sur des matières abordé par les PMP, ce groupe en étant composé. Ces matières
étant :
    ● Physique Quantique
    ● Physique Statistique
    ● Électronique
    ● Transformée Intégrale
    ● cristallographie

                         Projet de groupe numéro 58 – 2012-2013 – Application Android Phelma - 13/20
Nous avons cette année décidé de compléter ces QCMs par d'autres axés sur des matières de
PET. Nous avons donc réalisé des QCMs de :
     ● Physique du solide
     ● Logique
     ● Propriété des matériaux
         Nous avons également choisi de compléter certaines des matières déjà présente, l'électronique
et la physique quantique.

        Ces QCMs ont été réalisé sur la base de cinq questions par questionnaire, avec quatre
propositions de réponses par question. Chaque questionnaire couvrant un chapitre, ou une partie de
chapitre dans le cas ou ce dernier est trop imposant. Ils ont été réalisé à partir des polycopiés distribués
en cours et ont été créé dans le but de vérifier la maîtrise du cours. Ils n'abordent pas les notions et
techniques vues en TD et ne suffisent donc bien évidement pas pour avoir le niveau requis.

La réalisation des QCMs en eux même n'a pas posé de réels problèmes, la plus grande difficulté étant de
trouver des réponses fausses mais plausibles. Nous rajouterons aussi que certains chapitre se prêtent
bien mieux à ce genre de questionnaires que d'autres.

         Avant toute chose, nous avons demandé l'autorisation aux enseignants de réaliser et de rendre
accessible ces QCMs aux élèves de PHELMA, ainsi que leur aide pour vérifier et/ou améliorer les
questionnaires. Ces derniers ont été saisi grâce au logiciel HotPotatoes qui nous a grandement simplifié
la tâche.
         En effet nos prédécesseurs étaient obligés de saisir leurs QCMs sur un tableau en précisant le
nombre de réponse, la (ou les) bonnes réponses ainsi que le type de questions et de réponses (image ou
texte). Cette démarche était longue et fastidieuse. Au contraire la saisie avec hotpotatoes se révèle bien
plus légère. Il suffit de taper la question et les réponses dans les cases prévues à cet effet, et de
sélectionner la ou les bonnes réponses grâce à l'onglet correspondant. Il est ensuite possible d'insérer
des commentaires associé à une ou plusieurs propositions de réponses. Une fois cela terminé, il suffit de
passer à la question suivante.
         La gestion d'image est tout aussi simple puisqu'il suffit de copier l'adresse de l'image voulue au
format .PNG, l'image se trouvant dans lerépertoire ayant le même nom que le QCM.
         Une fois le questionnaire terminé on le converti en un fichier .txt en utilisant la fonction « export
WebCT » de l'onglet fichier.

        Les seuls inconvénients de cette méthode sont :
    ●   les accents et autres caractères non ASCII, ne sont pas converti dans le .txt, c'est pour    cela
        qu'aucun accent n'est présent dans les questionnaires.
    ●   De la même manière il est conseillé de présenter les formules en tant qu'image.
    ●   Il est impératif de laisser les images dans le même répertoire que le .txt.

                          Projet de groupe numéro 58 – 2012-2013 – Application Android Phelma - 14/20
Contrairement à l'année précédente, il est maintenant envisageable que les enseignants
puissent créer ou modifier à leur guise les QCMs via hotpotatoes.

Conclusions techniques

         A l’exception de l’ajout d’interactivité (type questionnaire aléatoire en fonction de l’activité d’un
accéléromètre par exemple), nous avons tenté d’apporter des réponses à l’ensemble des demandes
transcrites dans le cahier des charges. L'ergonomie a ainsi été améliorée par une refonte de la page
d'accueil, et la rédaction des QCM est maintenant partagée avec le même système que pour ceux
destinés à Chamilo de manière à attirer les enseignants vers la rédaction de contenu pour ce nouveau
support. Enfin, les utilisateurs apprécieront de pouvoir ajouter du contenu très facilement, car ils n'ont
désormais plus besoin de réinstaller l'application dès la moindre modification. Le nouveau système nous
permet donc de mettre en retrait le rôle de créateur de contenu pour l'ensemble du groupe du projet,
car les enseignants disposent d'outils simples leur permettant de le faire eux-même.

         Toutefois, on compte encore quelques problèmes pour fonctionner, comme le système de
lecture des nouveaux fichiers QCM ou encore le système de détection des QCM déjà téléchargés et de
détection des nouveautés du système de téléchargement. Cela est en autres causé par le fait qu’Android
utilise des structures qui lui sont propres pour ses diverses fonctions, et qu’implanter une nouveauté
nécessite d’abord de la transcrire une esquisse à l’aide des différentes fonctions mises à disposition par
Google, avant de la réaliser en JAVA. A cela s’ajoute les problèmes dus à l’émulation de l’application:
l’émulateur est lent, très lent, et à tendance ainsi à générer des timeout, nécessitant alors le
redémarrage complet de l’émulateur. Il faut ainsi parfois plus d’une heure pour tester deux nouvelles
lignes de code.

        L'avenir de l'application se tourne maintenant vers une facilité de mise en ligne des fichiers à
destination des enseignants, ainsi que vers le développement d'une interaction utilisateur/application
plus dynamique et distrayante.

        Nous recommandons ainsi aux futurs repreneurs du projet de travailler sur un système d’upload
des questionnaires en ligne sur le serveur distant via un simple script PHP par exemple, qui permettra
ainsi de simplifier la tâche d’ajoût des QCM par les enseignants. Enfin l’interactivité de l’application
pourra être complétée par l’ajout d’un système de High Score en ligne qui pourra se faire via le module
HTTP d’Android, en faisant un GET sur un script PHP distant. L'idée d'utiliser les accéléromètres du
téléphone pour détecter une secousse et ainsi déclencher un QCM aléatoire peut-être aussi envisagée.

                          Projet de groupe numéro 58 – 2012-2013 – Application Android Phelma - 15/20
Gestion du projet

        La gestion de ce projet a nécessité de prendre en compte des paramètres différents de la
gestion classique d’un projet tel qu’on le retrouve lors de la réalisation d’une carte électronique par
exemple. Déjà le fait que nous reprenions une application déjà fonctionnelle ne nous oblige pas à
attendre qu’un bloc fonctionnel essentiel soit réalisé pour tester le nouveau travail. De même, le fait
qu’Android propose de diviser chaque fonction du schéma fonctionnel initial en différentes activités
permet alors de décomposer le travail auprès de chacun en fonction de ses compétences.
        Nous avons donc, dans un premier temps, procédé à une formulation des réponses possibles
pour combler les problèmes de l’application existante mis en avant par le tuteur enseignant. Cela a été
réalisé après avoir procédé à une première analyse du code existant et à une étude des capacités
d’Android. Il a alors été édité le rapport de reformulation qui a été remis en Février 2013. Les
amélioration nécessitant alors de refaire certaines activités, certains membres du groupe ont du
procédé à une sorte de reverse-engineering du code existant de ces activités afin de pouvoir les rendre
fonctionnelles avec les nouveautés. A partir de là, chaque membre du groupe est devenu capable de
fonctionner en autonomie, avec toutefois une communication transverse nécessaire pour pouvoir
partager les nouvelles structures vitales telles la nouvelle arborescence de fichiers.

         Afin de pouvoir accéder au code n’importe quand, n’importe où et d’accéder aux nouvelles
briques terminées par les autres membres, nous avions tenté de mettre en place un système de
repository, serveur permettant le stockage et la hiérarchisation des travaux effectués sur chaque fichier.
Nous avions retenu GIT (http://git-scm.com/ ) car celui-ci propose une interface graphique bien plus
accessible que les autres, mais permet aussi de revenir en arrière si l’une des nouvelles modifications
apportées fait crasher l’application. Bien qu’utilisé au départ, nous éprouvions l’impossibilité de tester le
code existant sur l’émulateur intégré proposé par le kit de développement Android. Nous avions alors
procédé à d’importantes modifications inutiles et dangereuses du code dans l’espoir de pouvoir émuler
l’application. Il s’avère en réalité que le problème venait de l’émulateur lui-même. Nous avions donc
décidé de remettre le code d’origine sur le GIT, ce qui pour d’obscures raisons nous a refusé de
fonctionner par la suite. Partant du constat que chacun travaillait sur un fichier indépendant, il a été
décidé de centraliser les nouveautés en s’envoyant les fichiers par mail une fois le travail terminé.
         Ce problème d’émulateur, nous a fait rencontrer d’importants problèmes causant des retards
sur le projet. Le premier a été de pouvoir émuler le code existant au début du projet. Ce retard, de
l’ordre d’une semaine a toutefois permis de nous concentrer sur l’analyse du code existant. On rappelle
le diagramme de Gantt initial en figure 4.1:

                          Projet de groupe numéro 58 – 2012-2013 – Application Android Phelma - 16/20
Figure 4.1: diagramme de Gantt proposé dans le rapport de reformulation

         Ainsi, seules les activités propres à la programmation de l’application ont subi les conséquences
de ce retard. Dans le cadre de la réalisation de la passerelle Android/Chamilo qui est la plus
consommatrice en tâches, ce retard a été rattrapé du fait que l’étude de la faisabilité de la passerelle se
révèlait initialement simple grâce au système de téléchargement déjà intégré à Android. Au final, seule
la phase de beta-test publique n’a pu être réalisée, la réalisation de l’amélioration du système de
questionnaires nous ayant donné du fil à retordre jusqu’à la dernière séance.

         Apport personnel du projet

Antoine Le-Breton: Ce projet de groupe a été une expérience bénéfique car c'était la première fois que je
participais à un tel projet, sur une telle durée et dans une équipe aussi nombreuse. Le projet en lui même m'a
permis de me perfectionner en informatique, discipline pour laquelle je n'avais aucune facilité, ainsi qu'en talent
relationnel. En tant que responsable des QCMs j'ai également appris à rédiger un questionnaire pertinent ; ce qui a
aussi été un excellent moyen d’accroître ma maîtrise des différentes matières.
Louis Drouard: Ce projet de groupe fut véritablement le vrai premier grand projet de groupe de ma “carrière”. Il a
été l’occasion de véritablement aborder le travail en équipe. Respecter un planning, se répartir les taches,faire
avec les forces et faiblesses des autres membres, se renseigner pour mener à bien le projet, tout cela m’a été
bénéfique. J’ai cependant été confronté aux diffcultés que présentent ce genre de projet: les problèmes
inattendus, les difficultés qui semblent insurmountable, les éventuels incompréhensions au sein de l’équipe.
Techniquement j’ai aperçu le potentiel du langage java et de l’IDE Eclipse,mais j’ai été personnellement déçu, je
l’ai trouvé difficile à comprendre/lire/manier par comparaison avec le C.
Niels Grataloup: Venant d’IUT, j’ai déjà eu l’occasion de gérer un projet autant sur le plan technique que de
l’organisation du travail. Le travail de cette année fut l’opportunité de travailler sur un projet où le nombre de
membres dans l’équipe est nettement plus important, et où le domaine nous est initialement inconnu, nécessitant
une excellente capacité d’adaptation et de documentation.
Rémy Mansour: Ce projet m’a dès le début attiré car il touchait à la programmation. Ça a été pour moi, une
occasion de découvrir le langage Java ainsi que l’organisation autour d’un projet informatique. Malheureusement
j’ai été déçu de voir qu’il fallait reprendre un programme déjà fait. Ceci nous a été handicapant, car on partait avec
beaucoup moins de recul que les personnes ayant créée le code depuis le début. L’analyse et la compréhension du
code ont été des étapes très longues surtout que l’emulateur, permettant de tester le code et donc de le
comprendre, était très instable. Néanmoins ces difficultés m’ont permis de pousser encore plus loin mes capacités
d’analyse de code, de recherche d’information, d’adaptation etc.
Vincent Guiu : Ce projet fut un véritable challenge. Il nous a fallu apprendre deux tout nouveaux langages
informatiques, comprendre une application déjà réalisée dans une logique qui n’était pas forcément la notre, et
jongler avec les possibilités qu’offre le java pour atteindre nos objectifs. Néanmoins, il nous a été grandement
profitable. Outre les nouvelles notions en programmation, j’en ai surtout tiré une vue plus générale d’une
application de smartphone, une page “physique” pouvant s’utiliser pour des pages différentes par exemple. La
partie ergonomique me convenait tout à fait. En effet, devant l’inconnu, j’ai tendance à aborder directement le
problème, partie par partie, et d’observer physiquement les modifications que je pouvais faire. J’ai ainsi eu une
approche plus “expérimentale” de l’application que théorique.

                            Projet de groupe numéro 58 – 2012-2013 – Application Android Phelma - 17/20
Grille d'évaluation

Objet d'évaluation                                               Note
Travail fourni en projet                                         / 14
Travail fourni pour les rendus de communication                  /3
Ambiance de travail (ponctualité, présence)                      /1
Prises d'initiatives                                             /2

                           Projet de groupe numéro 58 – 2012-2013 – Application Android Phelma - 18/20
Annexes
Annexe 1: Schéma fonctionnel de la lecture de fichier QCM

                 Projet de groupe numéro 58 – 2012-2013 – Application Android Phelma - 19/20
Annexe 2: Schéma fonctionnel de DownloaderQcm.java

                Projet de groupe numéro 58 – 2012-2013 – Application Android Phelma - 20/20
Vous pouvez aussi lire