Open source / Flutter
Open source w aplikacjach: jak korzystać z pakietów i dzielić się kodem?
Gotowy pakiet może oszczędzić tygodnie pracy, ale staje się też częścią aplikacji, którą trzeba utrzymywać. Open source daje dostęp do kodu i możliwość jego rozwoju. Dobry wybór wymaga jednak sprawdzenia licencji, ograniczeń i zachowania biblioteki w konkretnym produkcie.
1. Otwarty kod to także zasady jego wykorzystania
Open source oznacza więcej niż publiczne repozytorium. Licencja określa prawa do używania, modyfikowania i rozpowszechniania kodu. Sama możliwość przeczytania plików na GitHubie nie wystarcza do uznania projektu za open source.
Przykładowo licencja MIT pozwala używać i modyfikować oprogramowanie, także komercyjnie, pod warunkiem zachowania informacji o prawach autorskich i treści zezwolenia w kopiach lub istotnych częściach kodu. Nie zapewnia gwarancji. Warunki sprawdzaj dla konkretnej biblioteki oraz jej zależności; nie przenoś zasad MIT na każdy publicznie dostępny projekt.
2. Wybieraj pakiet do problemu, który rzeczywiście masz
Zacznij od potrzeb aplikacji: wymaganych funkcji, platform i ograniczeń środowiska. Pakiet z rozbudowanym API nie zawsze będzie lepszy od małej biblioteki rozwiązującej jeden problem. Liczy się również to, jak łatwo można go przetestować, zaktualizować lub zastąpić.
Przeczytaj dokumentację, historię zmian i zgłoszenia błędów. Sprawdź testy oraz sposób obsługi awarii. Liczba pobrań może pomóc znaleźć popularne rozwiązanie, ale nie potwierdza jego jakości ani dopasowania do Twojego projektu. Rzadkie wydania też nie muszą oznaczać porzucenia: niewielki, stabilny pakiet może po prostu wymagać mniej zmian.
3. disk_kit — przykład połączenia Fluttera z systemem
W Dark Fox udostępniamy disk_kit: pakiet Flutter do komunikacji z dyskami i nośnikami danych. Pozwala wykrywać urządzenia, obserwować ich zmiany, montować i odmontowywać woluminy, kopiować pliki oraz formatować nośniki zewnętrzne. Kod jest dostępny na licencji MIT.
Wydanie 0.0.1 obsługuje macOS 12 i nowsze oraz wymaga aplikacji działającej poza App Sandbox. Implementacje dla Windows i Linux są planowane. To wczesne wydanie, którego API może się zmieniać. Te ograniczenia warto ocenić przed integracją, szczególnie gdy produkt ma działać na kilku systemach.
Obsługa nośników pokazuje też podział odpowiedzialności: pakiet wykonuje operację, a aplikacja musi jasno pokazać użytkownikowi wybrany dysk i uzyskać potwierdzenie przed formatowaniem. disk_kit nie tworzy automatycznej kopii zapasowej. Testy takich funkcji wymagają osobnego nośnika z danymi przeznaczonymi do usunięcia.
4. Zależności wymagają planu aktualizacji
W projekcie Dart lub Flutter plik pubspec.yaml opisuje zależności i dopuszczalne wersje, a pubspec.lock zapisuje rozstrzygnięte wersje pakietów. W aplikacji warto przechowywać plik lock w repozytorium, aby zespół korzystał z tego samego zestawu zależności.
Aktualizację wykonuj jako świadomą zmianę: przeczytaj changelog, sprawdź wymagania SDK, uruchom testy i zbuduj aplikację na docelowych platformach. Jeśli pakiet komunikuje się z systemem operacyjnym, sam test kodu Dart nie potwierdzi działania części natywnej. Sprawdź też zachowanie przy braku uprawnień, odłączeniu urządzenia i błędach operacji.
5. Kiedy warto opublikować własny pakiet?
Dobrym kandydatem jest moduł z jasno określonym zadaniem, który można wykorzystać bez znajomości reszty Twojej aplikacji. Wydzielenie go wymusza czytelne API i oddzielenie funkcji technicznej od reguł konkretnego produktu. Nie każdy fragment kodu potrzebuje jednak własnego pakietu.
Przed publikacją przygotuj licencję, instrukcję instalacji, działający przykład, testy i opis ograniczeń. Sprawdź, czy repozytorium nie zawiera sekretów ani danych klientów. Zapisz, jak zgłaszać błędy i które platformy rzeczywiście przetestowano. Obietnica przyszłej funkcji powinna być wyraźnie oddzielona od funkcji dostępnej dziś.
6. Wkład w open source zaczyna się od konkretnego problemu
Pomoc nie musi oznaczać dużego pull requesta. Odtwarzalny opis błędu, niewielki przykład, poprawka dokumentacji lub test regresji potrafią znacznie ułatwić utrzymanie biblioteki. Przed większą zmianą sprawdź zasady współpracy i omów jej zakres z opiekunami projektu.
Dla zespołu rozwijającego produkt open source jest narzędziem do współpracy i ponownego wykorzystania kodu. Korzyść pojawia się wtedy, gdy wybrany pakiet rozwiązuje realny problem, a zespół rozumie jego ograniczenia i potrafi zadbać o integrację.
Dobór pakietów i ich integracja są również częścią tworzenia i rozwoju aplikacji Flutter.
Dokumentacja do dalszej pracy
Instrukcje wdrożeniowe dobierz do wersji używanej w swoim projekcie. Poniższe źródła rozwijają opisane zagadnienia.