Catégorie: Le savoir concevoir

Bonjour,
Un grand jour pour le développement Android, la RC1 de la V1 de Spring for Android est arrivé !
Y'a plus qu'à l'utiliser :o)
C'est ici:
http://www.springsource.org/spring-android/news/1.0.0.rc1-released

Alors, merci qui?
Merci, Spring :o)

Mathias Séguy
mathias.seguy.it@gmail.com

Auteur Android2EE
Ebooks pour apprendre la programmation sous Android.

Retrouvez moi sur Google+
Suivez moi sur Twitter
Rejoignez mon réseau LinkedIn ou Viadeo

Bonne année à tous,
Aujourd'hui un document à lire si vous souhaitez faire des applications Android, le guide officiel du design Android par Google.
Vous le trouverez ici:
http://developer.android.com/design/index.html
Cet vraiment pleins de bonnes pratiques, il faut le lire au moins une fois et y revenir quand on est en phase de Design de l'application. Ok, il est orienté ICS, mais on finira bien par coder avec cette version. (Pas tout de suite, seulement 3.9% des appareils ont une version supérieure à 2.3)

Alors, merci qui?
Merci, Android2ee, les Ebooks de programmation Android :o)

Mathias Séguy
mathias.seguy.it@gmail.com

Auteur Android2EE
Ebooks pour apprendre la programmation sous Android.

Retrouvez moi sur Google+
Suivez moi sur Twitter
Rejoignez mon réseau LinkedIn ou Viadeo

Re, Re, Bonjour.
Les tutoriels sont disponible sur Android2EE section Exemple/Tutoriaux/Handler Tutoriels.

Vous avez le tutoriel avec les AtomicBoolean, celui avec le onRetainNonConfigurationInstance et enfin un projet qui démontre la fuite mémoire quand rien n'est fait.

Alors, merci qui?
Merci, Android2ee, les Ebooks de programmation Android :o)

Mathias Séguy
mathias.seguy.it@gmail.com

Auteur Android2EE
Ebooks pour apprendre la programmation sous Android.

Retrouvez moi sur Google+
Suivez moi sur Twitter
Rejoignez mon réseau LinkedIn ou Viadeo

Re-Bonjour,
Toujours dans cette problématique d'Handler et de cycle de vie d'une activité, il y a une solution préconisée par certains qui est d'utiliser la méthode public Object onRetainNonConfigurationInstance() qui permet de renvoyer un pointeur vers un objet à l'activité.
Euh, je m'explique, lorsque votre activité est détruite pour être immédiatement recrée, la méthode onRetainNonConfigurationInstance permet d’envoyer un objet de l'instance de l’activité mourante vers l'instance de la nouvelle activité.
Exemple adapté à notre problème:
@Override
public Object onRetainNonConfigurationInstance() {
return backgroundThread;}

permet de récupérer l'objet dans la méthode onCreate:
@Override
public void onCreate(Bundle savedInstanceState) {
…
backgroundThread=(Thread)getLastNonConfigurationInstance();
if(backgroundThread==null) {
//créer la thread comme d’habitude
}else{
//pas besoin de else, votre thread est récupérée
}
…}

On voit bien qu'avec cette méthode tout paraît résolu (au moins pour le changement d'orientation de l'appareil). Et oui, mais non, c'est une grave erreur que de penser ça. En effet, que se passe-t-il si votre activité est tuée? Ben, votre thread devient orpheline, votre handler et votre activité deviennent des fantômes (car le Garbage collector les détecte utilisés). Et voilà, encore une fois, Dark Vador se gausse.

La solution, et oui, il y en a une, est un peu plus complexe que cela. Il faut ré-implémenter un atomic boolean permettant de tuer la thread si votre activité n'est pas relancée immédiatement.

Et là, ben je vous invite à aller récupérer les tutoriels que j’ai déposé sur Android2EE section Exemple, partie Tutoriels (Handler Tutoriels).

