Journal de PPE4

Journal de PPE4 : Projet application mobile pour l’Atelier

Voici mon journal de PPE pour mon dernier semestre de formation au BTS SIO, le sujet de ce projet portera sur le développement d’une application mobile implémentant des fonctionnalités de l’application web que j’ai développé au cours de mon deuxième stage pour l’atelier du lycée Merleau-Ponty.

Contexte

L’atelier du lycée Merleau-Ponty réalise les travaux de maintenance du lycée. Une application web (PHP, MySQL, JavaScript) de gestion des travaux, ou « ticket », a été réalisée par une stagiaire de licence professionnelle en 2012, puis améliorée un stagiaire de BTS SIO en 2015. Cette application permet de gérer les tickets liés aux travaux du lycée, fonctionne comme un helpdesk classique que l’on peut trouver dans GLPI, par exemple. Elle a été réalisée selon les besoins de l’atelier et d’après le temps et les moyens fournis aux stagiaires. Voici la liste de ses fonctionnalités, dans les grandes lignes :

  • Gestion des tickets
  • Gestion des utilisateurs
  • Administration des données
    • Gestion des lieux
    • Gestion des catégories

Dans l’application est développée une solution pour imprimer des tickets sur une fiche, pour que l’agent puisse savoir quoi faire une fois sur place, une fois le travail effectué l’agent doit retourner sur l’application web pour signaler le travail comme résolu.

Enjeux et finalité

En 2015, il est raisonnable de penser que l’agent puisse embarquer avec lui la liste totale des tickets à effectuer sans l’imprimer et les signaler comme résolus sur place une fois que le travail effectué, tout simplement avec un appareil mobile (smartphone, tablette, …). Besoins Il faut créer une application permettant d’implémenter certaines fonctionnalités de la gestion des tickets via un appareil mobile :

  • Afficher les tickets contenus dans la base de données
  • Les trier par état
    • Pouvoir appliquer un sous-tri personnalisé par l’utilisateur
  • Résoudre un ticket (modifier son statut)
  • Mettre un ticket en attente (modifier son statut)

Lien vers le cahier des charges du projet :


 ► Jeudi 26 mars 2015

Pour commencer je dois déterminer les différentes technologies à disposition pour récupérer des données d’un serveur MySQL via un client Android. Ainsi je pourrais faire un choix sur la meilleure technologie à mettre en place. Voilà une semaine que j’effectue mes recherches sur le sujet, et il semble qu’il n’y ai pas différente façon de procédé : Il faut utiliser le service web du serveur

Le problème c’est que Android ne gère pas nativement le dialogue avec MySQL, il ne possède pas d’objet permettant cela comme PHP possède PDO par exemple. En revanche Android peut envoyer des requêtes HTTP, l’idée est d’utiliser des scripts PHP situer sur le serveur pour interagir avec la base de donneés MySQL, et renvoyer les données au terminal Android sous forme de fichier JSON, XML, etc. Ainsi on accède aux données présentes dans MySQL. J’ai rapidement fait un schéma qui résume l’idée, je pense que c’est compréhensible :

schema_omg

Pour traiter ces données, la bonne pratique semble qu’il faille répliquer la base de données MySQL dans une base SQLite du client Android. Ainsi, on récupère les données de MySQL, on remplit la base SQLite avec celles-ci et on peut facilement les manipuler.

Cela semble lourd à mettre en place mais je pense que c’est la meilleure façon de faire.

J’ai commencer à créer des IHM de la future application mobile, elles sont très riches en fonctionnalités mais seulement une fraction de celles-ci seront développée sur l’application en raison du peu de temps qui m’est impartis. C’est simplement dans le but d’avoir une vue de ce que pourrait donner l’application dans son potentiel maximal.

menu voir_ticket vue_ticket

J’ai préparé un diaporama présentant le résultat de mes recherches et de mes travaux sur les IHM comme demandé dans le cahier des charges, je finaliserais et validerais tout cela  pour la semaine prochaine.


 ► Jeudi 2 avril 2015

J’ai finalisé dans la semaine mon diaporama pour me préparer à la présentation orale. Je pense que je peux directement me lancer dans le développement de l’application pour ne pas perdre de temps. Je vais commencer par développer mes classes métiers et mettre en place la communication entre le serveur AMP et le client Android et ensuite implémentez la base de données SQLite.

Lien vers le diaporama au format PDF :

J’ai également (et rapidement) commencer un diagramme des classes métiers afin de déterminer ce que je devrais utiliser. J’ignore si il me servira puisque j’ai déjà le sujet très bien en tête. Néanmoins ce diagramme sera toujours utile pour rédiger une documentation, par exemple.

atelier Class diagram

J’ai donc d’abord créé ma base de données SQLite sur le client Android, et écris rapidement les classes métiers tickets et utilisateurs. Pour le moment j’ai du mal à déterminer quelle classe je devrais implémenter car c’est la première fois que je découpe mon programme de façon si rigoureuse.

Sur mon projet android, j’ai créé 3 packages :

  • bdd : contient les classes en relation avec la manipulation de la base de données SQLite (création des tables, requêtes, …)
  • http : contient les classes permettant d’effectuer des requêtes HTTP vers le serveur AMP.
  • metier : contient les classes métiers, propre à l’application en elle-même.

Pour le moment je ne conçois aucune interface graphique, j’essaye de tout faire fonctionner sans visuel, avec seulement la console, je pense qu’il faut d’abord se concentrer sur le fonctionnement interne de l’application plutôt que de foncer sur les interfaces graphiques.

coolstring

Ici on voit bien que l’objet récupère correctement ses attributs via la base de données et les affiches dans la console en appelant la méthode toString().

Pour le moment j’ai seulement créé ma base de données SQLite et fait un bref dialogue avec elle : j’affiche son contenu avec des requêtes SQL « SELECT » dans la console. Pour la semaine prochaine je pense écrire mes scripts PHP pour envoyer les données nécessaire au terminal Android.


 ► Jeudi 9 avril 2015

J’ai terminer ma base de données SQLite, désormais à la compilation toute la base est créé depuis des scripts placé depuis le terminal et créé la base. J’ai besoin maintenant de recréer exactement tout les objets en parallèle des entités de la base, ainsi je pourrais manipuler les données via des objets dans mon code java, puis les réinsérer dans ma base.

La prochaine étape est de télécharger les données depuis la base de données MySQL pour les insérer de la même manière dans la base MySQL.

J’ai créer dans la semaine tout mes objets, ça a été laborieux aux début pour traduire les clefs étrangère en attributs de classe, je suis passé par des attributs de type objet (objets métiers donc).

J’ai brièvement commencé à développer mes script PHP pour l’application, seulement je ne peux pas avancer j’ai un problème avec mon serveur de développement WampServer, il ne fonctionne plus …

J’ai entre-temps installé Microsoft SQL Server pour les TP de SLAM3, je pense que c’est l’origine du problème, il doit y avoir un conflit avec WampServer … Seulement, même en éteignant tout les services Windows liés à SQL Server, WampServer ne fonctionne toujours pas …


  ► Jeudi 16 avril 2015

J’ai finalement réussi à refaire fonctionner mon WampServer, en désinstallant SQL Server et en réinstallant complètement WampServer … Maintenant j’ai un autre problème à régler, j’ai fais une mise à jour de l’IDE que j’utilise pour développer, Android Studio, qui l’a complètement cassé … J’ai des tonnes d’erreurs incompréhensibles liées à l’environnement Android qui sont apparu et plus rien ne fonctionne … Je pense que je vais réinstaller Android Studio …

Une fois Android Studio de réinstallé, mes projets réimportés, etc. J’ai eu un autre problème, moins gênant, Android Studio ne semble pas « mettre à jour » mon code … En clair, dès que j’effectue une modification de mon code, je dois relancer Android Studio pour que celui-ci compile avec les modifications que j’ai apportés … Ce que est très particulièrement chronophage en particulier quand on ne maîtrise pas l’environnement et que l’on a besoin de vérifier que tout fonctionne pour avancer.

J’ai écris quelque méthodes pour obtenir des données de la base via des objets, je ne pense pas que j’aurai besoin de plus de méthodes, puisqu’en terme de traitement je dois juste modifier le statut d’un ticket.

Concernant le choix entre JSON et XML, je pense clairement que JSON sera plus simple à utiliser, j’ai vus quelque exemple sur internet, il est vraiment très simple à utilisé ce qui est un très gros avantage par rapport à XML qui lui, bien que plus puissant et plus typé, la mise en place d’un parser XML en Java n’est vraiment pas la plu simple des choses … Par conséquent je me lance en JSON.

JSON : JavaScript Object Notation

Je me suis pencher sur mon api PHP, j’ai fais des recherches pour installer JSON sur le serveur, en réalité depuis PHP 5.2.0, l’extension JSON est fournie et compilée dans PHP par défaut. donc pas de problème de ce côté là car pour installer l’application web nous avons mis à jour PHP vers sa version 5.6.

api_php

J’ai créer un dossier nommé « android_app_api » dans lequel j’ai créer 4 fichiers PHP. Le fichier « index.php » recevra les requêtes HTTP avec un paramètre passé dans les super-globales POST ou GET qui lui permettront d’appeler les différentes fonctions à exécuter et renverra les résultats en JSON.

<?php
 
/** 
 * Si POST Soumis
 */
if ($_SERVER["REQUEST_METHOD"] == "POST" && $_POST['mclef'] != '') {

    $mclef = $_POST['mclef']; // mclef = mot clef
    
    /**
     * Demande de connexion
     */
    if ($mclef == 'login') {

        # code ...

    } else if ($mclef == 'gettickets') {

        # code ...

} else {

    $response["err"] = TRUE;
    $response["err_msg"] = "Erreur ! Aucun paramètre détecté !";

    echo json_encode($response);

}

?>
index.php

Les différentes fonctions sont dans le fichiers « DB_Functions.php », elles dialogueront avec la base de données et renverront les résultats au fichier « index.php ».

Les deux fichiers « Config.php » et « DB_Connect.php » ne servent qu’à effectuer la connexion à la base de données MySQL, le premier fichiers définit les constantes qui servent à se connecter à la base et le deuxième sert à instancier l’objet PDO.

<?php 

/**
 * Fichier contenant les constantes servant à configurer la connexion à la base MySQL
 *
 * @constant BDD Nom de la base de données
 * @constant USR Nom de l'utilisateur
 * @constant MDP Mot de passe
 * @constant HOTE Adresse du serveur
 */

define(BDD, 'atelier_v2');
define(USR, 'root');
define(MDP, '');
define(HOTE, 'localhost');

?>
Config.php

Le fait de regrouper toute les constantes qui sont supposé être changé uniquement à la mise en production permet de la rendre plus aisé et efficace, en effet peut importe la personne qui effectuera la mise en place celle-ci aura uniquement à modifié le fichier « Config.php » sans avoir à chercher dans le code les lignes à modifié.


 

  ► Jeudi 30 avril 2015

Tous mes outils de travail sont enfin opérationnel !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *