Flutter er en hybrid mobil applikasjonsutviklingsplattform fra Google som nådde 1.0 i slutten av 2018. Selv om den er en nyere aktør på listen over hybridutviklingsrammer, har de gode ideene bak den fått den til å komme raskt inn blant utviklerne.

Målet mitt i denne artikkelen er å utforske disse ideene og skrive om mine erfaringer med Flutter, og hvorfor jeg føler at det er fremtiden for hybrid mobil applikasjonsutvikling.

Selv om det er eldre hybridapprammer i markedet, er det en økende liste over store navneselskaper som velger Flutter for sine mobilapplikasjoner. Mens Flutter utstillingsside lister opp mange av disse, her er noen bemerkelsesverdige apper som bruker Flutter enten for hele appen eller for en betydelig funksjon:

• Google Ads-appen
• GrabFoods GrabMerchant-app
• Alibaba Groups Xianyu-app, som har mer enn 50 millioner nedlastinger
• Nubank
• EBay Motors-appen

Mens Flutter-rammeverket er ganske i stand, er det fortsatt relativt nytt. For å få balanse vil jeg også diskutere noen begrensninger som du bør være oppmerksom på før du forplikter deg til Flutter.

Mitt håp er at etter å ha lest denne artikkelen, har du en god ide om fordeler og ulemper med Flutter, og har nok informasjon til å avgjøre om du skal bruke Flutter i ditt neste mobilapplikasjonsprosjekt.

Flutter Fordeler (fra et utviklingsperspektiv)

Som utvikler er dette det synspunktet jeg er mest kjent med og kan dele mest informasjon om.

Rask læringskurve

Den første hyggelige overraskelsen Flutter har for utviklere er hvor raskt det er å komme i gang. Det tar mindre enn 30 minutter å fullføre installasjonsprosessen og har et arbeidsutviklingsmiljø satt opp. Derfra er du klar til lag din første Flutter-app .

Populær redaktørintegrasjon

Flutter har også gode redaktørintegrasjoner. Jeg bruker personlig Android Studio, men det er det instruksjoner tilgjengelig for å sette opp IntelliJ, VSCode eller Emacs.

Ren utviklingsprosess

Sammenlignet med min tidligere erfaring med hybrid app-rammer, føles utviklingsprosessen også renere . Når jeg for eksempel brukte WebViews til å vise lister med mange elementer (rundt 100 eller så), måtte jeg håndtere høy CPU-bruk, spesielt når brukeren rullet gjennom listen. Jeg løste dem ved å bruke Joniske rammeelementer spesielt laget for dette. I Flutter er det en akseptert måte å vise lister på, ListView, som har fantastisk ytelse ut av esken.

Live på nytt

En annen ting som overrasket meg positivt, var funksjonen for live-omlasting. Som full stack-utvikler var jeg vant til rammeverk som BrowserWatch som leverer live reload i nettleseren.

Innfødt utvikling har ikke det (men jeg tror SwiftUI fra Apple gjør noen fremskritt på den fronten for iOS-utvikling). Android- og iOS-utviklere trenger vanligvis å skrive kode og deretter vente på at den skal kompileres og lastes på enheten eller simulatoren før de kan se endringer.

Flutter gir (a la React Native) en live-omlastningsmekanisme, der app-koden lastes inn på enheten så snart utviklerne trykker på 'lagre'. Dette gir umiddelbar tilbakemelding, noe som gjør utviklingen mye raskere.

Opptreden

Søknadsytelse er en annen beregning der Flutter er sakte dukker opp som en vinner .

Siden Flutter-rammeverket er under aktiv utvikling, er det mange steder der ytelsesoptimaliseringer kan gjøres. Dette er tydelig i for eksempel Flutter 1.17, som økte gjengivelsesytelsen med opptil 50% på nyere iOS-enheter, og reduserte minneforbruket med opptil 70% for visse typer arbeidsbelastninger.

Konsistens på tvers av plattformer

Virkelig konsistente brukergrensesnitt på begge mobilplattformene er en annen bemerkelsesverdig egenskap ved Flutter. Fordi Flutter bruker sin egen gjengivelsesmotor - mer om det senere - er brukergrensesnittet det nøyaktig det samme på iOS og Android. Utviklere trenger ikke lenger å takle plattformspesifikke stylingproblemer for å få alt til å se ut som designet: Den garantien er en del av rammeverket.

Språk, verktøy og utvidelse

Tre andre mindre, men fremdeles viktige aspekter jeg mener bør nevnes her er:

