This is the story of a former Andoid fanboy who, finally, switched to iOS ... but let's start at the beginning.

Wo am I?

At first, I'm a guy who loves technology and likes to play with it. At the same time I'm also someone who happens to hate it when technology gets in my way, which is the main motivation of this rant. I'm also a computer science student, a member of RadioTux which is a German GNU/Linux and OpenSource podcast network and a member of shackspace, the Stuttgart hackerspace.

The past

A few months ago I finished my bachelor degree in Computer Science and Media at Media University Stuttgart. During my studies I was engaged in some mobile-related projects and therefore got in touch with Android in the beginning of 2009. I was very excited at this time because Android was the first mobile platform I actually wanted to develop on: The SDK was available on Linux, Windows and OS X, the platform itself was mostly open source and there was a phone available which I actually wanted to use. At the time I was strictly using Linux for everything and I didn't want to boot up a VM or install Windows to do development. So Android was a really cool thing.

In the Spring of 2009 I bought a G1 (HTC Dream) and made the first babysteps on this new exciting platform. A few weeks later, Christian and I decided to write an Android XMPP client because we wanted such an application for our phones and we had the possibility to implement a software project for our studies and get credits for it.

Almost two years later, the project called yaxim is still alive and maintained by a great guy called Georg. I also did some Android related development during my internship semester and my part time work after that. One example is this module which implements a barcode scanner for Titanium Appcelerator on Android. I was using my Android phone during this whole time.

After almost two years, I'm writing this article because people keep calling me "Apple fanboy" (which I'm not) and want to know why I bought an iPhone and got rid of my Android device. This is an attempt to explain it so I don't need to keep on telling the same story over and over again.

So why did I switch to iOS?

There are several reasons why I switched to iOS, but there is only one really important one: I was pissed at Android and wanted a change. I'll try to explain what bothered me the most in the rest of this post.

User Experience

The first thing I noticed while using my iPhone for the first time was how smooth the UI transitions worked and how snappy all controls reacted. Almost every button I touched triggered an instant action. In contrast to every Android phone and tablet I used in the last two years I actually felt in control: There was no noticeable delay and all animations happened fluently. This is a great plus for user experience. Unfortunately, all current Android devices I've tried out lack this responsiveness - mostly due to the fact that most of the UI is rendered in software.

The other thing that caught my eye was the quality of the built-in apps. I tried to use the email client, the music player and the browser on Android but they just weren't what I wanted. So I started installing replacements. In terms of listening to music or podcasts I finally gave up and bought an iPod to fulfill my needs in this area.

Apple and iOS are often criticized for not allowing replacements for built-in apps. To be honest, in the past I also criticized Apple for exactly the same reason. Until I started using the built-in apps on my iPhone: The email client alone was SO MUCH better than everything I tried on Android.

For example: Once, I was invited to a birthday party of a friend. I didn't memorize his address since I had my smartphone with me and the address was in an email on my server. Long story short: When I searched for this particular mail, my client wasn't able to find it and I needed to launch a browser and log into my webmailer to be able to retrieve the mail I wanted. At this moment I hated my phone and its email client and wanted to throw it in the bin, but I didn't. In this moment, I finally understood the point: Normal users just wouldn't care to replace the default applications when they're good enough for their needs.

To be honest: Android may be okay for you when you're using Google Mail. But I don't since I run my own mail infrastructure and want it to stay that way.

Application Distribution

Every current smartphone platform has some kind of software distribution system. On iOS it's the App Store on Android it's the Android Market. Nothing new so far. Since Google as well as Apple is earning money through the app store, they should be motivated equally to provide a pleasant shopping experience.

The last time I used the Android Market was some months ago and I expect that a lot of my problems with it are fixed by now. But according to a post on Hacker News some days ago the biggest isn't:

Market Search - This is the big killer. Before the updates to the Market over the past few weeks, searching for our application by its content type would consistently put us near the top of the results. I believe that this is correct due to the fact that we are extremely popular and well-reviewed. However, now when searching in our application category, we are result #227. We are consistently being beaten by hundreds of application that have 10-50 downloads, zero ratings, and absolutely no Market history. This has caused our purchases to fall from doing very well to almost getting no purchases at all. Google's Market updates are effectively making sure that Out of Milk cannot continue development due to not making enough to cover operating costs.

