Desktop-Version

Start arrow Informatik arrow Strategie für die Portierung von Desktop-Business-Anwendungen auf iOS-gestützte Endgeräte

< Zurück   INHALT   Weiter >

5.3.1 Layout

Das Layout einer Anwendung wird maßgeblich von drei Faktoren getragen. Zu diesen Faktoren zählen:

1. View-Hierarchie

2. Container-Ansicht

3. Content-Ansicht

Die View-Hierarchie gibt das gesamte Layout der Anwendung vor. Sie legt fest, welche Ansichten wie miteinander in Beziehung stehen.

Die Container-Ansichten sind das Werkzeug der View-Hierarchie, um die einzelnen Content-Ansichten zu ordnen. Sie bündeln verschiedene Content-Ansichten und stellen sie in unterschiedlichen Formaten dar.

Den tatsächlichen Anwendungsinhalt stellen die Content-Ansichten bereit. Eine Content-Ansicht bildet sich zumeist aus einem Anwendungskontext und fasst die notwendigen Interaktionselemente zusammen.

5.3.1.1 View-Hierarchie

Das Layout beschreibt die Anordnung von Interaktionselementen einer grafischen Benutzerschnittstelle.

Beide Plattformen fassen Interaktionselemente mit gleichem Anwendungskontext in einer so genannten View (in dt.: Ansicht) zusammen. Die Ansichten lassen sich in beliebiger Breite und Tiefe verschachteln, was letztendlich zu einer zusammengesetzten grafischen Benutzerschnittstelle führt. Auf beiden Plattformen entsteht hierdurch eine View-Hierarchie.

Abb. 5-11 zeigt die View-Hierarchie der Referenzanwendung auf der WindowsPlattform

ViewHierarchi-Win.png

Abb. 5-11 View-Hierarchie der Referenzanwendung (Windows)

Spezielle Komponenten beider Plattformen ermöglichen es, die Ansichten gleichzeitig (nebeneinander) oder abwechselnd (hintereinander) anzuzeigen. Dafür stellen übergeordnete Ansichten Platzhalter bereit, in die die speziellen Komponenten die untergeordneten Ansichten zur Laufzeit laden.

Abb. 5-12 zeigt die zusammengesetzte Ansicht der Referenzanwendung auf der Windows-Plattform.

Abb. 5-12 Zusammengesetzte Ansicht der Referenzanwendung (Windows)

(11 ) Shell

(22 ) MainRegionView

(33 ) MenuBarView

(44 ) StatusBarView

(55 ) EnvironmentSelectorView

(66 ) CustomerWorkEnvironmentView und CustomerWorkEnvironmentWizardView (77 ) CustomerDataView

Das Presentation Integration System (Siehe Anhang B) kennzeichnet diese Platzhalter als Regions (in dt.: Regionen). iOS hingegen kennzeichnet sie als View. Da letztendlich die untergeordnete View (Child View) der übergeordneten View (Parent View) als Subview hinzugefügt wird. Die beiden speziellen Komponenten zur Verwaltung der View-Hierarchie heißen:

- RegionManager (Windows)

- Container View Controller (iOS)

In .NET übernimmt ein RegionManager (in dt.: Regionenverwalter) die Verwaltung der einzelnen Ansichten. Die Ansichten werden im Vorfeld beim RegionManager registriert. Dieser lädt sie anschließend auf Anfrage in die gewünschte Region.

Der RegionManager ist somit eine zentrale Komponente, die alle Regionen der Anwendung verwaltet. Egal in welcher Hierarchiestufe sich die Ansicht befindet.

Der Kernunterschied ist, dass die in WPF erstellte Oberfläche regelbasiert/deskriptiv gesteuert wird. Diese Aufgabe übernehmen bei iOS funktional geschrieben Controller. Jede Ansicht ist mit einem ViewController assoziiert. Eine Ansicht, die ihrerseits wieder Ansichten enthält, ist ein Container, der zugehörige ViewController ist ein Container-ViewController; Ansichten die Interaktionselemente beinhalten, werden von einem Content-ViewController gesteuert.

In der Referenzanwendung ist beispielsweise die EnvironmentSelectorView-Ansicht ein Container, die durch einen Container-ViewController gesteuert wird.

Tab. 5-6 zeigt eine mögliche Zuordnung der Ansichten und ViewController-Typen auf der iOS-Plattform.

Ansicht

ViewController-Typ

MainRegionView

Container-ViewController

MenuBarView

Content-ViewController

EnvironmentSelectorView

Container-ViewController

StatusBarView

Content-ViewController

CustomerWorkEnvironmentView

Container-ViewController

CustomerWorkEnvironmentWizardView

Container-ViewController

CustomerDataView

Content-ViewController

ApplicationView

Content-ViewController

SampleView

