Jak radzić sobie z fragmentacją wersji Androida

[Coders Lab 128]

Informacja o nowej wersji Androida zawsze budzi poruszenie. Kiedy zwykli użytkownicy czekają na nowe, ciekawe funkcje, programiści z niecierpliwością oraz niepokojem spoglądają na zmiany w API.

Dlaczego?

Problemem jest ilość wersji Androida którą należy wspierać. Każda z wersji API przynosi coś nowego, a może też usuwać stare rozwiązania. Przy tworzeniu aplikacji należy wziąć to pod uwagę.

Dla przykładu samo Android Studio informuje na ilu procentach urządzeń można będzie uruchomić nowo tworzoną aplikację.

Na załączonym obrazku widać, że jeżeli zdecydujemy się na wybór API 22 to aplikację będzie można uruchomić na około 80,2% urządzeń.

Obok tej informacji znajduje się hyperlink otwierający bardziej szczegółowy opis każdego z wersji API.

 

Wersja API ma duże znaczenie. Na przykład wybierając niższe niż 23 nie będziemy mieć łatwego dostępu do latarki. Będzie trzeba napisać więcej kodu, by móc nią łatwo zarządzać. Za to przechodząc na API 23 mamy możliwość włączenia latarki jedną metodą (z pomocą nowego Flashlihgt API).
Taka decyzja wiąże się z tym, że stracimy trochę urządzeń, na których nasza aplikacja mogłaby być zainstalowana - z ponad 80% spadamy na 62.6%.

Wybór starszej wesji API, na tym poziomie tworzenia aplikacji nie przekreśla jednak możliwości korzystania z nowych funkcji. Wspomnianą wyżej latarkę można „okodować” na dwa sposoby. Stary sposób będzie uruchamiany tylko na urządzeniach ze starszą wersja API. Urządzenia posiadające nowszego Androida będą ten fragment omijać. Oczywiście nie stanie się to magicznie. Musimy sami to zapewnić. Najprostrzym sposobem będzie stworzenie instrukcji warunkowej uruchamiającej odpowiednią metodę:

Sprawdzane jest tutaj czy API które zostało użyte w aplikacji reprezentowane przez pole: Build.VERSION.SDK_INT jest większe bądź równe polu Build.VERSION_CODES.M czyli API 23 (Android 6.0.) Jeżeli jest mniejsze to użyty zostanie stary sposób implementacji latarki, w przeciwnym wypadku nowy.

Innym dobrym przykładem problemów związanych ze zmianą wersji API jest sposób dzielenia plików. Android N wprowadził pewne zmiany uprawnień w celu poprawy bezpieczeństwa. Przekazanie pliku poza domenę pakietową za pomocą Intent powoduje rzucenie wyjątku FileUriExposedException. Co to oznacza w praktyce? Jeżeli na przykład zrobimy zdjęcie i chcemy je przekazać do Activity to aplikacja będzie nam się wywalać z powodu wyjątku.

Z pomocą przychodzi nowy FileProvider, który nie dość że potrzebuje dodania zmian w AndroidManifest.xml i określeniem plików dla niego dostępnych, to wymaga jeszcze dodatkowych uprawnień. Ma on wiele plusów, ale osobie, która używała wcześniejszego API, psuje na początku trochę krwi. Tutaj również – jeżeli chcemy wspierać stare API musimy skorzystać z instrukcji warunkowej:

Wybór API level jest sprawą bardzo indywidualną. Najłatwiej mają Ci, którzy tworzą aplikację dla konkretnego klienta. Wiedzą na jakich modelach telefonów oraz na jakim API ma działać.Jeżeli jednak programiści tworzą aplikację która będzie ogólnie dostępna, muszą się liczyć z tym, że wybranie zbyt nowego API ograniczy im pulę potencjalnych użytkowników. Z drugiej strony stare API może wymuszać wykorzystanie przestarzałych rozwiązań. W tej sytuacji pozostaje mieszanie starych i nowych rozwiązań w sposób omówiony powyżej. Jest to złoty (nieco zwiększający narzut pracy) środek powszechnie wykorzystywany przez programistów.