GUI Client in HomeSIP Project

Documentation de GUI Client in HomeSIP Project 2007 2008 Système Embarqué Guillaume GARDET Benjamin PUSSACQ Hervé SPITZ Damien LOZACH

Avant propos...3 Chapitre 1 Environnement de développement...4 1.1. Avant-propos...4 1.2. Processus de compilation d une application...4 1.3. Installation de l environnement Scratchbox...4 1.4. Installation d un SDK...7 1.5. Compilation d une application...11 Chapitre 2 Mise en place d une pile SIP...12 2.1. Avant propos...12 2.2. Installation d osip2 et d exosip2...12 2.3. Compilation d une application utilisant «osip2»...13 Chapitre 3 Mise en place de la bibliothèque QT...14 3.1. Avant-propos...14 3.2. Installation de QT...14 3.3. Compilation d une application QT...15 Chapitre 4 Objets de base...17 4.1. Avant propos...17 4.2. Objets de communication...17 4.3. Objets de gestion des capteurs...18 Chapitre 5 Les outils XML...21 5.1. La sauvegarde et le chargement d'informations...21 5.2. La communication SIP...25 5.3. Explication / Documentation de l'implémentation :...27 5.3.1. Utilisation de DOM, dans notre cas...27 5.3.2. Création d'un document XML :...28 5.3.3. Lecture d'un document XML :...29 5.4. Explication particulière :...30 Chapitre 6 Conception de l interface graphique...31 6.1. Principe de Qt...31 6.2. Conception...31 6.3. Présentation de l interface graphique...32 Chapitre 7 Comprendre et/ou communiquer...35 Guillaume GARDET Benjamin PUSSACQ Hervé SPITZ Damien LOZACH 2

Avant propos Ceci n'est pas un rapport de projet, mais une documentation de projet, elle met en avant les idées et les structures qui ont fait aboutir à une implémentation finale. Cette implémentation n'est pas décrite car trop complexe et harassante d'un point de vue code. A ce document est joint un support de présentation orale, dans la langue de Shakespeare, ainsi qu'un package contenant les fichiers sources et les explications pour les utiliser, comprendre et compiler. Certaines des explications sont dans la langue de Molière, l'autre, dans la langue de Shakespeare. Ce document ne présentera donc pas de cahier des charges ni de comparatif entre la solution finale et un possible cahier des charges. Mais il met l'accent sur les choix d'implémentation pour une optimisation et surtout une évolutivité et ré-utilisabilité. Car ce projet s'inscrit dans le cadre d'un projet bien plus grand et à plus long terme : le projet HomeSIP. Le projet HomeSIP et la communication SIP (Session Initiation Protocol) sont présentés dans d'autres documents, ainsi la lecture de cette documentation subodore une connaissance préalable de ces deux points. De même, la connaissance de la programmationobjet et plus particulièrement l'utilisation du langage C++ est un plus pour comprendre certains chapitres. Rapide rappel du "sujet" : Création d'une interface graphique (GUI - Graphical User Interface) sur tablette internet Nokia ( Ici le 770 et le 800 ), cette interface rassemblant les données de capteurs présents dans un réseau à distance. La communication entre ce réseau et la tablette se fait en respectant le protocole SIP. L'interface est créée en utilisant les bibliothèques Qt. Guillaume GARDET Benjamin PUSSACQ Hervé SPITZ Damien LOZACH 3

