Développez des applications Palm OS

Ceci est un extrait électronique d'une publication de
Diamond Editions :
http://www.ed-diamond.com
Ce fichier ne peut être distribué que sur le CDROM offert
accompagnant le numéro 100 de GNU/Linux Magazine France.
La reproduction totale ou partielle des articles publiés dans Linux
Magazine France et présents sur ce CDROM est interdite sans accord
écrit de la société Diamond Editions.
Retrouvez sur le site tous les anciens numéros en vente par
correspondance ainsi que les tarifs d'abonnement.
Pour vous tenir au courant de l'actualité du magazine, visitez :
http://www.gnulinuxmag.com
Ainsi que :
http://www.linux-pratique.com
et
http://www.miscmag.com
embarqué
palm os
 Développez des applications Palm OS
Denis Bodor
EN DEUX MOTS Il y a fort longtemps, le développement
d’applications pour Palm et compatibles avait déjà
rempli les colonnes de GNU/Linux Magazine. Depuis
janvier 2001, les choses ont bien changé.
l’époque où j’avais abordé le sujet,
le Palm était en concurrence
avec le Psion et les PocketPC
venaient d’apparaître. Depuis, les
PDA ont gagné en puissance et en mémoire.
Les écrans ont également été améliorés
tout comme la connectivité de ces chères
petites machines.
La concurrence des PocketPC a poussé les
fabricants de périphériques Palm à créer des
machines plus puissantes, plus esthétiques, plus
communicantes... tout en restant compatibles
avec l’énorme bibliothèque d’applications
existantes.
C’est ainsi que les périphériques compatibles
Palm OS sont maintenant équipés de
processeurs ARM tout en émulant pour la
totalité des applications une architecture
68k (Motorola Dragonball, M68VZ328,
M68EN302, etc.). Ce système, nommé PACE
(Palm application compatibility environment)
fait fonctionner l’ensemble du parc actuel
de machines récentes Palm OS.
Le système d’exploitation le plus avancé, Palm
OS Garnet (Palm OS 5), permet l’utilisation
de routines spécifiques aux processeurs
ARM, mais une application native n’est pas
encore possible. On parle alors d’objet natif
PACE (PNO, PACE native objects) qui sont
des sous-routines dédiées ARM, lancées
depuis un code 68k.
Palm OS Cobalt (Palm OS 6) est le prochain
Palm OS entièrement dédié à l’ARM. Il
contiendra un nouveau framework de gestion
pour le réseau, la sécurité, le multimédia,
etc. reposant entièrement sur l’API Protein
(entièrement en code natif ARM).
Nous ne traiterons ici ni de PNO, ni de Cobalt
puisqu’il s’agit d’une simple introduction au
développement pour Palm OS. Notre plateforme cible sera donc Garnet et l’architecture
68K.A la charge de PACE de s’occuper de nos
applications sur des périphériques récents
et au Palm OS « normal » de faire de même
sur les machines les plus anciennes.
86
Outils de Développement
La diversité et la disponibilité des outils de développement pour
Palm OS ont été des facteurs importants dans la popularisation
du système. US Robotics puis 3Com, sociétés à l’origine des
PDA Palm avaient compris qu’en rendant disponible facilement
les suites de développement, de nombreux programmeurs
allaient créer une masse d’applications importante qui allait
faire le succès du système.
Des outils de développement sont disponibles sur les trois
plateformes principales du marché : Windows, Mac OS
et GNU/Linux (et les autres UNIX libres). Nous ne nous
intéresserons, bien sûr, qu’à GNU/Linux, mais sachez que
les outils présentés ici peuvent également fonctionner sous
Windows (via Cygwin).
Un environnement de développement pour Palm OS se
compose de plusieurs éléments :
La chaîne de compilation croisée. Il s’agit du projet PRCtools qui regroupe le compilateur GCC, l’assembleur, l’éditeur
de liens et le débugger. Il s’agit des outils GNU modifiés afin
de supporter les spécificités propres à Palm OS. Avec PRCtools, vous serez à même de créer et construire vos binaires
au format spécifique PRC.
Le SDK (Software Development Kit) Palm OS. Pour cet
élément vous n’aurez pas le choix, il vous faudra le télécharger
depuis le site PalmSource dédié aux développeurs Palm OS
(http://www.palmsource.com/developers/ ). Pour pouvoir
télécharger et utiliser le SDK, vous devrez ouvrir un compte
(gratuit) sur le site et accepter les conditions d’utilisation.
Cette acceptation vous donnera non seulement accès au
téléchargement des SDK et des outils de développement
mais également à un forum de développeurs, aux ROM
Palm OS, etc. Lisez attentivement les conditions d’utilisation
et les différentes clauses limitatives pour être sûr que cela
correspond à vos besoins.
Le compilateur de ressources PilRC (http://sourceforge.
net/projects/pilrc/ ). Comme nous le verrons plus loin, une
application Palm OS se construit de manière très spécifique. On
compile le code et l’interface séparément pour les fusionner
et obtenir un binaire utilisable. La création et la compilation
des ressources décrivant l’interface d’une application sont le
travail d’un outil spécifique : PilRC de Aaron Ardiri.
Un émulateur. Il ne s’agit pas là d’un élément indispensable,
mais le test d’applications en cours de développement est
bien plus aisé via un émulateur que sur une véritable machine.
L’un des émulateurs les plus utilisés sous GNU/Linux est
Pose. Il permet d’émuler un grand nombre de périphériques
Palm OS. Pose comme tout émulateur Palm OS nécessite
d’utiliser un fichier image d’une ROM spécifique contenant
le système. Une fois inscrit sur PalmSource, vous pourrez,
en toute légalité télécharger l’une d’elles. Malheureusement,
le choix est très limité. Le téléchargement d’autres ROM
n’est pas possible, en raison, semble-t-il, de problèmes de
brevets et de copyright concernant Graffiti 2. Actuellement
 GNU Linux Magazine France
les seules images de ROM téléchargeables sur PalmSource
sont celles d’un Palm OS 4.1.2 sans support de couleurs. C’est
très regrettable sachant que la plupart des périphériques
Palm récents disposent d’un écran couleur. Vous pourrez
cependant tenter d’utiliser une image de la ROM de votre
périphérique qu’il vous sera possible de récupérer avec les
outils Pose ou Pilot-Link.
On notera que les outils de développements pour Windows
sont largement mis en avant sur le site des développeurs
Palm OS. Beaucoup d’éléments ne sont, en effet, disponibles
que pour ce système d’exploitation et pour Mac OS. Notre
GNU/Linux est un peu « à la traîne ».
Il n’existe, par exemple, pas de simulateur pour notre système.
Les simulateurs se différencient des émulateurs comme Pose
par le fait qu’ils n’émulent non pas un périphérique mais un
système. Sont disponibles au téléchargement des simulateurs
Garnet 5.1 à 5.4 et Cobalt 6.0 à 6.1.
Il en va de même pour le SDK qui ne concerne que Garnet
(68K) et non Protein/Cobalt. Ceux-ci sont uniquement
disponibles avec la « Palm OS Developer Suite », un fichier
auto-installable pour Windows de quelque 270 Mo comprenant
outils et SDK.
Avec cette suite, vous pourrez développer aussi bien pour
Garnet que pour Cobalt ou profiter du support PNO pour
PACE très simplement... à condition d’utiliser Windows.
Sachant que cette suite repose en partie sur Cygwin, c’est
un peu dommage, même si le système Microsoft représente
encore la grande majorité des OS installés.
Installation de l’environnement de
développement
Sous GNU/Linux, nous n’avons besoin que du SDK fourni sur
PalmSource. En effet, avec presque toutes les distributions,
les PRC-tools sont disponibles sous forme de paquets. C’est
le cas, bien entendu, pour la distribution Debian qui livre
ces outils sous la forme de plusieurs paquets (prc-tools,
prc-tools-arm, prc-tools-doc, prc-tools-m68k, prc-toolsutils). On notera que le paquet prc-tools-arm permettra de
développer des « armlets », ces fameux morceaux de code
natif ARM embarqués dans des applications 68K.
Le paquet prc-tools-utils contient un élément très important.
Comme vous vous en doutez, il est quasiment impossible de
développer une application Palm OS sans SDK. Ce paquet
intègre un utilitaire permettant de simplifier la prise en charge
du ou des SDK installés sur votre système. Jusqu’alors, il
était très délicat de compiler des programmes reposant sur
l’API Palm OS.
Il était, en effet, nécessaire de construire des fichiers Makefile
prenant en compte l’emplacement des fichiers en-têtes et
des bibliothèques statiques à lier et ce, pour chaque projet
et chaque SDK.
prc-tools-utils fournit palmdev-prep, un utilitaire permettant
de préparer un arbre de dépendances facilitant l’utilisation
des PRC-tools. Une fois le SDK téléchargé depuis le site
PalmSource sous la forme d’un fichier palmos-sdk-5.0r3-1.tar.
gz.tar, vous n’aurez qu’à le désarchiver dans l’emplacement
PalmDev par défaut : /opt/palmdev selon la page de manuel,
Numéro 77 / Novembre 2005
mais /usr/local/share/palmdev dans la
pratique (avec une Debian Etch/testing et les
PRC-tools 2.3). Dans tous les cas, lancez un
palmdev-prep -v pour connaître le répertoire
configuré au moment de la compilation des
outils pour votre distribution.
Une fois le SDK désarchivé, lancez simplement
palmdev-prep pour mettre à jours les
chemins :
% sudo palmdev-prep
Checking SDKs in /usr/local/share/palmdev
sdk-5r3 headers in ‘include’, libraries in ‘lib’
When GCC is given no -palmos options,
SDK ‘5r3’ will be used by default
Writing SDK details to configuration files...
...done
Les fichiers modifiés sont les fichiers specs
de GCC.Ainsi, les chemins par défaut seront
automatiquement les bons et aucune autre
configuration ne sera nécessaire.Vous pouvez
installer plusieurs SDK dans l’emplacement
par défaut et relancer palmdev-prep. Ce
dernier vous précisera les SDK détectés et
celui utilisé par défaut en l’absence d’option
-palmos passée à au compilateur.
Personnellement, j’ai conservé le SDK
3.5 utilisé lors du précédent article sur le
développement Palm d’il y a quelques années.
Malheureusement, aujourd’hui il n’est plus
possible (ni utile) de récupérer ces vieilleries
sur PalmSource.
Néanmoins, cela m’aura permis de vérifier
la viabilité palmdev-prep en compilant très
facilement un code pour Palm OS 3.5 ou
3.1 avec les SDK correspondants. Notez
toutefois que le SDL 5r3 actuellement en
téléchargement permet de développer des
applications parfaitement fonctionnelles sur
un vieux Palm IIIxe sous Palm OS 3.5.
Architecture
A l’heure actuelle, Palm OS est un système
mono-tâche. Il n’en sera pas de même avec
Cobalt (voir en fin d’article) mais ce n’est
pas ce qui nous préoccupe à présent. La
structure d’un programme Palm OS est donc
relativement étrange pour un développeur
GNU/Linux.
A l’instar des codes pour microcontrôleurs,
une application Palm OS est composée
d’une boucle consommant allègrement des
ressources CPU pour rien. Ce n’est pas bien
grave puisqu’au moment où notre application
est lancée, c’est elle qui a la main et rien
d’autre n’intervient en même temps (sauf si
87
embarqué
palm os
elle relaie l’information). Certains prétendent
que Garnet est multitâche car, sur un Tréo
par exemple, il est possible de recevoir un
appel téléphonique tout en utilisant une
application.
Il s’agit de multitâche coopératif ou d’astuces
de conception spécifiques aux Smartphone
Palm OS. Cela n’a rien à voir avec ce dont nous
disposons sous Linux ou ce que proposera
Cobalt d’ici peu.
La boucle principale constituant l’application
permet de traiter des évènements. Il peut
s’agir d’évènements système, d’actions de
l’utilisateur sur un menu ou sur l’interface
graphique (Formulaire), etc. L’application
doit alors identifier le type d’évènement
et réagir en conséquence.
Une autre spécificité du développement Palm
OS concerne l’interface graphique. La plupart
des écrans des périphériques compatibles
Palm OS se composent d’un carré de 160
pixels de coté. Il est possible, directement
depuis votre code, de dessiner sur l’écran à
l’aide de fonctions comme WinDrawChars()
ou WinDrawLine().
Cependant, les applications Palm OS se
composent habituellement de zones de saisie,
de menus et de boutons. Ces éléments ne
sont pas pris en charge directement par le
code du développeur mais font l’objet d’un
traitement particulier.
On parle alors de ressources qui seront
compilées et fusionnées avec l’application.
Un « écran » d’application Palm OS, par
exemple, est un formulaire possédant un
certain nombre de caractéristiques.
Enfin, il faut savoir que dans le système
Palm OS tout est base de donnée. Une
application est composée de code exécutable,
de ressources graphiques et de liens vers
d’autres bases.Toutes ces informations sont
stockées dans le système Palm OS en tant
qu’enregistrements de manière à optimiser
l’utilisation de la mémoire. La documentation
officielle explique qu’un système de fichiers
traditionnel ne serait pas adapté pour ce
type de périphériques.
Premier programme
Assez de théorie, passons sans plus attendre
à la pratique avec un premier programme
relativement simpliste. Je considèrerai, à partir
d’ici, que l’environnement de développement
complet (SDK inclus) est correctement
installé et configuré sur votre système.
Notre premier code, hello.c , sera
extrêmement court :
88
#include <PalmOS.h>
UInt32 PilotMain( UInt16 cmd,
void *cmdPBP, UInt16 launchFlags )
{
EventType event;
char *toto=»Coucou !»;
if (cmd == sysAppLaunchCmdNormalLaunch) {
WinDrawChars( toto, StrLen(toto), 55, 60 );
do {
EvtGetEvent( &event, evtWaitForever );
SysHandleEvent( &event );
} while (event.eType != appStopEvent);
}
}
return(0);
On retrouve ici la boucle do...while formant le corps
de l’application. Celle-ci reste infinie à moins que le type
d’évènement reçu soit appStopEvent, la fin de l’exécution du
programme. Le contenu de la boucle est très concis, notre
application ne fait rien d’utile :
Nous tentons de récupérer le prochain évènement. Le second
argument de la fonction EvtGetEvent() est le délai d’attente
en « tick » système. Ici evtWaitForever permet d’attendre
indéfiniment. Si vous spécifiez une valeur supérieure à 0 et
qu’aucun évènement n’est reçu entre temps, un évènement
nul est généré (nilEvent).
Comme spécifié dans la documentation du développeur Palm
OS, immédiatement après un EvtGetEvent(), nous utilisons
la fonction SysHandleEvent en lui passant en argument un
pointeur sur l’évènement reçu. Cette fonction donne une
chance au système de gérer l’évènement. Si cela se produit,
la fonction retourne 1. La seule raison légitime de ne pas
utiliser cette fonction est de gérer dans notre application
des évènements destinés au système. En effet, n’oubliez pas
que nous sommes en multitâche coopératif et lorsque notre
application fonctionne, rien d’autre n’est exécuté. Oubliez
SysHandleEvent et c’est le reset obligatoire sur le PDA.
Prenons du recul et regardons ce qui se trouve en dehors
de cette fameuse boucle. La fonction PilotMain est le main()
de tout programme C. Oublions les argv et argc, cette
fonction reçoit de la part du système plusieurs valeurs en
argument :
Un code de lancement. Celui-ci sera, dans la plupart des cas
sysAppLaunchCmdNormalLaunch, une exécution « normale »
provoquée par l’utilisateur. On notera au passage qu’il existe
un code sysAppLaunchCmdCardLaunch permettant à l’application
de détecter un lancement depuis une carte d’extention SD
par exemple et de réagir en conséquence.
Un pointeur sur une structure de paramètres spécifiques au
lancement (équivalent au argv). La structure et son contenu
dépendent du code de lancement.
Un ensemble de drapeaux permettant de connaître les
conditions de lancement de l’application.
 GNU Linux Magazine France
Développez des applications Palm OS
Nous utilisons ici la fonction WinDrawChars permettant d’écrire
arbitrairement des caractères sur l’écran. La fonction prend
en argument un pointeur sur une chaîne de caractères, la
taille en octets de la chaîne et les coordonnées X et Y du
début de la chaîne à l’écran.
J’aurais tout aussi bien pu utiliser WinDrawChars(«Coucou !»,
8, 55, 60), mais je tenais à utiliser StrLen. Cela peut sembler
trivial mais lorsqu’on développe depuis GNU/Linux pour une
autre plate-forme, on oublie parfois que la libc n’est pas là.
Cette fonction est un bel exemple, il est important de le
relever, car dans vos premières applications, vous aurez sans
doute tendance à utiliser strlen tout comme vous le faites
sous GNU/Linux.
Gardez un œil sur la documentation de l’API est un réflexe à
prendre pour faire passer les vilaines habitudes (http://www.
palmos.com/dev/support/docs/palmos/PalmOSReference/
ReferenceTOC.html).
Notre code se compilera très facilement avec :
% m68k-palmos-gcc -Wall hello.c -o hello
% m68k-palmos-obj-res hello
% build-prc hello.prc «Test» ESSA *.grc *.bin
La première commande compile le code et génère un binaire
au format mc68k COFF. La seconde utilise le binaire pour
générer des fichiers de ressources. Ces fichiers possèdent
l’extention grc et nous servent pour créer le fichier PRC
spécifique à l’environnement Palm OS. Un fichier PRC n’est
qu’un « emballage », le système le transformera en une base
de données de ressources Palm OS.
Voilà pourquoi nous devons préparer notre application, un peu
comme le format ELF qui n’est pas une image du programme
en mémoire. build-prc est utilisé pour empaqueter les
ressources. Les arguments sont, dans l’ordre, le fichier PRC
à créer, le nom de l’application, l’identifiant du créateur (crid,
pour creator ID) et les fichiers de ressources à combiner.
Le crid pourra être choisi arbitrairement en phase de
développement, mais si vous compter distribuer vos applications,
il vous faudra enregistrer votre crid sur le site PalmSource. La
commande figurant ici est donnée à l’ancien format. Ce n’est
qu’à partir du quatrième argument qu’on spécifie les fichiers
à traiter. La page de manuel recommande toutefois d’utiliser
une nouvelle syntaxe reposant sur des options :
% build-prc -o hello.prc -c ESSA -n Test *.grc *.bin
Notez que nous spécifions ici d’éventuels fichiers à l’extention
bin. Il s’agit de ressources provenant de données externes à
la compilation du code. Le fichier PRC créé est parfaitement
fonctionnel, mais loin d’être idéal, un certain nombre
d’informations peuvent être ajoutées. Certaines informations
utilisées par les applications Palm OS sont spécifiées via un
fichier de ressources :
ICON «icon.bmp»
VERSION «1.0 beta»
Numéro 77 / Novembre 2005
Nous enregistrons ces lignes dans un
fichier hello.rcp destiné à être compilé
par PilRC :
% pilrc hello.rcp
PilRC v3.2
Copyright 1997-1999 Wes Cherry ([email protected])
Copyright 2000-2005 Aaron Ardiri ([email protected])
Generating 68K resources from ‘hello.rcp’.
Writing tAIB03e8.bin (104 bytes)
Writing tver0001.bin (9 bytes)
PilRC permet de générer à partir du hello.
rcp des fichiers de ressources que nous
utiliserons ensuite avec build-prc. Ici, nous
spécifions un fichier au format BMP noir et
blanc (1 bit) qui sera l’icône de l’application.
Nous renseignons également la version qui
figurera dans les informations concernant
notre application.
Il s’agit, là encore, de l’ancienne syntaxe.
Avec l’arrivé des périphériques gérant la
couleur, il devient possible de compiler dans
une seule ressource plusieurs versions de
l’icône en utilisant ICONFAMILY suivi de quatre
noms de fichier BMP contenant l’image dans
des formats différents : 1bpp, 2bpp, 4bpp et
256 couleurs.
Ainsi, l’icône de votre application sera
toujours correctement affichée quel que
soit le PDA utilisé.
Fig. 1 : La version d’une application est spécifiée via
un fichier de ressources compilé avec PilRC.
Présenté de la sorte, PilRC peut sembler être
un outil « cosmétique », mais il ne faut pas
oublier que, pour l’heure, notre application
ne fait absolument rien de spécial.
Dès son lancement, elle affiche, sans plus de
fioritures, une simple chaîne de caractères sur
l’écran et attend de recevoir un évènement
de type appStopEvent. Difficile de parler
sérieusement d’application Palm OS pour
l’instant.
89
embarqué
palm os
Interface graphique
PilRC est indispensable pour créer de véritables
applications. Le fichier de ressources permet
de définir des formulaires qui seront utilisés
par l’application pour afficher convenablement
les informations et répondre aux actions
de l’utilisateur.
Nous allons, tout d’abord étoffer notre fichier
de ressources en ajoutant un formulaire :
FORM ID mainForm AT (2 2 156 156)
USABLE
FRAME
MODAL
BEGIN
TITLE “Coucou le Palm”
END
Nous créons ici un formulaire qui sera le
cadre de notre application. Ce formulaire est
désigné par l’identifiant mainForm et possède
un certain nombre de caractéristiques (voir
documentation de PilRC).
Un formulaire est un conteneur qui peut
regrouper plusieurs objets qui seront
énumérés entre des tags BEGIN et END. Ici,
le seul objet en présence est le titre du
formulaire.
Utilisons immédiatement la commande pilrc
pour obtenir les fichiers de ressources et,
plus important encore, un fichier resource.
h contenant simplement #define mainForm
9998 : l’identifiant numérique du formulaire
créé automatiquement par PilRC.
Incluons immédiatement le fichier d’en-tête
dans notre hello.c avant de nous attacher à
la gestion de la ressource. Modifions notre
fonction PilotMain :
UInt32 PilotMain( UInt16 cmd,
void *cmdPBP, UInt16 launchFlags )
{
if (cmd == sysAppLaunchCmdNormalLaunch)
{
FrmGotoForm(mainForm);
EventLoop();
}
FrmCloseAllForms();
return(0);
}
Nous commençons par utiliser FrmGotoForm
permettant en un seul mouvement d’envoyer
un frmCloseEvent au formulaire actif puis
un frmLoadEvent et un frmOpenEvent à la
ressource spécifiée en argument. frmLoadEvent
demande le chargement du formulaire en
mémoire, mais c’est à notre application de
traiter l’évènement.
90
Ensuite, nous remplaçons notre boucle de gestion d’évènement
par une fonction dédiée. Ce n’est pas critique ici, mais la
structuration du code est quelque chose de capital pour le
développement d’applications Palm. Nous reviendrons plus
loin sur la fonction FrmCloseAllForms.
Voici notre fonction de gestion des évènements. C’est ici
que le code bouclera indéfiniment en l’attente d’évènements
à traiter :
void EventLoop(void) {
EventType event;
int formID;
FormPtr form;
do {
EvtGetEvent( &event, evtWaitForever );
if(SysHandleEvent(&event)) continue;
}
if(event.eType == frmLoadEvent)
{
formID = event.data.frmLoad.formID;
form = FrmInitForm(formID);
FrmSetActiveForm(form);
switch(formID)
{
case mainForm:
FrmSetEventHandler(form, &MainFrmHandler);
break;
}
}
FrmDispatchEvent(&event);
} while (event.eType != appStopEvent);
On reconnaît la fonction de récupération du prochain
évènement suivie immédiatement par celle permettant de
laisser une chance au système de le gérer. On ajoutera une
condition permettant de sortir de la boucle si c’est le cas.
On détecte ensuite s’il s’agit d’un type évènement frmLoadEvent.
C’est normalement le cas immédiatement après le démarrage
de l’application. C’est nous-même qui venons de le provoquer.
Si c’est le cas, un certain nombre de manipulations s’imposent
pour initialiser correctement le formulaire.
On commence par récupérer l’identifiant de la ressource
concernée et on le stocke dans formID puis utilise cet
identifiant pour charger la ressource.
On obtient en retour un identifiant du formulaire (par
opposition à l’identifiant de la ressource) qui nous sert à
activer ce dernier.
On switche ensuite pour ne traiter que notre mainForm. Une
condition if aurait suffit dans ce cas, mais une application
peut se composer de plusieurs formulaires chargés à des
moments différents.
S’il s’agit bien d’un frmLoadEvent sur notre mainForm, nous
pouvons définir une fonction callback permettant de gérer
les évènements qui lui sont propres : MainFrmHandler, notre
gestionnaire d’évènements.
Finalement nous utilisons la fonction FrmDispatchEvent
permettant de passer l’évènement au gestionnaire
concerné.
 GNU Linux Magazine France
Développez des applications Palm OS
Gestionnaire que voici :
static Boolean MainFrmHandler(EventPtr event)
{
int handled = 0;
FormPtr form;
switch(event->eType)
{
case frmOpenEvent:
form = FrmGetActiveForm();
FrmDrawForm(form);
handled = 1; break;
case penDownEvent:
WinDrawChars( «coucou», 6, 55, 60 );
handled = 1; break;
}
return handled;
}
Nous ne gérons ici que deux évènements. Le premier est
l’ouverture du formulaire. Là encore, c’est notre application
qui a généré l’évènement via FrmGotoForm(). En réponse,
nous affichons le formulaire à l’écran.
Nous répondons également à un évènement penDownEvent
correspondant à l’utilisation du stylet sur le formulaire.
En réponse, nous affichons simplement la chaîne coucou à
l’écran.
Pour construire le fichier PRC, nous utiliserons cette fois
un fichier Makefile :
all: hello.prc
ressources: hello.rcp icon1bpp.bmp icon8bpp.bmp
pilrc -H resource.h hello.rcp
binary: hello.c resource.h
m68k-palmos-gcc -Wall -g hello.c -o hello
m68k-palmos-obj-res hello
hello.prc: ressources binary
build-prc hello.prc «Test» ESSA *.grc *.bin
clean:
rm -rf hello *.grc *.bin hello.prc resource.h
Le compilateur ne manquera pas de nous rappeler que notre
gestionnaire ne traite qu’une faible partie des évènements.
Ceci n’est qu’un simple avertissement, mais mieux vaudra en
tenir compte pour une application finalisée.
Revenons sur la fonction FrmCloseAllForms() utilisée juste
avant de sortir de PilotMain. Palm OS fonctionne sur des
périphériques dont la mémoire et les ressources sont limitées.
La chasse aux fuites de mémoire représente un point important.
En l’absence de cette fonction permettant de clore l’utilisation
des formulaires, la mémoire allouée n’est pas libérée.
L’émulateur Pose ne manque pas de le signaler. C’est là
un autre avantage de l’utilisation d’un émulateur dans la
phase de développement. Celui-ci permet de debugger les
applications bien plus efficacement qu’un PDA. En plus de
fournir des indications sur des violations de mémoire et des
Numéro 77 / Novembre 2005
Fig; 2 : Notre première application
utilisant un formulaire.
fuites, il vous permettra d’utiliser GDB en
mode client/serveur. Fonctionnalité non
négligeable lorsqu’on fait ses premiers pas
dans un environnement aussi exotique que
Palm OS.
Menu du jour
Notre formulaire est la base graphique de
notre application. Dans le fichier décrivant
les ressources, nous pouvons définir d’autres
objets que nous rattacherons ensuite au
formulaire.Ainsi, nous définissons une entrée
de menu :
MENU ID mainMenu
BEGIN
PULLDOWN «Options»
BEGIN
MENUITEM «About» ID menuItemAbout «a»
END
END
Identifiée par mainMenu, celle-ci se compose
d’une entrée ou branche «Options» dans
laquelle se trouve l’entrée identifiée par
menuItemAbout.
Pour lier ce menu au formulaire, il nous
suffit d’ajouter MENUID mainMenu dans la
définition de ce dernier (avant BEGIN...
END). Nous disposons à présent d’un menu
et d’une entrée identifiée. Poursuivons en
définissant une autre ressource :
ALERT ID aboutbox
INFORMATION
BEGIN
TITLE “A propos de Coucou”
MESSAGE «(c) Denis Bodor»
BUTTONS „Done“
END
91
embarqué
palm os
Il s’agit d’une ressource de type ALERT
identifiée comme aboutbox. Elle possède
un titre, un message et un bouton. Cette
ressource n’est pas liée avec le formulaire
ou tout autre élément. Elle sera chargée par
notre code et affichée au besoin.
Le fichier resource.h généré par PilRC
regroupera les identifiants numériques
de toutes nos nouvelles ressources. Nous
n’avons plus qu’à les utiliser.
Notre code ne change quasiment pas.
En réalité, la seule partie devant prendre
en compte les nouvelles ressources est
notre gestionnaire d’évènements. Nous
remplacerons ici, tout simplement, notre
condition penDownEvent du switch par
ceci :
Un pointeur vers une structure MenuBarType. Inutile ici,
notre ressource est un menu déroulant.
Un pointeur sur la structure décrivant l’évènement à
traiter.
Un pointeur vers un entier court non signé (UInt16) qui
contiendra le code erreur (en réalité, celui-ci est toujours
égal à zéro selon la documentation officielle).
Tout ce qui nous reste à faire se résume à déclarer la variable
pour le code d’erreur (UInt16 err;), puis à utiliser cette
fonction juste après SysHandleEvent :
if(MenuHandleEvent(NULL,&event,&err)) continue;
C’est tout. Il n’en faut pas plus pour construire et gérer un
menu déroulant affichant une boîte de dialogue. Comme
vous pouvez le voir, seule l’ossature de départ est délicate. Si
celle-ci est bien faite, on peut, à souhait, ajouter toutes sortes
d’éléments sans changements trop important dans le code.
case menuEvent:
switch(event->data.menu.itemID)
{
case menuItemAbout:
FrmAlert(aboutbox);
handled = 1;
break;
}
break;
Si le type d’évènement reçu est un menuEvent,
nous cherchons à savoir sur quel élément il
porte. Si c’est menuItemAbout, l’identifiant
défini pour l’entrée «About» dans le fichier
de ressources, nous réagissons. La fonction
FrmAlert est très efficace.
Elle permet de créer et d’afficher une
alerte jusqu’à ce que l’utilisateur clique
sur un bouton dans la boîte de dialogue.
Elle prend en argument l’identifiant de la
ressource à utiliser.
Si vous compilez et construisez un PRC en
vous arrêtant là, votre menu et, en toute
logique, la boîte de dialogue, n’apparaîtront
jamais. En effet, notre application de gère
pas la navigation dans les menus. Pas de
panique, il n’est pas nécessaire de traiter
cela manuellement.
Il suffit d’utiliser la fonction MenuHandleEvent.
Celle-ci demande au système de gérer le menu
déroulant à notre place. Si un évènement
penDownEvent est reçu dans un menu, cette
fonction suivra le stylet.
Si ce dernier est levé sur une entrée du
menu, un menuEvent est généré contenant
l’identifiant de l’entrée.
Le reste de la gestion (navigation, surbrillance,
sortie du menu, etc.) est effectué par
MenuHandleEvent à notre place. Les arguments
utilisés sont :
92
Fig. 3 : Notre application Palm OS minimaliste et
sa boîte de dialogue. Une base pour le développement
d’une application plus utile...
Arrêtons là cette longue introduction. Pour poursuivre
l’exploration par vous-même, il n’existe qu’une seule solution :
vous connecter sur le site PalmSource et parcourir les différentes
documentations développeurs concernant Garnet.Absolument
tout ce que vous avez besoin de savoir s’y trouve.
Un coup d’œil sur Cobalt
Bien qu’il y ait fort à parier que Garnet reste encore l’OS le
plus utilisé dans les prochains temps, Cobalt (alias Palm OS
6.1) est d’ores et déjà prêt. Il s’agit d’une refonte radicale par
rapport aux versions précédentes du système.
La montée en puissance et les nouveautés apportées sont
principalement dues à l’utilisation de processeurs plus
puissants comme l’ARM ou le Xscale. La présence d’une MMU
(Memory Management Unit), l’unité de gestion de mémoire
 GNU Linux Magazine France
Développez des applications Palm OS
qui fait défaut à tout la lignée 68K, permet des innovations
importantes parmi lesquelles :
Une architecture permettant la protection mémoire.Alors
qu’une application Palm OS peut, pour l’heure, faire ce qui lui
chante (ou presque) de la mémoire, Cobalt en se reposant
sur la MMU du processeur pourra mettre en œuvre des
mécanismes de protection comme on en trouve que sur les
machines de bureau. Il en découlera une plus grande sécurité
et stabilité pour l’ensemble du système.
L’arrivée du multithreading. Il ne s’agit plus d’astuces de
développement mais de véritables multitâches. Une application
reposant sur l’API Protein pourra exécuter et gérer plusieurs
threads, tout comme avec un système GNU/Linux. Coté
utilisateur cela signifie des choses simples comme la lecture
de MP3 en tâche de fond. Côté développeur, cela signifie
l’ouverture vers un tout autre domaine technologique à
exploiter.
Ceci ne représente que la partie la plus importante des
nouveautés proposées par Cobalt. Vous trouverez une liste
plus complète sur le site PalmSource (http://www.palmos.
com/dev/tech/oses/cobalt60.html). Si vous comptez porter des
applications vers Cobalt (sans utiliser PACE), la documentation
« Porting Applications to Palm OS Cobalt » vous guidera... à
condition de digérer les quelques 598 pages du PDF.
Du côté des chaînes de développement pour GNU/Linux
rien n’est vraiment clair. Pour l’heure, l’intégralité du support
semble ne concerner que le système Microsoft. Pire encore,
il semblerait, selon la documentation que les PRC-Tools ne
servent plus qu’au code 68K, GCC pour le développement
d’applications Protein destinées au simulateur et PACC, le
« Palm OS Protein C/C++ Compiler » pour les applications
pouvant fonctionner sur les périphériques Cobalt. Ne jurons
de rien, mais le peu de support Protein/Cobalt concernant
GNU/Linux et l’absence complète d’une mention de ce système
dans la documentation développeur laissent clairement penser
que PACC ne serait pas porté sous GNU/Linux.
2
Fig. 4 : Notre application Palm OS minimaliste
et sa boîte de dialogue. Une base pour le
développement d’une application plus utile...
Si tel était effectivement le cas, nous pourrions
toujours nous consoler en remarquant qu’une
machine incluant quelques 256 Mo de Flash
et de RAM pilotée par un ARM7 sera bien
capable de faire fonctionner un GNU/Linux
en lieu et place de Cobalt...
Denis Bodor,
sites
incontournables:
/
/
p
www.gnulinuxmag.com
t
t
w
H
www.ed-diamond.com
w
Toute l’actualité du magazine sur :
Abonnements et anciens numéros en vente sur :