2015 TD3 FR Moodress - Epitech · 2014. 10. 12. · Documentation technique!!!!! !! 2015_TD3_FR_Moodress.pdf ! ! ! Résumé : Ce document décrit l’intégralité de l’architecture

Documentation technique L’équipe Moodress :

tchiko_s bonet_g thiec_a ozkul_o pica_d (Chef de groupe)

pons_c thomas_t labell_s

Documentation technique

2015_TD3_FR_Moodress.pdf

Résumé :

Ce document décrit l’intégralité de l’architecture du projet Moodress. Notre projet étant à la base un serveur utilisant Symfony et Doctrine pour créer notre base de données. Notre API permet ensuite à nos applications mobiles et notre site web de communiquer avec le serveur et avoir un accès indirect à la base de données. Nous utilisons pour réaliser notre solution le framework PHP Symfony2, l’ORM Doctrine pour la gestion de notre base de données et enfin Cordova (PhoneGap) pour développer les applications mobiles. Nous utilisons essentiellement Github pour gérer le code de notre projet et les tâches en cours de réalisation.



Tableau de révision :

Date Auteur Commentaire

24/02 – 16/03 Sandro Tchikovani Préparation du document, mise en page, corrections.

05/03 - 09/03 Steeven Labelle Les choix techniques

08/03 - 14/03 Arnaud Thomas Dessessarts

Elaboration de plan pour la partie Réalisation. Rédaction partie User, Notifications, Tag / Fashtags, Follower / Following, Interfaces utilisateurs. Elaboration de nouveaux schémas via l’outil Visio.

08/03 - 14/03 Alan Thiec Elaboration de plan pour la partie Réalisation. Rédaction des parties Postes, Albums, Commentaires, Like, Search, Statistics.

08/03 – 13/03 Omer Ozkul Partie architecture.

11/03 – 12/03 Guillaume Bonet Fixation de bugs

11/03 - 11/03 Thomas Tortorini Corrections

14/03 – 14/03 Dany Pica Corrections

03/07 - 03/07 Guillaume Rajout de la partie mobile

03/07 - 03/07 Arnaud Mise à jour par rapport à la version actuelle de notre produit

03/07 - 03/07

Alan Modification de la partie Module Modification de la partie Interface Utilisateur

04/07 – 04/07 Sandro Mise en page

02/10 - 05/10 Sandro,Dany,Omer Révision intégral du document, Mise en page



Sommaire

1) Contexte ........................................................................................ 1

2) Architecture .................................................................................... 1 A) « Use case » de notre architecture ................................................................. 1 B) Diagramme global de solution ........................................................................ 6 C) Diagramme des entités ................................................................................. 8

3) Choix techniques ............................................................................. 10

4) Modules ......................................................................................... 12 A) API ......................................................................................................... 12 B) Serveur ................................................................................................... 16 C) Mobile .................................................................................................... 18

a) Hiérarchisation ...................................................................................... 18 b) Déploiement .......................................................................................... 19 c) Test de l’application ................................................................................ 20 d) Débuggage ............................................................................................ 20

D) Base de données ....................................................................................... 20 a) User .................................................................................................... 20 b) Post/Album/Commentaires ........................................................................ 21 c) Like ..................................................................................................... 22 d) Notification ........................................................................................... 22 e) Tags / Fashtags ....................................................................................... 22 f) Follower / Following ................................................................................ 22 g) Fashthème ............................................................................................ 23 h) Report ................................................................................................. 23 i) Up/Premium ........................................................................................... 23

5) Fixation de bug ............................................................................... 23


2015_TD3_FR_Moodress.pdf 1

1) Contexte

L' « École pour l'informatique et les nouvelles technologies » ou EPITECH, est une école formant des experts en informatique sur cinq années. Elle dispose d’une pédagogie particulière. En effet sur chaque projet les étudiants sont impliqués dans leur apprentissage et peuvent donc s’adapter aisément aux contraintes des projets demandés par l’école et aussi, par exemple aux évolutions technologiques qui auront lieu au cours de leur carrière.

L’ « EPITECH Innovative Project » ou EIP, est la principale étape dans le cursus

de l’école. C’est un projet de fin d’études réunissant au minimum six étudiants. L’EIP se déroule sur une durée de trois ans, une durée bien plus importante que celle des projets en début de cursus. L’EIP est crucial dans le cursus car elle change le statut d’étudiant à celui de professionnel.

2) Architecture A) « Use case » de notre architecture

Les cas d’utilisations suivants représentent les actions que peut réaliser le

client. Ces diagrammes permettent de mettre en action notre architecture dans des scénarios qu’un utilisateur lambda pourrait rencontrer.

Le cas d’utilisation de la barre de navigation est l’élément principal que rencontrera chaque utilisateur connecté (ou non connecté). Elle est présente sur chaque page afin de permettre à l'utilisateur d'avoir accès à tout le site via une simple interface. Elle permet de lier chaque élément de notre site mais permet également la création de publications, et l'affichage des notifications reçus par l'utilisateur.

Voir le cas d’utilisation à la page suivante



