Skip to content

Konstanten-Klasse

Damit Sie controlId-Werte im ABAP-Backend nicht als String-Literale tippen müssen, erzeugt der Mobile Builder auf Wunsch eine Konstanten-Klasse. Diese enthält für jede Komponente der View eine Konstante mit dem zugehörigen controlId-Wert.

Vorteile

VorteilBedeutung
TypsicherTippfehler werden zur Compile-Zeit erkannt
Refactoring-stabilEine Umbenennung in der View aktualisiert die Konstante
Code-VervollständigungIm ABAP-Editor schlägt die IDE alle verfügbaren controlIds vor
DokumentationEine zentrale Stelle, um zu sehen, welche Komponenten in der View existieren

Konstanten-Klasse erzeugen

Selektieren Sie im View-Tree die View und öffnen Sie im Eigenschaften-Panel den Reiter Binding. Klicken Sie auf das Konstanten-Klasse-Symbol:

Konstanten-Klasse erzeugen

Tragen Sie einen Klassennamen ein (z.B. ZCL_DEMO_LOGIN_CONST) und bestätigen Sie. Die Klasse wird im Paket der App angelegt und mit allen aktuellen controlId-Werten der View gefüllt.

Naming-Konvention

Generierte Klassen folgen dem Prefix mc_mb_ für interne Konstanten. Üblich für die View-Konstanten-Klasse ist Z<KUNDE>_<APP>_<VIEW>_CONST oder Z<KUNDE>_<APP>_<VIEW>_C.

Verwendung im Code

In den Event-Methoden Ihrer View-Klasse verwenden Sie die Konstanten anstelle von String-Literalen. Damit referenzieren Sie ein Eingabefeld nicht als 'inputUser', sondern als zcl_demo_login_const=>input_user.

Konstanten aktualisieren

Wenn Sie nach dem Generieren weitere Komponenten zur View hinzufügen, sind diese nicht automatisch in der Konstanten-Klasse enthalten. Erzeugen Sie die Klasse erneut – sie wird mit dem aktuellen Stand überschrieben.

Klasse wird überschrieben

Beim Re-Generieren werden eigene Anpassungen in der Konstanten-Klasse verloren gehen. Halten Sie die Konstanten-Klasse frei von Eigenlogik – verwenden Sie eine separate Klasse für eigene Erweiterungen.

Wann lohnt sich eine Konstanten-Klasse?

Bei kleinen Apps mit wenigen Komponenten ist sie optional. Empfehlenswert ist sie bei:

  • Views mit vielen Komponenten (≥ 10)
  • Views, deren Inhalt sich noch entwickelt (Refactoring-Sicherheit)
  • Apps, die in mehreren Mandanten gepflegt werden (Konsistenz)
  • Code-Reviews / Wartbarkeit über Teams hinweg

Nächste Schritte