FR3001561A1 - Procede d'execution d'une application multi-terminaux - Google Patents

Abstract

La présente invention concerne un procédé d'exécution d'une application par des moyens de traitement de données (11) d'un terminal (1), le terminal (1) comprenant en outre des premiers moyens de stockage de données (12) et des deuxièmes moyens de stockage de données (13), le procédé étant caractérisé en ce qu'il comprend des étapes de : (a) calcul en fonction d'une commande issue d'une action d'un utilisateur sur le terminal (1) d'au moins une transition d'un premier à un deuxième état choisis parmi une pluralité d'états (E1-E4) correspondant chacun à une phase de l'exécution de l'application ; (b) instanciation et/ou désinstanciation sur les premiers moyens de stockage de données (12) d'au moins un module d'une pluralité de modules (P1-P5) permettant chacun la mise en œuvre de fonctionnalités de l'application lorsque instancié, de sorte que dans chaque état de ladite pluralité d'états (E1-E4) les modules (P1-P5) instanciés sur les premiers moyens de stockage de données (12) soient les modules associés audit état dans un fichier (M1-M3) de description d'états, le fichier (M1-M3) étant associé au terminal (1), les modules (P1-P5) et le fichier (M1-M3) étant stockés sur les deuxièmes moyens de stockage de données (13). La présente invention concerne en outre un terminal et un procédé de montage d'une application.

Description

DOMAINE TECHNIQUE GENERAL La présente invention concerne le domaine des applications pour terminaux, et en particulier un procédé d'exécution d'une telle application.

ETAT DE L'ART On connait aujourd'hui un grand nombre de modèle de terminaux mobiles tels que des smartphones, des tablettes tactiles. On connait 10 également des terminaux fixes tels que des TV connectées. Ces modèles différent le plus souvent les uns des autres aussi bien en termes de capacités matérielles (taille et format de l'écran, mémoire, processeur, capacités graphiques, capacités fonctionnelles, etc.), qu'en termes de capacités logicielles (interfaces réseaux, sécurité, etc.). 15 Cela complique le développement d'applications sur ces terminaux, et aujourd'hui chaque portage d'une application nécessite un développement spécifique afin de tirer pleinement parti des possibilités d'un terminal. Les applications à succès sont ainsi aujourd'hui le plus souvent 20 proposées en une dizaine de versions différentes. Cela nécessite un effort soutenu de développement, et on constate que même avec ce grand nombre de versions, la mise en oeuvre de l'application sur certains terminaux n'est pas parfaite puisque des adaptations sont nécessaires pour s'adapter aux environnements 25 hétérogènes de chacun des terminaux. Il serait théoriquement nécessaire de développer autant de versions d'une application que de modèles sur le marché pour avoir un résultat optimal sur chacun. Pour réaliser des applications multiplateformes il a été proposé l'utilisation de « plugins DLL » (Dynamic Link Library), en d'autres termes de 30 modules qui « renvoient » vers des portions de code externes (au lieu de les incorporer directement dans le code source) que l'on peut concevoir spécifiques à chaque terminal vers lequel un portage est souhaité.

La demande de brevet EP2477138 décrit un exemple d'une telle utilisation (les terminaux sont des scanners de code-barres de différents modèles et fabricants). Cette solution nécessite de disposer d'autant de DLL que d'implémentations souhaitées, et une recompilation pour chaque terminal. Il serait ainsi intéressant de disposer d'une solution permettant de disposer d'une application qui puisse s'adapter au mieux à n'importe quel terminal sans effort de développement supplémentaire. Il serait également souhaitable qu'une telle application présente sur chaque terminal des performances optimales en termes d'utilisation des ressources du terminal et de consommation énergétique. PRESENTATION DE L'INVENTION Selon un premier aspect, la présente invention se rapporte donc à un Procédé d'exécution d'une application par des moyens de traitement de données d'un terminal, le terminal comprenant en outre des premiers moyens de stockage de données et des deuxièmes moyens de stockage de données, le procédé étant caractérisé en ce qu'il comprend des étapes de : (a) calcul en fonction d'une commande issue d'une action d'un utilisateur sur le terminal d'au moins une transition d'un premier à un deuxième état choisis parmi une pluralité d'états correspondant chacun à une phase de l'exécution de l'application ; (b) instanciation et/ou désinstanciation sur les premiers moyens de stockage de données d'au moins un module d'une pluralité de modules permettant chacun, lorsque instancié, la mise en oeuvre de fonctionnalités de l'application, de sorte que dans chaque état de ladite pluralité d'états les modules instanciés sur les premiers moyens de stockage de données soient les modules associés audit état dans un fichier de description d'états, le fichier étant associé au terminal, les modules et le fichier étant stockés sur les deuxièmes moyens de stockage de données. Selon d'autres caractéristiques avantageuses et non limitatives : - les premiers moyens de stockage de données sont une mémoire vive, et les deuxièmes moyens de stockage de données sont une mémoire de masse ; - l'application comprend une pluralité de fichiers de description d'états, chaque fichier étant associé à des terminaux différents ; - l'étape (b) comprend l'instanciation des modules associés dans le fichier de description d'états au deuxième état mais pas au premier état, et la desinstanciation des modules associés dans le fichier de description d'états au premier état mais pas au deuxième état ; - un module associé dans le fichier de description d'états à la fois au premier état et au deuxième état est maintenu instancié, et relancé ; - le procédé comprend la répétition des étapes (a) puis (b) ; - le procédé comprend suite à l'étape (b) une étape (c) d'activation et/ou de désactivation d'au moins un des modules instanciés en fonction d'une commande issue d'une action de l'utilisateur sur le terminal ; - un module activé génère des données représentatives d'événements en fonction des commandes issues des actions de l'utilisateur sur le terminal, une transition d'état, une activation ou une désactivation d'un module correspondant à un événement donné ; - chaque module met en oeuvre le modèle Modèle-Vue-Contrôleur 25 (MVC) ; - l'application comprend en outre au moins un fichier descripteur associé au terminal, les moyens de traitement de données étant configurés pour modifier l'apparence sur une interface du terminal d'un module instancié sur les premiers moyens de stockage de données en fonctions de données 30 dudit fichier descripteur.

Selon un deuxième aspect, l'invention concerne un terminal comprenant des moyens de traitement de données, des premiers moyens de stockage de données et des deuxièmes moyens de stockage de données, le terminal étant caractérisé en ce que : Une pluralité de modules d'une application et au moins un fichier de description d'états de l'application sont stockés sur les deuxièmes moyens de stockage de données, chaque module permettant la mise en oeuvre de fonctionnalités de l'application lorsque instancié sur les premiers moyens de stockage de données, une pluralité d'états correspondant chacun à une phase de l'exécution de l'application, au moins un module étant associé à chaque état dans le fichier de description d'états ; les moyens de traitement de données sont configurés pour mettre en oeuvre lors de l'exécution de ladite application : o Un gestionnaire de focus pour le calcul d'au moins une transition d'un premier à un deuxième état choisis parmi la pluralité d'états ; o Un gestionnaire d'état pour l'instanciation et/ou la désinstanciation, sur les premiers moyens de stockage de données, d'au moins un module de ladite pluralité de modules, de sorte que dans chaque état de ladite pluralité d'états les modules instanciés sur les premiers moyens de stockage de données soient les modules associés audit état dans le fichier de description d'états. Selon d'autres caractéristiques avantageuses et non limitatives : - les moyens de traitement de données sont en outre configurés pour mettre en oeuvre un gestionnaire de modules pour charger et/ou décharger 30 des modules dans les deuxièmes moyens de stockage de données.

Selon un troisième aspect, l'invention concerne un procédé de montage d'une application apte à être exécutée par des moyens de traitement de données d'un terminal selon le deuxième aspect de l'invention, le procédé étant caractérisé en ce qu'il comprend des étapes de : - sélection d'une pluralité de modules de l'application et d'au moins un fichier de description d'états associé au terminal, chaque module permettant la mise en oeuvre de fonctionnalités de l'application lorsque instancié sur des premiers moyens de stockage de données du terminal, une pluralité d'états correspondant chacun à une phase de l'exécution de l'application, au moins un module étant associé à chaque état dans le fichier de description d'états ; - compilation de l'ensemble comprenant ladite pluralité de modules de l'application et l'au moins un fichier de description d'états en au moins un paquet exécutable par les moyens de traitement de données du terminal. PRESENTATION DES FIGURES D'autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description qui va suivre d'un mode de réalisation préférentiel. Cette description sera donnée en référence aux dessins annexés dans lesquels : - la figure 1 représente un terminal pour la mise en oeuvre du procédé selon l'invention ; - la figure 2 représente l'architecture d'une application exécutée dans un terminal lors du procédé selon l'invention ; - les figures 3a-3c représentent trois diagrammes d'états obtenus dans la mise en oeuvre du procédé d'exécution selon l'invention pour un exemple d'application sur trois terminaux différents.

DESCRIPTION DETAILLEE Terminal En référence aux dessins, la présente invention concerne un procédé d'exécution d'une application sur un terminal 1. Par terminal, on entendra en particulier des smartphones et des tablettes tactiles (terminaux mobiles), mais également tout appareil électronique tel qu'un PC, un boitier multimédia (Set-Top Box) ou une télévision connectée.

Le terminal 1, visible sur la figure 1, comprend des moyens de traitement de données 11 pour l'exécution de l'application (en particulier un ou plusieurs processeurs), des premiers moyens de stockage de données 12, et des deuxièmes moyens de stockage de données 13. Le terminal 1 peut être connecté à un réseau 20 tel qu'Internet pour des fonctionnalités de certaines applications. Les premiers moyens de stockage de données 12 correspondent à une mémoire vive, en d'autres termes une mémoire rapide et volatile (telle que de la mémoire RAM, « Random Access Memory ») utilisée par les moyens de traitement de données 11 pour stocker les données lors de leur traitement, et les deuxièmes moyens de stockage de données 13 correspondent à une mémoire de masse, en d'autres termes une mémoire plus lente et non-volatile telle qu'un disque dur ou une mémoire flash. Application L'application exécutée peut être n'importe quel type d'application qui respecte l'architecture qui va être à présent décrite. En référence à la figure 2, l'application comprend une pluralité de modules P1-P5, de l'anglais « plug-ins », et au moins un fichier M1-M3 de description d'état (appelé également « manifeste »), associé au terminal 1. Ces différents composants sont stockés sur les deuxièmes moyens de stockage de données 13 du terminal.

Chaque module est un bloc élémentaire de l'application mettant en oeuvre certaines fonctionnalités de l'application lorsque instancié (voir plus loin). Chaque module met avantageusement en oeuvre le modèle Modèle- Vue-Contrôleur (MVC), modèle connu de l'homme du métier qui propose de séparer les aspects « données », « présentation » et « traitements » du module en trois composants qui sont le modèle (modèle de données), la vue (présentation, interface utilisateur) et le contrôleur (logique de contrôle, gestion des événements, synchronisation). Ce modèle est particulièrement adapté aux applications interactives en séparant les problématiques liées aux différents composants au sein de leur architecture respective. Chaque module est par ailleurs indépendant des autres. On comprend que le découpage de l'application en modules correspond à un découpage fonctionnel.

Par exemple, les cinq modules qui apparaissent sur les figures 3a-c sont ceux d'une application de VoD (Vidéo à la Demande). - P1 : un module « Fiche descriptive » affichant une présentation d'informations sur un film sélectionné par l'utilisateur (synopsis, distribution, etc.) ; - P2: un module « Bande-Annonce » permettant la récupération et la lecture d'une bande-annonce d'un film sélectionné par l'utilisateur ; - P3: un module « Formulaire » correspondant à une interface de saisie d'informations d'identification d'utilisateur avant l'achat d'un film en VoD ; - P4: un module « Suggestions » identifiant et affichant d'autres films pouvant plaire à l'utilisateur en fonction du film choisi ; - P5: un module « Paiement » pour la saisie d'informations bancaires pour l'achat du film. Comme l'on verra plus loin, ces modules P1-P5 fonctionnent en 30 particulier via un système événementiel. D'autres caractéristiques avantageuses des modules seront également décrites.

L'application comprend par ailleurs au moins un fichier M1-M3 de description d'états. Par état, on entend une phase de l'exécution de l'application. A chaque état, un ou plusieurs des modules P1-P5 sont instanciés sur les premiers moyens de stockage de données 12, en d'autres termes la mémoire vive. Par « instancié », on entend que le module s'est vu allouer un espace mémoire dédié dans les premiers moyens de stockage de données 12, et qu'il a été initialisé. Si ce module est désinstancié, cet espace alloué est libéré pour d'autres traitements. Dans le fichier M1-M3, chaque état E1-E4 est défini par un ou plusieurs des modules P1-P5 auxquels il est associé. Un même module peut être associé à plusieurs états. Comme l'on verra plus loin, une application est conçue comme un « parcours » d'état à état, en fonction de transitions. Le procédé selon l'invention est basé sur le fait que dans chaque état de ladite pluralité d'états E1-E4 les modules P1-P5 instanciés sur les premiers moyens de stockage de données 12 soient les modules associés audit état dans un fichier M1-M3 de description d'états. Dans la figure 2, on considère que les états El-E4 sont conformes au fichier Ml. En d'autres termes, à un état donné un module est instancié si et seulement s'il est associé dans le fichier M1-M3 à cet état. Et comme expliqué précédemment, le fichier M1-M3 de description d'états est associé au terminal 1. Plus précisément, un fichier de description d'état correspond à un ou plusieurs types (voire seulement modèles) de terminal. Avantageusement, il y a plusieurs fichiers M1-M3 chacun associés à des terminaux différents. Les figures 3a-c représentent ainsi les diagrammes d'états 30 correspondant à trois manifestes M1-M3 chacun associé à une catégorie de terminaux.

Dans la figure 3a, est considéré le premier fichier M1 correspondant aux terminaux « tablette tactile »; dans la figure 3b, est considéré le deuxième fichier M2 correspondant aux terminaux « smartphone » ; et dans la figure 3c, est considéré le troisième fichier M3 correspond aux terminaux « mobiles » (en d'autres termes, les terminaux mobiles moins avancés ne disposant pas de toutes les fonctionnalités d'un smartphone). Seul le fichier de description d'états associé au terminal 1 sur lequel l'application est exécutée est considéré (et consulté). En effet, des terminaux différents, bien que présentant des spécifications différentes, supportent souvent des langages communs. On peut citer par exemple JavaScript, ActionScript ou HTML. Un module conçu dans un de ces langages sera donc utilisable sur plusieurs terminaux. En définissant différemment les états selon les fichiers M1-M3, on peut ainsi modifier le déroulement de l'exécution de l'application en l'adaptant à un terminal, en d'autres termes en manipulant différemment les « briques » que sont les modules P1-P5. Par exemple, en référence aux figure 3a-3c, on voit que dans le mode d'exécution le plus « pauvre » (sur mobile peu évolué, figure 3c), certains modules P1-P5 trop « gourmants » en ressources pour être supportés, comme le module P2 « Bande-Annonce », sont absents (car associés à aucun des états). En outre, on voit que moins de modules sont instanciés simultanément (deux à la fois au maximum pour un smartphone, et un seul à la fois pour un mobile), de sorte à s'adapter aux ressources du terminal 1.

Le procédé selon l'invention permet ainsi une adaptation totale aux performances et capacités de chaque terminal 1. Par ailleurs, le fonctionnement par modules fait qu'à chaque instant, seulement une partie de l'application est instanciée, d'où une consommation moindre de la mémoire vive (les premiers moyens de stockage de données 12) par rapport à tous les procédés connus, d'où une consommation énergétique moindre, ce qui est très appréciable en particulier pour des terminaux mobiles.

Descripteurs et attributs De façon avantageuse, l'application comprend en outre au moins un « fichier descripteur » associé au terminal 1. Ce fichier descripteur contient des attributs de l'affichage graphique spécifiques du terminal qui permettent d'adapter le rendu graphique d'un module. En d'autres termes, les moyens de traitement de données 11 sont configurés pour modifier l'apparence sur une interface du terminal 1 d'un module P1-P5 instancié sur les premiers moyens de stockage de données 12 en fonctions de données dudit fichier descripteur. En effet, comme on l'a vu précédemment, les fichiers M1-M3 de description d'états ne permettent que de gérer le choix des modules P1-P5, mais ne permettent pas d'influer sur leur fonctionnement interne.

Les descripteurs permettent d'adapter un module au format de l'écran d'un terminal, de modifier le positionnement de son interface sur cet écran, d'adapter sa résolution, d'autoriser des combinaisons d'affichage de modules P1-P5 de type « mosaïque » etc. A l'intérieur d'un affichage, on peut jouer sur les CSS (« Cascading Style Sheets »). On peut prévoir un ou plusieurs descripteurs par module et par terminal. Chaque descripteur peut être spécifique d'un nombre plus réduit de terminaux qu'un fichier de description d'états. Un fichier descripteur est par exemple au format JSON (« JavaScript Objet Notation »), langage particulièrement adapté pour compléter un module écrit en JavaScript. Grâce aux descripteurs, l'adaptation d'une application à chaque terminal est maximale, et donc non seulement les performances peuvent être optimales (consommation de batterie, utilisation de ressources), mais en plus ses qualités esthétiques peuvent être adaptées au mieux aux capacités dudit terminal. Transitions Lors de l'exécution, l'application réagit comme une machine à états. Le procédé comprend ainsi des étapes de : (a) calcul en fonction d'une commande issue d'une action d'un utilisateur sur le terminal 1 d'au moins une transition d'un premier à un deuxième état choisis parmi la pluralité d'états E1-E4 ; (b) instanciation et/ou désinstanciation sur les premiers moyens de stockage de données 12 d'au moins un module d'une pluralité de modules P1-P5, de sorte que dans chaque état de ladite pluralité d'états E1-E4 les modules P1-P5 instanciés sur les premiers moyens de stockage de données 12 soient les modules associés audit état dans le fichier M1-M3 de description d'états associé au terminal 1. L'instanciation/désinstanciation de modules est gérée par un composant logiciel appelé le gestionnaire d'état GE qui consulte le fichier de description d'état M1-M3 lorsqu'une transition est détectée. Pour cela, comme expliqué avant, les modules P1-P5 fonctionnent en particulier via un système événementiel. En d'autres termes, toute commande en interaction avec un module entraîne la génération de données représentatives « d'événements », en d'autres termes de l'information permettant de détecter l'occurrence ou non d'un événement. Ces données peuvent par exemple décrire des grandeurs physiques, des états d'objets, des paramètres de fonctionnements, des commandes, etc. Ces données sont envoyées sous forme de messages entre les modules P1-P5. Par « commande issue d'une action d'un utilisateur », on entend toute interaction de l'utilisateur avec un des modules P1-P5 via une interface, des moyens de saisie tels qu'un clavier, un écran tactile, etc. La commande peut être directe (par exemple appui volontaire sur un bouton) ou indirecte (par exemple saisie d'une valeur particulière dans un champ). La mise en oeuvre d'une telle commande déclenche donc l'émission vers l'un ou l'autre des modules de données représentatives d'évènements.

Les modules reçoivent des données représentatives d'évènements, et génèrent à partir de celles-ci des données représentatives d'autres évènements, elles-mêmes réémises dans d'autres messages, etc. Une transition d'état est déclenchée en cas d'occurrence d'un ou 5 plusieurs événements donnés, en d'autres termes en cas de réception de données caractéristiques de ce ou ces événements. Le composant logiciel configuré pour déclencher une transition est le gestionnaire de focus GF. Seront décrits plus loin plus en détail les mécanismes événementiels mis en oeuvre au sein de l'application. 10 De façon préférée, l'instanciation/désinstanciation de modules P1-P5 se fait en identifiant quels modules apparaissent/disparaissent. En d'autres termes, l'étape (b) comprend lors d'une transition d'un premier état à un deuxième état, l'instanciation des modules P1-P5 associés dans le fichier 15 M1-M3 de description d'états au deuxième état mais pas au premier état. Les modules P1-P5 associés dans le fichier M1-M3 de description d'états au premier état mais pas au deuxième état sont ensuite désinstanciés. Un module associé dans le fichier M1-M3 de description d'états à la 20 fois au premier état et au deuxième état est maintenu instancié, et ré initialisé. Par exemple, si l'on passe d'un état dans lequel Pi, P2 et P3 étaient instanciés à un état dans lequel Pi, P2 et P4 doivent l'être, on aura seulement deux actions : l'instanciation de P4 et la désinstanciation de P3. 25 Cette procédure permet de minimiser encore les ressources impliquées, pour une efficacité maximale. Au fur et à mesure de l'exécution de l'application, une pluralité de transitions peuvent être mises en oeuvre, et les étapes (a) puis (b) sont 30 donc répétées. Cet enchaînement de transitions est appelé « navigation ».

On comprendra que l'un des états est un état initial, c'est-à-dire que le lancement de l'application correspond par convention à une transition d'un état « vide », sans aucun module P1-P5 instancié, vers cet état initial.

Gestion de modules au sein d'un état De façon préférée, un module instancié est par défaut « inactif », c'est-à-dire qu'il n'effectue pas de traitement (et ne génère pas de données représentatives d'événements), et n'interagit pas avec les autres modules instanciés. Le procédé comprend ainsi avantageusement une étape (c) d'activation et/ou de désactivation d'au moins un des modules P1-P5 instanciés en fonction d'une commande issue d'une action de l'utilisateur ou applicative sur le terminal 1. Lorsqu'un module reçoit des données (de la part d'un autre module), il est « stimulé » et traite alors les données qu'il reçoit (en utilisant les ressources du terminal 1). Il peut générer à son tour, comme expliqué, des données, éventuellement envoyées à d'autres modules. Gestionnaire de modules Un troisième composant logiciel est avantageusement également mis en oeuvre par les moyens de traitement de données, le gestionnaire de modules GP (visible également sur la figure 2). Ce gestionnaire de modules GP permet de charger et/ou décharger dans les deuxièmes moyens de stockage de données 13 des modules Pi-P5. Une bibliothèque complète de modules P1-P5 peut être associée à une fonction complète (par exemple la VoD) que l'utilisateur n'utilise pas ou plus, et le gestionnaire de modules GP peut ainsi permettre leur déchargement pour économiser des ressources.

Le gestionnaire de modules GP peut également gérer le remplacement de certains modules par d'autres (par exemple en cas de mise à jour) à la manière des DLL évoqués dans l'introduction.

Terminal Selon un deuxième aspect, l'invention concerne le terminal pour la 5 mise en oeuvre du procédé selon le premier aspect. Ce terminal comprend comme expliqué précédemment des moyens de traitement de données 11, des premiers moyens de stockage de données 12 et des deuxièmes moyens de stockage de données 13, L'application est stockée sur ces derniers, en d'autres termes une 10 pluralité de modules P1-P5 d'une application et au moins un fichier M1-M3 de description d'états de l'application sont stockés sur les deuxièmes moyens de stockage de données 13, chaque module P1-P5 permettant la mise en oeuvre de fonctionnalités de l'application lorsque instancié sur les premiers moyens de stockage de données 12, une pluralité d'états E1-E4 15 correspondant chacun à une phase de l'exécution de l'application, au moins un module P1-P5 étant associé à chaque état E1-E4 dans le fichier M1-M3 de description d'états ; Les moyens de traitement de données 11 sont ainsi configurés pour mettre en oeuvre lors de l'exécution de l'application : 20 o Un gestionnaire de focus GF pour le calcul (en particulier en fonction d'une commande issue d'une action d'un utilisateur sur le terminal 1) d'au moins une transition d'un premier à un deuxième état choisis parmi la pluralité d'états E1-E4 ; o Un gestionnaire d'état GE pour l'instanciation et/ou la 25 désinstanciation, sur les premiers moyens de stockage de données 12, d'au moins un module de ladite pluralité de modules P1-P5, de sorte que dans chaque état de ladite pluralité d'états E1-E4 les modules P1-P5 instanciés sur les premiers moyens de stockage de données 12 soient les 30 modules associés audit état dans le fichier M1-M3 de description d'états.

Packaging Le « packaging » désigne le montage de l'application, c'est-à-dire son conditionnement en un produit mis à la disposition du public pouvant 5 être placé sur les deuxièmes moyens de stockage de données 13 du terminal, par exemple via téléchargement. Lors de ce packaging, on met les composants (modules P1-P5, fichiers de description d'états M1-M3, descripteurs, etc.) dans un seul ou plusieurs paquets. 10 Selon un troisième aspect, l'invention concerne ainsi un procédé de montage d'une application apte à être exécutée par des moyens de traitement de données 11 d'un terminal 1 tel que décrit précédemment (conforme au deuxième mode de réalisation), en d'autres termes exécutée conformément au procédé d'exécution selon le premier aspect de 15 l'invention. Ce procédé de montage comprend ainsi des étapes de : sélection d'une pluralité de modules P1-P5 de l'application et d'au moins un fichier M1-M3 de description d'états associé au terminal 1 (et éventuellement d'au moins un descripteur), chaque module P1-P5 20 permettant la mise en oeuvre de fonctionnalités de l'application lorsque instancié sur des premiers moyens de stockage de données 12 du terminal 1, une pluralité d'états E1-E4 correspondant chacun à une phase de l'exécution de l'application, au moins un module P1-P5 étant associé à chaque état E1-E4 dans le fichier M1-M3 de 25 description d'états ; compilation de l'ensemble comprenant ladite pluralité de modules P1-P5 de l'application et l'au moins un fichier M1-M3 de description d'états (et le cas échéant le ou les descripteurs) en au moins un paquet exécutable par les moyens de traitement de données 11 du 30 terminal 1.

Selon un premier mode de réalisation de cet aspect de l'invention, ce paquet est exécutable par une pluralité de terminaux (il contient donc tous les fichiers M1-M3 et les éventuels descripteurs associés à chacun de ces terminaux).

Alternativement, il est spécifique au terminal 1 et ne contient que le fichier M1-M3 associé au terminal 1 et les descripteurs associés au terminal 1. Il peut même comprendre uniquement les modules P1-P5 qui sont associés à un état utilisé par le terminal, en d'autres termes ne pas comprendre les modules P1-P5 qui ne sont associés à aucun état pour le 10 terminal (par exemple le module P2 « Bandes-annonces » avec le fichier M3, qui est en effet absent de la figure 3c). Cette sélection des composants est en effet très facile à mettre en oeuvre (pas de recompilation nécessaire), cela pouvant même être fait automatiquement, et a plusieurs avantages. Tout d'abord, le paquet est allégé. Ensuite, on prévient tout effet de 15 bord que pourraient causer les composants supplémentaires.

Claims (13)

1. REVENDICATIONS1. Procédé d'exécution d'une application par des moyens de traitement de données (11) d'un terminal (1), le terminal (1) comprenant en outre des premiers moyens de stockage de données (12) et des deuxièmes moyens de stockage de données (13), le procédé étant caractérisé en ce qu'il comprend des étapes de : (a) calcul en fonction d'une commande issue d'une action d'un utilisateur sur le terminal (1) d'au moins une transition d'un premier à un deuxième état choisis parmi une pluralité d'états (E1-E4) correspondant chacun à une phase de l'exécution de l'application ; (b) instanciation et/ou désinstanciation sur les premiers moyens de stockage de données (12) d'au moins un module d'une pluralité de modules (P1-P5) permettant chacun la mise en oeuvre de fonctionnalités de l'application lorsque instancié, de sorte que dans chaque état de ladite pluralité d'états (E1-E4) les modules (P1-P5) instanciés sur les premiers moyens de stockage de données (12) soient les modules associés audit état dans un fichier (M1-M3) de description d'états, le fichier (M1-M3) étant associé au terminal (1), les modules (P1-P5) et le fichier (M1-M3) étant stockés sur les deuxièmes moyens de stockage de données (13).
2. 2. Procédé selon la revendication précédente, dans lequel les premiers moyens de stockage de données (12) sont une mémoire vive, et les deuxièmes moyens de stockage de données (13) sont une mémoire de masse.
3. 3. Procédé selon l'une des revendications précédentes, dans lequel l'application comprend une pluralité de fichiers de description d'états (M1-M3), chaque fichier (M1-M3) étant associé à des terminaux différents.
4. 4. Procédé selon l'une des revendications précédentes, dans lequel l'étape (b) comprend l'instanciation des modules (P1-P5) associés dans le fichier (M1-M3) de description d'états au deuxième état mais pas au premier état, et la desinstanciation des modules (P1-P5) associés dans le fichier (M1-M3) de description d'états au premier état mais pas au deuxième état.
5. 5. Procédé selon la revendication 4, dans lequel un module associé dans le fichier (M1-M3) de description d'états à la fois au premier état et au deuxième état est maintenu instancié, et relancé.
6. 6. Procédé selon l'une des revendications précédentes, comprenant la répétition des étapes (a) puis (b).
7. 7. Procédé selon l'une des revendications précédentes, comprenant suite à l'étape (b) une étape (c) d'activation et/ou de désactivation d'au moins un des modules (P1-P5) instanciés en fonction d'une commande issue d'une action de l'utilisateur sur le terminal (1).
8. 8. Procédé selon la revendication 7, dans lequel un module activé génère des données représentatives d'événements en fonction des actions de l'utilisateur sur le terminal (1), une transition d'état, une activation ou une désactivation d'un module correspondant à un événement donné.
9. 9. Procédé selon l'une des revendications précédentes, dans lequel chaque module (P1-P5) met en oeuvre le modèle Modèle-VueContrôleur (MVC).
10. 10. Procédé selon l'une des revendications précédentes, dans lequel l'application comprend en outre au moins un fichier descripteurassocié au terminal (1), les moyens de traitement de données (11) étant configurés pour modifier l'apparence sur une interface du terminal (1) d'un module (P1-P5) instancié sur les premiers moyens de stockage de données (12) en fonctions de données dudit fichier descripteur.
11. 11. Terminal (1) comprenant des moyens de traitement de données (11), des premiers moyens de stockage de données (12) et des deuxièmes moyens de stockage de données (13), le terminal (1) étant caractérisé en ce que : Une pluralité de modules (P1-P5) d'une application et au moins un fichier (M1-M3) de description d'états de l'application sont stockés sur les deuxièmes moyens de stockage de données (13), chaque module (P1-P5) permettant la mise en oeuvre de fonctionnalités de l'application lorsque instancié sur les premiers moyens de stockage de données (12), une pluralité d'états (E1-E4) correspondant chacun à une phase de l'exécution de l'application, au moins un module (Pi-P5) étant associé à chaque état (E1-E4) dans le fichier (M1-M3) de description d'états ; les moyens de traitement de données (11) sont configurés pour mettre en oeuvre lors de l'exécution de ladite application : o Un gestionnaire de focus (GF) pour le calcul d'au moins une transition d'un premier à un deuxième état choisis parmi la pluralité d'états (E1-E4) ; o Un gestionnaire d'état (GE) pour l'instanciation et/ou la désinstanciation, sur les premiers moyens de stockage de données (12), d'au moins un module de ladite pluralité de modules (P1-P5), de sorte que dans chaque état de ladite pluralité d'états (E1-E4) les modules (P1-P5) instanciés sur les premiers moyens de stockage de données (12) soient les modules associés audit état dans le fichier (M1-M3) de description d'états.
12. 12. Terminal selon la revendication 11, dans lequel les moyens de traitement de données (11) sont en outre configurés pour mettre en oeuvre un gestionnaire de modules (GP) pour charger et/ou décharger des modules (P1-P5) dans les deuxièmes moyens de stockage de données (13).
13. 13. Procédé de montage d'une application apte à être exécutée par des moyens de traitement de données (11) d'un terminal (1) selon l'une des revendications 11 et 12, le procédé étant caractérisé en ce qu'il comprend des étapes de : sélection d'une pluralité de modules (P1-P5) de l'application et d'au moins un fichier (M1-M3) de description d'états associé au terminal (1), chaque module (P1-P5) permettant la mise en oeuvre de fonctionnalités de l'application lorsque instancié sur des premiers moyens de stockage de données (12) du terminal (1), une pluralité d'états (E1-E4) correspondant chacun à une phase de l'exécution de l'application, au moins un module (P1-P5) étant associé à chaque état (E1-E4) dans le fichier (M1-M3) de description d'états ; compilation de l'ensemble comprenant ladite pluralité de modules (P1-P5) de l'application et l'au moins un fichier (M1-M3) de description d'états en au moins un paquet exécutable par les moyens de traitement de données (11) du terminal (1).