Öfter mal was Neues: BlackBerry

(zu Folge 3)

Ich konnte mich, knapp ein Jahr nach dessen Launch, endlich dazu durchringen, mein Windows Phone gegen ein BlackBerry Q10 einzutauschen. Die Entscheidung ist mir gleichermaßen leicht und schwer gefallen, deshalb: Was waren die Faktoren, was die Alternativen, was der Grund?

Vorweg dazu: Das perfekte Smartphone gibt es nicht. Das eine Killerargument für oder gegen eine Plattform ebensowenig. Deshalbe verzichte ich auf eine Rangliste der “Für und Wider”s, und stelle meine Beweggründe nach Plattform sortiert vor:

Der Grund

Bisher hatte ich, wie gesagt, ein Windows Phone (WP). Genauer gesagt: Ein LG E900 mit Windows Phone 7.8. Dazu bin ich eher zufällig gekommen, ich habe es zum Launch von WP gewonnen 🙂 ‘Geschenktem Gaul schaut man nicht in’s Maul, und WP sah echt vielversprechend aus, deshalb habe ich gewechselt. Obwohl ich mit meinem vorherigen Handy ziemlich zufrieden war, dazu später mehr.

Leider sieht WP immer noch “nur” vielversprechend aus, zumindest unter v7.x hat sich wenig getan über die Jahre. Das ist beim Nachfolger WP8 ein Stück weit anders, aber Microsoft hat viele Besitzer eines WP7 mit der Entscheidung verprellt, das Update für die “alte” Plattform nicht anzubieten, und viele Features auch nicht nachzureichen – darunter Grundlegendes wie CalDAV-Support, Rotation-Lock, lernende Autokorrektur (ich meine nicht neue Wörter, sondern Häufigkeit der Nutzung von Wörtern), oder auch nur custom Klingeltöne. Richtig gelesen: Was bei anderen Systemen seit x Jahren zur Grundausstattung gehört, verweigert M$ ausgerechnet seinen Early Adopters. Das war der primäre Grund für meinen Plattformwechsel.

Der konkrete Anlass allerdings war, dass mein WP langsam den Geist aufgibt. Es geht oft aus, manchmal im Minutentakt. Schade, denn sogar der Akku hält noch länger durch als bei manchem neuen Smartphone – was sicherlich dem “langsamen” Prozessor und der “geringen” Pixeldichte auf “kleinem” Display geschuldet ist.

Also, who’s next?

iPhone?

Das iPhone ist der Platzhirsch, keine Frage. Und dabei so angenehm handlich – aber auch abstrus teuer. Es ist mir absolut schleierhaft, wie jemand so einen Haufen Geld für ein Handy ausgegeben kann. Noch dazu für eins, das so schnell und oft kaputt geht. Raus.

Die Entscheidung war leicht.

Android?

Ähnlich attraktives Ökosystem, dabei deutlich günstiger. Leider auch (oft) deutlich größer und unhandlicher, außerdem ist ein Google-Account Pflicht. Und Google kommt mir nicht auf’s Handy. Wenn wir eins aus der NSA-Affäre gelernt haben, dann, dass Datensparsamkeit, Verschlüsselung und Dezentralisierung wichtig sind. Mindestens Punkt 1 und 3 steht Google direkt entgegen. Raus.

Die Entscheidung war leicht.

Jolla?

Kurz habe ich über das Jolla nachgedacht: Ein unabhängiges, Open-Source-Betriebssystem, aus Europa, auf Unix-basis, stylisches UI, konsequent auf Gestensteuerung ausgerichtet. Leider auch nicht billig, zumindest für die Hardware und das begrenzte Angebot an Apps. OK, man kann Android-Apps installieren, trotzdem fehlen mir konkrete Erfahrungsberichte und ein Hands-on im örtlichen Saturn (oder irgendwo). Bis auf Weiteres raus, wird aber beobachtet.

Die Entscheidung war nach einer Woche oder so auch leicht 😉

Windows Phone 8?