• Dart , språket som Flutter-applikasjoner er programmert på, er veldig enkelt å komme i gang med. Men det er det også ganske kraftig språk , opprinnelig ment av Google for å erstatte JavaScript. Hvis utviklere har erfaring med JavaScript eller andre C-lignende språk, har de ingen problemer med å plukke opp Dart innen en dag eller to.
• Det er en robust plugin manager (pub) inkludert i standardverktøykjeden og et stort bibliotek med plugins tilgjengelig gjennom pub.dev plugin repository.
• Opprette plugins det er ganske enkelt å dra nytte av funksjonene for innfødte plattformer, så hvis utviklere trenger tilgang til en plattformfunksjon som det ikke finnes noe plugin for, er det ikke så vanskelig å kode en.

Flutter Fordeler (fra et forretningsperspektiv)

Den største Flutter-fordelen som de fleste bedrifter tenker på er bare å måtte ansette ett lag for både iOS- og Android-plattformene. Imidlertid er en viktigere fordel som mange bedrifter overser raskere tid til markedet . Ved å utnytte utviklingsfordelene i forrige avsnitt, kan et mindre utviklingsteam bygge en vakker applikasjon med naturlig ytelse som gir den samme brukeropplevelsen på begge plattformene mye raskere ved hjelp av Flutter.

Flutter tillater utviklere å bygge noen virkelig vakre brukergrensesnitt . Se på en nylig utfordring fra Google og Lenovo for å bygge et vakkert UI-grensesnitt for Lenovo Smart Clock. Vinneren, Partikkelklokke av Mickel Andersson, er ikke bare unikt elegant - den viser også frem hvor performante animasjoner er i Flutter.

For bedrifter som vurderer Flutter, men som er usikre på om det er riktig vei å gå, kan Flutter utnyttes trinnvis: Eksisterende mobilapper kan integrere Flutter en enkelt del om gangen. Faktisk er det slik de fleste store selskaper starter med Flutter, ved å bygge en liten del av deres eksisterende applikasjon i Flutter, og deretter sakte erstatte andre deler når de ser fordelene.

Begrensninger du må vurdere før du bruker flutter

I rettferdighet er ikke Flutter det å være nyere ganske like kamptestet som andre hybridrammer for mobilapplikasjoner som React Native - når alt kommer til alt, dekker React Natives sluttbruker rekkevidde mobilappene til Facebook, Instagram, Skype og Discord.

Standardsvaret til 'skal jeg bruke Flutter?' er foreløpig en forsiktig ja . Dette er fordi prosjektledere fortsatt trenger å vurdere hvilke, om noen, avanserte funksjoner de trenger og sørg for at disse funksjonene er tilgjengelige i Flutter før du forplikter deg til å bruke den. Spesielt er det verdt å spørre hvilke biblioteker og plugins et team kan trenge for å bygge et bestemt program. Som en nyere oppføring i mobilapp-rammer, har ikke Flutter det omfattende omfanget av biblioteker og plugins som React Native gjør.

For eksempel er kamerastøtte i Flutter ikke fullført ennå, med zooming og blitsstyring ennå ikke en del av det offisielle kameraprogrammet. For meg var det ikke en deal breaker, da jeg klarte å finne et tredjeparts plugin når jeg trengte å integrere foto- / videofunksjonalitet i en app jeg bygde.

Et annet viktig plugin som du kanskje savner, er Google Maps. Det er ingen Dart-native Google Maps-plugins, og mens det er en plugg inn For å tillate integrering av Google Maps i Flutter-koden din, bruker den funksjonene i Flutter (plattformvisninger) som fremdeles er i utviklerens forhåndsvisningstatus.

En ting til som ikke vil påvirke mange prosjekter, men du bør være oppmerksom på, er at Flutter foreløpig ikke støtter 3D-muligheter. Teamet fokuserer bare på 2D for nå. Men de fleste applikasjoner bruker ikke 3D-funksjonalitet, så dette bør ikke være en deal-breaker for de fleste utviklere.

Noen råd fra min erfaring med Flutter

Etter å ha gitt ut tre Flutter-apper de siste to årene, lærte jeg en rekke ting som jeg skulle ønske jeg hadde blitt fortalt da jeg startet. Jeg vil liste dem her i håp om at de hjelper deg i din Flutter-utviklingsreise.

Flutter er veldig lett å komme i gang med. Jeg startet med et fantastisk kurs videre App Brewery . Etter å ha fullført de første modulene trodde jeg imidlertid at jeg hadde lært nok og begynte å bygge den første appen som jeg lanserte.

