+ Répondre à la discussion Actualité déjà publiée
  1. #1
    Expert éminent

    Profil pro
    Inscrit en
    avril 2009
    Messages
    100
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2009
    Messages : 100
    Points : 6 230
    Points
    6 230

    Par défaut [Cours débutant] Introduction à la programmation de tablettes Android

    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.

  2. #2
    Modérateur

    Homme Profil pro
    Ingénieur systèmes et réseaux
    Inscrit en
    février 2007
    Messages
    4 254
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingénieur systèmes et réseaux
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : février 2007
    Messages : 4 254
    Points : 7 606
    Points
    7 606
    Billets dans le blog
    3

    Par défaut

    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 !
    N'oubliez pas de cliquer sur mais aussi sur si un commentaire vous a été utile !
    Et surtout

  3. #3
    Membre régulier
    Profil pro
    Inscrit en
    décembre 2009
    Messages
    53
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2009
    Messages : 53
    Points : 111
    Points
    111

    Par défaut

    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 )

  4. #4
    Modérateur

    Homme Profil pro
    Ingénieur systèmes et réseaux
    Inscrit en
    février 2007
    Messages
    4 254
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingénieur systèmes et réseaux
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : février 2007
    Messages : 4 254
    Points : 7 606
    Points
    7 606
    Billets dans le blog
    3

    Par défaut

    Citation Envoyé par salve34 Voir le message
    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)
    N'oubliez pas de cliquer sur mais aussi sur si un commentaire vous a été utile !
    Et surtout

  5. #5
    Expert éminent

    Profil pro
    Inscrit en
    avril 2009
    Messages
    100
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2009
    Messages : 100
    Points : 6 230
    Points
    6 230

    Par défaut

    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

  6. #6
    Modérateur

    Homme Profil pro
    Ingénieur systèmes et réseaux
    Inscrit en
    février 2007
    Messages
    4 254
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingénieur systèmes et réseaux
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : février 2007
    Messages : 4 254
    Points : 7 606
    Points
    7 606
    Billets dans le blog
    3

    Par défaut

    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 !
    N'oubliez pas de cliquer sur mais aussi sur si un commentaire vous a été utile !
    Et surtout

Discussions similaires

  1. Réponses: 1
    Dernier message: 06/03/2015, 17h43
  2. Réponses: 9
    Dernier message: 02/05/2012, 12h01
  3. Introduction à la programmation sous Android
    Par Djug dans le forum Android
    Réponses: 7
    Dernier message: 12/09/2011, 17h20

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo