Der interessante Gedanke an dem Vergleich ist aber die Tatsache, dass Android Entwickler bei der Portierung von existierenden Android Apps sicher einen überschaubaren Aufwand haben und mit ein wenig Glück größere Teile der existierenden Codebasis 1:1 verwenden können. Vor allem bei der Neuentwicklung von Anwendungen, die auf beiden Plattformen laufen sollen, kann bei der Entwicklung der eigentlichen Programmlogik darauf geachtet werden, dass nur APIs verwendet werden, die sowohl auf Android als auch auf dem Kindle vorhanden sind.

Bei Apps ist es natürlich nicht so einfach ein “Kapitel” zum Testen zur Verfügung zu stellen. Aber hier muss das Rad nicht unbedingt neu erfunden werden. Bei Apples AppStore findet man derzeit verschiedene Ansätze, eine Testversion zur Verfügung zu stellen.

Kostenlose Lite-Version: Bisher gefühlt die häufigste Variante, um eine kostenlose Testversion anzubieten. Der Entwickler erstellt eine abgespeckte Version seiner Anwendung und bietet diese kostenlos an. Diese kann man dann kostenlos herunterladen und zeitlich unbegrenzt testen. Gefällt einem die Anwendung, dann kann man sich die Vollversion kaufen. Meines Erachtens kann man dieses Modell nur begrenzt auf den Kindle übertragen. Kostenlose Apps dürfen für den Kindle maximal ein Megabyte groß sein. Damit darf eine Testversion auch maximal ein Megabyte groß sein. Eine Möglichkeit, diese Einschränkung ein wenig zu entschärfen wären Testversionen, bei denen der Kunde nur für den entstehenden Traffic bezahlt. Aber mal ehrlich: auch wenn es sich hierbei nur um kleine Beträge handelt, bezweifle ich dass viele User für Demos Geld bezahlen. Eine weitere Möglichkeit wäre es, keine kostenlosen Lite-Versionen, sonderen normale und Pro-Versionen anzubieten. In der Praxis sähe das so aus: ich kann eine kostenpflichtige, aber sehr günstige Version einer Anwendung kaufen. Diese Version hat einen eingeschränkten Funktionsumfang, aber sie ist dauerhaft benutzbar. Gefällt mir die Anwendung, so besteht die Möglichkeit eine Pro-Version mit erweitertem Funktionsumfang kaufen. Dieses Vertriebskonzept kennt man von Desktop Software wie z.B. Photoshop. Für den kleinen Geldbeutel kann man sich Photoshop Elements kaufen, mit dem man schon einiges Anfangen kann. Reicht einem dieser Funktionsumfang nicht aus, so gibt es für deutlich mehr Geld das richtige Photoshop.

Werbefinazierte Version: Die Anwendung ist kostenlos und mit vollem Funktionsumfang erhältlich, blendet aber Werbung ein, um sich zu finanzieren. Optional gibt es auch eine Pro-Version mit gleichem Funktionsumfang, aber ohne Werbung. Amazon gestattet keine Werbung in Kindle Apps. Daher scheidet diese Variante von vornherein aus.

Vollversion durch In-App-Purscase: Wurde im Apple AppStore erst vor ein paar Monaten eingeführt. Die Idee ist simpel: eine Anwendung bietet die Möglichkeit, über eine Art internen Store zusätzliche Inhalte zu kaufen. Das können beispielsweise Levels für ein Spiel, Karten für eine Navigationslösung oder aber auch die Vollversion einer Demo sein. Der KDK API fehlt bisher die notwendige Schnittstelle, um direkt aus einer Anwendung heraus etwas zu kaufen. Daher scheidet diese Möglichkeit erstmal auch aus. Vom Prinzip ähnelt dieser Ansatz aber stark den eingangs erwähnten Probekapiteln.

Natürlich gibt es neben diesen drei Vertriebsmodellen noch weitere abseits den großen AppStore:

Zeitlich begrenzte Testversion: Eine Testversion ist nach dem ersten Start nur für eine begrenzte Anzahl von Tagen lauffähig Sehr beliebt bei Shareware auf Mac und PC.

Begrenzte Anzahl von Starts: Ähnlich wie bei der zeitlich begrenzten Testversion: eine Anwendung lässt sich z.B. nur 10x starten.

Durch die Größenbegrenzung von einem Megabyte für kostenlose Apps denke ich, dass sich beim Kindle App Store eine eigene Kultur für Testversionen bilden wird beispielsweise bei Apples AppStore. Für kleine Anwendungen, die unter einem Megabyte liegen ist es durchaus denkbar, dass eine Testversion angeboten wird. Ich glaube aber nicht, dass sich viele Entwickler die Mühe machen und aus einer 100 MB Anwendung eine Mini-Testversion extrahieren.