Chapitre 1 Environnement de développement 1.1. Avant-propos Malgré le fait que les Nokia utilisent un système GNU/Linux, plusieurs différences existent entre un ordinateur classique de bureau et ces dernières. La plus grande d entre-elles est le fait qu ils ne sont pas basés sur la même architecture. En effet, un ordinateur classique est généralement constitué d un processeur compatible x86 alors qu un Nokia est basé sur un processeur ARM. Il est donc facile de comprendre que l on ne peut pas utiliser un compilateur (GCC au hasard) classique pour créer une application pour les tablettes de chez Nokia. Pour parer à ce problème, il faut utiliser un environnement de cross-compilation. Le système d exploitation des tablettes étant un GNU/Linux, Nokia fournit un SDK (Software Development Kit) contenant tous les éléments qui ont permis la réalisation de leur système. Ce Kit est gratuit et peut-être téléchargé sur le net. Afin de le mettre en œuvre, il est nécessaire d utiliser un environnement de cross-compilation. En effet, le compilateur fournit dans le SDK permet de compiler des applications pour les tablettes, mais nécessite lui-même d être sur cette architecture pour pouvoir fonctionner. Ainsi, pour pouvoir simuler cette architecture, l utilisation de l environnement Scratchbox est obligatoire. Cet environnement ne permet pas seulement de simuler les tablettes de Nokia, mais également tout autre système basé sur GNU/Linux et dont l émulation sur l ordinateur est possible. En effet, le principe de Scratchbox est de faire tourner les applications de la tablette grâce à un émulateur nommé Qemu. Il est donc possible de créer un système pour toutes les architectures supportées par cet émulateur. 1.2. Processus de compilation d une application Maintenant que le contexte est bien défini, le processus de développement devient très simple. Il suffit de respecter les étapes suivantes afin d obtenir un résultat satisfaisant : - Installation de la Scratchbox - Installation du SDK - Création d une application - Transfert sur la tablette cible 1.3. Installation de l environnement Scratchbox Pour appliquer ce processus de création, il faut posséder un ordinateur standard muni d un système GNU/Linux (quoi de mieux que Linux pour créer un Linux). Toutes les distributions sont possibles bien évidemment. Malheureusement, à cause de certains problèmes de compatibilité, actuellement non résolus, il est préférable d en privilégier certaines par rapport Guillaume GARDET Benjamin PUSSACQ Hervé SPITZ Damien LOZACH 4

à d autres. L utilisation de Fedora 8 par exemple ne permet pas d utiliser la Scratchbox sans avoir des modifications à faire sur le système. Il est préférable d utiliser une distribution basée sur OpenSUSE ou bien Debian. De plus, Scratchbox étant basée sur cette dernière, des packages au format «.deb» sont disponibles sur le site. L environnement est composé de plusieurs parties. En effet, il n est pas forcément nécessaire d installer la compatibilité avec un processeur si celui-ci ne sera pas utilisé à l avenir. Ces compatibilités sont disponibles dans les packages «toolchain». Dans le cas des tablettes de Nokia, les packages nécessaires sont les suivants : - scratchbox-core : Cœur de l environnement - scratchbox-libs : Bibliothèque pour utiliser la Scratchbox - scratchbox-devkit-cputrans : Emulateur Qemu - scratchbox-devkit-debian : Scripts de démarrage pour Debian - scratchbox-toolchain-cs2005q3.2-glibc-arm : Compilateur pour ARM - scratchbox-toolchain-cs2005q3.2-glibc-i386 : Compilateur pour i386 Pour compiler une application pour la tablette, seule la première toolchain est nécessaire. La seconde permet principalement de pouvoir compiler pour une architecture i386 (pratique lorsqu on désire tester une application sans avoir à la transférer sur le Nokia). D autres packages sont également disponible, mais pas obligatoirement nécessaires. A noter qu il faut par contre installer le package scratchboxdevkit-maemo3 pour pouvoir développer une application pour une tablette utilisant la version 2007 ou 2008 du système Linux de Nokia. Une fois ces packages téléchargés, il faut les installer. Pour cela, il suffit d appliquer la commande en super-utilisateur : $ dpkg i *.deb Attention : Il est important de noter que l installation met en place un script permettant d utiliser l environnement dans le répertoire «/etc/init.d». Ce script se nomme Guillaume GARDET Benjamin PUSSACQ Hervé SPITZ Damien LOZACH 5