Cas d’utilisation de la barre de navigation

Un autre élément visible par tous les utilisateurs et présenté via ce cas d’utilisation est la page d’accueil. C’est la page principale de notre réseau social qui permettra aux utilisateurs connectés (ou non connectés) de découvrir les nouvelles tendances créées par la communauté Moodress.



La page d'accueil affiche les derniers articles sur le fil d'actualités et les dernières publications mises en avant via la bannière défilante. Il est possible de spécifier l'affichage des publications que l'on souhaite via les filtres présents sous la bannière défilante.

Cas d’utilisation de la page d’accueil

Les publications sont les éléments principaux de notre réseau social. Elles permettent de partager un style aux autres utilisateurs.

Il est possible d'intégrer 1 à 7 images mais également une description (dans laquelle on peut nommer d'autres utilisateurs et des fashtags).

Cette publication sera ensuite vue par les autres utilisateurs qui pourront commenter et aimer cette publication.

Voir le cas d’utilisation de la vue détaillée d’une publication à la page suivante



Cas d’utilisation de la vue détaillée d’une publication

Sur la page profil il est possible à l'utilisateur de voir ses publications ainsi que les personnes qu'il suit ou qui le suivent. Il peut gérer ses albums (créer/supprimer un album ou ajouter/supprimer des images). Cette page permet à l'utilisateur de récapituler toutes les actions qu'il a pu réaliser sur le réseau social.

Cas d’utilisation de la page profil



La page des paramètres permet de modifier les éléments principaux de votre compte (nom, prénom, mail, photo de profil, ...).

Elle offre la possibilité de devenir premium afin de donner la possibilité à l’utilisateur de promouvoir leurs publications pour qu'elles apparaissent sur la bannière défilante de la page d'accueil.

Il est également possible de faire une demande afin de devenir une page marque pour les créateurs indépendants ou les entreprises. Cette dernière permet d'avoir un affichage différent afin d'être plus facilement reconnaissable au sein de la communauté.

On permet aussi la possibilité de supprimer son compte via cette page.

Cas d’utilisation de la page paramètre

La page d'administrateur permet aux administrateurs d'analyser l'activité du réseau social.

Il offrira la possibilité de gérer les utilisateurs ainsi que les pages marque mais également la création de jeux à thème.

Cette partie permet donc de récupérer des statistiques de notre réseau social et de gérer son contenu.

Voir le cas d’utilisation de la page administrateur à la page suivante



Cas d’utilisation de la page administrateur

B) Diagramme global de notre solution

L’architecture d’un site et plus généralement d’un projet informatique correspond à l’ensemble des choix techniques qui structurent le projet : modèle de conception (« design pattern », lié au « framework » choisi), choix et définition de la base de données, choix du langage de programmation et aussi mais surtout la structure générale du site (telle que nous la définissons, à savoir par exemple les interactions entre les différentes fonctionnalités / modules du site).



Ces éléments définissent le « squelette » général de ce que sera notre projet. Il est primordial de choisir correctement ces différentes composantes de notre site pour plusieurs raisons :

• Temps de développement du projet En effet si les choix en termes d’architecture ne sont pas judicieusement faits et ne sont pas adaptés, le temps de développement peut s’en voir fortement impacté.

• Capacité d’évolution du projet Notre site étant un réseau social, il est plus que n’importe quel autre site amené à évoluer, rapidement et régulièrement. Si l’architecture générale du site n’est pas pensée pour être assez flexible / évolutive, cela peut poser de sérieux problèmes sur la durée. Ces problèmes peuvent être l’augmentation de la durée des développements ou même une restructuration partielle ou complète du site.

• Performances Bien que nous n’ayons pour le moment pas l’ambition / la prétention d’être le nouveau Facebook, l’architecture générale du site se doit cependant d’être également synonyme de performances. Il ne s’agit pas ici d’orienter le langage de programmation vers du très bas niveau (C / C++ / ASM...etc.) car cela n’a en l’état actuel du projet aucun sens. Notre objectif est de produire un site fluide et agréable à utiliser (le choix du framework, de la base de données et la structure générale du site jouant un rôle primordial).

L’architecture de notre projet sera basée sur le modèle n-tiers avec 3 couches

distinctes : • La base de données • Le serveur web • Le client (web ou mobile)

La base de données est le cœur de notre projet. Cette partie contiendra toutes

les données essentielles à notre site web. Cette base de donnée est générée via l’ORM (Object-relational mapping) Doctrine. Cet ORM permet de convertir les entités Symfony en base de données orientée objet. Elle sera en liaison avec la partie Serveur web qui interagira avec ses données. Seule la partie Serveur web aura la possibilité de communiquer avec la base de données. Le serveur assure la transmission des vues et des données pour les navigateurs. Elle comprend des web services pour chaque fonctionnalité. La partie mobile est réalisée avec phoneGap, ce sont donc des applications web qui auront pour utilité d’afficher les éléments reçus par le serveur.

Voir le schéma de l’architecture globale à la page suivante



Schéma de l’architecture globale

