# Architecting an iOS networking layer: Part 2

DevFeed: [Architecting an iOS networking layer: Part 2](<https://devfeed.tech/articles/architecting-an-ios-networking-layer-part-2-24562.md>)

Original publisher: [Read original article](<https://medium.com/bleeding-edge/architecting-an-ios-networking-layer-part-2-fe92a9231995?source=rss----d8ebe85cdc0f---4>)

Author: Melissa Yung

Published: 2019-04-01T10:05:31Z

Content type: tutorial

Language: en

Sources: [Bleeding Edge - Medium](<https://devfeed.tech/sources/bleeding-edge-medium.md>)

Topics: [iOS](<https://devfeed.tech/topics/ios.md>), [networking](<https://devfeed.tech/topics/networking.md>), [REST API](<https://devfeed.tech/topics/rest-api.md>), [unit test](<https://devfeed.tech/topics/unit-test.md>)

Tags: [clean-code](<https://devfeed.tech/tags/clean-code.md>), [ios](<https://devfeed.tech/tags/ios.md>), [networking](<https://devfeed.tech/tags/networking.md>), [rest-api](<https://devfeed.tech/tags/rest-api.md>), [software-development](<https://devfeed.tech/tags/software-development.md>), [swift](<https://devfeed.tech/tags/swift.md>), [unit-tests](<https://devfeed.tech/tags/unit-tests.md>)

## AI overview

Part 2 demonstrates an iOS networking layer in a sample app. It shows how a view uses request configuration, an HTTP client, a request object, and event listeners to fetch forum posts through a REST API, and explains unit testing with mocks.

## Source excerpt

A sample project including unit tests to demo our clean architectureIllustration by Marta Pucci Welcome to Part 2 of this two part series, where we go through the networking layer we use in our iOS app at Clue. As a follow-up to Part 1, where we went through the main building blocks of our networking architecture, we would like to now show it in action in our demo app. This demo app consists of a simple view with a button that is used to fetch forum posts. Based on the success of the request, the UI is updated to reflect the number of fetched posts. We will use a fake online REST API https://jsonplaceholder.typicode.com/ to achieve this. The View For simplicity's sake, we will only focus on the bit that performs the network request i.e. fetchPosts. https://medium.com/media/62e814391f03e564236862388fcef9c2/href A. The view needs to keep a reference to the fetchPostsRequest instance to ensure that it doesn't get deallocated prematurely. B. The view puts together the required building blocks to make the service call i.e RequestConfiguration, HTTPClient, Request and RequestEventListenerFactory The Request Objecthttps://medium.com/media/11bdd42c97a15f6245aa97fe9ed64bd5/href A.1 and A.3 The request conforms to the HTTPClientDelegate protocol as we want to make a service call and handle its success or failure. A.1 and A.2 The request conforms to the RequestObserving protocol as we have interested listeners that want to be notified of the results once the service call is complete. This means that it has an eventListenerFactory which will provide a list of listeners. B. Both the required HTTPClient and the RequestEventListenerFactory are injected to the constructor to ensure testability. C. We need to set the request to be the delegate of the HTTPClient so that we can be notified when the service call returns. D. The only public interface is the actual call to perform the service call. It is public since this class lives in the networking layer module which is separate from