Eine Alternative dazu wäre natürlich eine offizielle Möglichkeit von Amazon, kostenlose Testversionen jeder Größe zu verteilen. Ich denke aber, dass dies aufgrund der Traffickosten und der anderen ausstehenden Features (Audio API,…) erstmal nicht so schnell kommt. Aber ich lasse mich natürlich gerne überraschen.

Ähnlich wie bei iPhone Apps hat ein Kindlet beim beenden (wird z.B. durch betätigen der Home Taste ausgelöst) fünf Sekunden Zeit, um Ressourcen freizugeben und beispielsweise den aktuellen Zustand zu speichern.

Zusätzliche APIs – aber mit Einschränkungen

Die veröffentlichte Dokumentation erwähnt auch, dass neben dem bereits in der FAQ erwähnten Java PBP noch drei weitere API von Amazon zur Verfügung gestellt werden. Es handelt sich hierbei um den Xerces XML Parser , JSON.simple sowie log4j. Amazon weist allerdings daraufhin, dass alle Kindlets in der Sandbox laufen und es daher Funktionen in den APIs gibt, die nicht bei Kindlets verwendet werden dürfen, bzw. können. Um was es sich dabei genau handelt ist bisher nicht bekannt. Ähnliche Einschränkungen wird es aber sicherlich auch bei anderen 3rd-Party Bibliotheken sowie eigenem Code geben. Ich denke, dass Amazon demnächst noch entsprechende Guidelines veröffentlichen wird.

Die Packages des KDK im Überblick

• com.amazon.kindle.kindlet beinhaltet das Kindlet Interface, von das jede Anwendung implementieren muss sowie den KindletContext, der die Laufzeitumgebung eines Kindlets repräsentiert und selbigem Zugriff darauf ermöglicht.
• com.amazon.kindle.kindlet.event enthält verschiedene Konstanten für die Sondertasten des Kindle
• com.amazon.kindle.kindlet.net stellt verschiedene Interfaces für den Netzwerkzugriff bereit. Es werden allerdings nur das HTTP und das HTTPS Protokoll unterstützt. Daher ist es z.B. nicht möglich, einen Email Client zu entwickeln. Wobei das mit den 100 kB Traffic im Monat sowieso problematisch geworden wäre.
• com.amazon.kindle.kindlet.security enthält ein Interface für den Zugriff auf den SecureStorage. Dabei handelt es sich um einen sicheren Speicherplatz, den ein Kindlet nutzten kann, um sensitive Daten wie z.B. Logindaten zu speichern. Amazon weist darauf hin, dass der SecureStorage nur für kleine Datenmengen gedacht ist und seine Performance bei größeren Datenmengen nicht wirklich gut ist.
• com.amazon.kindle.kindlet.ui.* In diesem Package sowie seinen drei Subpackages border, image und pages befinden sich die Interfaces für die Erzeugung grafischer Oberflächen auf dem Kindle. Die Kindle GUI Komponenten basieren alle auf AWT und laut Amazon sollte es kein großes Problem darstellen, vorhanden AWT oder Swing Komponenten zu portieren. Es wird auch noch einmal auf die besonderen Eigenschaften des EInk Displays hingewiesen und in dem Zusammenhang daran erinnert, dass man im Gegensatz zu einer AWT oder Swing Anwendung beim Repaint einer Komponente nur den kleinst möglichen Teil neu zeichnen lassen soll.
• com.amazon.kindle.kindlet.util enthält einen Kindle-spezifischen Ersatz für java.util.Timer sowie java.util.TimerTask

• Kindle Anwendungen dürfen zwei APIs verwenden. Zum einen die aus der mobilen Javaentwicklung bekannte Java version 1.4 Personal Basis Profile (PBP) APIs for mobile devices und zum anderen Amazons Kindle API, die unter anderem Zugriff auf das Kindle UI, JSON und XML Parser, HTTP und HTTPS Networking, Secure Storage sowie andere Kindle-spezifische Features mitbringt. Weitere Features wie Audiosupport und Zugriff auf das Dateisystem sind für zukünftige Versionen der Kindle API versprochen.
• Es soll möglich sein, vorhandene J2ME Anwendungen auf den Kindle zu portieren.
• Das KDK ist kann mit beliebigen Java Entwicklungstools wie Eclipse, IntelliJ oder Netbeans verwendet werden.
• Es ist möglich, fremde Bibliotheken zu verwenden. Die Verantwortung, auf die Kompatibilität der entsprechenden Lizenzen zu achten liegt beim Entwickler.
• Entwickelte Anwendungen können entweder in einem bereitgestellten Kindle Simulator oder auf dem Kindle selbst getestet werden. Dazu können bis zu drei Kindle bei Amazon als Testgeräte registriert werden.
• Kindle Anwendungen sind nur auf dem Kindle selbst lauffähig. Eine Unterstützung für Kindle for PC oder der Kindle iPhone App gibt es derzeit nicht. Vor allem bei der iPhone App glaube ich nicht, dass dies von Apple erlaubt werden würde.
• Die Anwendungen werden via DRM geschützt.

