Version imprimable
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.
Salut !
J'ai parcouru tout le document (si si ! mais juste parcouru :D )
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 :D
9. Haaa c'est mon domaine ! :D
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 :D), 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 !
C'est une horreur abjecte ! :D (on en revient à mon premier point sur le SDK version d'ailleurs).Code:StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder().permitAll().build());
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 ! :mouarf:
Merci à toi Serge pour ce super boulot très didactique.:ccool:
Merci à toi nicroman pour tes critiques très constructives.
çà vaut aussi pour Netbeans ?Citation:
demander à Eclipse d'encoder en UTF-8 est une très mauvaise idée...
Ah bon 8O , je pensais aussi qu'il n'y avait que "GET/PUT/POST/DELETE" (mais là je pense pas être le seul :D )Citation:
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.
En fait, ce n'est pas seulement REST hein ! :D Même HTTP ne limite pas à ces méthodes, est REST est basée sur l'utilisation simple de HTTP.Citation:
Envoyé par salve34
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)
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
C'est pas un peu risqué d'évaluer un document sans l'avoir vraiment lu ?Citation:
J'ai parcouru tout le document (si si ! mais juste parcouru)
Le fond ensuite :
Remarque
RéponseCitation:
2.2. De mémoire demander à Eclipse d'encoder en UTF-8 est une très mauvaise idée...
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
RéponseCitation:
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.
Dans le paragraphe 9.2.2 .on trouve :
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.Citation:
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.
Remarque
RéponseCitation:
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".
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
RéponseCitation:
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).
Dans le paragraphe 9.3.6, il est écrit :
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 :Citation:
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]*:
RemarqueCitation:
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.
RéponseCitation:
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 !
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
Mince, pardon, je m'attendais pas à un échange aussi formel....
Mon but n'était pas d'évaluer le document, juste de voir si il y avait des erreurs, inconsistances, ou approximations.Citation:
C'est pas un peu risqué d'évaluer un document sans l'avoir vraiment lu ?
je viens tout juste de faire le test "simple" dans mon projet:Citation:
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.
Et le code produit n'est pas bon.... (fichier sauvé en UTF-8)...Code:String toto = "Un test de ça va déraper SÉVÈRE";
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 ! ....
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...Citation:
Spring MVC est parfaitement adapté pour faire du REST
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 ?
Oui, mais c'est bien mon soucis...Citation:
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.
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 !