Application Smartphone de diffusion d'informations pour les étudiants

Akrach Ibrahim Année universitaire

Petetin Cédric 2014-‐2015

Encadrant du projet : M. Christophe Lang

Rapport de Projet

Application Smartphone de diffusion d’informations pour les étudiants

Troisième année de Licence Informatique

UFR Sciences et Techniques, Université de Franche-‐Comté

Ibrahim Akrach Rapport de Projet Cédric Petetin

Université de Franche-‐Comté 2/39

Sommaire

Remerciements ....................................................................................................................................................4

I) Cadre du projet .............................................................................................................................. 5 1) Un module de la troisième année de Licence Informatique ..................................................5 2) Le choix du sujet .......................................................................................................................................5

II) Vers une application d’information à destination des étudiants ....................................... 6 1) Du sujet initial............................................................................................................................................6 2) … au cahier des charges, version initiale……………...……………………………………...…...…..6 3) … au cahier des charges, version finale……………………………………….....……………………..7

III) La partie commune : la base de données ............................................................................... 9 1) Outils utilisés..............................................................................................................................................9 2) Création des différentes tables...........................................................................................................9 3) Les différentes tables..............................................................................................................................9 a) La table Agenda................................................................................................................................9 b) La table Notifications.................................................................................................................. 10 c) La table User ................................................................................................................................... 10 d) La table FaqBu............................................................................................................................... 10 4) Les autres tables .................................................................................................................................... 10 a) La table Admin............................................................................................................................... 10 b) La table NotifSuscribers ........................................................................................................... 10

IV) Du côté du site ...........................................................................................................................11 1) Langages et outils utilisés.................................................................................................................. 11 2) Le thème utilisé : Bootstrap Admin............................................................................................... 11 3) La page « Agenda »................................................................................................................................ 12 3-‐1) Créer un nouvel événement................................................................................................ 12 a) Récupérer la date facilement .................................................................................... 12 b) Obtenir le titre, le contenu et le type d’événements....................................... 13 c) Envoyer ces données à la base de données ........................................................ 13 3-‐2) Accéder aux anciens événements..................................................................................... 14 a) Historique des événements....................................................................................... 14 b) Choix de la date et affichage...................................................................................... 14 4) La page « Notifications »..................................................................................................................... 14 5) La page « Statistiques »....................................................................................................................... 15 6) La page « FAQ BU » ............................................................................................................................... 16 7) Les autres pages..................................................................................................................................... 16 a) Page « Connexion »...................................................................................................................... 16 b) Page « Index » ................................................................................................................................ 16 c) Page « Administration »............................................................................................................. 16



V) Du côté de l’application.............................................................................................................17 1) Le langage SWIFT .................................................................................................................................. 17 2) Les outils utilisés ................................................................................................................................... 17 a) Xcode ................................................................................................................................................. 17 b) Le compte Developer.................................................................................................................. 18 c) Du bon usage des certificats .................................................................................................... 18 d) Les téléphones............................................................................................................................... 19 3) L’Agenda.................................................................................................................................................... 19 4) L’envoi et la réception des notifications...................................................................................... 21 5) Le menu Gauche..................................................................................................................................... 22 6) Les webviews .......................................................................................................................................... 22 7) La page de connexion automatique............................................................................................... 23 8) La FAQ BU ................................................................................................................................................. 23 9) L’onglet contact ...................................................................................................................................... 23

VI) Bilan .............................................................................................................................................24 1) L’avancement du projet ...................................................................................................................... 24 2) Les écueils................................................................................................................................................. 24 3) Les améliorations possibles.............................................................................................................. 24 4) D’un point de vue personnel............................................................................................................. 25

Conclusion .......................................................................................................................................................... 26

Netographie........................................................................................................................................................ 27

Annexes ................................................................................................................................................................ 28

Résumé ................................................................................................................................................................. 39



Remerciements

Nous tenions tout d’abord à remercier notre encadrant Monsieur Christophe Lang pour ses conseils avisés, sa gentillesse et sa disponibilité.

Nous remercions aussi Monsieur Fabrice Bouquet et Monsieur David Laiymani pour nous avoir fourni des explications durant toute l’avancée de notre projet.

Ensuite, nous voulions remercier Monsieur Antoine De Gieter qui a mis à notre service son savoir et son expérience dans le développement des applications ainsi que Monsieur Jérémy Othenin pour nous avoir fait profiter de ses talents de graphiste avec le logo de l’application.

Nous tenions enfin à remercier toutes les personnes qui nous ont aidés de près ou de loin.



I) Cadre du projet

Nous allons exposer les circonstances dans lesquelles s’inscrit la réalisation de ce projet. 1) Un module de la troisième année de Licence Informatique

Dans le cadre de nos études en troisième année de Licence Informatique à l’UFR ST (Sciences et Techniques) de Besançon, la réalisation d’un Projet sous la forme d’un module est demandée aux étudiants. Ce projet prend place du mois d’octobre au mois de mars. Notre binôme (composé d’Ibrahim Akrach et Cédric Petetin) a ainsi dû réaliser un choix parmi une liste de projets, par ordre de préférence, différentes technologies étant proposées. Après tirage au sort, il se trouve que nous avons été affectés à notre premier choix, l’intitulé du sujet étant : « Application Smartphone de diffusion d’informations pour les étudiants », encadré par M. Christophe Lang, maître de conférences à l’UFR ST. 2) Le choix du sujet