C) Diagramme des entités

Notre projet est divisé en différentes couches qui seront décrites dans cette

partie afin de donner une vision globale du rendu final. Les classes de la couche base de données ne sont qu’une représentation des

différentes tables. Ces tables représentent l’architecture de notre base de données. Sur ce diagramme de classe nous observons la structure de notre base de

donnée.

Voir le diagramme de classe de la base de données à la page suivante



Diagramme de classe de la base de données

Sur ce diagramme on retrouve une table "users" dans laquelle on stocke les informations liées à l'utilisateur (nom, prénom, mail, albums, ...). Une table "likes" qui contient l'id de l'utilisateur qui a aimé (une publication/image/commentaire/album/...) ainsi qu'un "id_object" de l'objet concerné par cet élément et son type pour le différencier.

Une table "postes" qui représente les publications réalisées sur notre site dont dépendent deux autres tables, "poste_fashtag" pour les fashtags se trouvant dans la déscription et "poste_pictures" qui contient les images de la publication. La table "up" concerne les publications mises en avant. Le "fastheme" concerne les jeux du moment crée par un administrateur afin de faire interagir les utilisateurs sur un thème précis sur un temps imparti. Le "report" est la gestion des retours utilisateur sur notre site mais également les retours sur les commentaires ou images inappropriées.



3) Choix techniques

Symfony 2 Notre choix pour Symfony2 s'est fait grâce à plusieurs facteurs:

1. L'équipe de développement est composée d'une majorité de personnes ayant déjà pratiqué du PHP. Le seul challenge pour ces personnes fût d'appréhender le framework.

2. Nous voulions un framework qui gère la base de données à partir de sa propre ORM (Ici, Doctrine).

3. Le fait que Symfony2 soit MVC n'a fait que confirmer notre choix. Cette architecture basée sur la forte cohésion et le faible couplage nous permet de manier les changements plus facilement. Les vues sont effectuées dans des twigs, très puissant pour afficher des données dynamique et pour effectuer certaines actions faisant partie de la logique quand c’est nécessaire.

4. Le fait que Symfony2 soit facilement testable grâce à PHPUnit, nous pouvons faire une application de qualité, totalement automatisée. Les tests d'intégrations et unitaires étant un bien non négligeable sur la robustesse du produit, nous mettons tous nos efforts pour ne pas laisser de côté la partie qualité du projet.

jQuery

jQuery est très puissant et nous permet de rendre le site plus attractif en le rendant dynamique via les animations mais aussi grâce à l’envoie et la récupération de données. On évite de recharger les pages dans certains cas grâces aux appels Ajax.

Foundation CSS Ce framework nous permet de gagner beaucoup de temps dans la réalisation des styles pour nos pages. Le framework est très complet, et il génère automatiquement du code CSS qui est responsive.

Cordova (PhoneGap)

Nous voulions au début faire une application mobile native sous Apple, Windows Phone et Android (respectivement en ObjectiveC, C#, Java). Malheureusement, à cause de notre retard, nous avons dû mettre en place un plan de redressement pour notre projet. Nous avons donc choisis Cordova pour le



développement d'une application hybride. Cordova offre tous les fonctionnalités natives et permet le cross-plateforme.

Cordova nous permet donc de créer des applications mobiles natives seulement en développant avec du HTML/CSS/Javascript. C’est le compilateur de Cordova qui génèrera les applications sous iOS, Android et Windows Phone dans leurs languages respectifs. Nous utilisons aussi le framework Ionic qui est un framework HTML5/CSS3, il nous permet d’avoir déjà des éléments de base (boutons, modal, formulaires etc.) implémentés et qui s’adapte correctement sur les différentes plates-formes mobiles.

Github

Nous utilisons les bienfaits de git et du service d'hébergement GitHub pour notre projet. Nous fonctionnons par issues et pull requests. Les pull requests forcent les développeurs à voir le travail de toute l’équipe. Les collaborateurs sont libres de donner leurs critiques et commentaires. S’il n’y a aucune amélioration à apporter, nous procédons au merge. Si nous estimons que le code n'est pas robuste, clair ou que nous détectons du code mort, le développeur se doit de modifier son travail pour que sa pull request soit acceptée. Les issues peuvent être créées par n'importe quel développeur et être assignées à n'importe quel autre. Plusieurs labels sont présents pour faciliter la gestion de ces issues :

• Tâche du lab EIP: On répertorie les tickets liés à une interaction directe avec les serveurs du laboratoire, mais aussi pour les mises à jour du site vitrine disponible sur http://eip.epitech.eu/2015/moodress.

• Bugs: la partie résolution et amélioration des incidents rencontrés est disponible dans ce label. Le ticket est fermé seulement si une solution est rencontrée pour la correction du bug.

• Feature: Ici seront présentes les différentes branches nécessaire à la réalisation du projet, ainsi que le système de pull-request qui sera détaillé plus en profondeur plus loin dans le document.

• Questions: Les différentes questions que possèdent les membres du groupe en lien avec le projet, ou avec le Lab EIP lors des suivis.

• Mises à jour: Les différentes parties implémentées ne sont pas toujours pleinement fonctionnelle ou alors certaines parties peuvent être plus générique. C’est donc ici que se retrouveront toutes les mises à jour du projet.

• Design: L’ergonomie et l’interface de notre site en matière de design sera directement géré via ce label.

• Mobile: La partie pour les différentes applications mobile et la partie design pour adapter aux écrans des smartphones, tablettes, seront disponibles dans cette catégorie.

• Tests: Si des bundles ou des librairies doivent être testées pour une éventuelle implémentation dans le projet, ils seront répertoriés ici.



4) Modules A) API

