Rapport

Document Sample
Rapport Powered By Docstoc
					                                 LPD2I 2010-2011 IUT DE RODEZ




    Etude du système Android
           de Google
         Réalisation d’applications pour « mobiles »
                                       (Java, 2D et simulation)
                                             08/03/2011




                                                                      Maxime RODRIGUES

                                                                          Maxime RIVIERE

                                                                          Sylvain PICARLE

                                                                          Mélanie MARC




Développement d’un Labyrinthe et d’un logiciel de gestion de matériels.
            Etude du système Android de Google :                                                     IUT de Rodez
            Réalisation d’applications pour « mobiles »

Remerciements

        Nous tenons à remercier Mr Barrios pour le soutien, les conseils, et les pistes qu’il nous a fourni
pour le bon déroulement de ce projet et la rédaction de ce dossier.




 Licence Professionnelle Systèmes Informatiques et Logiciels                                       Page 1
2010-2011
                  Etude du système Android de Google :                                                                                                IUT de Rodez
                  Réalisation d’applications pour « mobiles »

Table des matières

Introduction. ................................................................................................................................................. 4


1.     Découverte d’Android. ......................................................................................................................... 5
     1.1.      Présentation générale d’Android. ................................................................................................ 5
     1.2.      Un système basé sur le noyau Linux............................................................................................. 6
     1.3.      La Dalvik Virtual Machine, une surcouche du noyau Linux. ......................................................... 7
     1.4.      Les possibilités de la DVM et de l’environnement Java. ............................................................ 10
     1.5.      Le cycle de vie d’une application Android. ................................................................................. 17
     1.6.      Des outils de développement d’applications Android. .............................................................. 20


2.     Application du Labyrinthe à bille. ....................................................................................................... 23
     2.1.      Présentation des besoins............................................................................................................ 23
       2.1.1.         Spécification globale. .......................................................................................................... 23
       2.1.2.         Spécification détaillée de la première itération. ................................................................ 23
       2.1.3.         Spécification détaillée de la seconde itération. ................................................................. 24
     2.2.      Analyse / Conception de l’application. ....................................................................................... 24
       2.2.1.         Diagramme des cas d’utilisation......................................................................................... 24
       2.2.2.         Diagramme d’objets de base de l’application. ................................................................... 27
       2.2.3.         Diagramme des classes. ...................................................................................................... 28
     2.3.      Difficultés rencontrées et leurs solutions................................................................................... 29
       2.3.1.         Gestion de l’affichage des composants par rapport au matériel. ...................................... 29
       2.3.2.         Gestion des mouvements. .................................................................................................. 29
     2.4.      Synthèse sur l’application........................................................................................................... 30


3.     Application de gestion de Matériels................................................................................................... 31
     3.1.      Présentation des besoins............................................................................................................ 31
       3.1.1.         Spécification globale. .......................................................................................................... 31
       3.1.2.         Spécification détaillée de la première itération. ................................................................ 31
       3.1.3.         Spécification détaillée de la seconde itération. ................................................................. 32
     3.2.      Analyse / Conception de l’application. ....................................................................................... 33
       3.2.1.         Diagramme des cas d’utilisation......................................................................................... 33
       3.2.2.         Diagramme d’objets de base de l’application. ................................................................... 36
       3.2.3.         Diagramme des classes. ...................................................................................................... 37
     3.3.      Difficultés rencontrées et leurs solutions................................................................................... 38


 Licence Professionnelle Systèmes Informatiques et Logiciels                                                                                        Page 2
2010-2011
                    Etude du système Android de Google :                                                                                                IUT de Rodez
                    Réalisation d’applications pour « mobiles »

          3.3.1.         Gestion des enchainements d’activités. ............................................................................. 38
          3.3.2.         Affichage d’une liste composée (liste des équipements). .................................................. 38
          3.3.3.         Affichage récursif de l’ensemble des espaces et sous espaces. ......................................... 38
     3.4.        Synthèse sur l’application........................................................................................................... 39


4.        Synthèses ............................................................................................................................................ 40
     4.1.        Synthèse personnelle de Maxime Riviere. ................................................................................. 40
     4.2.        Synthèse personnelle de Maxime Rodrigues. ............................................................................ 41
     4.3.        Synthèse personnelle de Mélanie Marc. .................................................................................... 42
     4.4.        Synthèse personnelle de Sylvain Picarle. ................................................................................... 43


Conclusion sur Android. ............................................................................................................................. 44



Annexes. ..................................................................................................................................................... 45


     1.      Gestion de projet. ........................................................................................................................... 45
          1.1.       Définition des rôles. ................................................................................................................ 45
          1.2.       Planification initiale. ............................................................................................................... 46


     2.      Photos des applications. ................................................................................................................. 47
          2.1.       Application du Labyrinthe à bille ............................................................................................ 47
          2.2.       Application de gestion de matériels ....................................................................................... 47


     3.      Manuel d’utilisation des applications pour la gestion de matériels. ............................................. 48
          3.1.       Manuel d’utilisation de l’application PC. ................................................................................ 48
          3.2.       Manuel d’utilisation de l’application Android. ....................................................................... 49




 Licence Professionnelle Systèmes Informatiques et Logiciels                                                                                          Page 3
2010-2011
            Etude du système Android de Google :                                                   IUT de Rodez
            Réalisation d’applications pour « mobiles »

Introduction.

        Dans le cadre de la licence, un projet était à choisir de manière à pouvoir mettre en œuvre nos
compétences et les technologies étudiées dans le cadre d’un travail en équipe mais aussi d’en assimiler
de nouvelles. Notre choix s’est orienté sur un projet portant sur la découverte du système Android de
Google. La première partie du projet consiste à développer un jeu du labyrinthe à bille, la bille évoluant
grâce aux mouvements du téléphone qui est équipé d’un accéléromètre. La seconde partie, est une
application de gestion de matériels des bâtiments d’une organisation quelconque, celle-ci utilisera le
GPS équipant le téléphone, pour localiser les bâtiments.

        L’objectif principal de ce projet est certes de réaliser les deux applications mais surtout de
découvrir Android et son environnement de travail. A la fin de ce projet nous devrions être capables
d’apporter un point de vue critique sur certains aspects du système afin de pouvoir mettre en évidence
les qualités et les défauts de celui-ci.

       L’équipe de recherche et développement de ce projet est composée de 4 membres : Maxime
Rodrigues, Maxime Riviere, Sylvain Picarle et Mélanie Marc.

        Nous avons choisi ce sujet, dans le but de découvrir une nouvelle manière de développer une
application. En effet, développer une application pour ordinateur ou pour téléphone est différent,
surtout en termes de capacités mémoires. De plus, nous étions attirés par ce nouveau système
d’exploitation de plus en plus présent sur les téléphones portables, les tablettes tactiles...

        Pour cela, nous allons exposer les découvertes que nous avons faites sur Android, en
commençant par une présentation générale, puis en détaillant son fonctionnement, ses
caractéristiques, ses limites, et les outils de développement.
        Ensuite, nous allons vous détailler l’avancement des travaux pour chacun des sujets. Nous
présenterons une spécification globale des besoins, puis une pour chaque itération. Enfin nous
présenterons l’analyse et la conception de la solution suivis des difficultés rencontrées et enfin une
synthèse critique concernant l’application.
        Enfin, nous mettons à disposition des éléments de gestion de projet, et autres annexes.




 Licence Professionnelle Systèmes Informatiques et Logiciels                                     Page 4
2010-2011
            Etude du système Android de Google :                                                   IUT de Rodez
            Réalisation d’applications pour « mobiles »

1. Découverte d’Android.

    1.1. Présentation générale d’Android.

        Android est un système d’exploitation open source dont le développement a été commencé par
la société Android appartenant aujourd’hui à Google. En Juillet 2005, la société Google Inc. achète
Android, une petite startup implantée à Palo Alto en Californie. A ce moment, les fonctions de la société
Android sont peu connues en dehors du développement de logiciels pour téléphones portables. Google
a donc racheté cette société dans le but de se faire une place dans le monde des Smartphones. Les
développeurs commencent donc par créer un système d’exploitation pour mobiles basé sur un noyau
Linux. En novembre 2007, Google annonce officiellement la sortie de la plateforme Android. Aujourd’hui
les nouveaux appareils mobiles permettent de faire fonctionner ce système d’exploitation qui a été
conçu pour faciliter les accès réseaux et le partage de données sur Internet.

       Mais, bien entendu, ce système d’exploitation n’est pas le seul sur le marché. Il doit faire face à
de multiples concurrents tels que Microsoft, Apple, Blackberry, Nokia … . En effet toutes ces sociétés ont
créées leur propre système d’exploitation mais à terme il ne restera que très peu d’entre eux.
L’écrémage a d’ailleurs d’ores et déjà commencé puisque 3 systèmes se démarquent actuellement
(Symbian ne compte plus parmi ceux-ci étant donné qu’ils ont passé un accord avec Microsoft) :
            - iOs d’Apple.
            - Windows Phone 7 de Microsoft.
            - Android de Google.

        Android est basé sur un noyau linux au-dessus duquel se trouve une Machine Virtuelle (la Dalvik
Virtual Machine). Cette Machine Virtuelle développée par Google permet le développement
d’applications en langage Java. Un SDK (open-source et gratuit) basé sur un environnement Java est mis
à disposition des développeurs afin de leur permettre de réaliser des applications. Les possibilités sont
bien sûr plus limitées que sur un PC dernière génération, tant à cause des limites matérielles (fréquence
de calcul du processeur, capacités mémoires, capacités graphiques, …), que par les limites imposées par
la DVM qui se veut plus légère qu’une machine virtuelle telle que la Java Virtual Machine. Néanmoins,
un tel matériel nous donne des possibilités qui sont peu ou pas envisageables sur un PC fixe (comme la
fonction d’accéléromètre ou la géolocalisation).

        Aujourd’hui, le système Android n’est plus seulement présent sur des téléphones mobiles, il est
depuis la version 3.0 disponible sur des tablettes tactiles. Celles-ci permettent d’utiliser les
fonctionnalités du système de manière optimale. En effet, l’écran et les capacités étant plus importants
que sur des téléphones, il devient possible de développer des applications plus ergonomiques.

        Notre objectif est donc de travailler sur ce système et d’en découvrir les possibilités au travers
de différentes applications. Pour pouvoir comprendre le fonctionnement des applications sous Android
nous avons dû étudier différentes composantes de cet environnement.




 Licence Professionnelle Systèmes Informatiques et Logiciels                                     Page 5
2010-2011
            Etude du système Android de Google :                                                 IUT de Rodez
            Réalisation d’applications pour « mobiles »

    1.2. Un système basé sur le noyau Linux.

      Android est donc un système d’exploitation qui est basé sur un noyau linux monolithique. Le choix
