Nichts als die Wahrheit

27. März 2010

Hello Android!

Filed under: Android, Entwicklung, Tutorial, ubuntu — Argeleb @ 16:41

Schritt 1: Installation des Android SDK

Um Android Anwendungen entwickeln zu können ist es nötig ein Android SDK zu installieren. Auf der Web-Site des Android Projekts gibt es die Auswahl, für welches Betriebssystem man das SDK herunterladen möchte. Leider gibt es keine Version für 64 Bit Linux, daher muss man das 32 Bit SDK herunterladen.

Glücklicherweise wird auf der Installationsseite genau beschrieben, welche Software man auf einem Ubuntu-System installieren muss, damit das Android SDK verwendet werden kann. Vor allem muss man die 32 Bit Unterstützung, Sun-Java und Eclipse installieren:

apt-get install ia32-libs

apt-get install sun-java6-bin

Da leider in den Ubuntu-Repositories keine aktuelle Eclipse Version angeboten wird, sollte man Eclipse direkt von der Eclipse-Download Seite herunterladen, denn für die Android Development Tools (ADT) wird mindestens Eclipse 3.4 vorausgesetzt.

Nachdem nun alle Voraussetzungen erfüllt sind, kann das Android Starter Package für Linux heruntergeladen werden und anschließend in einem beliebigen Verzeichnis entpackt werden:

tar xvzf android-sdk_r05-linux_86.tgz

Das Basis Verzeichnis des SDK befindet sich dann unter android-sdk-linux_86

Mit dem Starter Package hat man allerdings noch kein vollständiges SDK. Um die Installation zu vervollständigen muss der Android SDK and AVD Manager aufgerufen werden:

<sdk-verzeichnis>/tools/android

Android SDK Manager mit ausgewählten Paketen für das Android SDK 2.1

Unter den Available Packages finden sich alle Versionen des Android SDK. Für die Zwecke dieses kleinen Einführungsbeispiels dürfte die Version nicht relevant sein, daher kann man ruhig die aktuellste Version, hier die Version 2.1 installieren. Nach einem Klick auf Install Selected lädt der SDK Manager die benötigten Dateien herunter und installiert sie. Vorher muss man noch den Lizenzbestimmungen für die einzelnen Komponenten zustimmen.

Schritt 2: Installation der Android Developer Tools

Für die Entwicklung von Android bietet sich Eclipse an, da es sich bei Android Anwendungen um Java Programme handelt. Um Android Anwendungen mit Eclipse zu entwickeln, müssen die Android Developer Tools (ADT) installiert werden. Hierfür gibt es die Update-Site des Android-Projekts: https://dl-ssl.google.com/android/eclipse/

Dazu öffnet man in Eclipse den Update-Manager unter Help/Install New Software. Dort fügt man dann die oben genannte Update-Site hinzu:

Eintragen der Update-Site des ADT in Eclipse

Anschließend kann man dann die Developer Tools auswählen und installieren:

Installation der Developer Tools

Schritt 3: Ein erstes Programm

Bevor wir ein erstes Programm entwickeln, müssen wir noch die Testumgebung einrichten. Wir benötigen ein virtuelles Gerät (Android Virtual Device (AVD)), auf dem wir die Software laufen lassen können, doch zuvor müssen wir Eclipse noch mitteilen, wo sich das Android SDK befindet.

  1. In den Android Preferences (Window > Preferences > Android) muss das SDK-Basis-Verzeichnis eingetragen werden:

    Einstellung des SDK Pfades

  2. Starten des Android SDK and AVD Managers (in Eclipse unter Window > Android SDK and AVD Manager)
  3. Anlegen eines neuen Virtual Device
  4. Wir geben dem Gerät den Namen TestDevice, und als Target wählen wir Android 2.1 – API Level 7 aus:

    

    Erstellen eines neuen Virtual Device

  5. Nachdem das virtuelle Gerät angelegt ist, können wir ein erstes Projekt erstellen

