Rapport de Projet Professionnel - Freejultey.free.fr/blog/uploads/univ.decorse/lgm_rapport.pdf ·...

Rapport de Projet Professionnel Année 2004/05

PROJET LIFE GOES MOBILE

Université du projet

Etudiants de Master 2 ISI

Cyril Ballesta Sébastien Denis

Sébastien Fesquet Julien Teyssier

Tuteur du projet

Christophe Paoli

Entreprise du projet

Collaborateurs

François-Xavier Cardi Michel Marti

Blog du projet

http://www.i-spirit.fr/lifegoesmobile/

Rapport de projet professionnel Life Goes Mobile Master 2 ISI Année 2004/05

1


2

Introduction

Ce rapport décrit le déroulement et le contenu de notre projet professionnel de

Master 2 ISI (Intégration des Systèmes Informations). Ce projet professionnel s’est

déroulé de novembre 2004 à mars 2005.

Nous avons collaboré avec la société I-SPIRIT afin de développer un logiciel

de moblogging sur plateforme mobile. Le sujet de ce projet professionnel était donc

de créer un logiciel permettant à un utilisateur de gérer ses articles (texte,

images,…) et de mettre à jour son blog directement de sa plate-forme mobile en

l’occurrence un téléphone portable. Le sujet étant novateur et pas encore développé

sur le marché, une longue étude préalable à du réaliser avant la conception et le

développement.

Il sera envisageable de coupler cette application avec un logiciel destiné à des

ordinateurs. Toutefois, dans un premier temps, nous nous sommes concentrés sur

l’aboutissement de l’application mobile. Le développement de l’application coté PC

pourra faire l’objet d’un stage au sein d’ I-SPIRIT.


3

Sommaire

Remerciements......................................................................................................... 4

1. Présentation de l’entreprise ............................................................................. 5

2. Mission ............................................................................................................... 6

2.1. Sujet.........................................................................................................................6

2.2. Moyen ......................................................................................................................6

2.3. Equipe......................................................................................................................6

2.4. Objectifs ..................................................................................................................7

3. Outils utilisés..................................................................................................... 8

3.1. Etat de l’art ..............................................................................................................8 3.1.1. Développement des blogs .......................................................................................... 8 3.1.2. Les bloggers ................................................................................................................ 8 3.1.3. Les fournisseurs de blog.......................................................................................... 10

3.2. XML-RPC ...............................................................................................................11 3.2.1. Définition .................................................................................................................... 11 3.2.2. Comparaison avec SOAP ......................................................................................... 14

3.3. J2ME et Outils de développement ......................................................................14 3.3.1. J2ME ........................................................................................................................... 14 3.3.2. Outils de développement.......................................................................................... 22

3.4. Blogs (Nucleus) et les API ...................................................................................24

3.5. kXML-RPC .............................................................................................................26

4. Déroulement de la mission............................................................................. 28

4.1. Planning ................................................................................................................28

4.2. Etude UML.............................................................................................................29

4.3. Avancement et difficultés ....................................................................................30 4.3.1. Communication ......................................................................................................... 30 4.3.2. Interface utilisateur ................................................................................................... 31 4.3.3. Stockage des préférences ........................................................................................ 33 4.3.4. Récupération d’une image sur le téléphone........................................................... 33 4.3.5. Envoi d’une image à partir du téléphone ................................................................ 35 4.3.6. Organisation modulaire de l’application................................................................. 37

5. Conclusion....................................................................................................... 38

6. Glossaire .......................................................................................................... 39

7. Références ....................................................................................................... 40


4

Remerciements

Nous remercions la société I-SPIRIT de nous avoir proposé ce projet fort

intéressant et valorisant.

A tous les webmasters et à leurs sites web que nous avons pu visiter et qui

traitaient des outils et technologies que nous avons utilisés.

A tous les étudiants du Master 2 ISI de Corte qui nous ont apporté un soutien

cette année scolaire et pendant le projet.

Merci à notre tuteur côté université, M. Christophe Paoli pour nous avoir

consacré du temps qui lui est très précieux.


5

1. Présentation de l’entreprise

Implantée à Ajaccio, la société I-SPIRIT est spécialisée dans l’Internet Mobile.

I-SPIRIT situe son activité dans la recherche et la conception de technologies

nouvelles et de produits nouveaux répondant au marché des services de l’Internet

Mobile.

I-SPIRIT anticipe les attentes des consommateurs, prévoie les évolutions de

comportements et y répond par des solutions concrètes. I-SPIRIT explore deux voies

complémentaires :

� Réflexion et recherche : Réflexion sur l’avenir des communications et

notamment sur celui de l’Internet Mobile. Quelles seront les attentes des

consommateurs dans les années qui viennent, comment agir comme

révélateur d’une demande, comment faire prendre conscience d’un nouveau

besoin sont autant de questions auxquelles nous essayons de répondre.

Notre société possède déjà une expérience conséquente dans ce domaine et

travaille pour garder constamment une certaine avance sur les besoins du

marché.

� Développement : Forts de cette réflexion et dans un souci de capitalisation

de nos recherches, nous avons lancé un vaste programme technique visant à

implémenter diverses solutions techniques pouvant répondre aux besoins

futurs des consommateurs. Plusieurs produits destinés au grand public ainsi

qu’au monde professionnel vont ainsi voir le jour dans les mois qui viennent.

Retrouver la société I-SPIRIT sur son blog : http://www.i-spirit.fr


6

2. Mission 2.1. Sujet

L'entreprise I-SPIRIT est une société développant et gérant des projets liés à

Internet et plus particulièrement à l'Internet mobile. Cette société souhaite réaliser un

projet de moblogging. Ce projet est le développement d’une suite d’applications pour

le moblogging. Ces logiciels vont permettre à un utilisateur de gérer ses articles et

ses médias sur son site web personnel (blog) via un terminal numérique (PC,

téléphone mobile,…)

2.2. Moyen

Pour ce projet, nous avons besoin d’un terminal mobile capable de supporter

une application utilisant des réseaux spécifiques (W@p, GPRS,…) c’est-à-dire un

Sony-Ericsson P900 ou autre téléphone de dernière génération pour l'implémentation

et les tests. Puis pour le développement, nous avons utilisé un environnement de

travail pour J2ME.

2.3. Equipe

