Erscheinungsbild
Mobile-Builder-API
Innerhalb einer ABAP-Klasse, die an eine View gebunden ist, greifen Sie über die Mobile-Builder-API auf das Frontend zu: 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 |
| Validierung auslösen | Validatoren einer Eingabe-Komponente prüfen |
| Value-State setzen | Komponente als Error, Warning, Success markieren |
| App-Daten | Aktuelle App-ID, View-ID, Sprache 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 | CheckBox, RadioButton, Switch | Status lesen / setzen |
selectedKey | ComboBox, SegmentedButton | Aktuelle Auswahl lesen |
enabled | Button, Input, alle Eingabe-Komponenten | Komponente sperren/freigeben |
visible | alle | Komponente ein-/ausblenden |
busy | View, ScrollContainer | Lade-Indikator anzeigen |
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
Über die Navigations-API wechseln Sie zur Laufzeit von einer View in eine andere. Übergeben werden:
| Parameter | Bedeutung |
|---|---|
| Ziel-View | controlId der Ziel-View (z.B. detail) |
| Kontext | Optional – Daten, die der Ziel-View beim Öffnen zur Verfügung stehen sollen |
Im Lifecycle-Hook on_pbo der Ziel-View greifen Sie auf den Kontext zu 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 |
| Aktive Sprache | Übersetzungen serverseitig laden |
| Aktuelle Mobile-Builder-Version | Diagnose |
Beispielablauf
Typische Event-Methode für einen Login-Button:
- Eingabefelder lesen – Username und Passwort über
get_property('value') - Backend-Prüfung – ABAP-Logik gegen Benutzer-Tabelle
- Bei Erfolg – Toast „Willkommen", Navigation in die
mainList-View - 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-Klasse –
controlIds typsicher in der API verwenden