developpement d’une application android€¦ · développement d’applications mobiles 15, rue...
TRANSCRIPT
Institut Supérieur d’Informatique, de Modélisation et de leurs Applications
Campus des Cézeaux BP 10125
63173 Aubière Cedex
Openium Développement d’Applications Mobiles
15, Rue Jean Claret Bâtiment « Le XV »
Parc Technologique de la Pardieu 63000 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 2010-2011
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.
Sommaire :
Introduction ................................................................................................... 1
1. Contexte ................................................................................................... 2
1.1. Android ......................................................................................................................... 2
1.1.1. Les Activités (appelées Activities) ................................................................................... 2
1.1.2. Les Services...................................................................................................................... 2
1.1.3. Les Broadcast et Intent receivers .................................................................................... 2
1.1.4. Les Content providers ..................................................................................................... 3
1.1.5. Le cycle de vie d’une application ..................................................................................... 3
1.2. Les outils utilisés ............................................................................................................ 4
1.2.1. Eclipse .............................................................................................................................. 4
1.2.2. Dropbox ........................................................................................................................... 5
2. Description du projet ................................................................................ 6
2.1. Choix du projet .............................................................................................................. 6
2.2. L’application StatusManager .......................................................................................... 6
2.2.1. Objectif ............................................................................................................................ 6
2.2.2. Description générale ....................................................................................................... 7
Onglet Aperçu ................................................................................................................................. 7
Onglet Agenda ................................................................................................................................. 7
Onglet Exceptions ........................................................................................................................... 8
2.3. Gestion du projet ........................................................................................................... 9
3. Le développement de l’application ......................................................... 10
3.1. Les applications de tests ............................................................................................... 10
3.1.1. Planification d'évènements ........................................................................................... 10
3.1.2. Création de graphiques à partir de données extraites dynamiquement ...................... 10
3.2. Conception de la base de données................................................................................ 11
3.3 Architecture de l’application ........................................................................................ 11
3.3.1. Spécificités d'Android .......................................................................................................... 11
3.3.2. Organisation du code .......................................................................................................... 12
3.4. Bilan ............................................................................................................................ 13
Conclusion .................................................................................................... 15
Annexes
Sitographie
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
1
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.
2
1. Contexte
1.1. Android
Android est un système d’exploitation Open Source pour smartphones, PDA et
terminaux mobiles, sorti en novembre 2007. 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.
1.1.1. 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.
1.1.2. 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.
1.1.3. 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 inter-
applications.
3
1.1.4. 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.
1.1.5. 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
4
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é.
1.2. Les outils utilisés
1.2.1. 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
5
1.2.2. 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
6
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.
2.2. L’application StatusManager
2.2.1. 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
7
date, par exemple pour un rendez-vous, afin que le téléphone adapte automatiquement son
mode.
2.2.2. 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).
Figure 2.1 : Capture d'écran de l'onglet "Aperçu"
Onglet Agenda
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).
8
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"
9
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.
10
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.
3.1.1. 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.
3.1.2. 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.
11
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
3.3.1. 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
12
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.
3.3.2. 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
13
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.
3.4. 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.
14
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.
15
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.
Annexes
Annexe I : Schéma UML
Annexe II : Base de données
Sitographie
1. ANDROID – Android. < http://www.android.com/>
2. THE ECLIPSE FOUNDATION – Eclipse. <http://www.eclipse.org/>
3. DEVELOPPEZ.COM – Introduction à la programmation sous Android.
<http://nbenbourahla.developpez.com/tutoriels/android/introduction-programmation-
android/>
4. MIXIMUM – Android : découvrir les concepts de base.
<http://www.miximum.fr/tutos/625-android-decouvrir-les-concepts-de-base>
5. WIKIPEDIA – Dropbox. <http://fr.wikipedia.org/wiki/Dropbox>
6. TUTOS ANDROID – Les services sous Android. <http://www.tutos-
android.com/service-android>
7. BLOG OXIANE – Créer une base sqlite dans Android.
<http://blog.oxiane.com/2010/03/23/creer-une-base-sqlite-dans-android/>
8. ANDROID POUR LES NULS – Tutoriel : Installation de l’environnement de
développement Eclipse - Android. <http://www.android-pour-les-
nuls.fr/tutoriaux/developpement/307-tutoriel-installation-de-lenvironnement-de-
developpement-eclipse-android>
9. MySQL–MySQL Workbench 5.2. <http://www.mysql.fr/products/workbench/>
10. XEBIA– Comment intégrer des graphiques dans une application Android.
<http://blog.xebia.fr/2010/10/21/comment-integrer-des-graphiques-dans-une-application-
android/>
11. ACHARTENGINE– AChartEngine. <http://www.achartengine.org/>