Alors, merci qui?
Merci, Android2ee, les Ebooks de programmation Android :o)

Mathias Séguy
mathias.seguy.it@gmail.com

Auteur Android2EE
Ebooks pour apprendre la programmation sous Android.

Retrouvez moi sur Google+
Suivez moi sur Twitter
Rejoignez mon réseau LinkedIn ou Viadeo

Bonjour,
Comme je vous disais précédemment, quand vous manipulez les Handlers ou les AsynchTasks, il faut toujours faire en sorte d'accorder le cycle de vie de la thread avec celui du Handler qui est lui-même lié à celui de l'activité... Sinon, votre Thread devient orpheline.
Bon en creusant un peu (je vais vous poser sur Androi2EE un projet eclipse qui démontre ce que je dis), c'est pire, en effet: Lors du passage par onDestroy puis onCreate (bref je retourne l'appareil), non seulement la Thread devient orpheline, mais le Handler aussi (arg, quoi il n'est pas détruit o_O') et pire votre activité devient fantôme... glooops.
Et oui c'est fou, la première activité n'est pas détruite, c'est elle qui est appelée par la première Thread au travers du premier Handler (d'où l'absence de levée d'exception du type NullPointer) et la seconde est créée avec son Handler et sa nouvelle Thread.

Là, j'entends DarkVador, Voldemor et Sauron rirent en pensant au nombre de Threads, de Handlers, d'AsynchTasks et d’activités fantômes qui peuplent les appareils Android à cause de développeurs inconscients du danger.

Donc: Gérer vos threads en accordant leur cycle de vie avec celui de l'activité.

Alors, merci qui?
Merci, Android2ee, les Ebooks de programmation Android :o)

Mathias Séguy
mathias.seguy.it@gmail.com

Auteur Android2EE
Ebooks pour apprendre la programmation sous Android.

Retrouvez moi sur Google+
Suivez moi sur Twitter
Rejoignez mon réseau LinkedIn ou Viadeo

Bonjour,
Vous avez une activité qui utilise un Handler. Pour cela, vous avez créé votre Handler, redéfini sa méthode handleMessage, vous avez créé et lancer la thread associée au Handler et voilà c’est fini pour la gestion de votre Handler…
La plupart d’entre nous aurons fait un chose pareille et c’est une énorme erreur !!!
Qu’arrive-t-il à votre thread quand votre activité passe en pause, est relancée, est détruite puis re-créée ?
Votre thread devient une thread orpheline !!
Ainsi vous avez écrit quelque chose comme ça : 
/** 
 * The handler  
 */ 
private final Handler slowDownDrawingHandler; 
/** Called when the activity is first created. */ 
@Override 
public void onCreate(Bundle savedInstanceState) { 
// handler definition 
slowDownDrawingHandler = new Handler() { 
  /** (non-Javadoc)*/ 
  @Override 
  public void handleMessage(Message msg) { 
  super.handleMessage(msg); 
  redraw(); 
  } 
}; 
// Launching the Thread to update draw 
Thread background = new Thread(new Runnable() { 
  /** 
   * The message exchanged between this thread and the handler 
   */ 
  Message myMessage; 
 
  // Overriden Run method 
  public void run() { 
try { 
    while (true) { 
  // Sleep 
  Thread.sleep(100); 
  // Do something 
  myMessage = slowDownDrawingHandler.obtainMessage(); 
  // then send the message 
  slowDownDrawingHandler.sendMessage(myMessage); 
    } 
  } 
  } catch (Throwable t) { 
  // just end the background thread 
  } 
  } 
}); 
// start the thread 
background.start();

