Der Einstieg in die Android-Programmierung - Tipps und Tricks

[Meishere 53]

Übersicht meiner Tutorials:

Der Einstieg in die Android Programmierung - Das Einrichten

- Der Einstieg in die Android Programmierung - Letzte Vorbereitung

- - Der Einstieg in die Android Programmierung - Hello World

- - - Der Einstieg in die Android Programmierung - Layouts

- - - - Der Einstieg in die Android Programmierung - Tipps und Tricks

--------------------------------------------------------------------------

Hallo und Herzlich Willkommen!

Vorab eine kleine Neuigkeit: Dies hier wird mein letztes Tutorial sein.

Zumindest in der Reihe "Der Einstieg in die Android Programmierung"

Denn, wenn du dich bis hierher durchgearbeitet hast, dann kannst du dich als eingeführt in die hohe Kunst der Android-Programmierung betrachten.

Außerdem ist der Titel jedesmal schon zur Hälfte voll, wenn ich "Der Einstieg in die Android Programmierung" reinquetsche

In diesem Tutorial hier werde ich dir ein paar kleine "Tipps und Tricks" näherbringen, mit denen dir das Programmieren erleichtert wird.

Dementsprechend kann es durchaus passieren, dass ich hier immermal wieder neue Sachen hinzufüge, denn man kann nie genug Tipps haben!

Natürlich bin ich auch offen für Vorschläge, was noch dazugehört.

Ok, fangen wir an:

1. Das Kommentieren:

Das Kommentieren ist eins der wichtigsten Dinge im Prorgammieren.

Es kommt direkt nach kalter Pizza, Cola und dem eigentlichen Code!

Es kann dazu dienen dir selbst einen besseren Überblick zu verschaffen oder eben auch Partnern oder anderen Programmierern, die den Code in die Finger kriegen, kurz zu schildern was zum Teufel du dir dabei gedacht hast.

Teilweise unterscheiden sich die Programmiersprachen darin, wie kommentiert wird.

Bei Java (also auch bei Android) gibt es im Grunde zwei Varianten.

Die erste Variante, dient vorallem zum kommentieren einzelner Zeilen.

So kannst du zum Beispiel kurze Kommentare ( Merke: zugehöriges Verb: "kommentieren" ) in deinen Code einbauen.

Das kann dann z.Bsp. so aussehen (Beispiel aus dem "Hello World"-Programm):

//Definiert die Klassenvariablen

        Button red;

	Button reset;

	TextView text;

