C’est une possibilité de plus qui confirme la stratégie multi front-end d’Eclipse Scout. En effet la même application peut-être rendue sous différente forme : application desktop, application web et maintenant application web mobile.

Depuis toujours, une idée principale d’Eclipse Scout consiste en une surcouche pour définir l’application qui soit indépendante de toute librairie graphique (SWT ou Swing). Les formulaires ainsi que les champs qu’ils contiennent sont définis dans un modèle d’application qui sera rendu sous forme d’interface graphique à l’exécution. Cette technique permet d’obtenir plusieurs déclinaisons de la même application :

Version SWT :

Version Swing :

Version web :

Le mobile étant une plateforme différente, il a fallu ajouter une étape supplémentaire lors du rendu. Les composants sont adaptés pour tenir compte des spécifiés de la plateforme. Voici quelques exemples :

Smartfield :

Le smartfield est un champ assez puissant : à la manière d’un combo-box, il permet de choisir parmi plusieurs choix. Il est également possible de saisir du texte dans le champ pour réduire les choix proposés. En version mobile, pour reproduire toutes ces possibilités, il a fallu ajouter une vue annexe sur la droite.

Absence de menu contextuel :

L’action proposée dans le menu contextuel apparait sous forme de bouton sous la table.

Représentation des tableaux :

La largeur offerte par le téléphone est limitée. La hauteur des lignes d’un tableau doit être suffisante pour permettre une sélection avec le doigt « sélection touch ». Du coup, les colonnes d’un tableau sont rassemblées sous forme de lignes dans une cellule plus haute. Les colonnes d’une ligne du tableau vont être représentées dans un formulaire annexe accessible en sélectionnant une cellule dans la liste mobile.

L’action principale du menu contextuel (celle qui aurait été proposée en double cliquant sur la ligne du tableau) et qui correspond souvent à l’opération d’édition se retrouve déportée en haut à droite. Les opérations restantes sont disponibles dans un menu supplémentaire.

Masquer certaines fonctionnalités :

Toutes les fonctionnalités ne font pas forcément sens sur mobile. Pour mon application, j’ai décidé de masquer la représentation sous forme graphique (déjà rudimentaire dans la version desktop) en supprimant l’onglet correspondant.

En conclusion

Cette transformation du modèle applicatif permet d’adapter le rendu web aux spécificités du mobile. Évidement l’application obtenue n’est pas aussi efficace qu’un développement dédié, mais le résultat est plus que convainquant par rapport au temps investi.

IQuestionsListProcessService service = SERVICES.getService(IQuestionsListProcessService.class);

Côté client, deux cas se présentent:
* une implémentation est disponible côté client. Dans ce cas elle est retournée par cet appel.
* l’implémentation se trouve côté serveur. Dans ce cas, un proxy est retourné, et l’appel à la fonction est transmis au serveur par Eclipse Scout.

Ce registre de services gère plusieurs implémentations pour une même interface. Il est possible de définir une priorité pour donner un ordre entre les implémentations.

D’où mon idée de septembre dernier de proposer pour chaque service une implémentation se passant de la base de données. Dans ce cas il n’y a plus de persistance des informations, mais dans le cas de démonstration ou de tests cela peut être suffisant.

Je l’ai mis en oeuvre pour mon application MCQS.

Depuis ce commit, je dispose maintenant d’un fragment org.eclipselabs.mcqs.server.nodb.frament qui propose une implémentation des services avec une priorité plus haute. Lorsque le fragment est chargé avec le serveur (ce qui est le cas avec le produit server/products/nodb), ce sont ses implémentations qui ont la priorité.

Ce n’est pas encore tout à fait parfait, car pour faire les choses proprement il ne faudrait pas avoir de dépendance à la base de données dans le plug-in serveur principal, mais dans un deuxième fragment (et utiliser l’un ou l’autre).

Mon fragment NoDB est rudimentaire. Il ne garde rien en mémoire, ce qui devrait être possible.

Dans tous les cas, c’est un bon cas d’exemple de l’annotation @Priority que l’on peut ajouter sur chacun des services.

Par défaut, une application Eclipse Scout contient un certain nombre d’images qui sont des «place-holders» pour l’application finale. Il s’agit de tous les remplacer pour avoir une application à l’apparence correcte.

Splash Screen
Affiché lors du chargement de l’application, il permet à l’utilisateur de savoir qu’il doit patienter et qu’il se passe quelque chose.

Il suffit d’ajouter un fichier splash.xxx à la racine du plug-in de lancement (Swing ou SWT en fonction du moteur de rendu choisi. Pour SWT sans changer les réglages par défaut de l’application RPC, il faudra utiliser un fichier bmp). Ne pas oublier de l’inclure dans le ficher build.properties (dans la catégorie binary build).

Logo
Ce logo (grand) est notamment affiché dans la fenêtre «à propos de cette application».

Voir ce tutoriel.

Icône
L’icône est également un élément important.

Voir ce sujet de forum.

Page de téléchargement sur le serveur
Lorsque l’on se connecte en HTTP sur le serveur où est déployée l’application, on obtient une page de téléchargement. Il est important de personnaliser cette page.

La page en question se trouve dans le plug-in de l’application server sous /resources/html.

Je n’ai pas fait beaucoup de modifications sur cette page, mais mon idée est de toute façon de proposer un installateur (voir ci après). J’ai donc laissé le texte en anglais et la description correspondant à une application windows.

Installation
La prochaine étape va consister à se préoccuper de l’installation d’un produit fini. Il doit être possible:
* d’installer ou de choisir une base de données Derby.
* de configurer l’adresse à laquelle les clients devront se connecter.
…

Encore un peu de travail en perspective…

Je voulais obtenir un code indépendant de la configuration de la base de données, c’est-à-dire utiliser le fichier config.ini (qui doit de toute façon être mis à jour leur d’un changement d’environnement).

Fidèle à sa logique, Eclipse Scout propose d’étendre la classe AbstractSqlService pour définir la configuration d’accès à la base de données.

Il existe une propriété privée m_jdbcMappingName qui est accessible par des getters et des setters publics. Dans la classe fille, il est d’usage d’indiquer une constante dans la fonction getConfigured*() correspondante (getConfiguredJdbcMappingName() dans ce cas). C’est ce que la perspective Eclipse fait si l’on utilise la «Scout Properties View».

Le code correspondant:

À l’initialisation, cette valeur va être lue et devenir la valeur courante (accessible ensuite par le getter traditionnel).

Pourtant il existe une autre manière d’initialiser cette valeur. Il est possible d’utiliser dans le fichier config.ini une ligne respectant ce pattern:

<Qualified Name>#<Setter name without set prefix>=<value>

Ainsi dans notre cas:
org.eclipselabs.mcqs.server.services.common.sql.McqDerbySqlService#JdbcMappingName=jdbc:derby:/Users/jebr/code/mcq/mcq_db.derby

C’est magique…