Le projet nécessitait 600h de travail. Chaque étudiant devrant y consacrer

environ 150h. 4 personnes seront nécessaires à la réalisation du projet. Les

techniques informatiques mises en oeuvre dans le cadre du projet :

� Conception et mise en place d'applications logicielles

� Compétences techniques requises : XML, JAVA, WML, SOAP


7

2.4. Objectifs

Voici les objectifs :

� Prévus : La réalisation d'un logiciel et d'une application mobile permettant la

communication et l'organisation d'informations

� Optimum : Un logiciel proposant une gestion chronologique des photos

numériques ou des vidéos, auxquelles le mobinaute peut bien évidemment

ajouter des commentaires, à la manière d'un journal intime multimédia


8

3. Outils utilisés 3.1. Etat de l’art

Suite à la lecture de différents articles et pages web, on a pu voir que le

moblogging est en plein boom et que le développement de logiciel côté mobile est lui

aussi en train d'avancer à grands pas.

3.1.1. Développement des blogs

Les blogs sont déjà bien développés aux Etats-unis et en Asie, et selon les

économistes, ce marché commence à s’implanter en Europe. Nous l’avons d’ailleurs

constaté au niveau français lors des derniers évènements survenus en Asie en

décembre 2004, à l’occasion desquels les blogs furent une source d’information non

négligeable.

Au niveau mondial, l’émergence des blogs est expliquée par Loïc Le Meur à

