Wątek przeniesiony 2019-07-19 10:56 z przez Patryk27.

Jakie technologie do napisania aplikacji na Androida?

Odpowiedz Nowy wątek
2019-07-19 10:21
0

Hej, nie klepałem nic na Androida przez 2 lata.

Ktoś aktualny w temacie mógłby wypowiedzieć się na temat obecnie używanych architektur w apkach ? Wcześniej stosowałem zwyczajne MVP i było ok. Jak to jest teraz ? Kumpel w robocie stosuje MVVM i jakieś liby do bindowania zależności, Daggery itd. Nie chciałbym za dużo czasu poświęcać na naukę nowych technologii na Andka, chcę to po prostu jak najszybciej w miarę sensownie naklepać. Apka to ma być 4-5 prostych ekranów. Proste use casy, zwykłe uderzenia do resta bez większej logiki, logowanie przez fb/google/customowo.

Widoki się robi nadal w xmlu z łapy czy jakieś lepsze podejście ?

W sumie to chciałbym też wypuścić to na iOS .. może lepiej react ?

Pozdro

edytowany 3x, ostatnio: Adam Boduch, 2019-07-19 11:02
Dagger, to już był w obiegu sporo ponad 2 lata temu i jest to najbardziej popularna biblioteka do DI na Androida, tylko API się zmieniało i Google go w międzyczasie przejął, więc trzeba sobie dokumentację przejrzeć. Do DI Guica używało się chyba z 5 lat temu albo wcześniej. Nie korzystałeś w ogóle z DI? :P - wiciu 2019-07-30 14:42

Pozostało 580 znaków

2019-07-19 10:44
3

Czy piszesz coś konkretnego,czy na razie sobie odświeżasz temat i się bawisz?

chciałbym też wypuścić to na iOS .. może lepiej react

A rzuć okiem na Fluttera. Nie namawiam na siłę, ale parę osób które znam (także z 4P) i które siedzą w React'cie, po pierwszym zetknięciu z Flutterem były trochę zmieszane, ale po chwili przyznały, że jest całkiem OK. Sam się obecnie nim bawię, ale że to mój pierwszy poważniejszy kontakt z mobilkami, za bardzo nie mam porównania. Niemniej mam właśnie apkę podobną do tego, czego Ty potrzebujesz - kilka prostych widoków, między którymi się przełączasz - poszło w miarę bezproblemowo. Znaczy - trochę z tym walczyłem, bo jak pisałem - uczyłem się tego od zera, ale obecnie to takie coś w jeden wieczór bym ogarnął.


That game of life is hard to play
I'm gonna lose it anyway
The losing card I'll someday lay
So this is all I have to say
edytowany 2x, ostatnio: cerrato, 2019-07-19 11:08

Pozostało 580 znaków

2019-07-19 10:55
2

Jak prosta aplikacja i mało kodu to może jednak lepiej natywnie oddzielnie 2 zrobić niż bawić się w cross technologie. Najwięcej tutków i sprawdzonych rozwiązań do szybkiego ogarnięcia. Na Androidzie widoki w xmlu tylko już używa się więcej ConstraintLayoutów zamiast zagnieżdzonych RelativeLayoutów/LinearLayoutów + jest już komponent, który przeżywa obrót ekranu i można w nim spokojnie pisać logikę z requestem czyli ViewModel i przekazywanie danych do widoku przez LiveDaty. Ogólnie teraz na Androidzie pisze się w Kotlinie (jak znasz Javę to przeszkoczysz w kilka dni, bo API Javowe jest w pełni dostępne), gdzie masz Koina, który jest uproszczonym Daggerem, do zapytań sieciowych to standardowo OkHttp, Retrofit, RxJava 2/courotines

Pozostało 580 znaków

2019-07-19 11:11
0

@cerrato: Piszę coś konkretnego i możesz zostać moim specem od marketingu haha :D

@viader

Dzięki. Piszę w Kotlinie backend także no-problem. Nie kumam o co chodzi Ci z tym komponentem do obrotu ekranu ? Nie ma tu się obracać ekran w tej apce. Tego Koina warto użyć ? Architektura z ViewModel chyba też mi obca. Masz jakieś simple projecty / tutki ? Korutyny słyszałem, że ciekawe. Warto zamiast Retrofita ?

"Nie kumam o co chodzi Ci z tym komponentem do obrotu ekranu" - Jeżeli chodzi o ViewModel z Architecture Components, to o ile to dobrze rozumiem (z teorii), to chodzi w tym o to, żeby raz załadować dane i trzymać je w tym obiekcie tak długo, aż Activity zostanie zniszczone. W wielu aplikacjach ludzie musieli robić jakieś customowe, nie do końca dobre rozwiązania, żeby coś takiego osiągnąć lub w ogóle się tym nie przejmowali przez co dane były niepotrzebnie wielokrotnie ładowane podczas obrotu ekranu. Czasem były robione wielokrotne requesty do serwera, itp. - wiciu 2019-07-30 14:54

