Binding to a table view with multiple cells and sections

One of the questions that keeps popping up in the RxSwift Slack channel for years now is how to display multiple cell types when binding data to a table view. This is actually very easy to do and in this post I’ll show you two distinct ways to display multiple cells in a table view (and it works identically for collection views if that’s what you’re looking for). We’ll look at the following two use cases:

Testing with RxBlocking, part 2

Previously, I wrote about the basics of testing with RxBlocking in Testing with RxBlocking, part1. Since then, I presented 2 times at meetups about MVVM and RxBlocking and I thought I’d post few more examples in a broader context. But first a question I got several times already when discussing RxBlocking. When to use RxBlocking vs. RxTest? RxTest is a great library for testing RxSwift code. It offers everything you need to test your Rx code and in most cases it’ll be everything you need.

Testing with RxBlocking, part 1

Whenever you decide to test your Rx code you have not one but two excellent choices - RxTest and RxBlocking. In this blog post I’ll go over the RxBlocking API and explain shortly how does the libary work. In Part 2 I’ll go over a bunch of real-life examples from open source I’ve written. Testing with RxTest pod RxTest to install it to your test suite from I’ve already written in the past about RxTest and few people have thanked me personally for shading some light on its usage, so if you’re interested head to the original article and read through: Testing your RxSwift code, part1.

observeOn vs. subscribeOn

Cross-thread subscriptions is a question that seems to pop up again and again on the RxSwift Slack channel. The explanation is very simple so I thought it was a good idea to put it in a blog post so whenever needed I can link to it instead of typing everything again and again. Observable subscriptions The terminology in regard to subscribing and observing is imho a bit messy so let’s first take this out of the way (do not skip this section!

Introducing RxAnimated

RxCocoa is super powerful for UI bindings - you can use bind(to:) to bind pretty much any kind of observable to a UI Control of your choice. You can bind a String to a UILabel, UIImage to a UIImageView, or an array of objects to UITableView or UICollectionView. Now, for table and collection view bindings there is a special library to allow you to bind a list of objects called RxDataSources and besides all the other goodness the library can add animations to your bindings.

Custom property bindings with RxSwift

Recently, in one of the few meetups I’ve been in person to, someone told me the didn’t try RxSwift because somebody told them that RxSwift doesn’t support custom views. While I’m still baffled what that original person meant, I thought the best way to disagree is to write a short tutorial to prove them wrong. What are custom property sinks? When you use RxCocoa bindings you can easily bind the values an observable emits to some view on screen like so:

combineLatest beyond the basics

In the last couple of weeks I got to talk to few people who were either still struggling to understand what exactly does combineLatest do or didn’t know about a more recent power feature. So here it is … a post about combineLatest! What does the combineLatest operator do? combineLatest is super useful and it was the first thing in RxSwift that really made see how powerful Rx is and showed me what kind of problems can be easily solved with RxSwift.

(dotSwift) Unidirectional data flow with RxSwift and RxRealm

In my talk at dotSwift 2017 I start with generic overview of some of the RxSwift basics and move to three complete code examples. In three posts I post the sample code and comment shortly why I chose to highlight these exact examples. I already posted a write up on the GitHub API search example here: The second post in the series, the one about presenting view controllers, is online here: http://rx-marin.

(dotSwift) Presenting View Controllers with RxSwift

In my talk at dotSwift 2017 I start with generic overview of some of the RxSwift basics and move to three complete code examples. In three posts I’ll post the sample code and comment shortly why I chose to highlight these exact examples. I already posted a write up on the GitHub API search example here: Let’s continue with example number two. Presenting a View Controller from RxSwift RxSwift doesn’t neccessarily force you into one architecture or another, it’s really up to you to chose how are you going to structure your application.

(dotSwift) Search GitHub with RxSwift

In my talk at dotSwift 2017 I start with generic overview of some of the RxSwift basics and move to three complete code examples. In three posts I’ll post the sample code and comment shortly why I chose to highlight these exact examples. Let’s start with number one. Searching for GitHub repositories with RxSwift The first example in the talk is a simple single-screen application that allows the user to enter a repository name (or part of it) and search GitHub for matching results.

A smarter Retry with RxSwiftExt

Sometimes your observable will fail with an error but that would not mean that you need to give up trying. For example saving to a file might fail because the file is locked temporarily but a split second later would be unlocked and ready for your changes. Same goes for web requests - there might be a temporary glitch in connectivity which could make the observable fail. RxSwift offers a special operator called retry, which allows you to try another time the observable subscription upon error.

Testing your RxSwift code, part 2

In part 1 I looked into writing very basic tests with RxSwift and life was good. But then I wanted to do more and moved on to writing asynchronous tests… I contributed the code for RxRealm - the Rx extension for RealmSwift owned by the RxSwiftCommunity. For RxRealm I needed some asynchronous tests because Realm’s collections emit notifications (which RxRealm wraps) when the underlaying data changes. So let’s have a look at some of the unit tests I wrote…

Testing your RxSwift code, part 1

I sat down recently and learned the basics of writing unit tests for RxSwift. It was way easier than I expected and that’s why I’d like to show few of the tests I got to write. Before I start on the code itself I just want to mention how great contributing to open source is. If I didn’t jump in to helping around on the RxSwift-Ext project I’d probably haven’t looked into writing unit tests with RxSwift yet, but I did - and that’s great.

App state with Realm and RxSwift

Intro This post isn’t that much about operators but how to leverage the awesome technology that Realm is. Long story short - I wanted to submit an app for review and literally just before hitting submit I realized I forgot to implement a favorites filter in one of the view controllers. I would’ve quickly hacked something to send it off but since different controllers took care of the navigation bar and the actual table view showing the data could not hack my way around.

Implementing state with scan in RxSwift

Intro Common misconception is that you cannot have state with Rx. Well you can - and there’s a special operator that helps you to: scan. If you’ve ever used reduce in Swift - scan is a very similar operator but reduce goes over the complete sequence and gives you the final value of the accumulator while scan emits each intermediate value as well. If you haven’t used reduce - no worries you’ll get to understand scan from the examples below.

Custom bindings with RxSwift

Intro After I did some convenience operators of my own, which really made things easier while writing code I thought I’d be a good idea to look into building more stuff on my own. It helps learning and it’s healthy :) Binding to make a view visible I noticed there is a binding on the hidden property of UIView but sometimes the code just reads better when you don’t have to think of hiding something but rather showing something.

