Pierwsze kroki w tworzeniu aplikacji Flutter

Spis treści

1. Pierwszy krok – instalacja
2. Samouczki
3. Pierwsza aplikacja Flutter – koncepcja
4. Pierwsze kroki
5. Praca z kodem – analiza przykładów
6. Jeden mały szczegół
7. Integracja Fabric / Crashlytics
8. Uruchamianie ciągłej integracji
9. Wzorzec projektowy przyjazny Flutterowi – dlaczego BLoC?
10. Implementacja

Do niedawna Flutter był tylko kolejną nowinką, nowym graczem na rynku wieloplatformowego tworzenia aplikacji. Jako doświadczony programista iOS nie zadałem sobie trudu, żeby się nad Flutterem głębiej pochylić. Kilka miesięcy po oficjalnym premierze wydaje się, że wszyscy mówią tylko o Flutterze. „Wszystko jest widżetem”, „Piękne natywne aplikacje w rekordowym czasie” i kilka innych fraz, dały nowej ofercie Google marketingowy sukces . Oczywiście nasza firma, zawsze na bieżąco z najnowszymi trendami, szybko zareagowała i zaczęliśmy pracować nad utworzeniem zespołu Flutter. Oto podsumowanie mojej pierwszej poważnej próby użycia DART i Fluttera – frameworka opartego na widżetach.

Pierwszy krok – instalacja

Konfiguracja Flutter na MacOS jest dość trywialna, a oficjalna strona Flutter wyjaśnia krok po kroku proces instalacji. Będąc programistą Swift, miałem na już na pokładzie narzędzia Xcode i Xcode command line, dzięki czemu proces ten był jeszcze szybszy.

Musiałem zainstalować Android Studio (można również użyć Visual Studio Code), aby móc kodować za pomocą Dart – języka używanego w Flutter. Musiałem także dodać ADB, aby moje podłączone urządzenia z Androidem były widoczne. W przypadku IDE postanowiłem wypróbować Android Studio, ponieważ pisałem kiedyś aplikacje „hello world” dla Androida, więc niezależnie od dotychczasowych zmian środowisko było mi przynajmniej znane.

Podsumowując, konfiguracja zajęła mi około dwóch godzin, a ja mogłem stworzyć prosty projekt demonstracyjny Flutter i uruchomić go na fizycznych urządzeniach z Androidem i IOS podłączonych do mojego Maca przez USB.

Samouczki

Oficjalna strona Flutter jest bogata w próbki kodu dla początkujących, które wyjaśniają, jak powinna wyglądać poprawna praca z Dart. Moja pierwsza reakcja była trochę paniczna, ponieważ to, co zobaczyłem, bardzo różniło się od tego, do czego jestem przyzwyczajony. Nie „wyczułem” kodu, nie było na widoku klas, metod ani zmiennych – jasne, że tam były, ale składnia znacznie różniła się od tego, do czego przywykłem w Swift. Jeśli lubisz patrzeć na nowe języki programowania, przypuszczam, że wiesz o czym mówię – wszystko wydawało się trochę dziwne – inny edytor, inny color coding i oczywiście – zupełnie inny język do zrozumienia. Jestem pewien, że wszystko, czego potrzebuję, to przyjrzeć się Dartowi bliżej, aby uzyskać lepsze o nim pojęcie.

Podczas czytania / wykonywania samouczków nauczyłem się, jak konfigurować widoki za pomocą podstawowych widżetów Flutter – do umieszczania przycisków i etykiet, otwierania następnego widoku itp. Wszystko odbywa się z kodu, więc na razie prosty sposób na oddzielenie kodu widoku od logiki biznesowej to wciąż na mojej liście “do nauki”.

Pierwsza aplikacja Flutter – koncepcja

Przed rozpoczęciem pisania projektu konieczne jest przeprowadzenie badań dotyczących podstaw. Dla początkującego Flutterowca ilość informacji do zaabsorbowania jest dość znacząca, ale nie musisz sam sobie radzić. Szybko rozwijające się Flutter community oferuje duże wsparcie, a wszystko, czego brakuje na oficjalnej stronie Flutter, możesz znaleźć w repozytoriach git, listach błędów lub Stackoverflow. Z ogromnej liczby tematów i problemów związanych z Flutter, widać już spore i stale rosnące zainteresowanie Flutter / Dart.

Do mojego pierwszego projektu musiałem dowiedzieć się trochę o:

• async get/post
• login form
• user profile with history
• images processing form
• playing sounds 
• showing alerts 

Z pomocą wszystkich wyżej wymienionych źródeł, znalezienie informacji było dość proste

Pierwsze kroki

Tyle do zrobienia i myślenia :). Czas na kolejny krok – rozpoczęcie podstawowych przygotowań do projektu. Po pierwsze – zmiana nazwy projektu – okazało się, że nie jest to wielki wysiłek dzięki prostym instrukcjom ze strony Flutter. Wyrazy uznania należą się zespołowi Flutter – wszyscy wiemy, jak irytująca może być zmiana nazwy projektu na różnych platformach. Flutter daje tutaj radę, ponieważ zmiana nazwy nie jest niczym wielkim. To samo dotyczy zmiany nazwy pakietu, dzięki dużej ilości informacji, które można znaleźć online.

Kilka innych rzeczy do rozważenia to: Android Manifest, Info.plist in Xcode, setting bundle.using flavours, Signing, Runner.workspace. Ustalanie targetu wdrożenia dla IOS i Androida. Po raz kolejny community i wsparcie Google były bardzo pomocne.

To, co wydawało mi się nieco dziwne we Flutter, to długa składnia importu:

import 'package: flutter_demo / model / user.dart’;

Preferuję krótkie importowanie, najlepiej jeśli zawierają one tylko nazwę pliku. Moje pierwsze wrażenie z DART było takie, że jest dość długi. Zamiast opisywać pracę w kilku prostych słowach, czułem się, jakbym opowiadał szczegółową historię o akcji :). Zobaczę, co się zmieni, kiedy już dobrze wyczuję konstrukcje Dart.

Praca z kodem – analiza przykładów

Jak mądra osoba powiedziała kiedyś: „Nauka języka programowania odbywa się w dwóch etapach – nauka czytania kodu, a następnie pisania kodu”, dlatego dobrą rzeczą na początek jest analiza próbek kodu, aby uzyskać właściwe wyczucie platformy Flutter. Obecność Abstract classes była ulgą, ponieważ wiedziałem, że będę w stanie wykonać dziedziczenie i logikę SWIFT podobną do protokołu.

Jeden mały szczegół

Twoja aplikacja musi być wyświetlana tylko w wymuszonym widoku pionowym – łatwo to wykonać, klikając ten link.

Integracja Fabric / Crashlytics

Trzeba przyznać, że tutaj musiałem stoczyć pierwszą poważną bitwę z Flutter. W przypadku Fabric jesteśmy obecnie w trochę trudnej sytuacji, jako że wykupił go Google i jest w trakcie integracji z Firebase Crashlytics. Nie było dla mnie jasne, które pakiety powinienem dodać, aby obsługiwać dystrybucję Fabric Beta i raportowanie błędów Crashlytics. Trochę dochodzenia w kwestii Firebase Alpha zastępującej Fabric Beta do dystrybucji kompilacji jest obiecująca, ale teraz, przy dostępnej tylko wersji Beta, potrzebny jest hybrydowy dostęp zarówno do Fabric, jak i Firebase.

Musiałem utworzyć jeden projekt Firebase dla aplikacji, stworzyć aplikacje na iOS i Androida, przenieść GoogleService-Info.plist i google-services.json do folderów projektu platformy, wykonać niezbędne modyfikacje w AndroidManifest.xml, build.gradle itp. Dla Andro dodać plik Info.plist i AppDelegate.m dla IOS. Następnie zostały tylko: poprawny import do pliku main.dart i modyfikacja metody main, aby ostatecznie uruchomić Crashlytics.

Uruchamianie ciągłej integracji