Erstellen eines Android Projekts

In Eclipse kann nun mit dem Android Projekt Assistenten ein neues Projekt erstellt werden (File > New > Android Project):

Android Projekt Assistent

  1. Als Name wählen wir android.hello (dabei handelt es sich um den Eclipse-Projektnamen)
  2. Als Application name stellen wir Hello Android ein
  3. Der Package Name muss aus mindestens zwei Identifiern bestehen, warum das so gefordert wird, ist mir jedoch unklar. Aber es ist sowieso gute Praxis, einen Pacakge Namen wie hier anzugeben: com.wordpress.argeleb.android.hello
  4. Wir erzeugen eine Activity, da diese in den allermeisten Fällen erstellt wird, auch wenn sie optional ist. Der Assistent generiert eine Klasse, die von der Android Klasse Activity abgeleitet ist.

Der Assistent ist so freundlich und hat bereits eine GUI-Datei angelegt, in der der Text Hello World, HelloActivity zu lesen ist:

Jetzt kann man bereits diese rudimentäre Anwendung ausführen, indem man im Kontextmenü des Projekts den Punkt Run As > Android Application auswählt. Nach eine gewissen Ladezeit des Emulators erscheint dann folgendes Bild:

Android Emulator mit geladener Hello World Anwendung

Das war’s im Prinzip. Viel Spaß beim herum experimentieren!

Weiterführende Literatur findet sich auf den Entwickler-Seiten des Android Projekts.

19. Februar 2010

KDE Tutorial: Teil 3, Qt Exkurs

Filed under: C++, Entwicklung, KDE, Open Source, Tutorial — Argeleb @ 19:56

In diesem dritten Teil möchte ich ein wenig auf die Details des Qt-Framworks eingehen. Das Qt-Programm, das ich entwickelt habe ist ein GUI für einen sehr speziellen Aufruf des Kommondozeilen-Programms mencoder. Dieses erste Program hat keine KDE Bestandteile, sondern ist ein pures Qt-Program, das mit Hilfe der IDE QtCreator entwickelt wurde.

Ich habe auf der Projektseite alle Dateien, auch die generierten Dateien eingecheckt.

Leider ist es nicht so leicht möglich, hier mit WordPress Quelltexte vernünftig zu formatieren, daher habe ich diesen Teil wieder in ein PDF auf der Projektseite (oder auch als OpenDocument) zu dieser Tutorial-Reihe abgelegt. Viel Spass beim Lesen…

23. Januar 2010

Standard statt Vendor-Lock-In

Filed under: Entwicklung, Microsoft — Argeleb @ 12:39

Ein Professor, dessen Namen ich aus Gründen des Persönlichkeitsschutzes nicht nennen möchte, hat während meines Studiums der Informatik einmal etwa folgendes gesagt:

Setzt euch immer für Standards ein, und tut danach alles, um sie zu brechen

Was zunächst nach einem unbedeutendem Witzchen klingt, spiegelt allerdings die Situation wider, vor der wir heute nach wie vor stehen. Dieses Zitat stammt aus den frühen 1990ern!

Was ist ein Standard

Man könnte annehmen, ein Standard wäre eine Norm, die von einem offiziellen Standardisierungsgremium vorgegeben wurde. Solche Gremien und Institute gibt es ja in zahlreichen Ausprägungen: ISO, DIN, IEEE, OASIS, ECMA, IETF, W3C, etc.

Aber das ist nur die halbe Wahrheit. Standards entstehen bereits viel früher, und die Standardisierungsgremien schreiben diese Entwicklungen fest.

Beispiele für einst proprietäre Entwicklungen, aus denen dann Standards wurden:

Weitere Standards:

  • iCalendar (entwickelt von der IETF durch Lotus- und Microsoft-Mitarbeiter)
  • E-Mail (RFC 822)
  • Diverse Grafikformate
  • TCP/IP
  • etc.