På grunn av min utålmodighet hoppet jeg over en rekke moduler i det kurset som viste seg å være viktig, og jeg måtte lære lærdommene til disse modulene på den harde måten ved å gjøre feil. Spesielt ville jeg ha gjort en mye bedre jobb ved første gangs bruk av Flutter for apputvikling hvis jeg hadde lært noen gode fremgangsmåter for Flutter:

• Hvordan modulere og strukturere Flutter-applikasjonskoden.
• Hvordan statsledelse fungerer.
• Hvordan autentisere brukere og spore autentiseringsstatus på tvers av de forskjellige sidene i Flutter-appen min.
• Hvordan integrere varsler ved hjelp av Firebase Messaging pakke.

Jeg endte opp med å lære alle disse tingene, men måtte gjøre mange feil først. Jeg skrev om viktige deler av den første appen jeg bygde. Med den andre Flutter-appen min hadde jeg imidlertid lært av feilene mine og endte opp med å gjøre en bedre og raskere jobb.

Det er mange ressurser du enkelt kan finne ved å søke på Google for å lære om konseptene jeg har oppført ovenfor. Du kan starte med å se på lenkene på Lære mer siden på Flutter-siden.

En annen ting jeg fant er at på grunn av hvor ny Flutter er, er det ikke noe mønster for å strukturere appen din. Fra en hovedsakelig Django-basert utviklingskarriere, er jeg vant til å vite at MVC er mønsteret som skal brukes i Django-appene mine. iOS har også en klar vinner i MVVM-mønsteret som følger. Android har sine sett med retningslinjer for hvordan du best kan arkitisere en app.

Flutter har ikke noe slikt arkitektonisk mønster som har 'vunnet ut' de mange mulighetene. Dette var noe som ga meg en tøff tid i utgangspunktet. Til slutt, etter å ha utviklet en rekke Flutter-apper, tror jeg det er best å bare velge en arkitektur og holde fast ved den.

Jeg bruker personlig provider pakke som både et avhengighetsinjeksjons- og endringsledelsesrammer. Mine Flutter-apper er også omtrent fordelt på tre linjer:

1. Visninger , som er widgetene som bygger opp applikasjonen, inkludert skjermene. Jeg injiserer tjenester og modeller ved hjelp av Consumer widget fra Provider pakke inn i mine synspunkter, slik at jeg kan bygge brukergrensesnittet basert på tilgjengelige data. Consumer widgeten bygger også opp visningen når staten endres, og det er hvordan appene mine reagerer på tilstandsendringer.
2. Modeller , som er vanlige gamle objekter som jeg bruker for å holde strukturerte data.
3. Tjenester / kontrollere , hvor det meste av forretningslogikken går. API-grensesnitt er også kodet her, som kan hente og sende data til API. Disse API-grensesnittene gir og aksepterer modeller for å formidle data rundt.

De blokkbibliotek er også verdt å vurdere som et alternativ til provider pakke. Den har en litt annen arkitektur, og den bruker strømmer av hendelser og stater for å koble til visninger og modeller.

I slekt: Hvordan utnytte BLoC for kodedeling i Flutter og AngularDart

Det er en litt mer kompleks måte å administrere staten enn å bruke provider biblioteket, men det lønner seg hvis du har et komplekst program der du gjør endringer i de samme dataene fra flere kilder og trenger å svare på disse endringene fra flere steder.

Hvis du ikke bruker BLoC eller provider, må du finne på noen metode for å administrere staten på tvers av applikasjonen din, spesielt når det gjelder varsler.

Hvordan Flutter sammenlignes med andre hybridrammer

Reager Native

React Native er uten tvil det mest populære og vellykkede hybrid-applikasjonsrammeverket til dags dato, og med god grunn. Det tok et populært og godt laget front-end web-rammeverk, React, og tillot også millioner av front-end-utviklere å begynne å skrive mobilapplikasjoner. Jeg er sikker på at mange av de flotte mobilappene vi har i dag, aldri ville blitt laget hvis utviklerne måtte finne tid og motivasjon til å lære de innebygde SDK-ene for iOS og Android.

På denne bakgrunn er jeg trygg på å si at Flutter til slutt vil vinne ut som det ledende hybrid mobilapplikasjonsrammeverket. Det er et par grunner til det.

