Was soll denn das mit Android Studio?

(Ja, ein weiterer Rant).

Was zum … haben die da mit “Android Studio” aus dem Hut gezaubert?

Sicher, es kann gut sein, dass man “verwöhnt” ist, wenn man zu lange Eclipse verwendet hat.

Aber … kann es sein, dass Android Studio ein fragil-wackeliger Moloch ist? Die erste Stunde hab’ ich schonmal damit verbracht, irgendwelche Emulatoren runterzuladen, bis er sich nicht mehr beschwert hat, dass ihm an meiner CPU irgendwas mit “VT-x” und “HAXM” nicht passt :verzweifel: Und jetzt … scheinbar elementarste Einstellungen sind unauffindbar in Menüs mit hunderten nutzlosen Funktionen versteckt. Jeder Klick scheint nur auf hilflose Versuche rauszulaufen, irgendwelchen Gradle-Syncs, Updates und Gradle-Builds laufen zu lassen, die dutzende von Log-Konsolen vollmüllen, und am Ende zu nichtssagenden Fehlermeldungen führen, die man nur in Google eintippen kann, um dann auf Stackoverflow die Anleitungen zu finden, die regelmäßig Schritte beinhalten wie

  • Geh in Project->Settings->Deep->Internal und setze das Häckchen bei “Eploy RTX when sleep-refreshing for Unicorn Sync”
  • Lösch dieses-und-jenes Verzeichnis, mach’ ein Project->Clean, starte neu und hoffe, dass es dann geht
  • Füge in dieser-und-jener-Datei diese-und-jene Zeilen […] ein
  • Schlachte ein Huhn und tränke deine Tastatur in seinem Blut :sick:
    Und … aaaaallleesssss daaaauuuerrrrt soooo laaaannnngeeee… :suspect:

Irgendwann gab’s mal ein Android-Plugin für Eclipse, das nicht viel mehr gemacht hat, als einen Button in die Toolbar zu hängen, mit dem man seine App auf einem Emulator laufen lassen konnte. Aber … das war anscheinend zu einfach, oder zu effizient, oder … was auch immer.

Verwendet das irgendjemand, in der Praxis, ich meine, so richtig…?

Ich verwende es tagtäglich und einige deiner genannten Punkte kann ich gut nachvollziehen.
Sind teilweise auch IntelliJ geschuldet das hinter Android Studio steckt.

Gerade mit den Menüs, andere Shortcuts, kein Autoimport und keine MouseOver Documentation.
Sicherlich alles halbwegs wie bei Eclipse Einsichtnahme aber naja…

Und langsam ist Android Studio, ja. Man braucht schon einen guten Rechner mit einer SSD. Sonst wird das nichts.

Der Intel HAXM CPU Treiber ist für die Android Emulation wichtig. Man braucht ihn nicht, aber er macht die Emulatoren logischerweise schneller.

Muss aber sagen, dass ich bei der Erstinstallation kaum Probleme hatte. Das SDK ist doch recht schnell einsatzfähig. Man muss über den ADV halt ein paar Bibliotheken nachladen und da muss man erstmal wissen welche…

Statt einem Emulator würde ich dir aber eher ein echtes Gerät anraten, nebenbei bemerkt, wenn du eins hast.
Einfach per USB Kabel an den Computer hängen, die Entwicklereinstellungen auf dem Smartphone freischalten und USB Debugging aktivieren.
Das ist viiiel angenehmer als über einen Emulator.

Wenn du spezifische Fragen hast, kannst du die gerne stellen.

[QUOTE=TMII]Gerade mit den Menüs, andere Shortcuts, kein Autoimport und keine MouseOver Documentation.
Sicherlich alles halbwegs wie bei Eclipse Einsichtnahme aber naja…[/QUOTE]

?

Doppelt Shift klicken → Suche ueberall (auch in Menus)
Settings → Keymap → Dein gewuenschtes Schema einstellen (gibt auch Ihclipse)
Settings → Autoimport → So einstellen, wie du es willst
Auf Element klicken und F1 → Doc in einem browserbaren Fenster