Pour reprendre les termes du sujet, le projet consiste en « la création d’une application mobile proposant des informations aux étudiants et un lien vers les outils essentiels […] de leur cursus. » Elle devra notamment permettre de « suivre l’étudiant tout au long de l’année et en quelque sorte de le « coacher » via l’application ». Aussi, cette application doit recevoir des messages flash.

Même si nous avions formulé différents vœux, c’est ce sujet qui a porté toute notre attention.

Premièrement, nous n’avions pas encore eu l’occasion d’aborder les technologies qui concernent le développement d’applications sur téléphone, c’était donc une très bonne occasion d’en avoir une première approche si jamais nous obtenions le projet. Deuxièmement, nous avons l’habitude de réaliser des projets dans différents modules. Ces projets sont évalués par les professeurs et jamais ils ne sont utilisés par des personnes tierces. Par conséquent, il était très stimulant de savoir que le travail que nous allions effectuer allait être utilisé concrètement et qu’il ne s’agissait pas seulement d’avoir une note dans un module.

Troisièmement et pour terminer, nous étions intéressés par le développement de notre propre application sur téléphone en dehors du cadre de nos études, avant même d’aborder cette troisième année de licence. Nous n’avions pas les connaissances nécessaires et réaliser ce projet nous permettrait donc de nous autoformer.



II) Vers une application d'information à destination des étudiants Avant de commencer le développement du projet, il nous a fallu le définir globalement dans un premier temps avant de développer les détails. 1) Du sujet initial... Après que les projets aient été affectés, nous avons pris un rendez-‐vous avec notre encadrant, M. Christophe Lang, afin d’avoir davantage d’informations sur le sujet, notamment sur les technologies et langages que nous devions employer. Alors que nous pensions nous retrouver seuls avec M. Lang le jour de la réunion, quelle ne fut pas notre surprise en voyant que deux autres personnes étaient présentes ! Il s’agissait de Madame Nathalie Chappe, qui est la Directrice Adjointe de l’UFR SJEPG (Sciences Juridiques Politiques Economiques et de Gestion), chargée des innovations pédagogiques, ainsi que de Madame Habiba Imaaingfen, employée au sein de la BU (Bibliothèque Universitaire) Proudhon de Besançon. C’est la présence à cette réunion de toutes ces personnes qui nous a fait ressentir que ce projet revêtait un véritable enjeu. Elles ont ainsi détaillé le sujet à travers le cahier des charges qu’elles avaient élaboré avec leurs collègues en tant que commanditaires de cette application d’informations. 2) ... au cahier des charges, version initiale… Ce que nous ne savions pas, c’est que l’application n’était pas destinée à tous les étudiants mais uniquement à ceux qui viennent d’arriver en première année et qui ont besoin de prendre leurs marques. Comme précisé sur le sujet, il était bien question de mettre en place au sein de l’application un menu qui renvoie vers les différents outils utiles aux étudiants, tels que leur emploi du temps, la plateforme Moodle, l’actualité de l’Université, le site du réseau de bus Ginko, le site de l’UFR SJEPG ou encore les actualités entre autres.

L’application devait également permettre un suivi des étudiants tout au long de l’année, et c’est à travers une fonctionnalité nommée « l’Agenda » que cela devait prendre forme. Il nous a donc été expliqué que cet agenda serait en quelque sorte un semainier et que ces messages devaient être de différents types (dates essentielles, informations, conseils) avec un affichage dans une bulle ou avec une mascotte et un code couleur. On devait pouvoir changer de semaine en faisant glisser le doigt sur la gauche ou la droite.



Les messages flashs devaient donc aussi être recevables par les téléphones à l’ouverture de l’application, avec un certain code couleur.

Comme nous nous en étions doutés, Mesdames Chappe et Imaaingfen nous ont expliqué qu’elles voulaient une interface simple afin d’alimenter l’Agenda et l’administrer. Aussi, sur cette interface, différentes statistiques devaient être disponibles pour que les commanditaires puissent s’en servir pour des travaux en interne.

Il nous avait également été demandé de créer une version pour Androïd, Windows Phone et iPhone.

D’autres exigences, plus secondaires, ont été formulées : une version adaptable en anglais et un moteur de recherche concernant les entrées de l’Agenda.

3) … au cahier des charges, version finale

Après avoir effectué d’autres réunions avec M. Lang et les commanditaires, nous sommes parvenus à un cahier des charges final qui a été validé par l’ensemble des personnes responsables du projet. (voir Annexe 1)

Tout d’abord, nous avons choisi de développer l’application pour les iPhone et non pas pour Windows Phone et Android. En effet, face à l’ampleur de la tâche, M. Lang a expliqué qu’il serait impossible en trois mois d’avoir ces trois versions. Le choix s’est donc porté sur l’iPhone puisque, selon nos commanditaires, c’est cette marque de téléphone que la majorité des étudiants au sein de l’UFR SJEPG possède.

Comme fonctionnalité principale, leur définition de l’agenda était assez claire.

A propos des liens, nous avons proposé un menu qui soit placé à gauche de l’écran, accessible depuis n’importe où et qui recouvre l’écran principal une fois qu’on l’a ouvert.

Une page « service de la BU » nous a été demandée suites aux réunions par Madame Pouilloux, conservateur de la BU Proudhon, qui prendra la forme d’une FAQ (Foire Aux Questions).

Nous avons proposé de mettre en place une barre de chargement qui se remplit et change de couleur selon l’avancée du semestre (vert au début, quand les étudiants ont encore du temps, jaune au milieu, pendant la toussaint, puis rouge à la fin, en période d’examens). Pour les statistiques, l’interface d’administration devait récupérer le nombre de connexions et également le temps passé par les utilisateurs sur l’application.

A propos des fonctionnalités secondaires (et donc ajoutables uniquement si le temps le permettait et/ou si elles étaient faciles à créer), nous avons notamment gardé la version adaptable en anglais et le moteur de recherche.



Une fois le cahier des charges défini, il nous a fallu passer à la pratique, le travail se répartissant clairement entre 2 grands axes de développement : la création de l’application pour iPhone et la création de l’interface d’administration. Nous avons donc commencé le travail à partir de rien, « from scratch » (ou ex nihilo pour les latinistes).



III) La partie commune : la base de données

Nous savions déjà avant de commencer à programmer qu’il y avait un élément incontournable qui permettrait la communication entre l’interface web et l’application : une base de données. Nous avions déjà des connaissances acquises en première année, complétées par celles du semestre 6 de Licence Informatique.

1) Outils utilisés Nous avons utilisé l’interface phpMyAdmin pour créer les tables et effectuer différents tests de nos requêtes. 2) Création des différentes tables

Nous avons défini un premier schéma de la base de données qui s’est révélé être celui que nous avons utilisé pour presque tout le projet. Nous avons juste ajouté un ou deux attributs et une table quand ils étaient nécessaires au développement.

3) Les différentes tables

Les tables que nous avons créées suivent grossièrement les noms des pages du site et correspondent au contenu de l’application. Voici les tables principales dont nous détaillerons les attributs les plus intéressants. (voir Annexe 2)

a) La table Agenda

Cette table contient :

-‐AgendaId, qui permet d’identifier de manière unique un événement,

-‐AgendaDate, qui correspond au jour où l’événement est créé (au format ANNEE-‐MOIS-‐JOUR),

-‐AgendaWeek qui est le numéro de la semaine de l’année dans lequel l’événement s’inscrit,

-‐AgendaTitle, qui est le titre de l’événement,

-‐AgendaMessage, qui est le contenu de l’événement.

-‐AgendaType qui est le type de l’événement, c’est-‐à-‐dire s’il concerne une information générale, de la BU ou de l’UFR SJEPG (ainsi, les 3 valeurs possibles pour cet attribut sont : GENERAL, BU, SJEPG),

-‐AgendaAuthor, qui est l’identifiant de l’administrateur qui a crée l’événement.



b) La table Notifications

Dans cette table, nous avons les attributs suivants :

-‐NotificationId, qui permet d’identifier de manière unique la notification,

-‐NotificationType, à l’instar de AgendaType, donne le type de la notification,

-‐NotificationText, représente le contenu de la notification.

c) La table User

Elle contient les attributs :

-‐UserId, qui permet d’identifier chaque nouvel utilisateur,

-‐UserDevice, qui correspond à l’appareil qui s’est connecté à la base de données,

-‐UserModel et UserOS, qui sont des informations respectivement sur le modèle du téléphone et son système d’exploitation.

d) La table FaqBu Cette table permet de créer la page « services de la BU » et contient donc les attributs :

-‐FaqBuID, qui est l’identifiant de la question posée,

-‐FaqBuQuestion, qui correspond à l’intitulé de la question,

-‐FaqBuAnswer, qui est la réponse correspondante à la question.

4) Les autres tables

Il s’agit d’autres tables qui sont réservées à des utilisations plus triviales.

a) La table Admin

Cette table renferme des informations sur les administrateurs : identifiant, mot de passe, adresse mail etc.

b) La table NotifSuscribers

On utilise cette table pour identifier les utilisateurs qui acceptent de recevoir des notifications.



IV) Du côté du site

L’interface d’administration permet d’entrer les informations affichées dans l’application. Elle doit être accessible, intuitive et prendra par conséquent la forme d’un site web.

1) Langages et outils utilisés

Avec nos connaissances acquises au cours du module « Langages du Web » de deuxième année de Licence Informatique, nous avons réemployés les langages HTML, CSS et PHP. Nous avons également dû utiliser le langage JAVASCRIPT dans une moindre mesure.

Des outils que nous avions déjà utilisés, toujours dans le cadre des cours sur le web, ont été réinvestis : un serveur local MAMP ainsi qu’un éditeur de texte, ici SublimeText.

Figure 1 : Logo de MAMP Plus tard au cours du projet, nous avons eu besoin de mettre l’interface en ligne sur un serveur. Nous avons d’abord employé la plateforme gratuite « freehosting » mais face à des problèmes rencontrés, nous avons utilisé une autre plateforme gratuite, byethost.com. 2) Le thème utilisé : Bootstrap Admin

Lorsque nous avons commencé à développer le site, il s’était déjà écoulé beaucoup de temps depuis le début du projet qu’il nous avait fallu affiner à travers les réunions. Aussi, nous ne sommes pas très doués pour tout l’aspect qui concerne le design. C’est pourquoi, pour gagner du temps et également proposer aux futurs utilisateurs de l’interface un affichage qui soit agréable à l’œil, nous avons employé le framework (structure logicielle) BootStrap Admin.

Celui-‐ci est réputé pour son caractère « responsive » (réactif), c’est-‐à-‐dire qu’il permet une adaptation du contenu, peu importe le navigateur et le support. Pour faire simple, il s’agit uniquement de la « forme » du site web que nous allions développer, toute la partie qui traite les données devant être implémentée par nous deux.



Trois pages qui traitent lesdites données sont les plus importantes : la page « Agenda », la page « Notifications » et la page « Statistiques ».

3) La page « Agenda »

3-1) Créer un nouvel événement

a) Récupérer la date facilement

