Pages 1 | 2 | 3 | 4

L'interface utilisateur de bas niveau

Cette API comprend les classes Canvas, Graphics et Font. La classe Canvas permet d'écrire des applications pouvant accéder aux événements de saisie de bas niveau, offrant ainsi un grand contrôle sur l'affichage. Les jeux sont la meilleure illustration du type d'application qui utilisera ce mécanisme.
Elle comprend également la classe Graphics. Elle permet de produire des graphiques en 2D. Elle est similaire à la classe java.awt.Graphics de J2SE.
La classe Font représente les polices de caractères ainsi que les métriques associées.

La gestion des événements
La classe Canvas est une sous-classe de la classe Displayable. Elle permet d'enregistrer un listener de commandes. Il est cependant préalablement nécessaire de créer plusieurs interfaces listener, chacune étant associée à un type d'événement.

Les touches
Chaque touche à laquelle un événement est associé est identifiée par un code de touche (exemple : KEY_NUM0 pour la touche 0).
Il existe trois types de méthodes de gestion des événements relatifs à ces touches : keyPressed(), keyReleased() et keyRepeated(). Attention, ce dernier événement n'est pas supporté par tous les terminaux. Pour savoir s'il est supporté, vous devez appeler la méthode hasRepeatEvents().

Les actions de jeu
Des actions de jeu sont prédéfinies. Ces actions correspondent par exemple aux flèches de déplacement (exemple : DOWN correspond à la touche pour descendre).

Les commandes
Comme avec les sous-classes de la classe Displayable, vous pouvez ajouter des commandes à un objet Canvas et enregistrer un CommandListener auprès de l'objet Canvas.

La gestion du pointeur
Sur certains terminaux, un pointeur peut être utilisé pour appuyer sur l'écran. Trois d'événements sont mis à votre disposition : pointerDragged(),pointerPressed() et pointerReleased(). Pour vérifier qu'un tel mécanisme est disponible sur le terminal sur lequel tourne le MIDlet, utilisez cette méthode : hasPointerEvents().

Le stockage persistent

RMS (Record Management System) est une API de stockage persistent sur le terminal. C'est en quelque sorte une base de données indépendante du terminal. Chaque enregistrement est représenté sous forme de tableau d'octets. La mise est jour est dite atomique : l'enregistrement entier est réécrit à chaque fois.
Les enregistrements sont stockés dans ce que l'on appelle un Record store. Si l'on veut faire un parallèle avec les SGBD relationnels, RMS correspond au SGBD lui-même et le Record store à la table. D'ailleurs, le parallèle de la notion de clé primaire des bases de données relationnelles est le recordID. Il s'agit de l'identifiant de l'enregistrement. C'est un nombre entier. La valeur de l'ID du premier enregistrement est 1 et chaque nouvel enregistrement a une valeur ID augmentée de un.
Plusieurs méthodes permettent de gérer les Records store.
openRecordStore et closeRecordStore permettent respectivement d'ouvrir et de fermer un Record store.
La liste de tous les Record store peut être obtenue par listRecordStore.
deleteRecordStore en supprime un.
Le nombre d'enregistrements dans un Record store est retourné par getNumRecords.
Les opérations de base sur les enregistrements sont assurées par ces méthodes : addRecord (ajout), deleteRecord (suppression), getRecord (lecture), setRecord (modification), getRecordSize (taille de l'enregistrement).
L'API RMS dispose cependant de quelques particularités supplémentaires, concernant la sélection des enregistrements. La première est l'utilisation de la méthode RecordEnumeration pour lister tous les enregistrements du Record store. La seconde est la possibilité de définir un filtre avec la méthode RecordFilter. Enfin, l'interface RecordComparator doit être implémentée pour que des enregistrements puissent être comparés et donc triés.

Pages 1 | 2 | 3 | 4