New Multiscreen-Entwicklung für 3D-Benutzerschnittstellen · 2012. 9. 20. · I Inhaltsverzeichnis...

eingereicht von: eingereicht am: Betreuer:

Richard Pietsch29.02.2012Prof. Dr. Teresa Merino (HTW Dresden)Nils Döhring ( Jung von Matt/Neckar)

Multiscreen-Entwicklung für 3D-Benutzerschnittstellenunter Verwendung der Adobe Flash Plattform

Diplomarbeit

im Studiengang Medieninformatik

an der Hochschule für Technik und Wirtschaft Dresden (FH)Fachbereich Informatik/Mathematik

I

Inhaltsverzeichnis

Tabellen- und Abbildungsverzeichnis ....................................................................... IVListingverzeichnis ..................................................................................................... VIAbkürzungsverzeichnis .......................................................................................... VIII

1. Einleitung ......................................................................................1

1.1 Idee und Motivation ...............................................................................................11.1.1 Variierende Nutzungsszenarien von Informationstechnologien ....................11.1.2 Die Dynamik der Medieninformatik ...........................................................21.1.3 Betrieblicher Kontext: Die Werbeagentur Jung von Matt ............................2

1.2 Zielsetzung .............................................................................................................41.2.1 Entwicklungs- und Testumgebungen ..........................................................5

1.3 State of the Art .......................................................................................................61.3.1 Mobile noch in den Kinderschuhen .............................................................61.3.2 Die Multiscreen Challenge ..........................................................................61.3.3 Die 3D-Fähigkeiten früherer Flash-Versionen .............................................7

1.4 Struktur der Arbeit .................................................................................................8

2. Grundlagen ....................................................................................9

2.1 Die Adobe Flash Plattform als Werkzeug zur Entwicklung reichhaltiger Anwendungen ..............................................................................................................9

2.1.1 Die Entstehung von Flash ............................................................................92.1.2 Überblick über die Flash Plattform ............................................................102.1.3 Die aktuelle Stellung von Flash im Vergleich zu anderen Technologien ....122.1.4 Kontroversen ..............................................................................................15

2.2 Multiscreen-Entwicklung .....................................................................................172.2.1 Die Mobile Revolution ...............................................................................172.2.2 Multiscreen: Definition und Grundkonzept ..............................................182.2.3 Klassifizierung der Endgeräte ....................................................................192.2.4 Typen von Apps auf mobilen Geräten........................................................222.2.5 Multiscreen Muster ....................................................................................252.2.6 Konzeptmuster ...........................................................................................272.2.7 Technische Herangehensweisen .................................................................33

2.3 Flash und die dritte Dimension ............................................................................352.3.1 Die Darstellungsebenen im Flash Player ...................................................352.3.2 Die 3D-Render-Pipeline ............................................................................372.3.3 Die Verwendung von Stage3D ...................................................................382.3.4 Vor- und Nachteile von Stage3D ...............................................................42

3. Konzeption der Multiscreen-Anwendung ............................................... 43

3.1 Anforderungen .....................................................................................................43

II MULTISCREEN ENTWICKLUNG FÜR 3D-BENUTZERSCHNITTSTELLEN

3.2 Idee, Grobkonzept und erste Tests .......................................................................433.3 Technische Vorbetrachtungen ..............................................................................44

3.3.1 Gewählte technische Herangehensweise ....................................................443.3.2 Architektur der Anwendung unter Nutzung eines Mikroarchitektur-Frameworks (Robotlegs) .....................................................................................453.3.3 Konventionen .............................................................................................46

3.4 Entkoppelte Entwicklung einer Multiscreen-Anwendung ...................................463.4.1 Basis-Applikation .......................................................................................463.4.2 Screen-Applikation ....................................................................................48

3.5 Feinkonzept ..........................................................................................................493.5.1 iPad App (Mobile App) ..............................................................................523.5.2 Desktop App (Web App) ...........................................................................55

4. Umsetzung ................................................................................... 57

4.1 Vorbereitung .........................................................................................................574.1.1 Entwickeln für iOS ....................................................................................574.1.2 Entwickeln für Flash 11 .............................................................................61

4.2 Anlegen der einzelnen Projekte ............................................................................624.2.1 Das Projekt DiplomBase ............................................................................624.2.2 Das Projekt DiplomMobile ........................................................................634.2.3 Das Projekt DiplomDesktop ......................................................................664.2.4 Verbinden der Screen-Apps mit der Basisapplikation ................................67

4.3 Implementierung ..................................................................................................674.3.1 Globale Models und Konstanten ................................................................684.3.2 Views und Mediatoren ...............................................................................704.3.3 Globale Verwaltung screen-spezifischer Asset-Bibliotheken......................754.3.4 Zentrale XML-basierte Sprachverwaltung ................................................774.3.5 Interaktive dreidimensionale Benutzerschnittstellen ..................................834.3.6 Umfärben des 3D-Objekts .........................................................................95

5. Fazit und Ausblick .......................................................................... 99

5.1 Ausgangssituation .................................................................................................995.2 Bewertung und Ergebnisse der praktischen Untersuchungen ............................. 101

5.2.1 Betrachtung der Entwicklungsumgebung FDT ...................................... 1015.2.2 Betrachtungen zur entkoppelten Entwicklungsweise der Multiscreen-Anwendung ....................................................................................................... 1015.2.3 Betrachtungen zur Entwicklung von Mobile Apps für iOS ....................1035.2.4 Bewertung der Stage3D-Performance .....................................................104

5.3 Erweiterungsmöglichkeiten ................................................................................1055.3.1 Beibehalten der strikten Entkopplung ......................................................1055.3.2 Kombinierter Entwicklungsansatz ...........................................................1055.3.3 Alternative Entwicklungsumgebung Flash Builder .................................106

5.4 Zusammenfassung und Schlussfolgerung ...........................................................1075.5 Ausblick ..............................................................................................................108

III

6. Literatur- und Quellenverzeichnis ...................................................... 111

7. Anhang ...................................................................................... 117

Begriffserklärungen .................................................................................................. 117Selbstständigkeitserklärung ......................................................................................121

IV MULTISCREEN ENTWICKLUNG FÜR 3D-BENUTZERSCHNITTSTELLEN

Tabellen- und Abbildungsverzeichnis

Abb.1: Das Credo von Jung von Matt ..........................................................................3Abb.2: Zielscreens für die Prototypen dieser Diplomarbeit..........................................4Abb.3: Multiscreen-Entwicklung mit Unity .............................................................. 14Abb.4: Die Adobe „We Love Choice“-Kampagne ......................................................16Abb.5: Erwartete Entwicklung der Internetnutzung von Desktops und Mobile........17Abb.6: Die vier Screen-Typen nach Radley Marx ......................................................18Abb.7: Interaktive Elemente auf unterschiedlichen Screens .......................................19Abb.8: Die verschiedenen Arten der Interaktion ........................................................20Abb.9: Mobile Apps und Web Apps ..........................................................................22Tab.1: Unterstützung verschiedener Betriebssysteme durch die Flash Plattform .......23Abb.10: Multiscreen Muster nach precious ................................................................25Tab.2: Multiscreen Muster nach precious ...................................................................26Abb.11: Das Mobile First Muster ...............................................................................28Abb.12: Das Fluidity Muster ......................................................................................29Abb.13: Das Responsive Design Muster ....................................................................30Abb.14: Responsive Webdesign - Robot or Not?........................................................31Abb.15: Das Kontextrelevanz Muster .........................................................................32Abb.16: Darstellungsebenen im Flash Player 11 ........................................................35Abb.17: Die Stage3D-Grafikpipeline .........................................................................37Abb.18: AGALtheMean ............................................................................................39Abb.19: Grundkonzept der Basis-Applikation ...........................................................46Abb.20: Grundkonzept der Screen-Applikationen.....................................................48Abb.21: Frühe Konzeptskizzen ..................................................................................49Tab.3: Komponentenübersicht ....................................................................................51Abb.22: UI-Konzept der Mobile App ........................................................................52Abb.23: Steuerung der Kamera durch Geräteneigung ...............................................54Abb.24: UI-Konzept der Desktop App ......................................................................55Abb.25: Generieren eines Certificate Signing Request ..............................................58Abb.26: Das Provisioning Portal ................................................................................58Abb.27: Komfortables AIR-SDK-Merging mit FDT5 ..............................................60Abb.28: Ein Pure AS3 Projekt als Basis anlegen. ......................................................62Abb.29: Ein Mobile Projekt erstellen .........................................................................63Abb.30: Auswählen des Merged-AIR-SDK...............................................................64Abb.31: Aktivieren des Provisioning Profiles .............................................................65Abb.32: Anlegen eines Stage3D-/Molehill-Projekts ..................................................66Abb.33: Das referenzierte Basisprojekt .......................................................................67Abb.34: Mediatoren als Brücken zwischen View und Model/Anwendungslogik ......70Abb.35: Robotlegs Injection .......................................................................................71Abb.36: Erleichterte Entwicklung durch automatische Codevervollständigung ........76Abb.37: Package Contents Dialog ..............................................................................80Abb.38: Das verwendete 3D-Modell ..........................................................................83Abb.39: Environment-Mapping .................................................................................87Abb.40: Die Kamera in der Szene ..............................................................................88

V

Abb.41: Die finalen Prototypen ..................................................................................99Abb.42: Away3D Statusmonitor ...............................................................................104Tab.4: Messreihe Performancetest ............................................................................104Abb.43: Anti-Aliasing ..............................................................................................105Abb.44: Kombinierte Entwicklungsweise ................................................................106Tab.5: Vor- und Nachteile einer entkoppelten Entwicklungsweise ...........................108

VI MULTISCREEN ENTWICKLUNG FÜR 3D-BENUTZERSCHNITTSTELLEN

Listingverzeichnis

Listing 1: Initialisieren einer Stage3D ........................................................................38Listing 2: Abfrage, ob TouchEvents unterstützt werden ............................................53Listing 3: Abfrage, ob das Accelerometer unterstützt wird ........................................54Listing 4: DiplomMobile-app.xml (Zeile 75-80) .......................................................64Listing 5: DiplomMobile-app.xml (Zeile 182-186) ....................................................65Listing 6: Colors.as (Base) ..........................................................................................68Listing 7: PaintModel.as (Base) ..................................................................................69Listing 8: Festlegen einer Regel zur Injektion ............................................................69Listing 9: Injizieren des Models .................................................................................69Listing 10: Mappen von View und Mediator .............................................................71Listing 11: MobileView.as (Zeile 50-66) ....................................................................72Listing 12: MobileViewMediator.as ...........................................................................73Listing 13: DesktopView.as (Zeile 41-45) ................................................................... 74Listing 14: DesktopViewMediator.as (Zeile 15-24) .................................................... 74Listing 15: AssetProviderMobile.as ............................................................................75Listing 16: AbstractMultiscreenView.as (Zeile 26-31) ................................................76Listing 17: MobileView.as (Zeile 42-45) .....................................................................76Listing 18: AbstractMultiscreenView.as (Zeile 33-41) ...............................................77Listing 19: AbstractMultiscreenViewMediator.as ......................................................78Listing 20: DiplomMobileContext.as (Zeile 28-40) ..................................................78Listing 21: Nutzung von getProperty() ......................................................................79Listing 22: de.xml (Base) ............................................................................................79Listing 23: MobileXMLParser.as ...............................................................................80Listing 24: DesktopXMLParser.as .............................................................................81Listing 25: DiplomDesktopContext.as (Zeile 30-46) ................................................82Listing 26: Away3DContainer.as (Zeile 132-136), Laden des Modells ......................84Listing 27: Hinzufügen des Modells, nachempfunden: ..............................................84Listing 28: Away3DContainer.as (Zeile 65-89), allgemeiner Initialisierungsvorgang 85Listing 29: Away3DContainer.as (Zeile 90-96), Initialisieren des Lichts ...................86Listing 30: Away3DContainer.as (Zeile 108-130), Initialisieren der Materialien .......86Listing 31: Away3DContainer.as (Zeile 147-170), Zuordnen der Materialien ............88Listing 32: Away3DContainer.as (Zeile 98-106), Initialisieren der Kamera ...............89Listing 33: Away3DContainerMobile.as (Zeile 38-41), Gestensteuerung ..................90Listing 34: Away3DContainerMobile.as (Zeile 85-88), Zoomen ...............................90Listing 35: Away3DContainerMobile.as (Zeile 48-52), Accelerometer I ...................91Listing 36: Away3DContainerMobile.as (Zeile 65-67), Accelerometer II .................91Listing 37: Away3DContainerMobile.as (Zeile 42-44), Mausereignisse registrieren .91Listing 38: Away3DContainerMobile.as (Zeile 69-83), Mausereignisse behandeln ...91Listing 39: Away3DContainerMobile.as (Zeile 55-63), onEnterFrame .....................92Listing 40: Away3DContainer.as (Zeile 217-224) Neuberechnen der Kamera ...........92Listing 41: Away3DContainerDesktop.as (Zeile 90-92) Einsatz des Mausrads .........93Listing 42: Away3DContainerDesktop.as (Zeile 54=66), onEnterFrame ...................93Listing 43: ColorBoxMediator.as ...............................................................................95

VII

Listing 44: Away3DContainerMediator.as .................................................................95Listing 45: Away3DContainer.as (Zeile 204-215), Ändern der Materialfarbe ...........96

VIII MULTISCREEN ENTWICKLUNG FÜR 3D-BENUTZERSCHNITTSTELLEN

Abkürzungsverzeichnis

AGAL ............... Adobe Graphics Assembly LanguageAIR ................... Adobe Integrated RuntimeANT .................. Another Neat ToolAPI .................... Application Programming InterfaceAS ..................... ActionscriptCD .................... Corporate DesignCI ...................... Corporate IdentityCPU .................. Central Processing UnitCSR ................... Certificate Signing RequestCSS ................... Cascading Style Sheetsfps ...................... frames per secondGB ..................... GigabyteGHz .................. GigahertzGPU .................. Graphical Processing UnitHTML .............. Hypertext Markup LanguageIDE ................... Integrated Development EnvironmentMVC ................. Model View ControllerQR (Code) ......... Quick Response (Code)RAM ................. Random Access MemoryRIA ................... Rich Internet ApplicationROI ................... Return of InvestmentSDK................... Software Development KitSVN .................. (Apache) SubversionSWC ................. Shockwave Flash Component FileSWF .................. Shockwave Flash FileUDID ................ Unique Device IdentifierUI ...................... User InterfaceURL .................. Uniform Resource LocatorUX ..................... User ExperienceXML ................. Extensible Markup Language

11. EINLEITUNG

1. Einleitung

1.1 Idee und Motivation

1.1.1 Variierende Nutzungsszenarien von Informationstechnologien

Das Internet ist in der Mitte unserer Gesellschaft angekommen. Dies ist vor allem schnel-leren, preiswerteren und flächendeckenden Internetzugängen zu verdanken, aber auch den reichhaltigeren Angeboten im Web. Dieses weltumspannende Netzwerk hat sich mit der Zeit stark verändert und Formen angenommen, an die man vor 20 Jahren noch nicht hätte denken können. Doch nicht nur das Netz unterliegt ständigem Wandel, sondern auch unser Umgang damit.

Durch die Entwicklung zum „Web 2.0“ ist der Internetnutzer vom Konsumenten zum Produzenten von Inhalten geworden und das „Cyberspace“ zum „Mitmachnetz“, zum Ort der Selbstverwirklichung.

Längst ist auch der Computer im heimischen Wohnzimmer oder am Arbeitsplatz nicht unser einziger Zugang in das Internet. Laut einer Studie des Statistischen Bundesamtes hat bereits im Jahr 2010 die Nutzung mobilen Internets im Vergleich zum Vorjahr um 78% zugenommen.1

Der Nutzer ist in der Lage, in den unterschiedlichsten Situation mit dem Internet zu in-teragieren. So ersetzt das Smartphone vieler Menschen bereits die Tageszeitung auf dem Weg zur Arbeit oder den Wetterbericht am Abend. Das Durchstöbern der Neuigkeiten in sozialen Netzwerken auf dem Smartphone ist die digitale Zigarettenpause des ein-undzwanzigsten Jahrhunderts. Moderne Fernsehgeräte halten sich nicht mehr nur an die Programmpläne der Sender, sondern bieten Möglichkeiten, Filme im Internet zu kaufen um sie direkt ansehen zu können. Serien können zu beliebigen Zeitpunkten abgerufen werden.

Durch die immer fragmentierter werdende Masse der Mobilgeräte und unterschiedlichste Nutzungszenarien besteht ein hoher Anspruch an Content-Anbieter und Werbetreibende: Um z.B. mit einer Kampagne große Wirkungen zu erzielen, muss zielgruppenspezifisch auf jedes Gerät und die damit verbundenen Nutzungsszenarien eingegangen werden.

Die Idee hinter dieser Arbeit ist es, neue technologische Entwicklungen als effektive Werbeträger nutzbar zu machen. Dabei gilt es, eine Marke oder ein Produkt interaktiv für unterschiedliche „Screens“, also verschiedenste Endgeräte, erlebbar zu machen und dabei auf kontextrelevante Besonderheiten zu achten.

1 Vgl. [StatBund 2011]

2 MULTISCREEN ENTWICKLUNG FÜR 3D-BENUTZERSCHNITTSTELLEN

1.1.2 Die Dynamik der Medieninformatik

Medieninformatik ist eine Disziplin, die sich mit „Multimedia“ beschäftigt. Und so be-schäftigen sich (angehende) Medieninformatiker mit einer Vielzahl von Medien und de-ren Zusammenwirken.

Zu den Besonderheiten des Studiengangs gehört die Tatsache, dass das Bild der Me-dieninformatik keine Momentaufnahme einer technischen Entwicklungsstufe wiedergibt – Forschung und Lehre unterliegen ständigen Veränderungen, welcher Studierende wie Lehrende antreibt, diesen Wandel aktiv weiter zu gestalten. Und der Zündstoff, der das Fach zu einem lebendigen Studiengang macht, ist das Internet.

Unser Verständnis für Technik und unser Umgang mit Technologien verändert sich fort-laufend und fordert ständig neue kreative Lösungen, welche sich unserem Alltag anpas-sen. Genauso müssen wir in der Rolle der Entwickler den sich wandelnden Technologien gerecht werden. Wir müssen dynamische Lösungen finden, für welche ein Nutzer kein Handbuch mehr benötigt – Unsere Anwendungen müssen sich den Bedürfnissen der Nutzer anpassen, sie ansprechen und begeistern.

Damit setzt sich auch die Multiscreen-Entwicklung auseinander. Denn Multiscreen An-wendungen erreichen den Nutzer über unterschiedlichste Kanäle und schaffen somit eine hohe und situationsgerechte Userexperience.

Ein Großteil der Studieninhalte befasst sich mit dreidimensionaler Computergraphik, da derartige Anwendungen in den letzten Jahren außerordentlich an Bedeutung gewonnen haben. Diese Entwicklung macht auch vor dem Internet und mobilen Geräten nicht Halt.

1.1.3 Betrieblicher Kontext: Die Werbeagentur Jung von Matt„Längst hat die Wahrnehmung eine Revolution durchlaufen. Der Verbraucher hat seine Konsequenzen aus der Informationsflut gezogen. Die Rettungsweste heißt Selektion. Er selektiert und lässt nur solche Botschaften zu, die für ihn von Nutzen sind. So geht er wenigstens nicht in der Flut unter. Dabei hat er nicht nur schwimmen gelernt. Er ist obenauf und surft auf der Informationswelle. Er ist nicht gestresst. Er ist vor allem verwöhnt. Er ist kein Opfer. Er ist im Gegenteil souveräner Herr der Lage und wählt genüsslich zwischen allen Kommunikationsangeboten aus.“, Holger Jung, Jean- Remy von Matt, Momentum - Die Kraft, die Werbung heute braucht.2

Diese Diplomarbeit entstand in enger Zusammenarbeit mit Jung von Matt, „Deutsch-lands einflussreichster Werbeagentur“3. Die Gruppe der Flash Developer ist ein junges engagiertes Team, welches fest in den Agenturalltag integriert ist.

2 Vgl. S.8/9 [JungVonMatt 2002]3 Vgl. [Horizont 2011]

31. EINLEITUNG

Zu den regelmäßigen Aufgaben gehört das Erstellen interaktiver Werbemittel unter-schiedlichster Formen. Zu den spannenderen Herausforderungen gehört die Program-mierung von Microsites, Landingpages, Facebook-Specials und Spielen. Der Anspruch, dabei stets qualitativ hochwertige Ergebnisse zu erzielen, ist der gemeinsame Antrieb.

Für die Umsetzung neuer Projekte gibt es bestimmte Vorgehensweisen, welche sich aus nunmehr zehnjährigen Erfahrungen herausgebildet haben. Es existiert ein praxiserprob-tes eigenes Framework, eine Vielzahl vorgefertigter Komponenten und das Team ist gut eingespielt.

Ein Teil der Zeit wird dafür verwendet, die Fühler nach dem Neuen hin auszustrecken. So werden regelmäßig aktuelle Frameworks und Innovationen getestet und die bestehen-de Basis ausgebaut. Es besteht außerdem ein guter Draht zu den Herstellern der benutz-ten Technologien, um möglichst früh mit Neuerungen in Kontakt kommen zu können.

Zu diesen Innovationen gehören die neuen 3D-Fähigkeiten des Flash Players in der Ver-sion 11 und die Multiscreen-Entwicklung von Projekten. Die wachsende Zahl der Kom-munikationskanäle macht es erforderlich, eine möglichst große Anzahl dieser mit über-schaubarem Aufwand bedienen zu können. Wie dies gelöst werden kann, und welche Fähigkeiten der neueste Flash Player mit sich bringt, soll in dieser Diplomarbeit unter-sucht werden.

Abb.1: Das Credo von Jung von Matt4

4 siehe: www.jvm.com/credo


1.2 Zielsetzung

Das Ziel dieser Arbeit ist es, eine prototypische interaktive 3D-Anwendung für unter-schiedliche Endgeräte zu entwickeln. Diese soll sowohl agenturintern, als auch extern (z.B. für Pitches) zu Demonstrationszwecken verwendet werden. Für die Umsetzung wird ein entkoppelter Entwicklungsanstaz gewählt, bei welchem für jedes angezielte Device eine eigenständige Applikation erzeugt wird. Dabei gilt es, verschiedene Konzeptmuster für die Multiscreen-Entwicklung anzuwenden und in Erfahrung zu bringen, wie diese programmiertechnisch umsetzbar sind.

Da der Bildschirm als gleichzeitiges Ein- und Ausgabewerkzeug das wichtigste und gleichzeitig am stärksten präsente Unterscheidungsmerkmal darstellt, werden verschiede-ne Geräte in dieser Diplomarbeit als „Screens“ bezeichnet.

Zur Programmierung wird die Flash Plattform verwendet, da die Arbeit in der Flash-Abteilung von Jung von Matt geschrieben wird. Während die neuen 3D-Fähigkeiten als sichtbares Ergebnis der Arbeit ein wichtiger Punkt der Untersuchung sind, gilt es vor al-lem herauszufinden, welche Eignung die gewählte technische Herangehensweise für die Umsetzung von Multiscreen-Anwendungen mit sich bringt. Die Ergebnisse der Diplom-arbeit könnten anschließend genutzt werden, um einen internen Vergleich zu konträren Ansätzen anstellen zu können.

Die zu entwickelnde Anwendung soll nach Vorgabe der Agentur für die folgenden zwei Screens konzipiert und an den jeweiligen Nutzungskontext angepasst werden:

• Desktop: Eine Web App, welche im Browser eines Computers läuft.

• Tablet: Eine Mobile App, welche auf dem iPad 2 läuft.

Abb.2: Zielscreens für die Prototypen dieser Diplomarbeit

Da es sich beim Ergebnis des praktischen Teils um zwei alleinstehende Applikationen handelt, wird hierfür der Terminus „Prototypen“ (Plural) verwendet. Unabhängig vom benutzten Screen handelt es sich trotzdem um eine funktional gleichartige Anwendung.

Mobile App

Base App

Desktop Web App

51. EINLEITUNG

1.2.1 Entwicklungs- und Testumgebungen

Für Entwicklung und Test wird folgende Hardware eingesetzt:

• Apple MacBook Pro, 5. Generation, 2.26 GHz Intel Core 2 Duo, 8 GB RAM, Betriebssystem: Mac OS X Lion (10.7.1)

• Apple Mac Pro, 5. Generation, 2.8 GHz Quadcore, 6 GB RAM, Betriebssys-tem: Mac OS X Snow Leopard (10.6.4)

• Apple iPad2, 1 GHz Dual-Core Apple A5

Bei der Software zur Entwicklung der Prototypen wird auf im Arbeitsalltag etablierte Produkte zurückgegriffen. Die primäre Programmierumgebung ist daher Powerflasher FDT 5. Die benutzten SDKs und Bibliotheken sind jeweils in der aktuellsten Version bzw. im Beta-Stadium. Als Architekturframework für die Prototypen wird Robotlegs verwendet.

Powerflasher FDT 5

FDT ist eine leistungsfähige Entwicklungsumgebung für Flash-/Flex- und AIR-Projekte und basiert auf Eclipse5. Der Editor bietet umfangreiche Funktionen, wie sie auch aus anderen professionellen Entwicklungsumgebungen bekannt sind. Dazu gehört zum Bei-spiel die automatische Codevervollständigung, was ein komfortableres Programmieren als in der Flash Professional IDE erlaubt.

Da FDT im Gegensatz zu Flash Professional weder Bühne, noch Zeitleiste bietet, rich-tet sich das Tool vor allem an Flash Developer, welche damit „Pure AS3“-Projekte ent-wickeln. Es können professionelle und komplexe objektorientierte Flash-Applikationen geschaffen werden. Zur Erzeugung von zeitleistenbasierten Flash Animationen ist FDT nicht geeignet.

Durch die Möglichkeit der Einbindung zahlreicher Eclipse-Plugins kann auch die di-rekte Anbindung an einen SVN-Server, also an ein Versionsverwaltungssystem, erfolgen. Dies macht FDT auch für den Einsatz in Entwickler-Teams interessant.

Mit der neusten Version von FDT wird auch eine kostenlose Variante angeboten, welche mit einem verminderten Funktionsumfang daherkommt. Für die Entwicklung der Pro-totypen wurde jedoch die kostenpflichtige Variante FDT 5 Max verwendet.

5 siehe: http://www.eclipse.org/


1.3 State of the Art

1.3.1 Mobile noch in den Kinderschuhen

Werbeagenturen haben längst die Bedeutung von mobilen Anwendungen in Crossmedia Kampagnen erkannt. Der Einsatz von „Mobile“6 findet jedoch nur sporadisch statt und steckt nur in einer explorativen Phase. In einer Untersuchung7 des amerikanischen „Chief Marketer“ Magazins stellte sich heraus, dass 2010 nur ein Drittel der Vermarkter bereits mobile Kampagnen ausrollten. Ein Aufwärtstrend ist jedoch beobachtbar:„[...] 33% of marketers had run mobile campaigns in 2010, and more than half were

doing so [2011]“

Auch Aussagen über die Gründe der geringen Integration mobiler Kampagnen können getroffen werden:„More than one in three respondents to the survey said they “assume” their customers are

mobile, but don’t have much information about their usage habits or content activities.“

Vor allem Textnachrichten werden in mobilen Kampagnen als Werbeträger eingesetzt. Ein auch in Deutschland deutlich beobachtbarer Trend ist die Verknüpfung von Print-kampagnen und Mobile durch sog. „QR-Codes“, welche mit dem Smartphone (mit ins-tallierter Erkennungssoftware) abfotografiert werden und auf eine mobile Webseite ver-linken. Rang Drei der beliebtesten Strategien zum Einsatz von Mobile in Kampagnen ist die Entwicklung gebrandeter Mobile Apps.8

1.3.2 Die Multiscreen Challenge

Während der Trend besteht, verstärkt Crossmedia Kampagnen einzusetzen, gilt es vor allem, die einzeln eingesetzten Medien mit überschaubarem Aufwand beherrschen zu können. Dabei besteht nicht mehr nur die Hürde, sowohl klassische als auch neue Medi-en zu bedienen. Es gilt auch, den Überblick über die breitgefächerte Gerätelandschaft zu behalten. Kampagnen, die sowohl im Web, als auch auf mobilen Geräten laufen, müssen eine Konsistenz aufweisen, welche sich nicht nur auf die Gestaltung bezieht, sondern auch auf die Funktionalität. Die gleichzeitige Entwicklung von mobilen Kampagnen und Webspecials birgt dabei einige Stolpersteine. „Entwicklung“ bezieht sich in diesem Fall nicht ausschließlich auf das Programmieren. Vor allem die Planung, Konzeption und Kreation einer Applikation sind entscheidende Arbeitsphasen.

6 Als „Mobile“ bezeichnen Werber Kampagnen, welche auf mobilen Medien, also vor allem Smartphones und Tablets, Einsatz finden.7 Chief Marketer, „2011 Mobile Marketing Survey“ Vgl. [EMarketer 2011]8 Vgl. [CMarketer 2011]

71. EINLEITUNG

1.3.3 Die 3D-Fähigkeiten früherer Flash-Versionen„Mit Flash Player 10 stellen wir eine echte Internet-Innovation bereit, die von der Community bereits genutzt wird, um eine völlig neue, bislang nicht da gewesene Art von Web-Erlebnissen zu gestalten.“ David Wadhwani, General Manager und Vice President der Platform Business Unit bei Adobe.

Am 15. Oktober 2008 veröffentlichte Adobe die bis dahin neueste Version des Flash Play-ers. Mit diesem ist es möglich, einfache 3D-Effekte auf 2D-Inhalte anzuwenden. Dies bedeutet, dass Objekte auf der Bühne auch in der Tiefe platziert werden können, womit eine perspektivische Darstellung von Anzeigeobjekten geschaffen werden kann. Außer-dem ist es möglich, beliebige Transformationen im dreidimensionalen Raum durchzu-führen. Hiermit lassen sich auch ohne Kenntnisse im Bereich dreidimensionaler Darstel-lung schnell interessante Ergebnisse erzeugen. Diese Neuerung wird oft mit „Postcards in Space“ betitelt, da die mit den neuen Bordmitteln erzielten Effekte trotzdem noch recht flach wirken. Schließlich sind die eigentlichen Objekte immer noch Flächen ohne eigene Tiefe.9

Als Entwickler stößt man mit Flash Player 10 schnell an die Grenzen der 3D-Fähig-keiten von Flash. So ist es weder möglich, komplexe 3D-Objekte zu laden, noch findet eine automatische Tiefensortierung („Z-Sorting“) einzelner Elemente statt. Dies ist so, da alle Anzeigeobjekte in Flash in einer Hierarchie, der sogenannten DisplayList, geordnet sind. Schon die Erstellung eines rotierenden Würfels ist nicht ohne weiteres möglich. Auch die maximale Anzahl der darstellbaren Polygone ist stark begrenzt, da für die Bildberechnung die CPU des Computers benutzt wird. Diese ist nicht für die Abbildung komplexer dreidimensionaler Welten konzipiert. Trotz dieser technischen Beschränkungen existieren Bibliotheken von Drittherstellern, welche zur Entwicklung von 3D-Applikationen benutzt werden können. Zu den wohl bekanntesten 3D-Flash-Engines gehören Away3D, Alternativa und Papervision. Mit Hilfe dieser Bibliotheken ist es sowohl möglich, dreidimensionale Primitive zu erstellen, als auch komplexere Modelle abzubilden, wobei man auch hier schnell an die Leistungsgrenzen der CPU stößt. Um dreidimensionale Welten effektiv anzuzeigen, ist es unumgänglich, die Berechnung der Szene von der CPU auf die GPU der Grafikkarte zu verlagern. Diese beherrscht zwar weit weniger Operationen als die CPU, ist aber optimiert auf diejenigen Rechenschritte, welche benutzt werden, um 3D-Objekte darzustellen.

Mit dem neuen Flash Player 11 können derartige Berechnungen auf der Grafikkarte durchgeführt werden. Das bedeutet, dass es mit dieser neuen Technologie möglich ist, komplexe dreidimensionale Welten direkt im Browser anzuzeigen, ohne die CPU zu belasten.

9 Vgl. [Flashhilfe 2008]


1.4 Struktur der Arbeit

Der Hauptteil der Arbeit ist in vier Teile gegliedert:

• Grundlagen• Konzeption• Umsetzung• Fazit und Ausblick

Nach einer kurzen Einleitung, welche in die behandelte Thematik einführt, bildet das Kapitel „Grundlagen“ den ersten Part des Hauptteils. Das Ziel ist, ein Grundverständnis für das Thema der Arbeit zu schaffen. Dabei wird anfangs die Rolle der Flash Plattform behandelt. Anschließend wird die Bedeutung von Multiscreen-Anwendungen erläutert, sowie Konzepte und Strategien aufgeführt, welche bei der Multiscreen-Entwicklung zum Tragen kommen. Den Abschluss des Grundlagenkapitels bildet eine Einführung in die Fähigkeiten von Flash im dreidimensionalen Bereich. Hierbei geht es vor allem um die mit dem Flash Player 11 neu eingeführte Darstellungsebene Stage3D.

Das Kapitel „Konzeption einer Multiscreen-Anwendung“ vermittelt zuerst allgemeine Vorbetrachtungen, welche bei der Umsetzung eines solchen Projekts zu bedenken sind. Anschließend erfolgt eine Präsentation der Konzepte, welche für die beiden zu entwi-ckelnden Prototypen dieser Diplomarbeit erarbeitet wurden.

