Reprise du message précédent :

parceque pour la vraie appli c'est ici

 
ben oui normal

Je planche sur un service de notification qui vous indiquerai dans la barre de notif quand vous avez un ou plusieurs nouveaux mp

Je suis curieux de savoir comment tu vas faire sans sucrer la batterie  

MUST
NOT  
FAP
 
 

Ben tout va se jouer sur la fréquence de vérification mais oui, c'est consommateur

Faut demander à joce pour intégrer http://code.google.com/intl/fr-FR/ [...] index.html

toyo, la classe d'authentification sera prête demain

harkonnen harkonnen harkonnen  
 
YEAAAAAAAAAAAAAAH  
 

 
un H !
un A !
un R !
un K !
un O !
un N !
un autre N !
un E !
un dernier N !
 
HAAAAAAAAAAAAAARKONNEN !!!!!!!!!!!!
 
yEAAAAAAAAAAAAAAAAH !!
 
 
 
je suis content

du calme, ça avance pas aussi vite que je le voudrais de mon coté à cause des petits soucis de santé de ma copine (sans gravité)

Toyo => quelques infos au cas où tu voudrais commencer un truc :
- le constructeur de la classe prend 3 paramètres : l'url de la page de connexion, le nom d'utilisateur et le mot de passe.
- 1 méthode publique : login() que je n'ai pas besoin d'expliquer
- 1 variable membre publique de type CookieStore, qui contient les cookies renvoyés par la connexion. il te suffira ensuite de transmettre ces cookies à ton httpclient chaque fois que tu en auras besoin (via HttpContext) :

cookieStore = Authentication.cookieStore;
HttpContext httpContext = new BasicHttpContext();
httpContext.setAttribute(ClientContext.COOKIE_STORE, cookieStore);
(...)
httpClient.execute([HttpGet|HttpPost], httpContext);

cette classe n'est pas finie : il manque le traitement d'un user et/ou mot de passe erroné (pour l'instant, j'assume que les données saisies sont correctes ), mais ce que je te livre demain te permettra d'avancer un peu.

