Forem: Jakub Turek

RxSwift workshops

Jakub Turek — Tue, 03 Sep 2019 09:37:29 +0000

Do you want us to run a professional RxSwift training in your company? Contact us at projects@elpassion.com.

The mobile team at EL Passion is very enthusiastic about reactive programming. The reactive approach helps us build the apps thinking about the functionalities, not about technical matters of keeping the internal state in sync.

In fact, we use reactive programming so extensively that we'd decided to share the knowledge with others. We've held two editions of RxSwift workshops during which we've mentored almost 40 iOS developers through their first steps with the framework and reactive programming in general!

Content

The workshop was aimed towards people who are familiar with iOS development but never had a chance to try RxSwift. It was divided into three modules:

Introduction to Functional Reactive Programming and basic RxSwift operators.
UI bindings with RxCocoa.
Reactive networking.

Each module consisted of a theoretical introduction in form of the presentation and a set of the practical exercises focused on implementing the most common tasks in the reactive fashion.

Agenda

9:00 - 9:30 Project setup
9:30 - 11:30 FRP and basic RxSwift operators
11:30 - 12:00 Coffee break
12:00 - 14:00 UI bindings in RxCocoa
14:00 - 15:00 Lunch break
15:00 - 17:00 Reactive API calls
17:00 - 17:15 Experiences & closing thoughts

Attendees' reviews

Review #1:

I've visited EL Passion during the RxSwift training. I work in software development for over 15 years, and I have to admit that I've never seen such a well-organized workshop ran free of charge. I was impressed by how professional the whole organization had been.

Review #2:

Thanks to iOS team for professional and well prepared RxSwift workshop.

Review #3:

I took part in RxSwift training ran by EL Passion. Very substantive workshops, great preparation and held in a nice atmosphere.

You can read more reviews on our Facebook page.

Pictures

Pictures

Check out more pictures at our Facebook page.

License

Paginated list with animated updates (RxFeedback, RxDataSources)

Jakub Turek — Mon, 02 Sep 2019 11:14:56 +0000

RxSwift is an amazing framework that streamlines all of the event handling in the iOS apps and makes them less prone to state related issues. RxSwift simplifies data updates from sources such as the local database, HTTP services or websockets.

At EL Passion we love using RxSwift. In fact we ❤️ it so much that we've held the two editions of the RxSwift workshop for iOS developers.

However, there are some cases where pure RxSwift is not always enough. For example paginating API results requires parts of explicit state management. That's why RxFeedback architecture came to life. It helps modelling system-level interactions with RxSwift abstractions.

In the showcase we present how we've built the paginated list with animated updates in approximately 100 lines of code for our Client.

Case study

The case study comes 100% from a real app built for one of the EL Passion's Clients. You can see it in action below:

Case study

View models

The app's been built using the MVVM architecture. Every collection cell has it's own view model assigned:

class ModelListItemViewModel: IdentifiableType, Equatable {
    init(model: Model) {
        self.model = model
    }

    // MARK: - Public API

    var image: Driver<UIImage> { /* ... */ }
    var author: Driver<String> { /* ... */ }

    // MARK: - IdentifiableType

    var identity: String {
        return model.id
    }

    // MARK: - Equatable

    public static func == (lhs: ModelListItemViewModel, rhs: ModelListItemViewModel) -> Bool {
        return lhs.model == rhs.model
    } 

    // MARK: - Private

    private let model: Model
}

In order to get the nicely animated updates with near-zero development cost, the app uses RxDataSources library. That's why the view model conforms to both IdentifiableType and Equatable types.

The collection view has a single section modelled as a list of items:

struct ModelSectionViewModel {
    var items: [ModelListItemViewModel]
}

extension ModelSectionViewModel: AnimatableSectionModelType {
    init(original: ModelSectionViewModel, items: [Item]) {
        self = original
        self.items = items
    }

    var identity: String {
        return String(describing: ModelSectionViewModel.self)
    }
}

RxFeedback

In order to build pagination with RxFeedback you need to define:

state structure,
possible events enum,
reduce function which converts the current state and the event to the new state,
system description with a list of feedback loops.

State

The state consists of already downloaded models and the next page offset. It also holds a flag to tell whether we should start downloading the next page.

struct ModelListState: Equatable {
    let models: [Model]
    let nextPageOffset: Int?
    let shouldLoadNextPage: Bool

    init(models: [Model] = [], nextPageOffset: Int? = 0, shouldLoadNextPage: Bool = true) {
        self.models = models
        self.nextPageOffset = nextPageOffset
        self.shouldLoadNextPage = shouldLoadNextPage
    }
}

Possible events

Scrolling the list toggles scrolledTo(item:) event. There're also 2 types of events to handle API responses (success & failure).

