Ein interessantes, spannendes iPad Projekt ist diese Tage zum Abschluss - und das Ergebnis zum Einsatz gekommen: Für die HSH Nordbank haben wir im Auftrag von BEST FRIEND eine Business iPad App der etwas anderen Art entwickelt. Die Brainwall Applikation besteht aus 6 iPads, die - fest in einer Säule verbaut - untereinander permanent kommunizieren und Informationen austauschen.

Jedes iPad präsentiert hierbei ein digitales Produkt, welches in einen Warenkorb gelegt werden kann. Beim Kaufvorgang blenden sich fünf der iPads synchron aus, das sechste iPad - der „Master“ - startet dann den Kauf-Workflow. Integriert in diesen Workflow ist ein Visitenkartenscanner, der automatisch die Adressdaten des Kunden bestimmt.

Das Ganze ist also eine Art digitales Verkaufsregal.

Die iPads müssen Informationen untereinander austauschen und auf Ereignisse reagieren, z.B.

• wenn ein Artikel in den Warenkorb gelegt oder von dort entfernt , muss das „Master“-Device dieses vermerken
• wenn der Kaufvorgang gestartet oder beendet wird, müssen alle iPads darau reagieren
• bei Inaktivität soll die ganze Anwendung - also alle iPads - in einen konsistenten Anfangszustand zurückgesetzt werden

Realisiert wurde die Synchronisierung der Devices mit dem GKSession-System von Apple. GKSession ermöglich den Aufbau von Peer2Peer Netzwerken.

Um dem Benutzer die Eingabe der Adressdaten via Tastatur abzunehmen, wurde ein automatischer Visitenkartenscan integriert. Zum Einsatz gekommen ist die Lösung, die wir bereits in unserer speedLEAD App im Einsatz haben.

Die iPads stellen digitale Produkte dar, die über Medien (Bilder und Videos) dargestellt werden; diese Medien werden in einem TYPO3-System bereitgestellt. Die iPads prüfen zu bestimmten Zeiten, ob im TYPO3 System aktualisierte Medien vorliegen und laden diese automatisch herunter. Die Aufteilung der Medien auf die iPads erfolgt ebenfalls im TYPO3. Schnittstelle zum iPad ist eine XML Datei.

Eine lokale CoreData Datenbank speichert die Warenkörbe solange vor, bis diese über WAN mit dem Zentralsystem synchronisiert werden können.

Wir haben uns dazu entschieden, die Anwendung als Master-Slave System zu konzipieren; also ein Master und fünf Slaves. Wir haben zwei Kommunikationsarten:

• ein Slave kann eine Nachricht zu dem Master schicken
• der Master kann eine Nachricht zu den fünf Slaves schicken.

Die Nachrichten sind getypt; Nutzdaten werden als JSON übertragen.

Da die iPads in einer festen Installation montiert sind, muss die App diese sehr viel robuster funktionieren als Devices „on hand“. Normalerweise ist es zulässig, bei bestimmten Systemzuständen (Resource kann nicht geladen werden; Warenkorb kann nicht übermittelt werden u.s.w.) den Benutzer darüber zu informieren und ihm Optionen anzubieten. Bei unserer App dagegen muss alles in hohem Maße fehlertolerant sein. d.h. wenn die iPads untereinander die Verbindung verlieren, muss die Applikation darauf automatisch reagieren. Wer sich mit Client-Server oder Peer2Peer Programmierung auskennt, weiß dass das nicht ganz trivial ist - denn wie bitteschön soll man Jemanden informieren, zu dem man keine Verbindung mehr hat?

Ebenfalls problematisch: die WAN Anbindung. Die iPads sind alle mit einem WLAN Router verbunden, der per UMTS Karte Verbindung zum WAN hält. Die iPad Applikation muss darauf vorbereitet sein, dass der Zugang zum WAN nicht vorhanden ist, der zum Wifi dagegen schon. Während das iPad bei Wifi davon ausgeht, dass die Verbindung zum „Internet“ steht, funktioniert außer Wifi eventuell rein garnichts. Aber immerhin - wenn Wifi funktioniert, so funktioniert wenigstens die Inter-iPad Kommunikation via GKSession.

Ein umfangreiches Settings-Menu erlaubt es, die Systemzustände zu ändern und zu überwachen. So lassen sich beispielsweise die Warenkörbe und auch die GKSession Zustände live mitverfolgen - für das Debugging der Client-Server Applikation ein unschätzbarer Wert.

Das Settingsmenu selber ist verborgen und nur über „geheime“ Gesten erreichbar - ein Cheat Code sozusagen.

Die grafisch anspruchsvolle Präsentation der Produkte wurde ohne Interfacebuilder programmiert. Der Kaufvorgang ist als Navigationcontroller implementiert; speziell die Back-Funktion des Navigationcontrollers passte sehr gut zum Konzept.

Wie auch bei unseren anderen Projekten haben wir festgestellt dass der Interfacebuilder zwar schön und gut ist - sobald es aber grafisch etwas anspruchsvoller sein soll, macht man es besser alles von Hand. Dies gilt besonders, wenn man in einer eigenen Hierarchie von Viewcontrollern arbeitet.

iPads quasi als Kiosksystem im öffentlichen Raum zu betreiben, bedeutet den Zugriff auf andere Apps zu limitieren. Da der Zugang zum Homebutton durch die spezielle Säulenkonstruktion geschützt ist, blieb noch die Multitasking-Bedienung in den Systemeinstellungen zu deaktivieren.

GKSession ist leider nicht ganz zuverlässig: GKSession Peers verlieren bisweilen die Verbindung. Reduzieren lässt sich dieses Fehlverhalten, wenn alle Devices auf der selben aktuellen iOS Version laufen. Ein weiteres großes Problem hat sich beim Laden von großen Files (Videos) gezeigt - die GKSession bremst das Netzwerksystem erheblich aus. Und zwar derart, dass die Kommunikation komplett einbricht. Wir haben dieses in den Griff bekommen, indem wir die Ladevorgänge der Devices vornehmen, bevor die GKSession Initialisierung startet. Nicht schön, aber vertretbar.

GKSession arbeitet mit Bluetooth und Wifi. Wir haben festgestellt, dass ohne Bluetooth die Robustheit der Session deutlich höher ist. Wie schön, dass wir - im Business-Kontext - dies voraussetzen können. Ärgerlich für AppStore-Apps, die nicht von ihren Benutzern erwarten können, das Bluetooth für eine App zu deaktivieren.

Zusammengefasst: Ein schönes, interessantes Projekt!

Das Ergebnis kann man hier bestaunen: Zur Referenz