Pozostało 580 znaków

2019-07-19 11:30
1

Z obrotem ekranu chodzi niekoniecznie o obrót ekranu, tylko o zmianę konfiguracji aplikacji (np. obrót ekranu) i przetrwanie w tym czasie, jak widok jest ubity, takich rzeczy jak zapytanie internetowe itp.

Przykładowa apka w MVVM - https://github.com/chrisbanes/tivi

Korutyny są ortogonalne do Retrofita. Możesz używać korutyn w Retroficie. Moim zdaniem warto.

edytowany 1x, ostatnio: Michał Sikora, 2019-07-19 16:23

Pozostało 580 znaków

2019-07-24 11:59
V-2
0
Bambo napisał(a):

Tego Koina warto użyć ?

Do prostych aplikacji jest całkiem poręczny, ale nie nazwałbym go "uproszczonym Daggerem", bo to nie jest Dependency Injection, tylko typowy service locator (ze sporą ilością Kotlinowego cukru składniowego). W przypadku aplikacji na parę ekranów można się zastanawiać, czy nawet ten Koin jest nam w ogóle potrzebny. (Jest też kilka innych alternatyw, jeśli chcemy ominąć Daggera - Kodein, Toothpick. Nie ma powodu traktować akurat Koina jako jakiś złoty standard.)


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.
Pokaż pozostałe 12 komentarzy
"twoje założenie, że Dagger 2 to tylko do poważnych rozwiązań, a Koin to niby ciekawostka co nie da się w tym sensownie zależności dostarcza" - jak każdy, komu chciałoby się przejrzeć tę wymianę zdań, mógłby łatwo stwierdzić, zmyślasz moje wypowiedzi, a na to szkoda mi czasu. Pozdrawiam - V-2 2019-07-24 12:43
Ale czy używałeś Koina jakkolwiek w dużym projekcie, że go nie polecasz do dużych projektów? Jakie ograniczenia będą bardziej odczuwalne? - viader 2019-07-24 12:49
nie cytuję wypowiedzi tylko czytam między wierszami taki kontekst twoich wypowiedzi, że Koin przy Daggerze to zabawka, przykłady: ------- "ale nie nazwałbym go "uproszczonym Daggerem", bo to nie jest Dependency Injection, tylko typowy service locator " "Używając Service Locatora musisz dopisać je ręcznie:" "Service locator to jest zasadniczo antywzorzec. ... chociażby Jake Wharton też tak uważa." "Ja nie twierdzę, że Koin w ogóle nie nadaje się do użytku. Trzeba jednak dobrze rozumieć, czym ustępuje prawdziwemu DI." " te jego ograniczenia będą bardziej odczuwalne" - viader 2019-07-24 12:56
jeszcze ostatnia sprawa, którą przeoczyłem, miałbyś w Koinie prościej dla klasy D, mniej więcej tak: factory { D(get(), get()) } factory { Foo(get(), get(), get()) } factory { Bar(get(), get(), get() } Factory tworzy za każdym razem nowy obiekt jeśli jakiś get() chce tej klasy, można użyć także single (singleton w scopie) oraz viewModel (dla activities i fragmentów) - viader 2019-07-24 13:15
Odnośnie standardów jeszcze. Dagger 2 może nie jest standardem tylko standardem de facto na Androidzie, ale JSR-330 już takim standardem jest. Zatem w teorii gdyby wyszła jakaś nowa biblioteka trzymająca się tego standardu, to dużo łatwiej by było zrobić migrację, bo należałoby zmienić jedynie konfigurację. Android jest trochę bardziej podchwytliwy, bo brakuje czasem konstruktorów, ale zasadniczo niewiele trzeba by było w tym wypadku zmienić po stronie wstrzykiwanej klasy, jeśli piszemy z głową. - Michał Sikora 2019-07-24 18:02

Pozostało 580 znaków

2019-09-02 11:11
0

Ok poczytałem trochę sobie blogów o ViewModelach, korutynach itd.

Chciałbym to wszystko ograć beż żadnego frameworka DI - Daggera, Koina itd - apka mi się po prostu wydaje prosta.

Zastanawiam się tylko nad architekturą trochę i wstrzykiwaniem repozytoriów do ViewModeli oraz Api od retrofita do repozytoriów.. Najprostsze rozwiązania jakie widziałem to robienie RetrofitFactory jaki singletonu i zwracanie z niego po prostu api. Czytałem tylko, ze tu może być problem z memory leakami. Tak samo ludzie robili repo, że tworzyli singletony i tak używali w ViewModelach.

Jakieś lepsze sposoby na ogranie tego ręcznie bez DI frameworków ? Może gdzieś to spiąć w App ? Customowe fabryki do ViewModeli i refleksja ?

Pozdrawiam

Pozostało 580 znaków

2019-09-02 11:31
1

Przykład aplikacji z DI bez żadnych bibliotek do tego - https://github.com/handstandsam/ShoppingApp. Nie ma tam tylko żadnej warstwy prezentacji w stylu ViewModel.

Tak jak napisałeś, najlepsze co możesz zrobić, to spiąć to wszystko w onCreate() klasy Application i potem dobierać się do tego z Activity, itp. Jeśli koniecznie chcesz korzystać z ViewModel, to musisz stworzyć własną fabrykę i korzystać z niej w ViewModelProviders.of(), żeby przekazywać parametry do konstruktorów.

edytowany 7x, ostatnio: Michał Sikora, 2019-09-02 11:38

Pozostało 580 znaków

2019-09-02 11:42
0

@Michał Sikora:

Dzięki. A co proponujesz poza ViewModelami ? czy to nie jest obecnie takie topowe podejście ? Myślałem, że MVP już dawno odeszło.

edytowany 1x, ostatnio: Bambo, 2019-09-02 11:46

Pozostało 580 znaków

2019-09-02 12:00
0
Bambo napisał(a):

Dzięki. A co proponujesz poza ViewModelami ? czy to nie jest obecnie takie topowe podejście ?

ViewModel pewnie jest obecnie najbardziej popularnym podejściem. Mi się to rozwiązanie nie podoba i skorzystałbym z własnych klas i onRetainNonConfigurationInstance/onRetainCustomNonConfigurationInstance. W zasadzie z tego mechanizmu korzysta też ViewModel tylko dodaje dodatkowy narzut w postaci dodatkowego cyklu życia, wymuszonego dziedziczenia i korzystania z service locatora w oparciu o typy. Aczkolwiek w większości projektów komercyjnych korzystałem z niego, bo jest to szybsze, prostsze i bardziej znajome dla większości ludzi.

Bambo napisał(a):

Myślałem, że MVP już dawno odeszło.

Zależy co dla Ciebie znaczy MVP. Takiego klasycznego, że ma się interfejs View, klasę Presenter i one gadają miedzy sobą wywołując nawzajem na sobie jakieś metody, to faktycznie już raczej nie używa.

I teraz tak… ja tylko nie lubię tej biblioteki - https://developer.android.com[...]raries/architecture/viewmodel. Bo jak najbardziej jestem za jednokierunkowym przepływem danych i nasłuchiwaniem w widoku na dane (view model) z warstwy prezentacji. A że Google postanowił sobie nazwać prezenter ViewModel i wprowadzać zamieszanie, to już ich sprawa.

edytowany 3x, ostatnio: Michał Sikora, 2019-09-02 12:26

Pozostało 580 znaków

2019-09-02 12:09
V-2
0
Michał Sikora napisał(a):
Bambo napisał(a):

Dzięki. A co proponujesz poza ViewModelami ? czy to nie jest obecnie takie topowe podejście ?

ViewModel pewnie jest obecnie najbardziej popularnym podejściem. Mi się to rozwiązanie nie podoba i skorzystałbym z własnych klas i onRetainNonConfigurationInstance/onRetainCustomLastNonConfigurationInstance. W zasadzie z tego mechanizmu korzysta też ViewModel tylko dodaje dodatkowy narzut w postaci dodatkowego cyklu życia, wymuszonego dziedziczenia i korzystania z service locatora w oparciu o typy. Aczkolwiek w większości projektów komercyjnych korzystałem z niego, bo jest to szybsze, prostsze i bardziej znajome dla większości ludzi.

Metoda onRetainNonConfigurationInstance jest deprecated od niepamiętnych czasów (API 13 czy 15).

onRetainCustomNonConfigurationInstance (i getLastCustomNonConfigurationInstance) są deprecated od listopada, z zaleceniem używania ViewModels:

onRetainCustomNonConfigurationInstance has been deprecated. Use a ViewModel for storing objects that need to survive configuration changes.

źródło

Taka jest oficjalnie zalecana praktyka. Nie ma powodu iść pod prąd i wyważać drzwi otwartych, reimplementując rozwiązania z SDK.

A że Google postanowił sobie nazwać prezenter ViewModel i wprowadzać zamieszanie, to już ich sprawa.

Architektura jest dobrze znana każdemu .NET-owcowi. ViewModel ma modelować widok, i tyle. Architecture Components pozwala tak pisać. Jeśli ktoś pakuje do viewmodelu logikę (zamiast wyekstrahować ją gdzie indziej), libka oczywiście nie będzie w stanie go przed tym powstrzymać, ale winowajcą takiego zamieszania będzie ów programista, a nie Google.


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 3x, ostatnio: V-2, 2019-09-02 12:17

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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

Robot: CCBot