© Spirit Boom Cat/Shutterstock.com
Java am Microcontroller mit MicroEJ – Teil 4

Mehr Steuerelemente mit MicroEJ


Seit dem Aufkommen der ersten C-Compiler im Embedded-Bereich gilt, dass sich die Verwendung von Hochsprachen insbesondere dann lohnt, wenn die zu erledigende Aufgabe aus algorithmischer Sicht kompliziert ist. Das Rendern von Diagrammen und ähnlich fortgeschrittenen Steuerelementen ist – logischerweise – eine Paradeaufgabe für MicroEJ.

Wir haben im letzten Teil der Serie durchaus umfangreiche Experimente mit dem MicroEJ-GUI-Stack durchgeführt und dabei festgestellt, dass er uns insbesondere im Bereich der Realisierung der Steuerelemente nicht unerhebliche Freiheiten zur Verfügung stellt. In diesem Artikel wollen wir unsere Überlegungen zu diesem Themenkreis ein wenig vertiefen.

Herrscher der Flexibilität

Am Ende des letzten Teils hatten wir festgestellt, dass das von MicroEJ zur Demonstration des GUI-Stacks angebotene Programmbeispiel eine Abstraktionsklasse nutzt, um die drei verschiedenen Steuerelementgenerierungsarten über einen gemeinsamen Codepfad abbilden zu können.

Wir möchten uns als Erstes die Erzeugung von Steuerelementen anhand monochromatischer Bitmaps – in der Welt von MicroEJ nennt man diese Pictos – ansehen. Hier ist die Klasse PictoWidgetPage verantwortlich, deren relevanter Code gekürzt folgendermaßen beginnt:

public class PictoWidgetPage extends WidgetPage { @Override protected ToggleWrapper newCheckBox(String string) { return new Toggle(new PictoCheck(), string); }

Wir erinnern uns, dass die im letzten Artikel vorgestellte Elternklasse die einzelnen Steuerelementinstanzen nicht direkt generierte. Sie nutzte stattdessen abstrakte Methoden, die von den eigentlichen Implementationsklassen zur Verfügung zu stellen sind. So sehen wir, dass die Methode newCheckBox den Konstruktor dazu auffordert, ein neues Kindsteuerelement anzuliefern.

Wer die Klasse PictoCheck in Eclipse als zur Reflektion freizugeben markiert, stellt fest, dass er sich im Package ej.widget.basic.picto; wiederfindet. Dabei handelt es sich um eine Framework-Klasse, die im Allgemeinen nach dem Schema in Listing 1 aufgebaut ist.

Listing 1

public class PictoRadio extends PictoToggle { @Override protected char getCheckedPicto() { return Pictos.RADIO_CHECKED; } @Override protected char getUncheckedPicto() { return Pictos.RADIO_UNCHECKED; } }

Das Zurückgeben von in den Enum Pictos enthaltenen Werten informiert die MicroEJ-Rendering-Engine darüber, welches der Symbole für den jeweiligen Renderingprozess vorzusehen ist. Interessant ist hier nur, dass es sich bei den Pictos um eine von der Hostplattform zur Verfügung gestelltes Enum handelt.

Zur Erklärung: Denken wir zurück, so erinnern wir uns daran, dass wir unser Evaluations-Board im ersten Artikel mit einer vorgefertigten JVM ausgestattet haben. In der Welt von MicroEJ ist man als Entwickler nicht unbedingt dazu verpflichtet, diese als Plattform bezeichneten fertigen Pakete zu akzeptieren. Es ist genauso legitim, unter Verwendung von ARM KEIL und den von MicroEJ bereitgestellten Basisbibliotheken eine eigene Plattform zu kreieren und dieser entweder zusätzliche Funktionen oder aber andere Symbole einzuschreiben.

Da diese Vorgehensweise allerdings etwas haarig ist und Kenntnisse von C++ und der Host-Hardwarearchitektur voraussetzt, wollen wir uns mit ihr im Moment nicht aufhalten. Eine tiefer hängende Frucht ist es, den Rest der Klasse anzusehen, in dem wir unter anderem folgende Methode wiederfinden:

@Override protected ToggleWrapper newRadioButton(String string) { return new Toggle(new RadioModel(), new PictoRadio(), string); }

Die Erzeugung eines RadioButtons erfolgt dabei im Allgemeinen analog zur Checkbox. Neu ist nur, dass der Konstruktor nun neben dem für die Anzeige der Pictos vorgesehenen Element auch eine Instanz von RadioModel erwartet – sie ist eine Modellklasse, die dafür sorgt, dass der RadioButton die vom Benutzer angelieferten Informationen persistieren bzw. für die im Code-Behind befindliche Logik ansprechbar machen kann.

Interessant ist in diesem Zusammenhang noch die Methode newSlider, die für die Erzeugung eines neuen Slider Widgets verantwortlich ist:

@Override protected AbstractSlider newSlider(int min, int max, int initial) { return new PictoSlider(min, max, initial); }

Beachten Sie bei der Betrachtung dieser Methode vor allem, dass das Steuerelement in diesem Betriebsmodus drei zusätzliche numerische Werte aufnimmt. Sie legen die verschiedenen Parameter fest, die das numerische Verhalten des entstehenden Schiebesteuerelements vollständig qualifizieren.

Damit haben wir die Besprechung der Pictos hinter uns gebracht und können uns ihren auf vollfarbigen Grafiken basierenden Kollegen zuwenden.

Hierfür dient die Klasse ImageWidgetPage. Im Interesse der Kompaktheit drucken wir hier nur die Methode newCheckBox ab, die abermals für die Erzeugung neuer Checkboxen verantwortlich zeichnet:

public class ImageWidgetPage extends WidgetPage { @Override protected ToggleWrapper newCheckBox(String string) { return new Toggle(new ImageCheck(), string); }

Wie weiter oben gilt auch hier, dass die im MicroEJ SDK enthaltene Eclipse-Reflektionsfunktion der beste Freund des Java-Embedded-Entwicklers ist. Als Nächstes wollen wir deshalb die Klasse ImageCheck reflektieren. Auch hier gilt, dass wir uns in einem von MicroEJ bereitgestellten Paket wiederfinden, das nun aber auf den Namen ej.widg...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang