Discussion :

[lex13]

Bonjour a tous, je débute totalement en Java...je me suis laissé tenté par eclipse puis par Visual Editor et enfin par Swing.

Je voulais savoir a quel niveau été la portabilité de swing...
Qu'est ce qu'il faudra changer en clair entre la version windows et linux...
Je voulais aussi savoir (comme ça sa fera d'une pierre 2 coups), si JAVA inclus ça propre liste d'API...(par exemple j'aurais besoin d'une api qui recupère la source html d'une page web, ou encore une api qui ouvre une boite de dialogue pour enregistrer un fichier).


Merci à ceux qui prendront le temps de me lire et de me répondre

[sinok]

Bah oui, Swing est portable quelquesoit l'OS: pour la récupération de pageWeb c'est pas bien dûr en bricolant avec les classes URL et InputStream, puis pour l'enregistrement c'est prévu dans Swing avec le JFileChooser

[lex13]

ok merci pour cette réponse rapide.
mais alors s'il n'ya rien de différent entre un prog java windows et linux pourquoi alors à chaque fois y a 2 versions diférentes à telecharger (exemple avec azureus) ?

[sironimo]

Tout simplement car la différence n'est pas dans l'IHM mais dans les protocoles de communication avec l'OS.

[sinok]

Non, c'est qu'azureus n'utilise pas Swing mais SWT (à l'odentique d'eclipse), ensuite les protocoles réseau sont les mêmes.

[fr1man]

Et en complément, je dirais que tu as une version par OS, pour tenir compte des spécificités de chaque OS. Ca concerne plus, l'installation et le lancement de l'application, car l'application en elle même est identique.
Je parle des applis swing en général.

[adiGuba]

Salut,

Et en complément, je dirais que tu as une version par OS, pour tenir compte des spécificités de chaque OS. Ca concerne plus, l'installation et le lancement de l'application, car l'application en elle même est identique.
Je parle des applis swing en général.

Et même les applis Java en général !

Cela peut donc également inclure certaines librairies natives parfois nécessaire...



Mais il faut noter qu'il est possible d'uniformiser cela en déployant via Java Web Start...

a++

[lunatix]

azureus, c'est effectivement parce que c'est pas du swing, mais du swt

sinon, c'est surtout pour fournir un instaleur. Tu as souvent une install windows, une osX, une linux et une multiplate forme dans les téléchargements

[lex13]

Tout simplement car la différence n'est pas dans l'IHM mais dans les protocoles de communication avec l'OS.

Et en français ça donne koi ? J'ai rien compris désolé

azureus, c'est effectivement parce que c'est pas du swing, mais du swt

sinon, c'est surtout pour fournir un instaleur. Tu as souvent une install windows, une osX, une linux et une multiplate forme dans les téléchargements

je ne savais pas que swt dépendait de l'OS ! J'ai donc bien fais de partir sur swing !


Sinon c'est vrai j'avais pas pensé a l'installateur !


-------

ok Donc en gros, si je fais mon appli avec swing je n'aurais pas de problème de portabilité, je n'aurais rien a changer...
sanchant que mon appli gère une base de donnée de divx et va chercher les infos des films sur internet...

[adiGuba]

ok Donc en gros, si je fais mon appli avec swing je n'aurais pas de problème de portabilité, je n'aurais rien a changer...

Disons que les problèmes ne viendrons pas de Swing en tout cas !


Ensuite tu dois quand même respecter certaines règles :

• Par exemple pour les chemins de fichier, tu ne dois pas utiliser '\' ou '/', mais File.separator (a noter toutefois que si le chemin n'est pas destiné à être affiché à l'utilisateur, tu peux utiliser '/' qui fonctionnera aussi bien sous Windows que sous les Unix).
• De même tu ne dois pas te baser sur des spécificités d'un système (appel de programme externe, etc.).
• Enfin, si tu utilises des librairies natives, tu devras gérer les différentes versions selon les systèmes cibles (et peut-être restreindre la compatibilité si ces librairies ne sont pas porté sur un système).

Mais concrètement pour une interface graphique Swing et du réseaux, il y a tout ce qu'il faut en standard !

Par contre, le point qui pourrait te gêner c'est l'intégration au système : certaine fonctionnalité basique du système ne sont pas forcément disponible (quoique Java 6 a apporté quelques améliorations de ce coté là).

a++

[sironimo]

Et en français ça donne koi ? J'ai rien compris désolé

que je me suis vautré vu que Azureus est développé en SWT pourtant je le savais...

Sinon je pensais entre autre chose en parlant de communication à l'installation.

[lex13]

[*]Par exemple pour les chemins de fichier, tu ne dois pas utiliser '\' ou '/', mais File.separator (a noter toutefois que si le chemin n'est pas destiné à être affiché à l'utilisateur, tu peux utiliser '/' qui fonctionnera aussi bien sous Windows que sous les Unix).

Ok merci pour l'astuce, c'est noté !

[*]De même tu ne dois pas te baser sur des spécificités d'un système (appel de programme externe, etc.).

Justement si, dans l'appli, il y a une option pour lancer le film ou pour lancer la page du film d'allocine sur les applis par défaut correspondantes

[*]Enfin, si tu utilises des librairies natives, tu devras gérer les différentes versions selon les systèmes cibles (et peut-être restreindre la compatibilité si ces librairies ne sont pas porté sur un système).
[...]

Ca j'ai pas trop compris, mais je pense que je vais voir ça petit à petit

Par contre, le point qui pourrait te gêner c'est l'intégration au système : certaine fonctionnalité basique du système ne sont pas forcément disponible (quoique Java 6 a apporté quelques améliorations de ce coté là).

Ouep, j'espère juste qu'il y a les fonctions natives qui me sont nécessaires ! (Comme la gestion d'une base de donnée)

D'ailleur vous savez quel type de base de donnée il faut que j'utilise pour que ce soit compatible avec linux et windows ?

[adiGuba]

Justement si, dans l'appli, il y a une option pour lancer le film ou pour lancer pour lancer la page du film d'allocine...

Hé hé hé ! C'est là qu'on rigole !

Le mieux serait de demander à l'utilisateur de spécifier le chemin des programmes pour lire les vidéos et pour le navigateur (et de sauvegarder ce chemin pour éviter de lui demander à chaque fois).

A noter que Java SE 6 propose "en partie" ces fonctionnalités :

• La méthode Desktop.open() permet d'ouvrir un fichier avec le programme auquel il est associé.
• La méthode Desktop.browse() permet quand à elle d'afficher une page sur le navigateur par défaut.

J'ai dit "en partie" car en fait cela n'est pas disponible sur tout les systèmes (car très dépendant du système lui-même), et qu'il faut vérifier si c'est supporté avec les méthode Desktop.isDesktopSupported() et Desktop.isSupported(Action)...

donc dans le cas où cela ne serait pas supporté il faudra une solution alternative (demander & sauvegarder le nom du programme par exemple).


Si tu n'utilises pas Java 6 tu as toujours la possibilité d'utiliser la librairie native JDIC qui propose les mêmes possibilités (mais qui n'est portable que sous Windows/Linux/Solaris).

Ca j'ai pas trop compris, mais je pense que je vais voir ça petit à petit

Les librairies "natives" comporte deux éléments : une librairie Java normale et une librairie en code natif (généralement C/C++) qui est donc différentes d'une système à l'autre.

Donc si tu utilises une librairie native (comme JDIC) tu devras "changer" la librairie en code natif selon le système cible...


Soit tu fais plusieurs installateurs par système, soit tu utilises Java Web Start qui permet de faire cela assez facilement...

Ouep, j'espère juste qu'il y a les fonctions natives qui me sont nécessaires ! (Comme la gestion d'une base de donnée)

JDBC est standard et te permet de manipuler n'importe quel BD...

D'ailleur vous savez quel type de base de donnée il faut que j'utilise pour que ce soit compatible avec linux et windows ?

N'importe laquelle ! Il faut juste que tu utiliser le drivers JDBC correspondant (voir la FAQ JDBC).

Tu as ensuite le choix entre une BD "normale" qui devra donc être installé en plus de ton programme, ou alors une BD embarqué en Java (comme derby ou hsqldb).

a++

[lex13]

Hé hé hé ! C'est là qu'on rigole !

Le mieux serait de demander à l'utilisateur de spécifier le chemin des programmes pour lire les vidéos et pour le navigateur (et de sauvegarder ce chemin pour éviter de lui demander à chaque fois).

A noter que Java SE 6 propose "en partie" ces fonctionnalités :

• La méthode Desktop.open() permet d'ouvrir un fichier avec le programme auquel il est associé.
• La méthode Desktop.browse() permet quand à elle d'afficher une page sur le navigateur par défaut.

J'ai dit "en partie" car en fait cela n'est pas disponible sur tout les systèmes (car très dépendant du système lui-même), et qu'il faut vérifier si c'est supporté avec les méthode Desktop.isDesktopSupported() et Desktop.isSupported(Action)...

donc dans le cas où cela ne serait pas supporté il faudra une solution alternative (demander & sauvegarder le nom du programme par exemple).


Si tu n'utilises pas Java 6 tu as toujours la possibilité d'utiliser la librairie native JDIC qui propose les mêmes possibilités (mais qui n'est portable que sous Windows/Linux/Solaris).

Je pense que je vais opter pour la dernière solution ! Windows et linux suffisent ! De toutes façon j'ai l'impression que JDIC est une bonne solution !

Les librairies "natives" comporte deux éléments : une librairie Java normale et une librairie en code natif (généralement C/C++) qui est donc différentes d'une système à l'autre.

Donc si tu utilises une librairie native (comme JDIC) tu devras "changer" la librairie en code natif selon le système cible...

Soit tu fais plusieurs installateurs par système, soit tu utilises Java Web Start qui permet de faire cela assez facilement...

Ok la j'ai compris ! Tant que le code source ne doit pas être différent et qu'il suffit de changer juste les librairies natives dans les installateurs, ça me convient !

JDBC est standard et te permet de manipuler n'importe quel BD...
N'importe laquelle ! Il faut juste que tu utiliser le drivers JDBC correspondant (voir la FAQ JDBC).
Tu as ensuite le choix entre une BD "normale" qui devra donc être installé en plus de ton programme, ou alors une BD embarqué en Java (comme derby ou hsqldb).

Ba ma fois si "derby" ou "hsqldb" sont des bons types de base de données ça conviendra !
Edit : j'ai un petit penchant pour hsqldb !

OUF et bien merci pour toutes ces informations ! je crois que j'ais assimilé assez de nouveauté aujourd'hui merci a tous et a toi adGuda !