La fonctionnalité Agenda étant l’élément le plus important du projet, cette page se devait d’être des plus pratiques d’utilisation. Il fallait donc créer une interface qui propose intuitivement de gérer les informations. (voir Annexe 4)

Comme il s’agit d’entrer les données par semaine de connexion, nous avons d’abord pensé à juste choisir le numéro de la semaine puis d’entrer les champs correspondants (titre et contenu de l’événement) avec une remise à zéro de la base de données à la fin de l’année universitaire.

En effet, il existe une semaine 1, une semaine 2, etc. pour chaque année alors pour créer un système plus simple à implémenter, nous voulions faire table rase des anciennes entrées pour accepter les nouvelles (et donc faciliter l’implémentation et éviter que les événements de plusieurs années différentes ne se superposent).

Après réflexion, nous avons jugé plus utile que des traces des événements créés restent dans la base de données, ne serait-‐ce que pour servir aux administrateurs de référence d’une année à l’autre.

Nous avons alors décidé de choisir l’année et la semaine. Avant d’une nouvelle fois nous raviser, puisqu’il aurait fallu calculer la semaine dans laquelle l’événement est ajouté. Finalement, et parce que c’était la solution qui nous semblait la plus ergonomique, nous avons opté pour ceci : on choisit le jour de l’année et à partir de ce jour, on en déduit la semaine ciblée qui contient l’événement, sans aucun calcul.

Pour ce faire, on a d’abord songé à utiliser des formulaires de type « liste déroulante » mais ça impliquait d’effectuer 3 actions différentes pour choisir une date.

Après quelques recherches pour une solution plus conviviale, nous avons opté pour un calendrier JAVASCRIPT qui affiche les jours et le mois actuel automatiquement et qui permet aisément de naviguer entre les dates grâce à des petites flèches.



Figure 2 : Calendrier

Pour récupérer la date, il a suffi d’associer ce calendrier à un formulaire en PHP, ainsi la date était sous cette forme : ANNEE-‐JOUR-‐MOIS.

b) Obtenir le titre, le contenu et le type d’événements

Nous avons crée deux formulaires pour entrer l’intitulé de l’événement ainsi que son contenu afin d’être stockés au sein de la base de données. A propos du type, nous avons crées trois boutons radio : GENERAL, BU, SJEPG.

Il était question dans le cahier des charges d’afficher une couleur différente par type d’événement sur l’application, et même si nous ne savions pas encore comment procéder, nous avions déjà de quoi différencier lesdits événements.

L’ensemble des formulaires sus-‐cités était renvoyé par un bouton « Envoi » et des alertes JAVASCRIPT ont été ajoutées dans le cas où l’utilisateur oublierait de les renseigner.

c) Envoyer ces données à la base de données

Pour les champs « Titre de l’événement » et « Contenu de l’événement », les données des formulaires sont récupérées et après connexion à la base de données, sont envoyées en effectuant une requête de type « INSERT ».

Concernant la date, il a d’abord fallu extraire la semaine lui correspondant. Le langage PHP intègre la fonction « date » avec de très nombreuses fonctionnalités (renvoi du jour/semaine/année, test du caractère bissextile d’une année, etc).



Pour obtenir la bonne semaine, nous avons ainsi utilisé la fonction date avec 2 arguments : « W » qui permet d’obtenir la semaine, et « AgendaDate » qui correspond à la date que l’administrateur a choisi dans le formulaire qui contient le calendrier.

3-2) Accéder aux anciens événements

La page Agenda devait permettre d’afficher le contenu déjà crée et également de supprimer les événements en cas d’erreur ou de modifications à effectuer.

a) Historique des événements

Afficher un historique de l’intégralité des événements aurait pris beaucoup de place à l’écran. Dans un premier temps, nous avions envisagé d’afficher un historique des derniers événements entrés mais ça n’aurait pas eu de sens. Ces événements peuvent effectivement être disséminés sur toute une année.

Nous avons alors décidé d’afficher les données selon la date choisie par l’administrateur. b) Choix de la date et affichage

Une nouvelle fois, nous avons utilisé le calendrier JAVASCRIPT pour choisir une date. Nous récupérons ainsi la semaine qui correspond à cette date sous la forme d’un tableau dont la taille s’adapte automatiquement au contenu et qui comprend : la date, la semaine, le titre, le message, le type et l’auteur de l’événement.

Au début, la date était affichée au format « US » à savoir : ANNEE-‐MOIS-‐JOUR alors nous avons employé une requête qui retourne la date au format JOUR-‐MOIS-‐ANNEE. Aussi, les événements qui correspondaient au même numéro de semaine de plusieurs années s’affichaient, nous avons donc comparé la valeur de l’année dans la requête à celle du jour choisi, afin que seuls les bons événements soient affichés.

Enfin, nous avons crée la colonne « Supprimer » qui intègre un formulaire de type « case à cocher » afin de supprimer les entrées indésirables (une seule à la fois).

4) La page « Notifications »

A l’instar de l’agenda, un formulaire permet d’entrer le contenu de la notification. (voir Annexe 5) Ce contenu est ensuite stocké dans la base de données afin de permettre l’affichage des dix dernières notifications en bas de la page.

On peut également choisir le type de notifications pour les statistiques (mais ceci n’influera pas sur la couleur puisque sur iPhone, les messages flashs ont tous un fond gris).

Contrairement à l’agenda, il n’est pas nécessaire de supprimer une notification puisqu’une fois envoyée, on ne peut plus y accéder sur les téléphones.



