DEV Community: Marwan Ayman

Swift tips and tricks for beginners

Marwan Ayman — Tue, 28 Feb 2023 19:16:31 +0000

Swift is a powerful and modern programming language used to build applications for Apple’s platforms. In this article, we’ll explore some tips and tricks for programming in Swift that can help you write better code and improve your productivity.

1. Use guard statements

Guard statements are a great way to improve the readability and maintainability of your code. They allow you to exit early from a function if certain conditions are not met, which can help you avoid nested if statements and improve the flow of your code.

guard let param1 = param1, let param2 = param2 else {
  print("Missing parameters")
  return
}

2. Use optional binding wisely.

Optionals are a core feature of Swift that allow you to represent values that may or may not be present. While optionals can be powerful, they can also be a source of confusion and bugs if not used properly.

if let optionalValue = optionalValue {
  // Code that uses optionalValue
}

let length = optionalValue?.count ?? 0

3. Use Extensions to Organize Your Code.

Use extensions to add functionality to existing types without subclassing them.

extension String {
  func capitalizeFirstLetter() -> String {
    return prefix(1).uppercased() + dropFirst()
  }
}

let myString = "hello world"
print(myString.capitalizeFirstLetter()) // Output: "Hello world"

4. Use Enums to Represent Finite States

Enums are a great way to represent finite states in your code. They can make your code more expressive and less error-prone by ensuring that only valid states are used.

enum NetworkState {
  case loading
  case loaded(data: Data)
  case error(error: Error)
}

func handleNetworkState(_ state: NetworkState) {
  switch state {
  case .loading:
    print("Loading...")
  case .loaded(let data):
    print("Data loaded: \(data)")
  case .error(let error):
    print("Error occurred: \(error)")
  }
}

5. Use closures to simplify your code and make it more readable.

let numbers = [1, 2, 3, 4, 5]
let doubledNumbers = numbers.map { $0 * 2 }
print(doubledNumbers) // Output: [2, 4, 6, 8, 10]

These are just a few tips and tricks to help you write better Swift code. With practice and experience, you’ll discover many more ways to improve your coding skills and create amazing apps.

Reach me out here

SOLID Principles in Swift: A Practical Guide

Marwan Ayman — Sun, 29 Jan 2023 20:40:09 +0000

The SOLID principles are a set of guidelines for writing maintainable and scalable software. They were first introduced by Robert C. Martin in his book “Agile Software Development, Principles, Patterns, and Practices”. These principles are widely used in object-oriented programming languages, such as Swift.

Single Responsibility Principle (SRP)

The single responsibility principle states that a class should have one, and only one, reason to change. This means that a class should have a single, well-defined responsibility. In other words, a class should have only one reason to exist and all its methods should be related to that reason.

class User {
    var name: String
    var email: String
    init(name: String, email: String) {
        self.name = name
        self.email = email
    }
}

In this example, the User class has only one responsibility: to store and retrieve information about a user. It has no other responsibilities, such as sending an email or validating the user’s information. This makes it easy to understand and maintain.

Open-Closed Principle (OCP)

The open-closed principle states that a class should be open for extension, but closed for modification. This means that a class should be designed in such a way that new functionality can be added without modifying the existing code.

protocol Shape {
    func area() -> Double
}

class Rectangle: Shape {
    var width: Double
    var height: Double

    init(width: Double, height: Double) {
        self.width = width
        self.height = height
    }

    func area() -> Double {
        return width * height
    }
}

class Circle: Shape {
    var radius: Double

    init(radius: Double) {
        self.radius = radius
    }

    func area() -> Double {
        return Double.pi * radius * radius
    }
}

In this example, we have a protocol “Shape” which has a function area(). The class “Rectangle” and “Circle” conforms to the Shape protocol and implements the area() function. Now, if we need to add a new shape, for example, a triangle, we can just create a new class “Triangle” which conforms to the Shape protocol and implements the area() function. We don’t need to modify the existing class, which makes it easy to add new functionality and maintain the code.

Liskov Substitution Principle (LSP)

The Liskov substitution principle states that objects of a superclass should be able to be replaced with objects of a subclass without affecting the correctness of the program. This means that a subclass should be a subtype of its superclass, and should be able to replace any instance of its superclass without affecting the correctness of the program.

Example:

class Car {
  func startEngine() {
    print("Engine started")
  }
}

class ElectricCar: Car {
  override func startEngine() {
    print("Electric motor started")
  }
}

let car: Car = ElectricCar()
car.startEngine()  // Output: "Electric motor started"

In the above example, we have a Car class and a ElectricCar subclass that inherit from it. Since ElectricCar overrides the startEngine() method and the ElectricCar instance can be assigned to a variable of type Car, LSP is satisfied.

