Discussion :

[loupapet]

Bonjour à tous,

Après plus d'une semaine de recherche sur votre site comme sur d'autres, je me résous à poster un sujet sur votre forum. Si toutefois, le sujet a déjà été traité, je vous prie de bien vouloir m'excuser de ne pas l'avoir trouvé et me signaler, si c'est possible, où je peux le trouver. D'avance merci.

Pour récupérer un parcours de compétition avec la puce GPS d'un smartphone, j'ai écrit une petite application sous Android avec son ADT pour me familiariser à la programmation Java sous ce système. Elle n'est pas très originale car j'en ai rencontrées pas mal sur la toile.

Description sommaire : lors d'un parcours, en voiture, à pieds, en planeur, etc.., l'application capture les points de géolocalisation et les envoie par tronçon de trajectoire dans des courriels successifs vers un concentrateur qui les réceptionne et reconstitue le cheminement, ceci pour avoir une trace presqu'en temps réel. Pourquoi des courriels ? tout simplement pour que l'application du smartphone soit complètement déconnectée de l'application de concentrateur, un simple PC, toutes deux fonctionnant de manière asynchrone entre elles.

Avec l'AVD d'Android, l'application fonctionne comme je le souhaitais à une seule chose près : lors des envois des courriels, la technique de programmation que j'ai adoptée à la suite de ce que j'ai lu et vu dans les tutos provoque l'affichage de panneaux sur l'écran au travers desquels ils doivent être envoyés manuellement alors que je voudrais la procédure complètement transparente et automatique. J'aimerais bien pouvoir tester mon application avec un smartphone Android que je compte acquérir à la fin de mon engagement en décembre.

Qu'y a-t-il donc d’erroné dans le code que je vous présente ci-dessous :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
/***********************************************************************************************
 
                  Méthode locale : envoi du tronçon de trajectoire par courriel
          
***********************************************************************************************/
public void envoiTroncon()
{
  Intent emailIntent = new Intent ( android.content.Intent.ACTION_SEND) ;
 
  String[] recipients = new String[]{courriel,""} ;
 
  emailIntent.putExtra( android.content.Intent.EXTRA_EMAIL
                      , recipients) ;
  emailIntent.putExtra( android.content.Intent.EXTRA_SUBJECT
                      , "Poursuite GPS : " + String.valueOf(nbCourriels)) ;
  emailIntent.putExtra( android.content.Intent.EXTRA_TEXT
                      , corpsMess) ;
  emailIntent.setType("text/plain") ;
  startActivity(Intent.createChooser( emailIntent
                                    , "Envoi du courriel " + String.valueOf(nbCourriels)
                                    )
               ) ;
}

où :

• courriel est l'adresse électronique du concentrateur spécifié au début du lancement de l'application
• nbCourriels est le nombre de courriels envoyés
• corpsMess contient les points de géolocalisation du tronçon courant de trajectoire.

Les envois s'effectuent avec les deux type "text/plain" et "message/rfc822".

N'y aurait-il pas une autre manière d'écrire l'instruction "startActivity" qui provoque cet état de fait ?

En espérant votre éclairage, merci d'avance.

Bien cordialement.

[Hephaistos007]

Par définition, ton code demande à démarrer une activity (un écran) donc c'est normal. Pour gérer l'envoi d'un email en arrière-plan il faut le coder dans l'idée d'un appel de service. Typiquement, accéder à un serveur de courrier sortant (SMTP) pour déclencher l'envoi. C'est ce que font les clients mails justement.
Je pense que l'API JavaMail peut t'aider à atteindre cet objectif plus facilement.

[loupapet]

Bonsoir Hephaistos007,

Tout d'abord, pardon de ne pas vous avoir répondu plus tôt pour vous remercier. Vous êtes le seul à l'avoir fait jusqu'ici. Mon PC a "fait la cavale" peu de temps après mon intervention. Je m'en suis donc trouvé privé jusqu'à l'achat d'un nouveau qu'il m'a fallu bien entendu reconfigurer pour retrouver ma petite application sous Android/Java ainsi que mes autres rubriques.

Lors de mes recherches sur la Toile, comme vous me l'aviez proposé, j'avais déjà téléchargé les API's JavaMail que j'avais insérés dans mon projet sous Eclipse. Je n'avais jamais réussi à le faire fonctionner. C'est pourquoi je m'étais rabattu sur l'exemple que j'avais joint. Ce dernier fonctionnait correctement à l'affichage des panneaux près. Avec les API's JavaMail, je m'étais appuyé sur l'exemple de la page "https://javamail.java.net/nonav/docs/api/" avec le source ci-dessous :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
    Properties props = new Properties();
    props.put("mail.smtp.host", "my-mail-server");
    Session session = Session.getInstance(props, null);
 
    try {
        MimeMessage msg = new MimeMessage(session);
        msg.setFrom("me@example.com");
        msg.setRecipients(Message.RecipientType.TO,
                          "you@example.com");
        msg.setSubject("JavaMail hello world example");
        msg.setSentDate(new Date());
        msg.setText("Hello, world!\n");
        Transport.send(msg, "me@example.com", "my-password");
    } catch (MessagingException mex) {
        System.out.println("send failed, exception: " + mex);
    }