As a user, I had exactly the same experience: I just wasn't able to find good apps via search. Most of my installed apps I knew from reviews on the web of recommendations of friends. Seriously?! This is a product of the FUCKING search giant Google and they aren't able to integrate a well working search in their software distribution platform? Am I the only one to find that kinda ironic?

On the Apple App Store there are also some editorial sections covering different topics and they feature new apps every week. On Android there were, at least some months ago, only few featured apps. And these apps were mostly the same I already knew. So no surplus for me ...

Available apps

There are lots of apps on both platforms and I found most of the apps I wanted to use on both of them. The main difference from my experience is: On Android they're mostly free and do their job and on iOS they mostly cost money and are very often more pleasant to use than the Android versions. My problem was that I just wasn't able to find really great apps on Android, even if I was willing to pay for them. Some people say that one should pay for apps, others say they should be free. I really don't care much, as long as the apps are great to use and not too expensive.

Normal Apps

I mostly use a hand full of apps on a regular basis:

• Google Reader client
• Twitter client
• Mail client
• Audio player
• News- and read-it-later clients

These apps were available on both platforms and I used them very extensively on both of them. What irritated me the most was that even Google Reader clients, like Reeder, were so much better to use on iOS compared to the apps on Android. Even the Reader app from Google itself was just doing a mostly crappy job. I think this is really sad and needs to change.

Games

Games are a special case. I was never a big gamer and didn't really spend much money on games on consoles or PCs. This didn't change when I got my Android phone: I installed a few games, tried some of them, noticed they suck my battery dry and uninstalled them afterwards. Most of them where boring or didn't run well on my hardware and I didn't care to play them once or twice.

My relationship to mobile games changed when I started using my iPhone: There are a ton of really well working games with fresh ideas I really enjoy playing. I think until now, I've spent more money on iOS games than on normal PC games. Compared to Android, iOS is just a really great gaming platform.

Available Devices

In terms of devices, there is a really big difference between the two platforms: For iOS there is one smartphone, one tablet and the iPod touch in different generations and some slightly different configurations. All are in the premium price segment. Whereas there are tons of different devices of different vendors in different price categories with different features running different versions of Android. If you want to choose from a large collection, you'll like Android. I personally find the diversity mostly confusing.

Update politics of hardware vendors

One of the biggest failures of the Android platform is the fact, that hardware vendors are in charge of updating the system. Let's be reasonable: Most hardware vendors don't care if their customers are running an obsolete version of Android as long as they are selling enough phones. I, for example, could update my phone up to Android 1.6. After that, I needed to root my phone and flash experimental firmware if I wanted some new features and security fixes (e.g. transmitting authentication tokens over an unencrypted HTTP connection). Some weeks ago even a network carrier released an update and instructions for rooting the Motorola Milestone XT720 because Motorola wasn't willing to update the software.

Apple, on the other hand, dropped support for the iPhone 3G in the beginning of 2011. This was more than two years after the phone had been launched for the first time. When iOS 5 will be released, my iPhone4 will get a major upgrade to this new version and probably the version after it. How many Android users with phones older than a year are provided with a current version of the operating system? HTC Desire users surely won't get newer Versions than Android 2.2 - which has been released over a year ago in May 2010.

From a developer's perspective

As stated before, I'm also a software developer interested in building stuff. So why would I write software for any platform? First, I have an itch to scratch and want to use the software for myself - as I did with yaxim. Second, I have the perspective of earning money by selling it. Third, someone is paying me for it.

The problem with Android in this context is that from my personal experience most Android users aren't willing to actually pay for software. If I only wanted to write software for my personal use, this would be fine. But the motivation to make an app really great is mostly gone once it works for me on my personal devices. In my opinion, this is the case for a lot of Android software: Developers create a software and maintain it until it works okay but don't go the hard last 10% of making the software really great. Which is bad for users because there isn't much great software - even if they were willing to pay.

If I wanted to sell my software, I would definitely go for Apple and the App Store because most Apple and iOS users I know are more willing to pay for software than Android users. As stated here, writing Android software and really supporting all available Devices can be a PITA:

On the smartphone side alone, there are a number of screen resolutions (QVGA, WQVGA, VGA, WVGA, FWVGA, and now qHD), a number of processor clock speeds made from various different companies all with varying graphics capabilities (Qualcomm, Texas Instruments, NVIDIA, Freescale, Samsung, and others), and various memory and storage space configurations. On iOS, there is only one iPhone, and several generations of the product available and usually developers target the most recent two or three generations of the iPhone to ensure broad compatibility.

