Refactor Your iOS Application Network Layer Into a Module
On every project a time always come to make changes in he core services. This could come for different reasons, changes to the library that we use, deprecated methods on third party/Apple libraries or we just want to migrate to start using a new library or API.
This “small” change could impact our development speed, could take a lot of time to complete and/or could introduce bugs.
What we’ll do
On this article, we will refactor all networking related files into a module. Then, we’ll migrate our network service and all related classes into a dynamic library, and finally we’ll change from using URLSession to Alamofire.
What you need to know
To follow along with the article, you’ll need to be familiarized with the following:
- Cocoapods (you can read more about cocoapods here)
URLSession(good to know)Alamofire(good to know)
Even if you are not familiarize with the last two libraries, you can still take advantage of this article.
Starting point
You can get this course starting point material from here.
First
Open the .xworkspace (or .xproject, it doesn’t make a difference at this time) and run (command + R).
The app is really simple; it allows you to search for an artist and display all of its albums and that’s that. Simple and straight.
Now that we have the app in the initial state let’s begin by adding a dynamic library to our project.
Click on the project at the very top of the project navigator.
Now on the “Targets” window, click on the plus (+) sign at the bottom left.
Now scroll all the way down until you get to “Framework and Library”, select “Cocoa Touch Framework” and click “Next”.
Now write the name (I’m calling mine NetworkService) and click on “Finish”.
After creating the framework, you should see it on the “Targets” window and on “Linked Frameworks and Libraries” on the “General” tab.
Second
Now that we have the framework in place, let’s move all the classes related to the network service into the newly created folder called “Network Service” (or however you called the framework)
Great, now if you run the app you’ll notice a few errors on the view controller.
To fix them you’ll need to import NetworkService on the view controller and navigate to the ApiService file make public the enum type (public enum Type) the ApiService class (public final class ApiService) and the get function inside the class (public static func get).
Run the app again and it should be working just fine.
We need to make these public to make them accessible to the app because they now live outside on the NetworkService module outside the app.
Great, we just modularize our network service.
Third
The project right now is using URLSession to handle all network calls. As your project increase or as the time passes is very likely that you’ll need to refactor, change or adapt your code because of changes on Cocoa Touch API or on your third party libraries.
Now let’s refactor our network manager to use Alamofire instead of URLSession.
The first thing that we’ll need to do is to update the Podfile.
We defined network_pods, every third-party library related to the network service, should be added inside this variable (i.e. AlamofireImage, SocketIO, etc.).
Then we added the newly created NetworkService target and added the network_pods only to this target. By doing this, we ensure that these network libraries will be reachable only within that target.
Now on your terminal run pod install, after completion make sure you are using the .xcworkspace and not the .xcodeproj.
Once you are on the .xcworkspace, use command + shift + O to open the NetworkManager file.
Now, import Alamofire and replace the URLSession with the following Alamofire method.
Now command + R to run the app, it should be working just like before should be running just like before.
Conclusion
Modularization of your app code is an excellent way to quickly change libraries or to maintain your current ones up to date. Is also very useful when working with a large team, since a developer could be working on a module without affecting other developers. Having a protocol for every module is something that I have found to be very useful, it makes sure that even on significant internal changes on the module, the methods that are being consumed by other parts of the app stayed the same.
You can find the final project here.
Follow me
Twitter: dmlebron