Ich werde nun einmal einen Blick auf die veröffentliche Dokumentation der Amazon API werfen und darauf warten, dass mein Beta Account freigeschalten wird.

Irgendwas muss man doch aber mit diesen 100 kB anstellen können! Ein Anwendungsfall, der mir einfällt, wären z.B. (Brett-)Spiele, die einen Highscore an einen Server übertragen. Oder beispielsweise Spiele, die sich jeden Monat 100 kB an neuen Spieldaten (Quizfragen, Rätsel, Schachaufgaben) herunterladen. Vor allem Schachaufgaben können sehr kompakt in wenigen Kilobyte beschrieben werden. Neben den eigentlichen Nutzdaten muss man natürlich auch noch bedenken, dass je nach Übertragungsprotokoll (HTTP,…) auch noch ein bisschen Traffic als Overhead verbraucht wird.

Irgendwie erinnert mich das an längst vergangene Zeiten, in denen Speicher und Traffic ein sehr kostbares gut waren und man sich einer Menge Tricks und Kniffe bediente, um dennoch Unmögliches möglich zu machen. Ich bin gespannt, ob sich beim Kindle eine ähnliche Mentalität entwickeln wird, um die technischen Beschränkungen Eigenheiten des Kindle zu umschiffen.

Wie finanziert Amazon den ganzen Freitraffic eigentlich? Angeblich kostet jedes MB ja $0,15. 100 kB wurden dann also mit $0,015 pro App und Monat zu buche schlagen. Das ist natürlich im einzelnen nicht sehr viel, wenn man aber von Millionen von Kindle und vielleicht einem Vielfachen an Apps ausgeht, kommt da schon ein ordentliches Sümmchen zusammen. Bei einer Million Apps, die das Datenkontingent pro Monat ausreizen kommt man schon auf $15.000. Mich würde interessieren was da alles in die Mischkalkulation mit hineinspielt. Nur die Erlöse aus dem Verkauf von Kindle, Kindlecontent sowie Kindle Apps? Oder sieht Amazon das auch ein wenig als strategischen Invest, um seine Stellung auf dem eReadermarkt zu festigen?

• Das KDK wird für die drei großen Plattformen OS X, Linux und Windows erscheinen
• Die Entwicklung wird voraussichtlich in Java erfolgen (In diesen Screenshot erkennt man ein geöffnetes Eclipse)
• Kindle Apps lassen sich in drei verschiedenen Preismodellen vertreiben:

1. Kostenlose Apps müssen kleiner als 1 MB sein und dürfen monatlich nicht mehr als 100 kB an Daten über das Mobilfunknetz übertragen
2. Kostenpflichtige Apps werden müssen einmal vom Kunden gekauft und dürfen ebenfalls nicht mehr als 100 kB an Daten pro Monat übertragen
3. Monatliche Abonnements müssen wie der Name schon sagt einmal pro Monat bezahlt werden

• Kostenplichtige Apps dürfen maximal 100 MB groß sein. Bis zu einer Größe von 10 MB werden sie via Whispernet übertragen, was darüber hinaus geht muss am Rechner heruntergeladen und anschließend per USB Kabel auf den Kindle kopiert werden
• Amazon behält vom Kaufpreis 30% als Gebühr, 70% bleiben beim Entwickler
• Von diesen 70% werden aber nochmals $0,15 pro übertragenem MB dem Entwickler in Rechnung gestellt, um den Datentransfer zu bezahlen. Amazon weist darauf hin, dass für den Kindle ja keine monatlichen Gebühren für den Datentransfer vom Kunden entrichtet werden und der anfallende Traffic ja auch irgendwie bezahlt werden muss. Nach der 10 MB Grenze kommen da pro App nochmals maximal $1,50 zu Amazons Provision dazu
• Wie man es von anderen Plattformen wie z.B. vom iPhone kennt sind einige Dinge kategorisch ausgeschlossen. Dazu gehören VoIP, Werbung, anstößige Inhalte, Schadcode ,das Sammeln von Nutzerinformationen ohne dessen ausdrückliche Zustimmung sowie die Nutzung der Marke Kindle im Zusammenhang mit den eigenen Apps. Außerdem sind keine Anwendungen erlaubt, die bereits existierende Funktionen des Kindle nachbilden.