Projet AllSchools : portage Android Rapport Final

(1)

Projet AllSchools : portage Android

Rapport Final

(2)

Rapport Final

Rapport Final : Remerciements

1 Sommaire

I. Remerciements ... 4

II. Introduction ... 5

III. Gestion de Projet ... 5

IV. Architecture de l’application ... 8

A. Architecture Générale ... 8

B. Modèle de l’application ... 9

C. Navigation dans l’application ... 9

D. Internationalisation ... 9

V. Déroulement de l’application ... 11

VI. Modèle de l’application ... 12

A. Récupération des informations ... 12

Les fichiers JSON ... 13

Les fichiers XML ... 14

B. Insertion et Récupération dans la base de données ... 15

VII. Interface de l’application ... 19

A. Carrousel ... 19

B. Article ... 22

C. Gestion des Onglets ... 23

Les onglets ... 23

L’onglet Autre... 24

Drag and drop ... 24

VIII. Modules... 25

A. Module Partenaires... 25

B. Module de Stage ... 26

Interface ... 26

Modèle ... 27

C. Module Carte 3D ... 28

Pré-réalisation ... 28

Conception et implémentation ... 28

D. Module Contact ... 30

IX. Conclusion ... 31

(3)

Rapport Final

2

X. Annexes ... 32

A. Cahier des charges ... 32

I. Présentation générale du problème ... 32

1. Projet ... 32

a. Présentation ... 32

b. Contexte ... 32

c. Retour sur investissement ... 32

2. Contexte ... 32

a. Situation du projet ... 32

b. Suites prévues ... 33

c. Nature des prestations demandées ... 33

d. Parties concernées par le déroulement du projet et ses résultats ... 33

3. Description de l’existant ... 33

4. Enoncé du besoin ... 34

5. Contexte ... 34

a. Moyens humains ... 34

a. Matériels utilisés ... 34

b. Langages & techniques utilisés ... 35

II. Expression fonctionnelle du besoin ... 36

1. Fonctions de service, contraintes et besoins en IHM ... 36

a. Fonctions de service principales ... 36

b. Contraintes ... 36

c. Besoins en IHM ... 37

1. Critères d’acceptabilité ... 37

2. Niveaux des critères d’appréciation et ce qui les caractérise ... 38

a. Niveaux dont l’obtention est imposée ... 38

b. Niveaux souhaités mais révisables ... 38

III. Cadre de Réponse ... 39

1. Solutions Proposées ... 39

a. Le MVC ... 39

b. L’authentification ... 39

c. Le parsage ... 39

d. La base de données SQLITE ... 40

2. Pour l’ensemble du produit ... 40

a. Prix de la réalisation de la version de base ... 40

(4)

Rapport Final

3

b. Mesures prises pour respecter les contraintes et leurs conséquences économiques .... 40

c. Prévisions de fiabilité ... 41

B. Documents de Planification ... 41

Planification du projet... 42

Structure de découpage du projet (SDP) ... 42

Grands jalons du projet ... 45

Planning ... 46

Cadre de gestion du projet ... 47

Rôles et responsabilités des intervenants ... 47

Modalités de surveillance et de maîtrise du travail (reporting) ... 47

Liste des documents ... 47

Budget ré-estimé en phase de planification ... 48

(5)

Rapport Final

4 I. Remerciements

L’équipe du projet tient à remercier Son encadrant Florent Carlier,

St-Ericsson représenté par Franck Albesa pour leur assistance,

Killian Lamberdière et Ronan Trotin pour leurs constantes améliorations de l’application, Jennifer Wolfarth-Garcia pour l’organisation inter-projet,

Et les gardiens de l’ENSIM pour nous avoir laissé l’accès aux salles jusqu’à une heure tardive.

(6)

Rapport Final

Rapport Final : Introduction

5 II. Introduction

AllSchools est un logiciel de présentation des offres de formation d’établissements supérieurs sur support mobile. Il a été créé à la base sur Iphone et présentait alors uniquement l’offre de formation de l’ENSIM, son berceau, ainsi que les infrastructures de l’université du Maine.

Dans le cadre du projet « AllSchools – L’Information universitaire étudiante pour support mobile » porté par la région des Pays de La Loire et soutenu par OCEANET et ST-ERICSSON et visant à exporter les fonctionnalités du logiciel non seulement à l’université du Maine, mais également aux trois grandes universités de la région (Nantes et Angers), AllSchools s’est vu proposé l’ouverture à l’univers Android, car en effet tous les étudiants n’ont pas forcément d’iPhone, d’autant plus que le public Android représente 50% de l’univers mobile.

C’est donc dans ce registre que s’inscrit notre projet : « AllSchools – Portage Android », et ce document fait état du résultat final de ce projet commencé le 17 novembre 2011 à l’ENSIM dans le cadre des projets de 2^ème année, et dont l’objectif était de réaliser une version Android du logiciel AllSchools, la plus proche possible du modèle iPhone, tout en se pliant aux contraintes du support. Par la suite, nous présenterons la version actuelle de notre développement : sa structure dans un premier temps, puis son fonctionnement, et enfin quelques explications techniques de nos différentes implémentations.

III. Gestion de Projet

Au niveau de la gestion de projet, nous étions dès le départ soumis à des contraintes temporelles. Une première version de l’application était en effet à livrer le 1^er mars 2012. Dans l’optique d’atteindre les objectifs fixés, nous avons désigné un chef de projet dont le rôle serait de répartir les tâches. Après concertation de toute l’équipe, Vincent Mollière a été choisi pour être chef de projet. Pour se faciliter la tâche, il a été décidé de scinder le travail en 2 parties indépendantes en terme de développement : d’une part l’interface et la présentation de l’application ; et d’autre part le contenu de l’application.

Il semblait nécessaire que chacune de ces deux parties soit gérée par un sous-groupe, dans le but d’alléger la tâche de chacun ; et pour alléger celle du chef de projet, il a été convenu que chaque sous-groupe serait géré par un chef de sous-groupe, avec la responsabilité de répartir les tâches dans son équipe et de gérer cette dernière. Après un vote général, les différents membres des sous-groupes se sont décidés avec Vincent en chef du sous-groupe Interface et Darryl Tadmi en chef du sous-groupe Contenu.

Dans le sous-groupe Interface, Vincent a divisé les tâches comme suit : Abdellah Moustaid à l’interface de l’application et l’affichage des onglets ; Amjed Chaouat à la création de la carte 3D et la gestion des cartes et Vincent à l’adaptation du carrousel puis de la structuration de l’interface de l’application.

Dans le même temps, dans le sous-groupe Contenu, Darryl a effectué la répartition suivante : Joffrey Durand à la création et de la gestion de la base de données, Anass Chabbab à

(7)

Rapport Final

Rapport Final : Gestion de Projet

6

l’instanciation des classes et Darryl au parsage des fichiers JSON et XML et de la structuration interne du modèle des données de l’application.

Cette répartition a été effective jusqu’au premier jalon du projet comme indiqué dans le planning ci-dessous. Par la suite, Vincent a effectué une nouvelle répartition des tâches, en fonction de celles qui étaient déjà achevées. Il a donc délégué les tâches comme suit : Anass à l’internationalisation puis au suivi des stages, Darryl au module Partenaires, Abdellah à la fonctionnalité Drag and Drop, et lui-même au module Associations, du module Contact et à l’assistance des membres de l’équipe au travers de chacune de leur tâche respective.

