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.

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.

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.

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.

Medianight

Morgen, am Donnerstag den 02.07.2009 wird an meiner Hochschule wieder die Medianight stattfinden. Hier werden die Studenten ihre Projekte des letzten Semesters praesentieren. Ich werde dort unter anderem mit meinem eigenen Projekt am Start sein.

YAXIM

Wie schon zuvor gesagt, werde ich zusammen mit Chris unser Semesterprojekt, das den Namen YAXIM traegt, vorstellen. YAXIM steht fuer "Yet Another XMPP Instant Messenger" und ist ein Jabberclient fuer die Android-Plattform. Als kleinen Vorgeschmack folgen hier noch unsere Folien und das Video der heutigen Praesentation:

Fuer diejenigen, die es nicht auf den LinuxDay geschafft haben, moechte ich nun noch unsere Slides zum Thema OpenWRT veroeffentlichen:

Hier gibt es die Praesentation auch noch als PDF

Wie bei manchen anderen Kleinigkeiten haben sich bei mir ein paar der Tools aus dem Android-SDK geweigert auf meinem 64Bit Arch Linux zu starten. Anscheinend fehlten ein paar Bibliotheken. Ich versuche hier mal zusammenfassend zu beschreiben, wie ich es zum laufen bekommen habe.

SDK installieren

Da das PKGBUILD aus dem User-Repository zum einen keine Abhaengigkeiten enthaellt und zum anderen nicht aktuell ist, habe ich mich dazu entschlossen eine modifizierte Version zu verwenden:

PKGBUILD

Wie man sieht, werden die *swt*-Komponenten des SDK durch native 64Bit Versionen ersetzt. Darum ist es auch notwendig zuvor das SWT-Paket zu installieren.

android.sh

Installation

Das Erstellen und Installieren des Pakets kann nun wie gewohnt mit makepkg vorgenommen werden. Mit diesem Setup sollten dann auch die Tools fuer Eclipse wieder wie gewohnt laufen.

Wie ich bereits gestern versprochen hatte, bekommt ihr nun hier die Slides meiner Praesentation ueber Design Patterns in Ruby:

Hier gibt es das Ganze auch noch als PDF. Den SourceCode findet man hier

Ein Kommilitone von mir hat heute die Ergebnisse seines letzten Semesterprojekts oeffentlich gemacht. Darum moechte ich hier mal etwas Werbung fuer das coole Projekt machen:

camstick is a symbiosis of camera and joystick to symbolize you that you can not only use your webcam for simple video chats but for interacting with your computer using your webcam. Camstick is started as a project work of mine at the Stuttgart Media University. Now i want to share my result with you!

Nach langer Wartezeit wurde nun der von mir genutzte und fuer Arch Linux gepflegte Feedreader newsbeuter in der Version 2.0 freigegeben. Die Liste der Neuerungen liesst sich bisher sehr gut:

• Added more flexible dialog handling
• Improved position handling in article list (fixes #112; thanks to Isaac Good)
• Fixed a lot of bugs (#102, #111, #117, #130, #131).
• Added ability to specify a list of OPML URLs when using OPML as URL source.
• Added config option "keep-articles-days" to optionally keep articles only for a limited number of days.
• Added config option "bookmark-interactive" to indicate that the configured bookmarking command is interactive.
• Don't display authentication information in URLs (fixes #121).
• Replaced mrss with new RSS/Atom parser.
• Added ability to search for text from the article view.
• Added basic support for Yahoo Media RSS.
• Made article view pager configurable.
• Improved HTML rendering of links and underlined and bold text.
• Added ":source" commandline command to (re)load configuration files.
• Implemented "pipe-to" key to pipe articles to external commands.
• Implemented backtick evaluation for configuration files.
• Extended filter language with "between" operator.
• Added "age" attribute for articles to filter them for relative age (in days).
• Extended "set" commandline command to toggle boolean variables and reset configuration variables of all types to their default.
• Added ability to configure local files as feeds.
• Added a "random-unread" key to go to a random unread article.
• When opening articles from a search result dialog, make search phrase stand out in article view.
• Persist commandline and search history.
• Implemented commandline completion.
• Improved help dialog so that it now shows unbound functions.
• Added ability to sort feed list and article list by interactively choosing the sort method.
• Improved and extended conditional HTTP download handling.

Ich habe gerade die Arbeiten am PKGBUILD fuer Arch Linux fertig gestellt und dieses in AUR hochgeladen. Ich wuensche euch viel Spass damit!