enum ModelListEvent {
    case scrolledTo(item: IndexPath)
    case response(page: ModelPage)
    case error
}

Reducer

Reducer handles the events as follows:

scrolled to an item event - it flips shouldLoadNextPage flag to true when user scrolled down to the bottom item,
next page response - it appends the models, updates the next page offset and stops fetching the next page.
error - it stops fetching the next page.

extension ModelListState {
    static func reduce(state: ModelListState, event: ModelListEvent) -> ModelListState {
        switch event {
        case let .scrolledTo(indexPath):
            return reduceLoadNextPage(item: indexPath.item, state: state)
        case let .response(page):
            return ModelListState(
                models: state.models + page.models,
                nextPageOffset: page.nextPageOffset,
                shouldLoadNextPage: false
            )
        case .error:
            return ModelListState(original: state, shouldLoadNextPage: false)
        }
    }

    var fetchOffset: Int? {
        return shouldLoadNextPage ? nextPageOffset : nil
    }

    // MARK: - Private

    private static func reduceLoadNextPage(item: Int, state: ModelListState) -> ModelListState {
        guard !state.shouldLoadNextPage, item + 1 >= state.models.count else {
            return state
        }

        return ModelListState(original: state, shouldLoadNextPage: true)
    }
}

Feedback loop

There are 2 feedback loops defined:

UI feedback loop - it wires sections' view models to the collection view and receives scroll to item events,
react feedback loop - it triggers fetching the next page when fetchOffset property is present for the page.

/// Signal called on will display cell event
let willDisplaySubject: PublishSubject<IndexPath>

/// Observable list of sections that drive UICollectionView
let sectionsRelay: BehaviorRelay<[ModelSectionViewModel]>

/// Creates a view model for a single list item from the API data
let itemViewModel: (Model) -> ModelListItemViewModel

/// Downloads a single page of results from the API
let listProvider: (Int) -> Single<ModelPage>

/// Maps state updates into events stream
let bindings: (Driver<ModelListState>) -> Signal<ModelListEvent> = bind(self) { me, state in
    let sectionSubscription = state
        .map { $0.models.map { me.itemViewModel(for: $0) } }
        .map { [ModelSectionViewModel(items: $0)] }
        .drive(me.sectionsRelay)

    let displayCellEvent = me.willDisplayCellSubject
        .map { ModelListEvent.scrolledTo(item: $0) }
        .asSignal(onErrorJustReturn: .error)

    return Bindings(subscriptions: [sectionSubscription], events: [displayCellEvent])
}

/// Models whole pagination subsystem
Driver.system(
    initialState: ModelListState(),
    reduce: ModelListState.reduce,
    feedback: bindings,
    react(query: { $0.fetchOffset }, effects: { [listProvider] offset in
        listProvider(offset)
            .map { ModelListEvent.response(page: $0) }
            .asSignal(onErrorJustReturn: .error)
        })
    )
.drive()
.disposed(by: disposeBag)

License

VinylShop mobile app

Jakub Turek — Mon, 02 Sep 2019 11:10:24 +0000

Our iOS team at EL Passion wanted to know what it takes to put our designers' work into motion. We've challenged ourselves to build demanding shots while retaining our trademark high code quality.

One of the outcomes is the Vinyl Shop mobile app by @MatPrzegietka implementation.

Dribbble shot	Implementation

Swift 4.2
Unit test code coverage: 100%

Source

License

SwiftLint config per target

Jakub Turek — Mon, 02 Sep 2019 11:07:19 +0000

EL Passion ❤️ open source.

In our mission to deliver the highest quality product possible, the iOS team at EL Passion rely on linting tools such as SwiftLint to fix common code structuring & formatting issues.

However, there are some scenarios in which we can't easily employ the tooling to work for us. We've encountered this issue when developing VinylShop mobile app with the following directory structure:

Project /
├── Project.xcodeproj
└── Sources /
    └── Controllers /
       └── Login /
           ├── LoginViewController.swift
           └── LoginViewControllerSpec.swift

We couldn't easily configure SwiftLint to use a different configuration for the production and for the test files.

SwiftLint runner

Fortunately, we've been able to fix the issue by implementing a simple Python script which reads the contents of the .pbxproj file and modifies the included files in the SwiftLint config prior to the linting. The script is divided into the two simple files:

lint.py,
xcproj.py.

What's even better is that we've released the script as the PyPI package, so you can use it in your own projects, too. It's as simple as running:

pip install swiftlint-runner

And adding an appropriate build phase:

slrunner <project_name>.xcodeproj <target_name> .<swiftlint_config_file_name>.yml

You can find more details at the elpassion/swiftlint-runner repository.

License

SwiftLint runner is maintained with ❤️ by EL Passion and released under an MIT license.