Dans cette partie, nous vous exposons les différents modules de l’API ainsi que les différentes actions disponibles pour chacun des modules. Pour connaître les détails de chaque méthode, vous pouvez consulter la documentation complète disponible sur ce lien. Vous pourrez connaître la méthode HTTP utilisée, les paramètres requis et optionnels, un exemple d’appel ainsi que la réponse renvoyée. Les utilisateurs Plusieurs actions sont possibles pour gérer les utilisateurs depuis l’API.

• Création de compte : Les clients peuvent créer un nouveau compte. Il suffit de transmettre en paramètre les champs obligatoires comme le pseudo, l’adresse email, le password etc.

• Vérification de la disponibilité du pseudo : Cette méthode permet d’informer l’utilisateur si le pseudo qu’il rentre dans le champs est déjà utilisé.

• La connexion : Pour se connecter, on a juste besoin de transmettre en paramètre un pseudo et un mot de passe.

• Modification de compte : Il est possible de changer certains paramètres du compte. Cela peut-être des données du profil (édition du pseudo, le pays, ou le username), ou bien encore des paramètres de confidentialité (Mettre son compte en privée).

• Modification de mot de passe : Une méthode a été spécialement créer pour l’édition du mot de passe. Il suffit de transmettre en paramètre l’ancien mot de passe, le nouveau, ainsi que sa vérification.

• Déconnexion : Cette méthode permet de se déconnecter. Elle ne nécessite aucun paramètre.

• Suppression de compte : Tout comme la déconnexion, cette méthode nécessite aucun paramètres, il faut juste que la partie client s’assure de demander une confirmation à l’utilisateur.

Les pages marques

• Effectuer une demande pour devenir une page marque : Cette action ne

requiert aucun paramètre. Cela va juste créer une demande qui devra être validée dans la partie administration du site.

• Effectuer la transformation en page marque : Cette méthode sera accessible uniquement pour les utilisateurs ayant le rôle d’administrateur. Si la requête est acceptée, on appelle cette méthode en transmettant uniquement un identifiant utilisateur.

• Retrait du statut “Page Marque” : Côté administration, il doit être possible de retirer ce statut de page marque. Comme la méthode précédente, il suffit de transmettre un identifiant utilisateur.



• Récupération des pages marques : Nous avons créer cette méthode pour que l’administration puisse voir les derniers pages marques créer sur le site. Cela permet une meilleure gestion de ces profils.

• Refus d’une demande pour devenir une page marque : Cette méthode permet à un administrateur de refuser si la demande de l’utilisateur ne convient pas. Un identifiant utilisateur est requis.

Les publications

• Création d’une publication : Pour pouvoir créer une publication, il suffit de transmettre une description et des photos en paramètres. Il est également possible de transmettre le titre d’un album, cela va engendrer la création automatique d’un album. Si on veut que la publication soit placée dans un album déjà existant, et autre que l’album “Upload”, il suffit de mettre un identifiant album en paramètre.

• Suppression d’une publication : Pour supprimer une publication, il suffit de donner en paramètre l’identifiant de la publication.

• Récupération des publications : On peut récupérer les dernières publications du site. Pour pouvoir les récupérer par paquet, on peut rajouter les paramètres “limit” et “offset”. Différentes méthodes de récupération sont disponibles. Comme la récupération des publications en fonction d’un identifiant utilisateur, ou celles des utilisateurs qu’on suit dans la communauté.

Les albums

• Création d’un album : Pour créer un nouvel album, il suffit de donner en paramètre un titre, et au moins une photo.

• Suppression d’album : Pour supprimer un album, il faut juste transmettre l’identifiant de l’album en paramètre.

• Rajout de photo(s) à l’album : Pour rajouter des photos, il suffit de donner en paramètre l’identifiant de l’album concerné, ainsi que les photos.

• Suppression de photo(s) : Pour la suppression de photo(s), il faut juste donner l’identifiant de l’album à la méthode, et transmettre un tableau comportant les identifiants des photos qu’on veut supprimer.

• Récupération des albums : On récupère les albums en précisant l’identifiant de l’utilisateur en paramètre.

Aimer

• Aimer un objet : Pour que l’utilisateur puisse aimer une photo, commentaire, publication ou album. Il est nécessaire de fournir l’identifiant de l’objet que l’utilisateur souhaite aimer et son type (photo, publication, album, commentaire)