«scratchbox-core» et est chargé par défaut au démarrage du système. Ainsi, si vous souhaitez désinstaller «à la main» en supprimant l environnement de développement, il est obligatoire d arrêter ce script via $ /etc/init.d/scratchbox-core stop Sinon, il y a une très grande possibilité pour détruire le répertoire «/dev» de votre système. Outre ce script, l environnement est installé dans une arborescence particulière sous le répertoire «/scratchbox». C est dedans que tous les SDK devront êtres installés par la suite. Il faut maintenant configurer l environnement. Pour cela, c est très simple, il suffit juste d ajouter un nouvel utilisateur dans l environnement. Le script «sbin_adduser» doit être lancé en super-utilisateur pour effectuer cette tache. Le nouvel utilisateur doit correspondre avec un utilisateur existant sur le système installé sur l ordinateur. $ /scratchbox/sbin/sbin_adduser maemo Si vous êtes logué avec le même nom utilisateur que celui qui vient d être utilisé, vous devez redémarrer le serveur X afin de prendre en compte le nouveau groupe «sbox» que vous venez d ajouter à l utilisateur. Voilà, l environnement est configuré, il n y a plus qu à l utiliser. Pour se connecter à cet environnement, vous devez être logué avec l utilisateur ajouté et lancer la commande : $ /scratchbox/login Guillaume GARDET Benjamin PUSSACQ Hervé SPITZ Damien LOZACH 6

Comme le montre l image, l environnement se lance très facilement. On remarque tout de suite la dernière ligne «sb-conf : No current target». En effet, nous n avons pas encore installé de SDK, il est donc normal que l environnement ne le trouve pas. 1.4. Installation d un SDK Les SDK sont fournis par Nokia en partenariat avec Maemo. Ils sont disponibles sur le site internet de ce dernier. Plusieurs versions existent et il faut donc choisir celle qui est la mieux adaptée au système cible. En effet, sur les tablettes Nokia, plusieurs versions de l OS existent : - ITOS2006 : Utilisation du SDK Maemo Gregale (v2) - ITOS2007 : Utilisation du SDK Maemo Bora (v3) - ITOS2008 : Utilisation du SDK Maemo Chinook (v4) Même si les OS sont très similaires, il existe quelques différences entre les différentes versions qui peuvent aboutir à des erreurs lors de l exécution sur le Nokia dans le cas où le mauvais SDK aurait été utilisé. De plus, chaque SDK se décline en 2 versions. Le premier, pour processeur ARM, a pour but de compiler les applications pour la tablette, alors que le second a pour but de compiler chaque application pour architecture i386 afin de tester sans avoir à transférer les données. Une fois téléchargé, il est conseillé (pour la suite) de placer l archive dans le dossier «/scratchbox/packages». Puis l étape d installation du SDK peut commencer via la commande «sb-menu» dans l environnement de crosscompilation. Les images ci-dessous décrivent les différentes étapes à suivre. $ sb-menu Guillaume GARDET Benjamin PUSSACQ Hervé SPITZ Damien LOZACH 7

Installation d une cible Création de la nouvelle cible Nom de la cible Sélection du compilateur ARM Guillaume GARDET Benjamin PUSSACQ Hervé SPITZ Damien LOZACH 8

Sélection de tous les packages Lancement des applications compilées avec l émulateur Qemu Extraction d un SDK SDK téléchargé sur le site de «Maemo» au préalable Guillaume GARDET Benjamin PUSSACQ Hervé SPITZ Damien LOZACH 9

Choix du SDK Confirmation de l installation Installation de tous les composants du SDK Redémarrage de l environnement avec la nouvelle cible Guillaume GARDET Benjamin PUSSACQ Hervé SPITZ Damien LOZACH 10

