Java sur PDA

Bonjour,

Je vais devoir réaliser une appli de saisie de données offline sur PDA.
Les données à saisir seront initialisées sur le PDA dans une base de données
(probablement avec un fichier XML extrait d'une application web,ou via un
webservice), puis rappatriées en fin de saisie (le meme fichier XML complété
avec les données, extrait depuis le PDA).
Qqun a-t-il déjà fait ce genre de choses avec J2ME ?

Bonjour,

Tout dépend du domaine ou tu évolues et du métier à gérer par l'application.

J'ai l'impression qu'il n'y a pas énormément de ressources, et que bcp de
dév migrent vers .NET Compact Framework, ce que je souhaiterais éviter.

Bcp migrent vers le CF ? ah, pas vu :o) ... quite à faire du spécifique
MS pourquoi se limiter à une plateforme qui bride les fonctionalités et
dont on a peu de visibilité sur l'évolution et la pérénité long terme.
Ceux qui ont besoin de spécifique MS CE continuent de faire en grande
majorité du natif classique et spécifique ... au moins là ça marche :)

Coté Java, l'avantage l'omni-disponibilité de Java ME : plus d'un
milliard de péripherique sur cette planete sont compatible, ça compte !
Qui plus est, lorsqu'elle n'est pas dispo par défaut, il est facile de
trouver des kits adaptables chez différent éditeur selon les plateformes
ciblés. Par exemple pour tout les machines Symbol (et toutes les
machines CE) on peut utiliser CrEme de http://www.nsicom.com/ .

Enfin, l'ensemble de la plateforme Java ME étant ouverte, et libre (Java
ME RI sous GPL) sur https://phoneme.dev.java.net/ on a une bonne
visibilité et un tas de possibilités.

L'inconvenient, est que la spec Java ME est trés souple et permet
d'implementer ce que l'on veut dedans, ce qui a créé pas mal de bazard
car si l'on doit supporté un large parc on se retrouve à devoir prévoir
des systèmes de configuration en fonction des capacités de la machine
cible. Mais ce n'est pas ton cas ;-)

Je n'ai pas de contrainte particulière concernant le type de PDA.

Merci pour vos retours d'expérience.

