blog@netplanet

1.000 Tage sind in etwa der Zeitraum, in denen Hersteller von Mobiltelefonen die Firmware von Smartphones pflegen. Dabei ist “pflegen” ein sehr dehnbarer Begriff, bei dem sich die meisten Hersteller strikt darauf beschränken, aus der initial verteilten Firmware die Bugs herauszuoperieren und maximal nur sehr moderate Erweiterungen zu integrieren. Man will ja den Kunden nicht dadurch verlieren, dass er so zufrieden mit seinem Gerät wird, dass er kein neues Smartphone mehr kauft.

Zusammenprall der Welten

Tatsächlich leidet unter diesem Zusammenprall der Welten Google mit seinem Betriebssystem Android am meisten. Android hat einen vergleichsweise hohen Entwicklungsschub, was für Google typisch ist. Wird in ein Produkt von Google Energie hineingesetzt, dann hochkonzentriert und stark. Das ist für einen Software-Hersteller natürlich kein so wirklich großes Problem, denn Software-Herstellung verläuft deutlich weniger “schweinezyklisch”, wie Hardware-Herstellung. Ist ein Bug in der Software, wird er eben gefixt. Das Internet unterstützt dieses Paradigma zudem. Ein Software-Update ist heute – wenn überhaupt – nur noch einen Klick weit entfernt.

In Sachen Hardware-Fertigung sieht das alles noch ganz anders aus. Planung, Entwicklung, Kalkulation, Fertigung, Verkauf, Distribution sind alles Dinge, die aufeinander aufbauen, gehörige Vorbereitungen und gewaltigen Einsatz in Sachen Finanzierung und Personal bedeuten und jeder Schritt muss passen. Die Software des Smartphones ist der Teil eines solchen Spektakels, mit dem der Endanwender am meisten Spaß oder Ärger hat, dementsprechend konservativ gehen Hardware-Hersteller mit diesem Thema um. Diese konservative Vorgehensweise der Hardware-Hersteller ist dann auch das zentrale Problem von Android, denn es gibt keinen einheitlichen Rollout einer Android-Version. Und noch viel schlimmer ist, dass Interimsversionen, die vornehmlich Bugfixing als Ziel haben, ebenfalls teilweise stark verzögert auf Smartphones landen – wenn überhaupt.

Auch wenn die Android-Entwicklung und spätere Anpassung auf Smartphones eine Geschichte ist, die man eben nicht mal so nebenbei erledigt: Der Konsument hat dafür immer weniger Verständnis und so bald sich der (gern subjektive) Eindruck breitmacht, dass ein Mobiltelefon in Sachen Software nicht gut gepflegt ist, ist der Wechsel zu einem anderen Mobiltelefon tatsächlich nicht mehr weit. Und noch viel schlimmer: Hat sich so ein Eindruck beim Endkunden manifestiert, ist nicht nur der Smartphone-Hersteller in seinem Ruf hier beschädigt, sondern auch gleich noch Android.

Apple, ja Apple

Besitzer von iPod, iPhone und iPad sind es gewohnt, in regelmäßigen Abständen Firmware-Updates zu bekommen, die allesamt sitzen und praktisch keine Kompatibilitätsprobleme aufweisen. Das ist auch verhältnismäßig einfach zu bewerkstelligen, denn Apple baut hier eine Software auf die eigene Hardware und hat von der Hardware auch verhältnismäßig wenig Versionen zu berücksichtigen.

Aber auch hier gilt die 1.000-Tage-Regel und spätestens nach dem letzten Update der Firmware beginnt ein Smartphone, an Nutzen zu verlieren. Immer mehr Hersteller von Apps berücksichtigen alte Firmware-Versionen nicht mehr und von weiteren Entwicklungen sind natürlich auch die hauseigenen Apps wie Webbrowser und Mail-Programm betroffen. Damit könnte man ja noch leben, aber das größte Problem bei so einem definierten Ende des Produktzyklus sind später entdeckte Fehler und Bugs. Die fixt für so abgekündigte Produkte natürlich auch keiner mehr. Lost in Translation.

Entkoppelung von Hard- und Software

