All apps today need at some point to talk to a remote resource like a server or database. These are async operations, meaning they get executed on a secondary thread and return at some later time on the main thread.
Let’s say we want to connect to such a remote resource in order to fetch details about a certain movie. The model we want to get back is this:
And — to keep in line with functional code we’ve used in the past — we’re going to write a function to return that model with the help of a…
In a previous article on Redux in Swift we saw how we can build a really basic counter app using SwiftUI and Redux, from scratch.
Here’s the UI code we ended up with:
SwiftUI and Redux work really well together and the benefits are immediate: the declarative syntax helps with readability and the strict unidirectional data flow makes code easier to test and reason about.
However, SwiftUI is still new and everyone’s still exploring different ways of using it to change their codebases for the better.
We’ve recently unveiled our plans for Rukkaz: a video platform designed for family creators, responsible advertisers and kids. Rukkaz is built with privacy-by-design and safe community as first principles (we talked about our guiding principles in an earlier post).
While developing Rukkaz natively for iOS and Android we realised we were writing the same functionalities twice, sometimes with different outcomes and inconsistencies across the platforms, resulting in loss of time, as well as headaches for the team.
In my previous series of articles I explored how to implement the Redux pattern in Kotlin, on Android. The reality is that the same can be applied in Swift, on iOS, without much hassle.
Of course, there are already a few libraries out there that implement a unidirectional data flow. One that I’ve tried is ReSwift. But the good thing about Redux is that it’s pretty simple to implement and thus you can easily roll out your own version, one that’s better suited to your needs.
This is the second article in a series about implementing the Redux pattern in Kotlin.
In the first part we built all of the main Redux entities that help power a simple counter app from the ground up.
That’s a really convenient way of getting into thinking about State, Reducers, unidirectional data flow, etc, but it’s not as useful as a real world example. With that I mean code that more closely resembles what we’d write on a day to day basis. …
During my past two articles we saw how we can look at views as a function of state and how we can decouple our application’s business logic from the views themselves in order to create more modular and SOLID code.
Throughout those articles, I mentioned Redux quite a lot — and how it inspired me to think about views as local stores of some state. That’s no accident. In the past few years, Redux has been fundamental about changing the way I think about big front-end systems and has been my default tool for making sense and simplifying complicated problems.
In my previous post I showed how we can structure our Views so that they’re easier to reason about and more deterministic by thinking about them as a function of state. I did that by ensuring two things:
First, the View’s own state — text draw on screen, selected buttons, loaded images — only gets updated through a redraw method.
Second, the View only interacts with the outside world through an Interactor.
That’s already a huge step up, in my opinion.
There’s room to improve even further, though, if we think about the number of responsibilities the view has.
One of the more interesting changes that has happened in the last few years is the appearance of state management libraries like Redux, Flux or MobX. This has generated a healthy debate amongst developers about — essentially — how to best make sense of the ever growing complexity in software.
Redux & co are there to help you make sense and cut down the complexity that arises from state and state changes. Redux specifically does that by enforcing a few simple rules:
At the heart of most modern applications sits some type of data layer. It’s there to help us connect to the network and get new information, store information locally or allow the user to send information to the cloud.
From the onset we can see that there’s a lot of weight placed on getting the data layer right.
But what does right mean? There’s probably as many answers as there are people, but for me it boils down to three key pillars:
Enthusiast of all things mobile and functional. Building a safer internet for kids as Engineering Lead @SuperAwesome.