De mon coté, tout dépend du type d'ergonomie que tu cherches :
- manipulation rapide par touches racoucis (préféré pour taches
répétitives)
- manipulation intruitive tactile (préféré si interraction alterné
avec manipulation, par exemple en attelier)
- manipulation intuitive par stylet (préféré si besoin de manipulation
graphique complexe: création d'assemblage, signature, etc)


Pour résumer, oui Java ME marchera nickel dans ton cas. Pour celà tu
dois déterminer le type d'appli et lister les API qui te seront
nécessaires pour implementer le tout. Enfin, lister les contraintes
matérielles, et croiser les deux pour choisir tes machines.

Quelques liens pour creuser plus :

http://www.netbeans.org/kb/55/svg-tutorial.html
http://www.netbeans.org/kb/55/mobility-lbs-demo.html
http://blogs.sun.com/lukas/entry/videos_of_svg_support_in
et bien sûr
http://www.netbeans.org/products/mobility/

Bon code...

A+
TM

TestMan wrote:

Coté Java, l'avantage l'omni-disponibilité de Java ME : plus d'un
milliard de péripherique sur cette planete sont compatible, ça compte !
Qui plus est, lorsqu'elle n'est pas dispo par défaut, il est facile de
trouver des kits adaptables chez différent éditeur selon les plateformes
ciblés. Par exemple pour tout les machines Symbol  (et toutes les
machines CE) on peut utiliser CrEme de http://www.nsicom.com/ .

Je n'ai pas du tout le même ressenti.

Il y a souvent du java dans toutes ces petites choses, mais avec de fortes
incompatibilités ("configurations", dit-on dans le langage diplomatiquement
correct) entre elles, et surtout il s'agit souvent des composants payants ;
rien de semblable à ce que l'on voit sur les PC.

Manifestement, coté PDA ou téléphone portable, l'hégémonie Microsoft manque,
et Sun semble beaucoup moins pressé d'y établir une plate-forme réellement
portable et gratuite.

Exemple entre 1000 : j'ai un Palm, qui comporte un Java ME que je suis
parvenu à installer après je ne sais combien de temps de recherche (la
version standard ne permet même pas de recevoir des jad ou des jar, ce qui
est tout de même fort). J'ai voulu y installer un paquetage bluetooth.

Les paquetages bluetooth sont gratuits pour les PC, mais payants pour les
Palm... cherchez pourquoi ?... Conséquence : moi, je ne suis pas du tout
contre Microsoft, grâce auquel je dispose d'un excellent langage de
développement gratuit, même si ce n'est que sur PC...


--
Hervé AGNOUX
http://www.diaam-informatique.com

Bonjour,

TestMan wrote:

Coté Java, l'avantage l'omni-disponibilité de Java ME : plus d'un
milliard de péripherique sur cette planete sont compatible, ça compte !
Qui plus est, lorsqu'elle n'est pas dispo par défaut, il est facile de
trouver des kits adaptables chez différent éditeur selon les plateformes
ciblés. Par exemple pour tout les machines Symbol (et toutes les
machines CE) on peut utiliser CrEme de http://www.nsicom.com/ .

Je n'ai pas du tout le même ressenti.

Il y a souvent du java dans toutes ces petites choses, mais avec de fortes
incompatibilités ("configurations", dit-on dans le langage diplomatiquement
correct) entre elles, et surtout il s'agit souvent des composants payants ;
rien de semblable à ce que l'on voit sur les PC.

Manifestement, coté PDA ou téléphone portable, l'hégémonie Microsoft manque,
et Sun semble beaucoup moins pressé d'y établir une plate-forme réellement
portable et gratuite.

Exemple entre 1000 : j'ai un Palm, qui comporte un Java ME que je suis
parvenu à installer après je ne sais combien de temps de recherche (la
version standard ne permet même pas de recevoir des jad ou des jar, ce qui
est tout de même fort). J'ai voulu y installer un paquetage bluetooth.

Les paquetages bluetooth sont gratuits pour les PC, mais payants pour les
Palm... cherchez pourquoi ?... Conséquence : moi, je ne suis pas du tout
contre Microsoft, grâce auquel je dispose d'un excellent langage de
développement gratuit, même si ce n'est que sur PC...

Faux, Bluesoleil et Widcomm sont pas gratuits, et sont les seules façon
d'avoir du bluetooth correct (support des profils avancés) sur un PC
Windows, même si Vista améliore un peu la chose.

Quand au monde du mobile ou de l'embarqué, il n'est pas comparable au
monde PC. Car dans le premier, vous achetez un produit "sur étagère" qui
comporte déjà un système d'exploitation personalisé par le fabricant du
périphérique (souvent selon les besoins/demandes des opérateurs ou
intermédiaires). Dans le cas du monde PC, c'est le client final qui
choisit sa configuration en fonction de ces besoins et peut installer
son propre système configuré à sa guise. Les modèles financiers
sous-jacents sont donc trés différents (sauf chez certains grands
distributeurs type Dell ou l'on retrouve aussi des rétro-marges et
avantages tiers, et de la personalisation mais qui s'apparente plutôt à
du groupage logiciel).

Le problème de fourniture de pilote adequat, standard et performant est
donc à la charge et du ressort du fabricant du périphérique et non pas
des responsable de la spécification ou du standard.

Et que l'on fasse du natif, du Java ME ou du CF.net, c'est le même problème.

Pour exemple, je citerais les difficultés pour accéder à la caméra de
des périphériques HTC. Tout simplement parce qu'il faut obtenir une
license de HTC pour accéder à leur API propriétaire de camera. Ainsi, ni
une CLR .net ou une JVM ME ne permet d'utiliser de camera sur les
mobiles HTC PPC2003 de façon standard. Des "bricolages" existent, mais
ils sont innaceptables dans une utilisation en production. Heureusement,
l'API de camera étant maintenant en standard sous WM5, HTC l'a
implementé sous WM5 pour ces nouveaux appareils. C'est un exemple à la
marge, mais qui montre bien la spécificité du monde du mobile/embarqué.

Au final, toute l'importance est dans le choix du matériel et de la
capacité du fabricant à fournir des pilotes suivant et conforme aux
spécifications.

Quand aux remarques sur la portabilité, ils sont hors propos. Java ME
est réellement 100% portable, mais les difficultés viennent de la
fragmentation des spécification et du trop grand nombre de chose
optionelles qu'il est possible de faire (sans compter, la fragmentation
des capacités des différentes machines visées). Pour ce qui est de la
gratuité, PhoneME (l'immplementation de référence) est gratuite, libre
et impleme une grande partie des JSR mobiles (dont la JSR-82 pour
bluetooth) voir https://phoneme.dev.java.net/content/phoneme_feature_r2.html

Étant sous GPL, tout le monde est donc libre de porter le code à son
grès et selon ses besoins...

A+
TM

TestMan wrote:

Quand aux remarques sur la portabilité, ils sont hors propos. Java ME
est réellement 100% portable, mais les difficultés viennent de la
fragmentation des spécification et du trop grand nombre de chose
optionelles qu'il est possible de faire (sans compter, la fragmentation
des capacités des différentes machines visées). Pour ce qui est de la
gratuité, PhoneME (l'immplementation de référence) est gratuite, libre
et impleme une grande partie des JSR mobiles (dont la JSR-82 pour
bluetooth) voir
https://phoneme.dev.java.net/content/phoneme_feature_r2.html

100% portable, aux fragmentations près... bon... le monde Java nous avait
habitué à mieux.

Et Phone ME peut-il fonctionner sur mon PDA Palm Tungsten E2, que j'ai
acheté il y a à peine 6 mois ? (et si "oui", par extraodinaire, merci de me
dire comment).

Et j'ai bien compris que le modèle économique de PDA et autres n'était pas
le même que celui des PC ; d'où, justement, les incompatibilités
constatées, à ce qu'il me semble. Tout ceci renforce ce que je disais, je
crois ? Peut-être considérais-tu que théoriquement la compatibilité était
de 100%, mais que pratiquement, ce n'était pas vraiment le même topo ? Et
que le modèle économique était une forme d'explication ?

... donc nous sommes d'accord.


--
Hervé AGNOUX
http://www.diaam-informatique.com

Bonjour,

TestMan wrote:

Quand aux remarques sur la portabilité, ils sont hors propos. Java ME
est réellement 100% portable, mais les difficultés viennent de la
fragmentation des spécification et du trop grand nombre de chose
optionelles qu'il est possible de faire (sans compter, la fragmentation
des capacités des différentes machines visées). Pour ce qui est de la
gratuité, PhoneME (l'immplementation de référence) est gratuite, libre
et impleme une grande partie des JSR mobiles (dont la JSR-82 pour
bluetooth) voir
https://phoneme.dev.java.net/content/phoneme_feature_r2.html

100% portable, aux fragmentations près... bon... le monde Java nous avait
habitué à mieux.
Ma remarque était en réaction de votre phrase "une plate-forme

réellement portable", qui métait en doute la portabilité de la
plate-forme Java ME.

Portabilité, compatibilité, ... les mots ont leur importance et une
forte différence.

Les appli ME sont 100% portable c'est un fait.

Maintenant si vous utilisez des API qui ne sont pas obligatoire vous
allez vous exposer à différents scénarios à gérer (sauf si vous décidez
simplement de poser des pré-requis). Dans une entreprise on peut poser
des pré-requis, un opérateur télécom, lui va devoir gérer
l'hétérogénéité des capacité des mobiles en présence :(

Ceci est entierement identique à l'utilisation d'extensions standard
dans du Java SE au passage : on rajoute du prérequis ...

Et Phone ME peut-il fonctionner sur mon PDA Palm Tungsten E2, que j'ai
acheté il y a à peine 6 mois ? (et si "oui", par extraodinaire, merci de me
dire comment).

Du fait que le µP est un Xscale, je pense que vous devriez tester la
compil du code, restera l'intégration avec les parties native ...
peut-être en partant des codes natifs versions linux ...mais sur de la
5.4 rien n'est sûr (java.net est HS en ce moment, impossible de vérifier).

Si vous êtes volontaires pour tester ça et disposez de solides
compétences Palm, ça peut le faire :)