Geht denn das Plugin fuer Ihclipse nicht mehr? Soll doch jeder mit dem Tool entwickeln, mit dem er am besten klarkommt.

Und wer heut immer noch keine SSD Platte zum entwickeln hernimmt, dem is einfach nich mehr zu helfen :wink:

Dass ein echtes Gerät besser wäre, ist klar. (Und als ich mich vor ein paar Jahren mal mit Android beschäftigt habe, war das sogar notwendig, weil die Emulatoren nicht die Funktionen anboten, die für die Entwicklung einer Android-OpenCL-Library notwendig gewesen wären ;-)). Aber hier flackt jetzt nur noch dieses Android 2.x-Ding von damals rum, bei dem auch der Touchscreen nicht mehr zu gehen scheint. Wie auch immer.

Eigentlich bräuchte ich kaum ein Gerät. Eigentlich wollte ich nur jgltf-model not portable to Android · Issue #4 · javagl/JglTF · GitHub nachvollziehen (weil der Gedanke, JglTF für Android verfügbar zu machen, und da auch gleich noch eine Viewer-Implementierung dafür anzubieten, schon SAU-Cool wäre :slight_smile: ). Und eigentlich bräuchte ich dafür vielleicht nicht mal einen Emulator: Es ging ja nur darum, zu schauen, welche Java 8-Features unter Android zu Fehlern führen.

Aber ich dachte eben: Joa, ich mach erstmal so eine elementare „Template“-App, damit ich einen Punkt zum Einhaken habe. Aber der Aufwand,

  • den Emulator an sich zum Laufen zu bringen
  • irgendwas compilierbar zu machen (flenn, flenn, falsche Gradle-Version, Websuche: Diese-Und-Jene Datei So-und-So editieren - WTF?!)
  • bei jedem Klick minutenlang eine Progress-Bar zu beobachten (trotz 32GB und SSD!)
  • rauszufinden, wo man sowas elementares macht wie z.B. dependencies hinzuzufügen (außer händisch in der Gradle-Build-Datei)
  • rauszufinden, warum bei jeder Aktion ein Feuerwerk von Popups an allen Ecken und Enden aufpoppen, in denen steht, dass irgendwas (meistens mit Gradle) nicht funktioniert hat
  • zu verstehen, warum das ganze komplett (!?!?) „um Gradle herum“ gestrickt zu sein scheint
    unterdrückt irgendwie das Gefühl, damit sinnvoll und mit etwas „Traktion“ loslegen zu können.

Klar, vermutlich muss man sich nur „dran gewöhnen“, aber der erste Eindruck ist irgendwo zwischen „Naja…“ und „WTF?!?“ (und deutlich näher an letzterem)

Das Projekt/Modulsystem von IntelliJ (ich nehm an das is beim Android Studio genauso) basiert auf dem Projektmodell von Gradle. D.h. das Gradlescript bestimmt, wie das Projekt in der IDE aussieht. Das ist imho ein Vorteil, denn normalerweise importierst dann ein Projekt (wo es schon ein Gradle Buildscript gibt) und das funktioniert dann einfach. Im Gegensatz zu Eclipse nutzt IntelliJ bestehende Infrastruktur, anstatt alles mit (fuer mich wirren) Dialogen nochmal nach zu bauen. Deshalb ist es auch einfacher, Dependencies im Gradlefile zu ergaenzen und danach das Script neu zu laden (macht der Refreshbutton im Gradlewindow).

Das kann tatsaechlich etwas dauern, denn dabei werden alle Dependencies aufgeloest und evtl. vom Maven Repo gezogen.

Die Popups kommen bei mir in der rechten unteren Ecke und stapeln sich so uebereinander. Normalerweise ist aber in diesen gleich ein Link zum Loesen des Problems. Das sollte man dann eben tun, dann kommt der Popup auch nicht mehr :wink:

Aber nochmal, wenn du IntelliJ so kacke findest, DANN NIMM ES HALT NICHT! Ich versteh immer nich, wieso sich Leute ueber Dinge aufregen, anstatt einfach die angeblich bessere Alternative zu waehlen. Das is so aehnlich, wie wenn ich mich ueber die Rosinen im Rosinenbroetchen aufrege, anstatt eins ohne Rosinen zu kaufen.

[QUOTE=schalentier]
Aber nochmal, wenn du IntelliJ so kacke findest, DANN NIMM ES HALT NICHT![/QUOTE]

Das ist mir jetzt zu blöd.

@schalentier
Für Android gibt es nur IntelliJ Android Studio. Das Eclipse Plugin wurde eingestellt und funktioniert auch nicht mehr zum Leidwesen der Eclipse-Nutzer, klar denn die müssen sich jetzt in IntelliJ einarbeiten und natürlich ist das nervtötender Aufwand weil man sich jetzt mit IntelliJ und dem Android SDK (im Falle von Marco13) das bereits kompliziert genug ist rumschlagen muss anstatt effektiv am Projekt zu arbeiten.
Das ist der Punkt an dem ein “Tool”->Werkzeug einem mehr Arbeit macht als es einem abnehmen sollte und damit seine Sinnhaftigkeit verliert.

Okay, ich dachte das is Opensource und es hat sich jemand aus der Community von Eclipse gefunden, der das weiterpflegt, so dass es zumindest noch funktioniert. Als ich vor sehr langer Zeit mal mit Android rumgespielt hab, gabs gar kein Studio, da ging das relativ easy auf der Commandozeile mit irgendwelchen Ant Scripten. Voellig unabhaengig von der IDE.

Aber dennoch draengt sich mir halt der Eindruck auf, dass hier irgendwas anderes schief laeuft. IntelliJ kann AutoImport seit Version 1.0 - sich dann ueber fehlenden AutoImport zu aergern … naja. Mir wuerde es andersrum wahrscheinlich genauso gehen, ich hab z.B. nie begriffen, warum sich das Aussehen von Eclipse komplett aendert, bloss weil ich Debugge anstatt normal zu starten. Oder wieso die einen eignen Java Compiler gebaut haben, der sich auch noch etwas anders verhaelt, als der von Oracle.

Zudem denke ich, gab es irgendwelche Gruende warum Google die Platform geaendert hat. Garantiert hat JetBrains nicht Google bestochen oder sowas.

Und nen Huhn musste ich noch nie schlachten :smiley:

[ot]

Das ist IMHO einer DER wichtigsten low-level-technologischen Pluspunkte von Eclipse gegenüber anderen IDEs. Ein inkrementeller Compiler, der viel tiefer integriert ist, als es jeder geparste Javac-Output jemals sein kann. Aber allgemein ist das natürlich nur einer von vielen, und … insgesamt ist Eclipse natürlich auch ein Moloch, bei dem nur extrem wenige Leute in der Tiefe durchsteigen, und bei dem sich vielleicht gerade deswegen niemand findet, der sowas einfach so weiterpflegen kann - insbesondere, wenn Google ohne Rücksicht darauf sein Ding macht (und das scheint es mit Android ja zu machen). (Bei Eclipse ist dieser Moloch aber wenigstens versteckt. An der Oberfläche ist es eine auf effizientes und einfaches Arbeiten ausgerichtete IDE, die sich für mich - und ich weiß, dass andere das anders sehen, und es in vieler Hinsicht faktisch anders ist - immernoch schlank anfühlt).
[/ot]

Aber das soll ja kein IDE-Bashing werden. Nur ein „Android Studio“-Bashing :smiley:

Natürlich ist es „immer“ so, dass man sich bei einer komplexen IDE erstmal einen Trampelpfad der Funktionen anlegen muss, die man tatsächlich braucht. Jemand, der zum ersten Mal Eclipse verwendet, wird sich vielleicht auch fragen, warum man „Dependencies“ versteckt in einem Menüeintrag „Java Build Path“ einstellen muss. Aber Android Studio scheint trotzdem schon SEHR überladen, SEHR undurchsichtig, SEHR wackelig und SEHR langsam zu sein.

