Entwickeln für das iPad

Nach dem iPhone erobert nun auch das iPad einen lange Zeit für nebensächlich erachteten Markt. Da das Design der grafischen Oberfläche, die Ergonomie und die Performance wichtiger denn je sind, ist ein Umdenken angesagt, wenn man für Apples neues Stück Hardware Anwendungen schreiben will.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 11 Min.
Von
  • Oliver Szymanski
Inhaltsverzeichnis

Nach dem iPhone erobert nun auch das iPad einen lange Zeit für nebensächlich erachteten Markt. Da das Design der grafischen Oberfläche, die Ergonomie und die Performance wichtiger denn je sind, ist ein Umdenken angesagt, wenn man für Apples neues Stück Hardware Anwendungen schreiben will.

Apple bezeichnet das iPad als "magisches und revolutionäres Gerät". Doch die Idee eines Tablet-PCs ist nicht neu, und auch auf Hardwareseite überrascht das iPad nicht. Solche Geräte gibt es schon seit Jahren. Aber sie haben es nicht geschafft, relevante Marktanteile zu erobern. Das wird sich wohl ändern, denn Apple hat in den ersten 28 Tagen seit Markteinführung immerhin eine Million Geräte verkauft. Das ist weit mehr als zum gleichen Zeitpunkt bei der Einführung des iPhones, dessen Erfolg heute niemand mehr anzweifelt.

Für die Entwicklung von iPad-Applikationen nutzt man das gleiche SDK, das auch für die iPhone-Entwicklung notwendig ist. Somit stehen einige der neuen Funktionen, die mit der Einführung des iPads ins Framework gekommen sind, auch für Apples kleinere mobile Geräte zur Verfügung. Als Programmiersprache ist Objective-C vorgegeben. Diese nachrichtenorientierte Sprache basiert auf C/C++ und verlangt vom Entwickler somit allein durch Header-Dateien und Speicherverwaltung mehr Arbeit als bei der Programmierung von Android-Anwendungen. Weiteres Teil des SDK ist der iPad-Simulator zur Ausführung der erstellten Apps.

Bei einem Touch-Gerät wie dem iPad steht die grafische Oberfläche der Apps im Fokus. Daher hat sich im neuen SDK viel bei den Views getan, aus denen die grafischen Oberflächen bestehen.

Die App-Oberflächen sind streng nach dem Modell-View-Controller-Prinzip (MVC) zu programmieren. Entwickler können die Views entweder programmatisch auf Codeebene zusammenbauen oder mit einem Designer erstellen. Ein View erhält zur Laufzeit einen Controller, und die anzuzeigenden Daten entsprechen dem Modell. Die folgenden View-Arten halfen bereits bei der Darstellung von Informationen auf dem Display der kleineren Geräte:

  • Der Navigation-basierte View (Navigation-based View) ist eine Art View-Stack, der neue Views über vorherige einblendet und die Möglichkeit bietet zurückzunavigieren.
  • Der TableView dient der tabellarischen Aufbereitung der Daten.
  • Mit dem WebView lassen sich Webinhalte anzeigen.
  • Der ImageView eignet sich für Bilder.
  • Der ScrollView bedient Inhalte, die über die Bildschirmgrenzen reichen.
  • Dazu kommen beliebige selbst komponierte Views.

Das neue Framework sieht folgende neuen Views vor:

  • Popovers zeigen den Inhalt überlagert vor den anderen Views an. Bei einer Berührung oder einem Klick außerhalb der Grenzen des View wird der Popover wieder verborgen.
  • SplitViews dienen als Container für zwei nebeneinander dargestellte Views. Zum Beispiel kann man einen View mit einem Baum zum Navigieren und einen für die Detailansicht gleichzeitig anzeigen.
  • Custom Input Views helfen, spezifische Eingabemöglichkeiten anzubieten. Somit ist die Eingabe nicht mehr nur auf die Standard-Bildschirmtastatur beschränkt.

