Les casts en C++

Nombreux sont les programmeurs C++ qui ont d’abord été confrontés au C. Les deux langages partagent en effet bien des fonctionnalités… mais ont également de grandes différences.

Parmi ces différences, on trouve les opérateurs de conversion C++. Ils sont certainement l’un des points les plus mal compris par les développeurs C qui voient souvent en eux un verbiage inutile. L’objectif de cet article est de (dé)montrer l’utilité des opérateurs de conversion C++, en comparaison avec les conversions classiques, dites : “à la C” et de comprendre ce qu’ils peuvent apporter au programmeur en termes de maintenabilité et de sécurité.

Un petit mot sur les conversions

Les conversions (ou “cast” en anglais) sont un des outils incontournables du programmeur C++. Mais comme tout outil, il faut savoir les utiliser à bon escient.

Dans l’idéal, un programme doit contenir le moins possible de “casts” : les types doivent s’interfacer naturellement les uns avec les autres. Cela garantit un découplage du code et donc une meilleure maintenabilité. Cela ne signifie pas qu’il faille à tout prix éviter les “casts” mais simplement qu’il faut les utiliser avec parcimonie.

Dans les sections qui suivent, nous allons expliquer le rôle de chaque opérateur de conversion. Pour l’ensemble des sections, nous considérerons les classes suivantes lorsqu’il sera question de hiérarchie :

class Base { public: virtual ~Base() {} };
class Derived : public Base {};
class Derived2 : public Base {};

class Base { public: virtual ~Base() {} };

class Derived : public Base {};

class Derived2 : public Base {};

static_cast<>

Il permet plusieurs choses :

Expliciter les conversions implicites, supprimant du même fait tout avertissement que donnerait le compilateur si la conversion peut entraîner un risque. Exemple : double vers int.
Convertir vers et depuis n’importe quel type pointé à partir d’un void*. Exemple : void* vers unsigned char*.
Convertir au travers d’une hiérarchie de classe, sans effectuer de vérification préalable. Exemple : Base* vers Derived* ou Base& vers Derived&.
Ajouter l’attribut constant au type converti. Exemple : char* vers const char*.

Dans le dernier cas, notez que puisqu’il n’y a aucune vérification et que static_cast<> n’échoue jamais, le code suivant a un comportement indéfini (communément nommé en anglais “undefined behavior” ou “UB“) :

void foo()
{
Base* base = new Derived();

// Ce code est valide et correct car base pointe en fait vers une instance de Derived.
Derived* derived = static_cast&lt;Derived*&gt;(base);

// Ce code compile mais à un comportement indéfini (Undefined Behavior)
// car base ne pointe pas vers une instance de Derived2.
Derived2* derived2 = static_cast&lt;Derived2*&gt;(base);
}

void foo()

{

Base* base = new Derived();

// Ce code est valide et correct car base pointe en fait vers une instance de Derived.

Derived* derived = static_cast<Derived*>(base);

// Ce code compile mais à un comportement indéfini (Undefined Behavior)

// car base ne pointe pas vers une instance de Derived2.

Derived2* derived2 = static_cast<Derived2*>(base);

}

Notez que la notion de comportement indéfini n’offre par définition aucune garantie : le code peut avoir le comportement espéré, faire crasher le programme ou provoquer l’envoi d’un missile nucléaire sur Cuba.

Il ne permet pas de :

Convertir vers ou depuis un type pointé à partir d’un autre type pointé autre que void*. Exemple : unsigned char* vers char*.
Tester qu’une instance est celle d’un type dérivé. Exemple : tester qu’un Base* est en fait un Derived*.
Supprimer l’attribut constant du type converti. Exemple : const char* vers char*.

En bref

static_cast<> est sans doute l’opérateur de conversion que vous serez amené à utiliser le plus. Il ne permet que de réaliser des conversions sûres et à pour rôle principal celui d’expliciter les conversions implicites.

Dans le cas du polymorphisme, il est à préférer à dynamic_cast<> lorsque l’on a la garantie que la conversion va réussir.

dynamic_cast<>

Le seul rôle de dynamic_cast<> est de tester à l’exécution si un pointeur d’un type de base est en fait un pointeur vers un type dérivé.

Exemple :

void foo()
{
Base* base = new Derived();

// Après l'appel, derived pointe vers l'instance de Derived
// car base pointe en fait vers une instance de Derived.
Derived* derived = dynamic_cast&lt;Derived*&gt;(base);

// Après l'appel, derived2 vaut 0
// car base ne pointe pas vers une instance de Derived2.
Derived2* derived2 = dynamic_cast&lt;Derived2*&gt;(base);

// Dans le cas d'une référence, si le cast n'est pas possible
// Une exception de type std::bad_alloc est lancée.
Derived2&amp; derived2_bis = dynamic_cast&lt;Derived2&amp;&gt;(*base);
}

void foo()

{

Base* base = new Derived();

// Après l'appel, derived pointe vers l'instance de Derived

// car base pointe en fait vers une instance de Derived.

Derived* derived = dynamic_cast<Derived*>(base);

// Après l'appel, derived2 vaut 0

// car base ne pointe pas vers une instance de Derived2.

Derived2* derived2 = dynamic_cast<Derived2*>(base);

// Dans le cas d'une référence, si le cast n'est pas possible

// Une exception de type std::bad_alloc est lancée.

Derived2& derived2_bis = dynamic_cast<Derived2&>(*base);

}

Note : pour que dynamic_cast<> fonctionne, le type de base doit posséder au moins une méthode virtuelle.

Un appel à dynamic_cast<> est plus coûteux qu’un appel à static_cast<>car dynamic_cast<> effectue une recherche dans la “v-table” de l’instance à l’exécution pour déterminer son type exact.

On veillera donc à n’utiliser dynamic_cast<> que lorsqu’il n’y a aucune autre solution.

En bref

dynamic_cast<> est le seul opérateur de conversion à avoir un effet “indéterminé” jusqu’à l’exécution. Son utilisation n’a de sens que lorsque confronté à du polymorphisme. Dans les cas où la conversion est assurée de réussir, on lui préfèrera static_cast<> plus rapide et ne nécessitant pas que les classes possèdent une méthode virtuelle.

const_cast<>

const_cast<> permet de supprimer l’attribut constant ou volatile d’une référence ou d’un type pointé. Exemple : const char* vers char* ou volatile int vers int.

C’est notamment le seul opérateur de conversion à pouvoir le faire : même reinterpret_cast<> n’a pas ce pouvoir.

void foo()
{
char* buf = new char[16];

// L'ajout de l'attribut const ne nécessite pas de cast
// Il est implicite
const char* cbuf = buf;

// Le retrait de l'attribut const nécessite const_cast&lt;&gt;.
char* buf2 = const_cast&lt;char*&gt;(cbuf);
}

void foo()

{

char* buf = new char[16];

// L'ajout de l'attribut const ne nécessite pas de cast

// Il est implicite

const char* cbuf = buf;

// Le retrait de l'attribut const nécessite const_cast<>.

char* buf2 = const_cast<char*>(cbuf);

}

L’importance d’écrire un code “const-correct”

Directement relié aux opérateurs de conversion, l’écriture d’un code const-correct est un autre aspect du C++ souvent mal perçu par les programmeurs C. Le C est plus ancien et le mot clé const n’y a pas toujours existé; il a été emprunté au C++ par la suite.

Le fait d’indiquer qu’une variable est constante est un outil puissant permettant au compilateur de nous signaler certaines de nos erreurs qui auraient autrement passé la barrière de la compilation.

Qui ne s’est jamais trompé dans l’ordre des arguments d’un memcpy() ?

void foo()
{
const char* source = "blog.freelan.org";
char* destination = new char[16];

// Oups ! Je me suis trompé dans l'ordre des arguments...
// ... heureusement, puisque memcpy spécifie que le premier paramètre est un void*
// et pas un const void*, le compilateur m'indique une erreur.
memcpy(source, destination, strnlen(source));
}

void foo()

{

const char* source = "blog.freelan.org";

char* destination = new char[16];

// Oups ! Je me suis trompé dans l'ordre des arguments...

// ... heureusement, puisque memcpy spécifie que le premier paramètre est un void*

// et pas un const void*, le compilateur m'indique une erreur.

memcpy(source, destination, strnlen(source));

}

Les mots clé “const” ou “volatile” appliqués aux classes

En C++, les mots clé const et volatile s’appliquent évidemment aussi aux instances de classes mais ont des sémantiques différentes :

Le caractère const ou volatile s’applique récursivement aux membres de l’instance.

Il n’est possible d’appeler une méthode d’une classe que dans les cas suivants :

l’instance n’est pas const.
l’instance est const et la méthode est déclarée const.
l’instance est déclarée volatile et la méthode est déclarée volatile.
l’instance est déclarée const et volatile et la méthode est elle aussi déclarée const et volatile.

À propos de “volatile”

Certains lecteurs peuvent être perdus à la lecture du mot clé volatile qui, il faut bien l’avouer, n’est pas utilisé très souvent. Décrire précisément le rôle de volatile mériterait un article bien à part mais je vais tout de même dire en deux mots à quoi il sert :

Lorsqu’une variable est déclarée volatile, le compilateur n’a pas le droit d’optimiser sa valeur (mise en cache processeur) lors de tests.

Ainsi sans volatile sur la variable do_loop, le code suivant :

void foo()
{
bool do_loop = true;
while (do_loop) { doSomething(); }
}

void foo()

{

bool do_loop = true;

while (do_loop) { doSomething(); }

}

Risquerait d’être optimisé en tant que :

void foo()
{
while (true) { doSomething(); }
}

void foo()

{

while (true) { doSomething(); }

}

Ce qui est correct dans la plupart des cas… sauf si do_loop peut être modifié par un autre thread. C’est principalement dans ce genre de cas que volatile trouve son utilité.

Erreurs courantes

Une erreur courante concernant const_cast<> consiste à supposer que l’on peut toujours supprimer le caractère constant d’une variable.

Ceci est évidemment faux : on ne peut supprimer le caractère constant (respectivement volatile) d’une variable que lorsque celle-ci a été déclarée non-const (respectivement non-volatile).

Ainsi le code suivant a un comportement indéfini :

void foo()
{
const char* cbuf = "blog.freelan.org";

// L'utilisation de const_cast&lt;&gt; ici a un comportement indéfini (undefined behavior)
// car cbuf a été déclaré const.
char* buf = const_cast&lt;char*&gt;(cbuf);
}

void foo()

{

const char* cbuf = "blog.freelan.org";

// L'utilisation de const_cast<> ici a un comportement indéfini (undefined behavior)

// car cbuf a été déclaré const.

char* buf = const_cast<char*>(cbuf);

}

Un autre cas courant est celui des variables membres qui servent à mettre en cache un résultat :

class MyClass
{
public:

MyClass() : m_value_cache(0) {}

int getValue() const
{
if (m_value_cache == 0)
const_cast&lt;int&amp;&gt;(m_value_cache) = computeValue();

return m_value_cache;
}

private:

static int computeValue();

int m_value_cache;
};

class MyClass

{

public:

MyClass() : m_value_cache(0) {}

int getValue() const

{

if (m_value_cache == 0)

const_cast<int&>(m_value_cache) = computeValue();

return m_value_cache;

}

private:

static int computeValue();

int m_value_cache;

};

L’utilisation de const_cast<> ici est erronée : si on déclare une instance const de MyClass, m_value_cache est aussi const lors de sa définition. L’utilisation de const_cast<> est la même que dans l’exemple précédent et a comportement indéfini.

La bonne solution est d’utiliser le mot clé mutable, qui permet à une variable membre de ne pas avoir les mêmes contraintes const/volatile que son instance parente :

class MyClass
{
public:

MyClass() : m_value_cache(0) {}

int getValue() const
{
// m_value_cache est déclaré mutable
// il peut donc changer, même dans une méthode const
if (m_value_cache == 0)
m_value_cache = computeValue();

return m_value_cache;
}

private:

static int computeValue();

// Utilisation du mot clé "mutable"
mutable int m_value_cache;
};

class MyClass

{

public:

MyClass() : m_value_cache(0) {}

int getValue() const

{

// m_value_cache est déclaré mutable

// il peut donc changer, même dans une méthode const

if (m_value_cache == 0)

m_value_cache = computeValue();

return m_value_cache;

}

private:

static int computeValue();

// Utilisation du mot clé "mutable"

mutable int m_value_cache;

};

En bref

const_cast<> est le seul opérateur de conversion à pouvoir supprimer le caractère const ou volatile d’une variable. L’utilisation de const_cast<> doit rester très rare : le contraire indique souvent une importante erreur de design. Son seul usage habituellement toléré est l’interfaçage avec des bibliothèques historiques qui ne sont pas const-correct.

reinterpret_cast<>