Letzten Endes entstehen Standards aus dem einfachen Grund, um Kooperation zu ermöglichen. Daher sind Standards immer ein Kompromiss, oder auch der kleinste gemeinsame Nenner, auf den sich die Marktteilnehmer einigen konnten.

Welche Kriterien muss ein Standard erfüllen, damit man ihn so nennen kann? Folgende Liste könnte man prüfen:

  1. Es muss eine allgemein zugängliche Beschreibung vorliegen
  2. Kein Teil des Standards darf durch Patente geschützt sein
  3. Ein allgemein anerkanntes Institut hat den Standard normiert
  4. Der Standard muss sich auf das wesentliche konzentrieren
  5. Der Standard muss herstellerunabhängig sein
  6. Es sollte mindestens zwei Produkte (unterschiedlicher Hersteller) geben, die den Standard vollständig unterstützen

Was ist kein Standard

Oft werden Gegebenheiten als Standard oder De-Facto-Standard bezeichnet, die allerdings keine Standards sind. Berühmtestes Beispiel ist sicher das .DOC Format von Microsoft. Man nennt sie Standard, weil so gut wie jeder Mensch sie nutzt. Allerdings sind solche Formate oftmals nicht offen gelegt und daher können sie nicht als Standard betrachtet werden.

Nehmen wir mal als Beispiel das Word-Format von Microsoft, und prüfen es anhand der obigen Liste:

  1. Es gibt eine Beschreibung (PDF) des Formats
  2. Das konnte ich nicht überprüfen, da Microsoft über 10000 Patente besitzt, und mglw. betrifft eines davon Details aus dem .DOC-Format
  3. Nein
  4. 210 Seiten dürften das Format erfüllend beschreiben (da fragt man sich, was auf den über 6000 Seiten der OOXML-Spezifikation geschrieben steht. 30mal mehr Funktionen? Ich bezweifle das)
  5. Nein
  6. Das dürfte der Fall sein

In diesem Beispiel hat der „Standard“ nur 4 von 6 Punkten bekommen und man sollte daher dieses Format nicht verwenden.

Wo liegen die Nachteile

Standards sind Kompromisse. Dies hat zur Folge, dass es meist eben nur der kleinste gemeinsame Nenner ist. Verwendet man, als Software-Hersteller, solche Standards, dann muss man oft auf Funktionalitäten verzichten, um nicht die Kompatibilität zum Standard zu verlieren.

Außerdem kann man sich nicht aus der Masse hervorheben, wenn man nur Standards unterstützt, da man ja nur das unterstützt, was sowieso alle unterstützen. Somit werden einem Alleinstellungsmerkmale verwehrt, die möglicherweise zu größerem Erfolg führen könnten.

Was sind die Vorteile

Standards sind gut dokumentiert, da ihre Spezifikation öffentlich zugänglich ist. Das erleichtert die Implementierung einer Software enorm. Standards sind klar umrissen und dadurch nicht sehr umfangreich.

Standards machen die Anwender unabhängig von Anbietern. Wenn man nur E-Mail Software einsetzt, die POP3/SMTP und RFC 822 verwendet, kann man sehr leicht auf einen anderen Client umsteigen. Dasselbe gilt natürlich auch für Office Produktivitätssoftware oder Web-Browser. Sobald man sich in die Falle des Nicht-Standardisierten begibt, ist man auf Gedeih und Verderb einem Hersteller ausgeliefert.

Die Standard-Rowdys

Es gibt immer wieder Unternehmen, die vorgeben, Standards zu unterstützen, diese jedoch nur torpedieren, um ihre eigenen proprietären Erweiterungen durchzudrücken. Das machen diese Unternehmen, um die Wahlfreiheit der Anwender einzuschränken. Denn nichts ist schlimmer für diese Unternehmer, als dass ein Anwender auch eine alternative Software einsetzen könnte.