Wie auch immer, wie man sich anhand von jgltf-model not portable to Android · Issue #4 · javagl/JglTF · GitHub sehen kann, ist es mir inwzwischen (nach einigen Stunden Download, und inzwischen >10 GB (!) im Android-Verzeichnis) gelungen, das ganze weitgehend zu compilieren - abgesehen von den Klassen, von denen ich teilweise schon „wußte“, dass sie in Android nicht existieren. Mal schauen, wie es jetzt weitergeht.

Vielleicht ist das jetzt noch IDE-Bashing, aber ich habe seit ich begonnen habe Java zu lernen gleich mit IntelliJ IDEA angefangen. Für mich stellt es sich genau umgekehrt dar, dass Eclipse extrem aufgeblasen und von der Projektverwaltung her schlecht ist. (Kann Eclipse eigentlich mittlerweile mit echt hierarchischen Projekten umgehen?)
Zumindest war das mein Eindruck, als ich mit Eclipse arbeiten musste (u. a. im Rahmen meiner Masterarbeit).
Ach ja, die vielen verschiedenen Views finde ich auch verwirrend. Sicher ist das ein gutes Werkzeug, wenn man daran gewöhnt ist. Aber eine IDE ist nun einmal zum Großteil Gewöhnungssache.

Für bessere Integration in die IDE braucht es keinen eigenen Compiler. Die Hinweise und Warnungen in IDEA gehen weit über das hinaus, was der Compiler liefert. Und man kann noch auswählen, welchen Compiler man verwenden möchte (also auch den Eclipse-Compiler).

Ich denke, für viele IDEA-Nutzer war es ein Graus, als Android-Studio noch auf Eclipse basierte. Denen ging es wahrscheinlich genau wie dir jetzt.

IDE Bashing:
Wieso man heute noch ohne inkrementellen Compiler arbeitet?
Ganz einfach:
Weil man gezwungen wird :frowning:

Sorry, aber das ist IMHO schon ein dicker Hund dass ich erst auf Build klicken muss um zu sehen ob mein Projekt kompiliert… das hatte ich 1990 mit Turbo Pascal 3.0…

Von welcher IDE redest du? IntelliJ IDEA kann das. Nicht nur inkrementell, sondern auch parallel. (Siehe in den Compilereinstellungen „Make project automatically“ und „Compile independent modules in parallel“).
Und IIRC kann Eclipse das auch. Meinst du Netbeans?
Edit: zugegeben, Eclipse konnte das laut google schon 2004, IntelliJ IDEA erst 2012. Aber wir leben ja 2016 :wink:
Noch ein Edit: Netbeans kann das auch, seit 2008.

[quote=Marco13]Stackoverflow die Anleitungen zu finden, die regelmäßig Schritte beinhalten wie

  • Geh in Project->Settings->Deep->Internal und setze das Häckchen bei “Eploy RTX when sleep-refreshing for Unicorn Sync”
  • Lösch dieses-und-jenes Verzeichnis, mach’ ein Project->Clean, starte neu und hoffe, dass es dann geht
  • Füge in dieser-und-jener-Datei diese-und-jene Zeilen […] ein
  • Schlachte ein Huhn und tränke deine Tastatur in seinem Blut[/quote]

Sehr unglaublich - das war genau das, was mich vor zwei Jahren in der Beta-Phase endlos angekotzt hat: irgendein Gradle-Cache irgendwo, der immer nervt und nervt und nervt…

Ich hätte gedacht, dass dieser Wahnsinn längst behoben ist, da kann doch was nicht stimmen? Aber wundern tut mich das auch nicht wirklich.

Der Umstieg auf Gradle war meiner Meinung nach ein echter Krampf - so viel neue Komplexität (die man lernen muss) allein für das Build-Tool, das ist doch albern. Aber die Entwickler sind ja leidensfähig.

**Suffering is the Commodity That you Provide
**

