Jaki język programowania na Androida?

0

Cześć.
Chciałbym poskrobać aplikację na Androida, ale nie wiem, w jakim języku pisać. Bawiłem się już pisząc aplikacje w Javie, coś tam umiem. Jaki wybór będzie najlepszy - najbardziej przyszłościowy, wydajny etc.? Coś próbowałem z Kotlinem, ale wydał się dla mnie dziwny. Ew. mogę do niego podejść jeszcze raz.
Dziękuję za odpowiedzi, pozdrawiam. :)

0

Kotlin jako natywne rozwiązanie. Lub nienatywne rozwiązania np.

  • Apache Cordova
  • PhoneGap
  • React Native
  • Ionic
  • Flutter
  • NativeScript

itd.

6

2tff58.jpg

0

Zgadzam się, Kotlin wygląda dziwnie. Do tego kojarzy się bardziej z sosem pomidorowym niż profesjonalnym środowiskiem.
Spróbuj COBOL-a, a nóż Ci podejdzie.
Za: szacun na dzielni, niezła kasa, niezbyt zatłoczona nisza.
http://www.veryant.com/products/cobol-mobile.html
https://play.google.com/store/apps/details?id=com.cobol.guid&hl=en_US

1
Adamek161 napisał(a):

Bawiłem się już pisząc aplikacje w Javie, coś tam umiem. Jaki wybór będzie najlepszy - najbardziej przyszłościowy, wydajny etc.? Coś próbowałem z Kotlinem, ale wydał się dla mnie dziwny.

http://www.paulgraham.com/avg.html

I'm going to use a hypothetical language called Blub. Blub falls right in the middle of the abstractness continuum. It is not the most powerful language, but it is more powerful than Cobol or machine language.

And in fact, our hypothetical Blub programmer wouldn't use either of them. Of course he wouldn't program in machine language. That's what compilers are for. And as for Cobol, he doesn't know how anyone can get anything done with it. It doesn't even have x (Blub feature of your choice).

As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.

1

Pewnie Kotlin to nie Java, wspiera na przykład paradygmat funkcyjny, pewnie dlatego wydaje ci się dziwny, jednak po coś te rzeczy wprowadzono. Poczytaj, zrozum, wykorzystaj. Warto, tym bardziej że w porównaniu z takimi językami jak Haskell czy Lisp I tak w dużej mierze przypomina Javę. Jak ci się nie chce albo w głowie co się nie mieści zostań przy Javie i tyle.
Tak w ogóle jeszcze w scali można pisać na Androida, choć nie wspiera tej platformy jak Kotlin który jest jej dedykowany. Za to ze swojego doświadczenia mogę powiedzieć że to fajny język, choć pewnie też wyda ci się dziwny.

0
elwis napisał(a):

Tak w ogóle jeszcze w scali można pisać na Androida, choć nie wspiera tej platformy jak Kotlin który jest jej dedykowany. Za to ze swojego doświadczenia mogę powiedzieć że to fajny język, choć pewnie też wyda ci się dziwny.

Scala słynie z długich czasów budowania, a jej integracja z Androidem pozostawia wiele do życzenia. Przy czym wkroczenie do gry Kotlina w zasadzie przekreśla już nadzieje na to, że coś się w tej kwestii poprawi. Poza tym Scala, w odróżnieniu od Kotlina, nie zapewnia pełnej, dwustronnej interoperatywności z Javą.

Spotkałem się w życiu z tylko jednym projektem androidowym napisanym w Scali. Jest to rzadkość dla hobbystów. Z takich niszowych rozwiązań to w Clojure też można zdaje się pisać :)

A jeśli ktoś nie ogarnął jeszcze Kotlina, wziąć się za Scalę to wpaść z deszczu pod rynnę. Kotlina można rozpatrywać jako lightową i przykrojoną wersję tego, co ona oferuje. Scala jako język ma większe możliwości, z tym że przywołuje na myśl cytat o idącej z tym w parze wielkiej odpowiedzialności, bo łatwo w niej nawyplatać kod, który będzie totalnie nieczytelny dla normalnych ludzi.

