Connaissez-vous l’histoire de l’exception dont on a perdu trace ?
Vous le savez probablement, chaque service GWT-RPC est en réalité une servlet. Petit rappel :
- les appels Ajax GWT-RPC sont réalisés en POST,
- le nom de la méthode du service à appeler est spécifié dans la requête envoyée,
- l’appel est traité dans la méthode
doPost(HttpServletRequest request, HttpServletResponse response), qui se charge de désérialiser les paramètres, faire appel à la bonne méthode du service par réflexion, puis sérialiser la réponse.
Que se passe t’il lorsque la méthode du service jette une exception ? Deux possibilités :
- soit l’exception est déclarée dans l’interface du service, et celle-ci sera sérialisée jusqu’au client, qui pourra la traiter correctement,
- soit ce n’est pas le cas (y compris pour les
RuntimeException), et le client recevra une erreur 500, et le tristement célèbre :
The call failed on the server; see server log for details
Lire la suite…
Le framework GWT met à disposition du développeur plusieurs API pour communiquer avec un serveur en HTTP.
L’une des possibilités offertes est l’utilisation du framework deRPC, présent depuis GWT 2.0. Cette nouvelle implémentation de GWT RPC est top moumoute, à tel point que Sami Jaber, dans son (très bon) livre Programmation GWT 2, considère l’ancienne API comme dépréciée et invite à utiliser uniquement deRPC.
Alors, faut-il adopter deRPC les yeux fermés ? Attention malheureux ! DeRPC peut considérablement augmenter la taille de vos requêtes HTTP.
Au cours d’une mission, j’ai ainsi découvert la multiplication par 50 de la taille d’une requête, de 200 Ko à 10 Mo.
Lire la suite…
Disclaimer : cet article contient des switch, et pourrait donc heurter la sensibilité d’un public non averti. Je tiens à décliner toute responsabilité en cas de switchite aiguë consécutive à une pratique trop assidue d’Android.
Développeurs Android, avez-vous remarqué à quel point votre code utilise des int comme identifiant à tout bout de champ ?
Il n’est pas rare de devoir écrire le code suivant :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
| public class MyActivity extends Activity {
private static final int WARNING_DIALOG = 0;
private static final int DOWNLOAD_PROGRESS_DIALOG = 1;
private static final int CONFIRM_LOGOUT_DIALOG = 2;
public void iCanHasCheezburger() {
showDialog(WARNING_DIALOG);
}
@Override
protected Dialog onCreateDialog(int id) {
switch (id) {
case WARNING_DIALOG:
return createWarningDialog();
case DOWNLOAD_PROGRESS_DIALOG:
return createDownloadProgressDialog();
case CONFIRM_LOGOUT_DIALOG:
return createConfirmLogoutDialog();
default:
return null;
}
}
// [...]
} |
Cette manière de faire est d’ailleurs recommandée par le guide de développement Android officiel.
Lire la suite…
Introduction
Dans la lignée des plugins chargés au runtime, je vous propose cette fois-ci d’explorer une seconde voie d’ajout de fonctionnalités au runtime : les Service Provider Interfaces (SPI) couplées à l’utilisation du ServiceLoader du JDK6.
Lire la suite…
Attention : cet atricle n’est pas un atricle sur le cyclimse.[?]
Introduction
Je suis un geek. Comme tout bon geek qui se respecte, mes activités extra-professionnelles incluent entre autre des jeux vidéo et de la programmation (tard le soir en buvant un soda quelconque). Alors quand je peux mélanger deux activités favorites entre elles, c’est chouette. Etant fan de Trackmania Nations, il m’arrive de fouiner dans toute source d’information qui s’y rapporte.
C’est ainsi que j’ai appris que le serveur dédié TrackMania peut être contrôlé à distance par des appels XML-RPC. Evidemment, tout ça me donne envie d’ouvrir mon IDE favori pour faire un HelloWorld en Java et voir un peu les possibilités.
Le HelloWorld ayant évolué un peu plus que je ne l’avais initialement prévu, il s’est vu doté d’un système de plugins chargés dynamiquement (parce que j’avais envie d’explorer ce domaine depuis un certain temps déjà).
Assez raconté ma life, je vais maintenant vous faire part de mes réflexions relatives à la mise en place d’un système de plugins sous forme de JARs, pouvant être chargés/déchargés au runtime, et utilisant des annotations personnalisées.
Lire la suite…