If you are writing software for someone else and getting paid for it, the choice between Android and iOS is most likely made by your customer. From my personal experience, most customers want iOS apps. After that, they maybe want an Android app. But this is only my limited personal impression and could be wrong ...

In my opinion, to really fix the Android platform, Google and the OHC need to:

• fix the market and fix its search
• add fast UI rendering and provide good UI widgets to further improve user experience
• apply pressure to hardware vendors so they guarantee softwares for some time
• do something to prevent the kind of device fragmentation the platform suffers from today
• at least make sure that the integrated apps and the ones from Google itself are great - others will follow

Conclusion

I was an Android user for quite some time and don't regret it. But honestly: Android devices aren't able to compete with the iPhone in the same market segment. iOS is mostly much more fun to use, the platform itself is more mature, there is a ton of really well implemented apps and the iPhone4 itself is just a great device.

Of course, Android is more open than iOS and there are things an Android device can do which are just not possible or forbidden by Apple on iOS. But know what? - These corner cases don't bother me any more. I've been using my iPhone for a few months now. Even in the first days I was able to do more useful stuff with it than I ever did on Android in almost two years. At the moment I'm really pleased with the experience on iOS, but I'm also curious if this is the case in two years from now.

My recommendation: Buy an Android phone if you want a smartphone that works and does its job. Buy an iPhone if you care about user experience and want a smartphone that works really well.

Today, Dominik Hübner, Thomas Maier and I did a presentation covering the VP8 video codec used by the WebM-Project which was started by Google. Here are our slides:

As some of you might know, I recently finished my Bachelor of Science in Computer Science and Media. Since it was a very interesting topic, I choose to write a Bachelor thesis covering realtime web applications and the challenges of scaling them.

Abstract

If you're interested: Here is the abstract:

Over the last few years we watched a paradigm shift from static content provided by a few entities to dynamic, user generated content. This content is no longer generated by only a few chosen ones. It is now generated by virtually everybody. Users no longer look at websites every few hours but want to know instantly if there are any news. They also expect, that content they create is visible to their peers instantly.

To fulfill this need for instant updates, more and more websites added dynamic content loading. They changed from websites which provided content to web applications with desktop like features. The next logical step was the transition to “realtime web appli- cations” which allow much faster updates. This generation of web applications will not only enable developers to create realtime collaboration and communication applications but also provide a basis of fast browser based games.

This thesis will discuss the current state of realtime web applications, the need for high performance application servers and design patterns to handle a huge amount of clients with persistent connections to the server.

Long story short: Here is the document.

The Idea

A few months ago, Momo came up with an idea to manage contact data in a decentralized and distributed way. The plan was to provide a simple interface to manage and distribute contact data using HTTP. Some weeks ago he finished his bachelor thesis on this topic.

The Project

After some discussions with Momo, I decided to implement his protocol specification. Fortunately, I had the possibility to do this as a software project at my university. The project was mentored by Prof. Kriha.

The implementation itself was done using Scala, Lift and MongoDB.

Abstract

For those of you who don't want to download the whole documentation, here's an abstract:

We all live in times of digital communication: Almost everybody is reachable via cellphone, instant messaging or email. Not only the communication itself evolved but also the communication channels increased dramatically. Some people have multiple email addresses, instant messaging accounts and profiles on several social networks. It is virtually impossible to keep track of all the information available. To address these problems, Moritz Haarmann came up with an idea of a system which is able to manage contact data in a distributed and convenient way. The result of this idea was a protocol proposal which enables users to manage their address data so they can just stop worrying about it. This documentation describes the implementation details and design decisions made to create an usable software which uses the protocol defined by Moritz.

Documentation

I've also written a documentation which describes the protocol specification, some implementation details and the technology used. Have fun with it.

Ich habe gerade diese Präsentation, die während einer Datamining-Vorlesung im letzten Semester entstanden ist, wieder gefunden. Diese wollte ich euch nicht vorenthalten.

In the last few months, I've created two stupid, but funny rules:

1. “If you are able to construct a sentence which contains 5+ buzzwords, you are allowed to terminate it with 'BITCH!'”
2. Is related to Godwins Law. “As an online discussion grows longer, the probability that someone applies a 'yo momma joke' approaches one. Once this occurs, the discussion is over and the one who made the joke wins - but only if it was a really funny joke!”

