These days, I’ve been working on a feature like implementing sign up form detail pages which I don’t want to write into database until the flow is complete. Yet I use MVVM pattern for my project which of course is a quite simple and clean architecture, accumulating intermediate state like this leads to singleton abuse and other problems.

These arise from multiple copies of the state and if you allow your app to navigate back-and-forth, then you have to make sure that the latest state in the latest view controller is available in other view controllers as well. Maintaining the state across all of your controllers that are involved through delegation or callbacks becomes messy. I suppose that kind of problem is quite common among iOS developers.

In this case, I chose to integrate Unidirectional Data Flow (Redux) approach with MVVM in my implementation. In the post, I try to explain work flow of unidirectional data flow(redux) and how we can use it for time traveling of state in our app. Woo hoo! Let’s start… .

Unidirectional data flow is an essential feature for working with the web-based applications.

The reason data flows from top to bottom is that change detection strategies are also always performed from top to bottom for every single component, every single time, starting from the root component. This is awesome, as unidirectional data flow is more predictable than cycles.

So What is Redux and how does it work?

Redux is an alternative or a variation of the flux framework that was developed at Facebook, and that Facebook now uses for most of their web applications. The main idea is that information always only flows in one single direction.

Let’s break down a bit what each component does for our implementation, shall we…

• Views: Subscribe to Store changes and display them on screen. Views send Actions.
• Actions: Actions don’t contain any code and are small pieces of data that describe a state change. An Action is manipulated by a Reducer.
• Reducers: Provide pure functions that based on the current action and the current app state, and return a new app state.
• Store: Stores the current value of the application state. Other modules like Views can subscribe and react to its changes.

In this article, I’ll use Reswift to implement unidirectional data flow. Reswift is a framework that helps you create Redux-like architecture in swift.

We are going to create an application which fetch popular movie list from network api and include a feature like searching movies. And then we will fetch the search history from redux store after that.

1. First we will need to set up wiring of ReSwift starting from creating states.

State is actually a data structure and contains substates like a navigationState (e. g. which view is currently active) and commonly one for each view of your app. In this example, only one AppState contains which involves two substates for 2 views.

2. We also define two actions, one for adding search result to the store and one for fetching search history according to search keyword.

3.Reducer will be notified by the store to return new states depending on difference action types.

In order to have a predictable app state, it is important that the reducer is always free of side effects, it receives the current app state and an action and returns the new app state. Then we wrap our reducers into a main reducer so we can inject into the store all at once.

To maintain our state and delegate the actions to the reducers, we need a store. Let’s call it mainStore and define it as a global constant, for example in the app delegate file:

var mainStore = Store<AppState>(reducer: appReducer, state: ni

Before the final step, we need to extend StoreSubscriber at our view so the newState method will be called by the Store whenever a new app state is available. This is where we need to adjust our view to reflect the latest app state.

We all set up. Let’s throw the action dispatch calls, Woo hoo!…

Lastly, our view layer, in this case a view controller, needs to tie into this system by subscribing to store updates and emitting actions whenever the app state needs to be changed:

As a final result, we can see time traveling ability which help to move back and forth among the previous states of the application and view the results in real time.

Hope you found this post interesting and useful for your projects. Any question or comment will be welcome!

Reference Links

• GitHub - ReSwift/ReSwift: Unidirectional Data Flow in Swift - Inspired by Redux
• Using Redux with MVVM on iOS
• Getting started with Redux in Swift - Part 1
• ReSwift Tutorial: Memory Game App

The Unidirectional Data Flow and Time Traveling of States in iOS was originally published in Dev Genius on Medium, where people are continuing the conversation by highlighting and responding to this story.

Say we have a small code base and includes some codes that fetch data from API and maps into the data model objects. And we also use design pattern like MVP for structuring our project. Aight!… everything is perfect, clean and smooth till now, right? But then suddenly our codebase starts to grow, and you need to write the code to fetch the books over and over again. You might say “let’s copy the code and paste it wherever you need to fetch all the data.”

What if you can provide a single-entry point to work with your models and remove duplicate query code. Here is where “The repository pattern” comes in… .

Hello Repository…

Repository pattern is a software design pattern that provides an abstraction of data, so that your application can work with a simple abstraction that has an interface. We can assume it as an object that encapsulates all the code to query your models in one place. By adding an abstraction layer over the top of database APIs, we can achieve loose coupling and can keep domain objects persistence ignorant.

So, Let’s see how we can integrate repository pattern with generics in an iOS Application. Below, you can take a look at a brief architecture of the application which I don’t suppose it’s a complete one but using this approach will make your app development a lot easier for unit testing.

1. We create generic protocol so that it can be used for any model object we have.

protocol Repository {
 associatedtype T
 func getAll() -> [T]
 func getById(id: Int) -> T
 func create(newData: T) -> Bool
 func update(id: Int, newData: T) -> Bool
 func deleteById(id: Int) -> Bool
}

2. Then we can infer the type of T to any type of repository object, because by implementing the methods, we have specified what T is. In this case Book object.

class RemoteRepository: Repository{

   let remoteDataSource: RemoteDataSource

   init(dataSource: DataSource){
        self.remoteDataSource = dataSource
   }

    func getAll() -> [Book] {
        return remoteDataSource.getAll()
    }
    
    func getById(id: Int) -> Book {
        return remoteDataSource.getById(id)
    }
    
    func create(newData: Book) -> Bool {...}
    
    func update(id: Int, newData: Book) -> Bool {...}
    
    func deleteById(id: Int) -> Bool {...}
}

3. Data and Networking Layer

//Networking layer
class BookStoreApi{
  class func saveNewBook(book: BookRequest){

    // save new book data to Server using Alamofire/UrlSession          

    Alamofire.request(...) 
 }

  class func getAllBooks() -> Observable<Book> {
    // get all books from Server using Alamofire/UrlSession ...
  }
}

//Data layer
class RemoteDataSource{
 class func getBookData() -> Observable<Book> {
        // return an Observable BookData from Server
    }
    
    // Saves the Observable data into Remote Server
    class func saveBookData(_ data: Book) {
        // ...
    }
}

BookListViewModel holds references of repositories and communicates with the BookListViewController when needed. Finally, in your view controller you can update your UI with the fetched data.

When and why we use repository pattern in our code base?

Repository Pattern is highly useful when you need to work parallel with different data sources such as Remote, Local and Cache. It is also architecturally useful when it comes to Separation of Concerns Principle. It makes your program testable and flexible.

When it becomes overkill feature?

Though using repository pattern has loads of benefits, there are also couples of considerations to be aware of before overusing it.

This is ‘pre-emptive work’. You’re doing a lot of work up front, just in case you might change your mind down the line. Trying to architect a ‘generic’ database solution which you may never end up using sounds like it might not pay off.

You’re increasing app complexity. This means more potential for bugs and more rigorous testing would be needed to make sure your API and the database API are in sync.

As long as the new database you’d be moving to consists of managing objects as well (ie Core Data), converting from one database to another isn’t usually a lot of work. As such, I’d recommend avoiding unnecessary work until the time when it becomes necessary.

Recap

Although extra layer of abstraction can lead unnecessary complexity for the development, adding a layer over the top of database APIs is pretty common. In order to hide the API from their business logic code, most developers usually wrap data layer with their own classes.

Hope you found this post interesting and useful for your projects. Any question or comment will be welcome!

Reference Links

https://medium.com/@frederikjacques/repository-design-pattern-in-swift-952061485aa

https://medium.com/tiendeo-tech/ios-repository-pattern-in-swift-85a8c62bf436

https://medium.com/swlh/theoretical-usage-of-repository-pattern-with-rxswift-and-mvvm-a3dfebb940ce

https://www.infoworld.com/article/3117713/design-patterns-that-i-often-avoid-repository-pattern.html

iOS: Hello Repository… was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.