Stell dir jetzt aber mal vor, du hast einen Kommentar der über fünf Zeilen geht. Du müsstest also vor jede Zeile einen "Doppel-Slash" (= // ) machen. Und genau dafür gibt es die zweite Methode. Sie dient dem Einfügen von mehrzeiligen Kommentaren. Von dieser Methode existieren zwei Variationen, die du nach Belieben einsetzen kannst. Du kannst das Kommentar mit /* beginnen, dann vor jede folgende Zeile ein * und schlussendlich mit */ das Kommentar beenden. Aussehen würde das Ganze so:

/*

*Hier wird ein neuer OnClickListener gesetzt.

*Dieser dient dazu, dem Button die Funktion zuzuweisen, auf klicks "zu hören",

*also auf sie zu reagieren.

*Der Text des Buttons wird rot und in "It is RED now!" umgewandelt.

*/

        red.setOnClickListener(new OnClickListener(){


	        public void onClick(View v) {

	        	text.setTextColor(Color.parseColor("#FF0000"));

	        	text.setText("It is RED now!");

	        }

        });

Oder du lässt die Sternchen in den mittleren Zeilen weg, startest einfach mit /* und endest mit */. Aussehen würde das dann natürlich so:

/*

Hier wird ein neuer OnClickListener gesetzt.

Dieser dient dazu, dem Button die Funktion zuzuweisen, auf klicks "zu hören",

also auf sie zu reagieren.

Der Text des Buttons wird rot und in "It is RED now!" umgewandelt.

*/

        red.setOnClickListener(new OnClickListener(){


	        public void onClick(View v) {

	        	text.setTextColor(Color.parseColor("#FF0000"));

	        	text.setText("It is RED now!");

	        }

        });

Wie hier unschwer zu erkennen ist, liegt der Vorteil der "Mehr Sternchen - Methode" darin, dass man eindeutig erkennt, was zum Kommentar gehört. Bei den meisten IDE werden bestimmte Code-Teile farblich hervorgehoben. Kommentare sind dort z.Bsp. oft grün. Wenn jetzt aber jemand deinen Code lesen möchte, der mit einem normalen Texteditor programmiert (Solche Leute gibt es noch?! ), dann wird es dem erheblich schwerer fallen dein Kommentar zu erkennen. Das trifft vorallem zu, wenn du, wie im Beispiel oben, auch noch Wörter aus dem "richtigen" Code (wie OnClickListener) verwendest. Eine wietere wichtige Funktion des Kommentierens ist das "Auskommentieren" von Code. Wenn dir der Compiler keinen Fehler ausgibt und alles fein säuberlich kompiliert hat, du daraufhin die App startest und dann ein "App reagiert nicht"-Fehler auf dich wartet kann das schnell zur ultimativen Frustration führen, denn du musst den Fehler schließlich alleine und ohne Hilfe finden.(Naja... Nicht ganz, aber dazu später mehr ) Auch wenn etwas plötzlich ganz aussieht als erwartet, kann das ziemlich nervig sein. Ein wichtiges Hilfsmittel dabei ist das "Ausklammern". In dem du vor bestimmte Codezeilen einen Doppel-Slash platzierst, wird die betreffende Zeile zu einem Kommentar. Das hat zur Folge, dass diese Zeile beim Kompilieren ignoriert wird. Sollte dein Programm daraufhin funktionieren, kannst du eingrenzen worin dein Fehler liegt. Nämlich in der/den betreffenden Zeile/n. Ein kleines Beispiel:

public class Kommentieren extends Activity {


	TextView text;

    /** Called when the activity is first created. */

    @Override

    public void onCreate(Bundle savedInstanceState) {

        super.onCreate(savedInstanceState);

        setContentView(R.layout.main);

        text = (Button) findViewById(R.id.text);


    }

}

Hier ist natürlich auf den ersten Blick der Fehler zu erkennen. Der TextView "text" kann natürlich nicht später im Code plötzlich als "Button" aufgerufen werden. Aber mal angenommen du hast gerade einen (realistischen) 18-Stunden Arbeitstag hinter dir, der Kaffee ist seit 2 Stunden alle und außerdem warst du gestern noch auf einer Party und hast eindeutig zu viel getrunken. Kurzum: Du siehst viel mehr lustige schwarze Striche anstatt Buchstaben. Und trotzdem willst du diesen blöden Code jetzt noch fertig schreiben. Also was machst du nach einem kleinen Wutanfall, weil das ganze nicht funktioniert? Genau, Fehlersuche! Dafür reicht es hier, die Zeile text = (Button) findViewById(R.id.text); "auszukommentieren".

public class Kommentieren extends Activity {


	TextView text;

    /** Called when the activity is first created. */

    @Override

    public void onCreate(Bundle savedInstanceState) {

        super.onCreate(savedInstanceState);

        setContentView(R.layout.main);

        [COLOR="Green"]//text = (Button) findViewById(R.id.text);[/COLOR]


    }

}

Daraufhin sollte das Programm normal starten.

Dann siehst du dir die Zeile genauer an und änderst sie natürlich sofort in

text = (TextView) findViewById(R.id.text);

um.

Und schon ist der Fehler gefunden.

Das wars eigentlich auch schon zu den Kommentaren.

2. Speichern und Cleaning/Rebuilding

Kommen wir nun zu einem weiteren sehr wichtigen Punkt...

Wenn nicht sogar dem wichtigsten!

Denn wo wäre die moderne Welt ohen die "Speichern"-Funktion?

Genau, und deswegen hier ein sehr wichtiger Tipp:

Speicher so oft wie möglich!

Du musst kurz aufs Klo? Speicher vorher ab!

Du gehst mal schnell was essen? Speicher vorher ab!

Du machst den Computer aus? Auf jedenfall vorher speichern. Wäre sonst schön blöd...

Zusätzlich zum Speichern gibt es einen zweiten sehr wichtigen Punkt.

Undzwar "Clean..." (unter Eclipse).

Zu finden ist dieser Punkt bei Eclipse unter "Project" -> "Clean...".

Hiermit wird euer Projekt "Neugebaut" (Rebuild).

Das bedeutet fehlende Dateien oder Ordner werden erstellt (sofern dies möglich ist) und bestimmte Beziehungen zwischen Dateien werden hergestellt.

Standartmäßig ist das "Auto-Build"-Feature bei Eclipse angestellt, was automatisch diesen Schritt übernimmt, wenn er notwendig ist.

Dann sollte auch beim Speichern jedesmal ein "Rebuild" stattfinden.

Zum Beispiel muss ja jede "Id" aus einer .xml-Datei erstmal in die "R.java" eingetragen werden.

Wenn das nicht passiert, gibt dir Eclipse einen Fehler zurück, wenn du versuchst auf diese ID zu verweisen.

Hier kann dann ein Klick auf "Clean..." das Problem lösen.

3. Debug:

Erinnerst du dich daran, dass ich oben erwähnt habe, dass du nicht ganz auf dich alleine gestellt bist, wenn du einen Fehler suchst?

Hast du seitdem die ganze auf die Erklärung dazu gewartet?

Wenn ja, dann hast du das Glück sie hier geliefert zu kriegen

Die Rede ist natürlich vom "Debuggen".

Das Wort Debug setzt sich aus der Vorsilbe "De-" und dem Wort "Bug" zusammen.

Bug ist englisch und wäre auf deutsch ein "Käfer".

Die Vorsilbe "De-" ist gleichzusetzen mit "Ent-". Also "rückgängigmachen" oder auch "löschen, entfernen".

Also: "Entkäfern"? Was soll das denn bitte sein? Und was hat Programmieren mit Kammerjägern zu tun?

Nun, man kann es kaum glauben, aber eigentlich ist der Programmierer die meiste Arbeitszeit mehr Kammerjäger als Programmierer.

Denn, wenn du erstmal einen ordentlichen Teil an Code geschrieben hast, gehts erst so richtig los.

Jetzt kommen nämlich die Fehler.

Und du, als "Nahezu-Profi", musst dich jetzt an die leidige Aufgabe des "Kammerjagens" oder "Käferjagens" machen. Denn die ganzen kleinen Fehler, die sich wie kleine Käfer in deinem Code eingenistet haben, sind manchmal echt schwer wieder auszubügeln.

Und deswegen hat sich mal ein (wahrscheinlich gelangweilter) Programmierer gedacht: "Hey. Wenn wir schon nach Fehlern, wie nach Käfern suchen, dann wollen wir auch einen eigenen Namen dafür!" Und genialerweise kam er auf die "Entkäferung" oder eben das "Debugging".

[Copyright, "Die Geschichte des Debug, von Meishere" ]

So genug Theorie, Taten warten!

Ich werde dir jetzt ein paar Möglichkeiten zum Debugging aufzeigen.

In Eclipse sind schon verschiedene Debug-Möglichkeiten "eingebaut".

Zum einen wird dir immer der Reiter "Problems" angezeigt.

Hier werden aller Fehler angezeigt, die schon vor dem Kompilieren entdeckt werden und dieses verhindern.

Das sind alle Fehler, die dir auch direkt im Code angezeigt werden (z.Bsp. Tippfehler oder falsche Verwendung von Wörtern).

Daher ist dieser Reiter erst wirklich sinnvoll, wenn es sich um größere Projekte handelt, bei denen der Code so lang ist und die so viele Dateien enthalten, dass man nicht einfach mal eben zur betreffenden scrollen kann.

Der nächste Reiter ist die "Javadoc".

Zwar wird dieser Reiter eher weniger zum Debug genutzt, trotzdem stelle ich ihn dir kurz vor.

Im Grunde ist das einfach ein "schlaues Buch".

Wenn du z.Bsp. im Code einen Button hast und das Wort "Button" ankilckst, dann wird dir in diesem Reiter die allgemeine Definition, eine kurze Erklärung und weiterführende Links zum Thema "Button" unter Android angezeigt.

Die Javadoc ist jedoch auf Englisch. Als Programmierer solltest du aber sowieso über halbwegs vernünftige Englischkenntnisse verfügen

Und direkt weiter zum nächsten Reiter "Declaration".

Dies dient schon eher dem Debugging, denn hier wird dir (wie der Name schon sagt) die Deklaration der jeweils ausgewählten (markierten, angeklickten) Variable, Klasse etc. angezeigt. Das heißt, worauf sich z.Bsp. eine Variable bezieht. Ein kleines Beispiel zur Verdeutlichung (Entnommen aus dem "Kommentieren"-Projekt von oben):

Hier ist jetzt gerade das "text" in der Zeile

"text = (Button) findViewById(R.id.text);"

markiert.

In diesem Reiter wird dir jetzt angezeigt, dass diese Variable oben als "TextView text;" deklariert wurde.

Nun hast du also dir Gewissheit, dass es sich tatsächlich um einen Textview handelt

Und der letzte Reiter, der hier immer angezeigt wird, ist der Reiter "Console".

In diesem Reiter wird dir gezeigt, was Android "gerade macht".

Also z.Bsp. wann deine App installiert wird, wann sie gestartet wird oder wann eine bestimmte Activity gestartet wird.

Die Konsole kann gut genutzt werden, um sich eine Übersicht darüber zu verschaffen, was wann stattfindet.

Ähnlich, nur umfangreicher ist "LogCat".

Das wird bei mir ausgespuckt, wenn ich versuche das Programm von oben zum Laufen zu bringen.

Das Lesen solch eines Logcats ist eigentlich eine Kunst für sich.

Oft kannst aber auch du als Normalsterblicher an bestimmten Stellen im Logcat deinen Fehler finden.

Und notfalls gibt es da draußen in den Weiten des Internets immer ein paar Irre, die dir gerne helfen dein Logcat auszuwerten.

Bei diesem Beispieil könntest du in Teile 2 den Text

"07-12 21:35:45.990: E/AndroidRuntime(4884): java.lang.RuntimeException: Unable to start activity ComponentInfo{com.Tutorial.Kommentieren/com.Tutorial.Kommentieren.Kommentieren}: java.lang.ClassCastException: android.widget.TextView cannot be cast to android.widget.Button" lesen.

Das ist auf den ersten Blick wohl ziemlich viel zusammengewürfelter Text, aber eigentlich ist das gar nicht so schwer zu verstehen.

07-12: Klar, das ganze wurde am 12 Juli ausgeführt.

21:35:45.990: Das ist eine Zeitangabe, inklusive Millisekunden. In so einem Smartphone laufen die Prozesse teilweise so schnell ab, dass man da mit Sekunden nicht weit kommt

E/AndroidRuntime(4884): Es handelt sich um einen Fehler (engl. Error). Genauer gesagt um einen AndroidRuntime-Fehler im Prozess 4884. Das bedeutet ein Fehler, der während der Laufzeit (engl. Runtime) des Programms entstanden ist.

java.lang.RuntimeException: Der Begriff der RuntimeException ist ein sehr wichtiger Begriff innerhalb Javas. Das bedeutet, dass es sich um eine Exception (zu deutsch: Ausnahme [= Fehler]) während der Laufzeit des Programms handelt. Eigentlich fallen also fast alle Fehler, die du in deinem Code machst und die erst auftreten, wenn das Programm gestartet ist, in diese Kategorie.

Unable to start activity ComponentInfo{com.Tutorial.Kommentieren/com.Tutorial.Kommentieren.Kommentieren}: Das Programm kann aus dem nachfolgenden Grund die Activity nicht starten.

java.lang.ClassCastException: Der Grund ist eine "ClassCastException". Also eine "Ausnahme die beim "Umwandeln" einer Klasse" entstanden ist.

android.widget.TextView cannot be cast to android.widget.Button:

Und schlussendlich noch, was denn nicht "umgewandelt" werden kann.

In diesem Fall, kann eben ein TextView (android.widget.TextView) nicht als Button (android.widget.Button) genutzt.

Siehst du, wenn man das ganze so auseinander zieht, dann ist es auch gar nicht mehr so schwer den Fehler zu finden.

Und mit Logcat hat man deshalb auch nahezu DAS ultimative Tool zur Schädlingsbekämpfung

Damit möchte ich dieses Tutorial (für heute) auch abschließen.

Das hat sich ja doch wieder ganz schön in die Länge gezogen (vorallem auch weil ich ein paar ungewollte Pausen einlegen musste... Tja, Gespräche im Real Life können schon nervig sein ).

Jedenfalls danke ich dir, dass du bis hierhin gelesen hast und hoffe dass du mit meinen Tutorials nun erstmal eine Basis hast, auf der du aufbauen kannst.

Keine Sorge, es werden weitere Tutorials meinerseits folgen, sodass du auch noch fortgeschrittenere Dinge kennenlernen wirst.

In diesem Sinne noch einen schönen Abend, Morgen, Tag oder Nacht,

Meishere

bearbeitet July 12, 2012 von Meishere

[Swissdroid 1.219]

Und wieder was gelernt

Vielen Dank Meishere

Und nicht vergessen Weltherrschaft und so xD

[Meishere 53]

Schön dass du was lernen konntestv;)