Die Entwicklungen dahinter habe ich nicht mitbekommen und weiß nicht, wie es früher war. Aber gerade, dass dort Gradle so eine zentrale Rolle spielt, hat mich irritiert. Ich meine, das ist “irgendein” Build-System. Die IDE sollte IMHO nicht zuletzt den Zweck erfüllen, sich um das Build-System keine Gedanken mehr machen zu müssen - zumindest während der Entwicklung! (Dass man am Ende nochmal irgedeine Form von “make and deploy” an der Konsole eintippen muss, kann ja OK sein). Aber in der IDE sollte man IMHO nicht sehen, ob das dahinterstehende System nun Gradle, Maven, Ant oder irgendwas home-brewn ist. Das ist sehr “idealistisch”, und auch wenn das paradox klingen mag: In Eclipse füge ich dependencies tendenziell auch durch händisches Editieren der POM hinzu, und nicht durch den “Add dependencies”-Button im Editor. Und es ist nachvollziehbar, dass man dann manchmal “Update Maven Projects” machen muss. Aber die Häufigkeit, mit der ich (bei meinen wenigen ersten Schritten) auf “Do a Gradle Sync” klicken musste, und die Zeit, die es jedes Mal gedauert hat, bis der Fortschrittsbalken am Ende war, sind schon irritierend - vor allem, wenn man anscheinend “viele” Einstellungen nur durch händisches Copy von “magischen” Zeilen aus Stackoverflow und Paste in irgendeine Gradle-Datei vornehmen kann…

Viele dieser Einstellungen die du durch händisches kopieren machen musst sind häufig Android spezifische Sachen bei der die UI-Oberfläche noch nicht aktualisiert wurde.
Oder um es in den Worten von einem Google Kollegen auszudrücken “Android entwickelt sich rasend schnell.”
Aber es trifft den Nagel auf den Kopf.

Besonderst die Performance ist sehr nervig.

Dennoch muss ich sagen, habe ich lange nicht mehr in den Gradle Files rumspielen müssen. Was hast du denn genau gemacht?

@cmrudolph
Vielleicht liegt es am Dalvik Compiler aber bei mir werden Fehler im Code erst angezeigt wenn ich die Klasse öffne, oder Make ausführe und auch dann nur ein Teil. Also heißt es immer wieder Rebuild ausführen bis alle Fehler beseitigt sind.
Ich kann eine komplette Klasse löschen, dass die anderen Klassen jetzt tausende Fehler haben bemerkt er nicht.

Ich habe es gestartet. Vielleicht war das schon der erste Fehler :o) Mal im Ernst: Ich wollte nur jgltf-model not portable to Android · Issue #4 · javagl/JglTF · GitHub nachvollziehen, und nicht bei allen Schritten, die notwendig waren um den aktuellen Stand zu erreichen, habe ich nachvollzogen, was in der „Fehler → Google → Stackoverflow → Copy+Paste-Lösung“-Schleife genau falsch lief. Ich erinnere mich an irgendeine falsche Gradle-Versionsnummer, die durch händisches Editieren gefixt werden mußte (und sich nur durch eine frustrierend nichtssagende Fehlermeldung wie ~„Something did not work“ äußerte), und daran, dass ich überall „23“ auf „24“ (und ein paar passende Versionsnummern) ändern mußte, um das API-Level anzuheben, für „java.util.functional“ (begleitet von mehreren GB downloads) - aber das könnte man händewedelnd rechtfertigen mit „Bei AS 2.0 gab’s 24 noch nicht, bei AS 2.1 wäre 24 default“ oder so.

EDIT: Besonders fragil scheint auch das zu sein, was „Instant Run“ heißt. Ich hab’s ein paar mal ein- und aus geschaltet, aber irgendwie wackelt und klappert es scheinbar unabhängig davon überall…

