- Flutter a Jetpack Compose sdílejí deklarativní, reaktivní model uživatelského rozhraní, ale liší se jazykem, ekosystémem a dosahem platformy.
- Compose čistě mapuje na koncepty Flutteru: komponovatelné objekty na widgety, líné seznamy na ListView/GridView, Canvas na CustomPainter a motivy na ThemeData.
- Nativní dovednosti Androidu (životní cyklus, navigace, zdroje, souběžnost) se přenášejí přímo do Flutteru prostřednictvím widgetů, Navigatoru, assets a async/await.
- Pro projekty pouze pro Android vyniká Compose, zatímco Flutter vyniká, když potřebujete jednu kódovou základnu pro Android, iOS, web a desktop.
Pokud se již cítíte jako doma při psaní uživatelských rozhraní s Jetpack Compose a zajímá vás, jak těžké je přejít na Flutter, jste ve skvělé pozici. Obě sady nástrojů jsou deklarativní, reaktivní a vytvořené společností Google, takže velká část vašeho mentálního modelu se přenáší téměř individuálně. Hlavní rozdíly spočívají v jazyce (Kotlin vs. Dart), struktuře projektu a v tom, jak jednotlivé frameworky komunikují se základními vrstvami Androidu (a v případě Flutteru i iOS, webu a desktopu).
Tato příručka je napsána speciálně pro vývojáře Jetpack Compose, kteří chtějí porozumět Flutteru do hloubky, bez marketingových zbytečností. Uvidíte, jak se základní koncepty prolínají mezi těmito dvěma světy: komponovatelné objekty vs. widgety, modifikátory vs. parametry konstruktoru, líné rozvržení vs. ListView/GridView, Canvas vs. CustomPainter, Navigation Compose vs. Navigator, remember vs. StatefulWidget a další. Také propojíme vaše širší znalosti Androidu (Views, životní cyklus, zdroje, intenty, práce na pozadí) s jejich ekvivalenty ve Flutteru, takže křivka učení bude spíše jako krok do strany než výstup.
Od Jetpack Compose po Flutter: kde se vaše dovednosti uplatní
Flutter je UI framework od Googlu pro tvorbu multiplatformních aplikací pomocí jazyka Dart, zatímco Jetpack Compose je moderní UI toolkit od Googlu pro nativní Android s využitím Kotlinu. V podstatě se zaměřují na různé běhové prostředí, ale architektonicky sdílejí stejnou hlavní myšlenku: popsat UI jako funkci stavu a nechat framework sám zjistit, kdy a jak jej překreslit.
V Jetpack Compose uvažujete v pojmech komponovatelných funkcí, modifikátorů a rekompozice; ve Flutteru uvažujete v pojmech widgetů, parametrů konstruktoru a rebuildů. Navzdory odlišnému pojmenování je chování nápadně podobné: vytvoříte strom prvků uživatelského rozhraní, každý uzel je neměnný a když se stav změní, framework znovu projde tento strom a vytvoří aktualizované rozhraní.
Jedním z klíčových rozdílů je, že Flutter je svou platformou multiplatformní. Stejná kódová základna Dart může cílit na Android, iOS, web, Windows, macOS a Linux. Compose se rozšiřuje i za hranice Androidu (například s Compose Multiplatform), ale příběh Flutteru pro více zařízení je v současné době mnohem vyspělejší a ucelenější, a to je přesně důvod, proč se na něj mnoho týmů zaměřených na Android zaměřuje, když chtějí dodávat platformu pro iOS nebo desktop.
Vaše znalost samotné platformy Android je v projektech Flutteru stále nesmírně cenná. Zatímco vrstva uživatelského rozhraní je čistě Dart a widgety, Flutter se spoléhá na Android (a iOS) pro oprávnění, konfiguraci systému, API platformy, oznámení, práci na pozadí a mnoho dalších funkcí, ke kterým se přistupuje prostřednictvím pluginů a kanálů platformy. To znamená, že veškerá intuice, kterou jste si vybudovali o tom, jak se Android chová, nepřijde nazmar – pouze se posune o jednu vrstvu níže.
Deklarativní model uživatelského rozhraní: komponovatelné prvky vs. widgety
Jetpack Compose i Flutter implementují deklarativní model uživatelského rozhraní: popisujete „jak“ by mělo uživatelské rozhraní vypadat pro daný stav, nikoli „jak“ krok za krokem mutovat zobrazení. Místo volání setterů na zobrazeních znovu sestavíte strom při změně stavu a necháte framework efektivně porovnávat a překreslovat.
V Jetpack Compose jsou prvky uživatelského rozhraní kompoziční funkce s anotací @Composable, často konfigurovaný s Modifier. Tlačítko by mohlo být Button(onClick = ..., modifier = Modifier.padding(16.dp))Řetězec modifikátorů dekoruje nebo rozvrhuje komponovatelný objekt bez změny jeho podkladového typu a Compose používá rekompozici k aktualizaci pouze těch částí stromu, jejichž vstupy se změnily.
Ve Flutteru jsou prvky uživatelského rozhraní widgety – obyčejné objekty Dart, které popisují konfiguraci. Jsou také neměnné a uspořádané ve stromové struktuře, ale místo předávání modifikátoru obvykle předáváte argumenty rozvržení nebo stylingu přímo prostřednictvím parametrů konstruktoru nebo obalíte widget v jiných widgetech rozvržení. Můžete například napsat Padding(padding: EdgeInsets.all(16), child: ElevatedButton(...)) aby se dosáhlo podobného výsledku.
Životní cyklus komponovatelných objektů i widgetů je záměrně krátkodobý a neměnný. Existují pouze do doby, než je nový vstup vyžaduje jejich nahrazení; ani jeden z nich se nesnaží řídit svou vlastní životnost ani se přímo mutovat. To je koncepční posun od starého světa Android View, kde jsou view objekty s dlouhou životností, opakovaně používané a mutované v průběhu času, a proto je váš způsob psaní ve Flutteru tak přirozený.
V podstatě se rozvržení v obou frameworkech řídí stejným vzorem řízeným nadřazenými prvky a založeným na omezeních. Rodič se změří, předá omezení dále, potomci si vyberou velikost s ohledem na tato omezení a rodič své potomky umístí. Ve Flutteru to uvidíte přímo jako BoxConstraints; v Compose je to řešeno v implementacích MeasurePolicy. V obou případech mohou rodiče omezit děti – widgety si nemohou jednoduše vybrat libovolnou velikost nebo polohu.
Strukturování aplikace: vstupní bod, scaffolding a rozvržení
V systému Android s funkcí Compose je vaším vstupním bodem obvykle Activity (často a ComponentActivity) kam voláte setContent pro hostování vašich kompozovatelných objektů. Odtud sestavíte kompoziční strom, obvykle počínaje MaterialTheme a povrch nebo lešení, které definuje vaše rozvržení na vysoké úrovni.
Ve Flutteru je vstupním bodem Dart. main funkce, která volá runApp s kořenovým widgetem vaší aplikace. Tento kořen je obvykle MaterialApp or WidgetsApp widget, který nastavuje směrování, motivy, lokalizaci a základní navigátor. První „obrazovka“, kterou zobrazíte, často používá Scaffold widget, který hraje velmi podobnou roli jako Scaffold v Material 3 Compose: nabízí panel aplikací, tělo, plovoucí tlačítko akce, zásuvky a tak dále.
U jednoduchého textu a statického obsahu může Compose standardně obsah zalamovat – přizpůsobovat velikost vnitřnímu obsahu – zatímco mnoho widgetů Flutteru standardně zabírá více dostupného prostoru, pokud není omezeno. Například pokud umístíte Text skládatelný uvnitř sloupce, automaticky nevyplní šířku. Ve Flutteru, Text uvnitř a Column se může chovat odlišně v závislosti na omezeních rodičovského objektu. Chcete-li ve Flutteru umístit obsah do středu, často jej zabalíte do Center widget nebo použijte widgety rozvržení jako Align, Row, Column, a Expanded v kombinaci s vlastnostmi zarovnání.
Lineární rozvržení se mapují téměř dokonale: Compose má Row a Column, a stejně tak Flutter. Ve Flutteru předáváte děti jako List<Widget> a ovládat rozestupy a zarovnání pomocí vlastností, jako je MainAxisAlignment a CrossAxisAlignmentV aplikaci Compose se spoléháte na horizontalArrangement, verticalArrangement, horizontalAlignment a verticalAlignmentUžitečný způsob, jak o tom přemýšlet: vlastnosti končící na „Arrangement“ se mapují na hlavní osu Flutteru a ty, které končí na „Alignment“, se mapují na příčnou osu.
Pokud potřebujete relativní nebo překrývající se rozvržení, jsou přístupy také koncepčně sladěny. V Androidu XML můžete sáhnout po RelativeLayout nebo vnořenou směs LinearLayout a FrameLayoutV aplikaci Compose byste psali Row, Column a Box (nebo si napište vlastní rozvržení). Ve Flutteru je analogie Row, Column a Stack v kombinaci s umístěnými podřízenými prvky a možnostmi zarovnání. Váš mentální model pro uspořádání prvků vůči sobě navzájem se pohybuje téměř beze změny.
Tlačítka, vstup a interakce
V Jetpack Compose obvykle vytvoření tlačítka znamená použití Button nebo jedna z jeho variant Material, která v rámci Material 3 odpovídá specifické implementaci, jako je FilledTonalButton. Poskytujete onClick lambda a volitelné stylování, často pomocí parametrů jako colors nebo modifikátory pro odsazení, šířku a zarovnání.
Ve Flutteru je ekvivalentem použití widgetů jako FilledButton, ElevatedButton, TextButton or OutlinedButton. Každý si vezme onPressed zpětné volání a child widget – nejčastěji TextMůžete si je přizpůsobit předáním style přes ButtonStyle nebo pomocí globálního přepsání motivu, které umožňuje centrálně upravit barvu, tvar, výšku a velikost pro celou rodinu tlačítek.
Pro práci s gesty se Compose spoléhá na modifikátory jako Modifier.clickable v mnoha případech, ale v případě potřeby můžete také přejít na specializované detektory gest. Dlouhé stisknutí, tažení a vlastní gesta se obvykle vytvářejí pomocí specializovaných modifikátorových API a zdrojů interakce.
Flutter odhaluje explicitní GestureDetector widget, kterým obalíte cokoli, co nemá vestavěnou podporu gest. Nabízí širokou škálu zpětných volání: onTap, onDoubleTap, onLongPress, onVerticalDragStart, onVerticalDragUpdate, onHorizontalDragEnd a mnoho dalších. Widgety jako ElevatedButton již odhalují onPressed vlastnost, ale pro zcela vlastní prvky uživatelského rozhraní můžete použít GestureDetector nebo widgety vyšší úrovně, jako například InkWell pro zpětnou vazbu zvlnění materiálu.
Vkládání textu ve Flutteru se spravuje pomocí TextField or TextFormField, jehož styl se vyrovná Composeově TextField a OutlinedTextField skládatelné materiály. Nápovědy, popisky, chyby a ohraničení konfigurujete pomocí InputDecoration podobné tomu, jak používáte vy TextFieldDefaults nebo parametry v textových polích v aplikaci Compose. Stejně jako v aplikaci Compose se chybové zprávy obvykle zobrazují reaktivně změnou stavu a přestavbou dekorace, spíše než ruční manipulací s pohledy.
Seznamy, mřížky a posouvající se obsah
Jetpack Compose nabízí dvě hlavní strategie pro seznamy: jednoduché Column/Row s iterací pro malé kolekce a LazyColumn/LazyRow/LazyVerticalGrid/LazyHorizontalGrid pro velké nebo dynamické seznamy. Líné kontejnery skládají pouze to, co je viditelné, což udržuje vysoký výkon při práci s tisíci položek.
Flutter používá stejný přístup „malé versus velké“, ale s jinými widgety. Pro malý seznam, který se vejde na obrazovku, můžete použít Column a namapujte svá data na childrenPo čemkoli, co se posouvá, saháte ListView or GridView, s konstruktory, které líně vytvářejí potomky pouze v případě potřeby.
Běžný vzorec ve Flutteru je ListView.builder, který zrcadlí položky líného seznamu DSL v Compose. Dodáváte itemCount a itemBuilder zpětné volání; Flutter volá tento builder s indexem od 0 do itemCount - 1 kdykoli se v zobrazení objeví nová položka. V nástroji pro tvorbu můžete vrátit téměř jakýkoli widget – od jednoduchého ListTile s textem a ikonou až po složité, vlastní řádky seznamu.
Pro mřížky, Compose LazyVerticalGrid a LazyHorizontalGrid mapa k Flutteru GridView widget. Místo přímého předávání počtu sloupců do mřížky Flutter často používá delegáta, jako například SliverGridDelegateWithFixedCrossAxisCount or SliverGridDelegateWithMaxCrossAxisExtent pro řízení rozložení buněk. Tito delegáti zapouzdřují pravidla jako „počet sloupců“ nebo „maximální šířka buňky“, podobná parametrům velikosti mřížky, které používáte v aplikaci Compose.
Chování rolování je také analogické v obou sadách nástrojů. Líné seznamy v Compose mají integrované rolování; nemusíte je balit do dalších kontejnerů pro rolování. Ve Flutteru je mnoho widgetů seznamů a mřížek samo o sobě rolovatelných, ale pro jeden, neopakující se obsah, který by se měl rolovat, můžete použít SingleChildScrollViewVytváření vlastních posouvatelných stránek se pak pro pokročilejší případy použití stává otázkou vnořování nebo skládání sliverů.
Adaptivní a responzivní vzory uživatelského rozhraní
Compose nabízí několik strategií pro responzivní design: vlastní rozvržení, BoxWithConstraints, WindowSizeClass a adaptivní knihovnu Material 3. Ty vám umožňují měnit kompozici na základě dostupného prostoru, polohy a kategorie zařízení a můžete je kombinovat v závislosti na složitosti projektu.
Flutter se nesnaží tato API přímo zrcadlit, ale základní myšlenka je stejná: prozkoumat omezení a charakteristiky obrazovky a poté větvit rozvržení. Dva hlavní nástroje jsou LayoutBuilder a MediaQuery. LayoutBuilder průkazy BoxConstraints dolů, abyste mohli widgety přehazovat nebo měnit jejich uspořádání nad určitou šířku nebo výšku. MediaQuery zpřístupňuje velikost obrazovky, orientaci, odsazení a hustotu pixelů pro zarážky na vysoké úrovni.
Místo snahy o jednoznačné propojení adaptivních řešení Compose a Flutteru je efektivnější uvažovat z hlediska vašich designových požadavků. Jakmile budete vědět, jak by se vaše uživatelské rozhraní mělo přizpůsobovat telefonům, tabletům a stolním počítačům, můžete tuto logiku vyjádřit buď pomocí Compose WindowSizeClass a adaptivní rozvržení nebo větvení řízené omezeními a médii ve Flutteru. Stejné designové myšlení – různá API.
Správa stavu: nezapomeňte vs. StatefulWidget a další
Jetpack Compose ukládá dočasný stav uživatelského rozhraní pomocí remember a státní držitelé jako mutableStateOf, často v kombinaci s ViewModel a architektonické komponenty pro delší životnost. Když se stav změní, dojde k rekompozici a příslušné kompozovatelné objekty získají nové hodnoty.
Příběh Flutteru o nízkoúrovňových stavech se točí kolem StatefulWidget a s ním spojené State objekt. Definujete widget, který chce uchovávat stav, rozšířením StatefulWidget, poté implementujte samostatný State<MyWidget> třída pro ukládání proměnlivých polí. Kdykoli tato pole aktualizujete, zavoláte setState(), což označí danou část stromu widgetů jako „dirty“ (nečistou) a spustí obnovu. Na této úrovni je to velmi podobné ukládání stavu kompozice pomocí remember a zneplatnění kompozovatelných objektů při změně hodnot.
U složitějších aplikací se Flutter silně opírá o komunitní a vlastní vzory: Provider, Riverpod, Bloc, obchody ve stylu Redux a další. Tyto fungují jako analogie vašich architektonických stacků Androidu: ViewModel + LiveData/Flow + repozitáře v projektech Compose. Centralizují obchodní logiku a zpřístupňují reaktivní datové toky, které řídí přestavby widgetů. Z prostředí Compose vám bude mnoho z těchto vzorů povědomých, i když se API liší.
Jedna věc, která vývojáře Androidu často překvapuje, je, že jak bezstavové, tak i stavové widgety ve Flutteru se často přestavují – potenciálně každý snímek během animací. Rozdíl nespočívá v frekvenci obnovy, ale v tom, kde je uložen proměnlivý stav: StatefulWidget dává ti společníka State objekt, který přežije přestavby, podobně jako remember umožňuje hodnotám přežít rekompozici v Compose.
Kreslení, animace a vizuální dokonalost
Pokud jste někdy pracovali přímo s Androidem Canvas a Drawable, Compose Canvas composable se pravděpodobně zdál přímočarý. Poskytuje deklarativní způsob kreslení tvarů, obrázků a textu v Kotlinu a skrývá mnoho imperativních ceremonií tradičních vlastních zobrazení.
Flutter odhaluje podobnou kreslicí plochu skrze Canvas API, přístupné přes CustomPaint a CustomPainter. Implementujete CustomPainter třída, kde přepíšete paint metoda kreslení na plátno pomocí Paint objekty, cesty, transformace a tak dále. Poté tento nástroj pro malování připojíte k CustomPaint widget. V podstatě se Compose i Flutter opírají o engine Skia, takže primitiva – čáry, cesty, shadery – vypadají velmi dobře povědomě z 2D renderování v Androidu.
Pro animace se Flutter opírá o explicitní animační systém postavený na AnimationController, Animation<T> a doplnění o doplňující prvky a bohatou sadu animovaných widgetů. Vytvoříte instanci řadiče (obvykle pomocí SingleTickerProviderStateMixin pro vsync), definujte CurvedAnimations nebo Tweeny, které mapují postup 0-1 na hodnoty domény, a poté je propojte s widgety jako FadeTransition, ScaleTransition, AnimatedBuilder nebo implicitní widgety, jako například AnimatedContainerAnimační systém také odhaluje AnimationStatus zpětná volání reagující na zahájení, dokončení nebo zrušení.
Animační API v Jetpack Compose jsou deklarativní odshora dolů a obsahují funkce jako animate*AsState, přechody a animovanou viditelnost. Místo ruční správy ovladačů ve většině běžných případů popisujete cílové stavy a framework řídí interpolaci v průběhu času. Pokud potřebujete více zakázkové kontroly, stále máte přístup k nízkoúrovňovým primitivům, ale obvyklá cesta je stručnější než klasický Android XML nebo imperativní animační kód.
Koncepčně se obě sady nástrojů používají stejným způsobem: widgety/kompoziční prvky se udržují lehké a čisté, propouštějí se přes ně časově proměnné hodnoty a interpolace a neplatnost se řeší na frameworku. Jako vývojář Compose, extra explicitnost Flutteru AnimationController Zpočátku se to může zdát trochu staromódní, ale získáte tak velmi jemnou kontrolu nad načasováním, křivkami a orchestrací.
Stylizace, motivy, fonty a další zdroje
Moderní aplikace žijí, nebo umírají, na uhlazenosti, takže Flutter i Compose kladou velký důraz na motivy a styling. Použití v aplikaci Compose MaterialTheme s barevnými schématy, typografií a definicemi tvarů a můžete vnořovat témata pro přepsání hodnot pro podstromy – včetně vynucení světlých nebo tmavých povrchů pro konkrétní oblasti.
Ve Flutteru je ekvivalentem ThemeData předán MaterialApp or Theme widgety. Definujete primární barvy, jas, typografii a témata specifická pro jednotlivé komponenty, jako například elevatedButtonTheme, textButtonTheme, appBarTheme a další. Témata můžete lokálně přepsat zabalením podstromů do Theme widgety, které kopírují nadřazenou položku a upravují určitá pole. Světlý a tmavý režim lze přepínat na úrovni aplikace poskytnutím theme a darkTheme a ovládání themeMode.
Stylování textu je známá oblast: v aplikaci Compose buď předáte jednoduché vlastnosti přímo do Text nebo dodat TextStyle objekt. Flutter to zrcadlí pomocí Text widget, který přijímá TextStyle přes jeho style parametr. TextStyle zahrnuje rodinu písma, velikost, tloušťku, rozteč písmen, výšku řádku, dekorace a další. Globální textové motivy můžete definovat v ThemeData.textTheme a odkazovat na ně všude, stejně jako byste používali typografii z MaterialTheme v aplikaci Compose.
Fonty a obrázky jsou zpracovávány prostřednictvím datových zdrojů, nikoli tradičním způsobem jako v systému Android. /res strom adresářů. Flutter nevynucuje konkrétní rozvržení složek; datové zdroje deklarujete v pubspec.yaml a poté se na ně odkazovat z kódu. Obrázky se obvykle načítají pomocí Image.asset(), který se na základě správné hustoty rozloží devicePixelRatioLogické pixely hrají stejnou roli jako dp v systému Android, čímž se abstrahuje fyzická hustota pixelů.
Pro vlastní fonty umožňuje Compose buď zabalit zdroje fontů, nebo je načíst za běhu prostřednictvím poskytovatelů, jako jsou Google Fonts, a poté je propojit s FontFamily a typografie. Flutter používá téměř stejný vzorec: umístí soubory písem do složky assets, vypíše je v pubspec.yamla poté odkazovat na rodinu písem podle názvu v TextStylePokud chcete fonty načítané za běhu, existuje oblíbená funkce. google_fonts plugin, který zpřístupňuje funkce Dart pojmenované po fontech – např. GoogleFonts.robotoTextTheme()— abyste je rychle propojili s vaším tématem.
Oba ekosystémy berou řetězce a lokalizaci jako prvořadé záležitosti, ačkoli Flutter nemá přímý ekvivalent k XML řetězcovým zdrojům Androidu. Nejlepší praxí je místo toho ponechat překlady v .arb soubory a propojit je s lokalizačním nástrojem Flutteru. Přístup k nim pak probíhá prostřednictvím generovaných tříd Dart, zhruba analogicky k použití R.string identifikátory v kódu Androidu.
Koncepty platformy Android optikou Flutteru
Kromě uživatelského rozhraní je jednou z největších otázek, které si vývojáři Compose kladou, to, jak se jejich znalosti o Androidu prolínají s architekturou Flutteru. Naštěstí mnoho základních myšlenek – aktivity, životní cyklus, záměry, práce na pozadí, zdroje, sítě – má jasné protějšky, i když povrchové API vypadá jinak.
V Androidu, Activity a Fragment jsou vaše primární obrazovky a kontejnery; ve Flutteru je vše widget a navigace probíhá přes Navigator a Route objekty. Trasa zhruba odpovídá aktivitě nebo fragmentu, ale obvykle existuje pouze jeden hostingový server. Activity na Androidu s integrovaným enginem Flutter. Na zásobník Navigatoru vkládáte a odebíráte trasy, a to buď prostřednictvím pojmenovaných tras definovaných v MaterialApp nebo přímo konstruovaným PageRoute případy jako MaterialPageRoute.
Zpětná volání životního cyklu Androidu (onCreate, onStart, onResumeatd.) nemají v kódu Flutteru individuální hooky, ale můžete sledovat životní cyklus aplikace pomocí WidgetsBindingObserver. Odhaluje státy jako resumed, inactive, paused a detached, které zhruba odpovídají fázím viditelnosti, pozadí a zničení systému Android. Pokud skutečně potřebujete nízkoúrovňové hooky životního cyklu pro správu zdrojů, obvykle je implementujete na nativní straně systému Android v FlutterActivity nebo plugin, ne v Dartu.
Intenty hrají v Androidu dvě role: navigaci v aplikaci a komunikaci mezi aplikacemi. Jak již bylo zmíněno, Flutter nemá API pro navigaci založené na intentech – Navigator ho v rámci světa Dartu plně nahrazuje. Pro úlohy napříč aplikacemi (spuštění kamery, výběr souborů, zpracování intentů pro sdílení) se obvykle používají pluginy, které obalují nezbytná volání pro Android (a iOS). Pokud žádný plugin neexistuje, můžete si napsat vlastní pomocí MethodChannels pro komunikaci mezi Dartem a nativním kódem, přeposílání intentů a výsledků jako zpráv.
Vaše chápání práce na pozadí a vláknování se také přenáší, ale primitiva vypadají jinak. Android vás nutí přesunout síťové a diskové I/O operace mimo hlavní vlákno pomocí korutin, AsyncTask (zastaralý), WorkManager, JobScheduler, RxJava atd. Dart naopak používá jednovláknovou smyčku událostí pro každý izolát, s async/await pro I/O a samostatnými izoláty pro práci náročnou na CPU. Pro cokoli vázaného na I/O stačí označit své funkce. async, await operaci a nechat smyčku událostí udržovat uživatelské rozhraní responzivní; pro náročné úlohy CPU roztočíte izolát a komunikujete prostřednictvím předávání zpráv namísto sdílené paměti.
Co se týče síťování, Flutter je populární http Balíček hraje podobnou roli jako OkHttp + Retrofit pro základní případy použití. Skrývá velkou část práce s nízkoúrovňovými sockety a přirozeně se integruje s async/await. Pro komplexní potřeby můžete přejít na balíčky jako dio, ale základní vzorec zůstává: provést asynchronní volání, čekat na výsledek, aktualizovat stav pomocí setState() nebo vámi zvoleného správce stavu a znovu sestavte postižené widgety.
Pluginy, úložiště, Firebase a nástroje
V Androidu jste zvyklí deklarovat závislosti v Gradle; ve Flutteru je deklarujete v pubspec.yaml a načíst je z pub.dev. Soubory Gradle pod android/ Složky projektu Flutter jsou většinou určeny pro integrace specifické pro platformu nebo když potřebujete vlastní nativní knihovny – každodenní vývoj aplikací zůstává v zemi Dartu.
Sdílené preference a SQLite mají také hotové ekvivalenty. Kde Android nabízí SharedPreferences Pro malé úložiště klíč-hodnota a SQLite (nebo Room) pro strukturovaná data je Flutter zabalí pomocí pluginů jako shared_preferences a sqfliteTyto pluginy sjednocují chování systémů Android a iOS, takže můžete používat jedno rozhraní Dart API bez ohledu na platformu a zároveň se spoléhat na základní nativní implementace.
Integrace s Firebase je podobně přímočará a prvotřídní. Většina služeb Firebase – Authentication, Firestore, Realtime Database, Cloud Messaging, Analytics, Remote Config a další – má oficiální pluginy pro Flutter spravované týmy Firebase a Flutter. Ty odrážejí koncepční model z Android Firebase SDK, ale s Dart-idiomatic API. Pro další specializované funkce Firebase, které nejsou přímo pokryty, existuje zdravý ekosystém pluginů třetích stran na pub.dev.
Pro ladění a profilování nabízí sada DevTools od Flutteru bohatou sadu nástrojů přímo srovnatelnou s profilerem a Layout Inspectorem v Android Studiu. Můžete kontrolovat strom widgetů, sledovat přestavby, alokace paměti, diagnostikovat úniky a fragmentaci a procházet kódem Dart. V kombinaci s podporou IDE v Android Studiu a VS Code, horkého opětovného načítání a horkého restartu se cyklus zpětné vazby ve vývoji na Flutteru zdá být přinejmenším stejně napjatý – a často i napjatější – než na to, na co jste zvyklí u Compose.
Push notifikace, další běžný problém Androidu, jsou ve Flutteru řešeny pomocí pluginů, jako je firebase_messaging. V podpoře komunikují s Firebase Cloud Messaging a nativními notifikačními frameworky v systémech Android a iOS, ale logika vaší aplikace je uložena v jednotném rozhraní Dart API. Konfigurace a chování specifické pro platformu (jako jsou notifikační kanály v systému Android) jsou stále důležité a vaše stávající zkušenosti s těmito podrobnostmi o platformě jsou i nadále velmi relevantní.
Dokonce i widgety na domovské obrazovce v systému Android, které nelze implementovat čistě ve Flutteru, se stále dají integrovat s kódem Flutteru. Obvykle je sestavíte pomocí rozvržení Jetpack Glance nebo XML a poté použijete balíček, jako například home_widget komunikovat s vaší aplikací Flutter, sdílet data a dokonce vkládat rastrované uživatelské rozhraní Flutteru jako obrázek do nativního widgetu. Tento hybridní přístup vám umožňuje zachovat hlavní prostředí ve Flutteru a zároveň respektovat omezení platformy.
Při pohledu na všechny tyto paralely je zřejmé, že vývojář Jetpack Compose, který vstupuje do Flutteru, vůbec nezačíná od nuly. Vaše chápání deklarativního uživatelského rozhraní, životního cyklu Androidu, navigace, stavů, zdrojů a asynchronní práce se velmi přirozeně mapuje na svět Flutteru; nejvíce se mění názvy, jazyk (Dart) a multiplatformní myšlení. Jakmile si osvojíte widgety a Navigator jako základní koncepty, zbytek stacku má tendenci docela rychle zapadat na své místo.