Présentation

Il existe de très nombreuses ressources sur l’Internet (mais pas que) qui présentent Git de façon très complète. L’objectif de cet article n’est pas de faire de vous un expert Git en quelques pages mais simplement de vous présenter l’outil et de, j’espère, vous donner l’envie de l’utiliser. si vous connaissez déjà suffisamment Git, vous pouvez sauter la section suivante et directement vous rendre à la partie “Installation sous Windows”.

Un gestionnaire de sources

Git est un gestionnaire de sources, comme Subversion (SVN), CVS ou encore Visual Source Safe (VSS). Un outil qui assure principalement les rôles suivants :

• Il permet de stocker différentes versions du code source.
• Il permet un travail collaboratif en facilitant la synchronisation entre différents développeurs.
• Il permet de savoir qui est à l’origine d’une modification

Les trois derniers outils que j’ai cités ont en commun leur architecture centralisée : tous les développeurs synchronisent leurs fichiers de code source auprès d’un dépôt central. Cette approche, très simple à comprendre est souvent plébiscitée par les entreprises, pour différentes raisons :

• L’administration d’un dépôt central est plutôt simple : on peut régler finement et individuellement les droits d’accès.
• Tout le monde comprend la notion de “publier” ses sources dans un dépôt central.
• En entreprise, en général, les liaisons réseaux sont fiables et robustes; l’accès 24H/24 au dépôt est quasi-garanti.
• Les clients ne disposent que du code source sur lequel ils travaillent actuellement; l’historique reste, lui, dans le dépôt.

Git se distingue principalement par son architecture distribuée. Avec Git, il n’y a pas de dépôt central, principal, ou autre : chaque dépôt Git contient tout l’historique du dépôt, de façon autonome. Il n’y a pas d’entité supérieure. Les dépôts peuvent communiquer entre eux selon des règles très simples. Ses avantages principaux sont les suivants :

• Le dépôt, puisque local et autonome, est toujours accessible et extrêmement rapide, même lorsque déconnecté du réseau.
• Git ne stocke pas les fichiers, mais les différences entre les fichiers : ce principe lui permet de disposer d’un des mécanismes de fusion (ou “merge”) les plus efficaces.
• Contrôle total sur le dépôt : on ne dépend plus d’une entité externe. Avec une solution centralisée, si le dépôt nous lâche, adieu l’historique.
• Un système de branchage extrêmement efficace.

Note : Il n’y aucun mal à utiliser un gestionnaire de sources centralisé; c’est d’ailleurs dans bien des cas la solution la plus adaptée. Cependant, puisque cet article parle essentiellement de Git, nous allons nous concentrer sur des cas où l’utilisation de Git semble plus opportune. Vous trouverez ici un historique plus précis de git et des raisons de sa création.

Avant de commencer

Si vous êtes déjà habité à utiliser un gestionnaire de sources “classique”, avant de continuer prenez quelques minutes pour vous rappeler de leur fonctionnement puis oubliez tout ! En tout cas temporairement : l’utilisation de Git est drastiquement différente et lui appliquer la logique d’un gestionnaire de source centralisé n’aurait aucun sens. Pour ma part, je suis habitué à utiliser SVN et il m’a fallu une certaine période d’adaptation pour comprendre que son fonctionnement était plus différent qu’il n’y paraissait.

Note : Bien que différents, il est tout à fait possible d’utiliser un dépôt SVN avec la ligne de commande git, grace à “git svn” qui s’avère être un moyen très simple de découvrir git sans changer ses dépôts existants. Je l’utilise depuis plusieurs semaines maintenant et j’en suis vraiment très satisfait.

Concepts

Chaque dépôt Git conserve un historique de tous les changements (ou “commits”) depuis sa création, potentiellement au sein de plusieurs branches. Au sein d’un dépôt, on ne peut travailler à la fois que dans une seule branche et sur un seul commit. Lorsqu’on a effectué des changements au sein d’une branche, on peut librement les enregistrer à la suite de la branche (on parle de faire un “commit”) et continuer (éventuellement en allant travailler dans une autre branche). Il est par la suite possible de fusionner (faire un “merge”) de plusieurs branches pour répercuter les changements de l’une dans l’autre. La philosophie de Git, c’est de faire des commits très souvent, même (et surtout) pour de petites modifications. Plus vous “commiterez” souvent, plus il sera facile pour Git de fusionner vos changements avec ceux des autres.

Installation sous Windows

