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…
Aujourd’hui je vais vous présenter un petit truc tout bête pour améliorer les performances d’une application utilisant un ORM, et en particulier de l’affichage d’une page de type back-office.
Problème
Vous avez un problème de performance lors de l’affichage d’une page importante de votre application. La page en question ne contient en gros qu’un tableau de données, avec une vingtaine de colonnes, le tout paginé qui plus est. Un cas assez courant dans les applications de gestion type back-office.
Votre chef vous explique que les utilisateurs seraient plus heureux (plus productifs en tout cas) si la page s’affichait instantanément plutôt qu’en 5 ou 10 secondes. Votre AMOA vous regarde avec pitié et étonnement : elle affiche le même tableau sans soucis dans son Squirrel avec une requête SQL pas très compliquée. Le directeur de projet vous soutient qu’Hibernate/JPA c’est lent et qu’on était mieux en JDBC.
Pour afficher le tableau en question, vous passez par une requête JPA/QL qui sélectionne les entités que vous cherchez (disons Person), puis vous utilisez le graphe d’objets résultant pour afficher la page :
1
| String hql = "select p from Person join fetch ... where p.age > 18 ..."; |
Bien sûr Person est une classe énorme avec toutes les informations imaginables (pays de naissance, nom de l’école maternelle, nom de jeune fille de la grand mère paternelle, …), et vous avez besoin de fetcher des associations en plus pour charger vos informations. L’ORM traduit tout cela en une ou plusieurs requêtes peu efficaces (sous selects, jointures, …) et chargeant beaucoup de données (50 colonnes sur trois tables), dont finalement peu sont utilisées. Lire la suite…