Des dates butoirs ont été régulièrement définies afin de rassembler le travail en commun, et d’établir un état des lieux de l’avancement du projet. Si le chef de projet a coordonné son équipe par l’intermédiaire de conseils et d’exigences, chaque membre était libre d’assister les autres et d’intervenir en cas de besoin. En dehors des séances régulières de projet, les e-mails ont été le meilleur moyen pour communiquer, notamment pour informer des mises à jour et diffuser au reste de l’équipe les nouvelles versions de l’application. Nous avons par ailleurs mis en place un serveur SVN pour la mise en commun du code. De cette manière, l’équipe a pu effectuer des commits concernant les différentes parties du programme de l’application. Il a ainsi été plus aisé de savoir quelles étaient les dernières modifications apportées, d’autant plus que la deuxième phase du projet devait être entreprise en partenariat avec ST-Ericsson.

Voici le planning réel :

(8)

Rapport Final

Rapport Final : Gestion de Projet

7

(9)

Rapport Final

Rapport Final : Architecture de l’application

8 IV. Architecture de l’application A. Architecture Générale

L’architecture de l’application est basée sur le modèle MVC (Modèle/Vue/Contrôleur), c’est-à-dire que le modèle (les données brutes), la vue (l’interface côté utilisateurs) et le contrôleur (gère le déroulement de l’application) sont indépendants entre eux. En bref on peut modifier la vue sans toucher ni aux données ni au contrôleur.

Par ailleurs, c’est un modèle MVC multicouche qui a été utilisé : la vue peut être considérée elle-même comme un sous-modèle MVC avec un modèle, une vue et un contrôleur.

Ainsi, nous avons divisé l’application en cinq grandes parties :

- Une partie Application avec des mécanismes propres à Android comme l’activité principale ou des fonctions utilitaires utilisées dans le reste de l’application.

- Une partie Controller avec deux contrôleurs : un pour l’initialisation de l’application, l’autre pour son déroulement.

- Une partie Vue avec l’affichage des onglets, des carrousels et des articles.

- Une partie Modèle avec la gestion de la base de données et du parsage des fichiers XML et JSON.

- Une partie Module indépendante du reste de l’application, avec son propre modèle MVC.

L’architecture principale est composée d’un arbre où chaque branche sera un écran. En naviguant parmi les nœuds, on navigue dans l’application. Il y a plusieurs types de nœuds, chacun d’eux entraîne un comportement différent de la part du contrôleur. Les trois types de nœud sont :

- Le nœud NODE_LIST : composé de nœuds, il déclenchera chez le contrôleur l’affichage d’un carrousel.

- Le nœud ARTICLE : composé de paragraphes. Le contrôleur affichera un article lorsqu’il recevra ce nœud.

- Le nœud NODE_ACTIVITY : composé de la classe d’une activité. Utilisé pour appeler l’activité principale d’un module.

NODE_LIST

ARTICLE ARTICLE NODE_LIST

ARTICLE ARTICLE NODE_ACTIVITY

(10)

Rapport Final

9

FIGURE 1-EXEMPLE D'UN ARBRE DE L'APPLICATION

Quel que soit son type, chaque nœud dispose d’un nom, d’un nom long et d’une image. Il y a plusieurs arbres dans l’application, indépendants entre eux. Ces nœuds sont initialisés à partir de données brutes récupérées depuis des fichiers.

Les modules sont des cas à part, car indépendants de l’application. Ils possèdent donc leur propre architecture.

B. Modèle de l’application

Pour pouvoir remplir l’arbre, l’application doit récupérer des informations depuis certains fichiers. Cette récupération prenant un certain temps, nous avons décidé d’utiliser une base de données afin de stocker une bonne fois pour toutes ces données.

De plus, dans le but de faciliter l’intégration et la synchronisation avec les autres parties de l’application, nous avons mis en place un système de petites boîtes qui communiquent les unes avec les autres, constituant une chaîne de transfert de l’information, depuis sa récupération jusqu’à sa présentation à l’utilisateur via l’interface.

FIGURE 2-MODELE DES PETITES BOITES COMMUNICANTES MIS EN PLACE POUR LA CHAINE DE TRANSFERT DE L’INFORMATION

C. Navigation dans l’application

Pour naviguer à travers les nœuds de l’application, il existe deux systèmes utilisés à deux niveaux différents. Pour naviguer entre les arbres des applications, nous utilisons un système d’onglets ; et pour naviguer dans un arbre, c’est un carrousel.

D. Internationalisation

Pour avoir un public plus large, surtout pour les étudiants étrangers, il est très important que l’application soit munie d’une option de choix de langues. On doit donc faire une internationalisation.

Pour effectuer cette tâche, on devait tout d’abord reprendre tous les attributs déclarés statiquement dans tout l’ensemble des classes de l’application et les déclarer dynamiquement.

Tous ces attributs seront déclarés dans un fichier string.xml par langue. Chaque attribut sera Parsage Sauvegarde Instanciation

et mise en

forme Présentation

(11)

Rapport Final

1 0

initialisé par une valeur de type String, cette valeur peut définir un titre ou un détail du contenu.

Une fois tous les attributs déclarés, on fait appel à eux dans leurs classes correspondantes en utilisant un Context, ce dernier permettra de les insérer dans les cases qui leur ont été attribuées.

Dans un premier temps, on a programmé les deux langues française et anglaise.

Voici une illustration du fonctionnement :

Après avoir inséré cette fonctionnalité, l’utilisateur n’a donc qu’à choisir la langue dans son Smartphone pour que les menus de l’application soient traduits.

Durant le développement de cette partie, on a rencontré des problèmes de traduction au niveau des fichiers contenant la traduction de tous les attributs de l’application. Il y avait plusieurs erreurs qu’on a donc essayé de corriger de notre mieux.

Français

Anglais

(12)

Rapport Final

Rapport Final : Déroulement de l’application

1 1

V. Déroulement de l’application

Lors du lancement de l’application, nous devions récupérer les données des fichiers de données. Pour cela, en fonction des situations, le logiciel peut être amené à :

- Télécharger des fichiers XML et JSON depuis un serveur - Parser les fichiers XML et JSON

- Insérer les données dans une base de données SQLite - Récupérer les données depuis une base de données Ces fonctions sont détaillées dans leur partie respective.

Voici un diagramme d’état présentant le déroulement de l’initialisation de l’application :

A la fin de l’initialisation, les structures de données brutes sont remplies et nous initialisons les arbres, bases de l’application.

La racine de l’arbre est envoyée à un contrôleur qui va s’occuper de gérer l’affichage du nœud.

(13)

Rapport Final

Rapport Final : Modèle de l’application

1 2

VI. Modèle de l’application A. Récupération des informations

Il s’agissait ici de concevoir les classes et méthodes Java permettant d’effectuer la lecture et l’interprétation (parsage) des informations contenues dans les fichiers de contenu de l’application. En effet, toutes les informations relatives à l’offre de formation et aux infrastructures disponibles dans l’école sont contenues dans ces fichiers sous un format particulier, et c’est ce contenu qui est affiché sur tous les écrans de l’application.