J'avais bien recherché, comme je le fais aujourd'hui, dans la description des différentes méthodes. J'ai quelques difficultés à donner les bonnes informations sur certaines, pas très aidé par mon manque d'expérience en Java :

• "mail.smtp.host" : je suppose que c'est imposé,
• "my-mail-server" : l'adresse courriel destinatrice (?)
• "me@example.com" : (FROM), l'adresse courriel du compte ouvert sur l'émulateur ADV,
• "you@example.com" : (TO), l'adresse courriel destinatrice (?), la même que ci-dessus (?).

Pour (SUBJECT) et (TEXT) pas de problème. J'aurais bien aimé trouver la méthode pour ajouter un document joint plus facile à traiter après extraction.
Je suppose que "me@example.com" et "my-password" ne sont pas utiles comme j'ai pu le voir dans un autre exemple similaire.

J'imagine qu'il y a peut-être autre chose à initialiser ou à configurer dans l'émulateur du téléphone !...

Je me permets d'exprimer, en aparté, que je suis tout de même assez sidéré de voir la quantité de messages postés sur ce forum comme sur d'autres dans lesquels rejaillit le désarroi de beaucoup d'intervenants tout comme la quantité de tutoriels des mêmes sujets distillant des informations assez parcellaires conduisant la plupart du temps à des exemples qu'on a du mal à faire marcher. Je suis probablement d'une vielle école puisque j'ai 73 ans mais j'ai toujours pensé qu'un bon système est réalisé par des développeurs, en nombre restreint, n'hésitant pas à déployer une très grande énergie pour simplifier, faciliter et réduire la programmation de milliers d'utilisateurs pour qui le système n'est pas du tout une préoccupation pour leur productivité. Cela ne semble pas être le cas aujourd'hui !...

Pour illustrer mon propos, j'ai été durant mon activité l'instigateur et le développeur d'une librairie graphique pour les ingénieurs du Bureau d’Études et de la Documentation Technique de ma société dans laquelle une quinzaine de primitives de base suffisaient pour remplir 80% de leurs besoins dans 80% des cas.

J'espère que vous pourrez peut-être me mettre sur une voie pour mon petit problème ? d'avance merci.

Bien cordialement.

_______________________
Pourquoi fait simple quand on peut faire encore plus simple !...
Le plus simple est de ne pas faire.... seulement si c'est possible !...

[nicroman]

Bonsoir Hephaistos007,

Et les autres non ?

Avec les API's JavaMail, je m'étais appuyé sur l'exemple de la page "https://javamail.java.net/nonav/docs/api/" avec le source ci-dessous :
...
J'avais bien recherché, comme je le fais aujourd'hui, dans la description des différentes méthodes. J'ai quelques difficultés à donner les bonnes informations sur certaines, pas très aidé par mon manque d'expérience en Java

J'ai peur que cela n'ai hélas aucun rapport avec Java... mais avec le protocole d'envoi des mails (assez vieux hélas), à savoir SMTP.
Pour envoyer un mail (j'entends par mail tout un contenu avec ses "headers" tels que le sujet, le from, le to, etc...) il faut avant tout un serveur SMTP. C'est ce serveur qui doit être défini dans "mail.smtp.host". Mais attention ! Il est (en général) interdit d'envoyer un mail à "toto.net" en passant par un serveur "titi.com". A moins de faire une (couteuse) requête DNS et récupérer l'adresse des serveurs de "toto.net", il faut passer par un serveur dit "relais". Hors aucun serveur n'accepte de faire de relais (pour éviter l'utilisation par des "spammers") *sauf* pour ses propres utilisateurs. Il faut donc en général un nom d'utilisateur et un mot de passe pour se connecter à ce serveur (ce sont les paramètres de la couche transport).
Certains providers (par exemple free), ne demandent pas de mot de passe mais obligent l'utilisateur à être sur une adresse IP appartenant à "free". Ce qui est bien entendu impossible en 3G sur smartphone (troll inside).

Une fois la connexion au serveur établie (voir ci-dessus), il faut aussi indiquer au serveur le MAIL-FROM (envoyeur) et le RCPT-TO (destinataire) du mail. Il se peut que le FROM doivent être identique au login utilisé pour la connexion.
Pour le "TO" c'est bien entendue l'adresse de destination.


Ensuite il faut plusieurs conditions:
1. Que l'application déclare bien utiliser "internet".
2. Que tout le code d'envoi/connexion soit bien utilisé dans une AsyncTask (de toute manière c'est nécessaire pour des question de relation avec l'utilisateur ).

J'imagine qu'il y a peut-être autre chose à initialiser ou à configurer dans l'émulateur du téléphone !...