d’un noyau monolithique est tout à fait logique étant donné que les performances de ceux-ci sont
supérieures à celles d’un noyau de type micronoyau et que ces performances sont recherchées sur des
matériels dont la puissance est limitée. Elles sont supérieures car la structure de micronoyau vise à
externaliser les fonctionnalités indépendantes du noyau ce qui permet d’avoir une plus grande sécurité.
      Mais cette sécurité a un prix, en effet la communication devient plus complexe et nécessite la
mise en place de mécanismes qui sont très lourds et dont les performances sont limitées.

Voici l’architecture du système d’exploitation Android :




        Le noyau linux est utilisé principalement pour gérer la sécurité, la mémoire, les processus, les
pilotes pour les matériels tels que le WiFi, le tactile, le son, …

       Mais ce noyau sert aussi de couche d’abstraction supplémentaire entre le matériel et la couche
supérieure du système d’exploitation.

        Il est le support qui permet de faire fonctionner la Dalvik Virtual Machine.




 Licence Professionnelle Systèmes Informatiques et Logiciels                                   Page 6
2010-2011
            Etude du système Android de Google :                                                   IUT de Rodez
            Réalisation d’applications pour « mobiles »

    1.3. La Dalvik Virtual Machine, une surcouche du noyau Linux.

         La DVM est donc la machine virtuelle qui est intégrée au système Android. Un des objectifs
d’une machine virtuelle applicative est de dissimuler, aux applications exécutées sur celle-ci, les
spécificités du support matériel (architecture matérielle) et logiciel (système d’exploitation). Tout ceci
dans un souci de portabilité. Ainsi une application n’est plus dépendante d’un environnement logiciel ou
matériel et les concepteurs n’ont pas à se soucier de la portabilité de leur application.
Comme dit précédemment la DVM et la JVM répondent toutes deux à ces besoins. Mais quelles sont les
différences ?

        Tout d’abord lors de la compilation pour exécution sur une DVM certaines classes seront
regroupées afin de former un seul fichier .dex qui contiendra le byte code de toutes ces classes. Les
principales différences entre un .dex et plusieurs .class (byte code générés pour une exécution sur la
JVM), générés par le regroupement des classes, sont les suivantes :
         Regroupement des constantes. (Suppression des doublons)
         Regroupement des instructions et des appels de méthodes
         …

       Voici un schéma de comparaison de la répartition des données lors de la compilation (le
regroupement dans un fichier .jar n’est pas nécessaire pour la transformation en fichier .dex) :




 Licence Professionnelle Systèmes Informatiques et Logiciels                                     Page 7
2010-2011
            Etude du système Android de Google :                                                      IUT de Rodez
            Réalisation d’applications pour « mobiles »

         Comme on peut l’imaginer ce regroupement de classes en un seul fichier permet d’alléger
considérablement le poids du byte code. Par conséquent, les fichiers exécutables seront eux aussi
allégés. Si le poids d’une application n’est plus un facteur important sur un PC, il l’est pour des matériels
moins puissants tels que les tablettes et les téléphones mobiles. Ci-dessous, un exemple de comparaison
de taille d’un projet montre clairement que le gain d’espace est réparti uniformément sur les différents
contenus de l’application.




        Une autre des différences est que la DVM a été allégée afin d’augmenter la rapidité de celle-ci et
surtout de diminuer la consommation de ressources.

        Enfin la principale différence est que la DVM est de type Register Based alors que la JVM est de
type Stack Based. Voici le principal avantage de la DVM :

        La DVM est susceptible d’être plus performante si le processeur contient un pipeline qui est une
architecture de séquencement permettant de traiter les instructions de façon parallèle. Dans un pipeline
à 5 étages une instruction, nécessite 5 étapes pour être exécutée complètement :
            - IF (Instruction Fetch) chargement de l'instruction à exécuter.
            - ID (Instruction Decode) décoder l'instruction et adresser les registres.
            - EX (Execute) exécution de l’instruction.
            - MEM (Memory) enregistrement d’un registre vers la mémoire ou inversement.
            - WB (Write Back) stockage du résultat dans un registre.
        Chaque étape nécessite un cycle (un cycle se déclenche à chaque impulsion d’horloge), donc
pour exécuter 5 instructions il faudra 25 cycles si le processeur ne possède pas de pipeline.
Maintenant en supposant que celui-ci en ait un simple à 5 étages, il faudra alors 9 cycles pour exécuter
complètement ces 5 instructions mais chaque instruction sera exécuté en a 5 cycles.

        Voici un schéma présentant le phénomène de séquencement :




         La vérification du byte code est normalement plus rapide que sur une VM de type Stack Based
car la vérification d’intégrité de la pile est simplifiée.



 Licence Professionnelle Systèmes Informatiques et Logiciels                                        Page 8
2010-2011
            Etude du système Android de Google :                                                   IUT de Rodez
            Réalisation d’applications pour « mobiles »

        Il faut toutefois noter que les programmes exécutables ne sont pas compilés en Java byte code,
mais en Dalvik byte code. Un bémol sur ce point, car la compilation passe par une étape intermédiaire
dans laquelle du Java byte code est généré avant d’être converti en Dalvik byte code.

        La technologie permettant d’obtenir le Java byte code est soumise à un brevet appartenant
désormais à la société Oracle, qui a porté plainte contre Google pour violation de brevet. Le résultat du
procès, même s’il ne changera probablement pas la fonctionnement de la plateforme Android, pourrais
obliger Google à revoir certaines parties du code (notamment du compilateur) s’il s’avérait qu’il y a bien
eu violation de brevet.




 Licence Professionnelle Systèmes Informatiques et Logiciels                                     Page 9
2010-2011
             Etude du système Android de Google :                                                IUT de Rodez
             Réalisation d’applications pour « mobiles »

    1.4. Les possibilités de la DVM et de l’environnement Java.

       Nous avons vu que la DVM s’inspire de la JVM de manière à permettre le fonctionnement sur
des matériels moyennement puissants. Afin de pouvoir s’exécuter, l’environnement doit seulement
disposer de 64Mb de mémoire et d’un processeur de 250 Mhz.

       A partir de la version 2.2 d’Android, la DVM dispose d’un JIT Compiler (Just-In-Time Compilation)
qui permet d’optimiser les programmes et accroître leur rapidité (2 à 5 fois plus rapide).


JIT Compiler

       La Just-In-Time Compilation ou JIT Compilation est une technique visant à améliorer la
performance de systèmes byte code-compilés par la traduction de byte code en code machine natif au
moment de l'exécution. La compilation à la volée se base sur deux anciennes idées : la compilation de
byte code et la compilation dynamique.


Les librairies

       Les librairies natives sont implémentées en C/C++ et sont utilisées par les différents composants
d’Android. Ces librairies et leurs possibilités sont utilisées via les applications Framework.




        L’ensemble de ces librairies permet de gérer :
            - Affichage                                       - Police Bitmap Vectoriel
            - Audio / Vidéo                                   - Cryptage SSL
            - Bases de données                                - Navigateur Web
            - Graphisme 2D/3D                                 - Librairies de base

        Les librairies de base sont un sous ensemble de J2SE 5.0, plateforme de Sun destinée aux
appareils mobiles.


Le Framework

        Le gestionnaire des applications fournit un ensemble d’outils permettant de développer une
application sur la plateforme Android. Le Framework est le point d’entrée de toutes applications, il
permet l’accès à toutes les ressources de niveau inférieur via la librairie. On peut aussi directement
accéder aux ressources en langage C via JNI (Java Native Interface).




Licence Professionnelle Systèmes Informatiques et Logiciels                                    Page 10
2010-2011
              Etude du système Android de Google :                                                IUT de Rodez
              Réalisation d’applications pour « mobiles »



              -   Activity Manager : Gestion du cycle de vie des activités Android.
              -   Window Manager : Gestionnaire de fenêtres utilisé pour l’affichage.
              -   Content Providers : Permet de stocker et d’accéder aux données.
              -   View Système : Gère les composants de l’interface graphique(Views) et les intéractions
                  avec l’utilisateur.
              -   Package Manager :         Permet d’accéder à des informations concernant les paquetages
                  installés sur le terminal Android.
              -   Téléphonie Manager : Permet d’accéder aux fonctionnalités de communication du
                  terminal.
              -   Location Manager : Permet aux applications d’obtenir des informations de localisation
                  fournies par le terminal (GPS).
              -   Notification Manager : Permet de notifier les utilisateurs.
              -   Ressource Manager : Permet d’accéder aux ressources des différents paquetages.

Activité

        Une activité est généralement le point d’entrée d’une application, elle possède un cycle de vie
qui sera détaillé par la suite.

           Modèle de définition d’une activité complète :
 package activite.test;

 import android.app.Activity;
 import android.os.Bundle;

 /**
  * Une activité est la partie visible par l'utilisateur dans une application
 Android.
  * Une application pouvant être un ensemble d'activités s'appelant entre elles.
  * @author groupe de projet Android      LPD2I 2010-2011
  */
 public class Activite extends Activity {

       /**
         * Appelée en premier lorsque l'activité est créée.
         * Elle permet d'initialiser l'ensemble des propriétés utiles à l'activité.
         * Ici l'activité n'est pas visible par l'utilisateur.
         * Suivi de la fonction onStart().
         */
       @Override
       public void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            setContentView(R.layout.main);
       }
       /**
         * Appelée automatiquement après onCreate().
         * Lorsque l'activité devient visible par l'utilisateur.
         * Suivi de onResume() si on veut l'exécuter au premier plan
         * ou onStop() si on veut continuer à l'exécuter en arrière plan (non
         * visible).
         */
       @Override
       protected void onStart() {
          super.onStart();
       }




Licence Professionnelle Systèmes Informatiques et Logiciels                                     Page 11
2010-2011
            Etude du système Android de Google :                                IUT de Rodez
            Réalisation d’applications pour « mobiles »


         /**
           * Appelée automatiquement après la fonction onStop().
           * Suivi de la fonction onStart().
           */
         @Override
         protected void onRestart() {
            super.onRestart();
         }

         /**
           * Appelée lorsque l'activité devient interactive avec l'utilisateur
           * - lorsqu'on revient d'un état de pause.
           * - lorsqu'une sous activité rend la "main" à celle-ci.
           * A ce moment l'activité est placée en haut de la pile d'activités.
           * Suivi de la fonction onPause().
           */
         @Override
         protected void onResume() {
            super.onResume();
         }

         /**
          * Appelée lorsqu'on quitte l'activité sans l'arrêter
          * par exemple lorsqu'on appuie sur le bouton retour du téléphone.
          * Elle est beaucoup utilisée pour effectuer des sauvegardes
          * mais aussi avant de lancer une autre activité.
          * Suivi de onResume() si on veut l'exécuter au premier plan
          * ou onStop() si on veut continuer à l'exécuter en arrière plan (non
          * visible).
          */
         @Override
         protected void onPause() {
           super.onPause();
     }

         /**
           * Appelée lorsque l'activité n'est plus visible par l'utilisateur
           * car l'activité est cachée par une autre.
           * Suivi de onRestart() si on veut l'exécuter au premier plan
           * ou onDestroy() si l'activité est fermée
           */
         @Override
         protected void onStop() {
            super.onStop();
         }

         /**
           * Appelée lorsque l'activité est fermée via la fonction finish()
           * ou bien lorsque le système choisi de forcer la fermeture de
           * l'application.
           * Apres l'exécution de cette fonction, le processus de l'activité sera
           * tuée.
           */
         @Override
         protected void onDestroy() {
            super.onDestroy();
         }
 }