Im Anschluss daran folgt das Kapitel „Umsetzung“, in welchem anfangs vorbereitend die Schritte erklärt werden, welche für die Entwicklung von iOS-Apps und 3D-Flash-Anwendungen notwendig sind. Es folgt eine ausführliche Beschreibung, wie ein Multi-screen-Projekt angelegt werden kann. Der nachfolgende Teil behandelt schließlich die konkrete Implementierung der beiden Prototypen. Hierbei werden die wichtigsten im Vorfeld diskutierten Konzepte angewandt und anhand des Quellcodes der Applikationen erläutert. Auch auf die zu beachtenden Eigenheiten der Zielplattformen wird eingegangen.

Im Kapitel „Fazit und Ausblick“ werden zusammenfassend die Ergebnisse der prakti-schen Arbeit diskutiert. Hierbei wird auch der Kreis zu den Konzeptions- und Grund-lagenkapiteln geschlossen. Es werden die Vor- und Nachteile der gewählten Herange-hensweisen und Strategien abgewägt und abschließend ein Ausblick gewährt, welche Bedeutung dem Thema zukünftig zukommen könnte. Auch die Rolle der Flash Platt-form wird betrachtet.

92. GRUNDLAGEN

2. Grundlagen

2.1 Die Adobe Flash Plattform als Werkzeug zur Entwicklung reichhaltiger Anwendungen

Die Bezeichnung „Flash“ wird umgangssprachlich oft für das Browserplugin Adobe Flash Player verwendet, welches notwendig ist, um Flash Inhalte im Browser anzeigen zu kön-nen. Diese Inhalte können mit Flash Professional, einer proprietären Entwicklungsum-gebung von Adobe Systems (kurz: Adobe) erzeugt werden. Auch als „Autorensoftware“ bezeichnet lassen sich damit sowohl aufwändige Animationen als auch interaktive Ap-plikationen erstellen. Durch die objektorientierte Programmiersprache ActionScript 3.0 (kurz: AS3) ist es möglich, auch komplexe Anwendungen zu entwickeln, welche zu Rich Internet Applications (kurz: RIAs) gezählt werden. Da Flash zu Beginn vor allem für klei-ne Animationen verwendet wurde, betitelten sich viele Designer, welche sich mit Flash beschäftigten, als „Flash Designer“. Durch die Weiterentwicklung von ActionScript und die stark erweiterten Einsatzfähigkeiten von Flash ist das noch sehr junge Berufsfeld des Flash Developers entstanden.

2.1.1 Die Entstehung von Flash

Der Ursprung von Flash ist das 1994 von der Firma FutureWave entwickelte Illustrati-onsprogramm SmartSketch. Um die damit erzeugten Grafiken im Splash-Format auch im Browser darstellen zu können, musste das FutureSplash-Browserplugin heruntergela-den werden. Ein Jahr später wurde das Programm zu einem Animationsprogramm wei-terentwickelt, dem FutureSplash-Animator. Dieser ist der erste Vorgänger der heutigen Flash-Professional IDE. Noch 1996 übernimmt das Softwareunternehmen Macromedia die Firma FutureWave und entwickelt deren Produkt unter dem Namen „Flash“ weiter. Das Browser-Plugin heißt von nun an „Shockwave Flash Player“. Im Jahre 1999 wird mit der vierten Version von Flash auch die Skriptsprache ActionScript eingeführt. Vier Jahre später (mit der Version Flash MX 2004) wird diese auf Objekten basierte Sprache durch eine objektorientierte, nämlich ActionScript 2.0, ersetzt. Ein bedeutungsvoller Zeitpunkt in der Geschichte von Flash ist 2005, als Adobe für 3,4 Milliarden US-Dollar Macrome-dia übernimmt. Im darauffolgenden Jahr erscheint der Adobe Flash Player in der Version 9 und ActionScript 3.0. Dies stellte die bis dahin wohl wegweisendste Veränderung der Flash Plattform dar, da sich der Anwendungsbereich von Flash Inhalten damit vor allem auf die Entwicklung reichhaltiger Internetanwendungen konzentrierte.10

10 Vgl. [Wolter 2009]


2.1.2 Überblick über die Flash Plattform11

Die Flash Plattform ist eine Zusammenstellung ausgereifter Technologien zur Anwen-dungsentwicklung, welche von einem Ökosystem etablierter Programme, Partner und einer lebendigen Community umgeben ist.

Tools

Die Werkzeuge zur Applikationserstellung sind Flash Professional, Flash Builder und Flash Catalyst. Flash Professional ist das ursprüngliche Autorensystem, mit welchem zeitleistenbasierte Flash-Animationen erstellt werden können. Auch können den Schlüs-selbildern der Animation Aktionen (Programmcode) zugewiesen werden. Flash Builder ist stärker auf die Anwendungsprogrammierung ausgerichtet. Der mächtige Code-Editor beinhaltet keine Zeitleiste. Flash Catalyst ist das jüngste der hier aufgeführten Werkzeu-ge und wird verwendet, um ohne Programmierung einfache Prototypen zu erstellen.

Framework

Flex ist ein leistungsstarkes Framework zur Programmierung von mobilen, aber auch traditionellen Anwendungen für Browser und Desktop. Es basiert auf ActionScript und MXML, einer XML-basierten User Interface Auszeichnungssprache. Flex ist als Open-Source-SDK kostenlos verfügbar. Zur Entwicklung mit Flex wird hauptsächlich Flash Builder eingesetzt.

Server

Die Adobe Flash Media Server Family umfasst verschiedene Lösungen zum Streamen und zur Echtzeit-Encryption hochqualitativer Inhalte.

Clients

Der Flash Player ist das wohl am meisten verbreitete Browser-Plugin. Mit ihm können Flash Inhalte (swf-Filme) im Browser angesehen werden. Obwohl der Begriff „Flash“ die komplette Plattform bezeichnet, wird es häufig für den Flash Player verwendet.

AIR ist eine Laufzeitumgebung, mit welcher Flash Inhalte auch außerhalb des Browsers als Anwendung ausgeführt werden können. Gleichermaßen ermöglicht AIR, native mo-bile Anwendungen zu entwickeln.

11 Vgl. [Adobe02 2011]

112. GRUNDLAGEN

Für mobile Geräte gibt es gesonderte Flash Player. Aufgrund einer strategischen Neu-ausrichtung und der immer fragmentierter werdenden Gerätelandschaft wurde die Wei-terentwicklung dieser Clients jedoch im November 2011 eingestellt. Der Flash Player für mobile Geräte bleibt damit im aktuellen Zustand erhalten. Ferner ist es dank AIR möglich, mobile Geräte durch Mobile Apps direkt zu adressieren. Unabhängig der mo-bilen Flash Player wird die Entwicklung von Mobile Apps auf Basis von AIR weiter vorangetrieben.

Verwandte Produkte

Flash Professional bietet eine hohe Kompatibilität zu anderen Produkten der Adobe Creative Suite. So können zum Beispiel Photoshop- oder Illustrator-Dateien direkt via Drag and Drop von einer Applikation in die andere verschoben werden.

Weitere Anwendungen von Drittherstellern

Flash Developer greifen häufig auch auf Entwicklungsumgebungen von Drittanbietern zurück, welche einen erweiterten Funktionsumfang bieten. Als kostenloses Beispiel ist FlashDevelop12 für Windows zu nennen. Den wohl höchsten Funktionsumfang bietet FDT13 von Powerflasher, welches in der neuesten Version auch in einer kostenlosen Va-riante erhältlich ist.

12 siehe: http://www.flashdevelop.org/13 siehe: http://fdt.powerflasher.com/


2.1.3 Die aktuelle Stellung von Flash im Vergleich zu anderen Technologien

Die Flash Plattform kann durch ihren Umfang und ihre unterschiedlichsten Fähigkeiten kaum einer einzelnen Technologie gegenüber gestellt werden, welche ein ähnliches Maß an Möglichkeiten bietet. Es ist schwer, klare Kriterien zu definieren, nach welchen eine faire Gegenüberstellung möglich wäre.

Populär ist der Vergleich mit HTML5, auch wenn die Meinungen dazu gespalten sind. Außerdem soll Unity aufgeführt werden, da diese eher unbekannte Plattform ein ver-gleichbares Funktionsspektrum bietet.

Allgemeine Vorteile von Flash

Internetseiten werden in verschiedenen Browsern oft unterschiedlich dargestellt. Dies ist bei Flash nicht der Fall. Flash bietet einen definierten Funktionsumfang und garantiert eine feste Layouttreue. Dies hat zur Folge, dass Flashinhalte unabhängig vom benutzten System oder Browser gleichartig dargestellt werden. Auch sind die Anwendungen skalier-bar, sodass sich Flashinhalte bei entsprechender Programmierung mit dem Browserfens-ter mitskalieren können. Dabei ist es auch möglich, Elemente neu zu platzieren, sodass der gegebene Platz immer optimal genutzt werden kann. Mit Flash können barrierefreie Inhalte erzeugt werden, da eine starke Kompatibilität zu textbasierten Browsern besteht. Auch Bildschirmleseprogramme, sog. „Screenreader“, welche vor allem von blinden Computer-Benutzern verwendet werden, können auf Flashinhalte zugreifen und diese korrekt interpretieren. Dies ist zwar aufwändiger und planungsintensiver als bei „norma-len“ Webseiten, aber möglich. Die enorm starke Verbreitung und die schnelle Adaption neuer Versionen des Players sprechen für Flash. Laut einer aktuellen Statistik von riastats.com hatten bereits am 09.11.2011 (einen Monat nach Einführung des Flash Player 11) über 40% der Flash-Nutzer die neueste Version installiert.14 Browser wie Google Chrome haben das Plugin mittlerweile sogar vorinstalliert, sodass kein manueller Download des Flash Players mehr notwendig ist. Auch ist es mit der Flash Plattform möglich, Inhalte für mobile Geräte zu entwickeln. Aufgrund der starken Cross-Plattform-Fähigkeiten von Flash entsteht auch ein immenser wirtschaftlicher Vorteil: um für unterschiedliche Platt-formen und Geräte zu entwickeln ist prinzipiell nur eine Entwicklergruppe notwendig.

Flash im Vergleich zu HTML5

Zu den am häufigsten mit Flash verglichenen Technologien gehört HTML5. An dieser Stelle soll kurz erläutert werden, warum diese Gegenüberstellung von geringerer Bedeu-tung ist, als häufig angenommen. Einige Fachautoren gehen sogar soweit zu sagen, ein solcher Vergleich sei „irrelevant.“15

14 Vgl. [RiaStats 2011]15 Vgl. [Cavazza 2011]

132. GRUNDLAGEN

Mit dem Aufkommen der ersten HTML5-Demonstrationen wurde diese Technologie als „Flashkiller“ gehandelt. Bis dato wurde Flash unter anderem häufig für Einzelkom-ponenten auf Webseiten eingesetzt, so zum Beispiel für Werbebanner oder Video-Player. Sowohl für mobile als auch für nicht mobile Internetangebote ist zum jetzigen Zeit-punkt eine Koexistenz beider Technologien gegeben. Mit der Weiterentwicklung von HTML5 (welches 2014 Webstandard werden soll) mussten bereits verschiedene Flash Inhalte dieser Art weichen. Dies wird gern als eine Negativentwicklung für den Flash Player angesehen. Es wird erwartet, dass Flash von Video-Playern und Werbebannern verschwinden wird. In Kreisen von Flash Developern wird dies jedoch nicht als ein aus-schließlich negativer Trend aufgefasst. Flash wird heutzutage hauptsächlich zur Erstel-lung sogenannter „Webspecials“ oder „Web Apps“ eingesetzt. Dies sind Webseiten, die nicht ausschließlich dem Übermitteln eines bestimmten Inhalts dienen, sondern in ihrer Präsentation auf besondere Art und Weise daherkommen und eine emotionale Wirkung haben. Für derartige Anwendungen wird Flash weiterhin verwendet und als geeignetes Mittel betrachtet, da die Verbreitung und Kompatibilität des Flash Players höher ist, als es bei HTML5 aktuell der Fall ist. Auch bietet die Flash Plattform eine Menge etablierter Funktionen und Bibliotheken, deren umfangreiche Möglichkeiten es von HTML5 zum jetzigen Zeitpunkt noch aufzuholen gilt. Es bleibt abzuwarten, welche Positionen die einzelnen Technologien einnehmen können. Dies muss allerdings nicht ausschließlich konträr betrachtet werden. Fakt ist, dass Adobe auch maßgeblich an dem Vorranbringen von HTML5 interessiert und beteiligt ist.

Mit dem neuen Flash Player 11 richtet Adobe seine Strategie verstärkt in Richtung Ga-ming und Mobile Application Development aus. Diese schärfere Fokussierung wird auch durch die Einstellung der Weiterentwicklung des mobilen Flash Players bestätigt. Ad-obe hat bekannt gegeben, man wolle sich stärker auf das Entwickeln von Mobile Apps konzentrieren und Flash damit direkt auf die Geräte bringen. Die steigende Bedeutung nativer Apps wurde erkannt.

Auch wenn seine 3D-Fähigkeiten stark gestiegen sind, ist der Flash Player für den Desk-top Browser von keinen drastischen strategischen Umbrüchen betroffen. Dieser wird wei-terentwickelt und es wird weiterhin Flash-Webspecials geben.16 Flash bietet somit ausge-prägte Möglichkeiten zur Cross-Plattform- und Multiscreen-Entwicklung.

Die nachvollziehbaren Entscheidungen von Adobe werden von Kritikern teilweise als Siegeszug von HTML5 über Flash gedeutet. Tatsächlich wird jedoch eine Koexistenz beider Technologien angestrebt, bei der beide ihren jeweiligen Anwendungsgebieten ge-recht werden können. Während dies für HTML5 bedeutet, dass es an vielen Stellen den Platz von Flash einnehmen wird, ist es auch für Flash eine Weiterentwicklung. Diese erweitert letztlich auch die Möglichkeiten der Flash-Entwickler im mobilen Bereich.

16 Vgl. [Adobe04 2011]


Flash und Unity

Bei Unity handelt es sich um eine Spielengine, also eine komplexe Entwicklungsumge-bung für Spiele. Im Fokus von Unity steht ein mächtiger 3D-Editor, mit dem es möglich ist, vielfältige Spielumgebungen zu schaffen, Umgebungsgeräusche einzubinden, interak-tive Elemente zu platzieren, und vieles mehr. Als Programmierumgebung wird MonoDe-velop mitgeliefert, mit welcher in verschiedenen Sprachen (unter anderem auch C#) Skripte erstellt werden können, welche die Spiellogik formulieren. Mit Unity ist es mög-lich, für verschiedenste Plattformen zu entwickeln. Dazu gehören natürlich PC, Mac, iOS, Android, aber auch Spielekonsolen wie die Wii oder die X-Box.

Abb.3: Multiscreen-Entwicklung mit Unity17

Unity bietet damit viele Features, welche die Fähigkeiten der Flash Plattform im 3D-Bereich übersteigen. Dazu zählt vor allem der integrierte 3D-Editor. Das kostenfreie Browserplugin ist in der Lage, durch DirectX oder OpenGL eindrucksvolle dreidimensi-onale Szenen anzuzeigen, und kann dabei mit allerlei Effekten aufwarten. In zukünftigen Versionen wird es auch möglich sein, direkt aus Unity für den Flash Player 11 zu entwi-ckeln18. Dies soll in der Entwicklungsumgebung ohne großen Aufwand möglich sein und die Performance sei laut Aussage der Unity-Entwickler „großartig“.19

Einiges spricht für Unity – auch der Fakt, dass die Spielengine von develop-online.net unter die „Top 10 Game Engines“ gewählt wurde.20

Rein technisch ähneln sich Unity und der aktuelle Flash Player 11 sehr stark, da beide die GPU zur Berechnung dreidimensionaler Grafiken verwenden. Bei der Verbreitung des Unity Browser-Plugins lässt sich allerdings nur spekulieren, da Unity keine Zahlen vor-legen kann. Adobe spricht bei der Verbreitung des Flash Player davon, dass mittlerweile 99% der Computer Flash Inhalte wiedergeben können.21

17 Quelle: http://unity3d.com/unity/publishing/18 Vgl. [BrowserMag 2011]19 Vgl. [Unity 2011]20 Vgl. [DevelopOnline 2009]21 Vgl. [Adobe01 2011]

152. GRUNDLAGEN

Betrachtet man den Kostenfaktor als Vergleichskriterium zwischen Unity und Flash, kann Unity nicht ganz mithalten.22 Flash Inhalte lassen sich mittlerweile auch ohne das kostenpflichtige Flash Professional23 programmieren. Das Flex-SDK ist Open Source und somit für jedermann zugänglich.

Aus Kundensicht ist Unity zu wenig verbreitet, um relevante Projekte damit durchführen zu können. Hier entscheidet man sich dann doch früher für Flash. Zum einen, da es de facto Web Standard ist; zum anderen, da Flash Developer mittlerweile eine stark profes-sionalisierte Berufsgruppe bilden.

2.1.4 Kontroversen

Die Haltung von Apple zu Flash

Eine häufig in den Medien diskutierte Kontroverse ist die Haltung von Apple zu Flash. Diese bezieht sich auf die Einbindung des Flash-Plugins in den Browser der mobilen Apple-Geräte. Von einem Android-Device sind Flash Inhalte über den Browser zugäng-lich. Apple dagegen weigert sich, Flash im Browser von iPhones und iPads zu unter-stützen. Laut Apple wolle man nicht, dass sich ein Dritthersteller mit einer proprietären Technologie zwischen die Zielplattform und die Entwickler stelle.24 Auch werden häu-fig Sicherheitsprobleme und Performanceschwierigkeiten angeführt, welche gegen Flash im mobilen Webbrowser sprechen. Es ist ein Trend beobachtbar, dass vor allem Apple-Anhänger diese Kontroverse weiter vorantreiben. Für Flash Developer ist die eigentliche Stellung gegenüber Apple kein bedeutungsvolles Problem. Durch Adobe AIR ist es mög-lich, alle Vorzüge von Flash in Form von Mobile Apps25 auf iPhones und iPads zu brin-gen. Der Anteil an beauftragten Kampagnen, welche explizit den mobilen Browser eines bestimmten Gerätes adressieren, ist marginal. Es ist also durch diesen Zustand nicht so, als gingen den Entwicklern wichtige Aufträge verloren.

Adobe startete im Mai 2010 eine Kampagne, welche ein Zugeständnis an die guten App-le-Produkte sein sollte, auf der anderen Seite aber auch kritisierte, dass mit der Beschrän-kung der Webbrowser die Kreativität der Entwickler und die Experience der User einge-schränkt würde. Die „We Love Choice“-Kampagne war adressiert an Apple und sorgte vor allem unter Anhängern des Unternehmens für Aufsehen.

22 Unity Pro kostet in der Ausstattung, mit der sich iPhone- und Android Apps entwickeln lassen zum aktuellen Zeitpunkt (09.11.2011) ca. 4500$ Die angesprochenen Möglichkeiten, auch für Wii oder X-Box zu entwickeln benötigen gesonderte Lizenzen pro entwickeltem Titel. Die Preise hierfür lassen sich nur per Nachfrage ermitteln. Quelle: https://store.unity3d.com/shop/23 Aktueller Preis vom 09.11.2011 auf adobe.de: 831,81€ in der Version CS5.524 Vgl. [Jobs 2010]25 Während allgemein oft von „Apps“ gesprochen wird, verdeutlicht die Betitelung „Mobile App“, dass es sich bei der entsprechenden Anwendung um keine native App handelt. Auch wenn Mobile Apps von solchen nativen Applikationen kaum unterschieden werden können.


Abb.4: Die Adobe „We Love Choice“-Kampagne26

„Flash ist tot“

Seit Einführung des iPhones hört man aus dem Lager der Flash-Gegner, Flash sei tot. Aufgrund eben dieser populären Konflikte mit Apple, dem Gedanken, HTML5 könne Flash obsolet werden lassen und den Ankündigungen zum Einstellen der Weiterent-wicklung des Flash-Plugins für mobile Browser fand man diese Aussage im November 2011 immer häufiger im Netz. Vor allem in den Kreisen der Flash Developer herrschte Unsicherheit über die Bedeutung dieser Ereignisse für Flash.

Besonders beachtlich ist der Umstand, dass im Zuge der Ankündigungen der Einstellung des mobilen Flash Players immer wieder falsche Informationen verbreitet wurden. So wurde zum Beispiel sogar behauptet, Macromedia verdiene heute mit jedem Flashfilm im Internet Geld.27

Adobe reagierte auf die vorherrschende Unsicherheit und stellte klar:„So, just to be very clear, contrary to what many have declared, Flash is not dead. It’s role and focus has shifted but we feel that it still fills important roles both on the web and mobile platforms.“,Mike Chambers, Adobe28

26 Quelle: http://www.adobe.com/choice/ – Der Text auf der rechten Seite der Anzeige lautet: „What we don‘t love is anybody taking away your freedom to choose what you create, how you create it, and what you experience on the web.“27 Vgl. [TAZ 2011]28 Vgl. [Chambers 2011]

172. GRUNDLAGEN

2.2 Multiscreen-Entwicklung„This “multiscreen” revolution represents the growing number and diversity of screens in our daily lives – PCs, smartphones, tablets, TVs and more – as well as our increasing ability to interact with content and applications across screens, and the interconnec-tions between them.“, Kevin Lynch, Senior Vice President und Chief Software Architect der Platform Business Unit von Adobe29

2.2.1 Die Mobile Revolution

Die Notwendigkeit, sich über Multiscreen-Entwicklung Gedanken zu machen, besteht seit der sogenannten „Mobile Revolution“.

Seit einem halben Jahrzehnt ist es üblich, dass irgendwann im Jahr, irgendjemand be-hauptet, es währe das Jahr des „mobilen Webs“. Nach dem Nichteintreten dieser mutigen Behauptungen wurden oft auch schnell die Gründe für das Ausbleiben der erwarteten Revolution genannt. War 2005 noch die schlechte Hardware schuld, waren es 2008 die schlechten Browser der mittlerweile fortgeschrittenen mobilen Geräte. Im Jahr 2010 konnten die meisten Hindernisse überwunden werden. Es existieren leistungsstarke Ge-räte, sogar schon mit mehreren Prozessorkernen. Die Browser sind vorangeschritten, die Netzabdeckung ist gut und das Interesse an der Technologie sehr hoch. Auch sind die Verträge für Datenübertragungen auf mobile Geräte erschwinglich geworden.

Abb.5: Erwartete Entwicklung der Internetnutzung von Desktops und Mobile.30

29 Auszug aus einem Vortrag von Kevin Lynch auf der Adobe MAX Konferenz 2010.30 Quelle: http://blogs.adobe.com/conversations/2011/02/the-multiscreen-revolution.html


Der Begriff „Mobile Revolution“ wird greifbar, wenn man die Verkaufszahlen betrachtet. Die Gesamtanzahl der verkauften Smartphones verdoppelte sich innerhalb eines Jahres. Die Marktanteile von Android-Geräten stiegen im Jahr 2010 um unglaubliche 885.9%. Für die nächsten Jahre wird erwartet, dass die Verkaufszahlen für Mobile weiter steigen, wohingegen Desktops immer seltener verkauft werden.31

2.2.2 Multiscreen: Definition und Grundkonzept32

„Multiscreen-Entwicklung“ ist ein noch sehr junger Begriff, welcher noch nicht streng definiert wurde, durch seinen bisherigen Gebrauch in Fachkreisen allerdings mittlerweile einheitlich benutzt wird. Die häufigste Verwendung findet in Verbindung mit der An-wendungsentwicklung für unterschiedliche Geräte, bzw. Screens, statt.

Bedeutsamkeit erhält das Thema durch die immer dynamischer und fragmentierter wer-dende Gerätelandschaft. So greifen Nutzer in unterschiedlichen Situation mit verschie-denen digitalen Endgeräten auf gleiche Angebote zu und erwarten dabei jeweils eine größtmögliche Usability. Das Empfinden ist dabei vor allem abhängig vom verwendeten Screen und dessen Kontext. Man spricht auch von „Multiscreen Experience“: Der Nutzer erlebt immer ein auf seinen Nutzungskontext angepasstes Angebot.33 Multiscreen-Ent-wicklung bedeutet, eine Anwendung unter Beachtung bestimmter Konzeptmuster auf unterschiedlichen Endgeräten zur Verfügung zu stellen und dabei individuelle Anpas-sungen vorzunehmen, um je nach Endgerät die höchstmögliche Userexperience zu bieten.

Radley Marx, UX Design Consultant bei Adobe Systems definiert vier Screentypen, wel-chen die Hauptbedeutung zukommt: Smartphone, Tablet, Desktop und TV, wie in der folgenden Abbildung dargestellt:

Abb.6: Die vier Screen-Typen nach Radley Marx

Um die Idee der Multiscreen-Entwicklung zu verstehen, gilt es, als erstes ein häufig auf-tretendes Missverständnis aus dem Weg zu räumen. Als Adobe AIR auf den Markt kam,

31 Vgl. [CNN 2010]32 Vgl. [Marx 2010]33 Vgl. [MultiscrExp01 2011]

192. GRUNDLAGEN

wurde es mit dem Claim „Write once, run anywhere“ beworben. Die Bedeutung des frei übersetzten „Einmal schreiben, überall ausführen“ ist, dass AIR-Desktopapplikationen gleichermaßen auf Windows, Mac OSX und Linux34 funktionsfähig waren. Dies be-zeichnet man als „Multi-Platform-Development“.

Während man also beim Multi-Platform-Development eine einzelne Applikation auf mehrere Plattformen bringen kann, geht es beim Multiscreen-Development darum, eine Applikation für mehrere Interfaces zu entwickeln. Diese neue Grundidee hinter AIR ist noch nicht bis in die Tiefen der Entwicklerkreisen vorgedrungen und so besteht häufig der Irrtum, es bestünde die Möglichkeit, eine „eierlegende Wollmilchsau-App“ zu ent-wickeln, welche mit wenigen Mausklicks sowohl auf Desktops, als auch auf Tablets, TVs und Smartphones portiert werden könne.

Das Endresultat kann nun also eine App mit mehreren Views (pro Endgerät eine) sein, oder aber mehrere Apps, welche aus einer Basis-Applikation entstanden sind.„„Write once, run everywhere“ was cool, but today multiscreen really means multiple

screens and that’s plenty of work for now. Maybe in a few years AIR will be powerful enough to make the slogan true again.“, Radley Marx, Adobe Systems

2.2.3 Klassifizierung der Endgeräte

Abb.7: Interaktive Elemente auf unterschiedlichen Screens

Das deutlichste Unterscheidungsmerkmal der vier aufgeführten Screen-Typen ist – wie der Name vermuten lässt – die Größe des Bildschirms und der Menge des darauf abbild-baren Inhalts. Doch nicht nur auf Größe und Auflösung kommt es an. Bei Smartphones und Tablets spielt der Bildschirm eine weitere wichtige Rolle, denn es handelt sich da-

34 Seit Version 2.7 unterstützt Adobe AIR nicht mehr das Linux-Betriebssystem.

?!


bei um den primären Interaktionsweg mit dem Gerät.35 Diesem Zustand ist es geschul-det, dass Interfacedesigner bei der Gestaltung mobiler Applikationen, welche per Touch gesteuert werden, vor einem Problem stehen, welches auf Desktops bereits seit den ersten grafischen Webbrowsern nicht mehr von Bedeutung ist: aufgrund der fehlenden sichtba-ren Repräsentation des Eingabegeräts (Mauszeiger) ist dem Nutzer nicht selbstverständ-lich ersichtlich, welche Elemente einer Webseite oder Applikation interaktiv sind. Vom Desktop bekannte hover-Effekte für Steuerelemente fehlen (siehe Abbildung 7). Auch ist die Wahrung der Konsequenz in der Erkennung und Behandlung von Gesten auf Touchscreens besonders wichtig. Denn ein intuitives und eindeutiges Verständnis für die Bedienbarkeit von ungekennzeichneten interaktiven Elementen ist auch eine Erleichte-rung für die Planung und Gestaltung mobiler Applikationen.36 Die Interaktion mit TVs erfolgt hauptsächlich über eine Fernbedienung und ist daher noch weniger intuitiv. Prin-zipiell können demnach drei hauptsächliche Arten der Interaktion unterschieden werden:

• Touch (Smartphone & Tablets)• Maussteuerung (Desktop)• Fernsteuerung (TV)

Abb.8: Die verschiedenen Arten der Interaktion

Die vier Screentypen Smartphone, Tablet, Desktop und TV sollen im Folgenden kurz erläutert werden.

Smartphone

Smartphones37 sind leistungsfähige Mobiltelefone mit computer-ähnlichen Funktionen. Bedient werden diese Geräte hauptsächlich über einen Touchscreen, welcher meist auch Multitouch-Gesten erkennt. Smartphones verfügen über ein hochwertiges Betriebssys-tem. Der Zugang zum Internet wird über einen eigenen Browser ermöglicht. Auf dem Gerät lassen sich kleine Programme, sogenannte „Apps“ installieren.

35 Der Vollständigkeit halber sollte erwähnt werden, dass auch Computer mit Touchscreens existie-ren. Maus und Tastatur sind bei Computern allerdings nach wie vor die wichtigsten Eingabegeräte.36 Vgl. S. 78 - 84 [Wroblewski01 2011]37 Mit Smartphone werden im Kontext dieser Arbeit Mobiltelefone bezeichnet, welche über einen Touchscreen als Hauptinteraktionswerkzeug verfügen. Diese Geräte werden in einigen Literaturquellen als „Touchphones“ bezeichnet, dieser Begriff ist allerdings markenrechtlich geschützt.

212. GRUNDLAGEN

Der Bildschirm moderner Geräte ist hochauflösend und klein, sodass das Gerät auch mit einer Hand bedient werden kann. Smartphones sind tägliche Begleiter und wertvolle Werkzeuge für den Alltag. Die Bedeutung von Smartphones ist innerhalb kurzer Zeit stark angestiegen.

Zu erwähnen ist, dass die schon länger existierende Sprachsteuerung durch die Einfüh-rung des neuen iPhone 4S deutlich an Bedeutung gewonnen hat. Der Sprachassistent „Siri“ ist eine innovative Entwicklung, welche für zukünftige Technologien von größerer Bedeutung sein kann. Zum jetzigen Zeitpunkt ist die Verbreitung derartiger Steuerungen im Vergleich zu den aufgeführten Formen der Interaktion jedoch zu gering, um sie zum Gegenstand der Betrachtung werden zu lassen.

Tablet

Tablets sind in ihrer Form und Leistung dem Smartphone sehr ähnlich. Hierbei handelt es sich um handliche Geräte mit mittelgroßen Bildschirmen. Auch beim Tablet ist der Bildschirm gleichzeitig Ein- und Ausgabemedium. In Ihrer Verwendung schließen Ta-blets die Lücke zwischen Smartphones und Desktops. Sie bieten einen Browser und die Möglichkeit, Programme in Form von Apps zu installieren; telefonieren kann man mit ihnen jedoch nicht. Tablets werden unterwegs, aber vor allem auch zuhause benutzt. Zum effektiven Arbeiten sind die Geräte bisher wenig geeignet. Viele Menschen betrachten sie als Lifestyle-Produkt oder Statussymbol.

Desktop

Beim Desktop handelt es sich um hoch entwickelte Computer. In Hinsicht auf die Mul-tiscreen Definition durch Radley Marx fallen auch Notebooks in diese Sparte. Diese Geräte zeichnen sich durch Bildschirme unterschiedlichster Größen, welche als primäres Ausgabemedium fundieren, aus. Zur Eingabe werden hauptsächlich Tastatur und Maus verwendet. Desktops sind die leistungsstärksten der hier aufgeführten Devices und wer-den sowohl für die Arbeit als auch im privaten Bereich verwendet.

TV

Fernsehgeräte sind die in der Betrachtung aus Multiscreen Sichtweise am wenigsten ver-breiteten Geräte, da es hierbei ausschließlich um moderne Modelle geht, welche über einen Internetanschluss verfügen und Programme ausführen können. Die Interaktion mit diesem Screen ist am mühsamsten, da häufig Fernbedienungen zur Steuerung verwendet werden. Auch gibt es die Möglichkeit, Smartphones und Tablets zur Bedienung zu benut-zen. TVs werden ausschließlich zuhause genutzt und sind nicht zum Arbeiten geeignet. Aufgrund der aktuell noch geringen Relevanz bezüglich des Angebots von Multiscreen-Anwendungen, wird dieser Screen nicht in die Betrachtungen Arbeit einbezogen.


2.2.4 Typen von Apps auf mobilen Geräten

Die primäre Art und Weise, Inhalte für ein mobiles Gerät bereitzustellen und sie einem potentiellen Nutzer verfügbar zu machen, sind Apps. Hierbei wird vorerst zwischen zwei Darbietungsformen unterschieden.38 Zum einen können Anwendungen wie Webseiten über den auf dem Gerät installierten Browser betrachtet werden; derartige Applikationen werden als „Web App“39 bezeichnet. Zum anderen gibt es Apps, welche über definierte Vertriebswege („App Stores“) teils kostenpflichtig heruntergeladen und anschließend auf dem Gerät installiert werden. Diese Programme heißen „Mobile App“.

Abb.9: Mobile Apps und Web Apps

Im Folgenden sollen kurz die wichtigsten Unterschiede beider Formen aufgeführt werden.

Unterschiede in der Entwicklung

Da Web Apps im Browser laufen, lassen sich diese Applikationen wie normale Internet-seiten entwickeln. Streng genommen sind es auch Internetseiten, nur sind diese eben be-sonders für die Verwendung auf dem entsprechendem Screens angepasst und reichhaltig an Funktion. Mobile Apps können mit verschiedensten Programmiersprachen und Ent-wicklungsumgebungen erstellt werden. Dies ist vor allem abhängig vom Zielgerät. Apps, die mit der primären Sprache eines entsprechenden Systems geschrieben werden, heißen „Native App“. So werden z.B. iOS-Apps mit Objective-C entwickelt. Zur Entwicklung von Android-Apps ist dies wiederum nicht geeignet. Eine weitere Möglichkeit zur Er-stellung von Mobile Apps ist es, existierende Web Apps durch sogenannte „Wrapper“ zu verpacken und für das entsprechende System zur Verfügung zu stellen.

38 Aus technischer Sicht kann eine feingliedrigere Unterteilung getroffen werden.39 Auch Flash Anwendungen, welche über den Browser eines Desktops betrachtet werden, be-zeichnet man als Web App. Diese Bezeichnung ist nicht auf einen spezifischen Screen beschränkt. „Mo-bile App“ hingegen wird für Smartphones und Tablets verwendet, um den Unterschied zu einer nativen Applikation herauszustellen.

Mobile App Web App

232. GRUNDLAGEN

Ein solches Tool bietet auch die Flash Plattform. Mit dem Packager for iPhone können Flash Projekte mit ActionScript-Code für das iPhone oder iPad veröffentlicht werden. Dadurch entstehen native Applikationen, welche man auf dem Gerät installieren kann. Der Anwender bemerkt im Idealfall keinen Unterschied zwischen einer mit ActionScript oder einer mit Objective-C entwickelten App.

Die folgende Tabelle gibt einen Überblick über die verschiedenen Betriebssysteme, und wie diese von der Flash Plattform unterstützt werden:

Plattform Browser Nativ

Windows (auch Mobile) Flash Player AIR

Mac OS X Flash Player AIR

Linux Flash Player AIR

iOS - Packager for iPhone

Android Flash Player AIR

Blackberry Flash Player AIR

Tab.1: Unterstützung verschiedener Betriebssysteme durch die Flash Plattform40

Der große Vorteil von Mobile Apps gegenüber Web Apps ist der, dass diese Applikationen direkt auf dem Betriebssystem des Geräts laufen, und nicht auf einer dazwischengeschal-teten Softwareschicht wie dem Browser. Dies bedeutet, dass der Programmierer einer Mobile App alle Besonderheiten des Systems nutzen kann. Dies bezieht sich auf Ein-gabewege, zum Beispiel durch Multitouch oder Gestenerkennung, aber auch durch die Benutzung integrierter Werkzeuge, wie der eingebauten Kamera eines Geräts oder dem Mikrophon. Auch können interne Events des Betriebsystems mit einbezogen werden und sogar ein Zugriff auf das Dateisystems ist möglich.41 Viele Spiele für mobile Plattformen nutzen auch die internen Neigungs- und Beschleunigungssensoren der Geräte.

Web Apps hingegen laufen im Browser des Geräts, wodurch kein Zugriff auf gerätespe-zifische Funktionen gewährleistet werden kann. Mit der Entwicklung einer Web App geht auch ein erhöhter Aufwand einher, da die Applikation für alle denkbaren Geräte und deren Browser optimiert werden muss.

Sollen bestimmte Hardware Features eines spezifischen Geräts genutzt werden, ist es ratsam, eine Mobile App zu entwickeln.

40 Vgl. Tabelle auf S.5 [Wagner 2011]41 Vgl. S.4 [Wagner 2011]


Unterschiede bezüglich der Distribution

Ein schon in der Konzeptionsphase bedeutungsvolles Kriterium bei der Entscheidung, ob eine Web- oder eine Mobile App entwickelt werden soll, ist der Bezugsweg der App. Zur Betrachtung einer Web App ist ausschließlich ein kompatibler Browser notwendig. Das heißt im Klartext, dass ein Nutzer nur einem Link zur App folgen muss, um diese betrachten zu können. Es ist keine Installation notwendig, wobei es zugegebener Maßen trotzdem zu Ladezeiten kommen kann, welche von der Komplexität der Anwendung und der Internetverbindung des Nutzers abhängig sind.

Mobile Apps werden sehr häufig über besondere plattformabhängige Vertriebsmodelle bezogen. So können iPhone Apps nur über den AppStore42 von Apple heruntergeladen werden, Android Apps wiederum aus dem Android Market43. Das Besondere hierbei ist, dass es im Gegensatz zu Web Apps möglich ist, kostenpflichtige Programme anzubieten. Die strikte Erwartung eines hohen Return of Investment (kurz: ROI) verleitet Firmen häufig dazu, sich in der Konzeptionsphase für eine Mobile App zu entscheiden. Dabei wird oft ein entscheidender Nachteil außer Acht gelassen: die Reichweite einer Mobi-le App ist unter Umständen sehr gering, wenn diese nicht ausreichend beworben wird. Die Verkaufsportale für plattformspezifische Apps sind prall gefüllt und es wird immer schwerer, aus der grauen Masse herauszustechen. Eine App so bekannt zu machen, dass sie auf den vorderen Plätzen der Portale erscheint („Beliebte Apps“), erfordert meist wei-tere erhebliche Investitionen. Dass Apps „von allein“ einen hohen Bekanntheitsgrad errei-chen, ist mittlerweile selten und eher unwahrscheinlich. Web Apps hingegen sind ohne Download und Installation jederzeit kostenlos abrufbar; die Hürde vor der Verwendung eines solchen Angebots ist also geringer.

Schlussfolgerung

Während oft abgewägt wird, ob eine Web App ausreichend ist, oder ob eine Mobile App erstellt werden sollte, stellt Luke Wroblewski in seinem Buch „Mobile First“ klar, dass eine Koexistenz beider Varianten nie ausgeschlossen werden sollte.

Eine Mobile App bietet eine Menge technischer Vorteile und ermöglicht den Designern und Entwicklern kreativere Ansätze, als eine Web App. Doch häufig ist es so, dass native Applikationen zu Werbezwecken auf weitere Internetangebote verweisen. Die beste User Experience erlebt man als Nutzer nur dann, wenn auch Links, die wohl möglich durch die App erreicht werden können, für das Zielmedium, also das Smartphone oder das Ta-blett aufbereitet wurden. Aus einer technisch ausgereiften Mobile App in eine inhaltlich dynamische Web App zu verzweigen, ist eine elegante Lösung, für die man sich öffnen sollte.44

42 siehe: appstore.com43 siehe: market.android.com44 Vgl. S.14f [Wroblewski01 2011]

252. GRUNDLAGEN

2.2.5 Multiscreen Muster45

Das Hamburger Design-Studio „precious“ stellt auf seiner Internetpräsenz eine Samm-lung von Multiscreen Mustern vor, welche in langjähriger Erfahrung und der Umsetzung verschiedenster Projekte zusammengestellt wurde. Diese beschreiben sechs mögliche Verbindungen zwischen verschiedenen Screens, welche ein Multiscreen-Projekt definie-ren können: Coherence, Synchronization, Screen Sharing, Device Shifting, Complementarity und Simultaneity.

Abb.10: Multiscreen Muster nach precious46

45 Vgl. [Precious 2011]46 angelehnt an eine Darstellung der auf [Precious 2011] eingebundenen Slideshow.

Coherence Synchronisation

Screen Sharing Device Shifting

Complementarity Simultaneity


Die nachfolgend aufgeführten Multiscreen Muster wurden einer Präsentation von „pre-cious“ entnommen.47 Sie führen denkbare Anwendungsfälle für Multiscreen-Applika-tionen auf und beschreiben die Verbindung und Funktionsweise, welche die einzelnen Screens zueinander haben.

Titel Beschreibung

Coherence Digitale Produkte und Services haben auf unterschiedlichen Screens ein kohärentes Aussehen und ermöglichen eine gleichartige Funkti-onalität. Die einzelnen Anwendungen werden dabei an die Beson-derheiten des jeweiligen Screens und auf mögliche Anwendungssze-narien angepasst.

Synchronization Verwendet ein Nutzer ein und dieselbe Anwendung auf unter-schiedlichen Screens, so sind die ihm zur Verfügung stehenden Da-ten immer synchronisiert. Eine Anwendung zum Lesen von eBooks speichert zum Beispiel die aktuelle Leseposition. Liest ein Anwen-der ein eBook mit einer Desktopanwendung und möchte zu einem späteren Zeitpunkt mit einer mobilen Applikation weiterlesen, blät-tert diese das eBook automatisch an die Stelle, an welcher zuletzt aufgehört wurde zu lesen – unabhängig vom benutzten Screen.

Screen Sharing Mehrere Bildschirme unterschiedlicher Geräte werden benutzt, um gemeinsam eine einzelne Quelle abzubilden.

Device Shifting Nutzer sind in der Lage, Inhalte von einem Screen auf einen ande-ren zu verschieben. Dies ermöglicht zum Beispiel, dass auf einem Smartphone gespeicherte Filme über ein TV-Gerät abgespielt wer-den können.

Complementarity Anwendungen sind in der Lage, sich über mehrere Screens hinweg untereinander zu ergänzen. Ein gutes Beispiel hierfür ist die Scrab-ble iPad-App. Diese kann mit einer speziellen iPhone-App erweitert werden, sodass der Spieler seine Spielsteine auf dem eigenen iPhone-Bildschirm sehen kann. Das iPad fungiert als Spielfeld und kann von allen Mitspielern gleichermaßen eingesehen werden.

Simultaneity Verschiedene Geräte können gleichzeitig verwendet werden. Wäh-rend des Verfolgens eines Fußballspiels an einem TV-Gerät kann ein Nutzer gleichzeitig eine Anwendung nutzen um Spielstände zu Tippen und mit anderen Fans zu interagieren.

Tab.2: Multiscreen Muster nach precious

47 Vgl. [Precious 2011]

272. GRUNDLAGEN

Für die Umsetzung der Prototypen sind die aufgeführten Multiscreen-Muster von ge-ringerer Bedeutung. Die Demonstration dieser Muster würde unterschiedlich konzipier-te Anwendungen erfordern. Daher wird bei der späteren Erläuterung der Konzeption und Implementierung der Applikationen von einem bestimmten Multiscreen-Muster ausgegangen.

2.2.6 Konzeptmuster

Neben den Multiscreen Mustern, welche die Funktionsweise des Verbunds der unter-schiedlichen Screens definieren, gibt es eine Reihe von Konzeptmustern, welche die grundlegenden Konzepte zur Gestaltung und Umsetzung einzelner Screen Apps be-schreiben. Während die Multiscreen Muster den Einsatzzweck einer Multiscreen-An-wendung, welche durch ihre einzelnen Screens Apps repräsentiert wird, sehr klar vonein-ander abgrenzen, sollten die einzelnen Konzeptmuster eher als eine Sammlung möglicher Werkzeuge zur Schaffung ansprechender Apps verstanden werden.

Konzeptmuster beschreiben Lösungsansätze für die Gestaltung und Konzeption von Ap-plikationen, welche innerhalb eines Multiscreen-Projekts entwickelt werden. Diese Mus-ter enthalten keine Patentrezepte, sind aber in etablierten Multiscreen-Anwendungen häufig wiedererkennbar, weswegen ihnen eine besondere Relevanz zugesprochen wird. Abhängig vom definierten Ziel und dem zugrunde liegendem Multiscreen Muster kön-nen die einzelnen Konzeptmuster miteinander kombiniert werden. Dieses Kapitel be-leuchtet die vier bedeutsamsten Konzeptmuster genauer:

• Mobile First• Fluidity• Responsive Design• Kontextrelevanz


Mobile First

Abb.11: Das Mobile First Muster

„Mobile First“ ist eine recht junge, dafür aber umso populärere Herangehensweise an die Konzeption von Multiscreen-Anwendungen. Wenn geplant wird, ein Programm für mehrere Screens zu entwickeln, soll nach diesem Konzept immer zuerst die mobile Va-riante (Mobile- oder Tablet-Version) der Anwendung entwickelt werden, bevor man sich Gedanken über die Desktop App macht. Dies ist so, da der kleinere Bildschirm ein kon-sequenteres Überdenken der Oberfläche fordert. Designer und Entwickler werden quasi gezwungen, die Funktionalität auf die wichtigsten Kernelemente zu reduzieren und in-tensiv über die Struktur, das Layout und die Steuerung einer Anwendung nachzudenken. Dieser Zwang, eine effiziente Lösung zu erarbeiten, erleichtert im Nachgang auch die Weiterentwicklung einer App für größere Screens. Das starke Wachstum der Mobile-Branche bietet außerdem weitreichende neue Aussichten und Innovationen.48

Umgekehrt betrachtet bedeutet es, dass es schwierig ist, aus einer existierenden Web App eine mobile Applikation zu formen. Oft sind Webseiten überladen, mit Funktionen voll-gestopft und unübersichtlich strukturiert. Dieses Konzeptmuster wirkt diesem Zustand entgegen und ist eine spannende Herausforderung für Entwickler.„Google programmers are doing work on mobile applications first, because they are bet-

ter apps and that‘s what top programmers want to develop.“, Eric Schmidt, Google Chairman49

Mobile First bedeutet nicht, das gezwungenermaßen zuerst eine Anwendung für mo-bile Plattformen realisiert werden muss. Der entscheidende Punkt ist, dass eine solche Anwendung zuerst konzipiert wird. Die eigentliche Anwendungserstellung für unter-schiedliche Screens kann parallel erfolgen, da sowieso meist unterschiedliche Teams in die Entwicklung für einzelne Screens involviert sind.

48 Vgl. Kapitel 4-7 [Wroblewski01 2011]49 Vgl. [Wroblewski02 2011]]

