SwiftUI+MVVM+Combine+Alamofire. Make HTTP requests the right way and handle errors.

Karen Mirakyan
3 min readMar 24, 2021

--

A while ago I faced an issue handling server-side errors making HTTP requests with Alamofire and that prompt me to write a short article about it. Let’s create a little application to understand how error handling works with Alamofire and Combine framework.

We use HTTP requests to enable connection with the server, so we need to get responses from it. And eventually, we should map our response to an object that we have. Using the Combine framework we can use the .publishDecodable (type: OurModel.self) method and it will do all the heavy lifting. But what is the problem? Each time you want to handle an error you will get (Could not decode response). Using only validation will through you an unacceptable response code and you will not be able to handle your error.

And here is the response that AF was not able to decode
This is the response we don’t want to display.

That’s the main goal of this article, how to handle server-side errors.

We will create a little application that will list chats.
Let's create a new project in Xcode.

Install Alamofire to your podfile. ->https://github.com/Alamofire/Alamofire

Open your project destination in the terminal and run pod init
Then open podfile and put the line in it -> pod ‘Alamofire’, ‘~> 5.2’
Run pod install

Structure:
We store models to parse the response from our server
Service is fetching server responses
ViewModel get the response of the server and pass it to our ContentView

Now we should create our response and error models to parse it in the future.

Later I will explain why we need both initial error and backend error.

It’s time to create our Service to fetch server responses.

The backend error is the server-side error, but imagine if the user loses connection. Your application will not be able to show anything and will crash. The initial error, in that case, should return a Network connection error which is possible only with initial error.

Why do we need validation?

AF automatically understands if the response is valid or no. If validation does no present it will try to decode the response without understandig it is error response or no and will throgh you error (Could not decode response). Or for instance, if the response and backend error models are the same AF listens to the validation code and returns you either error or response.

Why do we use Protocol-Oriented Programming(POP)?

It’s a way to think about a very specific problem set, that will help you create flexible, maintainable, testable and easy-to-read code. It should be thought of more as a complement to the Object Oriented approach. As soon as your app becomes bigger it will help you a lot.

Now we can create our ViewModel and get a response.

If any error occurs we check either the back end error is nil or no and if it’s not nil we should present its message in the alert, otherwise the response value presents and we pass it to our chats variable by taking only chats from it cause if you remember our response was ChatListModel.

Now when everything is clear we can create our view.

Any chat that has an unread message will be marked with a gray background and a blue circle.

Here is an example of an expected response

That's all. Isn’t it easy?
Thank you for your attention!

The source code is available on GitHub: https://github.com/karenxpn/HTTPRequest.git

--

--