Licence Professionnelle Systèmes Informatiques et Logiciels                    Page 12
2010-2011
               Etude du système Android de Google :                                                   IUT de Rodez
               Réalisation d’applications pour « mobiles »

Les Intents

        Les intents offrent un système de communication performant permettant de faire passer des
informations entre activités ou plus généralement entre composants applicatifs. Les intentions sont des
appels système qui permettent aussi de remonter les événements de modification matériels et même
les lancements d’une activité.

       Un intent est composé de deux éléments principaux : l’action à effectuer (ACTION_VIEW,
ACTION_EDIT, ACTION_MAIN) et les données sur lesquelles l’action doit être effectuée, généralement
représentée par une URI. De plus un intent peut posséder des attributs secondaires : catégorie, type,
composant, extras.

       La figure suivante représente une utilisation de l’intent et l’intent-filter :




       Par exemple, dans le labyrinthe à bille, on va utiliser une intention pour passer de la liste des
parcours au jeu. Elle servira également à faire passer le numéro du parcours choisi.

       Dans l’activité présentant la liste des parcours, on lancera le jeu de la manière suivante :
  // création de l'intention permettant de passer à l'activité jeu
  Intent intention = new Intent(this,JeuLabyrinthe.class);

  // création de l'objet contenant les propriétés à transmettre au jeu
  Bundle parametres = new Bundle();
  // on passe le numéro du parcours choisi
  parametres.putInt("numParcours", position);
  intention.putExtras(parametres);

  // lancement de la sous activité
  startActivity(intention);



       On récupérera les propriétés transmises dans la fonction onCreate() de l’activité JeuLabyrinthe :
   // récupération de l’indice du parcours choisi
   Bundle recuperationParametres = this.getIntent().getExtras();
   int indiceParcours = recuperationParametres.getInt("numParcours");




Les services

         Un service Android est destiné au processus de longue durée. Il peut s’exécuter séparé de toutes
activités. Sa création se fait via l’API ou avec une connexion via IPC. Son implémentation partage de
nombreuses caractéristiques avec une activité notamment son cycle de vie. L’exécution du service
perdure jusqu'à ce qu’il ne soit plus utilisé ou que le système ait besoin de récupérer de l’espace
mémoire, le problème est qu’un service représente un coût au niveau de la consommation CPU, il est
donc nécessaire de faire attention à son utilisation.




Licence Professionnelle Systèmes Informatiques et Logiciels                                       Page 13
2010-2011
            Etude du système Android de Google :                                                     IUT de Rodez
            Réalisation d’applications pour « mobiles »

BroadCast

        Le récepteur broadcast a pour principal rôle de recevoir des messages généralement de nature
inter-composants, mais ils peuvent aussi provenir du système lui-même (batterie faible). Il est possible
de définir un broadcast receiver par application afin d’être alerté par le gestionnaire de notifications.


Les applications

        Android met à disposition des applications développées par Google (Gmap , Gmail ,…) qui seront
placées dans la couche Applications.




        Les applications développées, permettent l’utilisation de toutes les possibilités : stockages,
réseaux, multimédia, GPS, Services des terminaux sous Android. Il faut aussi savoir, à titre d’information,
que Google a développé un environnement de création d’application Android AppInventor qui permet
sans écrire une seule ligne de code de développer de simples applications (lecture d’un son, mise en
place de lien). Ce logiciel parait limité (comme la plupart des RAD), mais doit être étudié pour savoir s’il
est possible de créer des applications à complexité variable.


Le langage JAVA

        La DVM prend en charge une bonne partie des packages fournis par Java tels que java.lang,
java.io,… Mais cette prise en charge est tout de même restreinte. A partir de nos recherches nous avons
pu déterminer quels packages étaient implantés.

        Le premier niveau peut être comparé à JSE sous sa forme :



              Dalvik.*                      java.* javax.*                org.apache.http.*




        Nous allons voir les différents packages qui sont entièrement et partiellement supportés par
l’environnement Android.




Licence Professionnelle Systèmes Informatiques et Logiciels                                       Page 14
2010-2011
            Etude du système Android de Google :                                                   IUT de Rodez
            Réalisation d’applications pour « mobiles »




       L’environnement Java d’Android est composé de 3200 classes et l’API est elle-même constituée
de 1900 classes. Ces chiffres montrent parfaitement les limitations du langage et du système comparé
aux 7000 classes de l’API de la JDK 1.6 de Sun.


Possibilité Graphique

      L’environnement Android dispose de deux grandes API : SGL et OpenGL qui ont été adaptées
pour développer des applications sur terminaux mobiles. Les paquets graphiques 2D les plus
couramment utilisés se trouvent dans android.graphics.*.

        SGL (Scalable Graphics Library) est une librairie 2D codée en natif dans la DVM. Elle est utilisée
par les couches supérieures afin de définir et réaliser des interfaces graphiques en deux dimensions.
C’est une bibliothèque de bas niveau qui gère le rendu de textes, formes géométriques et images, elle
est compatible avec les normes existantes en 2D et prend en charge divers formats comme SVG, PDF, et
OpenVG.

        OpenGL ES (Embedded Systems) est une API 3D basée sur OpenGL, optimisée pour les appareils
mobiles. Elle active l’implémentation logicielle et matérielle avec un faible encombrement, c’est une
plate-forme qui utilise les points fixes. Elle est accessible à partir des packages
javax.microedition.khronos.*.
        Il existe 3 versions de cette API : OpenGL ES 1.0 la moins coûteuse niveau matériel, OpenGL ES
1.1 qui utilise des accélérateurs graphiques et OpenGL ES 2.0 utilisable sur les produits haut de gamme
en vue des ressources demandées.




Licence Professionnelle Systèmes Informatiques et Logiciels                                      Page 15
2010-2011
            Etude du système Android de Google :                                                        IUT de Rodez
            Réalisation d’applications pour « mobiles »

         Tous les éléments graphiques ci-dessous sont des widgets qui doivent répondre à une sélection
tactile (par le doigt ou le stylet), c’est pour cela qu’ils sont bien plus gros que les widgets disponibles sur
PC.




Licence Professionnelle Systèmes Informatiques et Logiciels                                           Page 16
2010-2011
            Etude du système Android de Google :                                                   IUT de Rodez
            Réalisation d’applications pour « mobiles »

    1.5. Le cycle de vie d’une application Android.

        Sur Android une application (aussi appelée activité) possède un cycle de vie bien spécifique alors
qu’une application Java sur JVM n’en a pas, pour la raison qu’un ordinateur permet la gestion multi
fenêtrés et concurrentielle des applications : deux applications peuvent être en cours d’exécution totale
simultanément, ce qui n’est pas possible sur un écran de téléphone pour des raisons d’économie de
ressources. Voici un schéma présentant les différentes étapes du cycle de vie d’une application Android.




Licence Professionnelle Systèmes Informatiques et Logiciels                                      Page 17
2010-2011
            Etude du système Android de Google :                                                      IUT de Rodez
            Réalisation d’applications pour « mobiles »

La pile d’activité

         Lorsqu’une activité est lancée elle est placée en tête de la pile d’activités. Son cycle de vie
commence à ce moment et se termine lorsque le système la supprime de cette pile. La pile d’activités va
empiler les applications une fois exécutées, la première application (A1) se retrouvera en bas de la pile si
une nouvelle application (A2) est lancée. Cette nouvelle application (A2) placée en tête de pile sera celle
visible par l’utilisateur, l’application (A1) quant à elle se retrouvera en état de pause (cf. § Quatre états
principaux).

         Cependant cet enchainement peut être modifié. En effet, une instruction de la classe Intent du
package android.content pourra permettre de faire remonter une application dans la pile d’activités. Il
s’agit d’ajouter un flag à l’Intent de l’activité dans la méthode de lancement de l’activité, de la manière
suivante : Intent.addFlags(Intent.FLAG_ACTIVITY_REORDER_TO_FRONT);


Quatre états principaux :

        Pendant son cycle de vie, l’activité va pouvoir passer essentiellement par quatre états
principaux.

       Le premier état est caractérisé par une activité visible en fond d’écran. L’activité est alors placée
en haut de la pile, on dit qu’elle est « active » ou « running ».

        Le second état se caractérise par la perte de focus de la part de l’activité. Celle-ci est toujours
visible mais elle est dans un état appelé « paused ». A cet instant l’activité est toujours en vie, c’est-à-
dire qu’elle est toujours présente dans la pile. Cependant, le système peut, dans un cas extrême de
manque de mémoire, stopper l’activité.

         Le troisième état se présente lorsqu’une activité se trouve complètement cachée par une autre
activité. L’activité cachée se met alors dans un état « stopped ». Elle garde toujours ses informations.
Cependant, elle est cachée à l’utilisateur et peut aussi être stoppée par le système en cas de manque de
mémoire.

        Enfin, le quatrième et dernier état concerne une activité qui aurait été mise en pause ou
arrêtée. Le système peut alors supprimer l’activité ou simplement tuer le processus, celle-ci sera alors
supprimée de la pile d’activités.

        Ces différents états seront atteints par l’intermédiaire de méthodes prédéfinies. L’utilisation de
ces méthodes se fait dans des périodes d’utilisation précises. Il existe trois boucles principales d’appel
de ces méthodes.


Trois boucles principales :

        The « entire lifetime »

         L’ensemble du cycle de vie d’une application va se dérouler entre les deux appels de méthodes
suivants : onCreate(Bundle) et onDestroy(). La première permet d’initialiser l’ensemble de l’état global
d’une activité et la seconde permet, quant à elle, de libérer les ressources déclarées et initialisées dans
la méthode précédente. C’est lors de l’appel à la première méthode que l’application sera placée en tête
de la pile d’activités, la seconde la supprimera de celle-ci.




Licence Professionnelle Systèmes Informatiques et Logiciels                                        Page 18
2010-2011
            Etude du système Android de Google :                                                        IUT de Rodez
            Réalisation d’applications pour « mobiles »

         The « visible lifetime »

         La partie visible du cycle de vie d’une activité, pour un utilisateur, se passe entre les méthodes
