Introduction▲
Poursuivant notre tour d’horizon des solutions en mode déconnecté pour 4D, nous revenons sur la technologie Flash pour présenter un exemple de client pour PocketPC : la déclinaison Microsoft des assistants personnels.
La combinaison client Flash-serveur 4D a déjà été présentée dans une note technique que nous vous invitons à relire :
Connexion d’une application 4D avec Flash Macromedia (4D-200410-30-FR)
L’exemple de collaboration Flash/4D que nous présentons dans cette note diffère sur deux points majeurs :
· il cible un déploiement sur PDA (Personal Digital Assistant) de type PocketPC et non sur ordinateurs de type desktop ;
· la connectivité s’effectue par un protocole propriétaire échangeant du XML au-dessus de HTTP et non par un service Web de type SOAP.
Problématique des PDA et smartphones▲
Développer pour les mobiles ?▲
La question de la manière de réaliser des clients pour périphériques mobiles de type PDA et smartphones revient souvent. Aucune solution spécifique à 4D n’existe et la réponse au problème est loin d’être simple : les types de processeurs varient, les systèmes sont très différents, Microsoft Mobile, PalmOS, Symbian, Linux…
Suivant le type de périphériques ciblés, l’environnement de développement sera souvent fourni par Microsoft (avec sa plateforme Windows Mobile et Visual Studio) ou par SUN avec Java.
Flash pour mobiles ?▲
Les possibilités de la technologie Flash dans ce domaine sont souvent méconnues, car Macromedia, et maintenant Adobe depuis le rachat survenu en 2005, n’ont pas toujours une ligne directrice très claire et constante dans ce domaine.
En résumé, deux offres cohabitent pour les mobiles :
· Flash pour PocketPC ;
· FlashLite pour smartphones et Pocket PC compatibles Windows Mobile 5.0 (Treo 700W, QTek 9000, QTek 9100…).
La différence entre les deux offres tient principalement au type de player supporté, donc à sa compatibilité avec le langage ActionScript et les composants d’interface proposés dans l’environnement de développement.
Pour plus d’informations, consultez le site d’Adobe.
Avec la version FlashLite 2.1, Adobe propose une mouture prometteuse, compatible Flash 7 et Windows Mobile 5.0.
Connecté ou déconnecté▲
Une fois déterminé le type de mobile cible, l’environnement de développement, reste à gérer la caractéristique principale du périphérique : sa mobilité !
Ainsi, votre application peut imposer de ne fonctionner qu’en mode connecté, ce qui empêche son utilisation en toute circonstance et indépendamment du lieu et augmente son coût d’exploitation puisqu’il faut payer les frais de communication entre le mobile et le réseau d’entreprise.
À l’inverse, si vous choisissez un fonctionnement en mode déconnecté, les contraintes ci-dessus sont levées, mais vous en rencontrez de nouvelles :
· stockage des données sur le périphérique mobile ;
· synchronisation des données avec le serveur d’entreprise.
Particularités du développement pour PocketPC▲
Quoiqu’extraordinairement riche en fonctions, un PocketPC n’est pas un ordinateur de bureau :
· Faible résolution d’écran : la plus répandue 240x320 pixels
· Taille d’écran petite : 3''5 à 4''
· Processeur peu puissant : 400 MHz
· Interface utilisateur : stylet, écran tactile, rarement un clavier
· Capacités de stockage limitées : RAM, Compact Flash, SD Card…
· Modes de communication variables : GPRS : 30 to 50 Kbps, 802.11b or Wi-Fi : 11 MB/s, Bluetooth 1.0 : 768 Kbps …
Conclusion▲
La préparation d’un développement pour périphérique mobile requiert beaucoup de préparation et chaque choix doit être effectué en tenant compte de ses implications. Refuser de faire l’impasse sur certaines orientations peut conduire à rechercher la résolution de la quadrature du cercle !
Préparation de notre projet▲
Nos choix techniques▲
Nous allons nous intéresser ici uniquement à la cible PocketPC. Nous nous restreindrons au parc des PocketPC fonctionnant au minimum sous Windows Mobile 2003.
Nous effectuons le choix de l’outil de développement Flash, en visant le maximum de compatibilité avec la version la plus récente du player fourni par Adobe.
Nous choisissons un fonctionnement en mode connecté. Nous devrons nous assurer que ce fonctionnement est compatible avec au minimum une connexion de type GPRS. Notre application Flash sera hébergée dans une page HTML et s’exécutera dans le contexte du navigateur Pocket IE (équivalent d’Internet Explorer pour PocketPC).
Autrement dit, nous nous plaçons dans le contexte d’une entreprise maîtrisant sa flottille de PDAs et désirant proposer à ses collaborateurs mobiles une extension des fonctionnalités disponibles sur l’application 4D tournant sur leurs ordinateurs. Nous ne traitons pas de la réalisation d’une application verticale devant fonctionner sur tout type de périphérique. Une orientation vers FlashLite serait sans doute une meilleure solution…
Le cahier des charges▲
Nous allons prendre comme exemple la réalisation de deux formulaires permettant à un utilisateur nomade :
· de connaître ses rendez-vous ou évènements par date ;
· d’ajouter un rendez-vous ou évènement à une date donnée.
Notre objectif n’est pas de fournir une application finalisée, mais de présenter les technologies de développement et de communication. Nous ferons ainsi l’impasse sur de nombreux points :
· stockage de données locales pour le mode déconnecté ;
· finalisation de l’interface (optimisation, aspect graphique…) ;
· fonctionnalités réelles nécessaires (authentification, modification - consultation - suppression des rendez-vous déjà saisis…)
Gestion des échanges entre Flash et 4D▲
L’application Flash s’exécutant dans le contexte d’un navigateur, deux types de connectivité sont possibles avec 4D :
1. Mode semi-connecté par échanges de messages http ;
2. Mode connecté par utilisation de XML socket TCP.
Dans notre exemple, nous avons retenu le mode semi-connecté au-dessus de HTTP. Des contraintes de « temps réel » ou de partage d’informations entre plusieurs utilisateurs connectés simultanément peuvent orienter vers l’utilisation des XML sockets. Nous y reviendrons peut-être dans le cadre d’une autre note technique !
Nous devrons donc disposer d’un moteur 4D disposant d’une licence serveur http et d’une couche serveur http active.
Échanges de messages via http▲
Il est possible d’échange des messages plus ou moins formalisés au travers de requêtes http de type POST :
1. Requêtes http classiques véhiculant des variables textes, comme entre un navigateur et un serveur Web ;
2. Requêtes http véhiculant des données structurées en XML ;
3. Requêtes http à la structure formalisée par des spécifications précises et publiques, par exemple dans le cadre de service Web SOAP.
Nous nous placerons dans le cas 2, les échanges véhiculant des données structurées en XML.
Pourquoi ne pas utiliser SOAP ?▲
SOAP est très adapté aux échanges entre des clients et des serveurs qui ne se connaissent pas. Ses atouts principaux sont l’interopérabilité et la simplicité de mise en œuvre. Cela se paie par un supplément d’information devant transiter sur le réseau : l’enveloppe SOAP, au format XML, alourdit la communication et implique une consommation accrue de ressources pour l’analyse et la constitution des messages.
Ces considérations, transparentes en général dans un contexte d’intranet entre ordinateurs, peuvent se révéler importantes dans le cadre d’échanges avec un mobile au processeur lent, aux ressources physiques limitées et où la communication est facturée à l’octet échangé ! Quoique le mode d’échanges 1 soit certainement le plus économe, nous avons choisi un compromis avec le mode 2.
Une autre considération est spécifique à 4D. La couche serveur SOAP de 4D fonctionne comme une boîte noire qui ne fournit pas de point d’entrée au développeur. En particulier, la conversion en messages SOAP de structures XML n’est pas optimale de sorte qu’un fonctionnement plus bas niveau offrira un meilleur contrôle sur les opérations effectuées.
Préparation de l’environnement de développement▲
Avant de commencer, il nous faut réunir les éléments nécessaires.
L’équipement▲
Adobe - Macromedia Flash 8 Pro
Pour le développement du client Flash, il faut disposer de l’IDE Flash 8 Pro :
http://www.adobe.com/fr/products/flash/flashpro/
Le Flash Player
Le Flash player pour PocketPC est disponible gratuitement en version 7 depuis avril 2006 :
http://www.adobe.com/products/flashplayer_pocketpc/
Cette version n’est pas redistribuable, elle n’est fournie gratuitement qu’aux développeurs.
Elle ne peut être exécutée que dans PocketIE (et pas dans les autres navigateurs pour PPC). Il n’existe pas, au moment de cette rédaction, de version standalone (prévue dans le Flash Player7 Pocket PC Distribution Kit). Les PocketPC supportés sont ceux compatibles Windows Mobile 5 et Pocket PC 2003 OS.
Parmi les améliorations apportées par Adobe par rapport au player 6 :
· Support du Flash Player 7 ;
· Support d’Action Script 2 ;
· Support de XML socket ;
· Web services et SOAP API.
À titre de comparaison, la version courante du player Flash pour Windows et OSX est la 8.5, sortie avec Flex et compatible avec la version Studio 8. Malheureusement, la version mobile a toujours du retard.
Vérification de l’installation▲
Nous utilisons une toute petite application Flash pour vérifier que le player est bien installé et fonctionnel sur le PocketPC.
L’application Rdv.4DB doit être lancée avec 4D 2004, son serveur http démarré et accessible. On ouvre Internet Explorer sur le PocketPC, puis on saisit l’URL de la page HTML servie par 4D et contenant le clip Flash :
http://<nom d’hôte ou adresse IP>/sampleppc.html
Si tout va bien, nous devons obtenir l’affichage de la chaîne « Sample » dans le navigateur.
L’exemple de prise de rendez-vous▲
Le mobile doit être connecté à Internet, par Wi-Fi, GPRS, connexion locale ou autre…L’application 4D doit être lancée, son serveur http démarré et accessible.
Les actions possibles▲
On lance Internet Explorer sur le PocketPC, puis on saisit l’URL de la page HTML servie par 4D et contenant le formulaire Flash :
http://<nom d’hôte ou adresse IP>/rdv.html
L’écran ci-dessous s’affiche :
La date du jour est renseignée par défaut, les rendez-vous déjà pris pour ce jour s’affichent. Un clic sur une ligne permet d’afficher le descriptif de l’évènement ou du rendez-vous sur trois lignes
La saisie directe d’une date est possible dans le champ date. Les flèches de part et d’autre de ce champ permettent de faire défiler les jours. La liste des évènements correspondants est automatiquement mise à jour.
Il est possible de masquer la zone de saisie de l’url (« barre d’adresses ») du navigateur pour augmenter la zone d’affichage.
Il est possible d’ajouter un rendez-vous en cliquant sur le bouton « + », ce qui provoque l’affichage d’une nouvelle fenêtre affichant le formulaire de création d’un rendez-vous.
Une fois les informations saisies, un clic sur le bouton « OK » permet d’enregistrer le rendez-vous dans la base 4D. Un contrôle est effectué au préalable sur les champs obligatoires.
Un autre contrôle s’assure que deux évènements ne se produisent pas au même moment.
Une fois les champs correctement renseignés, une icône ‘smile' s’affiche indiquant que l’ajout dans la base 4D s’est bien déroulé.
Il est alors possible de refermer la fenêtre d’ajout par clic sur sa case de fermeture ou d’ajouter un nouveau rendez-vous (un bouton raz pour remettre tous les champs de saisie à vide serait une amélioration appréciable).
Le rendez-vous ajouté s’affiche maintenant dans la liste des rendez-vous de la date correspondante.
Considérations d’interface▲
La petite taille de l’écran représente le défi majeur à relever pour développer pour PocketPC. Elle propose couramment une résolution de 320 x 240 (elle peut monter jusqu’à 480x640). La copie d’écran ci-dessous vous montre l’écran d’un PocketPC 240x240 relativement à un écran de portable en résolution 1920x1200 :
Pour les anciens, rappelez-vous de l’écran du MacSE que l’on trouvait si petit : il proposait une résolution de 512x384 !
De plus vous devez enlever l’espace utilisé par le navigateur et le système.
Une démo▲
L’application a été développée pour un HP hw6515 qui ne dispose que d’un écran 240x240 en raison de la présence d’un clavier intégré.
L’objectif de la démo côté Flash était de montrer :
· que l’on pouvait utiliser complètement ActionScript 2 et en particulier les possibilités de traitement XML ;
· que l’on pouvait utiliser des composants d’interface Flash 7.
Ainsi, même si globalement les fonctionnalités proposées par cette démo pourraient être fournies par un ensemble de pages HTML, nous utilisons cependant des fonctionnalités avancées de Flash qui pourraient être avantageusement étendues pour renforcer :
· l’aspect graphique ;
· la convivialité des fonctions proposées (nous avons par exemple testé des animations).
Nous utilisons :
· les possibilités de multifenêtrage pour l’affichage du formulaire d’ajout de rendez-vous ;
· la capacité à échanger de l’information avec le serveur et à redessiner des portions de la fenêtre sans rafraîchir totalement l’écran (comme dans la technologie Ajax, se reporter à la note à ce sujet).
Pour valider l’utilisation de composants, nous avons mis en œuvre :
· un composant de connexion le XML connector ;
· un composant de mapping des données : le DataSet ;
· un composant d’affichage des listes : le DataGrid.
La taille du fichier produit demeure raisonnable, car elle ne fait que 130k environ, ce qui est utilisable tant en transfert qu’en empreinte mémoire.
Compromis▲
Cependant, nous avons dû effectuer des compromis entre la surface d’affichage et la taille des composants. Ainsi, l’utilisation du composant DateField (calendrier pour choisir la date) n’a pas été retenue, car :
· il est très gourmand en ressources ;
· il demande une surface d’affichage supérieure à 240x240 obligeant ainsi à faire défiler les ascenseurs.
Aller plus loin▲
Nous présentons dans ce paragraphe un ensemble de possibilités pour améliorer l’utilisation de la solution décrite. En particulier, deux reproches peuvent être adressés à l’obligation de fonctionnement dans le contexte d’un navigateur :
· la place perdue par l’interface du navigateur ;
· la nécessité de recharger à chaque fois le clip Flash depuis le serveur ce qui demande du temps et peut coûter de l’argent dans le cas d’une communication facturée à l’octet.
Nous allons voir deux moyens de remédier à ces critiques justifiées :
· compléter notre solution par un utilitaire complémentaire ou alternatif au player Flash et permettant l’affichage en mode standalone ;
· stocker localement les fichiers html et flash.
Stand-alone pour PocketPC▲
Des produits payants existent qui permettent une utilisation hors Explorateur et donc une plus grande surface d’affichage et une utilisation des boutons de l’appareil :
· http://www.bryht.com/flash_player.htm
· http://www.tweaks2k2.com/portal/staticpages/index.php?page=20050228103228923
· http://www.pocketone-soft.com
· http://www.smartsprite.com (gratuit)
Note :
En raison des restrictions de sécurité, ces produits sont sans doute plus adaptés à une utilisation locale, en exploitant par exemple des fichiers XML. Dans notre cas, la communication vers 4D ne se fait pas.
Stockage local▲
Il suffit de recopier dans la mémoire du PocketPC la page HTML et le clip Flash rdv.swf pour pouvoir lancer directement notre client depuis l’explorateur de fichier du PocketPC et éviter ainsi de recharger inutilement des éléments. Inconvénient : en cas de mise à jour de l’application, il faut gérer le déploiement.
Dans la copie d’écran ci-dessous, on peut constater que l’URL est une URL locale : la page HTML et son clip Flash sont chargés depuis la Storage Card.
Conclusion▲
Les utilisateurs sont de plus en plus demandeurs de solutions mobiles. Fournir un accès sur leur PDA PocketPC à des fonctionnalités du système d’information représente un défi que vous pouvez relever de manière gagnante avec le couple 4D/Flash. Dans la première partie de cette note, nous avons introduit le problème, présenté les contraintes et réuni les ressources nécessaires au développement d’une telle solution. Nous avons également décrit l’exemple servant à illustrer cette note. Dans la deuxième partie de la note, nous nous intéresserons à l’aspect programmation de la solution…
Ressources▲
Le monde des PocketPC regorge de ressources en tout genre.
Voici celles qui ont servi pour cette note...
Articles▲
« Playing Flash Content on the Pocket PC » :
un article indispensable sur les différentes solutions pour jouer des clips Flash sur PocketPC.
http://www.pocketpcmag.com/blogs/menneisyys/052006FlashPlayers.asp
Utilitaires▲
· Pour les captures d’écran sur PocketPC
Les captures d’écran ont été réalisées sur PocketPC grâce à l’utilitaire Magic_SS :
http://www.louterrailloune.com/magicss.html
· Visualiser l’écran du PocketPC sur le PC
Il est également possible de visualiser l’écran du PocketPC sur le PC.
http://www.microsoft.com/technet/prodtechnol/wce/downloads/ppctoys.mspx
Voir ici pour un tutoriel :
http://www.labi2s.com/index.php?chemin=74_76_153&nomExtranet=PUBLIQUE&id=405
Également, VH PocketPC Capture 0.91 beta :
http://www.hmelyoff.com/index.php?section=18
· Émulateur Pocket PC
Depuis peu Microsoft propose gratuitement un émulateur PocketPC.
http://www.microsoft.com/downloads/details.aspx?FamilyId=C62D54A5-183A-4A1E-A7E2-CC500ED1F19A&displaylang=en
Cela permet de tester sans avoir d’appareil ou de tester des configurations multiples, par exemple des résolutions différentes d’écran. Certaines des captures d’écran présentées dans cette note ont été réalisées grâce à cet émulateur.
· Copie de l’écran du PC
Nous avons eu recours à l’utilitaire gratuit ‘Gadwin Print Screen' :
http://www.gadwin.com/download/ps_setup.exe
· Compléments open source ou gratuits à Flash
MTSAC (Motion-Twin ActionScript Compiler)
Le compilateur en ligne de commande par Motion-Twin
http://www.mtasc.org/
Sepy
Éditeur en Python
http://www.sephiroth.it/python/sepy.php
FlashDevelop
Éditeur gratuit Windows (FlashDevelop nécessite Microsoft.NET 1.1 Framework.)
http://www.flashdevelop.org/
Télécharger la base exemple▲
Télécharger la base exemple.