Kotlina nie jest trudno się nauczyć, istnieje mnóstwo dobrej jakości materiałów, a wsparcie ze strony IDE jest prawie że wzorowe. Aczkolwiek im większe doświadczenie z językami starszego pokolenia jak Java, tym łatwiej docenić różnicę.

1

Poza tym Scala, w odróżnieniu od Kotlina, nie zapewnia pełnej, dwustronnej interoperatywności z Javą.

W praktyce jest tak, że:

  • z poziomu Scali możesz korzystać bezproblemowo z prawie każdej biblioteki Javowej - wyjątkami są pewne biblioteki oparte o refleksję, które mogą się sypać w pewnych przypadkach
  • z poziomu Javy możesz korzystać ze Scalowych bibliotek, które wystawiają API do łatwego wykorzystania z poziomu Javy - przykładem jest np Akka i jej Javowe API, ale też np PlayFramework
  • używanie bibliotek napisanych w Groovym, Kotlinie, Scali, Clojure etc z poziomu Javy to i tak egzotyka, więc to nie jest silny argument (edycja: chodzi konkretnie o używanie kodu np Kotlinowego z poziomu kodu Javowego jakiegoś biznesowego projektu)

Z długimi czasami budowania można w pewne sposoby zawalczyć. Przede wszystkim Scala obsługuje kompilację przyrostową, a także serwery kompilacji (po porządnym rozgrzaniu JVMki kompilacja Scali znacznie przyspiesza). Bardziej bym się obawiał skonfigurowania projektów Scalowych pod Androida tak by wszystko działało jak należy: przetwarzanie, pakowanie i wykorzystywanie zasobów, optymalizacja bajtkodu, tworzenie paczek Androidowych, odpalanie testów w emulatorze, integracja z modułami napisanymi w np React Native, itp itd Kotlin jest oficjalnie wspierany, więc spodziewałbym się, iż takie rzeczy działają od kopa.

Scala backendem stoi, więc tam mógłbym ją polecić na start :] Scala na Androida to raczej dla entuzjastów.

Na Androidzie się specjalnie nie znam, ale wydaje mi się, że ze wszystkich alternatyw do pisania w czystej Javie, Kotlin wydaje się najbezpieczniejszą opcją. Ma na tyle podobną mechanikę do czystej Javy, że bardzo łatwo o transfer wiedzy między Javą, a Kotlinem.

0
Wibowit napisał(a):
  • z poziomu Javy możesz korzystać ze Scalowych bibliotek, które wystawiają API do łatwego wykorzystania z poziomu Javy - przykładem jest np Akka i jej Javowe API, ale też np PlayFramework

OK, czyli rozumiem że trzeba przygotować coś w rodzaju warstwy proxy.

Z Kotlinem takiego problemu w zasadzie nie ma; czasem trzeba dodać jakieś anotacje, żeby nie zgrzytało, jest to kilka scenariuszy na krzyż.

Na Androidzie się specjalnie nie znam, ale wydaje mi się, że ze wszystkich alternatyw do pisania w czystej Javie, Kotlin wydaje się najbezpieczniejszą opcją. Ma na tyle podobną mechanikę do czystej Javy, że bardzo łatwo o transfer wiedzy między Javą, a Kotlinem.

No i - jak zauważyłeś - poza Javą tylko on spośród alternatyw ma oficjalne błogosławieństwo... (Za czym idzie także rozmiar i aktywność społeczności, itd.)

Ja na tę Scalę na Androida robiłem sobie smaka dawniej, jeszcze przed Kotlinem. Bo po emigracji z C# na Javę czułem się, jakby mi ktoś kazał żreć zupę widelcem. Dziś na pewno cieszyłbym się np., gdyby jako język dla Fluttera wybrano Scalę, a nie ten Dart.

0
Wibowit napisał(a):
  • używanie bibliotek napisanych w Groovym, Kotlinie, Scali, Clojure etc z poziomu Javy to i tak egzotyka, więc to nie jest silny argument