Il s’agit de l’opérateur de conversion le plus dangereux, et du plus mal utilisé. Son rôle est de dire au compilateur : “réinterprète-moi la représentation binaire de ce type en tant qu’un autre type”.

Il permet :

De convertir n’importe quel type pointé en une autre, même lorsque ceux-ci n’ont aucun rapport. Exemple : int* vers double*.
De convertir un type pointé en sa représentation intégrale et vice et versa. Exemple : int* vers int.

Il est à noter que ces conversions sont dépendantes de l’implémentation. En d’autres termes, le compilateur est libre de faire ce qu’il veut concernant la conversion basée sur reinterpret_cast<> mais ce comportement doit être constant : il ne s’agit pas de comportement indéfini; le comportement est bien défini, simplement pas par le standard C++ mais votre version du compilateur. Si vous vous basez sur cette dépendance de l’implémentation, votre code est donc non-portable.

La seule garantie délivrée par le standard C++ concernant reinterpret_cast<> est que si vous convertissez un type A en un type B, puis de nouveau en un type A, le comportement est bien défini et vous récupérez bien la valeur de départ.

On comprend dès lors facilement le danger que peut représenter reinterpret_cast<>.

Voici un exemple d’utilisation :

void foo()
{
int a = 5;

// Le contenu de b dépend du compilateur utilisé
// et n'est pas défini par le standard
double* b = reinterpret_cast&lt;double*&gt;(&amp;a);

// Ici, on a la garantie que *c vaudra a, c'est à dire 5.
int* c = reinterpret_cast&lt;int*&gt;(b);
}

void foo()

{

int a = 5;

// Le contenu de b dépend du compilateur utilisé

// et n'est pas défini par le standard

double* b = reinterpret_cast<double*>(&a);

// Ici, on a la garantie que *c vaudra a, c'est à dire 5.

int* c = reinterpret_cast<int*>(b);

}

Cas particuliers

Le peu de garanties associées à reinterpret_cast<> rendent celui-ci quasiment inutile dans la plupart des cas. Il y a cependant certaines exceptions de fait qui justifient une utilisation de reinterpret_cast<> sans nuire à la portabilité :

Les conversions entre les types char* et unsigned char* bien que non spécifiées par le standard, sont en pratique supportées par tous les compilateurs et produisent le comportement attendu. Le compilateurs ont par ailleurs de plus fortes contraintes à leur égard (spécifiquement au niveau de leur représentation) pour des raisons de compatibilité ascendante avec le C.

Vous pouvez donc clairement supposer qu’un reinterpret_cast<> entre un char* et un unsigned char* sera à la fois portable et défini.

Polymorphisme

reinterpret_cast<> utilisé dans le cadre d’une conversion faisant intervenir du polymorphisme a un comportement non défini. Il n’est ainsi pas correct d’effectuer un reinterpret_cast<> entre par exemple un Base* et un Derived*.

En bref

reinterpret_cast<> est l’opérateur de conversion le plus dangereux : permettant de faire ce qu’aucun autre ne peut faire (des conversions entres des types non liés) il convient de l’utiliser avec la plus grande prudence. En pratique, on lui préfèrera static_cast<> qui permet d’effectuer des conversions plus sûres, y compris vers et depuis des types pointés génériques (void*). Son seul usage toléré est l’interfaçage avec du code C ancien qui utilise pour ses paramètres de “buffer” des char* ou unsigned char* au lieu des void*.

Old-school : les conversions “à la C”

Le C++ supporte toujours l’ancienne syntaxe concernant les conversions “à la façon C”. Cependant, le standard précise clairement l’effet d’une telle conversion :

Le “cast” suivant : (Type)valeur ou Type(valeur)

Sera équivalent à, par ordre de préférence :

un const_cast<>
un static_cast<>
un static_cast<> suivi d’un const_cast<>
un reinterpret_cast<>
un reinterpret_cast<> suivi d’un const_cast<>

Les bonnes pratiques indiquent souvent que l’utilisation de ce type de conversion est à bannir, principalement parce qu’il peut résulter silencieusement en un reinterpret_cast<>, qui comme nous l’avons vu, peut se révéler extrêmement dangereux. De plus, l’usage des alternatives modernes aux opérateurs de conversion permet de spécifier clairement l’intention du programmeur et de protéger contre les erreurs involontaires (comme celles que nous avons vu avec const_cast<>).

Une autre utilité

Les “casts” à la C offrent également une possibilité qui n’est permise par aucun autre opérateur de conversion : celle de convertir vers une classe de base au travers d’un héritage privé. Ce type d’héritage est très souvent critiqué et fortement déconseillé. Je ne détaillerai pas ici les conséquences et les raisons de ce type d’héritage; c’est un sujet qui mérite son propre article.

Conclusion

Il y a beaucoup à dire sur les opérateurs de conversion et encore plus à apprendre. Nous avons vu que bien utilisés, ils sont un outil puissant et un allié du programmeur. Protégeant contre les erreurs involontaires et révélant les erreurs de conception, ils restent pour certains dangereux et sont tout de même à utiliser avec la plus grande précaution.

Une bonne connaissance de ces opérateurs de conversion et de leurs limites reste indispensable à la réalisation de programmes maintenables en C++.

Références

Voici une série de liens (en anglais, pour la plupart) qui m’ont inspiré dans la rédaction de cet article.

N’hésitez pas à les consulter pour obtenir d’autres informations. Je vous recommande également de vous inscrire sur Stack Overflow qui est à mon sens le meilleur site de questions/réponses concernant la programmation : le niveau des questions et surtout des réponses y est vraiment très élevé.

Comme toujours bien sûr, vous pouvez également utiliser les commentaires pour obtenir des précisions sur un point ou l’autre.

Merci pour votre lecture !

La directive “inline” démystifiée

7 réponses

Le C++ est sans conteste l’un des langages les plus complets mais aussi les plus complexes existant dans le monde du développement en entreprise. Ses grandes flexibilité et diversité en font à la fois un langage puissant et dangereux. Il ne s’agit pas ici d’en faire une nouvelle présentation; de nombreux ouvrages lui sont déjà consacrés : qu’il s’agisse des “design patterns” ou de fonctionnalités générales, il y en a vraiment pour tous les goûts.

Cependant, j’ai décidé aujourd’hui de traiter d’un point en particulier, souvent mal perçu par les débutants et parfois même par des gens plus expérimentés : il s’agit de la directive inline.

Piqûre de rappel

Avant d’avancer sur le chemin de “l’inlining”, rappelons quelques principes élémentaires du C++.

Remarque : En tant que programmeur expérimenté, vous connaissez probablement déjà tout ce qui suit. Vous devriez tout de même prendre le temps de lire cette partie pour deux raisons : la première, ça ne fait jamais de mal. Et la deuxième : si jamais j’écrivais une bêtise, vous pourriez gentiment me le faire remarquer !

Le C++ est un langage compilé (par opposition à langage interprété), ce qui signifie qu’il induit la génération d’un “binaire” lors d’une phase appelée compilation. Ce binaire peut être un fichier exécutable (.exe sous Windows), une bibliothèque (.so/.a sous Unix, .lib/.dll sous Windows) ou un fichier objet intermédiaire (.o sous Unix, .obj sous Windows).

La phase que l’on nomme “compilation” est en fait séparée en trois étapes successives :

Le prétraitement (ou “preprocessing”), qui va se charger de remplacer les différentes macros présentes dans le code par leur véritable valeur. Le résultat de ce prétraitement est passé au “compilateur”.
La compilation, qui transforme le code pré-traité en langage machine au sein de fichiers objets. En pratique, il y a un fichier objet généré par unité de traduction (ou “translation unit”).
L’édition des liens, qui rassemble les fichiers objets générés au sein d’une seule entité (une bibliothèque dynamique ou un exécutable). Si on a déclaré et utilisé une fonction mais que son implémentation est absente, cette étape ne passe pas.

Remarque : Habituellement, dans le cas d’une bibliothèque statique, l’édition des liens n’est pas effectuée : il s’agit d’une simple concaténation des fichiers objets.

Les bonnes pratiques du C++ dictent ensuite que lorsque l’on écrit le code d’une classe, on place sa définition (et donc sa déclaration) dans un fichier dit “header“, et son implémentation dans un fichier “source“.

Il existe une règle nommée “règle de la définition unique” (ou ODR : “One Definition Rule“) qui dit que l’on peut déclarer autant de fois que l’on veut une classe, une fonction, etc. mais qu’on ne peut la définir qu’une seule fois. Nous verrons plus tard en quoi inline influe à ce niveau.

Un exemple simple

Prenons un exemple tout simple avec une classe “Person” qui représente… une personne.

Voici le fichier header :

/**
 * \file person.hpp
 * \author Julien Kauffmann
 * \brief A person.
 */

#ifndef PERSON_HPP
#define PERSON_HPP

#include <string>

class Person
{
  public:

    /**
     * \brief Create a person given its name.
     * \param name The person name.
     */
    Person(const std::string& name);

    /**
     * \brief Get the name.
     * \return The name.
     */
    const std::string& name() const;

  private:

    /**
     * \brief The name.
     */
    std::string m_name;
};

#endif /* PERSON_HPP */

/**

* \file person.hpp

* \author Julien Kauffmann

* \brief A person.

#ifndef PERSON_HPP

#define PERSON_HPP

#include <string>

class Person

{

public:

/**

* \brief Create a person given its name.

* \param name The person name.

Person(const std::string& name);

/**

* \brief Get the name.

* \return The name.

const std::string& name() const;

private:

/**

* \brief The name.

std::string m_name;

};

#endif /* PERSON_HPP */

Dans ce header, nous avons déclaré et défini le type Person.

Son implémentation, elle, va dans le fichier source :

/**
 * \file person.cpp
 * \author Julien Kauffmann
 * \brief A person.
 */

#include "person.hpp"

Person::Person(const std::string& _name) :
  m_name(_name)
{
}

const std::string& Person::name() const
{
  return m_name;
}

