Uprość wydawanie aplikacji Flutter z flutter_eval: otwartoźródłową alternatywą dla CodePush

Od redakcji: Marcin napisał ten artykuł w lipcu 2024 roku. Kroki konfiguracji i cytowane zasady sklepów odzwierciedlają stan flutter_eval oraz warunków Google Play i Apple z tamtego czasu. Zanim wdrożysz to rozwiązanie, sprawdź aktualną dokumentację flutter_eval i zasady obu sklepów.

Choć wielu uważa, że programiści Fluttera mają lepsze narzędzia i bardziej przewidywalne środowisko pracy, jest jedna rzecz z tworzenia aplikacji webowych, której często im zazdrościmy. Właśnie o niej jest ten artykuł.

Od webu do mobile: dlaczego poprawki błędów i wydania są trudniejsze we Flutterze?

Nasze typowo mobilne doświadczenie deweloperskie (DX) obejmuje stateful hot reload, z którego firmy tworzące aplikacje we Flutterze korzystają cały czas i którego brakuje im w projektach poza Flutterem. Bez niego programiści mogą codziennie tracić mnóstwo czasu, próbując wrócić do stanu tej części aplikacji, nad którą właśnie pracują. Nasze platformy są też stabilne, więc nie musimy się martwić, że blokery reklam zakłócą żądania sieciowe albo dodatki rozsypią układ aplikacji, co może prowadzić do nieoczekiwanych błędów. Jest jednak jeden element pracy web developera, którego ja, a pewnie także wielu z was, nie potrafię nie zazdrościć: możliwości szybszego aktualizowania aplikacji Flutter i wypychania zmian w kodzie bez ponownego publikowania ich przez sklepy z aplikacjami. Zobaczmy, jak mogłoby to zmienić proces tworzenia aplikacji we Flutterze.

W tworzeniu aplikacji webowych poprawianie błędów i wdrażanie poprawek to płynny proces. Gdy pojawia się błąd, programista może szybko go naprawić, wdrożyć rozwiązanie i poprosić użytkownika, by po prostu odświeżył stronę. Wdrożenie da się nawet zautomatyzować po commicie do głównej gałęzi. Tak samo jest z rollbackami: jeśli poprzednia wersja była stabilniejsza, programiści mogą łatwo do niej wrócić, co daje im dużą elastyczność i kontrolę.

W przeciwieństwie do tego tworzenie aplikacji mobilnych jest bardziej złożone i mniej przewidywalne. Gdy ktoś zgłasza niedziałającą funkcję, poprawka powstaje szybko, ale po wysłaniu wydania do weryfikacji zaczyna się niepewność. To trochę loteria: akceptacja może zająć mniej niż godzinę albo kilka dni, zależnie od tego, co znajdzie osoba weryfikująca. Jeśli pojawi się problem ze zgodnością z przepisami, rozmowa o późniejszej poprawce może przerodzić się w polityczną przepychankę, choć najważniejsze powinno być to, żeby użytkownik mógł bez problemu korzystać z aplikacji.

Nawet po akceptacji nadal nie ma pewności, jak przebiegnie rollout. Nie wszyscy użytkownicy dostaną poprawkę, bo aktualizacje zależą od sposobu korzystania z urządzenia i tego, kiedy jest ono ładowane. Część osób może nigdy nie zaktualizować aplikacji do najnowszej wersji, przez co w systemie śledzenia błędów pozostaną nierozwiązane problemy. Są sposoby, by to ograniczyć, na przykład feature flagi i wymuszanie aktualizacji, ale jednego kroku wciąż nie da się ominąć: weryfikacji w sklepach. Gdyby dało się ten etap zautomatyzować albo przynajmniej uczynić go bardziej przewidywalnym, byłoby to bardzo cenne.

Czym jest flutter_eval? Otwartoźródłowa alternatywa dla CodePush dla aplikacji Flutter