Les fichiers en question sont de deux types, différents par leur format (dans le sens informatique du terme) et le type de leur contenu, et donc ayant imposé un parsage différent : les fichiers JSON et les fichiers XML. Pour en faciliter l’accès, les deux types de fichiers ont été stockés dans le répertoire Assets du projet Java.

Par ailleurs, dans le but de faciliter l’accès aux informations de contenu dans ces fichiers, et comptant sur les caractéristiques techniques du support matériel qu’est le Samsung Galaxy S2, nous avons adopté comme stratégie de développement un système de poupées russes.

Il s’agit d’un système de contenants, rangeant par étage les informations les unes dans les autres, selon le modèle des fichiers à parser. Concrètement, cela impliquait la création de classes correspondant à chaque information complexe et pertinente parsée. Ainsi, une information constituée d’un ensemble de valeurs correspondait, en code, à une classe renfermant ces données en attributs ; et une information encapsulant la précédente et d’autres encore était représentée par une classe à un niveau plus élevé, et ainsi de suite. L’avantage de cette méthode était de nous faciliter l’accès aux informations parsées, en attente de la base de données. Ces données, une fois parsées, sont donc directement disponibles à l’utilisation dans les autres parties de l’application, par les instances des classes les plus élevées du modèle décrit précédemment.

FIGURE 3-MODELE DE LA STRUCTURE EN POUPEES RUSSES MISE EN PLACE POUR LA SAUVEGARDE DES DONNEES ISSUES DU PARSAGE

Donnée niveau 1

Attribut 1

Attribut 2

Donnée niveau 2

Attribut 1 Attribut

2

Données niveau 3

Attribut 1 Attribut 2

(14)

Rapport Final

1 3

Les fichiers JSON

Ces fichiers contiennent les informations annexes, c’est-à-dire non relatives à l’offre de formation. Ce sont toutes les informations propres à l’ENSIM, rangées dans des fichiers JSON différents, dont le nom indique le contenu : un fichier pour chaque association de l’école, un pour la BU, etc.

Comme dit précédemment lors de la conception, pour en faciliter l’accès, nous les avons tous placés dans le répertoire Assets/Json du projet Java. Le parsage de ces fichiers est particulièrement aisé du fait de leur structure très proche du langage naturel, mais néanmoins très adapté au travail informatique.

FIGURE 4-MODELE DE LA STRUCTURE D’UN FICHIER JSON

Dans le but de faciliter l’accès à toutes ces informations, un schéma de poupées russes a été utilisé pour sauvegarder les informations parsées en attente de la base de données. La structure de base de ce schéma découle de celle des fichiers JSON, qui est assez stable dans l’ensemble : JData -> Vidéos, Photos, Datasources -> Data -> Header, Row

FIGURE 5-MODELE POUPEES RUSSES D’UN FICHIER JSON

JData DataSources

Videos Photos

Data

Header Row

(15)

Rapport Final

1 4

Les JData représentent l’ensemble du contenu d’un fichier JSON. Elles sont constituées d’une liste de datasources. Ces dernières quant à elles peuvent être des vidéos, des photos ou des Data. Les Data pour finir, sont le contenu primaire des fichiers JSON. Constituée d’un Header et d’un Row ou liste d’informations, une Data peut constituer un paragraphe entier de l’application.

Le parsage de ces informations est grandement facilité par l’utilisation de la librairie org.json de Java. En effet, cette librairie met à disposition des classes pour chaque type de contenu d’un fichier JSON, ainsi que des méthodes d’accès toutes faites, permettant de récupérer exactement le contenu souhaité. Pour ce faire, elle charge tout le contenu du fichier pour construire une instance de la classe JSONObject, ce qui en simplifie l’accès, comme pour le DOM avec des fichiers XML, le principal avantage étant la légèreté des fichiers JSON, induite par leur simplicité d’écriture.

Les fichiers XML

Ces derniers ont, quant à eux, été un peu plus délicats à parser, du fait de leur complexité, mais surtout de leur longueur. En effet, ils contiennent toute l’offre de formation détaillée de l’ENSIM, ainsi que les informations nécessaires pour représenter cette dernière dans l’application. Nous disposions de trois fichiers XML, respectivement pour l’offre de formation, sa représentation dans l’application, et la représentation des informations annexes.

Le premier fichier est formaté selon la norme CDM de représentation des offres de formation des établissements supérieurs. Il s’agit là donc d’un format règlementé, au contraire des fichiers JSON sur lesquels nous avions plus ou moins la main et pouvions être force de proposition quant à leur modification.

Les deux autres étaient présentés sous un format similaire, mais beaucoup moins strict.

Ils étaient également largement moins longs que le premier qui, à lui seul, faisait presque 3500 lignes d’information, voire plus.

Pour parser ces fichiers, nous avons utilisé l’API XmlPullParser de Java, fournie par la XmlFactory et basée sur l’implémentation de la technologie Stax, permettant de parcourir le fichier ligne par ligne jusqu’à la fin pour en récupérer les données. Cette API dispose de plusieurs méthodes permettant de récupérer les données précises de la ligne lue. Par contre, il est bien entendu totalement impossible de revenir en arrière dans le parsage pour savoir à quel niveau l’on en est.

Fort de ce constat, nous avons développé une méthode de parsage particulière basée sur la puissance de la récursivité et sur la structure des poupées russes précédemment mentionnées ; et permettant de remplir ces dernières au fur et à mesure de l’avancée dans le fichier. La classe de base se construit alors progressivement à partir des informations récupérées au cours de la progression (comme la classe JSONObject pour les fichiers JSON) et permet par la suite d’y avoir accès aisément.

Cette méthode a été peaufinée au fur et à mesure de nos développements, et utilisée pour l’implémentation du parsage des trois fichiers.

(16)

Rapport Final

1 5

Le constat final en est d’ailleurs que le parsage des fichiers sur la version Android se fait incroyablement plus vite que sur la version iPhone, obligeant même à ralentir le splashscreen et remettant en cause l’utilité de la base de données.

B. Insertion et Récupération dans la base de données

La base de données est un composant indispensable pour le bon fonctionnement de l’application Allschools. Elle permet en effet de stocker de manière cohérente et structurée les données contenues dans les différentes rubriques et de les mettre à jour. Plusieurs programmes peuvent accéder à ces données simultanément, mais dans notre cas, sous Android, la base de données est intégrée à l’application.

Notre base utilise le moteur SQLite qui ne nécessite aucune administration et nulle mise en place de services. La première étape de l’implémentation a été de comprendre le fonctionnement, les enjeux de SQLite et les relations entre la base et le reste de l’application.

Nous sommes partis sur un déroulement en trois blocs : le parsage, la base de données et l’instanciation des classes présentes dans la base.

Pour déterminer le contenu de ces classes, il a fallu examiner minutieusement la structure des fichiers XML et JSON et analyser les dépendances entre les balises. La complexité de ces fichiers a été la première source de difficulté, car certaines balises se retrouvaient parfois filles et parentes d’une autre. Il a non seulement fallu extraire le nom des classes et des attributs associés, mais également définir les connexions entre elles, via des identifiants.

