Discussion :

[Serge Tahé]

Ce fil de discussion est au sujet du cours :

Introduction à la programmation des tablettes Android par l'exemple

Vous pouvez ici laisser des commentaires, signaler des erreurs, des difficultés, échanger des idées. Le lecteur utilisera les améliorations que vous proposez afin d'améliorer sa maîtrise d'Android. N'oubliez pas que le document vise un public de débutants et que donc vos propositions doivent viser ce même public. Bonne lecture. ST.

[nicroman]

Salut !

J'ai parcouru tout le document (si si ! mais juste parcouru )

Voici quelques commentaires (dans l'ordre):

2.2. De mémoire demander à Eclipse d'encoder en UTF-8 est une très mauvaise idée... C'est effectivement un paramètre propre à l'éditeur de fichier, qui ne sera pas transmis à un compilateur java (javac) avec donc de forts risques... Pour les caractères "spéciaux", préférer la notation \u dans les chaines pour encoder les caractères accentués. De toute manière, ceux-ci n'apparaissant (à priori) que dans les chaines de ressource (localisation oblige), cela ne devrait jamais poser de problème, mais qui sait ?

2.3 targetSdkVersion n'est pas équivalent à maxSdkVersion. target indique la version du SDK utilisée pour produire l'application (compiler), indique aussi aux versions plus récentes d'appliquer des règles spécifiques. Ainsi une application compilée pour Android 2.3 ne plantera pas même si elle utilise le réseau dans le thread UI (ce qui est toujours une erreur, mais le système utilisera des règles "2.3" au lieu de règle 3.0+).

3.7 Je n'ai pas trop compris cette partie, c'est la gestion du "back" classique d'android qu'il faut utiliser non ? Parceque sinon, on risque de se retrouver avec une sacrée pile d'activités

9. Haaa c'est mon domaine !

D'abord, l'exemple montré ne saurait être REST.... en effet, par définition de REST, n appels à un GET sur une URL identique avec des paramètres identique doit retourner des données identiques (c'est tout l'interêt de REST).
Dans l'exemple il ne peut donc s'agir d'un GET.
D'autre part, REST ne limite pas à GET/PUT/POST/DELETE, la commande peut être n'importe quoi: RANDOM (par exemple ), LOGIN, ou tout autre commande qui ai un sens pour la ressource.
Quant à renvoyer du XML ou du JSON, pas forcément, un service REST peut très bien renvoyer du HTML, du PDF, du XLS, du CSV... l'étape de représentation dépend uniquement de "Accept-Type" de la requête passée au service REST.

9.1. Spring MVC comme point d'entrée "API" à un client distant, c'est pas un peu lourdingue ? Je veux dire, Spring MVC est de base fait pour proposer des visualisations (views) et appliquer des règles (controller) sur un modèle... dans le cas d'une API on vire en général la partie views, et la partie modèle... reste grosso-modo que le controlleur.... d'ou mon sentiment que MVC n'est pas adapté aux web-services "API".

9.3.6
HAHHAAAAA NON PITIE !

Code :

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

StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder().permitAll().build());

C'est une horreur abjecte ! (on en revient à mon premier point sur le SDK version d'ailleurs).

Il faudrait vraiment marquer en rouge de ne *jamais* utiliser cela !
(c'est pas pour rien que le système le vérifie de manière active depuis Android 3.0). Surtout que le truc asynchrone arrive bien après !

Sauf que... c'est l'inverse...

La génération de (n) nombres aléatoire est une opération potentiellement longue, et donc, doit intervenir de manière asynchrone, donc avant même que ce soit fait par l'appel à un webservice !
Comme une requête en base de données, une lecture de fichiers, ...

Donc j'inverserai les chapitres, en commencant par la génération de nombre asynchrone, puis, en intégrant le webservice.
1. C'est cohérent.
2. Cela évite de voir trainer dans un tutoriel/cours l'ignominie du StrictMode !

[salve34]

Merci à toi Serge pour ce super boulot très didactique.

Merci à toi nicroman pour tes critiques très constructives.

demander à Eclipse d'encoder en UTF-8 est une très mauvaise idée...

çà vaut aussi pour Netbeans ?

REST ne limite pas à GET/PUT/POST/DELETE, la commande peut être n'importe quoi: RANDOM (par exemple ), LOGIN, ou tout autre commande qui ai un sens pour la ressource.

Ah bon , je pensais aussi qu'il n'y avait que "GET/PUT/POST/DELETE" (mais là je pense pas être le seul )

[nicroman]

Ah bon , je pensais aussi qu'il n'y avait que "GET/PUT/POST/DELETE" (mais là je pense pas être le seul )

En fait, ce n'est pas seulement REST hein ! Même HTTP ne limite pas à ces méthodes, est REST est basée sur l'utilisation simple de HTTP.
http://en.wikipedia.org/wiki/Hyperte...equest_methods
Exemple avec WebDAV: http://en.wikipedia.org/wiki/WebDAV

En gros, REST c'est:
un objet: l'url
une fonction: la méthode à appliquer sur cet objet
des paramètres: les paramètres


Ensuite, certaines méthodes (POST/GET/PUT/DELETE) s'accordent bien avec le CRUD (Create/Read/Update/Delete) et donc on préfère les utiliser pour faire du REST (d'autant que le "GET" est sensé être idempotent, et permet une mise en cache des représentations des ressources)

