Mobile-Builder-API (On-Prem)

Innerhalb einer ABAP-Klasse, die an eine View gebunden ist, greifen Sie über die Mobile-Builder-API auf das Frontend zu. On-prem läuft der Austausch zwischen App und Backend über den REST-Kanal /mobbuild/run, die Basisklasse ist /mobbuild/cl_request_base. Die Methoden der View-Klasse sind in beiden Welten gleich (Cloud-Fassung: Mobile-Builder-API Cloud). Sie lesen Werte aus Komponenten, setzen Properties, navigieren zwischen Views und zeigen Meldungen.

Methodensignatur und Klassennamen

Die exakten Methoden-Signaturen, Klassennamen und Importing-/Exporting-Parameter entnehmen Sie der ABAP-Klasse, die der Mobile Builder beim Generieren erzeugt. Die folgende Beschreibung dokumentiert den funktionalen Umfang der API – die genauen Aufrufe halten Sie sich aus dem generierten Code vor Augen.

Funktionsbereiche

Bereich	Was macht die API?
Properties lesen / setzen	Aktuelle Werte einer Komponente ermitteln oder verändern
Items setzen	Listen, Tabellen, ComboBoxen mit Daten füllen
Navigation	Wechsel zwischen Views der App
Meldungen	Toast, Strip oder Dialog anzeigen
Value-State setzen	Komponente als Error, Warning, Success markieren
App-Daten	Aktuelle App-ID, View-ID und übersetzte Texte abfragen

Properties lesen und setzen

Über die API lesen Sie den Wert einer Komponente (z.B. den Inhalt eines Eingabefelds) oder schreiben einen neuen Wert. Üblich sind:

Property	Komponenten	Beispielzweck
value	Input, TextArea, StepInput	Eingabe lesen und auswerten
text	Label, Title, Button, Text	Anzeigetext setzen
selected / state	CheckBox (selected), Switch (state); RadioButton über selectedIndex der Gruppe	Status lesen / setzen
selectedKey	ComboBox, SegmentedButton	Aktuelle Auswahl lesen
enabled / editable	enabled bei Button, CheckBox, Link, SegmentedButton, StepInput; editable bei Input, TextArea, ComboBox, TimePicker, CheckBox, StepInput	Komponente sperren/freigeben
visible	die meisten Anzeige- und Eingabekomponenten (nicht App, View, Content, Kopf-/Fußzeile, HBox, VBox, ToolbarSpacer, ComboBoxItem und die Logic-Flow-Bausteine)	Komponente ein-/ausblenden

Zahlen- und Dezimalwerte

Werte übergeben Sie an das Frontend immer als Text — dabei gilt:

• Lange Ziffernfolgen (HU-Nummern, EANs, Belegnummern — mehr als 15 Stellen oder mit führenden Nullen) kommen exakt so an, wie Sie sie übergeben.
• Dezimalwerte formatieren Sie im ABAP (WRITE ... TO lv_text — nutzt automatisch das Dezimalformat aus den SU01-Benutzervorgaben) und übergeben z. B. 1,5 oder 12,50. Komma-Werte werden vom Frontend garantiert nicht verändert und exakt so angezeigt — auch die Nachkomma-Null bleibt erhalten.
• Punkt-Dezimalen wie 1.5 werden dagegen als Zahl interpretiert und normalisiert angezeigt (12.50 → 12.5).
• Beim Auslesen (PAI) erhalten Sie den Wert im selben Format als Text zurück — Komma-Werte parsen Sie im ABAP entsprechend zurück.

Items setzen (Listen / Tabellen)

Listen-Komponenten füllen Sie mit einer Datenmenge. Übergeben werden Daten in tabellarischer Form. Für Table sind dabei zusätzlich die Spaltenbindungen relevant – diese vergeben Sie über das Eigenschaften-Panel oder pflegen sie als Items mit benannten Feldern.

Navigation

Mit set_nav_to( iv_view_id ) wechseln Sie zur Laufzeit von einer View in eine andere. Einziger Parameter ist die controlId der Ziel-View (z.B. detail); Daten nimmt die Methode nicht entgegen.

Daten für die Ziel-View reisen getrennt davon über die globalen Daten (Bag):

Methode	Bedeutung
add_global_data( iv_key, io_data )	Wert (Elementar, Struktur oder Tabelle) unter einem Schlüssel ablegen
get_global_data( iv_key, co_data )	Wert zu einem Schlüssel wieder auslesen
remove_global_data( iv_key )	Schlüssel entfernen

Der Bag geht mit jeder Antwort an das Frontend und kommt mit dem nächsten Request zurück. Im Lifecycle-Hook on_pbo der Ziel-View lesen Sie ihn aus und initialisieren die View damit (z.B. Detail-Daten zu einer markierten ID nachladen).

Meldungen

Drei Varianten:

Typ	Verwendung
Toast	Kurze, nicht-blockierende Bestätigung (z.B. „Gespeichert")
MessageStrip	Persistente Hinweis-Leiste in der View (z.B. Validierungsfehler)
Dialog	Modale Rückfrage (z.B. „Möchten Sie wirklich löschen?") mit Bestätigen / Abbrechen

Value-State / Validierung

Beim Setzen des Value-States markieren Sie eine Komponente farblich:

State	Bedeutung	UI-Effekt
None	Standard	Keine Markierung
Information	Info	Blau
Success	Erfolg	Grün
Warning	Warnung	Gelb
Error	Fehler	Rot

Zusätzlich können Sie einen State-Text setzen, der als Tooltip oder Hilfetext angezeigt wird.

Validatoren (siehe Funktionen) erledigen einfache Prüfungen automatisch – die Backend-API ist für fachliche Validierungen, die nicht client-seitig entschieden werden können (z.B. „Ist die Bestellnummer im SAP-System bekannt?").

App-Daten

Über die API erfragen Sie Metadaten zur laufenden App:

Information	Verwendung
Aktuelle App-ID	Logging, Audit
Aktuelle View-ID	Verzweigungen je nach Quell-View
Übersetzte Texte	get_text( iv_key ) liefert den Text in der Anmeldesprache des Benutzers; get_i18n( iv_iso639 ) und get_i18n_text( iv_iso639, iv_key ) laden die Texte einer angegebenen Sprache. Eine eigene Abfrage der aktiven Sprache gibt es nicht

Beispielablauf

Typische Event-Methode für einen Login-Button:

1. Eingabefelder lesen – Username und Passwort über get_value( ) der Eingabekomponenten (allgemein: get_property_value( iv_key = 'value' ))
2. Backend-Prüfung – ABAP-Logik gegen Benutzer-Tabelle
3. Bei Erfolg – Toast „Willkommen", Navigation in die mainList-View
4. Bei Fehler – set_value_state('Error') + State-Text auf den Eingabefeldern, Toast „Anmeldung fehlgeschlagen"

Hilfsmethoden in der gebundenen Klasse

Eigene Hilfsmethoden organisieren Sie wie üblich in privaten Methoden der View-Klasse oder in separaten Helper-Klassen. Die Mobile-Builder-API ist nur in den von außen aufgerufenen Methoden (Lifecycle, Events) garantiert verfügbar – innerhalb von Hilfsmethoden müssen Sie ggf. den API-Kontext durchreichen.

Nächste Schritte

• Event-Methoden – die typischen Einstiegspunkte für API-Aufrufe
• Konstanten-Attribute – controlIds typsicher in der API verwenden