l’adresse suivante (http://www.loiclemeur.com/france/2004/06/les_blogs_et_le.html) :

« Deux événements majeurs ont donné l'impulsion au phénomène donnant au blog

son statut de média : après le 11 septembre puis avec le début de la guerre en Irak,

beaucoup d'Américains ont ressenti le besoin de s'exprimer, de savoir comment le

reste du monde réagissait. Les familles des GI et l'opinion américaine étaient

également à la recherche de réconfort, de compréhension et cherchaient surtout à se

tenir informées des événements sur place. Beaucoup de blogs américains et

internationaux sont ainsi nés. »

Le développement des blogs s’accompagne également du développement

des technologies. L’accroissement du nombre d’appareils photo numérique implique

l’envie de les partager sur un format numérique. Le blog est un support qui s’y prête

facilement.

3.1.2. Les bloggers

Le nombre de bloggers augmente de jour en jour. Parmi les sites qui publient

leur nombre de blogs, certains comme le site de la radio Skyrock (http://skyblog.com)


9

affichent plus d’un million et demi de blogs. Mais parmi ces blogs, une grande partie

est faite de blogs inactifs ou abandonnés.

Des chiffres plus intéressant sur le nombre de blogs actifs sont visible à

l’adresse suivante :

http://padawan.info/fr/weblogue/chiffres_et_tendances_de_la_blogosphere.html

On peut y retenir que les blogs représentent déjà plus de 10% du nombre de

sites web actifs, et peut-être même plus de 20%. Malgré qu’aucun chiffre officiel

n’existe on peut estimer qu’il existe plus de 3 millions de blogs actifs dans le monde.

Ces plates-formes de blog regroupent généralement les bloggueurs par

tranche d’age. Les blogs skyblog sont tenus par des adolescents, alors que les blogs

de 20six sont tenus par de jeunes adultes. Mais dans tous les cas, les bloggueurs se

« linkent » entre eux. C’est à dire qu’ils font des liens vers les blogs de leurs amis et

leurs blogs préférés, formant ainsi un réseau, une communauté. La publication de

photos et texte personnel est alors vécu par le bloggueur comme une discussion

avec ses amis.

Comme nous le fait remarquer Loïc Le Meur sur son blog personnel

(http://www.u-blog.net/loicfr/note/57285), les blogs ne sont pas que des journaux

intimes, mais aussi des outils de communication :

� Les célébrités l’ont d’ailleurs compris, cela permet de se montrer plus

accessible, de créer un dialogue permanent avec ses fans/supporters,

créer autour de soi un effet de réseau en suscitant la création de blogs

partisans, etc.

� Parmi les célébrités de la scène française tenant à jour un blog, nous

trouvons par exemple Dominique Strauss-Kahn (http://www.blogdsk.net/ )

et Alain Juppé (http://al1jup.com/ )

� Les entreprises se mettent également au blog : la communication d'une

entreprise peut désormais se passer d'intermédiaires (communiqué de

presse, newsletter) et diffuser directement des informations sur leur blog.

Un grand nombre de grandes entreprises américaines diffusent une partie

de leurs informations par l’intermédiaire de weblogs, comme par exemple


10

Nokia. De cette manière les journalistes ou clients intéressés peuvent s'y

abonner et éventuellement reprendre facilement l'information.

Afin d’obtenir plus d’informations sur la blogosphère ( le monde des blogs ),

nous ne pouvons que vous conseiller le blog de Loïc Le Meur (

http://www.loiclemeur.com ) et plus particulièrement cette adresse :

http://www.loiclemeur.com/france/2004/06/les_blogs_et_le.html

3.1.3. Les fournisseurs de blog

Les fournisseurs de blogs sont nombreux. Nous trouvons par exemple :

Blogger, Nucleus, Blog-City, 20six, etc. Ces plates-formes de blogs proposent

généralement leurs services de bases de façon gratuite. Mais de plus en plus

apparaît une cohabitation entre des solutions gratuites et payantes, permettant ainsi

d’accéder à des fonctionnalités à valeur ajoutée satisfaisant aux exigences des

bloggers professionnels ou simplement plus assidus que d’autres.


11

3.2. XML-RPC

3.2.1. Définition

Avant de parler de XML-RPC il faut connaître le concept de RPC (Remote

Procedure Call) que vous pouvez trouver dans la rubrique Glossaire.

Le protocole XML-RPC (http://www.xmlrpc.com/) est un standard pour le

traitement distribué sur Internet. Un message XML-RPC est une requête HTTP-

POST dont le corps est écrit en XML. Une procédure s'exécute sur le serveur et la

valeur retournée est également formatée en XML. Voici un message type en XML-

RPC :

POST /RPC2 HTTP/1.0 User-Agent: Frontier/5.1.2 (WinNT) Host: leprogrammeurweb.com Content-Type: text/xml Content-length: 182 <?xml version="1.0"?> <methodCall> <methodName>methode.action</methodName> <params> <param> <value><i4>1010</i4></value> </param> </params> </methodCall>


12

Les paramètres des messages XML-RPC acceptent six types de données

différentes :

Balise Type de données Exemple

<i4><int> Nombre entier signé sur 4

octets. 780, -23

<boolean> Valeur booléenne. 0 (false), 1 (true)

<string> Chaîne de caractères ASCII. 'Bienvenue'

<double> Nombre à virgule flottante en

double précision et signé. 0.129657835, -89.40325

<dateTime.iso8601> Expression temporelle au

format ISO-8601. 20020228T20:51:06

<base64> Données binaire encodées

en base 64. kf95WNb01Pht6245jHIjmp21hz1

Les valeurs repérées par le balisage <value> peuvent être non seulement une

valeur d'un type précité, mais aussi une structure <struct> ou encore un tableau de

données <array> :

<struct> <member> <name>lowerBound</name> <value><i4>18</i4></value> </member> <member> <name>upperBound</name> <value><i4>139</i4></value> </member> </struct> <array> <data> <value><i4>12</i4></value> <value><string>Egypt</string></value> <value><boolean>0</boolean></value> <value><i4>-31</i4></value> </data> </array>


13

La réponse à la requête est obtenue par le biais d'un message spécifique comportant

la balise <methodResponse> : HTTP/1.1 200 OK Connection: close Content-Length: 163 Content-Type: text/xml Date: Fri, 18 Apr 2002 16:09:54 GMT Server: UserLand Frontier/5.1.2-WinNT <?xml version="1.0"?> <methodResponse> <params> <param> <value><double>215.50</double></value> </param> </params> </methodResponse> Si une erreur est rencontrée, alors un balisage spécial sera renvoyé avec pour valeur

le code (faultCode) et le message (faultString) de l'erreur dans une structure

<struct>.

<?xml version="1.0"?> <methodResponse> <fault> <value> <struct> <member> <name>faultCode</name> <value><int>1</int></value> </member> <member> <name>faultString</name> <value><string>Unknown method.</string></value> </member> </struct> </value> </fault> </methodResponse>


14

3.2.2. Comparaison avec SOAP

SOAP a été créé sous les hospices de Microsoft et toujours soutenu par ce

dernier. Le protocole SOAP se montre bien plus populaire et utilisé que son

camarade XML-RPC. Cela principalement grâce au soutient du W3C, mainteneur de

la spécification depuis la version 1.2 du protocole, publiée en 2003. De fait,

aujourd'hui, SOAP est un standard de facto du monde des services Web : un service

se doit d'être au moins accessible par ce protocole.

Toutefois XML-RPC, au niveau des blogs, est le plus utilisé dans les APIs

disponibles. De plus il est bien plus simple que SOAP qui est bien plus complet et

complexe dans son implémentation. Le développement d’une application utilisant

XML-RPC est suffisant pour la gestion d’un blog. Pour un service Web possédant

plus de sécurité et plus de traitements alors on s’orientera vers le protocole SOAP.

3.3. J2ME et Outils de développement

3.3.1. J2ME

3.3.1.1. Introduction

L’objectif de cette partie est de présenter les différentes configurations et

profils de J2ME ainsi que quelques aspects techniques et l’environnement de J2ME.

Aujourd’hui, le nombre de terminaux ‘légers’ (PDA, téléphone…) dépasse

largement celui des ordinateurs personnels (400 millions d’ordinateurs personnels

dans le monde en 2002, un milliard de terminaux ‘légers’ en 2003). 30 à 50 % de ces

terminaux ont une connectivité possible à l’Internet. Il est souvent nécessaire sur ces

terminaux d’installer ou de télécharger de petits logiciels. Les terminaux sont aussi

très différents d’un constructeur à un autre. L’architecture J2ME est devenue la plate-

forme pour le développement de services sur ces terminaux. C’est pour cette raison

que nous l’utilisons dans le cadre de notre projet.


15

Historiquement, Sun a proposé plusieurs plates-formes pour le

développement d'applications sur des machines possédant des ressources réduites

(typiquement, celle qui ne fonctionnait avec J2SE et sa machine virtuelle) :

� JavaCard : pour le développement sur des cartes à puces

� EmbeddedJava : pour le développement de systèmes embarqués

� PersonnalJava : pour le développement sur des machines possédant au

moins 2 Mo de mémoire.

En 1999, Sun propose de mieux structurer ses différentes plates-formes sous

l'appellation J2ME (Java 2 Micro Edition). Par rapport à J2SE, J2ME utilise des

machines virtuelles différentes. Certaines classes de base de l'API J2SE sont

communes avec cependant moins de fonctionnalités dans l'API J2ME.

L'ensemble des appareils sur lesquels peuvent s'exécuter une application

écrite avec J2ME, est tellement vaste que J2ME est composée de plusieurs parties :

les configurations et les profils qui sont spécifiés par le JCP (Java Cummunity

process). J2ME propose donc une architecture modulaire.

Chaque configuration peut être utilisée avec un ensemble de packages

optionnels qui permet d'utiliser des technologies particulières (Bluetooth, services

web, appareil photo, ...). Ces packages sont le plus souvent dépendant du matériel.

L'inconvénient de ce principe est qu'il déroge à la devise de Java "Write Once,

Run Anywhere". Ceci reste cependant partiellement vrai pour des applications

développées pour un profil particulier. La plate-forme J2ME est cependant en

constante évolution du fait du développement exponentiel des technologies mobiles.


16

Le schéma suivant, représente la place occupée par J2ME dans les différents

environnements Java.

Source : Cours de programmation J2ME, Didier Donsez

3.3.1.2. Les configurations

Une configuration définie une machine virtuelle et un ensemble de

bibliothèques minimales pour un ensemble de terminaux qui possèdent des

caractéristiques similaires (taille mémoire, capacité du processeur, …)

Deux configurations sont actuellement définies :

� CLDC (Connected Limited Device Configuration)

� CDC (Connected Device Configuration)

La CDC est spécifié dans la JSR 036 : elle concerne des appareils possédant

des ressources relativement importantes (au moins 2 Mo de RAM, un processeur 32


17

bits, une bonne connexion au réseau) comme par exemple certains PDA "haut de

gamme". Elle s'utilise sur une machine virtuelle CVM.

La CLDC 1.0 est spécifiée dans la JSR 030 : elle concerne des appareils

possédant des ressources faibles (moins de 512 Ko de RAM, faible vitesse du

processeur, connexion réseau limitée et intermittente) et une interface utilisateur

réduite (par exemple un téléphone mobile ou un PDA "bas de gamme"). Elle s'utilise

sur une machine virtuelle KVM (Kuaui Virtual Machine). La version 1.1 est le résultat

des spécifications de la JSR 139 : une des améliorations les plus importantes est le

support des nombres flottants. Dans le cadre de notre projet, c’est cette configuration

qui est utilisée.

3.3.1.3. Les profils

Pour pouvoir fonctionner une configuration doit être complétée par un

« profil » spécifique à un environnement et/ou à un domaine. Un profil représente un

ensemble d’APIs de haut niveau qui définissent un cycle de vie pour les applications,

interface utilisateur, ... Un « profil » correspond à un ensemble d’équipements

similaires. On peut citer par exemple le Mobile Information Device Profile (MIDP) qui

est dédié au téléphone portable. Ce profil va être détaillé par la suite.

3.3.1.4. CLDC (Connected Limited Device Configuration )

Les terminaux ciblés par cette configuration correspondent aux

caractéristiques suivantes :

� 128 à 512 Ko de mémoire

� Processeur 16 et 32 bits

� Terminaux fonctionnent sur batterie

� Communication réseau limitée (9600 Bps en GPRS, 1200 en GSM - CD)

L’objectif de la configuration CLDC est de définir un ensemble de technologies

Java homogènes pour une large gamme de terminaux ayant les contraintes

techniques citées ci-dessus et de permettre la diffusion d’application sur ces


18

terminaux de manières sûres. La construction d’application se fait selon des

architectures 3-tiers.

La configuration CLDC a un domaine de couverture limité. Il prend en charge :

� la machine virtuelle ainsi que le langage Java

� le modèle de sécurité

� les entrées/sorties

� le support du réseau

� l’internationalisation

CLDC ne prend pas en charge :

� le cycle de vie ainsi que l’installation des applications

� le support des interfaces Homme/Machine

� le modèle applicatif de haut niveau

� l’accès aux bases de données

� ces différents aspects sont définis dans des profils comme MIDP

3.3.1.5. KVM (Kuaui Virtual Machine)

La KVM est une petite machine virtuelle construite pour les terminaux

contraints, elle ne fait que quelques dizaines de Ko (40 à 80 Ko suivant les options

de compilation). Elle a été spécialement développée par Sun pour les applications

J2ME, de ce fait elle est partiellement compatible avec la JVM (Java Virtual Machine)

mais avec des restrictions dues aux spécificités de J2ME (ex : pas de gestion des

nombres flottants). CLDC fonctionne sur la KVM.

Il faut aussi noter que plusieurs machines virtuelles ont été développées pour

les applications mobiles ou embarquées. On peut citer par exemple Monty (Sun),

HotSpot (Sun), MicroChaiVM (HP), J9VM (IBM), Waba (licence GPL-GNU).


19

3.3.1.6. Le profil MIDP

C'est le premier profil développé dont l'objectif principal est la création

d'application sur des machines aux ressources et à l'interface limitée tel qu'un

téléphone cellulaire. Ce profil peut aussi être utilisé pour développer des applications

sur des PDA de type Palm. Cependant, les terminaux visés doivent supporter CDLC.

L'API du MIDP se compose des APIs du CDLC et de trois packages :

� javax.microedition.midlet : cycle de vie de l'application

� javax.microedition.lcdui : interface homme machine

� javax.microedition.rms : persistance des données

Il existe deux versions du MIDP :

� 1.0 : la dernière révision est la 1.0.3 dont les spécifications sont issues de la

JSR 37

� 2.0 : c'est la version la plus récente (été 2003) dont les spécifications sont

issues de la JSR 118

Les applications créées avec MIDP sont des midlets : ce sont des classes qui

héritent de la classe abstraite javax.microedition.midlet.Midlet. Cette classe permet le

dialogue entre le système et l'application.

Elle possède trois méthodes qui permettent de gérer le cycle de vie de

l'application en fonction des trois états possibles (active, suspendue ou détruite) :

� startApp() : cette méthode est appelée à chaque démarrage ou redémarrage

de l'application

� pauseApp() : cette méthode est appelée lors de la mise en pause de

l'application

� destroyApp() : cette méthode est appelée lors de la destruction de l'application

Ces trois méthodes doivent obligatoirement être redéfinies.


20

Le schéma suivant décrit le cycle de vie d’une midlet.

Cycle de vie d’une midlet

Les possibilités concernant l'IHM de MIDP sont très réduites pour permettre

une exécution sur un maximum de machines allant du téléphone portable au PDA.

Ces machines sont physiquement pourvues de contraintes fortes concernant

l'interface qu'ils proposent à leurs utilisateurs.

Avec le J2SE, deux APIs permettent le développement d'IHM : AWT et Swing.

Ces deux APIs proposent des composants pour développer des interfaces

graphiques riches de fonctionnalités avec un modèle de gestion des événements

complet. Ils prennent en compte un système de pointage par souris, avec un écran

couleur possédant de nombreuses couleurs et une résolution importante.

Avec MIDP, le nombre de composants et le modèle de gestion des

événements sont spartiates. Il ne prend en compte qu'un écran tactile souvent

monochrome ayant une résolution très faible. Avec un clavier limité en nombre de

touches et dépourvu de système de pointage, la saisie de données sur de tels


21

appareils est particulièrement limitée. L'API pour les interfaces utilisateurs du MIDP

est regroupée dans le package javax.microedition.lcdui.

Avec MIDP, le mécanisme pour la persistance des données est appelé RMS

(Record Management System). Il permet le stockage de données et leur accès

ultérieur. RMS propose un accès standardisé au système de stockage de la machine

dans lequel s'exécute le programme. Le problème est que certains constructeurs

restreignent l’accès aux applications Java, concernant les données stockées

(exemple : le Sony-Ericsson P900).

RMS ne définit qu'une seule classe : RecordStore. Cette classe ainsi que les

interfaces et les exceptions qui composent RMS sont regroupées dans le package

javax.microedition.rms. Les données sont stockées dans un ensemble

d'enregistrements (records). Un enregistrement est un tableau d'octets. Chaque

enregistrement possède un identifiant unique nommé « recordId » qui permet de

retrouver un enregistrement particulier. A chaque fois qu'un ensemble de données

est modifié (ajout, modification ou suppression d'un enregistrement), son numéro de

version est incrémenté.

Pour supporter MIDP, un terminal doit avoir certaines caractéristiques :

� un écran de 96 * 54 pixels

� un clavier ou un écran tactile

� 128 Kb de mémoire non volatile pour les composants de MIDP

� 8 Kb de mémoire non volatile pour les données persistantes

� 32 Kb de mémoire volatile pour le runtime java

� au niveau réseau, une connexion full-duplex, intermittente, sans fils

Cette présentation de J2ME a été restreinte au profil et à la configuration que

nous avons utilisée lors de notre projet. Pour plus d’informations, vous pouvez

consulter les documents utilisés pour rédiger cette partie : Cours J2ME de Didier

Donsez :

� http://developper.java.sun.com/developer/J2METechTips/index.html

� http://wireless.java.sun.com/midp/articles/

� http://www.corej2me.com


22

3.3.2. Outils de développement

Pour développer et tester notre application J2ME, nous avons utilisés certains

logiciels spécifiques. Nous avons eu besoin d’un émulateur de téléphone portable et

d’un outil de développement Java spécifique à J2ME.

3.3.2.1. netBeans IDE 4.0 et netBeans mobility 4.0

Les applications J2ME sont des

applications développées en Java. Nous

avons commencé par regarder sur Internet

les différents outils existants.

Il existe plusieurs IDE, mais pour

notre projet, nous avons retenu une des

solutions de SUN. Cette dernière se

compose du logiciel netBeans 4.0 auquel

nous avons rajouté l’add-on netBeans mobility 4.0.

Ce package est très intéressant car il permet de développer des applications

avec netBeans et ensuite de les tester directement dans un émulateur de téléphone

portable grâce à l’outil Ktoolbar intégré à netBeans.

L'outil Ktoolbar est un petit IDE qui permet de compiler, pré-vérifier, packager

et exécuter des applications utilisant le profil MIDP. Il ne permet pas l'édition du code

des applications : il faut utiliser un éditeur externe pour réaliser cette tâche.

Les fichier générés à la compilation sont un fichier « *.jar » et son descripteur,

le fichier « *.jad ».

Cette solution a été retenue à la fois pour sa simplicité d’installation et son

aisance à la prise en main. Toutefois, l’outil Ktoolbar de « base » ne simule que des

téléphones génériques. Le portable de test étant un Sony-Ericsson P900, nous

avons alors décidé d’utiliser le SDK fourni par Sony-Ericsson dédié aux applications

J2ME.


23

3.3.2.2. Le SDK Sony-Ericsson

Le SDK de Sony-Ericsson fournit

l’outil Ktoolbar permettant de simuler

tous les téléphones de la marque,

supportant des applications J2ME. Pour

le développement des applications,

nous utilisions d’abord netBeans pour

écrire le code et générer les fichiers

« *.jar » et « * .jad ». Ensuite pour tester

l’application, nous utilisions l’outil Ktoolbar aux spécificités de Sony-Ericsson.

Voici un exemple du résultat obtenu sur l’émulateur : Ici, c’est la midlet concernant la

prise de photo qui tourne sur l’émulateur :


24

3.3.2.3. Les autres environnements de développement

Voici quelques autres environnements de développement :

� J2ME Wireless ToolKit de chez Sun

� IBM WebSphere Device Dev

� WabaSDK

� Nokia, Motorola (MERI)

� Docomo NTT (pour les japonais)

� Plus d’informations : http://wireless.java.sun.com/midp/articles/emulators

3.4. Blogs (Nucleus) et les API

Dans le cadre de notre projet, nous avons du choisir un blog avec lequel notre

application communiquera. Nous avons différencié deux catégories de blog. Les

blogs propriétaires et les blogs open source. Les blogs propriétaires sont les blogs

que l’on peut utiliser (gratuitement ou pas), mais que l’on ne peut pas télécharger

afin de l’installer sur un serveur. Les blogs open source sont les blogs dont on peut

télécharger les sources afin d’installer le blog sur un serveur web. Cet aspect là nous

a particulièrement intéressés, car nous pouvions examiner et paramétrer la plate-

forme de blog. De plus, l’entreprise I-SPIRIT pourra héberger les blogs sur ses

propres serveurs, et ainsi ne pas dépendre d’un organisme hébergeant la plate-

forme de blog.

De nombreux blogs open source furent étudiés. Nous avons retenu le blog

Nucleus (http://nucleuscms.org) pour les raisons suivantes :

� Facilité d’utilisation

� Utilisation de la technologie PHP/MySql

� Fonctionnement sur la majorité des serveurs gratuits (dont notre serveur de

test hébergé par Free)


25

Nucleus dispose également d’autres avantages agréables, tel que l’installation de

skins, de divers plugins, etc.…

Le plus gros avantage de Nucleus est qu’il implémente la Blogger API, la

metaWeblog API et la Movable Type API

(cf. http://nucleuscms.org/documentation/devdocs/xmlrpc.html). Ceci signifie que

Nucleus possède une interface standardisée lui permettant de communiquer avec la

plupart des outils et services utilisant ces mêmes APIs. Par exemple, le logiciel

w.bloggar cité précédemment utilise la Blogger API. Cela signifie qu’il peut

communiquer avec tous les blogs qui possède la Blogger API, donc avec tout les

blogs Nucleus.

La majorité des blogs implémentent des APIs. Les 3 principales APIs sont

comme nous venons de le voir :

� Blogger API (http://www.blogger.com/developers/api/1_docs)

� metaWeblog API (http://www.xmlrpc.com/metaWeblogApi)

� Movable Type API

(http://www.sixapart.com/movabletype/docs/mtmanual_programmatic)

L’intérêt que les plates-formes de blogs ont d’implémenter ces APIs, est de

permettre à des programmes/outils/services externes utilisant ces même APIs de

pouvoir communiquer avec le blog (c’est à dire envoyer des commandes au blog afin

de lui poster un article, d’éditer un article, etc.) Voici un exemple de services

proposés par ces APIs :

� blogger.newPost : Permet de poster un article sur un blog

� blogger.editPost : Permet d’éditer un article d’un blog

� metaWeblog.newMediaObject : Permet de déposer un média (un image par

exemple) sur un blog

Historiquement, la Blogger API a été la première mais elle a montré ses

limites et metaWeblog a été développée pour ajouter de nouvelles fonctionnalités,

cela en ré-implémentant les mêmes méthodes de base.


26

Comme le but de notre projet est de pouvoir envoyer du texte et des images,

nous nous intéresseront plus particulièrement à metaWeblog, car c'est la seul API

qui permet de transférer des objets médias, c’est à dire des images par exemple.

L’interface XML-RPC du blog Nucleus est à l’adresse :

http://www.yourserver.com/yourpath/nucleus/xmlrpc/server.php

C’est à dire que notre application devra se connecter à cette adresse afin de

communiquer avec le blog. Elle pourra alors envoyer des commandes des APIs

précédemment citées afin de poster, éditer, etc. des articles.

Afin de mieux connaître les blogs, nous vous conseillons de consulter

l’encyclopédie Wikipedia (http://en.wikipedia.org/wiki/Weblogs)

3.5. kXML-RPC

Nous avons choisi d’utiliser le protocole de communication basé sur XML-RPC

car il est utilisé par les serveurs de blog. Il fallait trouver une librairie écrite en Java

J2ME capable d’offrir les fonctionnalités de base pour que la communication entre

serveur de blog et mobile soit possible. Il fallait également que cette librairie soit

open source pour pouvoir l’utiliser dans le cadre de notre projet professionnel.

kXML-RPC répond à ces exigences et est relativement simple d’utilisation. La

librairie s’occupe, en effet, de tout. Après avoir spécifié les paramètres de connexion

du blog (URL, login et mot de passe), le nom de la méthode RPC (getPosted,

getRecentPosts, etc.) ainsi que leurs paramètres éventuels (chaîne de caractères,

tableau d’octets, etc.), une méthode execute de la librairie se charge d’encoder le

tout en XML-RPC et de l’envoyer au serveur via le protocole HTTP. Cette méthode

se charge également de la réception de la réponse du serveur et du décodage de la

trame XML reçue. Cela peut paraître très intéressant mais la phase de

développement révélera, dans cette librairie, des bugs relativement longs à corriger.


27

La librairie offre également des fonctionnalités plutôt intéressantes telles qu’un

outil pour lire et écrire des dates au format ISO, un outil permettant d’encoder et de

décoder un tableau d’octet au format Base64.

Au jour où ce rapport a été écrit c’est la seule librairie open source, destinée à

J2ME, documentée, capable d’offrir toutes ces fonctionnalités. Le site officiel d’XML-

RPC conseille même sont utilisation avec l’API de metaWebBlog et le serveur de

blog Nucleus.


28

4. Déroulement de la mission 4.1. Planning


29

4.2. Etude UML


30

4.3. Avancement et difficultés

L’utilisation de J2ME était pour l’ensemble de l’équipe une expérience

totalement nouvelle. L’approche Micro Edition conserve les atouts de Java Standard

Edition ce qui a permis de développer sans changement fondamental dans la

manière de programmer. Le passage par les tutoriaux a été indispensable pour

découvrir et apprendre les principes de J2ME.

Afin de concevoir l’application de moblogging il fallait séparer différents aspects :

� Communication avec le blog

� Interface utilisateur

� Stockage des préférences

� Récupération d’une image sur le téléphone

� Envoi d’une image à partir du téléphone

� Organisation modulaire de l’application

Les parties actuellement fonctionnelles sont :

� Réception de post sous forme de texte brut et avec images

� Envoi de post sous forme de texte brut

� Stockage de la configuration

� Interface utilisateur

4.3.1. Communication

La communication entre le blog (serveur web) et le téléphone mobile se fait

via XML-RPC. La librairie kXML-RPC écrite en J2ME implémente les fonctionnalités

pour utiliser ce protocole de communication. Cependant cette librairie date de 2002,

et depuis la compagnie Sun a fait énormément évoluer le J2ME. Par conséquent lors

des premiers tests de cette librairie nous avons eu pas mal de problèmes.


31

Le premier problème n’est pas uniquement présent dans la librairie kXML-

RPC. En effet de nombreux exemples d’initiation (d’accès au réseau avec J2ME)

trouvés sur Internet ne fonctionnent pas, il en va de même pour ceux sur le site

officiel de Sun. En effet les spécifications de développement ont changé et il n’est

pas possible de faire fonctionner le même code source avec le WTK 1 et le WTK 2. Il

faut donc maintenant utiliser un thread pour l’accès au réseau sous peine de blocage

complet de l’application. Toute classe développée utilisant la librairie kXML-RPC doit

donc implémenter impérativement Runnable.

D’autres bugs ont du être corrigés dans la librairie. Des problèmes pour la

lecture de la date, pour le décodage des trames XML-RPC, etc. rendaient l’utilisation

de ces fonctionnalités impossible. Les sources des fichiers n’étant pas tous

disponibles en téléchargement sur le site, il a fallu procéder à une phase de

décompilation des fichiers .class afin de corriger tous les bugs constatés. Pour rappel

cette librairie est entièrement open source.

Cette librairie est à présent fonctionnelle, du moins pour les parties que nous

avons utilisé.

4.3.2. Interface utilisateur

L’application demandée par l’entreprise devait avoir une interface la plus

simple possible afin qu’elle soit reprise par des designers. L’objectif était d’avoir une

interface facilement adaptable pour tel ou tel téléphone.

Afin de prendre en compte cette exigence, nous avons séparé au maximum

l’interface, du traitement des données. Cette façon de procéder permet également de

faciliter la maintenance du programme, ainsi que son évolution.


32

L’organisation de l’interface est réalisée de cette manière :


33

4.3.3. Stockage des préférences

Le stockage des préférences est nécessaire pour indiquer quelle est l’adresse

du blog de l’utilisateur, son login et son mot de passe. L’intérêt est simple : éviter à

l’utilisateur de ressaisir à chaque fois toutes ses informations.

Grâce à la librairie de J2ME (javax.microedition.rms) il est possible de stocker

ces données dans la mémoire du téléphone et de les lire par la suite. La librairie

Record Management System (RMS) permet de conserver la configuration même si

l’utilisateur éteint le téléphone, ou même s’il recharge la batterie.

4.3.4. Récupération d’une image sur le téléphone

Afin de pouvoir lire le contenu du post dans son intégralité, il est intéressant

de récupérer les images postées sur le blog et de les visualiser sur le téléphone. Le

système idéal serait d’avoir un interpréteur HTML sur le téléphone afin de pouvoir

afficher le post dans l’état où il se trouve sur le blog. En d’autres termes, il faudrait

pouvoir écrire en gras lorsque l’on trouve des balises <b></b> ou encore écrire du

texte souligné lorsque l’on trouve des balises <u></u>. Mais ce type d’exercice serait

plutôt fastidieux et dépasse largement le cadre de travail dans lequel nous évoluons.

Une recherche plus poussée de code open source permettrait peut être d’intégrer ce

système facilement. Nous nous sommes donc limités à l’interprétation de la balise

<img src= "…" >. Par conséquent le texte et les images sont affichés dans l’ordre

dans lequel ils se trouvent sur le blog.

La récupération du post est réalisée via le protocole XMLRPC, par contre

l’image est téléchargée directement depuis la source indiquée dans la balise via le

protocole HTTP sans passer par XMLRPC.


34

Pour résumer, le téléphone reçoit une trame XMLRPC, l’analyse, puis va

chercher les images comprises dans le post via HTTP. Ci-dessous un schéma

représentant les échanges :

Echange entre le téléphone te le serveur de blog

Requête de récupération du post (XML-RPC encapsulé dans http)

Réception du texte du blog (XML-RPC encapsulé dans http)

Requête de récupération d’une image (http)

Réception de l’image (http)

Tant qu’il y a des images à récupérer dans le post

Téléphone mobile (P900)

Serveur de blog (Nucleus)


35

4.3.5. Envoi d’une image à partir du téléphone

Ce point est problématique en particulier sur le téléphone Sony-Ericsson

P900. Cette opération se passe en deux phases : la récupération d’une image, puis

l’envoi. Il y a deux possibilités pour réaliser ce point :

� soit il faut accéder à la mémoire du téléphone et lire les images stockées dans

le système de fichiers à partir de l’application Java,

� soit il faut prendre directement la photographie à partir du programme Java.

Pour la première solution la librairie Java RMS ne permet d’accéder qu’à des

enregistrements réalisés par un programme Java, et pas au système de fichiers. De

toute manière les membres de l’équipe Sony-Ericsson ont publié sur le forum de

développement d’applications Java pour leurs mobiles qu’il n’est pas possible

d’accéder à la mémoire du téléphone. Il n’est donc pas possible de naviguer dans

l’arborescence des répertoires du téléphone pour en récupérer les fichiers

multimédias.

Liens vers le forum de développement de Sony-Ericsson :

� http://developer.sonyericsson.com/show_thread.do?forumId=10&threadid=165

02

� http://developer.sonyericsson.com/show_thread.do?sortDirection=1&ps=50&th

readid=14914&sortDirection=0&sortCol=MSG_AUDIT_MOD_DT&forumId=

� http://developer.sonyericsson.com/show_thread.do?sortDirection=1&ps=50&th

readid=14524&sortDirection=0&sortCol=MSG_AUDIT_MOD_DT&forumId=10

&readOnly=false

Cependant il est possible pour les autres téléphones (PDA ou Smart phone

dernière génération) d’accéder au système de fichiers en utilisant cette librairie

supplémentaire : PDA profile for J2ME (JSR 75). Il faut cependant faire remarquer

que cette librairie n’est pas prise en compte par défaut sur la majorité des machines

virtuelles des téléphones et que son utilisation limiterait la portée de l’application à

quelques rares mobiles très haut de gamme.

Une solution pour contourner ce problème serait de mettre à jour le firmware

(système logiciel propre au téléphone), afin d’y ajouter la librairie dont on a besoin.


36

La machine virtuelle Java du mobile serait donc dotée des dernières fonctionnalités

offertes par Sun. Et là aussi un problème se pose car les opérateurs (Orange, SFR,

Bouygues) bloquent leurs téléphones afin d’éviter leur utilisation avec des opérateurs

concurrents. Mettre à jour le firmware signifierait par conséquent faire sauter la

protection des opérateurs, une opération qui serait plutôt limite pour la

commercialisation du projet et un peu trop fastidieuse pour le consommateur. La

question ne se pose pas pour le P900 étant donné que le constructeur ne donne pas

de mise à jour pour la raison évoquée précédemment.

La deuxième solution qui consiste à prendre une photo au moment d’envoyer

le post serait donc plus intéressante. Mais là aussi différents problèmes empêchent

l’implémentation de cette fonctionnalité. Nous avons donc développé une application

Java pour prendre des photos directement à partir de celle ci. L’application

fonctionne, mais une fois de plus uniquement sur l’émulateur. Le P900 n’a pas la

machine virtuelle adéquate pour interpréter le code généré pour cette application. Ce

problème a d’ailleurs été reporté sur le forum du constructeur qui a confirmé

l’absence de la librairie (javax.microedition.media.control.VideoControl).

Le problème n’est cependant pas complètement fermé étant donné que nous

avons réussi à prendre des photos sur l’émulateur et nous avons réussi à envoyer

une photo sur le blog de test via XMLRPC. En regroupant les deux parties il sera

facilement possible d’ajouter cette fonctionnalité à l’application, même si elle ne peut

pas être prise en compte par le P900.

De plus l’API de Nucleus permet d’envoyer des fichiers multimédias sur le

blog, et il est donc possible d’envoyer de la vidéo en modifiant très peu de choses

par rapport au code d’envoi d’images.

Des applications manipulant les images sont pourtant bel et bien disponibles

pour le P900. Après une recherche sur ce sujet il s’avère que ces applications sont

développées en C++ et sont destinées à quelques rares téléphones. Ces

applications sont distribuées avec l’extension « .sis». La portabilité de ces

applications ne convient pas à notre projet, et inclure ce type d’accès à la mémoire

réduirait tous nos efforts de portabilité de l’application au P900.


37

4.3.6. Organisation modulaire de l’application

Le projet Life Goes Mobile doit être ouvert à de futures améliorations. Une

organisation modulaire de l’application est donc indispensable afin de le faire

évoluer. Afin de permettre l’ajout de fonctionnalités nous avons trois types de

modules différents : la partie menu principal, les modules de connexion au blog avec

l’interface qui leur sont liés et le module de configuration.

Les modules de connexion au blog sont particulièrement intéressants étant

donné que l’API de metaWeblog implémentée par Nucleus propose plusieurs

fonctionnalités qui n’ont pas toutes été exploitées.

Le code a été documenté afin d’expliquer et de spécifier comment ajouter un

module à l’application.

Organisation générale de l’application

Fichiers Nom module Implémentation

Traitement Interface Librairie

Module

interface

principale

Menu principal Kxmlrpc_demo.java Kxmlrpc_demo.java

Réception de post Getposted.java

ImageReader.java Getposted.java

Envoie de post NewPost.java NewPostInterface.java Module de

connexion Réception des posts

récents (beta) GetRecentPost.java GetRecentPost.java

kXMLRPC

Module

configuration

Enregistrement/lecture

des paramètres de

connexion

MemoryAcces.java Ps.java


38

5. Conclusion

Le bilan de ce projet professionnel est très positif, tant au niveau de

l’expérience qu’ils nous a apporté que de la finalité de l’application.

En effet nous avons pu collaborer à un projet où nous avons mis en œuvre

nos compétences en informatique et en gestion de projet acquises lors de notre

formation à l’Université des Sciences de Corte. Nous avons aussi appris de

nouveaux concepts informatiques liés au monde des blogs et du moblogging. Tous

ces faits nous ont été donc très bénéfiques pour notre expérience professionnelle.

De plus l’application développée est un prototype qui permettra à I-SPIRIT de

finaliser et de commercialiser un logiciel. Nous avons donc réussi à concevoir et

réaliser un projet concret en collaboration avec une société informatique.

Nous avons réussi à partager notre temps entre les cours dispensés lors de

notre formation en Master 2 ISI et la réalisation de ce projet professionnel ce qui n’a

pas été chose facile. La répartition de la masse de travail et des différentes tâches a

aussi posée des problèmes en cours de projet mais nous avons su y remédier grâce

à une bonne gestion de projet, ainsi qu’à une bonne communication entre les

différents membres de l’équipe.

A la vue de ces différents éléments, nous pouvons conclure que ce projet a

été une réussite pour les deux partis.


39

6. Glossaire

� Blog : Journal numérique accessible sur le web. L’activité de mettre à jour son

blog s’appelle « blogging » et les personnes qui possèdent un blog sont des

bloggers. Les blogs sont typiquement mis à jour tous les jours en utilisant des

logiciels (par exemple w.bloggar) ou directement sur la toile en utilisant une

interface d’administration incluse dans le blog. Les articles postés sur un blog

sont classés par ordre chronologique (les plus récents en haut de page) et

sont le plus souvent enrichis de liens externes.

� Moblogging : Toute activité, qui a lieu en dehors de l'endroit habituel où vous

blogguez, et dont l'objectif est de créer du contenu pour votre blog.

� RPC : Principe d’appel de procédure type client/serveur s’exécutant sur une

machine distante dans un environnement d’applications distribuées. Ce n’est

pas un standard et il existe de nombreux types de RPC dont Sun RPC, qui est

la base de l’accès aux fichiers distants NFS, mais aussi XML-RPC pour les

services Web, par exemple. Terme français : Appel de Procédure Distante.

� JSR (Java Specification Request) : Descriptions des propositions ainsi que les

spécifications finales concernant la plate-forme Java. A n’importe quel

moment, il existe un certain nombre de JSRs évoluant dans les processus de

consultation ou d’approbation.


40

7. Références Webographie

Voici par catégorie des liens sur notre projet :

Outils utilisées pour ce projet :

� J2ME : http://java.sun.com/j2me/

� WTK : http://java.sun.com/products/j2mewtoolkit/download-2_1.html

� XML-RPC : http://www.xmlrpc.com

� kXML-RPC : http://kxmlrpc.objectweb.org/

� blog Nucleus : http://nucleuscms.org

� Différentes APIs :

o Blogger API (http://www.blogger.com/developers/api/1_docs)

o metaWeblog API (http://www.xmlrpc.com/metaWeblogApi)

o Movable Type API

(http://www.sixapart.com/movabletype/docs/mtmanual_programmatic)

Articles sur les blogs et le moblogging :

� http://www.pointblog.com/past/cat_moblogging.htm

� http://archive.scripting.com/2004/09/19#whatIsMoblogging

� http://www.liberation.fr/page.php?Article=239724

� http://www.pointblog.com/past/000014.htm

� http://www.mobinaute.com/mobinaute/article.php?id=20040909135512

� http://www.outilsfroids.net/news/17.shtml

Sites qui proposent des services de moblogging :

� http://www.blogger.com (Gros site de blog - USA)

� http://phonit.snyke.com (Moblogging audio)

� http://www.typepad.com (USA: Il font pas mal de partenariat pour d'autres

sites web qui veulent un services de blog (ex: neuf telecom) )


41

� http://www.kaywa.com (Suisse)

� http://www.orange.fr/0/visiteur/PV (Voir blog)

� http://www.futublog.com (Finlande)

� http://www.blogg.org + son aide pour les fonctionnalités

� http://www.blogg.org/blog-1.html

� http://www.20six.fr

Logiciels pour le moblogging :

� http://www.tektonica.com/projects/moblog

� http://www.bitsplitter.net/vagablog

� http://www.atomiclava.net avec un article sur lui ici

� http://www.nokia.com/nokia/0,,59756,00.html

� Et bien, sur le meilleur pour la fin : http://www.i-spirit.fr/lifegoesmobile

Sites web qui nous ont aidés lors du projet :

� http://defaut.developpez.com/tutoriel/java/j2me

� http://developpeur.journaldunet.com/tutoriel/jav/020129jav_j2me1_1.shtml

� http://www.j2me.org

� http://developer.sonyericsson.com/site/global/home/p_home.jsp

� http://www.labo-sun.com/index.jsp?actionId=11&docId=196&technoArticle=1

Rapport de Projet Professionnel - Freejultey.free.fr/blog/uploads/univ.decorse/lgm_rapport.pdf ·...

Documents

Transcript of Rapport de Projet Professionnel - Freejultey.free.fr/blog/uploads/univ.decorse/lgm_rapport.pdf ·...