Fragmenty Androida: kiedy używać funkcji ukrywania / pokazywania lub dodawania / usuwania / zastępowania?


117

Załóżmy, że chcę zastąpić bieżący fragment w widoku kontenera innym. Czy lepiej jest użyć wymiany ...

    FragmentTransaction ft = getSupportFragmentManager().beginTransaction();
    ft.replace(R.id.fragment_container, newFragment, null);
    ft.commit();

... lub następujące, z funkcją show and hide?

    FragmentTransaction ft = getSupportFragmentManager().beginTransaction();
    ft.hide(oldFragment);
    ft.show(newFragment);
    ft.commit();

Czy można to zrobić bardziej wydajnie? Nie można znaleźć zbyt wielu informacji na temat tego, kiedy należy użyć tych metod lub jak wpływają one na cykl życia fragmentów, których to dotyczy. Dzięki!


jeśli przejdę do fragmentu B z fragmentu A, a następnie wrócę do fragmentu A, w jaki sposób mogę się upewnić, że zdarzenie cyklu życia, takie jak onCreateView, nie jest wywoływane dla fragmentu A? działa funkcja znajdowania fragmentów po tagu?
blackHawk

Odpowiedzi:


135

Powinieneś rozważyć, co planujesz zrobić z fragmentem, aby zdecydować, którą ścieżką podążać. Jeśli używasz FragmentTransaction, aby ukryć fragment, może on nadal znajdować się w stanie działania swojego cyklu życia, ale jego interfejs użytkownika został odłączony od okna, więc nie jest już widoczny. Możesz więc technicznie nadal wchodzić w interakcję z fragmentem i później ponownie dołączyć jego interfejs użytkownika. Jeśli zastąpisz fragment, faktycznie wyciągasz go z pojemnika i przejdzie on przez wszystkie zdarzenia porzucenia w cyklu życia (onPause, onStop itp.), A jeśli z jakiegoś powodu będziesz potrzebować tego fragmentu ponownie, będziesz musiał włóż go z powrotem do kontenera i pozwól mu przejść przez całą inicjalizację.

Jeśli istnieje duże prawdopodobieństwo, że będziesz potrzebować tego fragmentu ponownie, po prostu go ukryj, ponieważ ponowne narysowanie jego układu jest mniej kosztowną operacją niż jego całkowita ponowna inicjalizacja.


5
Dla naszych potrzeb inicjalizacja fragmentu jest dość kosztowna, więc prawdopodobnie pójdziemy hide()i show()zaoszczędzimy na tym! Dzięki za to!
Robert Karl

2
Cześć, kiedy mówisz odłącz od okna, czy masz na myśli wywołanie funkcji zwrotnej onDetach ()? Eksperymentowałem z tym, wydaje się, że tak nie jest.
GingerJim

prawdopodobnie miał na myśli „odłącz się”; fragment można również odłączyć / ponownie
podłączyć

1
@Zainodis, ja też mam ten sam problem. Moim rozwiązaniem jest zapisanie stanu ukrytego fragmentu w onSaveInstanceState () - saveInstanceState.putBoolean (STATE_HIDDEN, isHidden ()); następnie w onCreate () if (saveInstanceState! = null) odzyskuje stan ukryty, a jeśli fragment jest ukryty, ukryj go wraz z transakcją.
worawee.s

1
@ worawee.s Hej i dzięki za aktualizację :)! Jakiś czas temu rozwiązałem problem - tak naprawdę nie potrzebowałem ukrywania / pokazywania itp., Więc całkowicie go porzuciłem i teraz idę ze standardami takimi jak dodaj / zamień lub działania pojedynczego fragmentu w pojedynczym panelu (w zasadzie przepływ szczegółów głównych) . Dla tych, którzy nadal używają hide, Twoje rozwiązanie będzie naprawdę pomocne - a brak sprawdzania saveInstance! = Null był jednym z błędów, które wcześniej popełniłem.
AgentKnopf,

5

Zasadniczo odpowiedziałeś sobie. Jeśli chcesz zastąpić (więc stary fragment nie jest już potrzebny) użyj, replace()jeśli chcesz go tymczasowo ukryć, a następnie zrób hide().


Zasadniczo wymiana nie usuwa wszystkich. Nie mogłem znaleźć pasującego hideAll :(
AlikElzin-kilaka

@ AlikElzin-kilaka W mojej aktywności 3 fragment we wszystkich trzech fragmentach pobieram dane z sieci, którą metodę powinienem zastosować
Mansukh Ahir

0

Użyłem metody hide / Show w mojej aktywności z 4 fragmentami, co rozwiązało moje rozwiązanie, ale czasami losowo, gdy pokazuję moje okno dialogowe, powoduje to wyjątek złego tokena okna, gdy użyłem metody add i replace, a następnie zły wyjątek tokena nie występuje, więc myślę, że pokaż / metoda ukrywania nie jest idealna

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.