292. GRUNDLAGEN

Fluidity

Abb.12: Das Fluidity Muster

Das Konzeptmuster „Fluidity“ knüpft an die ursprünglichen Gedanken von Mobile First an. Hierbei geht es darum, für ein „fließendes“ Erlebnis der Nutzer zu sorgen. Häufig ist es so, dass eine Anwendung über mehrere Screens benutzt wird. Nutzer können verschie-dene Varianten der gleichen Anwendung zu beliebigen Zeitpunkten auf unterschiedli-chen Geräten verwenden. Ein bekanntes Beispiel hierfür ist Facebook. Viele Mitglieder des sozialen Netzwerkes interagieren mit der Anwendung sowohl über ihren Desktop, als auch über ihr Smartphone. Dies ist erfolgreich, da Facebook trotz der Unterschiede zwischen Desktop und Smartphone als eine einheitliche Dienstleistung erkannt wird. Sowohl Design als auch Funktionalität ähneln sich stark. Nutzer der Webseite finden sich auch auf der mobilen Applikation schnell zurecht und anders herum. Durch die Wiedererkennbarkeit der Gestalt einer bekannten Anwendung kann ein schneller Bezug zur Applikation hergestellt werden. Und obwohl eine solche App mit marginalen Design- und Funktionsdifferenzen auf verschiedenen Screens auftritt und für die einzelnen Teile (Mobile App, Desktop Web App, etc.) vielleicht sogar unterschiedliche Entwicklerteams zuständig sind, wird die gebotene Dienstleistung als einheitlich empfunden.

Bei der Entwicklung fluider Applikationen ist es wichtig, Brüche in der Logik einer Anwendung auf unterschiedlichen Screens zu vermeiden. Ein Angebot muss sich immer ähnlich anfühlen, unabhängig vom benutzten Screen. Der einzig variierende Faktor ist der Nutzungskontext des Geräts. Dies bedeutet, dass das Angebot angepasst wird, je nach der erwarteten Situation, in der sich ein Nutzer befindet, wenn er eine Anwendung verwendet.

Fluidity bedeutet, trotz leichter Varianz zweier Applikationen auf unterschiedlichen Screens, den roten Faden zu behalten und als zusammenhängendes Gesamtpaket aufzutreten.50

50 [MultiscrExp02 2011]


Responsive Design

Abb.13: Das Responsive Design Muster

„Responsive Design“ beschreibt die Anpassungsfähigkeit einer Webseite an den Screen, auf welchem sie betrachtet wird. In seinem Buch „Responsive Web Design“ formuliert Ethan Marcotte sehr deutlich, um was es dabei geht:„Rather than creating disconnected designs, each tailored to a particular device or brow-

ser, we should instead treat them as facets of the same experience. In other words, we can craft sites that are not only more flexible, but that can adapt to the media that renders them.“ 51

Dieses Konzeptmuster kann in zu unterschiedlichen Graden umgesetzt werden. Bei der Anwendung auf eine Webseite geht es vor allem darum, den gegebenen Platz opti-mal auszunutzen, und das Layout entsprechend anzupassen. Zum Beispiel sollten breite leere Flächen an den Rändern der Seite bei großen Bildschirmen vermieden werden. Die Ausrichtung von Elementen anhand eines flexiblen Grundrasters und die Verwen-dung relativer statt absoluter Größenangaben ermöglicht die effiziente Ausnutzung des Browserfensters. Die Webseite verhält sich demnach responsiv. Doch der Hauptgedanke des Konzeptmusters Responsive Design liegt darin, eine Internetseite (Web App) über mehrere Screens hinweg responsiv zu gestalten. Durch sogenannte „Media Queries“, bei welchen es sich um CSS-Formatelemente handelt, kann ausgelesen werden, welche Ei-genschaften und Beschränkungen das ausführende Gerät mit sich bringt. So kann eine Webseite beispielsweise erkennen, dass sie über ein mobiles Gerät betrachtet wird, und ihr Layout dahingehend optimieren. Responsive Design beschreibt eine dynamische He-rangehensweise an das Design von Webseiten, welche in der Lage sind, sich flexibel an jede denkbare Umgebung anzupassen.

Mit zunehmender Anzahl der zu unterstützenden Screens steigt auch der Aufwand bei der Implementierung einer solchen Web App.

51 Vgl. S.4 [Marcotte 2011]

312. GRUNDLAGEN

Das private Projekt „Robot or Not“ von Ethan Marcotte ist ein Paradebeispiel für Respon-sive Design, denn die Seite passt sich ständig der Browsergröße an und kann somit unab-hängig der Auflösung eines Gerätes komfortabel betrachtet werden. Wenn die Webseite von einem mobilen Gerät aus besucht wird ergibt sich ein stimmiges Bild, sodass Nutzer das Gefühl haben, die Seite wäre direkt für das Mobilgerät konzipiert worden.

Abb.14: Responsive Webdesign - Robot or Not?52

52 siehe: http://robot-or-not.com/


Kontextrelevanz

Abb.15: Das Kontextrelevanz Muster

Eine kontextrelevante Herangehensweise erweitert den Grundgedanken des Responsive Design. Nicht nur das Layout einer Web App soll sich dem Screen anpassen, sondern auch der dargebotene Inhalt. Dies folgt der Meinung vieler Designer, es sei notwendig, jeden Screen eigenständig zu behandeln, statt eine Seite für die verschiedenen Screens anzupassen.„By and large, mobile users want different things from your product than desktop users

do. If you’re a restaurant, desktop users may want photos of your place, a complete menu, and some information about your history. But mobile users probably just want your address and operating hours. If you’re a blockbuster movie, desktop users probably want an immersive experience, including trailers and production details. On mobile, they probably just want to know where the nearest theater is and what time it’s showing.“, Jeff Croft, Freelance Web Designer53

Damit macht Jeff Croft sehr verständlich deutlich, warum es sinnvoll ist, schon in der Planungsphase zu überdenken, welche Konzeptmuster verfolgt werden sollten. Es ist wertvoll zu wissen, in welcher Situation welche Typen von Usern aus welchen Gründen eine mobile Webseite besuchen. Es ist aber ratsam, sich nicht darauf zu versteifen. Denn laut aktuellen Umfragen nutzen auch immer mehr Nutzer ihr Smartphone oder Tablet von zuhause aus, also nicht nur zwischendurch, um die wichtigsten Informationen zu finden. Vor allem beim Fernsehen sind Smartphone und Tablet immer öfter dabei.54

Es wird demnach immer schwerer, zu unterscheiden, in welcher Art und Weise und für welchen Kontext ein Angebot aufbereitet werden muss.55

53 Vgl. [Croft 2010]54 Vgl. [Compete 2010]55 Vgl. S.106-108 [Marcotte 2011]

332. GRUNDLAGEN

2.2.7 Technische Herangehensweisen

Für die technische Umsetzung einer Multiscreen Anwendung gibt es unterschiedliche Herangehensweisen und Strategien, jedoch kein Patentrezept. Empfehlungen erfahre-ner Entwickler nach gibt es allerdings einige Techniken, mit welchen eine Multiscreen Anwendung geschaffen werden kann. Die den nachfolgend aufgeführten Techniken zu-grunde liegenden Grundkonzepte lassen sich prinzipiell miteinander kombinieren.56

Entkoppelte Entwicklung

Es existiert eine Basisapplikation, welche die Funktionalität und das Modell der Anwen-dung enthält. Die Basisapplikation beinhaltet keine Views, also Dialogfenster, sondern ausschließlich Logik. Gerätespezifische Anzeigelayer werden dann voneinander losgelöst entwickelt und erweitern die Hauptlogik der Anwendung. So entsteht für jeden Screen eine eigene View, welche auf die besonderen Merkmale des jeweiligen Screens angepasst ist. Die Views selbst besitzen kaum eigene Logik und benutzen dieselbe Basisapplikation. Soll die Applikation später verändert werden, so muss die Logik nur an der Basis, dem Kern der App, angefasst werden. Die Views werden dann gegebenenfalls jeweils einzeln und entsprechend der Anforderungen modifiziert. Wird diese Strategie streng verfolgt, so wird für jeden zu bedienenden Screen ein einzelnes Projekt angelegt. Die einzelnen Projekte haben untereinander keine Verbindung, sondern nutzen ausschließlich die Basis gemeinsam. Schon vor der eigentlichen Entwicklung ist ein genauer Planungsprozess notwendig, um zu bestimmen, was in die Basis gehört, und was für jeden Screen eigen-ständig programmiert werden muss.

Anpassungsfähige Einzelanwendung

Es wird genau eine einzelne stabile Applikation geschaffen, welche eine hohe Anpas-sungsfähigkeit an alle denkbaren Umgebungen bietet. Diese Anwendung verfügt sowohl über die Logik, als auch über die visuellen Elemente späterer Apps. Anhand bestimmter Vergleichskriterien (wie zum Beispiel der Bildschirmgröße) ist die Applikation in der Lage, ihre Form und ihren Funktionsumfang zu verändern. An vielen Stellen einer sol-chen Anwendung ist es notwendig abzufragen, in welchem Zustand sich die Laufzeit-umgebung befindet um möglichst sicher voraussagen zu können, auf welchem Screen die App ausgeführt wird und um damit eine größtmögliche Usability zu gewährleisten. Der Aufwand wird bei einer solchen Herangehensweise besonders hoch, wenn in ein weit fortgeschrittenes Projekt auf einmal weitere Anforderung integriert werden müssen. Dies ist dann der Fall, wenn z.B. ein weiterer Screen durch die Anwendung bedient wer-den soll. Für kleine Projekte ist der Aufwand überschaubar. Redundanzen im Code sind durch diese Herangehensweise ausgeschlossen. Soll sich eine App von Screen zu Screen jedoch sehr stark unterscheiden, ist dieser Ansatz wenig effizient.

56 Vgl. [Adobe07 2010]


Grundprinzip: Wiederverwendbarkeit

Wiederverwendbarkeit ist eine Kernphilosophie der Programmierung, welche für jedes Projekt im Hinterkopf behalten werden sollte.

Grundsätzlich ist es ratsam, dass projektunabhängig immer wiederkehrende Aufgaben in thematisch sinnvoll strukturierte Code-Bibliotheken gekapselt werden. So entsteht eine umfangreiche Grundlage für kommende Projekte.

Derartigen Sammlungen kommt im Zuge der Multiscreen-Entwicklung eine besondere Bedeutung zu. Wiederverwendbare Komponenten und Bibliotheken sollten so flexibel programmiert werden, dass sie in möglichst vielen Umgebungen benutzt werden können. Ist es zum Beispiel absehbar, dass gleiche Elemente später auf unterschiedlichen Screens benutzt werden sollen, so können diese von vornherein darauf vorbereitet werden. Dabei sollte vermieden werden, dass Elemente später mehr Funktionalität mit sich tragen, als es für einen korrekten Programmablauf notwendig wäre. Das heißt, dass Buttons in der Lage sein sollten, sowohl Mausinteraktionen, als auch TouchEvents korrekt zu interpre-tieren. Um Ressourcen zu schonen, sollte dabei jedoch nie gleichzeitig auf beide Eingaben reagiert werden. Hier muss bei der späteren Implementierung eines solchen Elements unterschieden werden, wie genau es im entsprechenden Kontext verwendet werden soll.

352. GRUNDLAGEN

2.3 Flash und die dritte Dimension

Das in Kreisen von Flashentwicklern meist gewünschte Feature für kommende Flash-Versionen ist seit Langem Hardwareunterstützung für 3D-Anwendungen. Mit dem Flash Player 11 kommt Adobe diesem Wunsch nach. Nach langer Entwicklungszeit wurde der Player am 04.10.2011 veröffentlicht. Unter dem Codenamen „Molehill“ verbirgt sich die größte Neuerung für Flash, nämlich eine Sammlung von APIs, welche es ermöglichen, echte 3D-Grafiken mit Hardwareunterstützung direkt im Flash Player darzustellen. Die-se Programmierschnittstelle, welche auch als „Stage3D“ bezeichnet wird, ermöglicht die Entwicklung völlig neuartiger Internet-Erlebnisse:„With the new Stage3D APIs, developers can expect hundreds of thousands of z-buffered

triangles to be rendered at HD resolution in full screen at around 60 Hz. Using the new Stage3D APIs in Flash Player and Adobe AIR® will make it possible to deliver sophisticated 3D experiences across almost every computer and device connected to the Internet.“57

2.3.1 Die Darstellungsebenen im Flash Player

Der Flash Player hat drei Typen von Darstellungsebenen, welche unterschiedliche Inhal-te abbilden können: StageVideo, Stage3D und die DisplayList.

In der folgenden Abbildung ist die Anordnung der einzelnen Ebenen in Flash dargestellt.

Abb.16: Darstellungsebenen im Flash Player 11

57 Vgl. [Adobe03 2011]

1) 2) 3)

1 - StageVideo2 - Stage3D [1..n]3 - DisplayList


• StageVideo ist die hinterste Darstellungsebene. Eingeführt wurde StageVideo mit Version 10 des Flash Players. Während Videos bisher an die DisplayList angehangen wurden ist es mit StageVideo möglich, die Encodierung eines Vide-os auf der Grafikkarte durchzuführen. Dies bringt einen starken Geschwindig-keitsvorteil bei Online Video Anwendungen.

• Mit dem Flash Player 11 wurde die Stage3D eingeführt. Stage3D ist gleichzei-tig die Bezeichnung der neuen Flash-API, welche eine Schnittstelle zur Grafik-hardware eines Computers bereitstellt und so für die Darstellung und Berech-nung realistischer 3D-Szenen sorgt.

• Die DisplayList, auch „Stage“ genannt, ist die vorderste aller Darstellungsebe-nen und die einzige, welche zum jetzigen Zeitpunkt Transparenzen unterstützt. Das heißt, dass man durch die DisplayList auch auf die darunter liegenden Schichten sehen kann. Diese Schicht ist eine Hierarchie von DisplayObjects (z.B. MovieClips, Sprites, Bitmaps, etc.). Jedes visuelle Element muss, um angezeigt zu werden, dieser Schicht hinzugefügt werden. (Ausnahmen bilden dabei natürlich alle visuellen Elemente tiefer liegender Schichten).

Stage3D als neuartige Schnittstelle für dreidimensionale Inhalte

Der Gedanke hinter Stage3D ist, die leistungsfähige Hardware, die in jedem modernen Computer steckt, mit dem meist verbreiteten Browserplugin, dem Flash Player, zu ver-binden. Somit kann jeder Nutzer neuartige 3D-Spiele und -Weberlebnisse erfahren.

3D-Hardwarebeschleunigung profitiert von der GPU der Grafikhardware eines Compu-ters. Dieses Bauteil ist dafür verantwortlich, dreidimensionale Inhalte zu rendern. Eine Flash Anwendung beschränkt sich beim Einsatz von Stage3D auf die Organisation und Definition einer dreidimensionalen Szene, welche direkt an die GPU übertragen wird. Die eigentliche Berechnung zur Darstellung der Objekte erfolgt dann nicht mehr in Flash, also der Software, sondern direkt auf der Hardware des Computers.

Eine 3D-Szene wird repräsentiert durch Polygone, welche aus einzelnen Punkten, so-genannten „Vertices“ konstruiert werden. Bisher mussten diese Vertices direkt von Flash verarbeitet werden, was trotz effizienter Programmierung ein sehr langsamer Vorgang ist, da die Berechnung auf der CPU des Computers vonstatten ging. Das ist so, da die CPU eine Vielzahl unterschiedlichster Operationen durchführen kann, für derartig rechenauf-wändige Aufgaben allerdings zu wenig optimiert ist – im Gegensatz zur GPU. An die GPU übergebene Vertices werden analysiert und zu einem Gesamtbild zusammengesetzt, welches dann durch Flash dargestellt wird. Da die GPU genau für diese Aufgaben ent-worfen wurde, ist dieser Vorgang enorm effizient und so kann in kürzerer Zeit ein Viel-faches an Polygonen verarbeitet werden.58

58 Vgl. [Adobe05 2011]

372. GRUNDLAGEN

2.3.2 Die 3D-Render-Pipeline

Der Rendervorgang von dreidimensionalen Inhalten wird von einer 3D-Render-Pipeline durchgeführt. Das heißt, dass der Prozess auf einzelne Blöcke aufgeteilt wird, welche jeweils eine spezifische Operation beherrschen und durchführen.

Abb.17: Die Stage3D-Grafikpipeline59

Die mit Stage3D genutzte Grafikpipeline ist teils programmierbar und funktioniert wie folgt: in Flash wird mithilfe der Stage3D-API eine dreidimensionale Szene erzeugt oder geladen. Diese besteht aus vielen einzelnen Vertices, welche als Vertex Stream an die GPU übergeben werden. Genauer gesagt an den Vertex Shader. Dieser manipuliert die eigent-liche Geometrie der Szene und projiziert sie in den Screen Space, also den zweidimensi-onalen Raum der Bildschirmfläche. Der Vertex Shader kann mit Flash programmiert werden, wodurch viele Effekte möglich sind, zum Beispiel eine Fisheye-Perspektive. Der transformierte Vertex Stream wird daraufhin an einen Block weitergeleitet, welcher aus den einzelnen transformierten Vertices ein Mesh konstruiert. Der daraus entstandene Triangle Stream wird daraufhin „geclippt“, also passend für den Viewport ausgeschnitten. Das heißt, dass für die folgenden Berechnungen nur die Polygone benutzt werden, welche auch wirklich später im gerenderten Bild sichtbar sein werden. Im darauffolgenden Schritt fügt der Rasterizer Texturen zu der Szene hinzu. An dieser Stelle können auch Effekte wie Nebel oder Alphablending angewandt werden. Der nächste ausgeführte Block, der Fragment Shader, kann wieder im Vorfeld in Flash programmiert werden. Hierbei handelt

59 Abbildung nachempfunden, vgl. [Adobe05 2011]

VertexStream Vertex Shader

transformierterVertex Stream Triangle Assembly

TriangleStream Viewport Clipping

Screen SpaceTriangle Stream Rasterizer

RasterizedStream Fragment Shader

ProcessedPixel Stream Frame Buffer

FinalImage


es sich wiederum um eine Shader-Einheit auf der Grafikkarte. Diese regelt, in welcher Art und Weise die einzelnen Pixel der Szene gerendert werden; beeinflusst also direkt die Farbe jedes einzelnen Bildpunktes, womit auch die Schattierung eines Bildes einhergeht. Durch die Option, diese Shader frei zu gestalten, bieten sich interessante Möglichkeiten, eine Szene wirken zu lassen. Der letzte Block ist der Bildspeicher (Frame Buffer), aus wel-chem das Endergebnis des Rendervorgangs schließlich ausgelesen wird.60

2.3.3 Die Verwendung von Stage3D„[...] Molehill does not replace anything in Flash – it simply adds to your bag of tricks.“ Christer Kaitila, Adobe Flash 11 Stage3D (Molehill) Game Programming61

Zur Initialisierung eines Stage3D-Objekts muss ein solches von der Stage, also der klassischen Flash-Bühne, angefordert werden. Jedes Stage3D-Objekt besitzt wiederum ein Objekt vom Typ Context3D. Die Stage3D fungiert als eine Art Zeichenfläche, wohingegen der Context3D Informationen über die darzustellenden Objekte und deren Abbildung beinhaltet.

Listing 1: Initialisieren einer Stage3D62

public function Stage3DGame(){ if (stage!=null) init(); else addEventListener(Event.ADDED_TO_STAGE, init);}