/**

* \file person.cpp

* \author Julien Kauffmann

* \brief A person.

#include "person.hpp"

Person::Person(const std::string& _name) :

m_name(_name)

{

}

const std::string& Person::name() const

{

return m_name;

}

Si nous reprenons les trois étapes de la compilation, voici ce que se passe pour chacun des fichiers :

Le processus commence par le choix de l’unité de traduction à compiler : ici, il s’agit du fichier “person.cpp”.

Le préprocesseur analyse chaque ligne, procède à l’inclusion du fichier “person.hpp” (directive #include) tel qu’on le ferait avec un copier-coller. Au passage, tous les commentaires dans les fichiers sont supprimés, et les éventuelles macros sont remplacées.

On se retrouve avec un fichier qui se rapproche théoriquement de ça :

// J'omets volontairement la définition de std::string qui est *un peu* longue !

class Person
{
  public:
    Person(const std::string& name);
    const std::string& name() const;

  private:
    std::string m_name;
};

Person::Person(const std::string& _name) :
  m_name(_name)
{
}

const std::string& Person::name() const
{
  return m_name;
}

// J'omets volontairement la définition de std::string qui est *un peu* longue !

class Person

{

public:

Person(const std::string& name);

const std::string& name() const;

private:

std::string m_name;

};

Person::Person(const std::string& _name) :

m_name(_name)

{

}

const std::string& Person::name() const

{

return m_name;

}

Le compilateur vérifie la syntaxe de l’ensemble du fichier et compile chaque implémentation de fonction (ou méthode) qu’il rencontre. Ici, les codes du constructeur Person::Person() et du “getter” name() sont effectivement transformés en langage machine au sein d’un fichier objet.
Enfin, si le programme fait référence à Person::Person() ou Person::name(), l’édition des liens associera l’appel de fonction à son adresse effective.

Les idées fausses sur la directive “inline”

S’en suit ici un florilège des idées reçues que j’ai déjà entendu (ou prononcé :D) ça et là sur inline :

“Ça sert à ordonner au compilateur de ne jamais compiler le code de la fonction.”
“C’est quand on écrit directement du code dans la définition d’une classe.”
“C’est pour accélérer les appels à une fonction.”
“Ça sert à déclarer des macros intelligentes.”
“Ça indique que la fonction a une liaison interne.”

En réalité, voici la raison d’être du mot clé inline, telle que définie par Bjarne Stroustrup :

The inline specifier is a hint to the compiler that it should attempt to generate code for a call of the inline function rather than laying down the code for the function once and then calling through the usual function call mechanism.

Pour ceux que l’anglais rebute :

La directive inline est une information donnée au compilateur lui indiquant qu’il devrait essayer de générer du code pour chaque appel de la fonction plutôt que de générer une seule fois le code de façon générique et d’utiliser le mécanisme habituel d’appel de fonction.

En gros, on apprend que la directive inline n’est pas un ordre, mais une simple indication, que le compilateur est d’ailleurs libre de refuser. Souvenez-vous que c’est son travail d’optimiser le code généré, pas le vôtre.

En pratique, on utilisera donc pas inline pour des raisons d’optimisation, mais simplement pour modifier la “One Definition Rule”. En effet, là où une fonction ne doit habituellement avoir qu’une seule définition parmi toutes les unités de traductions, le fait de la rendre inline change la règle et indique que la fonction doit avoir la même définition dans chacune des unités de traduction qui l’utilise.

Un exemple

Prenons pour exemple le célèbre cas de la fonction factorielle.

Remarque : Le choix de cet exemple n’est pas innocent. Bjarne Stroustrup utilise lui-même cet exemple lorsqu’il parle de la directive inline.

Une implémentation naïve de factorielle est la suivante :

inline int factorial(int n)
{
 return (n < 2) ? 1 : n * factorial(n - 1);
}

inline int factorial(int n)

{

return (n < 2) ? 1 : n * factorial(n - 1);

}

Note : Cette fonction n’est pas optimale (on répète inutilement le test “(n <= 1)" à chaque itération. Mais elle convient très bien pour notre exemple.

Supposons que cette fonction est déclarée dans un header de notre bibliothèque et qu’un utilisateur de cette bibliothèque utilise quelque-part dans son code la fonction, par exemple :

int main()
{
  int f = factorial(6);
  std::cout << "Factorial(6) = " << f << std::endl;
  return EXIT_SUCCESS;
}

int main()

{

int f = factorial(6);

std::cout << "Factorial(6) = " << f << std::endl;

return EXIT_SUCCESS;

}

Lors de la compilation de ce code, il peut se passer plusieurs choses :

Le compilateur peut décider de compiler la fonction factorial comme n’importe qu’elle autre fonction. Elle aura en pratique un passage de paramètre, une pile d’appel etc.
Ou il peut décider de remplacer factorial(6) par 6 * factorial(5) directement.
Enfin, un compilateur très intelligent peut carrément décider “d’inliner” complètement l’appel et de remplacer factorial(6) par 720, optimisant de ce fait drastiquement le programme.

On notera que l’appel d’une fonction inline est sémantiquement identique à celle d’une fonction “classique”. Il est possible d’en hériter, de la surcharger, etc.

Utilisation au quotidien

Voici quelques usages corrects de fonctions “inline” :

namespace Foo
{
	class Bar
	{
		public:

			int value() const { return m_value; }

			int add(int a) const;

			template
			T sub(T a)
			{
				return m_value - a;
			}

		private:

			int m_value;
	};

	inline Bar::add(int a) const { return m_value + a; }
}

namespace Foo

{

class Bar

{

public:

int value() const { return m_value; }

int add(int a) const;

template

T sub(T a)

{

return m_value - a;

}

private:

int m_value;

};

inline Bar::add(int a) const { return m_value + a; }

}

Dans le premier cas, la méthode value() est directement définie au sein de la définition de la classe. Elle est implicitement déclarée inline. L’ajout du mot clé inline serait redondant et donc inutile.
Dans le second cas, la méthode add() est simplement déclarée (sans mot clé particulier) au sein de la classe. Sa définition est écrite dans le fichier header, en dehors de celle de la classe, mais toujours dans le même namespace, tel qu’on le ferait si on implémentait cette fonction dans le fichier source. Dans ce cas, la définition de la fonction étant écrite au sein même du fichier header (et donc potentiellement présente dans plusieurs unités de traduction), on doit cependant ajouter le mot clé inline pour s’affranchir de la “One Definition Rule“.
Enfin, dans le dernier cas, la méthode sub n’est pas une vraie méthode mais un template. L’ajout de la directive inline n’est pas obligatoire, car encore une fois, la définition de la méthode se situe dans la définition de la classe. Elle est donc implicitement inline.

N’utilisez inline que sur de très petites fonctions (notion subjective mais en gros : si votre fonction fait plus qu’une simple opération arithmétique ou un retour de valeur, elle n’a surement pas d’intérêt à être inline) et si possible, uniquement sur celles qui ont vocation à être appelées souvent. Les meilleurs candidats pour inline sont généralement bien sûr les getters, les setters, ou encore les destructeurs virtuels vides.

Conclusion

La première fois que l’on m’a parlé du mot clef inline, on me l’a présenté comme un moyen d’optimiser les appels de fonction. Pendant très longtemps, j’ai d’ailleurs soutenu cette version aveuglement. Mais nous avons vu aujourd’hui que les compilateurs sont suffisamment capables pour déterminer d’eux-même quand, quoi et comment optimiser.

En pratique, on retiendra que de bonnes connaissances concernant la “One Definition Rule” et la directive inline sont indispensables à l’écriture d’un code réutilisable et maintenable.

J’espère que cet article vous aura appris quelque-chose (ou à défaut intéressé). N’hésitez pas à me signaler dans les commentaires les éventuelles erreurs que j’aurais pu commettre.

Bon code !

Personnaliser la barre d’action rapide sous Windows Vista/Seven

Laisser une réponse

Aussi longtemps que je me souvienne, j’ai toujours été très intéressé par la personnalisation. Quand je débutais la programmation, mes premiers programmes étaient des alternatives au “shell Windows” (explorer.exe). Évidemment, mes programmes de remplacement étaient pour la plupart encore plus pauvres que ceux à remplacer et ne faisaient généralement pas long feu ! Mais il s’agissait d’un bon exercice.

Aujourd’hui, le shell Windows a bien changé. Il offre nativement sous Vista (et encore plus sous Seven) un bon nombre de raccourcis pour des fonctions utilisées souvent. Toutefois, ses capacités de personnalisation pour un utilisateur lambda restent encore hélas bien limitées.

Dans cet article, je vais vous montrer comment personnaliser la barre d’action rapide pour y ajouter des fonctions “maison”.

La barre d'action modifiée

Le principe

Cette modification n’est pas officiellement supportée par Microsoft (ou en tout cas, je n’ai rien trouvé qui en parlait), mais elle reste relativement propre. En d’autres termes, si c’est pour modifier votre propre poste de travail et pour votre confort personnel, allez-y, mais si vous souhaitez baser une application commerciale dessus, c’est à vos risques et périls !

Le paramétrage de la barre d’action, comme beaucoup d’autres choses sous Windows, se fait par une modification de la base de registre. Si vous n’êtes pas déjà familier avec la base de registre Windows, je vous recommande sincèrement de ne pas continuer.

Chaque “type” de répertoire possède une clé unique associée à un paramétrage. Nous allons modifier les paramètres des dossiers de type “générique” pour que nos nouvelles commandes apparaissent à coté des commandes habituelles.

Les mains dans le camboui

Ouvrez, en tant qu’administrateur, l’éditeur de base de registre (“regedit”).

Placez-vous dans la clé suivante :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderTypes

1	HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderTypes

Puis localisez la clé nommée :

{5c4f28b5-f869-4e84-8e60-f11db97c5cc7}

1	{5c4f28b5-f869-4e84-8e60-f11db97c5cc7}

Il s’agit du GUID associé aux répertoires génériques. Ouvrez cette clé; vous devriez obtenir une fenêtre qui ressemble à ça :

Paramètres pour les dossiers génériques

Si vous n’avez pas de sous-clé nommée “TasksNoItemsSelected” ne vous inquiétez pas, c’est même plutôt normal. Nous allons justement la créer.

Par défaut, la clé sélectionnée a pour propriétaire l’utilisateur système “TrustedInstaller”, utilisé uniquement lors des mises à jour Windows. Pour ajouter nos propres clés, il nous faut nous rendre propriétaire de cette clé, et de ses sous-clés.

Faites un clic droit sur la clé “{5c4f28b5-f869-4e84-8e60-f11db97c5cc7}”, puis choisissez le menu “Autorisations”.

La fenêtre d'autorisations

Cliquez sur “Avancé” puis, dans l’onglet “Propriétaire”, sélectionnez votre compte comme nouveau propriétaire. N’oubliez pas de cocher la case marquée “Remplacer le propriétaire des sous-conteneurs et des objets” puis validez par “OK”.

Une fois devenu propriétaire de la clé, vous pouvez désormais créer des sous-clés.

Un exemple avec Powershell

Nous allons, pour exemple ajouter une action qui lance, dans le répertoire ouvert sous l’explorateur, une commande Powershell correctement positionnée. Cet exemple est bien entendu très facilement adaptable pour d’autres besoins.

Commençons par créer la sous-clé “TasksNoItemsSelected” si elle n’existe pas déjà.

Puis créez une sous-clé nommée ‘0’ pour la première commande que nous ajoutons. Pour les prochaines commandes, il faudra bien entendu remplacer ‘0’ par ‘1’, ‘2’, ‘3’, etc.

Ajoutez toutes les clés requises pour obtenir l’arborescence suivante :

L'arborescence de la commande "Ouvrir Powershell"

Pour ceux qui se demanderaient d’où sort la valeur “{C87DA2BC-C93B-439a-8568-88E93DFD2AB1}”, il s’agit en fait d’un GUID que j’ai généré arbitrairement. Vous pouvez prendre n’importe-quelle autre valeur ici, mais assurez-vous qu’elle ne corresponde pas déjà à un type connu sur le système ! Pour ceux qui ont installé Visual Studio, vous pouvez utiliser l’outil “GUID generator” pour le générer. Pour les autres, vous pouvez vous rendre sur ce site (n’oubliez pas d’ajouter les accolades).

La clé “{C87DA2BC-C93B-439a-8568-88E93DFD2AB1}” doit contenir les valeurs suivantes :

Les valeurs de la clé

Les différentes clés ont les significations suivantes :

La valeur “par défaut” contient le nom système que vous choisissez de donner à votre bouton d’action.
La propriété “Icon” contient le chemin vers la ressource “icône” à associer au bouton.
La propriété “InfoTip” contient le texte qui s’affiche lorsque l’on survole le bouton avec le curseur.
Enfin, la propriété “Title” contient le texte affiché sur le bouton.

Pour terminer, indiquez la commande à exécuter en modifiant la valeur par défaut de la sous-clé “command” :

La commande à exécuter

Ici, nous indiquons la commande suivante :

C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe -NoLogo -NoExit -Command "cd %*"

1	C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe -NoLogo -NoExit -Command "cd %*"

Je ne rentrerai pas dans les détails de cette commande qui sont propres à Powershell, mais soulignerai uniquement la présence du paramètre “%*”.

Je n’ai pas trouvé de liste exhaustive indiquant la liste et la signification des différents paramètres, mais je suis arrivé à la conclusion suivante :

“%*” sera remplacé dans la commande par “tous les paramètres”.
“%2″ sera remplacé par le dossier en cours (celui dans lequel on appuie sur le bouton d’action).

Je vous invite à expérimenter les différents paramètres possibles. Si vous en trouvez d’autres ou des informations sur leur signification, n’hésitez pas à commenter, et je mettrai cet article à jour en conséquence.

Dans tous les cas, ouvrez un navigateur (dans “C:\” par exemple) et vous devriez obtenir le résultat suivant :

Commande "Ouvrir Powershell" personnalisée

N.B : Il est possible que le bouton ne s’affiche pas dans certains répertoires spéciaux comme par exemple “Ma bibliothèque” sous Windows Seven. Je n’ai pas encore trouvé comment résoudre ce problème et pour être franc, je n’ai pas vraiment cherché. Si vous trouvez une solution, n’hésitez pas à vous faire connaître !

Des possibilités multiples

Il ne s’agit que d’un aperçu très bref des possibilités offertes par la personnalisation de la barre d’action. Je suis convaincu que l’on peut aller bien plus loin et que bien d’autres options se cachent ça et là.

En tout cas, cette petite astuce bien pratique m’a déjà servie de nombreuses fois et j’espère que cet article vous aura intéressé. Si l’idée vous tente et que vous êtes amené à le faire de nombreuses fois, vous pouvez également générer un fichier “.reg” pour éviter la saisie manuelle.

En tout cas, bonne personnalisation ! Et n’hésitez pas à partager vos idées !

Découverte de libsystools 2.1

4 réponses

Cette semaine, j’ai eu l’immense honneur d’effectuer la “release” de la version 2.1 de notre bibliothèque de base : libsystools. Cette version est le fruit de nombreuses heures de travail de l’équipe freelan et apporte un bon lot de nouveautés par rapport à la dernière version.

Cet article va tenter de vous faire découvrir ces nouveautés, d’expliquer certaines décisions de design et bien entendu de vous donner envie de l’essayer !

Présentation

Il y a 2 ans, le code de freelan commençait à être volumineux. Bon nombre de classes outils étaient écrites qui pouvaient intéresser d’autres projets. Nous avons donc décidé de rendre cet ensemble de classes autonome et c’est ainsi qu’est né libsystools.

libsystools propose une interface C++ moderne pour un certain nombre de bibliothèques C mais aussi des classes nouvelles (notamment SmartBuffer).

Ses principaux domaines d’application sont :

La gestion du xml (parsing, génération, modification, signature);
la gestion de la cryptographie (RSA, AES, SHA);
la gestion des certificats;
la gestion des ports série;
la gestion du SSL (TLS, DTLS);
la gestion du réseau (Socket, SocketAddress, SocketAddressResolver) en IPv4 et IPv6.
la gestion facilité de la mémoire (SmartBuffer);
une implémentation basique d’un client UPnP;
une implémentation basique d’un client HTTP;
une implémentation simple d’une classe de log;
la gestion de l’encodage (UTF-8, UTF-16, ISO-8859-1, etc.);
différentes méthodes pour calculer de checksum, compresser des flux, etc.

libsystools a été conçue dès le départ pour être extrêmement portable, qu’il s’agisse des systèmes d’exploitation ou des architectures. Elle est donc utilisable sur Windows (MinGW, Visual Studio 2010), Linux (gcc), Mac OSX (gcc), UNIX (gcc) aussi bien en 32 bits qu’en 64 bits.

L’ensemble de ses classes est documenté et différents exemples sont fournis qui traitent de chacun de ses domaines d’application.

libsystools se base sur différentes bibliothèques :

libxml2
libxmlsec1
openssl
libiconv
boost

Faciliter l’existant

Les bibliothèques sur lesquelles se base libsystools sont bien écrites et fiables. Cependant, elles ne fournissent qu’une interface en C.

Lorsqu’on utilise que peu ces bibliothèques dans un projet, il est acceptable de se servir simplement de ces interfaces C. Cependant, lorsqu’un projet en fait un usage intensif, le code devient très rapidement très dur à maintenir.

Qui n’a jamais eu à écrire un code de ce style ?

#include &lt;iostream&gt;

#include &lt;libfoo&gt;

int main()
{
	FOOCONTEXT ctx = CreateFooContext();

	try
	{
		FOOHANDLER handler = CreateFooHandler(ctx);

		try
		{
			// Code
		}
		catch (...)
		{
			FreeFooHandler(handler);

			throw;
		}

		FreeFooHandler(handler);
	}
	catch (...)
	{
		FreeFooContext(ctx);

		throw;
	}

	FreeFooContext(ctx);

	return EXIT_SUCCESS;
}

#include <iostream>

#include <libfoo>

int main()

{

FOOCONTEXT ctx = CreateFooContext();

try

{

FOOHANDLER handler = CreateFooHandler(ctx);

try

{

// Code

}

catch (...)

{

FreeFooHandler(handler);

throw;

}

FreeFooHandler(handler);

}

catch (...)

{

FreeFooContext(ctx);

throw;

}

FreeFooContext(ctx);

return EXIT_SUCCESS;

}

Bien sûr, un bon programmeur C++ simplifiera l’écriture de ce genre de code avec l’utilisation de classes conteneurs qui se chargent de libérer la ressource associée lors de leur destruction. Mais devoir refaire ce travail d’encapsulation à chaque utilisation est fastidieux, et ne règle qu’une partie du problème.

C’est dans cet esprit qu’on été développées les classes de libsystools : des wrappers simples, faciles à utiliser et efficaces.

En utilisant libsystools, le code précédent aurait plutôt ressemblé à :

#include &lt;iostream&gt;

#include &lt;libfoo&gt;

int main()
{
	FooContext ctx;
	FooHandler handler(ctx);

	// Code

	return EXIT_SUCCESS;
}

#include <iostream>

#include <libfoo>

int main()

{

FooContext ctx;

FooHandler handler(ctx);

// Code

return EXIT_SUCCESS;

}

Ce qui est bien plus lisible et maintenable, et présente l’avantage d’être “exception-safe”.

Utilisation & Exemples

Nous pourrions exposer les différents aspects conceptuels qui ont motivé chaque décision pendant des heures et sur plusieurs pages, mais après tout, en programmation, il n’y a pas plus explicite que le code. Voici donc quelques exemples d’utilisation commentés.

SmartBuffer, ou comment gérer la mémoire de façon intelligente

S’il ne fallait garder qu’une seule classe, ce serait celle-ci : SmartBuffer est au coeur de libsystools. Utilisée partout, SmartBuffer représente un tableau d’octets à taille variable et dont les différentes instances peuvent partager leur mémoire.

#include &lt;iostream&gt;

#include &lt;systools/smartbuffer.hpp&gt;

int main()
{
	using systools::SmartBuffer;

	// On crée un buffer à partir d'une chaîne C
	SmartBuffer buffer("Hello you");

	// On copie un buffer
	SmartBuffer copy = buffer; // copy et buffer partagent la même mémoire.

	// On réduit copy
	copy.resize(6); // copy a juste été réduit, copy et buffer partagent toujours la même mémoire.

	copy.append("me"); // copy a été modifié, copy et buffer ne partagent plus la même mémoire.

	// On affiche les résultats
	std::cout &lt;&lt; "buffer: " &lt;&lt; buffer.toStdString() &lt;&lt; std::endl; // buffer: Hello you
	std::cout &lt;&lt; "copy: " &lt;&lt; copy.toStdString() &lt;&lt; std::endl; // copy: Hello me

	return EXIT_SUCCESS;
}

// On peut utiliser un SmartBuffer comme valeur de retour de fonction
systools::SmartBuffer getBuffer()
{
	// La méthode-patron "factory" SmartBuffer::from permet de créer un buffer à partir de n'importe quel type.
	return systools::SmartBuffer::from&lt;int&gt;(4);
}

#include <iostream>

#include <systools/smartbuffer.hpp>

int main()

{

using systools::SmartBuffer;

// On crée un buffer à partir d'une chaîne C

SmartBuffer buffer("Hello you");

// On copie un buffer

SmartBuffer copy = buffer; // copy et buffer partagent la même mémoire.

// On réduit copy

copy.resize(6); // copy a juste été réduit, copy et buffer partagent toujours la même mémoire.

copy.append("me"); // copy a été modifié, copy et buffer ne partagent plus la même mémoire.

// On affiche les résultats

std::cout << "buffer: " << buffer.toStdString() << std::endl; // buffer: Hello you

std::cout << "copy: " << copy.toStdString() << std::endl; // copy: Hello me

return EXIT_SUCCESS;

}

// On peut utiliser un SmartBuffer comme valeur de retour de fonction

systools::SmartBuffer getBuffer()

{

// La méthode-patron "factory" SmartBuffer::from permet de créer un buffer à partir de n'importe quel type.

return systools::SmartBuffer::from<int>(4);

}

Dans bon nombre de cas, l’utilisation de SmartBuffer permet de simplifier le code existant en remplaçant les paramètres de type :

void fonction(const char* inbuf, size_t inbuflen, char** outbuf, size_t&amp; outbuflen);

1	void fonction(const char* inbuf, size_t inbuflen, char** outbuf, size_t& outbuflen);

Par un simple :

SmartBuffer fonction(const SmartBuffer&amp; inbuf);

1	SmartBuffer fonction(const SmartBuffer& inbuf);

La lecture et la maintenance s’en trouvent tous deux grandement facilités.

XML, les wrappers autour de libxml2

Avec l’engouement de tous les domaines pour le web, il est rare aujourd’hui d’avoir du code à produire qui ne nécessite pas de manipuler du XML. En C++, plusieurs solutions existent.

Nous avons opté pour la libxml2 pour plusieurs raisons :

C’est une bibliothèque mature, complète et quotidiennement maintenue;
elle est portable sur plusieurs architectures et plateformes;
elle s’interface très bien avec OpenSSL au sein de libxmlsec1 pour le support des signatures XML.

Le module XML de libsystools se décompose en trois parties :

Les éléments DOM, qui représentent de façon statique un arbre XML;
les “writers” qui permettent de générer du XML;
les objets XPath, qui permettent d’effectuer des requêtes dans les éléments DOM.

Voyons un exemple d’utilisation :

#include &lt;iostream&gt;
#include &lt;cstdlib&gt;
#include &lt;cstring&gt;

#include &lt;boost/shared_ptr.hpp&gt;
#include &lt;boost/foreach.hpp&gt;

#include &lt;systools/xml.hpp&gt;
#include &lt;systools/xml_document.hpp&gt;
#include &lt;systools/xml_node.hpp&gt;
#include &lt;systools/xml_xpath.hpp&gt;
#include &lt;systools/xml_buffer_writer.hpp&gt;
#include &lt;systools/xml_document_writer.hpp&gt;

int main(int, char**)
{
	using namespace systools;

	// Initialization
	xml::Initializer xml;

	std::cout &lt;&lt; "Initializing...: " &lt;&lt; "OK" &lt;&lt; std::endl;

	try
	{
		// Generation

		xml::XmlDocumentWriter writer;

		writer.startDocument();
		writer.startElement("configuration");
		writer.writeAttribute("xmlns", "namespace");
		writer.writeElement("key", "value");
		writer.startElement("parent");
		writer.writeElement("child", "anna");
		writer.writeElement("child", "bobby");
		writer.endElement();
		writer.endDocument();

		xml::XmlDocument document = writer.getResultAsDocument();
		std::cout &lt;&lt; "Generating XML document: " &lt;&lt; "OK" &lt;&lt; std::endl;
		std::cout &lt;&lt; document.toString().toStdString() &lt;&lt; std::endl;

		// XPath

		xml::XPath xpath = document.xpath();

		if (!xpath.registerNamespace("fl", "namespace"))
		{
			std::cerr &lt;&lt; "Warning ! Failed to register the namespace !" &lt;&lt; std::endl;
		}

		std::list&lt;xml::XmlNode&gt; list = document.xpath().evaluate("/fl:configuration/fl:parent");

		if (list.size() &gt; 0)
		{
			list = list.front().xpath().evaluate("fl:child");

			std::cout &lt;&lt; "Results:" &lt;&lt; std::endl;

			BOOST_FOREACH(const xml::XmlNode&amp; node, list)
			{
				std::cout &lt;&lt; node.name().toStdString() &lt;&lt; ": " &lt;&lt; node.content().toStdString() &lt;&lt; std::endl;
			}
		}
	}
	catch (Exception&amp; ex)
	{
		std::cout &lt;&lt; "Exception caught: " &lt;&lt; ex.toString() &lt;&lt; std::endl;
	}

	return EXIT_SUCCESS;
}

#include <iostream>

#include <cstdlib>

#include <cstring>

#include <boost/shared_ptr.hpp>

#include <boost/foreach.hpp>

#include <systools/xml.hpp>

#include <systools/xml_document.hpp>

#include <systools/xml_node.hpp>

#include <systools/xml_xpath.hpp>

#include <systools/xml_buffer_writer.hpp>

#include <systools/xml_document_writer.hpp>

int main(int, char**)

{

using namespace systools;

// Initialization

xml::Initializer xml;

std::cout << "Initializing...: " << "OK" << std::endl;

try

{

// Generation

xml::XmlDocumentWriter writer;

writer.startDocument();

writer.startElement("configuration");

writer.writeAttribute("xmlns", "namespace");

writer.writeElement("key", "value");

writer.startElement("parent");

writer.writeElement("child", "anna");

writer.writeElement("child", "bobby");

writer.endElement();

writer.endDocument();

xml::XmlDocument document = writer.getResultAsDocument();

std::cout << "Generating XML document: " << "OK" << std::endl;

std::cout << document.toString().toStdString() << std::endl;

// XPath

xml::XPath xpath = document.xpath();

if (!xpath.registerNamespace("fl", "namespace"))

{

std::cerr << "Warning ! Failed to register the namespace !" << std::endl;

}

std::list<xml::XmlNode> list = document.xpath().evaluate("/fl:configuration/fl:parent");

if (list.size() > 0)

{

list = list.front().xpath().evaluate("fl:child");

std::cout << "Results:" << std::endl;

BOOST_FOREACH(const xml::XmlNode& node, list)

{

std::cout << node.name().toStdString() << ": " << node.content().toStdString() << std::endl;

}

catch (Exception& ex)

{

std::cout << "Exception caught: " << ex.toString() << std::endl;

}

return EXIT_SUCCESS;

}

Reprenons cet exemple point par point :

Ligne 20 : nous déclarons un xml::Initializer qui existera pour toute la portée du main. Cet objet permet d’initialiser la libxml2 et de garantir sa libération au moment opportun, de façon automatique.
Ligne 28 : nous créons un XmlDocumentWriter. Cet objet permet une construction facilité d’un arbre XML en construisant l’un après l’autre ses différents éléments.
Lignes 30 à 38 : Nous créons chacun des noeuds XML. Les différentes fonctions prennent des systools::String en paramètre et supportent donc parfaitement la gestion des différents encodages.
Ligne 40 : Nous récupérons un arbre XML complet à partir du writer.
Ligne 46 : Nous récupérons l’instance XPath associé à l’arbre XML (cette instance est partagée par tous les noeuds d’un même arbre)
Ligne 48 : Nous associons un nom court au namespace nommé “namespace” dans l’instance XPath.
Ligne 53 : Nous effectuons une requête XPath sur la racine du document.
Ligne 57 : Nous effectuons une requête XPath sur un sous-noeud du document.

La manipulation du XML est grandement facilitée. On voit que seules quelques instructions suffisent à construire un arbre, à y naviguer et à en extraire les informations utiles.

Le module réseau

Une autre partie importante de libsystools est son module réseau. La manipulation des différentes fonctions et structures réseau d’un système a toujours été la bête noire des programmeurs novices. Entre les spécificités propres à chaque système d’exploitation, et les fonctions dépréciées suite au prochain passage à IPv6 (ça approche, si si, croyez-moi !), il n’est pas toujours évident de produire un code propre et robuste.

Le module réseau de libsystools a été conçu pour résoudre cette problématique. Il propose :

Une classe qui permet représenter une adresse de socket (IPv4, IPv6, etc.);
une classe pour effectuer des résolutions de nom ou d’adresse sur le réseau;
des classes Socket et SecureSocket qui encapsulent respectivement une socket classique et une socket SSL (en TLS ou DTLS);
une classe “Select” qui encapsule de façon objet les appels à la méthode “select()”;
une classe pour représenter les adresses Ethernet;
des outils de conversion entre adresse IP et représentation numérique.

Démontrons la simplicité de son utilisation en montrant le code d’un example qui va successivement :

Chercher l’adresse de socket associée à 127.0.0.1:34000 en TCP.
Créer une socket
Connecter cette socket sur le serveur TCP situé à l’adresse recherchée en 1.
Attendre la réception d’un message.
Se déconnecter et libérer la socket et toutes les ressources associées.

#include &lt;iostream&gt;
#include &lt;cstdlib&gt;
#include &lt;cstring&gt;
#include &lt;string&gt;

#include &lt;list&gt;

#include &lt;systools/network.hpp&gt;
#include &lt;systools/socket.hpp&gt;
#include &lt;systools/socket_address.hpp&gt;
#include &lt;systools/socket_address_resolver.hpp&gt;

int main(int, char**)
{
	using namespace systools;

	network::Initializer network;

	SocketAddressResolver sar;

	try
	{
		sar.getAddrInfo("127.0.0.1", "34000", IPPROTO_TCP, AF_UNSPEC);

		if (sar.size() &lt;= 0)
		{
			std::cout &lt;&lt; "No address information was returned." &lt;&lt; std::endl;
		} else
		{
			// Usually, one could choose to iterate trough the results and to keep only the first one to which a connection can be established.
			Socket socket(sar.front());
			SocketAddress address(sar.front());

			std::cout &lt;&lt; "Connecting to: " &lt;&lt; address.toNumericString() &lt;&lt; std::endl;

			socket.connect(address);

			SmartBuffer message;

			size_t recv_bytes = socket.recv(message);

			if (recv_bytes &gt; 0)
			{
				std::cout &lt;&lt; "Receiving message: " &lt;&lt; std::string(message.constData(), message.size()) &lt;&lt; std::endl;
			}
		}
	}
	catch (Exception&amp; ex)
	{
		std::cout &lt;&lt; "Exception: " &lt;&lt; ex.toString() &lt;&lt; std::endl;

		return EXIT_FAILURE;
	}

	return EXIT_SUCCESS;
}

#include <iostream>

#include <cstdlib>

#include <cstring>

#include <string>

#include <list>

#include <systools/network.hpp>

#include <systools/socket.hpp>

#include <systools/socket_address.hpp>

#include <systools/socket_address_resolver.hpp>

int main(int, char**)

{

using namespace systools;

network::Initializer network;

SocketAddressResolver sar;

try

{

sar.getAddrInfo("127.0.0.1", "34000", IPPROTO_TCP, AF_UNSPEC);

if (sar.size() <= 0)

{

std::cout << "No address information was returned." << std::endl;

} else

{

// Usually, one could choose to iterate trough the results and to keep only the first one to which a connection can be established.

Socket socket(sar.front());

SocketAddress address(sar.front());

std::cout << "Connecting to: " << address.toNumericString() << std::endl;

socket.connect(address);

SmartBuffer message;

size_t recv_bytes = socket.recv(message);

if (recv_bytes > 0)

{

std::cout << "Receiving message: " << std::string(message.constData(), message.size()) << std::endl;

}

catch (Exception& ex)

{

std::cout << "Exception: " << ex.toString() << std::endl;

return EXIT_FAILURE;

}

return EXIT_SUCCESS;

}

Pas si mal pour un code d’une cinquantaine de lignes qui gère correctement toutes les erreurs potentielles et la libération des ressources, non ?

Pour conclure

Vous n’avez eu ici qu’un très bref aperçu des possibilités offertes par la libsystools. Pour découvrir plus avant la bibliothèque, je vous invite à consulter sa documentation en ligne.

En tout cas, j’espère sincèrement que cette présentation aura attisé votre curiosité et vous aura donné envie d’essayer la bibliothèque lors de vos prochains développements. Bien entendu, si vous avez des questions générales sur la bibliothèque et des interrogations concernant son évolution future, n’hésitez pas à commenter cet article ou directement contacter l’équipe sur la mailing-list (en anglais).

Bon code !

Développer avec Qt pour Android

10 réponses

C’est possible ?

Dans ce petit article je vais vous parler du développement Android avec Qt et en C++, en effet, j’ai travaillé dernièrement dans une entreprise d’automatisation et de régulation des bâtiments où un des développeurs était en charge d’un projet d’application Android. La qualité de ses développements m’a donné envie de tenter l’aventure. Malgré la magnifique API de Java pour android je voulais pouvoir déployer pour Windows, Linux, Mac, Symbian et Android la même application. Mon choix se portait donc sur mon framework préféré : Qt et naturellement mon langage préféré. Je ne serai jamais assez redevant à Bjarne Stroustrup =D.

Développer des applications basées sur Qt pour android est possible via le projet android-lighthouse, qui fonctionne très bien ! En effet ce dernier rend possible l’exécution d’une application C++/Qt complète ou encore l’utilisation en Java des libraires écrites avec le framework.

Lighthouse

Quant à lighthouse c’est un projet que l’équipe du Framework Qt a lancé avant la version 4.7 pour rendre le framework Qt portable à n’importe quelle plateforme facilement. En effet cela requiert très peu de code spécifique à la plateforme afin de faire fonctionner toutes les librairies Qt.

Depuis quelques semaines lighthouse est passé dans la branche stable de Qt. Grâce à android-lighthouse on peut d’ailleurs voir que le portage des bibliothèques est très rapide. Seulement quelques mois ont été nécessaires pour obtenir une version pleinement (ou presque) fonctionnelle: même les interfaces basées sur le QML fonctionnent! C’est grâce à BogDan Vatra, initiateur du projet, que le port de Qt pour android en est arrivé à cette maturité qui démontre ainsi que Qt peut être porté n’importe où: Code less, do more, deploy everywhere!

Awesome!

Cela rend le portage d’applications Qt sur Android très simple, écrire une application avec le framework Qt signifie que l’on peut désormais la compiler sans effort pour : Symbian, Windows, Mac, Linux & Android ! C’est à mon sens parfait pour construire une base de librairies réutilisables dans une entreprise. Dans cette idée il est également possible de développer des bibliothèques basées sur les fonctionnalités de Qt et de les lier avec JNI afin d’apporter des fonctionnalités natives aux applications Java Android existantes.

Je vous présenterai dans cet article les différentes versions d’Android supportées, les quelques limitations et clarifications nécessaires, ainsi que les procédures à suivre afin de compiler pour et lancer sur Android votre application Qt.

Les versions d’Android compatibles

Lorsque le projet Qt android-lighthouse a été créé, seuls les périphériques Android 1.5 étaient supportés avec Qt lié en statique, ce qui n’est plus le cas aujourd’hui. En effet la branche actuelle du dépôt supporte seulement Qt lié dynamiquement (cela réduit l’utilisation de la mémoire – James Noble & Charles Weir 2001 – Small Memory Software, puisque chacune des applications partagent les mêmes bibliothèques Qt). Cette dernière supporte aujourd’hui les versions d’Android actuelles du marché: 1.6, 2.0, 2.1 et 2.2. N’hésitez pas à essayer avec l’émulateur Android car il fonctionne comme les véritables périphériques, plus d’un développeur Android m’en a confirmé ses qualités.

Quelques Limitations

Il y a actuellement (25/11/2010) quelques limitations, par exemple le rendu est réalisé uniquement par le software, les accélérations matérielles Open GL ne sont pas utilisées. Toutefois ce n’est certainement qu’une question de jours, car jusqu’aujourd’hui le portage de Qt sur Android a été très rapide et est toujours aussi actif.

Une autre limitation qui sera bientôt fixée d’après les initiateurs du projet est que l’on ne peut utiliser QtMultimedia pour jouer des sons, il y a d’autres solutions pour y parvenir, toutefois le port de QtMultimedia sera bientôt fait, et d’après l’initiateur du projet cela devrait être “le correctif le plus facile” qu’il lui reste à faire.

Quelques Clarifications

Vous n’avez pas besoin d’être “root” ou d’avoir accès au shell root sur votre périphérique pour déployer des applications Qt, cela signifie que vous pourriez envoyer l’application sur le Google Market. Toutefois actuellement il est plutôt déconseillé de le faire, il vaudrait mieux attendre que cela soit plus testé et utilisé (ce que fait actuellement une communauté grandissante: http://groups.google.com/group/android-qt/).

Préparez votre environnement de développement

J’ai écrit les instructions suivantes en m’inspirant de la page http://code.google.com/p/android-lighthouse/wiki/Compile et de ma propre expérience sur Linux 32 bits. Si vous êtes sur Windows vous devriez jeter un oeil au problème suivant: Configure does not work with Cygwin on winxp et appliquer le patch pour cygwin qui est proposé dans l’une des réponses. Enfin si vous êtes sur Mac OS X vous devriez simplement oublier pour le moment (ou bien trouver une solution :p): broken build on mac osx – x86.

Linux semble être la meilleure plateforme pour développer avec Qt pour android actuellement, donc si vous n’utilisez pas cette plateforme, je vous conseille d’essayer avec une Machine Virtuelle, du moins c’est la solution dont je peux vous en assurer le fonctionnement.

Actuellement quelques éléments dits sur la page officielle traitant de la compilation de Qt et d’applications Qt pour android ne sont pas vraies, c’est pourquoi je vais vous guider dans la bonne direction pour faire fonctionner votre application Qt sur android, tel que Francisco Dalla Rosa Soares m’a montré cette semaine sur la mailing list d’android-lighthouse. Sans lui je n’aurai jamais pu lancer quoi que ce soit, si ce n’est mon pc portable…

Téléchargement

Avant tout il vous faut télécharger et décompresser QADK, qui est un Kit de Développement natif non officiel pour android, basé sur l’officiel mais avec quelques bibliothèques non supportées en plus:

wget http://android-lighthouse.googlecode.com/files/qadk-r4-1.tar.bz2
tar xf qadk-r4-1.tar.bz2 .

1 2	wget http://android-lighthouse.googlecode.com/files/qadk-r4-1.tar.bz2 tar xf qadk-r4-1.tar.bz2 .

Après cela il vous faudra cloner le repository git de android-lighthouse qui lui même consiste en un clone du projet Qt lighthouse qui est officiellement fourni par Nokia:

git clone git://gitorious.org/~taipan/qt/android-lighthouse.git

1	git clone git://gitorious.org/~taipan/qt/android-lighthouse.git

Configurer & Compiler

Vous devrez compiler Qt pour la plateforme visée, il est nécessaire de définir la variable ANDROID_PLATFORM et de faire pointer NDK_ROOT vers le dossier où vous avez décompressé QADK.

mkspecs/android-g++/qmake.conf:12 -&gt;
NDK_ROOT = /path/to/qadk-r4

1 2	mkspecs/android-g++/qmake.conf:12 -> NDK_ROOT = /path/to/qadk-r4

mkspecs/android-g++/qmake.conf:18 -&gt;
ANDROID_PLATFORM = android-5

1 2	mkspecs/android-g++/qmake.conf:18 -> ANDROID_PLATFORM = android-5

La dernière ligne est présente pour cibler les plateformes android 2.0 & 2.1, ce qui fonctionna sans problèmes pour ma part. Utilisez android-4 afin de cibler les plateformes 1.6 et android-8 pour cibler les plateformes 2.2.

Vous pouvez désormais lancer la partie de configuration (n’hésitez pas à aller voir votre petite amie pendant ce temps):

./androidconfig.sh

1	./androidconfig.sh

Et enfin vous pouvez compiler le tout:

make -j3

make -j3

Changez 3 par le nombre de coeur de votre processeur + un, cela activera la compilation parallèle avec autant de processus.

Il y a une dépendance de Qt qui n’est pas incluse au projet, c’est libcloog-ppl-dev, lancez simplement:

sudo apt-get install libcloog-ppl-dev

1	sudo apt-get install libcloog-ppl-dev

Pour ce que j’ai pu comprendre c’est une librarie utilisée pour l’optimisation de code, qui est destinée à générer du code permettant de passer sur chacun des points d’un Polyèdre. Je suppose que c’est utilisé dans qmake, mais je ne pourrai vous l’assurer. Plus de détails et un exemple sur le site officiel.

Installez Qt sur le Périphérique

Maintenant ce serait sympa d’avoir Qt sur le périphérique Android (ou dans l’émulateur), pour ce faire faites simplement ce que la page de wiki de google code conseille:

mkdir andlibs
cp -a lib/*.so* andlibs/
adb push andlibs /data/local/qt/lib

mkdir andlibs

cp -a lib/*.so* andlibs/

adb push andlibs /data/local/qt/lib

Connectez votre Périphérique

Si vous recevez l’erreur adb: command not found, c’est parce que vous êtes nouveau au développement Android (tout comme moi). Vous devez simplement télécharger le dernier sdk d’Android, vous pouvez trouver les instructions détaillées ici et le sdk ici.

Cependant à cette étape de l’article vous avez simplement besoin de télécharger le SDK, de définir le PATH et d’éxécuter:

tools/android update sdk

1	tools/android update sdk

Ensuite si vous voulez essayer sur votre véritable téléphone vous devrez activer la connexion avec ce dernier, pour y parvenir je vous invite à suivre la petite partie décrite sur le site d’android.

Je suis sur Linux, donc j’ai simplement mis en place la configuration suivante pour mon téléphone LGGT540 sur android 2.1. Sur mon pc avec Ubuntu 10.10 j’ai défini les informations suivantes dans le fichier /etc/udev/rules.d/51-android.rules:
Les fichiers présents dans /etc/udev/rules.d/ sont destinés à définir des règles persistantes pour les périphériques, dont l’une est de changer le CHMOD d’accès à un périphérique, en fonction d’éléments permettant de l’identifier.

SUBSYSTEM=="usb", SYSFS{idVendor}=="1004", MODE="0666"
SUBSYSTEM=="usb_device", SYSFS{idVendor}=="1004", MODE="0666"

1 2	SUBSYSTEM=="usb", SYSFS{idVendor}=="1004", MODE="0666" SUBSYSTEM=="usb_device", SYSFS{idVendor}=="1004", MODE="0666"

Où 1004 vient d’une liste fournie de Vendor Ids pour les périphériques android: http://developer.android.com/guide/developing/device.html#VendorIds/. Prenez celui qui convient.

Sur Windows il vous faudra simplement installer les pilotes adb, et sur Mac OS X cela fonctionne sans rien faire, toutefois rappelez vous que android-lighthouse pour Mac OS X ne semble pas fonctionner.

Pour lister les périphériques Android existants vous pouvez lancer: adb devices.

Votre première Application Qt pour Android

Nous n’allons pas écrire notre propre code (oui je sais c’est triste), parce qu’il y a beaucoup de Hello World-like dans les demos du Qt Sdk. Nous allons donc choisir un très simple, afin d’expliquer les choses qui nous intéressent: la configuration de la compilation et comment créer un projet java afin de lancer l’application.

En effet contrairement aux dires du site officiel il n’est pas possible actuellement de compiler directement l’application en temps qu’exécutable natif. Il est nécessaire de la compiler en une bibliothèque dynamique, que l’on chargera à l’aide d’un petit launcher java basé sur les classes fournies par android-lighthouse. Ces dernières sont présentes dans le package com.nokia.qt.QtActivity.

Maintenant allez dans le répertoire /android-lighthouse/demos/mainwindow/, ici vous pouvez ouvrir le fichier mainwindow.pro, qui devrait contenir les configurations suivantes:

TEMPLATE = lib
CONFIG += dll

HEADERS += colorswatch.h mainwindow.h toolbar.h
SOURCES += colorswatch.cpp mainwindow.cpp toolbar.cpp main.cpp

TEMPLATE = lib

CONFIG += dll

HEADERS += colorswatch.h mainwindow.h toolbar.h

SOURCES += colorswatch.cpp mainwindow.cpp toolbar.cpp main.cpp

Il est réellement important de compiler l’application en tant que bibliothèque dynamique, ainsi pour vos prochaines applications n’oubliez pas d’utiliser les deux premières lignes données ci-dessus. Personnellement j’ai une préférence pour CMake, mais je n’ai pas encore pu préparer de configuration pour android pour le moment, et pourtant cela devrait seulement consister à éditer la méthode qt4_wrap_cpp pour lui donner la version android-lightouse spécialisée de qmake.

En effet pour compiler l’application, il faut utilisez android-lighthouse/bin/qmake afin de générer les fichiers de moc et le Makefile, et non pas la version de qmake que vous avez dans votre PATH.

/path/to/android-lighthouse/bin/qmake
make -j3

1 2	/path/to/android-lighthouse/bin/qmake make -j3

Voilà, vous ne devez même pas adapter le code de votre application Qt. Le résultat des commandes que vous avez lancées devrait être un fichier so (shared object) avec différents liens symboliques afin de rendre possible la compatibilité entre versions apportée par libtool.

Envoyez simplement celle sans informations de compatibilité de versions sur votre périphérique android: adb push libmainwindow.so /data/local/qt/lib. Une fois que vous avez fait cela, l’application est sur le téléphone, mais rien n’existe pour la lancer.

Créez le Projet Android

Nous allons ainsi créer un launcher en java, basé sur le launcher fourni par le projet android-lighthouse, qui s’occupe tout seul des bindings JNI nécessaires.

Tout d’abord créez un projet dans un sous-dossier (javaLoader par exemple)

android create project --target 2.1 \
			--name mainwindow \
			--path ./ \
			--activity mainwindow \
			--package com.yourcompany.mainwindow

android create project --target 2.1 \

--name mainwindow \

--path ./ \

--activity mainwindow \

--package com.yourcompany.mainwindow

Créez une classe QtMain.java (vim seul ou avec eclim est un bon outil pour cela):

package org.yourcompany.mainwindow;

	import com.nokia.qt.QtActivity;

	public class QtMain extends QtActivity
	{
		public QtMain()
		{
			/* setLibraries(libraries);
			    This could be useful for you if you need to load
			    some other libraries with your application.
			*/
			setApplication("mainwindow");
		}
	}