Wäre es nicht schön, wenn es mir egal sein könnte, ob Samsung für mein wunderbares Galaxy S2 zukünftig Softwareupdates liefert oder nicht? Immer ein Smartphone zu haben, das eine aktuelle Software so lange einsetzt, wie ich das möchte, unabhängig davon, ob Samsung nun den Support einstellt oder nicht? Traum? Ich persönlich glaube, dass die Zeiten der Koppelung von Hard- und Software auf Smartphones zukünftig eher Ausnahmen sein werden. Okay, Apple wird sich aus religiösen Gründen nicht davon trennen (können), die Software-Entwicklung aus der Hand zu geben, aber alle anderen Smartphone-Hersteller, die kein eigenes Betriebssystem einsetzen? Ein Traum, ein Smartphone mit entkoppelter Hard- und Software zu haben?

Nein, kein Traum, sondern Realität. Und wenn man es genau nimmt: Schon seit Jahren.

“Firmware-Cooking”

Dass bei Smartphones Software immer der Hardware hinterherhinkt, ist kein Phänomen, das erst mit Android auf die Welt kam. Windows Mobile hat daran in seiner Inkarnation in Version 5 und 6 ständig gekrankt. Der Hauptgrund war, dass Windows Mobile in Version 5 und 6 zwar ein leistungsfähiges, aber ein hoffnungslos veraltetes Betriebssystem war und quasi alles, was machbar war, dadurch verhagelte, dass es nur schwer zu bedienen war. Dazu kam ab Version 6 die aufkommende Touch-Bedienung, die vornehmlich HTC mit Windows Mobile zu implementieren versuchte und dazu eigene Software-Module beisteuern musste. So entstanden zwar hardware-technisch recht ausgereifte Geräte, die jedoch durch Windows Mobile unglaublich katastrophal zu bedienen waren.

Schon zu dieser Zeit, wir schreiben da den Zeitraum von 2005 bis 2007, gab es Menschen, die “eigene” Firmware-Pakete “kochten”. Dazu nahmen sie bestehende Update-Pakete, extrahierten daraus die Treiber und gerätespezifischen Anpassungen und backten diese in offizielle Windows-Mobile-Distributionen ein. Natürlich alles hochgradig illegal und oft auch in zweifelhafter Qualität, aber Microsoft verstand bemerkenswert gut, dass diese halblegal-illegale Subwelt gar nicht schlecht war, denn immerhin benutzten sie Windows Mobile und kauften solche Geräte auch, so dass die Betriebssystemabgabe schon beim Kauf des Gerätes geleistet wurde. Die ganzen Köche, die in ihrer Freizeit Firmwares auf Basis von Windows Mobile backten, bekamen auffällig wenig Ärger von Microsoft und wurden, glaubt man Gerüchten, teilweise sogar direkt von Microsoft mit Insiderinformationen und internen Dokumentationen versorgt, um etwaige Fehler in der Do-it-yourself-Firmware auszumerzen.

Wenn man will, war dieses Hobbykochen der erste Schritt zu dem, wie ich mir die Smartphone-Welt zukünftig vorstelle.

Firmware als Abo-Modell

Ich bin inzwischen überzeugt davon, dass der Versuch von Smartphone-Herstellens, Hard- und Software weiterhin aus einer Hand anzubieten, zukünftig immer weniger funktionieren wird. Schon heute ist der Produktezyklus sehr hoch und während heute ein Hersteller ein Smartphone einer bestimmten Preisklasse neu verkauft, ist die nächste Generation in der konkreten Entwicklung und die übernächste in der Planung. Und auch schon heute kommt die Software-Entwicklung kaum noch nach, so dass die ersten Versionen einer Firmware oft genug noch Beta sind, wenn man sie knallhart nach gängigen Qualitätssicherungskriterien bewerten würde.

Im Gegenzug könnten sich Hersteller von Smartphones, wenn sie sich nur noch auf Hardware beschränken würden, wieder auf das beschränken, was sie eigentlich wirklich gut können – gute Hardware bauen. Vernünftige, ausgewogene Leistungsdaten und durchdachte Schnittstellen, sowohl zur Firmware, als eben auch über die Bedienelemente zum Benutzer.

