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

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?

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

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

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) są 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?

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.

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.

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.

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.

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ć.