DEVELOPPEMENT D UNE APPLICATION ANDROID DE GESTION AUTOMATIQUE DES MODES DU TELEPHONE

Transcription

1 Institut Supérieur d Informatique, de Modélisation et de leurs Applications Campus des Cézeaux BP Aubière Cedex Openium Développement d Applications Mobiles 15, Rue Jean Claret Bâtiment «Le XV» Parc Technologique de la Pardieu Clermont-Ferrand RAPPORT DE PROJET DE 1ERE ANNEE DE L INSTITUT SUPERIEUR D INFORMATIQUE, DE MODELISATION ET DE LEURS APPLICATIONS PROJET DE 20 HEURES DEVELOPPEMENT D UNE APPLICATION ANDROID DE GESTION AUTOMATIQUE DES MODES DU TELEPHONE Jérémy PFEIFER Mylène SIMON Tuteur de projet : Olivier GOUTET Année scolaire

2

3 Remerciements Nous tenons à remercier particulièrement Olivier GOUTET, notre tuteur de projet, pour toute l aide et les précieux conseils qu il nous a apportés au cours du développement de l application et pendant la rédaction de ce rapport, ainsi que pour sa patience et sa sympathie. Nous remercions également la société Openium qui nous a accueillis dans ses locaux lors de nos entretiens avec M. GOUTET. Enfin, nous remercions Christine FORCE d avoir accepté notre sujet de projet et de nous avoir dirigés vers la société Openium lorsque nous recherchions un encadrement pour ce projet.

4 Sommaire : Introduction Contexte Android Les Activités (appelées Activities) Les Services Les Broadcast et Intent receivers Les Content providers Le cycle de vie d une application Les outils utilisés Eclipse Dropbox Description du projet Choix du projet L application StatusManager Objectif Description générale... 7 Onglet Aperçu... 7 Onglet Agenda... 7 Onglet Exceptions Gestion du projet Le développement de l application Les applications de tests Planification d'évènements Création de graphiques à partir de données extraites dynamiquement Conception de la base de données Architecture de l application Spécificités d'android Organisation du code Bilan Conclusion Annexes Sitographie

5 Table des figures : Figure 1.1 : Cycle de vie d'une application Android... 3 Figure 1.2 : Logo d'eclipse... 4 Figure 1.3 : Capture d'écran de l'outil Dropbox... 5 Figure 2.1 : Capture d'écran de l'onglet "Aperçu"... 7 Figure 2.2 : Captures d'écran de l'onglet "Agenda" et de l'insertion d'une nouvelle plage horaire... 8 Figure 2.3 : Capture d'écran de l'onglet "Exceptions"... 8 Figure 2.4 : Maquette de l'application... 9 Tables des annexes : Annexe I : Schéma UML Annexe II : Base de données

6 Introduction Dans le cadre de notre première année à l Institut Supérieur d Informatique, de Modélisation et de leurs Applications (ISIMA), nous avons réalisé un projet informatique de vingt heures en binôme. Ce projet a porté sur la création d une application Android appelée StatusManager permettant de gérer le mode du téléphone automatiquement en fonction de plages horaires définies par l utilisateur. Pour l encadrement de notre projet, nous avons été dirigés vers l entreprise Openium, spécialisée en développement d applications mobiles, et c est Olivier GOUTET, Responsable Recherche et Développement de cette société qui a été notre tuteur. Ce rapport présente le travail que nous avons effectué pour développer l application StatusManager. Tout d abord, nous aborderons dans une première partie le contexte du projet ainsi que les outils que nous avons utilisé. Nous nous attacherons ensuite à décrire notre projet, en expliquant pourquoi nous l avons choisi et en présentant plus en détails l application StatusManager. Enfin, dans une troisième partie, nous nous pencherons sur le développement de l application, en développant les différentes étapes de sa conception et en décrivant son architecture. 1

