Java oder Kotlin?

[swa00]

Kotlin ist ja "nur" ein Syntax , der dann wiederum letztendlich in einer JVM - also Java landet.
Ähnlich wie bei anderen High-Level Sprachen ...

 

[jogimuc]

Es ging nicht darum das was abgeschafft werden soll. Sondern was die am meisten verwendetete Sprache ist um eine Android App zu schreiben. Und das kann man dan als Standart bezeichnen.
[doublepost=1534746910,1534746222][/doublepost]@saw00
hast du einen Link zu der offiziellen Doku von Android?

denn auch ich finde zB beim ViewPager nur die Methoden beschreibung zu Java
ViewPager  |  Android Developers

 

[Rosa Elefant]

Package Index  |  Android Developers

 

[swa00]

Jörg, meintest Du sowas , was Elefant Dir geschickt hatte ?

 

[DagobertDokate]

hast du einen Link zu der offiziellen Doku von Android?

Lass mich kurz 2 Sekunden für dich googlen....

Documentation  |  Android Developers

nicht das du nur die javadoc kennst

 

[jogimuc]

Eigentlich nicht den das ist Java und nicht Kotlin. Da giebt es zb. noch static int variablen die es in Kotlin nicht gibt.

 

[Rosa Elefant]

Ein lösbares Problem: einfach dort runterscrollen.

Kotlin and Android  |  Android Developers

 

[swa00]

Dann bitte nochmal

Ich denke weder Dagobert, Elefant und ich haben genau verstanden , was du suchst

 

[jogimuc]

ich möchte die geiche auflistung der Methoten zB. Viewpager in Kotlin haben .
natürlich auch alle anderen.

der linkk von Rosa Elefant ist Java




Package Index | Android Developers

 

[swa00]

Eine "offizielle" gegenüberstellende Liste habe ich auch noch nicht bis dato gefunden.
Manche API Beschreibungen haben dann Syntax-Reiter für Java und Kotlin.

Manche muss man dann zu fuss suchen

Bsp
Location | Android Developers
Location | Android Developers


Manche fehlen dann komplett und man sucht sich den Wolf

 

[jogimuc]

Und wenn ich bei Googel etwas suche zB. meinen Viewpager was kommt da als erstes die Doku zu Java soviel zum Standart.

Danke Saw00 wolte damit nur beweisen das es somit noch kein standart ist.
Wenn selbst Googel bei einer Suche zuerst einen link zu Java gib.

 

[swa00]

Und genau das meinte ich Eingangs.

Nehmen wir auch das findByView Beispiel von oben.

Solange ich denken kann , ist der Entwickler selbst für seine Zuweisungen verantwortlich.
Das garantiert auch die Übersichtlichkeit .

setContentView(R.layout.activity_main)
          // No need to call findViewById(R.id.textView) as TextView
          textView.text = "Kotlin for Android rocks!"

Hier geht Kotlin hin und automatisiert es .

Im Falle der "traditionellen" Fehlersuche ist mit 99% davon auszugehen , dass Du der Übeltäter bist.
Jetzt kannst du dir nicht mehr sicher sein und drückst auf alle Fälle erst mal einen Sync

ICH möchte allerdings a = b und nicht : a = such mal b

Wahrscheinlich bedingt , dass ich in der Hauptsache immer noch Vernünftiges in C/C++ entwickle
und auch sehr oft NDK einsetze

 

[DagobertDokate]

Und wenn ich bei Googel etwas suche zB. meinen Viewpager was kommt da als erstes die Doku zu Java soviel zum Standart.

Ja es kommt immer drauf an was mach sucht.
Warum sollte jemand für 10 Jahre altes Zeugs direkt ein neues Tut schreiben.

Dann such mal nach NotificationChannels, Location, Dagger, Jetpack, Room, usw....
Da ändert sich das imo direkt schlagartig...

lg. Dagobert

 

[swa00]

An dieser Stelle sollte man auf die eigentliche Frage des TE's zurückkommen.

Er weis ja nicht , ob, wann und wieso es "altes " Zeugs ist .

Er geht ja unbedarft heran - Wir Gurus haben zumindest schon mal eine "Ahnung" was wir suchen sollen.
Und da ist m.E: ein Anfänger mit Kotlin aufgeschmissen .

Also muss man noch warten , bis Tante Google einem Lernwilligen wirklich hilfreich sein kann.

Und zu guter Letzt ist es dem individuellen Entwickler selbst überlassen , was er als "sein" Baby
ansieht und damit zurecht kommt .

Die Vergangenheit hat allerdings gezeigt , dass man tunlichst alles "Neue" erst einmal über Jahre hinweg
beobachten soll, denn so Manches ist schlichtweg von der Bildfläche verschwunden.

Für jemanden , der das beruflich ausführt, ein wirtschaftlicher Gau.
Das "Traditionelle" hilft aber immer weiter und das sollte man beherrschen

 

[Rosa Elefant]

Die Vergangenheit hat allerdings gezeigt , dass man tunlichst alles "Neue" erst einmal über Jahre hinweg
beobachten soll, denn so Manches ist schlichtweg von der Bildfläche verschwunden.

Ich wünschte, das würden die Leute mit JavaScript-Bibliotheken auch so machen.

 

[DagobertDokate]

Die Vergangenheit hat allerdings gezeigt , dass man tunlichst alles "Neue" erst einmal über Jahre hinweg
beobachten soll, denn so Manches ist schlichtweg von der Bildfläche verschwunden.

Das sehe ich in dem Bereich wo "wir" uns aufhalten nicht so. Aber da kann man bestimmt auch andere Meinung sein. Ich finde gerade die Themen Mobile&Cloud (welche zwangsläufig zusammengehören) sehr schnelllebig.

