Un Android Developer Labs (ADL) s’est déroulé à Paris jeudi 27 et vendredi 28 octobre 2011, traitant de l’optimisation des applications Android pour les tablettes.

J’ai eu la chance d’être invité à cet évènement ; j’en ai donc profité pour prendre des notes afin de pouvoir retranscrire le déroulement de cette journée (l’ADL du vendredi).

Apéro Android

Avant tout, laissez-moi vous parler de l’apéro Android. Sachant que les places pour l’ADL étaient limitées, le Paris Android User Group (PAUG) a organisé un apéro Android le jeudi soir, pour permettre à tous de discuter et de rencontrer les Android Developer Advocates.

Les Googlers sont très ouverts et abordables, et nous avons passé une soirée sympatique, en partie aux frais de FrAndroid. Je vous conseille vivement ce type de rencontre ; c’est un bon moyen d’apprendre et de rencontrer des gens intéressants tout en passant un bon moment.

Au cours de la soirée, j’ai eu le plaisir de constater que deux Android Developer Advocates (Nick Butcher et Richard Hyndman) connaissaient AndroidAnnotations, suite au talk de Matthias Kaeppler à la DroidCon 2011.

L’ADL

Le programme de la journée était le suivant :

• Introduction aux tablettes
• Quoi de neuf dans Ice Cream Sandwich
• Android Market pour développeurs
• Développer pour téléphones et tablettes
• Codelab

J’ai pris des notes du mieux possible ; j’espère que vous me saurez gré des lacunes éventuelles et de la faible mise en forme.

Introduction aux tablettes

Cette présentation fut consacrée aux spécificités liées à Honeycomb et au développement pour tablettes.

Notez qu’Honeycomb est uniquement orienté tablette : l’équipe Android n’avait pas le temps de réaliser un OS pour téléphones en parallèle.

System bar

Auparavant, les informations système et les notifications étaient situées dans une barre en haut de l’écran.

Désormais, cette barre se situe en bas de l’écran, et contient en outre les boutons de navigation. Cela permet de se débarrasser des boutons physiques, qui étaient mal placés lorsque l’on passait en mode paysage.

Les notifications sont désormais accessibles sans couvrir totalement l’écran, de même qu’un certain nombre de réglages et informations bien pratiques.

Cette barre peut distraire l’attention visuelle lorsque vous souhaitez une expérience immersive. Il est possible de la cacher en utilisant le code suivant :

mView.setSystemUiVisibility(View.STATUS_BAR_HIDDEN)

Dans le screenshot suivant, comme vous le voyez, la barre ne disparaît pas totalement. Elle devient noire, mais les icônes sont remplacés par des points gris toujours cliquables.

Note : ce screenshot montre le dernier niveau de Wind-up Knight, un jeu sympa qui est un bon exemple de l’efficacité du paiement in-app (la preuve, je n’ai pas résisté et ce fût l’occasion de réaliser mon premier paiement in-app).

Action bar

Vous souvenez-vous d’Android 1.X, où la barre de titre occupait une place énorme qui ne servait à rien ?

Autant utiliser cet espace !

C’est le principe de l’action bar. Celle-ci comporte tout d’abord une icône cliquable qui permet de retourner à tout moment à l’écran d’accueil.Elle affiche ensuite des éléments liés à la navigation, et pour finir des icônes d’action.

Cette action bar n’est pas nécessairement un composant Android, il s’agit plutôt d’un design pattern de UI, que toute application Android digne de ce nom devrait respecter.

Le projet ActionBarCompat, disponible dans les samples depuis ADT 14, met à disposition tout le code et les ressources nécessaires à la création d’une action bar fonctionnant sur toutes les versions d’Android.

ActionBarCompat sur mon Nexus One (Gingerbread)

Les menu items dans l’Options Menu peuvent être rendus disponibles dans les boutons d’action. Il suffit juste d’ajouter l’attribut suivant aux items dans votre menu.xml :

    android:showAsAction="ifRoom|withText";

Les fragments

Sans trop rentrer dans les détails : les fragments sont des composants de UI, réutilisables. L’utilisation de Fragment permet de repenser la UI, il ne suffit plus de se contenter d’avoir un design fluide qui s’élargit par rapport à la taille de l’écran, il faut organiser les fragments différents suivant l’écran et la place disponible.

Pour être tout à fait honnête, je ne suis qu’à moitié convaincu par ce nouveau système de fragment. Le principe reste proche de celui des activités : il s’agit d’un controller, chargé d’orchestrer le code métier lié à un assemblage de composants graphiques (des View).

En soit, ce n’est pas une mauvaise idée. Par contre, on se retrouve encore avec un modèle par héritage, comme pour les activités. Tout fragment doit hériter de Fragment. Il existe un ListFragment, un XXXFragment, etc, qui tous héritent de Fragment.

Le problème, c’est que dès lors que l’on souhaite factoriser du code commun à plusieurs Fragments, il va falloir recréer une sous classe pour chacun des types de Fragment. AbstractCustomFragment, AbstractCustomListFragment, etc. Et évidemment, si deux frameworks s’amusent à créer leurs propres fragments à étendre, il devient compliqué de les combiner.

Pour faire un parallèle, j’ai l’impression que l’équipe Android persiste à proposer des servlets, quand il serait bien plus utile de proposer des controllers Spring.

A bien y réfléchir, une Activity et un Fragment ont ceci de commun qu’ils répondent à des évènements (principe des callbacks type onCreate()), qu’ils renvoient des éléments de configuration (e.g. getLastNonConfigurationInstance()), et qu’ils fournissent des helpers (getLoaderManager(), getPreferences(), etc).

Pour moi, ces différentes responsabilités devraient appartenir à différents composants.

Les Loaders

Les Loaders sont un nouveau moyen pour récupérer des données en tâche de fond, en gérant convenablement les problématiques liées au cycle de vie des composants Android.

Samsung loader, by A1C Beatrice Cassetty, U.S. Air Force (public domain)

