Jedno działanie i wszystkie inne fragmenty [zamknięte]


158

Myślę o zaimplementowaniu jednego ekranu z Activitywszystkimi innymi ekranami z Fragmentsi managing all the fragments thru the activity.

Czy to dobry pomysł? a moja odpowiedź brzmi NIE, ale nadal chcę wiedzieć więcej o tej myśli.

Jakie są wady i zalety tego pomysłu?

Uwaga:

Proszę nie podawać mi linku do fragmentu i aktywności.

EDYTOWAĆ:

Oto coś na temat fragmentów i aktywności:

Plusy:

  1. Fragmenty mają być używane z działaniami jako działaniami podrzędnymi.
  2. Fragmenty nie zastępują działań.
  3. Fragmenty są przeznaczone do ponownego wykorzystania (należy wiedzieć, w jaki sposób można je wykorzystać).
  4. Fragmenty to najlepszy sposób na napisanie kodu obsługującego zarówno tablety, jak i telefony.

Cons:

  1. Musimy zaimplementować interfejs, aby uzyskać dane z fragmentów.
  2. W przypadku dialogu musimy przejść długą drogę, aby to pokazać.

Dlaczego powinniśmy używać fragmentów, jeśli nie myślimy o tabletach? Jaka jest różnica czasu rozpoczęcia między aktywnością a fragmentem?


Czy możesz wyjaśnić, dlaczego uważasz, że odpowiedź brzmi „nie”? Tak się składa, że ​​się nie zgadzam, ale łatwiej jest odnieść się do obaw, które możesz mieć w związku z tym podejściem, jeśli wiemy, jakie one są.
Alexander Lucas

1
@AlexanderLucas Odpowiedź, której udzieliłem nie, ponieważ czyni to kod mniej modułowym i zwiększa złożoność.
Vineet Shukla,

@Ski Bardziej koncentrujesz się na tym, aby Twoja odpowiedź została zaakceptowana, plz skoncentruj się na tym, o co jest pytane i jaka powinna być najlepsza odpowiedź, której możesz udzielić.
Vineet Shukla,

3
Dla każdego, kto to znajdzie, zatrzymałem refaktor, ponieważ sprawy bardzo szybko się skomplikowały.
theblang

18
To dobre pytanie i nie powinno być zamykane.
Jim In Texas,

Odpowiedzi:


94

To zależy od tworzonej aplikacji. Stworzyłem kilka aplikacji, używając obu podejść i nie mogę powiedzieć, że jeden sposób jest zawsze lepszy od drugiego. W najnowszej aplikacji, którą stworzyłem, korzystałem z pojedynczego Activitypodejścia i nawigacji w stylu Facebooka. Podczas wybierania elementów z listy nawigacji aktualizuję pojedynczy Fragmentkontener, aby wyświetlić tę sekcję.

To powiedziawszy, posiadanie singla Activityrównież wprowadza wiele zawiłości. Załóżmy, że masz formularz edycji i dla niektórych elementów, które użytkownik musi wybrać lub utworzyć, wymaga przejścia do nowego ekranu. W przypadku działań, które nazwalibyśmy po prostu nowym ekranem, startActivityForResultale Fragmentsnie ma czegoś takiego, więc kończysz zapisując wartość w Activitygłównym fragmencie edycji, Activityaby sprawdzić, czy dane zostały wybrane i powinny zostać wyświetlone użytkownikowi.

To, co Aravind mówi o przywiązaniu do jednego Activitytypu, jest również prawdą, ale tak naprawdę nie ogranicza. Twoja aktywność byłaby FragmentActivity i tak długo, jak nie potrzebujesz, MapViewnie ma żadnych prawdziwych ograniczeń. Jeśli jednak chcesz wyświetlać mapy, możesz to zrobić, ale musisz albo zmodyfikować bibliotekę zgodności Androida, aby FragmentActivityrozszerzyć MapActivitylub użyć publicznie dostępnych android-support-v4-googlemaps .

Ostatecznie większość deweloperów, których znam, którzy poszli tą samą Activitydrogą, wróciła do wielu działań, aby uprościć swój kod. Jeśli chodzi o interfejs użytkownika, na tablecie czasami utkniesz, używając jednego Activitytylko po to, aby osiągnąć szaloną interakcję, którą wymyślą twoi projektanci :)