Interface Segregation Principle (ISP)

The Interface Segregation Principle states that a class should not be forced to implement interfaces it doesn’t use. In other words, a class should only be required to implement the methods it needs.

protocol Printable {
  func printDocument()
  func scanDocument()
  func faxDocument()
}

class Printer: Printable {
  func printDocument() {
    // Code to print document
  }

  func scanDocument() {
    // Not implemented
  }

  func faxDocument() {
    // Not implemented
  }
}

In the above example, we have a Printable protocol with three methods. The Printer class only needs to implement the printDocument() method, but it is forced to implement the other two methods as well. To adhere to ISP, we can split the Printable protocol into two separate protocols: Printable and Scanable.

protocol Printable {
  func printDocument()
}

protocol Scanable {
  func scanDocument()
}

class Printer: Printable {
  func printDocument() {
    // Code to print document
  }
}

class Scanner: Scanable {
  func scanDocument() {
    // Code to scan document
  }
}

Dependency Inversion Principle (DIP)

The Dependency Inversion Principle states that high-level modules should not depend on low-level modules, but both should depend on abstractions. In other words, a class should not depend on a specific implementation, but rather on an abstraction.

Let’s take a look at an example where DIP is not followed:

class Database {
  func save(data: String) {
    // Code to save data to database
  }
}

class User {
  var database = Database()

  func save() {
    database.save(data: "user data")
  }
}

In this example, the User class depends directly on the Database class. If we need to change the implementation of the database, we would have to change the User class as well. This creates a tight coupling between the two classes and makes the code less flexible and harder to maintain.

To adhere to DIP, we can create an abstraction in the form of a protocol and have both the User and Database classes depend on it.

protocol DataStorage {
  func save(data: String)
}

class Database: DataStorage {
  func save(data: String) {
    // Code to save data to database
  }
}

class User {
  var dataStorage: DataStorage

  init(dataStorage: DataStorage) {
    self.dataStorage = dataStorage
  }

  func save() {
    dataStorage.save(data: "user data")
  }
}

In this example, the User class depends on the DataStorage protocol, rather than a specific implementation. This allows us to change the implementation of the database without affecting the User class.

DIP allows us to create more flexible and maintainable code by decoupling classes and making them depend on abstractions rather than specific implementations. It is an important principle to keep in mind when designing and implementing software.

Another way to follow DIP is to use Dependency injection. Dependency injection is a design pattern that allows us to provide an object with its dependencies, rather than creating them directly within the class. This allows us to change the implementation of the dependencies without affecting the class using them.

class Database: DataStorage {
  func save(data: String) {
    // Code to save data to database
  }
}

class User {
  var dataStorage: DataStorage

  init(dataStorage: DataStorage = Database()) {
    self.dataStorage = dataStorage
  }

  func save() {
    dataStorage.save(data: "user data")
  }
}

This way we can use a different implementation of the DataStorage protocol and use it in the User class

class CloudStorage: DataStorage {
  func save(data: String) {
    // Code to save data to cloud
  }
}

let user = User(dataStorage: CloudStorage())

Conclusion

In conclusion, the SOLID principles are a set of guidelines that help us create more maintainable and flexible code. These principles, Single Responsibility Principle, Open-Closed Principle, Liskov Substitution Principle, Interface Segregation Principle and Dependency Inversion Principle, are essential to consider when designing and implementing software.

By following these principles, we can create classes that are easy to understand, test, and change. They also help us avoid common design problems such as tight coupling and fragile code.

In this article, we have seen examples of how to implement SOLID principles in swift. By following these principles, we can create code that is more maintainable, flexible and easy to understand. These principles should be considered as a guide to help make our code more robust and scalable.

In short, SOLID principles are a set of guidelines that help us create more maintainable and flexible code. By following these principles, we can create code that is more robust and scalable, which is essential for building high-quality software.

Reach me out here

iOS unit test mocking using SwiftyMocky

Marwan Ayman — Sun, 27 Nov 2022 16:37:24 +0000

Swift was designed to be safe — supporting read-only reflection. Thus, there’s no way to modify your program at runtime. Overall, it’s good, the code is executed as expected, and other components cannot change it. But leading back to our topic, all mocking frameworks are built on reflection to be able to change classes, types, and objects on runtime.

This language needs its superheroes to write testable code, and we know them well — protocols and extensions! No matter what implementation it is — class, enum, or struct — the purpose of protocols remains — to define abstractions and add new functionality to types, even ones we don’t owe.

What we can do to mock?

Use meta-programming to generate complete mock implementation.