Poznaj flutter_eval, narzędzie open source do wydawania aplikacji. To część większego projektu open source, dart_eval, czyli przenośnej maszyny wirtualnej zaprojektowanej do wykonywania kodu Dart. Możesz traktować je jako alternatywę dla CodePush, a dokładniej CodePush dla aplikacji Flutter, podobnie jak silnik JavaScript SpiderMonkey w Firefoksie ma się do V8 w Chrome. flutter_eval wyróżnia to, że może działać wewnątrz twojego natywnego kodu Dart. Do parsowania kodu używa pakietu analyzer, co zapewnia pełną zgodność ze standardowymi narzędziami Darta.

Najciekawsze w flutter_eval jest to, że pozwala zdalnie przełączać implementację aplikacji, zarówno logikę, jak i interfejs, z pominięciem całego procesu weryfikacji. To sprawia, że jest atrakcyjną alternatywą dla CodePush dla zespołów, które chcą wdrażać aktualizacje Fluttera bez ponownej publikacji. Ponieważ narzędzie jest napisane w Darcie, można go używać wszędzie tam, gdzie Dart jest wspierany, także na Androidzie i iOS, desktopie, a nawet w webie, co ciekawie poszerza kontekst tego artykułu. Może to znacząco uprościć proces wydawania aplikacji Flutter i dać przewagę zespołom pracującym pod presją czasu.

Jeśli chodzi o bezpieczeństwo kodu, dart_eval stawia je na pierwszym miejscu i ma solidną, wbudowaną warstwę zabezpieczeń chroniącą twoje projekty. Domyślnie zdalny kod może komunikować się wyłącznie ze skompilowanym kodem Dart i jego pamięcią. Możesz jednak określić, do jakich zasobów ma mieć dostęp kod uruchamiany w maszynie wirtualnej. Do szczegółów jeszcze wrócimy.

Jak działa zdalne dostarczanie kodu we Flutterze? Magiczne trio

Zdalne dostarczanie kodu i dynamiczne wykonywanie kodu we Flutterze wymagają konkretnej architektury. Żeby przełączać widgety w czasie działania, potrzebujemy trzech kluczowych elementów:

1. dart_eval: ten element pełni dwie role. To maszyna wirtualna, która uruchamia nasz zdalny kod, a jednocześnie interfejs wiersza poleceń na maszynie deweloperskiej do kompilowania kodu do pliku .evc.

2. eval_annotation: ta adnotacja oznacza fragmenty kodu, które chcemy później podmieniać w czasie działania.

3. flutter_eval: ten element dostarcza funkcje specyficzne dla frameworka Flutter. Zawiera widget, który pobiera i konfiguruje pakiet zdalnego kodu, oraz pomocnicze widgety przełączające implementację we właściwym momencie.

dart_eval nie zastępuje istniejącej implementacji twojej aplikacji. Zamiast tego współpracuje z obecnym kodem, aby dostarczać zdalne aktualizacje, i te aktualizacje powinny obejmować tylko konkretne części aplikacji. Wrócimy do tego za chwilę.

Jak skonfigurować flutter_eval do zdalnej podmiany kodu w aplikacji Flutter: przewodnik krok po kroku

Na początek otwórz dowolny istniejący projekt Flutter i dodaj flutter_eval jako zależność. Dzięki temu zyskasz dostęp do widgetów HotSwapLoader i HotSwap. HotSwapLoader to widget, który ładuje i przechowuje w pamięci podręcznej zdalny kod na urządzeniu docelowym. Wskaż mu endpoint HTTPS z plikiem .evc, który za chwilę wygenerujemy, a HotSwapLoader zajmie się resztą.

Po załadowaniu widgety HotSwap dbają o to, by zdalny kod zastąpił fragmenty kodu Dart dostarczonego razem z aplikacją, na podstawie identyfikatora hot-swap. Taka konfiguracja może uprościć proces wydawania aplikacji Flutter. W podstawowej wersji użyjemy zwykłych stringów, ale żeby uniknąć literówek, lepiej użyć enumów. Na razie zwróć uwagę na wybrany tutaj identyfikator: #myHomePage. Funkcja childBuilder sprawia, że aplikacja zawsze ma co sensownie wyrenderować. Jeśli kod .evc nie będzie dostępny, childBuilder po prostu wyrenderuje kod dostarczony z pierwotnym wydaniem aplikacji.