-- EDYTOWAĆ --

Google w końcu udostępnił MapFragmentbibliotekę kompatybilności, więc nie musisz już używać hackowania android-support-v4-googlemaps. Przeczytaj o aktualizacji tutaj: Google Maps Android API v2

- EDYCJA 2 -

Właśnie przeczytałem ten wspaniały post o współczesnym (2017) stanie fragmentów i przypomniałem sobie tę starą odpowiedź. Pomyślałem, że podzielę się: Fragmenty: rozwiązanie wszystkich problemów Androida


6
Jest settargetfragmenti możesz poradzić sobie z taką czynnością jak startforresultprocedura.
Lalith B

1
Moim zdaniem działania istnieją tylko dlatego, że to stary system. Fragment wcześniej nie istniał. Naprawdę nie ma nic, czego nie mogą robić działania i fragmenty, poza formalnościami. Mogłabym sobie nawet wyobrazić, że w pewnym momencie czynności są usuwane i wszystko jest fragmentem.
Ixx

1
Podsumowując wady fragmentów - tylko dajesz, tak naprawdę nie ma. startActivityForResult, jak mówi Lalith B, ma odpowiednik, a mapy również nie są problemem. Poza tym wszystko (stan zapisu itp.) Można obsłużyć metodami cyklu życia fragmentu.
Ixx

85

Niedługo skończę projekt (trwający 5 miesięcy), który ma 1 aktywność i 17 fragmentów, wszystkie na pełnym ekranie. To mój drugi projekt oparty na fragmentach (poprzedni miał 4 miesiące).

Plusy

  • Głównym działaniem jest 700 linii kodu, po prostu ładnie zarządzających kolejnością nawigacji po fragmentach.
  • Każdy fragment jest ładnie podzielony na swoją własną klasę i jest stosunkowo mały (~ kilkaset linii elementów interfejsu użytkownika).
  • Kierownictwo może powiedzieć „hej, a może zmienimy kolejność tych ekranów”, a ja mogę to zrobić bardzo łatwo, ponieważ te fragmenty nie zależą od siebie nawzajem, wszystkie komunikują się poprzez działanie. Nie muszę przekopywać się przez poszczególne czynności, aby dowiedzieć się, jak się nazywają.
  • moja aplikacja jest bardzo obciążona grafiką i nigdy nie działałaby jako 1 ekran 1. Wszystkie te czynności podrzędne w pamięci sprawiłyby, że aplikacja cały czas zabrakło pamięci, więc musiałbym wykonywać finish()wszystkie niewidoczne czynności i stosować tę samą logikę sterowania dla nawigacji, jak w przypadku fragmentów. Równie dobrze możesz to zrobić z fragmentami tylko z tego powodu.
  • jeśli kiedykolwiek zrobimy aplikację na tablety, będzie nam łatwiej przerobić rzeczy, ponieważ wszystko jest już ładnie rozdzielone.

Cons

  • musisz się nauczyć, jak używać fragmentów

1
Nie byłem pewien, czy masz zbyt wiele fragmentów i dopiero teraz aktywność ... żadnych problemów z produkcją, a wina spoczywa na Tobie !! :)
Shahar,

1
@Dinash nie pozwól, aby system operacyjny wznowił Twoją aktywność. poradzić sobie ze zmianą orientacji samodzielnie. czytaj więcej tutaj: stackoverflow.com/questions/5913130/…
Tamas

1
@Tamas Czy masz jakieś ekrany z wieloma fragmentami (np. Master-detail), a jeśli tak, jak sobie z tym poradziłeś?
theblang

7
@Tamas To podejście jest mocno anty androidowe. Kończysz z klasą BOGA. System Android jest przeznaczony do pracy z działaniami - np. Nie masz przyjemnego sposobu obsługi pasków narzędzi w wielu fragmentach. Nie masz fragmentu początkowego dla wyniku, a wiele więcej nie ma. Oznacza to, że musisz przepisać całą logikę, która już istnieje. A co z lokalnymi odbiornikami, usługami i innymi komponentami Androida. Aby uruchomić usługę, musisz wykonać następujące czynności: getActivity ()! = Null ... to jest naprawdę brzydkie. Również komunikacja między fragmentami jest bardzo dziwna, jeśli masz dużo fr.
Teodor