They are many libraries doing the mock job for the unit testing, most poplar are Cuckoo and swifyMocky.

In this article, I will give overview on how we can do the mocking using SwiftyMocky.

SwiftyMocky

Advantages

Automatically mock Swift protocols
Support generics
Straightforward setup and lightweight
Good documentation
Nice and easy syntax (that utilizes auto-complete)

Mock generation

Mark protocols to be mocked
Every protocol in source directories, having this annotation, will be added to Mock.generated.swift

Stubbing

All mocks has given method (accessible both as instance method or global function), with easy to use syntax, allowing to specify what should be return values for given methods (based on specified attributes)

Spying

All mocks has verify method (accessible both as instance method or global function), with easy to use syntax, allowing to verify, whether a method was called on mock, and how many times. It also provides convenient way to specify, whether method attributes matters (and which ones)
All mocks has perform method (accessible both as instance method or global function), with easy to use syntax, allowing to specify closure, that will be executed upon stubbed method being called

Autocomplete

Setup

Install using Cocoapods
Instal CLI for easy mock generation

swiftymocky setup # if you don’t have a Mockfile yet

swiftymocky doctor # validate your setup

swiftymocky generate # generate mocks

Mocks generation is based on Mockfile.yml file with possibility to exclude swift lint rules using excludedSwiftLintRules

Conclusion

Not so many tools we, as developers, have for mocking on Swift, with some strict boundaries due to language limited runtime access. And here we come to the critical question — use or not to use external frameworks for mocking.

Well-known Uncle Bob keeps not using them as much as possible; he says: “The point at which you start to need a mocking framework is the very point at which the coupling between your tests and code is getting too high. After that, however, You should strive to keep the coupling between your code and tests low enough that you don’t need to use the mocking framework very often.”

Thank you for reading! If you liked this article, please clap so other people can read it too :)
Happy coding ✌️

Reach me out here

Getting Started with the VIPER Architecture Pattern for iOS Application Development

Marwan Ayman — Sun, 20 Nov 2022 13:43:49 +0000

When you are planning to build an app, one of the most important decisions is to choose how to structure your app’s core.

Better saying, you need to decide which architecture you should adopt to build all your screens, features, and contexts. You need to know how to organize your app in order to make it maintainable for the long term, testable, scalable, and understandable by anyone who enters the project sometime later. In this article, we will get familiar with a design pattern called VIPER (View, Interactor, Presenter, Entity, and Router.) for iOS development.

What is VIPER?

VIPER is an architectural pattern like MVC or MVVM, but it separates the code further by single responsibility.
One feature, one module. For each module, VIPER has five different classes with distinct roles. No class goes beyond its sole purpose.

Each of the letters in VIPER stand for a component of the architecture: View, Interactor, Presenter, Entity and Router.

View is the user interface. This layer is the ViewController together with the UIView(or xib/storyboard)
Interactor contains business logic related to the data (Entities) or networking, like creating new instances of entities or fetching them from the server. For those purposes you’ll use some Services and Managers which are not considered as a part of VIPER module but rather an external dependency
Presenter is directing data between the view and interactor, taking user actions and calling to router to move the user between views.The only class to communicate with all the other components.
Entity is your plain data objects, not the data access layer, because that is a responsibility of the Interactor.
Router handles navigation between the VIPER modules.

Below I will explain an example of VIPER

Protocols
I have created a separate file for all the protocols



protocol NewsListView: AnyObject {
}

protocol NewsListPresenter: AnyObject {
    func viewDidLoad(view: NewsListView)
}

protocol NewsListInteractorInput: AnyObject {
}

protocol NewsListInteractorOutput: AnyObject {
}

protocol NewsListRouter: AnyObject {
}

protocol NewsListRepo: AnyObject {

}

As you can see from the above code, this is the main contract agreement between VIPER layers.

Presenter

PresenterImplementation is an implementation of NewsListPresenter protocol and confirm the NewsListInteractorOutput.

In this layer presenter has a reference object from View, Router and Interactor



final class NewsListPresenterImplementation: NewsListPresenter{

    private weak var view: NewsListView?
    private let router: NewsListRouter
    private let interactor: NewsListInteractorInput

    init(router: NewsListRouter, interactor: NewsListInteractorInput) {
        self.router = router
        self.interactor = interactor
    }

    func viewDidLoad(view: NewsListView) {
        self.view = view
    }
}

extension NewsListPresenterImplementation: NewsListInteractorOutput {

}

Interactor
Interactor is an implementation of NewsListInteractorInput protocol

NewsListRepo is responsible to fetch the data from network or Data provider



final class NewsListInteractor: NewsListInteractorInput {

    weak var output: NewsListInteractorOutput?