Nachdem diverse Leute gute Erfahrungen damit gemacht haben, habe ich mich spontan dazu entschlossen in diesem Blog ebenfalls Flattr zu integrieren.

Was ist Flattr?

Die Wikipedia meint dazu folgendes:

Jeder bei Flattr registrierte Nutzer kann bei dem Dienst eine selbstgewählte Summe einzahlen, die er monatlich für Internet-Inhalte ausgeben möchte. Das Minimum für einen Flattr-Beitrag sind monatlich 2 Euro. Danach kann der Flattr-Nutzer auf jeder Website mit dem Flattr-„Spendenknopf“ entscheiden (siehe rechts), ob er für diesen Inhalt bereit ist zu bezahlen. Am Ende des Monats wird die Anzahl der Klicks addiert und die monatliche Summe des Nutzers gleichmäßig auf alle geklickten Inhalte verteilt.

Flattr in S9Y integrieren

Um Flattr-Buttons unter den Artikeln einzufügen, kann man das Flattr Plugin für S9Y verwenden. Da ich zudem noch einen Button in der Sidebar haben wollte, musste ich mir hier selbst behelfen: Bei den Sidebar Plugins für S9Y findet man das Plugin “Language-Specific HTML Nugget”. Mit diesem Plugin lässt sich der HTML-Code für einen Flattr-Button einbauen. Bei mir sieht das Ganze dan in etwa so aus:

Weitere Optionen findet man in der Dokumentation der Flattr-API

Vor ein paar Tagen wurde dieses Blog 5 Jahre alt, und ich hätte es fast schon wieder verschlafen. Ich gelobe hiermit Besserung und kündige hiermit an, dass ein paar neue Posts in der Mache sind.

Da es aktuell aufgrund von Zeitmangel relativ still auf diesem Blog ist und ich aktuell den meisten Content auf Twitter und bei RadioTux produziere, wollte ich auch an dieser Stelle mal ein Lebenszeichen von mir geben und die Slides meiner letzten Präsentation über die Programmiersprache Scala veröffentlichen.

Die Präsentation gibt es hier als PDF zum Download.

Abschließend habe ich noch ein Beispielprogramm erstellt, das den Einsatz von Scala Traits als polymorphe Typen beschreibt:

Ich bin, wie bereits bekannt sein sollte, seit knapp 3 Jahren Besitzer eines Thinpkpad T60. Leider hatte ich hiermit in der Letzten Zeit Probleme mit dem CPU-Frequency-Scaling: Wenn man das Notebook über das Netzteil mit Strom versorgt hat und der Akku entfernt war, wurde die CPU dauerhaft auf ihre minimale Taktfrequenz herunter geregelt. Diesen Zustand hat auch das Tool cpufreq-info bestätigt:

cpufrequtils 006: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 10.0 us.
  hardware limits: 1000 MHz - 1.83 GHz
  available frequency steps: 1.83 GHz, 1.33 GHz, 1000 MHz
  available cpufreq governors: powersave, ondemand, performance
  current policy: frequency should be within 1000 MHz and 1000 MHz
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1000 MHz (asserted by call to hardware).

Nach einer kurzen Suche habe ich im Thinkwiki eine passende Lösung gefunden: Das Anhängen des Parameters "processor.ignore_ppc=1" an die Kerneloptionen im Bootloader. Ein passender Eintrag sollte bei grub ungefähr so aussehen:

Nach dieser Änderung und reinem Neustart des Notebooks skaliert die CPU nun bei Last auch wieder sauber auf höhere Taktfrequenzen:

analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 10.0 us.
  hardware limits: 1000 MHz - 1.83 GHz
  available frequency steps: 1.83 GHz, 1.33 GHz, 1000 MHz
  available cpufreq governors: powersave, ondemand, performance
  current policy: frequency should be within 1000 MHz and 1.83 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1000 MHz (asserted by call to hardware).

Änderungen

Nach Feedback auf den letzten Blogeintrag habe ich mich nochmal an das Feedchecker Script gemacht und ein paar Änderungen eingepflegt:

• Ruby 1.8 Kompatibilität (da ich selbst auf Ruby 1.9 entwickle)
• Vereinfachtes Suchen der Urls durch XPath-Expression
• Konfigurierbare Anzahl der parallel abzuholenden Feeds

