Android Source Code einfach in Projekten einbinden

 Android, Entwicklung  Kommentare deaktiviert für Android Source Code einfach in Projekten einbinden
Apr 162012
 

Bei meinen Experimenten mit der Android Entwicklung stiess ich immer wieder auf das selbe Problem. Android ist Open Source aber der Debugger konnte nie in den Source rein springen. Ist auch logisch, denn den müsste ich zuerst runterladen.

Um es richtig zu machen müsste ich den Source Code für alle Versionen runterladen. Irgend wie nicht praktikabel.

Auf den Webseite von Lars Vogel gibt es einige Tutorials zu Android. Eines davon beschäftigt sich mit dem organisieren des Android Source Codes. Eine Lösung ist klassisch via Git. Die Andere via, und das finde ich absolut cool, einem Eclipse Plug-In.

Dieses Plug-In fügt einem Android Projekt automatisch den passenden Source Code hinzu. Auf der Seite sind ein paar andere Plug-Ins zu finden, von Interesse für mich ist zur Zeit nur das Android Sources.

Man füge die Angegebene URL in Eclipse unter “Hilfe -> Neue Software installieren” ein und lade das Plug-In runter. Achtung. Hier ist Geduld angesagt. Das Plug-In ist aktuell 240MB mächtig. Das dauerte so seine Zeit. Und in dieser Zeit tut sich nicht viel. Also Geduld, Eclipse ist nicht abgestürzt oder so. Es dauert halt nur lange.

Neue Software installieren in Eclipse

Wenn man, nach einem Neustart von Eclipse, im Source Code auf eine Klasse des Android Frameworks klickt, und mit F3 in die Definition springt …

Activity Klasse

… sollte in etwa so was hier auftauchen.

Activity Souce Code

Somit ist es also möglich in den Source Code von Android hinein zu debuggen. Cool.

Und einfacher geht es wohl nicht mehr.

PS: Direkt nach dem Neustart von Eclipse konnte ich noch nicht in den Source Code von bestehenden Projekten springen. Aus lauter Frust habe ich mir dann kurz ein neues Android Projekt erstellt. Im neuen Projekt konnte ich dann in den Source Code springen. Danach ging es auch bei bestehenden Projekten.

Okt 242011
 

In den letzten zwei [1] [2] Postings haben wir gesehen wie Ubuntu 11.10 installiert wird und was alles an Paketen auf das System muss.

Jetzt, wo wir alles nötige an Software zusammen haben, werden wir uns an die Einstellungen machen um die Entwicklungsumgebung auch nutzen zu können.

Dazu werden wir uns ziemlich viel im Terminal bewegen. Also starten wir zuerst einmal ein Terminal.

  1. Zuerst prüfen wir ob Python überhaupt läuft. Dazu geben wir am Prompt einfach python ein und drücken “Enter”. Dann sollte etwas in der Form hier erscheinen. Mit exit() können wir Python wieder verlassen.
    Python Test
    In der zweiten Zeile sehen wir das standardmässig Python 2.7 gestartet wird. Und das ist gut so.
  2. Als nächstes verpassen wir dem Datenbankuser postgres ein neues Passwort. Dazu geben wir auf der Konsole folgendes ein.
    sudo -u postgres psql

    Danach sieht der Prompt ein wenig anders aus.
    PostgreSQL Passwort ändern
    Man befindet sich jetzt in der PostgreSQL Umgebung. Dort gibt man nun folgendes ein.

    \password postgres

    Danach wird man nach dem Passwort gefragt. Mit \q verlässt man die PostgreSQL Umgebung wieder.
    Da ich den Tryton Server nicht mit einem speziellen User starten will erfasse ich mein Username noch in der DB.

    sudo su postgres -c "createuser --createdb --no-adduser -P geniali"

    Danach werden noch ein paar Fragen gestellt die man individuell beantworten kann.

  3. Wir erstellen nun im Home Verzeichnis ein neues Verzeichnis. Es scheint sich eingebürgert zu haben dies als workspace zu bezeichnen.
    mkdir ~/workspace
    mkdir ~/workspace/tryton-dist
    cd ~/workspace/tryton-dist

    Danach sollte es in der Konsole in etwa so aussehen.
    Order der Tryton Source

  4. Wir installieren noch hgnested richtig im System. Mit hgnested ist es möglich verschachtelte Repros von Mercurial abzurufen.
    Download hgnested
    Nach dem Download wird das Archiv noch entpackt. Danach gibt man folgendes im Terminal ein.

    cd ~/Downloads/hgnested-0.4/
    sudo python setup.py install
    sudo pip install --install-option="--user" hgnested
    sudo echo -e "[extensions]\nhgnested=" >> ~/.hgrc

    Danach müsste ein hg nclone in etwa wie folgt aussehen.
    Testausgabe von hg nclone

  5. Jetzt laden wir mal den Source Code der Version 1.8 von Tryton runter. Wichtig dabei ist das man im Ordner ~/workspace/tryton-dist steht.
    Client:

    hg clone http://hg.tryton.org/1.8/tryton

    Ausgabe von hg clone des Tryton Clients
    Server:
    Hier laden wir ALLES runter. Jedes offizielle Modul das es bei Tryton gibt. Das dauert dann einen Moment.

    hg nclone http://hg.tryton.org/1.8/trytond

