Myślę o zaimplementowaniu jednego ekranu z Activity
wszystkimi innymi ekranami z Fragments
i 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:
- Fragmenty mają być używane z działaniami jako działaniami podrzędnymi.
- Fragmenty nie zastępują działań.
- Fragmenty są przeznaczone do ponownego wykorzystania (należy wiedzieć, w jaki sposób można je wykorzystać).
- Fragmenty to najlepszy sposób na napisanie kodu obsługującego zarówno tablety, jak i telefony.
Cons:
- Musimy zaimplementować interfejs, aby uzyskać dane z fragmentów.
- 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?
Odpowiedzi:
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
Activity
podejścia i nawigacji w stylu Facebooka. Podczas wybierania elementów z listy nawigacji aktualizuję pojedynczyFragment
kontener, aby wyświetlić tę sekcję.To powiedziawszy, posiadanie singla
Activity
ró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,startActivityForResult
aleFragments
nie ma czegoś takiego, więc kończysz zapisując wartość wActivity
głównym fragmencie edycji,Activity
aby sprawdzić, czy dane zostały wybrane i powinny zostać wyświetlone użytkownikowi.To, co Aravind mówi o przywiązaniu do jednego
Activity
typu, jest również prawdą, ale tak naprawdę nie ogranicza. Twoja aktywność byłaby FragmentActivity i tak długo, jak nie potrzebujesz,MapView
nie ma żadnych prawdziwych ograniczeń. Jeśli jednak chcesz wyświetlać mapy, możesz to zrobić, ale musisz albo zmodyfikować bibliotekę zgodności Androida, abyFragmentActivity
rozszerzyćMapActivity
lub użyć publicznie dostępnych android-support-v4-googlemaps .Ostatecznie większość deweloperów, których znam, którzy poszli tą samą
Activity
drogą, 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 jednegoActivity
tylko po to, aby osiągnąć szaloną interakcję, którą wymyślą twoi projektanci :)-- EDYTOWAĆ --
Google w końcu udostępnił
MapFragment
bibliotekę 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
źródło
settargetfragment
i możesz poradzić sobie z taką czynnością jakstartforresult
procedura.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
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.Cons
źródło
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?
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?
źródło
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 stanonSaveInstanceState
i być przywracane (np. Podczas wznawiania po połączeniu przychodzącym lub gdy użytkownik kliknie przycisk Wstecz).Cons
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.
źródło
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.
źródło
Plusy:
Cons:
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.
źródło
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.
źródło
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
onPause
ionResume
. 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ć.źródło