• Ne plus aimer : Cette méthode permet de ne plus aimer un objet précédemment aimé par l’utilisateur que ce soit une photo, un album, une publication ou un commentaire. Requiert l’identifiant de l’objet et son type.



• Vérifier qu’un objet est déjà aimer : Renvoie un booléen pour savoir si cet objet est déjà aimé par l’utilisateur. L’identifiant de l’objet et son type.

Les commentaires

• Créer un commentaire : Pour créer un commentaire, il faut juste transmettre le commentaire avec un identifiant d’objet, ainsi qu’un type d’objet. Il faut préciser le type car on peut commenter un album, une publication, ou encore une photo.

• Supprimer un commentaire : Il suffit de donner en paramètre l’identifiant du commentaire.

• Edition d’un commentaire : Il faut communiquer l’identifiant du commentaire, et le nouveau commentaire en paramètre.

• Récupération des commentaires : On communique l’identifiant, et le type de l’objet pour récupérer le tableau des commentaires. Tout comme la récupération des publications, pour pouvoir les récupérer par paquet, on peut rajouter les paramètres “limit” et “offset”.

Suivi entre utilisateurs

• Suivre un utilisateur/une page marque : Pour suivre un utilisateur, il suffit de transmettre en paramètre le pseudo de le la personne/page marque que l’on veut suivre.

• Répondre à une requête de suivi : Dans le cas où un utilisateur a un compté privée, il va recevoir une requête pour les demandes de suivi. Il recevra la demande directement dans ces notifications, et grâce à l’API il pourra répondre à cette requête en donnant en paramètre l’identifiant de l’objet “FOLLOW”, ainsi que sa réponse booléenne.

• Annuler la demande de suivi : Pour annuler la demande, il suffit de donner en paramètre le pseudo de l’utilisateur à qui on a envoyer le requête.

• Ne plus suivre : Pour ne plus suivre l’utilsateur, comme pour la méthode qui permet de suivre, on donne juste le pseudo de l’utilisateur en paramètre.

• Récupérer les suiveurs : Pour récupérer le tableau des suiveurs, on a juste besoin de communiquer l’identifiant de l’utilisateur concerné, et pour récupérer les suiveurs par paquets, on peut rajouter les paramètres “limit” et “offset”.

• Récupérer les utilisateurs que l’on suit : Tout comme la méthode pour récupérer les suiveurs, on transmet l’identifiant de l’utilisateur, et on transmet les paramètres “limit” et “offset” pour les récupérer par paquets.

Les notifications

• Récupération des notifications : On précise l’identifiant du réceptionneur des notifications, et pour les récupérer par paquet, on peut préciser la “limit” et l’”offset”.

• Changer le statu d’une notifications : Il est important d’informer le serveur lorsque la notification a été vue. Nos notifications sont divisées en trois



catégories : Les commentaires / tags, les Suivis, et les “J’aime”. Pour informer le serveur qu’on a vu les notifications d’une de ces catégories, il suffit de préciser le paramètre “type”.

La recherche

• La recherche : Cette méthode permet de rechercher un utilisateur, une page marque ou un “fashtag”. Pour pouvoir utiliser cette fonction, il faut transmettre les mots clés que l’on souhaite rechercher et un filtre correspondant aux types voulant être recherché par l’utilisateur.

Les “Fashthèmes”

• Création d’un “fashthème” : Cette méthode permet la création d’un “fashthème” par un administrateur. Le fashthème étant le jeu hebdomadaire du site autour d’un fashtag. Les paramètres requis sont le “fashtag” utilisé, une description, la date du début, la date de la fin et la photo lié au fashthème.

• Modification d’un “fashthème” : On peut modifier un fashthème grâce à cette fonction. Il suffit d’envoyer le paramètre que l’on souhaite modifier (description, fashtag, photo, date du début ou date de fin)

Compte premium

• Passage à un compte premium : Pour pouvoir passer un compte utilisateur en mode premium qui permet à l’utilisateur de mettre en avant des publications sur la page d’accueil du site.

• Ajout d’une publication à la liste de mise en avant : Permet à une publication d’utilisateur d’intégrer la liste des postes qui seront mis en avant sur la page d’accueil du site. L’identifiant de la publication de l’utilisateur est requis.

Les statistiques

• Statistiques des genres des utilisateurs : Permet de connaître les pourcentages d’hommes et de femmes utilisateurs sur le site.

• Fashtags les plus populaires : Permet de récupérer une liste avec les fashtags les plus populaires du site. Un paramètre optionnel pour limiter le nombre de fashtags est disponible.

• Utilisateurs les plus suivis : Méthode pour connaître les utilisateurs les plus populaires du site en fonction de nombres de personnes les suivant. Le nombre d’utilisateurs en réponse peut être limité grâce à un paramètre optionnel.

• Publications les plus populaires : Pour pouvoir récupérer une liste contenant les publications les plus aimées du site. Un paramètre optionnel pour limiter le nombre de publications dans la liste est disponible.

• Publications les plus commentés : Permet d’obtenir une liste des publications les plus commentées. Un paramètre optionnel pour limiter le nombre de publications dans la liste est disponible.