private function init(e:Event = null):void{ if (hasEventListener(Event.ADDED_TO_STAGE)) removeEventListener(Event.ADDED_TO_STAGE, init);

//class constructor - sets up the stage stage.scaleMode = StageScaleMode.NO_SCALE; stage.align = StageAlign.TOP_LEFT;

//and request a context3D from Stage3d stage.stage3Ds[0].addEventListener( Event.CONTEXT3D_CREATE, onContext3DCreate); stage.stage3D[0].requestContext3D();}

60 Vgl. [Adobe05 2011]61 Vgl. letzter Absatz S.23 [Kaitila 2011]62 Vgl. Listing S. 42 [Kaitila 2011]

392. GRUNDLAGEN

Das Kreieren von dreidimensionalen Objekten mit Stage3D ist ein anspruchsvoller Vor-gang. Die Vertices, also die einzelnen Raumkoordinaten eines 3D-Modells, müssen in einem VertexBuffer definiert werden. Da ein Modell jedoch intern ausschließlich durch Polygone repräsentiert wird, muss die richtige Reihenfolge der zuvor definierten Vertices in einem IndexBuffer eingetragen werden. Das händische Anlegen dreidi-mensionaler Strukturen mit Stage3D ist ein sehr abstrakter Vorgang.

Die Stage3D-APIs bieten von sich aus keine Möglichkeit, Modelle, welche mit externen Editoren (wie Blender) erstellt wurden, zur Laufzeit zu laden. Ein Parser, der solche Da-teien verarbeiten könnte, müsste demnach selbst geschrieben werden.

Der wohl kniffligste Teil im Umgang mit Stage3D ist die Programmierung der zum Ren-dern notwendigen Shader. Diese werden jedoch nicht mit ActionScript programmiert, sondern mit AGAL-Tokens innerhalb des eigentlichen ActionScript-Codes.

Die Adobe Graphics Assembly Language (AGAL) ist eine Sprache, welche Adobe zur Ent-wicklung eigener Shader zur Verfügung stellt. AGAL ist eine Assembler-ähnliche Spra-che, welche die Maschinensprache des Grafikprozessors repräsentiert. Mit AGAL ist es möglich, die programmierbaren Einheiten der Grafikpipeline, also den Vertex- und den Fragment Shader, zu entwerfen. Da dies mit OpCodes, kurzen Maschinensprachen-ähn-lichen Befehlen, vollzogen wird, ist dies auch für erfahrene ActionScript-Entwickler Neuland. Die damit erreichbaren Effekte sprechen jedoch für sich: die Web App „AGALtheMean“ demonstriert eindrucksvoll die Fähigkeiten von AGAL und bietet dem Entwickler eine Möglichkeit, Shader direkt im Browser zu entwerfen.

Abb.18: AGALtheMean63

63 Quelle: http://www.lidev.com.ar/agalthemean/preview/


Bei der Entwicklung von Stage3D arbeitete Adobe eng mit Programmierern existieren-der Flash-3D-APIs zusammen, welche die Fähigkeiten des hardwareunterstützten Ren-derings nun kapseln, um es anderen Entwicklern leichter zu machen, mit Stage3D zu arbeiten. Im Folgenden sollen drei dieser Bibliotheken vorgestellt werden: Proscenium, Away3D und Starling.

Proscenium

Adobe Proscenium ist eine sich noch in der Entwicklung befindliche 3D-Engine für die Verwendung mit Stage3D. Die Engine kann kostenlos heruntergeladen werden64 und wird als SWC-Bibliothek in ein Projekt importiert.

Entwickelt wird diese API, um die eigentlichen Fähigkeiten der Stage3D vereinfacht de-monstrieren zu können und um Programmierer dazu zu bewegen, Stage3D auszuprobie-ren. Dabei weist Adobe ausdrücklich darauf hin, dass die Software noch Fehler enthalten kann und es keine Sicherheit gibt, dass es jemals eine finale Version der Bibliothek geben wird. Es wäre daher leichtsinnig, Projekte mit Proscenium umsetzen zu wollen.65

Away3D„Away 3D is one of the most popular real-time 3D engines available for Flash, allowing for the creation of a wide range of 3D applications, including visualizing detailed 3D environments, displaying animated 3D models, creating 3D text, and showing off a huge variety of special effects. With Away3D, a litte ActionScript, and a big imagina-tion the possibilities are endless“66

Away3D ist eine OpenSource 3D-Bibliothek für Flash, welche seit 2007 fortlaufend ent-wickelt wird und einen beträchtlichen Funktionsumfang besitzt. Die aktuelle Version (4.0) baut auf den Stage3D-APIs auf und ist syntaktisch sehr ähnlich der eigentlichen Flash-API aufgebaut. Mit Away3D lässt sich eine Vielzahl bekannter Formate laden. Sogar animierte Netze können importiert werden. Mit über 25 verschiedenen geome-trischen Primitiven lassen sich mit der API eindrucksvolle Szenen bauen. Neben den verschiedenen Primitiven bietet Away3D auch eine Vielzahl an Materialien, Shadern, Kameras, Lichtern und weiteren Eigenschaften.

Hinter Away3D steht eine kreative Gemeinschaft, welche die Bibliothek stetig weiter-entwickelt und um neue Features ergänzt.67 Neben anderen 3D-Engines für Flash ist Away3D von der wohl lebendigsten Community umgeben.

64 siehe: labs.adobe.com/technologies/proscenium65 Vgl. [Adobe10 2011]66 Vgl. Preface [Casperson 2011]67 Vgl. [Away 2011]

412. GRUNDLAGEN

Die Einbindung der Bibliothek in eigene Projekte ist sehr einfach. Um Away3D nutzen zu können, wird als erstes die API von der Webseite68 heruntergeladen und entpackt. Die enthaltene swc-Datei, welche alle Klassen der API beinhaltet, wird nun an eine geeigne-te Stelle im Projektverzeichnis kopiert und dem Klassenpfad hinzugefügt.

Away3D kümmert sich nun automatisch auch um die Benutzung der Stage3D. Der Ent-wickler erstellt nun nur noch ein Objekt vom Type View3D, und die API nutzt automa-tisch die Leistung der Hardware zum Darstellen der 3D-Szene.

Sollte das ausführende Gerät über keine kompatible Grafikhardware verfügen, so fällt Stage3D (und so auch Away3D) in einen Software-Fallback Modus zurück. Es wird also die CPU zur Berechnung der 3D-Szene benutzt. Obwohl dies aufgrund der geringeren Leistung eine weniger performante Lösung darstellt, bietet dieses Vorgehen trotzdem al-len Nutzern die Möglichkeit, eine Anwendung unabhängig von der genutzten Hardware zu betrachten.

Vom Away3D-Team gibt es außerdem eine kompatible Physik-Engine (AwayPhysics), welche ebenfalls für Stage3D optimiert wurde. Auch die Kollisionserkennung im dreidi-mensionalen Raum wird auf die GPU verlagert und dadurch stark beschleunigt.

Starling

Der österreichische Spielehersteller GAMUA bietet mit Starling eine interessante Biblio-thek an, welche ebenfalls Stage3D zum Rendern benutzt. Dabei handelt es sich um keine reine 3D-Engine, sondern um eine Adaption der existierenden 2D-Elemente aus Flash in eine 3D-Umgebung. Das heißt, dass das Prinzip der Sprites und MovieClips für die Nutzung mit der Grafikhardware angepasst wurde. Die Engine erstellt dabei einfachste Meshes und bildet Grafiken und Animationen darauf als Textur ab. Das Ergebnis ist eine zweidimensionale Ansicht einer Szene, welche im Hintergrund jedoch von der leistungs-fähigen 3D-Engine verarbeitet wird.69

Der resultierende Vorteil ist, dass Entwickler die bekannte ActionScript Syntax verwenden können. Anstatt des flash.display-Packages, muss lediglich das flash.starling-Package importiert werden.

Als nachteilig könnte gewertet werden, dass die visuellen Elemente nicht auf der Sta-ge liegen, sondern auf der Stage3D-Darstellungsebene, also unterhalb der eigentlichen DisplayList. Dies könnte zu Problemen führen, wenn außerdem StageVideo verwendet werden soll, da die Stage3D diese Darstellungsebene komplett überdeckt.

68 siehe: away3d.com/download69 Vgl. [Adobe07 2010]


2.3.4 Vor- und Nachteile von Stage3D

Die Standard APIs zum Rendern dreidimensionaler Szenen sind OpenGL und DirectX. Im Vergleich zu Stage3D ist der Aufwand, eine eindrucksvolle Anwendung mit diesen APIs zu erzeugen, recht hoch und es erfordert einige Erfahrungen auf diesem Gebiet, da diese Schnittstellen sehr nah an der Hardware angesiedelt sind. Stage3D hingegen macht es dem Entwickler einfacher, dreidimensionale Anwendungen zu erzeugen, da lediglich auf der Stage3D-Abstraktionsebene entwickelt wird. Dies bringt natürlich auch Nach-teile mit sich, da nicht direkt die Zielhardware angesprochen werden kann, sondern eben nur die virtuelle Stage3D, welche zwischen der Hardware und dem eigentlichen Code liegt.

Ein Vorteil der Technologie ist, dass sich alle bisherigen Funktionen von Flash kon-fliktfrei weiterhin nutzen lassen. Erfahrenen Entwicklern ist es also ein Leichtes, 3D-Anwendungen um die bekannten 2D-Elemente zu erweitern.

Der wohl größte Vorteil bei der Nutzung von Stage3D ist der, dass Stage3D-Applikatio-nen auf multiplen Plattformen funktionsfähig sind. Eine solche Anwendung ist auf dem Desktop nativ und im Browser, sowie zukünftig als Mobile Apps für iOS oder Android lauffähig, und das, ohne den Code anpassen zu müssen. Betrachtet man die flächen-deckende Verbreitung des Flash Players lässt sich erahnen, wie groß das Potential von Stage3D sein kann.

Der Hauptnachteil ist sicherlich der Fakt, dass es sich bei Stage3D um eine Abstrakti-onsebene handelt. Um möglichst viele Plattformen bedienen zu können ist es daher nicht möglich, die Fähigkeiten aktueller Grafikchips voll auszunutzen. Dies bedeutet, dass sich einige realistische Effekte heutiger Computerspiele nicht mit Stage3D erreichen lassen.70

70 Vgl. [Adobe05 2011]

433. KoNZEPTIoN DER MULTISCREEN-ANWENDUNG

3. Konzeption der Multiscreen-Anwendung

3.1 Anforderungen

Es wird eine interaktive 3D-Multiscreen-Anwendung zu Anschauungszwecken für zwei Screens geschaffen. Das iPad2 ist aufgrund seiner Popularität und Aktualität eine inter-essante Zielplattform und außerdem hervorragend geeignet, um in Präsentationen einge-setzt zu werden; es wird für diesen Screen eine Mobile App entwickelt. Der Desktop ist dem größten Teil potentieller Nutzer zugänglich und daher nach wie vor der bedeutungs-vollste Screen; für diesen wird eine Web App entwickelt, also eine Flashanwendung, welche über einen Browser betrachtet werden kann.

Das Ziel ist die Veranschaulichung der neuen 3D-Fähigkeiten des Flash Player 11, sowie der Möglichkeit, mit Hilfe der Flash Plattform performante iOS-Apps entwickeln zu können. Innerhalb der Jung von Matt Flash-Unit dient die Anwendung außerdem dem Zweck, einen entkoppelten Entwicklungsansatz für Multiscreen-Anwendungen zu tes-ten. Bei der Implementierung sollen die im Vorfeld diskutierten Konzeptmuster berück-sichtigt werden.

3.2 Idee, Grobkonzept und erste Tests

Die ersten Ideen wurden in einem Brainstorming der Flash Developer gesammelt. Als Eckpfeiler der Diskussion dienten die 3D-Fähigkeiten von Flash und das iPad als wich-tigster Ziel-Screen. Die gemeinsame Schlussfolgerung war, dass die zu entwickelnde An-wendung der Inszenierung eines Produkts oder einer Marke dienen sollte. Schnell stand die Idee eines interaktiven Fahrzeugkonfigurators im Raum. Im Mittelpunkt sollte ein aktuelles Fahrzeugmodell stehen, bei welchem sich die Lackierung und die Felgen ver-ändern lassen könnten. Eine virtuelle Probefahrt durch eine realistische 3D-Szene sollte das Gesamtbild abrunden.

Die ersten Tests ergaben, dass die Darstellung eines einfachen Modells ohne Konflikte zu bewerkstelligen war. Ein realistisches Modell mit unterschiedlichen Materialien und Texturen erforderte dagegen jedoch erheblichen Aufwand. Auch brachte die Steuerung des Fahrzeugs Schwierigkeiten mit sich: die Komplexität der Simulation einer halbwegs realistischen Fahrzeugbewegung wurde deutlich unterschätzt. Auch ist das iPad wenig geeignet, um damit intuitiv ein Fahrzeug steuern zu können. Die Idee wurde darauf-hin vereinfacht. Statt eines komplexen steuerbaren Vehikels sollte ein einfacheres Objekt verwendet werden, welches sich um den eigenen Mittelpunkt rotieren lassen könnte. Für diese Interaktion ist das iPad durch seinen Touchscreen bestens geeignet. An dem Ge-danken des Umfärbens wurde festgehalten.

Nach weiteren Tests, die das 3D-Objekt betrafen, wurde der Entwicklungsprozess für iOS-Geräte unter die Lupe genommen. Als ein Überblick über diesen Vorgang bestand, wurde der Funktionsumfang festgelegt, um mit dem Feinkonzept beginnen zu können.


3.3 Technische Vorbetrachtungen

3.3.1 Gewählte technische Herangehensweise

Die ursprüngliche Überlegung war, eine anpassungsfähige Einzelanwendung zu schaffen. Diese hätte durch unterschiedliche Konfigurationen und zahlreiche robuste Abfragen im Code zwei unterschiedliche Apps, also sowohl die Mobile App für das iPad2, als auch die Desktop Web App, aus ein und der selben Basisanwendung generieren sollen. Dies ließe sich mit Hilfe bestimmter Tools, wie z.B. ANT71, realisieren. Mit ANT können un-terschiedliche Konfigurationen zur Kompilierung eines Programms erstellt werden. So ist es möglich, aus ein und demselben Sourcecode unterschiedliche Apps zu kompilieren. Dank Cross-Compiling72 kann eine Anwendung für unterschiedliche Zielsysteme erzeugt werden.

In der frühen Recherchephase kristallisierte sich durch Aussagen vom Adobe-Exper-ten Radley Marx (siehe „Multiscreen: Definition und Grundkonzept“) heraus, dass eine entkoppelte Entwicklung die Empfehlung der Fachleute sei. Außerdem sprach die im Vorfeld angesprochene stark steigende Varianz der möglichen Zielgeräte dafür, diesen Ansatz zu verfolgen; auch wenn die Auftrennung in mehrere Projekte initial einen er-höhten Aufwand bedeutete. Ähnliche Kritikpunkte ließen sich auch für die Entwicklung einer komplexen Einzelanwendung finden: mit wachsendem Umfang wird es bei dieser Herangehensweise schwer, genau ein Programm zu entwickeln, das alle denkbaren Son-derfälle abzudecken vermag und gleichzeitig fehlertolerant genug ist. Da der Ansatz einer entkoppelten Multiscreen-Anwendung bisher noch nicht vom Flash-Team verfolgt wur-de, war dies ein weiterer Grund, diese Herangehensweise zu wählen, um Erfahrungen zu sammeln.

Die Entscheidung für eine entkoppelte Entwicklung bedeutet, dass für jeden Screen, der bedient werden soll, ein eigenes Projekt anzulegen ist. Beim Kompilieren besteht so später keine Notwendigkeit, gerätespezifische Eigenschaften unterschiedlicher Devices zu betrachten. In jedem Projekt steht ausschließlich das Zielgerät im Fokus. Da die zu entwickelnde Anwendung auf mehreren Screens laufen soll, trotzdem aber gemeinsame Komponenten bestehen, werden alle wiederverwendbaren Bausteine in einer Basisappli-kation implementiert, auf welche die einzelnen Projekte dann zugreifen können.

Das Model-View-Control-Pattern (kurz: MVC) soll bei der Programmierung der Proto-typen Einsatz finden. Diese Vorgabe wird bei Jung von Matt bei jedem größeren Projekt gestellt. Um die Arbeit im Team zu erleichtern, liegt besonderes Augenmerk darauf, klar strukturierten, sauberen und nachvollziehbaren Code zu schreiben. Für die Architektur der Anwendung wird ein Mikroarchitektur-Framework verwendet.

71 Another Neat Tool, siehe: http://ant.apache.org/72 Ein Cross-Compiler erzeugt Kompilate für verschiedene Zielsysteme, welche unterschiedlich zum eigentlich kompilierenden System sind.


3.3.2 Architektur der Anwendung unter Nutzung eines

Mikroarchitektur-Frameworks (Robotlegs)

Für die Implementierung einer solch flexiblen Anwendung ist es ratsam, nachvollziehba-re Design-Pattern und bestimmte programmiertechnische Konzepte zu verfolgen. Das Flash-Team bei Jung von Matt hat über die Jahre mit verschiedenen Frameworks gearbei-tet. In der letzten Zeit fand das Robotlegs-Framework73 häufig Verwendung.

Robotlegs ist ein leichtgewichtiges Mikroarchitektur-Framework und stellt eine solide Grundlage zur Implementierung eines MVC-Pattern zur Verfügung. Das Framework ermöglicht eine lose Kopplung der einzelnen Klassen und einen somit flexibleren Aufbau der Applikation.

Es würde den Rahmen dieser Arbeit sprengen, eine vollständige Einführung in Robot-legs zu liefern. Da das Framework für eine effiziente Entwicklung jedoch unentbehr-lich ist, sollte ein gewisses Grundverständnis dafür vorhanden sein. Deswegen soll im Folgenden kurz erläutert werden, welche Softwarearchitektur-Pattern durch Robotlegs verwendet werden. Aufgeführt sind die für die Prototypen relevanten Entwurfsmuster:74

Automatisierte Dependency Injection

Dependency Injection bedeutet, dass Objekte, von denen eine Klasse abhängig ist, in diese Klasse injiziert werden. Dafür müssen im Context einer Anwendung bestimmte Regeln definiert werden. Durch diese Vorgehensweise wird eine sehr lose Objekt-Kopplung er-reicht, womit die Flexibilität in der Entwicklung stark steigt.

Der Context ist der Einstiegspunkt in die Applikation. Hier wird die Logik verknüpft, es werden Regeln zur Injektion festgelegt und Views zur Anzeigeliste hinzugefügt.

Mediator Pattern

Mediatoren sind zweckgebundene Objekte zur Kommunikation zwischen Views und Models. Sie hören auf verschiedene Events und stoßen die entsprechend verknüpfte Funktionalität im Model oder seiner View an. Selbst beinhalten sie kaum Logik. Durch den Einsatz von Mediatoren müssen Objekte nichts mehr direkt voneinander wissen, um miteinander kommunizieren zu können.

73 siehe: http://www.robotlegs.org/74 Vgl. S.3 [HooksFallow 2011]


3.3.3 Konventionen

Bei der Programmierung der Prototypen werden die allgemeingültigen AS3-Coding-Conventions75 befolgt. Auch werden Konventionen beachtet, die sich im Flash-Team he-rausgebildet haben. Die dabei wohl auffälligste Besonderheit ist, dass private Funktionen und Variablen zur besseren Übersicht mit einem Unterstrich eingeleitet werden.

3.4 Entkoppelte Entwicklung einer Multiscreen-Anwendung

Die zu entwickelnde Multiscreen-Anwendung besteht aus mehreren individuellen Appli-kationen. Als Grundlage dient eine Basis App, welche Funktionen bündelt, auf die später von jedem Screen aus zugegriffen werden kann. Diese speziellen Anwendungen werden vorerst allgemein abgehandelt, weswegen sie nachfolgend als „Screen Apps“ bezeichnet werden.

3.4.1 Basis-Applikation

Abb.19: Grundkonzept der Basis-Applikation

75 siehe: http://opensource.adobe.com/wiki/display/flexsdk/Coding+Conventions

Basis App

wiedervendbare Grundfunktionalität

globale Komponenten

globale Konstanten, Models, Events(Sprache, Farben, ...)

gemeinsam genutzte Assets undBibliotheken


Die Basis App ist die Grundlage für alle zu entwickelnden Screen Apps. Sie bündelt die Grundfunktionalität, welche in allen Einzelanwendungen verfügbar sein soll. Dies geschieht vor allem in Form abstrakter Klassen. In diesen werden Methoden und Varia-blen implementiert, von denen anzunehmen ist, dass jeder Screen später gleichsam in der Lage ist, diese zu nutzen. Spezifische Klassen in den Screen Apps erweitern hierfür die abstrakten Klassen der Basis App. Dank der Vererbung von Funktionen und Eigenschaf-ten kann somit eine Verbindung zwischen Basis- und Screen-Funktionalität geschaffen werden.

Die Basis beinhaltet auch einen Pool von Komponenten, Konstanten und Bibliotheken, aus welchem sich die Screens bedienen können. Farbinformationen, Schriftarten, aber auch individuell angepasste Komponenten wie Textfelder oder Buttons lagern in der Ba-sis, damit über alle Anwendungen hinweg ein einheitliches äußeres Erscheinungsbild gewährleistet werden kann. Im Umkehrschluss bedeutet dies, dass einfache grafische An-passungen, wie z.B. Farbkorrekturen nur an der Basis vorgenommen werden müssen. Die Screens adaptieren damit automatisch die getätigten Änderungen.

Die Planung der Basis App ist ein wichtiger Punkt. Schließlich soll sie genügend wieder-verwendbaren Code anbieten, um den Aufwand in den einzelnen Screen Apps möglichst gering zu halten. Auf der anderen Seite muss unnötiger Ballast vermieden werden.

Die Entwicklung der Basis-Applikation erfolgt synchron zu der Arbeit an den Screen Apps. Im Idealfall wird mit genau einem Screen begonnen. Es muss dabei individuell abgewägt werden, ob etwas in die Basis oder die spezifische Screen-Applikation gehört. Alle kontextrelevanten Implementierungen und alle Funktionen, die in irgendeiner Art und Weise vom Zielscreen abhängig sind, gehören nicht in die Basis. Derartige Überle-gungen sollten bereits während der Konzeptionen stattfinden, um einen effizienten Ent-wicklungsprozess zu ermöglichen.


3.4.2 Screen-Applikation

Abb.20: Grundkonzept der Screen-Applikationen

Für jeden Screen, der mit einer Anwendung bedient werden soll, muss eine individuelle Applikation angelegt werden. Jede dieser Screen Apps hat Zugriff auf die Basis-Applika-tion, kann auf deren Funktionalität zugreifen und diese erweitern. Dies betrifft sowohl Programmlogik, als auch Layout-Elemente.

Komponenten und Elemente, die nur für den jeweiligen Screen benutzt werden, lagern in der Screen App, sodass auch nur diese darauf zugreifen kann. Während jeder Screen auf Komponenten der Basis zugreifen kann, wissen die Screens nichts voneinander und sind auch nicht von einander abhängig. Die in einem Screen definierten Komponenten und Funktionen sind exklusiv in dieser Screen App vorhanden.

Screen Apps

screenspezifische Funktionalität

lokale Komponenten

screenspezifische Kommunikation mit /Implementierung von globalen Models

gesondert genutzte Assets undBibliotheken


3.5 Feinkonzept

Die umzusetzende Multiscreen-Anwendung wird für zwei Zielscreens entwickelt: Tablet (iPad2) und Desktop. Dabei wird das Multiscreen Muster „Coherence“ verfolgt, da beide Screen Apps gleich aussehen und den gleichen Funktionsumfang besitzen sollen.

Die Grundidee ist, ein dreidimensionales Objekt darzustellen, welches ein gedachtes Pro-dukt repräsentiert. Die Anwendung an sich fungiert also als „Showcase“ für das Produkt, einen Sportschuh76. Der Nutzer ist in der Lage, den Schuh durch Rotation und Skalie-rung von verschiedenen Seiten zu betrachten. Auch kann die Farbe verändert werden, wobei die Anzahl der wählbaren Farben vordefiniert ist und möglichst klein gehalten wird. Eine Text-Komponente stellt fiktive Produktinformationen dar. Die Anwendung soll das beworbene Produkt in den Mittelpunkt stellen und möglichst einfach steuerbar sein.

Nach den Vorbetrachtungen der Konzeptmuster für Multiscreen-Entwicklung erscheint es als sinnvoll, das „Mobile First“-Muster zu verfolgen und zuerst die iPad-App zu be-trachten. Die aus dieser Konzeption gewonnenen Erfahrungen werden im Anschluss auf die Desktop App übertragen.

Abb.21: Frühe Konzeptskizzen

76 Vom Auto zum Sportschuh: Zu den Kunden von Jung von Matt gehören unter anderem die Unternehmen Mercedes Benz und NIKE. Beide Marken bieten Produkte an, welche von ihren Kunden in einem bestimmten Umfang konfiguriert werden können. Es ist daher naheliegend, schon für die Prototy-pen ein Objekt auszuwählen, welches für den praktischen Einsatz im Agenturgeschäft relevant ist.


Bevor jedoch mit der genaueren Planung einzelner Screen Apps begonnen werden kann, muss genau konzipiert werden, welche Teile der Implementierung in der Basis stattfinden sollten, und was in die Screen Apps gehört. Die Basis wird parallel mit der iPad-App entwickelt. Im Vorfeld ist also genau zu überlegen, welche Programmier-Paradigmen ver-folgt werden, um die Anforderungen an eine Multiscreen-Anwendung bestmöglich zu erfüllen.

Durch die Untersuchung der gestellten Anforderungen und Evaluationen innerhalb der Gruppe der Flash Developer haben sich folgende wichtige Betrachtungen ergeben:

• Alle über den Entwicklungszeitraum variablen Eigenschaften, insbesondere Far-ben, sollten über unterschiedliche Screens hinweg an zentraler Stelle änderbar sein. Hierfür eignet sich die Nutzung von Models und Konstanten in der Basis.

• Die Kopplung einzelner Klassen sollten einer besseren Austauschbarkeit halber möglichst gering sein. Um die in jedem Screen bestehenden Views frei von Ge-schäftslogik und Verbindungen zum Model zu halten, werden Mediatoren-Klas-sen verwendet. Wiederkehrende Grundfunktionalität wird in abstrakten Klassen in der Basis definiert. In den Screen Apps wird dann von diesen Klassen geerbt, sodass deren Funktionalität genutzt werden kann.

• Die zu verwendenden Grafiken werden nicht zur Laufzeit nachgeladen, sondern in Bibliotheken gespeichert. Da in jeder Screen App unterschiedliche Grafiken verwendet werden sollen, erhält jeder Screen eine eigene Asset-Bibliothek. Die Funktionalität zum Nutzen dieser Bibliotheken sollte jedoch in der Basis defi-niert werden, da diese für jeden Screen gleich ist.

• Um eine Grundlage für mehrsprachige Anwendungen zu legen, werden Sprach-dateien in Form von xml-Dateien benutzt. Diese müssen zur Laufzeit nachgela-den werden, da die Sprache ja theoretisch zur Laufzeit verändert werden können sollte. Da derartige Dateien auf mobilen Geräten aus dem Dateisystem geladen werden, ist der Ladevorgang von Screen zu Screen ein anderer. Daher muss das Laden einer xml-Datei für jede Screen App gesondert behandelt werden. Die Verwendung der in den Sprachdateien enthaltenen Texte sollte aber wiederum für jeden Screen gleich vonstatten gehen, sodass diese Mechanik in der Basis zu implementieren ist.

• Der 3D-Container für das benutzte Schuh-Modell ist in jeder Screen App der gleiche. Die Initialisierung der Lichter und Kamera kann daher also in der Basis erfolgen. Auch die Funktionalität des Umfärbens des Modells ist immer gleich. Der entscheidende Unterschied einzelner Screen Apps liegt in der Form der In-teraktion. Diese wird daher abhängig vom Kontext entwickelt. Eine Klasse der Basis, welche die initialisierte Szene beinhaltet, liefert die Grundlage hierfür.

Weitere Überlegungen betreffen die einzelnen in den Prototypen verwendeten grafischen Komponenten. In den Konzeptskizzen treten wiederkehrende Elemente auf, welche in


der Basis liegen sollten, sodass jede Screen App unkompliziert darauf zugreifen kann. Bestimmte von Screen zu Screen variierende Komponenten werden spezifisch in der je-weiligen App implementiert. Eine Auflistung der zu erstellenden Elemente und deren Auftreten erleichtert die Einschätzung, ob diese in der Basis oder in Screen Apps veran-kert sein sollten.

Die folgende Tabelle gibt eine Übersicht über die in den Prototypen verwendeten visuel-len Komponenten und deren Speicherort.

Basis-Projekt Mobile-Projekt Desktop-Projekt

Preloader

InfoBox

Headline

Subline

ColorBar ColorPicker

ColorBox ColorStripe

Away3DContainer Away3DContainerMobile Away3DContainerDesktop

AbstractMultiscreenView MobileView DesktopView

Tab.3: Komponentenübersicht

Bei dem Preloader (Anzeige des Ladevorgangs), der InfoBox, Headline und Subline handelt es sich um die Elemente, welche unabhängig vom Screen immer gleich in Erscheinung treten. Sie werden in der Basis definiert. Der Farbwähler ist im Mobi-le-Projekt eine Leiste (ColorBar) mit einzelnen Farbboxen (ColorBox), wohingegen er im Desktop-Projekt durch einen kleinen Farbwähler (ColorPicker) mit einzelnen Farbstreifen (ColorStripe) visualisiert wird. Der Away3DContainer stellt die 3D-Szene dar und wird durch die einzelnen Screen-Projekte um die Interaktivität erwei-tert. Die AbstractMultiscreenView definiert die Grundfunktionalität der späteren Views. Die Views der Prototypen erben die Funktionalität dieser Klasse und erweitern sie um screenspezifische Anzeigeelemente.


3.5.1 iPad App (Mobile App)

Abb.22: UI-Konzept der Mobile App

Kurzbeschreibung der App

Auf dem Startbildschirm des iPads wird die App durch ein in seiner Form typisches Icon repräsentiert. Nach dem Auswählen der App startet diese und der Nutzer nimmt als erstes ein zentriertes dreidimensionales Objekt (2) wahr, welches durch einen kurzen Informationstext (1) beschrieben wird. Für die erste Interaktion mit dem Objekt ist es nicht notwendig, den Bildschirm zu berühren. Allein durch den Winkel, in welchem das iPad in der Hand gehalten wird, verändert sich die Ansicht auf das Objekt. Liegt das Tablet auf dem Tisch, so sieht man das Objekt aus einer Draufsicht, hält man das Tablet vor sich, so kann man das Objekt von vorn sehen. Diese teils subtile Bewegung soll zur Interaktion anregen. Durch horizontales Wischen mit dem Finger kann das Objekt ge-dreht werden, um es von allen Seiten betrachten zu können. Mit einer Zwei-Finger Geste („Pinch“) kann die Ansicht skaliert werden. Am unteren Bildschirmrand befindet sich eine Leiste (3), welche durch ihre Größe und Farbigkeit ebenfalls zur Interaktion einlädt. Beim Antippen eines Farbfelds nimmt das Objekt diese Farbe an. Die Bedienung ist sehr spielerisch und erfordert keinerlei Erklärung. So wird erreicht, den Fokus von der Bedie-nung und der minimalistischen Gestaltung direkt auf das dargestellte fiktive Produkt zu richten.

1)

2)

3) 1)3)

1) Info-Box Komponente2) interaktives 3D-Modell3) Farbwähler

-auf Rotation des Geräts reagieren (StageOrientation)

2)


Interaktionskonzept

In der Mobile App werden verschiedene Interaktionswege unterschieden. Die größte Be-deutung kommt hierbei dem Touchscreen und dem Beschleunigungssensor des iPads zu.

Multitouch-Interaktion77

In Flash existiert eine Klasse Multitouch, welche sich um die Behandlung von Mul-titouch-Events kümmert. Diese Klasse unterstützt zwei grundlegende Eingabemodi: TOUCH_POINT und GESTURE. Ersterer ist geeignet, um auf (Multi)Touch-Eingaben des Nutzers zu reagieren. Die Abhandlung von TouchEvents ist sehr ähnlich zu MouseEvents, nur das eben mehre Berührungspunkte existieren können. Hiermit lie-ße sich die Rotation des Schuhs sehr gut umsetzen. Mit dem Eingabemodus GESTURE kann auf bestimmte vordefinierte Gesten reagiert werden, zum Beispiel der „Pinch“-Geste, welche zum Zoomen des Schuhmodells genutzt werden soll. Bevor dies jedoch geschehen kann muss überprüft werden, ob auf dem benutzten Gerät derartige Interakti-onen überhaupt unterstützt werden:

Listing 2: Abfrage, ob TouchEvents unterstützt werden