Die Software wiederum ist in einem Abo-Modell bestens aufgehoben. Wer eine Basis-Firmware braucht, dem genügt vielleicht schon eine ganz einfache Firmware, die weitgehend nur das Telefonieren ermöglicht. Wer Wert auf ausgefeilte Funktionen und Feintuning legt, wird sich am ehesten auch darauf einlassen, für so eine Firmware Geld auf den Tisch zu legen, wenn denn eben auch sichergestellt ist, dass die Software mit dem Gerät funktioniert und im Idealfall auch harmoniert.

Utopie? Schwer zu sagen. Es müsste einfach mal ein Hersteller offensiv probieren. Dass man sich in der Hardware-Welt dem Thema nicht verschließt, beweisen SonyEricsson und Samsung, die dem bemerkenswerten CyanogenMod-Projekt, das für viele Geräte eine ausgereifte Android-Distribution zur Verfügung stellt, die jeweils aktuellen Smartphones zu Entwicklungszwecken zur Verfügung stellt. Der nächste, konsequente Schritt wäre die Monetarisierung eines solchen Vertriebsmodells als Firmware-Abo. Wer sich da als erster traut, wird – meiner Meinung nach – nicht enttäuscht werden.

• 

Einer der Dinge, die mich  von Anfang an in Apples Mobilbetriebssystem iOS und auch in Android gestört haben, war eine fehlende ToDo-Verwaltung. Es ist mir unverständlich, wie man ansonsten alle PIM-Anwendungen wie Kalender, Kontakte, Notizzettel integrieren kann, dann aber eine simple ToDo-Verwaltung außen vor lässt.

Das Ergebnis auf beiden Plattformen ist dementsprechend desolat: Es blühen die Todo-Anwendungen von Drittanbietern und sie blühen in der Regel mehr schlecht als recht. Die eine Gruppe an solchen Apps macht es mit der Verwaltung entweder zu einfach oder viel zu kompliziert, die meisten Apps synchronisieren mit keinem gängigen Dienst und die wenigsten Apps sind kostenlos und im Gegenzug dafür sogar richtig unverschämt teuer. ToDo-Verwalten für 5 oder gar mehr Euro?

Meine private und geschäftliche ToDo-Verwaltung läuft unter Google Tasks, das von Google bis vor kurzem noch ziemlich stiefmütterlich behandelt wurde, inzwischen aber sogar eine offizielle API hat. Wenn man mit dem Umstand lebt, dass Google Tasks kein eigenes Webinterface hat und derzeit nur via Google Mail oder über ein Widget in iGoogle bedienbar ist, kann man damit ganz gut leben. Seine Klasse spielt Google Tasks schon allein dadurch aus, dass es extrem simpel ist und die Verschachtelung von Aufgaben einfach dadurch realisiert, in dem Aufgaben einfach “unter” bestehende Aufgaben geschoben werden und mit frei definierbaren Aufgabenkategorien gearbeitet werden kann. An umfangreiche Priorisierungen hat man einfach keinen Gedanken verschwendet, das realisiert man einfach durch das Verschieben von Aufgaben nach oben oder nach unten oder vergibt Aufgaben einen festen Fälligkeitstermin. So einfach kann es gehen.

Wenn man Google Tasks mit einer iOS- oder Android-App synchronisieren will, fällt glücklicherweise der größte Teil der ToDo-Apps gleich durchs Raster – die meisten nutzen Google Tasks nicht zum synchronisieren. Das macht die Auswahl dann auch gleich leichter. Gelandet bin ich dann bei zwei Apps namens “GoTasks”. Witzigerweise heißt nämlich die beste App für die Synchronisierung von Google Tasks für iOS genauso wie die App für Android, obwohl beide Apps miteinander nichts zu tun haben und jede App von einem anderen Programmierer gepflegt wird, die dann wiederum aber beides Russen sind. Zufälle.

Beide Apps kosten nichts, beide sind werbefrei, beide funktionieren sowohl auf Smartphones, als auch auf Tablets und beide funktionieren zuverlässig, auch mit Google-Apps-Konten:

• GoTasks für Android von Vadim Milyukov
• GoTasks für iPhone/iPad von Evgeniy Shurakov

