Getting began with VIPER
To begin with, you must learn my earlier (extra theoretical) article concerning the VIPER structure itself. It is a fairly respectable writing explaining all of the VIPER elements and reminiscence administration. I’ve additionally polished it just a little bit, final week. ⭐️
The issue with that article nonetheless was that I have never present you the actual deal, aka. the Swift code for implementing VIPER. Now after a full 12 months of tasks utilizing this structure I can lastly share all my greatest practices with you.
So, let’s begin by making a model new Xcode mission, use the one view app template, identify the mission (VIPER greatest practices), use Swift and now you are able to take the subsequent step of creating an superior “enterprise grade” iOS app.
Producing VIPER modules
Lesson 1: by no means create a module by hand, all the time use a code generator, as a result of it is a repetative process, it is fuckin’ boring plus you must concentrate on extra essential issues than making boilerplate code. You need to use my light-weight module generator referred to as:
This part is outdated, you must use the swift template repository.
Simply obtain or clone the repository from GitHub. You may set up the binary software by operating swift run set up –with-templates. This can set up the vipera app beneath /usr/native/bin/ and the fundamental templates beneath the ~/.vipera listing. You need to use your personal templates too, however for now I will work with the default one. 🔨
I normally begin with a module referred to as Most important that is the foundation view of the appliance. You may generate it by calling vipera Most important within the mission listing, so the generator can use the correct mission identify for the header feedback contained in the template recordsdata.
Clear up the mission construction just a little bit, by making use of my conventions for Xcode, because of this assets goes to an Belongings folder, and all of the Swift recordsdata into the Sources listing. These days I additionally change the AppDelegate.swift file, and I make a separate extension for the UIApplicationDelegate protocol.
Create a Modules group (with a bodily folder too) beneath the Sources listing and transfer the newly generated Most important module beneath that group. Now repair the mission points, by deciding on the Data.plist file from the Belongings folder for the present goal. Additionally do take away the Most important Interface, and after you can safely delete the Most important.storyboard and the ViewController.swift recordsdata, as a result of we’re not going to want them in any respect.
Contained in the AppDelegate.swift file, you need to set the Most important module’s view controller as the foundation view controller, so it ought to look considerably like this:
import UIKit
@UIApplicationMain
class AppDelegate: UIResponder {
var window: UIWindow?
}
extension AppDelegate: UIApplicationDelegate {
func utility(_ utility: UIApplication,
didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
self.window = UIWindow(body: UIScreen.major.bounds)
self.window?.rootViewController = MainModule().buildDefault()
self.window?.makeKeyAndVisible()
return true
}
}Congratulations, you have created your very first VIPER module! 🎉
UITabBarController & VIPER
I’ve an excellent easy answer for utilizing a tab bar controller in a VIPER module. First let’s generate a couple of new modules, these are going to be the tabs. I’ll use the JSONPlaceholder service, so we could say a separate tab for every of those assets: posts, albums, photographs, todos (with the identical module identify). Generate all of them, and transfer them into the modules folder.
Now, let’s generate yet one more module referred to as Dwelling. This can implement our tab bar controller view. In order for you you need to use the Most important module for this objective, however I wish to preserve that for animation functions, to have a neat transition between the loading display screen and my Dwelling module (all of it is determined by your wants).
So the principle logic that we’ll implement is that this: the principle view will notify the presenter concerning the viewDidAppear occasion, and the presenter will ask the router to show the Dwelling module. The Dwelling module’s view might be a subclass of a UITabBarController, it’s going to additionally notify it is presenter about viewDidLoad, and the presenter will ask for the correct tabs, through the use of its router.
Right here is the code, with out the interfaces:
class MainDefaultView: UIViewController {
var presenter: MainPresenter?
override func viewDidAppear(_ animated: Bool) {
tremendous.viewDidAppear(animated)
self.presenter?.viewDidAppear()
}
}
extension MainDefaultPresenter: MainPresenter {
func viewDidAppear() {
self.router?.showHome()
}
}
extension MainDefaultRouter: MainRouter {
func showHome() {
let viewController = HomeModule().buildDefault()
self.viewController?.current(viewController, animated: true, completion: nil)
}
}
extension HomeDefaultView: HomeView {
func show(_ viewControllers: [UIViewController]) {
self.viewControllers = viewControllers
}
}
extension HomeDefaultPresenter: HomePresenter {
func setupViewControllers() {
guard let controllers = self.router?.getViewControllers() else {
return
}
self.view?.show(controllers)
}
}
extension HomeDefaultRouter: HomeRouter {
func getViewControllers() -> [UIViewController] {
return [
PostsModule().buildDefault(),
AlbumsModule().buildDefault(),
PhotosModule().buildDefault(),
TodosModule().buildDefault(),
].map { UINavigationController(rootViewController: $0) }
}
}
class HomeModule {
func buildDefault() -> UIViewController {
presenter.setupViewControllers()
return view
}
}There may be one further line contained in the Dwelling module builder operate that triggers the presenter to setup correct view controllers. That is simply because the UITabBarController viewDidLoad technique will get referred to as earlier than the init course of finishes. This behaviour is sort of undocumented however I assume it is an UIKit hack with a view to preserve the view references (or only a easy bug… is anybody from Apple right here?). 😊
Anyway, now you’ve gotten a correct tab bar contained in the mission built-in as a VIPER module. It is time to get some information from the server and right here comes one other essential lesson: not every part is a VIPER module.
Providers and entities As you would possibly observed there is no such thing as a such factor as an Entity inside my modules. I normally wrap APIs, CoreData and lots of extra information suppliers as a service. This fashion, all of the associated entities will be abstracted away, so the service will be simply changed (with a mock for instance) and all my interactors can use the service by means of the protocol definition with out figuring out the underlying implementation.
One other factor is that I all the time use my promise library if I’ve to cope with async code. The rationale behind it’s fairly easy: it is far more elegant than utilizing callbacks and non-obligatory end result components. It’s best to study guarantees too. So right here is a few a part of my service implementation across the JSONPlaceholder API:
protocol Api {
func posts() -> Promise<[Post]>
func feedback(for put up: Submit) -> Promise<[Comment]>
func albums() -> Promise<[Album]>
func photographs(for album: Album) -> Promise<[Photo]>
func todos() -> Promise<[Todo]>
}
struct Submit: Codable {
let id: Int
let title: String
let physique: String
}
class JSONPlaceholderService {
var baseUrl = URL(string: "https://jsonplaceholder.typicode.com/")!
enum Error: LocalizedError {
case invalidStatusCode
case emptyData
}
personal func request<T>(path: String) -> Promise<T> the place T: Decodable {
let promise = Promise<T>()
let url = baseUrl.appendingPathComponent(path)
print(url)
URLSession.shared.dataTask(with: url) { information, response, error in
if let error = error {
promise.reject(error)
return
}
guard let httpResponse = response as? HTTPURLResponse, httpResponse.statusCode == 200 else {
promise.reject(Error.invalidStatusCode)
return
}
guard let information = information else {
promise.reject(Error.emptyData)
return
}
do {
let mannequin = strive JSONDecoder().decode(T.self, from: information)
promise.fulfill(mannequin)
}
catch {
promise.reject(error)
}
}.resume()
return promise
}
}
extension JSONPlaceholderService: Api {
func posts() -> Promise<[Post]> {
return self.request(path: "posts")
}
}Normally I’ve a mock service implementation subsequent to this one, so I can simply check out every part I would like. How do I swap between these companies? Effectively, there’s a shared (singleton – do not hate me it is fully nice 🤪) App class that I take advantage of principally for styling functions, however I additionally put the dependency injection (DI) associated code there too. This fashion I can cross round correct service objects for the VIPER modules.
class App {
static let shared = App()
personal init() {
}
var apiService: Api {
return JSONPlaceholderService()
}
}
class PostsModule {
func buildDefault() -> UIViewController {
let view = PostsDefaultView()
let interactor = PostsDefaultInteractor(apiService: App.shared.apiService)
return view
}
}
class PostsDefaultInteractor {
weak var presenter: PostsPresenter?
var apiService: Api
init(apiService: Api) {
self.apiService = apiService
}
}
extension PostsDefaultInteractor: PostsInteractor {
func posts() -> Promise<[Post]> {
return self.apiService.posts()
}
}You are able to do this in a 100 different methods, however I presently want this strategy. This fashion interactors can immediately name the service with some additional particulars, like filters, order, kind, and so forth. Mainly the service is only a excessive idea wrapper across the endpoint, and the interactor is creating the fine-tuned (higher) API for the presenter.
Making guarantees
Implementing the enterprise logic is the duty of the presenter. I all the time use guarantees so a primary presenter implementation that solely masses some content material asynchronously and shows the outcomes or the error (plus a loading indicator) is only a few traces lengthy. I am all the time attempting to implement the three primary UI stack components (loading, information, error) through the use of the identical protocol naming conventions on the view. 😉
On the view facet I am utilizing my good outdated assortment view logic, which considerably reduces the quantity of code I’ve to write down. You may go together with the normal approach, implementing a couple of information supply & delegate technique for a desk or assortment view is just not a lot code in any case. Right here is my view instance:
extension PostsDefaultPresenter: PostsPresenter {
func viewDidLoad() {
self.view?.displayLoading()
self.interactor?.posts()
.onSuccess(queue: .major) { posts in
self.view?.show(posts)
}
.onFailure(queue: .major) { error in
self.view?.show(error)
}
}
}
class PostsDefaultView: CollectionViewController {
var presenter: PostsPresenter?
init() {
tremendous.init(nibName: nil, bundle: nil)
self.title = "Posts"
}
required init?(coder aDecoder: NSCoder) {
fatalError("init(coder:) has not been applied")
}
override func viewDidLoad() {
tremendous.viewDidLoad()
self.presenter?.viewDidLoad()
}
}
extension PostsDefaultView: PostsView {
func displayLoading() {
print("loading...")
}
func show(_ posts: [Post]) {
let grid = Grid(columns: 1, margin: UIEdgeInsets(all: 8))
self.supply = CollectionViewSource(grid: grid, sections: [
CollectionViewSection(items: posts.map { PostViewModel($0) })
])
self.collectionView.reloadData()
}
func show(_ error: Error) {
print(error.localizedDescription)
}
}The cell and the ViewModel is outdoors the VIPER module, I are inclined to dedicate an App folder for the customized utility particular views, extensions, view fashions, and so forth.
class PostCell: CollectionViewCell {
@IBOutlet weak var textLabel: UILabel!
}
class PostViewModel: CollectionViewViewModel<PostCell, Submit> {
override func config(cell: PostCell, information: Submit, indexPath: IndexPath, grid: Grid) {
cell.textLabel.textual content = information.title
}
override func measurement(information: Submit, indexPath: IndexPath, grid: Grid, view: UIView) -> CGSize {
let width = grid.width(for: view, objects: grid.columns)
return CGSize(width: width, top: 64)
}
}Nothing particular, if you would like to know extra about this assortment view structure, you must learn my different tutorial about mastering assortment views.
Module communication
One other essential lesson is to discover ways to talk between two VIPER modules. Usually I am going with easy variables – and delegates if I’ve to ship again some form of information to the unique module – that I cross round contained in the construct strategies. I’ll present you a very easy instance for this too.
class PostsDefaultRouter {
weak var presenter: PostsPresenter?
weak var viewController: UIViewController?
}
extension PostsDefaultRouter: PostsRouter {
func showComments(for put up: Submit) {
let viewController = PostDetailsModule().buildDefault(with: put up, delegate: self)
self.viewController?.present(viewController, sender: nil)
}
}
extension PostsDefaultRouter: PostDetailsModuleDelegate {
func toggleBookmark(for put up: Submit) {
self.presenter?.toggleBookmark(for: put up)
}
}
protocol PostDetailsModuleDelegate: class {
func toggleBookmark(for put up: Submit)
}
class PostDetailsModule {
func buildDefault(with put up: Submit, delegate: PostDetailsModuleDelegate? = nil) -> UIViewController {
let view = PostDetailsDefaultView()
let interactor = PostDetailsDefaultInteractor(apiService: App.shared.apiService,
bookmarkService: App.shared.bookmarkService)
let presenter = PostDetailsDefaultPresenter(put up: put up)
return view
}
}
class PostDetailsDefaultRouter {
weak var presenter: PostDetailsPresenter?
weak var viewController: UIViewController?
weak var delegate: PostDetailsModuleDelegate?
}
extension PostDetailsDefaultRouter: PostDetailsRouter {
func toggleBookmark(for put up: Submit) {
self.delegate?.toggleBookmark(for: put up)
}
}
class PostDetailsDefaultPresenter {
var router: PostDetailsRouter?
var interactor: PostDetailsInteractor?
weak var view: PostDetailsView?
let put up: Submit
init(put up: Submit) {
self.put up = put up
}
}
extension PostDetailsDefaultPresenter: PostDetailsPresenter {
func reload() {
self.view?.setup(with: self.interactor!.bookmark(for: self.put up))
self.interactor?.feedback(for: self.put up)
.onSuccess(queue: .major) { feedback in
self.view?.show(feedback)
}
.onFailure(queue: .major) { error in
}
}
func toggleBookmark() {
self.router?.toggleBookmark(for: self.put up)
self.view?.setup(with: self.interactor!.bookmark(for: self.put up))
}
}Within the builder technique I can entry each part of the VIPER module so I can merely cross across the variable to the designated place (identical applies for the delegate parameter). I normally set enter variables on the presenter and delegates on the router.
It is normally a presenter who wants information from the unique module, and I wish to retailer the delegate on the router, as a result of if the navigation sample modifications I haven’t got to vary the presenter in any respect. That is only a private choice, however I like the best way it seems to be like in code. It is actually arduous to write down down this stuff in a single article, so I would advocate to obtain my completed pattern code from GitHub.
Abstract
As you’ll be able to see I am utilizing numerous design patterns on this VIPER structure tutorial. Some say that there is no such thing as a silver bullet, however I consider that I’ve discovered a very wonderful methodology that I can activate my benefit to construct high quality apps in a short while.
Combining Guarantees, MVVM with assortment views on prime of a VIPER construction merely places each single piece into the precise place. Over-engineered? Possibly. For me it is well worth the overhead. What do you concentrate on it? Be happy to message me by means of twitter. You may as well subscribe to my month-to-month e-newsletter beneath.