9
700 linii !!!! "ładnie"???? Zajęcia są bezpłatne.
beplaya

16

Po pierwsze, cokolwiek robisz, upewnij się, że masz modułowy projekt wykorzystujący model, widok, prezentera, który nie jest w dużym stopniu zależny od działania lub fragmentu.

Co naprawdę zapewniają Działania i Fragmenty?

  1. Wydarzenia cyklu życia i backstack
  2. Kontekst i zasoby

Dlatego używaj ich TYLKO do tego . Mają dość odpowiedzialności, nie komplikuj ich zbytnio. Twierdziłbym, że nawet intantowanie TextView w działaniu lub fragmencie jest złą praktyką. Istnieje powód, dla którego metody takie jak public View findViewById (int id)PUBLICZNE .

Teraz pytanie staje się prostsze: czy potrzebuję wielu niezależnych wydarzeń w cyklu życia i plecaków? Jeśli myślisz, że tak, użyj fragmentów. Jeśli myślisz nigdy, przenigdy, nie używaj fragmentów.

W końcu możesz stworzyć własny backstack i cykle życia. Ale po co odtwarzać koło?

EDYCJA: Po co głosować w dół? Zajęcia jednocelowe ludzie! Każde działanie lub fragment powinny mieć możliwość utworzenia wystąpienia osoby prowadzącej, która tworzy instancję widoku. Prezenter i widok to moduły, które można wymieniać. Dlaczego za działanie lub fragment powinien odpowiadać prezenter?


Hm ... związek między tworzeniem instancji widoku będącym złą praktyką a publicznym findViewById () jest niejasny. Chociaż zgadzam się co do tworzenia instancji widoków, uważam również wywołanie findViewById z innej klasy (np. Aktywność hostująca fragment wywołuje go na fragmencie) za złą praktykę. Naprawdę nie wiem, dlaczego jest to publiczne, ponieważ przynajmniej w przypadkach, które przychodzą mi do głowy, powoduje to niechlujny kod, a nie modułową konstrukcję.
Ixx

IMHO: Jeśli przekażesz działanie swojemu widokowi i prezenterowi (nazywając 2 połączone „modułem”), zezwalasz na ponowne wykorzystanie tego modułu w innych działaniach. Jeśli to pomoże, najlepiej będzie przekazać to ćwiczenie jako wprowadzenie, które ujawnia jedynie niezbędne rzeczy. Jeśli nie znosisz znajdowania widoków spoza działań, możesz wstrzyknąć wszystkie widoki, za pośrednictwem tego interfejsu, do wstępu / widoku. Główną kwestią jest to, że uważam, że kodowanie Androida powinno odbywać się poza koncepcją Actvities and Frags, tak aby zmiana między dwoma jest łatwa. kod.
beplaya

3
Puść MVP, będziesz lepiej bez niego dla Androida. Możesz spędzić dużo czasu, próbując dopasować pewien blok kształtu przez otwór o innym kształcie, z pewnością jest to wyzwanie, ale prawdopodobnie istnieją wymagania funkcjonalne, nad którymi rozsądniej byłoby spędzać czas.
straya

12

Plusy

Możesz kontrolować swoje fragmenty z jednej czynności, ponieważ wszystkie fragmenty są od siebie niezależne. Fragmenty mają cykl życia ( onPause, onCreate, onStart...) własnych. Mając cykl życia, fragmenty mogą niezależnie reagować na zdarzenia, zapisywać swój stan onSaveInstanceStatei być przywracane (np. Podczas wznawiania po połączeniu przychodzącym lub gdy użytkownik kliknie przycisk Wstecz).

Cons

  1. Stwórz złożoność w swoim kodzie działania.
  2. Musisz zarządzać kolejnością fragmentów.

Niemniej jednak jest to całkiem dobry pomysł, jakbyś chciał stworzyć aplikację, w której chcesz pokazać kilka widoków. Zgodnie z tym pomysłem będziesz w stanie wyświetlić kilka fragmentów w jednym widoku.


2