React Native-komponenter er beskrevet i JavaScript-kode og oversatt til opprinnelige kontroller. Dette betyr at brukerne får en annen brukergrensesnittfølelse i iOS- og Android-versjonene av appen. Hvis utviklere prøver å oppnå en innfødt opplevelse for brukerne, er dette flott.

Imidlertid betyr det også at hvis utviklere vil ha samme, konsekvent UI på tvers av begge mobile plattformer, de må jobbe hardt for å utforme de innfødte komponentene for å se like ut, eller bruke forskjellige komponenter helt som gir samme utseende og følelse på tvers av begge plattformene.

Kontraster dette med Flutter, der rammeverket gir sine egne widgets på alle støttede plattformer. Det skjer ingen oversettelse, fordi Flutter ikke stoler på de opprinnelige kontrollene for å male brukergrensesnittet. I stedet bruker den sitt eget kontrollbibliotek. Widgetbiblioteket til Flutter inneholder widgets som ser ut som innebygde kontroller, men de er helt valgfrie.

Denne tilnærmingen har sine fordeler og ulemper. Den største proffen er at du nå har nøyaktig samme app på begge plattformene. Men du gir opp noen ting for å oppnå det.

Siden Flutter bruker sine egne widgets i stedet for å bruke de innfødte, kan du ikke bruke mengden av eksisterende biblioteker som gir tilpassede kontroller som du kan med minimalt arbeid med React Native. I React Native er det ganske enkelt å skrive en liten innpakning rundt en eksisterende native-kontroll og få den til å fungere. Dette er også grunnen til at det for øyeblikket ikke er noen stabil Google Maps-implementering for Flutter.

Imidlertid jobbes det med muligheten til å bygge inn innfødte kontroller akkurat nå og er i forhåndsvisning av utviklere, noe som betyr at du kan bruke den, men kanskje måtte kjempe med feil. Når den er utgitt, lukker den dette ganske store hullet i funksjonalitet i Flutter sammenlignet med React Native.

Den samme Flutter-funksjonen - ved å bruke sitt eget bibliotek med widgets i stedet for native-funksjoner - gir også en enorm fordel når du vil lage en helt ny komponent. I React Native må du bygge en plattforminnfødt komponent og importere den til applikasjonen via bindinger.

Med Flutter kan du bygge tilpassede komponenter rett i Dart-koden. Du har full kontroll over brukergrensesnittet med moduler som CustomPainter som lar deg tegne hva du trenger, og du har et bibliotek med widgets tilgjengelig som lar deg implementere tilpassede animasjoner. Du trenger aldri å gå utenfor Dart-kodebasen for å bygge disse tilpassede widgetene.

Og dette tror jeg er en av de største fordelene med Flutter. Du har full kontroll over brukergrensesnittet ditt fra Dart-koden og trenger ikke lenger bekymre deg for å lære den innebygde SDK-en til plattformene du utvikler for.

Apache Cordova

Apache Cordova er ikke så mye et rammeverk som det er en nettleseromslag. Med Cordova bygger du applikasjonen din ved hjelp av webteknologier: HTML, CSS og JavaScript. Cordova gir deg en måte å kjøre denne webapplikasjonen på mobile plattformer og eksponerer API-er for innfødte plattformer i JavaScript slik at applikasjonen din kan samhandle med plattformen.

Det er en rekke forskjellige rammer bygget for Cordova. En av de berømte som jeg har brukt tidligere er Jonisk ramme . Det gir et sett med brukergrensesnittkomponenter som ser ut og virker som de opprinnelige plattformkomponentene. Imidlertid er disse komponentene implementert ved hjelp av HTML / CSS / JavaScript.

Utviklingsopplevelsen med Cordova og Ionic er veldig hyggelig, og det er veldig raskt å komme i gang hvis du allerede er nettutvikler. Fordi du bygger applikasjoner ved hjelp av webteknologier, har du hele webøkosystemet tilgjengelig for deg. Tenk på hundretusenvis av små komponenter og biblioteker basert på HTML / CSS / JavaScript, og du kan bruke de fleste - om ikke alle - av disse. Dette betyr at de fleste 'widgets' du trenger allerede er tilgjengelige for deg online.

Dette er imidlertid også en ulempe. Fordi du bruker webteknologier for å bygge applikasjonene dine, tar det stor forsiktighet å sørge for at appen ser ut og føles som en mobilapp, og ikke bare et nettsted som ble nedskalert til å fungere på mobil.

