5 powodów, dla których lepiej zacząć od nauki technologii natywnych, a potem przejść do Fluttera

Kiedy zaczynasz przygodę z tworzeniem aplikacji mobilnych, nauka Fluttera może wydawać się łatwym sposobem na wejście w świat programowania.

Jeśli ktoś mówi Ci, że możesz nauczyć się jednej technologii, żeby tworzyć aplikacje i na system iOS, i na Android, czemu miałbyś zawracać sobie głowę Kotlinem albo Swiftem?

Dlatego, że gdy coś brzmi zbyt pięknie, żeby było prawdziwe, prawdopodobnie gdzieś ukryty jest haczyk.

Istnieje przynajmniej 5 powodów, dla których warto najpierw zapoznać się bliżej z natywnymi technologiami, a dopiero potem odkrywać Fluttera. Sprawdź, dlaczego powinieneś rozważyć takie podejście.

1. Nauka Fluttera zajmuje więcej czasu, gdy nie masz doświadczenia w tworzeniu aplikacji

Co odróżnia Fluttera od jego najpopularniejszych cross-platformowych alternatyw? Często bazują one na znanych technologiach webowych – React Native korzysta z React.js i JavaScript, a Xamarin opiera się na środowisku .NET i C#.

Tymczasem Flutter wykorzystuje swoje własne rozwiązania technologiczne na czele z Dartem jako podstawowym językiem programowania. Rozwiązania, na których bazuje Flutter są w dużej mierze unikalne, dlatego znalezienie tutoriali i innych materiałów do nauki może być kłopotliwe.

Co więcej, Flutter wykorzystuje elementy charakterystyczne dla rozwoju aplikacji mobilnych (np. statycznie typowany język, system stylów) oraz te, które stosuje się w programowaniu rozwiązań webowych (deklaratywny UI, zarządzanie paczkami, konfiguracja assetów). To połączenie nie ułatwia zadania osobom, które uczą się Fluttera i nie mają doświadczenia w rozwoju aplikacji natywnych.

Dlaczego? Poza poznawaniem samego frameworka muszą oni też zrozumieć paradygmaty charakterystyczne dla mobilnych rozwiązań, służące do np. routingu, powiadomień, połączeń deep-linking, etc.

2. Konfiguracja niektórych zewnętrznych usług i integracji bywa skomplikowana

Możesz bez trudu stworzyć prostą aplikację we Flutterze, ale pisanie kodu to nie wszystko, o co musisz zadbać.

Poza programowaniem, są też inne ważne elementy procesu tworzenia mobilnej aplikacji. Na przykład testy quality assurance albo publikacja w sklepach.

Kiedy pracujesz nad projektem, zwykle konfigurujesz CI, żeby zbudować aplikację na iOS albo na Androida. Taki build później przechodzi przez platformy do publikacji, takie jak TestFlight albo Firebase App Distribution. Na koniec wysyłasz builda na produkcję przez Google Play lub Apple App Store.

Wszystkie te usługi wymagają odpowiedniej konfiguracji – osobnej dla każdej platformy. To zadanie może być przytłaczające dla kogoś bez wiedzy o tworzeniu aplikacji natywnych. Zwłaszcza, że większość tutoriali i plików z dokumentacją nie powstało z myślą o programistach Fluttera, a raczej o specjalistach, którzy znają platformy natywne.

Podpisywanie kodu i publikacja w sklepach z aplikacjami

Poza zewnętrznymi usługami, komponentem unikalnym dla technologii mobilnych jest też podpisywanie kodu.

Aby dodać aplikacje na iOS i Android do sklepów, należy je podpisać. W przypadku Androida proces ten jest dość prosty, ale w Apple App Store trzeba wygenerować certyfikat połączony z Developer ID, który wykorzystuje się do podpisywania buildów. Bez podpisu kodu nie można opublikować i instalować aplikacji na iOS.

Programiści bez doświadczenia w technologiach mobilnych mogą napotkać trudności z podpisywaniem aplikacji i generowaniem certyfikatów. Zwłaszcza, kiedy aplikacje mają być opublikowane w tym samym czasie na obu platformach.

3. Bez znajomości natywnych technologii trudno zrozumieć, jak działają niektóre elementy

Pomimo wysiłków, żeby maksymalnie uniezależnić Fluttera od platform, nie wszystko można zrobić bez wykorzystania natywnego kodu albo plików konfiguracyjnych aplikacji. Dobrym tego przykładem są `flavors`.

Kiedy chcesz stworzyć aplikację wykorzystującą inne środowisko, możesz wprowadzić parametr `--flavor <something>`. Wtedy wybierasz konkretną konfigurację środowiska w jakim utworzony będzie build. Żeby to zadziałało, musisz jednak skonfigurować dane środowisko w projektach na iOS i Android, które tworzy Flutter.

W Androidzie zmieniasz konfigurację Gradle, określając `flavorDimension` i `productFlavors`. W wersji iOS trzeba zdefiniować indywidualne schematy dla każdego flavor i zmienić konfigurację projektu w taki sposób, żeby wskazywała ona na właściwe pliki schematu.

W miarę rozwoju projektu złożoność tego typu zmian się zwiększa. Na przykład konfiguracja osobnych instancji Firebase dla różnych typów buildów albo ustawienie różnych Package Name / Bundle ID w zależności od wariantu builda.