Cible configurée Le SDK est installé et la Scratchbox s est relancée en utilisant les nouveaux paramètres. L environnement est complet. 1.5. Compilation d une application L environnement fournit tous les outils nécessaires pour la compilation d une application. On retrouve donc des éditeurs de textes, les outils de compilations, les debuggers et autres. Afin de tester ces outils de façon simpliste, il suffit de faire le premier «Hello World» en langage C par exemple. Une fois ce petit programme créé, nous le compilons et le lançons. Et voilà. L exemple donne bien le résultat espéré. En réalité, cet environnement est fait de telle manière que la création d une application soit complètement transparente. Il ne reste plus qu à g33ker comme des petits fous Guillaume GARDET Benjamin PUSSACQ Hervé SPITZ Damien LOZACH 11

Chapitre 2 Mise en place d une pile SIP 2.1. Avant propos Plusieurs piles SIP existent dans le monde merveilleux du libre. Nous avons choisi d utiliser la pile SIP implémentée par la bibliothèque «osip2». En effet, cette pile est assez complète et son empreinte mémoire est suffisamment réduite afin de permettre son utilisation dans le domaine de l embarqué. De plus, une seconde bibliothèque nommée «exosip2» fournit des fonctionnalités de plus haut niveau en se basant sur osip2. Il suffit de passer par ces fonctions simplifiées pour mettre rapidement en place la pile. Ces deux bibliothèques sont librement téléchargeables à l adresse : http://savannah.gnu.org/projects/osip http://download.savannah.nongnu.org/releases/exosip. et 2.2. Installation d osip2 et d exosip2 L installation d osip2 se fait de façon transparente en utilisant le trio : $./configure $ make $ make install Il suffit donc d exécuter ces commandes afin de compiler la pile pour l architecture ARM. Par contre, dans le cas d exosip2, une petite manipulation supplémentaire est à prendre en considération. En effet, malgré le fait que le script «configure» ne donne aucune erreur, un problème de compilation apparaît. Guillaume GARDET Benjamin PUSSACQ Hervé SPITZ Damien LOZACH 12

En réalité, la bibliothèque SSL installée par défaut est épurée sur le Nokia. Ainsi, plusieurs primitives et fonctions sont manquantes. Afin de contourner le problème, nous allons désactiver le support de SSL dans exosip2. Pour cela, il suffit d éditer le fichier «config.h» et commenter la ligne. #define HAVE_OPENSSL_SSL_H 1 Une fois cette modification effectuée, nous relançons la compilation. $ make clean $ make $ make install 2.3. Compilation d une application utilisant «osip2» Tout d abord, vous devez créer une application utilisant la pile SIP fournie par osip2 dans votre éditeur préféré. L étape de compilation se fait de façon classique. La ligne de commande standard pour cette étape est la suivante. gcc o test test.c losip2 losipparser2 lexosip2 Guillaume GARDET Benjamin PUSSACQ Hervé SPITZ Damien LOZACH 13

