1                     Themenübersicht

Dieses Dokument soll als Leitfaden und Referenz für die Entwicklung von mobilen Anwendungen dienen. Als mobile Anwendungen sind solche UI-Anwendungen zu verstehen, deren Zielplattform nicht der übliche PC oder Notebook darstellt, sondern ein mobiles Gerät wie beispielsweise ein Smartphone.

Die Entwicklung von mobilen Anwendungen erfolgt generell nach demselben Programmiermodell und mit derselben Entwicklungsumgebung wie die Entwicklung von UI-Anwendungen für den Desktop. Die Ausführungen in diesem Dokument beschränken sich daher auf die Anforderungen und Unterschiede, die speziell für mobile Anwendungen gelten.

2                     Zielgruppe

• Entwickler
• Technische Berater

3                     Einführung

Mobile Anwendungen sind Anwendungen, die speziell für den Einsatz auf mobilen Geräten entworfen wurden. Im Rahmen dieses Dokuments sollen unter mobilen Geräten vorrangig aktuelle Smartphones verstanden werden, da diese immer beliebter und leistungsfähiger werden. Smartphones verbinden die Funktionalität von Telefon und PDA (Handheld-Computer) in einem „immer-dabei“ Gerät. Durch die integrierten Sensoren und den fast an jedem Ort verfügbaren Netzwerkzugang dienen Smartphones inzwischen als Plattform für fast jede Art von Anwendung („Es gibt für alles eine App“). Die erfolgreichen Anwendungen sind aber nicht einfach „kleinere“ Versionen von bereits vorher existierenden Desktop-Anwendungen, sondern häufig völlig neu entwickelte Anwendungen für Aufgaben, die Benutzer speziell im mobilen Kontext benötigen. Anders als ein Computer den man an seinem Arbeitsplatz oft für mehrere Stunden nutzt um damit umfangreiche Aufgaben zu erledigen, werden Smartphones meistens nur dazu verwendet um eher „nebenbei“ bestimmte Informationen abzurufen. Dabei kommt es besonders darauf an, dass die Benutzer möglichst intuitiv und effizient an die von ihnen benötigten Informationen kommen.

Weitere wichtige Rahmenbedingungen für mobile Anwendungen sind natürlich die geringe Bildschirmgröße und ein für Touchscreens optimiertes Bedienmodell. Bei Geräten mit Touchscreens kommt es darauf an, dass alle Bedienelemente groß genug sind, damit sie mit dem Finger (besser Daumen) sicher bedient werden können. Für die gängigen Bildschirmgrößen bedeutet dies maximal ca. 10 Zeilen bzw. maximal 5 Buttons pro Zeile. Bei der Entwicklung von mobilen Anwendungen ist es daher unumgänglich, die wirklich wichtigen bzw. besonders häufig benötigten Informationen zu identifizieren und die Oberfläche entsprechend zu strukturieren. Selten benötigte Informationen oder Aktionen sollten dann entweder in separate Bildschirmseiten ausgelagert oder ganz weggelassen werden.

In den meisten Fällen werden mobile Anwendungen dazu genutzt um Informationen abzufragen, und nicht um neue Daten zu erfassen oder zu ändern. Mobile Anwendungen sollten die Anzeige und das Ändern/Erfassen von Daten möglichst trennen, beispielsweise mithilfe eines eigenen „Bearbeiten“ Dialogs, der explizit über einen „Bearbeiten“ Button geöffnet werden muss. Diese Vorgehensweise wird empfohlen, weil im Anzeigemodus alle leeren Felder automatisch unterdrückt werden und im Editiermodus bestimmte Eigenschaften der der Felder unterdrückt werden (z.B. Links). Darüber hinaus führen editierbare Felder leichter zu Fehlbedienungen, weil die Geräte nicht immer eindeutig erkennen können, ob der Benutzer den Fokus in Feld setzen oder innerhalb einer Bildschirmseite scrollen wollte.

3.1               Technik

Für die Programmierung von mobilen Anwendungen (Apps) setzen die Smartphone-Hersteller auf verschiedene Techniken. Neben der nativen Programmierung, beispielsweise in Objective-C/iOS oder Java/Android, bieten sie auch die Möglichkeit Anwendungen in HTML, CSS und JavaScript zu erstellen und diese dann in dem Browser des Geräts anzuzeigen. Im Gegensatz zu nativen Anwendungen ist damit eine plattformübergreifende Programmierung von Anwendungen relativ einfach möglich. Desweiteren macht dieser Ansatz den Anwendungsentwickler auch unabhängig von den so genannten „App-Stores“ des jeweiligen Herstellers. Gegenüber nativen Anwendungen unterliegen HTML/JavaScript basierte Anwendungen auch gewissen Einschränkungen, so sind beispielsweise in der Regel keine Zugriffe auf Sensoren oder Daten des Geräts möglich. Es gibt aber bereits Erweiterungsvorschläge für HTML5 um entsprechende Schnittstellen zu standarisieren.