L’envoi des notifications sur les téléphones est direct et ne nécessite pas de récupérer les informations dans la base de données. Nous expliquerons le procédé plus bas au sein de la partie « V) 4) L’envoi et la réception des notifications ».

5) La page « Statistiques »

Pour réaliser la page de statistiques, les données sont récupérées au sein de la base de données à travers différentes requêtes qui permettent par exemple : d’obtenir le nombre de notifications par type, le nombre d’événements par type, par date, le nombre de connexions etc. (voir Annexe 6)

Les requêtes sont placées dans des fichiers distincts et on utilise la bibliothèque que notre camarade Antoine De Gieter a développée et qui utilise l’interface PDO (PHP Data Objects).

Le framework BootStrap inclut une bibliothèque JAVASCRIPT qui s’appelle Morris et qui permet de créer différents graphiques, courbes et diagrammes en bâtons. Le problème qui s’est posé est le suivant : une fois la requête effectuée, comment faire pour que les données passent du langage PHP au langage JAVASCRIPT ?

Nous avons essayé différentes méthodes qui n’aboutissaient pas, jusqu’à ce que l’on découvre le JSON (JavaScript Object Notation) qui est un format de données comme le XML par exemple. Il permet donc de structurer l’information et c’est ainsi que les données transitent du PHP au JAVASCRIPT et permettent l’affichage des données sur les graphiques. Pour utiliser le JSON, deux lignes de code suffisent : json_encode($variable), pour encoder la variable au format JSON dans le PHP, et JSON.parse, pour parcourir la variable au format JSON dans le JAVASCRIPT.

Figure 3 : Récupération des données en JSON.



6) La page « FAQ BU »

Cette page ressemble à la page agenda, la date en moins. On entre ainsi la question et la réponse correspondante, et on peut supprimer ces entrées grâce à un historique présent sur la page.

7) Les autres pages

Ces pages sont des pages très courantes sur des sites web, c’est pourquoi nous les exposons brièvement.

a) Page « Connexion »

C’est la page sur laquelle on arrive lorsqu’on l’on va sur le site. On entre un identifiant, un mot de passe et on accède à la page Index.

b) Page « Index »

On trouve sur cette page des informations générales (quelques statistiques brèves) comme le nombre d’administrateurs ou de connexions. (voir Annexe 3)

c) Page « Administration »

Cette page permet de changer les informations d’administration et d’ajouter un nouvel administrateur.



V) Du côté de l’application

Puisque nous avions décidé de développer l'application sur iPhone, il a fallu adopter les outils qui sont proposés par la firme Apple, l'entreprise qui produit les iPhone. On a donc dû apprendre un nouveau langage, maîtriser un nouveau logiciel et disposer d'un compte de développement.

1) Le langage SWIFT

Jusqu'à 2014, le principal langage de programmation d'application sur iPhone était l'OBJECTIVE-‐C.

Un langage est apparu depuis, le langage SWIFT, développé par Apple. Il est supposé être beaucoup plus simple d'utilisation que l'OBJECTIVE-‐C, bien qu'il en soit dérivé.

Nous avons découvert que l'OBJECTIVE-‐C n'était pas compatible avec les nouveaux systèmes d'exploitations, tandis que le SWIFT l'est et est également rétrocompatible avec les anciens OS. Cependant, il est possible d’intégrer des éléments d’OBJECTIVE-‐C dans du code en SWIFT.

C'est donc avec ce langage que nous avons crée l'application. La documentation est relativement volumineuse et la syntaxe très différente des langages que nous avions appris jusqu'à présent. Nous nous sommes donc essentiellement inspirés de tutoriels, lesquels ne sont pas nombreux au vu du caractère récent du SWIFT. Nous avons parfois utilisé des tutoriels en OBJECTIVE-‐C que nous avons adapté au langage SWIFT.

2) Les outils utilisés

a) Xcode

Figure 4 : Logo de Xcode



Si l'on veut développer un logiciel sur iOS, l'environnement de développement Xcode est incontournable. Il fournit une kyrielle d'outils à la disposition des développeurs et permet par des « glisser-‐déposer» de placer des éléments en complément de l'aspect programmation.

Nous pouvons ainsi éditer le code, le compiler, et également l'exécuter sur la plateforme virtuelle de notre choix (iPhone 4, 4S, 5 etc.)

De manière générale, XCode est basé sur ce que l'on nomme un « storyboard» qui est une sorte d'établi virtuel. Il permet de gérer les différents écrans d'affichage (ou vues) appelés «views», les relations de ces views ainsi que leur design à travers des outils que l'on appelle « viewController»

Il existe différents types de viewController :

-‐ viewController : permet de gérer une vue de base, les barres d'outils et les barres de navigations,

-‐ TableViewController : permet la gestion des UITableView qui sont des tableaux (on l'utilise par exemple pour la FAQ),

-‐ CollectionViewController : permet de gérer une UICollectionView, qui sont en quelque sorte des cases (on emploie ce viewController pour l'agenda),

-‐ NavigationViewController : permet de « piloter» l'ensemble de ces viewControllers.

b) Le compte Developer

Pour développer sur Apple, il faut se délester de 99$ afin de disposer d'un compte « Developer».

Heureusement, l'UFC (Université de Franche-‐Comté) disposait déjà d'un compte et nous avons été ajoutés en tant que « member». Pour toutes les opérations qui demandaient plus de privilèges, nous nous sommes adressés à notre encadrant, M. Lang, qui disposait du rang d’«admin».

c) Du bon usage des certificats…

La société Apple est très exigeante quand il s'agit de développer des applications avec ses technologies. Des « certificats » sont alors délivrés et agissent en quelque sorte comme une « identification » et permettent une certaine forme de sécurisation des données de l'application.

