Kunnskap er bra, bare bra. Men praksis er også nødvendig slik at du kan bruke de mottatte dataene, og overføre dem fra "passiv lagring"-status til "aktiv bruk"-status. Uansett hvor god den teoretiske opplæringen er, kreves det fortsatt arbeid "i felten". Ovennevnte gjelder for nesten alle studieretninger, inkludert selvfølgelig programvareutvikling.
I år begynte GeekBrains, som en del av det mobile utviklingsfakultetet ved nettuniversitetet GeekUniversity, å jobbe med det interaktive byrået AGIMA, hvis team er profesjonelle utviklere (de lager komplekse høybelastningsprosjekter, bedriftsportaler og mobilapplikasjoner, det er alt). AGIMA og GeekBrains har laget et valgfag for et dypdykk i de praktiske spørsmålene ved utvikling av mobilapplikasjoner.
Forleden snakket vi med Igor Vedeneev, en iOS-spesialist, og Alexander Tizik, som spesialiserer seg på Android. Takket være dem ble valgfaget på mobilutvikling beriket med praktisk и . I denne artikkelen snakker utviklerne om viktigheten av hvert område for programmerere.
Reaktiv programmering i iOS med RxSwift som eksempel
Valgfaglærer Igor Vedeneev: "Med RxSwift vil søknaden din fly"
Hvilken informasjon får studentene i løpet av valgfaget?
Vi snakker ikke bare om egenskapene til rammeverket, men viser også hvordan du bruker det i den klassiske MVVM + RxSwift-kombinasjonen. Flere praktiske eksempler er også omtalt. For å konsolidere innhentede data, skriver vi en søknad som er så nært som mulig til feltdriftsforholdene. Dette vil være et musikksøkeprogram som bruker . Der vil vi bruke alle beste fremgangsmåter, pluss vurdere et enklere alternativ for å bruke RxSwift i MVC-paradigmet.
RxSwift - hvorfor trenger en iOS-programmerer dette rammeverket, hvordan gjør det livet enklere for en utvikler?
RxSwift effektiviserer arbeidet med hendelsesstrømmer og koblinger mellom objekter. Det enkleste og mest åpenbare eksemplet er bindinger: for eksempel kan du oppdatere grensesnittet ved å sette nye verdier i en variabel i viewModel. Dermed blir grensesnittet datadrevet. I tillegg lar RxSwift deg beskrive systemet i en deklarativ stil, som lar deg organisere koden din og øke lesbarheten. Alt dette bidrar til å utvikle applikasjoner mer effektivt.
For en utvikler er kunnskap om rammeverket også et godt pluss på en CV, siden forståelse for reaktiv programmering, og spesielt erfaring med RxSwift, er verdsatt i markedet.
Hvorfor velge akkurat dette rammeverket fremfor andre?
RxSwift har det største fellesskapet. Det vil si at det er større sjanse for at problemet utvikleren står overfor allerede er løst av noen. Også et stort antall bindinger ut av esken. Dessuten er RxSwift en del av ReactiveX. Det betyr at det finnes en analog for for eksempel Android (RxJava, RxKotlin), og kolleger på verkstedet kan snakke samme språk med hverandre, til tross for at noen jobber med iOS, andre med Android.
Rammeverket oppdateres kontinuerlig, mindre feil blir rettet, støtte for funksjoner fra nye versjoner av Swift legges til, og nye bindinger legges til. Siden RxSwift er åpen kildekode, kan du følge alle endringene. Dessuten er det mulig å legge dem til selv.
Hvor bør RxSwift brukes?
- Bindinger. Som regel snakker vi om brukergrensesnittet, muligheten til å endre brukergrensesnittet, som om vi reagerer på dataendringer, og ikke eksplisitt forteller grensesnittet at det er på tide å oppdatere.
- Forholdet mellom komponenter og operasjoner. Bare et eksempel. Vi må få en liste over data fra nettverket. Faktisk er dette ikke en så enkel operasjon. For å gjøre dette må du sende en forespørsel, kartlegge svaret til en rekke objekter, lagre det i databasen og sende det til brukergrensesnittet. Som regel er forskjellige komponenter ansvarlige for å utføre disse operasjonene (vi elsker og følger prinsippene ?). Med et verktøy som RxSwift for hånden, blir det mulig å beskrive HVA systemet vil gjøre, og HVORDAN det vil gjøre det vil være andre steder. Det er på grunn av dette at bedre organisering av koden oppnås og lesbarheten øker. Relativt sett kan koden deles inn i en innholdsfortegnelse og selve boken.
Coroutines i Kotlin
Valgfagslærer Alexander Tizik: «Moderne utvikling krever moderne tekniske midler»
Hva vil bli undervist ved GeekBrains-fakultetet som en del av merkekvartalet?
Teori, sammenligninger med andre tilnærminger, praktiske eksempler i ren Kotlin og i Android-applikasjonsmodellen. Når det gjelder praksis, vil studentene få vist en applikasjon der alt er knyttet til korutiner. Faktum er at de fleste applikasjoner er helt asynkrone og parallelle databehandlinger. Men Kotlin-korutiner lar forvirrende, heterogen eller altfor kompleks og ytelseskrevende kode reduseres til en enkelt, lettfattelig stil, og oppnår fordeler ved korrekt utførelse og ytelse.
Vi skal lære å skrive idiomatisk kode i korutiner som løser praktiske problemer og er forståelig ved første øyekast selv uten dyp kunnskap om hvordan korutiner fungerer (som ikke kan sies om biblioteker som RxJava). Vi vil også forstå hvordan man bruker mer komplekse konsepter, for eksempel aktørmodellen, for å løse mer komplekse problemer, for eksempel datavarehuset i MVI-konseptet.
Forresten, flere gode nyheter. Mens valgfaget ble spilt inn, ble det gitt ut en oppdatering til Kotlin Coroutines-biblioteket, der klassen dukket opp Flow - analog av typer Flowable и Observable fra RxJava. Oppdateringen gjør i hovedsak Coroutines-funksjonen komplett fra applikasjonsutviklerens synspunkt. Riktignok er det fortsatt rom for forbedring: til tross for at takket være støtten fra koroutiner i kotlin/native, er det allerede mulig å skrive multiplattformapplikasjoner i Kotlin og ikke lide av mangelen på RxJava eller analoger i ren Kotlin, støtte for koroutiner i kotlin/native er ennå ikke fullført. Det er for eksempel ikke noe begrep om skuespillere. Generelt har Kotlin-teamet planer om å støtte mer komplekse aktører på alle plattformer.
Kotlin Coroutines - hvordan hjelper de en Kotlin-utvikler?
Coroutines gir en flott mulighet til å skrive kode som er lesbar, vedlikeholdbar og sikker, asynkron og samtidig. Du kan også lage adaptere for andre asynkrone rammeverk og tilnærminger som kanskje allerede er brukt i kodebasen.
Hvordan er Coroutines forskjellige fra tråder?
Kotlin-teamet kaller coroutines lette tråder. I tillegg kan en coroutine returnere en viss verdi, fordi en coroutine i sin kjerne er en suspendert beregning. Det er ikke direkte avhengig av systemtråder; tråder utfører bare koroutiner.
Hvilke praktiske problemer kan løses med Coroutine, som ikke kan eller er vanskelige å løse ved å bruke "ren" Kotlin?
Alle asynkrone, parallelle, "konkurransedyktige" oppgaver løses godt ved hjelp av korutiner - det være seg å behandle brukerklikk, gå på nett eller abonnere på oppdateringer fra en database.
I ren Kotlin løses disse problemene på samme måte som i Java – ved hjelp av tusenvis av rammeverk, som hver har sine fordeler og ulemper, men ingen av dem har støtte på språknivå.
Som en konklusjon er det verdt å si at begge valgfagene (og hovedkursene også) oppdateres i henhold til endringer i ytre forhold. Hvis viktige oppdateringer vises i språk eller rammeverk, tar lærere hensyn til dette og endrer programmet. Alt dette lar deg holde fingeren på pulsen i utviklingsprosessen, for å si det sånn.
Kilde: www.habr.com