Und natürlich... ich finde wir sind auf dem besten weg

Gesendet von meinem Galaxy Nexus mit Tapatalk 2

[Thyrius 33]

Die Rede ist natürlich vom "Debuggen".

Das Wort Debug setzt sich aus der Vorsilbe "De-" und dem Wort "Bug" zusammen.

Bug ist englisch und wäre auf deutsch ein "Käfer".

Die Vorsilbe "De-" ist gleichzusetzen mit "Ent-". Also "rückgängigmachen" oder auch "löschen, entfernen".

Also: "Entkäfern"? Was soll das denn bitte sein? Und was hat Programmieren mit Kammerjägern zu tun?

Nun, man kann es kaum glauben, aber eigentlich ist der Programmierer die meiste Arbeitszeit mehr Kammerjäger als Programmierer.

Denn, wenn du erstmal einen ordentlichen Teil an Code geschrieben hast, gehts erst so richtig los.

Jetzt kommen nämlich die Fehler.

Und du, als "Nahezu-Profi", musst dich jetzt an die leidige Aufgabe des "Kammerjagens" oder "Käferjagens" machen. Denn die ganzen kleinen Fehler, die sich wie kleine Käfer in deinem Code eingenistet haben, sind manchmal echt schwer wieder auszubügeln.

Und deswegen hat sich mal ein (wahrscheinlich gelangweilter) Programmierer gedacht: "Hey. Wenn wir schon nach Fehlern, wie nach Käfern suchen, dann wollen wir auch einen eigenen Namen dafür!" Und genialerweise kam er auf die "Entkäferung" oder eben das "Debugging".

