'tention pour la version mobile (J2ME).
Bossant presentement sur une appli de ce type, j'ai les remarques suivantes a faire :
- Necessiter de bosser en MIDP/CLDC 1.0 si on veut ratisser large. Exit la signature de jar, exit un gros paquet de classes.
Avantage : la gui est simple a gerer.
- L'API j2se a ete taillade a coup de hache. Au revoir String.replaceAll, String.compareTo leve un NullPointerException quand l'argument est null (exit donc les "".compareTo(maString) et ca c'est rude).
Exit l'interface Map. Aïe. Pour ne pas se sentir seule, elle a embarquer avec elle sa copine, List. Nom di diou.
Adieu la classe Properties. Ouch. La ca commence a devenir dur a gerer.
Ciao Integer.toHexString et autres du meme acabit. Ca c'est pas trop genant, mais un dev habitue a du j2se va etre tres irrite de voir que la methode qu'il avait l'habitude d'utiliser par elegance va lui peter a la gueule.
SWING a bien evidemment ete atomise et n'existe plus du tout (qui a dit tant mieux? :P). On les comprends, on va pas embarquer une usine a gaz pareille sur un telephone.
Si c'est pour faire un source commun j2se/j2me, faut etre super rigoureux au codage (un bon ide est un plus, genre eclipse), et ca va chiffoner plus d'un dev ayant prit de bonne habitudes (ie utiliser les interfaces pour declarer une variable de type liste ou map, par ex, ou comparer une constante a une chaine en faisant un "maconstante".compareTo(maChaine)==0).
- Necessiter de compiler en bootstrappant avec cldc10.jar et midp10.jar, donc perte de la portabilite du binaire (bon, c'est pas dramatique, surtout si on utilise un bon ide, genre eclipse couple a un bon build ant).
- Niveau gui, GROSSE GROSSE variation au niveau des implementation entre constructeurs. On a ete oblige de hardcoder un modele de telephone qui gere mal les taille max des champs (il faut lui donner taille max + 1 a cecon, j'crois que c'est le 6600, encore lui). mobile 5 gere les TextField comme un abruti, les gui varient enormement d'un phonetel a l'autre. Sinon, le reste ca rentre comme papa dans maman la portabilite binaire est au rendez vous, et ca fait zizir ca.
A noter la dispo du plugin eclipseme pour eclipse, qui permet, couplé au jars du wtk22 de sun de se passer totalement de l'outil de sun pour ce qui est compile/packaging/generation du jad.
Et surtout, surtout, surtout, de pouvoir debugger sa midlet dans eclispe (et ca j'peux vous garantir quand on le trouve le plugin, c'est la fete dans le bureau, champagne, coc' et putes sur le compte de bibi).
A noter, certains telephones ont de grosses limites : 32ko allouables, 64 ko de taille max pour le jar.
Et 64ko, ca a pas l'air, mais quand on code propre (ie des petites classes, beaucoup d'heritage, beaucoup de packages), ca arrive SUPER vite. Proguard est votre ami, il m'a fait gagner presque 50ko en obfusquant.
Niveau dispo, la liste est longue, tres longue.
La comme ca de tete, j'ai pas d'exemple de plateforme non supportee (ah si ptetre linux ppc. Ya quelque chose qui tourne sur linux ppc ou quoi?)
Niveau telephone: windows mobile 2003, mobile 5, symbian os (c'est bien ca qu'il ya dans les nokia genre 6600?) sont supportes. Les telephones implementent divers profils, mais vu qu'ils sont backward compatible, en se limitant a midp/cldc 1, on tape dans tous les javaphones.
Le deploiement est relativement simple : deploiement par jad/jar (descripteur d'appli/appli) et la c'est zezette : MIDP2 supporte la signature, top moumoute, et yakacliqé sur un lien http envoye, par exemple, par sms et zou, ca telecharge et installe, c'est fun, c'est fluo, la vie est belle. A noter que j'ai eu de gros problemes avecle spv600 d'orange (qtek je sais pas combien), au niveau de la gestion du cache pour ce type de deploiement. En fait mobile 5 a un comportement totalement farfelu au niveau du cache d'ie/OTA que j'ai toujours pas reussi a cerner completement.
Si bluetooth est dispo, ya qu'a envoyer le fichier par la dent bleue et paf, yapuka installer.
Mon avis perso a moi que j'ai : c'est de toutes facons la seule et unique plateforme qui tourne sur des telephones divers et varies, du machin qui fait juste telephone tout con avec un ecran 96xPas beaucoup au telephone de ouf qui fait photo, fax, scanner, gode, fait le cafe, promene le chien, ramene ta femme et fait fuire le patron.
Le fait de pouvoir faire source commun avec une version "pc de bureau" est un plus, mais dont il ne faut pas abuser sous peine de se voir tres limite sur la version bureau.
[^] # Re: Exécutable java
Posté par kraman . En réponse au journal Langage multi-plateforme et plus.... Évalué à 3.
Bossant presentement sur une appli de ce type, j'ai les remarques suivantes a faire :
- Necessiter de bosser en MIDP/CLDC 1.0 si on veut ratisser large. Exit la signature de jar, exit un gros paquet de classes.
Avantage : la gui est simple a gerer.
- L'API j2se a ete taillade a coup de hache. Au revoir String.replaceAll, String.compareTo leve un NullPointerException quand l'argument est null (exit donc les "".compareTo(maString) et ca c'est rude).
Exit l'interface Map. Aïe. Pour ne pas se sentir seule, elle a embarquer avec elle sa copine, List. Nom di diou.
Adieu la classe Properties. Ouch. La ca commence a devenir dur a gerer.
Ciao Integer.toHexString et autres du meme acabit. Ca c'est pas trop genant, mais un dev habitue a du j2se va etre tres irrite de voir que la methode qu'il avait l'habitude d'utiliser par elegance va lui peter a la gueule.
SWING a bien evidemment ete atomise et n'existe plus du tout (qui a dit tant mieux? :P). On les comprends, on va pas embarquer une usine a gaz pareille sur un telephone.
Si c'est pour faire un source commun j2se/j2me, faut etre super rigoureux au codage (un bon ide est un plus, genre eclipse), et ca va chiffoner plus d'un dev ayant prit de bonne habitudes (ie utiliser les interfaces pour declarer une variable de type liste ou map, par ex, ou comparer une constante a une chaine en faisant un "maconstante".compareTo(maChaine)==0).
- Necessiter de compiler en bootstrappant avec cldc10.jar et midp10.jar, donc perte de la portabilite du binaire (bon, c'est pas dramatique, surtout si on utilise un bon ide, genre eclipse couple a un bon build ant).
- Niveau gui, GROSSE GROSSE variation au niveau des implementation entre constructeurs. On a ete oblige de hardcoder un modele de telephone qui gere mal les taille max des champs (il faut lui donner taille max + 1 a cecon, j'crois que c'est le 6600, encore lui). mobile 5 gere les TextField comme un abruti, les gui varient enormement d'un phonetel a l'autre. Sinon, le reste ca rentre comme papa dans maman la portabilite binaire est au rendez vous, et ca fait zizir ca.
A noter la dispo du plugin eclipseme pour eclipse, qui permet, couplé au jars du wtk22 de sun de se passer totalement de l'outil de sun pour ce qui est compile/packaging/generation du jad.
Et surtout, surtout, surtout, de pouvoir debugger sa midlet dans eclispe (et ca j'peux vous garantir quand on le trouve le plugin, c'est la fete dans le bureau, champagne, coc' et putes sur le compte de bibi).
A noter, certains telephones ont de grosses limites : 32ko allouables, 64 ko de taille max pour le jar.
Et 64ko, ca a pas l'air, mais quand on code propre (ie des petites classes, beaucoup d'heritage, beaucoup de packages), ca arrive SUPER vite. Proguard est votre ami, il m'a fait gagner presque 50ko en obfusquant.
Niveau dispo, la liste est longue, tres longue.
La comme ca de tete, j'ai pas d'exemple de plateforme non supportee (ah si ptetre linux ppc. Ya quelque chose qui tourne sur linux ppc ou quoi?)
Niveau telephone: windows mobile 2003, mobile 5, symbian os (c'est bien ca qu'il ya dans les nokia genre 6600?) sont supportes. Les telephones implementent divers profils, mais vu qu'ils sont backward compatible, en se limitant a midp/cldc 1, on tape dans tous les javaphones.
Le deploiement est relativement simple : deploiement par jad/jar (descripteur d'appli/appli) et la c'est zezette : MIDP2 supporte la signature, top moumoute, et yakacliqé sur un lien http envoye, par exemple, par sms et zou, ca telecharge et installe, c'est fun, c'est fluo, la vie est belle. A noter que j'ai eu de gros problemes avecle spv600 d'orange (qtek je sais pas combien), au niveau de la gestion du cache pour ce type de deploiement. En fait mobile 5 a un comportement totalement farfelu au niveau du cache d'ie/OTA que j'ai toujours pas reussi a cerner completement.
Si bluetooth est dispo, ya qu'a envoyer le fichier par la dent bleue et paf, yapuka installer.
Mon avis perso a moi que j'ai : c'est de toutes facons la seule et unique plateforme qui tourne sur des telephones divers et varies, du machin qui fait juste telephone tout con avec un ecran 96xPas beaucoup au telephone de ouf qui fait photo, fax, scanner, gode, fait le cafe, promene le chien, ramene ta femme et fait fuire le patron.
Le fait de pouvoir faire source commun avec une version "pc de bureau" est un plus, mais dont il ne faut pas abuser sous peine de se voir tres limite sur la version bureau.