[Serge Tahé]

Bonjour,

J'ai mis à jour le document pour le rendre plus accessible aux débutants :

- j'ai rajouté le mode d'installation de STS pour Android. Avant il fallait chercher ces informations dans un autre document;
- j'ai ajouté un paragraphe sur les erreurs de configuration les plus fréquentes que j'ai rencontrées et comment les corriger;
- j'ai ajouté une étape manquante dans l'exemple 05;
- j'ai simplifié la configuration des serveurs REST implémentés par Spring MVC en utilisant le projet Spring Boot;

Pour ce qui concerne les remarques de [nicroman] je répondrai à la fois sur la forme et sur le fond :

La forme d'abord :

Tu écris

J'ai parcouru tout le document (si si ! mais juste parcouru)

C'est pas un peu risqué d'évaluer un document sans l'avoir vraiment lu ?

Le fond ensuite :

Remarque

2.2. De mémoire demander à Eclipse d'encoder en UTF-8 est une très mauvaise idée...

Réponse
J'utilise différents IDE : Eclipse, Netbeans, Intellij Idea. Il se trouve que ces deux derniers IDE travaillent par défaut en UTF-8 et que j'échange souvent des projets Maven entre ces IDE. C'est pourquoi je mets Eclipse en UTF-8.

Remarque

9. Haaa c'est mon domaine !

D'abord, l'exemple montré ne saurait être REST.... en effet, par définition de REST, n appels à un GET sur une URL identique avec des paramètres identique doit retourner des données identiques (c'est tout l'interêt de REST).
Dans l'exemple il ne peut donc s'agir d'un GET.

Réponse

Dans le paragraphe 9.2.2 .on trouve :

Le service REST est implémenté par Spring MVC. Un service REST (RepresEntational State Transfer) est un service HTTP répondant aux demandes GET, POST, PUT, DELETE d'un client HTTP. Sa définition formelle indique pour chacune de ces méthodes, les objets que le client doit envoyer et celui qu'il reçoit. Nous appelons REST notre service parce qu'il est implémenté par un service de Spring qu'on a l'habitude d'appeler service REST et non parce qu'il respecte la définition formelle des services REST.

Si on accepte de ne pas respecter la définition formelle du GET, cette commande est très pratique parce qu'elle peut être testée avec un simple navigateur. J'utilise cette particularité abondamment dans le tutoriel.

Remarque

9.1. Spring MVC comme point d'entrée "API" à un client distant, c'est pas un peu lourdingue ? Je veux dire, Spring MVC est de base fait pour proposer des visualisations (views) et appliquer des règles (controller) sur un modèle... dans le cas d'une API on vire en général la partie views, et la partie modèle... reste grosso-modo que le controlleur.... d'ou mon sentiment que MVC n'est pas adapté aux web-services "API".

Réponse

Spring MVC est parfaitement adapté pour faire du REST. Dans un service REST, le M et le C sont bien présents. Dans les serveurs REST du tutoriel, le V est présent également mais réduit à une chaîne JSON. Mais tout ça, c'est bien du MVC.

Remarque

9.3.6
HAHHAAAAA NON PITIE !
StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder().permitAll().build());
C'est une horreur abjecte ! (on en revient à mon premier point sur le SDK version d'ailleurs).

Réponse

Dans le paragraphe 9.3.6, il est écrit :