Einen kleinen Wermutstropfen gibt es lediglich für GoTasks für Android: Offenbar lässt sich die App nicht auf allen Android-Gerätschaften finden. Auf meinem Samsung Galaxy S2 mit Android 2.3.4 ist es nicht auffindbar und im Web-Market wird angezeigt, dass mein Gerät nicht kompatibel sei. Es funktioniert aber, wenn man die App schon vorher installiert hat, sie ist also soweit kompatibel. Falls jemand mit Android die App nicht findet, bitte einfach mal kurz melden.

• 

(Gleich eine Vorwarnung an den geneigten Leser: Ein technischer, spezieller Artikel zu Google Apps und E-Mail-Migration. Darf man gern bis zum Ende lesen, wenn man sich dafür interessiert, muss man aber nicht, wenn nicht. )

Nachdem ich nach RSS-Reader, Kalender und Kontaktedatenbank alle mir wichtigen Organisationsdinge in die “Cloud” bei Google eingebracht habe und das alles sogar zuverlässig mit dem iPhone synchronisiert, war es nun mehr als notwendig, dass das älteste Relikt meiner Online-Identität diesen Weg ebenfalls geht – die gute, alte E-Mail.

Bis dato habe ich E-Mails per IMAP abgerufen, sowohl auf dem PC, als auch auf dem Notebook und dem iPhone. Das ist insofern praktisch und brauchbar, weil ich E-Mails nicht überall herunterladen muss, sondern quasi in die Mailbox hineinschauen kann. Wirklich heruntergeladen habe ich E-Mails traditionell immer nur am heimischen PC, auf dem ich dann alle ein- und ausgehenden E-Mails nach Jahrgängen archiviert. Technisch also alles kein Problem. Allerdings organisationstechnisch.Das Problem ist nämlich immer wieder, dass ich am Notebook auf ältere E-Mails zurückgreifen müsste, das aber nicht kann, weil die eben auf dem PC liegen. Sicherlich, ich kann den PC per Wake-on-LAN hochfahren, mich remote einloggen und das tun, was getan werden muss, aber es ist umständlich.

Ein zusätzliches Thema bei einer Migration: Der Umfang meiner Mailarchive. Die gehen zurück bis 1997, enthalten rund 45.000 E-Mails und belegen knapp einen Gigabyte an Speicherplatz. Früher einmal war das eine Herausforderung, heute ist das eher eine Bürde. Denn 1 Gigabyte lässt sich in jeder modernen Festplatte bequem einbunkern, allerdings hat das Archivieren solcher E-Mail-Berge ganz andere Anforderungen: Lesbarkeit der Archive, Durchsuchbarkeit und vor allem Datensicherung. Ich schlenkere Mailarchive auf meiner normalen Festplatte herum, auf meiner NAS und sicherheitshalber nochmal auf einem externen Datenträger. Das ist alles schön und gut, aber im Cloud-Zeitalter einfach Käse.

Google Apps als Lösung.

Der Einsatz von Google Apps war schon seit langem eine Überlegung und wurde jetzt einfach dringend notwendig. Die Gründe dafür liegen auf der Hand: Google ist zuverlässig, Google ist flott, Google hat alle notwendigen Dienste und Google Apps kostet mich für meinen Bedarf nichts. Tatsächlich: Nichts. Denn Google Apps ist in der Basisfassung mit 10 (bis Ende der ersten Maiwoche noch 50) User-Accounts und jeweils 7 GB (anwachsendem) Speicherplatz kostenlos. Also: Tun!

Die zentrale Entscheidung ist erst einmal, zwischen dem kostenpflichtigen “Google Apps for Business” und dem einfachen “Google Apps” zu unterscheiden. Der Link hier führt zur kostenlosen Version. Dort geht es dann mit einem Klick auf den Erste-Schritte-Buttons sogleich los.

Neben den Kontaktdaten (das kann eine Firma sein, aber eben auch eine Einzelperson) sind vor allem zwei Dinge wichtig. Die Domain, unter der man später Mailadressen einrichten möchte und die Anlage eines neuen Google-Accounts. Es ist dabei tatsächlich ein neuer Google-Account notwendig, bestehende Google-Accounts können aus administrativen Gründen nicht benutzt werden. Und hier gibt es in vielen Fällen auch schon ein Problem, wenn nämlich die gewünschte Adresse für diesen neu einzurichtenden Google-Account schon für den bisherigen genutzt wird. Ist das der Fall, muss tatsächlich für den bisherigen Google Account eine andere Mailadresse gewählt werden, um die entsprechende Adresse dann für den neu einzurichtenden Google-Account zu nutzen.