Leider tut sich in diesem Umfeld Microsoft als der größte Rowdy hervor. Immer wieder versprechen sie Standardkonformität, und brechen sie. Als Beispiel möchte ich Outlook heranziehen. Prinzipiell unterstützt Outlook das iCal Format (nicht zuletzt deshalb, weil Microsoft aktiv an diesem Standard mitgearbeitet hat). Jedoch verhindern „Bugs“ in Outlook, dass bestimmte Kalender importiert werden können. Man könnte jetzt natürlich argumentieren, dass es sich dabei um einen Fehler handelt, den man dem Hersteller erst mal verzeihen muss. Nur leider ist es nicht möglich, Microsoft dazu zu bewegen solche Fehler zu beseitigen. Ein Software-Hersteller, der das iCal Format zum Austausch verwendet, hört dann von den vielen Outlook-Kunden, dass er doch bitte Outlook unterstützen sollte. Das ist jedoch mit dem Standard nicht möglich, also müsste dieser Software-Hersteller das proprietäre Format von Microsoft verwenden, um Outlook vollständig unterstützen zu können.

In der Regel sind gerade kleine mittelständische Software-Hersteller nicht in der Lage, sich gegen solche Argumente zu wehren. Der Kunde sagt: „Das ist Outlook, das ist Standard, und ihre Software hat sich dem unterzuordnen“. Das Gegenargument: „Ja, aber Outlook verletzt den Standard und es ist nicht unsere Schuld“ wird dann mit dem Hinweis auf die hohe Verbreitung von Outlook weggewischt.

Daher würde ich jedem kleinen Software-Hersteller empfehlen, diese Argumente zu ignorieren und auf Standards und Standardisierungsgremien zu pochen. Das ist sicher oft sehr schwer, aber wenn die kleinen Software-Hersteller es nicht machen, werden sie am Ende die Verlierer sein, weil langfristig gerade Microsoft mit seinem Windows/Office-Monopol am längeren Hebel sitzt.

Zum Thema Internet Explorer will ich hier nichts weiter schreiben und verweise hier auf einen Artikel bei golem.

Fazit

Setzt man bei der Auswahl seiner Software-Komponenten konsequent auf Produkte, die sich an Standards halten, so gewinnt man Wahl-Freiheit. Der Preis ist unter Umständen fehlende Funktionalität. Dieser Preis ist jedoch gering, denn am Ende bezahlt man einen Vendor-Lock-In immer sehr teuer (in Form überteuerter Lizenzgebühren oder hoher Migrationskosten)

19. November 2009

KDE Tutorial, Teil 2: Ein erstes Programm mit Hauptfenster

Filed under: C++, Entwicklung, karmic, KDE, linux, Open Source, Tutorial, ubuntu — Argeleb @ 17:03

In diesem zweiten Teil entwickleln wir das erste KDE Programm. Da mir persönlich das Blog-Interface zu wenig Ausdruckmöglichkeiten bietet, habe ich das Tutorial mit OpenOffice geschrieben.

Ausserdem habe ich auf Google Code ein Projekt für das Tutorial angelegt. Dort befindet sich dann auch der Text.

Weiter mit dem Tutorial auf Google Code (PDF)

Referenzen:

18. November 2009

KDE Tutorial, Teil 1: Einrichtung der Entwicklungsumgebung [Update]

Filed under: C++, Entwicklung, karmic, KDE, linux, Open Source, Tutorial, ubuntu — Argeleb @ 09:30

Wenn man sich auf den Seiten des KDE-Projektes nach Informationen zur Entwicklung von KDE-Programmen umsieht, könnte man schnell den Eindruck gewinnen, man müsse die komplette Desktopumgebung kompilieren. Das ist natürlich nicht notwendig. Aber man muss schon ein paar Komponenten installieren, damit man vernünftig arbeiten kann.

Jeder Programmierer ist anders und hat besondere Vorlieben, was Editoren usw. angeht. Hier sei nur KDevelop erwähnt, da es das „natürliche“ Instrument für die KDE-Softwareentwicklung sein sollte. Aber Vorsicht, die Version, die mit Karmic ausgeliefert wird, ist immer noch eine Beta-Version.