onStart() et onStop(). Entre ces deux méthodes, l’application sera visible par l’utilisateur, cependant,
celui-ci ne pourra pas interagir avec elle. Une troisième méthode onRestart() peut être associée à ces
méthodes. Celle-ci permettra de reprendre l’activité, la refaire passer au premier plan, après l’appel de
onStop(). Pendant cette période (entre onStart() / onRestart() et onStop()), le développeur peut
maintenir les ressources dont il a besoin pour initialiser l’application et ses composants. Ce couple de
fonctions peut être appelé plusieurs fois dans une activité.


         The « foreground lifetime »

          Il s’agit de la partie du cycle de vie d’une activité pendant laquelle elle est au premier plan pour
l’utilisateur. C’est-à-dire qu’elle est visible et qu’il peut interagir avec elle. Cette partie se déroule entre
les deux méthodes onResume() et onPause(). La première méthode, onResume(), est exécutée après
chaque onStart(), à chaque passage de l’activité en premier plan. Elle permet d’initialiser la connexion à
une base de données, si présente, et de mettre à jour des données qui auraient pu être modifiées avant.

          La seconde méthode, onPause(), est exécutée avec chaque onStop(), à chaque fois que
l’utilisateur passe à une autre activité, ou bien si le système à besoin de libérer de la mémoire. Elle
permet de libérer des ressources (sauvegarde des données, déconnexion de la base de données).
L’exécution de cette méthode doit être rapide car la prochaine activité ne démarrera pas tant que
l’exécution de cette méthode n’est pas terminée.

        Une activité peut souvent passer des états de pause à celui de reprise.




Licence Professionnelle Systèmes Informatiques et Logiciels                                           Page 19
2010-2011
              Etude du système Android de Google :                                                  IUT de Rodez
              Réalisation d’applications pour « mobiles »

    1.6. Des outils de développement d’applications Android.

       Pour développer des applications Android plusieurs outils sont mis à disposition des
développeurs afin de faciliter le développement.


Le SDK Android :

        Le SDK Android met à la disposition du développeur, en plus des ressources java liées à la
plateforme Android, une suite d’outils de développement et de débogage.


Emulateur :

        L’environnement Android offre la possibilité de créer des émulateurs de manière très simple
grâce à une interface graphique claire appelable directement sous Eclipse via le plug-in Eclipse fourni
par Google.

        Il offre la possibilité de choisir la version du SDK dans laquelle développer et les API Google que
l’on veut charger afin de s’interfacer avec les web services Google (Google Maps, mail, météo, actu …).

       L’émulateur nous permet de tester des programmes et des configurations sur un appareil virtuel
entièrement paramétrable. Cela évite de posséder un appareil physique pour chaque configuration.
Comment créer un émulateur sous Eclipse ?

Sous Eclipse : Windows -> Android SDK and AVD Manager -> Virtual devices -> new
         Champ name : nom de l’émulateur
         Champ target : version d’Android de l’émulateur
         Valider en cliquant sur Create AVD




Licence Professionnelle Systèmes Informatiques et Logiciels                                       Page 20
2010-2011
            Etude du système Android de Google :                                                   IUT de Rodez
            Réalisation d’applications pour « mobiles »

        Certaines fonctions ne sont pas prises en charge par l’émulateur, parmi elles : la simulation d’un
appel téléphonique, la simulation de capteurs comme l’accéléromètre ou le GPS,…
        Il est néanmoins possible de donner manuellement les valeurs normalement retournées sur un
terminal réel grâce au service telnet.

         Par exemple si on veut simuler une position GPS sur l’émulateur, on utilise le service telnet.
Dans une invite de commande taper « telnet » -> o localhost 5554 -> geo fix [longitude] [latitude]
[altitude]
Exemple : geo fix -122.640155 45.52304

         L’option ‘o’ permet de se connecter à un hôte en précisant son nom et le numéro de port, ici
‘localhost’ sur le port 5554 qui correspond au premier système Android connecté, 5555 pour le second
et ainsi de suite.

        La commande ‘geo fix’ permet de préciser manuellement des coordonnées dans l’ordre
longitude, latitude, altitude, ce dernier étant optionnel.


Android Debug Bridge :

         L’ADB (Android Debug Bridge) permet de communiquer en temps réel avec un système Android
qu’il soit réel (penser à activer le mode débogage USB), ou virtuel afin de récupérer les informations
système, récupérer et modifier les variables d’environnement et installer des programmes.


Principales commandes de l’ADB :

        adb devices : affiche la liste des terminaux Android connectés.

        adb install c:\chemin\fichier.apk : installe ‘fichier.apk’ sur le terminal Android.

        adb push c:\chemin\fichier /sdcard : copie le ficher indiqué par le premier argument sur la
carte SD du terminal.

      adb pull /sdcard/fichier c:\chemin\ : récupère sur le terminal le fichier indiqué par le premier
argument et le copie vers l’ordinateur.

        adb shell : ouvre le Shell du terminal Android, un prompt doit apparaitre.

        adb shell “commande” : exécute la commande dans le Shell du terminal.

       On retrouve les principales commandes d’un Shell linux, parmi elles : cd, cp, rm, mkdir, rmdir, ls,
chmod, cat, …


Eclipse :

        Le plugin ADT fourni par Google nous permet de faire communiquer Eclipse avec le SDK Android
et ses outils. Il donne aussi accès aux classes Java spécifiques à la plateforme Android ainsi qu’à la
documentation correspondante.




Licence Professionnelle Systèmes Informatiques et Logiciels                                      Page 21
2010-2011
           Etude du système Android de Google :                                                   IUT de Rodez
           Réalisation d’applications pour « mobiles »

       L’onglet LogCat permet de visualiser le log d’un terminal en temps réel et donc de pouvoir tracer
une erreur et de voir comment elle est propagée dans la DVM, on peut aussi observer le comportement
du garbage Collector et voir le nombre d’octets libérés à chaque passage.

       Pour afficher LogCat dans Eclipse: Window -> Show View -> Android -> LogCat

        Le plugin permet également d’installer et de lancer l’application sur un système Android par
simple clic sur le bouton run.




Licence Professionnelle Systèmes Informatiques et Logiciels                                    Page 22
2010-2011
            Etude du système Android de Google :                                                      IUT de Rodez
            Réalisation d’applications pour « mobiles »

2. Application du Labyrinthe à bille.

         Le labyrinthe à bille est un jeu dans lequel on fait évoluer une bille à travers un parcours semé
de pièges et d’obstacles. Le but principal du jeu étant d’atteindre le point d’arrivée en évitant les pièges.
Le mouvement de la bille est induit par l’inclinaison du téléphone, en effet, on fait bouger la bille grâce à
l’accéléromètre équipant le téléphone.


    2.1. Présentation des besoins.

        2.1.1. Spécification globale.

         Cette première application a pour objectif la réalisation d’un Labyrinthe à bille en 2D qui devra
être jouable sur un téléphone portable en utilisant l’accéléromètre du téléphone. Le jeu du labyrinthe à
bille consiste à faire déplacer la bille sur le plateau de jeu afin d’atteindre un point d’arrivée, en évitant
les divers pièges (des trous par exemple), à travers divers chemins qui seront représentés grâce à des
parois (la bille pourra s’appuyer sur celles-ci, rebondir si la vitesse d’impact est importante, etc…).

         Un des points principal de l’application est le déplacement de la bille. En effet, il existe une
quantité relativement importante de jeux qui consistent à faire déplacer une bille sur une surface mais
très peu d’entre eux arrivent à rendre le mouvement fidèle à la réalité. C’est pourquoi, le déplacement
de notre bille devra être le plus fidèle possible à la réalité. Pour cela nous devront tenir compte des
divers facteurs tels que la masse de la bille, sa vitesse, son accélération mais aussi la résistance
engendrée par le frottement de celle-ci sur la surface. Les faibles frottements liés à l’air ne seront pas
pris en compte car peu significatifs. Pour donner un mouvement à la bille nous utiliserons
l’accéléromètre qui est un matériel intégré au téléphone. Ainsi, lorsque le joueur penchera le téléphone,
alors un mouvement correspondant à cette inclinaison sera imprimé à la bille. C’est grâce à ce matériel
que le joueur pourra totalement contrôler la bille et ses mouvements.

         Notre application devra également permettre de fournir au joueur un score lorsqu’il aura
terminé le parcours qu’il a choisi. Ce choix est également un aspect important de l’application car il va
permettre au joueur de choisir le parcours sur lequel il veut joueur parmi l’ensemble des parcours
disponibles. Si besoin il pourra trier les parcours par nom ou par niveau de difficultés (3 niveaux de
difficultés seront possibles : Facile, Intermédiaire, Difficile). Eventuellement, par la suite, nous pourrons
offrir la possibilité à des concepteurs de parcours de créer des parcours et de les mettre à disposition
afin que les joueurs puissent les installer et les jouer.

         Une des dernières fonctionnalités, est la possibilité pour l’utilisateur de paramétrer le jeu (dans
une certaine mesure). Il pourra par exemple choisir la gravité de son environnement de jeu parmi une
liste de gravité disponible, il pourra également choisir le type de la méthode de calcul du score parmi
une autre liste qui contiendra toutes celles disponibles.


        2.1.2. Spécification détaillée de la première itération.

        La première itération du développement de l’application devra permettre de fournir un
prototype jouable sur des parcours qui contiendront des éléments simples comme des trous (dans
lesquels la bille tombera) et des parois rectangulaires simples (sur lesquelles la bille pourra s’appuyer
par exemple), le point de départ et le point d’arrivée du parcours. L’objectif du jeu est bien sur inchangé
mais les fonctionnalités seront limitées. Aussi le paramétrage du jeu ne sera pas disponible, tout comme
le calcul du score. Le joueur pourra seulement choisir un parcours parmi deux qui seront définis « en
dur » (les fonctions de tris pour l’affichage, qui sera simpliste, ne seront pas encore implantées). On



Licence Professionnelle Systèmes Informatiques et Logiciels                                         Page 23
2010-2011
            Etude du système Android de Google :                                                     IUT de Rodez
            Réalisation d’applications pour « mobiles »

s’attachera surtout à permettre une visualisation correcte (sans s’attarder pour autant sur les couleurs
et textures) de tous les éléments présents sur le parcours et à rendre le mouvement de la bille le plus
fidèle possible à la réalité.


        2.1.3. Spécification détaillée de la seconde itération.

        Pour cette application il n’y a pas eu de seconde itération étant donné que nous avons pris du
retard pour la gestion du mouvement de la bille. Un seul élément a été rajouté, il s’agit de la définition
des paramètres. Il est possible de modifier les paramètres mais ceux-ci ne sont pas pris en compte.


    2.2. Analyse / Conception de l’application.

        2.2.1. Diagramme des cas d’utilisation.

            2.2.1.1.    Diagramme.




            2.2.1.2.    Les acteurs principaux.

        Le joueur : Il s’agit d’une personne physique qui a la volonté de jouer au jeu du labyrinthe à bille