Użyj tablicy args, jeśli zdalny widget potrzebuje dodatkowych argumentów. Musi ona zawsze zawierać co najmniej bieżący kontekst widgetu, bo Flutter potrzebuje go do poprawnego renderowania widgetów, ale może przyjąć dowolną liczbę argumentów. Jak widać, BuildContext korzysta z pomocniczej klasy $BuildContext z flutter_eval, która opakowuje kontekst wygenerowany przez kod dostarczony z aplikacją, żeby działał z maszyną wirtualną dart_eval w czasie działania. Więcej szczegółów znajdziesz w dokumentacji, ale dla zwięzłości pominiemy tę złożoność.

Teraz przejdźmy do najciekawszej części: przygotowania pakietu do hot swapu. Podmiany kodu w czasie działania są dostarczane niezależnie od aplikacji, dlatego zalecana konfiguracja zakłada trzymanie zdalnego kodu w osobnym pakiecie.

Zacznij od utworzenia pakietu, tak jak każdego innego projektu pakietowego. Następnie pobierz plik flutter_eval.json z wydania flutter_eval na GitHubie, które odpowiada twojej aktualnej wersji flutter_eval. Plik flutter_eval.json zawiera powiązania dla wielu widgetów Fluttera dostarczanych razem z frameworkiem Flutter, dzięki czemu możesz używać ich w kodzie dostarczanym zdalnie.

Następnie utwórz w nowym projekcie katalog .dart_eval/bindings i zapisz tam ten plik. Będzie używany na etapie kompilacji.

Będąc nadal w nowym projekcie pakietowym, dodaj zależność eval_annotation. Daje ona dostęp do adnotacji @RuntimeOverride, która pozwala później podmienić tag w czasie działania. Każda adnotacja RuntimeOverride powinna oznaczać funkcję zwracającą Widget. Lista args przekazana do odpowiadającego jej widgetu HotSwap zostanie zamieniona na argumenty funkcji zadeklarowanej tutaj.

Gdy implementacja będzie gotowa, skompiluj kod za pomocą CLI dart_eval. Jeśli jeszcze tego nie zrobiłeś, najpierw go aktywuj, a potem wywołaj dart_eval compile z wybraną nazwą pliku wyjściowego.

A teraz finał: publikacja kodu. Mam tylko jedną rekomendację: wybierz niezawodny hosting dla plików .evc. Gdy nowa zawartość .evc będzie już dostępna, zastąpi bieżącą implementację w docelowych aplikacjach. Warto też dodać numer wersji aplikacji do żądania pliku .evc. Z czasem możesz mieć wiele wersji aplikacji korzystających z plików .evc, więc dobrze jest móc podmieniać zawartość zależnie od wersji aplikacji, żeby uniknąć konfliktów.

Jak zadbać o bezpieczeństwo zdalnych aktualizacji kodu w aplikacjach Flutter?

Zgodnie z obietnicą porozmawiajmy o bezpieczeństwie tego narzędzia. Jeśli hosting plików .evc zostanie przejęty, atakujący może wyrządzić ogromne szkody na urządzeniach użytkowników końcowych. Ograniczenie liczby widgetów, które da się zdalnie aktualizować, może pomóc zmniejszyć ryzyko, ale nie wyeliminuje możliwości zamienienia twojej aplikacji w ransomware albo koparkę kryptowalut. Dlatego zespoły Fluttera powinny zadbać o to, by aktualizować dało się tylko wybrane części aplikacji, i ściśle kontrolować, do jakich zasobów zdalny kod ma dostęp.

To ryzyko bezpieczeństwa zostało zauważone wcześnie na etapie tworzenia narzędzia, dlatego zdalny kod domyślnie nie ma dostępu do żadnych zasobów na dysku ani w sieci. Jeśli twój przypadek użycia wymaga dostępu do potencjalnie ryzykownych zasobów, nadal możesz wskazać, do których katalogów na dysku i domen w sieci wolno sięgać, co daje ci bardziej szczegółową kontrolę nad bezpieczeństwem aplikacji.

Najlepsze praktyki flutter_eval: jak zachować zgodność z zasadami App Store i Google Play

Zanim zintegrujesz flutter_eval ze swoją aplikacją, warto pamiętać o kilku kwestiach. Część z nich pojawiła się już wcześniej, ale poniżej znajdziesz skrócony zestaw zasad, których warto się trzymać:

• Zadbaj o to, by podstawowe funkcje działały dzięki kodowi dostarczonemu razem z aplikacją, na wypadek słabego połączenia albo niedostępnego hostingu. Same wskaźniki ładowania w całej aplikacji nie zapewnią dobrego doświadczenia użytkownika.

• Do identyfikowania override'ów używaj constów zamiast zwykłych stringów, żeby uniknąć literówek i konfliktów nazw.

• Przekazuj informacje o wersji razem z żądaniem pliku .evc, żeby zachować elastyczność i móc dopasować pliki .evc do wersji aplikacji, jeśli zależność natywna spowoduje konflikty.

• Nie buduj całej aplikacji w oparciu o flutter_eval. To technicznie możliwe, ale niezalecane, bo na urządzeniach mobilnych dostęp do sieci nie jest gwarantowany. Jeśli użytkownik nie będzie miał połączenia przy pierwszym uruchomieniu, aplikacja okaże się bezużyteczna.

• Unikaj dużych zmian wdrażanych przez zdalne aktualizacje. Zasady sklepów są nieprecyzyjne, ale jasno wskazują, że funkcje nieweryfikowane przez sklep mogą skończyć się banem. Są tu różne poziomy ryzyka: jeśli zmienisz aplikację z odtwarzacza muzyki w giełdę krypto, ban masz praktycznie pewny; samodzielny rebranding bez nadzoru może skończyć się odrzuceniem, natomiast poprawianie istniejących funkcji i oferowanie treści dostosowanych do użytkownika jest w porządku. Jeśli testujesz granice zasad sklepów, robisz to na własne ryzyko. My rekomendujemy trzymać się poprawek błędów i ulepszeń funkcji.

To podsumowanie ma wyłącznie charakter wyjaśniający i nie należy go traktować jako porady prawnej. Koniecznie dokładnie przeczytaj swoje umowy.

Aplikacja dystrybuowana przez Google Play nie może samodzielnie się modyfikować, zastępować ani aktualizować w żaden inny sposób niż przez mechanizm aktualizacji Google Play. Podobnie aplikacja nie może pobierać wykonywalnego kodu, takiego jak pliki dex, JAR czy .so, ze źródła innego niż Google Play. To ograniczenie nie dotyczy kodu uruchamianego w maszynie wirtualnej lub interpreterze, jeśli zapewniają one wyłącznie pośredni dostęp do interfejsów API Androida, na przykład JavaScript w webview lub przeglądarce.

~ Pomoc Play Console

[...] kod interpretowany może zostać pobrany do aplikacji, ale tylko wtedy, gdy ten kod:

a) nie zmienia głównego przeznaczenia aplikacji przez dodawanie

funkcji lub możliwości niezgodnych z zamierzonym i

deklarowanym przeznaczeniem aplikacji zgłoszonej do App Store

b) nie tworzy sklepu ani witryny sklepowej dla innego kodu lub aplikacji oraz

c) nie omija podpisywania, sandboxa ani innych mechanizmów bezpieczeństwa systemu operacyjnego.

~ Umowa licencyjna Apple Developer Program

Oba sklepy z aplikacjami zasadniczo pozwalają pobierać i uruchamiać kod interpretowany, pod warunkiem że nie uzyskuje on bezpośredniego dostępu do API systemowych ani nie omija zabezpieczeń systemu operacyjnego. Aplikacja nie może też przez takie aktualizacje zmieniać swojego przeznaczenia ani oferować wewnętrznej galerii aplikacji aktualizowanej bez możliwości sprawdzenia jej przez osoby weryfikujące sklep, zanim trafi do użytkowników.

Jak flutter_eval pomaga zachować zwinność i usprawnić proces weryfikacji w sklepach

Pamiętaj, że flutter_eval ma przede wszystkim pomóc ci przejść przez proces weryfikacji, kiedy środowisko produkcyjne jest w kryzysie. Jeśli potrzebujesz wsparcia przy wdrożeniu flutter_eval lub innych usług związanych z tworzeniem aplikacji we Flutterze, skontaktuj się z Monterail. Chętnie pomożemy.