Et j'ai bien compris que le modèle économique de PDA et autres n'était pas
le même que celui des PC ; d'où, justement, les incompatibilités
constatées, à ce qu'il me semble. Tout ceci renforce ce que je disais, je
crois ? Peut-être considérais-tu que théoriquement la compatibilité était
de 100%, mais que pratiquement, ce n'était pas vraiment le même topo ? Et
que le modèle économique était une forme d'explication ?

Si vous avez une application qui nécessite une webcam mais que le client
l'execute sur un portable sans webcam, cette application ne fonctionera
pas correctement.

Peut-on pour autant parler de problème de portabilité dans ce cas ? Pour
moi c'est un problème de compatibilité matérielle.

Autre cas, une application de fax envoit du flux postscript mais le
fabricant de votre imprimante à décidé de faire l'économie de la gestion
PS résultat, celà ne fonctione pas ... est-ce de la responsabilité de
windows, de votre application ? Non, encore un fois, c'est une
limitation du ressort du fabricant (qu'il s'est bien caché de faire
apparaitre sur la boite).

Enfin, cas général, la taille d'écran, XP est donné pour fonctioner en
800x600 ... pourtant à cette résolution bon nombre d'application sont
inutilisables. Est-ce un problème de portabilité de la technologie windows ?

Tous ces problèmes de configuration matérielles se retrouveront quelque
soit la technologie utilisée (Java, MS, Linux ou tartanpion) ...

... donc nous sommes d'accord.

"Ou bien" :o)

A++
TM
PS : ZUI et SVG en force ;-)

Le Tue, 3 Apr 2007 13:10:36 +0200,
Lionel <SPAMcoollATfreePOINTfr> disait ceci :

Bonjour,

Je vais devoir réaliser une appli de saisie de données offline sur PDA.
Les données à saisir seront initialisées sur le PDA dans une base de données
(probablement avec un fichier XML extrait d'une application web,ou via un
webservice), puis rappatriées en fin de saisie (le meme fichier XML complété
avec les données, extrait depuis le PDA).
Qqun a-t-il déjà fait ce genre de choses avec J2ME ?

J'ai l'impression qu'il n'y a pas énormément de ressources, et que bcp de
dév migrent vers .NET Compact Framework, ce que je souhaiterais éviter.
Je n'ai pas de contrainte particulière concernant le type de PDA.

Merci pour vos retours d'expérience.

Bonjour,
Tout dépend des raisons qui te poussent à choisir Java sur le PDA.

Pas sur de ce que j'avance mais je pense que sur un PDA, la notion
portabilité de Java à ses limittes.

Dans ce cas autant miser sur des routines natives en JNI.
(Java Native Interface) et donc écrire le non supporté
en C ou C++.

Ce n'est pas très difficile (disons dans le principe).

De toutes façons, les langages de base sont souvent incontournables.

Pim.