sur un Smartphone.

       Le concepteur de parcours : Il s’agit d’une personne qui va créer des parcours via une interface
graphique sur PC.


            2.2.1.3.    Description du cas d’utilisation paramétrer le jeu.

Acteur principal : Joueur.

Résumé du cas : Permet au joueur de paramétrer le jeu et diverses composantes comme la méthode de
calcul du score (choix parmi plusieurs), ou la gravité (qui sera bornée) qui s’exerce pendant le jeu, etc.

Evénement déclencheur : La volonté du joueur de modifier les paramètres du jeu.


Licence Professionnelle Systèmes Informatiques et Logiciels                                       Page 24
2010-2011
            Etude du système Android de Google :                                                      IUT de Rodez
            Réalisation d’applications pour « mobiles »


Garanties en cas de succès : Les paramètres du jeu ont été modifiés et ils sont pris en compte
immédiatement. Le joueur pourra le constater lorsqu’il jouera sur un parcours.

Scénario nominal : Après avoir lancé le jeu le joueur a accès aux paramètres du jeu. Il pourra modifier
ses paramètres en fonction des diverses possibilités offertes. Par exemple il pourra modifier la gravité
qui est exercée sur les éléments des parcours en respectant les limites imposées qui sont nécessaires
pour la jouabilité, il pourra modifier la méthode de calcul du score en la choisissant parmi plusieurs
disponibles, etc.


            2.2.1.4.    Description du cas d’utilisation installer des parcours.

Acteur principal : Joueur.

Résumé du cas : Permet au joueur d’installer des parcours sous forme de packs (plusieurs parcours
possibles dans un seul fichier), mis à disposition par des concepteurs de parcours sur Internet.

Evénement déclencheur : Volonté du joueur d’installer d’autres parcours afin d’enrichir l’application.

Garanties en cas de succès : Les parcours disponibles sur l’application seront mis à jour et le joueur
pourra sélectionner ceux qu’il vient d’ajouter. Ceux-ci sont bien sûr sauvegardés et seront toujours
disponibles même après fermeture et réouverture de l’application.

Scénario nominal : Après avoir lancé le jeu, le joueur a la possibilité d’installer des packs de parcours
qu’il aura téléchargés sur son téléphone via Internet. Pour cela il devra sélectionner le pack à installer et
valider son choix. Une fois l’installation terminée les nouveaux parcours qui étaient dans le pack seront
accessibles avec les autres parcours qui étaient déjà présents avant cette installation.


            2.2.1.5.    Description du cas d’utilisation jouer un parcours.

Acteur principal : Joueur.

Résumé du cas : Permet au joueur de sélectionner un parcours et de jouer sur celui-ci.

Evénement déclencheur : Volonté du joueur de jouer sur un parcours qu’il sélectionne.

Garanties en cas de succès : Le joueur aura joué sur le parcours et un score lui aura été attribué en
fonction des différents paramètres qu’il aura définis.

Scénario nominal : Lorsque le joueur a lancé l’application il a la possibilité de choisir un parcours et de le
lancer. Les parcours seront triés soit par nom, soit par difficulté (niveau 1, 2 ou 3). Le joueur doit
sélectionner le parcours à jouer et lancer la partie. Après avoir lancé celui-ci le joueur doit réussir à
atteindre « l’arrivée » du parcours depuis son point de départ en évitant les pièges de celui-ci. Une fois
qu’il a terminé le parcours, le score lui sera affiché. Ce score est calculé en fonction des paramètres que
le joueur aura choisis (par exemple le calcul peut se faire en fonction du temps pour effectuer le
parcours). Le joueur pourra ensuite retourner à la sélection des parcours ou bien faire le parcours
suivant (selon l’ordre de tri choisit précédemment). Une fois que les parcours ont tous été finis, le
joueur est renvoyé sur le choix des parcours.




Licence Professionnelle Systèmes Informatiques et Logiciels                                         Page 25
2010-2011
            Etude du système Android de Google :                                                      IUT de Rodez
            Réalisation d’applications pour « mobiles »

            2.2.1.6.    Description du cas d’utilisation créer des parcours.

Acteur principal : Concepteur de parcours.

Résumé du cas : Permet au concepteur de créer un parcours à l’aide d’une interface graphique sur du
matériel possédant une ergonomie suffisante (PC par exemple…).

Evénement déclencheur : Volonté du concepteur de créer des parcours afin d’enrichir le jeu.

Garanties en cas de succès : Le concepteur aura créé un ou plusieurs parcours et pourra les tester sur
son téléphone ou bien les proposer aux joueurs.

Scénario nominal : Le concepteur lance l’application de création de parcours sur sa machine et définit
les diverses composantes du parcours comme les parois, le revêtement du sol, les points de départ et
d’arrivée de la bille… Une fois le parcours correctement paramétré le concepteur peut l’ajouter à la liste
des autres parcours qu’il souhaite publier sur Internet dans un même pack. Pour que la publication soit
effective il doit générer le fichier à publier et l’envoyer sur un site Internet qui regroupe tous les packs.
Le concepteur peut également placer son pack où il le souhaite sur sa machine afin de le copier sur son
téléphone s’il le désire.




Licence Professionnelle Systèmes Informatiques et Logiciels                                        Page 26
2010-2011
            Etude du système Android de Google :                                                   IUT de Rodez
            Réalisation d’applications pour « mobiles »

        2.2.2. Diagramme d’objets de base de l’application.

         Ceci est un exemple de diagramme d’objets qui pourrait être généré lors de l’utilisation de
l’application :




Licence Professionnelle Systèmes Informatiques et Logiciels                                      Page 27
2010-2011
           Etude du système Android de Google :                IUT de Rodez
           Réalisation d’applications pour « mobiles »

       2.2.3. Diagramme des classes.




Licence Professionnelle Systèmes Informatiques et Logiciels   Page 28
2010-2011
            Etude du système Android de Google :                                                      IUT de Rodez
            Réalisation d’applications pour « mobiles »

    2.3. Difficultés rencontrées et leurs solutions.

        2.3.1. Gestion de l’affichage des composants par rapport au matériel.

        Du fait des diverses configurations matérielles pouvant accueillir le système Android, nous avons
choisi d’utiliser des pourcentages pour dessiner les divers éléments graphiques tels que la bille, les
pièges, les parois... Afin de respecter la proportionnalité de ces éléments nous calculons un coefficient à
partir de la résolution physique de l’écran, au lancement de l’application. De cette manière l’application
sera adaptable à n’importe quelle taille d’écran.


        2.3.2. Gestion des mouvements.

          Une fois le terrain dessiné, le plus dur fut de gérer le déplacement de la bille et ses interactions
avec les autres éléments. Nous avons choisi d’utiliser l’intégration de Verlet pour gérer le déplacement
de la bille dans le labyrinthe, cette méthode prend en compte la vitesse et l’accélération instantanée de
la bille ainsi que les frottements entre la bille et le revêtement sur lequel elle se déplace.

         L’inconvénient majeur de ce système est qu’il ne prend pas en compte l’énergie potentielle
emmagasinée par la bille lors de son déplacement, ce qui se traduit par des variations de vitesse non
réalistes.

       Enfin, il nous a été impossible de gérer les rebonds correctement sans perturber l’algorithme de
déplacement de la bille s’appuyant sur l’intégration de Verlet.




Licence Professionnelle Systèmes Informatiques et Logiciels                                         Page 29
2010-2011
            Etude du système Android de Google :                                                   IUT de Rodez
            Réalisation d’applications pour « mobiles »

    2.4. Synthèse sur l’application.

        L’application labyrinthe permet de simuler le déplacement d’une bille dans un labyrinthe d’un
point de départ vers un point d’arrivée. L’objectif de cette application étant de reproduire le plus
fidèlement possible le comportement d’un jeu de labyrinthe traditionnel composé d’un plateau en bois
et d’une bille métallique.

        Au lancement du projet, nous prévoyions que l’application puisse restituer un comportement
réaliste en gérant les rebonds et l’inertie de la bille. Nous prévoyions également une interface
permettant de modifier les paramètres de jeu tels que la masse de la bille, la gravité appliquée sur le
parcours et le coefficient de frottement entre la bille et le revêtement du labyrinthe. Il était également
prévu l’affichage d’un score représentant le temps mis pour finir le parcours.

         La date buttoir approchant nous nous sommes aperçus que nos lacunes en physique et en
calculs mathématiques ne nous permettraient pas de représenter de manière réaliste le mouvement de
la bille. Nous avons donc choisi de recentrer nos objectifs afin d’obtenir un déplacement de la bille
correct et une gestion des collisions minimaliste afin que la partie reste jouable. L’algorithme de
déplacement ainsi choisi ne prenant en compte que la vitesse, l’accélération et les frottements, nous
avons choisi de ne pas proposer au joueur de paramétrer la partie.

    En conséquence, les fonctionnalités et améliorations suivantes peuvent être implantées :
        - Une meilleure gestion du mouvement prenant en compte la gravité.
        - Une gestion des collisions permettant de rebondir sur les obstacles selon un angle réaliste
           calculé.
        - Une interface permettant de paramétrer le jeu, d’étalonner l’accéléromètre et de régler sa
           sensibilité.
        - Une application tournant sur ordinateur offrant la possibilité de créer ses propres parcours.




Licence Professionnelle Systèmes Informatiques et Logiciels                                      Page 30
2010-2011
            Etude du système Android de Google :                                                      IUT de Rodez
            Réalisation d’applications pour « mobiles »

3. Application de gestion de Matériels.

         Cette application va permettre de gérer les équipements d’une organisation quelconque.
L’objectif est de permettre à un responsable de pouvoir contrôler les équipements de l’organisation
surveillée. On peut prendre comme exemple concret l’IUT de Rodez, un surveillant contrôle l’ensemble
des pièces des bâtiments de l’IUT. Il pourra alors notifier des équipements dégradés, ou absents, mais
également en ajouter.


    3.1. Présentation des besoins.

        3.1.1. Spécification globale.

         Cette application a pour objectif la réalisation d’une application de gestion de matériels destinés
à des organisations qui souhaitent effectuer un contrôle et un suivi des équipements disponibles dans
leurs locaux. Pour les besoins de l’application nous devrons utiliser les possibilités GPS du téléphone afin
de détecter un des bâtiments que le responsable devra inspecter. Le responsable est la personne qui est
en charge de l’inspection et du suivi des équipements présents dans les locaux de l’organisation.
L’application doit lui permettre de contrôler la présence ou l’absence des équipements mais également
il doit pouvoir spécifier leurs états s’il le désire.

        Les capacités ergonomiques d’un téléphone sont relativement restreintes à cause de la faible
dimension de celui-ci. C’est pourquoi nous voulons essayer de fournir une interface claire et complète
qui permettra une prise en main et une navigation facile.
Lorsque le responsable lancera l’application alors celle-ci devra lui proposer le bâtiment qui correspond
à sa position GPS. Après avoir sélectionné le bâtiment à inspecter le responsable pourra visualiser les
différents étages et les différentes pièces présentes sur l’étage. Grâce à un jeu de sélection celui-ci
pourra se déplacer dans le bâtiment (entrer dans une pièce, changer d’étage, …). Lorsqu’il se trouvera
dans un espace qui comportera des matériels, il pourra alors les contrôler et noter leurs
présence/absences et leurs états. Si nécessaire il pourra ajouter une description de l’état d’un matériel
spécifique.

         En parallèle de cela, nous devrons fournir une application Java (qui sera conçue pour
fonctionner sur d’autres matériels qu’un téléphone à cause de l’ergonomie) qui permettra au
responsable de définir des configurations pour ses bâtiments en indiquant des informations comme la
localisation GPS, les pièces, les étages, les couloirs d’un bâtiment mais aussi les équipements présents
dans ceux-ci. Après avoir définie la configuration il pourra la sauvegarder dans un fichier et la charger
sur le téléphone pour effectuer l’inspection des locaux. A la fin de celle-ci le responsable doit pouvoir
mettre à jour la configuration sur PC et un rapport de l’inspection lui sera fourni.


        3.1.2. Spécification détaillée de la première itération.

         Cette première itération sera l’occasion de définir un prototype fonctionnel de l’application
Android uniquement. Celle-ci ne permettra pas encore de charger des fichiers de configuration mais
utilisera une configuration définie « en dur ». Le principal objectif est de réussir à fournir une navigation
simple et efficace. De plus, toutes les fonctionnalités de base (déplacement dans le bâtiment,
vérification de présence ou non de matériel, ajout de nouveau matériel, ajout/modification d’une
description d’un équipement) de l’application seront implantées.

       Enfin, dans ce prototype la détection de la position du responsable via le GPS ne sera pas
forcément fournie, cela dépendra de l’avancement de la réalisation du prototype.


Licence Professionnelle Systèmes Informatiques et Logiciels                                        Page 31
2010-2011
            Etude du système Android de Google :                                                    IUT de Rodez
            Réalisation d’applications pour « mobiles »

        3.1.3. Spécification détaillée de la seconde itération.

         La seconde itération a pour objectif de prendre en compte la détection GPS du bâtiment. Ainsi le
responsable pourra soit choisir directement le bâtiment dans lequel il a été localisé soit choisir un autre
bâtiment parmi tous ceux qu’il aura défini au préalable. De plus cette seconde itération devrait nous
permettre de réaliser l’application qui permet au responsable de définir la configuration et de la
sauvegarder. Suite à cela nous mettrons en place le système de chargement de configuration sur
l’application mobile. Ainsi nous aurons une application fonctionnelle. La mise à jour de la configuration
sur PC à l’aide de celle modifiée sur le téléphone ne sera pas disponible. C’est une des améliorations qui
peuvent être effectuées.




Licence Professionnelle Systèmes Informatiques et Logiciels                                       Page 32
2010-2011
            Etude du système Android de Google :                                                     IUT de Rodez
            Réalisation d’applications pour « mobiles »

    3.2. Analyse / Conception de l’application.

        3.2.1. Diagramme des cas d’utilisation.

            3.2.1.1.    Diagramme.




            3.2.1.2.    Les acteurs principaux.

        Le responsable : Il s’agit d’une personne physique qui est responsable des locaux. Il doit tenir à
jour une liste des différents matériels présents dans les pièces des bâtiments.


            3.2.1.3.   Description du cas d’utilisation définir les configurations des bâtiments
                   sur PC.

Acteur principal : Responsable.

Résumé du cas : Permet au responsable de définir une configuration sur pc des bâtiments et des pièces
de celui-ci sur PC.

Evénement déclencheur : La volonté du responsable des bâtiments de définir une configuration des
bâtiments dont il est responsable sur PC.

Garanties en cas de succès : La configuration des bâtiments est bien définie sur PC et est prête à être
chargée sur le téléphone.

Scénario nominal : Après avoir lancé l’application sur PC, le responsable définit la configuration des
différents bâtiments qu’il doit inspecter. Il pourra consulter les configurations déjà décrites, en ajouter,
en supprimer et les modifier. Pour chaque bâtiment il devra définir les différents espaces ainsi que les
équipements (matériel pouvant se trouver dans une pièce comme des tables, des chaises, des
extincteurs, des ordinateurs, des imprimantes …) présents dans ceux-ci. Chaque équipement aura une



Licence Professionnelle Systèmes Informatiques et Logiciels                                       Page 33
2010-2011
            Etude du système Android de Google :                                                    IUT de Rodez
            Réalisation d’applications pour « mobiles »

description de son état afin de pouvoir effectuer son suivi. Il faudra nécessairement passer par
l’application sur PC pour créer la configuration des bâtiments et des pièces. Les équipements pourront
être définis plus tard à l’aide du téléphone bien entendu. Il suffira d’effectuer la mise à jour de la
configuration PC pour disposer d’une configuration complète sur PC. Une fois la configuration définie
elle est bien sûr sauvegardée et est prête à être chargée sur le téléphone en totalité ou partiellement
(soit un seul bâtiment, soit tous).


            3.2.1.4.   Description du cas d’utilisation charger la configuration des bâtiments
                   définie sur PC sur le téléphone.

Acteur principal : Responsable.

Résumé du cas : Permet au responsable de charger sur le téléphone la configuration définie sur PC.

Evénement déclencheur : La volonté du responsable des bâtiments de charger la configuration définie
sur PC sur le téléphone afin d’effectuer un contrôle.

Garanties en cas de succès : La configuration des bâtiments sur le téléphone est en phase avec celle
définie sur PC.

Scénario nominal : Après avoir connecté le téléphone avec le PC, le responsable envoie le fichier de
configuration sur le téléphone. Une fois le transfert terminé le responsable lance l’application du
téléphone. Il choisit alors de charger la configuration parmi les configurations disponibles sur le
téléphone. Le responsable devra juste sélectionner le fichier puis valider son choix. La configuration est
alors chargée et l’application est prête à être utilisée pour vérifier les configurations.


            3.2.1.5.    Description du cas d’utilisation vérifier les équipements dans les
                   différentes salles.

Acteur principal : Responsable.

Résumé du cas : Permet au responsable de gérer l’ensemble des équipements d’un bâtiment.

Evénement déclencheur : La volonté du responsable des bâtiments de contrôler les équipements
chaque espace de ceux-ci et effectuer les changements nécessaires.

Garanties en cas de succès : La configuration des bâtiments sur le téléphone est en phase avec la
réalité.

Scénario nominal : Après avoir chargé la configuration des bâtiments dont il est responsable sur son
téléphone, le responsable lance l’application sur son téléphone Android, il faudra qu’il choisisse l’espace
à contrôler en fonction des propositions qui lui sont faites grâce à la détection GPS. De cette manière
l’application lui présentera la liste des équipements recensés dans cet espace (qui n’ont pas été
contrôlés aujourd’hui). Le responsable vérifiera alors la présence de chacun des équipements et pourra,
si besoin, mettre à jour l’état d’un équipement (pour cela il choisira l’équipement à mettre à jour et
pourra choisir son état - neuf, bon, détérioré, hors service – et éventuellement ajouter un bref
commentaire), marquer sa présence ou son absence le cas échéant, ou encore ajouter un élément si
celui-ci n’est pas inscrit. Par défaut, lors d’un contrôle tous les éléments sont considérés comme
présents et dans l’état du dernier contrôle. A la fin du contrôle le responsable doit mettre à jour la
configuration PC des bâtiments.



Licence Professionnelle Systèmes Informatiques et Logiciels                                       Page 34
2010-2011
            Etude du système Android de Google :                                                   IUT de Rodez
            Réalisation d’applications pour « mobiles »

            3.2.1.6.   Description du cas d’utilisation mise à jour de la configuration des
                   bâtiments sur PC.

Acteur principal : Responsable.

Résumé du cas : Permet au responsable de mettre à jour la configuration PC des bâtiments dont il est
responsable.

Evénement déclencheur : La volonté du responsable de mettre à jour la configuration PC des bâtiments
à partir de la configuration Android.

Garanties en cas de succès : La configuration PC et la configuration Android seront en phase.

Scénario nominal : L’utilisateur lance l’application, sur son PC, qui va lui permettre de mettre à jour la
configuration en fonction des données recueillies dans les bâtiments. Après avoir importé la
configuration du téléphone sur son PC, l’utilisateur va synchroniser la configuration PC avec celle
modifiée du téléphone. L’application s’occupe alors d’effectuer la mise à jour de la configuration PC et
lui demande des confirmations pour les changements significatifs (disparition / apparition
d’équipements…). Une fois la synchronisation terminée, un compte rendu de la mise à jour lui est
affiché et est enregistré dans un journal qui sera consultable via l’application PC. Ce compte rendu
mettra en valeur les changements significatifs.




Licence Professionnelle Systèmes Informatiques et Logiciels                                      Page 35
2010-2011
            Etude du système Android de Google :                                                   IUT de Rodez
            Réalisation d’applications pour « mobiles »

        3.2.2. Diagramme d’objets de base de l’application.

         Ceci est un exemple de diagramme d’objets qui pourrait être généré lors de l’utilisation de
l’application :




Licence Professionnelle Systèmes Informatiques et Logiciels                                      Page 36
2010-2011
           Etude du système Android de Google :                IUT de Rodez
           Réalisation d’applications pour « mobiles »

       3.2.3. Diagramme des classes.




Licence Professionnelle Systèmes Informatiques et Logiciels   Page 37
2010-2011
            Etude du système Android de Google :                                                   IUT de Rodez
            Réalisation d’applications pour « mobiles »

    3.3. Difficultés rencontrées et leurs solutions.

        3.3.1. Gestion des enchainements d’activités.

         Sous Android, l’enchainement des différentes fenêtres d’une application, correspond à un
enchaînement d’activités et de sous-activités. Seulement pour pouvoir disposer des mêmes références
d’objets et des choix effectués par l’utilisateur, il faut pouvoir transmettre des informations d’une
activité à une autre. Une intention (Intent) dans une activité permet de lancer une sous-activité, mais
elle permet aussi de lui faire passer des données, mais pas des références d’objets, nous avons donc dû
utiliser la sérialisation et la désérialisation d’un fichier pour pouvoir sauvegarder et utiliser les
caractéristiques d’une organisation. Cependant, cette solution est coûteuse, puisqu’elle oblige une
sérialisation/désérialisation et surtout la lecture/écriture dans le fichier de configuration de l’objet à
chaque activité. Nous avons également rencontré ce problème pour l’application du labyrinthe, la seule
différence est que nous n’avons pas eu besoin de sérialiser à nouveau dans le fichier étant donné qu’il
n’y a pas de modifications sur le labyrinthe (sauf pour les paramètres).


        3.3.2. Affichage d’une liste composée (liste des équipements).

        Pour afficher la liste des équipements d’un espace, on souhaitait mettre en place une liste