C’est une alternative très intéressante à l’AsyncTask, qui malgré plusieurs bonnes idées souffre de quelques problèmes :

• Pas de gestion du cycle de vie (activité mise en pause, détruite définitivement, détruite mais pour raison de changement de configuration, etc)
• Pas facile à utiliser : le paramètre générique PARAM n’est pas vraiment utile (en plus, c’est une vararg, quelle horreur !), il n’y a pas de gestion des exceptions.

A noter qu’un des premiers risques avec les AsyncTask, c’est d’en faire des classes anonymes et de leaker des références vers leur outer class, qui est bien souvent une activité.

Et pour simplifier votre code de gestion des Threads sur Android, pourquoi ne pas essayer @Background et @UiThread sur AndroidAnnotations ?

hardwareAccelerated

Pensez à activer le flag suivant dans votre manifest :

android:hardwareAccelerated="true"

Cela permet de bénéficier de l’accélération matérielle pour le rendering, gratos. Il est désactivé par défaut car certaines implémentations dessinant via des canvas peuvent ralentir ou faire crasher votre appli.

Ce n’est normalement pas le cas des composants standards. Comment décider s’il faut l’utiliser ? C’est simple :

• Activez hardwareAccelerated
• Testez votre application sur Honeycomb. Si elle ne plante pas, c’est bon, vous pouvez dormir tranquille!

Renderscript

Renderscript est une nouvelle API C permettant de faire du 3D rendering haute performance. Nouvelle… pas tant que ça! Si j’ai bonne mémoire, Romain Guy nous présentait déjà Renderscript au précédent Android Dev Lab, il y a de cela deux ans. Bon, il est vrai que l’API n’a probablement plus rien à voir (initialement, ça n’était même pas du C), seul le concept reste identique.

Les applications Google Books et YouTube utilisent renderscript : Google Books pour tourner les pages, et YouTube pour l’écran avec toutes les vidéos visibles en même temps.

Développement pour tablettes, quelques règles simples

• Mesurer en dp plutôt qu’en pixels
• Utiliser des layouts extensibles
• Centraliser les dimensions dans dimens.xml, de façon à pouvoir les overrider grâce au mécanisme de ressources
• Supporter le mode paysage et ne pas bloquer en mode portrait. N’oubliez pas que la manière d’utiliser une tablette est essentiellement en paysage. Beaucoup d’application ont un écran de chargement de l’application en portrait, ce n’est pas très malin !

Mettre à jour votre application pour Honeycomb

• Ajoutez des graphiques pour les hautes résolutions (xhdpi)
• Utilisez des fragments, même pour les anciennes versions d’Android (grâce à la compatibility library)
• N’oubliez pas d’ajouter <uses-sdk android:targetSdkVersion="14" /> dans votre manifest, notamment pour bénéficier automatique de la nouvelle Action bar sur Honeycomb

Voilà qui conclu la première moitié de ce compte rendu sur l’Android Dev Lab, je vous conterai la fin de cette journée lors du prochain article.

Lorsqu’une branche qui a fait l’objet d’une pull request est validée, elle est mergée sur la branche d’intégration. Nous n’avons cependant pas pris l’habitude de supprimer ces branches une fois mergées. Je pense que nous aurions probablement du les supprimer au fur et à mesure, car nous nous retrouvons aujourd’hui avec de nombreuses branches mergées, qui ne servent à rien et qui polluent nos repository.

Branches konary by Krzysztof

Notez que GitHub conserve l’historique des pull request même quand les branches sont supprimées. Je ne vois vraiment aucune raison de conserver des branches mergées. Et vous ?

Quoi qu’il en soit, il est tout à fait possible de corriger cela, en quelques commandes Git bien senties.

On récupère toutes les données du repository remote

git fetch --all

On supprime de notre repository local toutes les branches remote qui n’existent plus

git remote prune origin

Valor prune by Glysiak

On compte toutes les branches remote mergées :

git branch -r --merged origin/integration | wc -l

Vous l’aurez noté, wc -l est une commande Unix permettant de compter le nombre de lignes du flux d’entrée. Ainsi, on pourrait l’utiliser pour compter le nombre de branches du repository remote :

git branch -r | wc -l

Il n’y a plus qu’à supprimer les branches mergées :

# Supprimer la branche sur le remote
git push origin :my_branch
# Et supprimer la branche qui la track en local
git branch -d my_branch

Notez aussi que GitHub met à disposition ce listing sans avoir à entrer une seule ligne de commande, en cliquant sur Branches.

Pour finir : si lister les branches mergées permet de faire le ménage, à l’inverse il peut être intéressant de prendre connaissance des branches non mergées, car il se peut que certaines d’entre elles aient été oubliées et soient à l’abandon. Pour cela, rien de plus simple :

git branch -r --no-merged origin/integration

On reproche souvent aux applications Android d’être… moches. Et ce serait la faute du framework Android, qui fournirait des composants qui n’ont pas la Apple sexy touch. Peut-être est-ce le cas, mais faudrait voir à ne pas être trop paresseux.

Prenons le cas des boîtes de dialogue. A priori, il n’y a rien de plus ennuyeux, et rien ne ressemble plus à une boîte de dialogue… qu’une autre boîte de dialogue. Sauf si vous décidez de changer leur style graphique, ce qui risque d’une part de perdre vos utilisateurs, et d’autre part de vous demander du boulot.

Je vous propose d’aborder quelques techniques simples pour donner un peu de vie à vos boîtes de dialogues, sans trop vous fatiguer.

Dialogue fadasse

Voici un exemple classique de boîte de dialogue :

new AlertDialog.Builder(this)
		.setMessage("Un message pas sexy")
		.setPositiveButton(android.R.string.ok, new DialogInterface.OnClickListener() {
			public void onClick(DialogInterface dialog, int which) {
				// Do something
			}
		})
		.show();

Une vue custom

Je vous propose de personnaliser le message affiché par notre boîte de dialogue. Plutôt que setMessage(), il suffit d’appeller setView(), qui prend en paramètre n’importe quel type de View.

