Cześć taki luźny temat nt waszych odczuć z rozwojem/ utrzymaniem/ łataniem bugów przy aplikacjach napisanych natywnie na androida i iOS.
Jest ktoś kto kodził apki na dwa systemy?
Gdzie wolicie robić widoki? Ja np nie lubię tworzyć tych wszystkich zależności związanych z fragmentami, menu, scroll view, osobiście gubię się w androidzie i zastanawiam się czy na iOS jest tak samo. Mam doświadczenie stricte w swoich projektach, nigdy nie pracowałem komercyjnie z tymi technologiami.
UI na iOS jest lepiej zaprojektowany i przemyślany. Omijałbym tylko szerokim łukiem Storyboard i udawał, że coś takiego nie istnieje.
alMarko napisał(a):
Ja np nie lubię tworzyć tych wszystkich zależności związanych z fragmentami, menu
Problem znika, jeśli nie korzysta się z fragmentów. Menu rozumiem, że chodzi Ci w połączeniu z onCreateOptionsMenu()? Jeśli tak, to problem też znika, jak się z tego nie korzysta (jak i z całego dobrodziejstwa ActionBar).
@Michał Sikora: ciekawe rzeczy piszesz, bo niektórzy storyboard przedstawiają jako największą zaletę, a i Google pozazdrościł tego i jak się zdaje, wprowadza coś podobnego w Androidzie: https://developer.android.com/guide/navigation
Nie, graf nawigacyjny to coś innego niż Storyboard. Storyboard służy też do budowania UI, coś jak Layout Editor na Androidzie, z którego też nikt na poważnie nie korzysta. Ze Storyboarda nie da się sensownie korzystać pracując w kilka osób, bo masz cały czas nieczytelne konflikty w gicie.
Ok, myślałem że to tylko przejścia. No ale z edytora layoutów w Androidzie to się chyba czasem korzysta, zwłaszcza pracę z ConstraintLaoutem znacznie jednak ułatwia. Chociaż, dodanie nowej kontrolki i wstawienie jej np pomiędzy inne, które mają poustawiane constrainty względem siebie to w edytorze wizualnym by była męka
Nie wiem, nigdy nie miałem potrzeby z korzystania z Layout Editora do czegokolwiek poza podglądem (ale ten aspekt jest akurat przydatny). Jak komuś ułatwia to pracę, to ok, może faktycznie tak jest. Sam po prostu wolałbym się powiesić i nikt z moich znajomych czy ludzi z firmy nie korzysta z tego. Możliwe, że Motion Editor jest jakoś przydatny pod tym względem, ale też do tej pory nie miałem potrzeby i szybciej tworzyłem wszystko z palca - ponownie, podgląd dalej jest przydatny.
No pewnie dlatego we Flutterze już nie ma w ogóle edytora, a jest tylko szybki podgląd
alMarko napisał(a):
Ja np nie lubię tworzyć tych wszystkich zależności związanych z fragmentami, menu
Problem znika, jeśli nie korzysta się z fragmentów. Menu rozumiem, że chodzi Ci w połączeniu z
onCreateOptionsMenu()? Jeśli tak, to problem też znika, jak się z tego nie korzysta (jak i z całego dobrodziejstwaActionBar).
@Michał Sikora Tak korzystam z metody onCreateOptionsMenu(). Moje menu to navigation drawer. Jak inaczej mógłbym zrobić menu z navigation drawer?
Jak można nie korzystać z fragmentów? Chyba nie miałbym tworzyć Activity na każdy ekran?
No navigation drawer jest już niemodny. Co do fragmentów, to możesz nie używać i zamiast tego opakować sobie podmienianie widoków, albo skorzystać z gotowych rozwiązań, które to robią.
alMarko napisał(a):
@Michał Sikora Tak korzystam z metody onCreateOptionsMenu(). Moje menu to navigation drawer. Jak inaczej mógłbym zrobić menu z navigation drawer?
Zależy co w tym menu ma być. Ciężko powiedzieć z góry. Najogólniejszym rozwiązaniem byłby RecyclerView.
Jak można nie korzystać z fragmentów? Chyba nie miałbym tworzyć Activity na każdy ekran?
Ja osobiście korzystam tylko z widoków. Są też inne rozwiązania typu Conductor, które są dużo lepszą abstrakcją niż fragmenty. Jakbym był zmuszony do korzystania z fragmentów to na pewno nie korzystałbym z fragment managera, do kontroli stosu nawigacyjnego. Ponoć wklejony wcześniej navigation component ratuje sytuację. Do większości aplikacji pewnie będzie w porządku, ale moim zdaniem jest dalej za mało elastyczny. Ciężko mi się na jego temat wypowiedzieć głębiej, bo nie korzystałem.
Możecie coś podlinkować o tych widokach? (jakiś przykład na github lub artykuł co i jak) Bo ja tego nie czuję i nie wiem o czym dokładnie piszecie i jak to zaimplemenotwać.
Bo zakładam że tam jest jedno activity ale jakoś layouty trzeba podmieniać. W tym artykule https://android.jlelse.eu/the-dark-side-of-fragments-ca0f871b1199 pisali na dole o używaniu ViewGroup zamiast fragmentów
Kilka przykładów.
https://github.com/square/leakcanary/tree/master/leakcanary-android-core/src/main/java/leakcanary
https://github.com/square/coordinators
https://github.com/Zhuinden/simple-stack
https://github.com/JakeWharton/u2020 -> Tego nie traktowałbym jako przykład o nawigacji na widokach. Po prostu coś bardziej skomplikowanego, co z tego korzysta.
https://github.com/MiSikora/Squash-It/tree/master/squash-it/library/src/main/java/io/mehow/squashit -> Tutaj też dużo nawigacji nie ma (i raczej jest słaba), ale działa na samych widokach.
I wspomniany Conductor: https://github.com/bluelinelabs/Conductor/blob/develop/README.md
dzięki za linki :) poczytam i zastosuje u siebie
Moim zdaniem da się poprawić mechanizm standardowy nawigacji fragmentów i wykorzystać je do budowy fajnej nawigacji. Byłem tech leadem tej aplikacji (https://play.google.com/store/apps/details?id=com.empik.empikapp) i całość nawigacji skupia się na zmianie fragmentów.
Tylko nie jest to trywialny temat :) Swoją drogą wiele osób prosi mnie o wypuszczenie biblioteki z poprawą tego standardowego mechanizmu (bo jest mojego autorstwa), także jest szansa, że coś wrzucę.
Ciekawe czy kogoś jeszcze to obchodzi, ale w końcu jest (prawie) pełna obsługa javy 8 bez względu na minimum api, jedna z nowości wraz z Android Studio 4