Jetzt müsste es im Verzeichnis tryton-dist zwei Ordner geben. Im Ordner trytond/trytond/modules müsste es etliche Ordner haben.

Verzeichnis mit allen Tryton Modulen

Das wäre dann nicht mal so schlecht. Im nächsten Post werden wir Tryton dann einfach mal starten.

Sep 092009
 

Ich arbeite seit längerem mit dem Blog BlogEngine.NET. Da ich auch Extensions erstelle habe ich auch den Source Code auf CodePlex angezapft. Fast jeden Abend aktualisiere ich die Codebasis.

Das habe ich jetzt etliche male gemacht. Gestern dachte ich mir, komm mach doch wieder mal ein Update auf dem Live Blog. Es scheint ja alles zu funktionieren.

Na ja. Als heute Morgen meine Extension immer noch nur ein Download hatte wurde ich misstrauisch. Ich klickte mal auf den Download. Ups… Fehler.

Dann halt mal einen älteren Download. Ups… Fehler.

Heute Abend dann der Stress. Fehlersuche.

Es Zeigte sich dann schnell das am FileHandler Anpassungen gemacht wurden. Nur wurden die wahrscheinlich ungetestet eingecheckt. Ich hab’s dann ungeprüft Live gestellt. #Fail

Na ja. Was lernt man daraus? Was bei dasBlog funktionierte muss nicht auch bei BlogEngine.NET funktionieren. Das heisst wohl ich muss in Zukunft besser testen. 🙁

kick it on dotnet-kicks.de

Aug 122009
 

Seit einiger Zeit läuft mein Blog auf BlogEngine.NET. Ich bin soweit sehr zufrieden. BlogEngine.NET läuft sehr stabil und schnell. Um mein altes Blog, dass auf dasBlog lief, zu migrieren musste ich noch einige Add-Ins neu erstellen. Ich habe sehr viel im dasBlog selber gemacht und das musste natürlich auch mit BlogEngine.NET funktionieren.

Im Internet, bei RTUR.NET, gibt es ein paar sehr gute Postings zum Thema Extension für BlogEngine.NET.
Teil 1, Teil 2, Teil 3 und Teil 4 und noch ein paar mehr.

Ich bin aber nirgends über eine Anleitung gestolpert die einem Zeigt, wie man an den Source Code von BlogEngine.NET kommt. BlogEngine.NET wird auf CodePlex gehostet. Früher war es recht umständlich den Source Code von CodePlex lokal zu synchronisieren. Seit dem auf CodePlex aber SVN unterstützt wird macht es wesentlich mehr Spass.

Ich gehe auch davon aus das du mit Visual Studio, auch Express, oder SharpDevelop (so viel ich weiss sollte man auch damit Extensions erstellen können) umgehen kannst.

Also, hier Schritt für Schritt.

  1. Zuerst besorgst du dir TortoiseSVN. Du findest sogar bei Wikipedia einen Artikel zum Tool. Die Downloads findest du hier. Am besten lädst du dir auch gleich noch das entsprechende Sprachpacket runter.
  2. Danach installierst du TortoiseSVN. Dazu gibt es nicht viel zu sagen. Zuerst TortoiseSVN, dann kommt eventuell ein Neustart des Systems und danach installierst du noch das Sprachpacket. Eventuell ist nach dem Sprachpacket auch noch ein Neustart nötig.
  3. Jetzt erstellst du einen neuen Ordner, den du zum Beispiel BlogEngine nennst.
  4. Im Kontextmenü des Ordners sollte es jetzt einen Menüeintrag mit dem Namen “SVN Auschecken…” geben. Den anklicken.
    TortoiseSVN Auschekcen...
  5. Auf der CodePlex Projektwebseite für BlogEngine.NET findest du im Register Source Code die URL die du im nun erscheinenden Dialog eingeben musst. Du musst die “Subversion URL” nehmen.
    TortoiseSVN URL auf Projekt
  6. Jetzt noch ein Klick auf OK und du darfst staunen. Es dauert einen Moment und danach hast du den aktuellen Source Code auf deinem eigenen PC.
    TortoiseSVN Dialog 
     TortoiseSVN Download
  7. Nach dem Download sollte das Verzeichnis so aussehen.
    Projekt Ordnerstrucktur
  8. Jetzt noch ein Doppelklick auf die “BlogEngine.sln” und es kann los gehen. Vielleicht wirst du noch darauf hingewiesen, dass das Projekt einer Source Code Verwaltung unterliegt. Ich wähle dann im Dialog immer den Punkt “Permanent entfernen” aus.

Jetzt ist deine Fantasie gefragt.

kick it on dotnet-kicks.de