Ils sont nécessaires par exemple pour envoyer des notifications ou simplement placer l'application sur le téléphone pour pouvoir la tester.

L'accès à ces certificats est relativement opaque, c'est pourquoi nous avons dû suivre des tutoriels avec M. Lang (puisqu'il était administrateur, c'est lui qui devait nous les délivrer).



d) Les téléphones

Dans un premier temps, à l'exécution, nous utilisions Xcode. Puis est venu le moment où il nous fallait prendre l'application en main.

Avec M. Lang, nous avons utilisé le téléphone de Cédric Petetin afin d'effectuer les tests en l'ajoutant sur le compte Developer. Un autre camarade a également pu tester l'application sur son téléphone car il disposait de son propre compte Developer.

En incluant Xcode et ses émulateurs, l'application a dont été testée sur 8 « téléphones » différents.

3) L’Agenda

Au départ, nous avons voulu générer des labels (zones de texte) automatiquement mais nous ne parvenions qu’à afficher qu’un seul événement de l’agenda. Nous avons donc utilisé une UICollectionView (des cellules en quelque sorte), ce qui nous permet d'afficher une collection d'événements. (voir Annexe 7)

Les événements sont récupérés sur le serveur, dans la base de données, grâce à une requête POST et sont une nouvelle fois retournées au format JSON. Voici un exemple du résultat d'une requête en JSON :

{

AgendaAuthor = 1;

AgendaDate = "2015-‐03-‐09";

AgendaId = 155;

AgendaMessage = VVVV;

AgendaTitle = AAA;

AgendaType = GENERAL;

AgendaWeek = 11;

}

Pour chaque événement, une cellule contenant un titre un texte et une date est créée.

L'agenda reconnaît les glissements de doigts de la gauche vers la droite pour revenir à la semaine précédente et de la droite vers la gauche pour afficher la semaine suivante.



C'est le code suivant qui permet ce « glisser » de doigt :

Figure 5 : Reconnaissance du glissement du doigt

Figure 6 : Action suite au glissement de doigt

Nous avons rencontré un problème lors de l'affichage des données sur le téléphone. Sur la console de Xcode, quand on passait d'une semaine à une autre, les informations de la base de données étaient bien récupérées. Sur l'application, les données s’affichaient avec une latence d’une vingtaine de secondes et à chaque changement de page, les cellules de l'agenda se superposaient. Ces deux dysfonctionnements compromettaient ainsi l'affichage.

En effet, l'application crée des threads (des tâches), ce qui faisait que la récupération des données et leur affichage se faisait dans deux threads différents d'où le délai.

La solution a été d'utiliser un observer (NSNotificationCenter.defaultCenter(), exécute une action quand il reconnaît les événements qui la déclenchent) que l'on appelle à la fin de la récupération des données. Cet observer lance la fonction « refresh » qui synchronise les threads et actualise les données. La latence a ainsi été réduite et les cellules ne se superposaient plus au changement de semaine.



Figure 7 : Fonction refresh

4) L’envoi et la réception des notifications

Les notifications dépendent du système d'exploitation (OS, Operating System) de l'appareil. Par exemple, sur iOS 8 et plus, les notifications peuvent inclure des boutons, ce qui n'est pas possible sur iOS 7.

L'utilisateur, en lançant l'application pour la première fois peut choisir de recevoir les notifications ou justement, de ne pas les recevoir.

S'il décide de les recevoir, Apple fournit un « token » (un jeton, qui est en fait une suite de numéro) qui correspond à l'appareil et que nous enregistrons dans notre base de données. C'est en renseignant ce token au moment d'envoyer la notification que le téléphone la recevra.

Nous avons principalement dû préparer l'application à recevoir des notifications, notamment en insérant cette portion de code qui permet de dire à l'application qu'elle va recevoir des messages flashs.

Figure 8 : Réception d’une notification

Au niveau de du site d'administration, dans la page « Notifications », il existe une fonction « sendNotif » qui récupère les données du formulaire dans lequel on a entré le contenu de la notification.

On récupère la liste des tokens à qui envoyer la notification puis on crée une connexion entre le serveur du site et les serveurs d'Apple.

Une array (liste) est créée, contenant le message de la notification, le son émis et le badge. Puis, on envoie l'array à Apple pour chacun des tokens et toutes les personnes qui ont accepté les notifications devront normalement la recevoir. (voir Annexe 8)

La principale difficulté que nous avons rencontrée concernait les certificats car il nous a fallu à plusieurs reprises demander à M. Lang de les générer puisque le processus pour les obtenir n’était pas très clair. Concernant le code par contre, nous avons trouvé des tutoriels très utiles concernant la démarche.



5) Le menu Gauche

Le principal problème était de trouver un moyen de faire notre menu en utilisant le storyboard car la plupart des tutoriels utilisaient du code. On ne pouvait donc pas créer de menu personnalisé, avec des images par exemple, comme nous le souhaitions. Ainsi, nous avons passé beaucoup de temps à trouver le bon tutoriel, celui que nous tentions d’utiliser fonctionnait mais incluait des fonctionnalités trop avancées pour que nous puissions les manipuler.

Nous avons finalement utilisé une bibliothèque OBJECTIVE-‐C (SWRevealViewController) qui nous a permis de faire de facon simple le menu. (voir Annexe 9)

On utilise une fonction « prepareForSegue » pour passer les liens à ouvrir dans les webview, ainsi la même webview est utilisée plusieurs fois.

Figure 9 : Envoi des données avec la fonction prepareForSegue

6) Les webviews

Pour naviguer sur les différents sites, on aurait pu depuis l’application ouvrir le navigateur du téléphone. Mais ça aurait été peu ergonomique, c’est pourquoi nous avons décidé d’utiliser des webviews qui sont des cadres dans lesquels on peut naviguer sur Internet.

Nous avons utilisé 2 webviews : une pour les sites faisant partie de la fac et une pour les sites extérieurs.

Dans les deux cas, lorsque l'on appuie sur l'onglet qui nous intéresse (site de la BU, Ginko Tempo etc.) dans le menu, les informations, telles que le lien du site, sont envoyées à la webView. C'est ceci qui nous permet d'utiliser la même webview pour afficher plusieurs sites différents.

Dans le cas des sites de l'UFR SJEPG, nous avons essayé de mettre en place une connexion automatique en passant par le CAS (Central Authentication Service, une fois authentifié par le CAS, l'utilisateur est authentifié sur tous les sites concernés par ce CAS) de l'UFR SJEPG.



Cependant, nous ne parvenions pas à envoyer les données automatiquement. Elles sont cependant récupérées dans la page de connexion automatique ou « login view ».

7) La page de connexion automatique

La logIn view est une page simple où l'utilisateur remplit deux champs «username» et «password» d'un formulaire.

En cliquant sur le bouton «Connecter», on enregistre les données dans la mémoire du téléphone, ce qui nous permet de garder les données en mémoire même après fermeture de l'application. (voir Annexe 10)

8) La FAQ BU

Pour la FAQ, on utilise une UITableView, ce qui nous permet d'afficher chaque question dans une cellule du tableau. Les données sont récupérées sur le serveur comme nous l'avions fait pour l'agenda. (voir Annexe 11)

Lorsque l'on appuie sur une cellule (qui correspond à une question), on ouvre une vue de réponse. En fait, on utilise de nouveau la fonction prepareForSegue qui permet de passer des données d'une vue à une autre. Ainsi, on récupère la question et la réponse dans la cellule que l'on envoie à la vue de réponse et, on affiche le tout dans cette vue de réponse.

Figure 10 : Transfert des réponses avec la fonction prepareForSegue

9) L’onglet Contact

La page de contact est une simple page affichant deux labels contenant le numéro de téléphone de l'UFR SJEPG et le mail de M.Lang.



VI) Bilan

Alors que vient la fin du projet, il est temps de prendre du recul sur ce que nous avons fait.

1) L’avancement du projet

Nous étions partis d’absolument rien et nous avons abouti sur une application qui est fonctionnelle. En effet, l’Agenda, la pièce maîtresse de l’application, affiche différents types d’informations selon les couleurs et d’un glissement de doigt, on peut passer d’une semaine à l’autre, avec un temps de chargement quasiment instantané.

Le menu gauche permet d’ouvrir des sites très utiles aux étudiants, exactement comme c’était prévu. Du côté de l’interface d’administration, l’ajout de données dans l’agenda et leur administration se fait de manière très intuitive. Il en va de même pour l’ajout de questions pour la page « Services de la BU ».

L’envoi de notifications fonctionne, elles sont reçues instantanément et des nombreuses statistiques sont disponibles.

2) Les écueils

Développer une application sous iOS nécessite des connaissances pointues, tant le langage SWIFT ressemble assez peu aux langages que nous avons appris jusqu’à maintenant et que le caractère récent du langage SWIFT rend la recherche d’informations plutôt pénible.

Même si c’était une étape nécessaire, nous avons consacré beaucoup de temps à affiner le projet et à prendre en main les outils de développement, tels que Xcode. Si nous faisions la majeure partie du travail ensemble, il a fallu séparer les tâches afin de réussir à finir le projet dans les délais impartis.

3) Les améliorations possibles

Au niveau des fonctionnalités principales, nous avons quasiment réalisé toutes les propositions. Celles que nous n’avons pas eues le temps de faire pourraient être implémentées. En reprenant le cahier des charges, il y a donc :

-‐ l’affichage d’une barre de chargement qui change de couleur selon l’avancée du semestre (vert au début, orange au milieu, puis rouge à la fin du semestre, pendant les examens),

-‐ la récupération du temps passé sur l’application (nous avons seulement pu récupérer le nombre de connexions).

Les fonctionnalités principales demandant déjà beaucoup de travail, nous n’avons pas pu ajouter les fonctionnalités secondaires comme la création de la version en anglais ou l’ajout d’un moteur de recherche.



Nous avons quand même essayé de créer la connexion automatique, les données ont bien été récupérées au sein de l’application mais nous n’avons pas réussi à les envoyer vers les webviews.

De manière générale, on nous avait conseillé l’utilisation de la bibliothèque « Alamofire » pour traiter les données mais il était trop tard pour l’implémenter quand on nous en a parlé.

A propos du design, nous n’avons pas l’œil artistique et nous avons fait du mieux que nous avons pu. Cet aspect peut être amélioré.

Au niveau de la sécurité du site web, nous avons sécurisé de manière sommaire avec les techniques que nous avons apprises et elle peut donc être augmentée.

Pour l’agenda, on pourrait permettre la suppression multiple dans l’historique de l’agenda et également sur la page FAQ BU.

Même si ça n’était pas présent dans le cahier des charges final, on avait envisagé une phase de test sur différents téléphones.

Enfin, la décentralisation du menu (c’est à dire que les administrateurs puissent choisir les rubriques du menu depuis le site web) peut être une option à intégrer, ainsi que l’affichage d’une version en ligne de l’agenda.