composée. Le but était d’afficher sur une même ligne, la désignation de l’équipement et un groupe de
boutons radios permettant de signaler sa présence ou son absence. De cette manière, le surveillant peut
modifier l’état (présent ou absent) de l’équipement directement sur la liste. Cependant, il devra accéder
à la description de l’équipement pour modifier son état (dégradé, hors service).


        3.3.3. Affichage récursif de l’ensemble des espaces et sous espaces.

        Dans cette application, les bâtiments contiennent des étages contenant des espaces, eux-
mêmes contenant des sous espace, etc. qui contiendront des équipements. Au départ, nous voulions
afficher cette liste d’espaces et de sous espaces dans un arbre, de manière à bien visualiser les
conteneurs. Seulement ce type d’arborescence n’est pas disponible sous Android. Nous avons donc mis
en place des enchainements d’activités, ainsi une activité présente un espace, chacun donnant accès au
sous espaces qu’elle contient et à son équipement et ainsi de suite.

Exemple d’arbre :




Licence Professionnelle Systèmes Informatiques et Logiciels                                      Page 38
2010-2011
            Etude du système Android de Google :                                                  IUT de Rodez
            Réalisation d’applications pour « mobiles »

    3.4. Synthèse sur l’application.

        L’application de gestion de matériels développée, respecte les fonctionnalités prévues par la
spécification de la première itération et de la seconde itération.

       Néanmoins, des améliorations et des nouveautés peuvent être apportées aux applications.

         Tout d’abord, pour le stockage des données, les propriétés d’une organisation complète sont
sauvegardées grâce à une sérialisation dans un fichier binaire, une évolution possible consistera à
effectuer le stockage dans un fichier XML de manière à permettre à un responsable de modifier ou
définir une configuration en saisissant le fichier directement.

        L’application sur PC pourra permettre de mettre en place une fonction d’historique permettant
de sauvegarder les différentes modifications apportées lors du contrôle des équipements. Ainsi on
pourrait imaginer de pouvoir retracer un historique d’un équipement précis. Une fonctionnalité
permettra d’effectuer des comptes rendus de vérification en mettant en évidence les différents
changements d’états des équipements ou leurs disparitions.

          Il serait également possible d’améliorer la gestion de la localisation GPS en permettant à
l’utilisateur de définir plus ou moins de 4 coordonnées GPS. Ainsi la précision de la localisation serait
augmentée pour les bâtiments qui ont des formes non rectangulaires.




Licence Professionnelle Systèmes Informatiques et Logiciels                                     Page 39
2010-2011
               Etude du système Android de Google :                                                    IUT de Rodez
               Réalisation d’applications pour « mobiles »

4. Synthèses

    4.1. Synthèse personnelle de Maxime Riviere.

           Ce projet fut vraiment intéressant car il m’a permis de découvrir la plateforme Android et le SDK
associé.

        Tout d’abord, le projet m’a permis de découvrir les méthodes de travail et de gestion liées au
travail en équipe. J’ai ainsi appris à travailler en binôme et à utiliser un outil de gardiennage me
permettant d’être toujours synchronisé avec le reste de l’équipe.

        J’ai trouvé particulièrement intéressant le coté développement embarqué s’appuyant sur la
technologie Java et la communication avec des périphériques tels qu’un chipset GPS ou un
accéléromètre peu courant sur un ordinateur.

       L’application de gestion de matériels m’a permis de découvrir la bibliothèque de widgets
Android ainsi que les avantages et les contraintes liées à l’utilisation d’un écran tactile de taille réduite.

       Quant à l’application labyrinthe qui utilise des formules physiques et mathématiques a
représenté un vrai défi qui m’a permis de m’intéresser à d’autres domaines que celui de l’informatique.

        En conclusion, la réalisation de ce projet a enrichi mes connaissances générales en
programmation, m’a fait découvrir l’univers de la programmation embarquée et a attisé mon intérêt
pour la plateforme naissante qu’est Android.




Licence Professionnelle Systèmes Informatiques et Logiciels                                         Page 40
2010-2011
            Etude du système Android de Google :                                                      IUT de Rodez
            Réalisation d’applications pour « mobiles »

    4.2. Synthèse personnelle de Maxime Rodrigues.

         J’ai choisi de travailler sur ce projet pour la simple raison que je souhaitais découvrir un nouveau
contexte d’application au développement différent des applications PC habituelles. L’an passé j’avais
travaillé sur de l’informatique embarquée ce qui m’avait vraiment fait prendre conscience des limites
matérielles. Ce projet est en quelque sorte l’intermédiaire entre celui de l’an passé et le développement
que nous produisons depuis maintenant 3 ans. Il m’a donc permis d’élargir mes connaissances sur les
divers supports pour applications informatiques.

         Le projet m’a également permis d’aborder un projet différemment qu’à l’accoutumé étant
donné que je ne savais vraiment rien d’Android et de son environnement. Cela a donc nécessité un
travail préalable pour prendre conscience de la capacité de l’environnement ainsi que certaines de ses
limites.

        De plus le développement des applications Android se fait en Java, qui est un langage que je
mets en œuvre depuis près de 3 ans, j’ai pu constater que la structure métier de la solution n’était pas
modifiée, comparée à une application sur PC. Seules les classes d’interface sont vraiment différentes
étant donné qu’une application Android se base sur un cycle de vie.

        Enfin l’expérience en tant que Chef de projet est vraiment bénéfique et j’ai pu faire le parallèle
avec celle de l’an passé afin de voir les différences entre l’organisation d’un groupe de 2 personnes et
l’organisation d’un groupe de 4.




Licence Professionnelle Systèmes Informatiques et Logiciels                                        Page 41
2010-2011
           Etude du système Android de Google :                                                   IUT de Rodez
           Réalisation d’applications pour « mobiles »

    4.3. Synthèse personnelle de Mélanie Marc.

       Ce projet a été pour moi une expérience intéressante sur plusieurs points.

        Tout d’abord cela m’a permis de développer le travail d’équipe. En effet travailler sur un projet
réclame une très bonne coordination entre les différents membres ainsi qu’une bonne communication.
De plus, ce projet comportant deux développements, nous avions instaurés des roulements dans les
binômes, ce qui nous permettait de travailler avec tous les membres du groupe et sur les deux parties
du projet.

       Ensuite ce projet m’a permis d’approcher un univers qui n’est pas trop abordé en formation,
mais que je souhaitais découvrir depuis un moment, il s’agit de la programmation sur mobiles et plus
précisément sous Android. Mais cet aspect de l’informatique possède quelques petits inconvénients liés
au matériel.

       Puis, ce projet m’a permis de pratiquer le langage Java d’une nouvelle manière, le
développement dans un environnement mobile étant très différent du développement sur PC.

         De plus, le développement de la partie graphique de l’application de gestion de matériels sur le
téléphone, m’a permis de découvrir l’utilisation des différents widgets fournis par Android ainsi que la
subtilité du cycle de vie d’une activité.

        Enfin, le développement du labyrinthe à bille m’a permis de me replonger dans les bases de la
physique en ce qui concerne le déplacement de la bille et les différents impacts entre objets. Ce qui fut
un challenge pour moi qui n’en avait pas fait depuis 3 ans.

        Pour conclure ce projet a donc été une expérience très enrichissante, il m’a permis de sortir du
cadre purement scolaire en touchant à la programmation sous Android, un environnement qui m’attirait
depuis un moment, tout en me permettant d’appliquer les différents enseignements liés aux méthodes
d’analyse mais aussi en programmation Java.




Licence Professionnelle Systèmes Informatiques et Logiciels                                     Page 42
2010-2011
            Etude du système Android de Google :                                                    IUT de Rodez
            Réalisation d’applications pour « mobiles »

    4.4. Synthèse personnelle de Sylvain Picarle.

         Ce projet m’a permis de m’améliorer sur plusieurs points. Tout d’abord j’ai pu voir les différents
problèmes que peut poser une conception plus ou moins appropriée aux problèmes et voir les échecs
que cela peut entrainer. J’ai aussi pu travailler sur une des technologies pour terminaux mobiles, en
abordant les divers aspects techniques et les différentes contraintes matérielles qui sont imposées par
les téléphones. Enfin j’ai pu découvrir et apprendre à utiliser une partie des possibilités de
l’environnement Android de Google, sur lequel il est plutôt agréable de travailler grâce à l’ensemble des
outils disponibles (« debugger », « logcat », « explorer » …).

         Le travail en groupe m’a aussi permis de voir les différents problèmes d’organisation, de
collaboration et de synchronisation d’une équipe. La gestion du temps et le partage du travail est
primordiale afin de pouvoir aboutir aux objectifs fixés. Je suis pleinement satisfait, de l’assiduité de
l’équipe et du travail qui a été effectué dans le peu de temps qui nous a été impartit. Je tiens aussi à
souligner que l’utilisation d’un SVN, nous a permis d’améliorer la rapidité de production mais aussi la
possibilité de travailler à distance.

        Sur le projet du Labyrinthe, les difficultés se sont accumulées, nous avons développés le
mouvement de la bille et la mise en place du labyrinthe séparément ce qui a posé différents problèmes
de compatibilité et regroupement, la détection du mouvement aurait dû être géré différemment, par
exemple : un objet indique qu’il a été touché, effectuer une détection de collision par zone et non sur
tous les composants de l’écran. Je suis assez déçu que le projet ne fonctionne pas totalement comme
prévu même si les principaux objectifs de création d’espace, de déplacement et de détection ont été
rempli.

          En ce qui concerne la seconde application, nous avons eu moins de difficultés, les problèmes de
gestion étant plus courants lors de notre parcours universitaire, nous avons pu définir une conception
plus correcte et ainsi réussir à coder la partie métiers rapidement. Les problèmes résultants se sont
simplement rapportés à l’utilisation du capteur GPS et la création graphique des différentes vues pour
l’utilisateur, l’ensemble étant spécifique à l’environnement Android auquel il a fallu s’adapter. Les
objectifs ont été pour ma part entièrement remplis, même si l’application peut largement et facilement
être améliorée.

        Après avoir travaillé sur l’environnement Android et avoir vu le travail que Google effectue sur
son système afin de l’améliorer par des versions successives, je me permets de prédire un bon avenir
pour cette plateforme, même si tout le monde sait que l’évolution des systèmes est tellement rapide
que cela ne durera que quelques années.




Licence Professionnelle Systèmes Informatiques et Logiciels                                       Page 43
2010-2011
            Etude du système Android de Google :                                                     IUT de Rodez
            Réalisation d’applications pour « mobiles »