if (Multitouch.supportsTouchEvents) { //do something}

Da der Nutzer die Möglichkeit haben soll, zu jedem beliebigen Zeitpunkt entweder zu zoomen oder das Modell zu rotieren, entsteht ein Konflikt. Denn Flash ist nur in der Lage, auf einen der beiden Eingabemodi zu hören.

Um dem Nutzer trotzdem die Möglichkeit zu geben, das Modell jederzeit zu drehen und zu zoomen, wird die bereits angesprochene hohe Ähnlichkeit zur MouseEvent-Klasse genutzt. Für den Rotationsvorgang wird nur ein Finger benötigt, wodurch die Abfrage auf Multitouch-Ereignisse also gar nicht zwingend notwendig ist. Die Implementierung einer solchen Funktionalität kann daher auch mit Mausereignissen gelöst werden. Die Multitouch-Klasse kann demnach also auf den Eingabemodus GESTURE konfiguriert werden, um so eine Zoom-Funktionalität komfortabel umsetzen zu können.

Bestünde die Notwendigkeit, Gesten und Multitouch gleichzeitig zu verwenden, müss-te auf den Modus TOUCH_POINT zurückgegriffen werden. Die Erkennung bestimmter Gesten müsste dann allerdings auch selbst übernommen werden.

77 Vgl. [Adobe08 2011]


Accelerometer

Die Draufsicht auf die 3D-Szene soll durch die Neigung des iPads kontrolliert werden können. Folgendes Schaubild verdeutlicht die Idee:

Abb.23: Steuerung der Kamera durch Geräteneigung

Dies ist nur möglich, da das iPad ein integriertes Accelerometer besitzt, also einen Be-schleunigungssensor. Dieser kann direkt aus Flash angesprochen werden, wobei auch hier zu prüfen ist, ob das ausführende Gerät über einen solchen Sensor verfügt:

Listing 3: Abfrage, ob das Accelerometer unterstützt wird

if (Accelerometer.isSupported) { //do something}

Orientierung

Eine Besonderheit vieler mobiler Geräte ist, dass man es nicht „falsch“ halten kann. Wird das Gerät auf die Seite gedreht, so rotiert sich die Ansicht entgegen der ausgeführten Drehung. Dadurch ist auch nach der neuen Orientierung alles korrekt betrachtbar. Die Möglichkeit der Reaktion auf ein solches StageOrientation-Ereignis existiert dank des integrierten Accelerometers, welches auch die sich ändernde Orientierung registriert.

Beim iPad wird zwischen zwei Ansichtsmodi unterschieden: Portrait (Hochformat) und Landscape (Querformat). Um die breitformatige Ansicht des Schuhmodells in jeder An-sicht beizubehalten, wandert die Beschreibung nach dem Drehen des Geräts auf eine extra Fläche unterhalb der 3D-Ansicht, der Farbwähler bleibt unterhalb der 3D-Ansicht. Hierdurch erfüllt die Mobile App gewisse Teile der Anforderungen des Konzeptmusters „Responsive Design“.

a

b

ca b c


3.5.2 Desktop App (Web App)

Abb.24: UI-Konzept der Desktop App

Kurzbeschreibung der App

Auch in der Desktop Web App kommt die größte Bedeutung dem abgebildeten drei-dimensionalen Objekt (2) zu teil. Dieses wird durch einen Informationstext (1) erklärt, genau wie aus der iPad App bekannt. Um den Nutzer zur Interaktion mit dem Objekt zu motivieren, wird dieses bereits initial langsam automatisiert rotiert. Klickt man auf das Objekt und bewegt dabei die Maus, so kann eine beliebige Rotation durchgeführt wer-den. Zum Zoomen dient das Mausrad. Nutzer sind häufig mit dieser Funktionalität ver-traut. Im Gegensatz zur iPad App gibt es hier keine dominante Farbleiste. Da die Maus ein weitaus filigraneres Steuern der Anwendung ermöglicht, wird auf die Präsenz eines Farbwählers in einer aus der iPad App bekannten Form verzichtet. Durch das Gedrückt-Halten der Maustaste, ohne die Maus zu bewegen, wird ein kleiner Farbwähler an der aktuellen Mausposition eingeblendet. Durch Klicken auf die Farbpunkte wechselt das Objekt die Farbe. Außerdem gibt es ein kleines Schließen-Kreuz, nach dessen Betäti-gung der Farbwähler wieder verschwindet.

Im Gegensatz zur Mobile App ist die Dimension dieser Anwendung nicht von Anfang an klar vorhersehbar. Damit sie jedoch auf großen wie auf kleinen Bildschirmen gleicher-maßen gut betrachtet werden kann, muss sich die Applikation responsiv verhalten. Da die Anwendung im Browserfenster ausgeführt wird, kann auf eine Größenveränderung dieses Fensters reagiert werden. Der Inhalt passt sich immer so an, dass das Objekt in der Mitte des Fensters steht. Da aufgrund der natürlichen Dimension des Screens nicht er-wartet werden muss, das die Anwendung ausschließlich hochkant betrachtet wird, erfolgt auch keine Ausrichtung danach; der informative Text bleibt immer oben links. Dies ist auch so, damit ein Nutzer nicht durch unnötige Animationen irritiert wird.

1)

3)2)

1) Info-Box Komponente2) interaktives 3D-Modell3) Farbwähler

-auf Größenänderung des Fensters reagieren (Resize)


Interaktionskonzept

Die Interaktion mit der Desktop App beschränkt sich auf die Maussteuerung. Das Dre-hen des Schuhmodells wird bei gedrückter Maustaste vollführt, zum Zoomen wird das Mausrad benutzt. Dies sind typische Funktionsbelegungen für die Maus und daher in-tuitiv verwendbar.

Die Interaktion mit dem Browserfenster, welcher die als Web App auftretende Anwen-dung umrahmt, hat eine Layoutanpassung des Inhalts zur Folge. Nach dem Grundge-danken des Responsive Design passt sich der Inhalt dem verfügbaren Platz an.

574. UMSETZUNG

4. Umsetzung

4.1 Vorbereitung

4.1.1 Entwickeln für ioS78

Um Applikationen für iOS entwickeln zu können, ist zuerst einige Vorarbeit notwendig. Denn Apple erlaubt es nur registrierten Entwicklern, iOS-Apps zu programmieren. Die hierfür erforderlichen Schritte sollen im Folgenden kurz erläutert werden.

Hinweis: Das Apple Developer Certificate kann sowohl von einem PC, als auch von einem Mac aus angefordert werden. In jedem Fall muss aber die aktuellste iTunes-Version auf der Maschine installiert sein. Die folgende Erklärung beschreibt die notwendigen Schritte an einem Mac.

Dem Apple Developer Program beitreten

Bevor eine eigene App programmiert, veröffentlicht und installiert werden kann, muss man dem Apple Developer Program beitreten. Die Mitgliedschaft kostet 99$ pro Jahr, bzw. 299$ für die Teilnahme am Enterprise-Program.

Unter der URL http://developer.apple.com kann man einen Account anlegen. Nach der Bestätigung durch Apple ist es anschließend möglich, das Apple Developer Certificate zu erzeugen, welches zur Entwicklung von Apps notwendig ist.

Das benötigte Zertifikat kann auch erlangt werden, indem man von einem bestehendem Account eingeladen wird. Nach der Eingabe des Einladungscodes und der erfolgreichen Registrierung für das Programm kann das Apple Developer Certificate angefordert wer-den. Dafür ist es vorab notwendig, ein Certificate Signing Request (CSR) zu generieren.

Generieren eines CSR

Das CSR ist eine Datei, welche mit Hilfe der Schlüsselbundverwaltung erzeugt wird. Dafür öffnet man diese und wählt in der Statusleiste den Punkt: Schlüsselbundverwal-tung > Zertifikatsassistent > Zertifikat einer Zertifizierungsinstanz anfordern. Dar-aufhin erscheint ein Dialogfeld, bei welchem der eigene Name und die E-Mail-Adresse einzutragen ist. Mit einem Klick auf weiter wird dann eine Datei erstellt, mit deren Hilfe im nächsten Schritt das Zertifikat beantragt wird.

78 Vgl. S.23-37 [Wagner 2011]


Abb.25: Generieren eines Certificate Signing Request

Abb.26: Das Provisioning Portal

Beantragen des Developer Program Certificate