On a une exception. Lorsqu'on se renseigne sur elle, on découvre qu'elle est lancée parce qu'on a ouvert une connexion réseau dans le thread de l'activité. Les bonnes pratiques poussent à ouvrir les connexions réseau dans un thread différent de celui de l'activité. Cette exception vise à renforcer cet usage. Ceci dit, cette règle peut être contournée en ajoutant la ligne 14 ci-dessous dans [Mainactivity]*:

On indique donc qu'on va contourner une bonne pratique. Donc ce qu'on fait n'est pas à reproduire. Ceci est redit un peu plus loin lorsqu'on introduit le client asynchrone au paragraphe 10 :

Dans le projet précédent, nous avons contourné une bonne pratique qui dit qu'on ne doit pas ouvrir une connexion réseau dans le thread de l'activité. Nous allons ici la créer dans un autre thread.

Remarque

Donc j'inverserai les chapitres, en commencant par la génération de nombre asynchrone, puis, en intégrant le webservice.
1. C'est cohérent.
2. Cela évite de voir trainer dans un tutoriel/cours l'ignominie du StrictMode !

Réponse

La progression pédagogique veut qu'on aille du plus simple au plus compliqué. Le client synchrone permet d'installer l'architecture client / serveur que va utiliser le client asynchrone tout en évitant la difficulté du multithreading. Dans un second temps, on transforme le client synchrone en client asynchrone en s'appuyant sur une architecture déjà construite mais en introduisant le multithreading. C'est cohérent et dans la révision que je viens de faire, l'ordre des chapitres est resté en l'état.

ST

[nicroman]

Mince, pardon, je m'attendais pas à un échange aussi formel....

C'est pas un peu risqué d'évaluer un document sans l'avoir vraiment lu ?

Mon but n'était pas d'évaluer le document, juste de voir si il y avait des erreurs, inconsistances, ou approximations.

Il se trouve que ces deux derniers IDE travaillent par défaut en UTF-8 et que j'échange souvent des projets Maven entre ces IDE. C'est pourquoi je mets Eclipse en UTF-8.

je viens tout juste de faire le test "simple" dans mon projet:

Code :

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

String toto = "Un test de ça va déraper SÉVÈRE";

Et le code produit n'est pas bon.... (fichier sauvé en UTF-8)...
Le paramètre -encoding est bien passé à javac par eclipse, maven et netbeans, mais un ant de base ne le fait pas "par fichier", il faut le définir en propriété générale...
De toute manière, c'est une mauvaise idée *à la base*, le langage n'acceptant aucun caractère non ASCII. Le seul endroit où de tels caractères pourraient apparaître serait dans les constantes "String". Hors si de tels caractères doivent être insérés dans une constante String, celle-ci est obligatoirement localisée (dépendante de la langue), et donc du même coup, n'ont rien à faire dans un fichier .java ! ....

Spring MVC est parfaitement adapté pour faire du REST

Pas du vrai REST hélas... mais bon... on ne va pas rentrer dans ces détails. Et pour faire du Spring toute la journée je suis bien content d'être passé à du MVP plus adapté à REST à mon humbe avis. Mais c'est un vrai détail...

Le fait est que dans l'article, il n'est fait à aucun moment usage des fonctionalités de REST. Juste un appel à un web-service avec un protocole d'entrée (le paramètres) et un protocole de sortie (le JSON). Pourquoi dès lors évoquer REST ?

La progression pédagogique veut qu'on aille du plus simple au plus compliqué. Le client synchrone permet d'installer l'architecture client / serveur que va utiliser le client asynchrone tout en évitant la difficulté du multithreading. Dans un second temps, on transforme le client synchrone en client asynchrone en s'appuyant sur une architecture déjà construite mais en introduisant le multithreading.

Oui, mais c'est bien mon soucis...

a) Le client synchrone fait une opération "longue" sur les nombres (génération de 'n' nombres peut être long si on utilise un générateur GPS par exemple).
De ce fait le client doit devenir asynchrone pour afficher le résultat (et c'est vrai, indépendamment de l'utilisation ou non d'un appel à un web-service).

b) On introduit *ensuite* la notion de web-service, qui s'insère parfaitement dans le code déjà évoqué.

C'est bien le problème de beaucoup de programmeurs Android qui font sans vergogne des requêtes SQLite en synchrone... La notion d'asynchrone est tellement importante dans une interface par message, que la passer au second plan est à mon avis une erreur.
Un jour Google rajoutera un test dans les requêtes SQLite "SQLiteOnMainThreadException", et on verra des StrictMode apparaître dès l'ouverture d'une base SQLite !