Discutez en sur les forums

1) Etre attentif à la version
C'est de moins en moins un problème sur les ordinateurs de bureau (en décembre 2003, plus de 90% des ordinateurs testés pouvaient au moins lire les animations Flash 6, selon les statistiques de Macromedia sur le Flash Player), mais le problème de la version du Player risque fortement de se retrouver lors de la création d'applications mobiles.

De fait, pour l'heure, il n'existe qu'un Player pour Pocket PC, et il en est à la version 6. Plus récemment, certains Sony CLIÉ intègrent le Flash Player 5, tandis que certains téléphones i-mode disposent d'une version "spéciale mobiles" du Player, Flash Player Lite 1.0, pouvant utiliser les objets Flash 5 et l'ActionScript Flash 4. Le site de Macromedia indique enfin que le Motorola A920 dispose du Flash Player 5, ainsi que les PDA "Communicator" de Nokia.
Les choix possibles sont forcément amenés à s'élargir, mais il est primordial aujourd'hui de savoir précisément quelle cible est visée par l'application, afin de développer un produit qui réponde effectivement aux capacités du lecteur.

2) Prendre en compte les différentes tailles
Tout comme la version du Player, la résolution disponible doit entrer en compte dès le lancement du projet : en effet, il ne s'agit plus ici de questions de proportionnalité (640*840, 800*600 et 1024*768 sont tous d'un ratio 4/3) mais bien d'écrans totalement différents, parfois plus larges que haut, parfois l'inverse. Le Pocket PC, par exemple, tourne généralement en 240*320.

Les développeurs utilisant Flash MX 2004 ont ici la tâche rendue plus facile par l'arrivée des modèles ou templates, notamment une vingtaine de modèles mobiles pour les marques iPAQ ou Nokia, ce qui permet de créer d'entrée de jeu une interface correspondant à la résolution définitive de l'application.

Par ailleurs, autant que faire se peut, il faut clairement séparer le contenu du contenant, dès que l'application doit tourner sur plusieurs terminaux, afin d'avoir un minimum de travail à faire pour adopter une nouvelle résolution... Cela va permettre par ailleurs au développeur de prendre de l'avance si d'aventure son client veut la même application pour un nouveau terminal.

3) Se documenter sur les capacités
Ce n'est pas pour rien que Macromedia a créé le Flash Player Lite : les terminaux mobiles disposent de considérablement moins de mémoire que leurs congénères de bureau. Par exemple, les nouveaux téléphones i-mode (900i) sont limités à des applications Flash de 100 Ko, les anciens (505i) à 20ko...
Ici, la seule manière de s'en sortir est de se documenter précisément sur le terminal-cible, et d'optimiser son application autant que possible (en évitant bien sûr les "hacks" qui n'ont fait leurs preuves que sur ordinateurs de bureau...).

4) Savoir que la connexion n'est pas toujours établie
Les terminaux mobiles sont plus souvent utilisés hors-ligne qu'en ligne, à la différence des ordinateurs de bureau qui sont quasi-constamment connectés à Internet. De fait, quand, sur un ordinateur, on peut créer une application qui, pour afficher des informations, doit sans cesse envoyer des requêtes à un serveur sur Internet, il n'en est pas de même pour une application Flash mobile : elle doit faire son possible pour fonctionner complètement hors-ligne, et donc sauver des données sur le terminal, et savoir quand lancer une requête sur Internet ou quand charger un fichier. En bref : l'application Flash doit savoir si elle a accès à Internet, et ce sans action requise de la part de l'utilisateur.

Sans accès aux SharedObject de Flash 6, le seul moyen de tester la connexion est de lancer effectivement une requête, et de voir si elle est positive, en utilisant la méthode Flash 5 loadVariablesNum() (et non loadVars(), réservée à Flash 6 et plus, et donc risqué) : loadVariablesNum("http://www.mon-site.com/cnx.txt?rand=" + randNum, 0); (l'utilisation de randNum() permet de s'assurer qu'on appelle toujours un nom de fichier différent).
Pour la sauvegarde de données, on passera également par loadVariablesNum(), ou par un appel du type getURL("javascript:getCookie()");, par exemple - et si le terminal reconnaît les cookies...

5) Faire simple !
Les utilisateurs de terminaux mobiles sont, si c'est possible, plus exigeants que les utilisateurs "de bureau", par définition : un terminal mobile est utilisé en marchant, en prenant le train, en voiture... rarement assis simplement à un bureau. De fait, les utilisateurs veulent avoir accès rapidement à l'information, et donc s'attendent à une interface extrêmement intuitive, sans fioritures, sans animations ni sons en trop...
Ajoutons que l'utilisation de sons, d'animations ou même de certains contrastes peut avoir un effet sur l'utilisation de la mémoire et la batterie. Faire simple, c'est préserver l'utilisateur.