Sporo procesorów adnotacyjnych i narzędzi do generacji kodu popularnych na Androidzie jest napisanych w Kotlinie. Z popularnych bilbliotek to na pewno Okio i SQLDelight. Chociaż ta druga jest dosyć specyficzna i nie widziałem, żeby ktokolwiek jej używał z poziomu Javy, bo jak się już ma Kotlina, to po co pisać w Javie. Dodatkowo każda klasa/moduł w naszym projekcie może być traktowana jako zewnętrzna zależność i tutaj jest to już bardzo spotykane podczas migracji projektów. W tym wypadku JetBrains bardzo postarali się, żeby interoperacyjność była gładka i swobodna w obie strony, ale możliwe, że również nie jest to kłopotliwe w innych językach.

Na Androidzie się specjalnie nie znam, ale wydaje mi się, że ze wszystkich alternatyw do pisania w czystej Javie, Kotlin wydaje się najbezpieczniejszą opcją. Ma na tyle podobną mechanikę do czystej Javy, że bardzo łatwo o transfer wiedzy między Javą, a Kotlinem.

Co do bezpieczeństwa, to wystarczy, żeby był bajtkod był na poziome Javy 8. Część API też może być, ale to zależy od kilku rzeczy takich jak eksperymentalne flagi, narzędzi do usuwania lukru składniowego czy po prostu SDK. Aczkolwiek nie będę się kłócił z wyborem Kotlina jako najbezpieczniejszej alternatywy, bo się zgadzam.

1

OK, czyli rozumiem że trzeba przygotować coś w rodzaju warstwy proxy.

Zależy co przez to rozumieć. Chodzi o to, by w API przygotowanym dla Javy np:

  • unikać Scalowych klas w sygnaturach metod jeśli mamy popularne Scalowe odpowiedniki, czyli np wystawiamy CompletableFuture, zamiast Scalowego Future albo wystawiamy java.util.List zamiast scala.collection.List
  • unikać konstrukcji, które w Javie nie da się prosto wykorzystać, czyli np traity ze stanem lub hierarchią dziedziczenia wykraczającą poza default methods w interfejsach albo genericsy wyższego rzędu czy z ograniczeniami, których nie da się wyrazić w Javie
  • dalej się w miarę wygodnie pisało kod, mimo rezygnacji z bajerów opisanych w poprzednich punktach

Robienie Javowego API w Scali jest trochę jak extern "C" w C++ - dbasz o to, by sygnatury dało się używać z poziomu C, ale w ciałach metod możesz korzystać z całej gamy mechanizmów dostępnych w C++.

Cechą charakterystyczną Scali jest też regularne zrywanie z wsteczną kompatybilnością. Oczywiście zrywanie z daną klasą, metodą czy elementem składni nie odbywa się od razu, ale np w ciągu 2 - 3 wersji, ale przez to, że co wersję kolejne elementy są oznaczane jako przestarzałe to co wersję jakieś wylatują. Dzięki temu Scala sukcesywnie pozbywa się niechcianych i nieudanych elementów, ale z drugiej strony w ociężałych projektach zrywanie z kompatybilnością wsteczną oznacza duży ból przy migracji na nowe wersje Scali. To ostatnie nie jest korpo-friendly. Mimo wszystko ja pracuję w zespole Scalowców w HSBC i dzielnie sobie radzimy :) Migrujemy mikroserwisy na nowe wersje Scali i różnych bibliotek jednocześnie nie zatrzymując rozwoju całego systemu.

0

Kotlin wbija ostatnie gwoździe do trumny Java, ale z tą wzorową dokumentacją to bym nie przesadzał.
Nadal większość bibliotek jest naklepana w Java, więc ten język przynajmniej też trzeba z grubsza ogarniać (przynajmniej na chwilę obecną), ale nie widzę tutaj dużego problemu, bo oba języki można łączyć (Kotlin świetnie współpracuje z Java, ale na odwrót już nie zawsze jest tak kolorowo).
Kotlin jak dla mnie to w przeważającej mierze dużo bardziej idiomatyczna Java z co raz to bardziej bardzo dynamicznie rozszerzaną funkcjonalnością (ten język na pewno ma przyszłość podczas gdy ostatnie wymuszone przez ofensywę Kotlin uaktualnienia Java to tylko chwytanie się brzytwy przez tonącego).
Pomijając kilka mocno widocznych zmian składni reszta jest bardzo intuicyjna - upraszczana na analogiczne sposoby.
Kotlin ma bardzo dużo kluczowych usprawnień względem Java co na dłuższą metę znacznie przyśpiesza pracę.
Na początku możliwość robienia tych samych rzeczy na masę różnych sposobów trochę wywołuje mętlik w głowie, ale na szczęście bardzo intuicyjne jest odnajdywanie jakiejś metody, a kotlin sam podpowiada jak można to zrobić lepszą metodą, podczas gdy w Java często jest tylko jedna mozolna często mało intuicyjna metoda.