Custom convenience operators with RxSwift, Part 2

Intro I got some great feedback on last week’s post on convenience operators part 1 so I’m really excited to publish part 2, which I hope will be even more interesting for those of you who are looking into RxSwift. Without further ado let’s dive in code… A better negate() operator First of all I have a better version of my negate() operator from last week for you. What I wrote on my own was a pretty simple function that looked like so:

Custom convenience operators with RxSwift, Part 1

Intro Just like when learning a new language you need to build up a dictionary to start understanding how the language works, you got to learn the Rx operators and everything will eventually click together. And then once you have a good common of a language it’s okay to start coming up with new words too to boost the expressiveness of your speech and for convenience. Same thing happened with me last week - for the first time I felt like I’m getting work done with RxSwift because I had good understanding how to use at least few operators.

Split laps timer with RxSwift and RxCocoa: Part 2

In my post from last week I worked on creating a split lapse timer app (last week’s post). But later on when I was playing with the application I noticed that I naturally would like to have means to start or stop the timer.

Well this week I am implementing exactly this functionality.

The first thing I thought about was how to implement state in my app because a timer clearly has two distinct states either running or not running. That got me thinking about combining signals, mapping, you know, all the good stuff.

If you want to follow along you can download the starter project I prepared. It is in the shape where last weeks blog posts leaves off but I’ve added a couple of buttons in the user interface:

Download the starter project to follow along here:

Now let’s put all those buttons to work!

Split laps timer with RxSwift and RxCocoa

I was browsing through RxMarbles and was totally baffled by the sample function. The marble diagram looks pretty random at first sight:

At first I thought - “Hey, that second sequence is getting totally ignored!”. But after I read the description I figured it out:

The first sequence’s elements is what sample emits, while the second sequence’s elements determine when sample emits. So in a way yes - the actual values A, B, C, D do get totally ignored.

When it was clear to me what sample does I started wondering if this function has any practical application :]

This brought me to creating a split lap timer app to test what sample can do for me. In the finished project I have a timer emitting time values (aka the first sequence) and I want to grab (or sample) the values whenever the user taps a button (aka the second sequence).

Here’s how the marble diagram looks like for the app setup:

And this is how the app looks like when finished:

Let’s build that app :]

Manually disposing a bag and creating a timer

I was reading through the RxSwift docs and did a little test to see if I understood manual disposing. As the example made a lot of sense I thought it’s not a bad idea to share it online.