En utilisant un code de ce type, quand votre activité meurt ou passé en pause, votre Thread devient orpheline. Plus rien ne peut l’atteindre, la détruire, communiqué avec elle… C’est une grosse erreur (genre tour Eiffel la taille de l’erreur, avec fuite mémoire et tout…).
Quelle est la façon de faire alors? Vous avez à gérer le cycle de vie de votre thread pour qu’elle soit en adéquation avec le cycle de vie de votre activité. Quand votre activité passé en pause, votre thread doit aussi passé en pause, quand elle est relancée votre thread doit l’être aussi, quand votre activité meurt votre thread aussi.
Une façon simple de faire cela est d’utiliser des AtomicBoolean (qui sont des Booleans synchronized) par exemple isPausing et isStopping, de changer leur valeur quand votre activité passe en pause, est relancée ou meurt et d’utiliser ces Booléens pour gérer le cycle de vie de votre thread.
Le code à utiliser est donc le suivant: 
/** * The handler */ 
private final Handler slowDownDrawingHandler; 
/** * An atomic boolean to manage the external thread's destruction */ 
AtomicBoolean isRunning = new AtomicBoolean(false); 
/** * An atomic boolean to manage the external thread's destruction */ 
AtomicBoolean isPausing = new AtomicBoolean(false); 
/** Called when the activity is first created. */ 
@Override 
public void onCreate(Bundle savedInstanceState) { 
// handler definition 
slowDownDrawingHandler = new Handler() { 
  @Override 
  public void handleMessage(Message msg) { 
  super.handleMessage(msg); 
  redraw(); 
  } 
}; 
// Launching the Thread to update draw 
Thread background = new Thread(new Runnable() { 
  /** 
   * The message exchanged between this thread and the handler 
   */ 
  Message myMessage; 
  // Overriden Run method 
  public void run() { 
  try { 
      while (isRunning.get()) { 
      if(isPausing.get()) { 
        Thread.sleep(2000); 
      }else { 
      // Sleep 
      Thread.sleep(100); 
      // Do something 
      myMessage = slowDownDrawingHandler.obtainMessage(); 
      // then send the message 
      slowDownDrawingHandler.sendMessage(myMessage); 
    } 
    } 
    } 
  } catch (Throwable t) { 
  // just end the background thread 
} 
  } 
}); 
// Initialize the threadSafe booleans 
isRunning.set(true); 
isPausing.set(false); 
background.start(); 
} 
 
/*(non-Javadoc) */ 
@Override 
protected void onPause() { 
//and don't forget to stop the thread  
isPausing.set(true); 
super.onPause(); 
} 
 
/*(non-Javadoc) */ 
@Override 
protected void onResume() { 
//and don't forget to relaunch the thread  
isPausing.set(false); 
super.onResume(); 
} 
 
/*(non-Javadoc) */ 
@Override 
protected void onDestroy() { 
//and don't forget to kill the thread  
isRunning.set(false); 
super.onDestroy(); 
}
Ceci est un exemple de comment résoudre le problème de manière générique. A vous de vous poser la question est de trouver la solution la plus appropriée à la gestion des threads de votre application. Mais n’oubliez pas : une thread orpheline, c’est une erreur qui coûte un bras.

(Pour voir le code en couleur, c'est ici :Version anglaise colorama)
Alors, merci qui?
Merci, Android2ee, les Ebooks de programmation Android :o)

Mathias Séguy
mathias.seguy.it@gmail.com

Auteur Android2EE
Ebooks pour apprendre la programmation sous Android.

Retrouvez moi sur Google+
Suivez moi sur Twitter
Rejoignez mon réseau LinkedIn ou Viadeo

Bonjour (enfin Re-Bonjour),

Je viens de tomber sur un tuto (en anglais je sais sorry about that:o)) qui montre comment utiliser l'API google + au sein de vos applications Android. C'est un peu compliqué à comprendre mais en même temps cela permet de mieux comprendre plein de choses. En effet, il construit un web-service pour rediriger les demandes vers Google... mais en même temps du coup on comprend plein de trucs.

Le tuto c'est ici: http://gnuc.in/resources/archives/1541

Alors, merci qui?
Merci, Android2ee, les Ebooks de programmation Android :o)