4) D’un point de vue personnel

Cette expérience de développement d’une application a sans doute été pour nous l’une des plus enrichissantes de nos trois années de Licence Informatique.

Tout d’abord, nous nous sommes retrouvés véritablement en relative autonomie (malgré l’encadrement de M. Lang) puisqu’il a fallu nous former nous-‐mêmes, chercher les informations, faire des choix de développement, établir des priorités et prendre des initiatives.

Aussi, le fait de nous dire qu’il y avait des « client(e)s » qui allaient se servir de notre travail nous a réellement transcendés et poussés à faire quelque chose que nous aurions pu utiliser nous-‐mêmes. Il a donc fallu nous mettre dans la peau des futurs utilisateurs, ce qui n’est pas forcément évident.

On peut dire d’une certaine manière que toutes ces actions nous ont responsabilisé et qu’on a eu un avant-‐goût de ce que pourrait être notre travail en Informatique plus tard.

Il nous a fallu également gérer le temps qui nous était imparti de manière optimale, et on se rend vite compte à mesure que le projet avance et que les difficultés s’accumulent que les mois que nous avons eu pour réaliser ce projet ne suffisent pas à tout réaliser comme nous l’avions prévu.

Même si nos connaissances en SWIFT sont vraiment sommaires, nous avons acquis suffisamment de connaissances pour développer notre application personnelle en dehors du cadre de l’université.



Conclusion

En définitive, comme le spécifiait le sujet initial, nous avons crée une «Application Smartphone de diffusion d’informations pour les étudiants».

Nous espérons vraiment que les utilisateurs apprécieront notre application, même si nous avons conscience qu’elle peut être améliorée et les fonctionnalités secondaires, réalisées, ce que nous regrettons de n’avoir pu faire, faute de temps.

C’est un sentiment étrange de se dire que notre travail sera sûrement repris par d’autres pour justement l’améliorer et le modifier sans que nous ayons quelque chose à dire.

La réalisation de ce projet fut pour nous une expérience qui nous a apporté beaucoup sur tous les points et nous sommes très heureux d’y avoir pris part.



Netograhie

-‐ Ray Wenderlich : http://www.raywenderlich.com/tutorials

-‐ OpenClassrooms : http://openclassrooms.com/

-‐ StackOverFlow : http://stackoverflow.com/

-‐ Développez.net : http://www.developpez.net/forums/

-‐ Apple Developer : https://developer.apple.com/

-‐ Server Density : https://blog.serverdensity.com/

-‐ iOSCreator : http://www.ioscreator.com/

-‐ AirPair : https://www.airpair.com/

-‐ Code With Chris : http://codewithchris.com/

.



Annexes

Annexe 1 : Cahier des charges

Cahier des charges Application Smartphone de diffusion d’informations pour les étudiants

Plateforme choisie : iPhone (iOS)

Fonctionnalités principales :

-l'agenda affichera les informations des administrateurs d'une semaine à l'autre, accessibles par un glissement de doigt (possibilité de revenir en arrière),

-ces informations (semaine après semaine) seront entrées par le biais d'une application web qui nécessite une identification par mot de passe,

-mise en place d'un "menu gauche" qui apparaîtra/disparaîtra selon les besoins de navigation ; dans ce menu gauche seront présents tous les liens qui renvoient vers l'Agenda, les informations, Moodle, l'emploi du temps ADE, l'actu de l'UFC etc.

-mise en place d'une barre de navigation affichée en haut,

-"services BU" : onglet qui mettra en avant les services importants de la BU sans renvoyer sur le site de celle-ci,

-affichage d'un catalogue de questions/réponses à propos de la BU ,

-disposition d'une ''frise" ou d'une barre de chargement au-dessus de l'agenda : plus le semestre avance, plus la barre se remplit et change de couleur (par exemple, pour le premier semestre, pour les premières semaines : vert, pour les semaines jusqu'à décembre : orange, pour le mois de décembre : rouge),

-création d'un onglet sur le site de l'UFR qui renverra sur l'application sur l'App Store,

-récupération du nombre de connexions et le temps passé sur l’application,

Fonctionnalités secondaires :

-création d'une version adaptable en anglais,

-sur la barre de navigation, ajouter des options qui permettent de changer de langue (passer du français à l'anglais et inversement), de se connecter à l'ENT et un bouton pour afficher le menu gauche sans avoir à le faire glisser,

-ajouter un moteur de recherche : recherche par mots indexés ou par catégories,

-affichage du temps passé sur chacune des rubriques de l'application,

-disposition de QR code pour faciliter le téléchargement.



Annexe 2 : Base de données



Annexe 3 : Page Index du site



Annexe 4 : Page Agenda du site



Annexe 5 : Page Notifications du site



Annexe 6 : Page Statistiques du site



Annexe 7 : L’Agenda



Annexe 8 : Réception des notifications



Annexe 9 : Le menu Gauche



Annexe 10 : La page de connexion



Annexe 11 : La FAQ



Résumé

Le but de ce projet est de développer une application pour iPhone à destination

des étudiants en première année de l’UFR SJEPG, ainsi que l’interface permettant de

l’administrer.

Le but de cette application est de fournir aux étudiants un suivi sur toute l’année

en fournissant des informations semaine après semaine.

Le but de l’interface d’administration est d’alimenter le contenu de l’application

et d’en obtenir des statistiques.

Mots clés : application, iPhone, iOS, SWIFT, MAMP, FILEZILLA, PHP, JAVASCRIPT, SQL

Documents

Application Smartphone de diffusion d'informations pour les étudiants