Discussion :

[Lharuun]

Bonjour,

Je suis entrain de développer une Application pour android 3.2.1
Et soudainement je me retrouve face a une petit soucis.
Après quelques recherche qui ne m'ont pas vraiment apportées la
réponse que j’attendais, je fait donc appel a vous.
J'aimerai quelques explication concernant le code suivant :

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
25
 
		try {
			String URL = "http://127.0.0.1";
 
			HttpClient httpclient = new DefaultHttpClient();
			HttpPost httppost = new HttpPost(URL);
 
			List<NameValuePair> nameValuePairs = new ArrayList<NameValuePair>(2);
			Set keys = Parametres.keySet();
			for (Iterator i = keys.iterator(); i.hasNext();) {
				String key = (String) i.next();
				String value = (String) Parametres.get(key);
				nameValuePairs.add(new BasicNameValuePair(key, value));
			}
			httppost.setEntity(new UrlEncodedFormEntity(nameValuePairs));
			HttpResponse response = httpclient.execute(httppost);
 
 
		} catch (Exception ex) {
			if (ex == null){
				Log.e("Exception","l'object est null");
				return false;
			}
			Log.e("Exception", ex.getMessage());
		}

Pour information l'exception est lancé sur

Code :

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

HttpResponse response = httpclient.execute(httppost);

Je ne comprenais pas pourquoi lorsque j’exécutais mon programme j'avais une stacktrace d'affichée dans les logs plutôt qu'une ligne avec Exeption et le message associé.

Il s'est avéré que le test (ex == null) ajouté dans le traitement de l'exception
était vrai....provoquant forcément une exception NullPointerException dans le traitement même de exception....

Quelqu'un est il au courant de ce phénomène et surtout peut il m'en donner la cause ? Par ce que je ne me sens pas vraiment de devoir tester dans chacune de mes exceptions si l'objet passé est valide ou non.

Je continu mes recherches

Merci d'avance.

Cordialement.

[Lharuun]

Apparement un premier element de réponse....

One possible cause is that you are trying to make a network connection on your main thread, which works fine pre-2.3.3/Honeycomb (SDK level < 10 for example) but will be thrown as an

android.os.NetworkOnMainThreadException

since SDK level 10.

Check this: http://developer.android.com/referen...Exception.html

The problem is that Eclipse doesn't really know about this exception (since it is conditionally thrown based on different SDK level so Eclipse probably can't get a correct instance of this exception, that explains why your exception object is always NULL)

Solution: create a separate

[Lharuun]

Et finalement la réponse est trouvée quelque minutes apèrs avoir posté.

Code :

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

1
2
3
4
 
StrictMode.ThreadPolicy policy = new StrictMode.ThreadPolicy.Builder()
				.permitAll().build();
		StrictMode.setThreadPolicy(policy);

[Simon MARQUIS]

Depuis les dernières versions d'Android, il est INTERDIT de lancer des requêtes HTTP depuis le thread principal (UI Thread).
Il te faut donc lancer cette requête dans un Background Thread

[nicroman]

Mais franchement... il est INTERDIT depuis le début des smartphone et Android 1.0 de faire des traitement long (comme des accès réseaux) depuis le thread principal....
Pour éviter les applications mal programmée, google a rajouté une vérification dans son code a partir de Android 3.0, le NetworkOnMainThread excpetion...

L'astuce du StrictMode consiste à dire: "Je programme salement et je m'en fiche, fait tourner mon programme quand même"...



Bon... sinon, concernant le probleme principal:

On peut avoir le code de la classe "Parametres" ? On dirait qu'il y a un grand nombre d'accès statiques...

Par définition on ne peut recevoir "null" dans un catch... surtout un catch (Exception ex)... puisque Java va vérifier que l'objet implémente "Exception" avant de rentrer dedans... si il hérite de Exception, c'est qu'il n'est pas null... il doit y avoir un autre probleme...

