Introduction
Nous disposons de plusieurs outils pour faire du développement mobile. Worklight studio est l’un de ces outils. Développé par une société israélienne rachetée par IBM, il met à disposition des entreprises un environnement intégré de développement mobile multiplateforme couplé avec un MDM (Mobile Device Management) et d’un module IBM WebSphere Cast Iron qui permet aux entreprises de connecter rapidement leurs applications mobiles à d’autres applications de l’entreprise.
Dans ce post nous allons essayer d’explorer rapidement les différentes possibilités mises à disposition par Worklight pour l’écriture d’une application mobile.
Installation
Worklight studio peut s’installer depuis le site developerWorks d’IBM. C’est un plugin éclipse qui peut donc s’installer depuis le marketplace d’éclipse. Le plus simple est de télécharger l’archive depuis le site d’IBM sur son poste et de l’installer depuis éclipse comme une archive.
NB : Une fois l’installation faite, il faudra procéder à quelques modifications dans le fichier eclipse.ini comme indiqué sur le site de IBM et surtout relancer éclipse avec l’option –clean
Création d’un nouveau projet
Avant d’aller plus loin, nous vous conseillons de switcher votre environnement éclipse sur la perspective Design. Il suffit d’aller dans Window –> Open Perspective –> Other –> Design
Un projet Worklight se fait de la même manière qu’un projet sous éclipse. Il suffit de faire:
File –> New Project –> Worklight Project –> Hybrid Application
Il faut ensuite donner un nom à votre projet. On peut voir un projet Worklight comme un WorkingSet contenant plusieurs applications Worklight.
Durant la phase de création de l’application, on doit spécifier quel type de technologie cliente (JavaScript) on aimerait supporter. Nous avons le choix entre JQuery Mobile, Sencha et Dojo (d’autres librairies viendront compléter la liste par la suite). Dans cet exemple, nous choisirons de travailler avec la framework Dojo qui est par défaut celle qui vient avec Worklight comme le montre le schéma suivant.
Une fois l’application créée, elle est accessible depuis l’exploration d’application d’éclipse. Par défaut le fichier application-descriptor.xml est ouvert pour édition.
On remarque à ce stage qu’un projet Worklight est considéré par éclipse comme un projet web donc la structure est la suivante :
Structure du projet
- WL Server Library – contient la librairie (jar) de l’API Worklight
- server/Java – l’emplacement des codes serveurs pour les adaptateurs Java
- JRE System Library – contient le JRE (Java Runtime Environment) utilisé par ce projet
- JavaScript Resources – contient les fichiers JavaScript du projet.
- adapters – comprend les adaptateurs utilisés par le projet pour les connexions aux différents serveurs.
- apps – contient les applications du projet
- bin – l’emplacement des artefacts générés qui seront déployés sur le serveur Worklight
- components – contient les composants des applications Shell
- dojo – contient les codes sources de la librairie Dojo
- server – contient les fichiers de configuration pour le serveur de test Worklight embarqué.
Structure de l’application
Comme indiqué plus haut, un projet Worklight peut comprendre plusieurs applications mobiles. On peut donc à tout moment rajouter une application mobile au projet qu’elle soit native, web mobile ou hybride. Il est important de noter que Worklight utilise PhoneGap et embarque un serveur application léger du nom de Jetty. Afin d’observer la structure de l’application qu’on avait ajouté au projet, il suffit d’étendre le répertoire apps du projet. On peut donc observer la structure de l’application DemoApplication :
- common – l’environnement par défaut crée pour l’application. On parlera un peu plus loin des environnements.
- css – DemoApplication.css, le fichier CSS principal de l’application
- images – les images par défaut pour l’environnement commun
- js – le fichier JavaScript principal de l’application
- DemoApplicatin.html – le fichier HTML principal de l’application
- legal – tous les documents légaux.
- application-desciptor.xml – le fichier méta- donnée par défaut de l’application (configuration serveur, url serveur, etc.….)
- build-dojo* – les artefacts liés au profile Dojo par défaut.
Comment tester son application
Une fois le projet en place, il suffit de se placer sur l’application (DemoApplication dans notre cas) pour la déployer automatiquement dans le container Jetty embarqué dans Worklight. On peut vérifier dans la console si l’application a été bien déployée ou pas.
Prévisualisation des ressources communes depuis le simulateur du navigateur mobile
Durant la phase de développement, on peut vite déboguer et visualiser les pages ou ressources web du projet. Worklight nous permet de charger facilement ces ressources dans le navigateur web à partir d’éclipse.
On peut aussi configurer éclipse pour qu’il ouvre les fichiers ressources dans un navigateur externe (Chrome par exemple). L’intérêt étant de pouvoir se servir des outils de débogage déjà disponibles sur ces navigateurs. Pour configures les navigateur par défaut sous éclipse, il suffit d’aller dans Window –> Préférences –> General –> Web Browser afin de configurer le navigateur externe.
Une fois le navigateur configuré, il suffit de sélectionner n’importe quel fichier ressource (HTML, CSS, JS) afin d’accéder l’option Preview pour amorcer l’affichage.
Environnement Worklight
Un environnement Worklight est une plateforme mobile, desktop ou web pouvant afficher une application web. Par défaut un projet Worklight ne supporte que l’environnement web. En d’autres termes, l’application peut être accessible depuis un navigateur web. Afin que qu’elle soit installable sur un téléphone Android ou iOS, il faudrait au préalable créer des environnements pour chacune des plateformes qu’on aimerait cibler. La création d’un environnement est spécifique à chaque application. Il est possible à tout moment de rajouter ou de supprimer un environnement à une application.
Pour créer un environnement, il suffit de faire un clic droit sur l’application et de choisir l’option Worklight Environment. DemoApplication –> New –> Worklight Environment.
Une fenêtre s’ouvre et nous permet de choisir les plateformes qu’on aimerait cibler. Dans notre cas, nous allons choisir Android, iPhone et mobile webapp. Une fois terminée, Worklight rajoute trois autres répertoires dans l’application comme le montre le schéma suivant. Ma version d’éclipse ayant déjà configuré le SDK android, Worklight génère automatiquement le projet Android associée à l’application dans le même workspace. De la même manière sous Mac OS, il est possible d’ouvrir sous Xcode, le projet iOS crée par Worklight pour notre application.
Worklight et intégration des composants visuels
Dans les lignes précédentes, nous avions eu a pendre en main l’outil Worklight et créer notre premier projet. Nous essayerons d’aller un peu plus loin sur la manière dont Worklight permet de créer les vues (écrans ou pages) de nos applications mobiles.
Avant tout, préparons éclipse pour l’édition des pages en mode Drag & Drop en ouvrant la vue palette et la vue Mobile Navigation.
Depuis la palette, on peut déplacer des composants visuels sur les pages HTML et modifier les propriétés de ces composants. On peut par exemple définir la fonction JavaScript à appeler lorsqu’il y a un click sur un bouton.
L’onglet Mobile Views nous permet de voir la liste des composants disponibles sur une page et la possibilité de les rendre visible ou pas.
Une fois l’édition et l’enchainement des pages effectués, on peut tester l’application sur différente plateforme ou environnement.
Worklight et adaptateurs
Worklight permet de définir un certain nombre d’adaptateurs qui facilitent l’intégration de nos applications avec un service distant en HTTP, une base de données, un flux JMS ou a WebSphere Cast Iron d’IBM. Ainsi, le développeur n’aura pas à écrire un adaptateur spécifique à chaque plateforme. En effet, l’adaptateur n’est rien d’autre qu’un module serveur hébergé sur le serveur Worklight qui permet d’interagir avec des sources de données distantes. Un module client entièrement écrit en JavaScript fournit une simple interface commune permettant d’invoquer l’adaptateur afin d’échanger des données. Supposons que nous avons un service web JSON à adresse suivante : http://localhost:9089/Services/getProfile, on peut configurer un adaptateur Worklight qui pourra se connecter à cette URL, récupérer les données et les rendre disponible à l’application mobile. L’application mobile pourra par la suite faire un appel de fonction JavaScript pour se connecter à l’adaptateur et afficher les résultats provenant du service web.
Pour écrire un adaptateur il faut aller sur le projet DemoProjet–> New –> WorklightAdapter comme le montre le schéma suivant. Il faut ensuite choisir le type d’adapter (HTTP, SQL, JMS, Cast Iron). Dans notre cas, nous allons choisir HTTP. Il faut donner un nom à notre adaptateur.
Une fois l’adaptateur créé, on peut voir un répertoire nommé adapter avec un certain nombre de fichiers dont le plus important s’appelle CustomHTTPAdapter.xml.
Il faut ensuite configure l’adaptateur à partir du fichier CustomHTTPAdapter.xml en spécifiant l’adresse du serveur qui héberge les services web. Il faut rajouter une procédure qui fera des appels à notre service web. Durant la création de l’adaptateur, un fichier JavaScript correspondant est créé. Ce fichier servira d’interface commune entre tous les environnements. On pourra y définir nos procédures.
Ouvrons ensuite le fichier CustomerHTTPAdapteer-impl.js et rajoutons l’implémentation JavaScript des procédures définies ci-dessus. Nous devons ensuite déployer l’adaptateur sur le serveur Worklight afin qu’il soit pris en compte et accessible par nos applications mobiles. La procédure est la même comme le montre le schéma suivant. L’adaptateur sera donc disponible dans l’interface web console.
function getProfile() {
var input = {
method : ‘get’,
returnedContentType : ‘json’,
path : ‘/Services/getProfile’
}
return WL.Server.invokeHttp(input);
};
Pour test l’adapter, il faut de faire un click droit sur l’adaptateur et de cliquer sur Run As –> Invoke Worklight procedure
Console Worklight
Worklight comprend un serveur web embarqué qui permet de contrôler, et tester les applications hybrides depuis un navigateur web. Lorsqu’on déploie l’application depuis éclipse, elle est automatiquement accessible depuis la console qui se trouve à l’adresse http://localhost:8080/console.
Cette console de test ne peut charger qu’un seul projet à la fois. Elle offre les mêmes fonctionnalités que le serveur Worklight de production et permet de supprimer/déployer les applications et les adaptateurs, d’activer/désactiver ou de bloquer les environnements.
Il suffit de cliquer sur l’œil associé à un environnement pour lancer la visualisation de l’application dans l’environnement dédié.
Sécurité et méthodes d’authentification
Nous avions appris à créer une application mobile avec Worklight. En entreprise, il faut savoir délivrer ces applications aux utilisateurs de manière sécurisée afin de ne pas mettre en péril les contraintes en termes de sécurité de l’entreprise. Avec Worklight, il est possible lors de la création de l’application de mettre en place assez rapidement des mécanismes d’authentification en utilisant des modules d’authentification et de login fournis par la plateforme ou définis dans un serveur d’application WebSphere en exécution par exemple. Ainsi à partir du fichier authenticationConfig.xml, on peut définir des Login Modules et des Realms (un peu comme sur un serveur applicatif où on utiliserait les mécanismes de JAAS – jsecurity_check). L’application Worklight s’appuiera alors sur ces informations ainsi que l’adresse du serveur Worklight configuré pour amorcer un vue de login dans l’application mobile à partir de laquelle l’utilisateur pourra s’authentifier pour se connecter au service.
Gestion des applications sous Worklight
Les applications mobiles diffèrent des applications traditionnelles de l’entreprise. Mais en terme de gestion d’application, le principe et les besoins sont plus ou moins les mêmes. La télédistribution d’une application mobile de l’entreprise se fera d’ailleurs très souvent aux delà de l’enceinte de l’entreprise. En d’autres termes, l’employé, depuis sa maison peut se voir télédistribuer une application mobile sur son terminal. Worklight permet de faciliter la télédistribution des applications mobiles. Par exemple la possibilité de mettre à jour à distance certaines ressources statiques de l’application mobile hybride (HTML, CSS, JavaScript) embarquées dans l’application sans une réinstallation complète de l’application. L’envoi de notification aux utilisateurs depuis l’interface des gestions de Worklight afin de les forcer par exemple à mettre à jour leur application mobile, la possibilité de désactiver à distance une version particulière d’une application mobile.
Pour mettre à jour les ressources (HTML, CSS, JavaScript) d’une application déjà installée sans supprimer et réinstaller l’application, le serveur Worklight et le client échangent des informations (le hash) lors du lancement de l’application. Si le hash reçu par le client ne correspond pas à celle du serveur, alors Worklight met en place le processus d’alerte permettant à l’utilisateur de mettre à jour les contenus modifiés (par exemple sous Android, le répertoire asset) sans désinstaller et réinstaller l’application. Ceci nous fait gagner énormément du temps et nous évite à passer par les processus de validation des plateformes ciblées.
Envoi de notification push
La fonctionnalité de push permet d’atteindre facilement les utilisateurs des applications et de communiquer avec eux. Depuis l’interface de gestion (console) Worklight, l’administrateur peut ajouter un texte de notification qui sera automatiquement disponible et afficher sur l’application de l’utilisateur. Le principe d’échange étant le même entre le serveur et l’application. En effet, au démarrage de l’application, une requête est envoyée depuis l’application mobile au serveur Worklight pour savoir s’il y a des notifications disponibles pour la version actuelle installée sur le terminal mobile.
Désactivation à distance d’une application
Un peu comme l’envoi du push, un administrateur peut amorcer depuis l’interface de gestion de Worklight la désactivation et la mise à jour d’une application. Il lui suffit de renseigner le message d’alerte de mise à jour et le lien correspondant au store privée de l’entreprise ou l’utilisateur pourra installer et mettre à jour son application.
Le store privé ou l’IBM application center
L’application center est un outil qui sert de store privée pour les applications mobiles au sein de l’entreprise. En d’autres termes il permet déjà durant les phases de développement de rendre les applications disponibles aux testeurs et de faciliter la distribution et l’accès aux applications à terme par les employés de l’entreprise. Il est donc un canal de distribution pour les applications mobiles.
On peut à partir de cette interface lire les commentaires laissés par les utilisateurs des applications comme sur Apple Store ou Google Play. L’objectif étant de mettre au sein de l’entreprise une boutique privée de distribution d’applications mobiles dont les fonctionnalités sont semblables à celle qu’on a dans le monde public.
Conclusion
Worklight Studio est un outil qui se veut adapter au développement et l’intégration des services au sein d’une entreprise. En ce qui concerne le développement des applications mobiles, l’utilité de Worklight se fait plus ressentir pour la catégorie des applications hybrides. Son intégration de PhoneGap et le fait d’en avoir fait un plugins éclipse est intéressant car on s’en accommode très vite. J’ai beaucoup aimé toute la partie serveur avec la possibilité de faire du débogage et de tester les applications depuis un navigateur sans oublier la console qui sert d’interface des gestions des applications.
Mon souci est que le rendu n’est pas encore satisfaisant, surtout sous android. J’ai pu noter aussi quelques soucis de lenteur et pas mal de petit plantage.
Je dirai que dans le cadre d’un grand projet mobile que c’est peut être un risque de se lancer dans cette direction. Par contre pour l’écriture d’un PoC ou d’une petite application sans exigence particulière pour l’expérience utilisateur, on peut utiliser Worklight. L’autre raison pour laquelle je choisirai Worklight serait pour l’usage de son MDM léger qu’il embarque et qui peut nous empêcher de réinventer la roue dans le cadre de la mise ne place d’une telle solution dans un environnement mobile. Je n’ai pas eu la chance et le temps de voir comment Cast Iron s’intègre avec Worklight. Ce serait peut-être l’objet d’un autre post.