Wszystko to zajęło większą część dnia, ale ostatecznie moja ciągła integracja została w pełni skonfigurowana dla mojego projektu Flutter, z pomocą Fastlane dla platform IOS i Android. Nie ma sposobu, aby zrobić to bezpośrednio dla Flutter lub stworzyć jedną konfigurację Fastlane dla projektu Flutter do obsługi obu platform – musisz utworzyć osobne pliki Fastfile dla każdej platformy i skonfigurować je niezależnie. Oto całkiem niezły samouczek na temat automatyzacji ciągłego budowania. Zmodyfikowałem go nieco, aby pozwolić kompilacjom przejść bezpośrednio do Crashlytics zamiast iTunes lub Google Play.

Konfiguracja powyższego wymaga trochę pracy – radzę pozostać na bieżąco z odpowiednimi wersjami pakietów, ponieważ dużo czasu zajęło mi znalezienie przyczyny „nieoczekiwanych” błędów kompilacji.

Miałem też do czynienia z tym błędem dla Androida:

> java.lang.RuntimeException: java.lang.RuntimeException: com.android.builder.dexing.DexArchiveMergerException: Nie można scalić dex

Było to na szczęście, ponieważ szybkie wyszukiwanie przyniosło rozwiązanie w postaci dodania multiDexEnabled true do defaultConfig build.gradle

Wzorzec projektowy przyjazny Flutterowi – dlaczego BLoC?

Podobnie jak w przypadku każdego projektu, skonfigurowanie odpowiedniej architektury do uruchomienia projektu aplikacji ma najwyższy priorytet. Sprawdziłem zarówno rekomendacje społecznościowe, jak i oficjalne, i wynika z nich, że ​​BLoC jest preferowaną opcją. Uznałem ten artykuł za pomocny w zrozumieniu działania architektury BLoC. Okazuje się, że BLoC jest bardzo podobny do MVVC na iOS, z klasą bloku zamiast modelView. Doszedłem do wniosku, że architektura BLoC jest właściwym wyborem i postanowiłem pracować z nią w moim projekcie.

Przykładowa aplikacja z powyższego artykułu była dość podobna do mojego pierwszego projektu aplikacji we Flutterze – wszystko, czego potrzebowałem, to dodanie dodatkowej warstwy projektu i oddzielnej zawartości dla poszczególnych modułów. Wystarczyło rozwinąć listę podstawowych folderów na wszystkie moduły (interfejs użytkownika, bloki, modele, zasoby). Stworzyłem również folder commonModels, w którym przechowywane są wszystkie modele używane w różnych modułach. Bardziej dogłębne przeczytanie artykułu zaowocowało kilkoma drobnymi zmianami w kodzie i udoskonaleniem architektury BLoC w moim projekcie.

Implementacja

Trudny początek sprawił, że naprawdę ciężko było stworzyć cokolwiek z kodem DART, co faktycznie by działało – pełen szacunek dla wszystkich, którzy z łatwością przechodzą na język Flutter. Dla mnie był to powrót do szkoły w prawie wszystkich aspektach pisania kodu – jeden krok do przodu, dwa kroki do tyłu. Wiedziałem tylko to, czego nauczyłem się z samouczków krok po kroku, przykładów i testów debugowania.

W końcu udało mi się stworzyć mały widget z 5 przyciskami zdefiniowanymi przez wyznaczone właściwości modelu – niezupełnie wystarczające aby nazwać to aplikacją. Utworzenie interfejsu użytkownika też nie poszło zbyt dobrze – nagle DART, i cała koncepcja że „wszystko jest widgetem” zaczęły przypominać JSONa – tylko bardziej skomplikowanego. Nadal muszę się zapoznać ze wszystkimi definicjami parametrów interfejsu użytkownika – krawędziami, wymiarami, wyrównaniami itp. – Planuję zabrać się za to, kiedy tylko skończę pisać i analizować kod.

Podsumowując, praca z Flutter była dla mnie trochę trudna, ale widzę, że cały ten szum wokół nowego frameworka Google nie jest bezpodstawny. Po pewnych udoskonaleniach i dogłębnym poznaniu uważam, że jest to bardzo dobry dodatek do zestawu narzędzi każdego software house-u, a dla mnie świetny sposób na rozszerzenie moich możliwości jako programisty.