    private let repo: NewsListRepo

    init(repo: NewsListRepo) {
        self.repo = repo
    }
}

View
View is a UIViewController with a confirmation of NewsListView protocol and it has reference to the presenter



final class NewsListViewController: UIViewController, NewsListView {

    private let presenter: NewsListPresenter

    init(presenter: NewsListPresenter) {
        self.presenter = presenter

        super.init(nibName: nil, bundle: nil)
    }

    required init?(coder aDecoder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }

    override func viewDidLoad() {
        super.viewDidLoad()

        presenter.viewDidLoad(view: self)
    }
}

Entity



struct News {
    let title: String
    let url: URL
}

Router



final class NewsListRouterImplementation: NewsListRouter {

    weak var viewController: UIViewController?

}

Now we need to update our VIPER module to fetch the news data, yes as you are thinking right now, we need to update our contract protocols first



protocol NewsListView: AnyObject {
    func show(newsList: [News])
}

protocol NewsListPresenter: AnyObject {
    func viewDidLoad(view: NewsListView)
}

protocol NewsListInteractorInput: AnyObject {
    func fetchNewsList()
}

protocol NewsListInteractorOutput: AnyObject {
    func fetchNewsListSuccess(newsList: [News])
    func fetchNewsListFailure(error: Error?)
}

protocol NewsListRepo: AnyObject {
    func fetchNewsList(completion: @escaping ([News]?, Error?) -> Void)
}

protocol NewsListRouter: AnyObject {
}

Let’s now add implementation for theses added funcs in the protocols

Interactor



final class NewsListRepoImplementationl: NewsListRepo {
    func fetchNewsList(completion: @escaping ([News]?, Error?) -> Void) {
        // Fetch the data with completion
    }
}



final class NewsListInteractor: NewsListInteractorInput {

    weak var output: NewsListInteractorOutput?

    private let repo: NewsListRepo

    init(repo: NewsListRepo) {
        self.repo = repo
    }

    func fetchNewsList() {
        repo.fetchNewsList { news, error in
            if let newsList = news {
                self.output?.fetchNewsListSuccess(newsList: newsList)
            } else {
                self.output?.fetchNewsListFailure(error: error)
            }
        }
    }
}

Presenter



final class NewsListPresenterImplementation: NewsListPresenter{

    private weak var view: NewsListView?
    private let router: NewsListRouter
    private let interactor: NewsListInteractorInput

    init(router: NewsListRouter, interactor: NewsListInteractorInput) {
        self.router = router
        self.interactor = interactor
    }

    func viewDidLoad(view: NewsListView) {
        self.view = view
        // Fetch the list from the interactor
        interactor.fetchNewsList()
    }
}

extension NewsListPresenterImplementation: NewsListInteractorOutput {
    func fetchNewsListSuccess(newsList: [News]) {
        self.view?.show(newsList: newsList)
    }

    func fetchNewsListFailure(error: Error?) {
        // show Error
    }
}

View



final class NewsListViewController: UIViewController, NewsListView {

    private let presenter: NewsListPresenter

    init(presenter: NewsListPresenter) {
        self.presenter = presenter

        super.init(nibName: nil, bundle: nil)
    }

    required init?(coder aDecoder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }

    override func viewDidLoad() {
        super.viewDidLoad()

        presenter.viewDidLoad(view: self)
    }

    func show(newsList: [News]) {
        // show the news in the UI 
    }
}

Now, we are fetching the news list from the interactor layer, then update the presenter with the result and the presenter is prepare the data for the View and boom pass it

Last piece from the puzzle here is to build our module, so I have created a builder class to launch my module



final class NewsListBuilder {

func build() -&gt; UIViewController {
    let router = NewsListRouterImplementation()
    let repo = NewsListRepoImplementation()
    let interactor = NewsListInteractor(repo: repo)
    let presenter = NewsListPresenterImplementation(router: router, interactor: interactor)
    let view = NewsListViewController(presenter: presenter)

    router.viewController = view
    interactor.output = presenter
    return view
}



}

Conclusion

VIPER is sounds complex in the beginning but it’s very clean architecture. It isolates each module from others. So changing or fixing bugs is very easy as you only have to update a specific module. Also for having a modular approach VIPER creates a very good environment for unit testing. As each module is independent of others, it maintains low coupling very well. So, dividing work among co-developers is also pretty simple.

My advice if you are going to using VIPER in your project, the smartest thing would be to use an automatic module structure generator. Otherwise creating files for modules will be a big hustle, There are few generators available online.

VIPER Gen
VIPER Code

Thank you for reading! If you liked this article, please Like so other people can read it too :)

Happy coding ✌️

Reach me out here