[quote=TMII]Vielleicht liegt es am Dalvik Compiler aber bei mir werden Fehler im Code erst angezeigt wenn ich die Klasse öffne, oder Make ausführe und auch dann nur ein Teil. Also heißt es immer wieder Rebuild ausführen bis alle Fehler beseitigt sind.
Ich kann eine komplette Klasse löschen, dass die anderen Klassen jetzt tausende Fehler haben bemerkt er nicht.[/quote]
Kann sein, dass es am Compiler liegt. Wenn ich eine Klasse lösche, dann kommt etwa eine halbe Sekunde später eine Liste von Fehlermeldungen, in denen die Klassen, in denen die gelöschte verwendet wird, aufgeführt sind.
Oder meintest du jetzt, dass du die Klasse im Dateisystem einfach gelöscht hast?
Edit: selbst dann erkennt er innerhalb von ein paar Sekunden, dass das so nicht mehr lauffähig ist.

hmmm die Grundeisntellungen eines Android Projekts im Nachhinein zu ändern ist in der Tat ein bisschen nervig. Insbesondere weil sie das Einstellungsfenster aus Eclipse verworfen haben und man das jetzt, wie du schreibst, händisch ändern muss.
Aber nicht nur in den Gradle Files sondern dann auch in den ganzen XML XY Dateien…
Da ist es manchmal einfacher einfach ein neues Projekt aufzuziehen und die ganzen Source-Files ins neue Projekt zu verschieben.

Aber die Gradle Version passt er eigentlich immer automatisch per Klick an.

Instant Run ist so eine Sache. Im Idealfall hast du deine Code-Änderungen in 5 Sekunden auf dem Zielgerät in der laufenden Applikation veröffentlicht, sehr ähnlich wie bei JRebel.
Das ist weit besser als 2 Minuten auf den Gradle Build zu warten.
Funktioniert aber nur wenn
A) Das Gerät oder der Emulator das Unterstützt
B) Das Projekt die Flag „Debug“ hat
C) Du die App nicht vorher beendet hast (sie muss unbedingt laufen! - meine Achillessehne, beende sie jedesmal)
D) Andere Probleme auftauchen*
*Es ist nicht immer perfekt. Manchmal ist eine frisch gestartete App einfach besser und Instant Run verursacht Probleme das es eigentlich nicht sollte weil die App intern dann einfach mit sich selbst out-of-sync ist.

[QUOTE=schalentier]IntelliJ kann AutoImport seit Version 1.0 - sich dann ueber fehlenden AutoImport zu aergern … naja. Mir wuerde es andersrum wahrscheinlich genauso gehen, ich hab z.B. nie begriffen, warum sich das Aussehen von Eclipse komplett aendert, bloss weil ich Debugge anstatt normal zu starten. Oder wieso die einen eignen Java Compiler gebaut haben, der sich auch noch etwas anders verhaelt, als der von Oracle.

Zudem denke ich, gab es irgendwelche Gruende warum Google die Platform geaendert hat. Garantiert hat JetBrains nicht Google bestochen oder sowas.[/QUOTE]
Da oben hat die Autokorrektur mir einen Streich gespielt.

Einsichtnahme → „einstellbar“
Danke Android(!) :rolleyes: :smiley:
Und der ganze Satz sollte Aussagen, man kann IntelliJ schon irgendwie wie Eclipse einstellen, aber es ist trotzdem unterschiedlich.
Selbst der Autoimport funktioniert anderst und er ist auch viel aggressiver. Man kann die Tastatur-Kürzel zwar auf „Eclipse“ stellen, aber trotzdem stimmen einige nicht - mal ganz abgesehen davon dass IntelliJ von der Oberfläche komplett anderst ist und damit auch andere Kürzel benötigt.

Weil es gerade so schön zum Thema passt:

@Marco13
Sei froh dass du dich damit nicht beruflich rumschlagen musst. Jetzt bin ich weder Kaffe-Trinker und das Rauchen hab ich auch aufgegeben (seit 5 Monaten clean), draußen ist es sowieso zu kalt zur Zeit, was mach ich mit den Pausen?
<-- Dass da ist ein vergrößerbares Bild
Am Besten in Erinnerungen schwelgen als ich mit C++ noch 20 Minuten auf den Compiler gewartet habe.

Sollte es jmd interessieren, ich hab ja Zeit:
für gerade mal

  • 141848 Zeilen Java-Code
  • 520 Java-Dateien
  • 2867 Projektdateien insgesammt
  • 0,7 GB