Content-ViewController

InstrumentView

Content-ViewController

WorkflowEnvironmentView

Container-ViewController

WorkflowGanttView

Content-ViewController

WorkflowTaskListView

Content-ViewController

Diverse Dialoge

Content-ViewController

Tab. 5-6 Zuordnung Ansicht und ViewController-Typ in iOS

Beide Plattformen bieten gleichermaßen Technologien an, um eine strukturierte Ansichts-Hierarchie aufzubauen. Aus der Hierarchie lässt sich der Workflow einer Anwendung ableiten. Sie gibt somit vor, in welcher Reihenfolge ein Anwender die einzelnen Ansichten aufruft. Die CustomerWorkEnvironmentWizardView-Ansicht gibt beispielsweise vor, in welcher Reihenfolge ein Anwender die benötigten Daten zur Berechnung der Arbeitsablaufpläne eingibt bzw. auswählt. Die EnvironmentSelectorView-Ansicht trennt hingegen beide Arbeitsbereiche. Zum einen in die Dateneingabe und zum anderen in die Gestaltung des Arbeitsablaufplans.

Dadurch, dass auch das UIKit-Framework die notwendige Technologie bereitstellt, lässt sich diese sinnvolle Aufteilung und Verschachtelung auf ein iOS-Endgerät übertragen.

5.3.1.2 Container-Ansichten

Das vorherige Kapitel hat gezeigt, dass es grundsätzlich möglich ist, die ViewHierarchie der Windows-Version 1:1 auf die iOS-Version zu übertragen. Die veränderte Platzsituation auf einem iOS-gestützten Endgerät lässt dieses Vorhaben jedoch nicht durchgängig zu. Grunddessen sind neue Überlegungen zum Bildschirmdesign zu treffen.

Offensichtliche Probleme bereitet in diesem Kontext insbesondere das iPhone. Durch sein 4 Zoll Display steht für Ansichten von klassischen Desktop-Anwendungen kein adäquater Raum zur Verfügung. Aus diesem Grund erfolgt der Aufruf der einzelnen Ansichten hintereinander. Die Mail-App von Apple ist ein gutes Beispiel. Sie die Hauptansicht in drei Bereiche auf, die jeweils nebeneinander angezeigt werden

Menüleiste

Postfächer

Übersicht Mails

Inhalt der ausgewählten Mail

Abb. 5-13 Schematischer Aufbau der Mac OS-Mail-App

Die Mail-Anwendung des iPhone ruft diese Ansichten hintereinander auf:

image: ../Art/ds_mailscreens.png

Abb. 5-14 Schematischer Aufbau der iPhone-Mail-App195

1. Postfächer

2. E-Mails

3. Inhalt der E-Mail

Das iPad bietet aufgrund seines 9,7 Zoll Display schon mehr Gestaltungsfreiraum, kommt aber an einen Desktop-Monitor auch nicht heran. Das iPad zeigt die einzelnen Ansichten teils hintereinander und nebeneinander an. Der Aufruf der Postfächer und der enthalten E-Mails erfolgt hintereinander. Den Inhalt einer E-Mail zeigt die App daneben an.

image: ../Art/land_mail_orientation.png

Abb. 5-15 Schematischer Aufbau der iPad-Mail-App196

Grundsätzlich ist jede Ansicht (Content- und Container-Ansicht), der zu portierenden Anwendung, auf ihre Geometrie zu überprüfen. Auf Basis dieser Erkenntnisse ist im Anschluss zu entscheiden, welche Container-Ansichten einzusetzen sind. Im Detail bedeutet das, dass die vorhandenen Container-Ansichten auf ihre Anwendbarkeit zu prüfen sind.

Content-Ansichten die in ihrer Geometrie nicht zu verwenden sind, verlangen die Ergänzung zusätzlicher Container-Ansichten. Hierbei kann es vorkommen, dass Interaktionselemente mit einem einheitlichen Anwendungskontext auseinandergerissen werden. Das Mail-Bespiel zeigt jedoch, dass die auseinandergerissen Ansichten mithilfe von sinnvoll eingesetzten Containern in einem gleichbleibenden Arbeitsfluss verknüpft werden können.

Die Ansichten der Referenzanwendung sind in ihrer Geometrie auf eine Bildschirmauflösung von 1280 x 800 Pixeln ausgelegt. Für die Portierung auf das iPad sind somit kaum Anpassungen vorzunehmen. Die EnvironmentSelectorView-Ansicht und die CustomerWorkEnvironment-WizardView-Ansicht wurden 1:1 übernommen. Tab. 5-7 zeigt die Gegenüberstellung der EnvironmentSelectorView in Windows und iOS. Zu erkennen ist, dass kein wesentlicher Unterschied besteht.

Tab. 5-7 Gegenüberstellung EnvironmentSelectorView in Windows und iOS

Dennoch lassen sich nicht alle Container-Ansichten in ihrer Gestaltung übernehmen. Die WorkflowEnvironmentView benutzt eine Splitbar, um beide Unteransichten anzuzeigen. Eine Splitbar erlaubt es, die Größe des Anzeigebereichs der jeweiligen Ansichten zu verändern. Dieses Interaktionselement existiert im UIKit-Framework nicht. Aus diesem Grund stellt die WorkflowEnvironmentView die beiden Unteransichten abwechselnd dar.

Tab. 5-8 Gegenüberstellung WorkflowEnvironmentView Windows und iOS

5.3.1.3 Content-Ansichten

Zu den Content-Ansichten zählen die Ansichten, die die tatsächliche Bedienung der Anwendung ausmachen. Sie bündeln zumeist zusammenhängende Interaktionselemente, die einen bestimmten Anwendungsfall unterstützen.

Aber auch die Menü- und Statusleiste lassen sich den Content-Ansichten zuordnen, da sie keine untergeordneten Ansichten verwalten.

Tab. 5-9 zeigt eine Übersicht aller Content-Ansichten der Referenzanwendung.

Ansicht

Container-Ansicht

Menuleiste

MainRegionView

Statusleiste

MainRegionView

CustomerDataView

CustomerWorkEnvironmentWizardView

ApplicationView

CustomerWorkEnvironmentWizardView

SampleView

CustomerWorkEnvironmentWizardView

InstrumentsView

CustomerWorkEnvironmentWizardView

WorkflowGanttView

WorkflowEnvironmentView

WorkflowTaskListView

WorkflowEnvironmentView

Tab. 5-9 Übersicht über die Content-Ansichten der Referenzanwendung

Eine Menüleiste stellt allgemeine Befehle bereit, die in allen Ansichten eine gleichbleibende Bedeutung haben. Mithilfe der Maus oder einem Tasten-Kürzel kann der Anwender auf diese Befehle zugreifen. Da die Menüleiste nicht alle Befehle gleichzeitig anzeigt, werden zusammengehörige Befehle in einem Kontextmenü gruppiert.

Dieser Art der Ansicht existiert in iOS nicht. Für die Bewerkstelligung dieser Aufgabe stellt das UIKit-Framework die Toolbar bereit. Die Toolbar ist in iOS keine Ansicht, sondern ein Interaktionselement, das Schaltflächen und Labels aufnimmt.

Die iOS-Version der Referenzanwendung hat daher anstatt einer Menüleiste eine Toolbar, die am unteren Rand der CustomerWorkEnvironmentWizardView und WorkflowEnvironmentView angezeigt wird. Abhängig der angezeigten Ansicht (CustomerWorkEnvironment oder WorkflowEnvironment) enthält die Toolbar zusätzliche Schaltflächen.

Abb. 5-16 zeigt im oberen Teil die Menüleiste der Windows-Version und im unteren Teil die beiden Toolbars der iOS-Version.

- Obere Toolbar: Darstellung im CustomerWorkEnvironment

- Untere Toolbar: Darstellung im WorkflowEnvironment

Abb. 5-16 Gegenüberstellung Menüleiste und Toolbars

Anwendungen nutzen Statusleisten, um den Nutzer verschiedene Anwendungsinformationen anzuzeigen. Dazu zählt beispielsweise der Netzwerkstatus, der angemeldet Benutzername oder das aktuelle Datum. iOS kennt für dieses Ansicht keine standardisierte Alternative. Es obliegt dem Softwarearchitekten, solch eine Ansicht zu entwickeln.

In der Referenzanwendung existiert eine Statusleiste. Sie zeigt jedoch nur das Datum und die Uhrzeit an. Diese Information liefert auch die Statusleiste von iOS am oberen Bildschirmrand. Aus diesem Grund kann auf die Statusleiste der Referenzanwendung verzichtet werden. Hierdurch entsteht mehr Platz für die übrigen Komponenten.

Das Layout der Content-Ansichten, die anwendungsspezifische Interaktionselemente präsentieren, sollte weitestgehend erhalten bleiben. Hierdurch behält der Anwender ein einheitliches Benutzererlebnis auf beiden Plattformen. Aufgrund der zum Teil abweichenden Interaktionselemente, ist das nicht immer möglich, sollte aber dennoch der Treiber beider der Gestaltung der Oberfläche sein.

Windows

iOS

IMG_0017.PNG

Tab. 5-10 Gegenüberstellung der beiden InstrumentsViews

In der InstrumentView (Abbildungen in Tab. 5-10) können beispielsweise die Ansichten auf beiden Plattformen das gleiche Layout verwenden.

 
< Zurück   INHALT   Weiter >

Related topics