Aus Sicht des ERP Systems kommt für mobile Geräte grundsätzlich die gleiche Technik zum Einsatz wie für Client-Computer mit Internet Explorer. In beiden Fällen wird eine dynamische HTML-Seite mit CSS und JavaScript erzeugt in der dann die einzelnen ERP-Anwendungen laufen. Für die mobilen Geräte wird intern lediglich eine eigene „Rendering-Engine“ verwendet, die für die nötigen Anpassungen an die Geräte und deren Browser sorgt.

3.2               Entwicklung

In Bezug auf die Entwicklung gibt es nur geringe Unterschiede zwischen mobilen und „normalen“ (Desktop) Anwendungen. In beiden Fällen handelt es sich um CisUiApplications, die auf gleiche Weise programmiert werden können. Dies gilt nicht nur für die Programmierung, sondern auch für die Anpassbarkeit der Oberfläche, die Übersetzbarkeit, die Auslieferung, die Erweiterbarkeit (Apps/Hooks) und so weiter. Der wesentliche Unterschied liegt in der speziellen „Rendering-Engine“, die beim Zugriff von mobilen Geräten zum Einsatz kommt. Während beim Zugriff über einen Desktop-Browser alle UI-Elemente in ihrer gewohnten Visualisierung präsentiert werden, wird beim Zugriff über einen mobilen Browser eine für Smartphones passende Darstellung genutzt. Von dieser Änderung sind nicht nur Form und Funktion einzelner UI-Elemente betroffen, sondern auch die Rahmenanwendung. Durch die spezielle Rendering-Engine ergeben sich allerdings auch bestimmte Einschränkungen und Vorgaben für die UI-Programmierung der mobilen Anwendungen. So unterstützt die Rendering-Engine beispielsweise nicht alle UI-Elemente und bestimmte Elementeigenschaften sind fest vorgeben.

Ob eine UI Anwendung auf mobilen Geräten angeboten wird, entscheiden die Einstellungen in dem zugehörigen Entwicklungsobjekt „Anwendung“. In dem Auswahlfeld „Anzeige- und Wartungseinstellungen“ muss dazu entweder „Mobile Geräte“ oder „Alle Geräte“ ausgewählt werden. Es ist also auch möglich eine Anwendung zu erstellen, die sowohl auf dem Desktop als auch auf Smartphones genutzt werden kann. Bei anpassbaren Anwendungen können dann sogar unterschiedliche Ansichten für die Verwendung auf dem Desktop bzw. dem Smartphone definiert werden. Generell ist jedoch davon auszugehen, dass sich die inhaltlichen Anforderungen sowie das Bedienmodell für diese Anwendungstypen soweit unterscheiden, dass besser zwei separate Anwendungen erstellt werden sollten. Unabhängig von dieser Entscheidung kann innerhalb von Anwendungen oder Anwendungskomponenten geprüft werden, in welchem Kontext die Anwendung bzw. Komponente verwendet wird. So kann beispielsweise eine EditorFactory unterschiedliche Editoren für den Desktop bzw. das Smartphone erzeugen. Entsprechende Auskunft gibt der „SessionType“, der an der Klasse CisEnvironment erfragt werden kann.

Hinweis: Die Anwendung com.cisag.app.general.partner.ui.MobilePartnerInfo ist kann als Beispiel für eine mobile Anwendung genutzt werden.

3.3               Anpassbarkeit

Mobile Anwendungen unterscheiden sich bei der Anpassbarkeit nicht von anderen UI Anwendungen. Ob und welche Teile einer Anwendung angepasst werden können, entscheidet der Entwickler der Anwendung über entsprechende Einstellungen im Entwicklungsobjekt „Anwendung“, durch das Einbinden von „DataViews“ sowie der Konfiguration der programmierten Oberflächenelemente (z.B. per VisualElement#setCustomizabe). Wie bei allen anpassbaren UI Anwendungen, erfolgt die Anpassung der Oberfläche im Designmodus der Anwendung. Die Anwendungen müssen dazu aber in einer Dialog-Session (Internet Explorer) geöffnet werden, die Anpassung direkt auf dem mobilen Gerät ist nicht möglich. Das Öffnen der mobilen Anwendungen muss gegebenenfalls aus dem zugehörigen Entwicklungsobjekt „Anwendung“ erfolgen, da mobile Anwendungen nicht im Navigator (Benutzermenü) aufgeführt werden.

Je nach Konfiguration im Entwicklungsobjekt „Anwendung“ lassen sich Ansichten für den Desktop, für Smartphones oder beides erstellen. Wenn die anpassbare Anwendung für alle Geräte zugelassen ist, kann im Designmodus beim Erstellen einer neuen Ansicht der gewünschte Typ ausgewählt werden.

4                     Benutzerschnittstelle

Die Benutzeroberfläche ist in einzelne Seiten (Views) organisiert. Eine solche Seite füllt jeweils die gesamte Bildschirmfläche aus, sie kann vertikal aber auch größer sein (erfordert Scrolling). Eine Anwendung kann aus einer oder mehrerer solcher Seiten bestehen. Typischerweise sind die Seiten hierarchisch strukturiert und dienen der Gruppierung von Detailinformationen. Die Anwendungen selbst werden durch eine übergeordnete Rahmenanwendung organisiert, die sich selbst auch als Startseite präsentiert.

4.1               Startseite

Die verfügbaren Anwendungen werden auf der Startseite (Home) als Schaltflächen präsentiert und können von dort durch einfaches Antippen geöffnet werden. Um häufig oder erst kürzlich benutze Anwendungen möglichst einfach im Zugriff haben zu können, ist die Startseite in die Rubriken „Favoriten“, „Verlauf“ und „Alle Anwendungen“ unterteilt.

Startseite

Alle Anwendungen

4.1.1          Favoriten

Die Rubrik „Favoriten“ listet die Anwendungen auf, die vom Benutzer explizit als „Favorit“ gespeichert wurden.

4.1.2          Verlauf

In der Rubrik „Verlauf“ werden die zuletzt geöffneten Anwendungen aufgelistet. Bereits als Favorit gelistete Anwendungen werden im Verlauf jedoch automatisch unterdrückt.

4.1.3          Alle Anwendungen

Die Rubrik „Alle Anwendungen“ gruppiert alle verfügbaren Anwendungen nach ihrer Framework-Zugehörigkeit in einzelne Unterseiten.

Hinweis: Im Entwicklungsobjekt „Anwendung“ muss als „Anzeige- und Wartungseinstellung“ entweder „Mobile Geräte“ oder „Alle Geräte“ ausgewählt sein damit eine Anwendung hier im Menü erscheint. Außerdem kann ein Benutzer natürlich nur die Anwendungen sehen, für die er berechtigt ist.

4.2               Navigationsleiste

Am oberen Rand des Bildschirms befindet sich die Navigationsleiste. Die Navigationsleiste zeigt üblicherweise eine Beschreibung (Titel) zu der gerade aktuellen Ansicht. Zusätzlich kann die Navigationsleiste auch ein oder mehrere Steuerelemente enthalten. Die Steuerelemente in der Navigationsleiste können je nach Ansicht entweder der Navigation zwischen verschiedenen Ansichten oder zur Steuerung des Inhalts dienen.

4.2.1          Anwendungen

Die Start- bzw. Hauptseite jeder Anwendung verfügt über eine besondere Navigationsleiste, in die neben dem Titel auch noch ein Identifikationsfeld sowie andere Bedienelemente eingebettet sein können.

Navigationsleiste mit Identifikationsfeld

4.2.1.1      Titel

Am oberen Rand der Navigationsleiste wird die Bezeichnung der aktuellen Anwendung zusammen mit der Bezeichnung des Systems angezeigt. Dies entspricht den Informationen, die bei Desktop-Anwendungen in der Titelleiste des Browserfensters angezeigt werden.

4.2.1.2      Identifikationsfeld

Die Identifikation des aktuell geöffneten Objekts wird in dem „Identifikationsfeld“ angezeigt. Dieses Feld kann, soweit es die Anwendung zulässt auch für die direkte Eingabe einer Identifikation genutzt werden, beispielsweise um ein bestimmtes Objekt zu öffnen.

Typischerweise handelt es sich bei dem Identifikationsfeld um ein „EntitiyField“, es können aber auch andere Feldtypen verwendet werden.

Das Identifikationsfeld muss durch die Anwendung bereitgestellt werden, indem das gewünschte Feld als einziges Feld der IndentPane der CisUiApplication hinzugefügt wird. Falls in der IndentPane mehrere (sichtbare) Felder enthalten sein sollten, wählt die Infrastruktur einfach das erste (sichtbare) Feld aus. Alle übrigen Felder aus der IndentPane scheinen nicht auf der Oberfläche.

Hinweis: Bei der Erstellung von anpassbaren Anwendungen muss darauf geachtet werden, dass die IndentPane nicht anpassbar ist, also nur die WorkPane angepasst werden kann. Am einfachsten lässt sich das realisieren, indem nur die Workpane mittels DataViewUI#resgister() registriert wird. Alternativ kann auch der Aufruf von VisualElement#setCustomizable(Customizable.FALSE) genutzt werden um die Anpassbarkeit für die Workpane zu deaktivieren.

Hinweis: Mehrteilige Identifikationen (z.B. Art und Nummer) müssen in einem (Text)Feld zusammengefasst werden.

4.2.1.3      Aktualisieren

Der „Aktualisieren“ Button ist mit der LoadAction des MainCoolBars verbunden und hat dieselbe Funktionalität wie auch in den Desktop-Anwendungen, d.h. er aktualisiert die Daten der aktuellen Anwendung bzw. öffnet das Objekt mit der im Identifikationsfeld eingetragenen Identifikation.

Bei Anwendungen mit Identifikationsfeld ist der „Aktualisieren“ Button optisch in das Feld integriert, ansonsten befindet er sich am rechten Rand der Navigationsleiste.

Hinweis: Anwendungen können die Sichtbarkeit des „Aktualisieren“ Buttons über die Methode „setEnabled()“ der zugehörigen LoadAction steuern.

4.2.1.4      Suchen

Wenn die Anwendung ein Identifikationsfeld bereitstellt und dieses Identifikationsfeld über eine Wertehilfe (SearchManager) verfügt, wird am rechten Rand der Navigationsleiste automatisch ein „Suchen“ Button eingeblendet. Nach Antippen diesen Buttons wird ein Suchdialog geöffnet (siehe Suchen).

4.2.1.5      Hinzufügen

Mit dem Button „Hinzufügen“ kann die aktuelle Anwendung den Favoriten (siehe Favoriten) hinzugefügt werden.

4.3               Werkzeugleiste

Die Werkzeugleiste (Toolbar) ist Bestandteil der Rahmenanwendung und befindet sich am unteren Rand jeder Anwendung (Hauptansicht).

Werkzeugleiste

4.3.1          Zurück

Der „Zurück“ Button blättert rückwärts durch die zuletzt geöffneten Objekte.

4.3.2          Vorwärts

Der „Vorwärts“ Button funktioniert entgegengesetzt zum „Zurück“ Button.

4.3.3          Startbildschirm

Der Button „Startbildschirm“ wechselt zu der Startseite.

4.3.4          Weitere Aktionen

Über den Button „Weitere Aktionen“ sind die Aktionen erreichbar, die wegen des beschränkten Platzes nicht direkt in der Werkzeugleiste angeboten werden können. Die Auflistung der jeweils möglichen Aktionen erfolgt in einer speziellen Liste (Action sheet), die von unten über die aktuelle Anwendung geschoben wird.

Partner-Info

Startseite

Welche Aktionen in der Liste angeboten werden, ist abhängig von der jeweils aktuellen Anwendung. Das Framework analysiert dazu die „MainCooBar“ der Anwendung und übernimmt daraus bestimmte „Actions“ in die Liste. Das erste Kriterium für die Auswahl der Actions ist ihre „Action-ID“. Von den Standardaktionen werden nur „CREATE“, „UPDATE“, „EDIT“, „DELETE“ und „EXIT“ übernommen. Zusätzlich werden alle anwendungsspezifischen Actions übernommen, deren Action-IDs im Bereich zwischen 1 und 9999 liegen. Das zweite Kriterium ist der Zustand der Action. Nur sichtbare und aktive (enabled) Actions werden übernommen. Eine Besonderheit stellt die Startseite dar. Statt der Aktion „Schließen“ (EXIT) wird dort die Aktion „Abmelden“ angeboten. Die „Abbrechen“ Aktion wird automatisch hinzugefügt, über sie kann der Benutzer die Liste schließen und zur Anwendung zurückkehren, wenn er versehentlich den Button „Weitere Aktionen“ angetippt hatte.

Hinweis: Der verfügbare Platz ist sehr beschränkt und die verwendete Liste bietet kein Scrolling, daher muss darauf geachtet werden, dass nicht zu viele Actions verwendet werden.

Hinweis: Der in der Liste dargestellte Text wird aus dem aus der Action erstellten Button ermittelt Für den Fall, dass der Button keinen Text besitzt wird auf den ToolTip zurückgegriffen. Die Texte der verwendeten Actions sollten nicht zu lang gewählt werden, da sie sonst umgebrochen werden müssen und dadurch weniger Platz für andere Buttons zur Verfügung steht.

4.3.5          Offene Anwendungen

Der Button „Offene Anwendungen“ öffnet eine Liste mit allen geöffneten Anwendungen. Ein Wechsel zu einer bestimmten Anwendung erfolgt durch Antippen des entsprechenden Eintrages in der Liste.

Liste mit offenen Anwendungen

4.4               Dialoge

Dialoge und Popup-Fenster werden gleichermaßen in einer eigenen Bildschirmseite dargestellt. Meldungen und Bestätigungsdialoge hingegen werden als halbtransparentes Popup-Fenster über die zuvor aktive Bildschirmseite gelegt.

Dialog

Alle Dialoge und Popup-Fenster werden automatisch mit einem „Zurück“ Button ausgestattet. Es können auch eigene Buttons bereitgestellt werden. Dazu muss der Dialog eine „ButtonBar“ enthalten und diese darf bis zu zwei Buttons (Actions) enthalten. Ist in der „ButtonBar“ ein eigener „CANCEL“ oder „CLOSE“ Button enthalten, so ersetzt dieser den Standard „Zurück“ Button oben links in der Navigationsleiste. Enthält die „ButtonBar“ einen Button, der weder „CANCEL“ noch „CLOSE“ entspricht, wird er auf der rechten Seite Navigationsleiste eingefügt. Alle weiteren Buttons werden ignoriert.

4.4.1          Meldungen

Anders als bei den Desktop-Anwendungen, gibt es für die mobilen Anwendungen keine Meldungsleiste oder Statuszeile. Stattdessen werden Fehlermeldungen und Warnungen in einem Popup-Fenster dargestellt. Bei Fehlermeldungen, die sich auf ein bestimmtes Feld beziehen, wird zusätzlich auch das betroffene Feld markiert.

Popup-Fenster mit Meldung

Hinweis: Die Anzeige ist aktuell für einzelne Fehlermeldungen optimiert, bei umfangreichen Fehlerlisten besteht die Gefahr, dass der Benutzer nicht alle Meldungen einsehen kann.

Hinweis: Warnungen können aktuell nicht bestätigt werden und wirken sich daher wie Fehlermeldungen aus.

4.4.2          Bestätigungsdialoge

Bestätigungsdialoge (Klasse com.cisag.pgm.gui.ConfirmationDialog) werden speziell behandelt und als Popup-Fenster geöffnet. Die Buttons werden auch hier automatisch aus der ButtonBar extrahiert, allerdings sind die Regeln etwas anders. Die ButtonBar darf wiederum nur maximal zwei Buttons haben, bei zwei Buttons wird der „Default“-Button grundsätzlich rechts positioniert und in einer etwas helleren Farbe dargestellt.

Bestätigungsdialog

4.5               Felder

Die Darstellung von Feldern ist speziell an die geringe Bildschirmbreite angepasst. Der Label wird immer über dem Feldinhalt platziert, so dass für beide möglichst viel Platz in der Breite zur Verfügung steht.

Feld mit Label

4.5.1          DialogButton

Der „DialogButton“ kann dazu genutzt werden, um zu einem Feld weitere „Details“ anzuzeigen oder bearbeiten zu lassen. Typischerweise wird dazu über den ActionListener der „DialogAction“ ein zusätzlicher Dialog bzw. Popup-Fenster geöffnet. Abhängig davon, ob das Feld noch weitere Interaktionen erlaubt (z.B. Link oder Editierbarkeit), dient entweder das gesamte Feld oder nur der rechte Teil als Schaltfläche zum Öffnen des Dialogs. Erkennbar ist dies an der Form und Farbe des Pfeilsymbols.

Nur DialogButton

Link mit DialogButton

Hinweis: Die Verwendung eines DialogButtons schließt gleichzeitig die Verwendung einer Wertehilfe aus.

Über eine spezielle Property kann ein Feld mit DialogButton auch so konfiguriert werden, dass der Label wie die Titelzeile bei einem Shelf (s. unten) dargestellt wird. Der Wert des Feldes dient in diesem Fall als Vorabinformation für den Dialog. Wenn im Dialog beispielsweise eine Liste mit offenen Rechnungen angezeigt wird, dann sollte das Feld als Vorabinformation die Anzahl der offenen Rechnungen bereitstellen. Auf Grund der Darstellung und des geringen verfügbaren Platzes sollte es sich dabei immer nur um einen Integer-Wert handeln.

DialogButton mit Property „addclass=counter“

Das Setzen der Property ist aktuell nur über die Klasse VisualElement aus dem Package com.cisag.pgm.dialog und die Methode setClientProperty möglich:

WebInterface.getVisualElement(field).putClientProperty(“addclass”, “counter”);

4.5.2          Wertehilfe

Bei editierbaren Feldern wird am rechten Rand ein Button zum Öffnen einer Wertehilfe bereitgestellt, sofern das Feld über einen SearchManager verfügt und der Platz nicht bereits durch einen DialogButton belegt ist. Bei Antippen des Feldes öffnet sich die entsprechende Suche (siehe Suchen).

EntityField mit SearchManager

Hinweis: Der aktuelle Wert des Feldes kann derzeit nur über den Suchdialog geändert werden.

4.5.3          Links

Felder können als Link verwendet werden, dabei ist zwischen internen und externen Links zu unterscheiden. Interne Links führen zum Aufruf eines entsprechenden Listeners (z.B. ActionListener oder MouseListener) in der Anwendung, während externe Links direkt durch den Client bearbeitet werden.

Hinweis: Für EntityFields werden die Links (Standardeintrag aus dem Kontextmenü) automatisch bereitgestellt.

Hinweis: Um Fehlbedienungen zu vermeiden, wird die Linkfunktionalität bei editierbaren Feldern automatisch deaktiviert.

Externe Links

Der Inhalt eines TextFields kann als externer Link interpretiert werden, dazu ist der entsprechende „Content-Type“ entweder in der zugehörigen DataDescription anzugeben oder direkt per API am Feld zu setzen. Es werden URIs für Webseiten, E-Mail Adressen und Telefonnummern unterstützt, wobei das zugehörige URI Schema (http:, mail: bzw. tel:) automatisch anhand des Content-Types ermittelt wird. Bei Antippen solcher Felder auf dem Smartphone, sorgt der Browser dann dafür, dass die zur URI passende App gestartet wird, also Browser, E-Mail Client oder Telefon-App.

Wenn ein externer Link unabhängig vom Feldinhalt benötigt wird, kann dieser auch durch Setzen einer Property bei einem Feld hinterlegt werden. Der dazu notwendige Code lautet:

WebInterface.getVisualElement(field).putClientProperty(“uri”, “http://www.comarch.de/erp”);

Hinweis: Externe Links lassen sich auch über den Server, also beispielsweise als Reaktion auf eine Action, öffnen. In diesem Fall ist die Methode startExternalApplication der Klasse ApplicationManager zu benutzen.

4.6               Suchen

Für alle Wertehilfen, die auf der Klasse DefaultSearchManager basieren, wird ein generischer Suchdialog bereitstellt. Dieser Suchdialog erlaubt nach der Bezeichnung zu suchen und zeigt in der Ergebnisliste die gefundenen Datensätze mit ihrer Identifikation, Bezeichnung und gegebenenfalls einer Löschkennzeichnung an. Welche Attribute dazu herangezogen werden, wird anhand der zugehörigen Metadaten automatisch ermittelt, also genau die Attribute, die in der OQL-Suche als „Identifikation“, „Bezeichnung“ bzw. „Löschkennzeichen“ klassifiziert wurden.

Suchen

4.7               Container

Als Strukturelemente können die Klassen View, GroupBox und Shelf verwendet werden. Es können die folgenden LayoutManager verwendet: BorderLayout, BoxLayout und StandardLayout. Für die Verwendung des StandardLayouts gilt jedoch die Einschränkung, dass die Inhalte grundsätzlich einspaltig layoutet werden, unabhängig von der tatsächlichen Spaltenanzahl. Desweiteren werden Elemente mit „ReferenceConstraints“ nicht berücksichtig.

Hinweis: Die Containerstruktur kann auch im Design-Modus definiert werden, die Programmierung der Containerstruktur in der Anwendung ist also nicht erforderlich.

Automatische Unterdrückung von Feldern und Containern

Um die Übersichtlichkeit auf der kleinen Bildschirmfläche zu verbessern, werden Felder und andere UI Elemente automatisch entfernt wenn sie deaktiviert oder leer und gleichzeitig nicht änderbar sind. Dieses Verhalten wird ggf. über die  gesamte Containerkette nach oben propagiert, d.h. wenn in einem Container keine oder nur unterdrückte Element liegen, wird auch der Container selbst unterdrückt.

4.7.1          GroupBox

GroupBoxen (Rubriken) unterscheiden sich zwar in der Darstellung, verhalten sich aber ansonsten wie auf dem Desktop. Der Titel ist optional und aufgrund der vorhandenen Abstände und Farbgebung können auch GroupBoxen ohne Titel zum Gruppieren von zusammengehörenden Informationen verwendet werden. Das Schachteln von GroupBoxen ist hingegeben nicht zu empfehlen, da sich die Visualisierung dann nicht von zwei untereinander liegenden GroupBoxen unterscheiden würde. Das Schachteln von GroupBoxen und Shelfs (oder umgekehrt) ist für mobile Geräte unproblematisch (siehe nachfolgenden Abschnitt).

GroupBox mit Titel

GroupBoxen ohne Titel

4.7.2          Shelf

Shelfs (klappbare Rubriken) verhalten sich auf den mobilen Geräten etwas anders als auf dem Desktop. In dem Container, im das Shelf eingefügt wurde, ist immer nur die Titelzeile des Shelfs zu sehen. Erst bei Antippen der Titelzeile wird der eigentliche Inhalt des Shelfs sichtbar gemacht, aber nicht in der aktuellen Bildschirmseite, sondern in einer eigenen „Detailseite“. Diese Funktionalität ist auch an kleinen Pfeil am rechten Rand zu erkennen. In der Detailseite erscheint der Titel des Shelfs dann als Titel in der Navigationsleiste und zusätzlich ein „Zurück“ Button mit dem der Benutzer wieder zurück zur Ausgangsseite kommt.

Shelf (Titelzeile)

Detailseite

Als Inhalt von Shelfs können nicht nur Felder, sondern auch GroupBoxen und wiederum Shelfs verwendet werden. Auf diese Weise lassen Inhalte flexibel gruppieren und hierarchisch auf verschiedene Bildschirmseiten verteilen. Allzu tiefe Hierarchien sollten aber auch nicht verwendet werden, da mit jeder Hierarchiestufe auch die Navigationsarbeit für den Benutzer zunimmt.

Bei Shelf kann ein zusätzliches „Header“-Element gesetzt werden. Bei der Darstellung auf mobilen Geräten wird dies jedoch nur unterstützt, wenn es sich dabei um einen Label mit einem Icon handelt. In diesem Fall wird die Titelzeile vorn um dieses Icon ergänzt.

Shelfs mit zusätzlichem Label (Icon) als Header

4.7.3          TabbedPane

Karteireiter werden aktuell nicht unterstützt, stattdessen werden die einzelnen Karteireiter als Rubriken (GroupBoxen) untereinander dargestellt. Diese vereinfachte Darstellung ist nur vorrübergehend und sollte nicht gezielt verwendet werden.

4.8               Listen

Für Listen ist aktuell nur eine sehr rudimentäre Unterstützung vorhanden. Es werden nur „read-only“ Listen unterstützt. Es können nur einfache „ListViews“ (keine ExtendedListViews) verwendet werden und als LayoutManager muss „BoxLayout“ verwendet werden (ggf. geschachtelt). Bei der Anzahl der Datensätze ist Vorsicht geboten (es gibt keinen PageButton), da die Rechenleistung und der Hauptspeicher bei mobilen Geräten begrenzt sind. Eine sinnvolle Obergrenze liegt bei ca. 50 Zeilen (mehr Zeilen möchte auch kein Benutzer durch scrollen).

Liste

4.9               Tabellen

Für Tabellen ist aktuell nur eine sehr rudimentäre Unterstützung vorhanden. Es werden nur „read-only“ Tabellen unterstützt, keine Selektion und Tabellen sollten nicht mehr als zwei oder drei Spalten haben. Es kann aktuell auch nicht sichergestellt werden, dass alle Feldtypen in der Tabelle korrekt dargestellt werden. Die Empfehlung lautet daher, auf die Verwendung von Tabellen vorerst zu verzichten.

4.10          Charts

Über die Klasse com.cisag.pgm.gui.Chart können Balkendiagramme in die Oberfläche eingebunden werden. Zur Verfügung stehen einfache Balkendiagramme (Bar charts) und gestapelte Balkendiagramme (Stacked bar charts). Benutzeraktionen (Antippen einzelner Balken im Diagramm) können programmtechnisch ausgewertet und beispielsweise dazu genutzt werden, zu einem Balken weitere, detaillierte Informationen anzuzeigen (beispielsweise ein weiteres Diagramm).

Bar Chart

Stacked Bar Chart

Hinweis: Die Klasse com.cisag.pgm.gui.Chart kann aktuell nur auf mobilen Geräten genutzt werden. In normalen Dialoganwendungen wirft die Klasse eine UnsupportedOperationException. Daher sollte vor der Verwendung dieser Klasse immer die statische Methode „isSupported()“ genutzt werden, um die Verfügbarkeit auf der konkreten Plattform zu testen und ggf. stattdessen eine alternative Visualisierung zu wählen.

4.11          Nicht unterstützte Elemente

Die folgenden Elemente werden aktuell nicht unterstützt:

• 2D Grafik (Canvas, Shapes, Strokes, …)
• Header (Tabelle)
• ComboBox
• HTMLEditor
• ImageLabel
• LayeredPane
• LayeredIconField
• Menüs (Menu, MenuBar, MenuManager, PoppupMenu)
• SearchView (Grid-Control)
• SmartButton
• SplitPane
• ToggleButtons
• TabbedPane (siehe TabbedPane)
• Table (siehe Tabellen)
• Tree
• Upload (FileUploadElement)

4.12          Nicht unterstützte Eigenschaften

Die folgenden Eigenschaften werden aktuell nicht unterstützt:

• Absolute Positionierung (x, y)
• Accesskeys
• Backround (Color)
• Border
• ContextHelp
• Drag & Drop
• Fokussteuerung
• Font
• Foreground (Color)
• Guides
• KeyEvents
• Margins (Insets)
• PreferredWidth/Height, MinimumWidth/Height, MaximumWidth/Height
• ReferenceConstraints
• Shortcuts
• TextAttribute
• Texture (Icon)
• ToolTips
• UIManager
• Wertehilfen für Dezimal-, Datumswerte und Dokumente/Ordner
• Zwischenablage

5                     Testumgebung

Einfache Tests und Präsentationen können bereits mit einem Desktop-Browser mit Webkit-Engine (z.B. Google Chrome oder Safari) durchgeführt werden. Die Infrastruktur erkennt solche Browser und zeichnet um die Anwendung einen Rahmen im Stil eines iPhones. So lassen sich die Platzverhältnisse und Proportionen bereits grob abschätzen. Durch Variieren der Fensterbreite kann auch die Drehung des Gerätes simuliert werden.

Ein Test auf echten Geräten und unter realen Bedingungen bleibt jedoch unverzichtbar, da die Simulation mit dem Desktop-Browser einige wichtige Aspekte nicht ausreichend abbildet. Als Testgeräte sollten sowohl iOS als auch Android basierte Geräte zum Einsatz kommen. Folgende Punkte sollten dabei jeweils getestet werden:

• Reale Platzverhältnisse (Berücksichtigung von Browserleisten und Bildschirmtastatur sowie reale Elementgrößen)
• Performance (Berücksichtigung von CPU, Netzwerkbandbreite und -latenz)
• Touchscreen (Bedienung mit Finger/Daumen, Bildschirmtastatur, Scrolling und Fokussteuerung)
• Navigation zwischen Anwendungen (Apps)

Simulation in WebKit Browser (Google Chrome)

6                     Technische Hinweise

6.1               Unterstützte Geräte

Die Unterstützung mobiler Geräten ist aktuell auf die folgenden Geräte bzw. Plattformen beschränkt:

• iPhone (ab 3GS, iOS 4.1 oder höher)
• Smartphones mit Android 2.2 (oder höher)

6.1.1          iPhone

Home-Bildschirm

Der Browser (Safari) bietet die Möglichkeit eine Webseite als Link auf dem Home-Bildbildschirm zu speichern. Am unteren Rand des Bildschirms gibt es dazu in der Toolbar des Safari einen „Hinzufügen“ Button (dargestellt als „+“). In dem folgenden Popup-Fenster ist anschließend der Button „Zum Home-Bildschirm“ anzutippen. Danach folgt ein Dialog in dem der Name für den Link eingegeben bzw. geändert werden kann. Nach dem Bestätigen wird der Link mit Namen und Icon (vergleichbar mit einer nativen App) auf dem Home-Bildschirm dargestellt. Beim Starten über diesen Link blendet der Browser dann seine eigenen Bedienelemente (Navigationsleiste und Toolbar) komplett aus, so dass für die Webseite der gesamte Bildschirm zur Verfügung steht.

Anmeldeinformationen

In den getesteten iOS Versionen war es nicht möglich Benutzername und Kennwort zu speichern. Bei jedem Starten ist daher eine neue Eingabe erforderlich.

Ältere Geräte

Bei dem Modell 3G kommt es häufiger zu Verzögerungen. Bei iOS Versionen vor 4.1 gibt es zudem einige Darstellungsfehler.

6.1.2          Android

Home-Bildschirm

Für Android gibt es zwar auch die Möglichkeit einen Link auf dem Startbildschirm abzulegen, die Visualisierung dieses Links ist jedoch abhängig von der Oberfläche des jeweiligen Geräts bzw. Herstellers. Beim Starten über diesen Link zeigt der Browser leider weiterhin seine eigenen Bedienelemente (Adressleiste).

Hersteller spezifische Oberflächen

Einige Hersteller statten ihre Android basierten Smartphones mit einer eigenen Oberfläche und/oder alternativen Bildschirmtastaturen aus. Diese Erweiterungen können leider auch zu Darstellungsfehlern im Browser führen. Ein solches Verhalten wurde beispielsweise bei dem „Desire“ von HTC mit „Sense“ Oberfläche beobachtet. Bei diesem Gerät kann gibt es verschiedene Probleme im Zusammenspiel von Scrolling und dem Bearbeiten von Feldinhalten.

6.2               Bildschirmanpassung

Die Oberfläche passt sich automatisch an die Bildschirmbreite des jeweiligen Geräts an, dass gilt auch für das Drehen des Geräts von dem Hoch- in das Querformat. Die Inhalte sind für Hoch- und Querformat identisch, der Unterschied liegt lediglich darin, dass im Querformat horizontal mehr Platz für lange Texte vorhanden ist, aber dafür vertikal früher Scrolling notwendig wird. Diese Form der Bildschirmanpassung gilt auch für Tabletts (iPad und Android).

6.3               Sessions

Mobile Geräte werden von der Infrastruktur an dem „User-Agent“ Header ihres Browsers erkannt. Die Infrastruktur ordnet den mobilen Geräten einen eigenen Session-Typ zu. Für diese Sessions gelten die folgenden Besonderheiten:

• Spezielles UI (angepasst für WebKit basierte mobile Browser)
• Pro Benutzer ist nur eine Anmeldung gleichzeitig möglich. Bei erneuter oder weiterer Verbindung wird die bestehende Session entweder übernommen oder automatisch beendet.
• Die Session wird durch den Server bei Inaktivität noch ca. eine Stunde gehalten. Solange diese Zeit nicht überschritten wird, kann ein Benutzer seine Arbeit auch nach einer Pause oder Verbindungsunterbrechung einfach fortsetzen.
• Der Zugriff von mobilen Geräten muss im System-Cockpit unter „System/Benutzer-Zuordnungen“ explizit erlaubt werden.

Hinweis: Zur Laufzeit von Anwendungen kann der Session-Typ über die Methode „getSessionType()“ an der Klasse „CisEnvironment“ abgefragt werden.