Non du tout.

Je me permets d'exprimer, en aparté, que je suis tout de même assez sidéré de voir la quantité de messages postés sur ce forum comme sur d'autres dans lesquels rejaillit le désarroi de beaucoup d'intervenants tout comme la quantité de tutoriels des mêmes sujets distillant des informations assez parcellaires conduisant la plupart du temps à des exemples qu'on a du mal à faire marcher.

Pour le coup, developpez.net est probablement une des rares source "fiable" pour les développeurs francophones. Et si un tutoriel ne "marche pas", il faut immédiatement le rapporter dans la discussion attachée à ce tutoriel. L'aureur pourra alors modifier celui-ci (souvent une question de "nouvelle APIs", comme google maps v2), ou le cas échéant expliquer plus en détails.

Je suis probablement d'une vielle école puisque j'ai 73 ans mais j'ai toujours pensé qu'un bon système est réalisé par des développeurs,

C'est toujours le cas.

en nombre restreint

Ce n'est plus possible (et fort heureusement)... quand j'ai commencé l'informatique sur ZX81 on avait 1Ko de RAM... 1024 octets ! Même un développeur ne pouvait tout remplir, et le code d'un programme tenait sur une page manuscrite.
Aujourd'hui un programme fait souvent le café avec un petit massage pendant que l'utilisateur regarde une vidéo Ce qui est nettement plus gratifiant pour lui, mais représente aussi, au bas mot, 10000 lignes de code... (et je parle d'un petit programme). Le code d'un SAAS moyen peut très vite augmenter en taille.

n'hésitant pas à déployer une très grande énergie pour simplifier, faciliter et réduire la programmation de milliers d'utilisateurs pour qui le système n'est pas du tout une préoccupation pour leur productivité. Cela ne semble pas être le cas aujourd'hui !...

C'est pourtant toujours le cas... Sauf qu'on est passé du mode:
"Programmeur Debutant" fait un service pour "Ingénieurs" (années 80)
à
"Programmeurs Avancés" font un service pour "Passionnés" (années 90)
à
"Programmeurs Chevronnés font un service pour "Utilisateurs" (années 2000)
Et quand je dis utilisateur je parle bien des gens derrière l'écran.

Le plus simple est de ne pas faire.... seulement si c'est possible !...

On ne leur avait jamais dit que c'était impossible... Alors ils l'ont fait!

[loupapet]

Bonjour Nicroman,

Je vous remercie pour votre réponse intéressante.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Et les autres non ?

Ben, je veux bien, mais Hephaistos007 a été le seul à m'avoir répondu..... avec vous maintenant !...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mais avec le protocole d'envoi des mails (assez vieux hélas), à savoir SMTP.

Oui, le protocole SMTP est vieux puisqu'il faisait déjà partie intégrante des applications-réseau quand je travaillais de 1985 à 1988 dans l'équipe-système de ma boîte à installer le réseau-usine. Il n'y avait pas internet et les e-mail à l'époque même si le concept existait déjà depuis le début des années 70 et utilisé aux US.

Mais y a-t-il quelque chose de plus moderne aujourd'hui ?

Je comprends votre excitation à me décrire ce qu'il faut faire pour envoyer automatiquement un courriel, excitation qui était la mienne à l'époque pour comprendre ce qu'il se cachait derrière certains outils. Aujourd'hui à la retraite, je ne suis plus un homme-système et suis plus intéressé par un outil générique qui me causerait le moins de souci possible pour atteindre mon objectif.

Vous me parlez d'une AsyncTask. J'ai regardé ce qu'elle faisait. Je n'ai pas trouvé son usage dans les exemples que j'ai vus à moins qu'elle fasse partie des "prerequisites" ? Pourtant, vous me dites qu'il n'y a rien à configurer dans le téléphone !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

.... Et si un tutoriel ne "marche pas", il faut immédiatement le rapporter dans la discussion attachée à ce tutoriel.

Je ne me serais pas permis d’affirmer qu'un tutoriel ne marche pas. J'ai tout simplement dit que j'avais du mal à les faire marcher ce qui n'est pas du tout pareil. C'est moi qui me mets personnellement en cause.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

.... Ce n'est plus possible (et fort heureusement)...

Les développeurs ne sont nombreux que dans les boîtes de développement de système puisque la finalité est justement de produire du système. Mais ils restent très peu nombreux par rapport à tous les utilisateurs de la planète qui utilisent leurs produits.
Dans une usine de production, c'est la même chose.

De mon point de vue, je dirais plutôt "malheureusement" car j'ai bien l'impression que les développeurs-système de ces boîtes à logiciels se cantonnent dans leurs tours d'ivoire sans se préoccuper de la productivité des utilisateurs.
Regardez le nombre de fois qu'une même fonction générique est écrite par des milliers d'utilisateurs alors qu'elle aurait pu être mise à disposition en standard. Cela n'empêcherait nullement les hommes-système lambda de regarder ce qu'il se passe derrière son appel. J'aurais bien vu une fonction... pardon une méthode du type :

sendMail (context, mail_FROM, mail_TO, sujet, corps, liste_doc_joints) ; (un peu à l'image de PHP)

J'aurais déjà résolu mon problème qui, pour moi, est plus intéressant que tout ce "charabia" qui faut écrire. Mais, peut-être, y a-t-il des préoccupations commerciales derrière cet état de fait ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

On ne leur avait jamais dit que c'était impossible... Alors ils l'ont fait!

Votre remarque est très significative de la société actuelle où l'on se préoccupe guère de ce qui est utile ou non. Je prendrais un exemple tout simple qui touche absolument tout le monde : l'automobile. Le faite de proposer une voiture suréquipée est une véritable arnaque puisque, comme vous dites, "On ne leur avait jamais dit que c'était impossible" ... (sous entendu de proposer). Alors il propose en standard un tas de choses inutiles que vous ne demandez pas, même que vous ne voulez pas, mais que vous payez bien entendu puis que le prix de base de la voiture a été insidieusement majoré pour cela.... Même chose pour les garanties x années pour lesquelles on vous fait payer le max au départ. Certes, au final, vous n'êtes pas obligé d'acheter n'est-ce pas ?...

Tout cela, c'est de la philosophie. Je fais tout de même avec et je finirai bien par faire marcher mon appli !...

Bien cordialement.

[nicroman]

sendMail (context, mail_FROM, mail_TO, sujet, corps, liste_doc_joints) ; (un peu à l'image de PHP)

Sauf que la fonction en question a besoin de plus de paramètres: serveur devant traiter le mail, identification sur serveur, éventuellement proxy pour accéder à ce serveur.... si ESMTP doit être utilisé ou non... quel charset utiliser (bien que SMTP soit ASCII par défaut, de nombreux serveurs acceptent d'autre charset), etc...

Là on est en programmation orientée objet... et une fonction qui prend 20 paramètres a de fortes chances d'être mal écrite... La fonction prend donc seulement un unique paramètre: le message.

Fort heureusement, il y a de grandes chances pour que les autres paramètres ne changent que rarement. C'est ainsi qu'on peut les définir une fois pour toutes dans les propriétés de la session (qui peut être conservée en mémoire). Ceci est fait par l'objet "Properties" (avec en particulier les propriétés "mail.user" et "mail.password", et "mail.host" bien sur).

Mieux encore: ces "properties" peuvent être définies dans un fichier texte (et ainsi être modifiées sans toucher "au code").

Encore mieux: la session peut être conservée au niveau JNDI (mais pour le coup pas très intéressant concernant Android) et ainsi donc définie au niveau de l'environnement (et non du programme).


Si les propriétés sont définies correctement c'est simplement:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
// le code ci-dessous peut être fait dans un singleton pour éviter de refaire 20x le rechargement des propriétés
Properties props = new Properties();
props.load(... un input-stream sur une ressource par exemple...)
Session  session = Session.getInstance(props,null);
try {
        MimeMessage msg = new MimeMessage(session);
        msg.setFrom("me@example.com"); // il faut bien un "from"
        msg.setRecipients(Message.RecipientType.TO,  "you@example.com"); // il faut au moins un "to"
        msg.setSubject("JavaMail hello world example"); // le sujet
        msg.setSentDate(new Date()); // la date ... mais il me semble que javamail le fait tout seul
        msg.setText("Hello, world!\n"); // le contenu
        Transport.send(session,msg); // l'envoi
    } catch (Exception mex) {
        Log.e(TAG,"Failed to send e-mail",mex);
    }

Pourquoi ne pas avoir une fonction "send" toute faite avec juste les paramètres nécessaires ? parce que chacun a ses propres besoins... Moi je n'utilise pas MimeMessage mais une classe fille de MimeMessage (qui implémente par exemple une traduction automatique html/plain-text).
Certains n'utiliseront pas SMTPTransport mais autre chose... enfin bref, ces APIs sont faites pour être souples.

Mais, peut-être, y a-t-il des préoccupations commerciales derrière cet état de fait ?

Non juste une préoccupation de souplesse et de ré-utilisabilité du code.

Votre remarque est très significative de la société actuelle où l'on se préoccupe guère de ce qui est utile ou non.

Quel rapport avec le fait que ce soit utile ou non ? Je ne suis pas très bien.
Il y a des choses utiles à beaucoup de gens, des choses utiles à une seule personne.
Ma remarque était juste pour marquer le fait qu'on ne fait pas quelque chose de "simple" parce que c'est plus facile, et en informatique, rien n'est impossible, tout est à inventer.

[loupapet]

Bonjour Nicroman,

Encore merci de me consacrer un peu de votre temps. Pardon si mon post est un peu long.

Je vous montre une capture de la fenêtre d'Eclipse/Android au moment de l'erreur. Je n'ai jamais pu dépasser le stade de l'appel de la méthode "getInstance" (ligne 313).

Je me suis appuyé sur la page "http://www.chicoree.fr/w/Envoyer_un_mail_avec_JavaMail" qui m'est apparue assez complète. Le programme tourne sous Linux mais je pense que cela n'a pas d'importance.

Dans la LogCat, la classe "javax.mail.Session" mentionnée dans le message d'erreur existe bien dans le package "javax.mail.jar" que j'ai téléchargé. Pas d'erreur à la compile. J'ai alors pensé à un mauvais paramétrage de l'AVD et j'ai essayé sans succès plusieurs données dans l'instruction "prop.put(...)" (ligne 312).

Si je passe ce cap, très probablement, cela voudra dire que la configuration du compte émetteur dans le téléphone est correcte.

Mon PC est connecté à travers un modem ADSL vers le fournisseur SFR.

Voici donc ce que j'ai déclaré dans l'AVD, en reprenant "Paramètres->Comptes et synchro" :

Paramètres généraux du compte émetteur dans le téléphone : "loupapetjpr@free.fr" . Là je me retrouve avec deux comptes "loupapetjpr@free.fr" ce qui est surprenant et je n'ai pas trouvé la procédure pour en supprimer au moins un :

• le premier :
  -> nom "Lou_Papet",
  -> compte par défaut d'envoi des e-mails ==> OUI,
  -> paramètres d'envoi :
  
  • serveur smtp : "smtp.free.fr" (j'ai essayé avec "smtp.sfr.fr" mon fournisseur d'accès, même erreur),
  • port 587 puisque je n'ai aucun type de sécurité. J'ai essayé 'SSL/TLS", le port passe à 465, sans succès,
  • connexion obligatoire ==> NON. J'ai essayé OUI, il refuse pour incompatibilité,
• le deuxième :
  -> nom "Lou_Papet",
  -> compte par défaut d'envoi des e-mails ==> NON,
  -> paramètres d'envoi :
  
  • serveur smtp : "smtp.sfr.fr" (j'ai essayé avec "smtp.free.fr", sans succès),
  • port 465, 'SSL/TLS", sans succès,
  • connexion obligatoire ==> OUI.
    ->nom d'utilisateur "jeanpierre.rousset@sfr.fr"
    ->mot de passe "..."
  
  J'ai permuté le compte par défaut pour les envois d'e-mail : sans succès.
  Tous les paramètres de port sont confirmés dans la page
  
  
  http://assistance.orange.fr/configur...ils-1222.php#2

Pour les autre paramètres :

• "courriel" (ligne 318) est l'adresse courrielle à destination de la messagerie pour traiter les courriels reçus (mon PC),
• "nbcourriels" (ligne 319) est le rang du courriel envoyé dans le sujet pour reconstituer la trajectoire sans avoir à traiter les heures des points.

À ce niveau, je ne sais plus quoi faire. Malgré les explications, je ne sais toujours pas quoi mettre en arguments l'instruction "prop.put(...)" en concordance avec la configuration de l'AVD.
Je joins, à tout hasard, le source 'java' complet de mon appli en espérant ne pas recevoir d'avertissement comme cela avait été injustement le cas avec l'un de vos collègue hiko-seijuro pour le motif 'Demande à faire son travail' comme si, à 70 ans à l'époque je me remettais à la programmation pour faire faire le travail aux autres !...

"http://jeanpierre.rousset.free.fr/Ae...Poursuite.java"

J'espère avoir néanmoins suffisamment prouvé mon travail antérieur d'apprentissage et de recherche avant de solliciter le forum.

Maintenant, pour le reste de la discussion, je reste convaincu de l'intérêt de proposer en standard une méthode générique d'envoi dans les conditions et le paramétrage de 80% des utilisateurs couvrant 80% de leurs besoins. Ce n'est pas, je pense, parce qu'il y a 20% de gens, probablement beaucoup moins, qui sortent des sentiers battus qu'il faut absolument l'imposer aux 80% des autres.

Je pars donc du principe que si PHP peut le faire, je ne vois pas pourquoi JAVA ne pourrait pas le faire.

Par ailleurs, généralement, si une fonction ou méthode nécessite un grand nombre de paramètres, il y a les structures voire même les tableaux de structures pour cela. Dans le prototype donné en exemple, pour moi l'argument "context" ne peut pas être autre chose qu'une structure comme c'est le cas dans l'instruction "Properties prop = System.getProperties() ;", à moins que, d'une manière cachée, ce soit un pointeur vers une structure de Java !.. Mais ce serait là une sacrée entorse aux positions dogmatiques des développeurs de JAVA qui ont refoulé unilatéralement, au niveau du programmeur, sans s'en priver pour eux-mêmes d'ailleurs, les pointeurs, les allocations dynamique de mémoire et l'odieux, horrible et maléfique "goto" !... qui rendent bien des services. Je ne suis pourtant pas particulièrement un nostalgique des langages que j'ai appris dans les années 60-62, Algol à la faculté de Marseille, dans ma Société Aéronautique à partir de 66 Cobol, Fortran, Pascal, Pl/1, Basic et les assembleurs des différentes machines qui les supportaient.

Vous avez mentionné que vous aviez travaillé sur un ZW81 de Sinclair dans les années 80. Je le connais très bien. J'ai commencé aussi par lui avant d'acheter un Zx Spectrum avec les extensions série RS232 et 2 microdrives et 2 entrées/sorties numériques pour piloter 2 moteurs pas à pas que je garde en relique dans un cocon pour le montrer plus tard à mes petits enfants lycéens.

Quant à la programmation orientée objet, elle fait les gorges chaudes des discutions de salon. Vous savez, quand j'ai débuté en l'informatique au début des années 60 à la faculté, on en parlait déjà. Ce n'est donc pas nouveau et certains voulaient la confronter avec la programmation modulaire, obligatoire dans les machines lentes et exiguës de l'époque. Je n'ai jamais voulu entrer dans ce débat que je trouve assez stérile puisque nous vivons dans un univers orienté objet depuis le Big Bang !... c'est une forme de pensée qui, pour moi, n'a rien à voir avec les langages. Je regrette seulement qu'on s'égosille à parler de programmation orientée objet mais motus sur l'exécution orientée objet. Mais là, le sujet et tellement passionnel qu'on pourra toujours dire que les vieux n'y comprennent rien !... Je ne veux pas m'étendre sur le sujet, mon post est déjà un peu long ("http://jeanpierre.rousset.free.fr/In...tte.html#philo").

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Non juste une préoccupation de souplesse et de ré-utilisabilité du code.

Pensez-vous vraiment que souplesse et ré-utilisabilité des codes est une révolution amenée par JAVA. Bien sûr que non. L'Algol 60, mon tout premier langage de programmation sur ordinateur, développé à l'université de Grenoble bien qu'il ait été initié aux US quelques années plus tôt, proposait en standard toutes ses fonctions comme réutilisables, nous disions à l'époque ré-entrantes, et si vous prenez simplement la peine de le regarder, vous constateriez que c'est du C avec mots-clés en français, ce qui a peut-être causé sa perte. Beaucoup d'autres langages s'en sont d'ailleurs inspiré par la suite.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Quel rapport avec le fait que ce soit utile ou non ? Je ne suis pas très bien.
Il y a des choses utiles à beaucoup de gens, des choses utiles à une seule personne.
Ma remarque était juste pour marquer le fait qu'on ne fait pas quelque chose de "simple" parce que c'est plus facile, et en informatique, rien n'est impossible, tout est à inventer.

Je suis absolument opposé au principe de "pack" dans lequel il y a tout et n'importe quoi, surtout ce qui ne sert pas. Je suis pour le principe de l'option :

Si un composant du pack tombe en panne et qu'il est irrécupérable, c'est tout le pack que l'on jette. Par exemple, je ferai en sorte de ne jamais acheter un téléviseur composé d'un tuner TNT, d'un magnétoscope, d'un lecteur de DVD etc... je préfère de loin, par expérience, avoir chacun des composants séparément. C'est beaucoup plus sûr.
Si un système de navigation sert beaucoup à un chauffeur de taxi, le mien ne m'a même pas servi une dizaine de fois en 7 ans. On me l'a imposé car je voulais une boîte de vitesse automatique que beaucoup ne veulent pas. Donc l'option est primordiale.
Pour faire de l'argent et générer du gaspillage, pauvre planète !... (je ne suis pas écolo !...), on fabrique des bagnoles dont la majorité des équipements sont inutiles. A quoi sert un compte tours aujourd'hui ? C'est peut-être pour cela que les Dacia ont tant de succès et en plus elle sont fiables.

De mon point de vue, le pack n'a été instauré qu'à des fins commerciales basés sur la paresse naturelle du consommateur à analyser ses propres besoins. Un téléphone mobile sert d'abord à téléphoner et à bien téléphoner, ce qui n'est pas toujours le cas. À voir les portables, on se demande si téléphoner n'est pas une fonction secondaire d'arrière plan. Pour réaliser ces fonctions souvent inutiles pour les uns et utiles pour les autres, il faudrait pouvoir les télécharger à la demande comme certaines le sont. Pour justifier ces fonctions souvent inutiles, il faut donc les implanter d'office. Il faut donc une programmation. Plus celle-ci sera laborieuse, plus haut seront les coûts d'écriture et de mise au point, de formation, d'assistance, etc...
Quand on est confronté à un problème complexe, et on n'y peut rien, le génie c'est quand même de pouvoir le résoudre avec une combinaison d'outils simples sinon c'est de la complication c'est à dire de la complexité stérile.

Merci d'en être arrivé là en espérant un éclairage pour contourner le mur devant lequel je me trouve.

Bien cordialement.

[nicroman]

Pardon si mon post est un peu long.

Pfiou... c'est long... effectivement
D'autant que la seule partie intéressante est finalement le NoClassDefFoundError (un simple copier coller du logcat aurait suffit plutôt qu'un screenshot, mais c'est pas grave).
Cette erreur (cf Javadoc associée), indique que la classe n'a pu être trouvée à l'execution... Si la compilation s'est déroulée correctement, cela veut dire que la librairie n'est pas exportée par le projet.

Le programme tourne sous Linux mais je pense que cela n'a pas d'importance.

Effectivement... c'est du java....

Pour le reste, les paramètres de comptes utilisateurs sont réservés en général aux applications de lecture/envoi des mail (gmail, ou autre). Il doit être possible d'en lire les settings (avec les autorisations idoines associées à l'application bien entendu), mais je n'ai aucune idée de comment faire (lire la documentation officielle android à ce sujet peut peut-être aider).

Maintenant, pour le reste de la discussion, je reste convaincu de l'intérêt de proposer en standard une méthode générique d'envoi dans les conditions et le paramétrage de 80% des utilisateurs couvrant 80% de leurs besoins. Ce n'est pas, je pense, parce qu'il y a 20% de gens, probablement beaucoup moins, qui sortent des sentiers battus qu'il faut absolument l'imposer aux 80% des autres.

Ben oui... c'est pour cela que la fonction est simplement

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
MimeMessage msg = .... ;
Transport.send(msg);

Cela convient à 80% des utilisateurs de la librairie.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Je pars donc du principe que si PHP peut le faire, je ne vois pas pourquoi JAVA ne pourrait pas le faire.

[mode troll on]Peut être parce que PHP n'est pas un vrai langage de programmation mais un script avec lequel faire des choses complexes devient rapidement horrible ?[/mode troll off]

Par ailleurs, généralement, si une fonction ou méthode nécessite un grand nombre de paramètres, il y a les structures voire même les tableaux de structures pour cela.

C'est exactement ce qu'est "Properties" une table de propriétés.

à moins que, d'une manière cachée, ce soit un pointeur vers une structure de Java !.. Mais ce serait là une sacrée entorse aux positions dogmatiques des développeurs de JAVA qui ont refoulé unilatéralement, au niveau du programmeur, sans s'en priver pour eux-mêmes d'ailleurs, les pointeurs, les allocations dynamique de mémoire et l'odieux, horrible et maléfique goto !... qui rendent bien des services.

Houlà... il ne faut pas tout mélanger... En java, à part les types de base (char,short,long,int,...) il n'y a que des "références". Oui on ne parle pas de pointeur, mais bien de référence. C'est la même chose, à ceci prêt que le fonctionnement est celui des sharedPtr<> de C++: tant qu'une référence existe sur un objet, celui-ci est conservé en mémoire.
L'allocation dynamique dépend de l'implémentation de la machine virtuelle et n'a (heureusement) rien à voir avec Java.
Quant au "goto" il ne sert effectivement à rien puisqu'on peut démontrer (théorie des langages) qu'il peut *toujours* être remplacé par un test.

Quant à la programmation orientée objet (...) c'est une forme de pensée qui, pour moi, n'a rien à voir avec les langages.

Personne n'a dit le contraire.

Je regrette seulement qu'on s'égosille à parler de programmation orientée objet mais motus sur l'exécution orientée objet.

La seule différence est le langage... On peut faire de l'exécution orientée objet en assembleur, en C, ... Mais de la programmation orientée objets, si le langage ne le permet pas, on ne peut pas

Pensez-vous vraiment que souplesse et ré-utilisabilité des codes est une révolution amenée par JAVA.

Non c'est quelque chose de bien pratique qui vient avec la conception orientée objets (à différencier encore de la programmation elle-même hein ! ).

L'Algol 60, (...), proposait en standard toutes ses fonctions comme réutilisables, nous disions à l'époque ré-entrantes

Réentrante a toujours voulu dire en langage informatique "utilisable simultanément par plusieurs threads en même temps".

c'est du C avec mots-clés en français, ce qui a peut-être causé sa perte.

Dans mes souvenirs cela ressemblait plus à un mix entre fortran et pascal... mais si vous voulez

Concernant les "packs", je ne vais entrer dans la discussion, qui semble stérile et inappropriée. Toujours est-il qu'un ".jar" est un "pack" de comportement qui peut utiliser d'autres "packs" pour fonctionner. Comme votre lecteur DVD utilisera votre télé pour fonctionner...
Oui forcément c'est possible d'acheter un "moteur" platine, un laser, un SOC décodage laser, un SOC décodage DVD, et tout brancher ensemble... si cela peut vous faire plaisir. Mais par soucis de simplicité pour les utilisateurs, les vendeurs ont décidé de tout mettre dans une boite. Une sorte de "pack" donc, ou tous les composants marchent ensemble.
Et en informatique (surtout orientée objets) c'est encore mieux, parceque vous pouvez customiser ce pack !

[loupapet]

Je vais à nouveau rechercher dans Javadoc qui décrit les composants de manière très détaillée sans pouvoir trouver de solution.

Cela fait maintes fois que je cherche avec le critère "java.lang.NoClassDefFoundError: javax.mail.Session". Je ne suis pas le seul à rencontrer ce problème. La proposition : installer "javax.mail.jar", surprenant car cela ne passerait pas à la compile. Or, chez moi c'est fait et intégré dans mon projet par un "Build Path->Add External Archives...."

Je vais continuer à chercher. Merci d'avoir tenté de m'aider.

[nicroman]

Je reprends ce que j'ai dit, avec en gras les éléments importants:

Cette erreur (cf Javadoc associée), indique que la classe n'a pu être trouvée à l'execution... Si la compilation s'est déroulée correctement, cela veut dire que la librairie n'est pas exportée par le projet.

Le build-path correspond à l'importation... En bref dire "pour tel projet, voici les librairies qui seront accessibles à l'execution"... Par exemple le android-sdk, ou le java-sdk seront présent lors de l'execution, ils sont donc dans le build-path, mais pas exportées.

Les "exports" correspondent aux librairies qu'il faudra inclure au final car par disponible par défaut à l'exécution.

[loupapet]

Oh, j'avais très bien compris cela depuis le début puisque cela passait à la compile et pas à l'exécution. Seulement comment faire dans les méandres inextricable d’Éclipse et javadoc (!) pour que le loader charge la librairie. La déclaration devrait être automatique. la finalité est quand même l'exécution, pas la compile. On ne donne pas la clé pour ouvrir une voiture sans donner celle qui la démarre, c'est souvent la même !... drôle de logique quand même.

Quoi mettre et comment écrire dans les champs du "Runnable JAR File Spécification" (si c'est peut-être la voie) après avoir cliqué droit sur "javax.mail.jar"-> export->java-<runnable JAR File->next ?

Assez décevant ce système. Aujourd'hui, 5% pour ne pas dire 2% du temps pour écrire mon appli d'une extrême simplicité et 95% du temps perdu à me battre contre ce java.

Quelle productivité !... d'autant plus, que si je me mets au fait de ce système, dans six mois il faudra que je recommence la galère... Mais bon !...

[nicroman]

Tout comme un serveur java (comme tomcat) utilisera un ".war" (Webapp ARchive) pour déployer une application java, Android utilise un ".apk" (Android PacKage) pour déployer une application java.
Ces deux archives (les deux peuvent être "dézippés" manuellement) contiennent *tout* ce qui est nécessaire pour exécuter le code.

Dans Eclipse, tout comme un projet "Tomcat" (ou J2EE) va à la fin fournir un .war (ou assimilé), un projet "Android" va à la fin fournir un ".apk". C'est le rôle du builder: "Android Package Builder" (visible dans les propriétés du projet dans Eclipse: section "Builders").
C'est Eclipse qui pilote ce builder grâce aux informations contenus dans les propriétés d'export du Build-Path (propriétés du projet dans Eclipse: section "Java Build Path", Tab "Order and Export").

Allons dans ces fameuses préférences "Java Build Path" de votre projet...
Le premier tab "Source" décrit les fichiers sources... ce que Eclipse va devoir compiler. Il y en a 2:
XXXX/src ce sont vos propres sources à vous.
XXXX/gen ce sont les sources automatiquement générés par les outils de l'ADT (éditeur d'interface par exemple), en particulier le fichier R.java !

Le deuxième tab "Projects" indique les dépendances entre projet utilisées par Eclipse. Ce tab contient toutes les librairies QUI NE SONT PAS ANDROID. En effet pour les librairies Android, le compilateur a besoin d'autres informations (notamment pour les identifiants de ressources) et utilise la secion "Android" (et la partie "Library" tout en bas de celle-ci) pour gérer les projets en dépendance.

Le troisième tab "Libraries" indique toutes les librairies dont le projet a besoin pour compiler... Il y en a en général 3:
Android X.Y (le SDK de la version android choisie)
Android Dependencies (les .jar des dépendances Android définies au deuxième tab).
Android Private Libraries (les .jar utilisés par *ce* projet, et situés dans le répertoire "libs" du projet).

Le quatrième tab "Order and Export" définit ce que le APKBuilder va devoir utiliser... on y trouve en général sélectionnés:
Une partie de vos sources (tout ce qui n'est pas compilable)
Une partie des sources générées (tout ce qui n'est pas compilable)
Android Private Libraries (donc tous les .jar des projets android intermédiaire dans Eclipse)
Android Dependencies (grosso modo tous les .jar du projet situés dans libs).
Et en non sélectionné:
Les librairies mentionnées dans le tab "Libraries" directement.
Android X.Y (puisque déjà inclut dans le device probablement).

Donc vérifiez bien que votre javamail.jar est bien situé dans l'un de ces exports....