Exkurs: Ein Google-Account oder lieber zwei?

Auch eine Sache, die man sich vorher überlegen muss: Nutzt man bereits Google-Dienste und möchte diese aus bestimmten Gründen weiterhin auf dem bisherigen Google-Account beibehalten (was Sinn machen kann, wenn man z.B. den Google-Apps-Account geschäftlich nutzen möchte), gibt es die Möglichkeit, sich mehrfach einloggen zu können. Aktiviert man diese Möglichkeit im bisherigen Google-Account, kann man sich demzufolge mit einem weiteren Google-Account einloggen und hat dann rechts oben im Browserfenster, dort wo die Mailadresse steht, mit der man aktuell eingeloggt ist, die Möglichkeit, schnell per Auswahl den anderen Account auszuwählen. Funktioniert nach meinem Test in vielen Google-Diensten, aber leider nicht in allen. Es macht also Sinn, sich ggf. tatsächlich über eine vollständige Migration der wichtigsten Dienste Gedanken zu machen, ganz unten gibt es einige Gedanken dazu.

Das Dashboard.

Zugegeben – wer es bisher gewohnt ist, dass Google-Dienste absolut einfach sind und ohne Denken funktionieren, der könnte bei Google Apps enttäuscht werden, denn es ist Mitarbeit gefragt. Benutzer müssen angelegt werden (natürlich nur, wenn man mehr als einen Benutzer einrichten möchte), und später muss für die Domain, die man für Mails nutzen möchte, auch die MX-Einträge geändert werden. Das ist nicht jedermanns Sache und die Google-Hilfe ist, sagen wir mal so, ausbaufähig. Der Hilfe-Assistent ist soweit brauchbar, allerdings muss man wissen, was man tut und das DNS sollte man auch kennen. Und leider muss man bei vielen Hilfe-Themen auf englischsprachige Artikel zurückgreifen, weil es an vielen Stellen keine deutsche Übersetzungen gibt.

Ansonsten, wenn es um einen einzigen Benutzer geht, sind die Einstellungen soweit schon mal brauchbar.

In Sachen Migration übrigens eine Empfehlung: Ruhig mal anfangen, sich in Google Apps umzuschauen, ohne gleich die eigene Domain auf Google Apps zu drehen. Das ist erst dann erforderlich, wenn man auch tatsächlich E-Mails dort live empfangen möchte. Zum Umschauen ist das noch nicht notwendig und auch noch nicht dann, wenn man Mailarchive importieren möchte. Und wer unbedingt schon mal den Empfang testen möchte, kann auf die segensreiche Möglichkeit der Test-Domain zurückgreifen, die Google Apps bei der Einrichtung automatisch anlegt (ist dann im Dashboard genau beschrieben).

Mail in Google Apps.

Wer bisher schon Google Mail genutzt hat, wird den Mail-Client kennen, denn es ist das Google-Mail-Frontend. Und Google Mail besitzt bekanntlicherweise auch eine Möglichkeit, per IMAP-Protokoll kontaktiert zu werden, so dass über diesen Weg auch bestehende Mailarchive importiert werden können (IMAP-Einstellungen gibt es in der Hilfe). Für die Outlook-Benutzer gibt es übrigens den angenehmen Nebeneffekt, dass es hier einen eigenen Importer gibt und auch der Import von PST-Postfachdateien funktioniert. Alle anderen Mailbenutzer müssen, wenn sie Mailarchive importieren möchten, den Weg über IMAP gehen.

Der IMAP-Transfer funktioniert, ist allerdings langsam. Sehr langsam. Für rund 75 % meiner Mails – das sind bis jetzt rund 35.000 E-Mails – habe ich rund 10 Stunden gebraucht und es sei angemerkt, dass das nur rund 250 MB Datentransfer war! Der Import größere Mailarchive ist also eine sehr zeitintensive Geschichte und es macht Sinn, durchaus zu überlegen, ob man wirklich alle E-Mails importiert haben möchte.