Manch einer, allen voran Andreas Pakulat, ist über die Entscheidung der Kubuntu Entwickler, eine Beta-Version in einer stabilen Distribution auszuliefern, nicht sonderlich glücklich. Zum Teil kann ich die Kritik nachvollziehen, allerdings darf sich das KDevelop-Team durchaus auch an die eigene Nase fassen, denn schließlich existiert KDE4 nun schon seit mehr als zwei Jahren, und es gibt immer noch keine stabile Version der Haupt-IDE. So gesehen erzeugt diese Vorgehensweise Druck auf die Entwickler (mal abgesehen davon, dass sie ja jederzeit ein PPA mit der aktuellsten Beta für Ubuntu bereitstellen könnten). So wie es jetzt aussieht, soll KDevelop wohl mit KDE 4.4 fertig werden.

Resourcen

Benötigte Programme und Bibliotheken

Im folgenden habe ich versucht, alle Pakete zusammenzufassen, die man für die Entwicklung benötigt. Da auf meinem Rechner nach mehreren Versuchen bereits alles vollständig installiert war, habe ich eine VM mit nacktem Kubuntu aufgesetzt, und nach und nach alle Pakete installiert, die gefehlt haben. Nichts desto trotz kann es sein, dass diese Liste nicht vollständig ist.

CMake

CMake ist ein plattformunabhängiger Generator für Build-Dateien. Unter Linux werden mit seiner Hilfe Unix-makefiles erzeugt. Statt komplizierte makefiles zu bearbeiten, wird für die Entwicklung von KDE4 Programmen lediglich eine CMakeLists.txt benötigt. Wenn die Vorraussetzungen erfüllt sind, erzeugt cmake alle notwendigen Dateien.

Um cmake unter Kubuntu zu installieren, gibt man auf der Konsole folgenden Befehl ein:

sudo apt-get install cmake

Näheres zu KDE4 und cmake kann man auf der KDE-Techbase nachlesen

Compiler

Um KDE Programme in C++ zu entwickeln, wird der C++ Compiler benötigt, den man mit folgendem Befehl installiert:

sudo apt-get install g++

Anmerkung: Wenn dieses Paket nicht installiert ist, stürzt KDevelop 3.9.95 beim Erzeugen eines neuen Projektes einfach ab.

kdevelop4 (Version 3.9.95)

Dieses Tutorial beschreibt die Entwicklung von KDE4 Programmen unter anderem mit Hilfe des neuen KDevelop4. Mit Kubuntu 9.10 befindet sich die Beta 5 in den Repositories. Folgender Befehl installiert kdevelop:

sudo apt-get install kdevelop

[Update] Statt der veralteten Beta 5 sollte man lieber auf eine aktuellere Version ausweichen. Auf dem Blog von Dr. Danz befinden sich aktuelle PPAs von KDevelop für Jaunty und Karmic

Nachdem man kdevelop startet und versucht ein neues Projekt mit einem Template anzulegen, wird man feststellen, dass kein KDE4-Template vorhanden ist. Das Paket kapptemplate im kdesdk beinhaltet einige Projekt-Templates für KDE:

sudo apt-get install kdesdk

Entwicklungspakete

Folgende Pakete müssen noch installiert werden, damit man KDE4-Programme entwickeln kann:

sudo apt-get install kdelibs5-dev

kdevelop kompilieren

Um mit der aktuellsten Version von KDevelop zu arbeiten, muss das Paket von der KDevelop Homepage heruntergeladen werden. Um KDevelop kompilieren zu können, ist zusätzlich das Entwicklungspaket des KDE-Workspace notwendig, das mit folgendem Befehl installiert werden kann:

sudo apt-get install kdebase-workspace-dev

Nähere Informationen zum Erstellen von KDevelop aus den Quellen können auf der Seite des Projekts gefunden werden.

Bloggen auf WordPress.com.