Fragment czy fragment wsparcia?

Tworzę aplikację obsługującą system Android> = 4.0. Wykorzystuje fragmenty z android.apppakietu. Ponieważ mam problemy ze starszą implementacją fragmentów w wersji 4.0, taką jak ta , które zostały już naprawione w bibliotece wsparcia, rozważam powrót do implementacji fragmentu z biblioteki obsługi, aby uzyskać bardziej niezawodną i spójną implementację.

Jaka jest twoja opinia na ten temat? Czy używasz fragmentów z biblioteki wsparcia, mimo że są już dostępne, podczas tworzenia dla Androida 4?

Z mojego doświadczenia wynika, że ​​korzystanie z tej samej implementacji fragmentów na wszystkich urządzeniach z Androidem jest wielką zaletą. Nie mogłem pozbyć się wszystkich wyjątków NullPointerExceptions, gdy stan jest zapisywany na Androidzie 4.0 przy użyciu natywnych fragmentów, z biblioteką obsługi, które zniknęły. Jak dotąd nie widziałem też wady takiego podejścia.

Tak więc moja odpowiedź na moje własne pytanie brzmi teraz: podczas tworzenia dla Androida 4.x dobrym pomysłem jest użycie fragmentów z biblioteki wsparcia. Biblioteka wsparcia ma naprawione błędy, które są nadal obecne w starszych implementacjach fragmentów i jest często aktualizowana o więcej poprawek błędów.

Jednym z głównych powodów, dla których warto trzymać się tego SupportFragmentprzez chwilę, jest to, że nie masz dostępu ChildFragmentManagerdo API do 17. Biblioteka wsparcia da ci wersję pomocniczą menedżera podrzędnych fragmentów.

Staje się to poważnym problemem, jeśli masz fragmenty zawierające inne fragmenty. Jest to powszechne w aplikacjach na tablety o dużej złożoności i / lub ogólna architektura jest oparta na układzie kart lub wykorzystuje szufladę nawigacji.

Byłem też sfrustrowany, że muszę dołączyć biblioteki wsparcia, pomimo ukierunkowania na Androida 4.0+ - ale wydaje się, że jest to oficjalnie zalecane:

Pakiet biblioteki obsługi systemu Android zawiera kilka bibliotek, które można dołączyć do aplikacji. Każda z tych bibliotek obsługuje określony zakres wersji platformy Androida i zestaw funkcji.

Ten przewodnik wyjaśnia ważne funkcje i obsługę wersji zapewnianą przez biblioteki pomocy technicznej, aby pomóc Ci zdecydować, które z nich należy uwzględnić w aplikacji. Ogólnie zalecamy włączenie obsługi v4 i bibliotek appcompat v7, ponieważ obsługują one szeroką gamę wersji Androida i zapewniają interfejsy API dla zalecanych wzorców interfejsu użytkownika.

http://developer.android.com/tools/support-library/features.html

IMHO, jeśli planujesz programować tylko dla 4.0, polecam korzystanie z natywnych bibliotek, ponieważ plik wykonywalny będzie się zmniejszał. Prawdą jest, że we wczesnych wersjach możesz napotkać problemy z błędami, ale myślę, że większość z nich powinna być dość trywialna do obejścia. Również biblioteka kompatybilności ma mapować do natywnych fragmentów w przypadku, gdy i tak używasz 4.0 lub nowszego. Więc może i tak będziesz musiał zmagać się z tego rodzaju problemami. Problem z bibliotekami pomocniczymi polega na tym, że wiele klas pojawia się 2x (raz w strukturze pakietu wsparcia, a raz w „natywnej” strukturze pakietu), co sprawia, że ​​programowanie jest nieco bardziej kłopotliwe.

Jeśli jednak chcesz udostępnić swoją aplikację również w wersji wcześniejszej niż 4.0, nie ma możliwości obejścia biblioteki wsparcia. Ponieważ na 2.3 jest około 38% wszystkich użytkowników, włączenie tej wersji systemu operacyjnego może mieć sens z biznesowego punktu widzenia. W takim przypadku możesz skorzystać z biblioteki wsparcia w połączeniu z Jake Wartons ActionBarSherlock (lub z obsługą Google ActionBar Library po jej ostatecznym wydaniu).

Wygląda na to, że lepiej teraz skorzystać z Support Library, ponieważ zobaczyłem tutaj oświadczenie https://developer.android.com/reference/android/app/Fragment.html

Ta klasa została wycofana na poziomie interfejsu API P. Użyj fragmentu biblioteki obsługi, aby zachować spójne zachowanie na wszystkich urządzeniach i uzyskać dostęp do cyklu życia.