Ansonsten bietet IMAP alle Annehmlichkeiten, die man beim Archivieren haben kann, vor allem nämlich die Anlage von Unterordnern. Ich habe dazu im Archiv meines Postfaches einfach Unterordner mit der entsprechenden Jahreszahl angelegt und darin jeweils einen Ordner für Posteingang, Postausgang und jeweils für Mailinglisten. In die habe ich dann die entsprechenden Mails aus meinen Mailarchiven kopiert.

Im Google-Mail-Frontend, das bekanntlicherweise nicht mit Ordnern, sondern mit so genannten Labels arbeitet, erscheinen diese Unterordner dann alle im Format “Archiv/(Jahreszahl)/Eingang” und sind in der Label-Ansicht auch nicht verschachtelt, da Labels nicht verschachtelt werden können. Aus der Navigationsansicht bekommt man die vielen Labels übrigens problemlos ausgeblendet, dazu einfach den Link “Labels verwalten” anklicken und ausblenden.

Und noch eine Eigenart, die das Labeling mitbringt: Vorsicht mit der Möglichkeit, Mails mit mehreren Labeln zu versehen. Die erscheinen dann nämlich in der IMAP-Ansicht tatsächlich in den entsprechenden Ordnern mehrfach. Und auch Vorsicht mit E-Mails, die gar kein Label besitzen, wie sie normalerweise im Posteingang nach dem Empfang erscheinen. Die kann man zwar problemlos mit Labels versehen – nur wenn man das nicht macht, wird man sie, wenn man sie wegsortiert, kaum mehr finden, da Google Mail zwar eine Suchfunktion für Mails mit Labels bietet, dummerweise aber kein Suchkriterium kennt, um Mails zu finden, die kein Label tragen.

Empfehlung meinerseits, von einem alten Backup-Hasen: Do not delete your Backup. Auch wenn der Import der Mailarchive funktioniert, sollte man seine lokalen Mailarchive nicht löschen. Vielleicht gefällt einem Google Apps nicht, vielleicht geht etwas beim Import schief, vielleicht löscht man aus Versehen ein Verzeichnis in der Cloud (was wirklich Datenverlust bedeutet) und da ist ein lokales Backup die beste und einzige Lebensversicherung. Ich habe es hiermit gesagt!

Migration des Google Reader, Google Calendar und Google Contacts

Bei der Migration von Google Diensten ist leider Handarbeit gefragt. Bei all diesen drei Diensten, die ich bisher einsetze, müssen die Inhalte jeweils im bisherigen Google-Account exportiert und im neuen Google-Account wieder importiert werden. Das ist insofern problemlos, allerdings gehen beim Google Reader die Trend-Informationen, die während der Nutzung des Google Readers entstehen, verloren, da diese nicht ex- bzw. importiert werden. Ärgerliches, kleines Manko.

Beim Google Calendar gibt es zudem noch Pflegeaufwand, wenn in einem Konto noch zusätzliche Kalender abonniert sind oder gemeinsame Kalender mit anderen Benutzern geführt wird. Hier macht es Sinn, im alten Google-Account zunächst die Mailadresse des neuen Google-Accounts hinzuzufügen und sich dann mit dem neuen Google-Account einzuloggen, um die gemeinsamen Kalender auch dort verfügbar zu haben.

Migration und externe Clients

Was man bei der Anlage eines neuen Google-Accounts und einer eventuellen Migration von Diensten auch berücksichtigen muss: Überall, wo man Google-Dienste bisher verwendet hat, müssen nun die neuen Google-Account-Daten hinterlegt werden, also z.B. auf Smartphone, iPad etc. und dort dann auch in eventuelle Apps, die Google-Dienste nutzen. Funktioniert hier zwar alles weitgehend reibungslos, ist aber auch Zeitaufwand.

• 

Als ich 2006 angefangen habe, meine altehrwürdige CD-Sammlung in Audiodateien umzuwandeln, wusste ich noch nicht so recht, wie praktisch das irgendwann sein könnte. Bereut habe ich es eigentlich kaum, denn obwohl ich lange Zeit so gar nichts mit mobiler Musik anfangen konnte, war es zumindest soweit praktisch, Musik immer per Knopfdruck am PC zu haben, ohne erst mal die CD zu suchen, einzulegen, abzuspielen und dann wieder die nächste usw. Irgendwann kommt man dann auch dahinter, wie das mit den Playlists funktioniert und wie der Windows Media Player anfängt, den Musikgeschmack zu lernen. Hübsch und gut.