Ich mag WP immer noch total gerne, ein WP8-Handy war bis zum Schluss die direkte Alternative zum BlackBerry. Das UI-Konzept funktioniert super, und ist insofern sogar stylisch, als dass es klug minimalisiert wurde. Klug, weil ergonomisch. Es funktioniert super – bis es in die Apps geht. Da nervt sie sehr schnell; wer mal eine App geschlossen hat, weil nie ganz klar ist, wohin der (eine) “Zurück”-Button nun navigiert, weiß, was ich meine.

Viele App-Entwickler kommen offensichtlich auch nicht damit zurecht, den Content in den Mittelpunkt der Anwendung zu stellen, bzw. scheitern daran, dass ein 1:1 Klon von anderen Plattformen nicht “funktioniert”. Vielleicht kommt hier ja noch mehr, wenn die Plattform sich (noch?) weiter verbreitet.

Bis es so weit ist, habe ich aber keine Lust mehr zu warten, nach 3 ½ Jahren ist meine Geduld dann mal erschöpft. Die Entscheidung war aber nicht leicht, zumal die Geräte vergleichsweise günstig sind.

BlackBerry?

Man muss erst mal wissen, dass ich vor dem WP ein Nokia E71 hatte, mit dem ich sehr zufrieden war. Das hatte eine Tastatur, und die war super. Auf dem WP vertippe ich mich, seitdem ich es habe und bis heute. Leider nimmt so eine Tastatur auch Platz weg, sonst wäre ich schon lange umgestiegen. Das Verhältnis von physischer Tastatur zu Bildschirm bleibt also zu testen.

dilbert

Das BB ist dafür gemacht, alles schnell und effizient erledigen zu können, nicht dazu, bsplw. Einsteigerhandy zu sein. Vieles bedient sich am Besten über Gestenund/oder Kurzbefehle und/oder Tastenkürzel – ja, Tastenkürzel. Wo die schon mal da sind!? 🙂 Aber für meine Frau wäre es ob der Kürzel und Gesten nichts.

Bei der Effizienz hilft, dass man alles customizen kann. Auch das wäre nichts für meine Frau, aber ich mag es, wenn ich Quick Settings ein- und ausblenden kann, ihre Reihenfolge ändere, … oder dass ich Quick Settings habe, schönen Gruß, Microsoft!

Auf dem BlackBerry OS v10 kann man ebenfalls Android-Apps installieren, damit dürfte das Angebot größer sein als bei WP8. Es gibt CalDav- und CardDav-Support. Die Sprachqualität ist super, wegen der zusätzlichen Mikrofone, die Umgebungsgeräusche rausfiltern. Man kommt ohne Probleme per USB auf’s Dateisystem, und zwar in beide Richtungen: Ich kann vom Handy aus meinen Rechner browsen, was bsplw. bei der Installation von Android-Apps hilft. OK, die hauseigene Maps-App ist Mist (kein ÖPNV!?), aber es gibt gute Ersatz-Apps. Das Gerät ist sauschnell und hatte zum Start mit die höchste Pixeldichte – bei inzwischen “nur” noch knapp über 300 €.

Damit war die Entscheidung gefallen, aber sie war schwer – nun muss BB sich beweisen!

Android Kalender: File-Import?

Anforderung an eine Webseite mit Event-Daten:

Clicking the button adds the event to the phone calendar.

Mangels weiterer Anforderungen gehe ich mal von iPhone, Android, idealerweise Windows Phone als Zielplattform aus. Gehe ich also zur Wikipedia, und sehe mich ein wenig um:

Gesagt, implementiert. Stellt sich aber heraus, dass die Kalender-App auf Android eine .ics-Datei nicht öffnen kann. Hm, kann nicht angehen! Hilfe der App geöffnet, “ics” gesucht, und Folgendes gefunden:

Termine aus iCalendar- oder CSV-Dateien importieren
Wenn Sie Termine aus iCalendar- oder CSV-Dateien importieren möchten, gehen Sie wie folgt vor:
1. Klicken Sie auf den Abwärtspfeil neben “Weitere Kalender”.