Contrairement à MySQL, SQLite fonctionne sans l’installation d’un serveur de base de données. Son fonctionnement s’avère par conséquent simplifié : des classes inclues dans Android nous ont permis de réaliser la création des tables, à l’instar de SQLiteOpenHelper qui contient les méthodes de création et de mises à jour. Une classe statique a suffi pour implémenter ces méthodes, utilisant par ailleurs des requêtes SQL. Dans la hiérarchie d’Allschools, la base de données se situe au niveau du modèle, tout comme les classes issues de la structure interne des fichiers XML et JSON. Le contrôleur fait appel à elle après l’exécution du parsage, mais elle n’agit que sur les classes du modèle.

Suite au parsage des fichiers XML et JSON fournis dans le contrat du projet, la base de données avait pour tâche d’insérer les informations parsées dans les classes correspondantes.

Les fichiers JSON sont les plus simples, étant donné leur redondante structure composée d’un entête et de lignes. Les fichiers XML, en revanche, ont dû être divisés en trois catégories différentes, chacune possédant une structure particulière : les Cdm, les CdmApp et les App. Des packages ont été créés pour ces divisions, dans lesquels ont été implémentées les classes relatives aux balises répertoriées dans la première partie du projet. Par rapport à elles, la base de données est composée de tables qui sont le reflet des classes. Chaque table a pour nom celui d’une classe, et pour champs les attributs de cette même classe. Par exemple, pour les fichiers Cdm, la classe Card, dotée de quatre attributs (photo, imageName, frameColor et title) correspond à une table Card comportant les champs « photo, image, frameColor et title », en plus d’un identifiant nécessaire.

Voici une représentation des classes du fichier Cdm, avec les références. Chaque classe est une table de la base de données.

(17)

Rapport Final

1 6

FIGURE 6– DIAGRAMME ENTITES/RELATIONS DU FICHIER CDM

(18)

Rapport Final

1 7

On se rend compte que les dépendances sont nombreuses, et certaines ne sont pas représentées sur le schéma pour le simplifier. Chaque table est déclarée dans la classe de la base de données, sobrement intitulée BaseSQLite, sous la forme d’une requête SQL avec les attributs et leur type.

Le diagramme des App est plus simple que celui des Cdm.

FIGURE 7-DIAGRAMME ENTITES/RELATIONS DU FICHIER APP

Les tables des App et des Cdm n’interagissent pas entre elles. Toutes cependant ont été déclarées dans la même classe, par souci de simplicité. Le diagramme des fichiers JSON a été représenté et finalisé en premier, car plus accessible, notamment pour tester l’insertion dans la base.

(19)

Rapport Final

1 8

FIGURE 8-DIAGRAMME ENTITES/RELATIONS DES FICHIERS JSON

Les clés primaires sont soulignées, et s’incrémentent au fur et à mesure des insertions dans la base. Les clés étrangères ne sont pas toutes présentées sur les schémas, mais elles ont dû être soigneusement adaptées dans le code. Le diagramme des CdmApp est le plus simple :

FIGURE 9-DIAGRAMME ENTITES/RELATIONS DU FICHIER CDMAPP

(20)

Rapport Final

Rapport Final : Interface de l’application

1 9

La table coupée en haut n’est autre que CourseCdm, à ne pas prendre en compte. On remarque néanmoins que la table Program est liée à la fois aux Cdm et aux CdmApp, ce qui n’est pas vraiment exact. Une table ProgramApp n’a pas été représentée, par oubli, mais c’est elle qui est reliée aux tables des CdmApp, tandis que Program n’appartient qu’aux Cdm. Toujours est-il qu’une fois les tables créées dans BaseSQLite, notre travail s’est orientée vers les méthodes propres à chaque classe des Cdm, des App, des CdmApp et des JSON. Ces méthodes ne sont autres que les getters et setters des attributs de classes, ainsi qu’une méthode toString qui renvoie les valeurs sous forme de chaînes de caractères.

Une difficulté majeure s’est posée au moment d’implémenter l’insertion des données dans la base. Après quelques recherches, nous avons trouvé une classe baptisée ContentValues qui nous permettrait de stocker un ensemble de valeur selon la typologie clé/valeur. Nous avons donc écrit pour chacune des tables une méthode d’insertion basée sur le principe des ContentValues et se terminant avec l’appel de la méthode insert() dans la table concernée. Ainsi, les valeurs intégrées dans le ContentValues sont insérées dans la table lorsque la méthode est appelée.

De nombreux problèmes d’incompatibilité entre les attributs de classe et les champs des tables de la base nous ont contraints à réécrire plusieurs fois ces méthodes, à l’aide du mode de débuggage. La phase suivante a été d’écrire les méthodes d’insertions dans les classes cette fois- ci. Par exemple, dans la classe Association du App, nous avons une méthode insertSQL() qui initialise les identifiants des tables en relation 1/1 avec elle, puis appelle les insertSQL() de ces tables-là ainsi que la méthode insertAssociation() définie dans BaseSQLite. Cet enchaînement de fonctions réalise l’insertion dans la base.

De même, les méthodes de récupération ont été écrites dans chaque classe, faisant appel aux méthodes get() de BaseSQLite, qui effectuent des requête de sélection dans les tables. Des difficultés à propos des types se sont posés, notamment l’utilisation d’AtomicInteger au lieu d’Integer. Le plus délicat dans cette partie du projet a été de s’assurer de la bonne concordance des noms de variables entre celles du parsage et celle de la base. Une seule incohérence lors de la création des tables, de l’insertion ou de la récupération arrêtait le programme et les erreurs n’étaient pas toujours évidentes à identifier. Nous avons fait usage du programme SQLiteDatabaseBrowserPortable pour vérifier que les champs des tables se remplissaient correctement après l’exécution, ce qui nous a été d’une aide précieuse. Au final, malgré quelques minimes incohérences pendant l’insertion des Cdm, la base de données a bien été réalisée à partir de zéro.

VII. Interface de l’application A. Carrousel

Le carrousel est un élément d’interface permettant d’afficher une liste. Les items de la liste sont affichés sous la forme de cartes placées dans un environnement 3D disposé en cercle. Une carte est affichée au milieu au premier plan et est cliquable. Deux types d’interactions sont possibles :

- Un clic sur la carte de gauche ou de droite de la carte centrale fait bouger le carrousel pour placer la carte cliquée au centre, elle devient alors cliquable.

- Un mouvement horizontal du doigt fait bouger le carrousel dans le sens du mouvement.

(21)

Rapport Final

2 0

Dans ce carrousel, chaque carte correspond à un nœud, et un clic sur cette carte entraînera l’affichage du nœud correspondant par le contrôleur.

Le carrousel est basé sur celui développé par Igor Kushnarev en 2011. Ce dernier se base sur la librairie 2D d’Android. L’objet Camera issu du package android.graphics permet la transformation 3D d’objets 2D par le biais d’une matrice.

Le problème de base est que le carrousel d’origine ne répond pas aux besoins du projet.

En effet, il est conçu pour afficher de petites icônes non cliquables, il est plutôt orienté présentation que navigation, il faut alors le modifier.

Il existe quatre types de carrousel, ayant chacun ses spécificités de conception :

- Les carrousels mono utilisés pour afficher une seule carte. Ici, on a désactivé les mouvements du carrousel. Nous n’affichons qu’une seule carte, à l’endroit où est placé la carte de devant sur les autres carrousels.

