Creating a cold signal in ReactiveCocoa 7

For any case, there is an arbitrarily complex way to do it.

This prints “HELLO WORLD!”.

AppCode vs XCode

AppCode has features that are not present in Xcode. At a minimum, AppCode will be a good addition to XCode.

The full list of features is here.

Here I will show examples of using AppCode features. Inspired by this article, that was very usefull for me.

1. Quick Fix feature in AppCode is more convenient. Refactoring to Modern Objective C syntax using Quick Fix (Alt + Enter).

Before:

After:

2. Simplifying expressions using Quick Fix.
Before:

After:

3. AppCode can generate code for you. Use Command + N.
Generated code – isEqual and hash methods for a class that has properties – objectID, name, selected:

Description method generated for a class with many properties:

4. Imports do not block other code and are folded. Typos in names are shown and renaming works better than in XCode.
These are small features, but very useful. Here defered should be renamed to deferred.

5. Unused imports and properties are shown.
XCode doesn’t do that.

6. Scroll from source feature in project navigator.
You can open a source file by name as in XCode, but after that you can also navigate to that source file in a project tree in one click.

Updating View With Two Data Sources in iOS

In this article I am going to describe a robust, simple and clean app architecture that allows to update a single iOS tableView from two different data sources asynchronously.

Let’s say, we have two sources of data, that need to be displayed in a tableView. When user pulls to refresh a tableView, two separate asynchronous requests are performed. While updating continues we need to show activity indicator and we can dismiss it only when both requests are finished.

This can be cleanly accomplished using ReactiveCocoa + MVVM. One of the benefits of ReactiveCocoa is in the easiness of synchronization of asynchronous data streams.

One would say, that this task can be also performed by using of dispatch groups. I agree, but it is more complex and not easy to do when the nature of data sources is different. For example, when one of the datasources is HTTP API and the second is a WebSocket.

Architecture looks like this:

In a ViewModel we have 3 arrays – cloudData1 (or any other name you want, that better describes your domain), cloudData2 and a union single datasource of a TableView – tableData. When cloudData1 or cloudData2 updates, the update of tableData is triggered and then it triggers an update of the TableView itself by bindings.

In the init method of a ViewModel we create a binding of cloudData1 and cloudData2 to tableData:

Also we combine two flags of progress cloud1RequestInProgress and cloud2RequestInProgress to a single one – inProgress.

LoadData method of a ViewModel starts the loading of data from each of two datasources:

And in a TableView we create a binding between ViewModels tableData and a View:

Pull to refresh triggers loadData of a ViewModel:

In a view we also create a binding between inProgress property of a ViewModel and the need to dismiss refreshing indicator:

Simple and brief -> easy to support, extend and reuse.