Selv om Cordova er en fin måte å utvikle en MVP eller til og med de første versjonene av appen din, var den første appen jeg bygde i Flutter en port til en Ionic-app. Ytelsesforbedringene vi fikk, spesielt i visninger som hadde mye innhold å bla gjennom, var merkbare fra den første interaksjonen.

Xamarin

Jeg har ingen erfaring med Xamarian, så jeg kan ikke sammenligne de to. Imidlertid, i løpet av min forskning, kom jeg over en flott artikkel det gjør en rettferdig sammenligning.

Mens artikkelen ender med et uavgjort mellom Flutter og Xamarian, kan jeg med sikkerhet si at hvis jeg leste den og måtte ta et valg mellom de to rammene, ville jeg ha gått med Flutter fordi de tingene som den skinner i er tingene at jeg verdsetter mer.

En teknisk oversikt over Flutter

Flutter: 'Game Engine' av Hybrid App Frameworks

Blant hybridrammer for mobilapplikasjoner har Flutter en unik tilnærming. Det delegerer ikke brukergrensesnittet til den opprinnelige plattformen, eller bruker en nettvisning. I stedet bruker Flutter sin egen gjengivelsesmotor for å male brukergrensesnittet. Dette ligner på hvordan spill bruker en spillmotor som genererer alle deler av brukergrensesnittene sine, i stedet for å bruke innebygde kontroller.

Flutter bruker den høye ytelsen, kamptestet Skia grafikkmotor å tegne alt i mobilapplikasjonen din. Å bruke Skia gir to hovedfordeler som jeg kan tenke meg, selv om jeg er sikker på at Google-ingeniørene bak Flutter hadde mye mer i tankene:

1. Appen din vil se nøyaktig ut på alle plattformer uten å måtte tilpasses for hver enkelt.
2. Appen din får god ytelse, i likhet med innfødte applikasjoner, fordi det ikke er noe mellomlag som må oversette koden din til innfødt plattformkode for å tegne widgetene.

Alt er en widget

Flutter-dokumentene snakker om Flutter som et 'React-style framework'. Dette er tydelig i hvordan apper er bygget ved å komponere mindre widgets ( komponenter i Reager terminologi) sammen.

Imidlertid tar Flutter alt er en widget gå et skritt videre enn noen annen ramme jeg har jobbet med.

Et enkelt eksempel er polstring. Med de fleste rammeverk er polstring en attributt av UI-elementene. I Flutter, Padding er en widget som kan pakke inn andre widgets i seg selv og legge til polstring rundt barn-widgeten.

Mer unikt, InheritedWidget har ingen brukergrensesnitt og gir ingen brukerinteraksjon. Den eneste jobben er å legge til informasjon i widget-treet, slik at du på et tidspunkt dypt inne i treet kan trekke ut den informasjonen.

For eksempel roten til applikasjonen din | _ _ + _ | widget - kan injisere en godkjenningstjeneste i widget-treet ved hjelp av MaterialApp. Nå, dypt inne i treet på en annen side, som brukerprofilsiden din, kan du bruke en metode for å trekke ut den autentiseringstjenesten og bruke den.

Dette alt er en widget tilnærming tar litt å bli vant til. Men når du først er kjent med det, blir det en kraftig måte å bygge funksjonalitet i applikasjonene dine på.

Flutter, Dart og Digging In the Source

Flutter er nært knyttet til Dart. Mens kjerngjengemotoren er bygget i C / C ++, er det bare en liten del av Flutter.

Flertallet av Flutter-kodebasen er skrevet i Dart, og det er det gode grunner hvorfor Flutter-teamet valgte det. Men den største fordelen for meg var at jeg enkelt kunne se på kildekoden til rammeverket - og alle de forskjellige widgetene det gir - og lære av dem.

Dette er en kraftigere fordel enn mange utviklere innser. Jeg anbefaler at de fleste utviklere prøver å finne svar i koden til rammene / bibliotekene sine, da det ikke bare hjelper dem å forstå hva som skjer under omslagene, men også utsetter dem for en velutviklet kode av høy kvalitet, noe som er en sikker måte av å vokse som utvikler.

Innfødt plattforms interoperabilitet

Mens Flutter leverer UI-laget, og forretningslogikken håndteres enkelt via rene Dart-pakker, er det den enkleste strategien å få tilgang til funksjonene til den opprinnelige plattformen som geolokalisering og kamerakontroll.

Men hvis det er noen funksjoner du trenger, og som ikke er tilgjengelig via en eksisterende pakke, skrive en selv er ikke så vanskelig. Jeg har ikke bygget noen plattform-native pakker selv, men jeg har sett på kildekoden for mange av nysgjerrighet.

