Android360 Vol.1

MOBILE MOBILE MOBILE COMMANDERCOMMANDERCOMMANDERDie Android-Plattform als mobile SteuerzentraleDie Android-Plattform als mobile SteuerzentraleDie Android-Plattform als mobile Steuerzentrale

www.android360.de

MIT CD!

StandortbestimmungDas Android Location API

The Guardian Das Android-Sicherheitsmodell

Vision trifft Realität Fragmentierung von Android

Roboters geheime Tagebücher Storage-Lösungen für Android

Vol. 1

Österreich € 14,70 Schweiz sFr 25,60 Luxemburg € 14,90Deutschland € 12,80

iOS unter Druck – Android auf dem Vormarsch

Fakten für Android-EntwicklerFakten für Android-Entwickler

SONDERHEFT

Android 2.2 | Sicherheitsmodell | Augm

ented Reality | Location API | AIR 4 Android | Fragmentierung | Live W

allpaper | BluetoothA

ND

RO

ID360

Mobile Welten

entdecken

Egal, ob Sie eine bestehende Applikation auf das iPad übertragen möchten oder ein neues Geschäftsmodell effi zient aufbauen wollen – Mobile Media Solutions liefert mit der neuen MMS Media App ein vollständig integriertes White-Label-iPad-System.

Mit unserem Leistungsangebot fi nden Sie dazu die passende Unterstützung mit einer Reihe von Optionen:

Sofort einsetzbare Anwendungen mit einem angepassten Branding im App Store verfügbar

Frontend-Lösungen, die über Standardschnittstellen kundenspezifi sche Funktionen integrieren

Individualprojekte, mit denen die Möglichkeiten des Kunden in Gesamtlösungen integriert werden

Die wichtigsten Features:

Unterstützung von multiplen Bestellprozessen

Lokale (offl inefähige) Bibliothek für Inhalte

Fortlaufende Aktualisierungen von Inhalten

Einbettung von Multimedia-Inhalten sowie statischer und dynamischer Werbung

Darstellung und Skalierung von Inhalten im Portrait- und Landscape-Modus

Auswahl von Fonts, Schriftgröße, Spaltenanzahl

Funktionales Bookmarking-System

Suchfunktion für lokale Inhalte und Shop-Inhalte

Integrierte Registrierung und Authentifi zierung

Die MMS Media App für das iPad

www.m-mediasolutions.de

NEU

EDITORIAL

Android hat sehr viel mehr

zu bieten, als wir in ein ein-

ziges Heft packen können.

www.android360.de ANDROID3604

Liebe Leserinnen und Leser,

die mobile Revolution ist da, daran besteht

kein Zweifel. Es ist lediglich eine Frage der Aus-

prägung: proprietär gegen Open Source, strikt

unternehmensgetrieben gegen communityaffin.

Die großen Gegenspieler heißen im Moment je-

denfalls iOS und Android. Und dieser Kampf

ist noch lange nicht entschieden – auch wenn

Oracle Mitte August als große, bis dahin unbe-

kannte Variable, eine Klage gegen Google aus

dem Hut gezaubert und mit der Begründung,

Google hätte bei der Entwicklung Androids

wissentlich geistiges Eigentum von Oracle ver-

letzt, für einiges Aufsehen gesorgt hat. Welche

Intentionen dahinter stehen, dürfte man nur in

der Firmenzentrale im kalifornischen Redwood

Shores wissen. Auch wenn in der Klage ver-

langt wird, dass alle Kopien der Java-Projekte

beschlagnahmt und zerstört werden müssten,

dürfte es kaum in Oracles Interesse liegen, die-

ses überaus erfolgreiche Stück Java von Smart-

phones zu verbannen. Denn weder Java ME

noch JavaFX Mobile sind als adäquate Alterna-

tiven zu betrachten. Android ist also derzeit die

einzige Option für unzählige Java-Entwickler

auf Smartphones.

Ich gestehe: Wenn es um Smartphones geht,

dann bin ich Apple-Fanboy. Das klare UI, das

schicke Design, die nicht gar so kritische Aus-

prägung der Fragmentierung – all das lässt mein

Herz für das Smartphone aus Cupertino höher

schlagen. Doch bei den Vorbereitungen zu die-

sem Heft habe ich viele spannende Dinge ge-

lernt. Trotz meines weiterhin vor allem wegen

des leidigen Themas der Fragmentierung kriti-

schen Blicks auf Googles OS, bietet Android Ent-

wicklern und Anwendern so viele aufregende

Möglichkeiten, die dem Wegbereiter für Smart-

phones, iOS, in nichts nachstehen. Sei es das

Sicherheitsmodell (S. 59), das Thema Storage

(S. 101) oder die Möglichkeit, sich mit Blue-

tooth und dem Lieblingsspielzeug aller Jungs

– Lego – auszutoben, wie es Miriam Brückner

und Andreas Frey auf S. 82 vormachen: Android

bietet eine umfangreiche und durchdachte Plat-

form, die nicht nur auf den Smartphones die-

ser Welt für Furore sorgen wird. Das glauben

Sie nicht? Dann lesen Sie den Artikel auf S. 42,

dann wissen Sie, was ich meine.

„Android 360“ ist das erste themenbezogene

Sonderheft unseres neuen, vierteljährlich er-

scheinenden Hefts „Mobile Technology“, das

sich über Android hinaus mit der vollen Band-

breite an wichtigen mobilen Technologien und

Strategien beschäftigt. Mit dem vorliegenden

Heft halten Sie einen Leitfaden in die faszinie-

rende Welt von Googles Open-Source-Betriebs-

system in Händen, der Ihnen sogar dabei helfen

wird, die Realität nach Ihren Vorgaben zu be-

einflussen. Mehr dazu finden Sie ab S. 90.

Und weil uns das alles noch nicht genug er-

schien, haben wir sogar noch einen besonderen

Bonus für Sie in petto. Unter www.android360.

de/bonus haben Sie die Gelegenheit, sich zwei

weitere, hochkarätige Artikel nach einer kurzen

Anmeldung kostenlos herunterzuladen. Denn

Android hat sehr viel mehr zu bieten, als wir in

ein einziges Heft packen können.

In diesem Sinne viel Spaß bei der

Lektüre von „Android 360“

Thomas Wießeckel

Redakteur

ANDROIDAPPS

SM

PROVIDER

OS

D

SMARTRTR PHONES

EDITORS PICK

iPHONE

Der frische 360°-Blick auf mobile Entwicklungen!

iPhone, Android und BlackBerry sind nicht mehr wegzudenken aus dem mobilen Leben der Menschen. Tendenz steigend. Mit immer neuen Geräten, neuen Anbietern und einem weiter stei-genden Bedarf an Applikationen ist der Hunger nach Informationen in diesem Bereich schier unendlich. Dieser Entwicklung trägt das neue

Webportal mobile360.de Rechnung, welches über sämtliche Plattformen und Betriebssyste-me hinweg, genauso aber auch über den Markt, Geschäftsmodelle, Trends und Neuigkeiten im Bereich der Appstores sowie über die verschie-denen Smartphones und Tablets berichtet – ein 360°-Blickwinkel auf das Mobile Development.

Der frische 360°-Blick auf mobile Entwicklungen

mobile360.de

E-READER

Die mobile Revolution ist Da,

DaRan besteht kein Zweifel

INHALT

1 einstieG ..............................................

8 Bücherecke

9 Mobile360.de im Gespräch mit Benno Bartels

„Apps sind gefühlt näher am User und werden

erfahrungsgemäß inniger geliebt.“

12 Kampf der Titanen

Oracle legt sich mit Google an – und was wird aus den Usern?

14 Was gibt’s Neues bei Android 2.2?

Die neue Android-Version bringt viel Neues –

das Wichtigste lesen Sie hier

19 Vision trifft Realität

Die Gründe für die Android-Fragmentierung

21 iOS unter Druck

Wie Android die (mobile) Welt erobert

28 App auf den Markt!

Wie man mit eigenen Android-Applikationen Geld verdienen kann

36 Innovationsfreude

Die Zugbegleiter der Deutschen Bahn mit

Android Smartphones auf Zukunftskurs

42 Bis zum Handy und noch viel weiter

Neue Anwendungsgebiete von Googles

Smartphone-Betriebssystem

55 Gemeinsam unterwegs

Android-Unterstützung für mobile Communitys

2 foRtGesChRitten ........................

59 The Guardian

Eine Übersicht über die Sicherheitskonzepte

der mobilen Plattform

64 Standortbestimmung und schöne Aussichten

Das Android Location API und Google Maps

70 Kleine Helfer auf dem Homescreen

Eine Einführung in die Android-Widget-Programmierung

78 Live Wallpaper

Animierte und interaktive Hintergrundbilder

für den Homescreen

82 Wir sind alle Roboter

Lego Mindstorms meets Android

90 Mehr Realität zum Selbermachen

Augmented Reality für Android

3 RoCket sCienCe .............................

95 Android im siebten Himmel

Android-Applikationsentwicklung auf Basis der

Flash-Technologie AIR

101 Roboters geheime Tagebücher

Ein Überblick über die Möglichkeiten der

Datenspeicherung

unter Android

36 innovationsfreudeDie Auswahl einer geeigneten

Endgeräteplattform für ein

verfahren auf mobilen Endgeräten im

Unternehmensumfeld gehört zu den

spannendsten Themen der heutigen IT. wer

in dieser Entscheidungssituation zurückblickt

und auf Kandidaten setzt, die sich in der

vergangenheit immer bewährt haben,

könnte in Schwierigkeiten geraten. Dieser

Artikel zeigt, wie die Deutsche Bahn ihren

weg gefunden hat.

64 Standortbestimmung

und schöne aussichten

Fast jedes Android-basierte Gerät erlaubt es,

seine Geoposition zu bestimmen. Standort- und

Positionsdienste machen gerade bei mobilen

Applikationen Sinn. Dieser Artikel zeigt die

Grundlagen der Positions- und Standortdienste

in Android und erklärt die verwendung von

Google Maps.

?? lum nonsequat. Per si.

Ad dolore doloreet utet autate feui blandip endiam

deliquatet veniatue modiat augait luptat nulla facil dolorpero

con hendrem venim ad magna coreros am ad eugait autpat

velisl utpat ad del el exerat wis del dolobortio odolorerit wis

dolorperos del ute do ea feuis del ing essi ero doloboreetue

magnit ad tem zzriliquis.

82Lego Mindstorms meets androidEin internationales Forschungsprojekt, ein

LEGO-Mindstorms-Roboter und ein Android-

Gerät. Als Kommunikationskanal zwischen den beiden wel-

ten dient Bluetooth. Dieses Thema bereitete den Autoren

nicht nur sehr viel Spaß, sondern ist auch technologisch

durchaus interessant – Grund genug, die wesentlichen

Schritte der Lösung in einem Artikel vorzustellen.

14 Was gibt‘s neues bei

android 2.2?

Mit vielversprechenden Funktionen wie External

Storage, Push, Data Backup und Fehlerreporting

bietet Android 2.2 mit dem Codenamen „Froyo“

viele spannende neuerungen für Entwickler. In

diesem Artikel erfahren Sie alles, was Sie wissen

müssen.

28 app auf den Markt!

Googles offenes Smartphone-Betriebssystem Android

wird von immer mehr Geräteherstellern unterstützt. Für Entwickler

steht dadurch eine Zielplattform mit hohem Potenzial zur verfü-

gung. Die Frage ist, wie man als Entwickler seine Applikation am

besten an den Kunden bringt. Dieser Artikel beleuchtet die Mög-

lichkeiten von Googles Android Market und den Alternativen und

gibt Tipps, wie man die Applikation am besten vermarktet.

Magazin | BÜCHER

www.android360.de8 ANDROID360

BüchereckeWer eine erfolgreiche App entwickeln möchte, sollte jede Hilfestellung nutzen, die sich bietet. Auch wenn Communitys immer eine große Hilfe sind, so sollte man sich ein gewisses Basiswissen erarbeitet haben. Wir haben uns umgesehen und die hilfreichsten Bücher für Sie zusammengesucht.

Android 2 von Arno Becker und Marcus Pant

Android hat sich mittlerweile als Plattform für Mobil-telefone und Kleincomputer etabliert. Java-Entwickler, die sich damit beschäftigen, erhalten über das Android SDK interessante Möglichkeiten der Anwendungsent-wicklung für eine Vielzahl von Geräten nicht nur für Mobiltelefone. Dieses Buch versetzt Java-erfahrene Le-ser in die Lage, professionelle Software für die Android-Plattform zu entwickeln. Dabei werden die besonderen Rahmenbedingungen berücksichtigt, die sich aus gerin-ger Prozessorleistung, instabilen Netzwerkverbindungen und plötzlichen Programmunterbrechungen, z. B. durch Telefonanrufe, ergeben.

Arno Becker, Marcus Pant

Android 2 Grundlagen und Programmierung

427 Seiten, 39,90 Eurodpunkt.verlag, 2010 ISBN 978-3-89864-677-2

Strategie: Mobile Marketing von Fritz Reust

Mobile Geräte sind aus dem Kommunikationsalltag nicht mehr wegzudenken. Bereits jetzt konsumieren wir Informationen in jeder Form, überall und jeder-zeit: Facebook und Twitter, Musik, Videos, TV, Radio, Games usw. Dieses Buch richtet sich an Werbetreibende auf Agentur- und Kundenseite, die ihre Botschaften dem neuen Kommunikationsverhalten anpassen möchten. Als Mobilkenner und Kommunikationsfachmann der ersten Stunde behandelt Fritz Reust sowohl die techni-schen als auch die werblichen Aspekte des Themas und zeigt die Möglichkeiten von heute und morgen. Dabei wird klar, dass Mobile Marketing anderen Gesetzmä-

Android von Heiko Mosemann und Matthias Kose

Mit einer Darstellung der Architektur von Android, mit den Anforderungen an die Hardware und mit den Installationsschritten und Werkzeugen, die die Vo-raussetzung für den effektiven Einsatz von Android schaffen, führen die Autoren Sie in die Android-Welt ein. Auch die Besonderheiten von Android, z. B. Acti-vities und Content-Provider, kommen nicht zu kurz. Sie lernen die wichtigsten APIs kennen, dazu zählen Grafi k, Multimedia, Internet, Datenbanken, Kontakt-daten, Lokalisierung, SMS und Zugriff auf Sensoren.

Heiko Mosemann, Matthias Kose

Android Anwendungen für das Handy-Betriebssystem erfolgreich programmieren

384 Seiten, 39,90 EuroHanser, 2009ISBN 978-3-446-41728-1

ßigkeiten unterliegt und keinesfalls mit Internetmarke-ting gleichgesetzt werden kann.

Fritz Reust

Strategie:Mobile MarketingGrundlagen, Technologien, Fallbeispiele

224 Seiten, 39,80 EuroMidas Verlag AG, 2010 ISBN 978-3-907100-35-6

www.android360.de 9 ANDROID360

Porträt

Benno Bartels hat sich schon während seines Studiums mit der Entwicklung und Portierung von mobilen Anwendungen beschäftigt. Danach gründete er mit zwei Freunden die Firma insertEFFECT in nürnberg. Im Fokus des mittlerweile zehn-köpfi gen Teams stehen Konzeption und Entwicklung von Mo-bile websites und Applikationen sowie Social Applications wie Facebook Apps und widgets. Gerne teilt er seine Erfah-rungen in workshops, BarCamps und auf webmontagen.

InTERvIEw | Magazin

„apps sind gefühlt näher am User und werden erfahrungs-gemäß inniger geliebt.“

Benno Bartels ist als Berater, Konzepter und Projektma-nager verantwortlich für Kunden wie die Immowelt AG, Focus Online und Stellenanzeigen.de. Bereits in seinem Studium beschäftigte er sich mit der Entwicklung von mo-bilen Anwendungen. Lukas Konieczny von Mo bile360.de befragte den Chef eines zehnköpfi gen Teams zu mobilen Themen.

Mobile360: Welche besonderen Anforderungen muss ein Entwickler für das Mobile Web erfüllen?Bartels: Leute, die sehr gutes Mobile-Know-how mitbrin-gen, sind gar nicht so leicht zu fi nden. Daher stellen wir fähige Entwickler/innen ein, die auch eine persönliche Affi nität zum Thema Mobile haben. Das Thema setzt nämlich eine gewisse Denke voraus, mit der nicht jede(r) kann. Dazu zählt, dass man den mobilen Kontext nie aus den Augen verlieren darf und den Ansprüchen der Benut-zer sowohl von Touchscreen-Phones, Featurephones als auch Smartphones gerecht werden muss. Die Geräteland-schaft verändert sich extrem schnell, man muss sich stän-dig weiterbilden, schwache Prozessoren berücksichtigen, mit Beta-SDKs arbeiten, selbst experimentieren und alles wieder verwerfen, Blogs lesen, neue Devices und Apps ausprobieren. Hierfür geben wir unseren Leuten auch die Zeit und die Tools, die sie brauchen. Was uns noch wich-tig ist, ist eine Offenheit gegenüber allen mobilen Platt-formen. Grabenkämpfe wie zwischen Steve und Google sollten lieber am Kickertisch ausgetragen werden.

Mobile360: Was wird beim Design von mobilen Web-seiten generell falsch gemacht? Was macht für Sie Usability im Mobile Web aus?Bartels: Gerade bei browserbasierten Lösungen muss man beim Design daran denken, dass die Site höchst-wahrscheinlich nicht nur auf iPhone und Android genutzt wird, sondern auch auf hunderten Featurepho-nes. Manchen Mobile Designs sieht man an, welches Handy der Designer in der Hosentasche hat, anderen sieht man an, dass der Designer bisher nur fürs Web de signt hat. Zum Beispiel kann man eine mobile Web-site heute so designen, dass sie mit Aufklappmenüs und JavaScript-Features glänzt – technisch alles mög-lich. Aber Benutzungssituation, Eingabemöglichkeiten, Lichtverhältnisse, Verbindungsqualität, Geräteunter-

Mobile360.de im Gespräch mit Benno Bartels

www.android360.de10 ANDROID360

Magazin | InTERvIEw

schiede und die Größe der Displays fordern Konzept und Design nach wie vor zur Zurückhaltung auf. Ein klares Wording und eine durchgängig logische Naviga-tion wirken Wunder bei der Zufriedenheit der Nutzer.

Mobile360: Was unterscheidet eigentlich eine App von einer mobilen Webanwendung? Sind die meisten Apps nicht verkappte Webanwendungen, die als Shortlink dienen?Bartels: Oh ja, das wird oft durcheinander gebracht. Die meisten meiner Telefonate mit Kunden beginnen mit der Erklärung, was da der Unterschied ist und wo die Vor- und Nachteile der einzelnen Lösungen liegen. Die Grenzen verschwimmen aber auch immer mehr. Zunächst mal ist ja da technisch ein Unterschied: Apps werden normalerweise nativ programmiert, also in Java, C++, Objective-C. Sie werden aufs Device runtergela-den und dort installiert. Web-Apps sind in Webtech-niken – HTML, CSS und JavaScript – programmiert und werden wie normale Webseiten auf einem Server abgelegt und laufen normalerweise im Browser des

Smartphones. Native Apps laufen nur auf einer Platt-form, also iPhone Apps nur auf iOS und Android nur auf Android-Devices. Mobile Webseiten laufen, wenn man es geschickt anstellt, im Browser aller internetfä-higen Geräte. Deshalb ergibt sich bei der Konzeption und der Usability ein großer Unterschied: Die User von Android Apps erwarten eine User-Experience, die sie von ihrem Device her kennen, z. B. den Style der Tabs, Belegung des Zurück-Buttons und des Android-Menüs. Bei der Nutzung des Browsers geht die Erwartungshal-tung eher in Richtung Web-Experience. Apps sind also gefühlt „näher“ am User und werden erfahrungsgemäß auch inniger geliebt. Für die meisten „Entscheider“ ist das Argument pro App und contra Web aber der Distri-butionskanal über die App Stores. Mittlerweile ist es für viele aus Marketingsicht ein Muss in Market und App Store präsent zu sein, selbst wenn es schon eine mobil optimierte Website des Service gibt. Das erklärte Ziel ist das Firmenlogo auf dem Handy des Nutzers. Deshalb entstehen derzeit viele Apps, die eigentlich auch als mo-bile Websites funktionieren würden und teilweise auch diesen „Shortlink-Charakter“ haben.

Eine interessante Entwicklung in dem Bereich sind Frameworks für Hybrid-Apps wie PhoneGap. Hier wird versucht, die Vorteile der beiden Welten miteinander zu vereinen.

Mobile360: Es gibt eine Tendenz hin zur App und weg vom Web, wie auf dem iPhone. In welche Richtung könnte sich das mobile Web bewegen?

Bartels: Um das offene mobile Web attraktiv zu halten, brauchen wir eine Möglichkeit, Web-Apps über die Stores zu verkaufen und zu vertreiben. Ich erwarte, dass Google (und Apple?) endlich den Schritt gehen, Web-Apps nicht mehr nur per URL, sondern auch per Market bzw. App Store offiziell „installierbar“ zu machen. Au-ßerdem muss sich im mobilen Web eine Bezahlmethode etablieren, die die Monetarisierung von mobilen Web-seiten vorantreibt.

Mobile360: Welche Folgen für das Web können Tablets wie das iPad haben, und können sie den Desktoprech-ner auf Dauer ersetzen?Bartels: Apple setzt auf sehr elegante Weise den Fokus auf Usability und Design. Man sieht schon jetzt die po-sitiven Folgen: Viele Webseiten werden bedienbarer und spielen mit spannenden Oberflächen. Ersetzen werden Tablets in der heutigen Form den Rechner aber nicht; wer schon mal versucht hat, einen Tag lang anstelle vom Notebook mit einem Tablet zu arbeiten, der weiß, was ich meine.

Mobile360: Welche mobile Plattform könnte irgend-wann dauerhaft über alle anderen dominieren? Oder bleibt es bei vielen verschiedenen Betriebssystemen für Smartphones?Bartels: Anforderungen an Handys sind so unterschied-lich wie die Menschen selbst, und der Markt entwickelt sich so schnell. Ich glaube, so schnell wird uns nicht langweilig werden.

Mobile360: Warum ist die Android-Plattform zu emp-fehlen und wo liegen die besonderen Stärken?Bartels: Für den Entwickler bietet die Android-Plattform eine riesige Spielwiese, auf der er sich nach Herzenslust austoben kann. Er braucht keine neue Programmier-sprache lernen, denn Java ist ja weit verbreitet; er kann mit dem Betriebssystem arbeiten, das ihm gefällt – denn Android lässt sich nicht nur von einem Mac aus ent-wickeln; und er kann direkt starten, denn sowohl SDK als auch IDE sind frei verfügbar. Genauso schnell und unkompliziert geht es auch, sich als Entwickler bei Google anzumelden und schließlich seine eigene erste App hochzuladen. Für Brands steht und fällt die Ent-scheidung pro/contra Android mit der Verbreitung der Geräte. Die aktuellen Zahlen zeigen den Verkauf von Android-Devices, dass Android neben iOS eine feste Stellung einnehmen wird. Derzeit ist eine Android App für viele aber noch nice to have, innovative Unterneh-men setzen aber schon jetzt auf den Trend. Ich hoffe, es kommt demnächst mal wieder ein Android Device auf den Markt, das in den Hosentaschen der Entscheider landet.

Mobile360: Ist Android besser für das Mobile Web als das geschlossene System iOS?Bartels: Na ja, eigentlich hat sich ja gezeigt, dass erst das iPhone dem Mobile Web zur Trendwende verholfen hat. Vor 2007 haben zwar alle geglaubt, dass Mobile das Ding der Zukunft wird, aber gekommen ist es nicht

Manchen Mobile Designs sieht man an, welches Handy der

Designer in der Hosentasche hat.

InTERvIEw | Magazin

wirklich. Dank Apple ist Mobile Realität geworden, und die Idee des geschlossenen Systems hat die Fragmentie-rung, unter der das Mobile Web immer gelitten hat, ausgeschlossen und die Landschaft geprägt. Ich bin kein Freund von Apples Walled-Garden-Politik und freue mich daher, dass Android jetzt Zeichen in Richtung Of-fenheit setzt und damit hoffentlich Schule macht.

Mobile360: Ein aktuelles und sehr heißes Thema: Ora-cle vs. Google. Was bedeutet das für Android? Sehen wir ein System sterben?Bartels: Für mich klingt das zunächst mal eher nach Sä-belrasseln, ich denke nicht, dass so eine Klage die An-droid-Plattform verändern wird. Viel problematischer sehe ich die Situation für Java selbst. Das System hat doch sehr von seiner – von Sun praktizierten – Offen-heit gelebt und profi tiert. Wenn jetzt jeder, der Java in eigenen Plattformen einsetzt, mit Klagen von Oracle rechnen muss, ist das sicher kein Motor für die Zukunft von Java…

Mobile360: Stichwort Fragmentierung: Besteht nicht die Gefahr, dass Android genauso endet wie JavaME, in einem Sumpf der Fragmentierung?

Anzeige

Bartels: Ich bin gespannt, wie Google dieses Problem lösen und in den Griff bekommen will. Schon jetzt hat man es als Entwickler nicht leicht, alle auf dem Markt befi ndlichen Android-Geräte zu unterstützen. Viele Apps laufen daher erst ab 2.0, weil ältere Versionen Probleme bereiten. Mittlerweile fragen auch wir unsere Kunden, ob sie ihre App auf 1.5 lauffähig haben wol-len. Teilweise muss das schon in der Konzeptionsphase bedacht werden, da gewisse Konstellationen, die auf an-deren Plattformen ganz selbstverständlich sind, bei An-droid erst mit Version 2.0 möglich wurden. Das erinnert mich dann stark an meine Zeit als JavaME-Entwickler, als ich die Hälfte der Zeit mit Endgeräte-Testing, Por-tierung und Programmierung von Workarounds ver-bringen musste, damit die Spiele auf den wichtigsten Devices liefen. Der offene Ansatz von Android zeigt hier seine Schattenseiten – und auch die Gerätehersteller sind hier gefordert. Die auf dem Markt befi ndlichen Geräte müssen regelmäßig mit Updates versorgt werden; und die Updates müssen vor allem auch von jedem Durch-schnittsuser einspielbar sein.

Mobile360: Herr Bartels, wir danken Ihnen für das Ge-spräch.

Anzeige

�� | Magazin

ANDROID360www.android360.de 13

wirklich mitgebracht haben. Solche Prozesse haben in der Vergangenheit selten zu etwas geführt.Zitat: Arno Becker

Dass Oracle Google verklagt, kommt wahrscheinlich für die meisten sehr überraschend. Insbesondere da mei-ner Meinung nach Google mit GWT, Google AppEn-gine für Java und Android stark zur Renaissance von Java beigetragen hat und damit den Wert der Marke Java hoch gehalten hat. Ich hoffe, dass sich die beiden Giganten schnell friedlich einigen können und dass sich die Java-Community über diese Klage nicht entzweit. Oracle hat sich in der jüngsten Vergangenheit vorbild-lich verhalten, als eine Änderung in der JVM Probleme für Eclipse-User verursacht hat. Hoffen wir, dass dieses Problem ebenso schnell und professionell beigelegt wer-den kann.

Zitat: Lars Vogel

Wer die Diskussionen zwischen Apache und Sun im JCP (Java Community Process) in den letzten Jahren mitver-folgt hat, dürfte über die kürzlich eingereichte Klage von Oracle gegen Google nicht sonderlich verwundert sein, denn Androids Anwendungsplattform basiert überwie-gend auf dem Harmony-Projekt von Apache. Google hat sich mit dem Trick, den Java-Bytecode in Dalvik-Code zu konvertieren und auf einer eigenen VM auszufüh-ren, geschickt aus der Affäre gezogen. Man darf zwar die Android-Anwendungsplattform nicht Java nennen, aber die Entwicklung erfolgt eben in der Java-Sprache. Google hat mit Android inzwischen eine erfolgreiche mobile Plattform etabliert. Obwohl Sun eigentlich von Anfang an der Auffassung war, dass bei Android Suns geistiges Eigentum unberechtigt verwendet wird, ist man nicht dagegen vorgegangen. Hierfür mag es verschiedene Gründe geben. Ob nun Sun seinerzeit mit internen Pro-blemen beschäftigt war und man sich deshalb nicht mit dem übermächtigen Google anlegen wollte oder ob man gezielt erst einmal abwarten wollte, wie sich die Android-Plattform am Markt etabliert, ist nicht wirklich klar.

Für die Entwicklergemeinde und für den Fortschritt der mobilen Industrie insgesamt war es wohl ein Glück, dass Sun Android bisher nicht gestoppt hat. Dass Oracle nach der Übernahme von Sun Anfang des Jahres nun sei-ne Rechte durchsetzen will, war zu erwarten. Wenn das allerdings bedeuten würde, dass Android nicht weiter existiert, wäre das vor allem für die Entwicklergemein-de, die viel in diese Plattform investiert hat, ein herber Verlust. Es ist jedoch zu vermuten, dass es letztendlich zu irgendeinem Deal zwischen Oracle und Google kom-men wird. Wollen wir hoffen, dass die Sache für Android gut ausgeht und die offene mobile Plattform – egal ob mit getarntem oder offiziellem Java – ihren Erfolg fort-führen kann.

Zitat: Kay Glahn [4]

Der Schutz geistigen Eigentums ist wichtig, um die Be-reitschaft von Investitionen in den betroffenen Bereich

zu sichern. Ob in diesem Fall wirklich Patent- bzw. Urheberrechte verletzt wurden, muss erst noch ge-klärt werden. Es wäre allerdings bedauerlich, wenn ein Rechtsstreit die aktuelle Dynamik im Android-Umfeld bremst und Erneuerungskraft dieses Betriebssystemre-bellen schwächt.

Zitat: Heiko Sasse

zukunftsmusikIn einer Stellungnahme gegenüber dem Onlinemaga-zin TechCrunch [5] zeigt sich Google „enttäuscht über Oracles Entscheidung, sowohl Google als auch die Open-Source-Java-Community mit einer haltlosen Kla-ge anzugreifen.“ Nun lässt sich zwar trefflich darüber streiten, ob Google wirklich der große Verteidiger der Java-Open-Source-Community ist – Diskussionen dar-über, wie Open Source Android letzten Endes wirklich sei, wurden in der jüngeren Vergangenheit sehr kontro-vers geführt – dennoch muss man sich die Frage stellen, welche Szenarien in Zukunft auf Anwender und Ent-wickler warten könnten. Die Kollegen von JAXenter haben zwei Extreme beleuchtet: In einem Worst-Case-Szenario beleuchten sie in einem fiktiven Gedankenspiel, was der Community im schlimmsten Fall drohen könnte [6]. Das Fazit, das „einer ganz erheblichen tektonischen Verschiebung der IT-Industrie gleichkäme“: Was Java betrifft, hat Oracle bereits alles, und es könnte sein, dass die Motivation, das vorhandene Netzwerk zu monetari-sieren, bei der Abwägung der Ziele überwiegt. Deutlich besser kommt die Community zwar im Best-Case-Sze-nario weg [7], dennoch sollte man sich stets vor Augen halten, dass die Wahrheit am Ende irgendwo dazwi-schen liegen wird.

Wenn Sie sich über die Entwicklung auf dem Laufen-den halten möchten, sei Ihnen die Serie „Oracle versus Google“ von den Kollegen von JAXenter empfohlen [8]. Dort werden stets alle aktuellen Ereignisse und Kommentare aus der Community zusammengefasst. Wie auch immer sich die Geschichte entwickeln wird: Es bleibt zu hoffen, dass sich beide Parteien schnell und gütlich einigen können. Hier geht es um sehr viel mehr als nur ein vielversprechendes Smartphone-OS.

Links & Literatur

[1] Offizielle Oracle-Mitteilung: http://bit.ly/A360_OvsG_1

[2] Oracle Google Complaint: http://bit.ly/A360_OvsG_2

[3] An update on JavaOne: http://bit.ly/A360_OvsG_3

[4] Vollständiger Kommentar von Kay Glahn: http://bit.ly/A360_OvsG_4

[5] �tellungnahme bei �echCrunch: http://tcrn.ch/A360_OvsG_5

[6] Worst-Case-�zenario: http://bit.ly/A360_OvsG_6

[7] Best-Case-�zenario: http://bit.ly/A360_OvsG_7

[8] �erie „Oracle versus Google“: http://bit.ly/A360_OvsG_8

Magazin | Android 2.2

www.android360.deANDROID36014

von Markus Junginger

Bevor wir uns den neuen und vielversprechenden Funktio-nen wie External Storage, Push, Data Backup und Fehler-reporting zuwenden, kurz ein Blick zurück: Zwischen der Veröffentlichung des SDKs für Android 1.0 im September 2008 und des SDKs für 2.2 sind nur 20 Monate vergangen. In dieser Zeit wurden mit 1.5, 2.0, 2.1 und jetzt 2.2 bereits fünf Versionen mit wesentlichen Neuerungen herausgege-ben (Version 1.1 war ein Bugfix-Release). Die Entwick-lungsgeschwindigkeit ist einerseits gut für die Plattform, andererseits auch eine Herausforderung für Entwickler,

die jedes halbe Jahr mit neuen APIs konfrontiert werden. Schaut man auf die Statistik der API-Änderungen, sieht man schnell, dass es nicht nur Kleinigkeiten waren, die sich verändert haben: Drei bis fünf Prozent Änderungen in Bezug auf die Gesamtgröße der APIs sind deutlich (Abb. 1). Die Quote an API-Neuerungen von Android 2.2 liegt mit 6 % deutlich an der Spitze.

Um auf die neuen Features zuzugreifen, müssen Ent-wickler zunächst den entsprechenden API-Level angeben, der für Android in Version 2.2 bei 8 liegt. Ein entspre-chender Manifest-Eintrag, der beispielsweise mindes-tens Android 1.6 erfordert, aber auch Features der

Die neue Android-Version bringt viel Neues – das Wichtigste lesen Sie hier

Was gibt’s neues bei android 2.2?

Auf der Google I/O 2010 präsentierte Google in einer Keynote Android 2.2, das umfang-reiche und spannende neue Möglichkeiten für Entwickler eröffnet. Die beachtliche Ge-schwindigkeit, mit der sich Android weiterentwickelt, bestätigt sich insbesondere in dieser Version mit dem Codenamen „Froyo“.

Android 2.2 | Magazin


Abb. 1: Android 2.2 bietet wieder einmal viel Neues

Abb. 2: Vorbereitende Schritte für C2DM

Was gibt’s neues bei android 2.2?

Version 2.2 benutzt, sieht dann wie folgt aus: <uses-sdk android:minSdkVersion="4" android:targetSdk Ver sion ="8"/>.

apps auf SD-KarteLang erwartet ist die Möglichkeit, Applikationen (Apps) auf eine SD-Karte installieren zu können. An-droid besitzt einen internen Telefonspeicher, dessen Größe im Vergleich zu SD-Karten meist deutlich ge-ringer ist. In diesem internen Speicher mussten vor Android 2.2 das System selbst sowie sämtliche Apps mit ihren Daten Platz finden. War dieser Speicher voll, konnten keine weiteren Apps installiert werden. Android 2.2 schafft Abhilfe, allerdings nicht automatisch. Be-stehende Apps werden unverändert weiterhin in den internen Speicher gelegt. Der Entwickler muss das Fea-ture explizit im Manifest der App freischalten. Dazu kommt das Attribut android:installLocation des ma-nifest-Elements zum Einsatz. Es kann drei Werte an-nehmen: internalOnly, auto und preferExternal. Der Default-Wert internalOnly steht für das bisherige Ver-halten, nur den internen Speicher zu nutzen. Mit auto wird zunächst im internen und mit preferExternal im externen Speicher installiert, solange hier Speicherplatz frei ist. Wenn nicht, wird die Anwendung auf dem je-weils anderen Ort installiert. Bei den beiden letzten Varianten kann der Nutzer zudem über die Einstellun-gen die App zwischen beiden Orten hin und her kopie-ren. Bei einer Installation auf dem externen Speicher wird die App gerätespezifisch verschlüsselt und kann somit nicht auf anderen Geräten ausgeführt werden. Zu beachten ist, dass für Applikationsdaten immer der interne Speicher benutzt wird. Bei der Entscheidung, welcher Speicherort bevorzugt werden soll, ist es da-her sinnvoll, die Größe der App zu betrachten, und zu bedenken, dass Apps auf dem externen Speicher nur dann ausgeführt werden können, wenn die SD-Karte verfügbar ist. Letzteres ist beispielsweise nicht der Fall, wenn das Gerät mit dem Desktoprechner verbunden ist und dieser auf die SD-Karte zugreift.

Push mit C2DMCloud-to-Device-Messaging (C2DM) hat Google sei-nen Dienst genannt, mit dem Nachrichten auf Geräte gepusht werden können. Musste zuvor jede Applikati-on periodisch nach Neuigkeiten beim jeweiligen Dienst nachfragen (Polling), kann dies nun zentralisiert vom Dienst aus angestoßen werden, sobald Neuigkeiten vor-liegen. Die Vorteile dieser Technologie liegen auf der Hand: Neues ist schneller verfügbar, der Akku wird ge-schont und der Netzwerk-Traffic sinkt.

Beim Push sind drei Systeme beteiligt: Android-Cli-ents, Applikationsserver sowie die Google Cloud. Als Entwickler sind wir für die Client-App und Applikati-onsserver verantwortlich. Für die Nutzung von C2DM sind drei vorbereitende Schritte notwendig, wie Abbil-dung 2 skizziert: Im ersten Schritt muss die Client-App den C2DM-Servern die Sender-ID und die Applikations-

ID mitteilen. Die Sender-ID ist die E-Mail-Adresse des Accounts, den man in der Regel für eine App anlegt. Die Applikations-ID ergibt sich aus dem Package-Namen, wie er im Manifest vergeben ist. Wie man am dazugehö-rigen Code sieht, wird der erste Schritt mit dem Starten eines Service über einen Intent realisiert:

Intent intent = new Intent("com.google.android.c2dm.intent.REGISTER");intent.putExtra("app", PendingIntent.getBroadcast(this, 0, new Intent(), 0);intent.putExtra("sender", "[email protected]");startService(intent);

Im zweiten Schritt muss die App die mittels eines Broad-castReceivers die Antwort mit der Registrierungs-ID entgegennehmen. Um den dazugehörigen Code etwas zu vereinfachen, wurde die Fehlerbehandlung im Fol-genden weggelassen:

public void onReceive(Context context, Intent intent) { if ("com.google.android.c2dm.intent.REGISTRATION".equals(intent. getAction ()) { String id = intent.getStringExtra("registration_id"); if (id != null) { // Schritt 3: ID an Applikationsserver weitergeben } }}

Nach Erhalt der Registrierungs-ID kann sie im dritten Schritt dem Applikationsserver mitgeteilt werden. Dies



sollte in einem separaten Thread oder Service erfolgen, da der BroadcastReceiver normalerweise im Haupt- Thread der App aufgerufen wird und dieser niemals blockiert werden sollte. Die Registrierungs-ID sollte für die weitere Verwendung gespeichert werden.

Mithilfe der Registrierungs-ID kann der Applikati-onsserver über die Cloud einzelne Geräte adressieren und diesen Nachrichten zukommen lassen (Abb. 3). Realisiert wird dies mit einem HTTP-POST-Request an den URL https://android.apis.google.com/c2dm/send mit entsprechenden Parametern: Am wichtigsten ist der Parameter registration_id für die Registrierungs-ID. Applikationsdaten kann man mit Parametern nach dem Schema data.KEY_NAME übergeben (KEY_NAME ist frei wählbar). Diese werden später unter dem entsprechenden Key KEY_NAME der App übergeben werden. Mit den optionalen Parametern collapse_key und delay_while_idle kann man die Nachrichtenzustel-lung beeinflussen: Mit collapse_key können überholte Nachrichten verworfen werden, und delay_while_idle bewirkt, dass die Zustellung nur dann erfolgt, wenn das Gerät tatsächlich aktiv ist. Die Werte von collapse_ key sind beliebige Strings, mit denen definiert wird, ob eine Nachricht eine vorhergehende überflüssig macht. Es wird immer nur die neueste Nachricht mit einem be-stimmten collapse_key übermittelt. Um z. B. einen ein-fachen Trigger zu realisieren, könnte man den String „mein-trigger“ als collapse_key verwenden. Versendet der Server mehrere Trigger, die der Client nicht entge-gennimmt, da er beispielsweise offline ist, so wird nur der letzte Trigger verschickt, wenn der Client online geht. Diese Optimierung spart vor allem Netzwerkres-sourcen. Schließlich muss aus Sicherheitsgründen dem Request noch ein Token für die Autorisierung über-geben werden. Damit wird verhindert, dass nicht ir-gendjemand Nachrichten in fremde Apps einschleust. Das Anfordern eines Tokens ist nicht trivial, weshalb wir an dieser Stelle auf die Webseiten [1] und [2] ver-weisen. Hat der Applikationsserver die Nachricht er-folgreich an die Cloud übergeben, wird sie von hier aus an den Client weitergereicht, sobald dieser verfüg-bar ist. Die App muss dazu nicht laufen, sondern wird bei Bedarf gestartet, sobald Nachrichten für die App empfangen werden. Ein BroadcastReceiver stellt auch hier die Schnittstelle dar, ähnlich wie beim Empfang der Registrierungs-ID. Hier kann derselbe Broadcast-Receiver benutzt werden und anhand der Action die

Unterscheidung gemacht werden. Zum besseren Ver-ständnis noch ein Codebeispiel für den Nachrichten-empfang, das einen zusätzlichen String „mein-extra“ aus der Nachricht bezieht:

public void onReceive(Context context, Intent intent) { if ("com.google.android.c2dm.intent.RECEIVE".equals(intent.getAction ()) { String meineDaten = intent.getStringExtra("mein-extra"); // Z.B. beim AppServer Daten anfragen, UI Update, etc. }}

Meist empfiehlt es sich, dass Push-Nachrichten nicht selbst die Applikationsdaten enthalten, sondern ledig-lich einen Trigger für die Applikation darstellen, worauf die Applikation beim Server nach Daten anfragt. Das hat zwei Gründe: Zum einen sind Nachrichten in ihrer Größe beschränkt und zum anderen ist die Nachrichten-zustellung nicht garantiert.

Wie es der aufmerksame Leser sicher schon bemerkt hat, haben wir bislang die nötigen Manifest-Einträge unterschlagen, die in der Datei AndroidManifest.xml ge-macht werden müssen. Zunächst benötigt die App die Er-laubnis, mit dem Internet zu arbeiten, also den android. permission.INTERNET-Eintrag. Für die C2DM-Regis-trierung und den Nachrichtenempfang kommt com.google.android.c2dm.permission.RECEIVE dazu. Schließ-lich empfiehlt sich noch das Empfangen von Nachrichten auf eine App zu beschränken, was mit einer neu definier-ten Permission gemacht wird. Alle Permissions zusammen sehen dann wie folgt aus:

<uses-permission android:name="android.permission.INTERNET" /><uses-permission android:name="com.google.android.c2dm.permission. RECEIVE" /><permission android:name="com.example.myapp.permission.C2D_MESSAGE" android:protectionLevel="signature" /><uses-permission android:name="com.example.myapp.permission.C2D_ MESSAGE" />

Auch die beiden BroadcastReceiver für die Registrie-rung und den Nachrichtenempfang dürfen natürlich nicht fehlen. Abweichend von den vorangegangenen Beispielen definieren wir der Einfachheit halber hier nur einen BroadcastReceiver, der beide Ereignisse in Emp-fang nimmt:

<receiver android:name=".C2DMReceiver" android:permission="com.google. android.c2dm.permission.SEND"> <intent-filter> <action android:name="com.google.android.c2dm.intent.RECEIVE" /> <category android:name="com.example.myapp" /> </intent-filter> <intent-filter> <action android:name="com.google.android.c2dm.intent.REGISTRATION" /> <category android:name="com.example.myapp" /> </intent-filter></receiver>

Abb. 3: Nachrichtenadressierung anhand der Registrierungs-ID

www.android360.de

Nachdem die grundlegende Funktionsweise von C2DM erklärt ist, möchten wir abschließend noch auf die C2DM-Website [3] verweisen: Insbesondere da bei Redaktionsschluss C2DM noch nicht allen Entwicklern offenstand, kann es hier wichtige Ergänzungen geben.

BackupsEin weiterer Dienst im Zusammenhang mit der Google Cloud ist das Data Back-up API. Damit können Applikationsdaten auf Servern von Google gesichert werden, damit sie wiederhergestellt werden können, wenn das Gerät gewechselt wird. Für den Anwender bedeutet dies eine beträchtliche Erhöhung des Kom-forts, wenn er die Applikationen auf seinem neuen Gerät im selben Zustand wie-derfindet, wie er sie auf dem alten Gerät hatte. Anderseits haben Nutzer auch die Möglichkeit, Backups in den Einstellungen ihres Geräts auszuschalten, wenn sie beispielsweise Bedenken gegenüber der zentralen Speicherung der Applikations-daten haben. An dieser Stelle sei noch darauf hingewiesen, dass es sich um eine reine Sicherung handelt und keine Synchronisation zwischen mehreren Geräten, die gleichzeitig genutzt werden, umfasst. Dies wäre eine interessante Ausweitung der Funktionalität und sicherlich keine große Überraschung, wenn Google eine entsprechende Erweiterung in einer zukünftigen Version von Android vorstellen würde. Fangen wir diesmal mit den Manifest-Erweiterungen an:

<application android:backupAgent="MyBackupAgent" ...> ... <meta-data android:name="com.google.android.backup.api_key" android:value="123" /></application>

Mittels des android:backupAgent-Attributs wird eine eigene Klasse angege-ben, die von BackupAgent abgeleitet wird und eine zentrale Rolle spielt. Da-neben muss man noch einen Key für den Backup-Service angeben, den man sich im Vorfeld bei Google anfordern muss [4]. BackupAgent leitet sich von der Context-Klasse ab, die Android-Entwickler unter anderem als Basisklasse von Activity kennen. So hat auch BackupAgent einen Lifecycle, der in diesem Fall um zwei zusätzliche Lifecycle-Methoden erweitert wurde: onBackup und on Restore. Diese werden aufgerufen, wenn ein neues Backup ansteht bezie-hungsweise wenn ein Backup eingespielt werden soll. Hier ist man selbst dafür verantwortlich, die entsprechenden Daten anhand von der Methode überge-benen Hilfsobjekten zu verarbeiten. Einfacher wird es, wenn man von Back-upAgentHelper ableitet, die BackupAgent um einige praktische Methoden erweitert. Die Implementierung der Methoden onBackup und onRestore ent-fällt. Stattdessen gibt es Helper für SharedPreferences und Dateien, die einem diese Arbeit im Wesentlichen abnehmen. Das Vorgehen ist schnell an einem Codebeispiel erklärt, das SharedPreferences sowie die Dateien „datei1“ und „datei2“ für das Backup vorsieht:

void onCreate() { addHelper("prefs_key", new SharedPreferencesBackupHelper(this, "prefs")); addHelper("myfiles", new FileBackupHelper(this, "datei1", "datei2"));}

Da ein BackupAgent parallel zu den Activities der App ausgeführt werden kann, muss beachtet werden, dass mehrere Threads um die Daten konkurrieren können. Bei SharedPreferences ist das in der Regel kein Problem, da es von sich aus thread- safe ist. Bei Dateien sollte man jedoch unbedingt Locks setzen, um korrupte Da-teien zu vermeiden. Nun fehlt nur noch der Trigger, der dem Android-System mitteilt, dass neue Daten für das Backup bereitstehen: Die Methode dataChanged der BackupManager-Klasse dient genau diesem Zweck. Somit hält sich der be-nötigte Zusatzaufwand für das Backup von einfachen Daten in Grenzen. Bei der

Anzeige



Entwicklung hilft zusätzlich das Shell-Tool bmgr [5], mit dem man unter anderem Backup- und Restore-Operatio-nen anstoßen kann.

JiT-CompilerFür viele steht ein Just-in-time-Compiler (JIT) schon lange ganz oben auf der Wunschliste neuer Android-Features – mit Android 2.2 ist er endlich da. Damit kön-nen Programme zwei- bis fünfmal schneller ausgeführt werden. Bisher wurde sämtlicher in Java geschriebene Code interpretiert auf Androids virtueller Maschine Dalvik ausgeführt. Dennoch konnten die meisten Apps schon zuvor recht schnell ausgeführt werden. Das hat vor allem zwei Gründe. Zum einen interpretiert Dalvik den Code schneller als übliche Java VMs; laut Google doppelt so schnell. Zum anderen sind weite Teile des Android-API nativ geschrieben, sodass relativ viel Code nicht interpretiert wird. Daher hängt es stark von der App ab, inwieweit sich eine Beschleunigung mit dem neuen JIT-Compiler bemerkbar macht. Am meisten profitieren erfahrungsgemäß Apps mit komplexeren Be-rechnungen, aber zum Beispiel auch die sonst leider zum Ruckeln neigenden ListView-UIs.

Beim JIT-Compiler wurden einige interessante Design entscheidungen getroffen. Zunächst einmal kompiliert Dalvik nicht ganze Methoden, wie es bei JVMs üblich ist, sondern nur Traces, eine wesentlich kleinere Einheit. Google hat eine typische Applikation analysiert und beide Varianten miteinander verglichen: Auf Methodenbasis wurden insgesamt 26 % des Codes kompiliert, während auf der Basis von Traces ledig-lich 2 % kompiliert werden mussten. Wie erwartet ist der Code mit der höheren Kompilierungsquote am Ende schneller, jedoch entstehen durch die Kompilie-rung für den Nutzer oft bemerkbare Wartezeiten am Anfang. Dies und der geringere Speicherbedarf dürf-ten die Gründe dafür gewesen sein, zunächst ganz auf die Kompilierung von Traces zu setzen. Laut Google verbraucht der JIT-Compiler tatsächlich nur 100 KB pro Prozess. Auch wenn der JIT-Compiler in der ersten Version schon sehr brauchbar erscheint, ist sicherlich noch einiges an Potenzial für zukünftige Optimierun-gen drin. Auch Sun hat einige Jahre am Compiler der JVM gefeilt, bis die Geschwindigkeit weitgehend der von C++-Programmen mithalten konnte. Weiteres Po-tenzial hat Dalvik noch bei der Garbage Collection, die in der Version 2.2 leider keine Verbesserungen erfah-ren hat. In zukünftigen Versionen ist jedoch mit gerin-geren Aufräumzeiten zu rechnen.

Weitere neuigkeitenViele Entwickler kennen die Situation: Im Android Market bekommt man schlechte Bewertungen, und falls man Glück hat, schreibt ein Anwender noch „force close“ als Kommentar dazu, wenn die App ab-gestürzt ist. Jedoch fehlte uns Entwicklern jeglicher Ansatzpunkt für eine Ausbesserung des Fehlers. Auch hier hat Android dazugelernt: Stürzt eine App ab, so

werden ab Android 2.2 entsprechende Informationen an Google gesendet, die Entwicklern dann in der De-veloper Console des Android Markets zur Verfügung gestellt werden.

Eine wichtige Neuerung insbesondere für Spieleent-wickler ist das Upgrade auf OpenGL ES 2.0 seitens des Java-API. Damit lassen sich Vertex und Fragment Shader definieren, die auf der GPU ausgeführt werden, um Vertices oder Pixel zu transformieren. Das ist gera-de für grafische Effekte interessant. Im Zusammenhang mit dem NDK ist OpenGL ES 2.0 bereits seit Andro-id 2.0 verfügbar, aber die Entwicklung von C/C++ ist nicht jedermanns Sache, insbesondere wenn man auch sonst viel von dem Android Java-API Gebrauch macht. In Kombination mit dem JIT-Compiler dürfte Android 2.2 damit nochmal wesentlich attraktiver für Spieleent-wickler geworden sein.

Auch Entwickler, die auf den Browser als Plattform abzielen, bekommen neue und interessante Möglichkei-ten an die Hand. Die vom Desktop-Chrome bekannte JavaScript Engine V8 hat Einzug in Android gehalten und stellt aktuell die schnellste mobile JavaScript Engine dar. Der Trend, dass JavaScript-Applikationen immer leistungsfähiger und komplexer werden, wird sich damit auch auf den mobilen Bereich übertragen. Mit Flash 10.1 gibt es darüber hinaus eine weitere Webtechnologie für Android. Zwar muss Flash nachinstalliert werden, dies gestaltet sich aber sehr einfach: Der Browser verweist direkt in den Android Market, wenn Flash noch nicht installiert ist. Dieses Vorgehen hat zudem den Vorteil, dass Flash sehr einfach aktualisiert werden kann.

Auch wenn dieser Artikel zu einem Ende kommen muss, waren es bei Weitem nicht alle Neuigkeiten, die Android 2.2 zu bieten hat. Es gibt noch viel Neues zu entdecken. Neben größeren Neuerungen in den Media- und Camera-APIs, neuen Klassen für die Spracherken-nung und das Device Management wird man in den nächsten Monaten noch etliche Detailverbesserungen bemerken. Insgesamt ist das neue Android-API ein sehr mächtiges und rundes Werkzeug für Entwickler gewor-den, das nur wenige Wünsche offenlässt. Vorerst zumin-dest, denn die nächste Version Gingerbread, die einige UI-Verbesserungen inklusive GPU-Rendering mit sich bringen wird, könnte noch dieses Jahr erscheinen.

Markus Junginger ist Android-Enthusiast und -Entwickler seit dem ersten Prerelease des Android SdKs, das 2007 erschien. Sein Startup greenrobot widmet sich der Entwicklung mobiler Software speziell für Android, mit dem Ziel, das Maximum aus der Plattform herauszuholen.

Links & Literatur

[1] Choosing an Auth Mechanism: http://bit.ly/MT_Android_1

[2] ClientLogin for installed Applications: http://bit.ly/MT_Android_2

[3] C2dM-Framework: http://bit.ly/MT_Android_3

[4] Android Backup Service: http://bit.ly/MT_Android_4

[5] bgmr: http://bit.ly/MT_Android_5

Fragmentierung | Magazin


von markus Stäuble

Seit der ersten Version von Android sind nun knapp 2,5 Jahre ins Land gegangen, und mit Froyo steht nun schon Android in Version 2.2 bereit. Bis diese Version aber auf den meisten Geräten läuft, wird noch einige Zeit ins Land gehen [2]. Auf vielen Geräten läuft heutzutage noch nicht einmal die Version 1.6 (Abb. 1). Durch die vielen Köche ist Android inzwischen stark fragmentiert. Was bedeutet das für Endanwender und Entwickler?

Fragmentiert starkAuf dem Entwicklerportal [3] zu Android ist eine Statis-tik über die Verteilung der unterschiedlichen Versionen von Android dargestellt .

Wie in Abbildung 1 zu erkennen, ist das meistverbrei-tete Android nach Version 2.1 die Version 1.5. Immerhin 27,6 % der Geräte laufen noch mit dieser alten Version. Für Entwickler von Apps ist das schon keine gute Situa-tion; vor allem aber auch für Anwender ist die Situation nicht erfreulich. Anwender haben leider nicht immer die

Wahl, ob sie mit ihrem Gerät auch auf die neueste Versi-on gehen. Dies liegt mitunter daran, dass Mitglieder der OHA auch proprietäre Erweiterungen an Android ma-chen. Aufgrund der Lizenz [5] von Android müssen diese Erweiterungen aber nicht in die Plattform zurückfließen. An dieser Stelle priorisieren Unternehmen den Wettbe-werbsvorteil höher als den einheitlichen Plattformgedan-ken. Ein weiterer Grund für die Fragmentierung ist die Geschwindigkeit bei der Geräteentwicklung. Da Software und Hardware von unterschiedlichen Firmen entwickelt werden, besteht hier auch keine Taktung in Bezug auf die Releasezyklen. Somit würde ein Update für Anwender äl-terer Geräte erst einmal die Situation verschlechtern. Ein Dorn im Auge einiger Mitglieder der OHA ist auch die starke Präsenz von Google in diesem Thema. Das Nexus One [6] hat bei vielen Mitgliedern der OHA kein Lächeln auf das Gesicht gezaubert. Da am Ende doch wieder der EBIT zählt, wird die Fragmentierung in Zukunft mit Si-cherheit nicht abnehmen. Auch dass HTC [7] über eine eigene Plattform nachdenkt, zeigt, dass die Einheitlichkeit in Schieflage geraten ist.

Die Gründe für die Android-Fragmentierung

Vision trifft RealitätAls 2005 Google das kleine Start-up Android Inc. aufgekauft hatte, war noch nicht abzusehen, welche Entwicklung sich daraus ergeben könnte. Im November 2007 folgte die Gründung der Open Handset Alliance (OHA) [1]. Aus Sicht der Anwender und Entwickler war es eine gute Nachricht: endlich ein Zusammenschluss wichtiger Firmen im mobilen Bereich, endlich ein einheitliches Betriebssystem für die etlichen Geräte, endlich die Möglichkeit für eine größere Auswahl an verfügbaren Zusatzprogrammen. Und alles offen und nicht proprietär. Mit der Pro-grammiersprache Java, die viele Softwareentwickler sprechen, wird auch die Möglichkeit für noch mehr zusätzliche Funktionen geboten.

Magazin | Fragmentierung


Das Problem mit dem app StoreSeit Anfang Mai 2010 wird das Gerücht kolportiert, dass Motorola das Unternehmen Azingo [8] und somit das mobile Betriebssystem Azingo Mobile gekauft hat – auch wenn noch nicht offiziell bestätigt, verwundern würde es nicht. Beim ersten Blick darauf stellt man sich die Frage, warum ein Mitglied der OHA ein neues Be-triebssystem erwirbt. Auf den zweiten Blick fallen einige Gründe ein; einer davon ist der große Erfolg des App Store von Apple.

Inzwischen ist sicherlich bei den meisten Hardware-herstellern und auch Netzbetreibern angekommen, dass der große Umsatz inzwischen durch die kleinen Zusatz-programme, den so genannten Apps, gemacht wird. Um auch von diesem Kuchen ein Stück abzukommen, möchte jeder in diesem hart umkämpften Markt agie-ren. Besonders lukrativ wird es, wenn man selbst einen App Store betreibt. Im Fall von Apple wandern näm-lich bei jeder Transaktion im App Store 30 % an Apple. Da schaut man als Konkurrenzunternehmen wie Mo-torola oder HTC doch neidisch auf diese Umsätze. Da verwundert es nicht, wenn manche Unternehmen über einen eigenen App Store nachdenken und somit die Vi-sion einer einheitlichen Plattform wieder schwindet. Ob der Alleingang auch Erfolg verspricht, bleibt fraglich. Kommen wird er trotzdem bei dem einen oder anderen Unternehmen.

also doch ein iOS?Bereits zum Start hatte die OHA einige bekannte und große Namen auf der Liste der Mitglieder. Laut FAQ [9] der OHA sind inzwischen 71 Mitglieder bei der OHA dabei. Da bei allen Mitgliedern am Ende des Jah-res eine Bilanz zu rechtfertigen ist, wird schnell klar, dass es hier nicht nur ein Geben, sondern auch ein Nehmen ist.

Trotz der Fragmentierung setzt Android aber einiges in Bewegung, wovon vor allem Anwender, aber auch Entwickler profitieren. Dass Hardware nicht immer mit der Software mithalten kann, war eigentlich schon im-

mer so. Auch Android kann das nicht ändern. Irgend-wann muss eben ein neues Gerät her. Wenn darauf eine freie Plattform wie Android installiert ist, umso besser. Man muss einfach davon Abstand nehmen, dass es das eine An droid auf allen Geräten geben wird. Hersteller versuchen nun einmal, Betriebssystem und Hardware optimal aufeinander abzustimmen, da kann nicht im-mer mit der Version des allgemeinen Android mitge-halten werden. Ein Grund, warum einige neidisch auf iOS von Apple schielen. Das ist aber proprietär.

Fragmentierung kann man auch als Belebung des Wettbewerbs sehen. Wenn dadurch neue Plattformen entstehen, werden diese nicht schlechter als bereits vor-handene. Erfreulich ist auf jeden Fall, dass Android den Anstoß für offene Plattformen auch im mobilen Bereich gegeben hat. Das ist so einfach nicht mehr umzukehren. Freuen wir uns auf Froyo und einen belebten mobilen Markt.

Links & Literatur

[1] Open Handset alliance (OHa): http://www.openhandsetalliance.com/

[2] Froyo ist nicht für jeden da: http://mobile360.de/froyo-ist-noch-nicht-fuer-jeden-da-11866.html

[3] entwicklerportal zu android: http://developer.android.com/index.html

[4] android Platform Versions: http://developer.android.com/resources/dashboard/platform-versions.html

[5] android-Lizenz: http://source.android.com/source/licenses.html

[6] nexus One: http://www.google.com/phone/

[7] Kommt bald ein HtC OS?: http://mobile360.de/kommt-bald-ein-htc-os-10925.html

[8] azingo: http://www.azingo.com

[9] FaQ der Open Handset alliance: http://www.openhandsetalliance.com/oha_faq.html

Markus Stäuble ist Senior it Consultant bei einer internationalen Werbeagentur. er schreibt regelmäßig artikel für diverse Fachzeit-schriften und gibt sein Wissen gerne in Vorträgen wieder. er hat das Buch „Programmieren fürs iPhone“ geschrieben.

Abb. 1: Verteilung der Android-Versionen, Quelle: developer.android.com [4]

Android-ExpAnsion | Magazin


von sven Mohr

Die mobile Nutzung des Internets wird derzeit zu ei-nem Massenphänomen. Hierzu tragen wesentlich die immer leistungsfähigeren Geräte bei, die im High-End-Segment mittlerweile den Desktoprechnern der Vergangenheit an Rechen- und Speicherleistung in nichts mehr nachstehen. Auch die Kapazität der Mo-bilfunknetze hat sich bei gleichzeitig fallenden Tarifen verbessert und wird noch weiter ausgebaut, sodass Smartphones zu einer echten Alternative zum Desktop oder Notebook werden. Auch bei der Benutzerfreund-lichkeit hat es in den Bereichen Nutzerführung und Eingabemöglichkeiten große Fortschritte gegeben. Eine intuitivere Bedienbarkeit macht die Geräte dieses Seg-ments zunehmend auch für wenig technikaffine Nut-zer attraktiv, wodurch zunehmend der Massenmarkt angesprochen werden kann. Hierdurch wiederum er-

schließen sich neue Anwendungsmöglichkeiten: Smart-phones, bisher eine Domäne der Businesswelt, werden zur Multimedia plattform für jedermann.

Software und Dienste sind zu treibenden Faktoren gewordenEntwicklung und Wettbewerb im mobilen Bereich wa-ren in der Vergangenheit in erster Linie von den Fakto-ren Hardware und Netzkapazität bestimmt. Nun wird in zunehmendem Maße die Verfügbarkeit attraktiver Anwendungen zum entscheidenden Kriterium. Einen Wendepunkt markiert hierbei der Erfolg von Apples iPhone, der sich nicht alleine aus dem Hype um die Marke Apple oder der Attraktivität des Geräts heraus erklären lässt. Entscheidend war vielmehr die gleichzei-tige Bereitstellung einer Entwicklungsumgebung sowie der Vertriebsplattform App Store, über die es externen Entwicklern ermöglicht wurde, mit kleinem Aufwand

Wie Android die (mobile) Welt erobert

iOS unter Druck Die zunehmend wachsende Attraktivität mobiler Internetnutzung hat dazu geführt, dass die Entwicklung und Verbreitung von Anwendungen in diesem Bereich derzeit boomt. Besonders freuen dürfte die Leser dieses Hefts, dass mit Android eine Java-basierte Ent-wicklungsplattform einen weltweiten Siegeszug angetreten hat und binnen kürzester Zeit zu einer führenden Plattform in diesem Segment geworden ist.

Magazin | Android-ExpAnsion


selbstentwickelte Anwendungen zu erstellen und zu vermarkten. Ein Angebot, das voll einschlug. Innerhalb kurzer Zeit haben Entwickler auf der ganzen Welt zahl-lose Apps (derzeit etwa 230 000) produziert und in den App Store eingestellt. Dieses breit gefächerte Angebot wiederum macht das Gerät erst individuell und vielseitig und damit wirklich interessant.

Der Erfolg des iPhones markiert einen Paradigmen-wechsel, der dadurch gekennzeichnet ist, dass nun auch im mobilen Sektor Software und damit verbundene Dienste zu wesentlichen Faktoren werden. Die Zeiten hingegen, in denen sich allein über die Leistungsmerk-male von Endgeräten oder Netzbandbreiten entschei-dende Wettbewerbsvorteile erzielen ließen, sind vorbei.

neue anwendungsmöglichkeiten tun sich aufBisher handelte es sich bei den ernsthaften Anwen-dungen auf Smartphones und PDAs in erster Linie um „kleine Brüder“ von Desktopanwendungen aus dem Of-fice-Bereich. Natürlich sind auch weiterhin Adress- und Terminverwaltung, E-Mail oder die Wiedergabe von Multimediainhalten von zentraler Bedeu-tung. Sie werden aber inzwischen als Stan-dard vorausgesetzt.

Wodurch aber wer-den die Innovationen in diesem Bereich mo-mentan getrieben? Da wären zum einen Zeit-schriften, Verlage und andere Anbieter von Inhalten, die derzeit die Präsenz in der mobilen Welt durch die Ver-breitung eigener Anwendungen ausbauen. Ein Aspekt ist dabei, dass man nicht Fehler der Vergangenheit wie-derholen will, als die Entwicklung des Internets vielfach unterschätzt oder schlicht verschlafen wurde. Stattdessen hat es nun den Anschein, dass jeder von Anfang an dabei sein will, um sich in einer sich verändernden Medienland-schaft möglichst gut zu positionieren. Die Entwicklung, die hierdurch angestoßen wird, ist wiederum zum guten Teil ein Selbstläufer, da durch das ständig wachsende An-gebot an Inhalten auch die Nutzung des mobilen Inter-nets immer interessanter wird.

Das wirklich Neue bei dieser Entwicklung liegt aber ganz woanders: Die Features moderner Endgeräte wie GPS-Ortung, Photo- und Videokamera oder Be-wegungssensoren bei gleichzeitiger Onlineanbindung ermöglichen faszinierende Anwendungen, an die bei Desktoprechnern nicht einmal zu denken ist. Alleine die Verknüpfung des aktuellen Standorts mit Datenbestän-den aus dem Internet birgt unzählige neue Möglichkei-ten. Erfolgt darüber hinaus eine Kombination mit der On-Device-Kamera und den Möglichkeiten der automa-tisierten Bilderkennung, können Anwendungen erstellt werden, die unter dem Schlagwort Augmented Reality zusammengefasst und bei denen Bilder visuell mit Zu-satzinformationen überlagert werden. Bedenkt man,

dass sich diese Entwicklung erst ganz am Anfang befin-det, wird klar, welches Potenzial dieser Sektor gerade im Bereich der Softwareentwicklung bietet.

Kampf um Entwickler entbranntDie Akteure auf dem mobilen Markt haben erkannt, dass das mobile Internet für ihre zukünftige Entwicklung von zentraler Bedeutung sein wird. Allesamt versuchen sie derzeit mit Hochdruck, attraktive Entwicklungs- und Distributionsplattformen bereitzustellen bzw. die beste-henden Plattformen zu optimieren, um verlorenes Ter-rain wiedergutzumachen – mit wechselndem Erfolg. Die Vielzahl neuer Plattformen, die derzeit auf den Markt geworfen werden und die Faszination, die Apples pro-prietäre und restriktive Plattform Cocoa auf eine gro-ße Zahl von Entwicklern ausübt, täuscht dabei schnell über eines hinweg: Java ist seit Jahren ein integraler Be-standteil der mobilen Anwendungswelt und auf nahezu allen Gerätegattungen präsent. Einen ganz besonderen Stellenwert hat in diesem Zusammenhang Java ME, das vor allem bei den Low- und Mid-End-Geräten, den

sog. Feature Phones, alter-nativlos ist, sich aber auf den BlackBerrys der Fir-ma RIM durchaus auch einen bedeutenden Platz im Smartphone-Sektor er-obert hat. Nun setzt sich mit Android gerade eine geräte- und herstellerü-bergreifende, offene High-

End-Plattform in atemberaubendem Tempo durch, die ebenfalls auf Java setzt – einem Sprachstandard, der wie kaum ein anderer über eine weltweit breit aufgestellte Entwicklercommunity verfügt.

Java ME bei Feature Phones konkurrenzlosBei Suns Java Micro Edition (Java ME oder auch J2ME) handelt es sich um eine abgespeckte Version der Java Standard Edition, die für Endgeräte wie Mobiltelefone, PDAs oder auch TV-Set-Top-Boxen optimiert wurde. Geräte also, die im Vergleich zu Desktoprechnern oder Serverplattformen leistungsmäßig stark limitiert sind. Andererseits sind in der Micro Edition eine Reihe von Komponenten enthalten, die speziell für diesen Einsatz-bereich entwickelt wurden und die wiederum nicht Be-standteil der Standard Edition sind. Unübertroffen ist Java ME von der Verbreitung her: Auf Low- und Mid-End-Geräten im Mobiltelefonbereich kann man hier von einem De-facto-Standard sprechen.

Um den Einsatz auf einer möglichst breiten Palette von Endgeräten zu gewährleisten, basiert Java ME auf verschiedenen Konfigurationen, die neben der JVM eine Reihe von Klassenbibliotheken enthalten, die wie-derum auf einen bestimmten Gerätetyp zugeschnitten sind. Diese Konfigurationen können mit so genannten Profilen weiter angepasst und erweitert werden. Dabei handelt es sich jeweils um einen Satz an Java-Kom-

der wichtigste auf Java set-zende Akteur im smartphone-sektor ist die kanadische Fir-ma research in Motion (riM).



ponenten, die optionale Funktionalitäten ermöglichen. Es stehen diverse freie Entwicklungsumgebungen und Emulatoren mobiler Endgeräte zur Verfügung. Bereits mit dem entsprechenden SDK von Sun wird eine IDE ausgeliefert. Wesentlich komfortabler sind allerdings die Plug-ins, die von Netbeans oder Eclipse angeboten wer-den und in die bereits Features wie ein Debugger oder Monitoring-Tools für Speicherverbrauch und Netz-werk-Traffic integriert sind. Die Architektur ist der von Applets oder Servlets sehr ähnlich, wodurch sich gerade Programmierer aus dem Webumfeld in der Regel sehr schnell zurechtfinden. Java ME kann durch zahlreiche optionale APIs erweitert werden und ermöglicht hier-durch die Umsetzung zahlreicher Features – theoretisch. Denn genau hier stößt es an seine Grenzen.

Der plattformübergreifende Ansatz hat zu einer ausgeprägten Fragmentierung geführt, der zentralen Schwäche von Java ME. Bei komplexen Anforderungen kommt man nicht umhin, für ganz bestimmte Zielgeräte zu entwickeln, da über die jeweiligen Konfigurationen und Profile hinaus diverse Eigenarten verschiedener Plattformen und Geräte berücksichtigt werden müssen. Probleme bereiten dabei neben unterschiedlichen Dis-playgrößen vor allem durch die Gerätehersteller unter-schiedlich implementierten SDKs und Bibliotheken. So kann auch bei völlig gleichen Profilen nicht von einem gleichen Verhalten auf unterschiedlichen Geräteplatt-formen ausgegangen werden.

Besonders deutlich wird dies bei den optionalen, nach Funktionalitäten gruppierten APIs, die zwar als Java Specification Requests (JSR) im Rahmen des Java Com-munity Process definiert, danach jedoch höchst unter-schiedlich oder nur lückenhaft implementiert wurden. Diese Unterschiede bestehen natürlich besonders bei verschiedenen Herstellern, können aber durchaus auch bei verschiedenen Serien ein und derselben Marke vor-kommen. Im Endeffekt führt das dazu, dass zahlreiche Möglichkeiten, die von den Ausstattungsmerkmalen bzw. den entsprechenden APIs her eigentlich zur Ver-fügung stünden, nur mit erheblichem Aufwand oder gar nicht nutzbar sind.

Weitere Einschränkungen bringt das Sicherheits-konzept von Java ME mit sich. Es erfordert, eine An-wendung zu zertifizieren, um aus dieser heraus auf Geräteressourcen zugreifen zu können. Doch selbst bei zertifizierten Anwendungen kommt es beim Zugriff auf Systemkomponenten oder auf das Internet immer noch zu zahlreichen Sicherheitsabfragen, worunter die Be-dienbarkeit mitunter stark leidet.

RiM setzt auf Java ME mit proprietären ErweiterungenDer wichtigste Akteur im Smartphone-Sektor, der bei al-len Geräten sowohl bei den internen Systemanwendun-gen als auch bei Zusatzsoftware auf mobiles Java setzt, ist die kanadische Firma Research In Motion (RIM). Um dem Problem der Fragmentierung zu begegnen, hat man die Java-ME-Umgebung kurzerhand um ein prop-rietäres Framework erweitert und ermöglicht darüber

hinaus über ein eigenes API umfangreichen Zugriff auf Gerätefeatures.

Grundsätzlich laufen auf den Geräten aber auch rei-ne Java-ME-Anwendungen, allerdings mit erheblichen Einschränkungen. Eine eigene Entwicklungsumgebung ermöglicht On-Device Debugging und auch die Signie-rung von Anwendungen ist recht komfortabel gelöst.

Zentrale Stärke der BlackBerry-Geräte ist das Senden und Empfangen von E-Mails per Push-Dienst, die Be-reitstellung entsprechender Tools zur Verwaltung per-sönlicher Daten und ein rundes Konzept zur Einbindung dieser Funktionalitäten in eine bestehende Firmeninfra-struktur. Auf diesen Kernbereich konzentrierte man sich sowohl bei den Bedienelementen der Endgeräte als auch bei der Architektur der zugrunde liegenden technischen Plattform kompromisslos. Im Hintergrund steht der BlackBerry Enterprise Server (BES) im Zentrum einer Client-Server-Architektur, über den Dienste aus dem Firmennetzwerk wie die Anbindung an einen Windows Exchange Server realisiert werden können. Entschei-dend für den großen Erfolg, den die Geräte gerade im Geschäftsumfeld haben, ist allerdings die Möglichkeit, Endgeräte zentral über den BES zu administrieren. Soft-ware kann zentral ausgerollt oder Updates eingespielt werden. Wie in anderen Netzwerken kann ein Adminis-trator auch Einschränkungen vornehmen: So kann z. B. der Zugang zum Internet limitiert werden. Auch auf den Geräten selbst können Funktionalitäten oder Zugriffs-rechte ganz oder teilweise gesperrt werden.

Die gezielte Ausrichtung auf funktionale Features für den Businessbereich hat zu einer enormen Verbreitung in diesem Sektor geführt. Gleichzeitig liegt hier aller-dings auch die relative Schwäche der Plattform für den Consumer-Bereich: Der Spaßfaktor der Geräte geht gegen Null. Durch den überwiegenden Gebrauch im Firmenumfeld ist darüber hinaus in der Regel davon auszugehen, dass Funktionalitäten, die in diesem Um-feld nicht benötigt werden, eher restriktiv gehandhabt werden. Vom freien Installieren von Anwendungen ganz zu schweigen. Für App-Entwickler bringt dieser Umstand natürlich erhebliche Unsicherheiten mit sich, da die Hard- und Softwareplattform zwar in sich kon-sistent ist, aber der Zugriff auf die Systemressourcen der einzelnen Endgeräte von Administartorenseite beliebig konfiguriert werden kann.

Auch RIM stellt mittlerweile mit der BlackBerry App World eine zentrale Vertriebsplattform für Entwickler zur Verfügung und versucht verstärkt, im Privatkun-densektor und damit in den Bereichen Multimedia und Unterhaltung Fuß zu fassen. Ob und wie weit das gelin-gen wird, bleibt zunächst abzuwarten. Es ist allerdings davon auszugehen, dass sich RIM unabhängig vom Ausgang der derzeit stattfindenden Verteilungskämpfe in seinem Kerngeschäft auf absehbare Zeit behaupten wird und das BlackBerry daher für Entwickler aus dem Java-Umfeld, die in erster Linie Business-Apps erstellen wollen, weiterhin eine ausgesprochen interessante Ziel-plattform bleibt.



android setzt sich bei Smartphones durchObwohl erst kurze Zeit verfügbar, kann schon jetzt eine große Zahl von Anwendungen im Android Market he-runtergeladen werden. Das Angebot reicht zwar noch nicht an das von Apples App Store heran, ist aber bereits dem anderer Hersteller haushoch überlegen. Die Platt-form wurde offensichtlich von einer großen Zahl von Entwicklern auf Anhieb angenommen, was die Frage aufwirft, worin diese Anziehungskraft begründet liegt. Da sind zum einen die Features der Plattform selbst. Basis von Android ist ein Linux-Kernel, der Prozessteu-erung, Netzwerkzugriffe und Speicherverwaltung steu-ert. Auf diesem setzt die selbstentwickelte und für den mobilen Einsatz optimierte Dalvik Virtual Machine auf. Vor allem performancekritische Systemkomponenten wurden nicht in Java, sondern in C/C++ erstellt. Außer-dem bringt die Plattform bereits von Haus aus eine gan-ze Reihe nützlicher Features wie einen WebKit-basierten Browser, eine leistungsstarke SQLite-Datenbank sowie zahlreiche Klassenbibliotheken von Java, dem Apache-Commons-Projekt und andere Komponenten (z. B. Par-ser für JSON und XML) mit.

Programme werden ausschließlich in Java entwickelt. Obwohl es sich bei Android um keine reine Java-Umge-bung handelt, können die gängigen Entwicklungstools verwendet werden. Benötigt wird hierzu neben einem aktuellen Java Software Developer Kit (SDK) ein wei-teres SDK für Android, das in die jeweilige IDE einge-bunden wird. Noch einfacher ist es, auf vorkonfigurierte Angebote zurückzugreifen. Eclipse beispielsweise kann bereits fix und fertig mit einer Android-Umgebung und entsprechenden Geräte-Emulatoren heruntergeladen und installiert werden.

Die Architektur ist auf eine maximale Widerver-wendbarkeit hin ausgelegt, wobei ein hochgradig modularer Ansatz verfolgt wird. Einen zentralen Ein-stiegspunkt wie eine main-Methode oder ein MIDlet sucht man hier vergebens, das Konzept erinnert eher an Internet-Mash-ups. Grundsätzlich soll es dabei in einer auf einzelnen Komponenten basierenden Architektur prinzipiell möglich sein, jede Komponente einer An-wendung unabhängig vom eigentlichen Kontext auch aus einer anderen Anwendung heraus aufrufen und einbinden zu können.

Die Erstellung von Oberflächen orientiert sich in And-roid am allseits bekannten MVC-Pattern. Verschiedene Elemente für die Benutzeroberfläche können dabei mit-hilfe von View- und Widget-Objekten erzeugt werden. Das Layout wiederum kann komplett in XML erstellt werden, wodurch eine vollständige Kapselung der Lay-outlogik und somit auch hier eine hohe Widerverwend-barkeit erreicht wird.

Neben den technischen Features ist vor allem die offe-ne Strategie, die mit der Open-Source-Plattform verfolgt wird, ein großes Plus. Zugleich ist es Google gelungen, mit der Open Handset Alliance ein Bündnis zu schmieden, in dem neben zahlreichen Herstellern mobiler Endgerä-te, Softwarefirmen, Marketingunternehmen, Vertretern

der Halbleiterindustrie auch Netzbetreiber wie die Deut-sche Telekom aktiv sind. Es steht also eine beträchtliche Marktmacht hinter Android, die zu einem guten Teil das enorme Tempo der bisherigen Verbreitung erklärt. Für potenzielle App-Entwickler hat diese Konstellation zwei entscheidende Vorteile. Zum einen muss man sich mit Android nicht auf einen bestimmten Hersteller festlegen und damit von dessen strategischen Entscheidungen und dem damit verbundenen Markterfolg abhängig machen. Zum anderen muss nicht davon ausgegangen werden, dass die Plattform sang und klanglos in der Versenkung verschwindet. Ganz im Gegenteil: Ein Blick auf die Situa-tion der bisher dominanten Plattformen im Mobilsektor deutet darauf hin, dass Android weiter an Bedeutung ge-winnt.

Symbian OS ist nicht mehr zeitgemäßDas inzwischen neben rein technischen Leistungsmerk-malen und der schieren Verbreitung eines Systems die Bereitstellung einer ausgereiften Entwicklungs- und Vertriebsplattform eine zentrale Rolle spielt, wird am Beispiel Symbian OS besonders deutlich. Seit zwölf Jahren am Markt, hat es derzeit von der Masse der be-stückten Geräte her die größte Verbreitung. Eigentlich optimale Vorraussetzungen, um eine ausgesprochen populäre Plattform für App-Entwickler zu werden, da ein potenziell riesiges Marktsegment angesprochen werden könnte. Auch von den Leistungsmerkmalen hat Symbian OS einiges zu bieten. Die Geräteintegration ist optimal und bietet vollen Zugriff auf sämtliche Fea-tures und Systemfunktionalitäten. Das Betriebssystem verfügt darüber hinaus über Features wie Multi-Tas-king, Multi-Threading und ein Konzept für Security. Die Entscheidung für C++ als Programmiersprache für zusätzliche Anwendungen spricht dafür, dass eine rela-tiv große Zahl von Entwicklern angesprochen werden und sich zügig in die Plattform einarbeiten könnte.

Entscheidendes Manko ist allerdings die historisch gewachsene und inzwischen überalterte Entwicklungs-plattform, die in der Lage ist, auch geneigte Entwickler zum verzweifeln zu bringen. Die erheblichen Einarbei-tungszeiten, die erforderlich sind, treiben Aufwand und Kosten in die Höhe. Darüber hinaus ist der zu erstel-lende Code außerordentlich umfangreich und komplex und dementsprechend schwer zu Warten und Erweitern. Demjenigen, der diese Hürden genommen hat, wird das Leben zusätzlich durch ein kompliziertes Securitykonzept schwer gemacht, bei dem unterschiedliche Zertifikate mit verschiedenen Berechtigungsstufen zum Einsatz kommen, was die Entwicklung von Software auch nicht einfacher macht. Nokia versucht, das Ruder noch herumzureißen. Ende 2008 wurden alle Anteile von Symbian übernom-men. Durch die inzwischen erfolgte komplette Freigabe von Symbian OS als Open-Source-Projekt erhofft man sich nun durch die Beteiligung externer Entwickler ei-nen Innovationsschub. Ob diese Strategie allerdings jetzt noch aufgeht, ist fraglich – die Liste offener Baustellen ist enorm groß, der Vorsprung der Mitwettbewerber ist es


auch. Es ist daher nicht weiter verwunderlich, dass auch Nokia nicht mehr ausschließlich auf Symbian OS setzt und sich mit dem Linux-basierten Maemo eine weitere Option für das High-End-Segment offenhält.

aufruhr bei den geräteherstellernAuch die übrigen Hersteller mobiler Endgeräte machen einen mehr oder weniger getriebenen Eindruck. Mit un-terschiedlichen Ansätzen wird versucht, den Anschluss nicht zu verlieren. So versuchte der ehemalige Pionier und Marktführer im Organizer-Bereich Palm mit dem neu entwickelten Betriebssystem webOS, das auf dem Palm pre herausgebracht wurde, einen Neuanfang. Palm setzte beim Versuch, eine möglichst große Zahl von Entwick-lern für die Plattform zu gewinnen, neben C/C++ vor allem auf aktuelle Webtechnologien und einen App Cata-log für den Vertrieb. Zwar wurden Gerät und Plattform überwiegend positiv aufgenommen, die Verkaufszahlen blieben jedoch weit hinter den Erwartungen zurück – was zeigt, wie eng der Markt bereits geworden ist. Mittler-weile wurde Palm von Hewlett Packard übernommen. Dennoch wagt auch Samsung einen Versuch und schickt mit Bada eine weitere Plattform ins Rennen, auf der mit Unterstützung von GNU-Tools in C++ programmiert werden kann. Alles aufs eigene System setzt Samsung al-lerdings selbst nicht: Die Koreaner verfolgen weiter eine

Multiplattformstrategie und bringen neben Symbian OS, Windows Mobile auch Android auf ihre Geräte. Frag-lich ist, ob sich für die verbleibende Bada-Nische eine nennenswerte Zahl von Entwicklern begeistern lässt. Es überrascht daher wenig, dass sich der Großteil der Her-steller nicht damit aufhält, weitere Plattformen auf den Markt zu werfen, sondern mehrere Eisen im Feuer behält und abwartet, welche Plattform sich durchsetzen wird. Interessant ist in diesem Zusammenhang, dass Hersteller wie Motorola, Acer, LG, Sony Ericsson und HTC dabei immer stärker auf Android setzen.

Der Befreiungsschlag von Microsoft lässt auf sich wartenWährend es höchst fraglich ist, ob es noch eine weitere Plattform schaffen wird, eine für App-Entwickler inter-essante Verbreitung zu erreichen, leidet ein Platzhirsch des Smartphone-Sektors an schwindenden Marktan-teilen. Windows Mobile liegt von der Verbreitung her nach wie vor auf Platz zwei. Ähnlich wie die Nummer eins – Symbian OS – ist es allerdings mittlerweile an-gestaubt. Die aktuellen Entwicklungen in Richtung Massenmarkt wurden schlicht verschlafen; erst Ende des letzen Jahres wurde mit dem Windows Market-place for Mobile eine zentrale Bezugsquelle für Apps zur Verfügung gestellt.

Anzeige



Die Plattform hat jedoch, im Gegensatz zu Symbian-OS, aus Entwicklersicht einiges zu bieten. Mit dem Visual Studio steht eine stabile und mächtige IDE zur Verfügung, für die darüber hinaus zahlreiche Tools existieren. Wurde ur-sprünglich mit C/C++ entwickelt, ist inzwi-schen .NET die Sprache der Wahl, da mit dem .NET Compact Frame-work zahlreiche Funk-tionalitäten und eine performante, effektive Runtime-Umgebung zur Verfügung gestellt werden. Seit Windows Mobile 6.5 ist außerdem die Entwick-lung von Widgets mit HTML und JavaScript möglich, womit vor allem Webentwickler angesprochen werden sollen.

Wie auch immer: Die Tage von Windows Mobile, das bald nur noch „Windows Phone Classic“ heißen wird, sind zumindest für den High-End-Sektor ge-zählt. Mit Windows Phone 7 hat Microsoft ursprüng-lich für 2009 eine neue Plattform angekündigt, die nun aber nach einer ersten Vorstellung im Februar erst im Herbst dieses Jahres erscheinen soll. Neben einer komplett überarbeiteten Benutzeroberfläche, die kon-sequent für die Steuerung per Multi-touch konzipiert ist und durch zahlreiche neue Entertainment-, Social- Networking- und Multimediafeatures ergänzt wurde, soll die Plattform jetzt auch technisch auf eine neue Basis gestellt werden. Entwicklungsplattform ist Sil-verlight, die Anwendungslogik und grafische Oberflä-chen sollen sauber voneinander getrennt sein und auf .NET bzw. XML basieren. Native und mit dem .NET Compact Framework erstellte Anwendungen werden von der Plattform nicht unterstützt, d. h. Windows-Mobile-Anwendungen werden zukünftig nicht mehr funktionieren. Fast drei Jahre nach der Einführung des iPhones setzt Microsoft im mobilen Bereich also nun alles auf eine Karte und versucht, seinem Erz-konkurrenten Paroli zu bieten. Dabei können sich die Redmonder weder grobe Schnitzer noch weitere Ver-zögerungen leisten. Gelingt es ihnen nicht, binnen kür-zester Zeit den Marketplace mit einer nennenswerten Anzahl attraktiver Windows-Phone-7-Apps zu füllen, wäre ein massiver Bedeutungsverlust im Mobilbereich kaum noch vermeidbar. Es ist daher davon auszuge-hen, dass der Softwaregigant erhebliche Ressourcen in das Projekt steckt. Man darf auf das Resultat gespannt sein.

Wachsender Unmut in apples bewachtem gartenDer bisherige Erfolg des iPhones beruht zu einem nicht unerheblichen Teil auf dem Umstand, dass es mit sei-ner Kombination aus attraktiver Hardware, Entwick-lungs- und Vertriebsplattform anfangs konkurrenzlos war und für Entwickler – ebenso wie für Apple – ein völlig neuer Markt erschlossen wurde. Entwickler aller

Couleur begannen fortan in Scharen, sich in das iPhone OS/iOS und die proprietäre Apple-Programmiersprache Objective-C einzuarbeiten, um ein Stück vom Kuchen abzubekommen. Die technischen Features der Betriebs-

plattform dürften für diesen Ansturm hinge-gen keine große Rolle gespielt haben: Außer bei einer Reihe nativer Anwendungen wurden bis zur iOS-Version 3 nicht einmal Multitas-king unterstützt. Aus

Entwicklersicht hat aber vor allem das Vorhandensein einer klar definierten, geschlossenen Umgebung und ex-pliziter Richtlinien erhebliche Vorteile. Man kann sich auf eine Software- und Geräteplattform konzentrieren.

Allerdings ist es mit der Konkurrenzlosigkeit des iPho-nes mittlerweile vorbei, womit das Risiko steigt, in die-sem abgeschotteten Umfeld Trends und Entwicklungen außerhalb des iPhone-Universums zu verpassen. Apple lässt nur Plattformerweiterungen zu, die das übergeord-nete Ziel, die volle Kontrolle über sämtliche Inhalte und Anwendungen zu bekommen und diese in die eigene Wertschöpfungskette zu integrieren, nicht gefährden. Was nicht in diese Strategie passt, bleibt außen vor und ist damit auch für die Entwickler von Apps nicht verfüg-bar. Das iPhone ist keine offene Plattform, und Entwick-ler sind dabei auf Gedeih und Verderb den Bedingungen ausgeliefert, die ihnen das Unternehmen Apple diktiert. Auch ob eine Anwendung überhaupt in den App Store darf, entscheidet Apple. Bitter, denn im Zweifel bleibt man auf den Entwicklungskosten sitzen. Erschwerend kommt hinzu, dass die dabei angewendeten Kriterien al-les andere als transparent sind – neben technischen und rechtlichen spielen dabei in zunehmendem Maße inhalt-liche Aspekte eine Rolle. Apple selbst spricht in diesem Zusammenhang schwammig von „unangemessenen“ Anwendungen.

Apple gerät inzwischen von mehreren Seiten in die Kritik. Erst kürzlich hat sich mit Joe Hewitt, ver-antwortlich für die Facebook-App, ein prominenter Entwickler demonstrativ vom iPhone abgewendet. Be-gründung: Die Politik Apples. Zeitschriften und Verlage hingegen mussten irritiert zur Kenntnis nehmen, dass Apples Gatekeeper nicht davor haltmachen, Inhalte, die sie für „unangemessen“ halten, von ihrer Plattform zu verbannen – und sehen darin einen Angriff auf die Pressefreiheit. Gerade durch die neuerdings lauter wer-denden Vorwürfe in dieser Richtung hat nicht nur das lockere und weltoffene Image, auf dem Apples überaus erfolgreiche Marketingstrategie basiert, erhebliche Krat-zer bekommen. Es ist außerdem davon auszugehen, dass sich Zeitschriften, Verlage und andere Produzenten von Content – auch oder wegen des mit ca. 30 % erhebli-chen Fees, das Apple von den Inhalteanbietern einbehält – verstärkt nach einer alternativen, offenen Plattform umsehen werden.

die Architektur von Android ist auf eine maximale Wieder-

verwendbarkeit ausgelegt.


Sven Mohr ([email protected])arbeitet als softwareentwick-ler und scrum Master in der Funktionseinheit products & innova-tion der deutschen Telekom. schwerpunkte seiner Tätigkeit sind das design und die Entwicklung mobiler Clients sowie von soAp- und rEsT-serveranwendungen. davor war er viele Jahre im soA-,

J2EE- und Webportalumfeld tätig.

Links & Literatur

[1] Android-portal: http://www.android.com

[2] sun-seite zu Java ME: http://java.sun.com/javame

[3] BlackBerry-Entwicklerportal: http://de.blackberry.com/developers/

[4] symbian-portal: http://www.symbian.org/

[5] Bada-developer-plattform: http://bit.ly/A360_Exp_5

[6] palm developer Center: http://developer.palm.com/

[7] Windows-Mobile-portal: http://bit.ly/A360_Exp_7

[8] iphone dev Center: http://bit.ly/A360_Exp_8

alles spricht für androidDer offene Ansatz Androids stellt einen Gegenentwurf zu Strategien dar, die darauf hinauslaufen, über die Durchsetzung eigener Standards Kontrolle über die Vertriebswege der digitalen Märkte zu erlangen – ein Konflikt, der bereits im Kontext des World Wide Web in den verschiedensten Konstellationen ausgetragen wurde und dessen Ausgang bekannt ist.

An Android sind zahlreiche Entwickler und Herstel-ler beteiligt, die die Plattform ständig verbessern und um neue Features erweitern. So ist kürzlich eine erste Testversion des Firefox-Browsers für Android (Fennec) erschienen, und das Betriebssystem selbst soll mit Ver-sion 2.2 Adobes Flash voll unterstützen. Der Plattform gelingt es darüber hinaus, eine ständig wachsende Zahl von Entwicklern für sich zu gewinnen – mit Tim Bray, einem der Erfinder von XML, gab es erst kürzlich einen prominenten Neuzugang in Googles Entwicklerteam.

Ausgebremst werden könnte der Erfolg Androids durch die wachsende Fragmentierung, die aus der Ver-breitung auf verschiedensten Endgeräten mit jeweiligen herstellerspezifischen Erweiterungen resultieren könnte – als Beispiel sei der Ärger genannt, den es derzeit mit den verschiedenen im Umlauf befindlichen Android-Versionen gibt. Die Auswirkungen wären allerdings in keinem Fall so dramatisch wie bei Java ME. Android setzt im Gegensatz zu diesem nicht auf einem fremden Betriebssystem auf, sondern ist als integrierte Entwick-

lungs- und Betriebssystemplattform über einen Linux-Kernel aufs engste mit der Geräteplattform verzahnt. Durch diese Flexibilität und seinen offenen Ansatz ist Android bestens für die derzeit stattfindenden Umwäl-zungen aufgestellt, die weit über den Mobilfunkbereich hinausgehen. Durch die wachsende Bedeutung relativ leichtgewichtiger Geräteplattformen, die den klassischen Desktoprechner zunehmend verdrängen, hat Android gute Karten, bald auch jenseits des Smartphone-Sektors eine zentrale Rolle zu spielen.

Anzeige

App Auf den MArkt!1 2 3


von kay Glahn

Das Konzept von installierbaren Anwendungen auf Mo-biltelefonen, die man über das Internet herunterlädt, ist eigentlich nichts Neues. Schon seit Jahren gibt es Java-Anwendungen, die über die verschiedensten Wege zum Download angeboten werden. Doch bisher konnte sich dieses Konzept zumindest beim Normalverbraucher nicht wirklich im großen Stil durchsetzen. Inzwischen hat sich hier einiges geändert. Einer der wichtigsten Treiber für den plötzlichen Erfolg von mobilen Appli-kationen war wohl Apples App Store für das iPhone.

Obwohl hier als Argument meist die innovative Technik angeführt wird, war wohl der wichtigste Faktor, dass das iPhone in den meisten Märkten von Anfang an nur mit einer Datenflatrate angeboten wurde. Denn in der Vergangenheit haben sich viele der normalen Nutzer nicht an mobile Applikationen herangewagt, da sie so-wohl beim Herunterladen als auch beim laufenden Be-trieb mit unkontrollierbaren Datenmengen und somit horrenden Telefonrechnungen rechnen mussten. Bei den meisten Android-basierten Geräten wird man zwar nicht zum Abschluss eines speziellen Datentarifs ge-zwungen, da das Android-System jedoch von Haus aus


App auf den Markt! Googles offenes Smartphone-Betriebssystem Android wird von immer mehr Geräteher-stellern unterstützt. Für Entwickler steht dadurch eine Zielplattform mit hohem Potenzial zur Verfügung. Die Frage ist, wie man als Entwickler seine Applikation am besten an den Kunden bringt. Dieser Artikel soll neben den Möglichkeiten, die Googles Android Market bietet, auch Alternativen beleuchten und Tipps geben, wie man die Applikation am besten vermarktet.

App Auf den MArkt! 3 2 1


sehr oft online geht, ergibt die Nutzung eines Android-Geräts eigentlich nur mit einer Datenflatrate Sinn, was auch hier die Hemmschwelle zum Herunterladen und Nutzen von mobilen Applikationen erheblich reduziert. So ist es nicht verwunderlich, dass nach dem Erfolg von Apples App Store auch Google dieses Erfolgsrezept übernommen hat und mit dem Android Market nun eine ähnliche Plattform zur Verteilung von Anwendun-gen etabliert hat. Für den Entwickler bietet dies enorme Möglichkeiten, seine Anwendung auf einfache Weise an den Endkunden zu bringen. Doch der Android Market ist lange nicht der einzige Weg, Android-Applikationen zu verkaufen. Während beim iPhone Apple sozusagen das Monopol auf den Verkauf und die Verteilung von Applikationen hat, ist die Android-Plattform wesentlich offener. So erlaubt es Google dem Entwickler, neben dem Android Market auch alternative Vertriebskanä-le zu nutzen. Dies kann entweder der App Store eines anderen Anbieters sein oder der Entwickler kann die Anwendung auch eigenständig zum Beispiel über eine eigene Website verteilen. In vielen Fällen ist dies sogar erforderlich, denn Googles Android Market ist zurzeit nur auf Geräten verfügbar, die in die Kategorie der Smartphones fallen. Alle anderen Geräte wie Tablet-PCs auf Basis von Android müssen bisher über alternative App Stores bedient werden.

Starke VerbreitungDie aktuell stark steigende Verbreitung von Android-Geräten bietet für Entwickler einen weiteren Anreiz, Applikationen für diese Plattform zu Entwickeln. Der Marktanteil der Android-Plattform steigt aufgrund der Unterstützung durch die verschiedensten Herstel-ler stark an. Laut Aussage des US-Marktforschers NPD Group hat Android das iPhone in den USA im ersten Quartal dieses Jahres sogar mit 28 % Marktanteil schon vom zweiten auf den dritten Platz verdrängt. Platzhirsch ist immer noch RIMs BlackBerry mit 36 %. Hierbei ist allerdings zu berücksichtigen, dass sich diese Zahlen nur auf an Consumer verkaufte Geräte beziehen. Klar ist al-lerdings, dass auch in Europa und auch im Geschäfts-kundenbereich immer mehr Android-basierte Geräte zum Einsatz kommen.

In der Vergangenheit war es für Android-Entwickler schwierig, die Entwicklungskosten für eine Applikation über den Verkauf auf dem Android Market wieder her-ein zu bekommen. Im Gegensatz zu Apples iPhone war die installierte Basis von Geräten einfach noch zu gering. Doch vereinzelte Beispiele zeigen, dass man mit einer ausgefallenen Idee und etwas Glück als einzelner Ent-wickler durchaus erfolgreich sein und Geld mit der Ent-wicklung von Android-Applikationen verdienen kann. Hierzu gehört zum Beispiel auch der frühere Volkswa-gen-Ingenieur und Mitbegründer des in San Francisco ansässigen Startups Picwing Edward Kim, der mit seiner in Eigenarbeit entwickelten Android-Applikation Car Locator 13 000 US-Dollar pro Monat über den Android Market verdient. Kim hat angeblich für die Entwicklung

der Applikation, die er für 4 US-Dollar anbietet, ledig-lich drei Wochen benötigt. Die Applikation ermöglicht es dem Benutzer, sein geparktes Fahrzeug wiederzufin-den. Obwohl dieses Beispiel wohl eher eine Ausnahme darstellt, gibt es doch immer mehr Entwickler, die mit dem Verkauf ihrer Android-Applikationen recht gute Einnahmen erzielen.

Im Folgenden wollen wir uns etwas genauer anschau-en, wie Googles Android Market funktioniert und wel-che Regeln zu beachten sind. Der Android Market ging bereits im Oktober 2008 online und hat es laut Anga-ben von Google bereits auf ein Repertoire von über 90 000 Anwendungen geschafft. Wenn man nach der Statistik der App-Suchmaschine Androlib.com geht, dann ist das Angebot für die Android-Plattform in den vergangenen zwölf Monaten förmlich explodiert, und zwar um den Faktor 15 von rund 6000 auf 91 000 Apps. Allein im vergangenen Juni sind über 15 000 An-droid Apps hinzugekommen, von denen knapp 62 % kostenlos sind. Im selben Zeitraum konnte sich der Apple App Store von 55 000 auf 225 000 Apps nur etwa vervierfachen.

Der Android Market steht prinzipiell jedem Entwick-ler offen und laut Google kann man mit drei einfachen Schritten am Markt teilnehmen. Man braucht sich nur anzumelden, die Anwendung hochzuladen und dann zu veröffentlichen. Hierbei hat man die Wahl, ob man seine Anwendung kostenlos oder kostenpflichtig anbie-ten möchte. Das Problem hierbei ist jedoch, dass nicht Entwickler aus jedem Land ihre Applikationen im An-droid Market einstellen dürfen. Während die Liste der Länder, aus denen Entwickler kostenlose Anwendungen anbieten dürfen, noch relativ lang ist, beschränkt sich die Liste mit Ländern für kostenpflichtige Anwendun-gen auf die Länder Österreich, Frankreich, Deutschland, Italien, Japan, Niederlande, Spanien, Großbritannien

Abb. 1: Der Android Market konnte in den letzten 12 Monaten einen rasanten Zu-wachs verzeichnen und kommt im Juli 2010 bereits auf über 90 000 Applikationen (Quelle: AndroLib.com)


App auf den Markt! Googles offenes Smartphone-Betriebssystem Android wird von immer mehr Geräteher-stellern unterstützt. Für Entwickler steht dadurch eine Zielplattform mit hohem Potenzial zur Verfügung. Die Frage ist, wie man als Entwickler seine Applikation am besten an den Kunden bringt. Dieser Artikel soll neben den Möglichkeiten, die Googles Android Market bietet, auch Alternativen beleuchten und Tipps geben, wie man die Applikation am besten vermarktet.



und USA. Während diese Einschränkung den deutschen Entwickler eher wenig betrifft, so wird die potenzielle Zielgruppe dadurch eingeschränkt, dass der Android Market nur in bestimmten Ländern zur Verfügung steht und nur in einem Bruchteil dieser auch kostenpflichtige Applikationen angeboten werden dürfen. Die Liste ist in etwa mit den Ländern identisch, aus denen Entwick-ler kostenpflichtige Anwendungen anbieten dürfen. Zu-sätzlich umfasst sie allerdings noch Australien, Kanada, Neuseeland und die Schweiz.

Um seine Applikationen über den Android Market verkaufen zu dürfen, ist es zunächst erforderlich, sich zu registrieren. Diese Registrierung ist mit einer einmaligen Gebühr von 25 US-Dollar verbunden. Laut Google wird diese Gebühr verlangt, um die Qualität der Anwendun-gen zu erhöhen und den Market vor Spam zu schützen. Im Vergleich zu Apples App Store, wo der Entwickler für eine Jahresgebühr von 99 US-Dollar aktiv werden kann, ist dies fast ein Schnäppchen. Möchte man kos-tenpflichtige Anwendungen über den Android Market verkaufen, so muss man sich zusätzlich als Händler bei Google Checkout registrieren. Das kann direkt von der Android-Market-Publisher-Website erfolgen, wenn man noch über keinen Checkout-Account verfügt. Was die Verkaufsgebühren betrifft, so verlangt auch Google eine Umsatzbeteiligung von 30 % des Anwendungspreises. Dieser von Apple eingeführte Prozentsatz hat sich inzwi-schen bei vielen App Stores als Standard etabliert. Bei der

Preisgestaltung hat man als Entwickler einen relativ gro-ßen Spielraum, man muss sich jedoch an die von Google vorgegebene Preisspanne halten, die zwischen 0,99 und 200 US-Dollar liegt und automatisch in die Währung des jeweiligen Verkaufslandes umgerechnet wird. Der Preis kann nach der Veröffentlichung beliebig geändert werden. Es ist allerdings nicht möglich, eine zunächst als kostenlos angebotene Anwendung später mit einem Preis zu versehen. Hierfür ist ein erneutes Hochladen der Applikation erforderlich, um sie dann als neue kos-tenpflichtige Applikation zu veröffentlichen.

Während Google zwar die parallele Verteilung der Applikation über beliebige andere Kanäle gestattet, so muss alles, was im Android Market landet, auch den Android-Market-Richtlinien entsprechen. Hierin ist bei-spielsweise festgelegt, dass Applikationen keine porno-grafischen, gewalttätigen oder Hass schürenden Inhalte enthalten dürfen. Außerdem muss die Applikation den US-Exportgesetzen entsprechen. Da die Applikation auf Servern von Google gehostet wird und Google eine ame-rikanische Firma ist, müssen US-Exportbestimmungen eingehalten werden, sobald jemand von außerhalb der USA eine Anwendung herunterlädt. Hierzu gehören beispielsweise relativ komplizierte Bestimmungen be-züglich der Verwendung von Kryptographie, mit denen man sich als Entwickler befassen sollte, da diese nicht verletzt werden dürfen.

Im Gegensatz zu Apples App Store gibt es beim An-droid Market keinen langwierigen Approval-Prozess. Während bei Apple der Entwickler in Extremfällen meh-rere Monate auf eine Genehmigung von Apple warten muss, wird die Applikation im Android Market sofort online gestellt. Google behält sich allerdings vor, die An-wendung zu einem späteren Zeitpunkt aus dem Android Market und sogar Remote von Endgeräten zu entfer-nen, falls die Anwendung die Richtlinien von Google verletzt. Der Entwickler wird in diesem Fall per E-Mail von Google über das Entfernen aus dem An droid Mar-ket informiert.

Wenn man seine Anwendung fertig hat, ist sie also ruckzuck auf dem Android Market. Man muss ledig-lich in einem Formular noch ein paar Details angeben. Hierzu gehört die Sprache der Applikation, die stan-dardmäßig Englisch ist. Außerdem kann pro Sprache ein Titel angegeben werden, unter dem die Applikation später im Android Market erscheinen soll. Des Weite-ren sollte man noch eine Beschreibung der Applikation angeben. Als Nächstes muss man den Typ der Appli-kation festlegen. Denn neben verschiedenen Kategorien, in die die Applikationen eingeteilt werden, wird grund-sätzlich zwischen den beiden Typen Applications und Games unterschieden. Außerdem gibt es verschiedene Publishing-Optionen. Hier kann man für die Applika-tion einen Kopierschutz aktivieren und auswählen, in welchen Ländern die Applikation zum Verkauf angebo-ten werden soll. Man kann entweder jedes Land einzeln auswählen oder die Anwendung automatisch für alle aktuellen und zukünftigen Länder freigeben.

Abb. 2: Im Android Market werden kostenlose und kostenpflichtige Applikationen in

verschiedenen Be-reichen angezeigt

Anzeige


Android kann seit der Version 1.6 außerdem verschie-dene Displayauflösungen unterstützen. Die Anwendung kann dementsprechend die Inhalte für die Darstellung auf kleinen, mittleren und großen Displays optimieren. Ein wichtiges Hilfsmittel für Feedback, das durch den Android Market bereitgestellt wird, ist die Statistik, die der Entwickler abrufen kann. Hierüber sind die Ratings der Benutzer, die Anzahl der Installationen sowie der noch aktiven Installationen einsehbar. Die Ratings und Kommentare werden von den Nutzern des Marktes zur Verfügung gestellt. Nachdem eine Anwendung herun-tergeladen und installiert wurde, kann man als Nutzer ein Rating von einem bis fünf Sterne abgeben und einen kurzen Kommentar schreiben. Jeder Nutzer ist allerdings nur ein Mal pro Applikation zur Abgabe eines Ratings oder eines Kommentars berechtigt. Man sollte auch be-rücksichtigen, dass Ratings und Kommentare über ver-schiedene Versionen der gleichen Applikation erhalten bleiben. Das bedeutet, dass mit einer neuen Version der gleichen Applikation immer noch die alten Kommentare erhalten bleiben und auch das Rating entsprechend wei-terberechnet wird. Man sollte also von Anfang an versu-chen, ein gutes Rating zu erhalten, denn hat man einmal zum Beispiel aufgrund von Bugs in der Applikation ein schlechtes Rating erhalten, so ist es schwierig, sein Ra-ting später zu verbessern; selbst dann, wenn man bereits alle Kinderkrankheiten der ersten Betaversion beseitigt

hat. Abhilfe würde hier nur das erneute Einstellen der Applikation in den Market unter einem neuen Namen schaffen.

Bei kostenpflichtigen Apps gibt es außerdem noch ein paar weitere Punkte zu beachten. So sind diese nur für Android-Geräte verfügbar, auf denen mindestens die Version 1.1 des Systems läuft. Außerdem sind ko-piergeschützte Applikationen nicht auf Android Dev Phones sichtbar, weil dort der Kopierschutz nach der

Abb. 3: Mit AppsLib bietet auch der Hersteller Archos seinen eigenen Android App Store an, der auf Applikationen für die Android-basierten Tablet-PCs des Herstellers spezialisiert ist

Anzeige



Installation nicht wirksam durchgesetzt werden kann. Beim Testen des Android Markets sollte man berück-sichtigen, dass man jeweils nur die Version des Markets zu Gesicht bekommt, die für das eigene Land bestimmt ist. Das bedeutet, dass ein Entwickler, der für Deutsch-land registriert ist und eine deutsche SIM-Karte in seinem Handy hat, auch nur den deutschen Android Market sieht. Interessant ist aber auch, dass Google in seinen Nutzungsbedingungen verbietet, dass ein Entwickler seine eigene Applikation kauft. Dies würde durchaus Sinn ergeben, um den korrekten Ablauf des Downloads und der Installation zu testen. Vermutlich will Google aber damit verhindern, dass man seiner Applikation durch Selbstkäufe künstlich Vorteile beim Ranking verschafft.

Zurzeit ermöglicht der Android Market noch keine Abo-Modelle, um regelmäßige Zahlungen vom Käufer der Anwendung einzuziehen. Wer nun denkt, er könnte dies selbst innerhalb seiner Applikation implementieren, der wird gleich wieder vom Android Market Developer Distribution Agreement in die Schranken gewiesen. Diese verbietet nämlich explizit das Einsammeln von Zahlungen aus der Anwendung heraus. Verwendet man einen alternativen App Store oder verteilt seine Anwen-dung selbst, dann spricht jedoch in den meisten Fällen nichts dagegen.

Als Käufer einer Applikation im Android Market soll-te man wissen, dass die Preise immer in der Heimatwäh-rung des Entwicklers angezeigt werden und noch keine Steuern beinhalten. Direkt vor dem Kauf zeigt der An-droid Market dann den ungefähren Endbetrag inklusive Steuern in der Heimatwährung des Käufers an. Für den Entwickler ist es wichtig zu wissen, dass der Käufer das Recht hat, innerhalb von 24 Stunden von dem Vertrag zurückzutreten und den Verkauf rückabzuwickeln. Es ist also wichtig, dass bei einer Applikation auf jeden Fall der erste Eindruck stimmt, denn sonst muss man als Entwickler möglicherweise mit einer hohen Stornoquote rechnen. Hat man als Käufer eine Applikation erwor-ben, so hat man das Recht, diese beliebig oft auf beliebig vielen Endgeräten zu installieren. Die gekaufte Applika-tion ist allerdings immer mit dem Google-Account des Käufers verknüpft. Da nur ein Google-Account gleich-zeitig pro Gerät aktiv sein und dieser erst nach einem Zurücksetzen auf Werkseinstellungen geändert werden kann, ist es nicht wirklich praktikabel, einmal gekaufte Applikationen an andere Nutzer weiterzugeben.

Zurzeit bietet Google lediglich für Kunden von T-Mo bile USA eine Abrechnung direkt über die Han-dyrechnung an. Das bedeutet, dass nach Ablauf der 24-stündigen Rückgabefrist der Betrag direkt auf das Mobilfunkkonto belastet wird. Für Entwickler ist hier-bei noch erwähnenswert, dass diese Art der Bezahlung nur für Applikationen funktioniert, die vom Verkäufer in US-Dollar angeboten werden. Bietet man seine Appli-kation in Euro an, wird also die potenzielle Zielgruppe eingeschränkt.

Der Android Market bietet, wie man sieht, einen un-komplizierten Vertriebskanal für Entwickler an. Er hat allerdings auch einige Nachteile. Hierzu gehört zum Beispiel, dass er nicht auf allen Android-Geräten ver-fügbar ist. Das betrifft vor allem Geräte, die nicht in die Kategorie der Smartphones fallen und somit nicht von Google für den Android Market freigegeben sind. Hierzu gehören zum Beispiel auf Android basierende Tablet-PCs. Viele Hersteller setzen auf solchen Geräten auf alternative App Stores, auf die wir noch etwas ge-nauer eingehen wollen. Außerdem ist zu beachten, dass Google keinen Support für die Applikationen leistet. Das bedeutet, dass sich Google nach Abwicklung des Kaufs und dem Verstreichen der 24-stündigen Rückga-befrist komplett aus der Verantwortung zieht. Jegliches Feedback oder Beschwerden sind danach direkt an den Benutzer zu richten. Einige App Stores zeigen, dass dies auch anders geht, indem sie einen First-Level-Support gegenüber dem Endkunden anbieten.

Alternative App StoresAls Konkurrenz zu Googles Android Market haben sich inzwischen zahlreiche Alternativen etabliert, von denen die wichtigsten in Tabelle 1 aufgeführt sind. Viele dieser App Stores haben sich auf bestimmte Gerätetypen, Geräte bestimmter Hersteller oder auch bestimmte Länder spe-zialisiert, die vom Android Market noch nicht mit abge-

App Store URL

AndAppStore http://andappstore.com

Android Market http://www.android.com/market

AndroidPit http://www.androidpit.de

Androlib http://www.androlib.com

AppBrain http://www.appbrain.com

Appoke http://www.appoke.com

AppsLib http://appslib.com

AutoLinQ http://www.autolinq.de

Camangi Market http://www.camangimarket.com

Cellmania http://www.cellmania.com

FastApp Store http://www.fastappstore.com

GetJar http://www.getjar.com

Handango http://www.handango.com

Handster http://www.handster.com

LePhone App Store http://www.lenovomm.com/appstore/

Mjelly http://mjelly.com

MobiHand http://www.mobihand.com

MobileRated http://www.mobilerated.com

Mobspot http://www.mobspot.com

Mplayit http://mplayit.com

neXva http://www.nexva.com

SHOP4APPS http://developer.motorola.com/shop4apps/

SlideMe http://slideme.org

Storeoid http://storeoid.com

Tabelle 1: Übersicht über einige wichtige App Stores für Android-Applikationen



deckt werden. So bietet zum Beispiel der Gerätehersteller Archos mit AppsLib einen eigenen App Store an, der sich speziell auf Android-Tablet-Geräte mit großen Displays spezialisiert hat, die vom Android Market ausgeschlos-sen sind. Der AppsLib Store ist zurzeit auf den Android Tablets von Archos vorinstalliert. Im Moment bietet er lediglich den Download von kostenlosen Applikationen an, ab August dieses Jahres kann man dann auch kosten-pflichtige Applikationen erwerben. Hierbei wird Archos genauso wie Google beim Android Market eine Verkaufs-provision von 30 % des Umsatzes verlangen, 70 % gehen an den Entwickler. Die Abwicklung der Zahlung erfolgt hierbei allerdings per PayPal. Der Zahlungsanbieter küm-mert sich dabei auch um die Umrechnung der Währun-gen, sodass der Käufer in seiner Währung bezahlen kann und der Verkäufer in sei-ner Heimatwährung aus-bezahlt wird. Nach dem Kauf einer Applikation bei AppsLib hat man das Recht, bis zu drei Kopien der Applikation auf ver-schiedenen Geräten zu installieren. Vorausset-zung ist allerdings, dass es sich um ein Android-Gerät vom gleichen Hersteller und der gleichen Marke handelt und dass der AppsLib Store für dieses Gerät zugelassen ist. Andere Beispiele für alternative App Stores sind SHOP4APPS von Motorola, der vor allem den von Google noch nicht unterstützten chinesischen Markt adressiert, sowie der AutoLinQ App Store von Continental, der sich auf Applikationen für die Android-basierte Fahrzeug-Infotainment-Plattform Au-toLinQ spezialisiert.

Um möglichst viele potenzielle Kunden und eine mög-lichst große Palette an Endgeräten abzudecken, macht es für Entwickler durchaus Sinn, ihre Applikation in so vielen Stores wie möglich anzubieten. Das ist natürlich mit einigem Aufwand verbunden, denn oft muss die Ap-plikation dafür auch an die speziellen Bedürfnisse der Zielplattform angepasst werden, für die der App Store vorgesehen ist. So ist es beispielsweise erforderlich, spe-zielle Versionen einer Anwendung für Tablet-PCs mit großen Displays oder für den Einsatz im KFZ zu lie-fern, wo spezielle APIs zur Verfügung stehen. Möchte man eine Vielzahl von App Stores adressieren, steigt na-türlich auch der Aufwand was die Abrechnung sowie die Auswertung von Statistiken und Feedback angeht. Abhilfe schafft hierbei der Distimo Monitor. Hierbei handelt es sich um ein kostenloses App-Store-Analy-setool für Entwickler von mobilen Applikationen, das einen guten Überblick über Verkaufsstatistiken einer Applikation über mehrere App Stores hinweg erlaubt. Gleichzeitig ermöglicht es auch einen Einblick in die ent-sprechenden Daten von Applikationen der Konkurrenz. Distimo Monitor sammelt Daten wie Anzahl der tägli-chen Downloads, Einnahmen sowie weltweites Ranking einer Applikation und stellt diese komfortabel über eine

Rechtliche Aspekte

ein wichtiger Aspekt, der von vielen angestellten Softwareentwicklern, die im Home Office nach der Arbeit ihre eigene mobile Applikation entwi-ckeln, oft vernachlässigt wird, ist der rechtliche Aspekt in Bezug auf den Arbeitgeber. denn bei Angestellten werden die rechte an entwicklungen üblicherweise an den Arbeitgeber übertragen, sofern dies nicht im Ar-beitsvertrag anders geregelt ist. das urheberrecht verbleibt zwar beim urheber, der Arbeitgeber erhält jedoch üblicherweise eine gesetzliche Li-zenz. dies kann allerdings im Arbeitsvertrag anders geregelt werden. die gesetzliche Lizenz gilt erst für alle entwicklungen, die ab dem eintritt in ein Arbeitsverhältnis entstanden sind. Als entwickler sollte man also bei eintritt in ein neues Arbeitsverhältnis dokumentieren, was man bereits vorher entwickelt hat bzw. auf eine entsprechende regelung im Arbeits-vertrag achten. normalerweise gibt es hier nur selten Streitigkeiten, doch sollte man mit einer eigenen App doch einmal äußerst erfolgreich sein, sollte man vorgesorgt haben und die rechte des Arbeitgebers am eige-nen Werk klar festgelegt bzw. ausgeschlossen haben.

Website bereit. Entwickler können dann diese Informa-tionen nutzen, um die Vermarktung ihrer Applikationen zu optimieren und zum Beispiel den Verkaufspreis oder den Verkaufskanal anzupassen.

Alternative EinnahmequellenObwohl App Stores nicht der einzige Weg für den Entwickler sind, seine Applikation an den Kunden zu bringen, stellen sie auf jeden Fall zurzeit die wichtigs-te Variante dar. Durch das Einstellen der Applikation zu einem bestimmten Preis in einen App Store rechnet man damit, dass ein bestimmter Prozentsatz aller Nut-zer den App Store verwendet und davon wieder ein Teil die Applikation im App Store findet. Von diesen hofft man als Entwickler, dass ein bestimmter Prozentsatz die

Applikation kauft und nicht von einem even-tuell vorhandenen Um-tauschrecht Gebrauch macht. Die Chance, dass ein potenzieller Kunde eine Applikation findet und kauft, kann durch entsprechendes Marke-ting erhöht werden. Und

die Wahrscheinlichkeit, dass ein Nutzer den App Store verwendet, kann erhöht werden, indem man die Appli-kation in mehreren App Stores parallel veröffentlicht.

Man hat als Entwickler aber wie gesagt auch zahlrei-che andere Möglichkeiten, seine Applikationen zu Geld zu machen. Neben dem direkten Verkauf an Endkunden über einen App Store besteht natürlich immer auch die Möglichkeit, die Anwendung direkt bestimmten Ziel-gruppen wie Firmen, Schulen und Universitäten, OEMs sowie Content- und Service-Providern anzubieten. Ob dieses Modell praktikabel ist, hängt natürlich stark von der jeweiligen Applikation ab.

App Stores stellen zurzeit die wichtigste Variante dar,

seine Applikationen an den kunden zu bringen.



Klar ist, dass kostenlose Applikationen wesentlich häufiger heruntergeladen werden als kostenpflichtige. Nicht nur weil die Kostenbarriere für den Benutzer nicht vorhanden ist, sondern weil die Applikationen auch oft wie beim Android Market in einem separaten Bereich angezeigt werden, in dem Benutzer oft bevorzugt nach neuen Applikationen schmökern. Vor allem bei Benut-zern von Android-Geräten handelt es sich oft um Nut-zer, die sich auch aufgrund der Begeisterung für das Open-Source-System für diese Plattform entschieden haben. Bei diesen Nutzern ist oft die Schwelle zum Kauf einer kostenpflichtigen Applikation noch etwas höher als beispielsweise bei einem iPhone-Benutzer. Diese Tat-sache kann man sich natürlich zunutze machen und sei-ne Applikation kostenlos anbieten, um dann auf andere Weise daran zu verdienen.

Das Freemium-ModellDieses so genannte Freemium-Geschäftsmodell wurde zuerst vom Risikokapitalgeber Fred Wilson beschrieben: „Biete deinen Dienst gratis an, möglicherweise mit Wer-beeinblendungen oder vielleicht auch nicht, gewinne vie-le Kunden auf effiziente Weise durch Mundpropaganda, Werbepartner, Platzierung in Suchmaschinen usw., und biete dann deinem Kundenstamm zu einem Aufpreis Zusatzleistungen oder eine erweiterte Version deines Diensts an.“ Inzwischen ist dieser Ansatz immer popu-lärer geworden und vor allem viele IT-Startups basieren auf diesem Konzept. Gerade im Bereich der mobilen Ap-

plikationen ist er ein sinnvolles Instrument, um zunächst einen möglichst großen Nutzerstamm aufzubauen, dem man dann Zusatzleistungen anbieten kann, an denen man dann erst später verdient. Dies können beispiels-weise kostenpflichtige Plug-ins sein, die eine kostenlose Basisversion der Anwendung um zusätzliche Premium-funktionen erweitert. Auch eine Freischaltung dieser zusätzlichen Funktionen mithilfe von Unlock-Codes ist denkbar. Diese können separat verkauft werden und er-möglichen das Freischalten von Zusatzfunktionen, die bereits in der kostenlosen Applikation enthalten, aber gesperrt sind. Eine andere Variante ist ein Abo-Mo-dell, bei dem man über einen Account in Verbindung mit einem Abo zusätzliche Services in Anspruch neh-men kann, die die kostenlose Version der Applikation aufwerten. Bietet man eine Applikation über Googles Android Market an, dann muss man jedoch aufpassen, dass man die Vereinbarungen für den Entwicklerver-trieb nicht verletzt, die unter anderem folgende Passage enthält: „Sie dürfen dann aber auch zukünftig den Nut-zern für Vervielfältigungen der Produkte, die diese ur-sprünglich unentgeltlich herunterladen konnten, nichts in Rechnung stellen.“ Bei anderen Marktplätzen sollte man vorher die Bedingungen daraufhin prüfen, ob sie mit einem Freemium-Geschäftsmodell vereinbar sind. Bietet man als Entwickler seine Applikation unabhän-gig von einem Marktplatz zum Beispiel über die eigene Website an, dann kann man bedenkenlos ein Freemium-Geschäftsmodell umsetzen.

Auch Werbung bringt EinnahmenEin anderer Ansatz, Einnahmen aus einer kostenlosen Applikation zu erzielen, ist das integrieren von Werbung. Viele Entwickler gehen inzwischen diesen Weg und grei-fen auf Ad-Provider wie Mobclix, Admob (inzwischen von Google übernommen) oder Google Ad Sense zurück. Mit Google Mobile Ads wird ein Developer Toolkit be-reitgestellt, dass die einfache Integration von Google Ads in Android- und iPhone-Applikationen ermöglicht. Google AdSense für mobile ist leider bisher nur im Rah-men eines Application-Betaprogramms in den USA und Kanada verfügbar, wird aber vermutlich in Zukunft auch auf andere Länder ausgeweitet (Abb. 4).

Es gibt Entwickler, die mit kostenlosen Applikationen über die integrierte Werbung mehr Geld verdient haben als mit kostenpflichtigen Applikationen. Man muss sich dann auch keine Gedanken mehr über die 24-stündige Rückgabefrist machen, denn der Nutzer installiert die Applikation zunächst kostenlos, und immer wenn er die Anwendung nutzt, kann man über die Werbeeinnahmen mitverdienen. Der Nachteil dieses Modells ist, dass man sich in eine Abhängigkeit von Third-Party-Code begibt und die Applikation auf eine Internetverbindung ange-wiesen ist, um Werbeanzeigen nachzuladen. Für Appli-kationen, die explizit für den Offlinebetrieb ausgelegt sind, ist die werbebasierte Finanzierung kein geeigneter Ansatz. Einige Entwickler bieten inzwischen eine kos-tenpflichtige und eine kostenlose aber werbefinanzier-

Abb. 4: Viele Appli-kationen wie der

Musikerkennungs-dienst Shazam

werden kostenlos angeboten und

erzielen ihre Einnahmen durch

Werbung oder Provisionen (z. B.

am Verkauf von MP3-Dateien)



te Version der gleichen Applikation auf dem Android Market an. Außer Werbung gibt es noch weitere Ansät-ze, über die man Einnahmen aus kostenlosen Applika-tionen generieren kann. Hierzu gehören beispielsweise Provisionsmodelle wie sie Amazon anbietet. Bietet man beispielsweise den Kauf von Artikeln oder MP3-Dateien aus der Applikation heraus an, so kann man als Entwick-ler an jeder Transaktion des Nutzers mitverdienen.

Mit MAO zum ErfolgEin weiteres wichtiges Thema, mit dem man sich als Entwickler beschäftigen sollte, ist die Mobile Applica-tion Optimization (MAO). Es gibt verschiedene Tricks, mit denen man die Downloadzahlen der eigenen Appli-kation verbessern kann. Hierzu gehören beispielsweise Sonderangebote innerhalb eines bestimmten Zeitraums, mit denen man der Applikation durch ein kurzfristig er-höhtes Downloadaufkommen ein besseres Ranking im App Store verschaffen kann. Auf diese Weise kann man eine Applikation durch Schübe von Angeboten immer wieder nach oben pushen.

Es ist außerdem wichtig, bei einer neuen Applikation im Android Market während der ersten Tage gute Ra-tings zu erzielen. Schlechte Kommentare und Ratings in den ersten Tagen bremsen von Anfang an das Wachstum aus und verhindern, dass die Applikation ausreichend Relevanz erhält, um auf den oberen Plätzen in den Such-ergebnissen zu erscheinen. Deshalb ist es wichtig, dass die Applikation von Anfang an reibungslos funktioniert, um nicht die ersten Benutzer gleich abzuschrecken. Dies erreicht man am besten, indem man den Fokus in der ersten Version auf Zuverlässigkeit und Stabilität anstatt auf einen großen Funktionsumfang setzt, denn viele Kunden scheuen auch bei einem kleinen Problem nicht, die Applikation aus Frust sofort zu deinstallieren und ein schlechtes Rating oder einen negativen Kommentar abzugeben. Man kann nicht erwarten, dass ein User sich mit einer ausführlichen Fehlerbeschreibung an den Entwickler wendet, sondern vermutlich die nächste Ap-plikation aus dem App Store herunterlädt, in der Hoff-nung, dass diese besser funktioniert.

Damit potenzielle Kunden die Applikation im App Store auch einfach finden, sollte man auf möglichst vie-le relevante Schlüsselwörter achten, die die Applikation identifizieren. Hierfür ist es auch wichtig, einen geeigne-ten Titel für die Applikation zu wählen und eine passen-de Beschreibung inklusive Screenshots bereitzustellen. Bei der Wahl des Titels sollte man sich in die Lage des Be-nutzers versetzen und überlegen, nach welchen Begriffen dieser suchen würde, wenn er eine entsprechende Appli-kation finden möchte. Man kann hier auch mit kleinen Tricks arbeiten und auch schauen, welche Schlagworte die Konkurrenz verwendet; man muss jedoch darauf achten, dass man keine Markenrechte verletzt.

Ein beim Android Market kontrovers diskutierter Ansatz, die Sichtbarkeit einer Applikation und somit deren Downloadzahlen zu verbessern, sind regelmäßige Updates. Denn nach jedem Update landet die Applika-

tion erneut in der Just-in-Sektion des Android Markets. Hierüber ist es wesentlich einfacher, auf die Applikation aufmerksam zu machen, als über ein gutes Rating oder die Suchfunktion. Von vielen Entwicklern wird dieser Mechanismus allerdings Missbraucht, indem neue Ver-sionen mit keinen oder nur minimalen Verbesserungen eingestellt werden, lediglich um die Sichtbarkeit der Ap-plikation im Android Market zu verbessern.

FazitSowohl der Android Market als auch zahlreiche andere, inzwischen verfügbare App Stores bieten Entwicklern enorme Möglichkeiten, ihre Anwendungen auf einfache Weise und ohne großes Marketingbudget zu vermarkten und Gewinne mit der Applikation zu erzielen. Es gibt aber auch andere Möglichkeiten, Geld mit den Applika-tionen zu verdienen, ohne dass man auf den App Store als Verkaufsplattform zurückgreifen muss. Die stetig steigende Zahl von Android-Geräten und die breite Unterstützung von vielen wichtigen Geräteherstellern werden auch in Zukunft die Nutzerzahlen und die Nach-frage nach Applikationen stark ansteigen lassen. Durch den kürzlich von Google vorgestellten App Inventor können nun sogar ganz ohne Programmierkenntnisse von jedermann Android-Applikationen erstellt werden. Obwohl viele gute Ideen bereits in Form von Applikati-onen realisiert sind, kann man mit einer außergewöhn-lichen Idee auf diesen Trend aufsteigen und versuchen, auch ein Stück vom Kuchen zu erhaschen.

Links & Literatur

[1] Glahn, kay: „das Jahr des Androiden“, in Java Magazin 6.2010, S. 38

[2] Website des Google Android Markets: http://www.android.com/market

[3] Mobclix Mobile Ad exchange: http://www.mobclix.com

[4] Admob: http://www.admob.com

[5] Google AdSense: http://www.google.com/adsense

Kay Glahn ist unabhängiger It-Berater mit den Schwerpunkten Mobile Applications und Services. er berät internationale kunden bei der umsetzung von projekten im Mobile-Bereich.

EntschEidungsfindung1 2 3


von heiko sasse

Die Zugbegleiter im Personenverkehr der Deut-schen Bahn AG nutzen schon seit vielen Jahren den RIS-Communicator als Informations- und Kommu-nikationswerkzeug. RIS steht für das ReisendenInfor-mationsSystem und bietet den Kunden der Deutschen Bahn aktuelle Informationen zu deren tatsächlichem Reiseverlauf. Der Pilotbetrieb des RIS-Communicators

startete vor über zehn Jahren im Nahverkehr. Damals war das primäre Ziel, Informationen zu Zügen auf nicht automatisch überwachten Nebenstrecken zu sammeln. Per Knopfdruck sendete der Zugbegleiter eine elektro-nische Abfahrtsmeldung als SMS. Mit den Jahren ist der Funktionsumfang des RIS-Communicators immer grö-ßer geworden, sodass das Endgerät für den Zugbeglei-ter in seinem Alltag immer hilfreicher wurde. Er kann mit dem RIS-Communicator beispielsweise Reisende

Die Zugbegleiter der Deutschen Bahn mit Android Smartphones auf Zukunftskurs

InnovationsfreudeDie Auswahl einer geeigneten Endgeräteplattform für ein Verfahren auf mobilen Endgerä-ten im Unternehmensumfeld gehört zu den spannendsten Themen der heutigen IT. Wer in dieser Entscheidungssituation zurückblickt und auf Kandidaten setzt, die sich in der Ver-gangenheit immer bewährt haben, könnte in Schwierigkeiten geraten.

EntschEidungsfindung 3 2 1


für Anschlusszüge melden, Anschlussinformationen für den nächsten Halt abrufen, Verbindungsauskünfte ertei-len, Schäden und Qualitätsmängel melden sowie Ware für die Bordgastronomie bestellen. Inzwischen sind ca. 8500 Zugbegleiter im Nah- und Fernverkehr mit dem RIS-Communicator ausgestattet, der an vielen Stellen Telefonate und konventionelle Papierunterlagen über-flüssig macht.

Die Deutsche Bahn setzt auf Consumer-EndgeräteSpeziell für einen Einsatzzweck entwickelte Endgeräte sind nur mit großem Aufwand auf dem aktuellen Stand der Technik zu halten und haben hohe Stückpreise. Des-halb setzt die Deutsche Bahn beim RIS-Communicator bewusst auf Consumer-Endgeräte. Eine Voraussetzung für diese Entscheidung ist, dass die konkrete Endgerä-testrategie mit den schnellen Produktlebenszyklen mobi-ler Endgeräte im Endkundenbereich Schritt halten kann. Ein zeitgleicher Kompletttausch der Endgeräte bei allen 8500 Zugbegleitern ist weder finanziell sinnvoll noch praktisch umsetzbar (zeitgleiche Schulungen, Endgerä-teverteilung etc.). Der Austausch der Endgeräte erfolgt kontinuierlich im Rahmen der Ersatzbeschaffung. Da immer ein RIS-zertifiziertes Endgerät beschaffbar sein muss, sind zeitgleich mehrere Endgerätetypen im Ein-satz. Deren Anzahl ist möglichst klein zu halten, um Be-triebs-, Support- und Wartungskosten zu minimieren.

Bisher kamen Nokia-Endgeräte zum Einsatz Seit dem Pilotbeginn im Jahr 1999 wurde die RIS-Soft-ware für Zugbegleiter auf vier Softwareplattformen umgesetzt (Abb. 1). Der erste RIS-Communicator war das Nokia 9110. Es war eines der ersten Geräte aus Nokias Communicator-Serie. Als Betriebssystem lief GEOS, das an C64er-Zeiten erinnert. Die Umsetzung der RIS-Software für den Pilotbetrieb erfolgte nativ in einem C-Dialekt. Die Kommunikation zwischen dem Endgerät und den zentralen Komponenten erfolgte per SMS. Für die damals sehr schmalbandige Kommunikati-on war die SMS wirtschaftlicher als Datenverbindungen über ein IP-Netz. Gerade in Gebieten mit sehr schlechter Mobilfunkabdeckung ist der Datenaustausch per SMS sehr zuverlässig und ermöglicht einen Informationsaus-tausch, wo andere Kommunikationskanäle versagen.

Als die Entscheidung fiel, das System RIS-Communi-cator fortzuführen und weitere Mitarbeiter mit einem Endgerät auszustatten, war der Nachfolger des Nokia 9110, das Nokia 9210i, das Gerät der Wahl. Es hatte bereits ein Farbdisplay, und als Betriebssystem kam Sym-bian mit der Entwicklungsumgebung Series 80 zum Ein-satz. Der Betriebssystemwechsel von GEOS zu Symbian machte eine Portierung der RIS-Software erforderlich. Das plattformunabhängige Java sollte bei zukünftigen Endgerätewechseln den Portierungsaufwand klein hal-ten. Die RIS-Software wurde nahezu komplett neu in Personal Java geschrieben. Als das Nokia 9210i im Jahr 2005 auslief, wurden die Geräte sukzessive durch das Nokia 9300 ersetzt. Trotz der Beibehaltung von Perso-

nal Java fiel bei dem Wechsel von Series 80 1st Edition zur 2nd Edition ein erheblicher Anpassungsbedarf an.

Durch die Übermittlung von dynamischen Anschluss-informationen ab 2006 stieg die übertragene Daten-menge sprunghaft an. Seit 2008 wird zusätzlich GPRS für die Datenübertragung verwendet. Da der Empfang einer SMS an registrierte SIM-Karten gebunden ist, wird bei bestimmten Übertragungen, die eine sichere Kommunikation erfordern, weiterhin SMS eingesetzt. Außerdem steht der SMS-Kanal als Rückfallebene zur Verfügung.

Der RIS-Communicator der vierten Generation wur-de das Nokia E90. Dieses basierte nun auf Series 60 3rd Edition, die kein Personal Java unterstützte. Die Java Mobile Edition (J2ME) der S60-Plattform konnte nicht alle Funktionen zur Umsetzung der RIS-Anforderungen zur Verfügung stellen. Die Ankündigung von Nokia und IBM zum Ende 2007, gemeinsam eine Java-Variante für embedded Rich Client Plattform (eRCP) für Symbian-Endgeräte bereitzustellen, bot eine vielversprechende Alternative. In der ersten Entwicklungsphase konnten große Teile des Quellcodes der Personal-Java-Version übernommen werden. Leider hat Nokia die eRCP-Strategie im September 2008 wieder aufgegeben. Nach enger Zusammenarbeit mit dem Systemintegrator Pro-Syst GmbH lag im März 2009 ein stabiler eRCP-Stack vor, mit dem die RIS-Anwendung auf dem Nokia E90 produktiv eingesetzt werden konnte. Allerdings hatte Nokia zwischenzeitlich entschieden, die Communica-tor-Baureihe einzustellen, sodass Mitte 2009 die letzten Nokia E90 ausgeliefert wurden.

Damit war es Mitte 2009 an der Zeit, die Endgerä-testrategie gründlich zu überarbeiten. Das Vorgehen zur Sicherstellung der Endgeräteverfügbarkeit musste an die gestiegene Dynamik des Markts angepasst werden. Der Schlüssel lag in der Auswahl der Endgeräteplatt-form für die fünfte RIS-Communicator-Generation, die im Folgenden beschrieben wird.

RIS-Anforderungen an die neue EndgeräteplattformAus dem großen Funktionsumfang der RIS-Anwendung ergeben sich spezielle Anforderungen an die Entwick-lungsumgebung und die Endgeräteplattform. Diese

Abb. 1: Bisherige Softwareplattformen der RIS-Software

Innovationsfreude

GEOS



wurden um weitere Anforderungen ergänzt, um eine zeitgemäße Anwendung zu ermöglichen:

Versand von SMS: Kurzmitteilungen (SMS) über ein •privates SMS-C (Short Message Service Center) ver-sendenEmpfang eingehender SMS: Eingehende SMS mit •Portadressierung und/oder speziellem Header emp-fangen, verarbeiten und aus der Anwender-Inbox löschenZugriff auf das Dateisystem von Endgerät und Spei-•cherkarteHintergrundprozesse: Hintergrundprozesse z. B. zur •Realisierung von Erinnerungsfunktionen startenTelefongespräche: Telefongespräche aus einer An-•wendung heraus aufbauenSoftwareverteilung und Aktualisierung Over-the-Air •(OTA): Software und Daten über das Mobilfunknetz verteilen und aktualisierenEffiziente Softwareentwicklung: Software in einem •engen Zeitrahmen zügig auf die neue Plattform por-tieren und den Aufwand für Softwarewartung und -weiterentwicklung gering halten

Bewertungsparameter für die neue EndgeräteplattformDie neue Endgeräteplattform soll bekannte Schwä-chen vermeiden und ein zeitgemäßes Bedienkonzept ermöglichen. Für die Sicherstellung der Endgerätever-fügbarkeit war die Zukunftssicherheit der neuen End-geräteplattform besonders wichtig. Außerdem sollten durch Betrachtung der Total Cost of Ownership (TCO) wirtschaftliche Aspekte Berücksichtigung finden. Für

die Auswahl der neuen Endgeräteplattform wurden sechs Bewertungsparameter festgelegt, die in Tabelle 1 aufgeführt sind.

Endgeräteplattformkandidaten und VorgehensweiseFür die Untersuchung, die Mitte 2009 stattfand, wurde ein breiter Fokus gewählt. Dafür wurden alle gängigen Betriebssysteme der aktuellen Smartphones betrachtet: Windows Mobile, Symbian S60, Apples iOS (früher iPhone OS), Android und BlackBerry. Die erfolgreiche Einführung des iPhones hatte den Endgerätemarkt stark verändert. Mit Android war ein neues Smartphone-Be-triebssystem bereits am Markt angekommen und weitere wie WebOS (Palm) und Maemo (MeeGo) sollten folgen. Da voraussichtlich nichts mehr sein würde, wie es noch vor ein paar Jahren war, wurde bei der Vorgehensweise der Fokus stark auf die Gegenwart und die Zukunft ge-legt. Als Informationsquelle dienten aktuelle Meldungen und Interviews mit Experten aus dem Mobile-Bereich.

VorauswahlrundeDie BlackBerry-Endgeräte finden sich überwiegend im professionellen Einsatz für Messaging und PIM. Durch die bahnspezifische Kombination von externen und internen Leistungsanteilen ergeben sich für den Black-Berry-Dienst laufende Kosten, die den Einsatz bei ei-ner so großen Anwendergruppe wie den Zugbegleitern unwirtschaftlich machen. Auf dem iPhone werden An-wendungen, die nicht von Apple kommen, als Fremdan-wendungen bezeichnet. Für diese Fremdanwendungen gelten besondere Beschränkungen: Es kann nur eine Fremdanwendung zurzeit aktiv sein, Hintergrundpro-zesse (z. B. für Erinnerungen) sind nicht möglich und

Bewertungsparameter Beschreibung

Herstellerunabhängigkeit Die Wahlmöglichkeit aus den Produktpaletten verschiedener Hersteller erhöht im Bedarfsmoment die Wahrscheinlichkeit, ein geeignetes Endgerät zu finden.

Intuitive Bedienung Der Nutzen, den der RIS-Communicator in der Praxis stiftet, ist maßgeblich davon abhängig, wie gut sich der Zugbegleiter mit dem Endgerät und der RIS-Anwendung auskennt. Da die Möglichkeiten zur Mitarbeiterschulung begrenzt sind, ist eine selbsterklärende Anwendung von Vorteil.

Performance Beim Einsatz der RIS-Anwendung zur Reisendeninformation in der Praxis ist es wichtig, dass die Anwendung zuverlässig funktioniert und schnell die benötigten Informationen liefert. Die Zuverlässigkeit des RIS-Communicators zeichnet sich im Arbeitsalltag insbesondere durch Stabilität und kurze Antwortzeiten aus. Dadurch kann der Zugbegleiter in der gleichen Zeit mehr Kunden informieren.

Zukunftssicherheit Ein Plattformwechsel ist immer mit hohem Aufwand verbunden. Damit im dynamischen Markt der mobilen Endgeräte die notwendige Flexibilität eines Verfahrens sichergestellt ist, sollte die ge-wählte Endgeräteplattform möglichst beständig sein und Anpassungen der Anwendung auf neue Endgeräte mit geringem Aufwand (Kosten und Zeit) ermöglichen. Die gewählte Plattform soll mög-lichst lange die Basis für den RIS-Communicator sein.

Endgerätepreis Ein Hebel zur Reduzierung der Verfahrenskosten sind die Kosten für die Endgerätebeschaffung. Im Anschaffungspreis der Endgeräte liegt daher ein großes Kosteneinsparungspotenzial.

Effiziente Softwareentwicklung und -wartung

Um die Lücke in der Endgeräteversorgung klein zu halten, sollte die Portierung der RIS-Anwendung auf die neue Endgeräteplattform möglichst schnell umgesetzt werden können. Darüber hinaus sollen die Verfahrenskosten durch die Wartung und Weiterentwicklung der RIS-Anwendung dauerhaft gering gehalten werden.

Tabelle 1: Bewertungsparameter zur Auswahl der neuen Endgeräteplattform

EntschEidungsfindung 3 2 1


Fremdanwendungen können nicht auf eingehende SMS zugreifen. Zum Analysezeitpunkt konnte Apple noch keine Möglichkeit anbieten, eine unternehmensinterne Anwendung über das Mobilfunknetz auf die Endgerä-te zu verteilen. Stattdessen hätte die Softwareverteilung und Datenaktualisierung von einem PC mit installiertem iTunes per Kabel erfolgen müssen. Damit konnte das iPhone nicht die notwendigen Plattformanforderungen erfüllen, und die RIS-Anwendung war nicht auf dem iPhone umsetzbar. Allerdings kam das iPhone in Work-shops bei den Zugbegleitern sehr gut an. Insbesondere gefiel die leicht verständliche und intuitive Bedienung des Endgeräts.

Die Plattformen WebOS (Palm) und Maemo (jetzt MeeGo) wurden ebenfalls in der ersten Analysephase betrachtet. Da für diese neuen Plattformen einfach noch zu viele Details unbekannt und auch noch keine Endge-räte verfügbar waren, wurden sie aufgrund der Unge-wissheit nicht weiter untersucht.

Zweite AnalysephaseDie zweite Analysephase betrachtete die Plattformen Windows Mobile, Symbian S60 und Android hinsicht-lich der Bewertungsparameter. Die Plattformen der zweiten Analysephase hatten gemeinsam, dass sie die RIS-Anforderungen grundsätzlich erfüllten. Mitte 2009 hatten viele namhafte Endgerätehersteller Windows-Mobile-Endgeräte in ihrem Produktportfolio. Auch Android-Endgeräte erschienen bereits auf dem Markt oder wurden von verschiedenen Anbietern, in der Regel Mitglieder der Endgerätehersteller Open Handset Alli-ance (OHA), angekündigt. Der größte Anteil an Symbi-an-Endgeräten stammte aus dem Hause Nokia, sodass die Herstellerunabhängigkeit wesentlich schwächer als bei den beiden anderen Plattformkandidaten ausgeprägt war.

In Workshops mit Zugbegleitern wurde eine iPhone-ähnliche Endgerätebedienung mit dem Finger über ein kapazitives Display besser beurteilt als die bisherige Bedienung über verschiedene Tastenfolgen. In Win-dows-Mobile- und Symbian-Endgeräten kamen meist noch resistive Displays zum Einsatz, die auf einen Stift zur Bedienung nicht verzichten konnten. Die Android-Endgeräte hatten in der Regel ein kapazitives Display, das sich gut mit dem Finger bedienen lässt. Durch die verschiedenen Standardbedienelemente lässt sich unter Android eine Anwendung entwickeln, die den Bewer-tungsparameter der intuitiven Bedienung besser als die beiden anderen Kandidaten erfüllt.

Der Bewertungsparameter Performance wurde von allen drei Plattformen gut erfüllt. Unter Symbian ist eine hardwarenahe Programmierung möglich, die die volle Performance der Endgeräte zugänglich macht. Android-Endgeräte des oberen Preissegments waren mit vergleichsweise schnellen Prozessoren und reichlich Hauptspeicher ausgestattet. Funktionen, die besonders ressourcenhungrig sind, könnten mit dem Native Deve-lopment Kit (NDK) sogar in C/C++ entwickelt werden.

Daher waren auch bei Android keine Performanceeng-pässe zu vermuten. Lediglich die Windows-Mobile-End-geräte blieben geringfügig zurück, da vergleichsweise etwas schwächere Prozessoren zum Einsatz kamen und hardwarenahe Funktionen oftmals herstellerspezifisch implementiert waren.

Die Beurteilung der Zukunftssicherheit war die schwerste Aufgabe dieser Analyse, da sie die größte Unsicherheit bot. Die Zukunft von Symbian im Bereich der Oberklassenendgeräte schien unsicher. Nokia woll-te beispielsweise viele Modelle mit MeeGo ausstatten. Windows Mobile war in der Vergangenheit immer eine zuverlässige Plattform, wenn es um die Umsetzung von Anwendungen im Unternehmensumfeld ging. Durch die Ankündigung von Windows Phone und den damit verbundenen Unsicherheiten für die Weiterverwendung von Windows-Mobile-Anwendungen konnte diese Zu-verlässigkeit nicht fortgeschrieben werden. Android versprach durch die Marktmacht von Google und den Partnern der OHA die größten Chancen.

Die Plattformanalyse hatte zwar nicht zum Ziel, ein konkretes Endgerät auszuwählen, doch sollten die End-gerätepreise der einzelnen Plattformen verglichen werden. Bei einem Vergleich ähnlicher Endgeräte, z. B. HTC Hero und HTC Diamond (beide Endgeräte mit Touchscreen und ohne Tastatur) oder HTC Touch Pro 2 und Nokia N97 (beide Endgeräte mit Touchscreen und mit Tasta-tur), wurde deutlich, dass Windows-Mobile- und Symbi-an-Endgeräte preislich dicht beieinander lagen, während die Android-Endgeräte deutlich günstiger waren.

Die geplante Anwendung konnte für die Beurteilung der Effizienz der Softwareentwicklung und -wartung na-türlich nicht auf allen Plattformen realisiert werden, um dann zu prüfen, welche Variante die effizienteste ist. Die Grundlage zur Beurteilung dieses Bewertungsparameters haben die Einschätzungen aus den Experteninterviews und der Studie von SIC! Software zum Bau einer Referen-zanwendung auf verschiedenen Plattformen [1] geliefert.

Symbian ist die Softwareplattform mit der größten Funktionalität. Das Höchstmaß an Flexibilität ist auf-grund der relativ altmodischen Architektur allerdings

Abb. 2: Analyse der drei Konkurrenten Android, Windows Mobile und Symbian



mit hohem Codieraufwand und einer aufwändigen Wartung des entwickelten Codes verbunden. Außerdem verfügt Symbian über viele Private APIs, die gar nicht oder nur schlecht dokumentiert sind. Nokia hat zwar den Quellcode unter einer Open-Source-Lizenz offenge-legt und eine Überarbeitung des Betriebssystems ange-kündigt. Inwieweit dies Verbesserungen bringen würde, war im letzten Jahr noch nicht absehbar.

Android ist ein leistungsstarkes Betriebssystem mit ei-ner modernen Architektur. Der Entwicklungsaufwand liegt auf sehr wirtschaftlichem Niveau. Die Entwick-lungswerkzeuge sind produktiv und der resultierende Code besitzt eine gute Wartbarkeit. Die native Entwick-lung für Android erfolgt auf der Java-Plattform (Standard Edition/Java SE). Damit entfallen Schwierigkeiten, die bei Umsetzungen auf Basis der eingeschränkten Micro Editi-on (Java ME) unvermeidbar sind. Das Android SDK ist sehr sauber umgesetzt, verfügt über eine sehr gute Doku-mentation und ermöglicht ein sehr praktikables Remo-te Debugging. Durch den Open-Source-Charakter ist es einfacher als bei geschlossenen Plattformen wie Symbian und Windows Mobile, plattformbedingte Probleme zu analysieren und Lösungen zu finden.

Die Produktivität bei der Programmierung für Win-dows Mobile profitiert ganz erheblich von den leis-tungsfähigen und modernen Entwicklungswerkzeugen aus dem Hause Microsoft. Die Entwicklung der RIS-Anwendung in C# wäre ähnlich aufwändig wie für An-droid in Java. Der Codeumfang ist gering, was zu einer guten Wartbarkeit des Codes führt. Allerdings sind hardwarenahe Funktionen oftmals herstellerspezifisch implementiert, was sich dann in einem unerwartet ho-hen Testaufwand niederschlägt. Da die Anzahl der C#-Entwickler für mobile Endgeräte eher gering ist, muss von höheren Tagessätzen ausgegangen werden.

Ergebnis der AnalyseDie Analyse hat gezeigt, dass Android die optimale Plattform für die Umsetzung der RIS-Anwendung ist. Die Gültigkeit der Analyseergebnisse ist auch heute noch gegeben. Allerdings würde die Zukunftssicherheit von Windows Mobile heute deutlich schlechter gewer-tet werden (Abb. 2). Auch Windows Phone ist immer noch keine Alternative. Anwendungen können nur über den öffentlichen Marketplace auf das Endgerät gebracht werden. Installationen über USB-Kabel, Speicherkarte oder aus dem Internet sind aus Sicherheitsgründen un-terbunden. Ein Corporate-Marketplace für Großkunden ist nach Microsoft zwar in Planung, Termine stehen aber noch nicht fest. Die Verteilung einer unternehmensinter-nen Anwendung an eine geschlossene Nutzergruppe ist damit nicht möglich. Im März 2010 war die Frage nach der geeigneten Plattform für den RIS-Communicator eine Aufgabenstellung beim Finale des europaweiten Fallstudienwettbewerbs T.I.M.E.S [2]. Die Teams ka-men zu unterschiedlichen Empfehlungen. Der entschei-dende Unterschied lag insbesondere in der Einschätzung der Teams, ob Open Source eher eine Chance oder ein

Risiko darstellt. Grundsätzlich haben die Lösungen aber das von der Deutschen Bahn angewendete Vorgehen be-stätigt.

EntwicklungsverlaufDie Entwicklung von Endgerätesoftware für den RIS-Communicator nach dem klassischen V-Modell wur-de bereits vor einigen Jahren zugunsten einer agilen Softwareentwicklung aufgegeben. Die Portierung auf Android ist im August 2009 mit der Scrum-Methode gestartet. Durch eine heterogene Zusammensetzung des Entwicklerteams wurde die so genannte „Sturmphase“ nie überwunden; der Projektfortschritt blieb hinter den Erwartungen zurück. Da die Leistungsfähigkeit einzel-ner Entwickler im sich selbst organisierenden Scrum-Team nicht transparent wird, konnte der Grund für den Verzug lange Zeit nicht identifiziert werden. Eine Ursache lag in der Unterschätzung der Komplexität der bahnspezifischen Fachlogik. Nach dem Austausch eines Entwicklers und der Ablösung von Scrum durch eine klassische Projektleitung wurden die gesteckten Ziele doch noch erreicht. Die Entwicklung wurde ab Dezem-ber 2009 durch einen Betatest begleitet. 30 Zugbegleite-rinnen und Zugbegleiter haben die Betaversionen in der Praxis erprobt und sehr viele qualifizierte Anregungen sowie Fehlermeldungen zurückgespielt. Der Rollout des RIS-Communicators V auf Basis des HTC Desire hat im Mai 2010 begonnen. Die Rückmeldung der Anwen-der ist sehr positiv und übertrifft die Erwartungen. Kein Zugbegleiter will seinen „Commi“ mehr hergeben.

nach dem studium zum Wirtschaftsingenieur startete Heiko Sasse seine Laufbahn 2002 bei der deutschen Bahn Ag. dem Einstieg als trainee in der Projektsteuerung des Reisendeninformationssys-tems (Ris) folgte 2005 die Übernahme des noch relativ jungen themas „Ris-communicator“. die Bedeutung der mobilen Endge-

räte im Ris ist seither stetig gewachsen. heute verantwortet heiko sasse die Verfahren und die Entwicklung im Aufgabengebiet Mobile Endgeräte Ris mit einem mehrköpfigen team.

Links & Literatur

[1] sic! software gmbh (2009) Whitepaper: „die mobilen Plattformen“ 2009: http://www.sic-software.com

[2] EstiEM, the organisation of European students of industrial Engineering and Management: https://www.estiem.org/default.aspx?Pageid=102

VV

Ihre Vorteile

auf einen Blick :

Frei-Haus-Lieferung

des Print-Magazins!

Alle Ausgaben online

immer und überall verfügbar!

Intellibook-Notebook zum Vorzugs-

preis von 199 EUR (statt 350 EUR)

www.intellibook.de

Ihre Vorteile

auf einen Blick :

des Print-Magazins!

immer und überall verfügbar!

Intellibook-Notebook zum Vorzugs-

preis von 199 EUR (statt 350 EUR)

www.intellibook.de

Einfach online bestellen unter: www.javamagazin.de/abo

Exklusiv für Abonnenten:Exklusiv für Abonnenten:Exklusiv für Abonnenten:Exklusiv für Abonnenten:Exklusiv für Abonnenten:

Das Magazin für Java-Profi s!magazin

Jetzt Online-Premium-Abo sichern! Schon ab € 1,30 pro Monat!

Android everywhere1 2 3


von Kay Glahn

Google hatte Android ursprünglich als Betriebssystem für Mobiletelefone entwickelt, doch inzwischen hat sich gezeigt, dass sich das System auch für zahlreiche ande-re Anwendungsszenarien und Zielplattformen eignet. Schon seit Langem gibt es Gerüchte, dass Google auch

den TV-Markt neu aufrollen wolle. Zur diesjährigen Google-I/O-Konferenz kam dann endlich die offizielle Ankündigung. Mit Google TV will der Suchmaschi-nenanbieter auch eine spezielle, auf Android basierende Softwareplattform für Fernseher und Set-Top-Boxen schaffen. Schon seit einiger Zeit arbeiten verschiedene Firmen auch an Android-basierten Tablet-PCs, doch

Neue Anwendungsgebiete von Googles Smartphone-Betriebssystem

Bis zum Handy und noch viel weiter

In der letzten Zeit überschlagen sich die Handyhersteller mit Neuankündigungen von Andro-id-basierten Smartphones. Doch das Handy ist nicht das einzige Gerät, auf dem sich das Open-Source-Betriebssys tem mehr und mehr etabliert. Vor allem Tablet-PCs und die Info-tainment-Systeme in Fahrzeugen sind neue Zielplattformen, aber auch auf Netbooks oder Fernsehern wird man Android in Zukunft immer häufiger antreffen. Im Folgenden möchte ich Ihnen einen Überblick über die aktuelle Entwicklung geben.

Android everywhere 3 2 1


der aktuelle Hype um Apples iPad hat dem Trend noch einmal einen zusätzlichen Schub verpasst. Und so haben inzwischen eine ganze Reihe von Herstellern entspre-chende Android-basierte Tablets angekündigt. Zurzeit sind zwar noch wenige Geräte verfügbar, aber das wird sich in den nächsten Monaten relativ schnell ändern.

Auch die Automobilindustrie hat festgestellt, dass sich Android mit seinem quelloffenen Linux-System her-vorragend als zentrales Multimedia- und Navigations-system für zukünftige Fahrzeuge eignet. Der Trend zu alternativen Antriebstechniken in der Automobilbran-che generiert hierbei eine zusätzliche Nachfrage nach intelligenten Systemen zur Nutzerinteraktion und Fahr-zeugsteuerung. Doch damit sind die Einsatzmöglichkei-ten von Android noch lange nicht ausgeschöpft. Weitere Ankündigungen gibt es zum Beispiel im Bereich E-Book-Reader oder Netbooks, und das Open-Source-Projekt LiveAndroid hat es sich zum Ziel gesetzt, ein Livesystem zu schaffen, mit dem man Android auf einem x86-PC oder Notebook von einer CD oder einem USB-Stick zum Laufen bringen kann.

Android auf dem FernseherMit Google TV möchte Google eine offene Plattform für Fernsehgeräte bereitstellen. Man will damit nach eigener Aussage das Beste aus TV und Web zusammenbringen, um eine einzigartige Entertainment Experience für das Wohnzimmer zu liefern. Die Plattform selbst ba-siert in der ersten Ver- sion auf Android 2.1, unterstützt aber gleichzeitig den Google-Desk-top-Browser Chrome, um dem Benutzer einen wirk-lich vollwertigen Webbrowser anbieten zu können. An-wendungen sollen in Zukunft sowohl von Web- als auch von Android-Entwicklern bereitgestellt werden können, die sich hier vor allem den zumeist großen TV-Screen zunutze machen können, den man weder auf dem PC und schon gar nicht auf dem Smartphone vorfindet. An-droid-Entwickler sollen sowohl Zugriff auf die meisten bereits bekannten Android-APIs bekommen, zugleich aber auch Google-TV-spezifische API-Erweiterungen nutzen können. Hierdurch soll es Anwendungsentwick-lern beispielsweise ermöglicht werden, aus der eigenen Applikation heraus innerhalb von TV-Inhalten zu navi-gieren.

Bisher ist die Google-TV-Plattform lediglich angekün-digt, laut Google soll der Verkaufsstart allerdings noch im Herbst dieses Jahres beginnen. Hierzu hat Google Kooperationen mit den Firmen Sony und Logitech ge-schlossen. Erste Geräte, auf denen Google TV vorinstal-liert ist, sollen Fernseher und Blu-Ray-Player von Sony sowie eine Logitech Companion Box sein. Mit dem Ver-kaufsstart wird das System aber leider noch nicht als Open Source bereitgestellt. Dies ist zwar geplant, und laut Google wird an der Veröffentlichung des Source-

codes von Google TV gearbeitet, aber es sei frühestens nächstes Jahr damit zu rechnen.

Chrome als zentrales ElementWas den Webbrowser betrifft, so handelt es sich um die bestehende Linux-Version von Googles Chrome. Hier-bei wurde lediglich das User Interface leicht angepasst, um es besser auf den Einsatz auf einem Fernseher ab-zustimmen. Die meisten Eigenschaften vom Rendering bis zur Browserplattform selbst sind jedoch identisch mit der Desktopversion des Chrome-Browsers. Das bedeutet vor allem, dass der Großteil der Webseiten, die auf dem Google-Chrome-Desktopbrowser korrekt dargestellt werden, auch auf Google TV entsprechend laufen. Google will seine TV-Plattform zunächst mit der Chrome-Version 5.0 ausstatten und dann später Up-dates auf neuere Versionen online ermöglichen. Auch bei seiner TV-Plattform bekennt sich Google ganz klar zu Flash, denn der Browser wird Flash 10.1 unterstützen und somit auch in der Lage sein, alle gängigen Flash-Webseiten anzuzeigen.

Leider gibt es im Gegensatz zu der Android-Smart-phone-Plattform auch einige Einschränkungen. So werden zunächst keine nativen Anwendungen bzw. na-tive Erweiterungen auf der Google-TV-Plattform unter-stützt. Google hat allerdings angekündigt, das Android NDK (Native Development Kit) zu einem späteren Zeit-

punkt auch für Google TV zur Verfügung zu stellen. Außerdem wird auf den ersten Geräten, die ab Herbst dieses Jah-res verfügbar sein wer-den, noch kein Android Market vorhanden sein.

Es können also keine zusätzlichen Anwendungen herun-tergeladen und installiert, sondern nur die von Google vorinstallierten Anwendungen genutzt werden. Google hat jedoch angekündigt, den Android Market ab Anfang 2011 auch für die Google-TV-Plattform bereitzustellen. Auch bestehende Geräte sollen dann online mit einer entsprechenden Version des Android Markets versorgt werden. Hierdurch will Google Entwicklern genügend Zeit geben, entsprechende Applikationen für die neue Plattform zu entwickeln, damit zum Start des Android Markets auf Google TV eine ausreichende Auswahl an Applikationen bereitgestellt werden kann. Laut Goog-le sollen dann bestehende Android-Applikationen auch auf der Google-TV-Plattform laufen. Voraussetzung ist allerdings, dass sie keine Hardware- oder Softwaref-eatures verwenden, die von der Google-TV-Plattform nicht unterstützt werden. Aus Entwicklersicht macht es allerdings durchaus Sinn, bestehende und neue Anwen-dungen für Google TV anzupassen und auf den großen Display und für den Zugriff auf TV-Inhalte zu optimie-ren.

Für Webentwickler stellt Google hierfür entsprechen-de Design-Guidelines für Google TV auf seiner Website

Laut Google sollen bestehen-de Android-Apps auch auf der Google-Tv-Plattform laufen.Bis zum Handy und

noch viel weiter



bereit. Android-Entwickler müssen sich allerdings noch eine Zeit lang gedulden. Google hat jedoch angekündigt, ein Android SDK Add-on mit Google-TV-spezifischen Erweiterungen anzubieten, dass für Entwickler kosten-los zum Download zur Verfügung gestellt werden soll. Dieses Add-on wird auch einen entsprechenden Emula-tor beinhalten, der das Testen von Google-TV-Anwen-dungen auf dem Entwicklungsrechner ermöglicht.

Neben der Firma Sony, die angekündigt hat, Goo gle TV in seine Fernseher zu integrieren, wird Logitech mit der Google TV Companien Box Revue eines der ersten auf der neuen Android-Plattform basierenden Geräte anbieten. Hierbei handelt es sich um eine externe Box, die via HDMI an den Fernseher angeschlossen wird. Die Bedienung soll über ein intuitives Eingabegerät erfolgen, das speziell auf die Google-TV-Plattform optimiert ist. Außerdem soll eine Bedienung auch über Smartphones

mithilfe von Logitechs Harmony Link möglich sein. Hierfür wird Logitech zum Start Applikationen für An-droid Smartphones sowie für Apples iPhone und iPod Touch anbieten. Eine speziell auf das iPad optimierte Version soll später folgen. Auch zahlreiche andere Her-steller arbeiten bereits an proprietären TV-Plattformen, die auf angepassten Android-Versionen basieren. Hier-zu gehört zum Beispiel auch der schwedische Hersteller People of Lava.

Grundsätzlich stellt sich allerdings die Frage, welche Use Cases für ein Android-System auf einem Fernseher wirklich in Frage kommen. Denn es ist noch nicht wirk-lich klar, ob sich das Surfen und Lesen von E-Mails am Fernseher wirklich in der Form durchsetzen kann. Zum einen sitzt man oft zu weit weg vom Bildschirm, was eine riesige Schriftgröße für ergonomisches Arbeiten er-fordern würde, und zum anderen kann im Wohnzimmer jeder mitlesen, wenn man vom Sofa aus seine E-Mails checkt oder im Internet surft. Ob das stört, muss jeder für sich selbst entscheiden. Als Hauptanwendungssze-nario bleibt dann wohl noch das Abspielen von Videos, TV-Programmen oder Diashows; also letztendlich die Funktionalität, die man eigentlich vom Fernseher ge-wohnt ist. Welche komplett neuen Arten von Anwen-dungen für diese Plattform entstehen werden, bleibt also noch abzuwarten.

Android fährt AutoImmer mehr Automobilhersteller springen auf den Trend auf, nach alternativen Antriebstechnologien zu suchen. Obwohl es keinen direkten Zusammenhang gibt, verlangen moderne Fahrzeuge, die mit immer mehr Technik ausgestattet sind, eine intelligente und leicht zu bedienende Benutzerschnittstelle. Vor allem haben aber auch Automobilhersteller erkannt, dass es durchaus Sinn macht, diese Systeme, die neben der Steuerung von Fahrzeugfunktionen auch gleichzeitig Navigations- und Entertainmentsystem sind, nach dem Verkauf durch zusätzliche Funktionalitäten zu erweitern. Was spricht also dagegen, das inzwischen auch beim Otto-Normal-verbraucher angekommene Konzept von herunterladba-ren Applikationen, wie man sie vom Smartphone her kennt, aufzugreifen? Hierfür kommt natürlich eine of-fene Plattform wie Android in Frage, die auf der einen Seite vom jeweiligen Automobilhersteller oder Zuliefe-rer individuell angepasst werden kann, auf der ande-ren Seite aber eine einheitliche Anwendungsplattform für Erweiterungen und herunterladbare Applikationen bereitstellt. Dieser Ansatz bietet eindeutige Vorteile ge-genüber proprietären geschlossenen Systemen, wie sie derzeit von vielen Automobilherstellern eingesetzt wer-den.

Einer der ersten Hersteller, der bereits ein Fahr-zeug mit integriertem Android-System auf den Markt gebracht hat, ist der chinesische Hersteller SAIC. Das Modell Roewe 350 verfügt über ein integriertes Infotainment-System, basierend auf der Version 2.1 von Android. Aber auch andere Hersteller haben den

Abb. 1: Archos liefert mit seinem Archos 7 Android Tablet bereits einen iPad-Konkur-renten mit eigenen Application Store aus

Abb. 2: Auch das WeTab des deutschen Herstellers Neofonie ermöglicht das Aus-führen von Android-Applikationen



Einsatz von Android in ihren Fahrzeugen bereits an-gekündigt oder arbeiten daran. So kooperiert Google zum Beispiel mit GM (General Motors), um ein ent-sprechendes Android-basiertes Infotainment-System für GMs erstes Elektrofahrzeug Chevy Volt zu entwi-ckeln. Bisher werden bei Automobilherstellern häu-fig Systeme von Microsoft, QNX-Software oder aus eigener Entwicklung eingesetzt. Interessant ist auch, dass der Hersteller der BlackBerry Smartphones RIM (Research in Motion) Anfang des Jahres den Herstel-ler QNX übernommen hat. Ziel ist es, QNX‘ Positi-on in dem Automobilsegment weiter auszubauen und Smartphones, wie den hauseigenen BlackBerry, stärker mit dem Infotainment-System des Fahrzeugs zu inte-grieren. QNX ist beispielsweise Technologielieferant für GMs OneStar-System. Hierbei kommt zwar kein Android zum Einsatz, aber für Java-Entwickler dürf-te diese Entwicklung trotzdem interessant sein, da die Anwendungsentwicklung für den BlackBerry ebenfalls in Java erfolgt. Mit der GENIVI Alliance Arbeitet ein Konsortium von Firmen aus der Automobilbranche an einer mit Android konkurrierenden Plattform, basie-rend auf der von Intel und Nokia ins Leben gerufenen MeeGo-Linux-Plattform.

Zulieferer stehen in den StartlöchernZurzeit beschäftigen sich vor allem die Automobilzu-lieferer intensiv mit dem Thema Android und bieten bereits erste Produkte an, die man vermutlich in nicht allzu ferner Zukunft auch in den ersten Fahrzeugen sehen wird. Hierzu gehört unter anderem der Herstel-ler Parrot, der ursprünglich aus dem Bluetooth-Zube-hör-Bereich kommt, aber schon seit einiger Zeit auch OEM-Lösungen für Automobilhersteller anbietet. Ein erstes auf Android basierendes Produkt ist das Parrot FC6100. Hierbei handelt es sich um eine OEM-Lösung, die von Fahrzeugherstellern in Autos integriert werden kann. Das System bietet eine komplette Infotainment-Lösung, basierend auf Android, und stellt neben einer Bluetooth-Freisprechanlage mit Spracherkennung auch Wireless LAN und Bluetooth 3.0 zur Verfügung. Außer-dem ermöglicht es Multimediaverbindungen mit iPod und USB-Geräten, und der Anwender kann über die 3G-Verbindung im Internet surfen. Aufgrund des offenen Android-Systems kann die Plattform vom Automobil-hersteller oder auch von Drittanbietern über Android-Applikationen problemlos erweitert und an individuelle Bedürfnisse angepasst werden.

Auch die Firma Continental, die ein wichtiger Play-er im Bereich der Automobilzulieferer ist, hat bereits im Sommer letzten Jahres ein ähnliches offenes System mit der Bezeichnung AutoLinQ angekündigt. Man will hiermit eine Umgebung schaffen, in der die Nutzer ef-fektiv mit ihrem Fahrzeug kommunizieren können; und das sowohl von zu Hause aus als auch im Büro oder über ihre mobilen Endgeräte. Nicht verwunderlich ist, dass sich auch Continental für den Einsatz der An-droid-Plattform entschieden hat – vor allem weil man

hierdurch auf die bereits große und stetig wachsende Entwicklergemeinde zurückgreifen kann, die Applika-tionen für die Plattform entwickeln. Zurzeit arbeitet Continental mit Automobilherstellern, Entwicklungs-partnern und der Android-Entwicklergemeinde zu-sammen. Eine Fahrzeugeinführung mit AutoLinQ ist bereits ab der nächsten Produktgeneration von Fahr-zeugen möglich. Continental arbeitet bereits mit der Deutschen Telekom, NAVTEQ sowie mit rund einem halben Dutzend weiterer Partner an frühen Prototypen von Anwendungen. Erste Ergebnisse sollen bereits im zweiten Halbjahr dieses Jahres vorgestellt werden, zu diesem Zeitpunkt soll auch ein eigener Application Store für das System zur Verfügung stehen, über den Entwickler dann ihre speziell auf den Einsatz im Fahr-zeug ausgerichteten Android-Applikationen anbieten können. Continental hat auch bereits ein eigenes Au-toLinQ SDK angekündigt. Dieses ist zurzeit allerdings nur in einer Alphaversion verfügbar und wird zunächst bestehenden Partnern und Entwicklern zur Verfügung gestellt. In den nächsten Monaten ist dann auch eine öffentlich verfügbare Version des SDKs geplant. Das AutoLinQ SDK besteht neben einem entsprechenden Emulator und einem Fahrzeugsimulator aus einer fahrzeugspezifischen API sowie den AutoLinQ-Benut-zeroberflächen. Das AutoLinQ SDK ist ein Add-on für den Android Virtual Device Manager des von Google bereitgestellten Android SDKs. Das SDK erstellt ein eigenes Automotive AVD und erlaubt dem Entwick-ler, mithilfe der Fahrzeug-APIs Android-Anwendun-gen zu entwickeln, die auf Fahrzeug informationen und -systeme zugreifen. Hierzu gehören beispiels-weise die Informationen zum Zustand des Fahrzeugs wie der Kraftstoffstand, die aktuelle Motordrehzahl oder der Verriegelungszustand der Türen. Mithilfe des bereitgestellten Fahrzeugsimulators können diese Informationen generiert und eingestellt werden, um Anwendungen, die die Fahrzeug-APIs verwenden, ent-sprechend auf dem Emulator zu testen.

Sonderausstattung aus dem Application StoreEinen ganz neuen Weg bei der Ausstattung von Fahr-zeugen hat Audi angekündigt. Der Audi A1 soll ab Werk mit zahlreichen Funktionen ausgestattet sein, die zunächst nicht freigeschaltet sind. Dies kann bei-spielsweise eine Sitzheizung sein, die beim Kauf des Fahrzeugs deaktiviert ist und nicht verwendet werden kann. Der Besitzer kann dann über einen Application Store kostenpflichtige Applikationen herunterladen, die diese deaktivierten Komponenten zum Leben er-wecken und gleichzeitig die Benutzerschnittstelle dafür bereitstellen. Der Besitzer kann dadurch mithilfe des Application Stores sein Fahrzeug Schritt für Schritt mit neuem Sonderzubehör nachrüsten, ohne dass er dafür die Werkstatt aufsuchen muss. Ob hierfür eine offene Plattform wie Android oder eine proprietäre Plattform zum Einsatz kommt, wurde allerdings bisher noch nicht bekannt gegeben.



Android tritt gegen Apples iPad anEin weiteres wichtiges Einsatzgebiet für Android sind Tablet-PCs und Netbooks. Gerade durch den Hype, den Apple mit dem iPad gerade um die Gerätekategorie der Tablet-PCs erzeugt, sehen viele Hersteller auch in An-droid eine große Chance, um in diesem Segment Fuß zu fassen und eine konkurrenzfähige Alternative zum iPad anzubieten. Zahlreiche Hersteller haben bereits Geräte aus diesem Bereich angekündigt. Die Zahl der aktuell verfügbaren Produkte ist allerdings noch relativ gering. Dies wird sich jedoch in den nächsten Monaten ändern.

Einer der wenigen Hersteller, die bereits einen An-droid-Tablet-PC zum Verkauf anbieten, ist der Her-steller Archos. Mit seinem Archos 7 Android Tablet, das bereits für Rund 170 Euro zu haben ist, bietet der Hersteller ein auf Android 1.5 (Cupcake) basierendes Gerät an, das über einen hochauflösenden 7-Zoll-TFT-Touchscreen mit einer Auflösung von 800 x 480 Bildpunkten und 16 Millionen Farben verfügt. Das Gerät lässt sich wie viele Android Smartphones über eine virtuelle Tastatur auf dem Bildschirm bedienen. Einziger Knackpunkt an dem Gerät ist das Installieren von Applikationen. Da Google seinen Android Market lediglich für von Google zertifizierte Geräte aus dem

Smartphone-Segment bereitstellt, ist dieser auf dem Archos-Gerät nicht vorhanden. Archos bietet aus die-sem Grund einen eigenen Application Store namens AppsLib an. Hier können Entwickler Applikationen für das Archos Tablet hochladen und Endanwender können diese dann über den auf dem Gerät vorinstal-lierten Application Store installieren.

Auch die deutsche Firma Neofonie hat mit seinem WeTab ein ähnliches Gerät angekündigt. Bei dem ursprünglich unter dem Namen WePad vorgestell-ten Gerät handelt es sich ebenfalls um einen Tablet-Computer mit Multi-touch-Unterstützung. Obwohl es sich strenggenommen nicht um ein reines Android-Gerät handelt, soll das WeTab Android-Applikationen ausführen können. Denn als Betriebssystem soll eine angepasste Linux-Distribution zum Einsatz kommen, die es erlaubt, Android-Applikationen auszuführen. Parallel dazu wird allerdings auch Adobe Flash sowie der Adobe Reader unterstützt und es sollen auch nati-ve Linux-Programme sowie Adobe AIR auf dem Ge-rät ausführbar sein. Um die zahlreichen verschiedenen Anwendungsplattformen mit Applikationen versorgen zu können, will Neofonie einen eigenen WeTab-Meta-Store bereitstellen, der verschiedene bestehende Stores integriert und dadurch sowohl native, Java-, Linux-, Adobe-AIR- und Android-Applikationen unterstützt. Das Gerät, das über ein 11,6 Zoll großes Display mit einer Auflösung von 1366 x 768 Bildpunkten verfügt, wird in einer Version mit WiFi und in einer Version angeboten, die zusätzlich über 3G und GPS verfügt. Beide Geräte sollen ab September verfügbar sein und 449 Euro (16 GB) bzw. 569 Euro (32GB + 3G/GPS) kosten. Vorbestellungen werden bereits bei Amazon entgegengenommen.

Doch dies sind nur zwei Beispiele für den aktuellen Trend. Viele der wichtigen Smartphone- und Note-book-Hersteller haben entsprechende Geräte in der Pipeline. So hat zum Beispiel Motorolas CEO Sanjay Jha kürzlich angekündigt, dass seine Firma bald ein Android-basiertes Tablet-Gerät anbieten wird. Ein Erscheinungsdatum für das Gerät mit einem 7 bis 10 Zoll großen Display wurde zwar nicht genannt, aber vermutlich kann man noch vor Jahresende mit der Verfügbarkeit eines solchen Geräts von Motorola rechnen. Auch der südkoreanische Konzern Samsung will in den nächsten Monaten einen Tablet-Computer auf den Markt bringen. Mobilspartenchef J.K. Shin bestätigte Pläne für einen iPad-Konkurrenten, der den Namen Galaxy Tab tragen und voraussichtlich mit dem Smartphone-Betriebssystem Android laufen soll. Das Gerät soll im dritten Quartal 2010 auf den Markt kommen. Der Konkurrent LG Electronics hat eben-falls angekündigt, im vierten Quartal ein Tablet auf den Markt zu bringen, das auf Android basiert. Auch der Notebookhersteller Dell springt auf den Trend auf und will mit dem Dell Streak einen Android-basierten Tablet-Computer in verschiedenen Größen anbieten. Es sind Versionen mit 5, 7 und 10 Zoll Display geplant.

Abb. 3: Beim E-Book-Reader Alex von Spring Design kann der Benutzer neben dem E-Paper-Display auch ein Farb-Touchscreen-Display nutzen



Der Hersteller Lenovo hatte bereits vor einiger Zeit ein Tablet-PC vorgestellt, der auf einer eigenen Linux-Distribution basiert. Laut Medienberichten wird diese nun eingestellt und Lenovo wird ebenfalls auf Android umsteigen. Auch hier steht als Verkaufsstart das vierte Quartal im Raum. Der deutsche Internetanbieter 1&1 tritt mit einem eigenen Tablet ebenfalls gegen Apples iPad an. Das SmartPad genannte Gerät, das von NEC gebaut wird, läuft ebenfalls mit Android und wurde von 1&1 gemeinsam mit dem deutschen Unterneh-men Kwest entwickelt. Netzwerkspezialist Cisco hat ebenfalls ein Android Tablet vorgestellt. Das Cius richtet sich allerdings in erster Linie an Businesskunden. Mit ei-ner HD-Kamera auf der Vor-derseite und einer zweiten Kamera auf der Rückseite sowie zwei Mikrofonen zur Rauschunterdrückung soll es vor allem für Videokon-ferenzen eingesetzt werden. Zahlreiche weitere bisher eher unbekannte Firmen haben ähnliche Geräte ange-kündigt. Hierzu gehören unter anderem Ramos mit dem W7 Android MID oder Blue Sky mit seinem BL10 Android Tablet.

Laut Verizon Wireless CEO Lowell McAdam arbei-tet der Hersteller in enger Zusammenarbeit mit Google an einem Android-basierten Tablet-Gerät, das eben-falls als Konkurrenz zum iPad ins Rennen geschickt werden soll. Google selber hält sich allerdings zurzeit noch bedeckt und unterstützt selbst in der Version 2.2 (Froyo) von Android offiziell immer noch keine Ta-blet-PCs, sondern nur Smartphones mit einer relativ kleinen Displaygröße.

Ein anderes Einsatzgebiet für Android ist das Seg-ment der Netbooks. Diese Mininotebooks, die bisher zumeist mit Linux oder Windows ausgeliefert wurden, sind oft von den Ressourcen nicht so leistungsstark wie ein vollwertiges Notebook. Was spricht also da-gegen, Android auf dieser Art von Geräten einzuset-zen, da es sich ja um ein Linux-System handelt, dass speziell auf Smartphones ausgelegt ist, die ebenfalls nur beschränkte Ressourcen bereitstellen können, was Prozessorleistung und Arbeitsspeicher betrifft. Erste Hersteller, die Netbooks mit Android ausliefern, sind beispielsweise Toshiba mit dem AC100 Smartbook. Das 870 Gramm leichte 10-Zoll-Netbook mit Nvidia-Tegra-Prozessor kommt standardmäßig mit Android 2.1 als Betriebssystem. Ein anderes Beispiel ist das As-pire One D250 von Acer, das mit einem Dual-boot-System ausgeliefert wird und bei dem man wahlweise Windows 7 oder Android starten kann. Zusätzlich zu Androids Standardwebbrowser, der auf WebKit ba-siert, liefert Acer das Gerät mit einer Firefox-Variante namens Minefield aus, die dem normalen Firefox in Sachen Funktionalität kaum nachsteht und im Unter-schied zum ebenfalls installierten Android-Browser auch Flash beherrscht.

Es geht auch mit Live-CDWer sich nicht extra ein Netbook kaufen will und An-droid einfach mal auf seinem PC oder Notebook testen möchte, der kann dies mit LiveAndroid tun. Hierbei handelt es sich um ein Open-Source-Projekt, dass eine Live-CD bzw. ein Live-USB-System von Android für x86-Plattformen darstellt. Das aktuell in der Version 0.3 vorliegende Projekt kann man kostenlos als ISO-Datei von der Projektwebsite herunterladen und auf eine CD brennen. Leider basiert die aktuelle Version lediglich auf Android 1.5 und auch den Android Market sucht man

vergeblich. Man kann jedoch Android-Applikationen aus dem Web installieren, die in Form von .apk-Dateien vor-liegen.

Das Problem, mit dem man relativ schnell beim Einsatz von Android auf einem Net-

book oder einem normalen PC konfrontiert wird, ist, dass das Betriebssystem eigentlich auf eine Bedienung per Touchscreen ausgelegt ist. Versucht man das System sowie die Applikationen mit einer Tastatur und Maus zu bedienen, ist dies nicht immer ganz trivial. So starten zum Beispiel Anwendungen nach Einfach- statt Dop-pelklick und Scroll-Balken werden zwar angezeigt, die-nen aber lediglich zur visuellen Orientierung, anklicken kann man sie nicht. Auch Anwendungen, die die Nut-zerinteraktion per Multi-touch unterstützen, machen dann das Bedienen mit der Maus fast unmöglich, wenn die Anwendung keine alternative Interaktionsmethode bereitstellt.

Doch hiermit ist das Spektrum an möglichen Geräten für die Android-Plattform immer noch nicht erschöpft. Auch die ersten E-Book-Reader mit Android sind in-zwischen verfügbar. Das Gerät mit dem Namen Alex von der Firma Spring Design ist eines der ersten Geräte, die man bereits kaufen kann. Das besondere an diesem Gerät ist sein duales Display, das aus einem 3,5-Zoll-Touchscreen-Farb-LCD-Display besteht, das sich ideal zum Browsen im Web eignet, und einem 6-Zoll-EPD (Electrophoretic Display Device), das durch seine E-Pa per-Technologie dem Benutzer eine Optik wie eine gedruckte Seite präsentiert und sich daher vor allem zum Lesen von längeren Texten eignet. Das kleinere Farbdisplay dient unter anderem auch zur Aufzeich-nung von Anmerkungen und Sprachkommentaren, die mit dem jeweils angezeigten E-Book verknüpft werden können. Das Gerät, das in einer reinen WiFi-Variante und zwei verschiedenen Varianten mit 3G ausgeliefert wird, basiert auf Android 1.5. Laut Hersteller soll aber ab Sommer dieses Jahres auch Android 1.6 verfügbar sein. Obwohl das Gerät alle Android-Applikationen unterstützt, die weder GPS noch Kamera oder 3G bei der WiFi-Version verlangen, plant Spring Design einen eigenen Application Store für Alex, der vor allem auch spezielle Applikationen bereitstellen soll, die sich beide Displays des Geräts zunutze machen.

Auch die ersten e-Book-reader mit Android sind inzwischen verfügbar.



Ein Application Store reicht nicht mehrEin Problem, das bei fast allen der hier vorgestellten Anwendungsszenarien für Android zutage tritt, ist, dass Google selber Android im Moment lediglich für das Smartphone-Segment vorgesehen hat. Ein of-fizieller Support von anderen Einsatzgebie-ten wie beispielsweise Tablet-PCs ist nicht vorgesehen; auch eine Automobilplattform wird von Google nicht spezifiziert. Neben der Tatsache, dass Android somit in der aktuellen Version offiziell nur Display-Größen aus der Smartphone-Ka-tegorie unterstützt, ist der Hauptnachteil, dass Goog-le den Android Market nur für Smartphones freigibt und nicht für den Einsatz auf anderen Geräten erlaubt. Dies hat zu Folge, dass Hersteller von entsprechen-den Geräten ihren eigenen Application Store anbieten müssen, um dem Benutzer das Installieren von zusätz-lichen Applikationen auf dem Gerät zu ermöglichen. Ein weiterer Grund, weshalb es oft Sinn macht, einen zusätzlichen Application Store anzubieten, ist, dass Applikationen oft zusätzliche, nicht standardisier-te APIs unterstützen müssen, um die Funktionen des jeweiligen Geräts voll ausnutzen zu können. Vor al-lem im Automobilbereich, wo zusätzliche APIs zum Zugriff auf Fahrzeugfunktionen von Interesse sind, trifft dies zu – aber auch bei einem E-Book-Reader mit zwei Displays, denn die Applikationen müssen speziell darauf abgestimmt sein, wenn sie diese auch nutzen wollen. Was den TV-Bereich betrifft, hat Google ja bereits eine eigene Plattform angekündigt. Bleibt ab-zuwarten, ob Google weitere Plattformen zum Beispiel für Tablet-PCs oder den Automobilbereich definiert und somit einen Art De-facto-Standard schafft, da es ansonsten schnell zur Fragmentierung kommen kann; sowohl was die An droid-Plattform selbst und die be-reitgestellten APIs betrifft als auch die Application Stores, die jeder Hersteller separat für sein spezielles Nischenprodukt bereitstellen muss. Grundsätzlich hat es ja auch seine Vorteile, wenn es alternativen zu Googles An droid Market gibt, doch sowohl für den Entwickler, der seine Anwendung mit viel Aufwand in verschiedenen Application Stores bereitstellen, als auch für den Benutzer, der zig verschiedene Applica-tion Stores auf seinem Gerät nutzen muss, kann die Situation schnell unübersichtlich werden.

FazitMan sieht, dass sich Android außer auf dem Smart-phone inzwischen auch in vielen anderen Bereichen etabliert. Obwohl es sich bei einigen der Produkte und Plattformen lediglich um Ankündigungen handelt, kann man davon ausgehen, dass dieses Jahr noch eine ganze Reihe von neuen Android-basierten Produkten auf den Markt kommen wird. Der Einsatz auf Tablet-PCs wird

vor allem durch den aktuellen Hype um Apples iPad angeheizt und der aktuelle Wandel in der Automobil-industrie verlangt auch bei den Infotainment-Systemen nach neuen Lösungen. Jason Schwarz schreibt in seinen Investment-Newsletter „Economic Weather Sta tion“,

dass bis Ende des Jahres 115 An droid-Handys sowie 50 weitere An-droid-Geräte, die nicht in die Handykategorie fallen, auf dem Markt sein werden. Hierdurch ergeben sich für den An-

droid-Entwickler ganz neue Möglichkeiten und eine Reihe neuer Zielplattformen. Da es sich in den Grund-zügen um die gleiche Plattform handelt, kann man sein bestehendes Know-how weiterverwenden, um in ganz neue Bereiche der Softwareentwicklung vorzudringen. Dadurch, dass sich das Konzept der Application Stores inzwischen etabliert hat, finden die Anwendungen dann auch relativ einfach den Weg zum Nutzer.

Google selbst hat Android im Moment nur für das Smart-

phone-Segment vorgesehen.

Kay Glahn ist unabhängiger iT-Berater mit den Schwerpunkten Mobile Applications und Services. er berät internationale Kunden bei der Umsetzung von Projekten im Mobile-Bereich.

Links & Literatur

[1] design Guidelines für Google Tv: http://www.google.com/tv/developer

[2] website des Continental AutoLinQ SdKs: http://www.autolinq.de/developers.aspx

[3] AppsLib Application Store von Archos: http://appslib.com

[4] website des Alex ereaders: http://www.springdesign.com

[5] website der open embedded Software Foundation: http://www.oesf.jp/en/

[6] website von People of Lava: http://www.peopleoflava.com

[7] Projektseite von LifeAndroid: http://code.google.com/p/live-android/

Mobile CoMMunitys 3 2 1


von Markus braun, Dominik Khan, eray Özmü, Heiko Roßnagel und Jan Zibuschka

Soziale Onlinenetzwerke (Communitys) gewinnen eine immer größere Relevanz, sie werden inzwischen von mehr als einem Viertel der Deutschen genutzt. Der Anteil unter den jugendlichen Nutzern ist sogar noch höher: Neben den populären Communitys im Web wie Facebook, Twitter und Co. hat sich inzwischen auch eine Reihe von Onlinenetzwerken mit Fokus auf mobile Geräte etabliert. Wie der große Anklang bei den Nut-zern vermuten lässt, gibt es auch für Android bereits verschiedene Apps, die die mobile Nutzung von sozialen Netzwerken unterstützen:

Facebook und Twitter bieten hauseigene Android-•Apps an, die die Funktionen der Webcommunitys in einem auf das Handy zugeschnittenen Format zur Verfügung stellen.Außerdem gibt es verschiedene, von Dritten be-•reitgestellte Apps, die entweder eine auf spezifi-sche Features der Communitys (beispielsweise den Facebook-Chat oder thematisch spezifische Tweets) reduzierte Benutzeroberfläche anbieten, verschiedene Communitys integrieren, oder – oftmals aus histori-schen Gründen – in direkter Konkurrenz zur anbie-tereigenen App stehen.Verschiedene Apps bieten Funktionalitäten an, wie •man sie auch in Communitys findet, bauen dabei aber auf eigene oder existierende Infrastrukturen auf. Ein Beispiel hierfür sind Chatclients für unterschiedliche Protokolle wie XMPP oder AIM/ICQ.

Darüber hinaus finden sich spezifische mobile Com-•munity-Apps, die Funktionen wie Chat und Ortung integrieren, um eine mit dem Nutzungskontext ange-reicherte Echtzeitinteraktion in sozialen Netzwerken zu erreichen. Ein typischer Anwendungsfall sind hier Friend Finder, die andere Communitynutzer in der Nähe aufspüren können.

Im Rahmen dieses Artikels wird ein Überblick darüber gegeben, wie man solche Anwendungen verwirklichen kann. Dafür wird die Implementierung einiger beispiel-hafter Kernfunktionalitäten vorgestellt, die teils mit Bordmitteln, teils unter Nutzung existierender Biblio-theken realisiert werden. Zum Abschluss präsentieren wir eine integrierte Anwendung, die verschiedene Com-munitydienste in eine App einbindet, die auf spezifische Szenarien zugeschnitten werden kann.

Mobile Anbindung an WebcommunitysAls ein wichtiges Beispiel für Webcommunitys soll in diesem Abschnitt die Anbindung an den Micro-Blog-ging-Dienst Twitter beschrieben werden. Twitter hat eine relativ breite Nutzerbasis und bietet offene Schnitt-stellen zur Integration in Anwendungen an (Kasten: „Twitter API“). Daher dient dieser Dienst hier als Re-ferenzcommunity.

Unser Beispiel verwendet das Twitter4j API [1], das für Java SE entwickelt wurde, aber auch unter Android fehlerfrei läuft – die Möglichkeit, auf existierende Bi-blikotheken zurückzugreifen, ist eine der großen Stär-ken von Android. Allerdings verwendet die Bibliothek ursprünglich die XML-Schnittstelle von Twitter. Wir

Android-Unterstützung für mobile Communitys

Gemeinsam unterwegs Onlinecommunitys erfreuen sich ungeahnter Beliebtheit – und wandern gleichzeitig auch auf das mobi-le Endgerät. Dies bietet einen Echtzeitzugang zu den Informationen, die die Community vorhält sowie eine Unterstützung von dezidiert mobilen Tätigkeiten mittels sozialer Netzwerke. Hierzu eignen sich verschiedene Schnittstellen und Bibliotheken. Dieser Artikel präsentiert Beispiele für Communityunter-stützung in Android-Anwendungen sowie ein integriertes Anwendungsbeispiel.

Mobile CoMMunitys1 2 3


haben festgestellt, dass Android JSON (JavaScript Ob-ject Notation) schneller verarbeitet, sodass wir das API um die Anbindung an die JSON-Schnittstelle erweitert haben. Der Aufwand hierfür war relativ gering, da die JSON-Verarbeitung vom API zur Verfügung gestellt wird und nur der Download vom Twitter-Server ange-passt werden musste.

Der Aufruf der Bibliothek gestaltet sich ebenfalls denkbar einfach. Als Beispiel soll hier eine Abfrage der öffentlichen Zeitleiste mittels der Twitter-Klasse des Twitter4j APIs präsentiert werden. Die angepasste Me-thode sieht folgendermaßen aus:

public List<Status> getPublicTimeline(Paging paging)throws TwitterException { // USE_JSON ist eine Konstante, die festlegt, ob json // anstatt der xml Schnittstelle verwendet werden soll if (USE_JSON) { return Status.jsonConstructStatuses(get(baseURL + "statuses/public_timeline.json", null, paging, false),this); } else { return Status.constructStatuses(get(baseURL + "statuses/public_timeline.xml", null, paging, false), this); }}

Dabei ist lediglich der Abschnitt neu, der ausgeführt wird, wenn USE_JSON gesetzt ist. Die baseURL spei-chert den URL des Twitter-Servers, um auch die Ein-

bindung communityspezifischer, privater Server zu unterstützen, wie sie etwa durch den Einsatz des Sta-tusNet-Systems [2] umgesetzt werden können. Über die zurückgegebenen Statusobjekte kann man auf einzelne Tweets und Daten der Nutzer, von denen die Nachrich-ten stammen, zugreifen.

Andere Communitys und Web-APIs lassen sich über ähnliche Clientkomponenten in eine mobile „Mash-up“-Applikation einbinden. Ein Beispiel hierfür ist das Facebook SDK für Android, [3] das speziell auf die Plattform zugeschnitten ist und Features wie eine siche-re Authentifizierung über OAuth, Abfrage des sozialen Graphs des Nutzers und Abschicken von Facebook-Bot-schaften erlaubt.

Mobile Communityunterstützung: ChatIn Zeiten des Social Webs gehört die Kommunikation mit Freunden und Bekannten zu einer der wichtigsten Onlineaktivitäten. Die Möglichkeiten von Instant-Messaging-Diensten wie ICQ, AIM oder Skype werden dabei täglich von mehreren Millionen Nutzern in An-spruch genommen. Beim Entwickeln eines Instant-Mes-saging-Programms für Android bietet es sich an, auf das früher Jabber genannte Protokoll XMPP zu setzen, das offen dokumentiert vorliegt. Die Funktionsweise ähnelt dabei dem Simple Mail Transfer Protocol (SMTP), das beim Versenden von E-Mails benutzt wird.

Android bietet dabei bereits eigene APIs an, um mit XMPP-basierten Diensten wie u. a. GTalk zu kommu-nizieren. Dieses API ist in seiner Funktionalität recht eingeschränkt und bietet keine Unterstützung von Funk-tionen wie z. B. einem Gruppenchat. Deshalb lohnt sich der Blick auf externe XMPP-Libraries.

Da bei der Android-Entwicklung Java zum Einsatz kommt, lässt sich mit einigen Anpassungen die Smack XMPP Library von Jive Software [4] einsetzen. Da An-droid jedoch nicht den kompletten Funktionsumfang von Java SE bietet, müssen einige Anpassungen an dieser Open Source Library vorgenommen werden, damit diese zuverlässig auf einem Android-Gerät läuft. Um es Ent-wicklern einfacher zu gestalten, eine für Android-Geräte stabile Version der Smack Library zu erhalten, lässt sich eine solche direkt herunterladen [4]. Nach erfolgreicher Einbindung der Library in das Android-Projekt könnte die Nutzung folgendermaßen aussehen:

private XMPPConnection conn1;protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); conn1 = new XMPPConnection("jabber.org"); conn1.connect(); conn1.login("mtucker", "12345"); …}

Der Quelltext stellt hier eine normale Android Activity mit seiner onCreate()-Methode dar. Zuerst verbindet sich der Client mit dem XMPP-Server auf jabber.org

Twitter API

Der Micro-blogging-Dienst twitter stellt verschiedene schnittstellen für den Abruf interner integrationen zur einbindung in externe Applikationen über Webprotokolle zur Verfügung. Dabei werden Rest-schnittstellen für die Abfrage von nutzerinformationen und die suche nach bestimm-ten schlüsselwörtern in nachrichten (tweets) genutzt, während für das breite Abgreifen eines großen Volumens von tweets eine schnittstelle bereitsteht, die Verbindungen über längere Zeiträume aufrecht erhalten kann und so eine Übermittlung einer Auswahl aktueller tweets in echtzeit ermöglicht. Zur clientseitigen Abwicklung der Kommunikation mit diesen schnittstellen gibt es verschiedene bibliotheken, unter Android kann etwa twitter4j zum einsatz kommen.

XMPP

XMPP steht für extensible Messaging and Presence Protocol und ist ein standard für die nachrichtenübertragung per XMl. Für den betrieb eines XMPP-netzwerks wird mindestens ein XMPP-server benötigt, der ähnlich einem e-Mail-server benutzer authentifiziert und nachrichten weiterleitet. Jeder XMPP-server kann dabei prinzipiell nachrichten mit anderen XMPP-servern austauschen, was die Kommunikation über Anbietergrenzen hinweg ermöglicht. ebenso ist es möglich, nutzer aus anderen Chatnetz-werken wie AiM, iCQ, die nicht auf XMPP als nachrichtenübertragungs-protokoll setzen, anzubinden.

Mobile CoMMunitys 3 2 1


und versucht, sich als Benutzer mtucker mit dem Kenn-wort 12345 anzumelden:

Chat chat = connection.getChatManager().createChat("[email protected]", new MessageListener() { public void processMessage(Chat chat, Message message) { showMyDialog("Erhaltene Nachricht: " + message); }});

Hier wird ein Chat mit dem Benutzer jsmith geöffnet. Der MessageListener wird dabei beim Empfangen von Nachrichten aufgerufen und gibt diese auf der Konso-le aus. Die selbstgeschriebene showMyDialog()-Hilfs-methode erzeugt dabei einen Standard-An droid-Dialog und zeigt die Nachricht darin an:

chat.sendMessage("Howdy!");

Mit der sendMessage()-Methode wird dann schließlich die jeweilige Nachricht versendet. Die Smack Library bietet auch Unterstützung für Freundeslisten, die im XMPP-Jargon Roster genannt werden, sowie Gruppenchats. Die Entwickler der Smack Library bieten ebenso den OpenFire-XMPP-Server an, mit dessen Hilfe sich schnell ein eigenes XMPP-Netz-werk erstellen lässt.

Mobile Communityunterstützung: Friend FinderEin weiteres verbreitetes Feature erfolgreicher mobiler Communitydienste ist der Friend Finder. Dieser Dienst ermöglicht es Teilnehmern, Freunde und Bekannte zu lokalisieren. Die Teilnehmer an einem solchen Dienst müssen sich vorher registrieren und eine Einwilligung zur Ortung abgeben. Solch ein Dienst lässt sich mit rela-tiv einfachen Mitteln auf einen bestehenden Community-dienst aufsetzen, beispielsweise den oben beschriebenen Twitter-Dienst. So kann eine eigene Nutzerverwaltung für speziell diesen Dienst vermieden werden und die Anwender müssen nicht für jeden einzelnen Dienst ihre Freunde und Bekannten eingeben.

Wird der Friend Finder gestartet, bekommt der Be-nutzer zunächst seine Freunde aus der Twitter-Anwen-dung aufgelistet (ListActivity). Aus dieser Liste können einzelne Freunde ausgewählt werden, und ihre Position wird auf Google Maps (MapActivity) anzeigt. Die GPS-Koordinaten werden dabei einfach im jeweiligen Twit-ter-Profil gespeichert. Dazu ist es natürlich notwendig, dass diese GPS-Koordinaten zuvor auch dort abgelegt worden sind. Für das Abfragen der Koordinaten gibt es in Android den Location Service. Um diesen Dienst zu nutzen, benötigt man eine Implementierung des Inter-face LocationListener (Listing 1).

Die Methode onLocationChanged wird aufgerufen, sobald sich die Position ändert. Die Koordinaten wer-den dann an den Twitter-Server geschickt und im Profil

gespeichert. Dafür muss nur noch eine Instanz des Liste-ners mit dem LocationService assoziiert werden:

LocationListener mLocationListener = new MyLocationListener();LocationManager mLocationManager = (LocationManager) getSystemService(Context.LOCATION_SERVICE);mlocationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, 10000, 10, mLocationListener);

Integriertes AnwendungsbeispielIm Rahmen des Projekts VeRSiert [5] ist eine einheitli-che Plattform für all die erwähnten mobilen Dienste für den Einsatz bei Großveranstaltungen entwickelt wor-

den, mit der sowohl Mehrwertdienste für Veranstaltungsteilneh-mer angeboten werden können als auch der Ein-satz von Mobilfunk für das Management von Notfallsituationen unter-

stützt werden kann. Mobile Dienste können in Notfallsi-tuationen verantwortliche Personen bei der Vorbereitung von Evakuierungen, Instruktion und Unterstützung von Einsatzkräften sowie bei der Lokalisierung von Opfern unterstützen. Eine wesentliche Voraussetzung, um auf Notfälle vorbereitet zu sein, ist allerdings, dass die betrof-fenen Personen mit dem Notfallsystem vertraut sind und vernünftig auf die Warnsignale ohne Verzögerungen re-agieren können [6]. Diese Voraussetzung ist sehr schwer zu erfüllen, wenn das System ausschließlich in Notfällen verwendet wird. Der Erfolg eines Notfallmanagement-systems hängt somit sehr stark von geübten Nutzern ab, die mit den Funktionalitäten der Dienste vertraut sind. Bei einem selten genutzten Notfallmanagementsystem können auch nur eingeschränkte praktische Erfahrungen erwartet werden.

Listing 1: Das Interface LocationListener

private class MyLocationListener implements LocationListener { public void onLocationChanged(Location location) { if (location != null && twitter != null) { // Location String im gewünschten Format zusammenbauen String loc = ((int) (location.getLatitude() * 1000000)) + " " + ((int) (location.getLongitude() * 1000000)); try { // Koordinaten an Twitter-Server senden twitter.updateLocation(loc); } catch (TwitterException e) { //Exception behandeln } } }}

Mobile Dienste können in notfallsituationen verantwort-liche Personen unterstützen.

Mobile CoMMunitys1 2 3


Mobile Mehrwertdienste für Großveranstaltungen, die die gleiche Infrastruktur nutzen, können die Ver-trautheit der Nutzer mit dem System verbessern. Sie ha-ben zudem das Potenzial, das Veranstaltungserlebnis für die Teilnehmer attraktiver zu gestalten und die zahlrei-chen professionellen wie ehrenamtlichen Helfer bei der Durchführung der Veranstaltung zu unterstützen.

Damit wird den Teilnehmern eine Plattform bereitge-stellt, auf der sie sich während der Veranstaltung aus-tauschen können. Kommunikationsdienste wie Friend Finder oder Twitter erleichtern einer größeren Gruppe bei unübersichtlichen Veranstaltungen den Überblick und den Zusammenhalt, insbesondere wenn es sich um Veranstaltungen über einen längeren Zeitraum und eine komplexere Örtlichkeit handelt. Mobile Communitys, die über eine Upload-Funktion für Fotos verfügen, können genutzt werden, um eine Dokumentation der Veranstal-tung gemeinsam von den Teilnehmern erstellen zu lassen. Weiterhin bietet dies die Möglichkeit, dem Veranstalter detaillierte Rückmeldungen zu einzelnen Aspekten und Problemen der Veranstaltung zukommen zu lassen.

Die Plattform stellt dabei Basisdienste zur Verfügung, die von Dienstanbietern und Notfallmanagern genutzt werden können. So können die Communityfunktionali-täten den Einsatzkräften zu einem besseren Lagebild bei ungeplanten Ereignissen verhelfen, und Friend-Finder-Dienste sind auch in Notfalllagen geeignet, die jeweili-gen Bezugspersonen wiederzufinden. Abbildung1 zeigt einige Screenshots der VeRSiert-App.

Wie die meisten Android-Anwendungen ist auch die VeRSiert-App in Java geschrieben. Dabei ist zu beach-ten, dass Android eine eigene Virtual Machine (Dalvik) mitbringt und nicht auf Komponenten von Sun zurück-greift, um Anwendungen auszuführen. Dennoch kön-nen viele gewohnte Java-Klassen verwendet werden, die durch Android-spezifische Klassen erweitert wurden.

Was beim Starten der Versiert-App zunächst auffällt, ist das „Spinner“-Control, das als Menü dient, um eine der vier Anwendungen der App zu starten (neben den hier beschriebenen Anwendungen gibt es auch einen di-rekten Zugriff auf Google Maps). Im Gegensatz zu den gängigen Controls wie Buttons, Labels und TextFields

musste dieses Control selbst implemen-tiert werden.

Der Spinner erweitert die View-Klas-se, von der auch alle anderen Controls abgeleitet sind. Um Bilder oder geomet-rische Figuren auf das User Interface zu zeichnen, überschreibt der Spinner die onDraw-Methode.

ZusammenfassungMobile Communitys werden immer beliebter. Es ist unter Android relativ einfach, die dafür notwendigen Funkti-onen zu unterstützen, da man feststellt, dass Android für alle Bedürfnisse die passenden Klassen zur Verfügung stellt,

die größtenteils sehr einfach zu verwenden und schnell eingebunden sind. Darüber hinaus stehen verschiedene Bibliotheken aus dem Java-Umfeld zur Verfügung, die die Nutzung der von den Onlinenetzwerken angebo-tenen Schnittstellen vereinfachen. Eine Unterstützung mobiler Communityfunktionen eröffnet neue Anwen-dungsfälle und kann auch für existierende Programme einen Schub in der Verbreitung bewirken.

Abb. 1: Screenshots der VeRSiert-App

Links & Literatur

[1] twitter4J: http://twitter4j.org

[2] statusnet Microblogging service: http://status.net/

[3] Facebook sDK for Android: http://github.com/facebook/facebook-android-sdk/

[4] smack library für Android: http://code.google.com/p/asmack/

[5] Projekt VeRsiert: http://www.versiert.info

[6] e. Gruntfest and C. Huber: status report on flood warning systems in the united states, environmental Management, 13, (3) (1989) 279–286

Markus Braun studiert informatik am Karlsruhe institute of technology und arbeitet seit Anfang 2010 als studentischer Mitarbeiter am institut für Arbeits-wissenschaft und technologiemanagent der universität stuttgart.

Dominik Khan studiert an der Hs Heilbronn im studiengang electro-nic business und arbeitet am iAt der uni stuttgart als studentischer Mitarbeiter. er beschäftigt sich mit Java- und Webtechnologien, ver-fügt jedoch auch über betriebswirtschaftliche Kenntnisse und it-Pro-jekterfahrung.

Dr. Heiko Roßnagel arbeitet am Fraunhofer iAo. er beschäftigt sich mit Wirtschaftlichkeit von it-sicherheit und mit mobilen Diens-ten und Anwendungen.

Eray Özmü studiert an der Hs Heilbronn im studiengang electro-nic business und arbeitet am iAt der uni stuttgart als studenti-scher Mitarbeiter. er interessiert sich vor allem für die entwicklung von grafischen benutzerschnittstellen und deren integration in mo-bile endgeräte.

Jan Zibuschka arbeitet am Fraunhofer iAo. er beschäftigt sich mit mobilem identitätsmanagement und Wirtschaftlichkeit von it-si-cherheit, verfügt aber auch über langjährige erfahrung im bereich Computergrafik und innovative eingabesysteme.

Das anDroiD-sicherheitsmoDell 3 2 1


von christian Küster

Mit der Android-Plattform gelang Google der Einstieg in das Segment der mobilen Plattformen. Ziel des Pro-jekts ist eine Plattform für mobile Geräte wie Telefone, PDAs oder auch Netbooks. Bemerkenswert ist dabei, dass die komplette Plattform unter verschiedenen frei-en Lizenzen verfügbar ist. So basiert das Gesamtsystem auf Linux und weiteren freien Bibliotheken aus dessen Umfeld, was einen detaillierten Einblick in die Interna von Android ermöglicht. Gleichzeitig ermöglicht die Li-zenz von Android aber auch, dass Hersteller von Mo-biltelefonen den möglicherweise veränderten Quellcode der Plattform nicht wieder freigeben müssen. So ist der Großteil der zurzeit im Markt befindlichen Geräte mit einer modifizierten Android-Plattform ausgestattet. Der von Google unter dem Namen Android Open Source Project (AOSP) freigegebene Teil ist jedoch eine voll funktionstüchtige Plattform für moderne Smart phones, der bis auf konkrete Treiber für spezifische Hardware-funktionalitäten alles Wichtige bereitstellt.

Die modernen Smartphones von Herstellern wie App-le, Nokia oder BlackBerry bieten dem Anwender den einfachen Zugriff auf einen jeweiligen Downloadmarkt an – neudeutsch auch App Store genannt –, in der sich Anwender neue Applikationen leicht herunterladen und installieren können. Das wirft allerdings einige Sicher-heitsbedenken auf. Inwieweit kann man Fremdappli-kationen trauen, die aus einem Markt heruntergeladen wurden? Niemand, auch nicht der Betreiber des Mark-tes, kann gewährleisten, dass Applikationen frei von Schadcode sind. Zu diesem Zweck wurde beim Entwurf von Android auf ein Sicherheitsmodell Wert gelegt, dass solche Gefahren minimieren soll. Zum einen setzt es auf die Fähigkeit des Benutzers, die Sinnhaftigkeit von Be-

rechtigungen einer Applikation einzuschätzen, zum an-deren auf technische Maßnahmen, auf die im weiteren Verlauf eingegangen wird.

VirtualisierungApplikationen werden unter Android virtualisiert aus-geführt. Die Eigenentwicklung der virtuellen Maschine Dalvik interpretiert dabei so genannten Dalvik-Bytecode. Dieser wird bei der Entwicklung von Applikationen zur-zeit aus Java-Bytecode transformiert, was die Verwen-dung eines üblichen Java-Compilers und der für einen Java-Entwickler gewohnten Entwicklungsumgebung, wie beispielsweise Eclipse, ermöglicht. Die Transforma-tion des Java- in den Dalvik-Bytecode wird erst vor der Paketierung der Applikation durchgeführt. Die Verwen-dung von Virtualisierung bietet üblicherweise einen zu-sätzlichen Schutz vor Schadcode, der das Gesamtsystem beeinflusst, da dieser zunächst aus der Virtualisierung ausbrechen müsste. Seit einiger Zeit ist es jedoch mittels des Native Development Kits [1] für Android möglich, innerhalb von Applikationen nativen Code ausführen zu lassen. Daher ist die Verwendung einer Virtualisierung in Android keine zusätzliche Verteidigungslinie. Das wird ebenfalls durch den Umstand deutlich, dass der Java Security Manager und dessen Berechtigungssystem innerhalb von Android keinerlei Rolle spielen. Mit des-sen Hilfe wäre es lediglich möglich, ein Sicherheitsmodell innerhalb von Java-Code durchzusetzen, wie dies bei-spielsweise für die Ausführung von in Webseiten einge-betteten Java Applets innerhalb von Browsern der Fall ist. Die Ausführbarkeit von nativem Code würde dagegen ein Ausbrechen aus dem Java Security Manager zu einem leichten Unterfangen machen.

Um trotzdem eine geeignete Isolation von Prozessen zu gewährleisten, wurde eine Stufe tiefer angesetzt.

Eine Übersicht über die Sicherheitskonzepte der mobilen Plattform

The Guardian Die Android-Mobilplattform bietet ein innovatives Sicherheitsmodell, das Entwickler und Endanwender gleichermaßen zufriedenstellen möchte. Doch mit welchen technischen Tricks und Kniffen haben die Entwickler versucht, die Plattform gegen unbefugte Eingriffe zu schützen? – ein kleiner Einblick in die Tiefen von Android.

Das anDroiD-sicherheitsmoDell1 2 3


Der Linux-Prozess selbst stellt die Vertrauenseinheit der Android-Plattform dar. Das wird dadurch gewähr-leistet, indem jede installierte Applikation unter einer eigenen, exklusiven Benutzeridentität (Linux UID) aus-geführt wird. Zum Installationszeitpunkt der Applikati-on wird vom Paketmanager eine freie Benutzeridentität zugeteilt, mit deren Rechten anschließend die Applika-tion läuft. Die Prozessisolation des Linux-Kernels über-nimmt dabei automatisch die Absicherung der einzelnen Android-Applikationen untereinander, denn Prozesse mit unterschiedlicher Benutzeridentität können nicht einfach aufeinander zugreifen.

Androids SicherheitsmechanismenWichtigstes Instrument in Androids Sicherheitsmodell ist das Berechtigungskonzept, eine Form von Manda-tory Access Control. Alle Aktionen, die entweder das Gesamtsystem oder andere Applikationen beeinflussen können, müssen von der Anwendung explizit deklariert werden und bedürfen der Zustimmung des Benutzers. Dazu gehört beispielsweise die Möglichkeit, ein Netz-werk zu verwenden oder auf Telefonfunktionen und -daten zugreifen zu können. Die von der Applikation ge-wünschten beziehungsweise benötigten Berechtigungen müssen vom Entwickler zum Entwicklungszeitpunkt im Manifest der Applikation mittels <uses-permission> de-klariert werden (Abb. 1).

Bei der Installation der Software werden sie dem Be-nutzer vom Paketmanager aufgeführt. Dieser kann dann

über die Sinnhaftigkeit der Berechtigungen entscheiden. Sollte eine Applikation eine nicht berechtigte Aktion durchführen, terminiert sie (in vielen Fällen) mit einer Sicherheitsverletzung und wird beendet (Abb. 2).

Android gibt eine Reihe von Berechtigungen vor, so z. B. die Berechtigung, Telefonfunktionen zu nutzen oder das Netzwerk zu verwenden. Wichtiger weiterer Eckpfeiler ist auch der Zugriff auf durch den Content-Provider gekapselte Daten. Android deklariert dutzende verschiedene Berechtigungen wie den Zugriff auf Netz-werk, GPS, das Abfangen eingehender SMS oder auch Zugriff auf Kamera und Ähnliches.

Die Durchsetzung der eingenommenen Berechti-gungen wird auf verschiedenen Ebenen der Plattform erreicht. Zwei Eckpfeiler sind dabei die Benutzeriden-tität der Applikation sowie die Benutzergruppen (Linux GIDs), in denen die Benutzeridentität Mitglied ist. Die Berechtigung zur Verwendung von Netzwerkfunkti-onalität wird z. B. anhand der Mitgliedschaft in einer speziellen Linux-Gruppe (Gruppe inet) ermittelt. Die entsprechende Kontrolle der Zugehörigkeit zur Grup-pe wird auf Kernel-Ebene durchgeführt, wofür Android eine Kernel-Modifikation verwendet.

Die Genehmigungen werden zusätzlich in so genannte Risk-Levels unterteilt, die darüber entscheiden, wie das System mit den Berechtigungen umzugehen hat. Man unterscheidet die Stufen normal, dangerous, signature und systemOrSignature. Alle mit dem Risk-Level nor-mal deklarierten Genehmigungen werden der anfordern-den Applikation automatisch ohne Benutzernachfrage zugeteilt. Der Benutzer kann bei der Installation diese Genehmigungen jedoch einsehen. Bei dangerous wer-den die angeforderten Genehmigungen dem Nutzer bei der Installation einer Applikation zur expliziten Zu-stimmung vorgelegt. Berechtigungen dieser Stufe haben einen direkten Einfluss auf das Gerät, andere Applikati-onen oder Benutzerdaten. Insbesondere können sie mehr Kontrolle über das Gerät übernehmen, als eventuell ge-wünscht. Eine mit signature deklarierte Genehmigung kann nur dann erteilt werden, wenn die deklarierende Applikation mit demselben Zertifikat unterschrieben ist, wie die Applikation, die diese Genehmigung ein-nehmen will. Ist dies der Fall, wird die Genehmigung automatisch erteilt. Berechtigungen der Stufe systemOr-

Abb. 1: Auswahl der von der Applikation deklarierten Berechtigungen während der Entwicklung

Abb. 2: Log-Ausgabe beim Versuch, ein Netzwerk-Socket ohne entsprechende Berechtigung zu verwenden

Das anDroiD-sicherheitsmoDell 3 2 1


Signature werden nur den Applikationen erteilt, die mit dem System-Image ausgeliefert wurden oder das gleiche Zertifikat aufweisen wie Applikationen, die mit dem System-Image ausgeliefert wurden.

Das Genehmigungskonzept folgt dem Alles-oder-nichts-Konzept: Der Benutzer muss entweder der Instal-lation und damit allen angeforderten Genehmigungen zustimmen oder den Abbruch der Installation veranlas-sen. Alle einmal erteilten Genehmigungen können zu jeder Zeit im Paketmanager eingesehen, jedoch nicht entzogen werden; es steht lediglich die komplette Deins-tallation der Applikation zur Verfügung (Abb. 3).

DatenabstraktionEin weiterer Sicherheitsmechanismus wurde für den Zu-griff auf Daten des Systems und anderer Applikationen entwickelt. Es muss Applikationen möglich sein, auf Daten anderer Applikationen oder des Systems zugreifen zu kön-nen. Dabei muss jedoch gewährleistet werden, dass dies nur unter Durchsetzung der Sicherheitsrichtlinien möglich ist. Daher hat jede Applikation ein eigens für sich abge-schlossenes Heimatverzeichnis, in das sie Daten nur für ihre eigene Lese- und Schreibberechtigung ablegt. Dies ge-schieht auf Basis des üblichen Linux-Discretionary-Access-Control-Modells, das für jede Datei definierbar macht, ob nur ein bestimmter Benutzer, eine Benutzergruppe oder „alle“ entweder Lese-, Schreib- oder Ausführungsberech-tigung haben. Da jede Applikation unter einer exklusiven Benutzeridentität läuft, lässt sich eine Datei einer ande-ren Applikation nur dann lesen oder beschreiben, wenn sie „für alle“ zugreifbar ist. Das ist nur durch das expli-zite Setzen des WORLD_READABLE beziehungsweise WORLD_WRITABLE Flags bei der Dateianlage mög-lich. Von einem solchen Vorgehen ist jedoch abzuraten, da Android mit dem Konzept der Content-Provider eine elegantere Möglichkeit der Datenabstraktion bereitstellt. Mit ihrer Hilfe wird ebenfalls gewährleistet, dass das Be-rechtigungssystem auch für den Zugriff auf fremde Daten verwendet werden kann. Berechtigungen können sogar für lesenden und schreibenden Zugriff einzeln deklariert werden. Dabei werden die Berechtigungen geprüft, wenn die Applikation einen Providerzugang anfordert sowie auch bei jeder Operation auf dem Provider. Ein Beispiel für eine Zugriffsberechtigung auf einen von Android aus-gelieferten Content-Provider ist die READ_CONTACTS-Berechtigung, die den Zugriff auf den Content-Provider für die Kontaktdaten erlaubt.

Content-Provider verwenden ebenfalls ein feingranu-lares Berechtigungskonzept für URIs, die den Ort der Daten spezifizieren. Das Konzept der URI-Berechtigun-gen erlaubt es, dass ein Content-Provider sehr spezifisch den Zugriff auf ein bestimmtes Datum erteilt, das unter einer spezifizierten URI zu finden ist und zwischen Appli-kationen geteilt werden soll. Es kann dabei schreibender oder lesender Zugriff erlaubt werden. Gibt beispielswei-se eine E-Mail-Applikation die URI, unter der ein spezi-fisches Attachment zu finden ist, an den entsprechenden Handler weiter, braucht diesem nicht der komplette Zu-

Abb. 3: Ansicht der Berechtigungen einer Applikation im Paketmana-ger von Android

griff auf E-Mail-Daten erlaubt werden, sondern ledig-lich der Zugriff auf das eine Attachment.

Zugriffsrechte auf PartitionsebeneUm die höchstmögliche Sicherheit vor Systemmodifikatio-nen zu gewährleisten, wurde ebenfalls der grundsätzliche Dateisystemaufbau überdacht und im Gegensatz zu ei-nem Standardaufbau auf dem Linux-Desktop angepasst. Systemkritische Daten und ausführbare Dateien werden unterhalb von /system/ abgelegt. Applikationsdaten wer-den unter /data/ abgelegt. Die /system-Partition ist per Vorgabe nur lesend eingehängt. Auf ihr befinden sich alle Programme und Systemdienste der Android-Plattform. Zu diesen gehören auch die standardmäßig ausgelieferten Applikationen wie Kontaktmanagement, Telefonappli-kation u. Ä. Dies verhindert auf Betriebssystemebene das Überschreiben von Systemkomponenten. Für den Aus-tausch von Android-Applikationen, die mit dem System ausgeliefert wurden, z. B. die Telefonapplikation, wird eine Ausnahmebehandlung verwendet, indem ein lokales Overlay angelegt wird. Die Applikation wird in die /data-Partition installiert und der Paketmanager „verbirgt“ die ältere Variante auf der Systempartition.

Das anDroiD-sicherheitsmoDell1 2 3


Da Android ebenfalls die Möglichkeit bietet, exter-ne Medien automatisiert einzubinden, wurde auch hier ein Trick angewendet. Um zu verhindern, dass nativer Schadcode über ein externes Medium eingeschleust wird, werden Medien mit der Option noexec eingehan-gen. So verhindert der Linux-Kernel, dass Programme, die auf einem externen Medium eingebunden werden, überhaupt ausgeführt werden können.

ApplikationssignaturenJede Android-Applikation muss vom Entwickler mit ei-ner Signatur versehen werden, die den Entwickler eindeu-tig identifiziert. Dabei ist es unerheblich, ob diese vom Entwickler in den Android-Market gestellt oder direkt in-stalliert wird. Der Paketmanager verweigert sonst die In-stallation der Applikation. Der private Schlüssel verbleibt dabei ausschließlich im Besitz des Entwicklers. Eine zen-trale Zertifikatsautorität, die die Authentizität der Signa-tur garantiert, ist nicht zwingend erforderlich; es besteht jedoch die Möglichkeit, Zertifikate von einer Autorität unterschreiben zu lassen. Zurzeit existiert jedoch keine zentrale Autorität von Google, daher ist es auch möglich, selbstsignierte Zertifikate zu verwenden. Die Zertifikate werden jedoch nur für Vertrauensbeziehungen zwischen den installierten Applikationen verwendet. Sie kontrollie-ren einerseits, ob die Applikation berechtigt ist, auf signa-turbasierte Berechtigungen zuzugreifen, und andererseits, ob zwei Applikationen unter derselben Benutzer-ID lau-fen dürfen und somit eine größere Vertrauensbeziehung zueinander haben, als zwei sich fremde Applikationen.

Spezialanpassungen? Linux vs. AndroidDer von Android verwendete Linux Kernel hat einige Spe-zialanpassungen, die unter anderem Sicherheitsaspekte berücksichtigen. So verwendet Android OpenBinder als alternatives Interprozess-Kommunikationsframework, statt des üblicherweise unter Linux verwendeten System-

V-IPC. Der Austausch der Komponente beruht unter anderem auf Sicherheitsbedenken gegenüber dem System-V-IPC, bei dem es unter Umständen zu Ressourcenverlus-ten kommen kann; beispielsweise bei Verwendung von System-V-Semaphoren [2]. Zusätzlich kontrolliert Open-Binder auch, welche Prozesse Operationen auf entfernten Objekten durchführen dürfen, und bietet somit ein Sicher-heitsmodell auch auf IPC-Ebene [3]. Um die Durchset-zung von Restriktionen auf die Netzwerkverwendung zu ermöglichen, musste ebenfalls der Kernel angepasst wer-den. Der entsprechende Kernel-Code zum Öffnen eines Netzwerk-Sockets kontrolliert nun, ob der anfordernde Prozess in der entsprechenden Benutzergruppe zur Ver-wendung von Netzwerk ist. Dieser befindet sich nur dann in der Gruppe, wenn der Applikation die Berechtigung INTERNET zugeteilt wurde. Dabei wurde ebenfalls dar-auf geachtet, dass nur eine minimale Anzahl von externen Bibliotheken unter Android zur Verfügung steht, um die Komplexität zu minimieren. Besondere Arbeit wurde in eine eigens aus der NetBSD-Standard-C-Bibliothek abge-wandelte Bibliothek gesteckt, um nur die wirklich benö-tigten Funktionalitäten zur Verfügung zu stellen.

Zusätzlich zu den genannten Sicherheitsfunktionen bietet Android noch die Möglichkeit, sich zu einem Vir-tual Private Network zu verbinden. Zur Verfügung ste-hen dabei zwei unterschiedliche Varianten: zum einen die PTPP-Variante, die mittels OpenVPN implementiert ist, zum anderen die direkte Unterstützung von Virtual Private Networks mittels IPSec.

Eine Plattform mit VerstandDas Sicherheitsmodell von Android ist ein pragmatischer Ansatz zwischen technischer Durchsetzung und Bedien-barkeit durch den Benutzer des mobilen Geräts. Benut-zer können daher sicher sein, dass Applikationen nur Funktionen und Daten nutzen, für die die Applikation die Berechtigung hat. Jedoch benötigt das Modell zwei Standbeine, ohne die es nicht funktionieren kann: Zum einen sollte der Entwickler nicht aus Bequemlichkeit ein-fach Berechtigungen deklarieren, die seine Applikation gar nicht benötigt. Eine ehrliche und akkurate Definiti-on verhindert, dass es zu einer inflationären Deklarati-on von Berechtigungen kommt und Nutzer einfach ihr O.K. geben, weil „es ja überall so ist“. Zum zweiten ist der Nutzer gefragt – er sollte sich die Berechtigungen ei-ner Applikation genau anschauen und die Sinnhaftigkeit überprüfen. Denn warum sollte das neu installierte Spiel unbedingt Zugriff auf die Kontaktdaten erhalten?

Abb. 4: Einstellungsdialog zur Erstellung einer VPN-Verbindung in Android

Links & Literatur

[1] android nDK: http://bit.ly/a360_security_1[2] android.git.kernel.org auf Git: http://bit.ly/a360_security_2[3] openBinder: Binder iPc mechanism: http://bit.ly/a360_security_3

Christian Küster ist softwareentwickler bei der tarent Gmbh in Bonn und beschäftigt sich im rahmen seiner tätigkeit vor allem mit mobilen themen und freien mobilen Plattformen wie android, maemo oder meeGo.

Location aPi1 2 3


von Lars Vogel

Über das Location API kann der Entwickler auf die aktuellen Geodaten des Geräts zugreifen und sich über Veränderungen informieren. Des Weiteren kann man einen Radius um einen Geopunkt definieren und Proximity Alerts auslösen, wenn man in diesen Ra-dius eintritt. Das Location API ist Teil des android.location-Packages und Bestandteil der standardisier-ten Android-Implementierung. Somit steht dieses API auf jedem Android-Gerät und damit jedem Android-Entwickler frei zur Verfügung. Weiterhin bietet das Android SDK die Möglichkeit, Google Maps zu nut-zen. Hiermit lassen sich sehr schön Geodaten auf einer Karte visualisieren. Das Google Maps API ist nicht frei und unterliegt den Lizenzbestimmungen von Google. Die Trennung zwischen Google API und Android API

ist aus technischer Sicht (noch) kein Problem, da fast alle Android-Geräte beide APIs anbieten. Man sollte sich aber bewusst sein, dass Google Maps kein freier Standard ist – und falls man diese kommerziell nutzen will, sollte man sich mit der Lizenz auseinanderset-zen.


Standortbestimmung und schöne Aussichten

Fast jedes Android-basierte Gerät erlaubt es, seine Geoposition zu bestimmen. Standort- und Positionsdienste machen gerade bei mobilen Applikationen Sinn. Antworten auf die Fragen wie „Gibt es in der Nähe einen Supermarkt?“ oder „Wer hat gerade in der näheren Umgebung getwittert?“ lassen sich schön in eine mobile Applikation integrieren. Dieser Artikel zeigt die Grundlagen der Positions- und Standortdienste in Android und erklärt die Verwendung von Google Maps.

Voraussetzungen

in diesem artikel setzen wir grundlegende android-Pro-grammierkenntnisse voraus. Einen Einstieg in die android-Programmierung findet der Leser in dieser ausgabe unter [1]. als Entwicklungsumgebung wird Eclipse verwendet. Das Endergebnis findet sich auf der cD. Das Projekt steht auch per Versionsverwaltung Git unter [2] bereit.

Location aPi 3 2 1


Location APIDas Location API besteht im Großen und Ganzen aus drei Klassen. Die Klasse LocationManager schafft Zu-griff auf den Android-Service, der die Positionsdiens-te verwaltet. Auf diesen greift man mit der Methode getSystemService(Context.LOCATION_SERVICE) zu. Der LocationManager erlaubt, dass man sich über die Methode getLastKnownLocation(provider) ein Objekt der Klasse Location holt. Als Provider stehen zwei Festwerte zur Verfügung, gps und network. network würde die ungefähre Position, z. B. basierend auf einer Triangulation aus der Stärke der verwendeten Sendemasten, ermitteln, während gps die GPS-Position (Global Positioning System) ermittelt. Wir nutzen im Folgenden den GPS-Provider.

Die dritte Klasse im Bunde ist der LocationListener. Diesen kann man beim LocationManager registrieren und sich so über Veränderungen in den Geopositions-daten informieren lassen. Hier kann man z. B. festlegen, dass man alle 100 Sekunden oder alle fünf Meter be-nachrichtigt wird. Wie immer bei der mobilen Program-mierung sollte man die Batterie des Geräts schonen und diese Werte so hoch wie möglich setzen.

Standortbestimmung im SimulatorAm besten lässt sich natürlich das Location API in der Realität testen. Da es für einen iterativen Entwick-lungsprozess unpraktisch ist, mit dem Handy durch die Gegend zu laufen, bietet das Android SDK an, die aktuelle Geoposition im Emulator zu setzen. Hierzu startet man eine Konsole und verbindet sich via telnet mit dem Emulator, z. B. auf den Standardport 5554 mit dem Befehl telnet localhost 5554. Den tatsächli-chen Port kann man in der Titelleiste des Emulators sehen. Danach kann man die aktuelle Position mit dem folgenden Kommando setzen: geo fix Längengrad Breitengrad Höhe, wobei der dritte Parameter optional ist: z. B. geo fix 13.24 52.31.

Alle Theorie ist grauGenug der Worte – wollen wir Taten folgen lassen. Wir legen ein neues Android-Projekt de.vogella.android.locationapi.pathfinder an. Obwohl wir zunächst nur das Standard-Android-API nutzen wollen, wählen wir gleich als Target Google API in Version 2.1 (Abb. 1). Falls noch nicht vorhanden, legt man dazu passend ein Device an (Abb. 2). Durch die Verwendung der Goo-gle API als Target können wir später unser Beispiel mit Google Maps ausbauen; wählt man als Target Android API, stehen die benötigten Bibliotheken nicht zur Ver-fügung. Danach passen wir das Layout in der Datei /res/layout/main.xml an (Listing 1). Damit ist der visuelle Teil zunächst fertig und wir können uns um Berechti-gungen und das Coding kümmern.

Darf ich das?Um Android-Applikationen Zugang zum Location API zu geben, benötigt die Applikation sowohl Be-


Standortbestimmung und schöne Aussichten

Fast jedes Android-basierte Gerät erlaubt es, seine Geoposition zu bestimmen. Standort- und Positionsdienste machen gerade bei mobilen Applikationen Sinn. Antworten auf die Fragen wie „Gibt es in der Nähe einen Supermarkt?“ oder „Wer hat gerade in der näheren Umgebung getwittert?“ lassen sich schön in eine mobile Applikation integrieren. Dieser Artikel zeigt die Grundlagen der Positions- und Standortdienste in Android und erklärt die Verwendung von Google Maps.

Abb. 1: Einstel-lungen im Android Project Wizard

Abb. 2: Neuanlage eines Devices

rechtigung zum Internet als auch zu den GPS-Daten. Für den Simulator wird auch die Berechtigung für Simulation der Positionsdaten benötigt. Hierzu tragen wir die folgenden Berechtigungen in das AndroidManifest.xml ein:

<uses-permission android:name= "android.permission.ACCESS_FINE_LOCATION"></uses-permission>

Location aPi1 2 3


Anzeige

Listing 1: Das Layout in der main.xml

<?xml version="1.0" encoding="utf-8"?><LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:orientation="vertical" android:layout_width="fill_parent" android:layout_height="fill_parent"><TextView android:id="@+id/TextView01" android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="Longitute: "></TextView>

<TextView android:id="@+id/TextView02" android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="unknown"></TextView><TextView android:id="@+id/TextView03" android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="Latitude: "></TextView>

<TextView android:id="@+id/TextView04" android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="unknown"></TextView><Button android:id="@+id/Button01" android:layout_width="wrap_content" android:layout_height="wrap_content" android:onClick="showLocation" android:text="Show"></Button>

</LinearLayout>

Listing 2

public class Pathfinder extends Activity { /** Called when the activity is first created. */ @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main); }

public void showLocation(View view) { switch (view.getId()) { case R.id.Button01: LocationManager locationManager = (LocationManager) getSystemService(Context.LOCATION_SERVICE); Location location = locationManager.getLastKnownLocation (LocationManager.GPS_PROVIDER); TextView longitudeField = (TextView) findViewById(R.id.TextView02); TextView latituteField = (TextView) findViewById(R.id.TextView04); if (location != null){ float lat = (float) (location.getLatitude()); float lng = (float) (location.getLongitude()); longitudeField.setText(String.valueOf(lng)); latituteField.setText(String.valueOf(lat)); } else { longitudeField.setText("GPS not available"); latituteField.setText("GPS not available"); } break; } }}

Listing 3: Das Layout „main.xml“

<?xml version="1.0" encoding="utf-8"?><RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android" android:id="@+id/mainlayout" android:orientation="vertical" android:layout_width="fill_parent" android:layout_height="fill_parent">

<com.google.android.maps.MapView android:id="@+id/mapview" android:layout_width="fill_parent" android:layout_height="fill_parent" android:clickable="true" android:apiKey="Your Maps API Key" />

</RelativeLayout>

Listing 4: Erweiterung der Klasse „Pathfinder“

public class Pathfinder extends MapActivity { private MapView mapView; private MapController mapController;

public void onCreate(Bundle bundle) { super.onCreate(bundle); setContentView(R.layout.main); mapView = (MapView) findViewById(R.id.mapview); mapView.setBuiltInZoomControls(true); // ZoomControls mapView.setSatellite(true); // Set View to Satellite mapController = mapView.getController(); mapController.setZoom(14); LocationManager locationManager = (LocationManager) getSystemService(Context.LOCATION_SERVICE); locationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER,0,0, new GeoUpdateHandler()); initMyLocation(); }

public class GeoUpdateHandler implements LocationListener { @Override public void onLocationChanged(Location location) { int lat = (int) (location.getLatitude() * 1E6); int lng = (int) (location.getLongitude() * 1E6); mapController.animateTo(new GeoPoint(lat, lng)); } // Leere Methoden weggelassen } private void initMyLocation() { MyLocationOverlay myLocOverlay = new MyLocationOverlay(this, mapView); myLocOverlay.enableMyLocation(); myLocOverlay.enableCompass(); mapView.getOverlays().add(myLocOverlay); } @Override protected boolean isRouteDisplayed() { return false; }}

Die Schwerpunkte des Hefts:

Enterprise Architecture Management | Cloud Computing, SOA, BPM | Agiles Projektmanagement | Change Management | Enterprise Integration | IT Governance | Open Source im Unternehmen

Gleich abonnieren und die erste Ausgabe gratis lesen!

Location aPi 3 2 1

Anzeige

<uses-permission android:name= "android.permission.ACCESS_MOCK_LOCATION"></uses-permission><uses-permission android:name= "android.permission.INTERNET"></uses-permission>

Jetzt aber: Wo bin ich denn nun?Unsere Activity halten wir einfach (Listing 2). In der Methode showLocation holen wir uns den GPS-Location Manager. Ist dieser nicht null (Kasten: „Tipp“), ge-ben wir den Längen- und Breitengrad auf dem UI aus.

Jetzt kann man die Applikation starten und bekommt beim Drücken des Buttons Show die aktuelle Geopositi-on angezeigt. Leider wird unser UI in unserem Freundes-kreis keine Begeisterung auslösen. Also ran an Google Maps!

Der Schlüssel zur KarteDas Google Maps API steht uns zur Verfügung, da wir als Target bei der Erstellung unseres Projekts das Target Google API haben. Um dieses API verwenden zu kön-nen, benötigt man einen API-Schlüssel von Google. Vo-raussetzung, um den Schlüssel beantragen zu können, ist ein existierender Google-Benutzer und eine MD5-Prüfsumme, die man sich per Kommandozeile generiert. Diese Prüfsumme basiert auf dem Zertifikat, mit dem die Applikation signiert wird. Dies geschieht während der Entwicklung mit dem so genannten Debug-Zertifi-kat. Unter Windows XP erzeugt man diese Prüfsumme für das Debug-Zertifikat wie folgt:

keytool -list -alias androiddebugkey -keystore C:\Documents and Settings\ <user>\.android\debug.keystore -storepass android -keypass android

Das Programm keytool findet man in der JDK-Installation unter /bin/. Detailliert beschrieben ist die Vorgehensweise unter [3]. Als Ergebnis bekommt man einen MD5-Fin-gerabdruck, mit dem man unter [4] seinen Map-Schlüssel beantragen kann. Klingt umständlich? Ist es leider auch, aber man sagt ja: Schönheit hat ihren Preis.

FaceliftingWir wollen nun unsere Applikation aufpeppen. Als Erstes müssen wir die Google-Maps-Bibliothek unserem Projekt bekannt machen. Dazu öffnen wir die AndroidManifest.xml und wählen den Application-Tab aus. Unter Application Nodes drücken wir Add, wählen Uses Library und pflegen com.google.android.maps als required ein (Abb. 3). Das Layout main.xml ersetzten wir mit Listing

Tipp

Bei der direkten Verwendung des Location aPi wird der GPS-Provider nicht immer automatisch gestartet bzw. bekommt nicht immer ein Up-date. Der GPS-Provider sollte gestartet werden, sobald man die erste Position per telnet und „geo fix“ gesetzt hat. ansonsten ist der GPS-Provider null. Leider klappt das nicht immer. Hier kann man dann einfach über das android-Menü im Emulator GooGle Maps auswählen. Danach läuft der GPS-Provider auch im Emulator.

Anzeige

Location aPi1 2 3


Listing 5: Erweiterung der Klasse „MyOverlays“

public class Pathfinder extends MapActivity { // wie bisher private MyOverlays itemizedoverlay; public void onCreate(Bundle bundle) { // wie bisher Drawable drawable = this.getResources().getDrawable(R.drawable.pen); itemizedoverlay = new MyOverlays(drawable); }

public class GeoUpdateHandler implements LocationListener { @Override public void onLocationChanged(Location location) { // wie bisher createMarker(); } … private void createMarker() { GeoPoint p = mapView.getMapCenter(); OverlayItem overlayitem = new OverlayItem(p, "", ""); itemizedoverlay.addOverlay(overlayitem); mapView.getOverlays().add(itemizedoverlay); }

Abb. 3: Die Google-Maps-Bibliothek wird dem Projekt bekannt gemacht

Abb. 4: Das Ergebnis der „createMarker()“-Methode

3. Hierbei muss Your Maps API Key durch den generier-ten API-Key unter [4] ersetzt werden.

Jetzt brauchen wir eigentlich nur noch die Aktivität zu programmieren. Wir erweitern in unserer Klasse Pathfinder die Klasse MapActivity (Listing 4). Diese stellt die Netzwerkkommunikation mit Google Maps sicher und erlaubt es, eine MapView darzustellen. Am Loca tionMana ger registrieren wir einen LocationListener mit der internen Klasse GeoUpdateHandler, der über seine Parameter dem Location Manager mitteilt, dass er gerne über jede Änderung informiert werden will.

GeoUpdateHandler verarbeitet in der Methode onLocationChanged() die neue Lokationsinformation, in-dem die Karte auf die aktuelle Position zentriert wird. Um Markierungen auf die Karte zu malen, verwendet man die Klasse Overlay. Um unsere aktuelle Position zu zeichnen, nutzen wir die existierende Klasse MyLocationOverlay. Diese instanzieren wir in der Methode initMyLocation() und fügen diese der View hinzu. Star-tet man jetzt die Applikation und setzt im Emulator eine Geoposition, wird die aktuelle Position angezeigt und die Karte auf dieser zentriert.

Hänsel und Gretel im 21. JahrhundertWir wollen die Applikation erweitern, sodass sie Hänsel und Gretel geholfen hätte, ihren Weg elektronisch zu markieren (und wieder zu verlieren). Wir wollen auf der Karte eine Markierung setzen, wenn sich die Position um mehr als fünf Meter ändert. Haben wir drei Markierun-gen gesetzt, soll die erste wieder gelöscht werden. Damit simulieren wir die Vögel, die die Brotkrumen unserer Märchenhelden verspeist haben. Dazu erzeugen wir die Klasse MyOverlays, die die Klasse ItemizedOverlay er-weitert. MyOverlays verwaltet die Markierungen und erlaubt es, eine Grafik darzustellen. MyOverlays ist aus Platzgründen nicht abgebildet. Diese Klasse initialisie-ren wir mit einer Grafik und in der Methode onLocation Changed() rufen wir die Methode createMarker() auf. Letztere fügt der Karte neue Markierungen hinzu. Das Ergebnis ist in Abbildung 4 dargestellt.

FazitDas Location API von Android ist intuitiv und leicht zu verwenden. Die Integration von Google Maps in das An-droid SDK und in die meisten Android-Geräte liefert eine einfache Möglichkeit, diese Daten hochwertig darzustel-len. Ich hoffe, dieser Artikel hat Lust auf mehr gemacht.

Links & Literatur

[1] Einführung in die android-Programmierung: http://bit.ly/a360_Location_1

[2] Beispielprojekt auf Git: http://bit.ly/a360_Location_2

[3] Key-Generierung mit keytool: http://bit.ly/a360_Location_3

[4] Beantragung des Map-Keys: http://bit.ly/a360_Location_4

Lars Vogel ist Product Manager bei der SaP aG und privat im Eclipse-Umfeld tätig. Unter http://www.vogella.de veröffentlicht er tutorials im Bereich Java, Eclipse, android und Webprogram-mierung.

www.btdays.de

www.btdays.de

Veranstalter:Präsentiert von:

Jetzt anmelden und attraktive Rabatte sichern!

16. bis 19. November 2010 | The Westin Grand München Arabellapark

Where IT Aligns With BusinessDie Business Technology Days bieten als Konferenz einen einzigartigen Rahmen für alle Architekten, IT-Leiter & Projektmanager, die sich mit der Modernisie-rung von Prozessen und Strukturen im Unternehmen

beschäftigen. Sie adressieren mit ihren Special Days gleichermaßen die Business- und Managementaspek-te von Enterprise-Architekturen, SOA, BPM und Cloud Computing.

Softwarearchitektur Cloud Computing Case Studies

ProjektmanagementBPMNEnterprise-Architektur

SOA-PraxisGovernanceBusiness Process Management

Silber-Sponsoren:

Agile-Day-Sponsor:Finance-Day-Sponsoren:

Gold-Sponsoren:

Bronze-Sponsor:

Homescreen Widgets1 2 3


von thomas Bornschlegel und markus Junginger

Die Anwendungsgebiete von Homescreen Widgets sind vielfältig: Sie reichen vom Platzieren von Notizzetteln auf dem Homescreen (Sticky Note) über das Anzei-gen des Batteriestatus und des genutzten Speicherplat-zes (Mini Info) bis hin zu ausgefallenen Aufgaben wie etwa dem Abspielen von Soundeffekten aus dem Super-Mario-Universum (Mario 8bit sound widgets). Neben Standalone Widgets ergänzen auch immer mehr Apps ihren Funktionsumfang um einen kleinen Helfer auf dem Homescreen. Der Aufgabenplaner Astrid zeigt so z. B. Erinnerungen an, ohne dass der Nutzer das Pro-gramm dafür starten muss. Soziale Netzwerke wie Facebook oder Twitter präsentieren Auszüge aus den letzten Neuigkeiten. Neben der Fülle von Widgets im Android Market liefert Android auch vorinstallierte Widgets mit. Ein Beispiel ist die Steuerung des Musikplayers, ohne dass der Nutzer die Player-App starten muss. So können direkt vom Homescreen Musiktitel abgespielt, gestoppt und übersprungen werden. Auch für den Kalender und für die Anzeige von Nachrichten sowie des Wetters exis-tieren entsprechende Erweiterungen. Daneben gibt es im Market eine Fülle von weiteren Widgets (Abb. 1).

Ein derartiges ergänzendes Widget kann die App auf den Homescreen bringen und ihn personalisieren. Auch Google legt es Entwicklern nahe, über die Nutzung von Widgets nachzudenken und hat daraus ein spezi-elles Design Pattern für Android gemacht (companion widget [1]). Bei der großen Auswahl bestehender An-wendungen im Market kann dieses Mehr an Komfort und Funktionalität die eigene Anwendung positiv aus der langen Liste hervorstechen lassen. Dieser Artikel soll zeigen, wie man Widgets einfach selbst realisieren kann.

Widget-AktualisierungEine wichtige Eigenschaft von Widgets ist die Möglich-keit, ihre Anzeige in periodischen Abständen zu aktua-lisieren, etwa wenn sich der Zeiger eines Uhren-Widgets bewegt oder wenn die neuesten Wetterinformationen dargestellt werden sollen. Ein Widget kann auf unter-schiedliche Varianten aktualisiert werden. Die einfachste Variante nutzt ein XML-Attribut des AppWidgetProviders, um eine Aktualisierung anzustoßen. Um die Batte-rie zu schonen, ist das Aktualisierungsintervall jedoch nicht unter 30 Minuten definierbar. Zudem wird das Gerät bei jeder Aktualisierung aufgeweckt, was ein

Eine Einführung in die Android-Widget-Programmierung

Kleine Helfer auf dem Homescreen Android Widgets sind kompakte Minianwendungen für den Homescreen. Meist präsentieren sie nütz-liche Informationen oder ermöglichen den schnellen Zugriff auf verschiedenste Dienste. Durch die Auswahl und freie Platzierung kann der Nutzer seinen Homescreen personalisieren und immer das im Blick haben, was ihm wichtig ist. Grund genug, einen ausführlichen Blick auf die Programmierung die-ser nützlichen Anwendungen zu werfen. In diesem Artikel zeigen wir, was mit Widgets alles möglich ist, wo ihre Grenzen liegen und wie man sie richtig anspricht.

Homescreen Widgets 3 2 1


Nachteil dieser Methode ist. Deshalb empfiehlt diese sich vor allem für Widgets, die eher selten aktualisiert werden – zum Beispiel eine Kalenderblattanzeige des ak-tuellen Datums. Im zweiten Teil des Artikels beschrei-ben wir ein energiesparenderes Vorgehen in Verbindung mit dem AlarmManager.

Zu Beginn ein einfaches BeispielIn einem ersten Beispiel wollen wir eine Anzeige auf dem Homescreen darstellen, die stündlich aktualisiert wird. Sie zeigt dem Nutzer dadurch den Zeitpunkt des letzten Updates an. Das GUI des Widgets wird zunächst wie gewohnt in einer Layout-XML-Datei deklariert. Wir fü-gen einem leeren LinearLayout einen TextView hinzu und speichern es als widget_layout.xml ab. Das einfache Layout ist in Abbildung 2 dargestellt.

Beim GUI-Design von Widgets ist zu beachten, dass es beim Layout deutliche Einschränkungen gibt. So steht nur eine Teilmenge der in Android enthaltenen Views zur Verfügung. Die Layouts sind auf FrameLayout, LinearLayout und RelativeLayout beschränkt. Als Elemente können lediglich AnalogClock, Button, Chronometer, ImageButton, ImageView, ProgressBar und TextView verwendet werden. Weitere Attribute des Widgets wer-den in einer gesonderten XML-Datei beschrieben, die in /res/xml/ abgelegt ist (im Beispiel widget_provider.xml benannt). Eine beispielhafte Realisierung dieser XML ist im folgenden Beispiel zu sehen:

<?xml version="1.0" encoding="utf-8"?><appwidget-provider xmlns:android="http://schemas.android.com/apk/res/ android" android:minHeight="72dp" android:minWidth="146dp" android:initialLayout="@layout/widget_layout" android:updatePeriodMillis="360000"/>

Die Dimensionen werden über minWidth und minHeight angegeben. Damit sich die View gut in das Ge-samtbild einfügt, wird die Größe zunächst in Zellen entworfen. Für unser schmales Beispiel-Widget wählen wir 2 mal 1 Zellen. Diese Zellen werden anschließend in dp (device independent pixel) umgerechnet. Dazu bedient man sich der Formel [2]: (Anzahl der Zellen * 74) – 2. Somit ergeben sich im Beispiel eine Breite von 146dp und eine Höhe von 72dp. Das Attribut initialLayout gibt den Namen der vorher erstellten Layout-datei an. Mit updatePeriodMillis wird angegeben, wie oft das Widget aktualisiert werden soll. Dabei zeigen Werte erst ab 18 000 Millisekunden einen Effekt, da Aktualisierungen wie erwähnt nur in Intervallen von mindestens einer halben Stunde möglich sind. In un-serem Beispiel wollen wir die Anzeige des Widgets jede Stunde erneuern und legen den Wert auf 360 000 Millisekunden fest. Damit die obige Deklaration von Android genutzt wird, muss sie in der Manifest-Datei innerhalb des application-Tags als receiver eingebun-den werden:

<application ...> <receiver android:name=".MyAppWidgetProvider" enabled="true"> <intent-filter> <action android:name="android.appwidget.action.APPWIDGET_UPDATE"/> </intent-filter> <meta-data android:name="android.appwidget.provider" android:resource="@xml/widget_provider" /> </receiver>...</application>

Abb. 1: Widget-Auswahl

Abb. 2: Simples Widget



Nachdem wir die Grundeinstellungen in den XMLs festgelegt haben, können wir uns an die Implemen-tierung der dynamischen Aktualisierung des Views machen. Im Beispiel realisieren wir dies in der Klasse MyAppWidgetProvider, die im Manifest als Receiver angegeben wurde. MyAppWidgetProvider erweitert

AppWidgetProvider, die Methoden für das Erstellen, Aktualisieren und Entfernen von Widgets bereitstellt. AppWidgetProvider wiederum leitet von der Klas-se BroadcastReceiver ab, die Intents in der Methode onReceive(Context, Intent) empfängt. Der AppWidgetProvider implementiert diese abstrakte Methode, extrahiert nötige Daten aus dem Context bzw. dem In-tent und ruft entsprechende Methoden auf, die im Fol-genden aufgezählt werden. Bei Widgets ist zu beachten, dass der Nutzer ein oder mehrere Instanzen davon auf dem Homescreen pinnen kann. Deshalb behandeln die ersten zwei der hier genannten Methoden Opera-tionen, die für alle Widgets gelten, während durch die restlichen Methoden einzelne Widgets angesprochen werden können:

onEnabled(Context)• wird benutzt, wenn die erste Instanz eines Widgets initialisiert wird. Hier könnte beispielsweise eine Datenbank geöffnet werden, die von allen Instanzen zusammen genutzt wird. Dabei ist zu beachten, dass das MyAppWidgetProvider-Objekt nur über eine begrenzte Lebenszeit verfügt. Dies liegt daran, dass die Superklasse BroadcastReceiver nur während dem Ausführen der onReceive-Methode als aktiv angesehen und danach verworfen wird (Receiver Lifecycle [3]). Umgehen lässt sich dies am einfachsten mit statischen Variablen oder unter Zuhilfenahme eines Service.onDisabled(Context)• wird aufgerufen, wenn die letz-te Widget-Instanz vom Homescreen gelöscht wurde. Hier ist der richtige Ort, um Objekte, die durch onEnabled erstellt wurden, aufzuräumen.onUpdate(Context, AppWidgetManager, int[])• wird bei jeder Aktualisierunganfrage ausgeführt und dient dazu, Daten und View des Widgets zu erneuern. Das übergebene int-Array beinhaltet die IDs der Instanzen der Widgets, die aktualisiert werden sollen.onDeleted(Context, int[])• wird verwendet, wenn eine Instanz des Widgets vom Homescreen entfernt wur-de.

Bei onDeleted gibt es eine Besonderheit: In Android 1.5 existiert ein Bug, durch den die onDeleted-Methode nicht aufgerufen wird. Dies ist durch eine fehlerhafte Implementierung der onReceive-Methode im AppWidgetProvider bedingt. Der Bug wird im Android Developers Guide beschrieben [2] und in unserem Beispiel behoben, indem wir die onReceive-Methode in MyAppWidgetProvider um den fehlenden Aufruf ergänzen [4] (Listing 1).

Daran ist die Arbeitsweise des AppWidgetProviders gut zu erkennen. Zuerst werden die benötigten Daten ausgelesen, dann wird die onDeleted-Methode aufge-rufen. Mit weiteren if-Abfragen hinsichtlich von intent.get Action() könnte man auch die drei anderen Metho-den selbst realisieren. Dabei kann man den AppWidgetManager aus dem Context erzeugen und die IDs der Widgets aus dem Intent extrahieren:

Listing 1: Bugfix in MyAppWidgetProvider

@Overridepublic void onReceive(Context context, Intent intent) { final String action = intent.getAction(); if (AppWidgetManager.ACTION_APPWIDGET_DELETED.equals(action)) { final int appWidgetId = intent.getExtras().getInt(AppWidgetManager. EXTRA_APPWIDGET_ID, AppWidgetManager.INVALID_APPWIDGET_ID); if (appWidgetId != AppWidgetManager.INVALID_APPWIDGET_ID) { this.onDeleted(context, new int[] { appWidgetId }); } } else { super.onReceive(context, intent); }}

Listing 2: Die onUpdate-Methode

public void onUpdate(Context context, AppWidgetManager appWidgetManager, int[] appWidgetIdArray) { // aktuelle Zeit auslesen DateFormat format = SimpleDateFormat.getTimeInstance(SimpleDateFormat.SHORT, Locale.getDefault()); String newTime = "Last update: " + format.format(new Date()); for(int appWidgetId : appWidgetIdArray){ // View aktualisieren RemoteViews remoteView = new RemoteViews(context.getPackageName(), R.layout.widget_layout); remoteView.setTextViewText(R.id.widget_textview, newTime); appWidgetManager.updateAppWidget(appWidgetId, remoteView); } super.onUpdate(context, appWidgetManager, appWidgetIdArray);}

Listing 3: onEnabled-Methode von PoliticiansWidget

@Overridepublic void onEnabled(Context context) { super.onEnabled(context); Intent intent = new Intent(context, PoliticiansWidget.class); intent.setAction(AppWidgetManager.ACTION_APPWIDGET_UPDATE); intent.putExtra(AppWidgetManager.EXTRA_APPWIDGET_IDS, new int[] {0}); PendingIntent pendingIntent = PendingIntent.getBroadcast(context, 0, intent, PendingIntent.FLAG_UPDATE_CURRENT); // Regelmäßige Updates mit AlarmManager starten AlarmManager alarmManager = (AlarmManager)context.getSystemService(Context.ALARM_SERVICE); int updateRateInSeconds = 300; // Update alle 5 Minuten alarmManager.setRepeating(AlarmManager.ELAPSED_REALTIME, SystemClock.elapsedRealtime(), updateRateInSeconds * 1000, pendingIntent);}

Homescreen Widgets 3 2 1


AppWidgetManager appWidgetManager = AppWidgetManager.getInstance(context);int[] appWidgetIds = intent.getExtras().getIntArray (AppWidgetManager.EXTRA_APPWIDGET_IDS);

Nun fehlt lediglich die Implementierung der onUpdate-Methode in MyAppWidgetProvider.java. Darin wird die neue Uhrzeit ausgelesen und die View aktualisiert (Listing 2).

Hierbei ist die Art und Weise zu beachten, wie die Daten der View aktualisiert werden. Abweichend vom üblichen Vorgehen bei Android-UIs darf nicht direkt mit View-Objekten gearbeitet werden. Stattdessen muss der Umweg über RemoteView-Objekte gegangen werden. Der Hintergrund dafür ist, dass die Widget-Darstellung nicht im Prozess der App, sondern in ei-nem Systemprozess des Homescreens läuft. Dies ist wesentlich ressourcenschonender, da nicht für jedes Widget ein Prozess am laufen gehalten werden muss. Zum Ändern der Views muss daher ein RemoteView-Objekt erstellt werden, das die Zugriffe auf die Views des Widgets kapselt. Der Text wird in unserem Fall durch setTextViewText angepasst, ohne eine Referenz des Objekts zu erzeugen. Das anschließende Update fin-det in einer for-Schleife statt, die über alle aktiven Ins-tanzen des Widgets iteriert. Damit wird sichergestellt, dass die Views aller Widget-Instanzen aktualisiert wer-den. Hat der Nutzer beispielsweise zwei Uhren-Wid-gets auf dem Homescreen verankert, so werden auch beide aktualisiert. Sobald aufwändigere Aufgaben im MyAppWidgetProvider anstehen, wie etwa das Bezie-hen von Daten von einem Webserver, sollte man auf Android-Services zurückgreifen. In den Codebeispielen von Google findet sich hierfür ein gutes Beispiel, bei dem das „word of the day“ aus dem Wiktionary in einem Widget dargestellt wird [5]. Auch im folgenden Beispiel kommt ein Service zur Anwendung.

Beispiel 2: PolitikergezwitscherMit der obigen Variante können wir Updates nicht in beliebigen Intervallen durchführen. Abhilfe schafft die Verwendung des AlarmManagers;, eine Alternative die zudem den Vorteil hat, dass das Gerät nicht bei jedem Update aufgeweckt und die Batterie somit geschont wird. Zur Veranschaulichung haben wir ein Beispiel ge-wählt, für das wir das Deutschland-API [7] nutzen, um Daten von Politikern abzurufen, um sie auf dem Home-screen darzustellen. Für das bald im Market erscheinen-de Widget nutzen wir davon den Politikernamen, die zugehörige Partei, das Bild von bundestag.de und die aktuelle Twitter-Nachricht. Dieses stellen wir in einem Widget kompakt zusammengefasst dar, so wie es in Ab-bildung 3 zu sehen ist.

Als Basis für die Beschreibung der Implementierung dient der Code aus dem vorherigen Kapitel. Da wir die Aktualisierung nun selbst triggern, stellen wir im ersten Schritt den updatePeriodMillis-Wert in widget_provider.xml auf 0 ein. Zur besseren Abgrenzung benennen

wir die Klasse MyAppWidgetProvider in PoliticiansWidget um und ändern den entsprechenden Eintrag im Manifest. Anschließend initialisieren wir einen AlarmManager in der onEnabled-Methode. Diese Methode wird beim Hinzufügen des ersten Widgets ausgeführt. Mithilfe des AlarmManagers lassen sich Intents einmalig oder wiederholt zu frei definierbaren Zeitpunkten star-ten. In unserem Widget starten wir alle fünf Minuten ein PendingIntent mit der Action AppWidgetManager.ACTION_APPWIDGET_UPDATE. Diese Action haben wir in der XML-Deklaration als Filter für PoliticiansWidget angegeben. Dadurch wird dessen onUpdate-Methode ausgeführt, wenn das Intent gestartet wird. Die onEnabled-Methode von PoliticiansWidget finden Sie in Listing 3.

Bei der gewählten Action des Intents muss das Ex-tra EXTRA_APPWIDGET_IDS übergeben werden. Fehlt es, so wird die onUpdate-Methode aus der AppWidgetProvider-Implementierung nicht getriggert. Normalerweise wird in onUpdate die View eines be-stimmten Widgets aktualisiert, weshalb dieses Extra verpflichtend gesetzt werden muss. Dadurch können mehrere Instanzen desselben Widgets auf dem Home-screen unterschiedlich behandelt werden. Da wir die

Abb. 3: Politiker-Widget



Aktualisierung jedoch vor dem Erstellen des ersten Widgets ausführen und somit keine ID zur Verfügung haben, übergeben wir schlichtweg den beliebigen Wert new int[]{0}. In der Realisierung von onUpdate, die nun genauer erläutert werden wird, ignorieren wir die-sen Wert und aktualisieren alle Widgets auf einmal. In onUpdate starten wir einen Android-Service [8] zur Abfrage von Politikerdaten. Der Service führt eine An-frage an den Server des Deutschland-API im Hintergrund aus, ohne dabei einen „Anwen-dung reagiert nicht“-Dialog zu riskieren, der sich öffnet, wenn ein Broadcast Receiver län-ger als zehn Sekunden benötigt [9]. Um das Ganze interaktiv zu ge-stalten, binden wir mit remoteView.setOnClickPendingIntent ein entspre-chendes Intent an die GUI-Elemente, um auf Klicks reagieren zu können:

Intent browserIntent = new Intent(Intent.ACTION_VIEW);browserIntent.setData(Uri.parse(politikerUrlString));PendingIntent pendingIntent = PendingIntent.getActivity(context, 0, browserIntent, Intent.FLAG_ACTIVITY_NEW_TASK);remoteView.setOnClickPendingIntent(R.id.TextViewPoliticianName, pendingIntent);

Beim Klick auf das Foto oder den Namen wird die Bio-grafie des Politikers auf bundestag.de angezeigt. Wird die aktuelle Twitter-Meldung angetippt, so öffnet sich das zugehörige Twitter-Profil. Dazu übergeben wir je-weils ein Intent mit der Action ACTION_VIEW und dem passenden URL als Data. Dadurch zeigt der Brow-ser bzw. ein etwaiger installierter Twitter-Client die ent-sprechende Information an. Nachdem die neuen Daten zur Verfügung stehen, stoßen wir im Service die Aktua-lisierung der View an. Da wir nicht zwischen einzelnen Widget-Instanzen unterscheiden, führen wir das Update des AppWidgetManagers nicht wie beim Uhren-Widget in einer for-Schleife aus. Außerdem erhält es andere Pa-rameter, die eine Aktualisierung aller Widgets nach sich ziehen:

ComponentName thisWidget = new ComponentName(context, PoliticiansWidget.class);appWidgetManager.updateAppWidget(thisWidget, remoteView);

Nun wird das Widget im Fünf-Minuten-Takt aktua-lisiert. Doch was ist, wenn es der Nutzer wieder vom Homescreen entfernt? Der AlarmManager würde immer noch weiterlaufen und unnötigerweise weiterhin Intents verschicken. Deshalb müssen wir onDisabled über-schreiben und dort die Updates wieder beenden. Dazu holen wir uns erneut eine Instanz des AlarmManagers

Links & Literatur

[1] companion Widget: http://bit.ly/A360_Hs_1

[2] dp-Formel: http://bit.ly/A360_Hs_2

[3] receiver Lifecycle: http://bit.ly/A360_Hs_3

[4] Bugfix in myAppWidgetProvider: http://bit.ly/A360_Hs_4

[5] Wiktionary-Android: http://bit.ly/A360_Hs_5

[6] appwidget-APi-demos: http://bit.ly/A360_Hs_6

[7] http://www.deutschland-api.de/

[8] Android-service: http://bit.ly/A360_Hs_8

[9] Fehlerdialog bei Zeitüberschreitung: http://bit.ly/A360_Hs_9

Thomas Bornschlegel ist als Android-entwickler bei greenrobot tätig. Auf seinem privaten Blog http://thomas.bornschlegel.net schreibt er ab und zu über Android, informatik und Fotografie.

und rufen dort alarm.cancel(pendingIntent) auf. Auch eventuell noch laufende Instanzen des Service müssen hier beendet werden.

FazitAnhand zweier Beispiele haben wir die Grundzüge der Widget-Programmierung kennen gelernt. Der beschrie-bene Aufbau kann hoffentlich leicht zur Programmie-

rung eigener Widgets verwendet werden. Es gibt noch viele weitere, interessante Punkte in Bezug auf Widgets, die hier nur knapp erwähnt werden können. So lässt sich das Verhalten von Widgets z. B. über eine Konfigurationsseite an-passen. Die Appwidget-Demo von Google bietet

hierfür eine gute Hilfestellung [2]. Zudem kann man am dazugehörigen Beispielcode nachvollziehen, wie man das Update eines Widgets von einer externen Klasse aus anstößt [6]. Dies ist nicht nur nützlich, um das Widget zu aktualisieren, wenn der User neue Einstellungen ge-troffen hat. Es kann genauso für Anwendungen verwen-det werden, bei denen eingegebene Nutzerdaten auf dem Homescreen dargestellt werden sollen. Beispielsweise können so die aktuellen Termine aus einer Aufgabenver-waltung oder die Elemente einer To-Do-Liste angezeigt werden. Es gibt also genügend spannende Ansätze, sich genauer mit diesem Thema zu beschäftigen.

die Appwidget-demo von google bietet eine gute Hilfe-

stellung dazu, wie sich Widgets über eine Konfigura-tionsseite anpassen lassen.

Der PHP SUMMIT hat den Anspruch, in drei Tagen alle wichtigen PHP-Themen in kompakter Form zu vermit-teln. Entscheiden müssen Sie dabei nur noch, welche persönlichen Themenschwerpunkte Sie setzen möchten. Sie können aus insgesamt 18 intensiven und interaktiven Power Workshops auswählen.

Sämtliche Workshops beziehen sich auf die tägliche Projektarbeit und zeigen Ihnen den produktiven Live- Einsatz von Tools und Methoden. Hohe Interaktion mit den Teilnehmern, Live-Coding statt vorgefertigte foo/bar-Beispiele, Informationen über neueste Trends in der PHP-Entwicklung – alles gewürzt mit einer guten Prise Humor – das sind die einzigartigen Merkmale des PHP SUMMIT. Hier profi tieren Sie vom geballten Wissen und der Praxiserfahrung von drei der bedeutendsten deutsch-sprachigen PHP-Experten.

Am Montag- und Dienstagabend fi nden jeweils die Speakerpanel statt. Erleben Sie, wie Arne Blankerts, Se-bastian Bergmann und Stefan Priebsch gemeinsam eine Code-Review-Session durchführen – auch das sollten Sie auf keinen Fall verpassen!

29.11. – 01.12. DÜSSELDORF

Präsentiert von Veranstalter

Alle Infos auf www.php-summit.de

The Ultimate PHP-Event

Sebastian Bergmann Arne Blankerts Stefan Priebsch

TRAINER

Nicht verpassen!Mit den early-Bird-Preisen bis 29. oktober sparen!

Markus Junginger ist Android-enthusiast und -entwickler seit dem ersten Prerelease des Android sdKs, das 2007 erschien. sein startup greenrobot widmet sich der entwicklung mobiler software speziell für Android, mit dem Ziel, das maximum aus der Plattform herauszuholen.

Live WaLLpaper1 2 3


von Marc reichelt und Markus Junginger

Es gibt bereits einige spannende Beispiele für Livehinter-gründe im Market und auf Android-Handys der neueren Generation. So sind beispielsweise Galaxie und Wasser auf neueren Android-Geräten vorinstalliert. Die Galaxie zeigt sich bewegende Sternformationen, die beim Wech-seln des Homescreens die Perspektive ändern (Abb. 1) und der Wasserhintergrund stellt einen Teich dar, der kleine Wellen schlägt, wenn man ihn mit dem Finger be-rührt. Im Android Market findet man eine bunte Vielfalt an Livehintergründen: von animierten Aquarien über Matrix-Buchstabenformationen und einer Pong-Uhr bis hin zu einer LogCat-Ausgabe für Poweruser. Ermöglicht wird all das durch die Tatsache, dass Live Wallpapers letztendlich Android-Applikationen sind. Das eröffnet eine Reihe interessanter Möglichkeiten: Live Wallpapers können Daten aus dem Internet herunterladen, die aktu-elle Position des Handys ermitteln und auf Sensoren zu-greifen. In diesem Artikel möchten wir die Grundlagen vermitteln und Sie inspirieren, außergewöhnliche und nützliche Hintergründe zu erstellen.

Als Erstes legen wir ein neues Android-2.1-Projekt an und treffen die nötigen Einstellungen in der Manifest-Datei. Dabei ist zu beachten, dass es Android-2.1-Ge-räte gibt, die keine Live Wallpapers ausführen können. Damit die Applikation auch nur auf Geräten mit ent-sprechender Unterstützung installiert wird, müssen wir neben der Angabe der minimalen SDK-Version auch ein entsprechendes uses-feature-Element angeben:

<uses-sdk android:minSdkVersion="7" /><uses-feature android:name="android.software.live_wallpaper" />

Animierte und interaktive Hintergrundbilder für den Homescreen

Live Wallpaper Mit Android 2.1 ist der Hintergrund des Homescreens wesentlich lebendiger geworden: Statt starrer Bilder können mit Live Wallpaper nun auch animierte Hintergründe gesetzt werden, die sogar mit dem User interagieren können. Wie man diese selbst erstellt, zeigt dieser Artikel.

Abb. 1: Rotierende Galaxie, ein Live Wallpaper auf dem Nexus One

Live WaLLpaper 3 2 1


Als Nächstes definieren wir im Manifest einen Service und versehen ihn mit dem entsprechenden IntentFilter und der Berechtigung BIND_WALLPAPER. Außer-dem wird für jedes Wallpaper eine weitere XML-Res-source definiert, die wir hier referenzieren müssen (Listing 1).

Nähere Informationen zu einem Wallpaper werden in unserem Beispiel in der Datei mywallpaper.xml im Verzeichnis /xml/ des Ressourcenverzeichnisses abge-legt, das zuvor noch angelegt werden muss. Dort kann für das Wallpaper ein Beschreibungstext und eine Vor-schaugrafik angegeben werden. Falls das Wallpaper konfigurierbar werden soll, können Sie hier zudem eine Aktivität zum Bearbeiten der Einstellungen für das Wallpaper angeben:

<wallpaper xmlns:android="http://schemas.android.com/apk/res/android" android:thumbnail="@drawable/mywallpaper_thumbnail" android:description="@string/mywallpaper_description" android:settingsActivity="MyPreferenceActivity" />

Beispiele für Einstellungsmöglichkeiten sind die Ge-schwindigkeit einer Animation oder Aktualisierungsin-tervalle, die angeben, in welchen Abständen Daten aus dem Internet heruntergeladen werden. Zur Erstellung dieser Aktivität stellt Android mehrere Klassen zur Ver-fügung, darunter die Klassen PreferenceActivity und Preference. Dieses Vorgehen ist nicht auf Wallpaper be-schränkt und vereinfacht die UI-Erstellung für die Ein-stellungsseite enorm. Ein Beispiel hierzu findet sich in den offiziellen API-Demos von Android.

Die Implementierung des in der obigen XML definier-ten Service erfolgt durch Ableitung der Klasse Wallpa-perService. Durch Überschreiben der Methode onCreate En gine() wird eine neue Instanz der Klasse Wallpaper Service.Engine zurückgegeben, die das Herzstück eines jedes Live Wallpapers darstellt. Über verschiedene Me-thoden der Engine erhält man Zugriff auf einen Surface-Holder und damit auf eine Zeichenoberfläche (Canvas). Bei der Programmierung sollte man darauf achten, dass mehrere Instanzen der Klasse Engine gleichzeitig aktiv sein können – beispielsweise, wenn das Wallpaper gerade in Verwendung ist und sich der Benutzer zusätzlich eine Vorschau davon anzeigen lässt. Listing 2 zeigt das Grund-gerüst, in dem zu sehen ist, wie ein WallpaperService implementiert wird. Das eigentliche Zeichnen mit dem Canvas-Objekt erfolgt in unserer Methode drawFrame(). Im Beispiel haben wir aus Platzgründen nur einen Kom-mentar an der entsprechenden Stelle platziert. Falls Sie noch nie mit Canvas gearbeitet haben, sei hier noch kurz angemerkt, dass es sich um ein Low-Level-API handelt; statt mit Views und Layouts wird hier mit primitiven Ele-menten wie Linien, Texten und Bitmaps gearbeitet, die in einem Koordinatensystem gezeichnet werden.

In der drawFrame()-Methode sollte nach Möglichkeit auf bereits vorher initialisierte Objekte zurückgegriffen werden, da beispielsweise das Laden von Bitmaps viel Abb. 1: Rotierende Galaxie, ein Live Wallpaper auf dem Nexus One

Listing 1: Im Manifest definierter Service

<service android:label="@string/mywallpaper_name" android:name=".MyWallpaperService" android:permission="android.permission.BIND_WALLPAPER"> <intent-filter> <action android:name="android.service.wallpaper.WallpaperService" /> </intent-filter> <meta-data android:name="android.service.wallpaper" android:resource="@xml/mywallpaper" /></service>

Listing 2: Grundgerüst in der Klasse „MyWallpaperService“

public class MyWallpaperService extends WallpaperService { private final Handler handler = new Handler(); public Engine onCreateEngine() { return new MyWallpaperEngine(); } private class MyWallpaperEngine extends Engine { private boolean visible; private final Runnable drawFrameRunner = new Runnable() { public void run() { drawFrame(); } };

public void onVisibilityChanged(boolean visible) { super.onVisibilityChanged(visible); this.visible = visible; if (visible) drawFrame(); else handler.removeCallbacks(drawFrameRunner); }

public void onSurfaceDestroyed(SurfaceHolder holder) { super.onSurfaceDestroyed(holder); visible = false; handler.removeCallbacks(drawFrameRunner); }

private void drawFrame() { final SurfaceHolder holder = getSurfaceHolder(); Canvas c = null; try { c = holder.lockCanvas(); if (c != null) { // TODO: hier mit Hilfe des Canvas zeichen } } finally { if (c != null) holder.unlockCanvasAndPost(c); } handler.removeCallbacks(drawFrameRunner); if (visible) { handler.postDelayed(drawFrameRunner, 1000 / 25); } }}}

Live WaLLpaper1 2 3


Zeit und Prozessorleistung benötigt. Bitmaps könnten beispielsweise beim Erzeugen der Engine geladen wer-den.

Die letzten beiden Zeilen der Methode drawFrame() veranlassen einen erneuten Aufruf dieser Methode nach einer Pause von einer 1/25 Sekunde. Stetiges Neuzeich-nen führt zum Eindruck einer Animation. Wenn Sie nichts animieren möchten, benötigen Sie den Handler natürlich nicht.

BesonderheitenEin wichtiger Aspekt von Livehintergründen ist, dass sie nur aktiv sein sollten, wenn der Homescreen auch tatsächlich sichtbar ist. Um die Batterie zu schonen, wird dringend empfohlen, keine Ressourcen zu bele-gen, wenn das Wallpaper nicht sichtbar ist. Das ist insbesondere dann der Fall, wenn der Benutzer eine App geöffnet hat oder das Gerät das Dis-play ausschaltet. In die-sem Fall sollte jegliche Aktivität eingestellt werden, um die CPU und damit die Batterie nicht unnötig zu belasten. Um Veränderungen der Sichtbarkeit zu registrieren, wird die Methode onVisibilityChanged() überschrieben. In unserem Beispiel wird hier die aktuelle Sichtbarkeit in der Member-Va-riable visible abgelegt. Wird das Wallpaper unsichtbar, werden dort zudem die geplanten Aufrufe der Zeichen-methode aus dem Handler entfernt und somit die Ani-mation gestoppt, bis das Wallpaper wieder sichtbar wird. Wenn Sie ein besonders batterieschonendes Live Wallpaper schreiben möchten, könnten Sie mit Anima-tionen sparsam umgehen und den Hintergrund viel-leicht nur ab und zu animieren.

Bei Animationen sollten Sie auch besonderes Augen-merk auf die Performanz legen: Zwischen einer flüssi-gen und lästig ruckelnden Animation liegen nur wenige Millisekunden. Eine erfolgreiche Optimierung an die-ser Stelle kommt meist auch der Batterielaufzeit zugu-te. Einige Tipps zum Steigern der Performanz liefert die Android-Dokumentation [1], auch wenn die Praxis zeigt, dass Performanz nicht immer zu Lasten eines gu-ten Designs gehen muss. Oft reicht es aus, den Garbage Collector im Auge zu behalten und dessen Aufruf in kritischen Schleifen zu vermeiden. Optimierte Batte-rielaufzeit und flüssige Animationen sind wesentliche Qualitätsmerkmale eines Live Wallpapers. Dies ist ein wichtiger Unterschied zur Entwicklung von gewöhnli-chen Apps, weshalb wir nochmals ausdrücklich darauf hinweisen möchten.

Live Wallpaper in BewegungWenn Sie bereits etwas mit dem Code experimentiert haben, werden Sie feststellen, dass die Oberfläche des Canvas exakt so groß ist wie die des Bildschirms. Die vir-tuelle Fläche des Wallpapers ist aber größer. Dies sieht

man auch an den klassischen Hintergrundbildern, die beim Wechsel eines Homescreens in die entsprechende Richtung verschoben werden. Dieses Verhalten lässt sich über die Methode onOffsetsChanged() erreichen, die aufgerufen wird, wenn der Nutzer mit dem Finger den Homescreen verschiebt. Um die virtuelle Homescreen-Position (Offset) beim Zeichnen zu berücksichtigten, speichert man sich die übergebenen Werte xPixelOffset und yPixelOffset und veranlasst durch den Aufruf der Methode drawFrame() ein Neuzeichnen des Bildschirms. Beim Zeichnen kann man dann auf diese beiden Off-sets zurückgreifen, um beispielsweise den Hintergrund dezent mitzuziehen. Die virtuelle Größe lässt sich über getDesiredMini mumWidth() und getDesiredMinimumHeight() ermitteln. Theoretisch könnten sich diese Werte

verändern, was über einen Aufruf von onDesiredSize Changed() signalisiert würde. Das ist derzeit aber eher als Sonderfall anzusehen, den wir nicht weiter betrachten. Um das Zeichnen unter Berück-

sichtigung des Offsets zu verdeutlichen, liefern wir im Folgenden ein Beispiel, das einen roten Kreis in die Mitte der virtuellen Fläche zeichnet und ihn beim Verschieben des Bildschirmausschnitts neu berechnet. Dabei wird da-von ausgegangen, dass die letzten Offset-Werte in lastXOffset und lastYOffset gespeichert wurden:

final int width = getDesiredMinimumWidth();final int height = getDesiredMinimumHeight();final Paint p = new Paint();paint.setColor(Color.RED);paint.setAntiAlias(true);c.drawCircle(width/2 + lastXOffset, height/2 + lastYOffset, 50f, p);

InteraktionFür die Reaktion auf Ereignisse des Homescreens exis-tiert die Methode onCommand(). Zurzeit gibt es zwei Aktionen, die an Live Wallpaper geschickt werden kön-nen: Erstens WallpaperManager.COMMAND_TAP, wenn der Anwender auf eine leere Fläche des Home-screens drückt, sowie WallpaperManager.COMMAND_DROP, wenn ein Objekt darauf abgelegt wird. Wenn Sie darüber hinaus mehr Benutzereingaben ver-arbeiten möchten, können Sie bei der Erstellung der Engine die Methode setTouchEventsEnabled(true) auf-rufen und die Eingaben in onTouchEvent() verarbeiten. Das dabei verwendete MotionEvent wird beispielsweise auch in Activities benutzt.

Tipps & TricksEin weiteres Beispiel für Live Wallpaper findet sich in den offiziellen Codebeispielen von Google: CubeLiveWall-paper [2]. Dort wird ein dreidimensionaler Würfel von Hand animiert und auf den Canvas gezeichnet. Wer sich

Die praxis zeigt, dass performanz nicht immer zu Lasten eines guten Designs gehen muss.

Cordula Lochmann, Jan Erik Gewehr, Martin Szugat

Soziale Netzwerke und Dienste130 Seiten, Softcover, 2010

PRINT ISBN: 978-3-86802-053-3

Preis: 12,90 € / 13,40 €E-BOOK ISBN: 978-3-86802-238-4

Preis: 8,00 €

Soziale Netze und Dienste haben sich rasant entwickelt und sind zu einem Massenphäno-

men geworden. Mit der Zahl der Nutzer sind auch Zahl und Spezialisierung der Angebote

gewachsen. Die Autoren – selbst intensive Nutzer – haben ihren Bestseller Social Soft-

ware komplett überarbeitet und an die aktuellen Webtrends angepasst. Sie zeigen auf

unterhaltsame Weise, wie man soziale Netze und Dienste für die eigenen Zwecke einsetzt

und welche Dienste geschickt kombiniert werden können. Sie verlieren dabei aber nicht

den Blick für’s Ganze – die gesellschaftlichen und wirtschaftlichen Entwicklungen und

Auswirkungen auf jeden von uns.w

ww

w.e

ntw

ickl

er-p

ress

.de

Weitere Informationen und Bestellmöglichkeiten finden Sie unter www.entwickler-press.de/netzwerke. Unsere Bücher erhalten Sie auch in jeder gut sortierten Buchhandlung.

Get involved: www.facebook.com/sozialenetzwerkeunddienste.

Frisch aus der Presse!

NEU!

Live WaLLpaper 3 2 1

für professionelle 3-D-Animationen interessiert, wird zu-nächst enttäuscht, da das Android SDK selbst keine ein-fache Möglichkeit bietet, OpenGL für Live Wallpapers zu nutzen. Abhilfe schafft die Klasse GLWallpaperEngine des Entwicklers Robert Green, die auf seiner Webseite frei zur Verfügung steht und eventuell in das offizielle SDK einfließen wird [3].

Wenn Sie ein Wallpaper erstellen möchten, das Daten aus dem Internet nachlädt, sollten Sie sich die Metho-de setInexactRepeating() der Klasse AlarmManager [4] ansehen. Richtig angewandt bietet diese eine Schonung der Batterie, da sie mehrere Ereignisse sammeln und zur gleichen Zeit ausführen kann. Je mehr Anwendungen das verwenden, desto seltener muss das Gerät für einzel-ne Anwendungen geweckt werden. Diese Klasse kommt ebenfalls bei der Programmierung von Homescreen-Widgets zum Einsatz, die im zugehörigen Artikel von Thomas Bornschlegel in diesem Heft auf Seite 70 be-schrieben werden.

Damit sind wir auch schon am Ende unseres Arti-kels über Live Wallpaper. Wir haben gesehen, dass die Implementierung sich im Grunde genommen einfach gestaltet: Es bedarf im Wesentlichen einiger Konfigura-tionsangaben, einer Engine-Implementierung und einer

Zeichenroutine. Dabei sind ein paar Besonderheiten in Hinblick auf die Batterielaufzeit bei Animationen zu beachten. Jetzt liegt es in Ihrer Hand, kreative Ideen in ansprechende Live Wallpaper umzusetzen.

Links & Literatur

[1] android-Dokumentation zum Thema performanz: http://bit.ly/a360_Wallpaper_1

[2] CubeLiveWallpaper: http://bit.ly/a360_Wallpaper_2

[3] GLWallpaperengine: http://bit.ly/a360_Wallpaper_3

[4] alarmManager: http://bit.ly/a360_Wallpaper_4

Marc Reichelt ist als android-entwickler bei greenro-bot tätig. auf seiner privaten Webseite http://www.marcreichelt.de/ schreibt er über Linux, android und eigene projekte. Markus Junginger entwickelt seit 2007 für android und ist Gründer von greenrobot.

Anzeige

BLUETOOTH1 2 3

ANDROID36082 www.android360.de

von Miriam Brückner und Andreas Frey

Der Roboter soll mithilfe der Lagesensoren des Smart-phones ferngesteuert werden. Je nach Neigung soll der Roboter in die entsprechende Richtung fahren. Kippt man das Gerät nach vorne, fährt der Roboter vor-wärts; kippt man das Gerät nach hinten, fährt er folg-lich rückwärts. Kurven sind durch Neigen nach rechts oder links natürlich auch möglich. Zusätzlich wird die aktuell gefahrene Richtung auf dem Display mit Pfeilen

Lego Mindstorms meets Android

Wir sind alle Roboter Im Rahmen des internationalen ITEA2-Forschungsprojekts VERDE starteten wir den Versuch, einen LEGO-Mindstorms-Roboter mittels eines Android-Geräts fernzusteuern. Als Kommunikationskanal zwi-schen den beiden Welten setzten wir auf Bluetooth. Dieses Thema bereitete uns nicht nur sehr viel Spaß, sondern ist auch technologisch durchaus interessant – Grund genug, die wesentlichen Schritte unserer Lösung in einem Artikel vorzustellen.

dargestellt. Die Kommunikation der beiden Ge-räte erfolgt dabei über Bluetooth. Dabei wird die aktuelle Neigung des Smartphones in ein entsprechendes Mindstorms-Blue-tooth-Kommando übersetzt und an das NXT (intelligen-ter, computergesteuerter Le-go-Stein) übertragen. Jeder daran angeschlossene Mo-tor kann einzeln angesteu-ert werden.

Mit dem NXT werden zu-sätzlich Sensoren verbunden, die Helligkeit, Lautstärke, Druck und Entfernung messen. Die von den Sensoren ausgelesenen Messwerte werden über die bidirektionale Bluetooth-Verbindung an das Android-Gerät zurückge-schickt und dort visualisiert.

Ein besonderer Aufbau des Roboters ist nicht nötig. Wir verwenden das Basisfahrzeug aus der Anleitung, verzichten allerdings auf den Greifarm (Abb. 1). Zusätz-lich haben wir eine Sounddatei (unsere Hupe) auf das NXT übertragen. Die Bluetooth-Kommunikation mit dem NXT, die Ansteuerung der Motoren und das Aus-lesen der Sensoren funktioniert mit so genannten Direct Bluetooth Commands [1] und erfordern keine weiteren Arbeiten am Roboter.

Sensoren auf AndroidDas Android API ermöglicht einen standardisierten Zugriff auf die Hardware des Smartphones (Kasten: „All Applica-tions are created equal...“). Als Steuerung für den Robo-ter soll die Neigung des Geräts verwendet werden (dazu müssen die Lagesensoren des Geräts ausgelesen werden). Diese gehören laut An droid-Kompatibilitätsrichtlinien

All Applications are created equal …

… ist einer der Leitsätze von Android [2]. Android unterscheidet nicht zwischen vorinstallierten und mitgelieferten Anwendungen, beide haben die gleichen Zugriffsmöglichkeiten auf die eingebaute Hardware. Entwick-lern bietet dies quasi uneingeschränkte Möglichkeiten, die verbauten Komponenten des Geräts – wie Bluetooth, Kamera, GPS, WiFi, Kompass, Beschleunigungssensor usw. – zu nutzen und für eigene, innovative Anwendungen zu verwenden. Einzige Ausnahme ist die Telefonie, auf die nur eingeschränkt zugegriffen werden kann.

Android und Kompatibilität

Der Android-Quellcode ist Open Source und kann prinzipiell für die ver-schiedensten Geräte mit unterschiedlichster Hardware verwendet werden. Das Android-Kompatibilitätsprogramm [3] verhindert allerdings eine zu große Diversi� kation der Endgeräte. Geräte, die den Namen Android verwenden wollen, müssen diese Kompatibilitätsrichtlinien erfüllen. So wird garantiert, über welche technischen Eigenschaften ein Android-Gerät verfügen muss. Bewegungs- und Lagesensoren sind beispielsweise Bestandteil dieser Richtlinien, Bluetooth allerdings nicht.

BLUETOOTH 3 2 1

ANDROID360 83

BLUETOOTH 3 2 1

ANDROID360 83

Bluetooth1 2 3


(Kasten: „Android und Kompatibilität“) zu den erfor-derlichen Bestandteilen eines Android Smartphones, sind also auf jeden Fall vorhanden. Im Folgenden zeigen wir, wie die Lagesensoren ausgelesen und für eigene Anwen-dungen verwendet werden können.

Zugriff auf LagesensorenZugriff auf Hardwarekomponenten und andere Sys-tem-Level-Dienste erfolgt über die Methode Activity.getSystemService(SENSOR_SERVICE), die abhängig vom übergebenen Servicenamen (hier SENSOR_SERVICE) unterschiedliche Komponenten zurückliefert. Im beschriebenen Anwendungsfall erhalten wir eine Instanz des SensorManager zurück, die abstrahierten Zugriff auf die eingebauten Sensoren zur Verfügung stellt.

Um Sensorwerte auszulesen, muss der Lagesensor aktiviert und ein SensorEventListener als Callback re-gistriert werden. Listing 1 zeigt, wie die Activity RoboDroid selbst das Interface SensorEventListener (mit den Methoden onSensorChanged() und onAccuracyChanged()) implementiert und sich in der Methode onCreate() als Callback am SensorManager registriert. Dabei können unterschiedliche Abtastraten für die Verarbeitung von eingehenden Werten verwendet wer-den (z. B. SENSOR_DELAY_UI für UI-Änderun-gen). Ändern sich die Sensorwerte, wird die Methode onSensorChanged(SensorEvent event) aufgerufen und ein neues SensorEvent übergeben. Ein zentraler Bestand-teil dieses SensorEvent ist die aktuelle Lage des Geräts, die sich aus drei Werten zusammensetzt (Abb. 2). Pitch bezeichnet hier die Rotation um die x-Achse, Roll die um die y-Achse. Zusätzlich wird Azimuth übergeben, was den Winkel zwischen magnetischem Norden und der y-Achse angibt und einer Drehung um die z-Achse entspricht. Diese Angabe wird im vorgestellten Szenario aber nicht benötigt.

Hinweis: Sensor.TYPE_ORIENTATION ist ab Android-Version 2.2 deprecated. Laut Dokumentation [4] soll stattdessen getRotationMatix() in Verbindung mit remapCoordinateSystem() und getOrientation() verwendet werden, um die Lagewerte zu ermitteln.

Bluetooth auf AndroidSeit der Android-Version 2.0 (Donut) ist das Bluetooth-API für Entwickler freigegeben. Geräte vor Donut verfügten zwar schon über Bluetooth-Fähigkeiten, al-lerdings war das verwendete API noch nicht fertigge-stellt und daher als privat gekennzeichnet. Bluetooth gehört auch nicht zu den Kompatibilitätsvoraussetzun-gen von Android und muss daher nicht auf jedem Gerät zur Verfügung stehen [5]. Gerade bei Mobiltelefonen kann allerdings davon ausgegangen werden, dass sie über Bluetooth verfügen. Android erlaubt Zugriff auf die komplette Bluetooth-Schicht, Anwendungen können beispielsweise:

Abb. 1: Smart-

phone und Roboter in „Real Life“

Listing 1: Zugriff und Auslesen der Lagesensoren

public class RoboDroid extends Activity implements SensorEventListener { … public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); … SensorManager sensorManager = (SensorManager)getSystemService(SENSOR_SERVICE); sensor = sensorManager.getDefaultSensor(Sensor.TYPE_ORIENTATION); sensorManager.registerListener(this, sensor, SensorManager.SENSOR_DELAY_UI); … }

public void onSensorChanged(SensorEvent event) { … float pitch = event.values[1]; float roll = event.values[2]; … if ( roll < LIMIT ) { mMindstormProxy.sendCommand(MindStormCommand.FORWARD, 50); … } … }

//onAccuracyChanged() ist für das vorgestellte System nicht von Bedeutung public void onAccuracyChanged(Sensor sensor, int accuracy) { … }…}

Frisch von der Leine: Alles, was der Eclipse-Profi braucht!

Exklusiv für Abonnenten!

Intellibook-Notebook

zum Vorzugspreis:

199 EUR (statt 350 EUR)

www.intellibook.de

NUR

199 Euro

Ihre Vorteile auf einen Blick: Frei-Haus-Lieferung des Print-Magazins!

Alle Ausgaben online immer und überall verfügbar!

Einfach online bestellen unter: www.eclipsemagazin.de/abo

Jetzt Online-Premium-Abo sichern!

Bluetooth1 2 3


nach anderen Bluetooth-Geräten suchen•gepairte Geräte durchsuchen•RFCOMM-Kanäle öffnen•Daten austauschen•Multiple Verbindungen verwalten•

Für unseren Roboter verwenden wir einen RFCOMM-Kanal zur bidirektionalen Kommunikation. Sämtliche Kommunikation startet vom Smartphone aus. Wir schicken Steuerbefehle an die angeschlossenen Moto-ren und fragen die Sensoren periodisch nach aktuellen Werten.

Kommunikation zwischen Android und Roboter über BluetoothBluetooth dient als Kommunikationskanal zwischen Android-Gerät und dem NXT. Die Bluetooth-Fähig-keiten von Android komplett zu beschreiben, sprengt den Rahmen und die Intention dieses Artikels. Im Fol-genden konzentrieren wir uns daher auf die Kommuni-kation zwischen den beiden Geräten und gehen davon aus, dass beide Geräte sich bereits kennen und gepairt sind. Zentrale Bestandteile von RoboDroid sind die Activity RoboDroid und die Klasse MindStormProxy. Die Activity dient als Controller, verarbeitet Benutzer-eingaben und visualisiert eingehende Sensorwerte; der MindStormProxy kapselt die komplette Kommunika-tion mit dem NXT, ist zuständig für die Bluetooth-Verbindung, empfängt Sensorwerte und bietet eine einfach zu bedienende Schnittstelle, um den Roboter zu steuern.

Verbindungsaufbau und bidirektionale KommunikationErster Schritt ist der Verbindungsaufbau und die Be-reitstellung einer Infrastruktur, die eine bidirektionale Kommunikation ermöglicht. Dazu verbinden wir An-droid-Gerät und NXT per Bluetooth und öffnen eine Socket-Verbindung. Der Socket (mBtSocket) bietet einen InputStream für eingehende und einen OutputStream für ausgehende Nachrichten (Sensor-Werte/Kommandos) an. Die Verwendung der beiden Streams zum Nachrichtenaustausch und der technische Ablauf

Abb. 2: Darstellung der Rotation

Listing 2: Verbindungsaufbau

public class RoboDroid extends Activity implements MindStormResponseListener { …

public void onCreate() { super.onCreate(); … mMindstormProxy = new MindStormProxy(); mMindstormProxy.registerMindStormResponseListener(this); mMindStormProxy.connect(«00:16:53:08:93:A6»); … }

public void onMindstormResponse(final MindStormResponses resp, final int intensity) { runOnUiThread(new Runnable() { public void run() { int alpha = (255 * intensity / 100); switch (resp) { case LIGHT: displayLight.setBackgroundColor(Color.argb(alpha, 255, 255, 255)); break; case PRESSURE: displayPressure.setBackgroundColor(Color.argb(alpha, 255, 150, 14)); break; … } } }); } …}

public class MindStormProxy { …

public enum MindStormResponses { LIGHT, PRESSURE, VOLUME, DISTANCE }

private BluetoothAdapter mAdapter; public boolean connect(String address) { mAdapter = BluetoothAdapter.getDefaultAdapter(); BluetoothDevice dev = mAdapter.getRemoteDevice(address);

try { mBtSocket = dev.createRfcommSocketToServiceRecord(UUID_MINDSTORM); mBtSocket.connect(); … return true; } catch (IOException e) { e.printStackTrace(); return false; }

public void registerMindStormResponseListener(MindStormResponseListener list) { this.mBluetoothListener = list; }

public interface MindStormResponseListener { void onMindstormResponse(MindStormResponses resp, int intesity); } …}

Bluetooth 3 2 1


der Kommunikation werden in späteren Abschnitten genauer beschrieben, Listing 2 zeigt den Verbindungs-aufbau exemplarisch. Als Parameter werden die zuvor ermittelte MAC-Adresse des Geräts sowie eine speziel-le UUID benötigt; hier die Standard-UUID (00001101-0000-1000-8000-00805F9B34FB). Gleichzeitig wird die Activity als Listener für eingehende Signale am MindStormProxy registriert – dazu muss sie das In-terface MindStormResponseListener mit der einzigen Methode onMindstormResponse(...) implementieren. Der MindStormProxy hält somit eine Verbindung zur Activity RoboDroid und informiert diese bei eingehen-den Signalen vom NXT – damit ist die Infrastruktur für eine bidirektionale Kommunikation geschaffen. Der Verbindungsaufbau (MindStormProxy.connect()) kann eventuell länger dauern und sollte unter keinen Umständen im UI-Thread geschehen. Um die Codebei-spiele einfach und leserlich zu halten, verzichten wir allerdings auf die Verwendung eines AsyncTask und verweisen stattdessen auf das API [6].

Kommunikation mit dem NXTAlle Kommunikation geht vom Android-Gerät aus. Bei aktiver Verbindung werden Benutzereingaben (Lageän-derungen) in Bewegungskommandos übersetzt und an den Roboter übertragen. Auf Bluetooth-Ebene handelt es sich bei den Kommandos um verschiedene Byte Arrays mit fester Struktur. Der MindStormProxy abstrahiert diese und bietet ein einfach zu bedienendes API an. Ein Befehl besteht aus einem MindStormCommand (Name) und einer Intensität (0-100). Das NXT beantwortet je-des empfangene Kommando mit einer Statusmeldung und informiert über eventuell aufgetretene Fehler. Die Antworten werden hauptsächlich für das Auslesen der Sensoren benötigt und sind in einem späteren Abschnitt genauer beschrieben.

Listing 3 zeigt das Versenden eines Bewegungskom-mandos. Wird das Gerät nach vorne gekippt (Robo Droid.on Sen sorChanged), sendet die Activity das Kommando MindStormCommand.FORWARD mit entsprechender Intensität (hier 50) an den MindStormPro xy. Der MindStormProxy übersetzt das MindStormCommand in das passende Byte-Kommando, setzt die gewünschte Inten-sität und übertragt es zum Roboter. Dazu wird das Byte-Kommando in den vom Socket zur Verfügung gestellten OutputStream geschrieben.

NXT-Sensoren auslesenDas Auslesen der Sensoren erfordert erheblich mehr Auf-wand als die Übertragung von Bewegungskommandos. Auch hier wird die Kommunikation vom Android-Gerät initiiert. Es gibt leider keine Möglichkeit, den NXT dazu zu bringen, geänderte Werte aller angeschlossenen Sen-soren selbstständig an per Bluetooth verbundene Gerä-te zu übertragen (PUSH), ohne zusätzliche Programme auf den NXT zu spielen. Stattdessen müssen die Senso-ren einzeln aktiviert und periodisch abgefragt werden (POLL).

Listing 3: Senden von Kommandos an den Roboter

public class RoboDroid extends Activity implements SensorEventListener { … public void onSensorChanged(SensorEvent event) { … if (roll < LIMIT) { mMindstormProxy.sendCommand(MindStormCommand.FORWARD, 50); } }}

public class MindStormProxy { /** Contains all existing commands for the robot. */ public enum MindStormCommand { HONK, FORWARD, BACKWARD, RIGHT, LEFT, STOP, START, START_SENSORS, STOP_SENSORS }

private static final byte[] COMMAND_MOVE = new byte[] { (byte)0x80, (byte)0x04, // 2 bytes command (byte)0xff, // OUTPUT PORT (byte)0x4B, // Power set point (byte)0x07, // Mode byte 0x07 (byte)0x01, // Regulation mode (byte)0x50, // Turn ratio (byte)0x20, // RUN state (byte)0x00, (byte)0x00, (byte)0x00, (byte)0x00, (byte)0x00 };

public void sendCommand(MindStormCommand cmd, int intensity) { switch (cmd) { case BACKWARD: // BACKWARD is the same command as FORWARD with negated value intensity = -intensity; case FORWARD: bytecommand[3] = (byte)intensity; sendDirectCommand(bytecommand); break; … } }

private void sendDirectCommand(byte[] command) { if (mBtSocket != null) { byte[] myCmd = command.clone(); try { OutputStream out = mBtSocket.getOutputStream(); out.write(command.length & 0xff); out.write(command.length >> 8 & 0xff); out.write(command); out.flush(); } catch (IOException e) { e.printStackTrace(); } } }

Bluetooth1 2 3


Listing 4: Der ListenThread

public class MindStormProxy { private ListenThread mListenThread; private static final byte[] COMMAND_READ_SENSOR_LIGHT = new byte[] { (byte)0x00, (byte)0x07, // 2 bytes command (byte)0x02 // INPUT PORT (Range 0-3) };

private static final byte[] COMMAND_LIGHT_ON = new byte[] { (byte)0x80, (byte)0x05, // 2 bytes command (byte)0x02, // INPUT PORT (Range 0-3) (byte)0x05,// Sensor type 0x05 LIGHT_ACTIVE 0x06 LIGHT_INACTIVE (byte)0x00 };

private static final byte[] COMMAND_LIGHT_OFF = new byte[] { … };

public boolean connect(String address) { … try { mBtSocket = dev.createRfcommSocketToServiceRecord(UUID_MINDSTORM); mBtSocket.connect(); mListenThread = new ListenThread(); mListenThread.start(); } catch (IOException e) { e.printStackTrace(); return false; } }

public void sendCommand(MindStormCommand cmd, int intensity) { switch (cmd) { case START_SENSORS: mQuerySensorTask = new QuerySensorTask(); mTimer = new Timer(); mTimer.scheduleAtFixedRate(mQuerySensorTask, 0, SENSOR_QUERY_INTERVAL); sendDirectCommand(COMMAND_LIGHT_ON); break;

case STOP_SENSORS: sendDirectCommand(COMMAND_LIGHT_OFF); mTimer.purge(); mTimer.cancel(); mQuerySensorTask.cancel(); break; … } }

/** TimerTask requerying the sensors after a certain period of time. */ class QuerySensorTask extends TimerTask { public void run() {

sendDirectCommand(COMMAND_READ_SENSOR_LIGHT); ... } };

private class ListenThread extends Thread { volatile boolean read = true; public void run() { try { … InputStream in = mBtSocket.getInputStream(); MindStormResponseInputStreamReader reader = new MindStormResponseInputStreamReader(in); ArrayList<Integer> res; while ((res = reader.readReponse()) != null) { if ((int)res.get(3) == 7) { // sensor response switch ((int)res.get(8)) { … case 6: double retval = (res.get(13) * 1000 + res.get(12)) / 22.55; mBluetoothListener.onMindstormResponse(MindStormResponses.LIGHT, (int)retval); res.clear(); break; } } in.close(); } catch (IOException e) { e.printStackTrace(); } } }}

public class RoboDroid extends Activity implements …, MindStormResponseListener { public void onMindstormResponse(final MindStormResponses resp, final int intensity) { runOnUiThread(new Runnable() { public void run() { int alpha = (255 * intensity / 100); switch (resp) { case LIGHT: lightView.setBackgroundColor(Color.argb(alpha, 255, 255, 255)); break; … } } }); }}

Bluetooth 3 2 1


Listing 4 beschreibt am Beispiel des Lichtsensors, wie die bidirektionale Kommunikation zwischen Android und NXT verläuft, um Sensoren auszulesen und zu visu-alisieren. Zunächst muss der Lichtsensor aktiviert wer-den. Der MindStormProxy bietet hierzu das Kommando START_SENSORS an. Dieses aktiviert den Lichtsensor und erstellt einen TimerTask sowie zugehörigen Timer, der die Werte des Sensors periodisch abfragt. Zum Aus-lesen der Werte kommt der beim Verbindungsaufbau gestartete ListenThread ins Spiel (in MindStormProxy.connect()). Dieser empfängt mithilfe eines MindStorm-ResponseInputStreamReader alle vom InputStream des Sockets eingehenden Signale und informiert (onMind-stormResponse) die registrierte Activity RoboDroid bei Änderungen. Um den UI-Thread nicht zu blockieren, muss dies in einem eigenen Thread stattfinden. Auf-gabe des MindStormResponseInputStreamReader ist, den ankommenden Datenstrom in einzelne Nachrich-ten zu unterteilen. Die Activity empfängt die ausgelese-ne Helligkeit als Prozentwert und aktualisiert das User Interface entsprechend. In RoboDroid ändert sich bei-spielsweise die Hintergrundfarbe eines durchsichtigen Anzeigeelements je nach Lichtintensität von schwarz über grau nach weiß.

Das User InterfaceAbbildung 4 zeigt das User Interface von RoboDroid. Es setzt sich aus verschiedenen Elementen zur Steuerung des NXT zusammen. Eine Verbindung zwischen Smartphone und NXT wird über (1) hergestellt, gleichzeitig zeigt die Farbe des Bluetooth-Symbols den Status der Verbindung an; blau bedeutet aktive Verbindung. Aus Sicherheits-gründen, hauptsächlich um zu verhindern, dass der Robo-ter die Tischkante herunterfährt, muss die „Zündung“ (2) aktiviert werden, kann aber jederzeit wieder ausgeschaltet werden, um alle drei Motoren sofort zu stoppen.

Der Roboter kann nun durch Kippbewegungen des Android-Geräts gesteuert werden. Die aktuelle Rich-tung wird durch Aufleuchten des jeweiligen Pfeils ange-geben (3). Die Sensoren werden durch Aktivierung von (4) eingeschaltet und die ausgelesenen Werte grafisch dargestellt (5). Wie bei „großen“ Fahrzeugen verfügt unser Roboter natürlich auch über eine Hupe (6). Hier-für wurde eine Sounddatei auf den NXT gespeichert, die bei Bedarf abgespielt wird.

Zu den abgedruckten SourcenEin Abdrucken des kompletten Sourcecodes ist aus Platzgründen leider nicht möglich, die hier dargestellten Codeschnipsel sind deshalb auf das Wesentliche redu-ziert, zeigen aber alle relevanten Passagen.

Unser Arbeiten mit AndroidDer uneingeschränkte Zugriff auf Gerätehardware und die Möglichkeit zur Interoperation verschiedenster An-wendungen fasziniert und weckt zugleich den Erfinder-geist in Entwicklern. Einen Lego-Mindstorms-Roboter über Bluetooth und Lagesensoren eines Android-Geräts

zu steuern, ist nur ein Beispiel, wie diese Möglichkeiten für eine Anwendung genutzt werden können. Darüber hinaus ist Android nicht nur auf den mobilen Markt beschränkt, sondern gewinnt unter anderem auch als Plattform für Infotainment-Systeme im automobilen Bereich an Bedeutung. Wir verfolgen diese Entwicklung mit großem Interesse und freuen uns auf weitere interes-sante Projekte in diesem Bereich.

Abb. 3: Die Kommunikation über Bluetooth wird immer vom Smartphone initiiert

Abb. 4: Das User Interface von RoboDroid

Links & Literatur

[1] lego MINDStoRMS NXt Direct Commands: http://bit.ly/A360_lego_1

[2] open handset Alliance: http://bit.ly/A360_lego_2

[3] Android Compatibility: http://bit.ly/A360_lego_3

[4] API Sensorevent Values: http://bit.ly/A360_lego_4

[5] Bluetooth Package Description: http://bit.ly/A360_lego_5

[6] API Asynctask: http://bit.ly/A360_lego_6

Andreas Frey arbeitet als Softwareentwickler und -Architekt bei der 1und1 Internet AG. Schwerpunkte seiner tätigkeit sind die entwicklung mobiler Anwendungen für Android und iPhone sowie die entwicklung von Jee-Anwendungen. Darüber hinaus interes-siert er sich für alles rund um Web2.0 sowie agile Anwendungs-

entwicklungs-Prozesse.

Miriam Brückner arbeitet bei der itemis in Pforzheim als Soft-wareentwicklerin. Der Schwerpunkt ihrer Arbeit liegt im embed-ded- und Automotive-umfeld. Darüber hinaus beschäftigt sie sich mit der entwicklung von Android-Anwendungen für mobile endge-räte.

Augmented ReAlity1 2 3


von Frank Angerman, tobias eble und Jan Schlink

Die erweiterte Realität ist in aller Munde. Das ist auch kein Wunder, denn durch die rasante Verbreitung von Smartphones mit Kamera, leistungsstarken Prozessoren, großen Displays, Daten-Flatrates, etablierten Vertriebs-plattformen für Software und offenen APIs für Mash-ups hält die Technologie Einzug in den Alltag von immer mehr Menschen. Damit virtuelle Daten in der realen Welt angezeigt werden können, kommt noch ein weiterer Faktor hinzu: Ortsbestimmung. Hier geht es um die Fra-gen, wo ein User ist, in welche Richtung er blickt und mit welchem Winkel er durch das digitale Fenster in die rea-

le Welt blickt. Und auch darauf haben moderne Smart-phones dank passender Sensorik wie GPS, Kompass oder Akzelerometer eine Antwort. Der mobilen Ausprägung von Augmented Reality wird eine wenn nicht goldene, so doch aussichtsreiche Zukunft vorausgesagt. Für die US-Marktforscher von Gartner Inc. beispielsweise ist der Fall klar: AR wird ein Riesenmarkt werden. Worauf es jetzt ankommt, sind sinnvolle Anwendungen, die unseren Alltag nicht nur erweitern, sondern wirklich bereichern. Dafür braucht es kreative Entwickler und die richtigen Tools für die richtige Plattform. Im Folgenden möchten wir Ihnen anhand von zwei auf Android basierenden Bei-spiele zeigen, wie Sie ganz einfach Ihre ersten Schritte in


Mehr Realität zum Selbermachen

Manche sagen, Technologie schaffe eine „Welt mit Untertiteln“, andere bezeichnen die Überlage-rung der realen Welt mit digitalen Inhalten als nötige Vorstufe auf dem Weg zum Internet der Dinge, und wieder andere nennen das ganz schlicht als „Post-its für die Realität“. Ganz gleich, wie man es nennt: Mobile Augmented Reality ist ein Paradigmenwechsel in der Organisation und Darstellung von Informationen. Denn in Zukunft wird man das Internet überall dabei haben und sich webbasier-te Inhalte dort anzeigen lassen, wo man sie braucht oder haben will.

Augmented ReAlity 3 2 1


der AR-Welt machen oder Ihre bisher gemachten Erfah-rungen erweitern können.

Eine eigene App oder ein Kanal in einem AR-Browser?Grundsätzlich gibt es für Entwickler zwei Möglichkeiten, in das AR-Ökosystem einzusteigen. Für die eine – eine ei-gene, proprietäre Anwendung – sind ein Geschäftsmodell und etwas weiter fortgeschrittene Programmierkenntnisse notwendig, denn sie ist SDK-basiert und erfordert neben größerem Zeitaufwand auch ein gewisses Investment. Die andere Variante basiert auf so genannten AR-Browsern. Diese stellen die Infrastruktur im Backend wie Server und Programmierebene und auch im Frontend mit z. B. ei-nem fertigen GUI und der Darstellung der Inhalte über ein offenes API frei zur Verfügung. Das heißt, man kann mit relativ wenig Aufwand ein AR-Konzept in die Tat umsetzen. Einzige Bedingung: Es läuft unter dem Dach und innerhalb des Browsers.

So ist zum Beispiel Moo Vision eine proprietäre App für das iPhone, mit der man eine Eiscremeverpackung von Ben & Jerrys „scannen“ kann, um im Livevideobild dann die „versteckten Zutaten“ in Form von 3-D-Ani-mationen zu entdecken (Abb. 1). Diese Marketingan-wendung entstand mit dem Unifeye SDK von metaio und nutzte das darin integrierte natürliche Feature-Tracking, um die Verpackung zu erkennen, die Position relativ zur Kamera zu bestimmen und in Echtzeit lagegerechte 3-D-Informationen im Livebild darzustellen. Eine derartige Beispielanwendung finden Sie im zweiten Teil des An-wenderberichts.

Ein Beispiel für einen so genannten AR-Browser ist die für Android und iPhone erhältliche Anwendung ju-naio. Wie man ganz einfach seinen Content oder seine Ideen auf die Straße bringt, möchten wir Ihnen im ersten Teil des Anwenderberichts zeigen.

Hello Worldjunaio ist ein Augmented-Reality-Browser, der kostenlos für das iPhone und Android-Telefone heruntergeladen werden kann. Neben dem Anzeigen von standortabhängi-gen (auch Location-based) Informationen erlaubt junaio auch visuelles Tracking. Das heißt, dass junaio zusätzlich zu GPS und Kompassinformationen auch das Kamera-bild auswerten kann, um virtuellen Content auf reale Objekte zu „kleben“ – wir nennen das junaio GLUE. Je-der Entwickler hat über junaios offene Schnittstelle (Open API) die Möglichkeit, seinen eigenen Channel zu erstellen und Infor-mationen in der Welt zu platzie-ren oder sie mit realen Objekten direkt zu verbinden (Abb. 2).

Voraussetzungenjunaio bietet Entwicklern eine offene Schnittstelle, um ein ei-genes AR-Erlebnis erschaffen zu können. Dazu gibt es online eine

umfassende Dokumentation [1], die die grundlegenden Funktionen und Möglichkeiten beschreibt und viele Bei-spiele gibt. Als junaio-Entwickler braucht man lediglich Erfahrung in Webprogrammierung. Eine serverseitige Programmiersprache wie PHP und etwas Erfahrung mit XML. Dazu benötigt man etwas Webspace auf einem Server. Auf diesem Server sollte ein Apache-Server mit PHP 5 installiert sein, wenn man PHP verwenden möch-te. Auch wenn ein Channel ohne ein Mobiltelefon vali-diert werden kann, sollte ein Entwickler ein iPhone oder Android-Telefon haben, auf dem junaio installiert ist. So kann er seinen Channel betrachten, testen und stetig verbessern.

Mit der offenen Programmierschnittstelle hat jeder Entwickler die Möglichkeit, von Informations- oder Navigations-Channels bis hin zu komplexen Multi-player-AR-Spielen alles zu entwickeln. Es findet dabei eine Integration direkt auf dem Server des Entwicklers statt, von welchem junaio authentifiziert Informatio-nen erfragt. Somit kann ein bestehendes Onlineangebot ohne späteren Verwaltungsaufwand in junaio integriert werden. Zusätzlich erhält der Entwickler Informatio-nen über die Abrufe auf seinem Channel, Interaktionen mit den virtuellen Objekten oder Positionsänderungen des Benutzers, auf die er mit Änderungen seines AR-Channels reagieren kann. Dies kann das Hinzufügen oder Entfernen von Informationen sein, das Ändern der Position oder der Eigenschaften eines virtuellen Objekts (Abb. 3).


Mehr Realität zum Selbermachen

Manche sagen, Technologie schaffe eine „Welt mit Untertiteln“, andere bezeichnen die Überlage-rung der realen Welt mit digitalen Inhalten als nötige Vorstufe auf dem Weg zum Internet der Dinge, und wieder andere nennen das ganz schlicht als „Post-its für die Realität“. Ganz gleich, wie man es nennt: Mobile Augmented Reality ist ein Paradigmenwechsel in der Organisation und Darstellung von Informationen. Denn in Zukunft wird man das Internet überall dabei haben und sich webbasier-te Inhalte dort anzeigen lassen, wo man sie braucht oder haben will.

Abb. 1: Natural Feature Tracking (ohne Marker!) in Aktion, als optische Referenz für die Bildverarbeitung dient eine reguläre Eisverpackung

Abb. 2: Dynamischer und interaktiver Content wird abhängig von Ort und weiteren Präferenzen in das Livekamerabild des Smartphones integriert



Der Hello-World-ChannelFür einen schnellen Start in die Entwicklung mit junaio gibt es ein Tutorial-Video und Getting-Started-Pakete zum Herunterladen [2]. Die Erstellung eines Channels erfolgt in vier einfachen Schritten (Abb. 4):

Onlineanmeldung und -registrierung eines neuen 1. ChannelsHerunterladen des Getting-Started-Pakets und Vor-2. nehmen von AnpassungenTesten des Channels3. Channel submitten4.

Das Ziel des Hello-World-Channels ist es, einen POI mit Textinformationen und einem Icon an einen Ort in der Welt zu platzieren. Dieses Beispiel wird folgende Infor-mation an junaio zurückgeben:

<?xml version="1.0" encoding="UTF-8"?> <results> <poi id="1" interactionfeedback="none"> <name><![CDATA[Hello World POI]]></name> <description><![CDATA[[This is my first POI.]]></description> <l>48.1385,11.5750,0</l> <o>0,0,0</o> <mime-type>text/plain</mime-type> <thumbnail>http://www.junaio.com/publisherDownload/tutorial/ icon.jpg</thumbnail> <icon>http://www.junaio.com/publisherDownload/tutorial/ icon_map.png</icon> </poi></results>

In diesem Fall ist es ein in München (Geokoordina-ten: 48.1385, 11.5750) platzierter POI mit einem Namen, einem Icon und einer kurzen Beschrei-bung.

Onlineanmeldung und -registrierung eines neu-en ChannelsNach dem Anmelden als junaio Developer auf der junaio-Developer-Website [3] kann man un-ter http://www.junaio.com/publisher/newchannel einen neuen Channel registrieren. Dieser benötigt zwingend folgende Informationen:

Name• : der Name des ChannelsDescription• : die Beschreibung des ChannelsCallback URL• : unter diesem URL erwartet junaio einen korrekt formatierten XML-String, der Informationen zu Punkten von Interesse (POIs) oder virtuellen Objekten des Channels enthält. (Beispiel für einen Callback URL: http://www.meinServer.com/junaio/html)

Zusätzlich können noch andere Informationen, z. B. ein Channel-Icon, hinterlegt werden.

Herunterladen des Getting-Started-Pakets und Vor-nehmen von AnpassungenEbenfalls auf der Webseite gibt es verschiedene Getting-Started-Pakete [4] zum Herunterladen. Solch ein Paket besteht aus verschiedenen .php-Dateien, die die Einrich-tung des Entwicklerservers vereinfachen oder ein „Out of the Box“-Erlebnis ermöglichen. Diese Pakete werden angepasst und anschließend auf den Entwicklerserver kopiert, sodass es unter dem angegebenen Callback URL des Channels aufgerufen werden kann. Folgende Anpassungen werden vorgenommen:

Anpassen des eigenen API-Keys in der • config.phpAnpassen der POI-Informationen in der • search.php, um diesen POI in der Nähe zu platzieren (Änderung des <l>-Parameters)

Das Skript kann auf den Server kopiert und im HTML-Verzeichnis der „_“ vor _.htaccess entfernt werden.

Testen des ChannelsOnline befindet sich an jedem Channel ein Validation-Button. Dieser führt grundsätzliche Aufrufe am Server aus, der im Callback-URL des Channels angegeben wurde, um den Channel zu prüfen. Gibt es hierbei keine Fehler, sollte der Channel auch am Mobiltelefon geprüft werden. Dazu loggt man sich innerhalb der junaio-Ap-plikation mit den Entwicklerzugangsdaten ein und hat so auch auf seine unveröffentlichten Channel Zugriff.

Channel submittenNachdem man zufrieden mit seinem Channel ist, kann man ihn submitten. Er wird dann nach einer kurzen Prü-

Abb. 3: Funktionsweise von junaio-Channels

Abb. 4: Erstellung eines Hello-World-Channels

Augmented ReAlity 3 2 1


fung für alle Nutzer freigegeben. Aufbauend auf diesem Beispiel finden sich auf der junaio-Webseite [2] weitere Tutorials zur Erstellung verschiedener POIs mit Websei-ten, Bildern, Videos oder eigener GLUE-Channels.

Und so entwickeln Sie eine proprietäre AR-AnwendungDas Unifeye SDK Mobile ist ein Multiplattform-AR-Framework. Es soll die Entwicklung mobiler AR-An-wendungen auf mehreren Plattformen vereinfachen und plattformspezifische APIs vereinheitlichen. Gegenwärtig werden die vier großen Plattformen unterstützt: iPhone, Android, Windows Mobile und Symbian. Im Folgenden soll beispielhaft eine erste AR-Anwendung für Android entwickelt werden. Dank einheitlicher Programmier-schnittstellen ist eine Portierung auf weitere Betriebssys-teme ohne größere Probleme möglich. Ausgenommen ist hiervon die Entwicklung der grafischen Benutzeroberflä-che, die bewusst nicht vom Unifeye SDK Mobile platt-formübergreifend berücksichtigt wird.

VoraussetzungenZunächst wird eine funktionierende Android-Entwick-lungsumgebung benötigt. Eine detaillierte Beschrei-bung hierzu findet sich auf der Android-Entwicklerseite [5]. Die Umgebung besteht im Grunde aus Eclipse mit einem Plug-in für die Hardwarekommunikation, um z. B. auch direkt auf einem Mobiltelefon zu debuggen. An die Mobiltelefone gibt es keine speziellen Anforde-rungen; im Prinzip kann jedes aktuelle Gerät für die Android-Entwicklung verwendet werden. Da Augmen-ted Reality ein rechenintensiver Anwendungsbereich ist, empfehlen wir jedoch Handys mit einem 1-GHz-Prozessor und grafischem Hardwarebeschleuniger, z. B. Google Nexus, HTC Desire oder das Sony Erics-son X10. Zusätzlich wird das Unifeye SDK Mobile benötigt, das als frei verfügbare Testversion herunter-geladen werden kann [6].

SDK-ÜberblickDer Application Layer (Abb. 5) erlaubt auch Nichtpro-grammierern die Konfiguration von AR-Anwendungen, z. B. wird in junaio mittels einer XML-Konfiguration das Tracking konfiguriert. Für Programmierer ist si-cherlich das High-Level-API am interessantesten. Ein monolithisches C++-Interface erlaubt das Erstellen komplexerer Anwendungen. Bei Android besteht die Besonderheit, dass die eigentliche Anwendung inklusive Benutzeroberfläche in Java programmiert werden muss. Deshalb wurden alle Funktionen auf Java gewrappt und um Hilfsunktionen erweitert. Somit kann eine An-wendung vollständig in Java geschrieben werden – mit dem einhergehenden Komfort inklusive einfacher GUI-Programmierung. Die rechenintensive Bildverarbeitung wird von effizienten, in C++ geschriebenen Algorithmen erledigt. Die darunterliegenden Module Tracking, Ren-dering und Capturing sind für den Programmierer nicht direkt ansprechbar und verstecken plattformspezifische Eigenheiten.

Die BeispielanwendungUm einen schnellen Start zu ermöglichen, wird mit Unifeye SDK Mobile für jede Plattform eine Beispiel-anwendung frei nach dem Motto runs out of the box mitgeliefert. Als Erstes werden wir dieses Projekt laden, bevor einzelne Bausteine erklärt werden [7]. Das soeben geladene Beispielprogramm kann auch schon direkt auf dem Handy gestartet werden.

Doch zunächst noch ein paar Details zu den Bau-steinen. Das Tracking-Verfahren sowie die zu ver-wendenden Modelle werden hauptsächlich über eine XML-Datei konfiguriert. Ein Überblick über die ver-schiedenen Tracking-Verfahren kann im metaio-Wiki [8] nachgelesen werden.

Die in Listing 1 gezeigte Konfiguration gibt an, dass das Referenzbild metaioman.ppm als Tracking-Vorlage verwendet werden soll. Wird dieses Referenzbild später mittels Bildverarbeitung in dem aktuellen Kamerabild erkannt, lässt sich die genaue Lage bestimmen und mit

Abb. 5: Der Aufbau des Application Layers

Listing 1: Konfigurationsdatei

<?xml version="1.0"?><TrackingData><Sensors> <Sensor type="FeatureBasedSensorSource" subtype="FAST"> <SensorID>FeatureTracking1</SensorID> <Parameters> <FeatureBasedParameters> <FeatureThreshold_ObservedImage>35</FeatureThreshold_ObservedImage> </FeatureBasedParameters> </Parameters> <SensorCOS> <SensorCosID>Patch1</SensorCosID> <Parameters> <referenceImage widthMM="200" heightMM="200">metaioman.ppm</referenceImage> </Parameters> </SensorCOS> </Sensor></Sensors> …



virtuellen Objekten anreichern. Die Größenangaben 200 mm beziehen sich auf die reale Größe des ausgedruck-ten Bildes. Die Tracking-Datei wird nun mittels der loadTrackingData(...)-Funktion geladen: boolean result = mUnifeyeSurfaceView.loadTrackingData((String)file-path);.

Um ein virtuelles Objekt zu laden, verwenden wir eine separate Funktion, in der auch die entsprechenden Rückgabewerte auf Gültigkeit überprüft werden.

In Listing 2 wird die verschlüsselte Datei metaioman.md2 geladen. Die möglichen 3-D-Dateiformate sind OBJ für detailreiche, nicht animierte Objekte oder MD2 für Objekte mit Animationen. Eine kurze Anleitung, wie solche Modelle mit Blender oder 3D Studio Max erstellt werden, findet sich wiederum im metaio-Wiki [9].

Schließlich wollen wir noch eine Animation abspie-len, sobald der Charakter über einen Touch Event aus-gewählt wurde (Listing 3). Animationen können durch

einen vorher definierten Klartext angesprochen werden. In diesem Fall wird mit startAnimation(sceneID, "close _up", true) die Animation close_up für den eindeutigen Objektbezeichner sceneID gestartet. Der letzte Parame-ter veranlasst, dass die Animation einfach wiederholt wird.

FazitWohin die Reise der mobilen AR geht und wann die Technologie im Internet der Dinge aufgegangen ist, kann man so heute nur schwer sagen. Auch in welchem Bereich die so genannten Killeranwendungen liegen und wie sie aussehen, ist schwer abzuschätzen. Die einen sagen, mit der digitalen Werbung im realen Raum fan-ge es an. Die anderen sagen, damit hört es auch schon wieder auf. Wieder andere sehen die größten Potenziale in den Services und in der Navigation. Und nicht we-nige entwickeln schon jetzt Szenarien für das Gaming der Zukunft. Auch wie sich die Plattformen, Endgerä-te und vielleicht auch die User weiter entwickeln, lädt zum munteren Mutmaßen ein. Im Moment sollten die Fragen jedoch eher lauten: Was ist jetzt schon möglich? Welche „Babysteps“ können wir gehen, um Multiplika-toren anzusprechen und das Potenzial der Technologie zu demonstrieren? Und auch: werden sich die Menschen langfristig 20 einzelne AR-Apps herunterladen oder sind Augmented-Reality-Browser die Lösung für die Zukunft? Wir würden uns freuen, wenn wir Sie dazu anregen konnten, sich mit diesen und anderen Fragen der Entwicklung und Implementierung von AR-Anwen-dungen auseinanderzusetzen.

Listing 2: Die Funktion „addMarkerObjects“

private boolean addMarkerObjects(ARMobileSystem unifeyeSDK) { // get the file path and check if its valid Object filepath = ApplicationManager.mFilePath.get("metaioman.md2_enc"); if (filepath != null) { // load the geomtry and check for errors int sceneid = unifeyeSDK.loadGeometry((String)filepath); if (sceneid > 0) { ApplicationManager.log("Object added with sceneid:"+String.valueOf(sceneid)); return true; } } else ApplicationManager.log("Model file not found!"); return false;}

Listing 3: Animation des selektierten Objekts

public boolean onObjectSelect(final ARMobileSystem unifeyeSDK, final int sceneID) { // Good place to start an animation unifeyeSDK.startAnimation(sceneID, "close_up", true);

// Any GUI related operation must be done in User Interface thread runOnUiThread(new Runnable(){ @Override public void run() { Toast toast = Toast.makeText(MainActivity.this, "Scene selected: "+String.valueOf(sceneID) , Toast.LENGTH_SHORT); toast.setGravity(Gravity.BOTTOM, 0, 0); toast.show(); } });

// return true if the event is handled, otherwise should return false return true;}

der diplom-ingenieur der medientechnologie (tu ilmenau) Frank Angermann ist bei metaio in münchen im Bereich der entwicklung mit Fokus auf junaio-development und developer Relations tä-tig.

Tobias Eble hat Computervisualistik an der uni Koblenz studiert und leitet die mobile-development-Abteilung bei metaio.

Jan Schlink ist nach einigen Jahren als Werbetexter in renommier-ten Agenturen bei metaio verantwortlich für kreative Konzepte und die unternehmenskommunikation.

Links & Literatur

[1] dokumentation: http://bit.ly/A360_AR_1

[2] AR-Beispiele: http://bit.ly/A360_AR_2

[3] junaio developer Website: http://bit.ly/A360_AR_3

[4] getting-Started-Pakete: http://bit.ly/A360_AR_4

[5] Android-entwicklerseiten: http://bit.ly/A360_AR_5

[6] unifeye-SdK-mobile-testversion: http://bit.ly/A360_AR_6

[7] unifeye mobile – getting Started: http://bit.ly/A360_AR_7

[8] trackingverfahren im metaio Wiki: http://bit.ly/A360_AR_8

[9] tutorial zur erstellung von modellen: http://bit.ly/A360_AR_9

Adobe AIR 3 2 1


von Saban Ünlü

Das SDK für Adobe AIR 2.5 ist eine Ansammlung von Entwicklerbibliotheken und Anwendungen, die es Pro-grammierern erlaubt, native Applikationen für die Android-Plattform zu erstellen. Die dabei entstehende Software ist ein Android Package (APK) und lässt sich auf allen Android-Geräten installieren und ausführen. Normalerweise ist eine APK eine Variante des Java-JAR-Formats und wird mittels des Android SDK auf Basis von Java erzeugt. Die mithilfe des Adobe SDK erzeug-ten APK sind Anwendungen, die auf der Flash-Plattform basieren und mit ActionScript 3.0 programmiert sind. Dieser Umstand bringt viele Vorteile mit sich: Zum ei-nen gewinnt der Android Market hierdurch eine Vielzahl neuer Entwickler, die mittels der neuen Technologie den

Markt deutlich bereichern können. Zum anderen wird ActionScript-Entwicklern ein einfacherer Einstieg in die Entwicklung von Android-Applikationen ermöglicht. Auch der Auftraggeber einer auf AIR basierten APK kann von der Technologie profitieren. Mit einem überschauba-ren Aufwand lassen sich bereits vorhandene Flash-RIAs in Android-Applikationen umwandeln oder umgekehrt. Das bedeutet im weitesten Sinne, dass eine Applikation, die einmalig entwickelt wurde, ohne große Mühe mehr-fach verwendet werden kann. Hier einige Beispiele:

Publizierung für den Android Market•Bereitstellung im Internet als Webanwendung•Erstellung einer Desktopanwendung•Veröffentlichung im Adobe AIR Marketplace [2]•Verwendung auf weiteren mobilen Endgeräten•

Android-Applikationsentwicklung auf Basis der Flash-Technologie AIR

Android im siebten Himmel

Seit Ende Juni 2010 ermöglicht Adobe ActionScript-3.0-Entwicklern den Zugang zu einer Betaversion von AIR 2.5 für Android [1]. Adobe AIR war bislang dafür bekannt, Flash-RIAs als Desktopanwendung bereitzustellen. Mit der neuen Version wird Entwicklern die Ver-öffentlichung auf der Android-Plattform ermöglicht – in diesem Artikel wollen wir die neue Technologie vorstellen und auf die Möglichkeiten eingehen.

Adobe AIR1 2 3


Letzteres ist im Moment noch Zukunftsmusik – ver-trauen wir jedoch Adobe und dem Open Screen Project [3], so sind Potenzial und vor allem die notwendigen starken Partner vorhanden. Für die Android-Plattform hingegen müssen wir nicht spekulieren: Die Technologie steht bereits in den Startlöchern, und es ist mit einer zeit-nahen Veröffentlichung zu rechnen. Höchste Zeit also, der Laufzeittechnologie Adobe AIR für Android auf den Zahn zu fühlen.

EntwicklungsumgebungUm sich ein Bild von Adobe AIR für Android zu machen, muss zunächst eine Entwicklungsumgebung installiert werden. Grundsätzlich benötigen Sie keine besondere Software, um mit dem AIR SDK Android-Applikationen entwickeln zu können. Ein Editor und ein sicherer Um-gang mit dem Terminal und Kommandozeilen-Compi-lern reichen vollkommen aus. Deutlich einfacher machen Sie sich das Leben aber mit den Adobe-Produkten, die das Aufsetzen eines Projekts und das Ansprechen des Com-pilers automatisch übernehmen. Die Software, die Sie hierfür benötigen, ist kostenfrei oder als Testversion ver-fügbar. Im Verlauf dieses Artikels werden wir uns daher auf die Verwendung folgender Produkte konzentrieren:

Flash Professional CS5 [4]: Die Entwicklungsumge-bung ermöglicht Ihnen in Kombination mit der Android- Erweiterung (AIR for Android Extension for Flash CS5) [7] ein sehr einfaches Projektsetup, Veröffentlichung und Installation der APK.

Flash Builder [5]: Mittels des Flash Builders lässt sich deutlich komfortabler objektorientiert programmieren als mit dem ActionScript-Editor, der in Flash Professi-onal CS5 integriert ist. Bitte denken Sie daran, dass Sie erst Zugang zum Betaportal [7] erhalten, wenn Sie sich erfolgreich für Adobe AIR for Android [1] registriert haben. Laden Sie sich im Portal unter anderem folgende Pakete herunter:

AIR 2.5 Runtime – Device [For FroYo]• : Laufzeitum-gebung für Android 2.2AIR 2.5 Runtime – Emulator [For FroYo]• : Laufzeit-umgebung für eine 2.2 AVDAIR 2.5 SDK• : Das SDK muss abhängig von Ihrem Betriebssystem installiert werdenAIRforAndroid_FlashCS5_ yyyymmdd.zxp• : Die Er-weiterung von Flash CS5 wird mittels des Extension Managers installiert.

Außerdem ist die Installation des Android SDK [6] aus unterschiedlichen Gründen notwendig. Es stellt die Windows-USB-Treiber für Ihr Android-Gerät ebenso bereit wie Anwendungen (adb), die das Installieren von APK-Dateien auf einem Emulator bzw. Endgerät ermög-lichen. Darüber hinaus stellt es einen Emulator bereit, falls kein Endgerät zur Verfügung steht. Nachdem Sie Flash CS5 und anschließend den Flash Builder installiert haben, muss AIR 2.5 und das Android SDK installiert werden. Befolgen Sie hierzu bitte die Anweisungen in den Kästen „AIR SDK installieren“ und „Android SDK installieren“.

Im nächsten Schritt erstellen Sie eine Android-Emula-torinstanz (AVD) und testen Ihre Umgebung. Starten Sie zunächst über die Kommandozeile die Android-Datei in-nerhalb des tool-Verzeichnisses im Android SDK. Instal-lieren Sie anschließend unter Available Packages die SDK-Plattform für Android 2.2. Unter Windows sollten Sie auch gleich die USB-Treiber installieren. Wechseln Sie anschließend in Virtual Devices und erstellen ein

AIR SDK installieren

duplizieren Sie im Programmverzeichnis von Adobe Flash builder 4 das 1. SdK-Verzeichnis 4.0.0 bzw. 4.1.0 und benennen Sie den ordner z. b. um in 4.1AIR25Android.entpacken Sie die die 2. Zip-datei für Windows bzw. die tbz2-datei unter Mac oS.Überschreiben Sie die dateien und ordner im duplizierten Verzeichnis 3. aus Schritt 1 mit den entpackten daten. Unter Mac oS x empfiehlt es sich, diesen Schritten zu folgen:a. Kopieren Sie die tbz2-datei in das duplizierte Verzeichnis aus Schritt 1.b. Verwenden Sie sudo tar jxvf AIR25_mac_sdk_ yyyymmdd.tbz2 zum entpacken und Überschreiben der daten.Umgebungsvariablen definieren:4. a. Unter Windows erweitern Sie die Umgebungsvariable path. die Um-gebungsvariablen lassen sich in den Systemeinstellungen definieren. Verwenden Sie als erweiterung den Pfad zu dem duplizierten Verzeich-nis aus Schritt 1, gefolgt vom bin-Verzeichnis ;C:\deinAirSdKordner\bin;. denken Sie daran, dass am Anfang und ende der erweiterung ein Semikolon vorhanden sein muss.b. Unter Mac oS muss die $PATH-Variable in der ~/.bash_login-datei um den Pfad zum duplizierten Verzeichnis, gefolgt vom bin-Verzeichnis, erweitert werden. Sollte die datei noch nicht existieren, können Sie einfach eine neue unter dem Namen anlegen. beachten Sie hierbei den Punkt am Anfang des dateinamens. In unserem Fall sieht die erweiterung wie folgt aus: export PATH=$PATH:/Applications/Adobe\ Flash\ builder\ 4/sdks/4.1AIR25Android/bin

Android SDK installieren

entpacken Sie innerhalb des Programmverzeichnisses von Adobe Flash 1. builder 4 im sdks-ordner die Android-SdK-ZIP-datei. Anschließend befindet sich im SdK-Verzeichnis auch das Android-SdK-Verzeichnis. Umgebungsvariablen definieren:2. a. Unter Windows erweitern Sie die Umgebungsvariable path. die Umgebungsvariablen lassen Sich in den Systemeinstellungen definie-ren. Verwenden Sie als erweiterung den Pfad zum tool-Verzeichnis im Android SdK ;C:\deinAndroidSdKordner\tools;. denken Sie daran, dass am Anfang und ende der erweiterung ein Semikolon vorhanden sein muss.b. Unter Mac oS muss die $PATH-Variable in der datei ~/.bash_log-in um den Pfad zum tool-Verzeichnis im Android SdK erweitert werden. In unserem Fall sieht die erweiterung wie folgt aus: export PATH=$PATH:/Applications/Adobe\ Flash\ builder\ 4/sdks/android-sdk-mac_86/tools

Adobe AIR 3 2 1


Virtual Device für Android 2.2 mit ei-ner SDCard. Starten Sie anschließend die AVD und testen Sie nun, ob alles erfolgreich installiert wurde. Öffnen Sie hierfür eine neue Kommandozeile und geben Sie folgende Anweisungen ein: adt –version. Der Aufruf muss eine AIR-Version zurückgeben, die mit der Version 2.5 beginnt.

adb devices. Der Aufruf muss eine Liste von ange-schlossenen Android-Geräten zurückgeben. Hier sollten Sie mindestens eine Emulatorinstanz sehen, sofern diese wie beim Start der AVD gestartet werden konnte.

Nun installieren Sie die Laufzeitumgebung für AIR auf Ihrem Emulator bzw. Ihrem Android-Endgerät. Der Einfachheit halber sollte hierfür nur ein Gerät bzw. Emulator angeschlossen oder aktiv sein. Hierfür ist es sehr wichtig, dass Sie auf den Endgeräten den Debug-Modus aktivieren (Einstellungen | Anwendungen | Entwicklung | USB-Debugging) und unbekannte Quellen (Einstellungen | Anwendungen | Unbe-kannte Quellen) zulassen. Installieren Sie die Lauf-zeitumgebung für Emulatoren über die Kommandozeile mit folgenden Befehl: adb install ./Runtime_Emulator_Froyo_ yyyymmdd.apk. Bitte bedenken Sie, dass Sie sich innerhalb des Terminals in dem Verzeichnis befinden müssen, indem auch die Datei APK abgelegt wurde!

Die Installation der Laufzeit für Endgeräte funktio-niert wie zuvor beschrieben. Es muss lediglich darauf geachtet werden, dass man hierfür die Runtime_Device_Froyo_ yyyymmdd.apk installiert.

Zu guter Letzt muss jetzt nur noch die Android-Erwei-terung für Flash CS5 installiert werden. Doppelklicken Sie hierfür auf die Datei AIRforAndroid_FlashCS5_ yyyymmdd.zxp. Hierdurch sollte sich der Extension Manager öffnen, in dem Sie den Anweisungen zur Ein-richtung folgen. Sollte der Manager nicht starten, wurde er nicht gemeinsam mit Flash CS5 auf Ihrem System in-stalliert. Sie müssen daher, um die Erweiterung installie-ren zu können, zuvor den Manager [8] installieren. Die Erweiterung ist erst nach einem Neustart von Flash CS5 verfügbar.

Funktionsweise und ProjektsetupDie Bestandteile, aus denen eine AIR-Android-Applikati-on erzeugt wird, sind überschaubar. Das Kernelement ist eine SWF-Datei, die den gesamten Quellcode beinhaltet (ActionScript 3.0), Grafiken und Logiken für die Anwen-dung. Im Regelfall werden SWF-Dateien in Kombination mit HTML auf Webservern zur Verfügung gestellt und sind über den Flash-Player im Clientbrowser zu betrach-ten. Weiter wird eine Anwendungsdeskriptordatei (siehe Kasten) benötigt, die eine Applikation bezüglich ihrer In-halte und Einstellungen in Form einer XML beschreibt. Diese beiden Dateien werden anschließend mittels eines von Adobe zur Verfügung gestellten Packagers zu einem Softwarepaket verschmolzen. Für gewöhnlich ist das Pa-ket, das dabei entsteht, eine AIR-Datei. Eine AIR-Datei

lässt sich mit der gleichnamigen Laufzeitumgebung von Adobe installieren und stellt anschließend eine Desktop-anwendung zur Verfügung. Im Fall der Android-Platt-form wird von dem Software-Packager allerdings eine APK erzeugt, die als native Applikation auf Endgeräten installiert werden kann. Hierbei ist zu beachten, dass auch diese Anwendung die AIR-Laufzeitumgebung zur Ausführung benötigt. Zum aktuellen Zeitpunkt steht noch nicht fest, ob die Laufzeitumgebung bei der Installa-tion einer AIR-APK automatisch mitinstalliert wird oder separat installiert werden muss. Während der Betaphase muss sie auf jeden Fall manuell – wie beschrieben – ins-talliert werden.

Bei der Paketierung einer APK wird automatisch auch eine Signierung der Datei vorgenommen. Auf diese Weise lässt sich später immer der Urheber der Anwendung eruieren – sofern das Zertifikat des Ent-wicklers ordnungsgemäß angelegt wurde. Optional lassen sich auch Anlagen in ein Paket einbinden. Die in der Anlage abgelegten Ordner und Dateien sind an-schließend durch die Anwendung erreichbar. So kön-nen beispielsweise Bilder, Audios, Videos oder auch SQLite-Datenbanken ausgelagert und nur bei Bedarf initialisiert werden.

BeispielanwendungAm einfachsten lässt sich eine APK mithilfe von Flash CS5 erstellen. Die IDE unterstützt Sie beim Anlegen des Projektsetups, erzeugt automatisch die Anwendungs-deskriptordatei, kompiliert eine SWF und steuert den Software-Packager zur Erstellung der APK. Selbst die In-stallation und Ausführung der Anwendung werden auf Wunsch von der Entwicklungsumgebung übernommen.

Abb. 2: Paketierung einer AIR APK für Android

Abb. 1: Nach der Installation wir die Android-Erweiterung im Manager aufgeführt

Adobe AIR1 2 3


In dem folgenden Beispiel wird eine Anwendung erstellt, die mithilfe des Beschleunigungssensors ein grafisches Element steuern soll.

Öffnen Sie das Vorlagenfenster in Flash CS5 über Da-tei | Neu und wählen Sie in dem Bedienfeld das Register Vorlagen und die Kategorie Air for Android. An-schließend selektieren Sie die Vorlage 480x800 Android und klicken auf OK. Dann speichern Sie die FLA-Datei.

Öffnen Sie das Application-&-Installer-Settings-Be-dienfeld über Datei | AIR Android Einstellungen. In der aktuellen Beta ist die Lokalisierung noch nicht ab-geschlossen, weshalb wir alle Einstellungen auf Englisch

Anwendungsdeskriptordatei

In der Anwendungsdeskriptordatei werden alle einstellungen für eine Applikation im XML-Format definiert. Im Folgenden erläu-tern wir Ihnen die wichtigsten einstellungsmöglichkeiten anhand eines beispiels, das Sie auf der beliegenden Cd finden.

application: In dem Root-XML-Knoten wird der Namensraum für die XML als Attribut (xmlns) definiert. es ist wichtig, dass Sie hier auf AIR 2.5 referenzieren, indem Sie die Version als endver-zeichnis des URL definieren. Je nach Namensraum wird für eine spezifische AIR-Umgebung die Anwendung generiert.

id: ein eindeutiger bezeichner für Ihre Anwendung. Mittels der Id wird die Anwendung auf dem endgerät identifiziert und ausgeführt. Um eine eindeutigkeit gewährleisten zu können, verwenden Sie als Identifikator die einstiegsklasse Ihrer Appli-kation inkl. der Pakethierarchie. die in dem beispiel aufgeführte Anwendung kann anschließend über die Kommandozeile auf dem Gerät gestartet werden. Verwenden Sie hierzu folgende Anweisung: adb shell am start -a android.intent.action.Main -n app.com.netTrek.dev.CameraApp/.Appentry

versionNumber: die Versionsnummer darf nur Zahlen und Punke enthalten und versioniert Ihre Anwendung. Mittels dieser Num-mer wird im Android Market auf Updates geprüft und ggf. dem benutzer zum Update angeboten.

filename: Name der Ausgabedatei.

description: beschreibender Text über Ihre Anwendung. Wenn Sie eine mehrsprachige beschreibung definieren wollen, verwenden Sie den text-Knoten wie im beispiel (auskom-mentiert) dargestellt. Verwenden Sie für eine deutschspra-chige beschreibung entsprechend den Ländercode de: <text xml:lang="de">deutsche beschreibung für diese App</text>

name: der Name Ihrer Anwendung. Wenn Sie eine mehrsprachi-ge benennung definieren wollen, verwenden Sie den text-Knoten wie zuvor beschrieben.

initialWindow.content: Relativer Pfad zu der SWF-datei, aus der die AIR-Applikation erzeugt wird.

initialWindow.fullScreen: Verwenden Sie hier den Wert true, falls Sie Ihre Applikation so laufen lassen möchten, dass die Andro-id-Statusleiste nicht zu sehen ist – andernfalls false.

initialWindow.autoorients: erlaubt Ihrer Applikation die automatische darstellungsausrichtung im Hoch- und Querformat. die darstellung ändert sich automatisch, wenn der Wert true ist, in Abhängigkeit, wie das endgerät in der Hand gehalten wird. Je nach verwendeter darstellung muss darauf geachtet werden, dass die bedienelemente in der Anwendung umpositioniert bzw. skaliert werden. Unterschied-liche eigenschaften (deviceorientation, autoorients, supportsorien-tationChange) und ereignisse (orientationChange) der State-Klasse unterstützen Sie bei der erkennung der darstellung.

initialWindow.aspectRatio: Sollte der Wert für autoorients auf false gesetzt sein, können Sie in diesem Knoten bestimmen, ob Ihre Anwendung im Hochformat (portrait) oder Querformat (landscape) dargestellt wird.

initialWindow.renderMode: Aktivieren Sie innerhalb Ihrer Appli-kation die Hardwarebeschleunigung zum Rendern Ihrer Grafiken, indem Sie den Wert auf gpu setzen.

icon: In diesem Knoten können Sie Icons für Ihre Anwendung definieren. Verwenden Sie hierfür PNG-Grafiken in den dimen-sionen 36 x 36 Pixel, 48 x 48 Pixel und 72 x 72 Pixel. Referen-ziert werden die Icons innerhalb der entsprechenden Knoten image36x36, image48x48 und image72x72. bitte beachten Sie, dass die Icon-Grafiken zusätzlich als Anlange für den Soft-ware-Packager definiert sein müssen.

android.manifestAdditions.manifest: Im Manifest-bereich werden Android-spezifische einstellungen definiert. eine der wichtigs-ten einstellungsmöglichkeiten ist hierbei die Verwendung des folgenden Knotens: <attribute name="android:installLocation" value="preferexternal"></attribute>. Hiermit sind Sie in der Lage, Ihre Anwendung so zu bereichern, dass sie auf der Sd-Karte ins-talliert werden kann (erst ab Android 2.2). der Wert preferexternal sorgt hierbei dafür, dass die Sd-Karte als Installationsort präferiert wird, falls eine Karte eingelegt ist und über ausreichend Speicher-platz verfügt. Alternativ kann auch der Wert auto verwendet werden.

android.manifestAdditions.manifest.data: Im CdATA-bereich dieses Knotens werden alle berechtigungen [10] für Ihre Appli-kation eingestellt. Jede Android-Anwendung fordert vom benut-zer unterschiedliche berechtigungen, die er für die Installation der Anwendung akzeptieren muss. die in dem beispiel aufge-führte berechtigung sorgt dafür, dass die Anwendung auf das Internet zurückgreifen darf und daten von dort beziehen kann.

vornehmen müssen. Im Register General werden alle allgemeinen Einstellungen zur Anwendung vorgenom-men. Hier werden die Ausgabedatei, der Applikationsna-me, der Identifikator sowie die Version und Ausrichtung festgehalten. Details zu den Einstellungen finden Sie im Kasten „Anwendungsdeskriptordatei“. Weiter sind Sie hier auch in der Lage, Applikationsanlagen hinzuzufügen (Abb. 3). Für unser Beispiel können wir alles so belas-sen, lediglich die Option Full screen aktivieren wir. Im Register Deployment (Abb. 4) müssen wir nun diverse Einstellungen zur Paketierung und Installation der An-wendung vornehmen.

Adobe AIR 3 2 1


Zunächst legen wir ein Zertifikat fest, mit dem die APK signiert wird. Sollten Sie kein persönliches p12-Zertifikat besitzen, können Sie über die Schaltfläche Create ein neues erstellen. Bitte achten Sie darauf, dass zur Veröffentlichung einer Anwendung im Android Market eine Gültigkeitsdauer von 25 Jahren notwendig ist. Im nächsten Eingabefeld tragen Sie das Passwort zu Ihrem Zertifikat ein. Anschließend können Sie den Typ der Veröffentlichung bestimmen. Wählen Sie Release, um eine Applikation für den Market zu erzeugen bzw. Device debugging, um eine Testversion zu erstellen. Eine Debugging-Version lässt sich über eine ActionScript- 3.0-Debug-Session auch mit Breakpoints und Speicher-abbildern durchführen. Achten Sie in diesem Fall dar-auf, dass Sie die Internetberechtigung verwenden und die Applikation auf dem Endgerät erst nach dem Start der Session öffnen.

In dem Bereich After publishing können Sie einstellen, dass die Applikation automatisch auf dem angeschlosse-nen Endgerät bzw. Emulator installiert (Install applica-tion on the connected Android device) und auf Wunsch anschließend ausgeführt (Lauch application on the con-nected Android device) wird. Aktivieren Sie hier beide Optionen. Beachten Sie bitte, dass Sie beim Debugging das automatische Ausführen der Anwendung deaktivie-ren müssen. Im letzten Feld wird die adb-Datei im An-droid SDK ausgewählt. Erst mit dieser Angabe wird die Installation und Ausführung der APK auf dem Endgerät ermöglicht. Zuvor haben wir auch schon mit der adb die Laufzeitumgebung auf unser Zielgerät installiert. Im

Abb. 3: Allgemeine Einstellungen in Flash CS5 Abb. 4: Einstellungen zur Veröffentlichung

Register Icons können Sie die jeweiligen Icons für Ihre Anwendung selektieren. Wenn Sie die Paketierung mit Flash CS5 durchführen, müssen Sie die Bilddateien nicht zusätzlich in die Anlage hinzufügen.

Beenden Sie die Einstellungen mit OK und speichern Sie die offene Datei erneut. Dadurch wird automatisch die Anwendungsdeskriptordatei erstellt. Sie finden die XML-Datei im gleichen Verzeichnis wie Ihre FLA.

Öffnen Sie nun den ActionScript-Editor über Fenster | Aktionen und geben Sie den im Kasten „Scripting“ aufgeführten Code ein. Speichern Sie nun erneut die Da-tei und beginnen Sie den Veröffentlichungsprozess über Datei | Veröffentlichen. Im Anschluss an die Veröf-fentlichung wird die Anwendung automatisch auf Ihrem Emulator bzw. Endgerät ausgeführt.

FazitIn Anbetracht der Tatsache, dass wir mit einer Betaver-sion arbeiten, muss ich sagen: „Es fühlt sich gut an“. Selbst komplexe ActionScript-Projekte, die ich zum Ex-perimentieren in eine APK portiert habe, machten keine nennenswerten Probleme. Lediglich mit der Videoper-formance bin ich im Moment noch nicht glücklich und hoffe, dass dieses Feature bis zum Erscheinungstermin verbessert wird. Grundsätzlich erreiche ich aber über ActionScript fast alles, was ich auch über native Pro-gramme erreichen kann. Netzwerkschnittstellen, Ka-mera, Mikrofon, GPS-Sensor, Beschleunigungssensor, File-System und vieles mehr konnte ich erfolgreich an-sprechen. Getestet habe ich die Anwendungen mit dem

Adobe AIR1 2 3


Scripting

der hier aufgeführte Code erstellt in Zeile 13 ein zur Laufzeit gezeich-netes Viereck. In Zeile 15 und 16 wird die Zeichnung als bitmap in den Arbeitsspeicher gelegt. Auf diese Weise profitieren wir von einer höheren Performance, weil bitmap-daten schneller gerendert werden können als Vektordaten.In Zeile 21 wird kontrolliert, ob wir Zugriff auf den beschleu-nigungssensor haben. Sollte dies der Fall sein, wird der bescheunigungs-sensor in Zeile 23 und 24 angesprochen und auf Updates des Sensors in der Methode onAcc (Zeile 32) reagiert. In der Funktion move (Zeile 39) werden die Sensorinformationen dafür verwendet, das gezeichnete Viereck zu bewegen.

import flash.sensors.Accelerometer;import flash.events.AccelerometerEvent;import flash.events.Event;import flash.display.Shape;import flash.display.Graphics;

var accX:Number;var accY:Number;var maxX:Number;var maxY:Number;var accelerometer:Accelerometer;

var redBox:Shape = drawRedBox ();

redBox.cacheAsBitmapMatrix = new Matrix ();redBox.cacheAsBitmap = true;

maxX = stage.stageWidth - redBox.width;maxY = stage.stageHeight - redBox.height;

if (Accelerometer.isSupported) { accelerometer = new Accelerometer(); accelerometer.addEventListener( AccelerometerEvent.UPDATE, onAcc ); addEventListener( Event.ENTER_FRAME, move );} else { trace( "Accelerometer is not supported" );

}

function onAcc( e:AccelerometerEvent ):void { e.stopImmediatePropagation(); accX = e.accelerationX * -20; accY = e.accelerationY * 20;}

function move( e:Event ):void { if (redBox) { var expX:Number = redBox.x + accX; var expY:Number = redBox.y + accY; if (expX < 0) { expX = 0; } else if ( expX > maxX ) { expX = maxX; } redBox.x = expX;

if (expY < 0) { expY = 0; } else if ( expY > maxY ) { expY = maxY; } redBox.y = expY; }}

function drawRedBox () : Shape { var redBox:Shape = new Shape (); var g:Graphics = redBox.graphics; g.beginFill( 0xff0000 ) g.drawRect( 0, 0, 10, 10 ); g.endFill(); addChild( redBox ); return redBox;}

Nexus One, dem HTC Desire und dem HTC Legend. Unglücklich bin ich lediglich darüber, dass einige Her-steller dazu neigen, das Betriebssystem zum Teil stark zu modifizieren, sodass einige Features der nativen AIR-Klassen nicht funktioniert haben. Dies konnte man aber in den meisten Fällen durch Workarounds wieder beheben. Gespannt dürfen wir auf ein beson-deres Flex SDK namens Hero [11] sein. Dieses wurde speziell dafür entwickelt, die deklarative Program-miersprache MXML für Mobiltelefone zu optimieren und somit die Applikationsentwicklung deutlich zu beschleunigen.

Links & Literatur

[1] Air 2.5 für Android: http://labs.adobe.com/technologies/air2/android/

[2] Adobe AIR Marketplace: http://airmarketplace.adobe.com

[3] open Screen Project: http://www.openscreenproject.org/

[4] Adobe Flash: http://www.adobe.com/de/products/flash/

[5] Adobe Flash builder: http://www.adobe.com/de/products/flashbuilder/

[6] Android SdK: http://developer.android.com/sdk/

[7] betaportal: https://prerelease.adobe.com

[8] extension Manager: http://www.adobe.com/de/exchange/ em_download/

[9] eSeminar-Aufzeichung und weitere Informationen und bespiele: http://v4.nettrek.de/de/1/139

[10] berechtigungsmanifest: http://developer.android.com/reference/android/Manifest.permission.html

[11] Flex SdK Hero: http://labs.adobe.com/technologies/flex/mobile/

Saban Ünlü [netTrek.de] ist freiberuflich als entwickler und Con-sultant tätig. Seit 10 Jahren hat er sich auf die Flash-Plattform spezialisiert und profitiert von seiner langjährigen erfahrung als professioneller Flex-und ActionScript-entwickler.

Datenspeicherung

1 | 2010 ANDROID360www.android360.de

3 2 1

101

von Jan peuker

Moleskine-Notizbücher haben es in alle Handtaschen ge-schafft, obwohl wir dachten, zwei Mobiltelefone wären genug. Trotz MP3 im Telefon lieben wir den iPod. Da-ten in verschiedenen Formen auf verschiedenen Medien zu halten, ist ein elementarer Bestandteil unseres Lebens geworden. Gerade unter Android, dem jüngsten, aber bei Entwicklern schon beliebtesten der Handybetriebs-systeme, ist es wichtig, die zum jeweiligen Zweck ange-messenen Mittel einzusetzen. Dieser Artikel liefert einen Überblick über diese Mittel. Es werden Vergleiche zu Java ME gezogen und es wird ein Blick in die Zukunft gewor-fen. Diese Vergleiche beruhen, so wie der Blick nach vor-ne, auf persönlichen Erfahrungen mit der Entwicklung mobiler Anwendungen in den letzten sieben Jahren. Den Anfang bildet eine Bestandsaufnahme zur Notwendigkeit der Speicherung von lokalen Daten auf mobilen Geräten. Danach werden Möglichkeiten zur Lösung dieser Anfor-derungen jetzt und in naher Zukunft aufgezeigt.

Notwendigkeit lokaler DatenhaltungEs wird in diesem Artikel davon ausgegangen, dass lo-kale Datenhaltung unabdingbar für schnelle Reaktions- und hohe Laufzeit ist. Daher wird mit einem Überblick der fünf wichtigsten Use Cases für Datenspeicherung begonnen:

Der offensichtlichste Nutzen von lokaler Speiche-1. rung sind Benutzereinstellungen, also Properties – oft in Key-/Value-Form. Hierbei muss auf Da-tensicherheit (z. B. bei Passwörtern) und schnellen Zugriff beim Anwendungsstart geachtet werden, deshalb sind Dateien gut geeignet.Anwendungen der ausgelieferten Ressourcen sind 2. meist fest im Auslieferungspaket integriert – unter

Android werden diese mit „R“-Zugriffskonstanten gespeichert. Doch auch der Zustand der Aktivität muss unter Umständen persistiert werden. Dies ist besonders wichtig, da der Activity Lifecycle jeder-zeit unterbrochen werden kann. Hier kommt es auf schnelle (De-)Serialisierung, aber auch auf Sicherheit an – das Metier von Datenbanken.Daten, die der Benutzer in der Anwendung erstellt 3. hat, können vielfältiger Natur sein. Im einfachsten Fall sind sie eine Spezialform der Anwendungsdaten, z. B. Spielstände, können aber auch heruntergelade-ne Komponenten sein, die meist in privaten Dateien abgelegt werden. Einige Anwendungen müssen diese Daten aber auch extern bereitstellen, etwa Doku-mente oder Bilder. Hier sieht man oft Zwitterlösun-gen aus Cache/Index und Dateien.Zur Kommunikation zwischen Prozessen unter An-4. droid gibt es vielfältige Möglichkeiten, etwa Intents und Content Provider. Androids Konzept der Aktivi-täten, die auf systemweite Aufgaben reagieren, agiert hier als Integrationsschicht zwischen allen Anwen-dungen. Soll weniger zielgerichtete Kommunikation verwendet werden, kann man die Daten über einen Provider oder öffentliche Dateien für alle zugänglich machen. Datenbanken sind, auch zwischen Threads, jedoch nicht geeignet, da SQLite dateibasiert lockt.Besonders für Anwendungen mit starker Backend-5. Abhängigkeit ist das Caching von Web-Service-Informationen wichtig. Hier kommt es je nach Web Service zwar weniger auf Sicherheit an, dafür aber auf eindeutigen Zugriff und Metainformationen (etwa HTTP eTags). Oft wird der Request nach dem Amazon-Prinzip gehasht und anstelle des Quell-formats (z. B. JSON) direkt im für die GUI dar-stellbaren Format gespeichert – häufig in einfachen Datenbanken.

Ein Überblick über die Möglichkeiten der Datenspeicherung unter Android

Roboters geheime Tagebücher Das Deathmatch von Web- gegen Rich-Client-Anwendungen wird auf dem Feld der Datenhaltung ausge-tragen. In der mobilen Welt stellt sich die Frage, wo gespeichert werden soll, wenn alles ständig in Be-wegung ist. Doch was muss überhaupt gespeichert werden? Und wie? Und kann uns die Cloud dabei helfen?

Datenspeicherung

www.android360.de1 | 2010 ANDROID360

1

102

2 3

Bei der Datenspeicherung wird immer die Entscheidung zwischen Zugriffszeit, Transferrate, Konsistenz und Skalierbarkeit getroffen. Diese Entscheidung wird stark von der verwendeten Technologie beeinflusst – in Tabel-le 1 werden die Wichtigsten vorgestellt.

Sicherheit und SpeicherverfahrenVorab soll jedoch an einen weiteren Faktor erinnert werden: die Sicherheit. Geteilte Dateien in öffentlichen Ordnern haben keinerlei Schutz, wohingegen „private“ Dateien theoretisch nicht zugänglich sein sollten. Unter Java Mobile ist eine zusätzliche Verschlüsselung des Java Record Management Stores (RMS) unumgänglich, mit dem JSR-177 steht auf einigen Geräten aber ein Pa-ket sicherer Funktionen zur Verfügung. Unter Android sind verwendete Dateien und Datenbanken grundsätz-lich nicht von anderen Anwendungen einsehbar, können aber auf einem unter root ausgeführten Telefon gelesen werden. Sensitive Daten wie Passwörter oder Zertifikate sollten deshalb auch hier verschlüsselt werden.

SpeichertechnologienViele der hier vorgestellten Technologien beziehen sich auf Android, da unter dieser Plattform momentan die größte Vielfalt herrscht. Unter Java ME gibt es RMS und Dateien, die jedoch beide nur bedingt zur Kommu-nikation zwischen Anwendungen geeignet sind. Platt-formspezifische Bibliotheken wie etwa RIMs globalen EventListener, neue Qt Frameworks unter MeeGo oder den geteilten Speicher von JavaFX beleuchten wir hier nicht. Android hingegen hat den unterschiedlichen An-forderungen von Anfang an Rechnung getragen [1]. Es bietet für alle oben genannten Fälle maßgeschneiderte Lösungen an. Für kurze Speicherung während der Pau-sierung einer Aktivität werden oft die zur Verfügung gestellten Bundles genutzt. Diese kleinen Datenpakete

bleiben im Speicher – jedoch nur solange, bis die Appli-kation vollständig geschlossen wird. Der Programmie-rer muss für eine Persistenz darüber hinaus sorgen. Für Benutzereinstellungen gibt es die SharedPreferences mit der dazugehörigen PreferencesActivity zur komfortab-len Verwaltung und Speicherung der Wertpaare.

DateispeicherungMöchte man direkt auf Dateien zugreifen, bietet Andro-id die Schnittstelle openFileOutput an. Hierüber können verschiedene Arten von File Handles angefordert und in einen FileOutputStream geschrieben werden. Standard-mäßig handelt es sich dabei um private Dateien der An-wendung. Eine Besonderheit sind Raw-Dateien, die zur Entwicklungszeit festgelegt werden können – Android lie-fert darauf einen automatisch generierten InputStream:

FileOutputStream fileOutput = openFileOutput(FILENAME, Context.MODE_PRIVATE);fileOutput.write(dataObject.getStringRepresentation().getBytes());fileOutput.close();

Oft möchte man aus Datensicherungsgründen auf Da-teien, die auf externem Speicher, z. B. SD-Karte, liegen, zugreifen. Dabei müssen bei Android aber Verzeichnis-strukturen berücksichtigt werden. Ab Android 2.2. gibt es spezielle Methoden, um Datei-Handles für bestimm-te Content-Typen zurückzuliefern. Will man etwa eine Cache-Datei auf dem externen Speicher erstellen, ruft man getExternalCacheDir() auf, um ein Handle hierauf zu erhalten. Apps können nun auf dem externen Speicher installiert werden – allerdings muss hier darauf geachtet werden, dass z. B. bei einer USB-Verbindung die Karte unmounted wird, was die Anwendung abstürzen lassen kann.

Wenn man Benutzerdaten exportieren oder austau-schen will, kann man entweder auf den externen Spei-cher zugreifen oder einen temporären Export direkt an die Zielaktvität realisieren. Entweder stellt man die Daten dafür in einem Content Provider zur Verfügung, der von beliebigen Aktivitäten aufgerufen werden kann, oder man ruft die Zielaktivität über einen Intent mit weiteren Informationen auf (Abb. 1). Der Nutzer kann dann, vorausgesetzt der Intent ist nicht eindeutig, entscheiden, welche Aktivität den Intent umsetzt. So könnte man z. B. eine E-Mail senden, indem man das System aller Ziel-Activities für den Sende-Intent anzei-gen lässt:

Abb. 1: Kommunikation mit Intents

Benutzung sinnvoll? Datei Bundles Datenbank Cloud

a) Benutzereinstellungen Ja Ja Nein Teilweise

b) Ressourcen Ja Nein Nein Ja

c) Benutzerdateien Ja Nein Ja Teilweise

d) Prozesskommunikation Teilweise Ja Nein Nein

e) Servicedaten/Cache Ja Nein Teilweise Nein

Tabelle 1: Sinnvolle Speicherverfahren unter Android

Datenspeicherung


3 2 1

103

final Intent sendEmailTo = new Intent(Intent.ACTION_SEND);sendEmailTo.setType("text/plain");sendEmailTo.putExtra(Intent.EXTRA_SUBJECT, subject);…startActivity(Intent.createChooser(sendEmailTo, R.string.title_email));

Der Vollständigkeit halber sei der RMS unter Java ME erwähnt, der seit MIDP 1 als Standardschnittstelle zur Informationsablage verfügbar ist. Seit MIDP 2 kann der Speicher auch von mehreren Anwendungen genutzt werden, in MIDP 3 werden Tags, d. h. native Einschrän-kungsgruppen sowie Datenbankvorbelegung ergänzt und die Sicherheit erhöht. Das kann jedoch nicht über den mangelnden Komfort des Byte-Array-basierten Speichers hinwegtäuschen, weshalb er auch unter Android nicht verfügbar ist. Der grundsätzlich auch auf Java Mobile be-ruhende BlackBerry hat eine eigene Objektpersistenzbi-bliothek sowie eine integrierte SQLite-Implementierung, weshalb dort der RMS nur aus Kompatibilitätsgründen zu finden ist. SQLite jedoch ist auch unter Android die erste Wahl bei der Schema-orientierten Speicherung.

SQLiteRelationale Datenbanken sind seit jeher die bevorzug-te Weise der strukturierten Ablage von Informationen. Die meisten Pakete gehen mit ihren Anforderungen an Ressourcen jedoch über die Möglichkeiten der meisten mobilen Geräte hinaus. Von einigen Datenbanken exis-tieren daher, in die Anwendung integriert, auslieferbare („embedded“) Varianten. Ein Beispiel dafür sind My-SQL und Berkeley DB, mittlerweile unter Oracle wieder vereint, sowie Derby, die unter Java 6 auch als Java DB bekannt ist.

SQLite ist die populärste relationale Embedded-Datenbank mit Transaktionssteuerung. Da hier kein Serverdienst betrieben werden muss, stellt sie eine um-fangreiche API zur Verfügung. Auf Android wird die Datenbank standardmäßig genutzt. Mit der Plattform 2.2 kann sie besonders vom JIT profitieren. Aber auch Plattformen wie Maemo bzw. MeeGo (mit Qt), Adobe Air (das auch unter Android verfügbar ist) oder RIMs BlackBerry OS (für Java) liefern das Paket mit, weshalb ihm hier mehr Platz eingeräumt wird. Um per SQLite Daten zu speichern, benutzt man unter Android die Me-thoden des android.database.sqlite-Pakets. Beim Design des Datenmodells sind besonders die Datentypen zu beachten. Da SQLite keine Datumsfelder unterstützt, sollte auf durchgängige Datumsformatierung geachtet werden. Um Platz und Codierungszeit zu sparen, kann man in Base64 vorliegende Strings in ein Byte-Array statt in UTF-8 Strings speichern.

Um Content Provider zu nutzen, ist eine eindeutige ID mit dem Namen der Konstante BaseColumns._ID not-wendig. Da SQLite automatisch eine rowid mitführt, ist es guter Programmierstil, eine Spalte mit der Android-Konstante anzulegen und diese als INTEGER PRIMA-RY KEY (evtl. AUTOINCREMENT) zu deklarieren, was zu einer Kopie der rowid führt.

Guter Programmierstil ist es auch, die Datenbank für jedes Schreiben zu öffnen und danach zu schließen, da Android den Lifecycle immer unterbrechen könnte. Wie beim Threading sollte dies zwischen dem Status onResume und onPause passieren. Die Helper-Klasse SQLite Open Helper muss dafür abgeleitet werden. In dieser wird definiert, wie die Datenbank erstellt und bei einer Versionsänderung (der Applikation) migriert wird – das kann z. B. als innere Klasse in einer generischen Storage-Komponente implementiert werden. Da die Dalvik-VM finale, statische Strings optimiert, sollten Feldnamen in dieser generischen Komponente, wenn möglich, als Konstanten gehalten werden (Listing 1). In Abbildung 2 finden Sie die Zugriffsreihenfolge des eben besproche-nen Beispiels.

Bleibt noch zu erwähnen, dass mitgelieferte Daten-banken im Assets-Ordner maximal ein MB groß sein können, man sollte daher überlegen, diese als Raw-Typ auszuliefern. In jedem Fall muss die Datenbank zuerst an einen beschreibbaren Ort kopiert werden, beispiels-weise die SD-Karte.

Datenspeicherung in der CloudDatenspeicherung in der Cloud, vorangetrieben vor al-lem von Amazon S3 und beliebten Apps wie Dropbox, ist ein weiterer Ansatzpunkt zur Integration von mobilen und webbasierten Anwendungen. Auch Google hat in den Labs einen Cloud-Speicher zur Verfügung gestellt. Mit Android 2.2 wurde ein Backup-Service eingeführt, über den Anwendungen direkt auf die Cloud gespeichert werden können. Ende Mai hat Google eine Kooperation mit VMware, zu denen auch SpringSource als Hersteller der Spring-Framework-Familie gehört, angekündigt, in der es um stärkere Integration der Plattformen geht [2].

Abb. 2: Zugriffsreihenfolge des Beispiels

Datenspeicherung

www.android360.de1 | 2010 ANDROID360

1

104

2 3

Die Tatsache, dass sowohl S3 als auch Google REST-In-terfaces bereitstellen, zeigt auch die Anforderung, weiter lokale Anwendungen einsetzen zu wollen. Gleichzeitig sollen diese Anwendungen aber möglichst einfach Daten persistieren und auf verschiedenen Geräten und Formen bereitstellen können.

NoSQL-Datenbankkonzepte [3] werden hier aufgrund ihres einfachen Datenmodells bei gleichzeitig hoher Leistung auf verteilten Systemen gerne eingesetzt. Ihre vielfältigen Ausprägungen sind etwa Tabellen wie Ama-zons BigTable oder Key/Value Stores wie Redis. Letzte-res gehört ebenfalls zu VMWare/SpringSource, ebenso wie die Datenmanagementlösung GemStone – jetzt ge-nannt GemFire. So kann davon ausgegangen werden, dass die transparente Datenspeicherung mittelfristig in

diese Plattformen integriert wird, und damit eventuell auch in die Google-Dienste, allen voran der AppEngine und der Android-Plattform. Dies mag ein Grund dafür sein, warum Oracle inzwischen Google und Android als direkten Konkurrenten sieht.

Will man auf eine Cloud-Datenbank zugreifen, sollte im Sinne schneller Ergebnisse RESTful HTTP als Pro-tokoll verwandt werden. Dies ist die von den meisten Cloud-Anbietern favorisierte Lösung, insbesondere im Zusammenspiel mit JSON-Datensätzen, wie es beispiels-weise CouchDB zeigt. Im Fall einer weborientierten Ar-chitektur (WOA) wird die Lösung auch von Gartner im wahrsten Sinne des Wortes „gehypt“.

Zur Sicherheit wird oft das Amazon-Prinzip mit HMAC SHA1 verwendet, das unter Android im Rah-

HTML 5

auch bei lokalen anwendungen auf mobilen geräten ist htML nicht wegzudenken, so wird es beispielsweise für Dashboard Widgets oder auch in htML-renderern innerhalb von applikationen verwendet. Letzteres ist eine gern verwen-dete cross-plattform-strategie, z. B. bei sencha.Die unmöglichkeit lokaler speicherung ist ein hauptnachteil von htML-basierten Webapplikationen. google gears ist ein häufig eingesetztes Browser-plug-in, um diese Beschränkun-gen, insbesondere im Zusammenspiel mit dem google Web toolkit, zu umgehen. anfang 2010 hat google bekanntge-geben, gears zugunsten der speichermöglichkeiten in htML 5 auslaufen zu lassen [5]. in diesem neuen standard sind sowohl ein lokaler Key/Value store vorgesehen als auch Möglichkeiten zur implementierung von Offlineanwendun-gen über cache-steuerung. im gegensatz zu pcs ist der Browsermarkt bei smartphones einigermaßen standardisiert – fast alle hersteller setzen WebKit ein. Damit ist die Basis geschaffen, htML 5 erheblich schneller als auf dem pc als standard etablieren zu können. Mit android 2.2 ist die WebKit engine nun mit dem schnellen V8 Javascript ausge-stattet, was noch schnellere anwendungen erlaubt.

Listing 1

public synchronized void storeNameMap(String name, byte[] binaryJsonArray) { if(TextUtils.isEmpty(name)) throw new IllegalArgumentException(); try { database = mySqliteHelper.getWritableDatabase(); Date currentDate = new Date(); ContentValues values = new ContentValues(); values.put(DATABASE_COL_BLOBFIELD, binaryJsonArray); values.put(DATABASE_COL_NAME, name); values.put(DATABASE_COL_TIME, dateFormatter.format(currentDate)); database.replaceOrThrow(DATABASE_TABLE, null, values); } catch (Exception e) { closeDatabase(); throw new StorageException(e);… class MySQLiteHelper extends SQLiteOpenHelper { public MLsoSQLiteHelper(Context context) { super(context, DATABASE_NAME, null, DATABASE_VERSION); }

@Override public void onCreate(SQLiteDatabase db) { db.execSQL("CREATE TABLE IF NOT EXISTS " + DATABASE_TABLE + " (" + BaseColumns._ID + " INTEGER PRIMARY KEY ASC AUTOINCREMENT, " + DATABASE_COL_NAME + " TEXT NOT NULL UNIQUE, " + DATABASE_COL_BLOBFIELD + " BLOB, " + DATABASE_COL_TIME + " TEXT NOT NULL);"); Log.d(DATABASE_LOG_TAG, "Created table " + DATABASE_TABLE + " in database " + db.getPath()); }

@Override public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) { // TODO: Implement actual version checking and data migration db.execSQL("DROP TABLE IF EXISTS " + DATABASE_TABLE); onCreate(db); }

MEAP

Zur plattformübergreifenden entwicklung werden bei großen projekten häufig so genannte Mobile enterprise application platforms (Meap) eingesetzt. Dazu können auch codege-neratoren wie appcelerator gezählt werden. hier stehen oft weitaus umfangreichere persistenzschichten zur Verfügung.im weiteren sinne einer Meap sei hier auch das BlackBerry api erwähnt, das mit seinen Möglichkeiten der Datensyn-chronisation zum Desktopmanager weit über syncML etc. hinausgeht. Zudem steht hier das Mobile Data api zur Verfügung, das den Zugriff auf intranetfunktionen erlaubt. einer der Marktführer in diesem gebiet, sybase [6], wurde kürzlich von sap übernommen, um die sOa-strategie der Walldorfer z. B. mit Mobile crM zu vervollständigen [7].

Datenspeicherung


3 2 1

105

men der BouncyCastle-Bibliothek verfügbar ist. Es ist ratsam, eine generische HTTP-Schicht mit Threads zu implementieren (gestartet in onResume) und über diese eine transparente Storage-Schnittstelle anzubinden. Da-rüber kann ein mehrstufiger Web Service Cache imple-mentiert werden, um z. B. die aktuellsten Daten auch lokal vorzuhalten und bei Netzausfällen eine Grund-funktionalität bereitstellen zu können. Dabei sollte al-lerdings der Nutzer über gegebenenfalls veraltete Daten informiert werden.

Um auf Datentransformation zu verzichten, kann ein Blick in die der Serverseite zugrunde liegenden Tech-nologie nützlich sein: Es ist möglich, statt SQLite auch andere Datenban-ken in die eigene An-wendung einzubetten. Beliebt sind beispielswei-se db4o und Perst, die nicht nur Integration in die Anwendung, sondern auch direkte objektorientier-te Speicherung erlauben. Zwar gibt es bisher nur we-nige Standardimplementierungen von Java-basierten Datenbanken unter Android, etwa die Oracle Berkeley DB, theoretisch wäre dies aber für weitaus mehr Sys-teme möglich. Die in Java 6 integrierte Derby-Daten-bank etwa könnte nach Android portiert werden. Viele Cloud-Systeme nutzen JSON als Standardformat, dies kann auch lokal eingesetzt werden.

Storage auf anderen PlattformenUnter anderen Plattformen, etwa MeeGo, steht eine große Auswahl von Datenbanken zur Verfügung. Dazu werden oft proprietäre Java-Mobile-Bibliotheken an-geboten, was den Entwicklungsprozess komplizieren kann. Dafür hat man aber den Vorteil lokaler Transakti-onssicherheit, soweit notwendig, und kann die umfang-reichen Funktionen relationaler Datenbanken nutzen. Es sollte auch nicht unerwähnt bleiben, dass Oracles Strategie [4] scheinbar hin zur Java SE mit JavaFX oder Flash/Air als Frontend geht, wodurch die Nutzung noch umfangreicherer Datenbanken möglich wird. Schließ-lich ist Oracles Berkeley DB bereits verfügbar und AFP Forms lange als Multiplattformlösung etabliert.

Doch nicht nur bei Android gibt es Entwicklungen: In naher Zukunft wird der neue Standard MIDP 3 für Java ME erwartet, der insbesondere auch bei sicherem Stora-ge Vorteile bringen wird. MIDP 3 wird ein umfangrei-ches Sicherheitsmodell mit detailierten Berechtigungen und Zertifikatsschutz inklusive Revocation implementie-ren. Letzteres ist in Android 2.2 durch das Lizenzsystem realisiert worden. Die Nutzung signierter MIDlets ist insbesondere hinsichtlich der Datenverschlüsselung und der Auslieferung von Geräten mit installierten Firmen-zertifikaten interessant. Mit MIDP 3 wird auch HTTP 1.1 vollständig unterstützt werden, was die vollständige Nutzung von REST-konformen Schnittstellen möglich macht. Zuletzt wird die Inter-Midlet-Kommunikation

eingeführt, mit der es möglich sein wird, Daten zwischen parallel laufenden Midlets gezielt auszutauschen.

Abschließend sei noch zu erwähnen, dass mit MIDP der ISO-Zeichensatz durch UTF-8 ersetzt wird, was bei Byte Stores wie dem RMS aber auch bei Berkeley DB und natürlich anwendungsintern verwalteten Dateien zu beachten ist.

FazitDie Notwendigkeit der Speicherung von Daten auf mo-bilen Geräten steht außer Frage. Statt der klassischen PIM- und Kontaktdaten werden Persistenzinformatio-

nen und Web-Service-Daten sowie Cloud Storage immer wichti-ger. Den Anwendungs-entwickler stellt dies vor die Herausforderung, eine Geschäftslogik so zu implementieren, dass

verschiedene Arten der Datenhaltung möglich sind – und deren Synchronisation untereinander. Zustandslose, eventbasierte Kommunikation nach REST ist hier eine Lösung. Das sollte uns nur Recht sein: Denn so werden Anwendungen endlich „pervasive“ und „mobile“, statt nur „ubiquitous“.

Zur plattformübergreifenden Entwicklung werden bei großen Projekten häufig so genannte Mobile Enter-prise Application Platforms (MEAP) eingesetzt. Dazu können auch Codegeneratoren wie Appcelerator gezählt werden. Hier stehen oft weitaus umfangreichere Persis-tenzschichten zur Verfügung.

Im weiteren Sinne einer MEAP sei hier auch das Black-Berry API erwähnt, das mit seinen Möglichkeiten der Datensynchronisation zum Desktopmanager weit über SyncML etc. hinausgeht. Zudem steht hier das Mobile Data API zur Verfügung, das den Zugriff auf Intranet-funktionen erlaubt. Einer der Marktführer in diesem Ge-biet, Sybase [6], wurde kürzlich von SAP übernommen, um die SOA-Strategie der Walldorfer z. B. mit Mobile CRM zu vervollständigen [7].

Links & Literatur

[1] http://developer.android.com/guide/topics/data/data-storage.html

[2] http://www.vmware.com/company/news/releases/vmware-google.html

[3] Java Magazin 7/2010

[4] http://jaxenter.com/comment-oracle-on-the-road-to-write-once-run-anywhere%20-10209.html

[5] http://gearsblog.blogspot.com/2010/02/hello-html5.html

[6] http://www.gartner.com/DisplayDocument?doc_cd=172728

[7] http://blogs.sybase.com/ithain/?p=1532

Jan Peuker entwirft und entwickelt bei accenture technology so-lutions Java-, ria- und mobile anwendungen. er hat sein Diplom in Multimediainformatik an der hs augsburg und uni Melbourne zum thema plattformübergreifende entwicklung von mobilen an-wendungen geschrieben.

Die notwendigkeit der spei-cherung von Daten auf mobi-len geräten steht außer Frage.

BonusartikelRegistrieren Sie sich unter www.android360.de/bonus und laden Sie sich kostenlos folgende Artikel herunter:

Android Remoting von Gregor Roth

Die zunehmend bessere Versorgung mit mobilen, breitbandigen Datendiensten sowie die immer leistungsfähigeren Endgeräte schaffen immer bessere Voraussetzungen für die Entwicklung hochwertiger, mobiler Apps auf Basis verteilter Anwendungs-architekturen. Typischerweise kommunizieren solche Apps über den RESTful-HTTP-Ansatz mit serverseitigen Diensten, um bestimme Use Cases umzusetzen. Dieser Artikel beleuchtet unterschiedliche Ansätze für die clientseitige Implementierung der Serverkommunikation.

Caching-Content-Provider von Ronan Schwarz

Jeder, der mobile Anwendungen entwickelt, wird sich früher oder später mit Caching beschäftigen müssen. Eine Applikation, die Daten von einem Server bezieht, sei es vom Internet oder einem VPN, profitiert in nahezu allen Fällen von einem Cache. Das Android-Framework bietet mit Content-Providern eine einfache und leistungsfähige Möglichkeit, das Problem zu lösen.

Impressum

Please hold the Line: Warum JavaFX nicht ins Rollen kommt iOS, die Vierte: Neues vom Marktführer Im Zeichen der Super-Apps: Integration mit dem Posteingang

Querschau

InserentenCREATE OR DIE 25www.createordie.de

Business Technology Days 2010 69www.btdays.de

Business Technology Magazin 67www.bt-magazin.de

Eclipse Magazin 85www.eclipse-magazin.de

Entwickler Akademie 75www.entwickler-akademie.de

Entwickler-Forum 31www.entwickler-forum.de

Entwickler Magazin 63www.entwickler-magazin.de

entwickler.press 81www.entwickler-press.de

InMobi 11www.inmobi.com

IT-Republik 27www.it-republik.de

Java Magazin 41www.javamagazin.de

JAXenter 107www.jaxenter.de

meat* – concept and design 17www.meat-frankfurt.com

mobile media solutions 108www.m-mediasolutions.de

Mobile Technology 2mobile360.de/MobileTechnology

Mobile360.de 5www.mobile360.de

WebTech Conference 2010 49www.webtechcon.de

Ausgabe 5.2010 | www.entwickler-magazin.de

Verlag:Software & Support Media GmbH

Anschrift der Redaktion:Android360 Software & Support Media GmbH Geleitsstr. 1460599 Frankfurt am MainTel.: +49(0) 69 630089-0Fax: +49(0) 69 630089-89E-Mail: [email protected]: www.android360.de

Redaktion: Thomas Wießeckel, Lukasz Konieczny

Chefin vom Dienst/Leitung Schlussredaktion: Nicole BechtelSchlussredaktion: Ella Klassen, Katharina Klassen, Frauke Pesch

CD/DVD-Erstellung: Özkan Peksan, Daniel Zuzek

Leitung Grafik/Produktion: Jens MainzLayout, Titel: Daniela Albert, Pobporn Fischer, Melanie Hahn, Karolina Gaspar, Maria Rudi, Franziska Sponer, Patricia Schwesinger

Autoren dieser Ausgabe: Frank Angermann, Thomas Bornschlegel, Markus Braun, Miriam Brückner, Tobias Eble, Andreas Frey, Kay Glahn, Markus Junginger, Dominik Khan, Christian Küster, Sven Mohr, Eray Özmü, Jan Peuker, Marc Reichelt, Heiko Roß-nagel, Heiko Sasse, Jan Schlink, Markus Stäuble, Saban Ünlü, Lars Vogel, Jan Zibuschka

Bildnachweis: S. 83 mit freundlicher Genehmigung der LEGO GmbH

Pressevertrieb:DPV NetworkTel.: +49 (0) 40 378456261 · Web: dpv-network.de

EinzelverkaufspreisDeutschland 12,80 �Österreich 14,70 �Luxemburg 14,90 �Schweiz 25,60 sFr

Druck: PVA, Landau

© 2010 für alle Beiträge.Alle Rechte, auch für Übersetzungen, sind vorbehalten. Reproduktionen jeglicher Art (Fotokopie, Nachdruck, Mi-krofilm oder Erfassung auf elektronischen Datenträgern) nur mit schriftlicher Genehmigung des Verlags. Jegliche Software auf der CD-ROM unterliegt den Bestimmungen des Herstellers oder der zuständigen Organisation. Eine Haftung für die Richtigkeit der Veröffentlichungen kann trotz Prüfung durch die Redaktion vom Herausgeber nicht übernommen werden. Honorierte Artikel gehen in das Verfügungsrecht des Verlags über. Mit der Übergabe der Manuskripte, Abbildungen eventueller Quellcodes an den Verlag erteilt der Verfasser dem Herausgeber das Exklusivitätsrecht zur Veröffentlichung. Für un ver langt eingesandte Manuskripte, Abbildungen oder Quellcodes keine Gewähr.

Alle Markennamen sind in der Regel eingetragene Warenzeichen der entsprechenden Hersteller oder Organisationen.

Mobile Welten: Android-Apps aus dem Baukasten Multi-touch: Revolution oder Evolution Multi-touch for Java: Ein OS-Multi-touch-Framework für Java

Ausgabe 10.2010 | www.javamagazin.de

Ausgabe 1.2010 | www.android360.de

Des Androids bester Freund: Hat Java noch Biss? Rückkehr der P2P-Netzwerke: Synchronisierung per Netz Neue Features: Advantage Database Server 10