7 1. Contexte 1.1. Android Android est un système d exploitation Open Source pour smartphones, PDA et terminaux mobiles, sorti en novembre Il a été à l origine conçu par Android Inc, une startup rachetée par Google, l entreprise mondialement connue pour son moteur de recherche. Ce système est fondé sur un noyau Linux et comporte une interface spécifique développée en Java. Il est ainsi possible de développer des applications fonctionnant sur les appareils mobiles équipés d Android, à l aide du SDK (kit de développement) fourni pour Google. Les applications Android comportent quatre principales composantes : les activités, les services, les broadcast et intent receivers et les content providers Les Activités (appelées Activities) Une activité ou activity est la composante principale d une application Android. Pour simplifier, cela correspond à une fenêtre de l application Les Services Un service est un processus qui effectue des traitements en arrière plan, il ne possède donc pas de vue, contrairement à une activité. Les services sont donc nécessaires lorsqu une application doit effectuer des opérations ou des calculs en dehors de l interaction utilisateur. Ils permettent l exécution d un algorithme sur un temps indéfini et ne s arrêtent que lorsque la tâche est finie ou que leur exécution est arrêtée Les Broadcast et Intent receivers Le Broadcast Receiver est un écouteur de messages. Il permet d écouter ce qui se passe sur le système ou sur l application et de déclencher une action prédéfinie. Les messages envoyés par le système Android sont appelés des Intent. Ce sont des structures de données basiques contenant diverses informations. Ils permettent de lancer les composants d une application (sauf les Content providers) et la communication interapplications. 2

8 Les Content providers Les content providers servent à accéder à des données depuis l application. Une application peut utiliser différents moyens pour stocker des données (bases SQL, préférences, fichiers, ), implémenter un content provider permet donc aux autres composants de l application, et éventuellement aux autres applications, de récupérer ces données de manière centralisée Le cycle de vie d une application Les applications Android suivent ce qu on appelle le «cycle de vie d une application» (Figure 1.1). Figure 1.1 : Cycle de vie d'une application Android 3

9 La méthode oncreate() est appelée à la création de l activité et sert à l initialiser. La méthode onstart() est appelée dans le cas où l application repasse en avant-plan alors qu elle était en arrière-plan. La méthode onresume() est appelée après la méthode onstart(), c'est-à-dire au moment où l application repasse en avant-plan. La méthode onpause() est appelée juste avant qu une autre application passe en avant-plan. L activité n a donc plus accès à l écran. La méthode onstop() est appelée quand l activité n est plus visible. La méthode ondestroy() est appelée quand l application est totalement fermée, c'est-à-dire quand le processus correspondant est terminé Les outils utilisés Eclipse Pour développer notre application, nous avons choisi d utiliser l environnement de développement intégré Eclipse (Figure 1.2). Il s agit d un environnement de développement libre, extensible, polyvalent et universel qui permet de créer des projets de développement dans n importe quel langage de programmation. Principalement écrit en Java, sa spécificité vient du fait que toutes ses fonctionnalités sont développées en tant que plugin. En installant le SDK Android fourni par Google, Eclipse permet de développer plus facilement des applications Android et de les tester sur un émulateur de téléphone. Figure 1.2 : Logo d'eclipse 4

10 Dropbox Afin de gérer les mises à jour du code de notre application, nous avons choisi d utiliser l outil Dropbox, un service de stockage et de partage de fichiers en ligne. C est un service dit d informatique en nuage qui est accessible depuis n importe quel navigateur web ou en utilisant un client multi-système d exploitation. Il permet la synchronisation des fichiers stockés sur différents ordinateurs de manière transparente avec sauvegardes et synchronisations automatiques. Grâce au site web de Dropbox, il est également possible d accéder à une copie des fichiers ainsi qu à leurs versions successives et à une copie des fichiers détruits (Figure 1.3). Figure 1.3 : Capture d'écran de l'outil Dropbox 5