[Copyright, "Die Geschichte des Debug, von Meishere" ]

haaahaaaa... muahaaaa... *kringel auf boden*

wie geil... Das ist ja noch geiler, als das, was unser Lehrer (siehe Beitrag) gebracht hat. Das ist wohl nur HAMMAAAAAA...

Werde mir erlauben, Deine Definition (mit CR-Hinweis natürlich) huete im Hörsaal zu veröffentlichen...

Deine Arbeit muss mal öffentlich gewürdigt werden...

*brüüüüüüüüüllllllllllllll*

Danke nochmals, ich hab selten so einfach so schnell so viel gelernt... mit Bauchweheffekt... rofl

[Meishere 53]

oha... ich freu mich echt über das positive feedback

wenn ichs richtig verstehe, dann schaffst mein text vor mir an die uni, ja? xD

tja... so kanns gehen

echt cool, dass es dir gefällt... und welch eine ehre, dir offenbar schneller etwas beigebracht zu haben als dein lehrer

ich möchte eigentlich unbedingt noch mehr tutorials rausbringen, nur ist das schon immer relativ viel arbeit...

naja, mal sehen... klausurzeit ist bald vorbei... dann kann ich eventuell ein paar stunden zeit aufbringen

seid gespannt!

bis dahin (oder auch früher ),