Mehr Details gibts in der Commit-History auf github.

Geschwindigkeit

In meinen Tests verwende ich meine Liste mit ca. 160 Feeds. Einmal mit den Standardeinstellungen und einmal mit der Option, dass 10 Feeds parallel abgeholt werden.

Zuerst ein paar Vorbereitungen:

Mit Standardeinstellungen:

Mit 10 Threads:

Mit 10 Threads und aggressiveren Timeouts von 20 statt 60 Sekunden:

Viel Spaß damit und ein frohes Fest euch allen!

Was tun mit riesigen Feedlisten?

Es geht wahrscheinlich vielen so: Man sammelt im laufe der Jahre hunderte Feeds in seiner Liste ohne nun wirklich zu wissen welche noch aktuell sind und welche nicht. In der letzten Zeit hatte ich genau aus diesem Grund mal wieder das Bedürfnis meine RSS-Feeds auszumisten. Da ich ein fauler Mensch bin und eigentlich keine Lust habe hunderte von Feeds "von Hand" zu prüfen, habe ich ein kleines Tool geschrieben, das mir dabei hilft kaputte, nicht erreichbare oder verwaiste Feeds zu entdecken.

Das Tool

Das Tool wurde in ruby geschrieben, ist frei unter der GPLv2 verfügbar und hoert auf den nicht besonders kreativen Namen feedchecker. Um es zu benutzen ist das Trollop-Gem sowie das Peach-Gem notwendig. Dieses lassen sich einfach mittels "gem install trollop" sowie "gem install peach" installieren.

Update: Unter Debian scheint das SSL-Plugin nicht mit der normalen Ruby-Installation mit installiert zu werden. Darum sollte es noch mittels "aptitude install libopenssl-ruby" nachinstalliert werden.

Verwedung

Da das Tool nicht viel kann, haellt sich die Komplexitaet der Optionen in Grenzen:

Mit einem Aufruf des Scripts lässt sich zumindest die Liste der zu prüfenden Feeds stark eingrenzen.

Eventuell hat ja ausser mir noch jemand eine Verwendung dafür. Falls ja ist dies mein Weihnachtsgeschenk an euch.

Der Ingo hat mich vor ein paar Tagen dazu eingeladen bei Radiotux etwas zu Google Wave zu erzählen.

Letzten Donnerstag war es dann so weit und ich war bei radiotux@horads zu Gast und habe mich etwas an der Diskussion beteiligt. Leider sind wir aus unterschiedlichen Gründen nicht mehr zu Wave gekommen. Das wird dann wahrscheinlich in einer anderen Sendung nachgeholt.

Sollte sich also jemand dafür interessieren was der Herr aus roothausen so zu erzählen hat: Hört euch den Podcast an.

... bringen nichts. Als Beweis hier mal ein paar Fotos der Haltestelle Stuttgart Universität. An dieser Stelle sollte noch erwähnt werden, dass hier auf beiden Seiten der Haltestelle mehrere Kameras hängen ...

Eigentlich wirkt das Bisschen Farbe auch erfrischender als die Werbeplakate, die da rumhängen. Aber das ist dann eher Geschmackssache.

Vor kurzem hatte ich das Bedürfnis Bilder automatisiert, mit Hilfe eines Ruby-Scripts, zu verkleinern. Dieses Script sollte zudem ohne Änderungen sowohl auf Linux als auch auf Windows lauffähig sein.

Fuer diese Aufgabe ist Imagemagick natürlich ein super Werkzeug, da man es auch als Bibliothek von Ruby aus nutzen kann und auch für Windows verfuegbar ist. Unter Windows ist hierfür eine Installation von Ruby, sowie die Installation von Imagemagick und dem passenden RMagick Ruby-Gem notwendig. Unter Linux reicht es Imagamagick und Ruby mit dem Paketmanager seiner Wahl zu installieren und mittels "gem install rmagick" das Gem zu installieren.

Der eigentliche Code gestaltet sich relativ simpel. Prinzipiell lässt sich ein Bild mit wenigen Anweisungen verkleinern:

Die Methode resize_to_fit() sorgt hier für das Verkleinern auf bestimmte Maximalwerte in Länge und Breite. Weiteres erfährt man aus der Doku.