Signaler des bugs

• Signaler un bug : Cette méthode permet de créer un signalement de bug par l’utilisateur, pour pouvoir être par la suite réparer par les développeurs. Les paramètres requis sont la plateforme concernée, la fonctionnalité concernée, le message de l’utilisateur et les captures d’écrans.

• Répondre à un signalement : Permet à l’administrateur de répondre à un signalement créé par un utilisateur. Les paramètres requis sont l’identifiant du signalement, le message de l’administrateur et le status en cours (résolu, en attente, suspendu ou invalide)

• Récupérer les signalements : L’administrateur a accès à cette méthode pour récupérer tous les signalements créés par les utilisateurs ou seulement les signalements de bugs.

B) Serveur

L’application web suit l’organisation par défaut d’un projet basique Symfony 2. Cette configuration nous permet d’organiser notre serveur en plusieurs “bundles” liés à une partie spécifique. Chaque bundle contient une ou plusieurs entités, des controleurs, et toutes les ressources correspondantes telles que les vues, les fichiers de styles, javascript etc. Voici une liste de nos différents ‘bundles’:

• AdminBundle: Ce bundle nous permet d’avoir un contrôle administrateur de notre site pour avoir un aperçu des différentes activités récentes (derniers ‘posts’ créés, derniers utilisateurs), une partie statistique (‘posts’ les plus populaires, utilisateurs les plus populaires, etc), créer des fashthèmes.

• AlbumBundle: Ce bundle permet de faire toute la gestion des albums pour les utilisateurs, mais également de la simple consultation. Il définit également l’entité Album et Picture.

• ApiBundle: L’APIBundle hérite du bundle développé par la communauté FriendsOfSymfony FOSRestBundle. Ca nous permet de gérer plus facilement sa gestion. C’est dans ce bundle que nous mettons toutes les méthodes de l’API. Nous avons crée un controller pour chaque fonctionnalité.

• CommentBundle: Ce bundle permet la gestion des commentaires pour l’utilisateur et il définit aussi l’entité Comment lié aux commentaires.

• FashtagBundle: Ce bundle définit l’entité ‘Fashtag’ et contient les contrôle lié aux Fashtags (création d’un fashtag, mais aussi les vues permettant de regrouper tous les postes contenant un même fashtag.

• FashthemeBundle: Ce bundle définit l’entité ‘Fashtheme’ qui est utilisé par l’administrateur par la suite, et les vues liées.

• HomeBundle: Ce bundle est utilisé pour contenir toutes les fonctionnalités que l’on retrouve sur la page d’accueil. Le contrôleur de la page d’accueil est contenu dans ce bundle ainsi que la vue auquel il est lié.



• LikeBundle: Il s’agit du bundle qui permet la gestion des ‘Like’ sur notre site. Il contient aussi les fichiers Javascript utilisé pour avoir un ‘Like’ dynamique. Ainsi que la définition de l’entité que l’on retrouve dans notre base de données.

• NotificationBundle: La gestion des notifications est effectuée dans ce bundle ainsi que la définition de l’entité des notifications.

• PosteBundle: Ce bundle contient l’entité définissant le ‘Poste’. Le contrôleur s’occupant de la gestion des postes ainsi que les vues liés au poste.

• ProfileBundle: Ce bundle s’occupe exclusivement de la partie profil de l’utilisateur et la gestion de ses paramètres. Il contient les différentes vues et contrôleurs.

• ReportBundle: Ce bundle permet à l’utilisateur de signaler des bugs ou du contenu interdit dans les ‘postes’ (photo, commentaire, description) et à l’administrateur de répondre à l’utilisateur pour l’informer de la progression sur le problème rencontré et son statut en cours. Toutes les entités, vues et contrôleurs liés sont contenus dans ce bundle.

• StaticPageBundle: Ce bundle est utilisé pour regrouper toutes les pages statiques qui ne comportent pas de fonctionnalités mais seulement des textes informatifs.

• UpBundle: Ce bundle regroupe toutes les entités, contrôleurs et vues liées à notre système de compte premium et les fonctionnalités liées à la mise en avant.

• UserBundle: Ce bundle hérite à la base du bundle de FriendsOfSymfony, FOSUserBundle, ce qui nous permet d’avoir une base pour l’entité d’un user ainsi que quelques vues et contrôleurs de base pour les actions basiques (connexion, inscription, page profil, etc). Nous sommes parties de cette base pour ensuite surcharger ce bundle. Tout ce qui concerne le ‘user’ est repertorié ici ainsi que l’entité et contrôle pour les ‘follow’.

Nous utilisons également des bundles déjà existant. Certains ‘bundles’ sont déjà installés par défaut dans l’application web et sont stockés dans les ‘vendors’. Nous sommes libres d’en rajouter, ou bien d’en retirer. Pour gérer ces “vendors”, il suffit d’utiliser le ficher de configuration composer.json. Voici quelques exemples de “vendors” que nous utilisons :

nelmio/api-‐doc-‐bundle : Gestion de la documentation de l’API. friendsofsymfony/user-‐bundle : Gestion de toute la partie utilisateur (connexion, création de compte, déconnexion etc.) friendsofsymfony/rest-‐bundle : Gestion de l’API. Création des routes de type REST. Le choix de la méthode (POST, GET, DELETE et autres), ce fait à travèrs les annotations de ce “bundle”. friendsofsymfony/facebook-‐bundle : Gestion de l’authentification par Facebook. ob/highcharts-‐bundle : Générateur de graphiques pour la partie statistique.



C) Mobile a) Hiérarchisation