11 2. Description du projet 2.1. Choix du projet Nous avons choisi de proposer un sujet personnel pour le projet que nous avons à réaliser dans le cadre de notre première année à l ISIMA. En effet, il nous semblait plus intéressant, étant donné que nous avions déjà réalisé des projets informatiques lors de notre formation à l IUT, de profiter de cette occasion pour travailler sur une technologie moins habituelle. Comme nous possédions tous les deux des téléphones Android et que l un de nous avait déjà acquis de solides notions de développement sur cette plateforme grâce à son stage, notre choix s est naturellement porté vers le développement d une application Android. Nous avons ensuite cherché à imaginer une application qui nous serait utile dans notre vie de tous les jours et qui resterait assez facilement développable pour que cela puisse s intégrer dans un projet d une vingtaine d heures de travail chacun. C est ainsi qu est née l idée de l application StatusManager, une application permettant de gérer de manière automatique le statut du téléphone. Nous nous sommes alors adressés à Mme Christine FORCE, directrice des études de l ISIMA, qui nous a orientés vers la société Openium, alors basée dans les locaux de l ISIMA et spécialisée dans le développement d applications mobiles. C est Olivier GOUTET, responsable Recherche et Développement de la société, qui nous a encadrés tout au long de ce projet L application StatusManager Objectif L'application StatusManager a pour but de permettre de programmer les changements de statut du téléphone, en fonction de certaines périodes. Ainsi, le téléphone pourra se mettre automatiquement en mode silencieux, vibreur, ou sonnerie, en fonction du jour de la semaine, et des différentes plages horaires définies par l'utilisateur. Ce dernier pourra de plus programmer certaines plages horaires ne se produisant qu'à une certaine 6

12 date, par exemple pour un rendez-vous, afin que le téléphone adapte automatiquement son mode Description générale L'application se présente sous la forme de trois onglets, chacun permettant d'accéder à différentes fonctions. Onglet Aperçu L'onglet aperçu permet de visualiser d'un seul coup d'œil les différentes plages horaires de la journée, avec le mode correspondant. Celles-ci se présentent sous la forme d'un diagramme circulaire, gradué suivant les heures de la journée (Figure 2.1). Onglet Agenda Figure 2.1 : Capture d'écran de l'onglet "Aperçu" Cet onglet permet de gérer les différentes plages horaires. Il est ainsi possible d'ajouter de nouvelles plages, avec le mode correspondant, ou de supprimer celles qui seraient déjà définies, ceci pour n'importe quel jour de la semaine (Figure 2.2). 7

13 Figure 2.2 : Captures d'écran de l'onglet "Agenda" et de l'insertion d'une nouvelle plage horaire Onglet Exceptions Le dernier onglet permet de gérer des plages horaires, avec un fonctionnement presque identique à celui de l'onglet Agenda. La différence est que les plages ne sont pas définies pour un jour de la semaine, mais pour un jour en particulier. L'utilisateur peut donc planifier un rendez-vous à l'avance, durant lequel le téléphone changera automatiquement de statut, pour se mettre en mode silencieux (Figure 2.3). Figure 2.3 : Capture d'écran de l'onglet "Exceptions" 8

14 2.3. Gestion du projet Nous avons commencé par définir les fonctions que devait remplir l application, comme vu dans la partie précédente. Puis, avant de commencer le développement, nous avons réalisé une maquette sous la forme d un diaporama OpenOffice (Figure 2.4). Le but était de développer l application en ayant déjà en tête l aspect général des différentes activités. Figure 2.4 : Maquette de l'application Nous avons après cela créé le modèle de la base de données de l application, détaillée dans le point 3.2. En ce qui concerne le développement, nous sommes réparti les tâches, et nous avons réfléchi ensemble et avec notre tuteur de projet aux différentes fonctionnalités à implémenter. 9

15 3. Le développement de l application 3.1. Les applications de tests Avant de réaliser certaines parties de l'application StatusManager, il a fallu nous assurer que tous les points étaient réalisables, avant de les intégrer dans l'application finale. Nous avons donc effectué des tests sur la planification des évènements, ainsi que sur la création de graphiques générés à partir de données extraites de la base de données. En effet, ces deux points nous paraissaient être ceux étant susceptibles d apporter le plus de problèmes Planification d'évènements La planification d'événements sur Android soulève quelques difficultés. En effet, il faut être en mesure de garantir que les actions qui ont été programmées soient exécutées, même si l'application à l'origine de ces actions a été stoppée entre temps. Afin de tester la possibilité de créer de tels évènements, nous avons développé une petite application, proposant un unique bouton, permettant de planifier l'affichage d'un message après une période donnée lors d'un appui sur ce dernier. Une fois l'application réalisée, nous avons intégré la fonctionnalité de planification dans l'application finale Création de graphiques à partir de données extraites dynamiquement Ce deuxième point méritait également une attention particulière. En effet, nous savions qu'il était possible de créer des graphiques sur Android, mais nous ne connaissions pas les différentes bibliothèques permettant de réaliser cela. Nous ne connaissions donc pas les contraintes liées à l'utilisation de ces bibliothèques. Après avoir sélectionné une bibliothèque correspondant à nos besoins, nous avons créé une application qui avait pour seul rôle d'afficher des graphiques à partir de données arbitraires. Une fois l'application réalisée, nous avons intégré l'affichage des graphiques à l'intérieur de l'application finale. 10

