Originally posted on my personal blog at riteshhh.com 🙇 🙈

In this post, we will explore how we can form a declarative networking layer using Combine for iOS applications. The idea here is not to re-create URLSession.DataTaskPublisher operator but rather to understand and take advantage of the existing declarative nature of Combine (and its operators) to manage success and error values declaratively. I know I have already over used the term declarative, so please bear with me 😅

The Combine framework has a built-in operator named DataTaskPublisheralong with a convenience method on URLSession which can be used to hit a network request i.e. func dataTaskPublisher(for request: URLRequest) -> URLSession.DataTaskPublisher .

Though before we go ahead and parse server’s response we need to validate it so that we can segregate the error values from the success values. Once we have established this clear separation between the two paths, we can then parse them correctly and pass on the values in their respective streams. Also, the Combine framework doesn’t know how to understand custom error cases that a server might throw (4xx/5xx) or some hidden key/value pair in headers. So we need to handle two things to move forward,

1. How to add validation rules to segregate success and error values?
2. How to map the server’s error response to a custom type and forward its value via error stream only?

This is just an excerpt from the original article posted on my personal blog at riteshhh.com 🙇‍♂️ 🙈

One of the missing pieces is the binding operator <~ which I think everyone in the ReactiveSwift community is fond of. So, I thought let's try to recreate it using Combine as it shouldn't be too hard.

This is just an excerpt from the original article posted on my personal blog 🙇‍♂️

Part 1: AppStarterViewController

This is just an excerpt from the original article posted on my personal blog 🙇‍♂️

http://riteshhh.com/child-view-controllers-part-1/

Child View Controllers, Part 1 was originally published in Swift Sundae 🍨 on Medium, where people are continuing the conversation by highlighting and responding to this story.

Motivation

In the last one year, I have played a lot with ReactiveSwift and since then I haven’t looked back to non-reactive style of programming. Reactive programming completely re-wires your brain and gradually it changes the approach of solving a problem. Since I like OSS a lot, these days I’m trying to adapt my existing swift libraries to have a reactive layer as well. Though one can argue that why not re-write them completely using reactive approach. Well adding just a top layer give user the freedom to choose between reactive & non-reactive versions of the same library. This is advantageous because we don’t want someone to not use our libraries just because they don’t want ReactiveCocoa since it’s a relatively bigger dependency (you can checkout Receiver if you are looking for a reactive µ-framework)

Closure based api

Let’s say we are using a framework, DataProvider, which takes care of populating UITableView & UICollectionView. After removing the low level details of the class, it looks like something below,

class DataProvider {
    ...	
    var sections: ([Section] -> Void)
    ...
}

As you can see, we have a closure named sections which we want to invoke or observe to make relevant updates in a table/collection. The objective here is to add a reactive layer along with this closure api. Since the framework, let’s say, is not maintained by us and we don't want to modify their underlying logic so let's try to figure out how to go about it.

ReactiveSwift

1. ReactiveExtensionsProvider

If you are familiar with ReactiveSwift, there’s a protocol ReactiveExtensionsProvider which marks the foundation of adding a separate layer of reactive apis. This separate layer is provided by a property .reactive. Below you can checkout the extension in more detail,

public struct Reactive<Base> { ... }

extension ReactiveExtensionsProvider {

    public var reactive: Reactive<Self>
    ...
}

Since ReactiveCocoa (UIKit + ReactiveSwift) makes NSObject conform to ReactiveExtensionsProvider thus every subclass of NSObject (which is practically the entire UIKit) gets a property –– .reactive. Let's see some UIKit reactive & non-reactive counterparts,

...
view.alpha // non-reactive
view.reactive.alpha //reactive

view.isHidden
view.reactive.isHidden
...

Similarly if we want to add a reactive layer on top of the DataProvider, we can simply conform DataProvider to ReactiveExtensionsProvider,

extension DataProvider: ReactiveExtensionsProvider {}

Since ReactiveExtensionsProvider is an empty protocol so we don't need to provide anything. But what we get in return is .reactive property on an instance of DataProvider. Now that we have a separate layer for reactive apis, so let's see how to make a couple of such apis. Since they are reactive apis so it's not as straight forward as adding properties directly to DataProvider. There are few steps involved which we will understand below.