Le projet PhoneGap contient un ensemble de dossiers permettant de pouvoir le compiler sous les différents systèmes d’exploitation mobiles. Nous retrouvons trois principaux répertoires qui seront utiles lors du développement de notre application.

Screenshot des principaux dossiers du projet PhoneGap

• Le répertoire ‘Plugin’ qui permet d’ajouter de nouvelles fonctionnalités à notre

application, soit pour pouvoir ajouter un écran d’accueil ou une API qui permettra de naviguer dans le système de fichier de l’appareil mobile.

• Le répertoire ‘platforms‘ dans lequel seront stockées les différentes version de l’application pour chaque système d’exploitation. En effet à l’aide d’une commande permettant l’ajout d’une nouvelle plate-forme, le code compilé de cette nouvelle plate-forme sera ajouté dans un nouveau dossier.

• Le répertoire www qui contiendra un dossier pour chaque langage de programmation que l’on utilise pour l’application (HTML, CSS et JS). L'utilisateur voulant crée son application via Phonegap ira la crée à l’intérieur de ce dossier en élaborant sa propre arborescence. (Voir photo ci-dessous pour un exemple).

Voir screenshot de l’arborescence sur la page suivante



Screenshot de l’arborescence

b) Déploiement

Grâce à Ionic, nous pouvons appeler un binaire qui compilera le projet pour la plateforme que l’on veut tester. Cela peut être pour iOS (Apple), Android ou Windows Phone. Le binaire va nous transformer le code réalisé en HTML, CSS, Javascript dans le langage voulu, c’est à dire Objective-c pour iOS, Java pour Android et C# pour Windows Phone. Un exécutable sera alors créé pour chaque plateforme, il ne restera plus qu’à tester l’application sur les différents émulateurs pour en vérifier son bon comportement.



c) Test de l’application Chaque plateforme à son émulateur attitré :

iOS pour tester l’application, il suffit d’ouvrir le fichier avec l'extension “xcodeproj” avec le logiciel Xcode. A partir de Xcode nous pouvons choisir

sur quel type de téléphone nous pouvons tester l’application, donc cela peut être sur l’iphone 4 ou 5 et autres. Nous avons aussi la possibilité de tester l’application sur notre propre iPhone pour cela il suffit de le brancher au Mac et Xcode le reconnaitra automatiquement.

Eclipse, qui est le logiciel pour l’environnement de developpement des applications Android dispose aussi d’un émulateur inclu. Mais celui-ci jugé trop lent, nous avons décidé d’utiliser Genymotion qui est aussi un émulateur pour

Android mais beaucoup plus rapide, de plus il est souvent mise à jour et nous pouvons tester l’application sous les différents téléphones qui supportent Android (c’est à dire de la gamme de téléphone de Samsung jusqu’au Nexus de Google). Il suffit de transférer le fichier avec l'extension “apk” dans l’émulateur afin de pouvoir tester l’application.

Windows Phone : Visual Studio propose aussi son propre emulateur, celui ci se comporte un peu comme pour iOS, il suffit d’ouvrir le fichier avec l’extension “sln” puis il suffit de cliquer sur le bouton “Play” afin de tester l’application

dans le controller.

d) Débuggage

Il est plutôt difficile de pouvoir effectuer du debug avec Phonegap, en effet les émulateurs n’ont pas de console pour nous permettre de repérer les erreurs CSS ou Javascript qui peuvent survenir. Pour cela nous plaçons des messages dans le code pour qu’ils apparaissent lors de l’exécution de l’application afin de voir quel chemin le code empreinte. Grâce à ces messages nous pouvons aussi afficher ce que contiennent nos variables et donc bien vérifier le contenu de nos variables.

D) Base de données a) User

Ce module représente toutes les informations liées à un utilisateur de

Moodress.

Ces informations servent à identifier l’utilisateur (pseudonyme, photo de profil, ville…etc.) mais également à l’authentifier sur Moodress (la table utilisateur contenant le login et le mot de passe).

Voir la classe de ce module sur la page suivante



Classe User

b) Post/Album/Commentaires

Ce module représente presque tout le contenu que contient le réseau social

Moodress. Il se divise en 3 grandes parties :

• Les postes permettent de partager n’importe quel contenu qui est lié à la mode (photo, demande d’avis, d’idée, etc.).

• Les albums qui sont utiles à l’organisation des anciennes photos postées. Les commentaires qui apportent toute l’interaction entre les utilisateurs de Moodress.

Classes Post, Comment, et Album