lg.

PS: Ja wir sollten langsam wieder zurück kommen:
Wie anfangs gesagt, es ist deine Entscheidung. Funktionieren wird beides. Du wirst bei beiden auf die Nase fallen und musst dich wieder aufraffen

 

[markus.tullius]

Zur Zeit läuft Android in einer Java VM und der Code im ASOP ist immer noch Java. D.h Kotlin hat noch einen weiten Weg vor sich, bevor es die primäre Sprache in Android ist.

Aber im Endeffekt ist es völlig egal, welche Sprache man benutzt. Das größere Problem in der aktuellen Androidentwicklung ist der sinn- und wahllose Einsatz von Frameworks, Hauptsache neu, so setzen viel Leute zum Beispiel RXJava ein, ohne zu beachten, dass Activities schon selber in Threads eingebettet sind. Das das ganze nicht wirklich testbar ist, ist noch das kleinste Problem.

 

[deek]

Sorry, da muss ich einhaken, weil wir da tief drin sind in der Firma.
Android läuft mitnichten auf einer Java VM. Android lief früher auf der DalvikVM und heute auf der Android Runtime (ART). Die sind beide von Java soweit weg wie Australien von Grönland.
Auf Dalvik läuft dex-Code (in APK Dateien findet man unter anderem immer die classes.dex Files, die den Code enthalten) und Art nutzt oat (wobei art auch dex ausführen kann, oat ist schneller)
Beim Kompilieren auf dem Rechner passiert nun die Umwandlung Java -> Java Bytecode -> Dex bzw. Kotlin -> Java Bytecode -> Dex
Bei ART Geräten (alle seit Lollipop) wird auf dem Device dann noch Dex -> Oat ausgeführt.
D.h. von dem ursprünglichen Java ist nichts mehr übrig, daher ist es am Ende egal ob vorne Java oder Kotlin reinkam, es braucht keine Emulation oder irgendwas, am Ende ist alles dex/oat. (bei Kotlin landet noch etwas zusätzlicher Code in Form einer Library im Bytecode, aber das tut nicht wirklich was zur Sache.
Die Entscheidung für die Entwickler die Java Syntax zu verwenden und APIs zu bauen, die den Java APIs ähneln (siehe jahrelanger Rechtsstreit) war nur um das System einfach zugänglich zu machen. Man hätte genauso gut eine komplett neue Sprache und API bauen können, die zu dex compiliert wird. Durch die Entscheidung es wie Java aussehen zu lassen hat man direkt deutlich mehr Entwickler und auch Libraries für Android zugänglich gemacht.

Zu RxJava stimme ich dir zu, die Pest. (auch wenn Activities erstmal alle im selben Thread, mainThread, laufen)

 

[jogimuc]

Hallo Danke Deek genau so habe ich es auch schon gelesen. Der erste Weg Java zu Dex wurde auch schon in dem Android 2 Buch so beschrieben.
Schön das du es hier nochmal erklärt hast.

Die User hatten sich hier an dem Begrif Standart etwas aufgehangen. Was wirklich Standart ist oder wird, wird uns die Zeit zeigen.

 

[markus.tullius]

Hi Deek,

mit der Java VM habe ich mich vergriffen (späte Uhrzeit und ich programmiere gerade nicht für Android) .

Deine Ausführung ist (aktuell ART) aber auch nicht ganz richtig.

Ein Compiler sortiert vereinfacht ein Code so, das eine CPU die Anweisungen ausführen kann. Die Reihenfolge, wie der Compiler die Anweisungen sortiert, hängt zum einen von der verwendeten CPU und zum anderen von der verwendeten Sprache ab. Entgegen Deeks Vermutung ist es nicht egal, mit welcher Sprache die Compiler gefüttert werden. Die compilierten Programmteile müssen miteinander agieren können (Android besteht aus vielen verschiedenen Dateien). Dafür gibt es Schnittstellen, und diese sind speziell für Java konzipiert worden.

Eine Methode kann verschiedene Zustände haben:
AOT compiled,
JIT compiled oder
interpreted (dex code)

Das heißt, der Code liegt in auf dem Device in allen drei Zustanden vor. Der AOT - Compiler erzeugt die oat - Datein. JIT und der Interpreter benutzen die dex Dateien.

(Quelle: siehe Link unten)

Der Compile-Vorgang läuft in zwei Schritten ab. Als erstes wird das apk erzeugt. Wenn die apk installiert wird, werden die vorliegenden Quellen nochmal auf dem Device kompiliert. So kann die App speziell für das spezielle Device angepasst werden.
Deshalb ist das apk fast immer kleiner als die installierte App.

ART wurde für Java entwickelt. Damit Kotlin auf Android läuft, braucht man neben den Compiler noch ein Parser, damit wie Deek schon richtig angemerkt hat, JavaBytecode erzeugt wird. Hier liegt die Schwäche von Kotlin, man braucht eine zusätzliche Programmschicht (den Parser). Mehr Code heißt mehr Platz für Bugs. Und der Kotlin Code muss so umgebogen werden, dass er unter der Haube wie Java aussieht. Das geht in der Regel auf die Performance.

Google hat auch sonst nichts davon, Java durch Kotlin zu ersetzen. Der erzeugte Bytecode entspricht immer noch der API von Oracle. Der Einsatz von Kotlin ist eher ein Gefallen für JetBrain (AndroidStudio).
[doublepost=1535581400,1535580871][/doublepost]Das ist nur eine grobe Übersicht. Bevor das ganze hier in einen Diskurs über ART ausartet. Hier ein Link: ART and Dalvik | Android Open Source Project