J’ai longtemps travaillé avec Subversion (SVN) sous Windows en utilisant TortoiseSVN. Cet outil graphique est plutôt bien pensé et m’a toujours satisfait. En voulant essayer git, je me suis donc naturellement porté vers TortoiseGIT mais je dois avouer que j’ai été déçu. Je pense que les gens derrière TortoiseGIT ont fait un travail remarquable et ils continuent d’améliorer le logiciel, mais à l’heure actuelle l’outil me paraît plus contraignant à utiliser que sa version classique en ligne de commande (comme sous Linux). C’est donc sur cette dernière que va porter l’installation.

Téléchargements

Commencez par télécharger git en vous rendant sur cette page. Prenez la dernière version existante de git (Version “Git-1.7.3.1-preview20101002.exe” à l’heure actuelle). Exécutez l’installation :

Installation de git

Choisissez les modules que vous souhaitez installer. Pour ma part, j’ai choisi ces modules :

Modules à installer

Enfin, l’installeur vous demande de quelle façon vous souhaitez installer git. Les deux premières options nécessitent l’utilisation d’une console de type UNIX (msys/cygwin) pour l’utilisation de Git, la dernière permet d’utiliser git depuis une console native (type “cmd.exe” ou encore Powershell).

Mode d'installation de git

C’est cette dernière option que nous choisirons pour les raisons suivantes :

• La console UNIX est vraiment très puissante et efficace… mais, à mon sens, assez peu adaptée à Windows.
• De nombreux développeurs Windows utilisent déjà Powershell et donc il faut pouvoir utiliser git depuis n’importe quelle console. Changer de console juste pour commit ses changements dans git n’est pas envisageable.

Notez que comme il est indiqué dans l’installeur, la dernière option va remplacer une partie des outils Windows (tels que find.exe et sort.exe) par leur équivalent GNU. Si vous utilisez ces outils, vous pourrez toujours les utiliser, mais il faudra les préfixer par leur chemin complet. Une fois l’installation terminée, lancez une console puis saisissez la commande :

git --version

Si vous obtenez la sortie suivante :

Obtenir la version installée de git

C’est que git est correctement installé et fonctionnel. Félicitations !

Configuration préliminaire

Il est possible de configurer un bon nombre de choses dans git. Cela passe du nom d’utilisateur au proxy à utiliser ou à l’activation des couleurs lors de l’affichage des informations du dépôt. Les configurations de git sont soit globales, soit propres à chaque dépôt. En pratique, si une valeur de paramètre n’est pas trouvée au sein du dépôt, git va regarder la configuration globale. Voici les paramètres les plus couramment modifiés :

git config --global user.name "Votre nom"
git config --global user.email "adresse@email.com"
git config --global color.branch auto
git config --global color.diff auto
git config --global color.interactive auto
git config --global color.status auto

Le deux premiers sont assez explicites; les quatre suivant activent les couleurs lors des commandes associées (ce qui est quand même plus sympathique). Il existe évidemment encore bien d’autres paramètres, je vous invite à consulter la page de manuel de git-config pour les découvrir.

Utilisation basique

Le moyen le plus efficace, c’est de pratiquer. Commençons par créer un dépôt git :

Création d'un dépôt git

Note : Plutôt que de créer un dépôt vide, on aurait également pu choisir de cloner un dépôt existant avec la commande “git clone”.

Créons un fichier à ajouter au dépôt :

Création d'un fichier à ajouter au dépôt

La commande “git status” permet d’interroger le dépôt sur le statut actuel de la copie de travail (ou “working copy”). Ici, on voit que le fichier main.cpp a été créé mais n’est pas suivi (ou “tracked”) par le dépôt. Indiquons à git que ce fichier doit être suivi et faire partie du prochain commit :

Ajout d'un fichier au dépôt

Pour ce faire, nous avons utilisé la commande “git add” qui permet d’indiquer qu’un fichier (même si il est déjà suivi) doit faire partie du prochain commit.

Après “git add”, “git status” nous indique bel est bien que le fichier doit être suivi. Nous pourrions à ce moment là, ajouter d’autres fichiers, en modifier, voire en supprimer ou en déplacer certains. Il faut simplement signaler à git que le changement (quel que soit sa nature) doit faire partie du prochain commit.

Nous nous contentons de ce simple ajout pour l’instant.

Historisation d'un changement

