Dlaczego warto korzystać z fragmentów Androida?


15

Przeczytałem dokumentację i kilka innych wątków pytań na ten temat i tak naprawdę nie jestem przekonany; Nie widzę wyraźnie granic zastosowania tej techniki.

Fragmenty są teraz postrzegane jako najlepsza praktyka ; każde działanie powinno zasadniczo wspierać jeden lub więcej fragmentów i nie może bezpośrednio wywoływać układu.

Fragmenty są tworzone w celu:

  1. pozwalają na Activityużycie wielu fragmentów, na zmianę między nimi, na ponowne użycie tych jednostek ... ==> Fragmentjest całkowicie zależne Contextod działania, więc jeśli potrzebuję czegoś ogólnego, z którego mogę ponownie korzystać i obsługiwać wiele działań, mogę tworzyć własne niestandardowe układy lub widoki ... Nie będę się martwić o tę dodatkową warstwę rozwijającą złożoność, którą dodawałyby fragmenty.

  2. lepsza obsługa do innej rozdzielczości ==> OK dla tabletów / telefonów w przypadku długiego procesu, w którym możemy pokazać dwa (lub więcej) fragmenty w tej samej Aktywności na Tabletach i jeden po drugim w telefonach. Ale dlaczego miałbym zawsze używać fragmentów ?

  3. obsługa wywołań zwrotnych w celu nawigowania między Fragmentami (tj .: jeśli użytkownik jest zalogowany, pokazuję fragment, a inny pokazuję inny fragment). ===> Po prostu spróbuj zobaczyć, ile błędów na Facebooku ma SDK z tego powodu, aby zrozumieć, że to naprawdę (?) ...

  4. biorąc pod uwagę, że aplikacja na Androida opiera się na działaniach ... Dodanie kolejnych cykli życia w ćwiczeniu byłoby lepiej zaprojektować aplikację ... Mam na myśli, że moduły, scenariusze, zarządzanie danymi i łączność byłyby lepiej zaprojektowane, ponieważ sposób. ===> To jest odpowiedź kogoś, kto widział Android SDK i Android Framework z wizją Fragmentów. Nie sądzę, że to źle, ale nie jestem pewien, czy przyniesie dobre rezultaty ... I to jest naprawdę abstrakcyjne ...

====> Dlaczego miałbym komplikować swoje życie, kodując więcej, używając ich zawsze? inaczej, dlaczego jest to najlepsza praktyka, jeśli jest tylko narzędziem w niektórych przypadkach? jakie są te przypadki?


1
Nie jest jasne, o co pytasz, czy mógłbyś streścić pytanie, może poniżej wyliczenia rzekomych korzyści i swojej krytyki każdego z nich?
logc

Dodałem szczegółowe pytanie.
ahmed_khan_89

Zgubiłem się jak @logc. Jak poradziłbyś sobie z tymi przypadkami bez fragmentów?
neontapir

Dałem to, co bym zrobił bez Fragmentów: (1) tworzenie niestandardowych ogólnych kontrolek i ponowne użycie ich tam, gdzie chcę (2) za pomocą 2 działań i nawigowanie za pomocą startActivityForResult, lub po prostu zmienianie widoków (pokazywanie / ukrywanie, pompowanie / usuwanie ...) bez kodowania tak dużo ... (3) możesz użyć oddzwaniania nawet w Działaniach z widokami (4) To abstrakcyjna odpowiedź, którą zawsze otrzymuję, kiedy
omawiam

1
Hmm Te pytania i odpowiedzi pokazują ograniczenie projektu stackexchange, w którym oryginalny plakat wybiera „najlepszą” odpowiedź. (W przeciwieństwie do slant.co, gdzie wszyscy głosują.) Nie jest to idealne rozwiązanie dla takich szerokich pytań. Tutaj niejasne pytanie otrzymuje akceptowaną odpowiedź, która oczywiście zgadza się z tym, co pytający chciał usłyszeć. Jeśli nie widzisz powodu, aby używać fragmentu w swojej sytuacji, nie rób tego. Lepszym pytaniem byłoby pytanie o zalety / wady fragmentu a aktywność . I jest wiele wątków na ten właśnie temat.
ToolmakerSteve

Odpowiedzi:


5

Fragment jest modułową sekcją działania, która ma własny cykl życia, odbiera własne zdarzenia wejściowe, które można dodawać lub usuwać podczas działania (coś w rodzaju „działania podrzędnego”, które można ponownie wykorzystać w różnych działaniach)

Poza oczywistą zaletą korzystania z fragmentów, optymalizacja interfejsu użytkownika na różnych ekranach, pozwala zarządzać przetwarzaniem działania w tle bez widocznego komponentu interfejsu użytkownika.

Teraz...

====> Dlaczego miałbym komplikować moje życie, kodując więcej ... ??

Chociaż jest to zalecane, nie musisz tego robić, chyba że planujesz kontrolować cykl życia poszczególnych elementów i / lub ponownie wykorzystywać stan stosu lub historię poprzednich widoków.


5

Jeśli istnieje przypadek użycia „bramy” dla sceptyków fragmentów, prawdopodobnie są to okna dialogowe. Odległe przestarzałe metody showDialog(...), onCreateDialog(...)itp, były ładne, że ramy nazwałbym je automatycznie zniszczyć i odtworzyć dialogi, gdy aktywność gospodarzem był zniszczony i odtworzony. Jeśli bezpośrednio tworzysz własne okna dialogowe, musisz samodzielnie zarządzać wszystkimi tymi rzeczami. Ale jeśli używasz DialogFragment, możesz ponownie pozwolić, aby środowisko zarządzało nimi za Ciebie. W takim przypadku fragmenty mogą znacznie uprościć kodowanie.


1

Zadałem to pytanie ponad rok temu.

Używam fragmentów codziennie i poleciłbym to.

Przede wszystkim chcę powiedzieć, że używanie fragmentów jest tylko opcją i będzie odruchem, aby rozważyć to, gdy zaczniesz ich używać.

Zalety:

1 / pomaga zmodularyzować kod, dzięki czemu możesz mieć pełny przepływ w jednym działaniu, w oddzielnych fragmentach. Przykład: + lista / siatka i szczegóły, + logowanie i rejestracja i zapomnij hasło, + itd. To niesamowite, aby otrzymać kod wielokrotnego użytku, który zawsze możesz skopiować i wkleić w różnych projektach.

2 / masz nowy cykl życia, pełen kłopotów, to prawda, ale także z zaletami. Przykład: zachowany fragment instancji jest niesamowity, ponieważ rozwiązuje problem orientacji.

3 / możesz zarządzać przepływem swoich fragmentów według zdarzeń i słuchaczy z działania.

4 / stos twoich fragmentów w swojej Aktywności.

5 / użyj tego samego paska akcji na wielu ekranach.

I wiele innych...

Nadal czasami używam Activity jako jedynego kontenera, szczególnie w przypadku aparatu. Niektóre interfejsy API Androida i niektóre biblioteki stron trzecich nie są łatwe do wdrożenia we fragmentach.

Cóż, to jest jak każde narzędzie, musisz je rozważyć i sam ocenić, czy lepiej jest użyć go w sprawie.

Mam nadzieję, że to może pomóc !!!

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.