Meishere

Gesendet von meinem Galaxy Nexus mit Tapatalk 2

[Thyrius 33]

Einige lustige Teile davon gehen mit ja... Vor allen die megageile Definition vom Debuggen.

Wie gesagt, der Wunsch war schon lange da. Du "gabst mir den Rest"... Lol

Gesendet von meinem LG-P990 mit Tapatalk 2

[Meishere 53]

haha... schöne sache...

ich wünsch dir auf jeden fall viel erfolg

jetzt muss ich erstmal schön "schule-hocken" spielen

Gesendet von meinem Galaxy Nexus mit Tapatalk 2

[Thyrius 33]

Danke sehr. Ich sitze auch bereits im Zug. In 20 Minuten gehts auch los...

Gesendet von meinem LG-P990 mit Tapatalk 2

[PapaNappa 8]

Die Rede ist natürlich vom "Debuggen".

Das Wort Debug setzt sich aus der Vorsilbe "De-" und dem Wort "Bug" zusammen.

Bug ist englisch und wäre auf deutsch ein "Käfer".

Die Vorsilbe "De-" ist gleichzusetzen mit "Ent-". Also "rückgängigmachen" oder auch "löschen, entfernen".

Also: "Entkäfern"? Was soll das denn bitte sein? Und was hat Programmieren mit Kammerjägern zu tun?

