projet de groupe 2013 application android...

Louis Drouard - Niels GrataloupVincent Guiu - Antoine Le BretonRémy Mansour

Projet de groupe 2013Application Android Phelma

Projet 58 - Sous la direction de Luc Salvo

Projet de groupe numéro 58 – 2012-2013 – Application Android Phelma - 1/20

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


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'estpourquoi il a été préféré par rapport à ses concurrents, où l'accès aux informations utiles à laconception 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'ergonomieL'application actuelle a selon notre tuteur les points noirs suivants:


– 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 questionnairesRé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'applicationA 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échargementCette 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.


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.


Figure 2.2: Cycle de vie d ’ une activité sous Android .


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%


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 texte2. 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 :


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.


Étude et réalisation de l'activité de téléchargementL'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 assetsSur 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.


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èreselec: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...


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:

2nom_fichier_qcm1:Intitulé du contenu de fichier_qcm1nom_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.


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 QCMLes 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


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.


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.


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:


http://git-scm.com/

http://git-scm.com/

http://git-scm.com/

http://git-scm.com/

http://git-scm.com/

http://git-scm.com/

http://git-scm.com/

http://git-scm.com/

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.


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


Annexes

Annexe 1: Schéma fonctionnel de la lecture de fichier QCM


Annexe 2: Schéma fonctionnel de DownloaderQcm.java


projet de groupe 2013 application android...

Documents