La syntaxe d'appel de "Log" n'est pas bonne... c'est: Log.e(TAG,MESSAGE,EXCEPTION)
donc:
Log.e("MonTagAMoi","Erreur de processing http",ex);
(et surtout pas de ex.getMessage())

Et pour finir, une petite remarque concernant le code... En Java 1.5+ ceci:

Code :

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

1
2
3
4
5
6
7
 
Set keys = Parametres.keySet();
			for (Iterator i = keys.iterator(); i.hasNext();) {
				String key = (String) i.next();
				String value = (String) Parametres.get(key);
				nameValuePairs.add(new BasicNameValuePair(key, value));
			}

s'écrit:

Code :

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

1
2
3
4
5
 
for (String key : Parameters.keySet()) {
    String value = (String) Parameters.get(key);
    ...
}

EDIT: En fait, Parametres ressemble à une variable "Map" (si c'est une variable elle ne devrait pas commencer par une majuscule), et dans ce cas:

Code :

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

1
2
3
 
for (Map.Entry<String,String> e : Parameters.entrySet()) 
    nameValuePairs.add(new BasicNameValuePair(e.getKey(), e.getValue()));

[Hizin]

"Tiens, mon système me donne une erreur ? Pas grave, on la passe sous le tapis !"

Mais bordel, les erreurs sont pas là pour faire chier le développeur, mais là pour l'aider.

Les choses qui ne vont pas :
Le catch (Exception ex) : ne catch que les exceptions que tu dois traiter, pas toutes (ou utilises un système de log robuste pour ça). C'est à cause de ça que tu as ta NPE, car ton catch est trop vaste, il prend aussi le NetworkOnMainThreadException, alors qu'il ne devrait pas. Cette exception, si elle arrive, ne doit arriver que lors du développement, jamais à un autre moment.

Tu fais un traitement long bloquant sur le thread principal, le thread graphique. Tu freezes ainsi toute ton application, sans retour utilisateur. Avec des temps pouvant aller de 2 à 30 secondes de freeze, tu peux être sûr que ton application sera désinstallée de suite.

Hors ça, c'est une mauvaise pratique que Google demande d'éviter depuis le début. Vu que les développeurs s'en foutent, Google a créé cette erreur : NetworkOnMainThreadException, qui oblige les développeurs à paralléliser le traitement dans une tâche asynchrone.

Par respect pour tes utilisateurs, et si tu veux que ton application ne bloque pas, oubli totalement le bout de code que tu as donné, et intéresse-toi plutôt au Thread ou à AsyncTask pour faire de ton appel réseau une tâche asynchrone.

EDIT : et paf, grillé

[Lharuun]

Depuis les dernières versions d'Android, il est INTERDIT de lancer des requêtes HTTP depuis le thread principal (UI Thread).
Il te faut donc lancer cette requête dans un Background Thread

Je sais que ca fait un peu long à la détente comme réponse. Mais
juste pour information ces traitements ne sont pas lancés depuis le Thread Principale mais a partir de public class ServiceSynchro extends Service

Et si je ne me trompe pas cette Classe sert bien a traiter en arrière plan.
Après il est vrai que je pourrais lancer un Thread par requête Mais normalement le Service ne doit rien bloquer de l'UI ? Non ?

Effectivement concernant les Exceptions j’avoue j'ai tendance à ratisser large surtout en début de projet.
Ca n'excuse en rien mes mauvaises pratiques, mais ce code était issue de mon premier projet Android, donc utilisation de Java+API Android depuis 2 jours sachant qu'à la base je développe en C++ et C# pour Windows Mobile/CE avec Visual studio 2008 dont la philosophie et les API ne sont pas exactement identiques....

Merci encore pour vos informations.

[nicroman]

Un "Service" a les mêmes restrictions qu'une activité... mais sans "interface"
Le sevice doit donc répondre aux "Intent" (et aux demandes de start) avec la même dilligence.