- Les carrousels duo utilisés pour afficher 2 cartes. Comme pour le mono, on désactive les mouvements, mais en plus on détermine la carte qui a été cliquée, non pas en récupérant les coordonnées, mais en calculant le milieu du carrousel. Si c’est à gauche du milieu, c’est la première carte et vice versa.

-

- Les carrousels simples utilisés pour afficher trois à six cartes. C’est le carrousel de base qui a été implémenté ici.

(22)

Rapport Final

2 1

- Les carrousels complexes utilisés pour afficher sept cartes et plus. On affiche un effet de dégradé progressif sur les cartes au fur et à mesure qu’elles vont vers le fond pour simuler un effet d’infini. On remplace la carte, invisible, du fond en fonction du mouvement du carrousel.

-

Chaque type de carrousel est implémenté par une classe qui hérite de CarouselView. Le contrôleur du carrousel appelle, en fonction du nombre de cartes dont il dispose, l’une de ces classes.

Ensuite, le carrousel implémente un écouteur de mouvement du doigt, en l’occurrence nous n’en gardons que deux : onFling pour un jeté du doigt et onSingleTap pour le simple clic. En ce qui concerne l’onFling, on récupère le signe de la composante horizontale de la vélocité (x).

S’il est positif, on pivote le carrousel de gauche à droite, sinon dans le sens inverse. Pour le single tap, on vérifie que la zone cliquée ne correspond pas à une carte cliquable. Pour cela, on récupère les coordonnées de la carte centrale (seule cliquable), et on les compare à celles de la zone cliquée. Si le clic n’est pas compris dans cette zone, on vérifie si elle se situe à gauche ou à droite et en fonction, on pivote le carrousel.

L’une des premières nécessités était d’afficher du texte en dessous des cartes. Pour cela, nul besoin de modifier le carrousel, il suffit de traiter les images des cartes pour incruster du texte sur une portion d’une image transparente.

Il faut ensuite gérer une transparence progressive dans le cas du carrousel complexe.

Pour cela, on va modifier l’alpha en fonction de l’angle de la carte. L’angle 0 étant la carte centrale au premier plan. Il suffit de calculer un alpha proportionnel à l’angle.

Comme dit au début, l’une des difficultés sous Android est l’adaptation à la taille de l’écran. C’est d’autant plus difficile que le Carrousel, à cause des transformations matricielles, est difficile à dimensionner au besoin de l’écran. Pour respecter cette contrainte, nous avons défini un ratio minimum entre la largeur du carrousel et sa hauteur. Cette contrainte empêche pour l’instant le carrousel d’être optimisé pour l’affichage horizontal. Pour le cacher, nous avons désactivé la rotation du téléphone.

(23)

Rapport Final

2 2

B. Article

Un article est tout d’abord un type de nœud. Il est composé de paragraphes, chacun étant composé d’un titre et d’un texte. Il y a quatre types de paragraphes :

- Titre : affiche un titre, utilisé classiquement au début d’un article. Il n’y a généralement qu’un texte.

- Table : paragraphe modélisant un tableau à deux colonnes.

- Liste : énumération.

- Paragraphe : texte simple sans organisation particulière.

Ces articles sont ensuite affichés par l’ArticleController par la classe correspondant à l’article. Un article correspond à une page composée de paragraphes présentés dans des containers blancs. Il y a différents types de containers, stockés dans des classes, correspondant chacun à un type de paragraphe :

- ArticleTitleView : affiche le titre en gras et centré

ArticleTableView : affiche les cellules dans un tableau aux bords invisibles

- ArticleListView : affiche les textes séparés par des traits horizontaux

- ArticleParagraphView : affiche le texte dans une mise en forme particulière

(24)

Rapport Final

2 3

C. Gestion des Onglets

Allschools affiche cinq onglets au bas de l’écran. Quatre pour accéder aux grandes parties de l’application, et la dernière pour afficher les autres grandes parties moins importantes sous forme d’une liste.

Les onglets

Chaque onglet a trois attributs : - un texte

- une icône

- une intention pour appeler une autre activité

Nous avons donc conçu un modèle contenant les trois attributs pour chaque onglet. Puis sur ce modèle se base la création de la vue de chaque onglet. Nous avons par conséquent créé une barre d’onglets qui contient les cinq onglets de l’application. Les différents onglets sont créés et ajoutés dans la barre d’onglets à partir d’un contrôleur.

Sous Android, la classe permettant de créer un onglet est TabSpec. Cette classe nous a permis de :

- donner un nom et une icône à un onglet par la fonction setIndicator() - donner une intention (activité appelée lorsque l’onglet est cliqué) par la fonction

setContent()

Cette classe est dépendante de la classe TabHost qui permet de créer une barre d’onglets.

Pour créer cette dernière, l’activité qui l’implémente doit hériter de la classe TabActivity. Puis on récupère la barre d’onglets grâce à la fonction getTabHost() qui est dans la classe TabActivity.

Toutes les barres d’onglets utilisées dans l’application sont définies de la même façon.

(25)

Rapport Final

2 4

L’onglet Autre

Une liste des grandes parties non affichées sur les autres onglets.

Chaque élément de la liste a trois attributs : - Une icône

- Un nom - Une attention

Pour la liste, nous avons créé aussi un modèle, une vue et un contrôleur : - Le modèle contient les trois attributs pour chaque élément de la liste - La vue ou la liste est définie

- Le contrôleur pour créer la liste

Sous Android, nous avons utilisé la classe ListeView pour créer la liste en définissant son contenu dans un fichier de style XML. Ce fichier contient une ImageView pour l’icône et un TextView pour le texte.

Drag and drop

Pour personnaliser les onglets pour les grandes parties de l’application, nous avons implémenté la méthode de drag and drop. Lors d’un long clic sur un onglet ou sur un élément de la liste qui donne l’accès aux grandes parties de l’application, un objet de type ImageView se crée et prend l’icône de l’élément cliqué. Cette image est donc déplaçable sur l’écran en la glissant avec le doigt. Lorsqu’on enlève le doigt de l’image, on teste si l’image créée se superpose avec un onglet ou un élément de la liste. Si c’est le cas, on permute l’icône, le nom et l’intention des deux éléments et on supprime l’image créée, sinon on supprime simplement l’image créée sans que rien d’autre ne se passe.

Cette fonctionnalité était bugée, mais a été refaite par ST-Ericsson.

(26)

Rapport Final

Rapport Final : Modules

2 5

VIII. Modules

A. Module Partenaires

Nous avons également implémenté le module Partenaire dont le but est de présenter l’ensemble des partenaires industriels de l’ENSIM classés par type. Ce module s’inscrit dans l’ensemble des modules de l’application, au même titre que celui des associations, un module se définissant dans le cadre de notre projet comme une partie indépendante de l’application (possédant ses propres données et sa propre activité) appelée au besoin et ne demandant aucune modification et aucune implémentation de la part du reste de l’application pour s’exécuter.

Le module Partenaire est constitué visuellement de trois onglets nommés OR, ARGENT et BRONZE de par le type des partenaires qui y sont présentés en ordre alphabétique.

Il s’agissait donc ici pour nous de créer les layouts (fichiers xml définissant une interface utilisateur) de présentation de ce module, d’en créer les classes appelantes, d’en récupérer les données pour remplir ces classes, et d’en définir et implémenter la classe d’activité principale.