Nur: Wo ist der Button “Weitere Kalender”? Tja, nirgendwo! Die Hilfe der App ist nämlich die Onlinehilfe für www.google.com/calendar! Und da gibt’s den Button! Wie link ist das denn? Und ich suche den eine halbe Stunde lang!

Ungläubig surfe ich noch ein wenig rum, und finde einen entsprechenden Bug von sage und schreibe November 2008 (und immer noch aktiv!). Die Kommentare unter dem Bug werden zusehends schärfer, und das zurecht. Denn ich war auch weitere zwei Stunden später nicht in der Lage, ein dediziertes Kalenderformat zu identifizieren, das vom Android mit dem Kalender geöffnet wird (CSV ignoriere ich dabei, denn das wird im Zweifel mit dem Texteditor oder der Excel-App geöffnet).

Fairerweise muss ich sagen, das Windows Phones .ics-Dateien auch nicht öffnen können – aber zumindest behaupten sie nicht das Gegenteil 🙁

Gestensteuerung ist 2011

Arduino liest Deine Gedanken, und schickt sie an Siri:

und dann geht das ganze per Native Extension über’s Arduino an AIR. Nimm das, HTML5.

Projekthomepage; vor kurzem haben sie einen Investor gefunden^^ via

OK, evt. muss man noch eine App dazwischenschalten, für die Kommunikation von Siri zum Arduino:

via

AIR Native Extensions mit FDT

AIR Native Extensions (ANE) erlauben das Verwenden von System-spezifischen Funktionen – hier das Gyroscope. Mit FDT 4.5 verwendet man sie wie folgt:

  1. Die .ane-Datei kopieren, und die Kopie in .swc umbenennen.
  2. Die .swc wie gewohnt in den Classpath einbinden.
  3. In den Projekteigenschaften -> “FDT Build Path” -> “Build Order” die SWC auswählen, und einen Haken bei “Use as Runtime Shared Code” setzen.
  4. Die Extension im Description-XML deklarieren: Entgegen der Vorlage der Powerflasher heißt der Knoten nicht <extension>, sondern <extensions>, und sieht für dieses Beispiel wie folgt aus:
    <extensions><extensionID>com.adobe.gyroscope</extensionID></extensions>
  5. Die .ane-Datei im Projekt ablegen, beispielsweise unter /bin/ane/
  6. Im Build-XML (das mit dem ADT-Compiler) folgende Zeilen hinzufügen:
    <arg value=”-extdir” />
    <arg value=”../bin/ane” />
  7. Kompilieren 🙂

Tipp, Quelle 1, Quelle 2 (PDF)

Flash auf dem iPhone: Eine AIR-Videoplayer-App in FDT 4.5

Neulich stand ein entsprechendes Projekt auf dem Plan. Meine erste iPhone-App, und meine erste umfangreichere AIR-Anwendung. Hier meine Anmerkungen zum Workflow:

Zum Aufsetzen des Projektes in FDT 4.5:

Zu AIR auf dem iPhone:

  • Evt. muss der Compiler-Parameter -swf-version=11 gesetzt sein. Ohne hatte ich einen 1014 Class not found (Quelle). Damit das übernommen wird, muss ggf. USE_PROJECT_COMPILER_ARGUMENTS auf false stehen
  • Für mehr Performance: AIR 3 verwenden (Danke, Björn!); wobei ich die playerglobal.swc direkt unter www.adobe.com/support/flashplayer/downloads.html gefunden habe
  • Einen Splashscreen (“Default.png”) fügt man im jeweiligen Ant-Script unter “Files to Package” unter der SWF ein: <arg value=”Default.png” />
    (Damit erklärt sich von selbst, wo man weitere ADT-Parameter hinzufügt). Bei mir liegt das Default.png parallel zur SWF in /bin/
  • In dem Zusammenhang: Wenn ich die App-Icons in /bin/icons/* liegen habe, dann füge ich die relativ zu /bin/ im Build-Skript (<arg value=”icons/icon512.png” />) und im Descriptorfile (<image512x512>icons/icon512.png</image512x512>) hinzu
  • Um die App bei Rückkehr zum Homescreen zu beenden, muss man in der ADL-Decriptor-XML unter iPhone.InfoAdditions “<key>UIApplicationExitsOnSuspend</key><true/>” hinzufügen (Quelle)
  • Wer das iPhone 3 und 4 verwenden will, muss unbedingt die unterschiedlichen Auflösungen im Auge behalten! Ich habe es nicht geschafft, einfach die höher aufgelöste SWF auf den kleineren Screen runterzuskalieren, sondern musste im Code darauf reagieren.

Zu Video (hier: StageVideo) auf dem iPhone:

  • Ein gutes Tutorial (inkl. Sourcen) von Thibault Imbert für StageVideo gibt es hier.
  • Für StageVideo-Wiedergabe muss der renderMode (siehe Descriptor-XML) auf “gpu” oder “direct” stehen – “auto” genügt nicht. “gpu” verringert aber die Performance der restlichen Anwendung; “direct” scheint OK zu sein. (PS: “direct” wird im XML-Kommentar nicht erwähnt; Quelle)

Fazit und offene Fragen:

  • Die Performance ist schlechter als nativ, aber absolut OK. Man muss ein wenig darauf achten, wie viel man parallel macht, aber wenn man das weiß, ist AIR eine echte Alternative.
  • Wenn ich sage “die Performance ist OK”, dann meine ich Code, der (abgesehen von StageVideo) nicht optimiert ist! Die Performance ist sicherlich noch besser, wenn man z.B. Stage3D verwendet
  • Sweet: Bis zum Verpacken in einer IPA hat man ein SWF, was Abstimmungen extrem einfach macht.
  • Ich habe es nicht geschafft, das StageVideo um 90° zu drehen, was laut verschiedener Quellen möglich ist. Wer einen Tipp hat, immer her damit!
  • Die gleiche Anwendung müsste auch auf Android exportierbar sein, das habe ich aber noch nicht ausprobiert

HTH,

Lennart

Flash auf iOS, 2

7 Tage, 7 Posts, 6: Eine Kurzanleitung zum Open Screen Project Manager. Ich setze den vorherigen Post zum Thema voraus. Desweiteren wird benötigt:

Dann kann’s losgehen. Der Open Screen Manager ist eine AIR-Anwendung, die ein Projekt-Template für FDT installiert. Ein solches Projekt erzeugt ein Standard-Projekt, ergänzt um die folgenden Ordner:

  • bin: Das Export-Verzeichnis für alle Open Screen Formate
  • bin/ios: Das Export-Verzeichnis für iOS-Apps
  • bin/resources: Hier können externe Inhalte (Bilder, XMLs, …) abgelegt werden, die die Anwendung nachladen kann. ACHTUNG: SWFs dürfen keine Logik enthalten 🙁
  • build: Einstellungen und Ant-Skripte
  • build/core: Enthält zentrale Skripte plus einiger Pfadangaben. Kann im Einzelfall geändert werden, muss aber normalerweise nicht.
  • build/device: Enthält Settings für jedes unterstütze Gerät. Muss normalerweise nicht geändert werden
  • build/*.properties: Wichtige Settings, die manuell geändert werden können, aber normalerweise durch einen Dialog geändert werden:
  • build/project.osp: Per Doppelklick zu öffnender Dialog zum Setzen der wichtigsten Einstellungen

Diese Einstellungen sind die folgenden:

  • Project-Settings, Name: Dieser Name wird später auch am Icon der Anwendung auf dem iPad-Desktop stehen.
  • Project-Settings, Identifier for Distribution: Zum Beispiel com.example.myApp
  • Project-Settings, File name: Das SWF
  • Project-Settings, SWF Content: Der Name des SWF ohne Suffix (?)
  • Project-Settings, Main class: Die zu startende Klasse in dem SWF
  • Device-Settings: Hier ist die iOS-Plattform auszuwählen, also iPad, iPhone, …
  • Plattform-Settings, iOS certificate file: Das Zertifikat des Entwicklers – wichtig: als .p12-Datei
  • Plattform-Settings, iOS certificate password: Das Passwort, mit dem die .p12-Datei verschlüsselt wurde
  • Plattform-Settings, iOS Provision file: Das Provisioning-File
  • Plattform-Settings, iOS Adobe Packager (pfi): etwa ../../packagerforiphone/bin/pfi, aus dem erwähnten Paket

Kompiliert wird über Ant (/build/build.xml). Achtung: Das Skript wird basierend auf dem oben ausgewählten Device erstellt. Wenn dort nichts eingetragen ist, ist das Skript leer. Falls der Task fehlerfrei durchläuft, sollte unter bin/ios/ipad/ eine .ipa-Datei mit dem unter Project-Settings/SWF Content eingetragenen Namen erscheinen. Diese kann man dann via iTunes installieren 🙂

Flash auf iOS, 1

7 Tage, 7 Posts, 5: Eine Kurzanleitung zum Open Screen Project Manager. Hier der vorbereitende Teil:

  1. Man besorge sich einen iOS-Developer Account.
  2. Man logge sich ein.
  3. Man gehe zum iOS Provisioning Portal (rechts in der Navi)
  4. Man gehe zu “Devices”, und richte (zum Beispiel) sein iPad ein. PS: Die UDID (“Device ID”) findet man, wenn man in iTunes auf der Übersicht der Geräteeigenschaften auf die Seriennummer klickt. Diese wird dann zur UDID^^
  5. Man gehe zu “App IDs” und trage die folgenden Informationen ein: Description (Fließtext), “Bundle Seed ID” (die App-ID, unter der man mehrere Apps bündeln möchte – optional), “Bundle Identifier” (zum Beispiel com.example.myApp)
  6. Man gehe zu “Certificates” und lege einen neuen “Team Member Account” an (man beachte dabei das “Howto”, ganz rechts). Das ist wichtig, der aktuelle Account dient nur zu administrativen Zwecken. Auch wichtig: Erst nach der Verifizierung per Email erscheint der neue Account unter “Team Member Certificates”
  7. Man gehe zu Provisioning und verknüpfe App-ID(s), Entwickler und Device(s)
  8. Man lade sich das resultierende Provisioning-Profile runter

iPad: Fehlermeldung bei Installation einer App

Wer einen der obigen (oder einen ähnlichen) Fehler hat, und auf den Button “Weitere Informationen” klickt, dem sein Browser wird geöffnet, und wird vermutlich einen 404 bekommen. Der Grund? OS X ist auf Deutsch eingestellt – sonst wäre die Meldung nicht Deutsch. Die Webseite checkt aber die eingestellte Sprache, und versucht zu einer lokalisierten Version der gewünschten Seite zu verlinken. Die es nicht gibt.

Ja, richtig, kein Witz: Wenn man sein OS X in den Systemeinstellungen auf Englisch umstellt, dann geht der Button. Und man landet auf http://support.apple.com/kb/TS1702

Danke, Apple.

“Open Screen Project”-Manager für FDT 4.1

http://www.youtube.com/watch?v=8n6jDLz4Im8

Das Open Screen Project hat sich viel vorgenommen:

Enable consumers to engage with rich Internet experiences seamlessly across any device, anywhere.

Dies für FDT 4 umzusetzen ist das Ziel des “OpenScreen Project Managers”: Ein Project-Template, das im Grunde nur eine Sammlung von Ant-Skripten plus einer Oberfläche zum Administrieren dieser Skripte mitbringt. Man kommt trotzdem nicht drumrum, zum Beispiel für iOS-Veröffentlichungen den ganzen Overhead (Login benötigt!) zu erledigen, aber trotzdem: Hat man das ganze erst mal durchschaut, ist es komfortabler als die Konsole 😉

PS: Danke an Björn!