Bonjour,
je dois choisir un langage pour faire développer un logiciel très simple dans sa fonction et sa conception.
Une appli cliente qui se connecte à un serveur mysql, avec des tris pour afficher des résultats.
Ce logiciel doit être en "standalone", fonctionnel sans installation, juste en l'exécutant.
Il doit être aussi multiplateforme, c'est à dire utilisable sous Linux, MacOSX, Windows mais aussi sur Windows Mobile, Symbian, Palm OS (téléphone portable et smartphone).
Le langage doit être assez standard pour vite trouver les compétences sur le marché du travail.
Ce sont les seules contraintes, j'ai pensé à du java mais pour l'OS Symbian j'ai un doute et puis je sais pas si ça permet de faire un exécutable en "standalone".
Quels sont vos expériences à ce sujet?
Merci beaucoup.
Journal Langage multi-plateforme et plus...
5
oct.
2006
# Exécutable java
Posté par Sébastien Koechlin . Évalué à 2.
Se connecter à une base de donnée: Java viens avec une API simple nommée JDBC qui est très largement supporté par pleins de bases; cela te permettra d'adapter très facilement le logiciel le jour ou tu voudras changer de base de donnée.
Afficher des résultats: si tu penses à une interface graphique, Java vient avec une API un peu complexe je pense, nommée SWIG qui fait tout cela sur toutes les plateformes.
Fonctionnel sans installation: il est possible de distribuer les applications sous forme d'un fichier JAR qui est un fichier au format zip contenant le code, les ressources et un fichier texte décrivant quelle classe doit être lancée lorsque le JAR est exécuté. Il est nécessaire d'avoir Java2 (la version Runtime) installé sur l'OS. Sous windows, il suffit de double-cliquer sur le fichier JAR.
Multiplateforme: il faut voir si Java2 est disponible sur toutes les plateformes que tu veux utiliser. Il est peut-être possible de réduire l'application pour qu'elle tourne sur la version mobile, ou d'avoir deux interfaces de sortie selon les disponibilités.
Assez standard pour vite trouver les compétences: Java est extrèmement répandu en ce moment.
[^] # Re: Exécutable java
Posté par Frédéric COIFFIER . Évalué à 3.
Certes, pas besoin d'installer l'application mais il faudra quand même installer la machine virtuelle (Windows (Offline Installation) (filesize: 16.00 MB)).
On peut installer la JVM sous Windows sans les droits admins ?
[^] # Re: Exécutable java
Posté par Snarky . Évalué à -2.
heuu, toutes...
La JVM marche sous Linux en dézippant juste un fichier... Donc je pense que pour windows on doit pouvoir avoir faire la même chose.
[^] # Re: Exécutable java
Posté par kraman . Évalué à 1.
Par contre, l'installeur est indispensable pour profiter du %CLASSPATH%, du %JAVA_HOME% et des commandes javac/java dans le path.
Mon equipe avait livre un .exe builde avec l'installateur open source populaire (oublie le nom, sorry, si quelqu'un peut me rafraichir la memoire), qui embarque un jre+l'appli dans 12Mo.
Bon, on avait ampute le jre de classes inutiles, on avait clairement pas le droit de le distribuer, mais on s'en pétait; on etait presta et c'etait pas notre probleme.
Bien lire la licence de sun pour ce qui est de la redistribution du jre.
heuu, toutes...
par defaut, surement pas. La seule a ma connaissance pour le grand public, c'est mac os X.
Et je suppute solaris, evidemment.
Maintenant, faire du reellement portable sans ajouter de runtime tierce partie, ben va falloir se lever tot et boire de l'eau fraiche.
Ou alors etre pret a se fader 25 branches dans le cvs.
[^] # Re: Exécutable java
Posté par TemPi . Évalué à 1.
Oui, bien sûr !
[^] # Re: Exécutable java
Posté par kraman . É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.
# Appli xulrunner
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 0.
Se connecter à une base de donnée: Tu peux installer l'extension qui permet d'attaquer du mysql ou du postgresql (certes pas évidente encore à compiler, mais ça marche). Tu as également maintenant l'API mozstorage (utilisée dans Firefox 2), qui embarque directement SQLite : plus besoin de serveur de base de donnée.
Afficher des résultats : l'interface se fait en XUL, un langage XML de déscription d'interface. La modification se fait donc comme dans une page web, en utilisant le DOM. Et tu peux designer tout ça via CSS.
Fonctionnel sans installation : une appli pour xulrunner, c'est un simple .app (fichier zip, ou alors un repertoire) contenant tous les fichiers XUL, javascript, CSS etc..
Multiplateforme: Comme toutes les applis XUL, ton appli est utilisable sur toutes les plateformes où existe XulRunner (c'est à dire quasiement toute). Sauf sur les mobiles... Faudrait voir si c'est pas trop lourd en fait pour les mobiles..
Les standards: Coder une appli XUL, c'est utilisé le XUL (qui est à l'étude au W3C), XBL (qui est en working draft au w3c), et CSS, Javascript voir Xforms, C++, XHTML, RDF etc... qui sont tous des standards. Bref, tout est pratiquement que des standards.
Et sachant que les compétences en XUL sont de plus en plus demandées...
Et pour développer, pas besoin de compilateur super lourd (sauf si tu fais des composants c++, ce qui est rare) : un simple éditeur et un zip suffisent.
[^] # Re: Appli xulrunner
Posté par Frédéric COIFFIER . Évalué à 3.
Je ne pense pas que la base de données MySQL tourne à côté de l'application. Sinon, je serai étonné de voir ça sur un mobile (Symbian) ou un palm (PalmOS).
XulRunner, c'est une appli standalone ou il faut l'installer ?
[^] # Re: Appli xulrunner
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
pour moi, une appli standalone, il faut l'installer. non ? Qu'appelles tu installer ? Qu'appelles tu standalone ?
[^] # Re: Appli xulrunner
Posté par Frédéric COIFFIER . Évalué à 3.
Bref, sous Windows ou Linux, on télécharge un exécutable (au pire un Zip contenant quelques fichiers), on lance l'exécutable et ça marche sans avoir eu à installer un package quelconque.
Ici, peut-on imaginer avoir un XulRunner.exe + fichiers du projet XUL dans un Zip et lorsque l'on dézippe le fichier, en double-cliquant sur le fichier projet, avoir une appli qui fonctionne ?
[^] # Re: Appli xulrunner
Posté par alexissoft . Évalué à 2.
La réponse est oui. Tu prend le xulrunner.zip pour windows, du dézippe, et ensuite après tu récupère le xulrunner-stub.exe et tu le renomme au nom de l'appli (ou un truc du genre pour qu'il sache quel fichier .js voir, t'as des tutos sympa sur xulfr.org). Ensuite double clic sur ce .exe et POUF.
# eTcl
Posté par B16F4RV4RD1N . Évalué à 3.
http://wiki.tcl.tk/eTcl
C'est le premier langage que je vois qui peut fonctionner directement d'une plateforme à l'autre (pour info je n'ai toujours pas trouvé de jre tournant sous pocketpc qui permette d'utiliser des applications java standard)
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
# Environnement Mobile
Posté par Ririsoft . Évalué à 5.
Si tu comptes développer une interface graphique, tu auras du mal à faire un truc qui s'utilise sur Windows, Linux, MacOS d'une part et Windows Mobile, Symbian, Palm Os ou autre environnement mobile d'autre part, sans aucun changements.
Je m'explique :
Le développement d'une interface graphique en environnement mobile demande une conception particulière dans la gestion de l'IHM (interface homme-machine) et des ressources matérielles (mémoire, espace disque ....).
L'exemple le plus parlant est la gestion de la taille de l'écran : tu devras faire attention à ce que les fonctionnalités principales soient accessibles facilement en quelques clics de stylet, et tu devras utiliser des barres de défilement au bon endroit. Les choix que tu feras pour que ton appli soit jolie et facile d'accès sur un PDA feront que ton appli ne sera pas super belle sur un systeme classique avec un gros écran.
Ce que je te recommande c'est de séparer le code de l'interface graphique et le code fonctionnel (celui qui va se connecter à ta base, faire les requêtes et renvoyer le résultat).
La librairie de traitement "fonctionnel" pourra être utilisée indifféremment sur n'importe quelle plateforme tandis ce que l'interface graphique doit être pensé selon qu'elle sera sur un PC classique ou sur un PDA.
Comme te le conseillent les commentaires précédents, java est très bien adapté pour tout ça : très portable, tu trouveras une machine virtuelle pour tous les environnements que tu veux ainsi qu'une multitude de librairies qui feront tout le boulot pour toi (gestion de la connexion à la base de données, gestion de l'IHM ...).
Tu peux aussi utiliser .NET de Microsoft qui est tout à fait comparable à java pour une telle application.
Bon courage, et n'oublie de revenir nous montrer le résultat !
# Et Qt4 ?
Posté par Frédéric COIFFIER . Évalué à 3.
Par contre, il fonctionne sur Windows, Linux et MacOSX. Malheureusement, pas sous Symbian ou PalmOS (même si Qtopia est orienté mobile et smartphone, il faut que ça tourne sous Linux embarqué).
Qt intègre tout ce qu'il pour accéder à une base SQL.
Une bonne documentation ce qui permet de coder très vite même en ne connaissant pas du tout Qt.
Pour l'installer, il suffit d'avoir les quelques DLL correspondantes à livrer avec l' .exe (sous Linux, les .so avec l'appli).
[^] # Re: Et Qt4 ?
Posté par chraa_n . Évalué à 2.
la base de donnée sera bien sur un serveur à distance et non pas intégrée directement à l'appli.
"pour info je n'ai toujours pas trouvé de jre tournant sous pocketpc qui permette d'utiliser des applications java standard"
Superwaba fait ça très bien. Bien sur comme le faisait remarqué chicha, il faut adapter l'IHM à la plate-forme de type mobile.
http://www.superwaba.com.br/fr/default.asp
questions : si une machine virtuelle java est déjà installé sur la plate-forme (allez sur une machine sous Linux par exemple), le fait de cliquer dessus lance l'appli directement ou non? Puis-je distribuer la machine virtuelle en même temps que l'appli (pas GPL blabla)? Sous Symbian, le java passe ou non?
Le fait de l'avoir en 'standalone', tout le monde l'aura compris, c'est de permettre une diffusion très facile car on évite trop de manip pour voir ce que fait le logiciel. Dans un monde de plus en plus "faut ce que ça aille vite, j'ai pas le temps" ;-)
je vais creuser aussi eTcl.
Merci sincèrement pour vos réponses très détaillées!
[^] # Re: Et Qt4 ?
Posté par chraa_n . Évalué à 2.
[^] # Re: Et Qt4 ?
Posté par Nicolas Dumoulin (site web personnel) . Évalué à 2.
Sauf erreur de ma part, les bindings pour python sont disponibles :-)
# Symbian
Posté par jberchet . Évalué à 4.
j'ai un téléphone sous symbian (communicator 9500)
il a une machine virtuelle embarquée en standard dessus (java sun)
j'ai essayé plusieurs applications simple en java ça fonctionne bien
en gros un bon jar s'execute tout seul
il faut juste vérifié que les appareils sous symbian cible ont un support java ce qui est vrai pour tout les appareils symbian pas trop anciens
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.