16 3.2. Conception de la base de données La gestion des plages horaires repose sur une table principale, permettant de stocker des instants précis dans le temps, associés chacun à un mode particulier : la table link_mode_weekday_slots. Elle fait ainsi le lien entre la table ref_modes, qui contient les différents modes possibles, et les tables slots et ref_weekday, qui contiennent respectivement les heures et les jours de la semaine. De la même manière, la table link_mode_exception permet de stocker les rendez-vous précis, en liant cette fois ci la table ref_modes avec la table exceptions, qui contient les différents rendez-vous. La table ref_strings contient quant à elle la liste des chaines de caractères, dans différentes langues. Elle permet ainsi de doter l application d un aspect multilingue. Enfin, les la table logs contient les logs enregistrés lors de l utilisation de l application, à des fins de débogage. Les différents niveaux de logs sont enregistrés dans la table ref_logs_levels, et le niveau désiré peut être réglé grâce à une constante prédéfinie dans la classe DatabaseManager, ce qui permet de désactiver les logs lors de la publication de l application, ou de les filter afin de ne garder que les logs d erreurs. Le schéma de cette base de données est disponible dans l Annexe II : Base de données. 3.3 Architecture de l application Spécificités d'android Les applications Android possèdent un fonctionnement particulier. Tandis qu'une application courante comporte un seul point d'entrée, et permet ensuite de naviguer à l'intérieur, les applications Android comprennent de multiples points d'entrée, et seulement une partie du code de l'application nécessite d'être exécuté, en fonction de l'action demandée. Ce fonctionnement permet de faire communiquer les applications entre elles de manière très efficace. En effet, une application peut utiliser des éléments d'une autre application, si celle-ci le permet. Par exemple, si une application a besoin d'afficher une liste déroulante 11

17 d'images, et qu'une autre application comporte un système qui pourrait convenir, qu'elle rend disponible aux autres, alors il est possible d'appeler cette dernière afin qu'elle réalise la tache à accomplir, plutôt que de développer de nouveau une action similaire. Le fonctionnement des applications repose donc sur un principe comparable à un site web interactif, où l'on peut naviguer d'une page à l'autre, en suivant un cheminement logique entre les pages, mais où l'on peut aussi entrer indifféremment par la page d'accueil, ou par toute autre page permettant d'effectuer une certaine action. Les applications sont ainsi composées «d'activités» qui peuvent être exécutées indépendamment. Il a donc été nécessaire de concevoir l'application différemment de ce que nous avions l'habitude de développer en Java. Notamment, nous avons du faire attention à l'enchainement entre les activités, et aux paramètres transmis d'une activité à l'autre. Nous avons également rencontré une autre difficulté, liée à la plateforme Android. Cette dernière permet en effet de lancer plusieurs applications en même temps, et sa gestion du cycle de vie des programmes est assez particulière. Lorsqu'une activité passe en arrière plan, elle est mise en pause, puis redémarré lorsqu'elle revient sur le premier plan. Or, lorsque celle-ci est en arrière-plan, elle peut être détruite si le système a besoin de libérer des ressources. Il faut donc faire attention à sauvegarder l'état de l'activité, et à le restaurer dès que ceci est nécessaire. Le téléphone est également équipé de capteurs permettant de détecter son inclinaison. Ainsi, lorsque le téléphone change d'orientation, l'application change également d'orientation. Lorsqu'un changement d'orientation intervient, l'activité actuellement au premier plan est détruite, puis recrée instantanément. Il est alors nécessaire d'anticiper ce comportement lors de la conception d'une activité, et donc d'une application en général Organisation du code Afin d'organiser notre raisonnement, nous avons commencé par réaliser un diagramme de classes, afin de visualiser l'architecture globale de l'application (Annexe I : Schéma UML). Tout d'abord, la plupart des activités devant accéder à la base de données, cette dernière représente un point central de l'application. Nous avons donc commencé par implémenter 12