Conclusion sur Android.

        Le système Android contient des avantages auxquels se couplent des inconvénients :

        Tout d’abord, la prise en charge de l’API Java de Sun donne accès à une vaste bibliothèque de
composants déjà éprouvés, de plus l’univers Java possédant déjà une communauté développée, Android
entre dans le monde des plateformes embarquées avec un certain nombre d’adeptes.

         De plus, des fichiers XML permettent de définir les vues des activités. En effet, pour chacune des
activités d’une application, on pourra affecter une vue qui définit des widgets, au départ prédéfinis par
Android, à afficher sur l’écran, dans un fichier XML. Ensuite grâce au XML, on peut affecter des actions
(implémentées dans le code de l’activité concernée) sur des widgets ce qui permet une gestion
événementielle simplifiée. L’association XML-Java permet la réalisation « rapide » d’interfaces
d’applications de gestion mais elle présente des limites car pour des applications telles que des jeux il
est impossible de gérer les éléments graphiques via un fichier XML.

         Ensuite, nous avons découvert qu’une application Android peut être composée de plusieurs
activités. Une activité pourra lancer une nouvelle activité et se mettre elle-même en pause, en donnant
la main à la nouvelle activité. On parle d’un enchainement entre activité principale et sous-activité.
Le lancement d’une sous-activité à partir d’une activité principale se fait via une référence d’intention
(Intent). Cet objet s’avère donc très utile pour l’enchainement des activités, mais il permet également
de faire passer des valeurs de l’activité principale vers la sous-activité. Seulement ce passage de valeurs
reste compliqué voir restreint, en effet, il est impossible de faire passer des références d’objets, via des
intentions (Intent), afin de conserver les objets pendant la durée d’exécution de l’application. Cela nous
a donc obligé à utiliser le mécanisme de lecture/écriture dans des fichiers pour chaque modification de
la référence d’une organisation, par exemple.

        Android, propose également une bibliothèque de widgets permettant de construire des
interfaces graphiques de tout type : des boutons, des listes,… Cependant, cette liste est limitée puisque
nous recherchions une liste à structure arborescente pour afficher l’ensemble des espaces et sous
espaces d’un étage (dans l’application de gestion de matériels) qui n’existe pas sous Android.

         En ce qui concerne l’application de gestion de matériels nous avons eu besoin d’un sélecteur de
fichiers (présent dans l’API Java) pour pouvoir choisir la configuration de l’organisation à charger. Cette
absence liée à un surplus de sécurité imposé par Android nous oblige donc à revoir notre idée.

         En conclusion, la plateforme Android, propulsée par Google et une large communauté de
développeurs (en constante augmentation), possède un potentiel certain. Elle représente un concurrent
de taille dans le monde des Smartphones et des tablettes tactiles aujourd’hui en pleine croissance.

        A court terme, les applications Android vont très certainement être de plus en plus utilisées
dans un contexte professionnel, notamment sur les tablettes car elles disposent d’une ergonomie et
d’une puissance intéressante et de plus en plus importante. La version 3.0 d’Android marque clairement
la volonté de Google de fournir un système d’exploitation compatible avec divers supports portables
tout en exploitant au maximum les capacités de ceux-ci.

         Pourtant à long terme, le système Android devra évoluer afin de pouvoir fournir des services
compatibles avec la puissance croissante des supports. En effet, dans quelques années les tablettes et
Smartphones auront la puissance d’un PC actuel et les applications devront évoluer en conséquence.
Une des plus grosses limites sera alors l’ergonomie des supports qui pour l’instant ne permettrait pas
d’utiliser les capacités d’un PC sur un Smartphone.




Licence Professionnelle Systèmes Informatiques et Logiciels                                       Page 44
2010-2011
            Etude du système Android de Google :                                                    IUT de Rodez
            Réalisation d’applications pour « mobiles »

Annexes.

1. Gestion de projet.

    1.1. Définition des rôles.

        Pour la réalisation de ce projet tuteuré des rôles ont été attribués aux différents membres de
l’équipe :
           - Chef de Projet : Maxime Rodrigues.
           - Intégrateur : Maxime Riviere.
           - Gestionnaire de configuration : Sylvain Picarle.
           - Développeurs : Maxime Riviere, Maxime Rodrigues, Mélanie Marc, Sylvain Picarle.


        Le chef de projet a pour rôle de gérer le projet et de coordonner les membres de l’équipe afin
de faire avancer le projet de manière efficace. Il organise les différentes réunions qui peuvent avoir lieu
avec les membres de l’équipe.

       L’intégrateur est la personne qui doit effectuer les migrations des applications développées sur
le matériel afin d’éviter que n’importe qui installe n’importe quoi, n’importe comment.

        Le gestionnaire de configuration doit quant à lui assurer la mise en place d’un environnement de
développement identique pour tous les développeurs. Il s’occupe par exemple de créer un dépôt SVN
accessible par tout le monde, ou encore d’installer l’IDE avec tous ses plug-ins pour les développeurs.

       Le développeur a pour objectif de s’occuper de la réalisation technique des solutions
correspondant aux besoins.




Licence Professionnelle Systèmes Informatiques et Logiciels                                       Page 45
2010-2011
           Etude du système Android de Google :                IUT de Rodez
           Réalisation d’applications pour « mobiles »

   1.2. Planification initiale.




Licence Professionnelle Systèmes Informatiques et Logiciels   Page 46
2010-2011
           Etude du système Android de Google :                                           IUT de Rodez
           Réalisation d’applications pour « mobiles »

2. Photos des applications.

   2.1. Application du Labyrinthe à bille




   2.2. Application de gestion de matériels




          Page d’accueil                 Sélection du bâtiment    Sélection de l’étage




         Affichage des pièces           Liste des équipements    Modification d’un équipement




Licence Professionnelle Systèmes Informatiques et Logiciels                              Page 47
2010-2011
              Etude du système Android de Google :                                                  IUT de Rodez
              Réalisation d’applications pour « mobiles »

3. Manuel d’utilisation des applications pour la gestion de matériels.

         Ce manuel a pour objectif d’expliquer comment utiliser les applications de gestion de matériels
et les faire fonctionner ensemble. Contrairement à l’application du labyrinthe ce manuel est nécessaire
afin de saisir les subtilités de l’application.

    3.1. Manuel d’utilisation de l’application PC.

        Pour lancer l’application PC, il suffit de double cliquer sur le fichier GestionMateriel.jar, vous
aurez alors la fenêtre suivante :




           En bleu, on retrouve la barre de menu traditionnelle qui va permettre d’effectuer les diverses
actions.
        La zone entourée en vert, contiendra la structure arborescente représentative de la
configuration en cours d’utilisation.
        En rouge, ce sont les boutons d’actions qui permettront de manipuler l’arborescence.

         Les premières actions qui sont disponibles se trouvent dans Fichier. Il est possible de quitter
l’application, de charger une configuration existante, de la sauvegarder ou bien d’en créer une nouvelle.
Lorsque vous en créez une nouvelle vous devez fournir un nom qui correspond à celui de l’organisme.
Vous ne pouvez créer une nouvelle configuration que si vous n’en avez pas chargée ou créée une autre
au préalable. C’est tout à fait normal étant donné qu’un responsable n’est responsable que d’une
organisation ou qu’il ne doit pas mélanger diverses configurations d’organisations différentes.

        Suite à la création ou au chargement d’une configuration il devient possible de manipuler
l’organisation et de définir les différents espaces de celle-ci. Ainsi vous pouvez manipuler des bâtiments,
des espaces et des équipements (ajouter, supprimer, modifier, visualiser). Lorsque vous souhaitez


Licence Professionnelle Systèmes Informatiques et Logiciels                                       Page 48
2010-2011
            Etude du système Android de Google :                                                      IUT de Rodez
            Réalisation d’applications pour « mobiles »

manipuler un élément de la structure arborescente il suffit de le sélectionner et les actions possibles se
dégriseront. Pour ajouter un élément à un endroit précis il suffit de se placer sur l’élément parent de
celui-ci et de cliquer sur le bouton ajouter correspondant. Des boîtes de dialogue simples vous
permettront de renseigner les divers éléments.


    3.2. Manuel d’utilisation de l’application Android.

         Pour lancer l’application Android il suffit de sélectionner l’application (que vous avez installé :
Gestion Matériels) parmi toutes vos applications déjà installées. La fenêtre d’accueil s’affiche alors. Le
bouton « Lancer » permet de lancer l’application avec la dernière configuration chargée et le bouton
« Charger » permet de charger une configuration qui est présente sur la carte SD du téléphone. Pour
placer une configuration sur la carte SD il suffit de relier le téléphone à l’ordinateur, d’accéder à la carte
SD et d’aller dans le répertoire Android, puis Gestion_Materiel. Si les répertoires n’existent pas alors
vous devez les créer puis placer le fichier que vous avez créé avec l’application décrite précédemment.
Suite à cela si vous demandez le chargement d’une configuration via le téléphone, la liste des fichiers de
configuration sera alors affichée, il suffira de sélectionner celle que vous désirez.

        Une fois l’application correctement lancée et la configuration chargée, une page contenant la
liste des bâtiments disponibles est affichée. Il est possible de détecter les bâtiments les plus proches
grâce au GPS que vous pouvez activer via un bouton. Une fois activée, et la détection des bâtiments à
proximité effectuée, ceux-ci s’affichent sur la partie centrale de l’application. Il est possible de
sélectionner un bâtiment pour afficher la liste des étages et des différents espaces qu’il contient. A ce
niveau les espaces s’affichent sous forme de liste et vous pouvez les sélectionner en cliquant sur l’un
d’eux. Vous pouvez également visualiser les équipements présents en cliquant sur le bouton « Voir les
équipements ». Si celui-ci est grisé c’est que l’espace ne peut contenir d’équipements. Sur la page des
équipements, la liste de ceux-ci permet de cocher leur absence / présence puis de valider (sans
validation les changements ne seront pas conservés). Il est également possible de modifier un
équipement en cliquant sur son nom. Une fenêtre descriptive apparait alors et vous pouvez changer son
nom, son état et/ou son statut ou encore le supprimer. Lorsque la liste des équipements est visible il est
également possible d’ajouter un équipement en remplissant les champs précisés.

        Une fois les manipulations terminées, toutes les modifications sont automatiquement
enregistrées (sauf si vous avez changé la présence / absence et que vous n’avez pas validé).

        Enfin, vous avez dû charger une configuration sur le téléphone pour utiliser l’application mais il
est également possible de faire l’inverse en reliant le téléphone à l’ordinateur et en utilisant la fonction
« Charger » de l’application PC.




Licence Professionnelle Systèmes Informatiques et Logiciels                                         Page 49
2010-2011

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:22
posted:4/14/2012
language:
pages:50