Chapitre 3 Mise en place de la bibliothèque QT 3.1. Avant-propos QT est une bibliothèque fournissant toute une panoplie de fonctionnalités permettant de concevoir des interfaces graphiques. Elle est entièrement conçue en C++ par la société Trolltech. Lors de la mise en place de QT pour les tablettes, plusieurs problèmes se sont posés à nous. Tout d'abord, il est important de faire la différence entre QT et Qtopia. QT donne la possibilité de créer une interface graphique dans le cas où un serveur graphique est déjà existant sur la plate-forme, tel que le serveur graphique de MacOS ou bien serveur X11. Qtopia, quant à lui, fournit un serveur graphique embarqué en plus de la bibliothèque graphique pour les plates-formes non équipées. Dans notre cas, nous devons utiliser QT car les tablettes possèdent déjà un serveur X11 natif. D autre part, la version utilisée ici est estampillée 4.1.5. Les versions supérieures posent plusieurs problèmes de compilation qui n ont pas été résolus. Cette version est directement téléchargeable à l adresse : http://ftp.ntua.gr/pub/x11/qt/qt/source/qt-x11-opensource-src-4.1.5.tar.gz 3.2. Installation de QT La version de QT choisie pose quelques problèmes lors de la compilation. Mais ceux-ci sont facilement corrigeables. Il faut tout d abord décompresser l archive, puis exécuter le script de configuration. Celui-ci est appelé de la façon suivante../configure prefix /opt/qt415 L option «-prefix» permet de définir un répertoire d installation autre que celui par défaut. Ce script demande d abord de valider la licence de QT afin de pouvoir lancer la configuration. Il est donc nécessaire d entrer «yes» et de valider. À partir de cet instant, la configuration s effectue. Cette étape peut s avérer longue et par conséquent, une pause-café s impose. Une fois la création des «Makefile» terminée, le script rend la main. Il faut maintenant procéder à quelques modifications afin de pouvoir compiler QT sans erreur. Lors de la compilation pour architecture ARM, des outils comme «linguist» et «designer» posent quelques problèmes. Il faut donc les désactiver. Pour cela, nous remplaçons les «Makefile» originaux par ceci dans les répertoires correspondants. Guillaume GARDET Benjamin PUSSACQ Hervé SPITZ Damien LOZACH 14

install : all : echo Etape finie Deux autres erreurs doivent également être corrigées. Il s agit cette fois-ci d erreurs dans le code. La première est due à un code manquant. Il est nécessaire de rajouter dans le fichier «src/gui/qmath_p.h» les lignes suivantes : #inline double qmin(double a, double b) { return (a > b)? b : a ; } #inline double qmax(double a, double b) { return (a > b)? a : b ; } Enfin, la dernière erreur est due à des cast manquants dans le fichier «src/gui/kernel/qapplication_x11.cpp». Ainsi, la ligne 1512 du fichier initialement getxdefault("xft", FC_SCALE, &X11->fc_scale); doit être remplacée par la ligne suivante : getxdefault((char *)"Xft", (char *)FC_SCALE, (int *)&X11- >fc_scale); Une fois ces trois modifications terminées, le plus long reste à faire pour l ordinateur. Il suffit de compiler et installer QT. Pour cela, la suite de commandes cidessous est nécessaire. $ make $ make install 3.3. Compilation d une application QT Une fois que l application a été créée via «designer» ou tout autre moyen, QT fournit plusieurs outils afin de créer les «Makefile» nécessaires à la compilation de l application. Il faut d abord créer un nouveau projet puis les «Makefile» avant de compiler. $ qmake -project $ qmake $ make Le problème est que le projet est créé par défaut en utilisant les bibliothèques de «debug» de QT qui sont nettement plus grosses que celles sans les informations de déboguage. Or, dans le monde de l embarqué, l empreinte mémoire est un élément Guillaume GARDET Benjamin PUSSACQ Hervé SPITZ Damien LOZACH 15

important. Afin de parer à ce problème, il faut alors modifier le fichier «.pro» qui a été créé lors de l exécution de la commande «qmake». Il suffit de supprimer toutes les itérations «_debug» dans le fichier «Makefile». Au final, la suite de commandes se résume à la suivante. $ qmake project $ qmake $ sed «s/_debug//» Makefile > TMP $ mv Makefile Makefile-old $ mv TMP Makefile $ make L application est alors créée en utilisant les bonnes bibliothèques. Il ne reste plus qu à transférer l application sur le Nokia et tester l ensemble. Guillaume GARDET Benjamin PUSSACQ Hervé SPITZ Damien LOZACH 16