Nous utilisons dans ce module deux fichiers de layouts au moins : un pour l’affichage d’une liste déroulante (listview) sur fond blanc et un second pour l’interface de l’ensemble du module, contenant la barre horizontale portant les trois onglets (TabHost).

Enfin, en ce qui concerne les classes implémentées, en plus des classes de configuration du TabHost, nous avons implémenté une activité par onglet et une activité principale. C’est dans les classes des onglets que nous récupérons les informations propres à ces onglets et les mettons en forme pour pouvoir les afficher. L’activité principale, pour finir, instancie les trois dernières et leur attribue un onglet chacune.

FIGURE 10-CAPTURE D'ECRAN DU MODULE PARTENAIRE

(27)

Rapport Final

2 6

B. Module de Stage

Le module de stage via un serveur web permet à l’utilisateur de consulter les offres de stage actuellement disponibles. Il permet même de faire un suivi personnalisé des offres. Ce module est encore en cours de développement.

Interface

Pour le module de stage, nous avons trois interfaces.

La première pour l’authentification. Elle contient :

- Deux TextField pour saisir le mot de passe et le nom de l’utilisateur - Un Button pour s’identifier

- Une zone de texte pour afficher les informations de l’identification Un fichier de style XML contient la structure de cette interface.

La deuxième pour afficher les offres avec une image, un titre et une description. Cette interface utilise le même modèle de ListView créé pour accéder aux grandes parties de l’application

La troisième partie pour afficher la description du stage. Elle est définie dans le fichier XML qui suit :

(28)

Rapport Final

2 7

Modèle

Voici le modèle utilisé pour le module :

Champs Utilisation

offre Balise définissant une offre de stage.

titreOffre Titre de l’offre de stage.

FormationCandidat Lien vers un .PDF détaillant l’offre.

DetailMission Description détaillée de l’offre de stage.

DateCreationOffre Date d’ajout de l’offre dans la base de données.

Annee Année de formation requise pour l’offre.

CompetencesCandidat Filière du candidat.

TypeOffre Importance de l’offre de stage.

NomStructure Nom de la structure proposant l’offre de stage.

(29)

Rapport Final

2 8

C. Module Carte 3D

Dans cette partie, on s'intéresse à la réalisation d'une Carte Google Map intégrée à notre application, cette carte aura pour rôle de guider le visiteur de l’ENSIM pour faciliter l'accès à l'établissement.

Pré-réalisation

Deux opportunités se présentent pour intégrer une carte Google Map dynamique : - intégration d'une page web avec un tag sur la localisation de l'Ensim.

- Implémenter le code de la carte pour l'intégrer directement à notre application.

Il a été décidé d’utiliser l’intégration directe via la Google API, celle-ci nécessite une API Key.

La première étape pour l'obtention d'une clé API est de créer un MD5 checksum : une clé unique nécessaire pour avoir une signature valide de notre future API KEY.

Le MD5 peut être généré grâce au debug certificate en exploitant le fichier debug.keystore de notre projet. Le fichier debug.keystore se situe classiquement sous le chemin : <répertoire utilisateur>/.android/debug.keystore. Une fois le chemin connu, il faut lancer une console Windows pour exécuter et utiliser le générateur de clés SSL de java « KeyTool:

keytool -list -alias androiddebugkey -keystore <chemin_vers_le_fichier_debug>.keystore - storepass android -keypass android

Une fois la clé MD5 générée, on utilise cette dernière pour générer notre clé API, pour cela il suffit de se rendre sur le service Google Developpers sous la rubrique « signature Google API » :

https://developers.google.com/android/maps-api-signup?hl=fr

Ainsi, on obtient une clé valide qui nous permet d'exploiter les services Google dans notre application, en particulier le service Google Map.

Pour réaliser notre carte Google Map, notre activité principale doit hériter non pas de la classe Activity, mais de MapActivity qui constitue la classe mère de toute implémentation Google Map.

Notre activité principale aura pour rôle d'afficher une carte dynamique dans laquelle on pourra naviguer librement, mais qui ne pointe sur aucune adresse prédéfinie (rue « Aristote » dans notre cas).

Conception et implémentation

Pour résoudre ce problème, nous allons implémenter une classe qui permet de rajouter des superpositions de carte personnalisée. Pour cela, nous allons réaliser une classe qui hérite de ItemizedOverlay, qui est une classe de base pour un Overlay, consistant en une liste de OverlayItems. Cette classe va nous permettre de rajouter nos coordonnées géographiques de l'ENSIM à la liste des « OverlayItems ». Ainsi, on pourra pointer sur notre élément de liste dans la classe principale du module et arriver de ce fait à afficher la carte de l'ENSIM avec un zoom défini à 20 lors du lancement de la carte, pour la première fois par l'utilisateur.

(30)

Rapport Final

2 9

Ainsi, l'organisation de ce module serait telle qu'elle est décrite dans le diagramme suivant :

Enfin, après mise à jour du fichier AndroidManifest et du fichier layout du module, il ne nous reste qu'à rajouter le marqueur de notre choix pour le positionner sur l'adresse de l'ENSIM en mettant un zoom par défaut de 20 % sur les coordonnées (48.019152, 0.157993), ces coordonnées doivent être converties en type long pour pouvoir les exploiter.

On obtient une vue sur l'adresse de l'école dès que l'utilisateur pointe sur le tab Carte 3D :

FIGURE 11-CAPTURE D'ECRAN DE LA CARTE 3D

(31)

Rapport Final

3 0

D. Module Contact

Le module Contact se présente sous la forme d’un fichier où l’on affiche des informations sur les personnes issues du CDM. Nous utilisons la classe ContentProvider pour interagir avec les contacts d’un téléphone.

(32)

Rapport Final

Rapport Final : Conclusion

3 1

IX. Conclusion

Au terme de notre développement, l’équipe projet « AllSchools – Portage Android » est heureuse d’avoir pu participer à ce projet, tant du fait des incroyables améliorations, d’un point de vue professionnel, qu’il nous a permis d’effectuer ; des rencontres qu’il a permises (ST- ERICSSON, UNIVERSITE DU MAINE) ; des inspirations qu’il nous a données ; que de la simple fierté d’avoir participé à la réalisation d’un projet dont l’impact nous dépasse même de par sa grande utilité et sa portée.

Par ailleurs, bien que notre participation s’arrête officiellement à cette date, ce projet est loin d’être terminé. Il a en effet encore du chemin à parcourir avant d’arriver à remplir toutes les attentes des personnes s’y étant investies. C’est la raison pour laquelle nous serons honorés d’être comptés parmi les référents de ce projet, et de pouvoir apporter, si besoin, des renseignements aux personnes qui contrairement à nous, continueront de travailler à l’élévation de cette application, autant pour aider que pour rester en contact et continuer d’en apprendre.

(33)

Rapport Final

Rapport Final : Annexes

3 2

X. Annexes

A. Cahier des charges

I. Présentation générale du problème 1. Projet

a. Présentation

Du fait de la croissance rapide des parts de marché du système d’exploitation Androïd, AllSchools dans un souci d’être accessible à tous doit être porté sur cet OS.

b. Contexte

Apple est un support mobile qui propose des applications intuitives, parmi lesquelles se trouve l’application «AllSchools ». Cette application permet aux futurs étudiants d’obtenir une vue synthétique de l’offre de formations proposées par l’Université du Maine. Dans le cadre du développement des médias, l’ENSIM s’investit dans l’évolution de cette application.

Les améliorations de l’application « AllSchools » ont toujours pour but de promouvoir l’offre de formation de l’enseignement supérieur de l’Université du Maine sur support mobile Androïd.

Le portage de l’application sous Androïd permettra à l’application d’être plus accessible au public concerné.

c. Retour sur investissement

Il n’y a aucun retour sur investissement. En effet, l’application développée sera mise à disposition gratuitement sur l’Androïd Market, et ce, dans une optique de la rendre la plus accessible possible pour les utilisateurs.

2. Contexte

a. Situation du projet

(34)

Rapport Final

3 3

Le projet est développé par une équipe de six personnes, tous en deuxième année à l’ENSIM (École Nationale Supérieure d’Ingénieurs du Mans) dans le cadre des projets de 2^ème année de l’ENSIM.

b. Suites prévues

L’application sera reprise ensuite par ST-Ericsson qui poursuivra le projet dans le cadre d’un stage de niveau Master 2.

c. Nature des prestations demandées

Notre travail est de développer le portage sur le système d’exploitation Androïd de l’application AllSchools en respectant le plus scrupuleusement possible l’architecture de l’application originelle.

d. Parties concernées par le déroulement du projet et ses résultats

Le maître d'ouvrage, directeur des études informatique de l’ENSIM : - M. Florent Carlier

- Email : florent.carlier@univ-lemans.fr La maîtrise d’œuvre est constituée de :

- M. Vincent Molliere

- Email : vincent.molliere.etu@univ-lemans.fr - M. Darryl Tadmi

- Email : Darryl.Tadmi_Tchangam.etu@univ-lemans.fr - M. Anass Chabbab

- Email : Anass.Chabbab.Etu@univ-lemans.fr - M. Amjed Chaouat

- Email : vincent.molliere.etu@univ-lemans.fr - M. Joffrey Durand

- Email : Joffrey.Durand.Etu@univ-lemans.fr - M. Abdellah Moustaid

- Email : abdellah.moustaid.etu@univ-lemans.fr

3. Description de l’existant

(35)

Rapport Final

3 4

Une version pour Iphone et Ipad de Apple existe déjà. Il existe de plus une version non- dynamique de l’application sous Androïd. Les seuls points qui seront repris de cette application sont les interfaces.

4. Enoncé du besoin

La principale finalité de cette application est qu’elle doit permettre à des utilisateurs de pouvoir se renseigner sur les études post-bacs par le biais de l’application. Il pourra se renseigner sur les établissements, les associations…

De plus, pour les utilisateurs de l’ENSIM, un étudiant pourra se renseigner sur les propositions de stage.

Aussi, un utilisateur pourra suivre les actualités liées aux parcours.

5. Contexte

a. Moyens humains

Voici les membres de l’équipe du projet : - Vincent MOLLIERE

- Darryl TADMI - Anass CHABBAB - Amjed CHAHOUAT - Joffrey DURAND - Abdellah MOUSTAID

Pour les soutenir dans ce projet, ils pourront bénéficier de la participation si nécessaire de leurs enseignants de l’ENSIM.

a. Matériels utilisés

Voici le matériel que nous utiliserons au cours du projet :

• Des ordinateurs portables

• Des ordinateurs de bureau en complément.

• Une machine distante hébergeant un serveur de contrôle de version.

i. Ordinateurs portables

(36)

Rapport Final

3 5

Les ordinateurs portables nous serviront de plateforme de développement principale. De plus, leur aspect « portable » est le bienvenu car il permet également de travailler sur le projet à tout moment et où que ce soit.

ii. Ordinateurs de bureau

Les ordinateurs de bureau seront des supports secondaires de développement.

iii. Machine distante

La machine distante permettra l'hébergement d'un serveur de contrôle de version nommé TortoiseSVN. Cette machine n'aura pas d'autre intérêt que celui de centraliser les sources et documents du projet.

b. Langages & techniques utilisés

Pour le développement d’un tel site, il faudra mettre en œuvre une stratégie technique bien révisée, et nous tourner vers des outils de développement bien spécifiques. C’est pourquoi, nous combinerons :

- Pour l’application en elle-même, nous utiliserons Java par le biais du SDK Eclipse avec les bibliothèques nécessaires à la programmation sous Eclipse.

- Pour le service de stage, les technologies Web habituelles.

(37)

Rapport Final

3 6

II. Expression fonctionnelle du besoin

1. Fonctions de service, contraintes et besoins en IHM

a. Fonctions de service principales

L’application doit permettre, Aux utilisateurs suivants :

- Simple utilisateur - Etudiants d’une école - Responsable d’une école

… de réaliser les actions suivantes : - Simple utilisateur :

 parcourir les écoles

 parcourir les formations

 parcourir les associations

 parcourir les fonctionnalités pratiques

 parcourir les contacts

 parcourir les partenaires

 lire l’information d’une fiche

 parcourir les différentes sections d’une fiche

 parcourir les vidéos d’une fiche

 parcourir les images d’une fiche

 lire une vidéo d’une fiche

 voir une image d’une fiche

 enregistrer un contact ou un partenaire

 envoyer un mail à un contact ou à un partenaire

 parcourir les différentes formations

 parcourir les différentes écoles.

 suivre les actualités.

- Etudiants d’une école :

 s’authentifier.

 utiliser les services propres à son école.

- Responsable d’une école

 s’authentifier

 ajouter des services

 mettre à jour les services b. Contraintes

Le demandeur du projet n’a pas vraiment émis de limites ou de contraintes, à part l’exigence de faire le portage de la version Iphone de l’application vers une version Androïd sans

(38)

Rapport Final

3 7

y ajouter d’autres fonctionnalités. Par exemple, un étudiant de l’université du Maine peut accéder à des fonctionnalités telles que le module stage, en utilisant son identifiant et son mot de passe de l’université.

Le module ENT ne sera pas disponible sur cette application ainsi que les fonctionnalités suivantes, même si elles nous semblent indispensables dans cette application :

- L’accès aux emplois du temps.

- L’accès aux événements

- L’accès à la messagerie de l’université - L’accès aux disponibilités des salles.

- L’accès aux relevés de notes

- Les inscriptions en ligne aux différents cursus et aux différentes activités de l’université (SUIAPS, CUEPs, etc.)

- Autres

c. Besoins en IHM

Le support utilise pour l'application AllSchools, en l’occurrence l’Iphone Galaxy SII, suppose une interaction tactile entre les diffe rents menus. Pour naviguer entre les interfaces, au lieu d'avoir des liens sous forme textuelle, sont mis en place des ico nes qui se doivent d'e tre d'une taille suffisante pour permettre une navigation aise e et adapte e aux mouvements digitaux.

Une fois l'ico ne en question touche e, le sous-menu correspondant apparaî t en une fraction de seconde. La notion de simplicite est essentielle pour ne pas perdre l'utilisateur dans la hie rarchie des interfaces. Les ico nes doivent ainsi respecter une charte graphique colore e, dont la fonction est facilement identifiable. Une barre d’onglets au bas de l’e cran permet de retourner a la racine de l’application, permettant de ce fait de choisir l’une des quatre sections principales.

