Le marché des téléphones mobiles est un domaine extrêmement fragmenté avec des disparités significatives :

·   les systèmes d’exploitation mobiles langages de programmations sont très différents les uns des autres ; par exemple Symbian, RIM, iPhone, Android, WinPhone et même propriétaires pour Samsung et LG

·   les téléphones mobiles de fabricants différents, même basés sur un système d’exploitation commun, ont des spécificités propriétaires ; par exemple le système d’exploitation Symbian dont sont dérivées la plateforme Nokia S60 et la plateforme SonyEricsson JP8

·   les modèles de téléphones chez un même fabricant, donc basés sur la même plateforme, ont également des caractéristiques différentes ; par exemple RIM OS 5.0 affiche les éléments graphiques différemment de RIM OS 4.7 à partir des mêmes commandes

L’objectif de U***** étant de supporter le plus grand nombre possible de modèles de téléphones portables avec un coût de R&D minimal, plusieurs voies de résolution de cette fragmentation ont fait l’objet d’études à approfondies afin d’en retenir tout ou partie pour construire la solution la plus optimale. Le but étant de faire évoluer la version 1 de l’applet développée selon le modèle JME pour aboutir à une version 2 supportant de la manière la plus générique possible la fragmentation du domaine des plateformes de téléphonie mobile.

Outil de développement générique.

Les premières analyses des outils de développement générique disponibles sur le marché (par exemple MobileDistillery, JMEPolish, OpenPlug) n’ont pas permis d’identifier un produit supportant toutes les caractéristiques recherchées. Par exemple l’accès aux identifiants radio-cellulaire et Wifi n’est pas présent or c’est une fonction structurantes des algorithmes U******. De même, le support générique de plateformes multiples n’est soit pas entièrement automatisé soit délégué à des sociétés tierces. Enfin, ces environnements sont plus adaptés aux traitements graphiques complexes nécessaires à la plupart des logiciels embarqués autonomes par rapport à U***** qui n’utiliserait qu’une fraction de leurs fonctions. Cette voie est donc pour le moment laissée de coté tout en continuant une veille technologique sur le sujet.

Centralisation des fonctions.

Il est évident que toutes les fonctions ne peuvent être centralisées au niveau du serveur. Les fonctions d’économie d’énergie, de collecte et surveillance des indications de localisations des différentes sources du modèle hybride doivent impérativement résider au niveau de l’application embarquée sur les téléphones mobiles. Toutefois toute activité de développement devra respecter ce principe fondamental : ne conserver sur l’application mobile que les fonctions nécessaires et suffisantes. Toute autre fonction actuellement implantée au niveau de la version 1 de l’applet et identifiée comme étant transposable sur le serveur central sera migrée afin de minimiser la dépendance aux spécificités des variantes de plateformes mobiles.

« Componentisation » de l’applet et architecture selon le modèle objet.

La version actuelle de l’application embarquée a été structurée de façon à pouvoir s’adapter aux variantes des différentes plateformes de téléphone mobile à supporter. Toutefois une recherche de l’amélioration de son architecture visant à améliorer sa « componentisation » et à tirer partie de la puissance du modèle objet supporté par Java est sans doute l’axe de travail le plus prometteur. L’objectif sera d’isoler les dépendances par rapport à la plateforme ainsi que les appels aux API spécifiques matérielles afin de les masquer à la partie générique de l’application embarquée par une couche d’abstraction (HAL – Hardware Abstraction Layer).

Les interfaces spécifiques aux plateformes utilisées sont :

·   formatage des éléments graphiques affichés à l’écran en fonction de sa taille et définition (texte, icon, URL, listes, centrage horizontal et vertical, boutons actifs)

·    accès aux zones mémoires permanentes pour enregistrement d’information utilisateur

·   accès aux identifiants radio cellulaires des réseaux mobiles (MCC, MNC, AC, CID)

·   accès aux identifiants point d’accès des réseaux Wifi (SSID)

·   certificats d’authentification et permissions d’accès aux ressources réseau data (communication http), de localisation par GPS, de redémarrage automatique de l’application au « boot » du téléphone

·   adaptation du modèle de programmation (listener, provider et callback) dans le cas de non support du modèle JME

·   intégration à Java d’autres langages de programmation (C++, C#, ObjectiveC) rendus nécessaires pour accéder à des fonctions non supportées en Java par la plateforme cible (e.g. l’accès aux identifiants radio-cellulaires pourrait nécessiter l’écriture de routines en C++)

Le cœur de l’applet qui devra rester commun à toutes les plateformes supportées est constitué de :

·   la logique d’enchainement des écrans et la disposition de chaque écran

·   les algorithmes d’économie d’énergie, de détection de mouvement et d’adaptation dynamique du positionnement du mobile en fonction de sa vitesse

·   les communications à différents niveaux de priorités et endurcies avec le serveur central

Intégration de packages « open source » sous licence GPL.

Toujours dans le but de minimiser les coûts de R&D il sera fait massivement appel à l’open source sous licence GPL pour remplacer des développements spécifiques.

Le premier candidat à l’intégration de packages open source concerne l’IHM de l’applet. L’objectif est d’uniformiser l’interface utilisateur sur tous les téléphones supportés de la manière la plus générique possible.

Des packages tels que « Lightweight User Interface Toolkit – LWUIT » (http://java.sun.com/javame/technology/lwuit/) ou bien Light-Weight Visual Component Library – LwVCL (http://lwvcl.com/j2me.php) seront évalués pour en sélectionner un qui sera intégré à l’applet afin d’en construire toute son IHM.

D’autres packages open sources concernant d’autres fonctions pourront faire l’objet de recommandations mais ne seront pas intégrés à cette étape.

Volumétrie de l’applet version 1 et objectifs de la version 2.

L’applet version 1 a été développée en Java suivant le modèle de programmation JME.

L’applet version 1 est constituée de :

·   1 package

·   19 fichiers sources java

·   22 classes

·   7 300 lignes de code

·   5 unités de données protocolaires par HTTP

·   11 écrans avec éléments de type texte, listes, boutons, images, …

·   1 record store

·   3 user defined JAD attributes

L’applet version 1 fait appel aux spécifications suivantes :

·   JSR-118 MIDP 2.0

·   JSR-139 CLDC 1.1

·   JSR-179 Location 1.0

La version 2 devra supporter les mêmes versions que la version 1 et sera validée sur les modèles de téléphones suivants :

·   BlackBerry Bold 9000, 9700

·   BlackBerry Curve 8310, 8900

·   BlackBerry Pearl 8110

·   HTC Magic

·   HTC Desire

·   LG Arena KM900

·   LG Viewty Smart

·   LG GW620

·   Nokia 6700 Classic

·   Nokia E71

·   Nokia N97

·   Samsung Jet S8000

·   Samsung Galaxy

Le code source de la version 1 et le document d'architecture de haut niveau correspondant seront fournis au prestataire au départ du projet ainsi que des comptes de tests sur le serveur central.

De même le prestataire effectuera des livraisons hebdomadaires en fonction de l'état d'avancement du projet: document d'architecture, copies d'écrans simulayeurs ou photos d'écran de téléphones, source code de la version 2 intermédiaire et final.

Commentaire de l'administrateur :

1. Ce projet a fait l'objet d'une validation par téléphone par un administrateur ProgOnline. Il est sérieux, et a de grandes chances de se concrétiser, à condition de recevoir des offres pertinentes de la part des prestataires.
2. Le client est : une société d'ingénierie informatique.
3. Le client affirme souhaiter concrétiser son projet à la fin du mois de septembre.
4. Informations complémentaires :

• Le client possède un applet pour téléphones portables développé en JAVA et souhaite créer une version qui supporter par d'autres modèles de téléphones portables.
• Le client fournira au prestataire le cahier des charges la version 2 de l'applet.
• Compétences exigées :
• Maîtrise des langages C++, C#, ObjectiveC et JAVA
• Connaissance des spécifications JSR-118 MIDP 2.0, JSR-139 CLDC 1.1, JSR-179 Location 1.0
• Utilisation de packages Open Source
• Estimation de la charge de travail : 2 mois
• Mission en télétravail.