Dette lille Kotlin-bibliotek kan være den reneste måde at opbygge tværplatformsapps på

I verden af mobiludvikling spiller valget af den rigtige applikationsarkitektur en afgørende rolle for at sikre kode kvalitet, vedligeholdelse og skalerbarhed. Hvert år bringer nye tilgange, biblioteker og rammer designet til at forenkle udviklingsprocessen og gøre kode mere struktureret.I de seneste år har MVI-arkitekturen (Model-View-Intent) vundet særlig popularitet ved at tilbyde en elegant løsning til styring af applikationsstatus og tilrettelæggelse af en-vejs dataflow. I denne artikel vil vi undersøge SimpleMVI – en let, men kraftfuld løsning til implementering af MVI-mønsteret i Kotlin-multiplatformprojekter. Hvad er MVI-mønsteret og dets kerne begreber Model-View-Intent (MVI) er et arkitektonisk mønster til udvikling af brugergrænseflader, inspireret af funktionel programmering og reaktive systemer. — data moves in one direction, forming a cycle: from user action to model change, then to view update. Unidirectional Data Flow — the application state is not changed directly; instead, a new state is created based on the previous one. Immutable State — the same user actions with the same initial state always lead to the same result. Determinism I MVI arkitektur: Model repræsenterer den uforanderlige applikationstilstand, der fuldt ud beskriver de data, der er nødvendige for at vise brugergrænsefladen. Visning viser passivt den aktuelle tilstand og overfører brugerhandlinger som intentioner. Intent beskriver brugerens eller systemets hensigter, der potentielt kan ændre applikationens tilstand. Ud over disse kernekomponenter omfatter MVI ofte: Reducer – en funktion, der tager den aktuelle tilstand og Intent, og returnerer en ny tilstand. Sideeffekt – bivirkninger, der ikke påvirker tilstanden, men kræver interaktion med eksterne systemer (f.eks. navigation, meddelelser, API-anmodninger). Kort historie om arkitektoniske mønstre UI arkitektoniske mønstre har udviklet sig betydeligt over tid: MVC (modelvisningskontroller) Et af de første mønstre, der opdelte applikationen i tre komponenter: Model – data og forretningslogik Visning – brugergrænseflade Controller – håndtering af brugerindtastning Hovedproblemet med MVC er den stramme sammenkobling mellem komponenter og uklar adskillelse af ansvarsområder, hvilket komplicerer test og vedligeholdelse. MVP (modelvisning præsentation) En forbedring i forhold til MVC, hvor: Model – data og forretningslogik Visning – passiv brugergrænseflade Præsentant - formidler mellem Model og View MVP løser testbarhedsproblemet, men fører ofte til oppustede præsentanter og stram sammenkobling mellem præsentant og visning. MVVM (Model-View-ViewModel) er en Næste skridt i udviklingen: Model – data og forretningslogik Visning – brugergrænseflade ViewModel – konverterer data fra Model til et format, der er bekvemt for View MVVM bruger begrebet data binding, som reducerer mængden af boilerplate kode, men kan forårsage problemer med sporing data flow. MVI (Model-View-Intent) er en En moderne tilgang, der fremhæver: Forudsigelighed – en deterministisk tilgang til statsforvaltning Immutabilitet – tilstanden ændres ikke, men erstattes Unidirektionel datastrøm – klar og gennemsigtig sekvens af begivenheder MVI er særligt effektiv til komplekse, data-rige applikationer med talrige brugerinteraktioner og asynkrone operationer. Hvorfor SimpleMVI blev skabt og dens plads blandt andre biblioteker SimpleMVI blev udviklet for at give udviklere et simpelt men kraftfuldt værktøj til implementering af MVI-mønsteret i Kotlin Multiplatform-projekter. Fokuserer på domæne logik, uden at påtvinge løsninger til UI-laget Overholder princippet om "enkelhed frem for alt", hvilket giver et minimum af nødvendige komponenter Er optimeret til Kotlin Multiplatform, hvilket sikrer kompatibilitet med forskellige platforme Strengt kontrollerer trådsikkerhed, hvilket sikrer, at interaktion med staten kun forekommer på hovedtråden Giver fleksibel fejlhåndteringskonfiguration gennem konfigurationssystemet De vigtigste fordele ved SimpleMVI i forhold til alternativer: Færre afhængigheder og mindre bibliotekstørrelse sammenlignet med mere komplekse løsninger Lavere indgangstærskel for forståelse og brug Full Kotlin-tilgang ved hjælp af moderne sprogkonstruktioner Praktisk DSL til beskrivelse af forretningslogik Tydelig adskillelse af ansvarsområder mellem komponenterne SimpleMVI sigter ikke mod at løse alle applikationsarkitekturproblemer, men giver et pålideligt grundlag for at organisere forretningslogik, der kan integreres med enhver løsning til brugergrænseflade, navigation og andre aspekter af applikationen. Grundlæggende begreber og komponenter i SimpleMVI SimpleMVI tilbyder en minimalistisk tilgang til implementering af MVI-arkitektur, der fokuserer på tre nøglekomponenter: Store, Actor og Middleware. Hver af disse komponenter har en unik rolle i at sikre unidirektionel dataflow og styre applikationstilstanden. Store – det centrale element i arkitekturen Definition og rolle for butikken Store er hjertet af SimpleMVI – det er en beholder, der holder applikationens tilstand, behandler intentioner og genererer bivirkninger. Store indkapsler al data-relateret logik, der giver en enkelt kilde til sandhed for brugergrænsefladen. public interface Store { // Current state public val state: State // State flow public val states: StateFlow // Side effects flow public val sideEffects: Flow // Store initialization @MainThread public fun init() // Intent processing @MainThread public fun accept(intent: Intent) // Store destruction @MainThread public fun destroy() } Stor livscyklus Tjenesten har en klart defineret livscyklus: - instantiating the Store object with necessary dependencies Creation - calling the method, preparing internal components Initialization init() - processing intents through the method Active use accept(intent) - calling the method, releasing resources Destruction destroy() Det er vigtigt at forstå, at: Alle offentlige Store-metoder skal kun kaldes på hovedtråden (mærket med @MainThread-annotationen) Efter at have kaldt destroy(), kan Butikken ikke bruges; forsøg på at få adgang til en ødelagt Butik vil resultere i en fejl Butikken skal initialiseres med init()-metoden før brug Statsforvaltning Store giver følgende muligheder for at arbejde med staten: via the property Access to the current state state via the flow Observing state changes states via the flow Processing side effects sideEffects SimpleMVI bruger klasser fra Kotlin Coroutines til implementering af flow: For stater og regelmæssigt for bivirkninger, der sikrer kompatibilitet med standardtilgange til reaktiv programmering i Kotlin. StateFlow Flow Praktiske udvidelser til butikken SimpleMVI giver praktiske operatører til at arbejde med intentioner: // Instead of store.accept(intent) store + MyStore.Intent.LoadData // Instead of store.accept(intent) store += MyStore.Intent.LoadData Handler - Implementering af forretningslogik Princippet om aktørarbejde Actor er den komponent, der er ansvarlig for forretningslogik i SimpleMVI. Det accepterer intentioner, behandler dem og kan producere en ny tilstand og bivirkninger. Actor er formidleren mellem brugergrænsefladen og applikationsdata. public interface Actor { @MainThread public fun init( scope: CoroutineScope, getState: () -> State, reduce: (State.() -> State) -> Unit, onNewIntent: (Intent) -> Unit, postSideEffect: (sideEffect: SideEffect) -> Unit, ) @MainThread public fun onIntent(intent: Intent) @MainThread public fun destroy() } Hver aktør har adgang til: CoroutineScope - til lancering af asynkrone operationer Funktion for nuværende tilstand (getState) Statens reduktionsfunktion (reduktion) Ny hensigt at sende funktion (onNewIntent) Sideeffekt sendende funktion (postSideEffect) Forsøg på behandling Den metoden kaldes af butikken ved modtagelse af en ny hensigt og er hovedindgangspunktet for forretningslogik. onIntent(intent: Intent) Bestemmer typen af den modtagne hensigt Udfører den nødvendige forretningslogik Opdatering af staten Genererer bivirkninger, hvis nødvendigt DefaultActor og DslActor: Forskellige implementeringsmetoder SimpleMVI tilbyder to forskellige tilgange til Actor-implementering: DefaultActor – en objektorienteret tilgang class CounterActor : DefaultActor () { override fun handleIntent(intent: CounterIntent) { when (intent) { is CounterIntent.Increment -> { reduce { copy(count = count + 1) } } is CounterIntent.Decrement -> { reduce { copy(count = count - 1) } } is CounterIntent.Reset -> { reduce { CounterState() } sideEffect(CounterSideEffect.CounterReset) } } } override fun onInit() { // Initialization code } override fun onDestroy() { // Cleanup code } } DefaultActor fordele: Den kendte OOP-tilgang Velegnet til kompleks forretningslogik Velegnet til store projekter DslActor - Funktionel tilgang med DSL val counterActor = actorDsl { onInit { // Initialization code } onIntent { reduce { copy(count = count + 1) } } onIntent { reduce { copy(count = count - 1) } } onIntent { reduce { CounterState() } sideEffect(CounterSideEffect.CounterReset) } onDestroy { // Cleanup code } } DslActor fordele: En mere deklarativ tilgang Mindre boilerplade kode Bedre egnet til små og mellemstore projekter Type-Safe Intent håndtering Begge tilgange giver den samme funktionalitet, og valget mellem dem afhænger af udviklerens præferencer og projektets specifikationer. Middleware – udvidelse af funktionalitet Formålet med Middleware Middleware i SimpleMVI fungerer som en observatør af begivenheder i butikken. Middleware kan ikke ændre begivenheder, men kan reagere på dem, hvilket gør det ideelt til implementering af tværfunktionel logik som logging, analytics eller debugging. public interface Middleware { // Called when Store is initialized public fun onInit(state: State) // Called when a new intent is received public fun onIntent(intent: Intent, state: State) // Called when state changes public fun onStateChanged(oldState: State, newState: State) // Called when a side effect is generated public fun onSideEffect(sideEffect: SideEffect, state: State) // Called when Store is destroyed public fun onDestroy(state: State) } Logging og debugging evner SimpleMVI indeholder en indbygget Middleware-implementering til logning — : LoggingMiddleware val loggingMiddleware = LoggingMiddleware ( name = "MyStore", logger = DefaultLogger ) fanger alle begivenheder i Butikken og eksporterer dem til logbogen: LoggingMiddleware MyStore | Initialization MyStore | Intent | LoadData MyStore | Old state | State(isLoading=false, data=null) MyStore | New state | State(isLoading=true, data=null) MyStore | SideEffect | ShowLoading MyStore | Destroying Dette er nyttigt til debugging, da det giver dig mulighed for at spore hele datastrømmen i applikationen. Brug af Custom Middleware Oprettelse af din egen Middleware er meget simpelt: class AnalyticsMiddleware ( private val analytics: AnalyticsService ) : Middleware { override fun onInit(state: State) { analytics.logEvent("store_initialized") } override fun onIntent(intent: Intent, state: State) { analytics.logEvent("intent_received", mapOf("intent" to intent.toString())) } override fun onStateChanged(oldState: State, newState: State) { analytics.logEvent("state_changed") } override fun onSideEffect(sideEffect: SideEffect, state: State) { analytics.logEvent("side_effect", mapOf("effect" to sideEffect.toString())) } override fun onDestroy(state: State) { analytics.logEvent("store_destroyed") } } Middleware kan kombineres, hvilket skaber en kæde af håndtere: val store = createStore( name = storeName (), initialState = MyState(), actor = myActor, middlewares = listOf( loggingMiddleware, analyticsMiddleware, debugMiddleware ) ) Vigtige anvendelsesområder for Middleware — recording all events for debugging Logging — tracking user actions Analytics — measuring intent processing time Performance metrics — visualizing data flow through UI Debugging — verifying the correctness of event sequences Testing Det er vigtigt at huske, at Middleware er en passiv observatør og ikke kan ændre de begivenheder, den modtager. Arbejde med biblioteket Installation og installation Tilføj afhængighed til dit projekt: // build.gradle.kts implementation("io.github.arttttt.simplemvi:simplemvi: ") Opret din første butik Den nemmeste måde at oprette en Store på er at erklære en klasse, der implementerer Store-grænsefladen: class CounterStore : Store by createStore( name = storeName (), initialState = State(), actor = actorDsl { onIntent { reduce { copy(count = count + 1) } } onIntent { reduce { copy(count = count - 1) } } } ) { sealed interface Intent { data object Increment : Intent data object Decrement : Intent } data class State(val count: Int = 0) sealed interface SideEffect } Brug af butikken // Creating an instance val counterStore = CounterStore() // Initialization counterStore.init() // Sending intents counterStore.accept(CounterStore.Intent.Increment) // or using operators counterStore + CounterStore.Intent.Increment counterStore += CounterStore.Intent.Decrement // Getting the current state val currentState = counterStore.state // Subscribing to the state flow val statesJob = launch { counterStore.states.collect { state -> // Useful work } } // Subscribing to side effects val sideEffectsJob = launch { counterStore.sideEffects.collect { sideEffect -> // Processing side effects } } // Releasing resources counterStore.destroy() Støtte til flere platforme SimpleMVI understøtter forskellige platforme via Kotlin Multiplatform: af Android IOS af macOS Vask JS Brug af platformspecifikke kodeisoleringsmekanismer : expect/actual // Common code public expect fun isMainThread(): Boolean // Android implementation public actual fun isMainThread(): Boolean { return Looper.getMainLooper() == Looper.myLooper() } // iOS implementation public actual fun isMainThread(): Boolean { return NSThread.isMainThread } // wasm js implementation public actual fun isMainThread(): Boolean { return true // JavaScript is single-threaded } Logging implementeres på samme måde for forskellige platforme: // Common code public expect fun logV(tag: String, message: String) // Android implementation public actual fun logV(tag: String, message: String) { Log.v(tag, message) } // iOS/wasm js implementation public actual fun logV(tag: String, message: String) { println("$tag: $message") } Eksempler på: Counter Definition af Big Data Model class CounterStore : Store { // Intents - user actions sealed interface Intent { data object Increment : Intent data object Decrement : Intent data object Reset : Intent } // State data class State( val count: Int = 0, val isPositive: Boolean = true ) // Side effects - one-time events sealed interface SideEffect { data object CounterReset : SideEffect } } Stor gennemførelse class CounterStore : Store by createStore( name = storeName (), initialState = State(), actor = actorDsl { onIntent { reduce { copy( count = count + 1, isPositive = count + 1 >= 0 ) } } onIntent { reduce { copy( count = count - 1, isPositive = count - 1 >= 0 ) } } onIntent { reduce { State() } sideEffect(SideEffect.CounterReset) } } ) { // Data model defined above } Tilslutning til UI (Android eksempel) class CounterViewModel : ViewModel() { private val store = CounterStore() init { // Built-in extension for automatic lifecycle management attachStore(store) } val state = store.states.stateIn( scope = viewModelScope, started = SharingStarted.Eagerly, initialValue = store.state ) val sideEffects = store.sideEffects fun increment() { store.accept(CounterStore.Intent.Increment) } fun decrement() { store.accept(CounterStore.Intent.Decrement) } fun reset() { store.accept(CounterStore.Intent.Reset) } } Avancerede funktioner Bibliotekskonfiguration SimpleMVI giver et fleksibelt konfigurationssystem: configureSimpleMVI { // Strict error handling mode (throws exceptions) strictMode = true // Logger configuration logger = object : Logger { override fun log(message: String) { // Your logging implementation } } } Forkerte håndteringsmetoder strictMode = sandt - biblioteket fungerer i streng tilstand og kaster undtagelser, når der opdages fejl strictMode = falsk (standard) - biblioteket fungerer i langsom tilstand og logger kun fejl uden at afbryde udførelsen Fejl i håndteringen SimpleMVI har særlige undtagelser: NotOnMainThreadException - når du forsøger at kalde Store-metoder ikke fra hovedtråden StoreIsNotInitializedUndtagelse - når du forsøger at bruge en uinitialiseret butik StoreIsAlreadyDestroyedException - når du forsøger at bruge en allerede ødelagt butik Test af komponenter Takket være den rene adskillelse af opgaver er SimpleMVI-komponenter nemme at teste: // Example of Store testing @Test fun `increment should increase counter by 1`() { // Arrange val store = CounterStore() store.init() // Act store.accept(CounterStore.Intent.Increment) // Assert assertEquals(1, store.state.count) assertTrue(store.state.isPositive) // Cleanup store.destroy() } Konklusionen Som mobiludvikling bliver stadig mere kompleks og kravene til kodekvalitet og applikationsvedligeholdelighed vokser, bliver valget af den rigtige arkitektur en afgørende beslutning. SimpleMVI tilbyder en moderne, elegant tilgang til kodeorganisation baseret på MVI-mønsterprincipper og tilpasset til multiplatformudvikling med Kotlin. De vigtigste fordele ved SimpleMVI For at opsummere kan følgende styrker i biblioteket fremhæves: Minimalistisk og pragmatisk tilgang SimpleMVI leverer kun de nødvendige komponenter til implementering af MVI-mønsteret, uden unødvendige abstraktioner og kompleksiteter. Biblioteket følger princippet om "enkelhed frem for alt", hvilket gør det nemt at forstå og bruge selv for udviklere, der lige er blevet bekendt med MVI-arkitektur. Full Kotlin multiplatform support SimpleMVI er bygget på Kotlin fra bunden og er optimeret til multiplatformudvikling. Biblioteket isolerer platformspecifik kode gennem forventnings-/virkelige mekanisme, hvilket sikrer kompatibilitet med Android, iOS, macOS og wasm js. Forudsigelig statsforvaltning Strengt overholdelse af principperne om statens uforanderlighed og unidirektionel datastrøm gør applikationer bygget på SimpleMVI mere forudsigelige og mindre fejlbevidste. Indbygget beskyttelse mod almindelige problemer Biblioteket giver streng trådsikkerhedskontrol, der sikrer, at interaktion med status kun forekommer på hovedtråden. Praktisk DSL til deklarativ logisk beskrivelse Takket være DSL-understøttelse giver SimpleMVI mulighed for at beskrive forretningslogik i en deklarativ stil, hvilket gør koden mere læsbar og forståelig. Fleksibilitet og udvidelighed På trods af sin minimalistiske tilgang giver SimpleMVI mekanismer til at udvide funktionaliteten gennem Middleware-systemet. Dette gør det nemt at tilføje funktioner som logging, analytics eller debugging uden at påvirke kerneforretningslogikken. Typiske brugstilfælde SimpleMVI er særligt velegnet til følgende scenarier: Kotlin multiplatform projekter Hvis du udvikler en applikation, der skal arbejde på flere platforme (Android og iOS, webapplikationer), giver SimpleMVI dig mulighed for at bruge en enkelt arkitektonisk tilgang og delt forretningslogik kode. Applikationer med komplekse statlige og brugerinteraktioner For applikationer, der håndterer komplekse tilstande og håndterer talrige brugerinteraktioner, giver MVI-tilgangen en klar struktur og forudsigelighed. Projekter med vægt på testbarhed Takket være en klar adskillelse af ansvarsområder mellem komponenter og forudsigelige datastrømme er applikationer bygget med SimpleMVI nemt enhedstestbare, hvilket gør biblioteket til et fremragende valg for projekter, hvor kodekvalitet og testbarhed er en prioritet. Migration af eksisterende projekter til MVI-arkitektur SimpleMVI kan indføres gradvist, begyndende med individuelle moduler eller funktioner, hvilket gør det velegnet til gradvis migration af eksisterende projekter til MVI-arkitektur. Uddannelsesprojekter og prototyper På grund af sin enkelhed og minimalisme er SimpleMVI velegnet til undervisning i MVI-principper og til hurtig prototyping. Ressourcer til yderligere læring For dem, der ønsker at uddybe deres viden om SimpleMVI og MVI arkitektur generelt, anbefaler jeg følgende ressourcer: SimpleMVI GitHub repository – kildekode for biblioteket med eksempler på brug SimpleMVI-dokumentation – officiel dokumentation med detaljerede API-beskrivelser og anbefalinger Afsluttende tanker SimpleMVI repræsenterer en afbalanceret løsning til at organisere applikationsvirksomhedslogik ved hjælp af moderne tilgange til arkitektur. Biblioteket tilbyder en klar struktur og forudsigelig datastrøm uden at pålægge unødvendig kompleksitet. Når du vælger en arkitektur til dit projekt, skal du huske på, at der ikke er nogen universel løsning, der passer til alle tilfælde. SimpleMVI kan være et fremragende valg for projekter, hvor enkelhed, forudsigelighed og multiplatform support værdsættes, men for nogle scenarier kan andre biblioteker eller tilgange være mere hensigtsmæssige. Eksperimentér, udforsk forskellige arkitektoniske løsninger og vælg, hvad der passer bedst til dit projekt og dit team. Og husk: Den bedste arkitektur er den, der hjælper dig med at løse opgaverne effektivt, ikke den, der skaber yderligere kompleksitet.