2. BindingTarget

UIView has properties like –– view.isHidden, view.alpha etc. We already know that isHidden is of type Bool and alpha is of type CGFloat. Now if we checkout the types of their reative counterparts like view.reactive.isHidden, we can find out that it's BindingTarget<Bool> rather than simply Bool. Similarly view.reactive.alpha is of type BindingTarget<CGFloat>. So if we want a property which we want to bind, we need an instance of BindingTarget of that corresponding property. Let's try to add a corresponding reactive property for sections in DataProvider so that we can do something like dataprovider.reactive.sections which will have type BindingTarget<[Section]>,

extension Reactive where Base: DataProvider {
	
    var sections: BindingTarget<[Section]> {
	return makeBindingTarget { (dataProvider, newSections) in 
	    dataProvider.sections(newSections) 
	}
    }
}

Now let’s breakdown the extension so we can understand the inner bits,

• extension Reactive where Base: DataProvider –– Base is the custom class in which we want to add a reactive layer (DataProvider in our case).
• var sections: BindingTarget<[Section]> –– We have already discussed it above i.e. if we have a closure api dependent on [Section] then we would want it’s reactive counterpart of type BindingTarget<[Section]>.
• makeBindingTarget { (dataProvider, newSections) in } –– It’s an in-built function inside ReactiveSwift framework which returns an instance of BindingTarget. It has a closure based initialiser which takes two arguments as part of a tuple i.e. an instance of the Base class (DataProvider) and the input ([Section]).
• dataProvider.sections(newSections) –– This is the internal underlying logic which we want to use when we get new values of sections so that we can trigger the table/collection to update.

Thus after making the above changes, the new reactive api looks something like below,

let dataProvider = DataProvider()

// reactive
dataProvider.reactive.sections <~ ... // acts like a target

// non reactive
dataProvider.sections(...)

3. BindingSource (Signal)

Just now we saw how we can reactively get the sections which allows us to bind it with other functions. Now what if we want to observe the sections reactively as well. To achieve it, there's another protocol –– BindingSource which simply means it can act like source of values which we can listen or bind forward. We already have a class Signal comforming to BindingSource, as part of ReactiveSwift framework, to make our job easier. Let's see some UIKit examples to understand the flow,

textField.reactive.continuousTextValues // Signal<String?>
button.reactive.controlEvents // Signal<UIControlEvents>

We can see a similar pattern here as well i.e. how to migrate a type to it’s reactive counterpart — we simply need a Signal of that type. In our case it's array of section i.e. Signal<[Section]>. Let's again extend Reactive to add a new property called sectionsSignal

extension Reactive where Base: DataProvider {
	
    var sectionsSignal: Signal<[Section]> {
	return Signal { observer, _ in
		base.sections = { sections in 
			observer.send(value: sections) 
		}
	}
    }
}

Let’s again deconstruct the extension without repeating the parts we have already discussed,