au sujet de la variable membre publique (au lieu d'un getter habituel), je te laisse lire le pourquoi du comment ici
http://developer.android.com/guide [...] al_get_set

pourquoi tu perds du temps la dessus si c'est pas grave ?

A quel endroit ils disent de mettre l'attribut en public et de ne pas faire de getter/setter?

oui tu as mal lu Harkonnen, c'est dans le code même de la classe qu'il vaut mieux accéder à l'attribut direct plutôt que par son getter ... mais de l'extérieur il faut continuer à appeler le getter

Il y a des gens qui utilisent des getters/setters pour accéder aux membres à l'intérieur de leur propre classe ?    
/debatalacon

il peut y avoir des cas où c'est plus lisible ..
Typiquement si j'ai une classe A qui hérite de B possédant un attribut X, dans A je préfère appeler getX() au lieu de X directement, comme ça quand je fais un "Open call hierarchy" (eclipse powered ) sur la déclaration de getX() dans B bah il me montre aussi l'appel fait dans A

je viens de relire ma phrase, et j'ai mal à la tête

Rien à voir avec la lisibilité A la limite un getter (ou setter) ne fait pas un simple return mAttr ; mais va faire des vérifs sur des contitions avant de retourner l'attribut. Enfin ce n'est que mon avis.

ben dans le cas pratique détaillé 3 posts au dessus ça aide à ma lisibilité mais je suis d'accord que c'était juste histoire de trouver un contre-exemple
 
sinon pour le debug rien de pire que des getters/setters qui font autre chose que de se contenter de retourner/setter l'attribut ...

Ben c'est un peu l'objet de l'article hein
 
Moi j'ai compris ceci :

interface foo
{
   public int getBar();
}
 
public class toto implements foo  
{
   public int i;
   
   public int getBar()
   {
      return i;
   }
 
   public toto(int i)
   {
      this.i = i;
   }
}
 
class machin
{
   public static void Main()
   {
      foo a = new toto(3);
      int g = a.getBar(); // accès par l'interface
 
      toto b = new toto(3);
      int z = b.i; // accès par la classe
   }
}

voilà ce que j'ai compris. Après je peux me tromper hein, mais perso des méthodes qui accèdent aux données membres de leur classe par des accesseurs, n'en ai jamais vu

 
On parle bien de l'accès par un objet d'une de ses variables membres par une des ses fonctions membres ...
Et dans ce cas ( cf article de Android Dev )  "... On Android, this is a bad idea.  ..."  
 

 
Voilà ...
 

 
Oui mais là, on ne parle pas de lisibilité mais de performance ( à nouveau cf article Android Dev "Designing for Performance" cité par Harko )
 

 
Non, tu sors alors complètement du cadre de base d'un getter/setter ...
 

 
Voilà quoi ! .......... Tu veux être mon ami ?

interface foo
{
   public int getBar();
}
 
public class toto implements foo  
{
   public int i;
   
   public int getBar()
   {
      return i;
   }
 
   public toto(int i)
   {
      this.i = i;
   }
}
 
class machin
{
   public static void Main()
   {
      foo a = new toto(3);
      int g = a.getBar(); // accès par l'interface
 
      toto b = new toto(3);
      int z = b.i; // accès par la classe
   }
}

non non, tu as mal compris, le mot clef c'est "internal"
 
d'ailleurs la preuve c'est que dans leur exemple ils précisent bien :
i = mCount  à la place de i = getCount()
et non pas comme dans ton exemple :
i = b.mCount  à la place de i = b.getCount()

 
 
Moi j'ai compris que : It's reasonable to follow common object-oriented programming practices and have getters and setters in the public interface, but within a class you should always access fields directly.
 
veut dire :
 
Il est raisonnable de suivre les pratiques courantes de programmation orientée objet et de mettre les getters et setters dans l'interface publique, mais au sein d'une classe, vous devez toujours accéder aux champs directement.
 
Donc ton attribut i doit être privé, de l'extérieur on y accède par la méthode getBar, mais à l'intérieur de ta classe si tu veux accéder à ton attribut tu n'utilises pas le getter, tu utilises directement l'attribut.
 
Exemple la classe Socket :
 
Nulle part tu vois des attributs publiques. Si tu veux connaître le port local tu utilises getLocalPort() en tant qu'utilisateur de la classe. Pourtant dans l'implémentation de la méthode connect(SocketAddress remoteAddr) qui doit utiliser le port local, on doit accéder directement à l'attribut privé mLocalPort et non pas utiliser getLocalPort().
 
Ce qui retranscrit bien It's reasonable to follow common object-oriented programming practices

 
ça dépend si tu aimes copuler sauvagement dans le foin ?

 
C'est vrai J'étais moi-même dans la contradiction

ton esprit est revenu dans le droit chemin  

et je tiens à dire que c'est monnaie courante d'autant plus si l'attribut en question est hérité (je reviens sur mon exemple plus haut) ... dans la classe fille tu trouves des getBidule() au lieu de mBidule
 
si t'en as vraiment jamais vu bah ...

ça veut dire non ?    
 

but within a class you should always access fields directly.
 
Pour moi ça veut dire en interne.
En externe, si une classe veut accéder à i, on utilise le getter. Dans ton exemple, machin est une autre classe, externe, donc getBar est de bon aloi.
 
Mais ton raisonnement n'est pas con du tout, mais peut être tordu non ?

C'est bien ça
A l'intérieur de la classe, tu accèdes à l'attribut directement, à partir du moment ou c'est une classe externe (je dirais même une dérivée), il faut utiliser un getter

C'est contraire au principe d'encapsulation

Par ailleurs je ne connais pas trop les principes d'héritages en java, mais en C++ on peut jouer sur la visibilité des attributs de la classe mère avec l'héritage protégé ou privé. Dans ce cas on est obligé d'accéder aux attributs de la classe mère par les getters et setters. C'est la même chose en java?

oui

Ben oui. Suffit que A est un attribut privé toto.
B qui hérite de A aura accès à toto via un getter.

 
T'es certain de ça ?    
 
Si B hérite de A , il accédera au variables membres de A comme si elles étaient les siennes ... en direct !
 
[ edit: on me signale dans mon oreillette que pour que B accède aux variables privées de sa classe parent, ils faut qu'elles soient déclarées 'protected'  .... au temps pour moi ! ]

   
 
la visibilité package doit être valide aussi, si la classe fille est dans le même package.

Ca dépend aussi beaucoup du langage, tous ne proposent pas la possibilité de mettre un attribut en protégé

protected, package/friendly, public

La notification des mps marche, c'est classe

j'avais pensé à une notification Toast pour faire à peu près la même chose (Thread indépendant qui checke toutes les 5mn l'arrivée de MPs)
 
les notifs Toast c'est ça (avec genre "un nouveau MP est arrivé!" à la place de "You selected Ubuntu" )