Mathias Séguy
mathias.seguy.it@gmail.com

Auteur Android2EE
Ebooks pour apprendre la programmation sous Android.

Retrouvez moi sur Google+
Suivez moi sur Twitter
Rejoignez mon réseau LinkedIn ou Viadeo

Bonjour,

Il est parfois bien utile pour nos applications de pouvoir les notifier à partir de notre serveur (enfin du votre pour vos applications). Cette méthode s'appelle le push et permet d'envoyer des notifications à votre application.

Il y a plusieurs ruses de sioux pour y arriver (par SMS, avec une connexion http permanente vers votre serveur...). Mais le problème des ruses de sioux c'est qu'elles ne sont pas pertinentes quand une solution clef en main est fournie par l'Android SDK lui-même.

En effet, Google, met à disposition des développeurs des serveurs qui se chargent de faire ce push et des commandes qui vous permettent de l'implémenter dans votre application. Ce service l'Android Cloud to Device Messaging Framework aussi connu sous le nom de C2DM vous permet de mettre en place cette fonctionnalité. Comme beaucoup de service Google, il vous faut vous enregistrer pour en profiter.

Le tuto Google (toujours très clair) suivant vous permet en deux temps trois mouvements et deux coups de cuillère à pot de mettre en œuvre ce service:

http://code.google.com/intl/fr/android/c2dm/index.html

Et bon push à vous :o)

Alors, merci qui?
Merci, Android2ee, les Ebooks de programmation Android :o)

Mathias Séguy
mathias.seguy.it@gmail.com

Auteur Android2EE
Ebooks pour apprendre la programmation sous Android.

Retrouvez moi sur Google+
Suivez moi sur Twitter
Rejoignez mon réseau LinkedIn ou Viadeo

Bonjour,
Android2EE vient de publier son arcticle intitulé "Construire Dynamiquement ses IHM Android" (en cours de relecture sur DVP). Cet article vous explique comment construire dynamiquement une IHM. Il explique comment déclarer les composants, les placer dans leur layout, utiliser les ScrollViews, charger des images à partir de leur nom dans le dossier de ressources ou leur URL. Enfin il montre comment générer des données de tests au format JSON.

C'est ici : Construire Dynamiquement ses IHM Android.

Cerise sur le gateau, cet article est associé à un tutorial gratuit que vous pouvez télécharger sur Android2ee à la rubrique "Exemples".

Bonne lecture, bon téléchargement!

Merci qui?
Merci, Android2ee, les Ebooks de programmation Android.

Mathias Séguy
mathias.seguy.it@gmail.com
Auteur Android2EE
Ebooks pour apprendre la programmation sous Android.

Voilà, la nouvelle est lachée, le nouveau SDK pour HoneyComb est disponible en télécharegement.
Dans Eclipse, ouvrez votre "Android SDK and AVD Manager" et dans les "Avaiable packages" découvrez le "SDK platform Android3.1, API 12, revision1".
C'est le premier cadeau de Google lié à l'évènement Google IO qui se passe en ce moment.
(cf http://android-developers.blogspot.com/2011/05/android-31-platform-new-sdk-tools.html)

Alors, merci qui?
Merci, Android2ee, les Ebooks de programmation Android :o)

Mathias Séguy
mathias.seguy.it@gmail.com
Auteur Android2EE
Ebooks pour apprendre la programmation sous Android.

Encore un petit billet sur Android.
Sony va sortir deux tablettes Android d'ici la fin de l'année.
Il provient de la BBC new Technology:
http://www.bbc.co.uk/news/technology-13192354
Alors Android développeurs, à vos claviers, le monde souffle pour vous.

Alors, merci qui?
Merci, Android2ee, les Ebooks de programmation Android :o)

Mathias Séguy
mathias.seguy.it@gmail.com
Auteur Android2EE
Ebooks pour apprendre la programmation sous Android.