Chapitre 4 Objets de base 4.1. Avant propos Les objets de base (non graphiques et XML) sont écrits en C++ pour une meilleure réutilisabilitée. De plus, Qt est basé sur du C++. Ces objets seront utilisés par la partie interface graphique et le partie XML. La partie SIP sera gérée par deux objets : SIP et Communication. L'objet SIP est une implémentation assez directe en C++ des bibliothèques SIP, écrites en C (libexosip et osip), qu'il utilise. L'objet Communication apporte plus de souplesse dans l'utilisation de SIP et utilise l'objet SIP précédent. Il apporte aussi des méthodes utiles lors de la communication (obtention automatique de l'ip, sauvegarde de l'identifiant SIP, etc...). Ensuite la partie concernant la gestion des objets est constituée des objets Capteur, Group et Alarm. Capteur contient toutes les informations qui concernent le capteur par lui-même (id, type, nom, etc...), Group contient les informations de gestion d'un groupe de capteurs et Alarm (non utilisé) contient toutes les informations nécessaires à l'utilisation d'alarmes (température inférieure à 0 C par exemple) dans Capteur. 4.2. Objets de communication L'objet SIP est un objet de base qui ne sera pas appelé directement depuis notre programme ou les autres objets, excepté Communication. Il est constitué de : le constructeur SIP() qui initialise la pile SIP. le destructeur ~SIP() qui quitte proprement la pile SIP Les méthodes : bool SIP::Creation() qui ouvre un socket sur le port 5060 en UDP. Retourne false si un problème est rencontré, true sinon. bool SIP::Send(std::string de, std::string a, std::string msg, std::string type, int timeout) qui se charge d'envoyer le message SIP "msg" provenant de "de" destiné à "a" de type "type" et on spécifie un timeout par "timeout". Cette méthode retourne false si un problème est rencontré, true sinon. void* SIP::Listen(void* a) qui sera lancée dans un thread (d'où les void*) et qui lance un serveur d'écoute qui se charge d'appeler les bonnes méthodes en fonction des requêtes SIP. Lorsque qu'une réponse à notre message est reçue (EXOSIP_MESSAGE_ANSWERED) la méthode read_xml_string(std::string(buf->body)); à laquelle on passe le corps de la réponse en paramètre, est appelée pour traiter la réponse. L'objet Communication utilise l'objet SIP. Il est constitué de : Le constructeur Communication() qui crée un objet SIP et effectue toutes les Guillaume GARDET Benjamin PUSSACQ Hervé SPITZ Damien LOZACH 17

initialisations (SIP->Creation(), obtention automatique de l'ip, création de l'id SIP et lancement du serveur d'écoute SIP::Listen(void*) dans un thread), uniquement lors du premier appel. Rien lors des autres appels. Le destructeur ~Communication() qui se charge de quitter le thread et de détruire l'objet SIP créé par le constructeur. Les méthodes : std::string setid(std::string _login, std::string _adresse) qui se charge de construire un ID SIP à partir du login et de l'adresse passés en paramètres. Retourne un string de la forme <sip:login@adresse> std::string setmyid(std::string _login, std::string _adresse) qui appelle la méthode précédente (setid) pour formater l'id puis le sauvegarde dans la variable my_sip_id interne à l'objet. int settimeout(int _timeout) qui règle le timeout pour les messages SIP. std::string settype(std::string _type) qui règle le type de message SIP. (type "message" utilisé dans notre application). bool Send(std::string login, std::string adresse, std::string message) se charge d'envoyer le message "message" à "<sip:login@adresse>" en utilisant l'objet SIP. Retourne false si un problème a été rencontré lors de l'envoi true sinon. bool Send(std::string dst, std::string message) envoie le message "message" au destinataire "dst" (dst est de la forme login@adresse). int get_ip(std::string* ip) permet de récupérer l'adresse IP courante de la machine. Utilise l'utilitaire ifconfig. std::string get_sipid() retourne my_sip_id qui est notre ID SIP. void* Listen(void*) qui n'est en fait pas utilisée et qui, au départ, devait appeler la méthode void* SIP::Listen(void*). 4.3. Objets de gestion des capteurs L'objet Alarm n'est finalement pas utilisé à cause de problèmes d'implémentation du côté serveur. Il est constitué de : Les constructeurs : Alarm() initialise les valeurs d'alarmes haute et basse à 0 et la latence à 10. Alarm(int _H, int _L) initialise les valeurs d'alarme haute à _H et basse à _L et la latence à 10. Le destructeur ~Alarm() ne fait rien. Les méthodes : int get_h() renvoie la valeur haute de l'alarme int set_h(int) spécifie la valeur haute de l'alarme. int get_l() renvoie la valeur basse de l'alarme int set_l(int) spécifie la valeur basse de l'alarme. int get_latency() renvoie la latence actuelle. Guillaume GARDET Benjamin PUSSACQ Hervé SPITZ Damien LOZACH 18

int set_latency(int) spécifie la latence. Renvoie -1 en cas d'erreur et 0 en cas de succès. La valeur minimale est 1 (une seconde). L'objet Capteur contient toutes les données relatives à un capteur. Il est constitué de : Les constructeurs : Capteur(std::string _id, std::string _type) qui construit un objet à partir de l'identifiant unique id et le type de capteur type. Il instancie aussi un objet Communication qui sera créé s'il n'en existe pas encore ou utilisera celui créé. Capteur(std::string _id, std::string _type, std::string _name) qui construit un objet à partir de l'identifiant unique, du type et du nom donné au capteur (non unique). Il instancie aussi un objet Communication qui sera créé s'il n'en existe pas encore ou utilisera celui créé. Le destructeur ~Capteur() qui supprime toutes les références à lui-même dans les groupes auxquels il appartient. Les méthodes : Alarm get_alarms() retourne l'objet Alarm associé (non utilisé). int save() non utilisé car modification de la partie XML. std::string get_value() retourne la valeur du capteur. void set_value(std::string _value) attribue la valeur au capteur. bool update_value(std::string dst) se charge d'envoyer un message SIP pour demander l'actualisation du capteur. Renvoie false si un problème est rencontré true sinon. int set_alarms(alarm) attribue un objet Alarm au capteur (non utilisé) int set_group(std::vector<group*>) attribue un vecteur de Group au capteur. int set_name(std::string) attribue un nom au capteur. std::string get_name() récupère le nom du capteur. int add_group(group*) ajoute un groupe MAIS PAS LE CAPTEUR AU GROUP! std::vector<std::string> get_groupstring() récupère la liste des groupes sous forme de vecteur de string. std::vector<group*> get_group() récupère le vecteur de groupe. int rm_group(group*) supprime le groupe du vecteur de Group du capteur. std::string get_id() renvoie l'id du capteur std::string get_type() renvoie le type du capteur void enable_alarm() active l'alarme (non utilisé) void disable_alarm() désactive l'alarme (non utilisé) unsigned int get_date() renvoie la date d'acquisition (entier non signé qui correspond au temps unix, nombre de seconde écoulées depuis le 1 er janvier 1970). void set_date(unsigned int) règle la date de la dernière acquisition. Guillaume GARDET Benjamin PUSSACQ Hervé SPITZ Damien LOZACH 19

bool get_updated() retourne true si la valeur du capteur a été mise à jour depuis la dernière lecture, false sinon. L'objet Group contient toutes les données relatives à un groupe. Il est constitué de : Le constructeur Group(std::string nom) construit un groupe nommé "nom" qui ne contient aucun capteur. Le destructeur ~Group() qui se dé-référence dans tous les capteurs qui appartiennent à ce groupe. Les méthodes : std::string get_name() retourne le nom du groupe void set_name(std::string _name) attribue le nom au groupe. int add_capt(capteur* capteur) ajoute un capteur au groupe MAIS PAS LE GROUPE AU CAPTEUR! int rm_capt(capteur* capteur) retire un capteur du groupe. Retourne -1 si le capteur n'a pas été trouvé dans la liste, 0 sinon. unsigned int get_nb_capteurs() retourne le nombre de capteur du groupe. std::vector<capteur*> *get_list() renvoie l'adresse du vecteur contenant les références vers les capteurs du groupe. Guillaume GARDET Benjamin PUSSACQ Hervé SPITZ Damien LOZACH 20

Chapitre 5 Les outils XML Les outils XML sont implémentés dans les fichiers xml_tools.{c,h}pp. Ce fichier est divisé en trois parties : - Fonctions utiles dans les deux autres parties : o Utily - La communication SIP : o Answer from Capteur's Network o Resqued to Capteur's Network - La sauvegarde et le chargement d'informations. o Load from file o Save to file 5.1. La sauvegarde et le chargement d'informations Dans une partie précédente, il a été présenté les objets Capteurs avec leurs attributs. Il est nécessaire de sauvegarder les données propres aux capteurs dans un fichier. Cette sauvegarde se fait manuellement, à la demande de l'utilisateur. (cf Chapitre 6) Les capteurs sont différenciés par leur "id" qui est unique. Les attributs de chaque capteur contiennent des informations propres aux capteurs, ou propres à l'utilisateur. Ainsi deux fichiers de sauvegarde sont nécessaires. Un fichier commun à tous les utilisateurs "Capteur.xml" et un fichier de préférence "pref.xml" propre à un utilisateur. Choix du format de fichier : Un format libre, efficace, très répandu existe : le format XML (Extensible Markup Language). De plus, des outils très performants existent dans la bibliothèque Qt. Qt offre deux manières d'interagir avec des contenus au format XML : DOM et SAX. SAX est théoriquement le plus simple des deux, il permet de lire et parser au fur et à mesure. Avec DOM, le fichier est lu entièrement et mis dans un arbre, en mémoire. Cet arbre peut ensuite être lu et manipulé avant d'être à nouveau sauvegardé. Choix de la bibliothèque : SAX est plus "difficile" à utiliser pour modifier les données. D'un autre coté, il ne requiert que peu de mémoire car la lecture se fait au fur et à mesure. DOM requiert, lui, beaucoup de mémoire mais propose beaucoup plus d'outils. Au vu de l'application et des supports d'utilisation ainsi que de l'ordre de grandeur des données traitées, l'utilisation de DOM n'est pas un problème. Son utilisation est, par contre, un très gros gain de temps de compréhension et d'implémentation pour le développement de l'application. Guillaume GARDET Benjamin PUSSACQ Hervé SPITZ Damien LOZACH 21

La sauvegarde se fait donc dans deux fichiers. Le premier "Capteur.xml" : qui regroupe tous les capteurs, au format suivant : <save_capteur> <capteur> <id>id d'un premier capteur</id> <type>type associé à ce capteur</type> </capteur> <capteur> <id> ID d'un deuxième capteur </id> <type>type associé à ce capteur</type> </capteur> [ ] </save_capteur> Guillaume GARDET Benjamin PUSSACQ Hervé SPITZ Damien LOZACH 22

Le deuxième "pref.xml" : qui regroupe les préférences de l'utilisateur, au format suivant : <pref> <list_capteur> <capteur> <id>id d'un premier capteur</id> <name>nom associé à ce capteur</name> <value>valeur associée à ce capteur</value> <acquisition_date>heure associée à cette valeur </acquisition_date> <groups> <group>nom d'un groupe le contenant</group> <group>nom d'un autre groupe le contenant</group> [ ] </groups> </capteur> <capteur><id>id d'un deuxième capteur</id> <name>nom associé à ce capteur</name> <value>valeur associée à ce capteur</value> <acquisition_date>heure associée à cette valeur </acquisition_date> <groups> <group>nom d'un groupe le contenant</group> <group>nom d'un autre groupe le contenant</group> [ ] </groups> </capteur> </list_capteur> <server> <ip-login>utilisateur@192.168.4.221</ip-login> </server> </pref> Guillaume GARDET Benjamin PUSSACQ Hervé SPITZ Damien LOZACH 23