Gerade eine Kombination aus SplitView und Popover ergibt Sinn, wenn man das Display des iPad optimal ausnutzen möchte. Wird das iPad quer (Landscape-Modus) gehalten, zeigt man zwei Views am besten nebeneinander an. Bei hochkanter Position (Portrait-Modus) nutzt man den Popover, um bei Bedarf einen der Views anzuzeigen.

Damit die Position des iPads Einfluss auf ein Programm hat, müssen alle beteiligten ViewController die shouldAutorotateToInterfaceOrientation-Methode überschreiben, was die gewünschte Orientierung erlaubt. Gerade beim iPad sollten Anwendungen immer darauf vorbereitet sein, dass der Nutzer das Gerät beliebig halten kann. Das fängt damit an, dass man das Startfenster bei iPad-Anwendungen für alle Orientierungen optimiert hinterlegen sollte. Sind die einzelnen Views und ihre ViewController vorhanden, wird der SplitView angelegt.

// Erzeugen des ersten ViewController
TreeViewController *treeView = [[TreeViewController alloc]
initWithNibName:@"Tree"
bundle:[NSBundle mainBundle]];
// Erzeugen des zweiten ViewController
ContentViewController *contentView = [[ContentViewController alloc]
initWithNibName:@"Content"
bundle:[NSBundle mainBundle]];
// Erzeugen des Split ViewController
UISplitViewController *splitController =
[[UISplitViewController alloc] init];
// Die ViewController bekannt machen
splitController.viewControllers = [NSArray
arrayWithObjects:treeView, contentView, nil];
// Den SplitView anzeigen
[window addSubview:splitController.view];
[window makeKeyAndVisible];
// Das Aufräumen nicht vergessen
[treeView release];
[contentView release];
[splitController release];

Als Standardeinstellung verbirgt der SplitView den ersten View im Portrait-Modus. Möchte man auf Popover verzichten und in diesem Modus einen SplitView verwenden, lassen sich die Methode willAnimateRotationToInterfaceOrientation: duration: überschreiben und je nach Orientierung die Größen der Views anpassen. Will man den ersten View im Portrait-Modus nicht nur verbergen, sondern ihn als Popover anbieten, implementiert man das UISplitViewControllerDelegate-Protokoll, um auf SplitView-spezifische Ereignisse reagieren zu können.

Es sei nun ein Knopf in der Toolbar vorgesehen, der den TreeView anzeigt. Der Knopf soll nur sichtbar sein, wenn der TreeView sich nicht auf dem Display befindet. Alles Weitere wie die eigentliche Anzeige des TreeView im PopoverView erfolgt automatisch. Dazu legt man die Toolbar wie folgt mit einem Button an. (Um zukunftssicher zu sein, sollten der Button-Titel eigentlich internationalisiert und die Größenkonstanten nicht fix eingetragen sein, das Beispiel vernachlässigt das aber.) Eine Member-Variable für die Toolbar (UIToolbar *toolbar) muss dazu vorab angelegt werden.

// Tree View Controller wird nicht sichtbar =» Toolbar anzeigen
- (void)splitViewController:(UISplitViewController*)svc
willHideViewController:(UIViewController *)aViewController
withBarButtonItem:(UIBarButtonItem*)barButtonItem
forPopoverController:(UIPopoverController*)pc {


barButtonItem.title = @"Tree";
if (toolbar == NULL) {
toolbar = [[UIToolbar alloc]
initWithFrame:CGRectMake(0, 0, 1024, 44)];
[toolbar setItems:[NSArray arrayWithObject:barButtonItem] animated:YES];
}

// Toolbar dem Content View hinzufügen
UIViewController* contentController = [svc.viewControllers objectAtIndex:1];
[contentController.view addSubview:toolbar];
}

// Tree View wird angezeigt =» Toolbar verbergen
- (void)splitViewController:(UISplitViewController*)svc
willShowViewController:(UIViewController *)aViewController
invalidatingBarButtonItem:(UIBarButtonItem *)button {

// Toolbar entfernen
[toolbar removeFromSuperview];
}