Zawsze irytowały mnie np getter'y i setter'y (BTW nie rozumiem dlaczego taki konwenans się w ogóle masowo przyjął mocno rażąc swoją ułomnością). Kotlin rozwiązuje ten problem, ale czasami kiedy nie jestem pewien jak wklepać pewne parametry zaczynam wklepywać getter/setter Java, żeby IDE samo zasugerowało mi adekwatny kod Kotlin.
Bardzo podobają mi się te sugestie połączone z czytelnością parametrów.
Regularnie jak chcę coś zrobić z wykorzystaniem jakiejś klasy zanim zrobię jakiś research wklepuję kropkę po nzwie klasy i przeglądam dostępne funkcje.

Kotlin ma (póki co) jeden rzucający mi się w oczy mankament. O ile samo dodanie możliwości przypisania NULL w zasadzie wszystkiemu jest dobre, o tyle zmuszanie do robienia safe call czasami jest mało intuicyjne i głowimy się dlaczego coś nie działa, kiedy jakiś argument funkcji przeklepanej na Kotlin z metody Java dodatkowo precyzuje, że np dany parametr może mieć wartość null i trzeba na końcu dodać znak zapytania. IDE mogłoby to podpowiadać (ale mam nadzieję, że wkrótce będzie).

3
Eksterminator napisał(a):

Kotlin jak dla mnie to w przeważającej mierze dużo bardziej idiomatyczna Java z co raz to bardziej bardzo dynamicznie rozszerzaną funkcjonalnością (ten język na pewno ma przyszłość podczas gdy ostatnie wymuszone przez ofensywę Kotlin uaktualnienia Java to tylko chwytanie się brzytwy przez tonącego).

title

0
Eksterminator napisał(a):

Kotlin ma (póki co) jeden rzucający mi się w oczy mankament. O ile samo dodanie możliwości przypisania NULL w zasadzie wszystkiemu jest dobre, o tyle zmuszanie do robienia safe call czasami jest mało intuicyjne i głowimy się dlaczego coś nie działa, kiedy jakiś argument funkcji przeklepanej na Kotlin z metody Java dodatkowo precyzuje, że np dany parametr może mieć wartość null i trzeba na końcu dodać znak zapytania. IDE mogłoby to podpowiadać (ale mam nadzieję, że wkrótce będzie).

To już ma miejsce. Kod w Javie musi mieć po prostu odpowiednie adnotacje. Natomiast domyślnie nullowane typy miały miejsce na początku, ale na szczęście JetBrains szybko z tego zrezygnowali na rzecz platform types.

0
Michał Sikora napisał(a):

To już ma miejsce. Kod w Javie musi mieć po prostu odpowiednie adnotacje. Natomiast domyślnie nullowane typy miały miejsce na początku, ale na szczęście JetBrains szybko z tego zrezygnowali na rzecz platform types.

Gdyby wszystko przychodzące z Javy było typu nullowalnego (T?), to by np. na każdym Observable.create też trzeba było robić safe call - bo a nuż RxJava pierwszy raz w życiu zwróci tam nulla - i na każdym następującym potem RxJavowym operatorze flatMap, filter itd. również, linijka po linijce. To byłaby mordęga.

Eksterminator napisał(a):

Nadal większość bibliotek jest naklepana w Java, więc ten język przynajmniej też trzeba z grubsza ogarniać (przynajmniej na chwilę obecną)

Przede wszystkim samo Android SDK jest w Javie. A nie potrafić tam czasem zajrzeć i czegoś przeczytać, to byłoby dla androidowego developera pewne inwalidztwo.

W idealnym scenariuszu pożądany rozkład umiejętności byłby taki, że Javę (niekiedy) czytamy, a w Kotlinie piszemy.

1 użytkowników online, w tym zalogowanych: 0, gości: 1