• return Signal { observer, _ in } –– Signal intializer gives us two arguments, observer & lifetime where observer is the instance of the class which is listening to the values emitted by this Signal (for simplicity let's not talk about lifetime).
• base.onNext –– base is the instance of the custom class which we want to extend to have a reactive layer. In this case it's DataProvider, that's why we can access sections property which is nothing but a closure.
• observer.send(value: sections) –– whenever someone calls base.sections(), sectionsSignal will emit a new value of sections by calling the method observer.send().

Thus after making the above changes, the new reactive api looks something like below,

// acts like a source of values
... <~ dataProvider.reactive.sectionsSignal

Conclusion

Thus without modifying any underlying logic of DataProvider or creating a new class, we are able to extend it to make it plugeable with other reactive apis. The protocols or classes used above are –– ReactiveExtensionsProvider, BindingTarget, Reactive & Signal (BindingSource) Let's the compare the final api,

extension DataProvider: ReactiveExtensionsProvider {}

extension Reactive where Base: DataProvider {
 
    var sections: BindingTarget<[Section]> {
       return makeBindingTarget { (dataProvider, newSections) in 
         dataProvider.sections(newSections) 
       }
    }
 
    var sectionsSignal: Signal<[Section]> {
      return Signal { observer, _ in
          base.sections = { sections in 
            observer.send(value: sections) 
          }
      }
    }
}

let dataProvider = DataProvider()

// reactive
dataProvider.reactive.sections <~ ... // used as a target
... <~ dataProvider.reactive.sectionsSignal // used as a source

// non-reactive
dataProvider.sections(...)
dataProvider.sections = { sections in ... }

There are few terms/concepts which I have deliberately left out so that it doesn’t mix with the objective of the article. Feel free to ask about them in the comments or add your thoughts on how to make it better! Thanks again for reading 🚀

Reactive <~ Closure was originally published in Swift Sundae 🍨 on Medium, where people are continuing the conversation by highlighting and responding to this story.

About

My last snippet was about how we can transform Apple’s Foundation/UIKit apis using extension to remove some of the boilerplate code. Today we will explore how we can reduce code to construct a UIAlertController.

You can find its Gist here!

UIAlertControllerStyle

The first extension is on UIAlertControllerStyle which returns an instance of UIAlertController of a specific style i.e. –– alert or actionSheet. So now I can do something like this,

let alertController = UIAlertControllerStyle
  .alert
  .controller(title:, message:, actions:)

So instead of passing a style type inside the constructor of UIAlertController, I can now ask for a controller of a particular style (if you have read my earlier snippets or blog posts, you probably know by now that I like extension oriented apis –– looks cleaner and simple to read).

String

Now any alert will also have some actions associated to it. Thus the next extension is on String since every action will some have title and it returns an instance of UIAlertAction,

let dismissAction = "Dismiss".alertAction()

let retryAction = "Retry".alertAction { _ in /* retry logic */ }

So instead of passing a title into the constructor of UIAlertAction, I can now ask of an alertAction on a String.

That’s it, now let’s look at the entire api,

Without creating extra classes, we have been able to write such a short api to construct any kind of UIAlertController. You can also make an actionSheet using the same api 🚀.

PS –– I have used String for simplicity but if you don’t like it then you can also create an Enum just for the different actions and extend it to have similar behaviour!

If you are wondering about the inception of Swift-Snippets or want to checkout more such snippets, you can find them here 😊

Swift snippet #14 — UIAlertControllerStyle was originally published in Swift Snippets 🚀 on Medium, where people are continuing the conversation by highlighting and responding to this story.

Idea 💡

In the last couple of years, MVVM has gained some reputation in the iOS community. Almost every other conference has atleast one talk on it. Almost every other blog post is talking about design patterns specially MVVM (like this one :p). All of this indicates that it must be very good at what it does. So let’s try to understand what it actually does 🤔.

Motivation 💪

When we make an iOS (or you can say in general any mobile/web) app, every screen has more than one UI component like UIView, UITextField, UILabel, UIImageView.. etc. These components need to fill themselves with a lot of business logic. Hence there is a big opportunity of tight coupling between the two. Now the coupling is bad because it,

• increases the cost of making UI modifications
• difficulty of unit testing such code

Thus to decouple them, we often try to use some design patterns to add some abstraction & modularity. One of such patterns is MVVM, introduced by Microsoft, which stands for ofcourse — Model-View-ViewModel. I won’t delve into the finer details of MVVM since you must be tired of reading it again & again. Instead I’ll talk about what it has to offer and where else can we apply it. If you are hearing MVVM for the first time then there are some really good documentation by Microsoft which you can checkout here or there are plenty of good posts by the community as well.

What it does? 🤔

MVVM has one & only one job — it simply separates the presentation logic from an UI. Let’s talk about this presentation logic. Every UI needs to display some data in one form or the other. Now a data can’t be directly shown because it’s saved in a raw format. So we need to apply some decorative methods on it to make it usable for the UI. So far so good but nobody talks about where is this data coming from. It could come from a persistence layer or may be an api call or may be both. So who is exactly resposible for getting this data. Since ViewModel is "ONLY" resposible for decorating the data so may be we could put our data fetching logic also in it like some core-data helpers or may be some api logic.. aaand we are back to where we started from, it starts to sound like a controller. It's time we take a step back and leave the view-model only with presentation logic.

Moment of truth! 😲

Since, while we study MVVM (or such design patterns), this grey area (i.e. who gets the data) is not very well defined so we end up putting this logic inside view-model or controller. Thus giving rise to massive-controllers or these days massive-viewmodels. But nobody said that you can’t abstract data fetching just like you just abstracted presentation logic. So what we should also learn from MVVM is we should abtract out different resposibilities and put them in a different class. It’s just MVVM doesn’t talk about data fetching but we could use the idea that led to MVVM i.e. it’s good to have single responsibility per class. We can achieve this in many ways, though right now I’ll only discuss using two simple ways — concrete classes & protocols.

Example 🛠️

In the first example we will see how can inject Datasource into UserListViewModel so that we can abstract out the logic of fetching data into a separate class and make the view-model only consume it,

struct User {
	
	let name: String
}

// to fetch data from persistence/api
struct Datasource<T> {

	func items() -> [T] {
		return []
	}
}

struct UserListViewModel {

	// decorated data with business logic
	let users: [User]

	init(datasource : Datasource<User>) {
		// business logic
		users = datasource
			.items()
			.map { "\($0.name.uppercased())" }
			.map { "Hey \($0)" }
	}
}

We can achive similar result using protocol as well thus making UserListViewModel act like a datasource but without having the actuall logic inside it,

Update: Recently I got to know that the following approach actually has a name –– Dependency injection with Cake Pattern (small world 😅)

struct User {
	
	let name: String
}

// to fetch data from persistence/api
protocol Datasource {
	
	associatedtype Model
}

extension Datasource {
	
	func items() -> [Model] {
		return []
	}
}


struct UserListViewModel: Datasource {

	typealias Model = User

	// decorated data with business logic
	let users: [User]

	init() {
		// business logic
		users = items()
			.map { "\($0.name.uppercased())" }
			.map { "Hey \($0)" }
	}
}

What did we learn!? 🤓

MVVM is just not about separating presentation logic but also about abstraction in general (just like other patterns as well). Let’s not bloat view-models or view-controllers with too many responsiblities. Don’t try to fit your logic flow into popular design patterns. Rather simply try to find out different ways to just abstract functionalities and try to reuse them, it’s more than enough 🚀.

MVVM, you had one job to do!? was originally published in Swift Sundae 🍨 on Medium, where people are continuing the conversation by highlighting and responding to this story.

Idea 💡

The reason I have titled it “Reusable View Layout..” rather than simply “Reusable View..” because I’m NOT referring to object level reusability of views here. Rather I’ll be discussing about how we can reuse a view layout with the help of a protocol & MVVM. In the process I’ll share how we can outline a view’s interface, basically different configuration states, with a protocol which will enable us to inject different view-models into a view. In other words, the idea here is to design data agnostic modelling of a view layout.

MVVM

Before we move further, let’s get few things straight about MVVM. It’s one of most confusing design patterns out there so just want to make sure we are on the same page. It’s a design pattern where we make a view dependent on an intermediate model object called view-model. This view-model, gets some data (doesn't matter from network or persistence layer) and apply some decorative methods which is finally consumed by a view. E.g. if we have a profile view class –– ProfileView, we can create it’s view-model ProfileViewModel to configure it and save it's state.

class ProfileView: UIView {

	var nameLabel: UILabel!

	func configure(with model: ProfileViewModel) {
		nameLabel.text = model.nameTitle
	}
}

struct ProfileViewModel {

	var nameTitle: String { return "Profile Title" }
} 

Binding

As we can see ProfileView gets coupled with ProfileViewModel for any kind of configuration which happens when you use MVVM. This works well if your view, in the entire lifetime, will only have one kind of view-model. Now let's say we want to reuse ProfileView class which should be capable of showing both an Owner profile & a Guest profile.

Enum

To support this, we can convert ProfileViewModel into an enum where owner & guest will be different cases.

enum ProfileViewModel {

	case owner
	case guest

	var nameTitle: String {
		switch self {
			case .owner: return "Hi, Owner"
			case .guest: return "Hi, Guest"
		}
	}
}

This solution doesn’t look bad at once but if we keep on adding more cases, it will eventually become a God class. To avoid this we can modify the way we think about MVVM. Instead of making our view directly dependent on a view-model, I propose to make an interface of a view which could include all the configurable properties. Thus we need something which a view could understand without actually knowing anything about it’s incoming view-models.

Protocol

To achieve that “something”, we can use a protocol. A view could have an interface which could be outlined using a protocol. This interface could have all the configurable states of it’s view. Finally we can have different view-models conforming to it. This approach makes the view totally oblivious of the kinds of view-models it could be expecting. E.g,

class ProfileView: UIView {

	...

	func configure(with interface: ProfileViewInterface) {
		nameLabel.text = interface.nameTitle
	}
}

protocol ProfileViewInterface {

	var nameTitle: String { get }
}

Thus now ProfileView is only aware of the fact that some object will configure it and it will be conforming to ProfileViewInterface. Doing so we have separated the layer between view and it's view-models. View is oblivious of it's view-models but view-models know which view they need to configure. This provides a scalable solution since different classes can now conform to ProfileViewInterface so that they can act like view-models for their view. E.g,

class OwnerViewModel: ProfileViewInterface {

		var nameTitle: String { return "Owner Title" }
}

class GuestViewModel: ProfileViewInterface {

		var nameTitle: String { return "Guest Title" }
}

class AdminViewModel: ProfileViewInterface {

		var nameTitle: String { return "Admin Title" }
}

let view = ProfileView()

let ownerModel = OwnerViewModel()
let guestModel = GuestViewModel()
let adminModel = AdminViewModel()

view.configure(...)

// here we can pass any of the three above view-models since they all conform to ProfileViewInterface

So tomorrow if you intend to add another kind of profile view then simply make a new view-model class conforming to ProfileViewInterface and inject it to ProfileView’s configure method 🚀.

Reusable View Class using Protocol & MVVM was originally published in Swift Sundae 🍨 on Medium, where people are continuing the conversation by highlighting and responding to this story.

I posted my last swift snippet way back in March, so roughly it’s been 6 months now. I wanted to be more active, but a lot has happened since then. Now I’m rekindling this series of snippets and hopefully will continue posting for a longer time 🚀.

You can find its Gist here!

About

With this post, I would like to highlight the power & relevance of creating Extensions. In my recent app, I had to use FileManager api and it’s really easy to use them btw. But after using it at couple of places, I was calling the same functions again, FileManager.default.contents(atPath: path) or FileManager.default.someFunc(). I felt it could be refactored and thus got the idea of converting the same api into more extension-oriented rather than function-oriented where you have to pass the argument.

If you observe the api — FileManager.default.contents(atPath: path), it takes exactly one argument i.e. path and thus we can make an extension on this argument (URL in general) to achieve the same result. In this case, it adds two benefits. It makes the new api,

• inline (you can get the same result by using dot notation)
• shorter (makes it easier to read)

Usage

Let’s say we want to read the contents of a json file name "model_user". With the above extensions, now you can achieve something like this,

let userData = "model_user".fileURL.fileContent

• fileURL gets the correct url of the file from the document's directory, eliminating the need to figure out how to get the document directory's url.
• fileURL internally uses fileName which make sure that we have a centralised variable to do any processing on the file name so that the chances of getting it wrong reduces.
• fileContent uses the FileManager api to get the required data

Thus the final api is dependent on smaller pieces of logic which are abstracted in the extension. If you want, you can make the api even shorter by using the below extension,

extension String {

	var fileContent: Data? {
		return fileURL.fileContent
	}
}

let userData = "model_user".fileContent

Though I’m not saying shorter is better, it’s a matter of how much further you should/could go (clarity is more important than brevity) 🚀

If you are wondering about the inception of Swift-Snippets or want to checkout more such snippets, you can find them here 😊

Swift snippet #13 — Extension Oriented API was originally published in Swift Snippets 🚀 on Medium, where people are continuing the conversation by highlighting and responding to this story.

Let’s take up a use case to understand what we are trying to achieve here. Every app has a UITableview or UICollectionView. To populate them, we either make an api request or hit the cache or sometimes do both. Recently I started working on multiples generic data-providers which could take care of all the above tasks. I know it sounds like too much work for protocols but hold on, you will discover later how I’ll extend associatedType to make specific data providers like CacheDataProvider & APIDataProvider derived from a generic parent protocol DataProvider.

protocol DataProvider {
  
  associatedtype Data
  var data: ([Data]) -> Void { get set }
}

protocol CacheDataProvider: DataProvider {
  
  associatedtype Data: NSManagedObject
}

protocol APIDataProvider: DataProvider {
  
  associatedtype Data: Parsable
}

DataProvider is the base protocol which has a generic constraint named Data which will be provided by the individual screen conforming it. Data defines the type of object that screen is dependent on like, list of users or list of magazines or list of movies etc.

CacheDataProvider is a child protocol, derived from DataProvider, which takes care of fetching cache data for a screen. In our case it should be a subclass of NSManagedObject. So what we have achieved here is that we have extended the meaning of Data from it’s parent protocol to something which makes more sense for cache related operations.

APIDataProvider is also a child protocol, derived from DataProvider which takes care of fetching new data from server. In our case it should be parsable, which converts a json into a concrete object. Here again we have extended the behaviour of Data to something which is more meaningful for fetching data via api.

This means that we can extend the meaning of Data as we like and it could differ for different child protocols. Now let’s see how they both provide the data in their own way,

extension CacheDataProvider {
  
  func fetchCacheData() {
    ...
    Data.allObjects()
    ...
  }
}

extension APIDataProvider {

  func fetchAPIData() {
    ...
    jsonList.map { Data.parse($0) }
    ...
  }
}

As we can see, in case of CacheDataProvider we can call a function allObjects() since Data acts like a NSManagedObject & allObjects() is a helper method on NSManagedObject to fetch all the cache objects.

In case of APIDataProvider we can call a function parse() which converts json into a concrete object since Data acts like Parsable which has a method to parse data.

Even though Data is not defined by DataProvider but as we have seen we can extend it’s meaning to anything we want as suited for the child protocol we create. If a screen only need cache then one can only conform to CacheDataProvider or if only need new data from api then APIDataProvider or if both are needed then one can conform to both the protocols to get cache first and then server data.

Thus associatedType is indeed a powerful way to extend functionality. I have used a similar approach along with ReactiveSwift to make different kinds of data providers including a paginated data provider which handles pagination for me 🚀 If you like the article, do share the kinds of associatedType you use in your projects in the comments!

Extend Swift Associated Types in Protocol to compose behaviour! was originally published in Swift Sundae 🍨 on Medium, where people are continuing the conversation by highlighting and responding to this story.

You can find its Gist here!

The above snippet creates items & itemsCount properties on every enum which has RawValue as Int.

enum City: Int {
 
 case delhi
 case bangalore
 case mumbai
}

With the help of above snippet, to get the entire the list of cases we can do City.items or City.itemsCount to get the count 🚀

Since the advent of Swift, we all have been using Enums a lot lately in our apps! And why not, they are super cool and so powerful. But they have this big limitation where we explicitly need to provide a computed var to list all the items or even items count, something like:

extension City {
  
  static var items: [City] {
    return [.delhi, .bangalore, .mumbai]
  }
  static var itemsCount: int {
    return items.count
  }
}

Nothing is wrong with the above code but its not awesome 😓 Everytime we add a new case, we have to update our items, failing of which could lead to bugs 🐛 No one likes them so how about we automate it to make it work out of the box & thus the above snippet 😄

Big thanks to Nate Cook for making it even more awesome!!!

Nate Cook on Twitter

@_riteshhh Great! 🎉 A hint: If you constrain your extension to where RawValue == Int, those don't need to be optional

It has two limitations though 🛠️:

1. only applicable for enums having RawValue as Int
2. not applicable for discontinuous cases nor the ones starting from a value other than 0

If you are wondering about the inception of Swift-Snippets or want to checkout more such snippets, you can find them here 😊

Swift snippet #11 — RawRepresentable was originally published in Swift Snippets 🚀 on Medium, where people are continuing the conversation by highlighting and responding to this story.