Der nächste Schritt findet im Provisioning Portal von Apple statt. Nach der Anmeldung auf der Seite (http://developer.apple.com) klickt man in der oberen rechten Ecke auf iOS Provisioning Portal. Wenn noch kein Zertifikat vergeben wurde, so erscheint im un-teren Bereich des Bildschirms eine Aufforderung, eine Datei auszuwählen, um diese

594. UMSETZUNG

hochzuladen. Man wählt dafür die eben erstellte certSigningRequest-Datei aus und klickt daraufhin auf Choose. Auf der Certificate-Seite erscheint nun das eigene Zertifikat, welches nach der Übertragung des CSR von Apple erstellt wurde. Dieses muss heruntergeladen werden. Ein Doppelklick auf die Datei fügt das Zertifikat automatisch der Schlüsselbundverwaltung hinzu.

Für die spätere Verwendung mit Flash Professional CS5.5 ist es außerdem noch not-wendig, das Zertifikat ins p12-Format zu exportieren. Dies wird erreicht mit einem Rechtsklick auf den Eintrag in der Zertifikatübersicht und anschließendem Klick auf Exportieren.

Ein Gerät hinzufügen

Als registrierter und zertifizierter Apple Developer ist es zunächst notwendig, das Gerät, für welches man entwickeln möchte, in seinem Developer Account zu registrieren. Auch dies ist im Provisioning Portal machbar. Dafür wird links der Punkt Devices ausgewählt. Um ein Gerät hinzuzufügen, wird es als erstes an den Mac angeschlossen, woraufhin es in der iTunes-Übersicht erscheint. Dort wird ein Identifier angezeigt, die sogenannte „UDID“. Diese kopiert man. Zurück im Provisioning Portal klickt man auf Add Device. Im erscheinenden Dialogfeld wird die UDID des Geräts eingefügt und ein beliebiger Name dafür vergeben.

Erzeugen einer App ID

Das Erzeugen einer App ID ist der letzte notwendige Schritt, bevor ein Provisioning Pro-file heruntergeladen werden kann. Die App ID identifiziert eine App – jede verfügbare App hat eine eindeutige Identifikationsnummer. Im Provisioning Portal wird links auf den Punkt App IDs geklickt. Daraufhin kann ein Bezeichner für die zu entwickelnde Applikation gewählt werden. Mit einem Klick auf Submit erscheint eine Übersicht aller bisher selbst generierten App IDs.

Erzeugen des Provisioning Profiles

Nach dem erfolgreichem Erhalt des Apple Developer Certificate, der Registrierung eines Testgeräts und der Erstellung einer App ID kann das Provisioning Profile erzeugt wer-den. Dies ist der letzte und wichtigste Schritt, um eine eigene App entwickeln zu können. Denn auf jedem Testgerät, auf dem die spätere Anwendung installiert werden soll, muss zuvor ein solches Profil installiert werden. Es bindet quasi ein Developer Certificate an eine Anwendung und an ein Device.

Im Provisioning Portal klickt man links auf Provisioning. Das Dialogfeld zum Erstellen eines neuen Provisioning Profiles öffnet sich beim Klick auf New Profile. Als erstes wird dem Profil ein Name vergeben. Darunter erscheint der Name des Developer Certificates.


Mit der Checkbox daneben wird das Profil dem eigenen Zertifikat zugewiesen. Anschlie-ßend wird noch die App ID und das zuvor registrierte Testgerät ausgewählt. Mit einem Klick auf Submit wird das Provisioning Profile erstellt. Daraufhin muss das erzeugte Profil mit einem Klick auf Download auf den eigenen Rechner übertragen werden.

Zum Installieren des Provisioning Profiles auf einem Testgerät wird die heruntergeladene mobileprovision-Datei in das iTunes-Fenster hineingezogen. Mit dem Synchroni-sieren des Geräts mit iTunes wird auch automatisch das Provisioning Profile auf dem Gerät installiert.

Mergen von Flex- und AIR-SDK

Um mit FDT5 Flash-Anwendungen zu entwickeln, welche mit Hilfe des AIR-SDKs für die Installation auf einem iOS-Device verpackt werden sollen, muss das installierte Flex-SDK mit einem AIR-SDK verbunden („merged“) werden. Dazu wird zuerst das aktuelle AIR-SDK heruntergeladen.79 Öffnet man in FDT den Preferences-Dialog, kann man unter dem Punkt FDT > Installed SDKs einen Button Merge Air SDK finden. Das mittig ausgewählte SDK wird daraufhin sehr komfortabel automatisiert mit AIR verbunden.

Abb.27: Komfortables AIR-SDK-Merging mit FDT5

Schlussendlich sind damit alle notwendigen Schritte erfüllt, um eine App für ein regist-riertes Testgerät zu entwickeln.

79 siehe: http://www.adobe.com/special/products/air/sdk/

614. UMSETZUNG

4.1.2 Entwickeln für Flash 1180

Bevor die neuen Fähigkeiten des Flash Player 11 für Desktop Apps genutzt werden kön-nen, muss FDT dafür vorbereitet werden.

Download der erforderlichen Dateien

• Zum Debuggen muss der für Entwickler optimierte Flash Player Content Debug-ger in Version 11 heruntergeladen und installiert werden.

• Ein aktuelles Flex SDK muss installiert sein. (Mindestens Version 4.5.1)

• Es wird eine modifizierte playergoblal.swc-Bibliothek benötigt.

• Das FDT Molehill Project Template erleichtert den Einstieg in die Stage3D-Ent-wicklung. Diese Dateien findet man unter [Powerflasher 2011] und dem beilie-genden Datenträger.

Patchen des SDKs

Das heruntergeladene Flex SDK wird entpackt und in einem beliebigen Ordner gespei-chert. Daraufhin wird es mit der heruntergeladenen playerglobal.swc gepatcht. Diese Datei beinhaltet notwendige Verweise auf die ActionScript APIs. Um für die neu-este Version des Flash Players entwickeln zu können ist ein manuelles Austauschen dieser Datei notwenig. Dafür wird im Ordner /frameworks/libs/player/10.2 des entpackten SDKs einfach die Datei playerglobal.swc durch die gleichnamige heruntergelade-ne Bibliothek ersetzt.

In FDT muss anschließend noch das neue SDK hinzugefügt werden, dies geschieht un-ter dem Punkt Preferences > FDT > Installed SDKs > Add. Hierbei sollte ein sinn-voller Name vergeben werden, um das gepatchte SDK später von anderen unterscheiden zu können.

Installation des Projekttemplates

Im letzten Schritt wird noch das Projekttemplate in die FDT Entwicklungsumgebung eingefügt. Die beiden im Archiv enthaltenen Ordner werden einfach zu den bereits mit-gelieferten Templates hinzugefügt. Diese befinden sich in dem Ordner /Users/{userna-me}/Library/Application Support/FDT

80 Vgl. [Powerflasher 2011]


Wurden alle Schritte korrekt ausgeführt, kann beim nächsten Start von FDT ein Mole-hill-Projekt angelegt werden, welches von den Fähigkeiten der Stage3D Gebrauch macht.

4.2 Anlegen der einzelnen Projekte

In der Entwicklungsumgebung FDT werden drei Projekte angelegt:

• Das Basis-Projekt (DiplomBase)• Das Mobile-Projekt (DiplomMobile) • Das Desktop-Projekt (DiplomDesktop)

Im Folgenden soll erläutert werden, was bei den einzelnen Projekten im Besonderen zu beachten ist.

4.2.1 Das Projekt DiplomBase

DiplomBase ist das Basisprojekt für die geplante Multiscreen-Anwendung. Da es später nicht alleinstehend kompiliert werden soll, ist auch beim Anlegen des Projekts nicht viel zu beachten.

In FDT wird unter File > New > New FDT Project das bereits vorausgewählte AS3-Template benutzt. Dadurch wird ein normales ActionScript Projekt erstellt. Die generier-ten Packages und Klassendateien können gelöscht werden, da eine eigene Struktur erstellt wird. Auch auf die Compiler-Settings muss nicht geachtet werden. Schließlich ist dieses Projekt die Basis für die einzelnen Prototypen und wird selbst nie kompiliert.

Abb.28: Ein Pure AS3 Projekt als Basis anlegen.

634. UMSETZUNG

4.2.2 Das Projekt DiplomMobile

DiplomMobile ist das iPad-Projekt. Auch hierfür wird mit FDT ein neues Projekt erstellt. Dabei wird ein Template ausgewählt, durch welches FDT die Erstellung von Projekten für mobile Zielplattformen deutlich vereinfacht, nämlich Mobile > AS3.

Abb.29: Ein Mobile Projekt erstellen

In diesem Dialog muss das Projekt benannt werden. Auch können hierbei bereits die wichtigsten Parameter angegeben werden:

• Die Application ID muss einer im Apple Developer Provisioning Portal einge-richteten AppID entsprechen.

• Die Target Platform kann Android oder iOS sein. Da der Prototyp auf dem iPad laufen soll, ist iOS hierbei die richtige Wahl.


Auswahl des Merged-AIR-SDK

Um das Projekt DiplomMobile korrekt für das iPad verpacken zu können, muss das zuvor verbundene AIR-SDK ausgewählt werden. Dafür wird auf das neu erstellte Projekt mit einem Rechtsklick der Punkt Flash Project > Change SDK ausgewählt. Der dar-aufhin erscheinende Dialog zeigt eine Übersicht der installierten Flex-SDKs. Auszuwäh-len ist das zuvor mit Hilfe von FDT generierte Merged-AIR-SDK.

Abb.30: Auswählen des Merged-AIR-SDK

Projektkonfiguration

Nach dem Erstellen des Projekts befindet sich im bin-Ordner eine xml-Datei, welche wichtige Informationen zum Projekt beinhaltet. Diese Datei ist unentbehrlich, um die App später korrekt kompilieren zu können. Neben der bei der Erzeugung des Projekts eingestellten AppID sind unter anderem auch Layout-Informationen darin enthalten:

Listing 4: DiplomMobile-app.xml (Zeile 75-80)

<aspectRatio>portrait</aspectRatio> <fullScreen>false</fullScreen> <autoOrients>true</autoOrients> <renderMode>direct</renderMode> <visible>true</visible> <depthAndStencil>true</depthAndStencil>

Hier kann z.B. das initiale Seitenverhältnis der Anwendung kontrolliert werden. Auch kann definiert werden, ob die Anwendung im Vollbildmodus starten soll. autoOrients gibt Auskunft darüber, ob sich der Inhalt mit der Drehung des Geräts neuorientieren soll. Die bedeutendste Einstellung ist für das iPad-Projekt jedoch der renderMode. Da Stage3D benutzt wird, um dreidimensionale Inhalte anzuzeigen, ist es notwendig, den renderMode auf direct zu stellen. So wird sichergestellt, dass zum Rendern auch tat-sächlich die Grafikhardware des Geräts genutzt wird. Sollte an dieser Stelle eine andere Eigenschaft übergeben werden, kann das Projekt nicht kompiliert werden.

654. UMSETZUNG

Listing 5: DiplomMobile-app.xml (Zeile 182-186)

<InfoAdditions><![CDATA[<key>UIDeviceFamily</key> <array> <string>2</string> </array>]]></InfoAdditions> <requestedDisplayResolution>high</requestedDisplayResolution>

In dieser xml-Datei kann auch definiert werden, welche Geräte bedient werden. Der Eintrag <string>2</string> unter UIDeviceFamily legt fest, dass es sich beim Zielgerät um ein iPad handelt. Mit dem Tag requestedDisplayResolution kann durch das Eintragen von high weiterhin beschränkt werden, dass die Applikation nur auf einem iPad2 lauffähig sein wird. Dies stellt zwar sicher, dass auf die höhere Grafik-leistung des iPads2 zurückgegriffen werden kann, grenzt auf der anderen Seite jedoch die iPad-Nutzer erster Generation für die Anwendung aus. Für agenturinterne Demonstrati-onszwecke ist dieser Schritt ohne Konsequenzen, da direkt für das iPad2 entwickelt wird.

Bevor das Projekt kompiliert werden kann, ist es außerdem notwendig, weitere Einstel-lungen für den Debug-Vorgang zu tätigen. Dafür wird auf das Projekt in FDT rechts geklickt, und dann Debug As > Debug Configurations ausgewählt. In dem sich öff-nenden Dialog muss auf den Punkt Configure project properties geklickt werden. Daraufhin öffnet sich ein weiterer Dialog, in dem unter Digital Signature das im Vorfeld erstellte Provisioning Profile aktiviert werden muss.

Abb.31: Aktivieren des Provisioning Profiles


Nun kann das Projekt kompiliert werden. Hierfür wird mit einem Rechtsklick auf das Projekt der Punkt Debug As > FDT Mobile Application ausgewählt, woraufhin der Kompiliervorgang startet. Der Packager verpackt danach die kompilierte SWF in eine ipa-Datei. Um die Anwendung anschließend testen zu können, muss das registrierte Testgerät mit dem Computer verbunden sein. Zum Ausführen der App auf dem iPad muss die ipa-Datei durch einen Doppelklick der iTunes-Bibliothek hinzugefügt werden und kann anschließend via Drag and Drop auf das Testgerät gezogen werden.

Zum Testen der Applikation kann diese auch auf dem Computer emuliert werden. Hier-für wird im Debug Configuration-Dialog unter dem Punkt Launch Method der Ra-dioButton On desktop ausgewählt. Dies bringt die Einschränkung mit sich, dass gerä-tespezifische Interaktionen nicht durchgeführt werden sollen.

4.2.3 Das Projekt DiplomDesktop

Auch für die Desktop Web App wird ein neues Projekt angelegt. Das im Vorfeld ins-tallierte Molehill Project Template bietet dem Entwickler die Möglichkeit, schnell und komfortabel ein funktionsfähiges Stage3D-Projekt anzulegen. Alle Konfigurationen, die manuell getätigt werden müssten, erledigt dieses Template automatisch.

Zu beachten ist, dass Stage3D-Projekte auf dem Desktop nur im Browser getestet werden können. Eine entsprechende html-Datei wird ebenfalls vom Mobile Project Template angelegt.

Abb.32: Anlegen eines Stage3D-/Molehill-Projekts

674. UMSETZUNG

4.2.4 Verbinden der Screen-Apps mit der Basisapplikation

Nachdem nun die drei Projekte angelegt wurden, müssen das Mobile- und Desktop-Projekt noch eine Verbindung zum Basisprojekt herstellen. Nach einem Rechtsklick auf das Mobile-Projekt wird der Punkt Properties ausgewählt. Im erscheinenden Dialog wird links Project References angeklickt. Es wird eine Auflistung aller vorhanden Projekte aufgeführt. Mit einem Haken kann festgelegt werden, welches dieser Projekte referenziert werden soll. Hierbei wird das Basisprojekt DiplomBase ausgewählt. In der Übersicht links wird nun angezeigt, dass die Projekte miteinander verbunden sind, und man hat aus dem Mobile-Projekt ebenfalls Zugriff auf alle Klassen und Bibliotheken des Basisprojekts.

Abb.33: Das referenzierte Basisprojekt

4.3 Implementierung

Bei der Erläuterung der Implementierung der Prototypen wird auf deren wichtigste Komponenten Bezug genommen. Für die Entwicklung einzelner Teile wurden unter-schiedliche Konzeptmuster und programmiertechnische Ansätze verfolgt, welche bei der Umsetzung eines Multiscreen-Projekts gemischt vorkommen können. Nachfolgend wird die Umsetzung der folgenden Kernprobleme beleuchtet:

• Globale Models und Konstanten

• Views und Mediatoren

• Globale Verwaltung screen-spezifischer Asset-Bibliotheken

• Zentrale XML-basierte Sprachverwaltung

• Interaktive dreidimensionale Benutzerschnittstellen

• Umfärben des 3D-Objekts

Wenn eine differenzierte Betrachtung von Desktop- und Mobile-Projekt möglich ist, wird das Mobile-Projekt immer zuerst beschrieben, da bei der Umsetzung das Konzept-muster Mobile First angewandt wurde und die Desktop Web App erst nach der Fertig-stellung der iPad-App entwickelt wurde.


4.3.1 Globale Models und Konstanten

Während der Konzeptionsphase wurde festgelegt, dass die Prototypen ein einheitliches Erscheinungsbild haben sollen (Multiscreen Muster: Coherence). Dies dient vor allem der Wiedererkennbarkeit der App auf unterschiedlichen Screens, also dem Konzeptmuster „Fluidity“. Da an verschiedenen Stellen im Programm unterschiedliche Farben genutzt werden sollen, welche im Vorfeld jedoch noch nicht starr festgelegt wurden, ist es sinn-voll, eine Klasse zur Farbverwaltung zu schreiben. Diese beinhaltet eindeutig bezeichnete Konstanten. Um diese Farbkonstanten in allen Screen Apps nutzen zu können, muss die Klasse in der Basis der Anwendung angelegt werden.

Listing 6: Colors.as (Base)

public class Colors { public static const BLACK : uint = 0x000000; public static const GREY_DARK : uint = 0x58585A; public static const GREY_BRIGHT : uint = 0xDADADA; public static const GREY_LIGHT : uint = 0xEAEAEA; public static const WHITE : uint = 0xFFFFFF; public static const GREEN : uint = 0x8AAE53; public static const GREEN_PALE : uint = 0xD4E3BD; public static const BLUE : uint = 0x3EB0AF; public static const BLUE_PALE : uint = 0xCFE9E9;}

Alle später in den Prototypen zu verwendenden Farben sind nun definiert. An jeder Stel-le, an der später auf einen Farbwert zugegriffen werden soll, geschieht dies durch einen Zugriff auf eine öffentliche statische Konstante dieser Klasse. Soll im Nachhinein global zum Beispiel der Grünton aller Applikationen einheitlich geändert werden, so geschieht dies nur an einer einzigen Stelle im Programmcode, was die Pflegbarkeit der Anwendung um ein Vielfaches erleichtert.

Models

Das MVC-Pattern sieht vor, dass alle darzustellenden Daten in einem Model gespeichert werden. Das Model selbst enthält im besten Fall keine Geschäftslogik, sondern wird nach dem Beobachter-Entwurfsmuster überwacht. Es steht unabhängig von Views und Cont-rollern. Dies bedeutet, dass notwendige Models in der Basis der Multiscreen-Anwendung angelegt werden. So sind diese später in jeder einzelnen Screen App verfügbar.

Ein solches Model beinhaltet zum Beispiel die Farben, welche das 3D-Schuhmodell spä-ter annehmen können soll. Diese werden für einen vereinfachten Zugriff in einem Array gespeichert. Um dieses Model während der Entwicklungsphase variabel zu halten, wer-den hier die Farbkonstanten aus der zuvor entwickelten Colors-Klasse benutzt. Eine Änderung der Farbwerte in dieser Klasse ändert also automatisch auch das Model.

694. UMSETZUNG

Listing 7: PaintModel.as (Base)

public class PaintModel extends Actor { private var _colors : Array = [Colors.GREEN, Colors.GREEN_PALE, Colors.BLUE, Colors.BLUE_PALE];

public function get colors() : Array { return _colors; }}

Das Model PaintModel erweitert die Klasse Actor des Robotlegs-Frameworks. Ak-teure können alle Klassen sein, die in irgendeiner Art und Weise zur Injektion geeignet scheinen.

In der Basis wird festgelegt, dass die Klasse PaintModel als Singleton auftreten soll. Dies bedeutet, dass beim Ausführen der Anwendung genau ein Objekt vom Typ PaintModel erstellt wird, welches – wann immer ein Objekt dieses Typs in einer beliebigen Klasse be-nötigt wird – in diese Klasse injiziert wird.

Listing 8: Festlegen einer Regel zur Injektion

injector.mapSingleton(PaintModel);

Nach dem Mapping des PainModels als Singleton kann dieses später wie folgt verwen-det werden:

Listing 9: Injizieren des Models

[Inject]public var paintModel:PaintModel;

//späterer Zugriff auf Farben aus dem Modell:var temporary_colors:Array = paintModel.colors;

Die injizierte Variable paintModel kann nun aufgrund der zuvor festgelegten Regel ohne Initialisierung verwendet werden.

Was wurde erreicht?

Models und Konstanten halten Anwendungen übersichtlich und leicht editierbar. Au-ßerdem sind diese Klassen in jeder Screen App wiederverwendbar. Durch die feste De-finition bestimmter Eigenschaften erfüllt eine Anwendungen die Anforderungen des Konzeptmusters „Fluidity“, da sie auf jedem Screen gleiche Eigenschaften benutzt. Un-terschiedliche Apps erhalten dadurch ein gleichartiges Auftreten.


4.3.2 Views und Mediatoren

Views sind die vielseitig gestaltbaren, animierten, interaktiven Komponenten, welche In-ternetanwendungen reichhaltig machen. Sie sind die Oberfläche, die visuelle Repräsenta-tion einer Anwendung, mit welcher der Nutzer interagiert. Unabhängig davon, wie eine View entwickelt wird, ist es notwendig, dass diese fähig ist, mit anderen Views und den Models der Hauptanwendung kommunizieren zu können.

Mediatoren sind leichtgewichtige Klassen, welche die Views mit dem Rest der Logik ei-ner Anwendung verbinden. Man kann sie als kleine Schaltzentralen betrachten, welche auf wichtige Events hören, und beim Eintreten eines solchen die View entsprechend an-passen. Außerdem stoßen sie Änderungen im Modell einer Applikation an, welche durch Nutzerinteraktionen in einer View zustande kommen.81

Abb.34: Mediatoren als Brücken zwischen View und Model/Anwendungslogik

Damit ein bestimmter Mediator als Brücke zwischen einer View und dem Rest der An-wendung fungieren kann, müssen View und Mediator miteinander verbunden werden. Man spricht hierbei davon, dass ein Mediator auf eine View „gemappt“ wird. Das be-deutet, dass an einer zentralen Stelle im Code definiert wird, welcher Mediator einer bestimmten View hinzuzuordnen ist.

Ein abstraktes View-Mediator-Paar

Für jeden zu bedienenden Screen wird eine eigene View entwickelt, in welcher das Aussehen der App für diesen Screen festgelegt wird. Unabhängig des Screens muss jede View über bestimmte Eigenschaften und Funktionen verfügen. Dazu gehört zum Beispiel das Laden und Anzeigen von Elementen aus einer Grafik-Bibliothek, sowie die Unterstützung externer Sprachdateien. Es ist daher sinnvoll, ein abstraktes View-Mediator-Paar zu schaffen, von welchem die Views und Mediatoren der einzelnen Screen Apps nachfolgend ihre Funktionalität erben. Im Basis-Projekt wird eine Klasse AbstractMultiscreenView (erbt von Sprite) und der dazu passende Mediator AbstractMultiscreenViewMediator (erbt von Mediator) angelegt. Durch die Vererbung deren Methoden wird ermöglicht, dass unterschiedliche Views die gleiche Funktionalität nutzen können, welche allerdings nur einmal programmiert werden muss.

81 Vgl. S.59f [HooksFallow 2011]

Mediator View

714. UMSETZUNG

Das Mapping, also das Zuordnen eines Mediators zu einer View, geschieht in der mediatorMap. Dies ist eine durch Robotlegs definierte Eigenschaft im Startpunkt der Anwendung, dem sogenannten „Context“.

Listing 10: Mappen von View und Mediator

mediatorMap.mapView(AbstractMultiscreenView,AbstractMultiscreenViewMediator);

Das definierte Mapping wird von Robotlegs nun folgendermaßen behandelt: wann im-mer eine View, in diesem Fall ein Objekt vom Typ AbstractMultiscreenView der Anzeigeliste hinzugefügt wird, so wird automatisch auch ein Mediator vom Typ AbstractMultiscreenViewMediator generiert.

Kommunikation zwischen Mediator und View

Da eine direkte Abhängigkeit zwischen View und Mediator verhindert werden sollte, erfolgt die Kommunikation zwischen dem erzeugten View-Mediator-Paar durch Depen-dency Injection. Das zuvor durchgeführte Mapping legt die Regel zur Injektion fest. In den AbstractMulsitscreenViewMediator wird dadurch eine View vom Typ MultiscreenView injiziert und kann in dieser wie eine normale Variable verwendet werden. Über diese ist es letztendlich auch möglich, bestimmte Funktionen der View aufzurufen.

Abb.35: Robotlegs Injection82

82 Abbildung nachempfunden, Quelle: S.28, Abb. 4-2 [HooksFallow 2011]

SomeClass

[Inject]public var thingNeeded:SomeType

Injection Pointin the class

Injector Rule for creating„SomeType“

Injection Point + Injection Rule = Robotlegs Injection


MobileView und MobileViewMediator

Der Vorteil bei der Verwendung von Mediatoren ist die verstärkte Entkopplung von An-zeigeelementen und dem Rest der Anwendung. Ein hierfür prädestiniertes Beispiel findet sich auch in der Mobile App.

Eine Besonderheit in der mobilen Repräsentation ist, dass diese auf Orientierungsände-rungen des Zielgeräts reagieren muss. Wie bereits erwähnt hat das iPad zwei fest definier-te Ansichtsvarianten: den Portrait-und den Landscape-Modus. Es ist notwendig, dass die MobileView in der Lage ist, sich nach einer Orientierungsänderung neu zu arrangieren. Hierfür werden in der View zwei öffentliche Methoden bereitgestellt:

Listing 11: MobileView.as (Zeile 50-66)

public function arrangeLandscape() : void { _infoBox.hideBackground(); _infoBox.y = 0; _colorBar.y = stage.stageHeight - 50; _colorBar.arrange(stage.stageWidth); _shoe.setViewportSizeTo(stage.stageWidth, stage.stageHeight - 50); _logo.x=stage.stageWidth-_logo.width-25;}

public function arrangePortrait() : void { _infoBox.showBackground(); _infoBox.y = stage.stageHeight - 300; _colorBar.y = stage.stageHeight - 350; _colorBar.arrange(stage.stageWidth); _shoe.setViewportSizeTo(stage.stageWidth, stage.stageHeight - 300); _logo.x=stage.stageWidth-_logo.width-25;}

Um die Wiederverwendbarkeit dieser View möglichst hoch zu halten, sollte keine Ab-hängigkeit zum Rest der Anwendung bestehen. Im Idealfall sollte es den Entwicklern ermöglicht werden, dass Views einfach ausgetauscht werden könnten.

Nun bietet die MobileView zwar die Funktionalität zum Arrangieren des Bildschirms an, weiß aber nicht, wann diese auszuführen ist. Da angestrebt wird, die Klassen mög-lichst lose zu koppeln und keine direkten Abhängigkeiten zu anderen Teilen der Anwen-dung zu schaffen, sollte die MobileView nicht selbst auf Events hören. Hierfür gibt es den MobileViewMediator als Brücke zur Anwendungslogik. In diesem wird nun unter anderem auf das spezielle Event gehört, welches eintritt, sobald das Gerät rotiert wird. Anschließend wird in der dem Mediator zugeordneten View (Variable view) die Funktionalität zum Arrangieren der Ansicht aufgerufen. Der Mediator selbst beinhaltet dabei nur so viel Logik wie notwendig.

734. UMSETZUNG

Listing 12: MobileViewMediator.as

public class MobileViewMediator extends AbstractMultiscreenViewMediator { public var view : MobileView;

public function MobileViewMediator() { super(); }

override public function onRegister() : void { super.onRegister(); view = MobileView(multiscreenView); view.init(); eventMap.mapListener(view.stage, StageOrientationEvent.ORIENTATION_CHANGE, _onChangeOrientation); }

private function _onChangeOrientation(event : StageOrientationEvent = null) : void { switch(event.afterOrientation) { case (StageOrientation.ROTATED_LEFT): view.arrangeLandscape(); break; case (StageOrientation.ROTATED_RIGHT): view.arrangeLandscape(); break; case (StageOrientation.DEFAULT): view.arrangePortrait(); break; case (StageOrientation.UPSIDE_DOWN): view.arrangePortrait(); break; } }}

Die Funktion onRegister wird genau dann aufgerufen, wenn die dem Mediator zuge-hörige View erstellt wird. An dieser Stelle geschieht das Mapping der Events. In diesem Fall wird auf das Event StageOrientationEvent.ORIENTATION_CHANGE ge-hört. Tritt das Ereignis auf, so wird die Funktion _onChangeOrientation aufge-rufen. Dort wird zwischen den möglichen Orientierungen des iPads unterschieden und die jeweils passende Funktionalität in der View aufgerufen. Die View hat dabei keinerlei Abhängigkeiten von der Geschäftslogik der Applikation.


DesktopView und DesktopViewMediator

Während für die iPad-App zwei vordefinierte Layouts implementiert wurden, muss sich die Desktop-App responsiv verhalten und auf Größenänderungen des Browserfensters reagieren. Die Funktionalität hierfür wird in der Klasse DesktopView bereitgestellt:

Listing 13: DesktopView.as (Zeile 41-45)

public function updateSize() : void { _shoe.setViewportSizeTo(stage.stageWidth, stage.stageHeight); _colorPicker.y = _colorPicker.x = 150; _logo.x=stage.stageWidth-_logo.width-25;}

Auch bei der DesktopView gilt der Grundsatz, dass diese so lose wie möglich zu kop-peln ist. Daher wird die Verknüpfung zur Anwendungslogik in der onRegister-Funk-tion der Klasse DesktopViewMediator hergestellt.

Listing 14: DesktopViewMediator.as (Zeile 15-24)

override public function onRegister() : void { super.onRegister(); view = DesktopView(multiscreenView); view.init(); eventMap.mapListener(view.stage, Event.RESIZE, _onStageSizeChange);}

private function _onStageSizeChange(event:Event) : void { view.updateSize();}

Die aufgeführte Implementierung ist sehr ähnlich zu der aus der iPad-App. Auch hier wird im Mediator auf ein Ereignis gehört und als Reaktion darauf eine Methode der in-jizierten View aufgerufen.

Was wurde erreicht?

Mediatoren verknüpfen Views mit dem Rest der Anwendung, beinhalten selbst allerdings kaum Logik. Erst beim Eintreten eines erwarteten Ereignisses wird eine Methode in der verbundenen View aufgerufen. Diese wiederrum hat keine Abhängigkeiten zum Model und der allgemeinen Anwendungslogik. Die View stellt ausschließlich Methoden bereit, welche ihr Aussehen beeinflussen. Dank der Mediatoren bleiben die Views austauschbar und wiederverwendbar. Die Applikationen bleiben im Sinne der technischen Herange-hensweise entkoppelt und es entstehen keinerlei Abhängigkeiten.

754. UMSETZUNG

4.3.3 Globale Verwaltung screen-spezifischer Asset-Bibliotheken

Bei den Assets einer Anwendung handelt es sich um eine Sammlung multimedialer Ele-mente, welche in der Applikation verwenden werden. Zu einer entkoppelten Entwicklung gehört es, jedem Screen nur genau die Elemente zur Verfügung zu stellen, die auch wirk-lich benötigt werden. Es gibt daher keine globale Asset-Bibliothek, die für alle Screens gleichermaßen benutzt wird, sondern jeweils eigens auf den Screen zugeschnittene As-sets. Die Mechanik, welche zur Bereitstellung einzelner Elemente dieser Bibliothek dient, sollte jedoch unabhängig des Ziel-Screens funktionieren und global definiert werden.

Screen-spezifische Asset-Bibliotheken

Für die zentrale Verwaltung der Assets existiert in jedem Screen-Projekt eine Klasse, in welcher die benötigten Dateien als Konstanten eingebettet werden. Da eine solche Klasse keine Funktionalität beinhaltet sondern ausschließlich Verweise auf eingebettete Assets bereitstellt, spricht man dabei von sogenannten „Asset Providern“.

Listing 15: AssetProviderMobile.as

public class AssetProviderMobile { [Embed(source=“../assets/logo_mobile.png“)] public static const LOGO : Class; }

Mit Hilfe des Embed-Schlüsselwortes wird die Grafik hinter dem angegebenem Pfad schon beim Kompiliervorgang in die swf-Datei eingebettet. Es können neben Grafi-ken unterschiedlichste Dateitypen verwendet werden, wie zum Beispiel auch Filme oder Sounds. Bei einer späteren Auslieferung der Daten ist es nicht notwendig, die verwen-deten Dateien mitzuliefern. Sie müssen nur beim Kompilieren unter dem angegebenem Pfad vorhanden sein.

Assetverwaltung in der View

Jede einzelne View soll nun in der Lage sein, auf die Asset-Bibliothek zugreifen zu können. Da die Konstanten im Asset Provider als Klassen (vom Typ Class) deklariert wurden, besteht die Notwendigkeit, Funktionen zu schaffen, welche aus der übergebenen Klasse ein Objekt des zu verwendenden Typs kreieren. Diese Funktionen werden global für alle später zu entwickelnden Views in der Klasse AbstractMultiscreenView definiert. Das nachfolgende Beispiel zeigt auf, wie mit der Funktion getAsSprite() aus einer übergebenen Klasse aus dem Asset Provider eine Grafik (vom Typ Sprite) generiert wird.


Listing 16: AbstractMultiscreenView.as (Zeile 26-31)

public function getAsSprite(value : Class) : Sprite { var bmp : Bitmap = new value(); var spr : Sprite = new Sprite(); spr.addChild(bmp); return spr;}

Diese Funktion kann nun in jeder beliebigen View verwendet werden, um grafische As-sets zu generieren. Übergeben wird dabei eine Konstante aus dem Asset Provider:

Listing 17: MobileView.as (Zeile 42-45)

_logo = getAsSprite(AssetProviderMobile.LOGO);_logo.y = 25;_logo.x = stage.stageWidth-_logo.width-25;addChild(_logo);

Was wurde erreicht?

Ein durch diesen programmiertechnischen Ansatz entstandener Vorteil wird bereits di-rekt während der Entwicklung ersichtlich. Die im Asset Provider deklarierten Klassen tauchen bei der Benutzung dieses Providers in FDT in einem Dropdown-Menü auf. So behält man jederzeit den Überblick über die verfügbaren Assets und kann schnell darauf zugreifen.

Abb.36: Erleichterte Entwicklung durch automatische Codevervollständigung

Die über alle Views hinweg gleichbleibende Mechanik der Assetverwaltung ist in höchs-tem Maße wiederverwendbar und erweiterbar. Durch die screen-spezifischen Asset Pro-vider wird mit geringem Aufwand ermöglicht, jeden Screen mit eigenen Assets zu versor-gen. Dies ist eine ressourcenschonende Herangehensweise, welche dafür sorgt, dass die Anwendung so schlank wie möglich bleibt. Denn in jeder App stecken zum Schluss nur die Dateien, die auch wirklich benötigt werden. Durch diese entkoppelte Verwaltung der Assets wird das Kontextrelevanz-Konzeptmuster erfüllt.

774. UMSETZUNG

4.3.4 Zentrale XML-basierte Sprachverwaltung

Das zentrale Verwalten aller Texte, die in einer Applikation verwendet werden, hat meh-rere Vorteile. Zum einen können nachträgliche Textänderungen unkompliziert vorge-nommen werden, wenn alle Texte an einer bekannten Stelle definiert werden, anstatt sie über die einzelnen Views und Komponenten einer Anwendung zu verteilen. Zum anderen kann durch einen solchen Ansatz die Mehrsprachigkeit einer Anwendung er-möglicht werden. Sind alle Texte in einer xml-Datei abgelegt, kann diese übersetzt und anschließend einfach ausgetauscht werden. Das Einpflegen einer neuen Sprache ist somit ohne Änderungen im Quellcode machbar.

Zugriff auf Sprach-Properties innerhalb von Views

Da Texte hauptsächlich in Views verwendet werden, wird der Zugriff auf die extern geladenen xml-Dateien bereits in der AbstractMultiscreenView, bzw. dem AbstractMultiscreenViewMediator definiert.

Listing 18: AbstractMultiscreenView.as (Zeile 33-41)

public function getProperty(id : String) : String { var returnString:String = „{„+id+“}“; for (var i:uint = 0; i<_properties.property.length();i++){ if (_properties.property[i].@id==id){ returnString = _properties.property[i]; } } return returnString;}

Jede AbstractMultiscreenView, und damit jede Klasse, die von dieser erbt, besitzt eine Variable _properties vom Typ XML. In dieser XML sind alle vorhandenen Texte gespeichert. Um nun auf einen bestimmten Text zugreifen zu können, gibt es die Metho-de getProperty(). Dieser wird die id, also ein eindeutiger Bezeichner des darzustel-lenden Texts aus der XML übergeben. Wird die id in der _properties-XML aufge-funden, so gibt die Funktion einen String mit dem entsprechendem Text zurück. Ist die id nicht vorhanden, wird die angefragte id in geschweiften Klammern zurückgegeben. Daran erkennt der Entwickler beim Debuggen, dass entweder eine falsche id übergeben wurde, oder dass eine angegebene id noch nicht in der XML enthalten ist.

Um die Kopplung der einzelnen Klassen so lose wie möglich zu halten, muss erreicht werden, dass jede einzelne View die notwendigen Sprach-Properties erhält, ohne je-doch von einer bestimmten XML oder einem Model abhängig zu sein. Dafür sorgt der AbstractMultiscreenViewMediator. Dieser dient als Kommunikationsglied zwischen Model und View und weist einer beliebigen View die geladene xml-Datei zu.


Listing 19: AbstractMultiscreenViewMediator.as

public class AbstractMultiscreenViewMediator extends Mediator { [Inject] public var language : AbstractXMLParser; [Inject] public var multiscreenView : AbstractMultiscreenView;

public function AbstractMultiscreenViewMediator() { super(); }

override public function onRegister() : void { multiscreenView.properties = language.xml; }}

In den AbstractMultiscreenViewMediator werden zwei Eigenschaften injiziert. Zum einen eine Variable language vom Typ AbstractXMLParser, zum anderen eine Variable multiscreenView vom Typ AbstractMultiscreenView.

Die letztere Variable ist verfügbar, da die AbstractMultiscreenView auf die-sen Mediator gemappt wurde (siehe Listing 10). Um auch auf die language-Variable zugreifen zu können, muss hierfür noch eine Regel erstellt werden. Dies geschieht an der gleichen Stelle, an der auch die Mediatoren gemappt werden, hier am Beispiel des Mobile-Projekts:

Listing 20: DiplomMobileContext.as (Zeile 28-40)

override public function startup() : void { super.startup();

_xmlParser = new MobileXMLParser();

injector.mapValue(AbstractXMLParser, _xmlParser); mediatorMap.mapView(ColorBar, ColorBarMediator); mediatorMap.mapView(ColorBox, ColorBoxMediator); mediatorMap.mapView(MobileView, MobileViewMediator, AbstractMultiscreenView); mediatorMap.mapView(Away3DContainerMobile, Away3DContainerMediator, Away3DContainer); contextView.addChild(new MobileView());}

794. UMSETZUNG

Der Context einer Robotlegs-Anwendung ist das Herz der Applikati-on. Hier geschieht das Mapping, und hier wird auch die View zur Anzeige-liste hinzugefügt. Im DiplomMobileContext wird dafür gesorgt, dass im AbstractMultiscreenViewMediator ein AbstractXMLParser vorhanden ist. Zuerst wird genau ein Objekt vom Typ MobileXMLParser angelegt. Die darauf folgende Zeile (injector.mapValue(AbstractXMLParser, _xmlParser);) sorgt dafür, dass, wann immer ein Objekt vom Typ AbstractXMLParser angefordert wird, die erstellte Variable _xmlParser injiziert wird.

Somit kann nun auch die Variable language (siehe Listing 19) verwendet werden, da diese dank des vorangegangenen Mappings automatisch das Objekt _xmlParser enthält.

In der onRegister() Funktion (siehe Listing 19) wird schließlich den properties der injizierten View die ebenfalls injizierte XML zugewiesen.

Die Benutzung der getProperty()-Funktion (siehe Listing 18) ist damit ein Leichtes und funktioniert wie folgt:

Listing 21: Nutzung von getProperty()

var tf : TextField = new TextField();tf.text = getProperty(„headline“);

Die übergebene id („headline“) stammt aus einer extern gelagerten xml-Datei:

Listing 22: de.xml (Base)

<?xml version=“1.0“ encoding=“UTF-8“?> <base> <property id=“headline“> <![CDATA[LOREM IPSUM]]> </property> <property id=“subline“> <![CDATA[dolor sit amet.]]> </property> </base>

Ein abstraktes View-Mediator-Paar kümmert sich in der Basis nun also um die Verknüp-fung von geladener Sprachdatei und View. Die Screen Apps müssen sich darum nicht mehr kümmern, da deren Views und Mediatoren die Funktionalität von den abstrakten Klassen der Basis erben. Einzig der Vorgang des Ladens der xml-Datei unterscheidet sich von Screen zu Screen, weswegen diese Mechanik auch nicht in der Basis umgesetzt werden kann, sondern für jeden Screen im Speziellen zu implementieren ist.


MobileXMLParser

Für die Nutzung von xml-Dateien in Mobile Apps auf dem iPad ist es grundsätzlich notwendig zu wissen, dass dies anders funktioniert, als bei einer Web App. Denn es ist nicht ohne weiteres möglich, Dateien in eine Anwendung hineinzuladen, um sie anschlie-ßend zu parsen. Um lokale xml-Dateien überhaupt verwenden zu können ist es notwen-dig, diese zusammen mit der Applikation zu verpacken. Im FDT geschieht dies über ei-nen Rechtsklick auf das Mobile-Projekt und anschließendem Auswählen von Debug As > Debug Configurations. Im sich öffnendem Dialog wird unten Configure project properties ausgewählt und danach auf den Reiter Package Contents geklickt. Der Liste wird nun die zu benutzende xml-Datei hinzugefügt.

Abb.37: Package Contents Dialog

Die xml-Datei ist nun für das Projekt verfügbar und kann nachfolgend vom File-System des Geräts geladen werden. Dies geschieht in der dafür vorgesehenen Klasse MobileXMLParser:

Listing 23: MobileXMLParser.as

public class MobileXMLParser extends AbstractXMLParser implements IXMLFeedable { private var _xmlFile : File; private var _fileStream : FileStream;

public function MobileXMLParser() { loadXML(); } public function loadXML() : void { _xmlFile = File.applicationDirectory; _fileStream = new FileStream();

814. UMSETZUNG

_fileStream.open(_xmlFile.resolvePath(„de.xml“), FileMode.READ); xml = XML(_fileStream.readUTFBytes(_fileStream.bytesAvailable)); }}

Das Interface IXMLFeedable definiert die Methode loadXML(). Jeder Parser muss diese Methode dadurch zwangsläufig implementieren.

Nach dem Laden des _xmlFiles aus dem lokalen File-System wird der Inhalt der XML in die durch die Klasse AbstractXMLParser definierte Variable xml geschrieben.

DesktopXMLParser

Der DesktopXMLParser lädt die xml-Datei vom einem beliebigen relativen Pfad und implementiert dabei ebenfalls das Interface IXMLFeedable.

Listing 24: DesktopXMLParser.as

public class DesktopXMLParser extends AbstractXMLParser implements IXMLFeedable { private var _urlLoader : URLLoader;

public function DesktopXMLParser() { }

public function loadXML() : void { _urlLoader = new URLLoader(); _urlLoader.addEventListener(Event.COMPLETE, _onXMLLoaded); _urlLoader.load(new URLRequest(„../../DiplomBase/bin/language/de.xml“)); }

private function _onXMLLoaded(event : Event) : void { xml = XML(event.target.data); dispatchEvent(new XMLParserEvent(XMLParserEventEvent.LOADED,xml)); }}

Während der Ladevorgang an sich einem bekannten Schema folgt, fällt auf, dass im Kon-struktor der Klasse kein Aufruf der eigentlichen loadXML()-Methode erfolgt. Da die Datei von einem externen Pfad geladen wird, muss sichergestellt werden, dass die xml-Datei auch wirklich geladen wurde, bevor auf ihre Inhalte zugegriffen werden kann. Dies geschieht im DiplomDesktopContext.


Listing 25: DiplomDesktopContext.as (Zeile 30-46)

override public function startup() : void { super.startup();

_xmlParser = new DesktopXMLParser(); _xmlParser.addEventListener(XMLParserEvent.LOADED, _onXMLLoaded); _xmlParser.loadXML();}

private function _onXMLLoaded(event : XMLParserEvent) : void { injector.mapValue(AbstractXMLParser, _xmlParser);

mediatorMap.mapView(ColorPicker, ColorPickerMediator); mediatorMap.mapView(ColorStripe, ColorStripeMediator); mediatorMap.mapView(DesktopView, DesktopViewMediator, AbstractMultiscreenView); mediatorMap.mapView(Away3DContainerDesktop, Away3DContainerMediator, Away3DContainer); contextView.addChild(new DesktopView());}

Das Mapping geschieht hier nicht wie im DiplomMobileContext (siehe Lis-ting 20) direkt in der startup()-Funktion, sondern erst, wenn die xml-Datei ge-laden wurde. Es wird jedoch gleichermaßen eine Regel definiert, welche festlegt, dass das Objekt _xmlParser immer dann injiziert wird, wenn ein Objekt vom Typ AbstractXMLParser angefordert wird. Der Unterschied ist, dass dies hier nur kor-rekt funktioniert, wenn das Objekt auch wirklich vollständig geladen wurde.

Nach Abschluss des Ladevorgangs (siehe Listing 24) wird ein eigens für diesen Zweck angelegtes XMLParserEvent versendet, auf welches der DiplomDesktopContext hört und dann schließlich das Mapping vornimmt, um die DesktopView der Anzeige-liste anzufügen.

Was wurde erreicht?

Abläufe, welche für jeden Screen gleich sind, wie z.B. Views mit Sprachdateien zu ver-sorgen, werden in der Basis der Multiscreen-Anwendung implementiert. Der Entwick-ler einer Screen App muss sich darüber im Nachhinein keine Gedanken mehr machen, was die Entwicklung verschiedener Screen Apps deutlich beschleunigt und vereinfacht. Die verwendeten xml-Dateien können leicht ausgetauscht und angepasst werden und die Sprachdateien liegen hierdurch an einer bekannten zentralen Stelle. Einzelne Texte sind nicht über die Klassen der Anwendung verteilt. Die Apps bleiben dadurch klar struktu-riert und übersichtlich. Kontextrelevante Unterschiede in der Programmierung werden voneinander entkoppelt behandelt – einzelne Screen Apps bleiben schlank und effizient.

834. UMSETZUNG

4.3.5 Interaktive dreidimensionale Benutzerschnittstellen

Das wichtigste Element der Prototypen ist das dreidimensionale Objekt, mit welchem die Interaktion erfolgen soll. Dieses steht zentriert im Mittelpunkt der Anwendung, sowohl auf dem Desktop, als auch auf dem Tablet.

An der Optik des 3D-Objekts bestehen zwischen beiden Screens keine Unterschiede, dafür jedoch an der Interaktion. Während beim Desktop eine Maus benutzt wird, ver-wendet ein Nutzer der iPad-App seine Finger zum Bewegen des Objekts. Dies muss unterschiedlich implementiert werden.

Vorbereiten des Modells

Als 3D-Modell für die Prototypen wurde ein einfacher Sportschuh ausgewählt.83

Abb.38: Das verwendete 3D-Modell

Das Netz („Mesh“) des Modells besteht aus mehreren Unternetzen, sogenannten „Subme-shes“. Anhand dieser Strukturen soll zu einem späterem Zeitpunkt die Zuweisung der unterschiedlichen Materialen auf das Modell erfolgen. Für den Export wurde das Wave-front-Format gewählt, dabei entsteht eine obj-Datei. Zu beachten ist, dass alle Netze trianguliert sein müssen, und alle Normalen mitexportiert werden. Auf den Export einer separaten Materialien-Datei wurde abgesehen, da alle Materalien direkt in Flash erstellt werden. Das finale Modell besteht aus 115.360 Polygonen.

83 Das abgebildete Objekt wurde innerhalb der Agentur modelliert.


Da das Objekt an sich von einer App zur anderen nicht variiert, kann sich ein sog. „Ba-siscontainer“ um das Laden des 3D-Modells kümmern. Desweiteren wird in diesem Container auch die Szene erzeugt. Dazu gehört das Erstellen und Positionieren von 3D-Objekt, Kamera und Lichtern, sowie die Zuweisung von Materialien auf das 3D-Objekt.

Laden des Modells im Basiscontainer

Für das Anzeigen des 3D-Objekts wird die Bibliothek Away3D benutzt. Away3D ist dabei nicht nur in der Lage dreidimensionale Szenen zu rendern, sondern bietet auch verschiedene weitere Funktionen zum Umgang mit 3D-Objekten an. Dazu gehört auch das Laden und das Parsen des Modells. Da es keine Anforderung an den Prototypen darstellt, das Modell leicht austauschbar zu halten, wird die Datei wie die übrigen Assets direkt in den Quellcode eingebettet. Um ein Modell auszutauschen, muss bei diesem Ansatz das Programm neu kompiliert werden. Der Vorteil besteht jedoch darin, dass dieser Ansatz für jeden Screen gleichermaßen funktioniert. Die Datei, welche die Da-ten zur dreidimensionalen Repräsentation beinhaltet, wird als Class mit dem Namen SHOE_OBJ eingebettet. Außerdem existiert eine Variable _modelLoader vom Typ Loader3D. Diese Klasse wird mit der Away3D-Bibliothek mitgeliefert.

Listing 26: Away3DContainer.as (Zeile 132-136), Laden des Modells

Loader3D.enableParsers(Parsers.ALL_BUNDLED);

_modelLoader = new Loader3D();_modelLoader.addEventListener(LoaderEvent.RESOURCE_COMPLETE, _onResourceComplete);_modelLoader.loadData(SHOE_OBJ,null);

Dem _modelLoader wird ein EventListener hinzugefügt, welcher genau dann auslöst, wenn das Modell komplett geladen wurde. Da die Datei eingebettet wurde, muss initial kein Ladevorgang gestartet werden, sondern es kann direkt das Parsen angestoßen werden. Dies geschieht über die Funktion loadData() des _modelLoaders.

Das Modell befindet sich nach dem erfolgreichem Parsen im _modelLoader und kann der Szene hinzugefügt werden:

Listing 27: Hinzufügen des Modells, nachempfunden:

_object = new ObjectContainer3D();_object.addChild(_modelLoader);_view.scene.addChild(_object);

854. UMSETZUNG

Kreieren der Szene im Basiscontainer

Das zentrale Element, welches zur Darstellung einer dreidimensionalen Szene mit Away3D benötigt wird, ist ein Objekt vom Typ View3D. Die von der Grafikkarten ge-renderten Bilder werden darauf abgebildet. Während Away3D intern Stage3D zur Be-rechnung benutzt, muss man sich als Entwickler über die Integration dieser APIs keine Gedanken machen.

Listing 28: Away3DContainer.as (Zeile 65-89), allgemeiner Initialisierungsvorgang

public function Away3DContainer() { _view = new View3D(); _view.mouseEnabled = true; _view.mouseChildren = true; _view.antiAlias = 2; addEventListener(Event.ADDED_TO_STAGE, onAddedToStage);}

private function _onEnterFrame(event : Event) : void { _view.render();}

public function onAddedToStage(event : Event) : void { removeEventListener(Event.ADDED_TO_STAGE, onAddedToStage); _cameraBorders = {min:70, max:500};

_initLights(); _initCamera(); _initScene();

addChild(_view);

addEventListener(Event.ENTER_FRAME, _onEnterFrame);}

Im Konstruktor der Klasse wird als erstes eine neue View3D angelegt, und einige Eigen-schaften definiert. So wird zum Beispiel ein zweifaches Anti-Aliasing angewandt, was dafür sorgt, dass die Kanten des Modells weicher gezeichnet werden.

Wenn ein Objekt der Klasse Away3DContainer der Anzeigeliste hinzugefügt wird, so wird direkt danach die Funktion onAddedToStage() aufgerufen. Dort wird der mini-male und maximale Abstand der Kamera zum 3D-Objekt definiert. Nachfolgend werden verschiedene Funktionen aufgerufen, welche die Lichter, die Kamera, und schließlich die Szene initialisieren. In der Funktion _onEnterFrame(), welche im Idealfall 60 mal in der Sekunde aufgerufen wird, erfolgt abschließend das Rendern der _view.


Listing 29: Away3DContainer.as (Zeile 90-96), Initialisieren des Lichts

private function _initLights() : void { _light1 = new PointLight(); _light1.y = 400; _light1.z = -300; _view.scene.addChild(_light1);}

In der Funktion _initLights() wird eine Punktlichtquelle (PointLight) erstellt. Diese wird im Raum positioniert und schließlich der Szene hinzugefügt. Dies wirkt recht simpel, birgt jedoch einen Stolperstein. Allein das Hinzufügen von Lichtern zur Szene reicht nicht aus, sodass diese auch berücksichtigt werden. Werden nämlich Materialien verwendet, müssen auch diesen extra die Lichter hinzugefügt werden. Dies geschieht in der Funktion _initScene(), in welcher im Anschluss auch das 3D-Modell geladen wird.

Listing 30: Away3DContainer.as (Zeile 108-130), Initialisieren der Materialien

_colorizableMaterial = new ColorMaterial(_modelColor);_colorizableMaterial.ambientColor = _modelColor;_colorizableMaterial.specular = .8;_colorizableMaterial.gloss = 10;_colorizableMaterial.lights = [_light1];

_whiteMaterial = new ColorMaterial(Colors.WHITE);_whiteMaterial.lights = [_light1];

_textilMaterial = new ColorMaterial(Colors.GREY_BRIGHT);_textilMaterial.lights = [_light1];_textilMaterial.specular = .3;

_textilMaterialDark = new ColorMaterial(Colors.GREY_DARK);_textilMaterialDark.lights = [_light1];_textilMaterialDark.specular = .3;

_environmentMap = new CubeMap(new Away3DContainer.POSX().bitmapData, new Away3DContainer.NEGX().bitmapData, new Away3DContainer.POSY().bitmapData, new Away3DContainer.NEGY().bitmapData, new Away3DContainer.POSZ().bitmapData, new Away3DContainer.NEGZ().bitmapData);

_colorizableMaterial.addMethod(_environmentMethod = new EnvMapMethod(_environmentMap));_environmentMethod.alpha = .1;

874. UMSETZUNG

In dieser Funktion werden vier Materialien erstellt. Alle diese Materialen sind vom Typ ColorMaterial. Zur Initialisierung ist es daher prinzipiell ausreichend, einen Farb-wert für das Material anzugeben. So entstehen ein verfärbbares Material (_colorizalbeMaterial), ein weißes (_whiteMaterial), ein hellgraues (_textilMaterial) und ein dunkelgraues (_textilMaterialDark). Allen Mate-rialien wird das erstellte Licht hinzugefügt. Der spekulare Lichtanteil der weißen, hell- und dunkelgrauen Materialien ist recht gering, sodass diese nur wenig glänzend, sondern eher matt, erscheinen. Der hohe spekulare Anteil beim verfärbbaren Material und der zusätzliche recht hohe gloss-Wert lassen dieses glänzend und glatt erscheinen. Zusätz-lich wird für das verfärbbare Material eine EnvironmentMap erstellt. Die Environment-Map beinhaltet eine künstliche Umgebung in Form von Texturen, welche auf einem Würfel abgebildet werden. Wird diese nun einem Material zugewiesen, so wird mit Hilfe eines kubischen Mappings die Textur des Würfels auf das Material, bzw. auf das Objekt projiziert. Auf den Nutzer wirkt es, als spiegelte sich die Umgebung im Material. Ein alpha-Wert von 1 würde dabei wie eine perfekt spiegelnde Fläche aussehen:

Abb.39: Environment-Mapping

Die Zuweisung der im Code erstellten Materialien erfolgt schlussendlich in der Funktion _onResourceComplete(), welche aufgerufen wird, wenn das Modell fertig geparst wurde (Registrierung dieser Funktion: siehe Listing 26).


Listing 31: Away3DContainer.as (Zeile 147-170), Zuordnen der Materialien

for (var i : uint = 0; i < _modelLoader.numChildren; ++i) { mesh = Mesh(_modelLoader.getChildAt(i)); switch (i) { case 1 : mesh.material = _textilMaterial; break; case 2 : mesh.material = _colorizableMaterial; break; case 3 : mesh.material = _textilMaterialDark; break; case 4 : mesh.material = _textilMaterialDark; break; case 7 : mesh.material = _textilMaterialDark; break; default : mesh.material = _whiteMaterial; break; }}

Die einzelnen Meshes sind Kinder des _modelLoaders und können demnach ein-deutig mit ihrem childIndex identifiziert werden, wonach schlussendlich auch die Zuweisung des Materials erfolgt.

Nun existiert ein 3D-Modell eines Schuhs, dessen Submeshes unterschiedliche Materia-len zugewiesen wurden. Außerdem gibt es ein Licht, welches die Szene ausreichend be-leuchtet. Um allerdings überhaupt etwas von der Szene sehen zu können, muss eine Ka-mera initialisiert werden. Die Positionierung der Kamera innerhalb der Szene kann an folgendem Schaubild verdeutlicht werden:

Abb.40: Die Kamera in der Szene

Dabei ist die Kamera im wesentlichen von zwei Parametern abhängig: zum einen von der Entfernung zum 3D-Objekt, und zum anderen vom Winkel zur X-Z-Ebene der Szene. Diese zwei Parameter sind ausreichend, um den Blick des Nutzers auf die Szene zu be-schreiben. Daher finden sie sich auch im Quellcode wieder:

cameraAngle

cameraDistance

894. UMSETZUNG

Listing 32: Away3DContainer.as (Zeile 98-106), Initialisieren der Kamera

private function _initCamera() : void { _camera = new Camera3D(); _cameraAngle = 0; _cameraDistance = 250; _camera.y = Math.sin(_cameraAngle * (180 / Math.PI)) * (-_cameraDistance); _camera.lookAt(new Vector3D(0, 0, 0), new Vector3D(0, 1, 0)); _camera.z = -Math.sqrt(Math.pow(_cameraDistance, 2) - Math.pow(_camera.y, 2)); _view.camera = _camera;}

In der Funktion _initCamera() wird zuerst eine neue Kamera vom Typ Camera3D initialisiert. Auch die Werte für die Entfernung zum 3D-Objekt (_cameraDistance), sowie der Winkel zur Szene (_cameraAngle) werden initial gesetzt. Die Raumkoordi-naten der Kamera sind von diesen beiden Variablen abhängig. Um die Eigenrotation der Kamera richtig zu ermitteln, hilft die Funktion lookAt() der Klasse Camera3D. Der erste übergebene Vektor beinhaltet die Koordinaten des Zielpunkts der Kamera, was in diesem Fall der Ursprung des Koordinatensystems ist. Der zweite Vektor ist der sog. „up-Vektor“, welcher definiert, in welcher Richtung für die Kamera oben ist. Zuletzt wird die Kamera der _view zugewiesen. Die Ansicht wird damit automatisch aus der Perspektive dieser Kamera gerendert.

Was wurde erreicht?

In der Klasse Away3DContainer wurde eine einfache dreidimensionale Szene erstellt, welche ein 3D-Objekt, ein Licht und eine Kamera enthält. Bei der Initialisierung des Schuhmodells wurde auf das konstante Farbregister des Basis-Projekts zurückgegriffen. Diese Klasse dient den Screen Apps als Grundlage für die interaktive 3D-Benutzer-schnittstelle. Bei der Implementierung wurde auf Effizienz und Wiederverwendbarkeit geachtet: erneut lassen sich alle Eigenschaften der 3D-Szene an zentraler Stelle manipu-lieren. Allein die Interaktivität muss in jedem Screen realisiert werden.

Durch die einheitliche Basis wird die 3D-Szene in allen Screens einheitlich dargestellt, wodurch über die Anwendungen hinweg ein gleichbleibendes visuelles Erlebnis geschaf-fen wird (Fluidity).


Touch-Interaktion in der Mobile-App

Die Klasse Away3DContainerMobile erweitert die Funktionalität des Away3DContainers um die Interaktion mit der bereits initialisierten Szene. Dabei werden die folgenden Interaktionswege unterstützt:

• Gestensteuerung via Multitouch

• Nutzung des internen Accelerometer des iPads

• Touchsteuerung via MouseEvents

Gestensteuerung

Zuerst wird überprüft, ob das Zielgerät überhaupt TouchEvents unterstützt.

Listing 33: Away3DContainerMobile.as (Zeile 38-41), Gestensteuerung

if (Multitouch.supportsTouchEvents) { Multitouch.inputMode = MultitouchInputMode.GESTURE; view.addEventListener(TransformGestureEvent.GESTURE_ZOOM, _onZoom);}

Werden TouchEvents unterstützt, so sorgt dieser Code-Baustein dafür, dass die API auf Gesteneingaben reagiert. Die in der Klasse TransformGestureEvent definierte Geste GESTURE_ZOOM repräsentiert das bekannte Zwei-Finger-Zoomen. Dabei wer-den zwei Finger (meist sind dies Zeigefinger und Daumen) auf den Bildschirm gelegt und aufeinander zu oder voneinander weg beweget. Objekte sind dann in der Lage, sich entsprechend des Abstands der beiden Finger zu skalieren.

Die Prototypen sind jedoch so konzipiert, dass keine direkte Skalierung der Szene statt-findet. Schließlich müsste nicht nur das 3D-Objekt skaliert werden, sondern auch die umgebenden Lichter. Daher wird ein Vergrößern und Verkleinern der Szene indirekt über die Kamera, welche auf die Szene blickt, umgesetzt. Soll herangezoomt werden, bewegt sich die Kamera auf das 3D-Objekt zu:

Listing 34: Away3DContainerMobile.as (Zeile 85-88), Zoomen

private function _onZoom(event : TransformGestureEvent) : void { _isRotating = false; cameraDistance = (cameraDistance / event.scaleX);}

914. UMSETZUNG

Nutzung des Accelerometers

Ein zweiter Parameter zur Steuerung der Ansicht ist der Winkel der Kamera zum Boden der Szene. Dieser Winkel wird bei der Mobile App durch die Neigung des iPads, also das integrierte Accelerometer, gesteuert:

Listing 35: Away3DContainerMobile.as (Zeile 48-52), Accelerometer I

if (Accelerometer.isSupported) { _acceleroMeter = new Accelerometer(); _acceleroMeter.setRequestedUpdateInterval(100); _acceleroMeter.addEventListener(AccelerometerEvent.UPDATE, _onAccelerometerUpdate);}

Listing 36: Away3DContainerMobile.as (Zeile 65-67), Accelerometer II

private function _onAccelerometerUpdate(event : AccelerometerEvent) : void { _currentAccelZ = Number(event.accelerationZ.toFixed(2));}

Nachdem erfolgreich geprüft wurde, ob das Testgeräte das Accelerometer unter-stützt, wird ein solches initialisiert und ein UpdateInterval festgelegt. In diesem Fall wird aller 100ms die aktuelle Neigung des Geräts abgefragt und in eine Variable (_currenAccelZ) geschrieben. Durch diesen Wert und die vorher bestimmte Entfer-nung der Kamera zur Szene kann die Ansicht durch den Nutzer kontrolliert werden.

Touchsteuerung via MouseEvents

Wie während der Konzeptionsphase festgestellt wurde, kann die Steuerung über den Touchscreen des Devices auch mit Mausereignissen behandelt werden:

Listing 37: Away3DContainerMobile.as (Zeile 42-44), Mausereignisse registrieren

view.addEventListener(MouseEvent.MOUSE_DOWN, _onTouchBegin);view.addEventListener(MouseEvent.MOUSE_MOVE, _onTouchMove);view.addEventListener(MouseEvent.MOUSE_UP, _onTouchEnd);

Listing 38: Away3DContainerMobile.as (Zeile 69-83), Mausereignisse behandeln

private function _onTouchBegin(event : MouseEvent) : void { _isRotating = true; _initialTouchPointX = mouseX;}


private function _onTouchMove(event : MouseEvent) : void { if (_isRotating) { _rotValue = .25 * (mouseX - _initialTouchPointX); _initialTouchPointX = mouseX; }}

private function _onTouchEnd(event : MouseEvent) : void { _isRotating = false;}

Wird mit dem Finger der Touchscreen berührt, so löst das Ereignis MOUSE_DOWN aus. Daraufhin wird die Variable _isRotating auf true gesetzt. Außerdem wird die aktu-elle x-Position des Fingers auf dem Touchscreen in eine Variable gespeichert. Wird nun, solang _isRotating den Wert true hat, der Finger horizontal in eine beliebige Rich-tung bewegt, so verändert sich der Rotationswert _rotValue. Dies geschieht immer in Abhängigkeit zur aktuellen und vorherigen Position des Touch-Punkts. Wird der Finger angehoben, so endet der Rotationsvorgang.

Die Ergebnisse der drei behandelten Interaktionsarten (Gesten, Accelerometer und Touch) werden schlussendlich in einer Funktion zusammengeführt.

Listing 39: Away3DContainerMobile.as (Zeile 55-63), onEnterFrame

private function _onEnterFrame(event : Event) : void { _rotValue *= .92; if (Math.abs(_rotValue) < 0.00005) _rotValue = 0; else object.rotationY -= _rotValue; _accelZ += (_currentAccelZ - _accelZ) * .25; updateCamera(_accelZ);}

In jedem Frame, also idealerweise aller 1/60 Sekunde, wird der Rotationswert _rotValue um einen geringen Prozentsatz abgedämpft. Die Rotation des 3D-Objekts endet daher nie abrupt. Ab einem bestimmten Grenzwert wird die Rotation schließlich gestoppt. Auch die Differenz der Werte zur Neigungserkennung werden von Frame zu Frame ge-messen und leicht abgeschwächt. Schließlich wird mit der Funktion updateCamera() die Kamera abhängig von _cameraDistance und _cameraAngle neu positioniert.

Listing 40: Away3DContainer.as (Zeile 217-224) Neuberechnen der Kamera

public function updateCamera(angle : Number) : void { _cameraAngle = angle; if (_cameraAngle <= -1) _cameraAngle = -1; if (_cameraAngle >= 1) _cameraAngle = 1; _camera.y = Math.sin(_cameraAngle) * (_cameraDistance);

934. UMSETZUNG

_camera.z = -Math.sqrt(Math.pow(_cameraDistance, 2) - Math.pow(_camera.y, 2)); _camera.lookAt(new Vector3D(0, 0, 0), new Vector3D(0, 1, 0));}

Diese Funktion entspricht dabei im wesentlichen der Initialisierungsfunktion der Kame-ra (siehe Listing 32)

Maus-Interaktion in der Desktop App

Bei der Desktop Web App beschränkt sich die Interaktion mit dem 3D-Modell auf die Maus. Zum Rotieren des Objekts wird die gleiche Funktionalität wie in der Mobile App verwendet. Der einzige Unterschied ist, dass auch eine Rotation um die X-Achse möglich ist. Dadurch wird das Fehlen eines Beschleunigungssensors kompensiert. Durch Ge-drückt-Halten der linken Maustaste und gleichzeitiges Bewegen der Maus in eine belie-bige Richtung, wird das 3D-Objekt rotiert. Das Zoomen der Szene, also der Abstand der Kamera zum 3D-Objekt wird durch das Mausrad betätigt. Die Implementierung ähnelt dabei deutlich der Gestenerkennung bei der Mobile App.

Listing 41: Away3DContainerDesktop.as (Zeile 90-92) Einsatz des Mausrads

private function _onMouseWheel(event : MouseEvent) : void { cameraDistance -= event.delta;}

Auch in der Desktop Web App werden die einzelnen Interaktionsmöglichkeiten in der _onEnterFrame-Funktion zusammengeführt.

Listing 42: Away3DContainerDesktop.as (Zeile 54=66), onEnterFrame

private function _onEnterFrame(event : Event) : void { if (_autoRotation) { _rotValueY += .05 * (_standardRotation - _rotValueY); object.rotationY -= _rotValueY; } else { _rotValueY *= .92; updateCamera(_rotValueX); if (Math.abs(_rotValueY) < 0.00005) _rotValueY = 0; else { object.rotationY -= _rotValueY; } }}


Aufgrund der Tatsache, dass die Interaktion mit dem 3D-Objekt auf dem Desktop weni-ger intuitiv erscheint, wird dieses initial automatisch mit einem Standardwert rotiert. Be-ginnt ein Nutzer mit der Interaktion, schaltet sich diese automatisierte Rotation ab. Mit einem Doppelklick auf das 3D-Objekt wird die automatische Rotation wieder aktiviert.

Was wurde erreicht?

Jeder einzelne Screen erweitert die durch den Away3DContainer vorgegebene Grund-funktionalität um die Interaktion mit der 3D-Szene. Bei der Umsetzung wurde das Kon-zeptmuster „Mobile First“ befolgt und zuerst die Mobile App realisiert. Als Entwickler wird man hierbei mit dem eigentlichen Aufbau der Szene nicht konfrontiert, da dies bereits in der Basis abgehandelt wurde. Die Konzentration bei der Umsetzung der Screen Apps liegt also ausschließlich auf der Realisierung der Interaktionswege mit der App. Die Mechanik ist dabei von dem jeweils benutzten Screen abhängig. Die Implementierung ist durch diese eindeutigen Vorgaben absolut kontextrelevant.

Die Flash Plattform ermöglicht die umfassende Nutzung von Multitouch und Gestener-kennung und eröffnet dem Entwickler umfangreiche Möglichkeiten in der Umsetzung von User-Interfaces. Die Mittel von ActionScript erlauben, das „Look and Feel“ einer nativen Anwendung zu erzeugen, wodurch eine hohe Usability erreicht werden kann.

Die aus der Programmierung der Mobile App gewonnenen Erfahrungen konnten auf die Desktop Web App angewandt werden. Auch hier wurde absolut kontextrelevant gearbeitet und die Interaktionsmöglichkeiten auf die Möglichkeiten des Zielscreens zugeschnitten.

Die einzelnen Screen Apps basieren auf der gleichen Grundlage, haben aber entspre-chend der entkoppelten Entwicklungsweise keine Abhängigkeiten untereinander.

954. UMSETZUNG

4.3.6 Umfärben des 3D-objekts

Das Umfärben des 3D-Objekts erfolgt bei beiden Prototypen auf die gleiche Art und Weise. Der einzige Unterschied ist die Form des Farbwählers, welche bei beiden Anwen-dungen unterschiedlich ist.

Die möglichen Farben wurden bereits im PaintModel definiert (siehe Listing 7) und sind daher auch nachträglich global variierbar.

Der Umfärbevorgang beginnt mit dem Klicken auf eine vordefinierte Farbfläche, am Bei-spiel der Mobile App ist dies eine ColorBox. Der zugehörige Mediator hört auf das Klicken des Nutzers und leitet das entsprechende ColorPickerEvent weiter.

Listing 43: ColorBoxMediator.as

public class ColorBoxMediator extends Mediator { [Inject] public var colorBox : ColorBox;

public function ColorBoxMediator() { super(); }

override public function onRegister() : void { addViewListener(MouseEvent.CLICK, _onColorBoxClicked); }

private function _onColorBoxClicked(event : MouseEvent) : void { dispatch(new ColorPickerEvent(ColorPickerEvent.COLOR_CHANGED, colorBox.color)); }}

Im neu erstellten ColorPickerEvent ist die Farbe der angeklickten ColorBox ge-speichert (colorBox.color) Das Ereignis wird mit der Funktion dispatch() an den Robotlegs-Eventbus weitergeleitet. Auf genau dieses Event wird wiederum an einer ande-ren Stelle der Anwendung gewartet, nämlich im Away3DContainerMediator.

Listing 44: Away3DContainerMediator.as

public class Away3DContainerMediator extends Mediator { [Inject] public var away3DContainer : Away3DContainer;

public function Away3DContainerMediator() { super();


}

override public function onRegister() : void { super.onRegister(); addContextListener(ColorPickerEvent.COLOR_CHANGED, _onColorChanged); addViewListener(Away3DContainerEvent.IS_LOADED, dispatch); }

private function _onColorChanged(event : ColorPickerEvent) : void { away3DContainer.changeColor(event.colorData); }}

Tritt das COLOR_CHANGED Event auf, so wird die Funktion changeColor() des in-jizierten Away3DContainers aufgerufen. Dieser wird die gewünschte Farbe als Para-meter übergeben.

Der Away3DContainer kümmert sich im Anschluss um das Umfärben des 3D-Objekts:

Listing 45: Away3DContainer.as (Zeile 204-215), Ändern der Materialfarbe

public function changeColor(color : uint) : void { TweenMax.to(this, .5, {hexColors:{modelColor:color}, onUpdate:_onUpdateColor});}

private function _onUpdateColor() : void { var mesh : Mesh; _colorizableMaterial.color = _modelColor;

mesh = Mesh(_modelLoader.getChildAt(2)); mesh.material = _colorizableMaterial;}

Hierfür wird die TweenMax-Bibliothek von Greensock84 verwendet. Über eine Dauer einer vordefinierten Zeit (0,5 s) wird der Wert der Variable modelColor zum übergebenen Ziel-Farbwert color getweent. Dabei wird nach jeder vollzogenen Änderung, also je-dem Zwischenschritt, die Funktion _onUpdateColor() aufgerufen. Dort wird dem _colorizableMaterial der neue Farbwert zugewiesen. Außerdem muss das Ma-terial erneut dem entsprechendem Submesh zugeordnet werden, damit die Änderungen auch sichtbar werden. Durch diese Prozedur wird der Farbwechsel mit einem weichen Übergang vollzogen und die Anwendung wirkt weitaus organischer.

84 siehe: www.greensock.com

974. UMSETZUNG

Was wurde erreicht?

Der Farbwähler wurde in beiden Apps auf den Kontext angepasst unterschiedlich gestal-tet. Da der eigentliche Umfärbevorgang allerdings unabhängig vom Screen immer gleich funktionieren soll, wurde dieser in der Basis implementiert. Der Umfärbevorgang ist ein Paradebeispiel für entkoppelte Entwicklung und den Einsatz von Mediatoren.

Die eigentliche Visualisierung der Farbwähler sind einfache Flächen, mit einer aus dem Model vordefinierten Farbe. Diese besitzen keinerlei Funktion. Im Context der Anwen-dung wurden diese einzelnen Farbflächen mit einem entsprechendem Mediator assozi-iert. In diesen wird die Farbfläche injiziert. So bleiben Farbwähler und Mediator vonei-nander entkoppelt. Es besteht keine direkte Abhängigkeit. Der Mediator überwacht nun die Farbfläche und registriert, wenn darauf geklickt wird. Tritt dies ein, so wird ein in der Basis definiertes Ereignis (ColorPickerEvent) an den Robotlegs-Eventbus gesendet. An dieses Ereignis ist die Farbe der angeklickten Fläche geknüpft. Mehr Funktionalität ist in den Screen Apps nicht notwendig. Auch besteht keine direkte Abhängigkeit von der Basis.

Der Mediator der Klasse Away3DContainer wartet während der Laufzeit des Pro-gramms auf Ereignisse vom Typ ColorPickerEvent. Es spielt daher keine Rolle, woher diese Ereignisse stammen. Hierdurch wird die lose Kopplung einzelner Klassen aufrecht erhalten. Tritt das Event nun durch das Betätigen des Farbwählers ein, ruft der Mediator die Umfärbefunktion in der Basis-Applikation auf.

Das Ergebnis ist, dass in jeder Screen App die gleiche Funktionalität zum Umfärben aus der Basis wiederverwendet wird. Einzig die visuelle Repräsentation des Farbwählers muss gesondert implementiert werden. Sogar auf die Nutzung eines Mediators könnte verzichtet werden, da der Farbwähler auch selbst das Ereignis an den Eventbus schicken könnte. Durch den Einsatz des Mediators wird der Code allerdings sauber gehalten und die strikte Entkopplung befolgt.

Erweiterungsmöglichkeiten

Würde man das MVC-Entwurfsmuster an dieser Stelle noch strenger befolgen, müsste das einsetzende Ereignis eine Änderung im Model zur Folge haben. Auf diese Modelän-derung müsste der Away3DContainerMediator hören und erst daraufhin die Farbe des Schuhs verändern. Da es allerdings nicht vorgesehen ist, die aktuelle Farbe länger-fristig zu speichern und an einer anderen Stelle wiederzuverwenden, wurde auf diese Vorgehensweise verzichtet.

Dieser Schritt wäre eine sinnvolle Erweiterung, wenn eine Änderung in der Mobile App auch ein Umfärben in der Desktop Web App zur Folge haben sollte. Das Model könn-te dann in Form einer Datenbank online gespeichert sein und von beliebigen Screens aus verändert werden. Für komplexere Anwendungen wäre dies ein durchaus denkbarer Schritt und entspräche folglich dem Multiscreen Muster „Synchronization“.

995. FAZIT UND AUSBLICK

5. Fazit und Ausblick

Mit dieser Diplomarbeit wurde die Entwicklung einer Multiscreen-Anwendung doku-mentiert. Zu Beginn wurde definiert, dass sich durch die sich stärker ausweitende Gerä-telandschaft vier Screen-Typen herausgestellt haben: Mobile (Smartphone), Tablet, Desk-top und TV. Die Herausforderung für Entwickler besteht darin, mit möglichst geringem Aufwand eine Anwendung für diese unterschiedlichen Kanäle bereitzustellen und sie an den jeweiligen Nutzungskontext anzupassen. Zur Untersuchung der Umsetzbarkeit ver-schiedener Konzeptmuster wurden zwei relevante Screens ausgewählt: das Tablet und der Desktop, für welche je eine App entstehen sollte. Für die technische Realisierung wurde eine entkoppelte Entwicklungsweise gewählt, bei welcher beide Applikationen zwar ohne Abhängigkeiten voneinander programmiert wurden, aber auf eine gemeinsame, wieder-verwendbare Basisanwendung aufbauen. Zur Betrachtung screenspezifischer Interakti-onskonzepte und der 3D-Fähigkeiten von Flash wurde das hochauflösende 3D-Modell eines Sportschuhs entwickelt.

Abb.41: Die finalen Prototypen

5.1 Ausgangssituation

Erst Anfang Oktober 2011, synchron zur Anmeldung dieser Diplomarbeit, erschien die finale Version des Flash Player 11 und ermöglichte die Nutzung der neuen 3D-Fähigkei-ten, welche mit Stage3D aufkamen. Die im Vorfeld durchgeführten Tests beliefen sich auf Beta-Versionen des Flash Players. In fast wöchentlichem Zyklus erschienen während der Beta-Phase neue Updates, welche kleinere und größere Änderungen im Sourcecode mit sich brachten. Um unter Nutzung des zu diesem Zeitpunkt aktuellen Flex-SDKs (Version 4.5.1) den Flash Player 11 ansteuern zu können, mussten einzelne Dateien des SDKs ausgetauscht werden. Ein weiteres Problem in der Testphase war das Finden einer funktionierenden 3D-Engine für Flash. So wurden konkurrierende APIs wie Alternativa und Away3D ausgiebig getestet. Mit den ständigen Updates des Flash Players musste auch immer auf die Anpassung dieser Bibliotheken gewartet werden. Anfang Novem-ber, kurz vor Beginn des praktischen Teils erschien Away3D in einer mäßig stabilen Beta-Version. Während somit die Nutzung von Stage3D für die Desktop-App möglich


war, existierte noch keine 3D-Unterstützung für mobile Geräte. Kurz vor der Anmel-dung der Diplomarbeit war von Adobe angekündigt worden, dass mit der Beta-Version von AIR 3.2 Stage3D auch für mobile Geräte verfügbar sein sollte. Die unangenehme Überraschung war, dass dies zum Zeitpunkt der Veröffentlichung nicht der Fall war. Die iPad-App wurde zu Beginn mit einem Software-Renderer, also ohne Grafikkartenunter-stützung und Stage3D entwickelt. Am 22. November 2011 erschien die zweite Version der öffentlichen AIR 3.2 Beta. Erneut musste Adobe die Community besänftigen, da es auch in der Version keine Stage3D-Unterstützung für mobile Geräte gab.

Adobe Prerelease Program

Adobe bietet einem kleinen ausgewähltem Entwicklerkreis die Möglichkeit, an einem Prerelease Programm teilzunehmen. Dieses beinhaltet verschiedene, sich noch in der Entwicklung befindende Technologien. Die teilnehmenden Entwickler haben die Mög-lichkeit, diese herunter zu laden und auszutesten. So können schon frühzeitig Fehler erkannt und eliminiert werden. Auch Jung von Matt verfügt über einen solchen Account. Nur hierdurch ergab sich die Möglichkeit, das AIR SDK in einem fortgeschrittenem Entwicklungsstand zu testen, welches bereits die Stage3D-Fähigkeiten unterstützte.

Die Prototypen dieser Arbeit wurden fast zeitgleich mit den ihnen zugrunde liegenden Technologien entwickelt. Dies war nicht nur eine zeitliche Herausforderung. Die spärli-che Dokumentation und nur rar gesäte Quellen machten die Arbeit zwar nicht unbedingt einfacher, dafür aber spannender. Die wiederholt aufgetretenen Aktualisierungen von AIR und der benutzten 3D-Engine erforderten ständige Anpassungen im Sourcecode der Prototypen. Der Anspruch, immer mit der aktuellsten Software zu arbeiten, führte dazu, dass das am 29.11.2011 veröffentlichte Flex 4.6 SDK eingesetzt wurde. Trotz des zu diesem Zeitpunkt weit voran geschrittenen Stands der Mobile App für das iPad brachte die Umstellung auf das neue SDK keine Konflikte mit sich. Erst mit der späteren Aktu-alisierung auf eine neue Version des AIR SDKs traten zwei immense Probleme auf: zum einen wurde das 3D-Modell nicht mehr korrekt angezeigt, zum anderen funktionierte das Debugging via FDT nicht mehr. Erst nach zwei Tagen intensiver Tests und Recher-che stellte sich heraus, dass dies nicht am AIR SDK lag, sondern an Flex. Um erneut Ge-brauch vom Debugger machen zu können, wurde auf das Flex SDK 4.5.1 zurückgestellt. Danach konnte auch der Darstellungsfehler gefunden und eliminiert werden.

Die Entwicklung geht rasant voran und es gilt abzuwarten, welche neuen Möglichkei-ten und Verbesserungen mit der finalen Version von AIR 3.2 aufkommen werden. Der schnelle Wandel und die ständige Weiterentwicklung sind ein deutliches Zeichen, dass Flash eine lebendige und leistungsstarke Technologie ist.

Am 27.02.2012, genau einen Tag, bevor diese Arbeit gedruckt wurde, veröffentlichte Adobe AIR 3.2 in der „Release Candidate“-Version. Während es sich hierbei immer noch nicht um die finale Version handelt, ist es nun für jedermann möglich, Mobile Apps mit Stage3D-Unterstützung zu entwickeln.


5.2 Bewertung und Ergebnisse der praktischen Untersuchungen

Die Wahl der entkoppelten Entwicklungsweise für Multiscreen-Anwendungen wird von Adobe ausdrücklich empfohlen. Im Folgenden sollen die während der Umsetzung festgestellten Vor- und Nachteile der gewählten technischen Herangehensweise erläutert werden.

5.2.1 Betrachtung der Entwicklungsumgebung FDT

Als Fremdhersteller bietet die Powerflasher GmbH mit FDT eine vollwertige Actions-cript-Entwicklungsumgebung, welche sich hervorragend in die Flash Plattform integ-rieren lässt. Durch vorgefertigte Templates beschleunigt FDT bereits das Anlegen der einzelnen Projekte. So ist auch die Nutzung der neuen Stage3D-APIs für die Desktop App ohne Komplikationen möglich. Die Verbindung der voneinander unabhängigen Screenprojekte zum Basisprojekt erfolgt unkompliziert über die Nutzung sogenannter „Linked Libraries“, also Verweisen auf bereits existierende Projekte, deren Funktionalität hierdurch nutzbar wird. Auch zur Durchführung vorbereitender Maßnahmen, wie dem Verknüpfen eines Flex SDKs mit dem AIR SDK, erledigt FDT auf einen Knopfdruck. Die übersichtlichen Dialogfelder erleichtern vor allem die Konfiguration mobiler Projek-te. Hierbei kann zwischen Android- und iOS-spezifischen Eigenschaften unterschieden werden. Andere Plattformen, wie Windows Phone oder Blackberry, werden dabei aller-dings nicht unterstützt. Durch die aktuell noch fehlende Export-Möglichkeit der durch FDT automatisiert erstellten ANT-Konfigurationen wird es dem Entwickler erschwert, fortgeschritten individualisierte Einstellungen bezüglich des Kompiliervorgangs zu täti-gen. Die Nutzung eigener ANT-Skripte ist darüber hinaus dennoch möglich. Durch eine separat in die Entwicklungsumgebung installierbare Erweiterung ist auch die Anbindung an ein System zur Versionsverwaltung möglich, was die Sicherheit und Kontrolle über den Sourcecode deutlich verbessert und ein effizientes Arbeiten im Team ermöglicht. Ein Anwendung muss unabhängig von ihrer technischen Herangehensweise getestet und debuggt werden. Bei der Web App für den Desktop ist dies ein bekannter und herkömm-licher Vorgang. Auch für das Testen einer iOS-Applikation bietet FDT eine komfortable Lösung. Befinden sich das Testgerät und die Maschine, auf welcher die Entwicklungs-umgebung ausgeführt wird, im gleichen Netzwerk, kann in FDT via Knopfdruck ein Remote-Debugging durchgeführt werden.

5.2.2 Betrachtungen zur entkoppelten Entwicklungsweise der Multiscreen-Anwendung

Das Basisprojekt ist die Grundlage der voneinander entkoppelten Screenprojekte und der Speicherort gemeinsam verwendeter Komponenten. So wird zum Beispiel die grundlegen-de Initialisierung des 3D-Containers der zu entwickelnden Multiscreen-Anwendung im Basisprojekt vollzogen. Die Generierung von Lichtern, Materialien, Szene und Kamera erfolgt einmalig an dieser Stelle. Die Screenprojekte nutzen diese gemeinsame Basis und können somit bei eventuell auftretenden Programmänderungen gleichzeitig an zentraler Position gepflegt werden. Die von Screen zu Screen variierenden Interaktionskonzepte


werden bei einer entkoppelten Entwicklung im jeweiligen Screenprojekt umgesetzt. Die Steuerung der Apps kann dadurch immer individuell realisiert werden, ohne das auf Be-sonderheiten und Ausnahmen anderer Screens geachtet werden muss. Durch die Kapse-lung wiederverwendbarer Komponenten in das Basisprojekt wird eine stabile Grundlage für unterschiedliche Screenprojekte geschaffen. Diese wiederrum erweitern die Grund-funktionalität um individuelle Komponenten, ohne sich gegenseitig zu beeinflussen. Auch die spezifischen Anzeigeschichten werden außerhalb der Basis für jeden Screen se-parat programmiert. Bei einer konsequenten Durchführung dieses technischen Ansatzes können gut strukturierte und stabile Apps geschaffen werden: diese nutzen eine gefestigte Grundlage, besitzen aber die notwendige Agilität bezüglich ihrer screen-spezifischen Be-sonderheiten. Als nachteilig ist zu werten, dass Manipulationen am Basisprojekt immer indirekte Auswirkungen auf alle darauf aufbauenden Screenprojekte haben können. Die-se sind mitunter nur schwer nachvollziehbar und erfordern ein hohes Maß an Konzent-ration beim Entwickler. Auch wird es mit einer steigenden Komplexität der Multiscreen-Anwendung zunehmend schwieriger zu entscheiden, ob die Einordnung bestimmter Code-Bausteine in das Basisprojekt oder die individuellen Screenprojekte erfolgen sollte.

Die Nutzung etablierter Design Pattern erleichtert die Strukturierung einer entkoppelt entwickelten Multiscreen-Anwendung. Mit dem Robotlegs Mikroarchitektur Framework wird die Kopplung zwischen einzelnen Objekten und Klassen weiter verringert. Die Fle-xibilität der Anwendung wird hierdurch signifikant erhöht. Für Entwickler, welche mit einer solchen Architektur oder derartigen Frameworks nicht vertraut sind, verschlechtert sich hierbei jedoch die Lesbarkeit und Nachvollziehbarkeit des Programmcodes, da in-nerhalb dessen kaum direkte Abhängigkeiten einzelner Objekte erkennbar sind.

Den entwickelten Applikationen für Tablet und Desktop liegt das Multiscreen Muster „Coherence“ zu Grunde. Beide Apps vermögen die gleiche Aufgabe zu bewerkstelligen, stehen sonst aber in keiner weiteren Verbindung zueinander. Die Wahl des Multiscreen Musters für diese Betrachtungen ist jedoch nicht von einer technischen Herangehenswei-se abhängig. Allein die erdachte Funktionsweise einer Anwendung entscheidet, welches Multiscreen Muster angewandt werden könnte.

Bedeutungsvoller ist die Bewertung der Implementierbarkeit der im Grundlagenkapitel vorgestellten Konzeptmuster für Multiscreen-Anwendungen. Während nach Vorgaben der Agentur bereits während der Planungsphase klar war, dass die zu entwickelnden Screen-Apps für Desktop und Tablet umgesetzt werden sollten, rückte die Mobile App für das Tablet zuerst in den Fokus konzeptioneller Überlegungen. Dies erfolgte nach dem Konzeptmuster „Mobile First“. Auch während der Entwicklung wurde dieses Muster verfolgt, da die iPad-App vor der Webapplikation für den Desktop umgesetzt wurde. Erst als alle während der Konzeptionsphase bedachten Komponenten der mobilen Anwen-dung fertiggestellt wurden, begann die Arbeit an der Web App für den Desktop. Diese konnte in Anbetracht des zu diesem Zeitpunkt weitestgehend finalisierten Basisprojekts und der Erfahrungen aus der iPad-App innerhalb erstaunlich kurzer Zeit erstellt werden. Die nachfolgend eingearbeiteten marginalen Änderungen an den einzelnen Apps konn-ten synchron vorgenommen werden, ohne weitreichende Änderungen an der beiden Apps zugrunde liegenden Basis vornehmen zu müssen.


Die Möglichkeit der Anwendung des Konzeptmusters „Responsive Design“ wurde be-reits durch die Wahl der technischen Herangehensweise stark beschränkt. Dieses Kon-zeptmuster ist anwendbar, wenn genau eine Applikation existiert, welche für mehrere Screens gleichzeitig verwendet werden soll. Diese Anwendung sollte dann in der Lage sein, ihr Aussehen und ihre Interaktivität abhängig von bestimmten Faktoren intelli-gent an den jeweilig benutzten Screen anzupassen. Da mit einer entkoppelten Entwick-lungsweise jedoch zwei Applikationen entstanden sind, waren derartige Vorkehrungen nach diesem Konzeptmuster gar nicht notwendig. Das Konzeptmuster konnte dennoch in seinen Grundzügen in der Umsetzung beachtet werden: die einzelnen Apps verhal-ten sich innerhalb ihres jeweiligen Screens responsiv und reagieren auf Größen- und Orientierungsänderungen.

Besonders auffallend bei der Betrachtung der Ergebnisse der Praxisarbeit war das Zu-sammenspiel der Konzeptmuster „Fluidity“ und „Kontextrelevanz“, welche in ihren Grundgedanken recht unterschiedlich sind, sich jedoch ergänzen. Während Ersteres beschreibt, dass einzelne Screen-Apps einer Multiscreen-Anwendung für ein gleich-bleibendes Empfinden beim Nutzer sorgen sollten, geht es bei Letzerem darum, auf die durch die im Geräte- und Nutzungskontext auftretenden Unterschiede im Layout als auch bei der Implementierung einer Anwendung Rücksicht zu nehmen. Nach Abschluss der Umsetzung beider Screen-Apps stellte sich heraus, dass viele einzelne Komponenten beiden Konzeptmustern zugeordnet werden konnte. So ist die vom Screen unabhängige Funktionalität zur Verwaltung von Assets ein fluides Merkmal, wohingegen die Speiche-rung der eigentlichen Grafiken immer kontextrelevant von Screen zu Screen gesondert erfolgte. Auch die xml-basierte Sprachsteuerung sorgte für ein fluides Aussehen beider Apps. Hierbei war jedoch der technische Hintergrund entsprechend geräteabhängiger Unterschied immer auf den jeweiligen Kontext zugeschnitten. Betrachtet man nun die Orte der Implementierung der jeweiligen Funktionalität, so fällt auf, dass alle fluiden Eigenschaften, egal ob sie das Layout oder die Funktionalität betreffen, im Basispro-jekt stattfanden. Kontextrelevante Besonderheiten, unabhängig ob diese dem technischen Hintergrund eines Screens oder die Verwendung unterschiedlicher Layout-Elemente dienlich sind, wurden immer in der entsprechenden Screen-App implementiert. Dieser Zusammenhang lässt darauf deuten, dass ein entkoppelter Entwicklungsansatz für die Betrachtung dieser Konzeptmuster bestens geeignet ist. Ein weiterer Vorteil ist folglich auch, dass die Einordnung bestimmter Komponenten in das jeweilige Konzeptmuster die Strukturierung einer entkoppelt entwickelten Applikation erleichtern kann.

5.2.3 Betrachtungen zur Entwicklung von Mobile Apps für ioS

Die Entwicklung von iOS-Apps ist im Gegensatz zu Applikationen für den Desktop, welche als Web App wie normale Internetseiten im Browser betrachtet werden können, um einiges umständlicher. Dies beginnt bereits mit dem Einrichten eines hierfür not-wendigen Apple Developer Accounts und der Erzeugung aller notwendigen Zertifikate. Diese Voraussetzungen müssen erfüllt sein, bevor eine iOS-App kompiliert werden kann. Nach dem daran anschließendem Verpacken der Applikation wird eine ipa-Datei er-zeugt. Diese muss zuerst der iTunes-Bibliothek hinzugefügt werden, bevor sie dann via


Drag and Drop auf das Testgerät gezogen werden kann. Die erfolgreiche Installation ist davon abhängig, ob alle Zertifikate und identifizierenden Bezeichner korrekt in die Applikation integriert wurden. Der sich ständig wiederholende Prozess des manuellen Hinzufügens der App zur iTunes-Bibliothek und der anschließenden Übertragung aufs Testgerät ist ein mühsamer und zeitaufwändiger Vorgang. Auch müssen regelmäßig die bereits auf dem Gerät installierten Vorgängerversionen der App von Hand gelöscht wer-den. Eine Veränderung dieser Abläufe wäre eine deutliche Verbesserung am Workflow des Entwicklers.

5.2.4 Bewertung der Stage3D-Performance

Zur Bewertung der Performance der Stage3D wurde ein kleines Tool verwendet, welches mit Away3D ausgeliefert wird: AwayStats. Der Statusmonitor lässt sich einfach in eine Anwendung integrieren und bekommt eine beliebige View3D übergeben. Die für die Tests relevante Information ist hierbei die durchschnittliche Framerate, welche oben rechts dargestellt wird.

Abb.42: Away3D Statusmonitor

Die nachfolgende Tabelle gibt einen Überblick über die in den Tests ermittelten Bildwi-derholungssraten auf den einzelnen Testgeräten. Es wurden fünf Messungen über je fünf Minuten durchgeführt. Die erste Messung erfolgte ohne jegliche Nutzerinteraktion. Die Tests der Desktop Web-App erfolgten im Safari Browser Das Fenster war dabei exakt 1280x1024 Pixel groß.

Nr. Messung iPad2 Mac Pro MacBook Pro

1 – ohne Interaktion 57 fps 59 fps 61 fps

2 56 fps 59 fps 63 fps




Tab.4: Messreihe Performancetest


An den Testergebnissen ist erkennbar, dass sich die Bildwiederholungsrate aller Test-geräte über einen längeren Benutzungszeitraum stark dem Zielwert von 60 fps annä-hert. Diese Werte bleiben auch während der Nutzerinteraktion konstant; einzig beim MacBook Pro konnten selten kurze Ausreißer-Werte überhalb der 200 fps ausgemacht werden. Diese selten auftretenden Messfehler erklären, warum die Ergebnisse bei diesem Testgerät knapp überhalb des Zielwerts liegen.

Trotz der unterschiedlichen Hardware und Leistungsfähigkeit der einzelnen Testgeräte konnte das 3D-Modell mit 115.360 Polygonen auf jedem Gerät flüssig und fehlerfrei dargestellt werden. Dies ist äußerst zufriedenstellend, wenn man die bisherigen 3D-Fä-higkeiten von Flash betrachtet. Leider konnte auf der iPad-App zum jetzigen Zeitpunkt kein Anti-Aliasing benutzt werden, wodurch sich an den Rändern des 3D-Modells harte Kanten bilden. Es ist jedoch zu erwarten, dass dieses Feature mit der Veröffentlichung des AIR 3.2 SDK und der Away3D-Bibliothek nachgereicht wird.

Abb.43: Anti-Aliasing

5.3 Erweiterungsmöglichkeiten

5.3.1 Beibehalten der strikten Entkopplung

Vom finalen Stand der Entwicklung der einzelnen Apps ausgehend wäre es ein Leichtes, nun weitere Screens mit der Anwendung zu bedienen. Es müsste hierfür ein Projekt für den hinzukommenden Screen angelegt werden. Der Aufbau des Projekts wäre ähnlich zu den bereits existierenden Projekten. Die zu diesem Zeitpunkt gut ausgebaute Basis-Applikation beinhaltet alle notwendigen Methoden und Komponenten, um schnell eine weitere App umsetzen zu können. Kontextrelevante Feinheiten würden dann wieder un-abhängig von den anderen Screens programmiert werden.

5.3.2 Kombinierter Entwicklungsansatz

Sollten Apps für weitere Screens entwickelt werden, wäre in bestimmten Fällen auch ein kombinierter Entwicklungsansatz denkbar. Soll nun zum Beispiel zusätzlich eine iPho-ne-App veröffentlicht werden, so kann man annehmen, dass diese der existierenden iPad-App stark ähnelt. Bei einer entkoppelten Entwicklung wäre der überwiegende Teil des


Quelltextes innerhalb der Screen App redundant. Die einzigen zu beachtenden Differen-zen bei der Entwicklung sind die Bildschirmauflösung und die Leistungsfähigkeit des iPhones. Auf diese Unterschiede könnte in der existierenden iPad-App eingegangen wer-den, statt eine weitere Screen App zu entwickeln. Aus der bereits existierenden iPad-App würde demnach eine anpassungsfähige Anwendung, die nach gewissen Unterscheidungs-merkmalen entweder für das iPad oder eben für das iPhone veröffentlicht wird (Respon-sive Design). Bei einer überschaubaren Komplexität der Applikation wäre dies eine gang-bare Herangehensweise, um Redundanz im Programmcode zu vermeiden und dadurch eine höhere Effizienz in der Entwicklung zu erlangen. Die Entkopplung zu den anderen Screen Apps würde davon unangetastet weiterhin bestehen bleiben.

Abb.44: Kombinierte Entwicklungsweise

5.3.3 Alternative Entwicklungsumgebung Flash Builder

Mit dem Flash Builder liefert Adobe ein mächtiges Werkzeug von ActionScript- und Flex-Anwendungen. Die neueste Version (4.5) bietet die Möglichkeit, Projekte für unter-schiedliche Screens anzulegen, Apps zu verpacken und so auch für iOS- und Android-Devices zu entwickeln. Diese Alternative wurde in dieser Diplomarbeit nicht betrachtet. Mit den zu Flex-Anwendungen gehörenden MX- und Spark-Komponenten existiert eine reichhaltige Sammlung an vorgefertigten UI-Elementen. Via MXML, einer xml-basierten Auszeichnungssprache für Userinterfaces können Flex-Applikationen effizient und ro-bust programmiert werden. Die in einer Werbeagentur entwickelten Anwendungen sind jedoch in höchstem Grade auf Corporate Design (CD) und die Identität einer Marke (CI) zugeschnitten und erfordern viele individuell für den Kunden zugeschnittene Kom-ponenten und Elemente. Diese „Maßanfertigung“ von Anwendungen ist der Grund, wa-rum auf die Verwendung vorgefertigter Flex-Komponenten im Workflow von Jung von Matt verzichtet wird.

Es sollte trotzdem nicht unerwähnt bleiben, dass der Flash Builder umfangreiche Mög-lichkeiten bietet, mit welchen sich komfortabel umfassende Anwendungen für unter-schiedliche Screens entwickeln lassen.

combinediOs Mobile App

combinedAndroid Mobile App

Base App

Desktop Web App


5.4 Zusammenfassung und Schlussfolgerung

Mit einer entkoppelten Entwicklungsweise konnte eine kohärente Multiscreen-Anwen-dung geschaffen werden. Durch den technischen Ansatz wird diese durch zwei alleinste-hende Apps repräsentiert: eine Mobile App für das iPad2 und eine Web App, welche im Desktop-Browser läuft. Beide Applikationen nutzen dabei die gleiche Code-Basis.

Alle vorgestellten Konzeptmuster wurden bei der Implementierung berücksichtigt. Ein-zig das „Responsive Design“-Muster hätte besser zu einer anderen technischen Herange-hensweise gepasst, nämlich der Entwicklung einer anpassungsfähigen Einzelanwendung.

Der Umsetzung der Prototypen folgte die Erkenntnis, dass die entkoppelte Entwicklung vor allem für Anwendungen geeignet ist, bei denen die einzelnen Apps größere Unter-schiede hinsichtlich ihres Layouts, ihres Inhalts und vor allem ihrer Steuerung aufweisen. Für Apps, die nur marginale Anpassungen von Screen zu Screen erfordern, ist eine an-passungsfähige Einzelanwendung die effizientere Entwicklungsweise.

Die nachfolgende Tabelle gibt einen abschließenden Überblick über die Vor- und Nach-teile der entkoppelten Entwicklungsweise.

Pro Kontra

Einzelne Ziel Screens sind durch eigene Projekte klar voneinander getrennt.

Jede zu entwickelnde App muss einzeln angelegt und konfiguriert werden.

Das Basisprojekt kapselt wiederkehrende Funktionalität und Komponenten für alle Screens, erhöht somit die Wiederverwend-barkeit. Auch grundlegende Funktionen können durch die Basis allen Screens glei-chermaßen bereitgestellt werden.

Änderungen an der Basis betreffen immer automatisch alle Screens und können zu unerwarteten Effekten führen. Dies wird kritischer, je mehr Entwickler am Projekt arbeiten.

Apps beinhalten nur Programmcode, den sie auch wirklich benötigen.

Funktionen, die nur leicht variiert in un-terschiedlichen Screens auftreten, sind redundant.

Flexibilität in der Wahl des SDKs: jeder App kann ein eigenes Flex SDK zugewie-sen werden.

Screens, die sich nur minimal unterschei-den, weisen ebenfalls starke Redundan-zen im Code auf und sind unflexibler zu pflegen.

Entwickler müssen nur die Projekte aus einem Versionsverwaltungssystem (SVN) herunterladen, an welchen sie auch wirk-lich arbeiten.

Es ist mitunter schwer einschätzbar, ob be-stimmte Mechanismen direkt in der App oder an der Basis implementiert wurden.


Pro Kontra

Die Aufmerksamkeit kann durch die strik-te Trennung der Apps besser auf einen be-stimmten Screen gerichtet werden.

Eine existierende Anwendung kann nur umständlich in eine solche Entwicklungs-weise überführt werden. Der bestehende Code müsste in Basis- und Screenprojekt aufgeteilt werden, bevor weitere Screens bedient werden können.

Die Kompilierung einer einzelnen Screen App ist zeitsparend, da nur der diesem Screen zugehörige Programmcode berück-sichtigt werden muss.

Tab.5: Vor- und Nachteile einer entkoppelten Entwicklungsweise

Wenn bei der Umsetzung eines Projekts davon auszugehen ist, dass es für verschiedene Screens erreichbar und erweiterbar sein soll, so muss dies von vornherein in die Konzepti-on des gesamten Anwendungsspektrums einfließen. Hierbei sind bestimmte Muster und Strategien zu beachten: eine Mobile App sollte sich in bestimmten Gesichtspunkten von einer Desktop App unterscheiden, die Anwendung an sich allerdings wiedererkennbar und fluid sein. Abhängig von den unterstützen Screens, den konzeptionellen Unterschie-den einzelner Screen Apps und dem voraussichtlichem Aufwand ist von den Entwicklern abzuwägen, welche technische Herangehensweise zu wählen ist.

5.5 Ausblick

Für Entwickler, Werber und Content-Anbieter wird es zunehmend schwieriger, mit der rasanten Entwicklung der Gerätelandschaft und den damit aufkommenden Innovationen Schritt zu halten. Durch den stark wachsenden Markt und der Unterschiede zwischen einzelnen Screens ist es notwendig, effiziente Lösungsstrategien zu entwickeln, ein mög-lichst großes Publikum ansprechen zu können. Die Flash Plattform bietet sich als etab-liertes und flexibles Werkzeug zur Erzeugung reichhaltiger Multiscreen-Anwendungen an.

Der Verbund von Actionscript, Flex und AIR bietet Entwicklern die Möglichkeit, viele Screens mit nur einer einzigen Technologie anzuvisieren. Bereits mit der Einführung touchbasierter Events und der Erkennung von Gesten erweiterte die Flash Plattform das Betätigungsfeld der Entwickler. Mit AIR wurde es möglich, Flash-Applikationen für mobile Geräte zu verpacken, und damit auch Screens außerhalb des Desktops zielgerich-tet zu bedienen. Mit der bevorstehenden Veröffentlichung des AIR 3.2 SDKs wird nun auch die Leistungsfähigkeit von Stage3D für mobile Plattformen zugänglich. Hierdurch wird es für Flash Developer möglich, reichhaltige Inhalte wie Spiele oder Multimediaan-wendungen für verschiedenste Screens bereitzustellen.


Während die Bedeutung mobiler Plattformen folglich steigt ist abzuwarten, wie sich die Stellung von Flash für den Desktop verändern wird. Betrachtet man die strategische Aus-richtung Adobes, so ist anzunehmen, dass sich Flash auch hierbei stärker in Richtung der Spieleentwicklung positionieren wird. Flash qualifiziert sich damit für ein weites Feld neuartiger Anwendungsmöglichkeiten weit ab von Bannern und Video-Playern. Die Er-stellung eindrucksvoller Webspecials und Kampagnenseiten ist darüber hinaus weiterhin möglich, wenn auch das Zielmedium durch die Einstellung des Flash Player Plugins für mobile Geräte auf den Desktop beschränkt wird.

Durch die rasch aufkommenden Technologien und die immer leistungsfähigeren Geräte ist zu erwarten, dass die Grenzen zwischen den einzelnen Screens stärker verwischen. Bereits jetzt sind Tablets wahre „Mehrzweckwunder“ und in der Lage, Spielfilme wieder-zugeben, Sendungen zu streamen, hochwertige Spiele zu ermöglichen und durch Office-Anwendungen in die tägliche Arbeit integriert zu werden. Durch diese Überlagerung von Einsatzzwecken wird es herausfordernder, Nutzungsverhalten und -situationen korrekt abschätzen zu können. Es ist daher auch denkbar, dass Multiscreen-Anwendungen nur der Anfang einer neuen Generation von Softwarelösungen sind. Dynamische Applikati-onen, die sich nicht mehr nur an den Screen und einen vordefinierten gedachten Anwen-dungsfall anpassen, sondern auch an den Benutzungsort, die Tageszeit, den Terminplan des Nutzers oder gar seinen Gewohnheiten sind eine denkbare Weiterentwicklung.

Nach den ursprünglichen Mulitplattform-Fähigkeiten von AIR ist die Möglichkeit zur Entwicklung reichhaltiger Multiscreen-Anwendungen ein neuer Meilenstein für die Flash Plattform. Der gewählte technische Ansatz der entkoppelten Entwicklung stellt hierfür eine geeignete Möglichkeit bereit. Sollte die Zukunftvision von Radley Marx ein-treten, und AIR in einigen Jahr leistungsfähig genug sein, um selbstständig eine einzelne Anwendung für die unterschiedlichsten Screens aufzubereiten und dabei automatisch alle kontextrelevanten Besonderheiten zu beachten, käme der Flash Plattform eine überra-gende technologische Bedeutung zu.

Bis es so weit ist, wird die Relevanz von Multiscreen-Entwicklung weiter steigen.„Going through so many options may feel overwhelming and guess what? There are no right or wrong answers. There are those who would argue that some techniques are bet-ter than others but it really boils down to target audience, target device usage, resour-ces, time and budget. Whatever the final strategy may be, one cannot assume that a multi-screen approach is a thing of the future. It is here, now.“, Christina Truong, Teehan+Lax85

85 Vgl. letzter Absatz [Truong 2012]

1116. LITERATUR- UND QUELLENVERZEICHNIS

6. Literatur- und Quellenverzeichnis

[Adobe01 2011] Adobe: PC penetration, http://www.adobe.com/products/flashplatformruntimes/statistics.html abgerufen am 23.09.2011

[Adobe02 2011] Adobe Flash Platform, http://www.adobe.com/flashplatform/, abgerufen am 30.10.2011

[Adobe03 2011] Adobe Developer Connection: Stage3D, http://www.adobe.com/devnet/flashplayer/stage3d.html, abgerufen am 07.11.2011

[Adobe04 2011] Adobe Blogs: Flash to Focus on PC Browsing and Mobile Apps, http://blogs.adobe.com/conversations/2011/11/flash-focus.html, abgerufen am 09.11. 2011

[Adobe05 2011] Adobe Developer Connection: How Stage3D works, http://www.adobe.com/devnet/f lashplayer/articles/how-stage3d-works.html, abgerufen am 12.11.2011

[Adobe06 2011] BETA ActionScript 3.0 Reference for Adobe Flash Plat-form, http://help.adobe.com/en_US/FlashPlatform/beta/reference/actionscript/3/f lash/display3D/Program3D.html#upload(), aberufen am 12.11.2011

[Adobe07 2010] Adobe Developer Connection - Writing multiscreen AIR apps, https://www.adobe.com/devnet/air/flex/articles/writing_multiscreen_air_apps.html, abgerufen am 15.11.2011

[Adobe08 2011] ActionScript 3 Reference: Multitouch, http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/ui/Multitouch.html, abgerufen am 13.01.2012

[Adobe09 2011] Adobe Developer Connection: Native extensions for Adobe AIR, http://www.adobe.com/devnet/air/native-extensions-for-air.html, abgerufen am 19.01.2012

[Adobe10 2011] Adobe Labs - Proscenium, http://labs.adobe.com/technologies/proscenium/, abgerufen am 16.11.2011

[Away 2011] Away3D - Features, http://away3D.com/features, abgerufen am 16.11.2011


[Bitblokes 2011] Bitblokes: Hochrangiges IBM-Mietglied: Der PC ist tot - und das am 30. Geburtstag, http://www.bitblokes.de/2011/08/hochrangiges-ibm-mitglied-der-pc-ist-tot-und-das-am-30-geburtstag/, abgerufen am 07.11.2011

[BrowserMag 2011] Browsermagazin: Unity holt Flash an Bord, http://www.browsergame-magazin.de/unity-3d-holt-flash-an-board/, ab-gerufen am 09.11.2011

[Casperson 2011] Casperson, Matthew: Away 3D 3.6 Essentials, 1. Auflage, Packt Publishing, 2011

[Cavazza 2011] Fred Cavazza: Why Opposing HTML5 And Flash Is Non-sense, http://www.forbes.com/sites/fredcavazza/2011/07/17/why-opposing-html5-and-flash-is-a-non-sense/, abgerufen am 27.11.2011

[Chambers 2011] Mike Chambers: Clarifications on Flash Player for Mobile Browsers, the Flash Platform, and the Future of Flash, http://www.mikechambers.com/blog/2011/11/11/clarifications-on-flash-player-for-mobile-browsers-the-flash-platform-and-the-future-of-flash/, abgerufen am 11.11.2011

[CMarketer 2011] Chief Marketer: 2011 Mobile Marketing Survey High-lights, http://chiefmarketer.com/mobile/2011-mobile-marke-ting-survey-0613bq7/index.html abgerufen am 23.10.2011

[CNN 2010] CNN Money : The numbers don‘t lie - Mobile devices overtaking PCSs, http://tech.fortune.cnn.com/2010/08/11/the-great-game-mobile-devices-overtaking-pcs/, abgerufen am 10.11.2011

[Compete 2010] competepuls: Smartphone Owners - A Reasy and Wil-ling Audience, http://blog.compete.com/2010/03/12/smartphone-owners-a-ready-and-willing-audience/, abgerufen am 10.11.2011

[Croft 2010] Jeff Croft: On „Responsive Web Design“ and the Mobile Context, http://jeffcroft.com/blog/2010/aug/06/responsive-web-design-and-mobile-context/, abgerufen am 10.11.2011

[DevelopOnline 2009] develop-online.net: The Top 10 Game Engines, http://www.develop-online.net/features/516/THE-TOP-10-GAME-EN-GINES-NO4-Unity-3D, abgerufen am 09.11.2011


[EMarketer 2011] eMarketer: Advertisers Work to Integrate Mobile into Cross-Platform Campaigns, http://www.emarketer.com/Article.aspx?R=1008498 abgerufen am 23.10.2011

[HooksFallow 2011] Hooks, Joel; Fallow, Lindsey: Actionscript Developer‘s Guide to Robotlegs, 1. Auflage, O‘Reilly Media, 2011

[Horizont 2011] HORIZONT.NET: Jung von Matt führt erneut Kreativ-Index des Manager Magazins an, http://www.horizont.net/aktuell/agenturen/pages/protected/Jung-von-Matt-fuehrt-erneut-Kreativ-Index-des-Manager-Magazins-an_103965.html, abgerufen am 17.11.2011

[Jobs 2010] Steve Jobs: Thoughts on Flash, http://www.apple.com/hotnews/thoughts-on-flash/ abgerufen am 23.09.2011

[JungVonMatt 2002] Jung, Holger ; von Matt, Jean-Remy: Momentum - Die Kraft, die Werbung heute braucht., 5. Auflage, Lardon Media AG, 2011

[Kaitila 2011] kaitila, Christer: Adobe Flash 11 Stage3D (Molehill) Game Programming, 1. Auflage, Packt Publishing, 2011

[Marcotte 2011] MarCotte, Ethan: Responsive Web Design, 1. Auflage, A Book Apart, 2011

[Marx 2010] Radley Marx: Multiscreen development means multi-ple Screens, not all in one, http://radleymarx.com/blog/multiscreen-development/ abgerufen am 30.10.2011

[MultiscrExp01 2011] Multiscreen Experience, http://www.multiscreen-experience.com/ abgerufen am 30.10.2011

[MultiscrExp02 2011] Multiscreen Experience: Fluidity, http://www.multiscreen-experience.com/?page_id=116, abgerufen am 09.11.2011

[MultiscrExp03 2011] Multiscreen Experience: Konzeptmuster, http://www.multiscreen-experience.com/?page_id=50, abgerufen am 15.01.2012

[Powerflasher 2011] Powerflasher-Blog: Macht euer FDT Molehill ready, http://blog.powerflasher.de/macht-euer-fdt-molehill-ready/ abgerufen am 22.11.2011


[Precious 2011] Precious: Patterns for multiscreen strategies, http://precious-forever.com/2011/05/26/patterns-for-multiscreen-strategies/ , abgerufen am 15.01.2012

[RiaStats 2011] riastats.com, http://riastats.com/#, abgerufen am 09.11.2011

[Scabia 2011] Marco Scabia: My Name is AGAL, and I Come from Ad-obe, http://iflash3d.com/shaders/my-name-is-agal-i-come-from-adobe-1/, abgerufen am 12.11.2011

[Starling 2011] Starling Framework, http://www.starling-framework.org/, abgerufen am 16.11.2011

[StatBund 2011] Statistisches Bundesamt Deutschland: Mobile Internet-nutzung über das Handy 2010 stark gestiegen, http://www.destatis.de/jetspeed/portal/cms/Sites/destatis/Internet/DE/Presse/pm/2011/02/PD11__060__63931.psml abgerufen am 23.10.2011

[TAZ 2011] taz.de : Flash für mobile Geräte - Groß, schwerfällig und voller Fehler, http://www.taz.de/Flash-fuer-mobile-Geraete/!81689/, abgerufen am 15.11.2011

[Truong 2012] Christina Truong: No screen left behind: Creating a digital experience for multiple devices, http://www.teehanlax.com/blog/no-screen-left-behind-creating-a-digital-experience-for-mul-tiple-devices/, abgerufen am 19.01.2012

[Unity 2011] Unity Technologies Blog: Unity and Flash - a sneak peak, http://blogs.unity3d.com/2011/09/01/unity-and-f lash-a-sneak-peek/ abgerufen 09.11.2011

[Wagner 2011] wagner, Richard: Professional Flash Mobile Development, 1. Auflage, Wiley Publishing Inc., 2011

[Wichmann 2008] Sebastian Wichmann: Adobe Flash Player 10 ab sofort ver-fügbar, http://www.flashhilfe.de/news_adobe-flash-player-10-ab-sofort-verfuegbar_1024.html, abgerufen am 07.11.2011

[Wolter 2009] Sascha Wolter: Die Geschichte von Flash, http://www.wolter.biz/2009/12/07/die-geschichte-von-flash/ abgerufen am 24.10.2011

[Wroblewski01 2011] wroblewski, Luke: Mobile First, 1. Auflage, A Book Apart, 2011


[Wroblewski02 2011] PDF-Präsentation „Mobile First“ von Luke Wroblews-ki, http://www.lukew.com/resources/articles/MobileFirst_LukeW.pdf, abgerufen am 09.11.2011

1177. ANHANG

7. Anhang

Begriffserklärungen

Im Folgenden sollen einige wichtige Begriffe erklärt werden, welche in dieser Diplom-arbeit auftauchen. Auch wenn viele der aufgeführten Ausdrücke keine Übersetzung erfordern ist es hilfreich, den Zusammenhang im technischen/werblichen Kontext zu verstehen.

Begriff Erklärung

Accelerometer Ein feinmechanisches Bauteil zur Bestimmung der Beschleunigung eines Geräts entlang eines dreidimensionalen Koordinatensystems.

Asset Einzelne Medieninhalte unterschiedlichster Art, welche von einer Software oder Internetseite verwendet werden.

Beobachter Entwurfsmuster

Ein Verhaltensmuster in der Softwareentwicklung, bei welchem Objekte Veränderungen abhängiger Objekte beobachten und selbst-ständig auf Zustandsänderungen reagieren.

Compiler Settings

Einstellungen, welche beim Kompilieren eines Programms beachtet werden. Wie zum Beispiel die angestrebte Bildwiederholfrequenz.

Crossmedia Kampagne

Werden für eine Werbekampagne verschiedenste Medien wie Print, Plakate, Webspecials und Mobile eingesetzt, also unterschiedlichs-te Kanäle von einer Kampagne betroffen, so spricht man von einer Crossmedia Kampagne.

Debuggen Der Vorgang des Auffindens von Fehlern zur Laufzeit eines Programms.

Fallback Ein Fallback beschreibt eine Ersatzlösung, welche dann benutzt wird, wenn eine eigentlich angeforderte Technologie aus unbekann-ten Gründen nicht verfügbar sein sollte. Internetnutzer, welche kei-nen Flash Player installiert haben, sehen statt Werbebannern zum Beispiel nicht animierte Grafiken.

Fisheye-Perspek-tive

Beschreibt die extrem weitwinklige Darstellung einer 3D-Szene. In der Fotographie werden hierfür stark gewölbte Linsen verwendet.

Framework Bei Frameworks handelt es sich um Programmiergerüste, welche zur effizienten Softwareentwicklung verwendet werden.


Begriff Erklärung

iOS Das Betriebssystem mobiler Apple-Produkte, wie dem iPad oder dem iPhone.

Landingpage Nach einem Klick auf Werbemittel oder Suchmaschineneinträgen landen Nutzer häufig auf speziell hierfür eingerichteten Landingpa-ges. Diese dienen der besonderen Präsentation eines Produkts oder einer Leistung.

Look and Feel Wiedererkennbare standardisierte Designelemente und Inter-aktionsformen beschreiben das typische „Look and Feel“, also das Aussehen und den Bedienkomfort bekannter Software- und Hardwareprodukte

Mapping (von Klassen und Objekten)

Mithilfe eines Mappings können bei der Softwareentwicklung be-stimmte Relationen zwischen verschiedenen Objekten hergestellt werden.

Mapping (von Texturen)

Die Algorithmen zum Abbilden zweidimensionaler Grafiken auf eine dreidimensionale Oberfläche.

Mesh Ein Netz aus (meist) gleichartigen Polygonen.

Mikroarchitektur Eine MVC-Architektur, welche nicht übergreifend auf ein gro-ßes Softwareprojekt angewendet wird, sondern auf deren einzelne Module.

Mobile In der Werbebranche wird der Begriff „Mobile“ (englisch ausge-sprochen) für Kampagnen oder Teilkampagnen verwendet, welche den mobilen Sektor bedienen. Der Begriff hat sich in der Branche eingebürgert, genau wie man auch von „Print“ oder „Online“ spricht, bezeichnet „Mobile“ eben alle auf mobilen Kanälen durchführbaren Aktionen. Auch werden Smartphones und Tablets gern unter dem Begriff „Mobile“ zusammengefasst. Etwas für „Mobile“ zu entwi-ckeln bedeutet, dass es sich bei der Zielplattform um mobile Geräte wie Smartphones oder Tablets handelt.

Open Source Der Quelltext von Open Source Bibliotheken ist öffentlich zugäng-lich. Dieser Lizenztyp ermöglicht einer breiten Masse die Weiter-entwicklung derartiger Programme.

Parser Ein Parser wandelt bestimmte Ausgangsdaten in ein verwendbares Format um.

Pitch Ein Wettbewerb um den Werbeetat eines Unternehmens.

1197. ANHANG

Begriff Erklärung

Plugin Ein Plugin kann während der Laufzeit in ein Softwareprodukt inte-griert werden und dessen Funktion hierdurch erweitern.

Rendern Ein Vorgang zur Erzeugung von gerasterten Bildern aus bestimm-ten Daten, wie zum Beispiel Vektoren.

Screen In Zeiten von Touchscreens und Gestensteuerung ist der Bild-schirm eines Geräts nicht nur das Anzeigeelement, sondern gleich-zeitig auch das Eingabewerkzeug. Damit wird der Bildschirm das Interaktionswerkzeug eines Geräts. Dadurch beschreibt der Screen die wichtigsten Eigenschaften eines Gerätes. Für unterschiedliche Screens zu entwickeln bedeutet also, für unterschiedliche Endgeräte zu entwickeln, und dabei die jeweiligen gerätespezifischen Beson-derheiten zu berücksichtigen

Singleton Das Singleton-Entwurfsmuster stellt sicher, dass von einer Klasse nie mehr als ein Objekt gleichzeitig erzeugt werden kann.

Tween Ein Tween beschreibt die auf einem Anfangs- und Endzustand ba-sierende Interpolation verschiedener Eigenschaften von Anzeigeob-jekten über einen bestimmten Zeitraum.

Usability Im Kontext der Softwareergonomie beschreibt die Usability die Gebrauchstauglichkeit eines Gerätes oder einer Oberfläche für die Nutzer.

User Experience Die Erlebnisse, welche ein Nutzer während der Interaktion mit einem Produkt erfährt, beschreiben die User Experience eines Angebots.

Selbstständigkeitserklärung

Hiermit versichere ich, dass ich die vorliegende Diplomarbeit zum Thema

„Multiscreen-Entwicklung für 3D-Benutzerschnittstellen unter Verwendung der Adobe Flash Plattform“

selbstständig und unter ausschließlicher Verwendung der angegebenen Literatur und Hilfsmittel erstellt habe.

Stuttgart, den 28. Februar 2012

Richard Pietsch

Da ich aus Angst, jemanden zu vergessen, nicht all die vielen Menschen aufzählen kann, welche mich in den letzten Monaten so großartig unterstützt haben, ob durch ihre ehrliche

Anteilnahme, Motivation oder Ablenkung, möchte ich ein riesengroßes aufs Papier bringen. Danke an alle, die für mich da waren!

—

Dankbar bin ich auch den Menschen, die aktiv an der Gestaltung meiner Diplomarbeit teilgenommen haben:

Allen voran meine KollegInnen der „Flasherbutze“ – für den anhaltenden kreativen Input, die technische Unterstützung, das Korrektur-Lesen und die tagtägliche Rücken-

stärkung, wenn der Compiler mal wieder nur rote Zeilen ausspuckte – Danke Steffi, Daniel und Simon!

Auch bei „Möchtegern-Flasher“ Darius bedanke ich mich ganz herzlich für das Korrek-tur-Lesen und die vielen hilfreichen Anmerkungen!

Auch wenn mir ein Mercedes lieber gewesen wäre – bei Boris möchte ich mich für den großartigen Turnschuh bedanken. Passt perfekt!

Bei den Powerflashern bedanke ich mich für die Unterstützung mit FDT5 Max.

I‘d also like to thank the brilliant indie-game-developer Breakdance McFunkypants AKA Christer Kaitila for the early support with his incomparable Stage3D-knowledge.

If your book had arrived earlier, i would have banned all 3rd-Party APIs!

Ein ganz besonderer Dank gilt meinen Betreuern:

Frau Prof. Dr. Teresa Merino von der HTW Dresden. Ihnen möchte ich schon für die Unterstützung vor der Diplomarbeit danken. Denn

ohne Ihren Zuspruch und Ihre Motivation wäre ich wahrscheinlich gar nicht bei Jung von Matt angekommen, und hätte jetzt eine ganz andere Arbeit abgeben müssen. Auch für ihre Bereitschaft, mich aus der Ferne zu betreuen und mir stets mit konstruktiven

Hinweisen außerhalb jeglicher Sprechzeiten zur Seite zu stehen, möchte ich Ihnen ganz herzlich „Danke“ sagen.

Nils Döhring als Technischer Direktor bei Jung von Matt/Neckar. Du hast mir die einmalige Chance gegeben, so „cutting edge“ zu arbeiten, dass nur dein

kompetenter technischer Einfluss, die Unterstützung mit brandheißen Technologien und dein Know-How größere Schnittwunden und Verbrennungen vermeiden konnten. Daher freue ich mich riesig, auch weiterhin „mitflashen“ zu dürfen. Und beim nächsten

Multiscreen-Projekt braucht‘s dann auch keine 5 Monate mehr, versprochen!

Kolophon

Bei den verwendeten Schriftarten handelt es sich um

JVMHelveticaCondensed-Bold, Helvetica Neue, Adobe Caslon Pro und Courier.

—

Zum Satz wurde Adobe InDesign CS4 verwendet. Alle Illustrationen ohne Angabe einer Quelle wurden in Adobe Illustrator CS4 erstellt.

Für die Bearbeitung von Abbildungen wurde Adobe Photoshop CS4 verwendet.

—

Die Rechte der verwendeten Logos der liegen beim jeweiligen Inhaber.

New Multiscreen-Entwicklung für 3D-Benutzerschnittstellen · 2012. 9. 20. · I Inhaltsverzeichnis...

Documents

Transcript of New Multiscreen-Entwicklung für 3D-Benutzerschnittstellen · 2012. 9. 20. · I Inhaltsverzeichnis...