c) Like

Le module like permet à tout utilisateur de donner son avis sur le contenu partagé pas ces connaissances. Il permet également de voir une liste de tous les contenus qu’il a aimé et ainsi de retrouver facilement un style qu’il a aimé par exemple.

Classe Like

d) Notification

Le module de notifications permet simplement d’alerter l’utilisateur

(simplement visuellement sur le site / l’application, ou par email) de nouvelles interactions sur son réseau (nouveau follower, nouveau commentaire, nouveau poste, etc).

e) Tags / Fashtags

Le module de « fashtags » permet la catégorisation de ressources sur le site : post, photos, albums. Le but est de créer des réseaux / communautés entre les utilisateurs ayant les mêmes centres d’intérêts.

Classe Fashtag

f) Follower / Following

Le module de follower / following permet, à la manière de Twitter, de suivre

des utilisateurs du réseau (à l’aide des notifications entre autres) ou à l’inverse d’être suivi par des personnes intéressées par votre profil et vos publications.

Classe Follower



g) Fashthème Le module fashthème permet d’avoir en base de données les jeux que pourront

mettre en place les ‘community managers’ du site. Il contient les dates de début et de fin du jeu, une description pour expliquer le thème aux utilisateurs, le fashtag qui est utilisé pour participer.

h) Report

Ce module nous permet de représenter les signalements effectués par les utilisateurs à propos de bugs rencontrés ou de contenu interdit dans notre base de données. Il contient l’identifiant de l’utilisateur qui est le créateur, l’identifiant de l’administrateur en charge du signalement, un message décrivant le problème, une date de création, le statut en cours du signalement et enfin la réponse de l’administrateur.

i) Up / Premium

Cette table permet de repertorier tous les postes qui sont mis en avant par les utilisateurs premium. Elle contient l’identifiant du poste à mettre en avant ainsi que la date de mise en avant.

5) Fixation de bug

Github possède un puissant outil pour nous permettre de tracker les bugs dans notre projet. Nous avons décidé d’utiliser son système d’issues car les issues sont très simples à créer. Il suffit d’un titre et de sa description. Il est alors très facile et attractif de créer des issues pour les bugs qui doivent être fixés.

La première chose importante dans les issues sont les “labels”, étant donné que nous utilisons aussi les issues comme une “Todo list”, nous avons besoin de lister les bugs facilement, c’est donc là qu’interviennent les “labels”. En conclusion, nous avons un label “bug” qui nous permet de trier les issues par bug.

Example de la liste de bugs sur Github avec les labels “bug”



Nous utilisons la structure suivante pour écrire nos issues :

• un titre simple et clair afin de pouvoir s’y retrouver facilement dans la liste des bugs

• le contexte : on explique pourquoi nous ouvrons une nouvelles issue pour résoudre un bug.

• le problème / idée : explication d’où pourrait provenir le problème et ainsi donner une direction de comment il pourrait se résoudre.

• solution : c’est ici que les choses avancent, car nous pouvons assigner les issues à des collaborateurs et ainsi ils peuvent discuter du problème puis proposer leurs solutions dans les commentaires.

Une fois le bug résolu, la personne en charge peut faire son “commit” pour

“patcher” le code et attribuer ce commit au numéro de l’issue. Cela permet de montrer aux autres collaborateurs comment la personne a pu résoudre ce problème en montrant les lignes de codes qui ont été modifiées. Ainsi les collaborateurs peuvent apporter des commentaires si il y en a besoin. Une fois cela terminé, l’issue peut être ‘close’ sur Github et peut être aussi ‘re-open’ à l’avenir si le même bug réapparaît.

Liste de bugs

• Lorsqu’on lance le serveur Moodress, le premier bug qui est souvent rencontré est celui-ci :

RuntimeException: Failed to write cache file "/var/www/myapp/app/cache/dev/classes.php".

Pour corriger ce bug il faut exécuter les lignes suivantes dans son shell :

$ chmod 777 app/cache $ chmod 777 app/logs $ rm -‐rf app/cache/* $ rm -‐rf app/logs/*

Puis à la racine Symfony de son fichier:

$ php app/console cache:clear

• L’utilisation du langage est parfois à l’origine de certains bugs, comme par

exemple faire des comparaisons entre des variables, il est mieux d’utiliser ‘===’ que ‘==’ pour que l’opération soit faite que si les deux variables sont strictement identiques.



• Erreur pour la création d’un utilisateur et l’insertion dans la base de donnée:

SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'nb_postes' cannot be null " Pour corriger ce type d’erreur SQL il faut mettre à jour le constructeur de la

classe concernée. Setter la valeur de la variable qui ne peut pas être null (voir ci-dessous l’exemple):

/** * Constructor */ public function __construct() { parent::__construct(); $this-‐>nbPostes = 0; }

Documents

2015 TD3 FR Moodress - Epitech · 2014. 10. 12. · Documentation technique!!!!! !! 2015_TD3_FR_Moodress.pdf ! ! ! Résumé : Ce document décrit l’intégralité de l’architecture