Akrach Ibrahim Petetin Cédric Année universitaire 2014-2015 Encadrant du projet : M. Christophe Lang Application Smartphone de diffusion d informations pour les étudiants Troisième année de Licence Informatique UFR Sciences et Techniques,
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 2/39
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 3/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. 4/39
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 ) 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. 5/39
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. 6/39
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. 7/39
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). 8/39
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. 9/39
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. 10/39
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. 11/39
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. 12/39
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). 13/39
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. 14/39
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. 15/39
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. 16/39
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 17/39
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 () 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). 18/39
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 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. 19/39
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. 20/39
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. 21/39