To zależy od układu projektu Twojej aplikacji. Załóżmy, że jeśli używasz kart w ActionBar w układzie projektu, to w pojedynczym działaniu aplikacji możesz mieć fragmenty zmieniane po kliknięciu karty. Więc teraz masz działanie i powiedz, że załóżmy trzy zakładki na pasku akcji i widok zakładek dostarczany przez fragmenty, co ułatwia zarządzanie, a plus jest również wykonalny. Wszystko zależy więc od schematu projektu Twojej aplikacji i tego, jak podejmiesz decyzję o jej zbudowaniu.


1

Plusy:

  • Może być użyty do stworzenia pojedynczego interfejsu używanego przez wiele rozmiarów i orientacji ekranu poprzez układy XML.

Cons:

  • Wymaga bardziej złożonego kodu w Twojej działalności.

Uważam, że to dobry pomysł, ponieważ używanie różnych układów XML w zależności od aktualnego rozmiaru i orientacji ekranu może zwiększyć użyteczność aplikacji i zmniejszyć potrzebę wydawania wielu wersji aplikacji, jeśli planujesz wydać aplikację zarówno na telefony, jak i tablety. Jeśli Twoja aplikacja nigdy nie będzie używana zarówno przez tablety, jak i telefony, prawdopodobnie nie jest to warte zachodu.


Dla orientacji nie jest konieczne używanie różnych układów opartych na XML.
Vineet Shukla,

@VineetShukla prawda, ale jest to opcja, podobnie jak używanie różnych układów XML w zależności od rozmiaru ekranu. Na przykład ekran główny mojego telefonu z Androidem ma inny układ, gdy oglądam go w orientacji poziomej i pionowej.
Ski

0

Jestem zwolennikiem odkładania wszystkich poglądów na inflację na fragmenty, aby zapewnić większą elastyczność. Na przykład jedno działanie związane z lądowaniem na tablecie, które gromadzi wiele fragmentów i ponownie wykorzystuje te same fragmenty na telefonie, aby wyświetlić jeden ekran na fragment. Jednak we wdrożeniu telefonicznym miałbym osobną aktywność dla każdego ekranu. Działania nie miałyby zbyt dużego kodu, ponieważ od razu przeszłyby do ich fragmentarycznego odpowiednika, aby zobaczyć inflację.

Myślę, że to zły pomysł, aby implementacja telefonu musiała zmienić się na jedno działanie typu landing, gdy wprowadzane są zakładki lub wysuwane menu, ponieważ nawigacja po zakładkach lub menu powoduje po prostu zupełnie nowy ekran.


„Myślę, że to zły pomysł, aby implementacja telefonu musiała zmienić się w jedno działanie typu landing page, kiedy wprowadzane są zakładki lub wysuwane menu, ponieważ nawigacja po zakładkach lub menu powoduje po prostu zupełnie nowy ekran”. -> Nie jest zrozumiałe, co dokładnie masz na myśli, ale ani zakładki, ani menu boczne nie stanowią problemu w aplikacji jednorazowej (tablet / telefon).
Ixx

-1

Najważniejszym powodem, dla którego chciałbym nie stosować podejścia opartego na pojedynczej czynności, jest to, aby można było wykorzystać cykl życia działania. Działania zawierają kontekstowe zachowanie określonej części aplikacji, a fragmenty tego zachowania uzupełniają. Możliwość skorzystania z możliwych do pominięcia etapów cyklu życia działania pomaga oddzielić zachowanie jednej czynności od innej za pomocą metod takich jak onPausei onResume. Ten cykl życia umożliwia również powrót do poprzedniego kontekstu. W podejściu opartym na pojedynczej aktywności, gdy opuścisz fragment, musisz stworzyć mechanizm, aby do niego wrócić.


4
Nie wierzę, że to prawda. Z dokumentacji cyklu życia fragmentu ( developer.android.com/guide/components/fragments.html#Lifecycle ): „Cykl życia działania, w którym żyje fragment, bezpośrednio wpływa na cykl życia fragmentu, tak że każde wywołanie zwrotne cyklu życia dla działania powoduje podobne wywołanie zwrotne dla każdego fragmentu. Na przykład, gdy działanie otrzymuje onPause (), każdy fragment w działaniu otrzymuje onPause (). ”
narty
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.