Par exemple une TextView, définie ici dans un layout :

<?xml version="1.0" encoding="utf-8"?>
<TextView
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="fill_parent" 
    android:layout_height="wrap_content" 
    android:textSize="30sp"
    android:padding="20dp"
    />

Ensuite, il suffit de gonfler (inflate ) ce layout, et de le définir comme vue de la boîte de dialogue :

TextView messageView = (TextView) View.inflate(this, R.layout.dialog, null);
messageView.setText("Un message à peine plus sexy");

new AlertDialog.Builder(this) //
		.setView(messageView) //
		.setPositiveButton(android.R.string.ok, new DialogInterface.OnClickListener() {
			@Override
			public void onClick(DialogInterface dialog, int which) {
				// Do something
			}
		}) //
		.show();

Et voilà le travail :

Un peu de style

Dans un précédent article, nous avons découvert Html.fromHtml() qui se marie très bien avec une TextView. Mettons-le à profit :

TextView messageView = (TextView) View.inflate(this, R.layout.dialog, null);
CharSequence message = Html.fromHtml("I like <b>sexy</b> <font color=\"#42dd42\">turtles</font>!");
messageView.setText(message);

Évidemment, c’est mieux avec l’i18n, ajoutons donc une entrée à strings.xml :

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <!-- ... -->
    <string name="dialog_message"><![CDATA[I like <b>sexy</b> <font color="#42dd42">turtles</font>!"]]></string>
</resources>

Et notre code devient :

CharSequence message = Html.fromHtml(getString(R.string.dialog_message));

Et avec une photo sexy ?

Saviez-vous que Html.fromHtml() supporte la balise img, et permet de charger des images locales, grâce à un ImageGetter ?

Ajoutons une image à notre message :

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <!-- ... -->
    <string name="dialog_message"><![CDATA[I like <img src="turtle" /> <b>sexy</b> <font color=\"#42dd42\">turtles</font>!"]]></string>
</resources>

Ainsi que la ressource correspondante :

Il n’y a plus qu’à créer un ImageGetter qui sait charger un Drawable à partir de son nom de ressource :

ImageGetter imageGetter = new ImageGetter() {
	@Override
	public Drawable getDrawable(String source) {
		String name = source.replace("/", "");
		Resources resources = getResources();
		int drawableId = resources.getIdentifier(name, "drawable", getPackageName());
		if (drawableId != 0) {
			Drawable drawable = resources.getDrawable(drawableId);
			drawable.setBounds(0, 0, drawable.getIntrinsicWidth(), drawable.getIntrinsicHeight());
			return drawable;
		} else {
			return null;
		}
	}
};

CharSequence message = Html.fromHtml(getString(R.string.dialog_message), imageGetter, null);

Et le tour est joué :

turtle's head by Betta.1

Conclusion

Ces quelques lignes de code permettent de rapidement mettre en avant les informations importantes au sein d’une boîte de dialogue, sans pour autant déstabiliser l’utilisateur.

Bien entendu, l’abus de boîte de dialogues est dangereux pour la santé mentale des utilisateurs, à afficher avec modération !

Il est généralement admis qu’utiliser un système de gestion de version (décentralisé de préférence) pour le code d’un projet est une bonne chose.

Mais qu’en est-il des documents de spécifications fonctionnelles et techniques ? Loin de l’approche monolithique du cycle en V, les adeptes des méthodes agiles ont à coeur de faire évoluer ces documents très fréquemment. D’aucuns pourraient penser que les posts-it de Scrum remplacent avantageusement tout document de spécification…

Archaeological post-it label by Evelyn Simak

Versionner les spécifications

N’oubliez pas, être agile ne constitue pas une excuse pour ne pas écrire de documentation. Pareil pour le design émergeant. Bien au contraire, il est d’autant plus important de consigner et conserver le savoir fonctionnel et technique.

Steacie Science and Engineering Library at York University, by Raysonho@Open Grid Scheduler

Vous qui posez un tag sur votre code dans votre système de gestion de version (VCS) lors d’une nouvelle release, êtes-vous capables de retrouver plus tard les spécifications fonctionnelles et techniques correspondant à cette release ?

Un moyen simple pour y parvenir est d’héberger ces documents dans le même VCS que le code. Ainsi, tout tag/branche contiendra automatiquement la bonne version des spécifications.

Diff de specs ?

Allons plus loin : un VCS n’a pas pour seul but de conserver l’historique d’un projet ; il permet aussi d’appréhender les changements réalisés, grâce aux outils de diff. C’est évidemment essentiel pour assembler le travail parallèle des différents développeurs, pour comprendre l’origine d’un bug, pour toute revue de code, etc.

Le problème des outils de diff est qu’ils fonctionnent très bien pour tout ce qui est textuel, et beaucoup moins bien lorsqu’ils ont affaire à des fichiers binaires. Malheureusement, les documents de spécifications sont bien souvent des fichiers Word ou LibreOffice, qui entrent dans cette catégorie.

Il existe pourtant un format textuel tout à fait adapté: Markdown. La syntaxe de ce langage est réellement accessible, même pour les membres non techniques de votre équipe :

# Titre du document
## Mon sous titre

Un paragraphe contenant un [lien absolu](http://www.google.com), un
[lien relatif](../autrePage), et une ![image](image.png).

* une liste à puces
* avec une sous liste
  * contenant un élément *en italique*
  * et un élément **en gras**

De plus, les documents Markdown peuvent aisément être visualisés en HTML ou PDF, si vous ne disposez pas d’un éditeur dédié. Il existe même des scripts pour convertir de l’ODT en Markdown.

Bref, vous n’avez aucune excuse valable .

Retour d’expérience

Chez Siine, nous hébergeons nos projets sur GitHub, et chaque User Story fait l’objet d’une branche dédiée.

Les spécifications fonctionnelles et techniques relatives à une User Story sont écrites en Markdown, sur la branche dédiée à cette User Story.

Lorsque la User Story est prête à être intégrée sur la branche de développement, le développeur crée une pull request. Il suffit alors d’ouvrir l’onglet Diff de la pull request pour tout de suite identifier les changements fonctionnels et techniques introduits par cette User Story.

Diagrammes

Tous les fichiers binaires ne peuvent pas forcément être remplacés par des fichiers textuels ; c’est le cas des diagrammes techniques.

A moins que… en êtes-vous si sûr ?

websequencediagrams.com et yuml.me vous proposent d’exprimer le contenu de vos diagrammes sous forme de texte, et se chargent de générer l’image correspondante.

websequencediagrams

websequencediagrams permet de générer des diagrammes de séquence, et offre même le luxe de choisir le style utilisé.

UI->StuffManager: doSomeStuff()
note over StuffManager: HandlesStuff
activate StuffManager
StuffManager->DataStore:gimmeDaStuff()
activate DataStore
DataStore->StuffManager:
deactivate DataStore
StuffManager->DataStore:updateDaStuff()
activate DataStore
DataStore->StuffManager:
deactivate DataStore
StuffManager-->UI:
deactivate StuffManager

yUML

yUML permet de générer des diagrammes UML de classe, d’activité, et de cas d’utilisation.

[Activity]^[MyActivity]
[MyActivity]-[note: I like turtles!]
[Step]^[FirstStep]
[Step]^[SecondStep]
[Step]^[FinalStep]
[MyActivity]++->[StateHolder]
[MyActivity]++-*>[Step]
[FirstStep]+->[StateHolder]
[SecondStep]+->[StateHolder]

Connaissez-vous d’autres outils bien pratiques de ce type ?

La startup pour laquelle je bosse depuis peu héberge son code source sur GitHub, et ça, c’est carrément cool.

En plus, nous sommes récemment passé d’un workflow old school (tout le monde commit comme des sauvages sur la même branche) à un workflow de type feature branching. Encore plus cool !

Le merge d’une feature branch sur la branche d’intégration ne se fait qu’après validation (revue de code et tests fonctionnels) par quelqu’un qui n’a pas développé la feature. Dans cette optique, les pull requests de GitHub se révèlent particulièrement pratiques.

Mais trêve de bavardage, venons-en à l’objet de cet article.

Roooh, j’ai encore oublié ma branche Git !

Avec le feature branching, on se retrouve à changer fréquemment de branche.

Du coup, j’ai tendance à ne plus savoir sur quelle branche je me trouve, ou encore à oublier le nom précis de la branche, et à taper git branch toutes les trois commandes.

Un membre de l’équipe nous a envoyé un script plutôt pratique, qui ajoute le nom de la branche en cours au prompt de votre terminal :

Le petit truc cool en plus, c’est que le nom s’affiche en rouge si vous avez des modifications locales (dirty working tree), et en vert dans le cas contraire.

Instructions à ajouter à votre fichier ~/.bashrc (ou ~/.profile sur Mac) :

# git branch name in prompt
c_red=`tput setaf 1`
c_green=`tput setaf 2`
c_sgr0=`tput sgr0`

parse_git_branch () {
  if git rev-parse --git-dir >/dev/null 2>&1
  then
          gitver=$(git branch 2>/dev/null| sed -n '/^\*/s/^\* //p')
  else
          return 0
  fi
  echo -e "($gitver) "
}

branch_color () {
        if git rev-parse --git-dir >/dev/null 2>&1
        then
                color=""
                if git diff --quiet 2>/dev/null >&2
                then
                        color="${c_green}"
                else
                        color=${c_red}
                fi
        else
                return 0
        fi
        echo -ne $color
}

PS1="\[\$(branch_color)\]\$(parse_git_branch)\[$(tput sgr0)\]$PS1"

Dans le même ordre d’idée, voici un article bien pratique pour disposer de l’autocomplétion des noms de branches.

À vous, partagez vos astuces !

Avant de vous jeter sur Photoshop pour créer des images correspondant au pixel près à ce qu’ils attendent, pourquoi ne pas garder votre bonne vieille TextView ?

Pour changer un peu des récents articles sur GWT, voici quelques petites astuces pour Android.

Tweak la police

Par défaut, Android ne propose que trois polices de caractères pour les TextView : monospace, sans et serif.

Toutefois, il est tout à fait possible d’utiliser votre police préférée, à condition de l’embarquer dans votre application.

Il suffit de copier la police dans le répertoire assets de votre projet Android, puis de la charger au Runtime :

@Override
protected void onCreate(Bundle savedInstanceState) {.
  super.onCreate(savedInstanceState);

  setContentView(R.layout.main);
  TextView myTextView = (TextView) findViewById(R.id.myTextView);

  Typeface myFont = Typeface.createFromAsset(getAssets(), "MyFont.otf");
  myTextView.setTypeface(myFont);
}

Il n’est pas possible de le faire directement dans votre fichier de layout, sauf en créant des composants alternatifs.

Stylé !

Votre texte doit comporter des morceaux en couleur, en italique… ; bref, il doit être mis en forme.

Avant d’envisager la création d’une TextView pour chaque morceau de texte différent, jetez un oeil à Spannable, et surtout à son cousin germain Html.

Html.fromHtml() retourne un Spanned, qui peut être utilisé pour définir le contenu d’une TextView.

Par exemple :

Spanned spanned = Html.fromHtml("Hello <b>World</b>!")
myTextView.setText(spanned);

Bien entendu, une String en dur dans le code, c’est moche (pas très i18n).

Pour y remédier, il suffit d’encadrer dans un CDATA le texte contenant le markup Html, au sein de vos fichiers de ressources.

Exemple de res/values/strings.xml :

<?xml version="1.0" encoding="utf-8"?>
<resources>
  <string name="styled_content"><![CDATA[I like turtles!<br />Hello <font color="#99cc33"><b>World</b></font>!]]></string>
</resources>

Malheureusement, vous ne pouvez pas utiliser ces ressources directement dans vos fichiers de layout ; il faut en passer par du code Java :

@Override
protected void onCreate(Bundle savedInstanceState) {.
  super.onCreate(savedInstanceState);

  setContentView(R.layout.main);
  TextView myTextView = (TextView) findViewById(R.id.myTextView);

  myTextView.setText(Html.fromHtml(getString(R.string.styled_content)));
}

Notez que le support du HTML reste limité (nombre de balises supportées, HTML mal formé, balises les unes dans les autres…)

Bonus

• Linkify permet de créer des TextViews contenant des liens cliquables de toute sorte. A ce sujet, je vous recommande l’excellent article disponible sur la doc Android.
• Quels liens entre design Web et design Android ? Un article tout récent sur le blog Android aborde le sujet.

Craquer une clé WEP peut être l’affaire de quelques minutes, et pourtant, aujourd’hui encore, de très nombreux réseaux Wifi de particuliers sont protégés par WEP. Même le New York Times en parle. Faites passer le mot, il faut que cela change.

Les techniques pour y parvenir se sont considérablement améliorées ces dernières années. Parallèlement à ces techniques, c’est aussi leur facilité de mise en œuvre qui a formidablement évolué.

Aujourd’hui, quelques clics suffisent : même mamie peut craquer du Wifi, et c’est l’objet de cet article.

Mise en place

Matos

En termes de matériel, une carte Wifi suffit. La plupart des cartes conviennent et disposent aujourd’hui de drivers adaptés.

Vous obtiendrez de très bons résultats avec l’Alfa AWUS036H, a priori la carte la plus puissante du marché (1000mW). Attention par contre, il me semble qu’elle est interdite à la vente en France, effet micro onde garanti .

OS

Les drivers patchés pour le crack Wifi sont essentiellement disponibles sous Linux. Plus précisément, la distribution Backtrack contient tout le nécessaire. Elle est disponible en Live CD et en Live USB.

Version mamie : vous trouvez une clé USB avec quelques gigas de libres ; vous suivez ce tutoriel ; vous branchez la clé USB ; et vous redémarrez pour booter sur la clé USB (cf. ce tutoriel > Modifier l’ordre de boot).

Backtrack démarre, se logue tout seul, et présente une ligne de commande une fois démarré.

Il suffit de taper startx pour lancer l’environnement graphique.

root@root:~# startx

Une fois l’environnement graphique démarré, vous pouvez changer le layout de clavier dans System > Preferences > Keyboard > Layouts.

Wifite : à un clic du crack

Le plus dur est fait ! Il ne vous reste plus qu’à récupérer Wifite et le lancer.

Téléchargez le script python à cette adresse : http://wifite.googlecode.com/svn/trunk/wifite.py.

Rendez-le exécutable : chmod +x ; ou bien clic-droit sur le fichier, sélectionnez Properties > Permissions et cochez
z Execute: Allow executing file as program.

Exécutez le script (double clic sur le fichier > Run).

Et hop, une bonne grosse interface à la clicouille :

Sélectionnez l’interface réseau à utiliser (en général, il n’y en a qu’une). Étant donné que l’on s’intéresse ici au WEP, vous pouvez sélectionner uniquement WEP dans encryption type.

De nombreux paramètres sont disponibles, mais pour mamie, il suffit de cliquer sur h4x0r 1t n40, et d’aller prendre une tisane.

Wifite se charge de tout, et note les mots de passe crackés dans le fichier log.txt créé à côté du script wifite.py.

Bingo !

Toujours pour Rockslide, je souhaitais pouvoir écrire le code à mettre en forme dans des templates UiBinder, plutôt que dans des Strings statiques portées par des classes Java.

Est-ce possible ? Comment y parvenir ? En creusant ces questions, j’ai réalisé que UiBinder possède de nombreuses facettes non documentées et qui méritent que l’on s’y attarde. Tour du propriétaire.

Widgets customs

Vous le savez probablement, il est possible d’inclure ses propres widgets GWT dans un template UiBinder.

Il suffit pour cela d’étendre la classe Widget. Prenons l’exemple d’un bouton ouvrant une fenêtre d’alerte :

public class AlertButton extends Button implements ClickHandler {

	public AlertButton() {
		addClickHandler(this);
	}

	@Override
	public void onClick(ClickEvent event) {
		Window.alert("I like turtles");
	}
}

Vous pouvez ensuite l’inclure dans vos templates UiBinder, en ajoutant un namespace correspondant au package de votre widget :

<ui:UiBinder
    xmlns:ui='urn:ui:com.google.gwt.uibinder'
    xmlns:g='urn:import:com.google.gwt.user.client.ui'
    xmlns:custom='urn:import:info.piwai.blog.ui'
>

	<g:FlowPanel>
		<custom:AlertButton />
	</g:FlowPanel>

</ui:UiBinder>

Un peu limité quand même…

Et avec des paramètres ?

Il y a mieux ! Vous pouvez tout à fait passer des paramètres à votre widget. Il suffit d’ajouter des paramètres de constructeur (donc obligatoires) ou des setters (donc facultatifs) à votre widget :

public class AlertButton extends Button implements ClickHandler {

	private final String msg;

	@UiConstructor
	public AlertButton(String msg) {
		this.msg = msg;
		addClickHandler(this);
	}

	@Override
	public void onClick(ClickEvent event) {
		Window.alert(msg);
	}
}

Puis d’utiliser les attributs correspondants dans vos templates UiBinder :

<ui:UiBinder
    xmlns:ui='urn:ui:com.google.gwt.uibinder'
    xmlns:g='urn:import:com.google.gwt.user.client.ui'
    xmlns:custom='urn:import:info.piwai.blog.ui'
>

	<g:FlowPanel>
		<custom:AlertButton msg="I like turtles" />
	</g:FlowPanel>

</ui:UiBinder>

Les attributs, ça pue ?

Si votre widget implémente HasText, vous pourrez alors définir ce texte directement au sein de la balise au lieu d’utiliser des attributs. Modifions AlertButton :

public class AlertButton extends Button implements ClickHandler, HasText {

	private String msg = "Default Message";

	public AlertButton() {
		addClickHandler(this);
	}

	@Override
	public void setText(String msg) {
		this.msg = msg;
	}

	@Override
	public void onClick(ClickEvent event) {
		Window.alert(msg);
	}

	@Override
	public void getText() {
		throw new UnsupportedOperationException();
	}
}

C’est déjà plus sympa :

<ui:UiBinder
    xmlns:ui='urn:ui:com.google.gwt.uibinder'
    xmlns:g='urn:import:com.google.gwt.user.client.ui'
    xmlns:custom='urn:import:info.piwai.blog.ui'
>

	<g:FlowPanel>
		<custom:AlertButton>I like turtles</custom:AlertButton>
	</g:FlowPanel>

</ui:UiBinder>

Quid du HTML ?

Vous pouvez aussi inclure, au sein de vos widgets, du HTML défini dans votre template UiBinder, grâce à HasHTML.

Par exemple, supposons que je souhaite enrichir mon AlertButton pour afficher de belles popups, en utilisant une DialogBox :

public class AlertButton extends Button implements ClickHandler, HasHTML {

	private String html = "";

	private String title = "Default title";

	public AlertButton() {
		addClickHandler(this);
	}

	@Override
	public void setHTML(String html) {
		this.html = html;
	}

	@Override
	public void setTitle(final String title) {
		this.title = title;
	}

	@Override
	public void onClick(ClickEvent event) {
		DialogBox dialogBox = new DialogBox();
		dialogBox.setWidget(new HTML(html));
		dialogBox.setText(title);
		dialogBox.center();
	}

	@Override
	public void getText() {
		throw new UnsupportedOperationException();
	}

	@Override
	public void setText(String text) {
		throw new UnsupportedOperationException();
	}

	@Override
	public String getHTML() {
		throw new UnsupportedOperationException();
	}

}

Je peux désormais spécifier le contenu HTML de cette boîte de dialogue dans mon template UiBinder :

<ui:UiBinder
    xmlns:ui='urn:ui:com.google.gwt.uibinder'
    xmlns:g='urn:import:com.google.gwt.user.client.ui'
    xmlns:custom='urn:import:info.piwai.blog.ui'
>

	<g:FlowPanel>
		<custom:AlertButton title="I like turtles">
			<p>
				I <strong>really</strong> like turtles!<br />
				What about <em>you</em>?
			</p>
		</custom:AlertButton>
	</g:FlowPanel>

</ui:UiBinder>

  ?

Comment utiliser des entités HTML dans vos templates UiBinder ? Il suffit d’ajouter la DTD fournie par Google :

<!DOCTYPE ui:UiBinder SYSTEM "http://dl.google.com/gwt/DTD/xhtml.ent">
<ui:UiBinder
    xmlns:ui='urn:ui:com.google.gwt.uibinder'
    xmlns:g='urn:import:com.google.gwt.user.client.ui'
    xmlns:custom='urn:import:info.piwai.blog.ui'
>

	<g:FlowPanel>
		<custom:AlertButton title="I like turtles">
			<p>
				Turtles &gt; Dolphins!
			</p>
		</custom:AlertButton>
	</g:FlowPanel>

</ui:UiBinder>

Paramètres complexes

<ui:with /> permet d’injecter un objet (créé via GWT.create()) dans votre template UiBinder.

Un exemple d’utilisation serait l’injection d’une Enum afin de paramétrer un widget.

Reprenons notre fenêtre d’alerte initiale :

public class AlertButton extends Button implements ClickHandler {

	private final Animal animal;

	@UiConstructor
	public AlertButton(Animal animal) {
		this.animal = animal;
		addClickHandler(this);
	}

	@Override
	public void onClick(ClickEvent event) {
		Window.alert("I like " + animal.toString());
	}
}

Animal est une simple Enum :

public Enum Animal {
  TURTLES, DOLPHINS;
}

Il ne reste plus qu’à utiliser l’Enum en question dans le template UiBinder :

<ui:UiBinder
    xmlns:ui='urn:ui:com.google.gwt.uibinder'
    xmlns:g='urn:import:com.google.gwt.user.client.ui'
    xmlns:custom='urn:import:info.piwai.blog.ui'
>
	<ui:with field="animal" type="info.piwai.blog.Animal"/>

	<g:FlowPanel>
		<custom:AlertButton animal="{animal.TURTLES}" />
	</g:FlowPanel>

</ui:UiBinder>

Bon, et la coloration syntaxique alors ?

En combinant tout ce qui a été dit précédemment, il est possible d’écrire des exemples de code au sein de templates UiBinder, mis en forme par SyntaxHighlighter. On utilisera pour cela un widget implémentant HasHTML.

Avant de passer aux choses sérieuses, un rappel. Dans l’article précédent, nous utilisions le code suivant pour faire de la coloration syntaxique en GWT :

public void bindTextAreaCodeToHtml(TextArea textArea, HTML html) {
    JavaScriptObject brush = BrushFactory.newJavaBrush();
    String code = textArea.getValue();
    String htmlCode = SyntaxHighlighter.highlight(code, brush, false);
    html.setHTML(htmlCode);
}

Une précision : Le parseur UiBinder utilisé pour les widgets implémentant HasHTML ne garde pas les retours à la ligne, ce qui se révèle gênant lorsque son contenu est du code mis en forme. Pour contourner cela, on peut utiliser une balise <pre> dans le template UiBinder.

Trêve de suspens, voici le résultat :

public class Code extends Composite implements HasHTML {

	private JavaScriptObject brush = null;

	private HTML panel = new HTML();

	@UiConstructor
	public Code() {
		initWidget(panel);
	}

	public void setBrush(JavaScriptObject brush) {
		this.brush = brush;
	}

	@Override
	public void setHTML(String html) {
		// On supprime la balise <pre>
		final String code = html.replaceFirst("<pre>", "").replaceFirst("</pre>", "");
		Scheduler.get().scheduleDeferred(new ScheduledCommand() {
			@Override
			public void execute() {
				if (brush != null) {
					String codeAsHtml = SyntaxHighlighter.highlight(code, brush, false);
					panel.setHTML(codeAsHtml);
				}
			}
		});
	}

	@Override
	public void getText() {
		throw new UnsupportedOperationException();
	}

	@Override
	public void setText(String text) {
		throw new UnsupportedOperationException();
	}

	@Override
	public String getHTML() {
		throw new UnsupportedOperationException();
	}

}

On peut ensuite utiliser ce widget dans un template UiBinder classique :

<!DOCTYPE ui:UiBinder SYSTEM "http://dl.google.com/gwt/DTD/xhtml.ent">
<ui:UiBinder
    xmlns:ui='urn:ui:com.google.gwt.uibinder'
    xmlns:g='urn:import:com.google.gwt.user.client.ui'
    xmlns:custom='urn:import:info.piwai.blog.ui'
>

	<ui:with field="brushFactory" type="info.piwai.blog.BrushFactory"/>

	<g:FlowPanel>
		<custom:Code brush="{brushFactory.newJavaBrush}"><pre>
			public class Main {
				public static void main(String[] args) throws Exception {
					List&lt;String&gt; moto = Arrays.asList("I", "Like", "Turtles");
					System.out.println(moto);
				}
			}</pre>		
		</custom:Code>
	</g:FlowPanel>

</ui:UiBinder>

Edit : Merci @matboniface, j’avais au départ parlé d’échapper des entités HTML, ce qui n’a pas beaucoup de sens.

Conclusion

Cet article s’est révélé plus long que ce que j’avais en tête initialement ! J’espère qu’il vous aura fait découvrir des aspects intéressants et souvent méconnus de UiBinder.

N’hésitez pas à compléter ce billet avec vos trucs et astuces UiBinder en commentaire !

Vous pouvez aussi vous abonner au flux RSS. Je me suis fixé comme objectif de publier un article par semaine, on verra si je tiens le rythme .

Qui dit slides techniques dit exemples de code, et donc coloration syntaxique.

J’ai creusé un peu le sujet pour finalement retenir une solution.

Comment faire de la coloration syntaxique côté client, en GWT ?

Solutions disponibles

A ma connaissance, il n’existe pas de solution de coloration syntaxique spécifique à GWT, ce qui nous laisse trois options :

• Implémenter une solution en GWT (c’est mort, je n’ai pas que ça à faire)
• Trouver une solution en Java et adapter la partie graphique (fausse bonne idée)
• Trouver une solution en Javascript et réaliser un binding GWT (ça, c’est dans mes cordes)

Un rapide tour d’horizon fait ressortir deux frameworks Javascript très utilisés pour la coloration syntaxique :

• highlight.js
• SyntaxHighlighter

Les deux semblent maintenus, des releases récentes sont disponibles. Mon choix se porte sur SyntaxHighlighter, qui semble plus beau. C’est purement subjectif, mais je trouve que le code mis en couleur par highlight.js a un petit air vieillot.

gwt-syntaxhighlighter

Coup de bol : je tombe sur gwt-syntaxhighlighter, une intégration assez poussée de SyntaxHighlighter dans GWT.

Trop poussée, hélas :

• gwt-syntaxhighlighter utilise des Generators, ce qui allonge le temps de compilation,
• gwt-syntaxhighlighter comporte quelques bugs qui ne sont pas corrigés et qui sont difficiles à contourner,
• la version de SyntaxHighlighter utilisée n’est pas à jour (les versions récentes apportent pourtant des évolutions intéressantes).

De plus, il s’avère que l’intégration de SyntaxHighlighter est relativement aisée, beaucoup plus simple que ce que tente de faire gwt-syntaxhighlighter.

Intégration GWT de SyntaxHighlighter

Charger les scripts et les CSS

Tout d’abord, il faut télécharger SyntaxHighlighter. Les dossiers scripts et styles contiennent tout ce dont vous aurez besoin.

Ces fichiers devront être inclus dans l’application GWT. Il existe différentes méthodes. J’ai choisi de créer un répertoire public au même niveau que le répertoire client, et d’y placer les répertoires scripts et styles.

Ensuite, il suffit de les ajouter au module (fichier .gwt.xml) :

<?xml version="1.0" encoding="UTF-8"?>
<module>

    <!-- La CSS de base pour SyntaxHighlighter -->
    <stylesheet src="styles/shCore.css"/>

    <!-- J'utilise le thème Eclipse (8 thèmes disponibles) -->
    <stylesheet src="styles/shThemeEclipse.css"/>

    <!-- Le javascript de base pour SyntaxHighlighter -->
    <script src="scripts/shCore.js"/>

    <!-- Les extensions pour les différents langages utilisés -->
    <script src="scripts/shBrushJava.js"/>
    <script src="scripts/shBrushXml.js"/>

    <!-- [...] -->
</module>

Go, Go, GO!

A l’origine, SyntaxHighlighter fonctionnait en parsant le DOM et en modifiant les nœuds marqués comme conteneurs de code. La dernière release propose une approche alternative, qui fonctionne indépendamment du DOM.

Le fonctionnement est simple : une fonction Javascript prend en entrée du code sous forme de String, et renvoie une String contenant le HTML pour afficher le code formaté.

Un brush (pinceau) est nécessaire pour colorer du code. Il existe en fait un brush par langage, et celui-ci définit les mots clés, la syntaxe, etc.

Il nous faut donc une fabrique de pinceaux :

public class BrushFactory {
    public native JavaScriptObject newJavaBrush() /*-{
        return new $wnd.SyntaxHighlighter.brushes.Java();
    }-*/;

    public native JavaScriptObject newXmlBrush() /*-{
        return new $wnd.SyntaxHighlighter.brushes.Xml();
    }-*/;
}

Voici le code JSNI utilisant SyntaxHighlighter pour transformer du code en html :

public class SyntaxHighlighter {
    public static native String highlight(String code, JavaScriptObject brush, boolean toolbar) /*-{
        var params = {};
        params['toolbar'] = toolbar;
        brush.init(params);
        return brush.getHtml(code);
    }-*/;
}

Ya plus qu’à utiliser tout ça, par exemple en récupérant le code contenu dans une TextArea et en l’affichant via un HTML.

public void bindTextAreaCodeToHtml(TextArea textArea, HTML html) {
    JavaScriptObject brush = BrushFactory.newJavaBrush();
    String code = textArea.getValue();
    String htmlCode = SyntaxHighlighter.highlight(code, brush, false);
    html.setHTML(htmlCode);
}

Conclusion

Vous avez désormais toutes les clés en main pour faire de la coloration syntaxique côté client en GWT.

Bien entendu, ce code est à adapter suivant vos besoins. Vous n’êtes pas obligés d’utiliser des static partout .

La longueur maximale des lignes de code est un débat récurrent dans les équipes de développement.

Dès lors que l’on met en place un formatage du code automatique et partagé par tous les développeurs (notamment pour faciliter les diff), l’éternelle question revient :

80 ou 120 ?

Ça fait 5 ans qu’on a tous des 19 pouces, on pourrait peut-être passer à 160 non ?

Que nenni !

Voici la configuration que j’utilise :

Vous avez bien lu, je préfère 1000. Ou 2000. Ou 10000. Ou… bon, je suppose que vous avez compris.

Non pas que j’ai la chance de disposer d’un écran de cinéma pour coder, pour moi il s’agit juste de bonnes pratiques.

Ce n’est pas votre IDE qui doit décider de la longueur de vos lignes de code, c’est vous.

Une ligne de code qui dépasse la largeur de l’écran, c’est un code smell. Laisser l’IDE ajouter des retours à la ligne, c’est cacher le code smell.

Un peu comme mettre du déo sans se doucher après un jogging.

Pour la route, quelques cas classiques de longlignite aigüe :

Le syndrome du développeur C, aka le radin des variables

A l’origine, en C, il fallait déclarer toutes les variables locales d’une procédure au début de celle-ci. Ce n’est pas forcément une mauvaise idée.

Mais en combinant cela avec l’idée qu’une variable locale, c’est forcément de la mémoire utilisée en plus et donc de la “performance” en moins, on prend rapidement la bonne habitude de créer le moins de variables locales possibles.

Un exemple de la vraie vie :

WebApplicationContextUtils.getWebApplicationContext(this.getServletContext()).getAutowireCapableBeanFactory().autowireBeanProperties(this, AutowireCapableBeanFactory.AUTOWIRE_BY_TYPE, true);

Vous trouvez-ça lisible vous ?

C’est peut-être super excitant à écrire (ah ça c’est sûr on est fier hein, on a utilisé aucune variable…). Et PAN, +10000€ de dette technique.

La solution est simple, elle s’appelle la variable locale. Découpez votre code, créez des variables locales même si elles ne servent qu’une fois. Et découpez votre code en petites méthodes.

Moins de 5 lignes, c’est bien. Au passage, je vous recommande chaudement la lecture de Clean Code .

On comprend déjà mieux :

ServletContext servletContext = this.getServletContext();
WebApplicationContext applicationContext = WebApplicationContextUtils.getWebApplicationContext(servletContext);
AutowireCapableBeanFactory beanFactory = applicationContext.getAutowireCapableBeanFactory();
beanFactory.autowireBeanProperties(this, AutowireCapableBeanFactory.AUTOWIRE_BY_NAME, true);

Le fan de programmation fonctionnelle

Le mec, un jour, il a découvert Google Guava et ses Function ; il a trouvé ça trop cool et a adopté le “style fonctionnel” dans tous ses développements. Malheureusement, en Java, cela se traduit par des classes anonymes (à moins d’utiliser FJF… pub ), et cela déborde vite de l’écran !

Encore un exemple de la vraie vie, un peu maquillé et allégé pour l’occasion :

public class MyPanel extends Composite {
	public MyPanel() {
		final Request request = new Request();

		initWidget(new VerticalPanel() {
			{
				add(new HorizontalPanel() {
					{
						add(new RadioButton("native", "native") {
							{
								setValue(request.isNativeRequest());
								addClickHandler(new ClickHandler() {

									public void onClick(ClickEvent event) {
										request.setNativeRequest(getValue());
									}
								});
							}
						});
					}
				});
				add(new Button("Run", new ClickHandler() {
					public void onClick(ClickEvent event) {
						ServicesHolder.requestService.execute(request, new AsyncCallback<Response>() {

							public void onFailure(Throwable caught) {
								Window.alert(caught.getMessage());
							}

							public void onSuccess(Response response) {
								try {
									updateUi(response);
								} catch (Exception e) {
									onFailure(e);
								}
							}
						});
					}
				}));
			}
		});
	}
}

Quand je tombe sur une classe qui comporte 1000 lignes comme ça, j’ai beaucoup de mal à suivre le flux d’exécution. Pas vous ?

L’utilisation d’une Fluid interface

Les Fluid interfaces, par design, sont faites pour permettre les appels chaînés, afin d’augmenter la lisibilité du code et éventuellement créer des DSL.

Si la chaîne d’appels de méthode est courte et a un sens grammatical, il paraît alors sensé de la laisser sur une ligne, sans que l’IDE ne formate cette ligne.

Exemple avec un binding Guice :

bind(Geek.class).annotatedWith(Piwai.class).toInstance(piwai);

Par contre, si la chaîne d’appels est trop longue, à vous de la découper à votre goût sur plusieurs lignes.

Une astuce simple consiste à ajouter “//” en fin de ligne, pour empêcher l’IDE de recoller ensemble des appels de méthodes que l’on a décidé de séparer.

Par exemple, pour utiliser un SharedPreferences helper généré par AndroidAnnotations:

prefs.edit() //
  .clear() //
  .name().put("John Smith") //
  .age().put(42) //
  .done();

A vous maintenant : qui a d’autres exemples de longlignite aigüe ?