Was damals mangels vernünftiger Alternative ein Schritt war, war die Entscheidung auf ein Musikformat. MP3 fiel heraus, weil mich MP3 nie wirklich von der Klangqualität überzeugte (ja, ich habe tatsächlich einmal Unterschiede heraushören können) und so landete ich bei Windows Media Audio. Ein Schritt, den man bedauern kann. Nicht, weil das Format nicht hochklassig wäre – das ist es nämlich nach wie vor – sondern weil WMA ein Problem hat: Das Apple-Reich will das Format nicht kennen. Schick wäre es allerdings, Musik auf dem iPhone haben zu können, immerhin habe ich ja sowohl für die Musik, als auch für das iPhone Geld bezahlt.

Also wartete der Schritt eigentlich nur darauf, einen Formatewandel durchzuziehen. MP3 fiel weiterhin aus, aber MP4 alias AAC ist dann die Antwort. Das ist das Hausformat von iTunes und inzwischen auch vom Windows Media Player 11 unter Windows 7. AAC wird zwar aufgrund höherer Lizenzkosten bei weitem noch nicht von allen Musikabspielgeräten eingesetzt, aber darf man trotzdem AAC als potentiellen Nachfolger von MP3 nennen? Falls nicht, ist es mir auch egal.

Also durften die noch bei mir im Besitz befindlichen CD wieder eine Runde im PC drehen, um ihren Inhalt als M4A-Dateien auf meine NAS auszuwürgen. Kurzfristig vermisste ich dann mal ungefähr 70 Alben und begann, das Haus zu durchsuchen, bis mir schwante, dass diese 70 Alben vielleicht schon längst nicht mehr in meinem Besitz sind, was sie auch tatsächlich nicht mehr sind. Nennen wir es mal “natürlich Auslese”, die da im Laufe der Jahre passiert ist.

Nun also: M4A alias AAC. Versteht nach wie vor die PS3, versteht auch das iPhone, iTunes kann mit meiner Buffalo-NAS korrespondieren, auf der die Audiodateien liegen und der Windows Media Player auch. Die nächste Stufe kann kommen.

• 

Die Artikel zum Synchronisieren zwischen Google Calendar und dem iPhone gehören weiterhin zu den absoluten Artikelschlagern hier im Blog. Das hat den Vorteil, dass die Artikel offensichtlich einigen Ratsuchenden eine Hilfe darstellen und einiges an Erfahrungen zusammenkommen, die leider in den offiziellen Google-Anleitungen nicht gut oder teilweise gar nicht dokumentiert sind.

Bei der Verfassung der Anleitung zum Synchronisieren des Google Calendar mit dem iPhone hat sich ursprünglich das Verhalten gezeigt, dass über dem offiziellen Verfahren namens “Google Sync” (das auf dem ActiveSync-Verfahren von Microsoft beruht) nur der Hauptkalender eines Google-Calendar-Accounts synchronisiert werden kann und offenbar nicht eventuell eingerichtete Sub-Kalender. Meine Alternative war die Anleitung zur Synchronisierung per CalDAV. Das funktioniert zwar, ist aber deutlich langsamer.

Nun, kurzum, es funktioniert doch mit Google Sync, wenn man sich von einer Fehlermeldung von Google, die auf einem simplen Sprachproblem basiert, nicht ins Boxhorn jagen lässt. Dementsprechend habe ich die Anleitungen auf Basis von Google Sync dementsprechend aktualisiert und der einzig wahre und perfekte Artikel ist folgender:

• Terminsynchronisation zwischen iPhone und Google Calendar.

Und wer es dann trotzdem noch per CalDAV machen möchte, weil er ActiveSync aus politischen Gründen nicht nutzen kann, nimmt halt diese Anleitung, die jetzt einen neuen Titel hat:

• Terminsynchronisation zwischen iPhone und Google Calendar via CalDAV.

Und wer beides nicht nutzt, also weder Google Calendar, noch iPhone, der kann trotzdem etwas per Flattr spenden, war nämlich alles richtig viel Dokumentationsarbeit. Alles nicht so einfach im Leben.

•