18 une classe gérant l'ouverture et la fermeture de la base de données : le DatabaseManager, pouvant être instanciée facilement depuis une autre classe. L'architecture du logiciel se rapprochant fortement du modèle MVC, celui ci s'appuie sur un modèle : le ScheduleManager, héritant de la classe abstraite Manager, qui lui permet d'obtenir une connexion à la base de données. D'autres modèles peuvent ainsi être rajoutés, chacun héritant de la classe Manager (voir Annexe I : Schéma UML). Le ScheduleManager permet ainsi de récupérer la liste des différentes plages horaires depuis la base de données, et de les gérer, en ajoutant de nouvelles plages ou en supprimant celles déjà existantes. Le reste des classes représente des activités, qui peuvent être considérées comme contrôleurs. En effet, ce sont elles qui gèrent l'affichage des éléments à l'écran, et les interactions de l'utilisateur. Les vues, quand à elles, sont matérialisées sous forme de fichiers xml liés à l'application, et indiquant la position des éléments sur l'écran. Chaque activité est alors liée à un ou plusieurs de ces fichiers Bilan Nous n'avons malheureusement pas été en mesure de réaliser la totalité des fonctionnalités prévues, mais un certain nombre ont tout de même été implémentées. Il est ainsi possible d'insérer des plages horaires pour n'importe quel jour de la semaine, avec le mode associé. Le passage effectif du téléphone dans le mode correspondant n'est pas encore assuré complètement, mais celui-ci change bien lors du début de la plage horaire. L application n est donc pas encore totalement fonctionnelle, et il reste à compléter la liaison avec le gestionnaire d alarme lors de l ajout d une plage horaire. Les graphiques fonctionnent, mais ils sont pour l'instant codés en dur, et il reste juste la liaison avec la base de données à effectuer. 13

19 L'architecture globale est donc en place, et les fonctionnalités manquantes pourront être rajoutées par la suite, car la conception de l'application est telle qu'il est possible de la faire évoluer dans le futur sans trop de difficultés. En effet, des fonctionnalités telles que l'ajout de modes personnalisés ou la personnalisation des graphiques sont envisageables, et la base de données est construite en conséquence. 14

20 Conclusion Ce projet a été très bénéfique pour nous, dans la mesure où il nous a permis de nous confronter aux difficultés liées à ce type de travail. Il nous a ainsi permis de progresser dans le développement d applications Android, l un d entre nous ayant appris à développer sur cette plateforme grâce à ce projet, et l autre ayant pu compléter ses connaissances. Nous avons également rencontré les difficultés du travail collaboratif, notamment la confrontation des différents points de vue lors de la conception de la base de données et des différents composants de l application. Cette expérience nous a ainsi permis d apprendre à collaborer sur un projet, ce qui n est pas toujours facile. Il nous a de plus permis d obtenir davantage d expérience en ce qui concerne la gestion du temps, et des priorités, que nous avions parfois du mal à cerner, dans un projet de développement. Grâce à tous ces différents aspects, nous pouvons dire que ce projet a constitué une expérience enrichissante, et malgré le fait que nous n ayons pas été en mesure de le terminer, nous sommes heureux d avoir eu la possibilité de travailler sur un projet que nous avons choisi de toutes parts. 15

21 Annexes Annexe I : Schéma UML

22 Annexe II : Base de données

23 Sitographie 1. ANDROID Android. < 2. THE ECLIPSE FOUNDATION Eclipse. < 3. DEVELOPPEZ.COM Introduction à la programmation sous Android. < 4. MIXIMUM Android : découvrir les concepts de base. < 5. WIKIPEDIA Dropbox. < 6. TUTOS ANDROID Les services sous Android. < 7. BLOG OXIANE Créer une base sqlite dans Android. < 8. ANDROID POUR LES NULS Tutoriel : Installation de l environnement de développement Eclipse - Android. < 9. MySQL MySQL Workbench 5.2. < 10. XEBIA Comment intégrer des graphiques dans une application Android. < 11. ACHARTENGINE AChartEngine. <

24