Tabris est le premier framework Java conçu pour développer des applications natives multi-plateformes. Il offre une expérience utilisateur "native", semblable à celle offerte par le système, tout en ajoutant des fonctionnalités et des composants faits sur mesure.
Mais que veut dire exactement "natif"?
Le nombre de plateformes existantes pose un problème de taille lorsque l'on développe une application mobile.
C'est un rêve pour les utilisateurs finaux qui ont accès à différents systèmes, machines, ou logiciels, mais c'est un cauchemar pour les développeurs.
Les développeurs d'applications mobile devant développer une application sur plus d'une plateforme rencontrent rapidement certains obstacles.
L'un des challenges le plus difficile est de posséder l'expertise nécessaire. Si nous ne considérons "que" les deux systèmes leaders sur le marché, iOs et Android, cela veut dire que:
- Il faut être compétent dans deux langages: Java et Objective-C.
- Il faut connaitre deux plateformes proposant des APIs différentes.
- Il faut prévoir un (ou deux) design(s) qui tient compte des particularités de chaque système.
En Bref,si vous développez "nativement" pour chaque plateforme, l'effort requis pour développer l'application mobile augmente plus ou moins avec le nombre de systèmes supportés. Heureusement, les toolkits multi-plateformes nous proposent une excellente alternative.
Il en existe deux types: d'un côté, il y a ceux basés sur du HTML, et de l'autre, ceux qui proposent une compilation multi-plateformes, en interprétant les fonctionnalités et les contrôles natifs.
PhoneGap domine clairement la première catégorie et utilise du HTML pour afficher des interfaces. L'atout indéniable de cette solution est la rapidité avec laquelle il est possible de développer une application simple.
Cependant, HTML5 a récemment perdu de son attrait, principalement à cause des utilisateurs non satisfaits et d'échecs dans son utilisation, comme le cas de l'application Facebook.
En ce qui concerne l'expérience utilisateur, HTML5 peut rapidement devenir un fardeau dans le développement d'applications mobiles. Au contraires des applications Web, celles que nous avons sur nos mobiles sont en général équipées de widgets sophistiqués. Même si certains toolkits HTML5 comme jQuery Mobile offre des composants similaires à ceux fournis par le système, ils sont souvent composés de nombreux éléments. Dans le cas d'interfaces utilisateurs complexes, cela implique une multitude d'éléments dans le DOM, ce qui peut avoir une influence négative sur les performances de l'application. Que ce soit avec une approche composant ou non, la plupart des interfaces HTML n'offrent pas une expérience utilisateur satisfaisante. Ce manque de familiarité en terme de "look & feel" des widgets induit des concepts de navigation et d'animations complètement différents.
La seconde catégorie de toolkits multi-plateformes utilise les composants natifs du systèmes, évitant ainsi les problématiques de "look & feel". Les applications créées avec ce genre d'outils sont visuellement plus proches de l'interface native que d'une interface HTML. Cependant, ils amènent d'autres problématiques.
Pour développer avec succès une application native, il n'est pas suffisant de se contenter d'afficher des composants natifs. La navigation doit également refléter les concepts liés à la plateforme. Dans le cas d'un développement natif, un développeur a accès à différents concepts pour le design d'une application. Dans le cas de iOS par exemple, nous aurons le principe du 'ViewController', et pour Android les 'Activity' et les 'ActionBar'. Il existe peu de toolkits qui tentent une abstraction de ces concepts et essayent de les unifier.
C'est sur ce point que Tabris se démarque. Tabris fait partie de la deuxième catégorie de toolkits: il fait une abstraction des contrôles natifs et de leurs fonctionnalités avec une API Java. Cela inclut des éléments simples, comme des boutons ou des champs de texte, mais également des composants plus complexes comme des listes. En plus de ces contrôles, l'API Java donne également accès à la caméra et à la possibilité d'avoir des informations de géolocalisation. Une autre fonctionnalité fondamentale de Tabris est l'abstraction des concepts de navigations, appelée Tabris UI.
L'UI reste très simple et est composée de deux composants principaux : les 'Page' et les 'Action'. Le meilleur moyen d'expliquer ce que sont ces composants est d'utiliser une capture d'écran.
(Cliquez sur l'image pour l'agrandir)
L'image montre comment la même application est rendue sur des téléphones iOS et Android. Le contenu est identique, seule l'intégration avec les frameworks est différente. La zone marquée en rouge représente une Page. Une Page est une sorte de conteneur pour les contrôles. La zone marquée en vert représente deux Actions. Conceptuellement, une Action représente une possible interaction avec l'utilisateur, relative à l'application ou à une page.
Pour créer une application complète avec ces types, ils doivent êtres connectés les uns avec les autres. La première connection est ce qu'on appelle le 'flow'. Le flow décrit une suite de pages qui peuvent s'assembler de différentes façons. Pour créer ce genre de flow, une Page doit avoir un rôle: page top-level ou page normale. Une page top-level marque le début d'un flow et est unique. Une page normale peut exister plusieurs fois dans le flow, mais pas au début. Cela s'explique simplement avec le schéma suivant.
(Cliquez sur l'image pour l'agrandir)
Le schéma ci-dessus montre un flow d'application typique. Dans ce cas, l'application a trois pages de type top-level, et plusieurs normales. Un utilisateur peut naviguer entre les pages, en utilisant des Actions. Il est important de comprendre que l'on peut parcourir les pages de différentes façons, comme expliqué dans l'exemple suivant.
Partons du principe que nous voulons développer une application pour un magasin vendant des livres. Dans cet exemple, les livres sont des élément centraux de l'application. L'utilisateur doit donc être capable de naviguer facilement entre les différents livres. Une fonctionnalité qui a contribué au développement d'Amazon est le filtrage collaboratif, C'est à dire "Les clients ayant acheté ce livre ont également acheté ceux-la". Avec cette fonctionnalité un utilisateur peut naviguer d'un livre à l'autre. La longueur de cette chaine de navigation n'a pas de limite en soi. Toutefois, la possibilité de naviguer en sens inverse est requise, que ce soit vers un précédent livre ou vers la page d'accueil.
Le flow de Tabris UI permet d'obtenir ce genre de navigation, et il n'y a aucune limite concernant le nombre de pages que l'on peut visiter: il est toujours possible d'avancer. Cependant, le point de départ de notre application doit être fixé. Dans notre exemple, ca pourrait donc être une liste de best-seller.
Le second concept, les Actions, ont une relation avec les pages. Typiquement, une action encapsule une fonctionnalité de l'application, par exemple le fait d'ajouter un livre dans un panier ou d'effectuer une recherche. Ces deux fonctions mettent également en valeur la notion de scope. Une action possède un scope, qui peut être lié à une Page ou global, c'est à dire lié à l'application. Une recherche est un exemple d'action globale puisqu'elle doit être accessible depuis n'importe où, alors que l'action d'ajout de livre ne doit être disponible que lorsque l'utilisateur est sur la page de détails d'un livre.
Le flow complet d'une application pour une librairie pourrait ressembler à ceci:
(Cliquez sur l'image pour l'agrandir)
Les captures d'écran montre la même application sur Android et iOS. L'application possède trois pages parentes: "All Books", "Popular" et "Favorites". Chacune de ces pages affiche une liste de livres. Après sélection d'un livre, celui-ci est montré dans une vue plus détaillée. De là, l'utilisateur peut accéder à d'autres livres ou à un court extrait. Le code de cette application est disponible sur GitHub. Pour voir l'application en action, vous pouvez également voir cette vidéo.
Après que nous ayons discuté des concepts de navigation de Tabris UI, nous voulons également aborder le sujet des widgets qui font partie intrinsèque de l'application. Tabris tire partie des API du bien connu SWT (Standard Widget Toolkit). SWT est léger, répandu, open source et utilise JFace afin de fournir un framework MVC puissant. La listview de la librairie présentée ci-dessus peut, par exemple, être implémentée en seulement quelques lignes de code.
public class BooksListPage extends AbstractPage {
public void createContent( Composite parent ) {
TreeViewer viewer = new TreeViewer( parent, SWT.V_SCROLL );
viewer.setContentProvider( new BooksContentProvider() );
viewer.setLabelProvider( new BooksLabelProvider() );
addBookSelectionListener( viewer );
...
public class BooksContentProvider implements ITreeContentProvider {
public Object[] getElements( Object inputElement ) {
return books.toArray();
}
...
public class BooksLabelProvider implements ITableLabelProvider {
public String getColumnText( Object element, int columnIndex ) {
String result = null;
if( columnIndex == 0 ) {
if( element instanceof Book ) {
result = ( ( Book )element ).getTitle();
...
Mise à part la concision de l'API, l'utilisation de SWT apporte d'autres avantages, comme la documentation, les exemples et le support de la communauté Eclipse. La gestion de Big Data, le design modulaire de l'application avec OSGi et l'intégration d'interfaces basées sur des modèles font également partie de Tabris.
L'architecture sous-jacente permet une intégration simple de technologies Java déjà éprouvées. La finesse de l'architecture cliente de Tabris peut certainement être comparée avec un serveur Web ou un navigateur, avec une logique applicative exécutée du côté serveur, dont l'interface qui l'accompagne, délivrée en HTML et rendue par le navigateur. Dans le cas de Tabris, la logique applicative est également exécutée côté serveur, au travers d'une application JEE. Un client natif, par exemple sur une tablette, est connecté au serveur et recoit la représentation de l'interface en JSON. Mais au lieu d'avoir une interface basée sur du HTML, les clients Tabris génèrent des widgets natifs afin d'avoir une expérience utilisateur spécifique.
Comme la plupart des applications Web, les clients mobiles doivent toujours être connectés au serveur. Pour certaines applications, cela est une restriction inacceptable, mais pour d'autres cela peut être un avantage. Les données sont seulement transférées pour pouvoir créer des interfaces. Les clients n'exécutent aucune logique applicative, ils ne font que générer l'interface. De plus, cela veut dire qu'aucune donnée sensible ou aucun algorithme n'est sauvé sur les mobiles, permettant de se protéger implicitement de tout vol ou toute perte.
Un avantage intéressant qu'apportent l'architecture et le protocole de communication libre utilisé1, est la gestion de différents clients. Pour exemple, en plus des clients mobiles sont également disponibles des clients Web et Desktop open source. Certains clients, par exemple, basés sur Windows CE ou pour des systèmes embarqués comme des terminaux de paiement peuvent proposer un ensemble de widgets réduits, permettant donc la création de nouvelles applications simplement.
La version 1.0 de Tabris est disponible depuis avril 2013. Les composants serveur, et les clients Web et Desktop sont couverts par la Eclipse Public License et peuvent gratuitement être utilisés avec des produits commerciaux. Seul les clients mobiles sont couverts par une licence commerciale. Pour personnellement tester et évaluer toutes les possibilités de Tabris, des clients mobiles sont disponibles en téléchargement sur le site du projet 2.
A propos des auteurs
Jochen Krause est membre de la direction de la fondation Eclipse. Il est CEO de EclipseSource, leader reconnu dans la distribution de Eclipse et OSGI. Jochen a eu un rôle de leader dans la communauté Eclipse depuis sa création en 2002, et il a également servi différentes fonctions comme leader de projet, membre de conseil d'architecture et leader PMC.
Holger Staudacher travaille comme consultant développeur à EclipseSource à Karlsruhe, en Allemagne. Il est responsable de Tabris et il est l'un des committers de l'équipe travaillant sur le projet Eclipse Remote Application Platform (RAP). Holger est également l'auteur du populaire framework restfuse pour tester les APIs REST. Il s'intéresse à tout ce qui concerne l'Agile, clean code et les systèmes distribués.