Programiści, którzy nie mają wiedzy o natywnych platformach mogą oczywiście pomagać sobie tutorialami i wprowadzać wymagane zmiany. Prawda jest jednak taka, że mogą oni mieć problem ze zrozumieniem, jak te zmiany wpływają na projekt i dlaczego są konieczne.

Istnieje spore prawdopodobieństwo, że doświadczeni programiści mobilni będą wykonywać te zadania szybciej i z lepszymi rezultatami.

Kwestia bibliotek

Wiedza o tym, jak działają platformy, może się przydać podczas procesu rozwoju aplikacji. Nawet przy użyciu bibliotek.

Możesz wykorzystać jedną z najpopularniejszych bibliotek, SharedPreferences, bez korzystania z natywnego kodu. Ale jest to o wiele łatwiejsze, gdy znasz sposób działania platformy.

Jeśli spojrzysz na kod biblioteki Fluttera, zobaczysz, że jest on zbudowany w oparciu o `NSUserDefaults` w przypadku iOS i `SharedPreferences` w przypadku Androida. Dzięki temu możesz się dowiedzieć więcej o tym, jak pamięć się zachowa, jeśli np. wyczyścisz dane aplikacji. Taka wiedza może się okazać pożyteczna na dłuższą metę i mieć duży wpływ na wybór bibliotek podczas programowania.

4. Wiedza o technologiach mobilnych pozwala Ci oszczędzać czas

Zachowanie aplikacji webowych w dużej mierze nie podlega ograniczeniom – istotna część procesu ich tworzenia bazuje na obmyślaniu rozwiązań, które gwarantują dobry UX i stosowaniu odpowiednich wytycznych przy projektowaniu interfejsu.

W przypadku aplikacji mobilnych jest zupełnie inaczej. Muszą się one dopasować do zachowania systemu i wymogów unikalnych dla każdej platformy – iOS i Android. To może stanowić pewne utrudnienie dla programistów, którzy do tej pory nie pracowali z technologiami mobilnymi.

Aplikacje działające na smartfonach muszą:

• dostosować się do cyklu życia w systemie,
• zatrzymywać i wznawiać bieżące działania, kiedy mają działać w tle albo są przywracane,
• w minimalnym stopniu zużywać zasoby baterii,
• być przygotowane na to, że system może je wyłączyć, kiedy okaże się, że pobierają zbyt wiele energii.

Programiści aplikacji mobilnych dobrze znają te problemy, ponieważ występują one zarówno w przypadku natywnych, jak i cross-platformowych rozwiązań. Dlatego też łatwiej im sobie z nimi radzić.

Inaczej będzie z osobami, które mają doświadczenie w innego typu technologiach. O ile pewnie nie będzie to przeszkodą w przypadku prostych aplikacji, w bardziej rozbudowanych cross-platformowych projektach wiedza o tym, jak wygląda cykl życia aplikacji pozwala zaoszczędzić wiele czasu.

Komponenty zależne od platformy

Są też inne komponenty zależne od platformy, które niełatwo zrozumieć bez wiedzy o iOS i Androidzie. Dobrym przykładem jest dostęp do informacji o lokalizacji.

Obie platformy wymagają, żeby aplikacja poprosiła o dostęp do informacji o lokalizacji. Jest wiele flutterowych rozwiązań, które umożliwiają to bez wykorzystania natywnego kodu. Ale zrozumienie systemu tych uprawnień zajmuje wiele czasu. Podobnie zresztą jak określenie, których parametrów należy użyć i jak je skonfigurować, żeby aplikacja nie została odrzucona przez Google Play albo Apple App Store.

5. Czasem natywny kod to jedyna opcja

Flutter samodzielnie przeprowadza większą część procesu konfiguracji zarówno na systemie iOS, jak i Android. Czasami jednak trzeba zmienić sposób, w jaki budowane są aplikacje natywne. Wytłumaczę to z pomocą ustawień Firebase.

Konfiguracja bibliotek Firebase w projekcie Fluttera wymaga nie tylko zmian w kodzie. W niektórych przypadkach konieczne jest też wprowadzenie zmian w konfiguracji systemowych buildów dla każdej platformy osobno.

Dla programistów, którzy przeszli do Fluttera ze środowiska webowego, systemy buildów wykorzystywane w Android Studio i XCode mogą wydawać się trudne do zrozumienia i utrzymania.

Z kolei programiści aplikacji mobilnych nie będą mieli z nim większego kłopotu, ponieważ dobrze znają Gradle albo XCode Build System. Wiedza o tym, jak natywne aplikacje są zbudowane pozwala zaoszczędzić wiele czasu. To przydaje się również wówczas, kiedy zmagasz się z problemami związanymi z rozwiązywaniem zależności. Programiści z doświadczeniem w iOS czy Androidzie są zwykle zaznajomieni z systemami do zarządzania dependency na ich platformach. Dlatego wiedzą, jak poradzić sobie z najpowszechniej występującymi problemami w zarządzaniu zależnościami w Gradle albo w konfiguracji CocoaPods.

W technologii Google’a wiele elementów związanych z programowaniem wygląda i działa inaczej niż te, do jakich są przyzwyczajeni programiści mobilnych i webowych aplikacji. Ale nie ma to większego znaczenia – przynajmniej tak długo, jak zespół będzie chciał uczyć się Fluttera. Do niektórych zagadnień należy też podejść z innym nastawieniem. Ostatecznie jednak, tworząc aplikacje mobilne na iOS czy Androida, warto mieć pod ręką kogoś, kto zna te platformy i wie, jak przebiega proces tworzenia aplikacji.