Selv om jeg ikke er en egen applikasjonsutvikler, kunne jeg for det meste forstå de opprinnelige delene av disse pluginene og se hvordan de koblet seg til Dart-kjøretiden via meldingsoverføring. For erfarne utviklere av innfødte plattformer vil det være veldig enkelt å lage en ny pakke for å utnytte en innfødt evne.

Bør du bruke flagre i ditt neste prosjekt?

Forhåpentligvis har denne artikkelen gitt deg nok informasjon til å avgjøre om du kan bruke Flutter i ditt mobilapplikasjonsprosjekt. Jeg har prøvd å gi et balansert bilde av Flutter, og viser både fordeler og ulemper.

Selv om ingen kan ta avgjørelsen for deg, kan jeg gi deg noen avskjedsråd om hvordan jeg kan nærme meg spørsmålet om å bruke Flutter i min neste mobilapplikasjon. Hvis fordelene til Flutter kan gi alle funksjonene som et program trenger, vil jeg velge det med et hjerteslag.

Det er fordi, bortsett fra de få områdene der Flutter mangler for øyeblikket, er alle andre aspekter av det de jeg har lært å beundre og stole på når jeg utvikler og lanserer de fem forskjellige Flutter-applikasjonene det siste året:

• Flutter er lett å komme i gang
• Hastighetsgevinsten som kan oppnås ved å bruke et rammeverk som ble designet fra grunnen av for å fokusere på utviklingshastigheten
• Det rike økosystemet med lett tilgjengelige Dart-biblioteker og tredjepartspakker
• Flutter er annerledes, men ekstremt produktiv måte å utvikle applikasjoner på alt er en widget nærme seg

De som tilbyr tjenester for utvikling av mobilapper ville være lurt å gi Flutter et seriøst blikk, hvis de ikke allerede har gjort det.

Jeg vil avslutte med å merke en siste Flutter-fordel: Den har noe av den beste dokumentasjonen for ethvert bibliotek eller rammeverk jeg har jobbet med. Det er sjelden jeg googler et Flutter-spørsmål, og det blir ikke besvart av en side fra Flutter sin egen side .

I slekt: Flutter Tutorial: Hvordan lage din første Flutter-app

---

Som Google Cloud-partner er ApeeScapes Google-sertifiserte eksperter tilgjengelig for selskaper på etterspørsel for deres viktigste prosjekter.

Forstå det grunnleggende

Hva brukes Flutter til?

Flutter er en utviklingsplattform for mobilapplikasjoner fra Google som brukes til å bygge raske, native-lignende mobilapplikasjoner. Flutter-applikasjoner kan kjøres på både iOS og Android med samme kode og presentere det samme eksakte brukergrensesnittet på begge plattformene.

Hvilket språk er Flutter?

Flutter bruker programmeringsspråket Dart, som brukes til å kode alle brukergrensesnitt-widgets og forretningslogikken til en mobilapplikasjon.

Hvorfor opprettet Google Flutter?

Googles uttalte mål for å lage Flutter er å tilby et brukergrensesnittverktøy som kan brukes til å lage mobilapplikasjoner som 1) gir utviklere full kontroll over alle lagene i applikasjonen, 2) gir nesten naturlig ytelse, og 3) ser ut og fungerer på samme måte på alle støttede plattformer.

Er Flutter vanskelig å lære?

Flutter bruker Dart-språket, som er et kraftig, men imøtekommende programmeringsspråk. Hvis du er kjent med grunnleggende OOP-konsepter og har litt programmeringserfaring, kan du enkelt lære grunnleggende om Dart og begynne å bygge apper med Flutter på så lite som to uker.

Er Flutter verdt å lære?

Som en spennende ny aktør i hybridlandskapet for utvikling av mobile applikasjoner, er Flutter absolutt verdt å lære. Det er enkelt å komme i gang med og kraftig nok til å brukes til de fleste applikasjoner. Det driver allerede virksomhetskritiske applikasjoner fra selskaper som Google, Alibaba og Nubank.

Har Flutter en fremtid?

Flutter er et stabilt og aktivt prosjekt, etter å ha gitt ut v1.7 i mai 2020 med store ytelsesforbedringer. Den brukes av selskaper som Google og Alibaba til å drive deler av kjernevirksomhetens mobile applikasjoner. Det er ganske rimelig å forvente at Flutter er fremtiden for hybrid mobil applikasjonsutvikling.