Nun, man kann es kaum glauben, aber eigentlich ist der Programmierer die meiste Arbeitszeit mehr Kammerjäger als Programmierer.

Denn, wenn du erstmal einen ordentlichen Teil an Code geschrieben hast, gehts erst so richtig los.

Jetzt kommen nämlich die Fehler.

Und du, als "Nahezu-Profi", musst dich jetzt an die leidige Aufgabe des "Kammerjagens" oder "Käferjagens" machen. Denn die ganzen kleinen Fehler, die sich wie kleine Käfer in deinem Code eingenistet haben, sind manchmal echt schwer wieder auszubügeln.

Und deswegen hat sich mal ein (wahrscheinlich gelangweilter) Programmierer gedacht: "Hey. Wenn wir schon nach Fehlern, wie nach Käfern suchen, dann wollen wir auch einen eigenen Namen dafür!" Und genialerweise kam er auf die "Entkäferung" oder eben das "Debugging".

[Copyright, "Die Geschichte des Debug, von Meishere" ]

Also ich finde den wahren Ursprungs des Begriffs lustiger...

[Thyrius 33]

hmmm... ne Motte aus 1947 als Systemlahmleger... sehr lustig... hehe

[Meishere 53]

hmmm... ne Motte aus 1947 als Systemlahmleger...

Obwohl der Begriff "Bug" in dem Zusammenhang natürlich noch viel älter ist

Gesendet von meinem Galaxy Nexus mit Tapatalk 2