Les cibles concerne es par l'application sont entre autres les e tudiants d'une e cole de l'enseignement supe rieur et les responsables de formation. Cela induit sur la manie re dont sont pre sente es et spe cifie es les informations. Un e tudiant doit pouvoir reconnaî tre les sections qui lui sont de die es d'un simple coup d’œil, sans avoir a acce der a celles-ci pour ve rifier. De me me, dans cette optique, en fonction de l'utilisateur authentifie , les sections disponibles varient.

L'interface consacre e aux responsables de formation sera par conse quent plus fournie que celle de die e aux simples utilisateurs.

L'application doit supporter l'affichage de textes, notamment pour la section des actualite s, ainsi que des images et des vide os. Ces dernie res interagissent du point de vue tactile, une vide o se lance en touchant le bouton Lecture, s'interrompt avec le bouton Pause. Dans un ordre d’ide e similaire, les pages qui disposent d’un contenu exce dant la taille de l’e cran glissent selon la verticale, sous l’impulsion tactile de l’usager. Les interactions possibles entre l’humain et la machine varient donc suivant le contenu affiche .

1. Critères d’acceptabilité

(39)

Rapport Final

3 8

Les critères obligatoires sont :

- L’application dispose des mêmes fonctionnalités que l’originale.

- L’architecture de l’application est identique sauf particularités du langage de l’application de départ.

Les critères importants sont :

- L’application doit être fiable et doit présenter le moins de bugs possible pour une expérience utilisateur optimale.

- L’application doit être rapide dans l’exécution de ses fonctionnalités.

Les critères accessoires sont :

- L’ajout de fonctionnalités est possible mais seulement après la finalisation du portage.

2. Niveaux des critères d’appréciation et ce qui les caractérise

a. Niveaux dont l’obtention est imposée

Un test approfondi du système pendant une durée à déterminer permettra de savoir si l’application présente les mêmes fonctionnalités que l’originale.

b. Niveaux souhaités mais révisables

Les utilisateurs doivent nous faire le moins de rapport de bug possible. Si des rapports sont soumis, les bugs devront être corrigés le plus vite possible. De plus, on notera dans le suivi des utilisateurs, les remarques sur l’application et si aucun retour important n’est recueilli, alors la condition est remplie.

On s’évertuera aussi à calculer les temps de réponse entre la demande d’une fonctionnalité et son affichage et ceci pour toutes les fonctionnalités. Si les valeurs relevées sont raisonnables, alors le critère est respecté.

(40)

Rapport Final

3 9

III. Cadre de Réponse 1. Solutions Proposées

a. Le MVC

Comme dans tout bon développement, nous utiliserons le MVC (Model-View-Controller) pour notre implémentation. En effet, cela implique de diviser de manière indépendante les différentes parties du programme.

Le modèle ici sera constitué de tout le contenu et de toutes les classes d’objets, codées bien entendu en Java Androïd. Nous y rangerons mes offres de formation, de stages (etc.), les associations, les débouchés, toutes les caractéristiques propres à l’école, ainsi que toutes les méthodes associées à ce contenu.

La vue quant à elle sera ici une sorte de vue contrôlée plutôt que d’avoir un contrôleur à part, ceci pour nous plier à l’existant. En effet, le Carrousel qui constitue la vue dispose d’un contrôleur intégré. Par ailleurs, le système Samsung Galaxy se charge lui-même du contrôle en ceci que c’est au travers de fonctions et boutons déjà présents que l’application sera contrôlée.

Ajoutés au carrousel pour compléter la vue, il y’aura la représentation, dans l’application, des différents offres. Ces dernières seront le résultat du parsage de fichiers XML en provenance du serveur central AllSchools.

b. L’authentification

Un système d’authentification sera mis en place pour les accès en nécessitant une. Il ne sera notamment permis qu’aux étudiants de l’ENSIM d’accéder aux offres de stage de l’ENSIM.

Dans ce cas le système se branchera au système d’authentification de l’ENT de

l’université concernée, pour éviter d’avoir à gérer une base de données de tous les étudiants de toutes les universités partenaires.

Une connexion internet sera bien sûr requise mais les informations consultées pourront être téléchargées et enregistrées dans le mobile pour un accès ultérieur.

Quant aux informations ne nécessitant pas d’authentification particulière, elles seront accessibles automatiquement et téléchargeables au même titre.

c. Le parsage

Comme indiqué précédemment, les données du modèle seront complétées suite au parsage de fichiers en provenance du serveur central AllSchools. Ce dernier nous envoie des fichiers au format CDM, calqué sur XML, décrivant l’ensemble des offres de formation.

Ceci dit, au vu du caractère chronophage du parsage de fichiers XML dans le contexte d’une utilisation mobile, les données autres que les offres de formations, celles qui ne sont pas

(41)

Rapport Final

4 0

formatées CDM et donc sur lesquelles nous avons le contrôle, seront au format JSON, beaucoup plus pratique du point de vue vitesse de parsage.

Ainsi, il sera question d’avoir deux modes de parsage différents : un réservé aux fichiers CDM et un autre pour les fichiers JSON. Le résultat de ces 2 opérations en une sera ensuite exporté vers une base de données SQLITE, laquelle sera utilisée par la suite pour restituer les informations, plutôt que de les télécharger à chaque fois.

Par ailleurs, le processus de parsage intégrera une phase de téléchargement des fichiers : d’une part les CDM, d’autre part les JSON, avec un paramètre permettant le versionning, avant de les rediriger dans les répertoires correspondants dans le téléphone.

d. La base de données SQLITE

Les informations contenues dans cette base gérée de manière interne à l’application, seront, comme indiqué précédemment, le résultat du parsage des fichiers de contenu. Elle contiendra donc l’ensemble des offres de formations et de stage, ainsi que les différentes données propres à l’école.

Ces informations étant sujettes à changement, elles ne peuvent être statiques. C’est là qu’intervient la capacité de versionning du téléchargement. En effet, les fichiers référés dans la base de données ont un paramètre de version permettant d’indiquer s’ils sont à jour ou pas ; auquel un nouveau téléchargement des fichiers non à jour uniquement est proposé à l’utilisateur.

2. Pour l’ensemble du produit

a. Prix de la réalisation de la version de base

Etant un projet au sein d’une école et donc exécutés par des élèves, le budget pour la main- d’œuvre est nul.

De plus, tous les logiciels de développement et les langages de programmation sont libres et gratuit.

Le budget pour la réalisation du logiciel est nul.

b. Mesures prises pour respecter les contraintes et leurs conséquences économiques

Afin de respecter les contraintes et leurs conséquences économiques, plusieurs séries de test du produit ont été planifiées tout au long de la phase de réalisation afin de mieux intégrer le facteur d'évolution technologique, de portabilité, …

(42)

Rapport Final

4 1

c. Prévisions de fiabilité

Prévoir la fiabilité d’un système relève essentiellement d’une étude statistique (intervalles de confiance notamment) et probabiliste sur des échantillons limités, afin d’estimer au mieux le taux de panne relatif à chaque module du projet.

Ces taux de panne étant obtenus sur des échantillons forcément limités en taille, leur valeur est gouvernée par les lois de la statistique (intervalles de confiance notamment).