La commande “git commit” permet de sauver le changement au sein du dépôt. Ici le paramètre “-m” permet de spécifier un message à associer au commit. Sans ça, git aurait ouvert un éditeur de texte pour nous demander de saisir notre message.

Note : La saisie d’un message est extrêmement importante. Les messages ne doivent pas forcément être très longs, mais il ne devraient jamais être vides. À quoi sert-il de mettre ses changements sous historiques si on est incapable de dire pourquoi ils ont été faits ? Même lorsque vous travaillez seul, prenez l’habitude de toujours renseigner des messages informatifs pour chacun de vos commits. C’est une habitude que vous ne regrettez pas.

Après le commit, on constate que la “working copy” a été mise à zéro : “git status” indique qu’aucun changement n’a été apporté depuis le commit actuel. Nous pouvons bien entendu dès à présent consulter l’historique de notre dépôt grâce à la commande “git log” :

Consultation de l'historique

Le commit est bien dans l’historique. Il s’est vu assigner un identifiant unique “c0d281e3532a4970415bba1e9159b1dc7ed816b1″. Modifions maintenant le fichier main.cpp, de la façon suivante :

Le fichier main.cpp modifié

Après sauvegarde des modifications, on utilise “git status” qui nous informe qu’en effet, main.cpp a été modifié par rapport à la version actuelle :

Le fichier main.cpp a été modifié

Notons que bien que modifié, le fichier n’est pas automatiquement marqué comme faisant partie du prochain commit.

Nous pouvons afficher la liste des modifications apportées au fichier grâce à la commande “git diff” :

Utilisation de git diff pour lister les changements

Nous souhaitons archiver cette nouvelle version de main.cpp. Pour ce faire, nous pouvons faire “git add main.cpp” suivi de “git commit” ou bien directement :

Archivage de la correction de main.cpp

L’argument “-a” permet de dire à “git commit” qu’il doit automatiquement ajouter tous les fichiers déjà suivis qui ont été modifiés depuis le dernier commit.

Encore une fois, un appel “git log” nous donne la sortie suivante :

Affichage des logs du dépôt

Le changement a bien été archivé. Il est possible de revenir à un état antérieur du dépôt grâce à la commande “git checkout” :

Utilisation de git checkout

Et bien entendu de revenir à la dernière version en date en utilisant : “git checkout master”, où “master” est le nom de la branche à utiliser. Note : par défaut, la branche principale d’un dépôt git est nommée “master”. Il s’agit d’une convention, que vous êtes libre de ne pas suivre, mais qu’il est tout de même recommandé de respecter.

Aller plus loin

Nous n’avons vu ici qu’un petit aperçu de l’utilisation et du principe de git : il y a bien plus à voir et à découvrir. Il est également possible de (liste loin d’être exhaustive) :

• Partager ses modifications avec un ou plusieurs autres dépôts (“push”, “pull”, “fetch”, etc.).
• Effacer localement certains commit intermédiaires ou de réécrire totalement l’historique (lorsque cela est absolument nécessaire).
• Utiliser git avec un dépôt SVN (“git svn”) pour par exemple faciliter la transition.
• Rechercher quelle modification a introduit un bogue (“git bissect”)

Pour tout découvrir, je vous recommande notamment le livre Pragmatic Guide to Git qui est à la fois très facile d’accès et très complet. N’hésitez pas non plus à consulter les pages de manuel de git qui sont très bien fournies. Comme toujours, n’hésitez pas à poser vos questions si j’ai manqué de clarté sur certains aspects.

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 :

1. 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”.
2. 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”).
3. 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 */

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;
}

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;
}

• 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);
}

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;
}

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

1. 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.
2. Ou il peut décider de remplacer factorial(6) par 6 * factorial(5) directement.
3. 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; }
}

• 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 !

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

Puis localisez la clé nommée :

{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 %*"

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 !

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 <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 <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 <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& outbuflen);

Par un simple :

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 <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 :

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

#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 !

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 !

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

Si vous obtenez la sortie suivante :

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
s
 -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

Si vous obtenez la sortie suivante :

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>

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

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

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

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

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

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

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

Qui produit la sortie suivante :

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

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

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.

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 :

1. Démarrez Eclipse, et rendez-vous dans le menu “Help” puis “Install New Software”.
2. Cliquez sur le bouton “Add…”
3. 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”.
4. 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.
5. 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.
6. 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 !

]]> http://blog.freelan.org/2010/11/20/installer-lenvironnement-de-developpement-pour-android/feed/ 8