package org.yourcompany.mainwindow;

import com.nokia.qt.QtActivity;

public class QtMain extends QtActivity

{

public QtMain()

{

/* setLibraries(libraries);

This could be useful for you if you need to load

some other libraries with your application.

setApplication("mainwindow");

}

Et ensuite tapez simplement:

ant debug
cd bin
adb install mainwindow-debug.apk

ant debug

cd bin

adb install mainwindow-debug.apk

Votre application est installée, et peut facilement être lancée sur votre périphérique à l’aide de:

adb shell am start -a android.intent.action.MAIN -n com.yourcompany.mainwindow/.mainwindow

1	adb shell am start -a android.intent.action.MAIN -n com.yourcompany.mainwindow/.mainwindow

À propos du débogage

Pour le moment je n’ai hélas pas réussi à déboguer l’application sur le périphérique, mais les sorties consoles sont redirigées, il est donc tout de même possible d’utiliser qDebug pour faire le débogage. Ce n’est pas optimal mais ce n’est qu’en attendant de trouver un moyen simple. Je pense néanmoins que l’outil qadk-r4/ndk-gdb peut rendre le débogage possible, je n’ai pas réussi cependant à faire quoi que ce soit pour l’instant à ce sujet. Je posterai dès que j’y parviendrai.

Qt Creator

Apparemment l’intégration d’Android pour Qt Creator est très avancée mais pas encore dans le dépôtd’après un mail de Tero Savolainen arrivé au moment de poster l’article, sur la liste de diffusion nommé “Re: Qt porting status and some great news” l’intégration de Qt Creator avec Androïd est faite et le débogage est la prochaine fonctionnalité à venir.

Conclusion

Comme vous avez pu le voir il devient très simple de développer nativement pour Android, le projet étant très actif, il y a fort à parier que pour fin décembre les limitations citées devraient avoir disparues et que le débogage soit possible.

Merci beaucoup pour votre lecture, je suis ouvert à toutes vos suggestions et remarques concernant cet l’article.

WindowsPager ou comment rendre son Windows un peu plus agréable

Laisser une réponse

S’il est bien une chose que l’on peut regretter lorsque l’on passe de Linux à Windows, c’est bien l’absence de bureaux virtuels. Aujourd’hui, et grâce à un ami (merci Fabien), cette absence est palliée !

Présentation

La solution miracle se nomme WindowsPager. Ce logiciel léger et configurable permet de simuler la présence de plusieurs bureaux virtuels et a le bon goût d’être gratuit et open-source (sous GPL).

Il se présente sous la forme d’un exécutable et d’un fichier de configuration au format INI et n’occupe de plus que très peu de mémoire.

J’avais déjà essayé pas mal d’émulateurs de bureau virtuel, mais je crois que j’ai finalement trouvé le bon.

WindowsPager est le seul que j’ai trouvé qui réponde à tous ces critères :

Intégration esthétique : un aperçu des bureaux est affiché en grand dans la barre des taches. Fini les petits icônes dans la zone de notification.
Légèreté : Une fois lancé, et avec 4 bureaux virtuels, celui n’occupe chez moi que 900 Ko de mémoire.
Réactivité : Même avec le CPU occupé à 100% (lors d’une grosse compilation par exemple), le changement de bureau se fait avec une vitesse époustouflante.
Disponibilité en x86 et x64 : Ok, ce n’est pas obligatoire, mais quand on voit que le développeur a fait l’effort de produire un code propre qui compile sans problème pour les deux architectures, ça inspire davantage la confiance.

WindowsPager qui s'intègre très bien dans Windows Seven.

Pour ceux à qui il prendrait l’envie de l’essayer, ça se télécharge ici.

Je ne l’utilise que depuis une journée, mais je sens déjà que ça va me changer la vie !

Développer pour Android sans utiliser Eclipse

14 réponses

Il y a quelques jours, j’ai découvert le développement Android et Eclipse par la même occasion. Ayant abandonné il y a longtemps les IDE, j’ai tout de même décidé de sauter le pas histoire de ne pas mourir idiot.

Il faut le reconnaître, l’intégration Android dans Eclipse est très bien pensée et plutôt efficace : auto-complètement, assistants à tout va, débogueur, etc. Seulement voilà, il faut se rendre à l’évidence : quand on est habitué à Vim, l’éditeur de texte d’Eclipse fait plutôt pâle figure. Et en y réfléchissant bien, l’essentiel du développement Android reste l’écriture de code toute bête ou la modification de fichiers XML : pourquoi ne pourrait-on pas simplement utiliser une console et l’éditeur de texte de notre choix ?

Voici donc ce que propose ce tutorial : l’installation d’un environnement de développement simplifié pour Android.

Prérequis

Avant de poursuivre ce tutorial, vérifiez que vous :

Êtes habitué au développement “console”. Si vous n’avez jamais utilisé que des IDE, je ne peux que trop vous conseiller de rester dans cet environnement. Le développement Android en console n’est pas recommandé par Google et de plus beaucoup moins facile d’accès que pour d’autres langages (C, C++).
Savez ajouter/modifier/supprimer des variables d’environnement.
Avez téléchargé et installé le Android SDK. Si vous ne connaissez pas la marche à suivre, elle est indiquée dans cet article.
Êtes prêt à passer pour un fanatique auprès de vos amis qui utilisent un IDE.

Si vous remplissez toutes ces conditions, c’est parti !

Développons en Java

On a beau se passer d’Eclipse, on ne peut évidement se passer d’utiliser Java.

Commencez par télécharger le kit de développement Java (JDK) pour votre système d’exploitation, puis installez-le.

Pour ma part, j’ai choisi le chemin d’installation par défaut, c’est à dire “C:\Program Files\Java” sur mon Windows Seven 64 bits.

On se retrouve avec les deux répertoires suivants :

Répertoires Java

La dernière étape concernant Java, consiste à ajouter le sous-répertoire “C:\Program Files\Java\jdk1.6.0_22\bin” au PATH de l’environnement.

Ouvrez une fenêtre console et saisissez la commande suivante :

javac

javac

Si vous obtenez la sortie suivante :

C:\Users\Julien&gt;javac
Usage: javac &lt;options&gt; &lt;source files&gt;
where possible options include:
 -g                         Generate all debugging info
 -g:none                    Generate no debugging info
 -g:{lines,vars,source}     Generate only some debugging info
 -nowarn                    Generate no warnings
 -verbose                   Output messages about what the compiler is doing
 -deprecation               Output source locations where deprecated APIs are used
 -classpath &lt;path&gt;          Specify where to find user class files and annotation processors
 -cp &lt;path&gt;                 Specify where to find user class files and annotation processors
 -sourcepath &lt;path&gt;         Specify where to find input source files
 -bootclasspath &lt;path&gt;      Override location of bootstrap class files
 -extdirs &lt;dirs&gt;            Override location of installed extensions
 -endorseddirs &lt;dirs&gt;       Override location of endorsed standards path
 -proc:{none,only}          Control whether annotation processing and/or compilation is done.
 -processor &lt;class1&gt;[,&lt;class2&gt;,&lt;class3&gt;...]Names of the annotation processors to run; bypasses default discovery proces
s
 -processorpath &lt;path&gt;      Specify where to find annotation processors
 -d &lt;directory&gt;             Specify where to place generated class files
 -s &lt;directory&gt;             Specify where to place generated source files
 -implicit:{none,class}     Specify whether or not to generate class files for implicitly referenced files
 -encoding &lt;encoding&gt;       Specify character encoding used by source files
 -source &lt;release&gt;          Provide source compatibility with specified release
 -target &lt;release&gt;          Generate class files for specific VM version
 -version                   Version information
 -help                      Print a synopsis of standard options
 -Akey[=value]              Options to pass to annotation processors
 -X                         Print a synopsis of nonstandard options
 -J&lt;flag&gt;                   Pass &lt;flag&gt; directly to the runtime system

C:\Users\Julien>javac

Usage: javac <options> <source files>

where possible options include:

-g Generate all debugging info

-g:none Generate no debugging info

-g:{lines,vars,source} Generate only some debugging info

-nowarn Generate no warnings

-verbose Output messages about what the compiler is doing

-deprecation Output source locations where deprecated APIs are used

-classpath <path> Specify where to find user class files and annotation processors

-cp <path> Specify where to find user class files and annotation processors

-sourcepath <path> Specify where to find input source files

-bootclasspath <path> Override location of bootstrap class files

-extdirs <dirs> Override location of installed extensions

-endorseddirs <dirs> Override location of endorsed standards path

-proc:{none,only} Control whether annotation processing and/or compilation is done.

-processor <class1>[,<class2>,<class3>...]Names of the annotation processors to run; bypasses default discovery proces

-processorpath <path> Specify where to find annotation processors

-d <directory> Specify where to place generated class files

-s <directory> Specify where to place generated source files

-implicit:{none,class} Specify whether or not to generate class files for implicitly referenced files

-encoding <encoding> Specify character encoding used by source files

-source <release> Provide source compatibility with specified release

-target <release> Generate class files for specific VM version

-version Version information

-help Print a synopsis of standard options

-Akey[=value] Options to pass to annotation processors

-X Print a synopsis of nonstandard options

-J<flag> Pass <flag> directly to the runtime system

C’est que tout est bien configuré

Un peu de ménage

Avant d’installer le JDK, je me suis rendu compte que j’avais déjà une version du runtime Java installée.

Si c’est également votre cas, rien ne vous empêche de la garder, mais pour éviter les conflits potentiel, et ne pas gaspiller inutilement de l’espace disque, j’ai choisi de procéder manuellement à sa désinstallation avant d’installer le JDK.

J’ai également à ce moment là, fait le ménage dans les variables d’environnement qui faisaient référence à Java.

Ant, un “Makefile-like” pour Java

Le Android SDK utilise Ant pour automatiser la compilation des projets. Pour ceux qui connaissent, c’est une alternative orientée Java à Makefile, CMake, SConstruct ou encore BJAM.

Pour les plus curieux, vous pouvez faire un tour sur la page officielle de Ant.

Sinon, passons directement au téléchargement : Télécharger Ant.

Décompressez l’archive où bon vous semble (j’ai choisi encore une fois de tout mettre dans C:\) et ajoutez les variables d’environnement suivantes :

ANT_HOME : Le chemin vers l’archive décompressée. Chez moi : “C:\apache-ant-1.8.1″
JAVA_HOME : Le chemin vers l’installation du JDK. Chez moi : “C:\Program Files\Java\jdk1.6.0_22″
PATH : Ajoutez le chemin vers les binaires de Ant. Chez moi : “C:\apache-ant-1.8.1\bin”

Une fois que tout est configuré, ouvrez une nouvelle console et tapez :

ant

ant

Si vous obtenez la sortie suivante :

C:\Users\Julien&gt;ant
Buildfile: build.xml does not exist!
Build failed

C:\Users\Julien>ant

Buildfile: build.xml does not exist!

Build failed

C’est que Ant est correctement installé.

Si ça ne fonctionne pas, vérifiez bien que l’environnement de votre console est bien à jour. Sous Windows, il faut fermer toutes les fenêtres consoles et les ré-ouvrir pour appliquer les modifications faites à l’environnement.

C’est tout ?

Oui. Il n’en faut pas plus pour avoir un environnement de compilation simple pour Android.

Nous pouvons d’ores et déjà voir comment créer un nouveau projet, le compiler et le déployer sur un émulateur.

Création d’un projet

Pour créer un nouveau projet, nous allons utiliser la commande “android”.

Voici la syntaxe pour créer un nouveau projet :

android create project \
--target <em>&lt;version_cible&gt;</em> \
--name <em>&lt;nom&gt;</em> \
--path <em>&lt;chemin&gt;</em> \
--activity <em>&lt;activité&gt;</em> \
--package <em>&lt;</em>espace_de_nom<em>&gt;
</em>

android create project \

--target <version_cible> \

--name <nom> \

--path <chemin> \

--activity <activité> \

--package <espace_de_nom>

La signification des différents paramètres est la suivante :

version_cible : l’identifiant de version Android cible à utiliser. Pour avoir la liste des identifiants disponibles sur votre poste, utilisez la commande “android list targets”.
nom : Le nom de votre projet. Ce paramètre est optionnel, mais s’il est spécifié, ce nom sera celui du paquet “.apk” généré ultérieurement.
chemin : Le répertoire cible où sera créé votre nouveau projet.
activité : Le nom complet de l’activité. Exemple : “MyAndroid”.
espace_de_nom : L’espace de nom (ou “namespace”) utilisé par votre projet. Exemple : “org.freelan.myandroid”.

Google donne la commande exemple suivante :

android create project \
--target 1 \
--name MyAndroidApp \
--path ./MyAndroidAppProject \
--activity MyAndroidAppActivity \
--package com.example.myandroid

android create project \

--target 1 \

--name MyAndroidApp \

--path ./MyAndroidAppProject \

--activity MyAndroidAppActivity \

--package com.example.myandroid

Qui crée dans le répertoire courant un sous-répertoire “MyAndroidAppProject” contenant le nouveau projet.

Arborescence d'un nouveau projet Android

Nous ne rentrerons pas ici dans les détails de cette arborescence, mais voici tout de même dans les grandes lignes les choses intéressantes :

Les fichiers source Java sont situés dans le répertoire “src”.
Tout ce qui concerne les chaînes de caractères, fichiers XML représentant l’interface graphique (ou “Layouts”) ou images sont dans le répertoire “res”.
Ne touchez jamais aux fichiers “*.properties” ! Ils sont utilisés par Ant pour la phase de “build” et n’ont pas vocation à être modifiés manuellement.

Compilation du projet

Le projet, tel que créé par défaut est simpliste mais fonctionnel. Le rôle de ce tutoriel n’étant pas d’apprendre à concevoir une application Android mais de simplement maitriser les outils du SDK, nous ne ferons aucune modification de ce projet.

Pour être diffusée, une application Android doit être signée. Ceci implique plusieurs démarches dont nous traiterons dans un autre tutoriel. Pour l’heure, nous choisissons de compiler notre projet en “debug”, ce qui nous permet de nous affranchir de cette étape.

Dans la même console, toujours à la racine du projet, tapez simplement la commande :

ant debug

ant debug

Qui a pour effet de générer dans le répertoire “bin” différentes choses, dont le fichier “MyAndroidApp-debug.apk”.

Ce n’est pas plus compliqué que ça.

Création d’un périphérique virtuel

Pour tester notre application, il nous faut soit un téléphone sous Android relié en USB et configuré en mode développeur, soit un téléphone virtuel lancé dans un émulateur.

Si vous n’avez pas encore créé de téléphone virtuel, voici la marche à suivre :

Dans votre console, tapez la commande :

android

android

Ce qui a pour effet d’ouvrir la fenêtre suivante :

Gestion des téléphone virtuels

Cliquez sur “New…”, puis spécifiez les caractéristiques de votre téléphone virtuel :

Caractéristiques du téléphone virtuel

Puis validez en cliquant sur “Create AVD”.

Si tous les paramètres sont corrects, votre téléphone virtuel est créé. Vous pouvez d’ores et déjà le démarrer en le sélectionnant dans la liste et en cliquant sur le bouton “Start…”.

Ce premier démarrage peut être assez long, aussi, soyez patient.

Installer son application sur le téléphone

Une fois le paquet “apk” créé, l’installation sur un téléphone (qu’il soit virtuel ou non) se fait très simplement :

adb install <em>bin\MyAndroidApp-debug</em>.apk

1	adb install <em>bin\MyAndroidApp-debug</em>.apk

La commande prends quelques secondes et vous indique le succès ou l’échec de l’opération.

Si vous disposez de plusieurs émulateurs, ou d’un émulateur et d’un téléphone physique, adb ne peut pas deviner où installer votre paquet.

Utilisez alors la syntaxe suivante pour spécifier le périphérique à utiliser :

adb -s emulator-5554 install bin\MyAndroidApp-debug.apk

1	adb -s emulator-5554 install bin\MyAndroidApp-debug.apk

Ou positionnez la variable d’environnement ANDROID_SERIAL avant vos appels à adb.

Pour obtenir la liste des numéros de série des périphériques, vous pouvez utiliser la commande suivante :

adb devices

1	adb devices

La commande “adb install” possède tout un tas d’option qu’il ne serait pas raisonnable de détailler ici. Vous devriez cependant y jeter un coup d’oeil. Pour les lister, tapez simplement :

adb install

1	adb install

Qui produit la sortie suivante :

C:\Users\Julien&gt;adb install
Android Debug Bridge version 1.0.26

 -d                            - directs command to the only connected USB device returns an error if more than one USB device is present.
 -e                            - directs command to the only running emulator. returns an error if more than one emulator is running.
 -s &lt;serial number&gt;            - directs command to the USB device or emulator with the given serial number. Overrides ANDROID_SERIAL environment variable.
 -p &lt;product name or path&gt;     - simple product name like 'sooner', or  a relative/absolute path to a product out directory like 'out/target/product/sooner'.
 If -p is not specified, the ANDROID_PRODUCT_OUT environment variable is used, which must be an absolute path.
 devices                       - list all connected devices
 connect &lt;host&gt;:&lt;port&gt;         - connect to a device via TCP/IP
 disconnect &lt;host&gt;:&lt;port&gt;      - disconnect from a TCP/IP device

device commands:
 adb push &lt;local&gt; &lt;remote&gt;    - copy file/dir to device
 adb pull &lt;remote&gt; [&lt;local&gt;]  - copy file/dir from device
 adb sync [ &lt;directory&gt; ]     - copy host-&gt;device only if changed
 (see 'adb help all')
 adb shell                    - run remote shell interactively
 adb shell &lt;command&gt;          - run remote shell command
 adb emu &lt;command&gt;            - run emulator console command
 adb logcat [ &lt;filter-spec&gt; ] - View device log
 adb forward &lt;local&gt; &lt;remote&gt; - forward socket connections
 forward specs are one of:
 tcp:&lt;port&gt;
 localabstract:&lt;unix domain socket name&gt;
 localreserved:&lt;unix domain socket name&gt;
 localfilesystem:&lt;unix domain socket name&gt;
 dev:&lt;character device name&gt;
 jdwp:&lt;process pid&gt; (remote only)
 adb jdwp                     - list PIDs of processes hosting a JDWP transport
 adb install [-l] [-r] [-s] &lt;file&gt; - push this package file to the device and install it
 ('-l' means forward-lock the app)
 ('-r' means reinstall the app, keeping its data)
 ('-s' means install on SD card instead of internal storage)
 adb uninstall [-k] &lt;package&gt; - remove this app package from the device ('-k' means keep the data and cache directories)
 adb bugreport                - return all information from the device that should be included in a bug report.

 adb help                     - show this help message
 adb version                  - show version num

DATAOPTS:
 (no option)                   - don't touch the data partition
 -w                           - wipe the data partition
 -d                           - flash the data partition

scripting:
 adb wait-for-device          - block until device is online
 adb start-server             - ensure that there is a server running
 adb kill-server              - kill the server if it is running
 adb get-state                - prints: offline | bootloader | device
 adb get-serialno             - prints: &lt;serial-number&gt;
 adb status-window            - continuously print device status for a specified device
 adb remount                  - remounts the /system partition on the device read-write
 adb reboot [bootloader|recovery] - reboots the device, optionally into the bootloader or recovery program
 adb reboot-bootloader        - reboots the device into the bootloader
 adb root                     - restarts the adbd daemon with root permissions
 adb usb                      - restarts the adbd daemon listening on USB
 adb tcpip &lt;port&gt;             - restarts the adbd daemon listening on TCP on the specified port
networking:
 adb ppp &lt;tty&gt; [parameters]   - Run PPP over USB.
 Note: you should not automatically start a PPP connection.
 &lt;tty&gt; refers to the tty for PPP stream. Eg. dev:/dev/omap_csmi_tty1
 [parameters] - Eg. defaultroute debug dump local notty usepeerdns

adb sync notes: adb sync [ &lt;directory&gt; ]
 &lt;localdir&gt; can be interpreted in several ways:

 - If &lt;directory&gt; is not specified, both /system and /data partitions will be updated.

 - If it is "system" or "data", only the corresponding partition is updated.

C:\Users\Julien>adb install

Android Debug Bridge version 1.0.26

-d - directs command to the only connected USB device returns an error if more than one USB device is present.

-e - directs command to the only running emulator. returns an error if more than one emulator is running.

-s <serial number> - directs command to the USB device or emulator with the given serial number. Overrides ANDROID_SERIAL environment variable.

-p <product name or path> - simple product name like 'sooner', or a relative/absolute path to a product out directory like 'out/target/product/sooner'.

If -p is not specified, the ANDROID_PRODUCT_OUT environment variable is used, which must be an absolute path.

devices - list all connected devices

connect <host>:<port> - connect to a device via TCP/IP

disconnect <host>:<port> - disconnect from a TCP/IP device

device commands:

adb push <local> <remote> - copy file/dir to device

adb pull <remote> [<local>] - copy file/dir from device

adb sync [ <directory> ] - copy host->device only if changed

(see 'adb help all')

adb shell - run remote shell interactively

adb shell <command> - run remote shell command

adb emu <command> - run emulator console command

adb logcat [ <filter-spec> ] - View device log

adb forward <local> <remote> - forward socket connections

forward specs are one of:

tcp:<port>

localabstract:<unix domain socket name>

localreserved:<unix domain socket name>

localfilesystem:<unix domain socket name>

dev:<character device name>

jdwp:<process pid> (remote only)

adb jdwp - list PIDs of processes hosting a JDWP transport

adb install [-l] [-r] [-s] <file> - push this package file to the device and install it

('-l' means forward-lock the app)

('-r' means reinstall the app, keeping its data)

('-s' means install on SD card instead of internal storage)

adb uninstall [-k] <package> - remove this app package from the device ('-k' means keep the data and cache directories)

adb bugreport - return all information from the device that should be included in a bug report.

adb help - show this help message

adb version - show version num

DATAOPTS:

(no option) - don't touch the data partition

-w - wipe the data partition

-d - flash the data partition

scripting:

adb wait-for-device - block until device is online

adb start-server - ensure that there is a server running

adb kill-server - kill the server if it is running

adb get-state - prints: offline | bootloader | device

adb get-serialno - prints: <serial-number>

adb status-window - continuously print device status for a specified device

adb remount - remounts the /system partition on the device read-write

adb reboot [bootloader|recovery] - reboots the device, optionally into the bootloader or recovery program

adb reboot-bootloader - reboots the device into the bootloader

adb root - restarts the adbd daemon with root permissions

adb usb - restarts the adbd daemon listening on USB

adb tcpip <port> - restarts the adbd daemon listening on TCP on the specified port

networking:

adb ppp <tty> [parameters] - Run PPP over USB.

Note: you should not automatically start a PPP connection.

<tty> refers to the tty for PPP stream. Eg. dev:/dev/omap_csmi_tty1

[parameters] - Eg. defaultroute debug dump local notty usepeerdns

adb sync notes: adb sync [ <directory> ]

<localdir> can be interpreted in several ways:

- If <directory> is not specified, both /system and /data partitions will be updated.

- If it is "system" or "data", only the corresponding partition is updated.

Démarrer une activité

Une fois installée, vous pouvez démarrer l’activité sur votre téléphone comme vous le feriez pour n’importe quelle autre application. Mais si vous le souhaitez, vous pouvez également le faire en ligne de commande (voire automatiquement, si vous mettez toutes les commandes dans un script).

La commande ci-après démarre votre activité sur le téléphone spécifié (ou sur le seul téléphone connecté) :

adb shell am start -a android.intent.action.MAIN -n com.example.myandroid/.MyAndroidAppActivity

1	adb shell am start -a android.intent.action.MAIN -n com.example.myandroid/.MyAndroidAppActivity

Vous pouvez d’ailleurs démarrer n’importe-quelle activité en utilisant cette méthode.

Une seule commande pour tout

Astuce qu’il est agréable de connaître : Il est possible de réunir les dernières étapes en une seule commande en utilisant la commande suivante :

ant install

1	ant install

Qui va se charger de faire un “ant debug”, “adb install…” pour vous. Plutôt sympa non ?

Conclusion

Le développement Android en mode console s’avère moins pénible à mettre en place que je ne l’aurais pensé. Google a fait un travail impressionnant en fournissant aux développeurs des outils simples et facile à intégrer à n’importe quel environnement.

Certains argueront que l’apprentissage du développement Android est bien plus facile sous Eclipse, et je pense que dans un sens ce n’est pas faux : il est clair qu’avoir le complètement automatique et des assistants permet d’apprendre peu à peu et facilement les différentes structures de données à utiliser. Cependant, la découverte de cet environnement console permet assurément de comprendre tout ce qu’Eclipse fait pour nous de façon automatique.

L’utilisation directe de “adb” peut notamment fournir au développeur des outils avancés indispensables et une aide précieuse au développement.

Installer l’environnement de développement pour Android

8 réponses

Il existe déjà sur la toile un bon nombre d’articles traitant du développement sur Android. La plupart sont d’ailleurs très bien écrits et assez faciles à suivre mais supposent souvent que le lecteur connaisse Java ou en tout cas soit familier avec son environnement de développement. Si comme moi, ce n’est pas votre cas mais que vous souhaitez tout de même développer pour Android : ce retour d’expérience cet article est fait pour vous.

Commençons par le début, voulez-vous ?

Nous allons supposer que vous disposez d’un ordinateur, d’une connexion à l’Internet et éventuellement d’un téléphone sous Android. Ce dernier point n’est évidemment pas obligatoire mais il faut reconnaître que c’est quand même moins marrant de tester son application dans un émulateur que sur un vrai téléphone.

Les instructions que je vais décrire sont pour Windows, mais il ne sera certainement pas très difficile de les transcrire pour Linux ou Mac OSX.

Installer le support de Java

Le langage de choix pour le développement Android est le Java. Il s’agit d’un langage complètement portable : le code est le même indépendamment du système d’exploitation ou de son architecture (x86, x64, etc.). Pour s’exécuter sur les différents systèmes, Java requiert l’installation d’une JVM, (“Java Virtual Machine” ou encore “Machine Virtuelle Java”) qui “traduit” le code Java en instructions compréhensibles par le système hôte.

Installons donc cette JVM : Télécharger la JVM

Le “Android SDK”

Il faut ensuite télécharger le kit de développement Android fourni par Google. Encore une fois, rien de plus simple : Télécharger le Android SDK

Une fois l’archive récupérée, décompressez-la où bon vous semble. Pour ma part, j’aime avoir mes différents environnements de développement sous Windows à la racine du C:\, mais vous pouvez très bien décider de la mettre ailleurs^*.

* Évitez tant que possible d’utiliser un chemin contenant des espaces, ce ne serait pas la première fois que ça cause des problèmes !

Il faut ensuite ajouter au PATH le répertoire de l’archive contenant les outils du SDK. Sur mon poste, j’ai donc ajouté “C:\android-sdk-windows\tools” à mon PATH :

Ajouter les outils du Android SDK à son PATH

Eclipse, l’outil de prédilection

Pour développer, il faut ensuite au moins un éditeur de texte et au mieux un IDE. Bien que ne connaissant que très peu Java, j’avais cependant déjà entendu parler d’Eclipse. Google ayant en plus eu le bon goût de développer un plugin Eclipse pour le développement Android : il semble s’agir d’un bon choix.

Mon instinct de développeur à la page m’inciterait à télécharger la dernière version d’Eclipse (la 3.6 au moment où ces lignes sont rédigées), mais Google indique sur la page de présentation de son plugin que celui-ci ne fonctionne qu’avec la version 3.5.

Téléchargeons donc la version 3.5 : Page de téléchargement d’Eclipse

Rendez-vous dans l’onglet “Older versions” puis choisissez “Eclipse Galileo SR2 Packages (v 3.5.2)” puis enfin prenez “Eclipse IDE for Java Developers“.

Décompressez l’archive, et placez le dossier “eclipse” où bon vous semble. Encore une fois, j’ai choisi de le mettre à la racine du C:\ par souci de cohérence.

Rendez-vous dans le répertoire fraîchement décompressé puis lancez “eclipse.exe”. Ceci peut prendre un peu de temps, puis le programme vous demande où vous souhaitez enregistrer vos futurs projets.

Le plugin ADT

Il ne manque plus que l’installation du plugin officiel Google pour Android (ADT).

Rendez-vous sur cette page. Et suivez les instructions concernant votre version d’Eclipse.

Pour ceux qui auraient un problème avec la langue de Shakespeare, voici les premières instructions traduites :

Démarrez Eclipse, et rendez-vous dans le menu “Help” puis “Install New Software”.
Cliquez sur le bouton “Add…”
Dans le premier champ, entrez “Android Developer Tools” puis dans le second champ, saisissez “https://dl-ssl.google.com/android/eclipse/”. Validez par un clic sur le bouton “OK”.
Vous devriez désormais voir une entrée “Developer Tools” dans la liste plus bas. Sélectionnez la case à cocher, ce qui a pour effet de sélectionner automatiquement les deux sous-cases.
Faites “Next” autant de fois que nécessaire, acceptez la license d’utilisation (si vous la comprenez), puis cliquez sur “Finish”. Eclipse télécharge ensuite les composants.
Redémarrez Eclipse pour terminer l’installation du plugin.

Installer de nouveaux composants pour Eclipse

Ajouter la source ADT

Acceptation de la licence

Avant d’être utilisé, le plugin ADT doit être configuré. Rendez-vous dans “Windows”, puis “Preferences” et sélectionnez “Android” dans la liste à gauche.

Spécifiez le chemin vers le SDK installé en cliquant sur le bouton “Browse…” et en cherchant l’endroit où vous avez décompressé le Android SDK. Chez moi, il s’agit de “C:\android-sdk-windows”.

Validez par “OK” pour terminer la configuration.

Configuration du Android SDK

La dernière étape avant de pouvoir développer pour Android consiste à configurer le Android SDK.

Rendez-vous dans le répertoire où vous avez décompressé le Android SDK, puis exécutez le programme : “SDK Manager.exe”.

Configuration du Android SDK

Choisissez les paquets à installer en les acceptant ou en les refusant.

Pour ma part, j’ai conservé le choix par défaut, puis j’ai cliqué sur “Install”. S’en suit une série de téléchargements, plus ou moins rapides.

Créer un périphérique virtuel

Cette étape n’est pas obligatoire pour ceux qui disposent d’un téléphone sous Android, mais il peut être pratique d’avoir un téléphone virtuel prêt à l’emploi pour faire des tests rapides (ou lorsqu’on est dans le train et qu’avoir 15 000 trucs sur les genoux n’est pas une option !).

Toujours dans le “Android SDK Manager”, rendez-vous dans la catégorie : “Virtual Devices” puis faites “New…”.

Choisissez un nom significatif pour votre périphérique virtuel. Dans mon cas, j’ai décidé de reproduire les caractéristiques physiques de mon téléphone : je l’ai donc nommé “HTC_Desire”.

Choisissez une version de l’OS à utiliser (dans mon cas toujours, “Android 2.2 – API Level 8″) et une taille pour la carte SD. Ici, ça dépend vraiment de votre espace disque : j’ai choisi “4096 Mo” comme ma vraie carte SD, mais si vous êtes limité en place, quelque-chose comme “128 Mo” peut être suffisant.

Pour le reste, j’ai laissé les réglages par défaut qui semblaient convenir.

Cliquez sur “Create AVD” pour finaliser la création.

Vous pouvez, si vous le souhaitez, vous amuser à démarrer le téléphone virtuel en cliquant sur le bouton “Start” à droite. Le téléphone peut mettre un peu de temps à démarrer (surtout la première fois) aussi, soyez patient.

L'émulateur de périphérique Android

Félicitations !

Ça y est ! Vous avez terminé la configuration de l’environnement de développement et vous êtes prêt à développer pour votre nouvelle plateforme préférée !

Rendez-vous dans Eclipse, faites “New”, “Project” puis choisissez “Android Project” et laissez-vous guider !