Jaki język programowania na Androida?

Odpowiedz Nowy wątek
2019-02-11 21:31
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. :)

Pozostało 580 znaków

2019-02-11 22:08
0

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

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

itd.


"Trolling is a art"

Pozostało 580 znaków

2019-02-11 23:00
6

2tff58.jpg

Pozostało 580 znaków

2019-02-11 23:30
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[...]d=com.cobol.guid&hl=en_US


Szacuje się, że w Polsce brakuje 50 tys. programistów
edytowany 1x, ostatnio: vpiotr, 2019-02-11 23:31

Pozostało 580 znaków

2019-02-26 10:49
V-2
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.


Nie ma najmniejszego powodu, aby w CV pisać "email" przed swoim adresem mailowym, "imię i nazwisko" przed imieniem i nazwiskiem" ani "zdjęcie mojej głowy od przedniej strony" obok ewentualnego zdjęcia.
edytowany 1x, ostatnio: V-2, 2019-02-26 14:53

Pozostało 580 znaków

2019-02-26 17:10
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.

edytowany 2x, ostatnio: elwis, 2019-02-26 17:13

Pozostało 580 znaków

2019-02-26 20:01
V-2
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ę.


Nie ma najmniejszego powodu, aby w CV pisać "email" przed swoim adresem mailowym, "imię i nazwisko" przed imieniem i nazwiskiem" ani "zdjęcie mojej głowy od przedniej strony" obok ewentualnego zdjęcia.

Pozostało 580 znaków

2019-02-26 20:35
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.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 3x, ostatnio: Wibowit, 2019-02-26 22:20

Pozostało 580 znaków

2019-02-26 20:53
V-2
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.


Nie ma najmniejszego powodu, aby w CV pisać "email" przed swoim adresem mailowym, "imię i nazwisko" przed imieniem i nazwiskiem" ani "zdjęcie mojej głowy od przedniej strony" obok ewentualnego zdjęcia.

Pozostało 580 znaków

2019-02-26 21:07
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.

edytowany 1x, ostatnio: Michał Sikora, 2019-02-26 21:09
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 - ale Javowcy raczej nie wywołują ich bezpośrednio ze swojego kodu Javowego, no nie? - Wibowit 2019-02-26 21:20
Z drugiej strony argument o stopniowej migracji z Javy na Kotlina jest całkiem sensowny. - Wibowit 2019-02-26 21:23
Z tymi narzędziami do generacji, to raczej nie. Ale też zależy jak na to popatrzeć, bo ten kod jest konsumowany przez jakieś Javowe narzędzia jak javac, pluginy do IDE, pluginy do Gradle. Znam tylko jeden przypadek, żeby ktoś sam na bazie tych narzędzi w Kotlinie pisał swoje narzędzia w Javie. Z kolei przykłady bibliotek, zwłaszcza Okio pokazują, że coś się dzieje. Najciekawsze, że Okio zostało przepisane z Javy na Kotlina, żeby zapewnić wsparcie dla wielu platform i nie zostało złamane API. To samo pewnie czeka niedługo Moshi. Obie biblioteki bardzo popularne. - Michał Sikora 2019-02-26 21:32
Doprecyzowałem w takim razie o co mi chodziło, a chodziło u wywoływanie kodu np Kotlinowego z poziomu kodu Javowego. - Wibowit 2019-02-26 22:17

Pozostało 580 znaków

2019-02-26 21:19
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.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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