Why?

This word is truly magical. Why did I do this?

protocol SociaHandler {
    associatedtype Request: FirebaseRequestStrategy
    
    var nextHandler: (any SociaHandler)? { get set }
    var request: Request? { get set }

    init(with handler: (any SociaHandler)?)

    func handle(_ onSuccess: (() -> Void)?) async -> LocalizedError?
}

• Why is Request a generic type and nextHandler not? (Reason is here)
• Why am I returning LocalizedError?
• Why do I need a closure called onSuccess?

guard model.username.isEmpty == false else { return AuthError.emptyUsername }

• Why am I checking for a boolean value? (It made me feel awful)

But this is a really beautiful thing. Because when I look at my code and I can think that something is wrong and I can fix my mistakes, it shows that I can continue my development. And that’s exactly what I want.

Let’s look at the problems together and find our solutions. One thing we need to pay attention to here is that there is something we want to fix. We learned something new, but should we really apply it?

Why is Request a generic type and nextHandler not?

Our first item talks about exactly this. Yes, if we can, it is more performant to get a generic type instead of any keyword. There is a video next to the article in which I explain this issue. (You may say that it might be better if this were done. If you have an idea, please let me know.)

But what I need here is exactly any handler. Because if a chain knew the generic form of the next chain, I would have to change the code so that something could be selected into the chain. And that doesn’t fit Solid’s O. So open closed.

Therefore, this is the answer to our first item. Using generics may cause reasons for me to change the code.

Why am I returning LocalizedError?

The code here is “If an error is received, the error should be returned and I will check it and notify the user.” It is in the form. This isn’t a problem, but why is this a return type?

It would definitely be much better to use throws here. It shouldn’t be your job to debug. If an error occurs, just let the developer know about it. That’s why I updated the code here as follows.

func handle() async throws

Now I throw errors instead of returning them. What did I gain here?

This code performs only one task. In other words, it will do a job and this job may make mistakes. Then I don’t want results. What if I wanted to? Now in this case, I can just add return type and do what is necessary :)

Why do I need a closure called onSuccess?

We can get a clue from the item above. We really don’t need this. Our protocol already has the full new handler.

Old

func handle(_ onSuccess: (() -> Void)?) async -> LocalizedError? {
    guard let request else { return AuthError.requestError }
    guard request.storageData.isEmpty == false else { return await nextHandler?.handle(nil) }
    onSuccess?()

    let result: FirebaseResponse<String> = await FirestorageManagerManager.shared.request(request)
    if result.status == .success, let downloadLink = result.content {
        return await nextHandler?.handle { [weak self] in
            guard let handler = self?.nextHandler as? RegisterHandler<RegisterRequest> else { return }
            guard var requestModel = handler.request?.model else { return }
            requestModel.imagePath = downloadLink
            handler.request?.model = requestModel
        }
    }

    return AuthError.uploadError
}

New

func handle() async throws {
    guard let request else { throw AuthError.requestError }
    guard !request.storageData.isEmpty else {
        try await nextHandler?.handle()
        return
    }
    try await handleRequestResult(handleRequest(request))
    try await nextHandler?.handle()
}

private func handleRequestResult(_ response: FirebaseResponse<String>) throws {
    guard response.status == .success, let downloadLink = response.content else {
        throw AuthError.uploadError
    }
    
    guard let nextHandler = nextHandler as? RegisterHandler else {
        throw AuthError.unexpectedError
    }
    nextHandler.request?.model.imagePath = downloadLink
    self.nextHandler = nextHandler
}

private func handleRequest(_ request: UploadProfilePhotoRequest) async -> FirebaseResponse<String> {
    await FirestorageManagerManager().request(request)
}

The new code is longer. But it’s definitely more understandable. So much so that when I first looked at it, I said, where does the handle method work here?

Logically, when all operations are completed, the new handler should work. But here, even though the transactions are completed, we throw a new job to the other chain. And I think this is not the right approach.

We look at the next handler we have in the new code. And we change its model. Thus, all responsibility for uploading photos remains in this chain.

Why am I checking for a boolean value?

This is entirely my fault. When writing your code, you usually write the easiest thing first, and then you can think about how to write it better. This is how I usually do it. But even though I reviewed my code here, doing long tasks definitely requires a break.

Even if I pay attention to my code while trying to create and explain the article, it seems overlooked and funny. Then let’s immediately update it with the code below and our problem will disappear.

guard !request.storageData.isEmpty else {
    try await nextHandler?.handle()
    return
}

Summary and Closing

If you ask why I wrote this article, it was definitely not to edit the code or share it. I could do this by updating the other article. The main theme here is definitely why we should use the word Why.

Especially when we learn new things, we feel deeply that our code is good and that we are improving ourselves. However, reviewing the code we wrote again (breaks are important here 🙂) gives a good answer to the question of whether we can take it further.

When you do this at regular intervals, you can see that it is improving and be able to criticize your own code. And you can continue to work and produce much more motivated.

Thank you for reading. Have a nice coding :)

But we should do this in our work. Then let’s take a look at the Chain of Responsibility that reins in complex sequential processes.

Let’s understand our problem first. I have a social media project called Socia. And it has a sign-up flow like every social media app. There are several responsibilities here.

The code containing part of the relevant flow is available below. And it’s messed up. There are a lot of controls in a single function, and it is very difficult to both read the code and make new developments at the moment.

func autoLoginAfterRegister(name: String, surname: String, bio: String, image: UIImage, username: String, on system: AuthSystem) {
    system.isAuthProgress = true

    DispatchQueue.main.async {
        self.sgServices.uploadPhoto(image: image, imagePath: "profile/profilePic.jpg", username: username) { saveResult in
            switch saveResult {
            case .failure(let saveError):
                system.failedTransaction(message: saveError.localizedDescription)
                return
            case .success(let imageURL):
                let userData = UserModel(username: username, name: name, surname: surname, bio: bio, imagePath: imageURL, bannerPath: nil, followers: nil, follows: nil, posts: nil).toMap()
                self.fsSaveService.saveUser(saveData: userData) { saveResult in
                    switch saveResult {
                    case .failure(let saveError):
                        system.failedTransaction(message: saveError.localizedDescription)
                    case .success:
                        if system.lastLoginID.isEmpty {
                            self.fsSaveService.saveBondedAcc(provider: system.lastLoginProvider, id: system.lastLoginID, username: username) { result in
                                switch result {
                                case.failure(let err):
                                    system.failedTransaction(message: err.localizedDescription)
                                case .success:
                                    system.successfulTransaction {
                                        system.username = username
                                        system.defaults.set(username, forKey: "username")
                                        system.setCurrentUser()
                                        system.isEdittingRequired()
                                    }
                                }
                            }
                        } else {
                            system.failedTransaction(message: "LOCAL_AN_ERROR_TAKED")
                            return
                        }
                    }
                }
            }
        }
    }
}

Now let’s redesign this flow with the chain of responsibility and talk about the “+ — ” points.

First, let’s create a handler protocol. We do this to create each element in the chain.

protocol SociaHandler {
    associatedtype Request: FirebaseRequestStrategy
    
    var nextHandler: (any SociaHandler)? { get set }
    var request: Request? { get set }

    init(with handler: (any SociaHandler)?)

    func handle(_ onSuccess: (() -> Void)?) async -> LocalizedError?
}

My application works with Firebase and I have a manager managed with Strategy Pattern. The strategy I have adopted here is a base protocol for all my Firebase transactions.

If you don’t have an idea about strategy pattern, you can look here or here.

Let’s blend Pattern and my needs;

• Each chain can have a chain after it.
• Each chain must contain a handler method.
• Depending on the need, a request can be given to the relevant chain.

So, let’s create the localizable error enum I need and the requests we will use in our chains.

enum AuthError: LocalizedError {
    // Common Errors
    case unexpectedError
    case requestError
    case decodeError
    case uploadError
    
    // Required Fields
    case emptyEmail
    case emptyPassword
    case emptyRepassword
    case emptyUsername
    case emptyName
    case emptySurname
    
    // Password Related Errors
    case passwordTooShort
    case passwordsNotMatched
    
    // Related Errors
    case usernameAlreadyUsed
    case emailAlreadyUsed
    
    // Bio and Profile Photo Errors
    case bioTooLong

    var errorDescription: String? {
        switch self {
        case .unexpectedError:
            return "An unexpected error occurred."
        case .requestError:
            return "Request is nil or wrong."
        case .emptyEmail:
            return "Email is empty."
        case .emptyPassword:
            return "Password is empty."
        case .emptyRepassword:
            return "Re-entered password is empty."
        case .emptyUsername:
            return "Username is empty."
        case .emptyName:
            return "Name is empty."
        case .emptySurname:
            return "Surname is empty."
        case .passwordTooShort:
            return "Password is too short."
        case .passwordsNotMatched:
            return "Passwords do not match."
        case .usernameAlreadyUsed:
            return "Username is already in use."
        case .emailAlreadyUsed:
            return "Email is already in use."
        case .bioTooLong:
            return "Bio is too long."
        case .decodeError:
            return "Data decoding error."
        case .uploadError:
            return "Upload error."
        }
    }
}

These are the error situations we may encounter. There’s more. But I chose to keep it short for the sake of examples. When you see this is an example request.

final class CheckUsernameRequest: FirestoreRequestStrategy {
    var model: RegisterModel
    
    var type: FirestoreRequestType {
        .get(model.username)
    }
    var referance: String = "accDatas"
    var data: [String: Any] {
        model.dictionary ?? [:]
    }
    
    init(_ model: RegisterModel) {
        self.model = model
    }
}

Now it’s time to go into some detail. Let’s start writing our chains.

When we look at our flow, we see that the first chain is the part that controls the username. Let’s create a Check Username Handler for this.

final class CheckUsernameHandler<T: FirestoreRequestStrategy>: SociaHandler {
    typealias Request = T

    var nextHandler: (any SociaHandler)?
    var request: T?

    init(with handler: (any SociaHandler)?) {
        nextHandler = handler
    }

    func handle(_ onSuccess: (() -> Void)?) async -> LocalizedError? {
        guard let request else { return AuthError.requestError }
        guard let model: RegisterModel = request.data.decode() else { return AuthError.decodeError }
        guard model.username.isEmpty == false else { return AuthError.emptyUsername }
        onSuccess?()

        let result: FirebaseResponse<UsernameCheckModel> = await FirestoreManager.shared.request(request)
        if result.status == .error(5) && result.content == nil {
            return await nextHandler?.handle(nil)
        }

        return AuthError.usernameAlreadyUsed
    }
}

Let’s look at what this code does.

• Even if the Handler method does not expect a request, this chain needs a request. So our first check is whether the request exists.
• Afterward, we check whether the model is correct in our request. This way, we know that the content of the request we send will be correct, and if we need it (which we do), we can perform validations on the request body.
• We want to check the username. So, isn’t it necessary to get a username? Let’s check this.
• Then we see a closure called onSuccess. So what is this? I needed to be able to say “The previous transaction was successful, do this before you do your own thing” when triggering the previous chain or the chain itself. Therefore, such a closure was born entirely out of my need.
• Afterward, we go to a service and wait for a response from Firebase. The logic behind the code here is as follows. If no document is found, error number 5 is returned. This is exactly what we want!
• If there is no data, we can write our usage in the next step. That’s why we trigger nextHandler’s handle method.
• Of course, if we did not come to such a conclusion, the username unfortunately does not exist and we return the relevant error to inform our user of this.

Then we can move on to our next step. The next handler of our first chain: AuthHandler.

final class AuthHandler<T: FirebaseAuthRequestStrategy>: SociaHandler {
    typealias Request = T

    var nextHandler: (any SociaHandler)?
    var request: T?
    
    init(with handler: (any SociaHandler)?) {
        nextHandler = handler
    }
    
    func handle(_ onSuccess: (() -> Void)?) async -> LocalizedError? {
        guard let request else { return AuthError.requestError }
        guard let model: RegisterModel = request.data.decode() else { return AuthError.decodeError }
        guard model.email.isEmpty == false else { return AuthError.emptyEmail }
        guard model.password.isEmpty == false else { return AuthError.emptyPassword }
        guard model.rePassword.isEmpty == false else { return AuthError.emptyRepassword }
        guard (model.password.count > 8) == false else { return AuthError.passwordTooShort }
        guard model.password == model.rePassword else { return AuthError.passwordsNotMatched }
        onSuccess?()

        let result = await FirebaseAuthManager.shared.request(request)
        if result.status == .success {
            return await nextHandler?.handle(nil)
        }
        
        return AuthError.emailAlreadyUsed
    }
}

Let’s examine the differences from our first chain.

• Everything is the same, right down to model checking. We need more validation. We can increase or decrease the number here according to our needs.
• Then we make a different service call and register the user. If the registration is successful, the image upload chain begins for us.

final class ProfilePhotoHandler<T: FirestorageRequestStrategy>: SociaHandler {
    typealias Request = T

    var nextHandler: (any SociaHandler)?
    var request: T?
    
    init(with handler: (any SociaHandler)?) {
        nextHandler = handler
    }
    
    func handle(_ onSuccess: (() -> Void)?) async -> LocalizedError? {
        guard let request else { return AuthError.requestError }
        guard request.storageData.isEmpty == false else { return await nextHandler?.handle(nil) }
        onSuccess?()

        let result: FirebaseResponse<String> = await FirestorageManagerManager.shared.request(request)
        if result.status == .success, let downloadLink = result.content {
            return await nextHandler?.handle { [weak self] in
                guard let handler = self?.nextHandler as? RegisterHandler<RegisterRequest> else { return }
                guard var requestModel = handler.request?.model else { return }
                requestModel.imagePath = downloadLink
                handler.request?.model = requestModel
            }
        }

        return AuthError.uploadError
    }
}

This part is quite different. Because we have a different bond with the next chain.

• The main task of this chain is to upload the profile photo and bring us the download link.
• But we will register our user in the next chain and we also need the link to the user’s profile picture. Therefore, when this chain is completed successfully, we attach the link we have to the request of the other chain.

final class RegisterHandler<T: FirestoreRequestStrategy>: SociaHandler {
    typealias Request = T

    var nextHandler: (any SociaHandler)?
    var request: T?
    
    init(with handler: (any SociaHandler)?) {
        nextHandler = handler
    }
    
    func handle(_ onSuccess: (() -> Void)?) async -> LocalizedError? {
        guard let request else { return AuthError.requestError }
        guard let model: UserModel = request.data.decode() else { return AuthError.decodeError }
        guard model.name?.isEmpty == false else { return AuthError.emptyName }
        guard model.surname?.isEmpty == false else { return AuthError.emptySurname }
        guard (model.bio?.count ?? 0 < 250) == true else { return AuthError.bioTooLong }
        onSuccess?()

        let result: FirebaseResponse<UserModel> = await FirestoreManager.shared.request(request)
        if result.status == .success {
            return await nextHandler?.handle(nil)
        }

        return AuthError.uploadError
    }
}

• onSuccess in our new chain now makes sense. The URL of the uploaded image is now included in the model we have. And with this step, the chain is completed.

Now that we’ve written down all the relevant parts, let’s see how to connect them. I created all the models we needed. The basic thing when creating the chain is to start from the end.

struct ChainTest: View {
    @State private var isAlertOn = false
    @State private var chainResult: LocalizedError?
    @State private var isLoadingOn = false
    @State private var isSheetOn = false
    
    var body: some View {
        ZStack {
            VStack {
                Button("Run Chain", action: runChain)
            }.confirmationDialog("Error!", isPresented: $isAlertOn, titleVisibility: .visible) {
                Button("Try Again!", action: runChain)
            } message: {
                Text(chainResult?.localizedDescription ?? "")
            }.tint(.accentColor)
            
            if isLoadingOn {
                VStack {
                    ProgressView()
                }.frame(width: 100.0.responsiveW, height: 100.0.responsiveH)
                    .background(.ultraThinMaterial)
            }
        }.sheet(isPresented: $isSheetOn) {
            VStack {
                Image(systemName: "checkmark.rectangle.stack.fill")
                    .font(.largeTitle)
                Text("Successful!")
            }
           
        }
    }
    
    private func runChain() {
        let registerModel = RegisterModel(username: "ates", email: "test1@gmail.com", password: "12345678", rePassword: "12345678")
        let userModel = UserModel(username: "ates", name: "Mehmet", surname: "Ateş")
        let imageData = UIImage(systemName: "applelogo")?.jpegData(compressionQuality: 0.8) ?? Data()
        
        let registerHandler = RegisterHandler<RegisterRequest>(with: nil)
        registerHandler.request = RegisterRequest(userModel)
        
        let profilePhotoHandler = ProfilePhotoHandler<UploadProfilePhotoRequest>(with: registerHandler)
        profilePhotoHandler.request = UploadProfilePhotoRequest(username: "ates", storageData: imageData)
        
        let authHandler = AuthHandler<AuthRequest>(with: profilePhotoHandler)
        authHandler.request = AuthRequest(registerModel)
        
        let checkUsernameHandler = CheckUsernameHandler<CheckUsernameRequest>(with: authHandler)
        checkUsernameHandler.request = CheckUsernameRequest(registerModel)
        
        Task {
            isLoadingOn = true
            chainResult = await checkUsernameHandler.handle(nil)
            guard chainResult != nil else { return isLoadingOn = false }
            isAlertOn.toggle()
            isLoadingOn = false
        }
    }
}

On the page I created above, our first attempt was successful. Because all validations are smooth and our user registration is open.

But on our second try, exactly what we expected happened. We’ve just created a registration! You cannot use the same username.

To do this, I updated the username, run the project again, and try again. But I forgot one thing. My email is the same and I just created a user with it.

I change this and try again. This time, I see a screen like this.

We have comprehensively examined the Chain of Responsibility and seen what difference it makes in real projects.

• Our code is now definitely fragmented and open to development.
• It’s easy to add a flow in between, at the beginning, or the end.
• It is very easy to update the relevant chain and catch which chain an error occurs in.
• Testability is high.

Summary

We examined the Chain Of Responsibility and managed to perform a string operation in a chain. Now, when I want to add a new piece to Socia’s recording flow, I can create a handler and quickly add it to any position I want in the chain.

Thank you for reading. Happy Swifting.

You should definitely check this out.

Why did I code like this?

My Resources

• HolySwift — Chain Of Responsibility
• Refactoring.Guru — Chain Of Responsibility Article — Example Code

A manager that allows us to manage, write and publish Swift packages in our project. First of all, let’s talk about what we were doing before SPM, then let’s learn how to use it and what it can add to our lives.

SPM is a relatively new technology. For this reason, we were meeting this need with a tool called CocoaPods, which was used before instead of SPM. CocoaPods brought us a lot of things,

• Having to work on .xcworkspace
• Enormous pods folder
• A Podfile in ruby ​​language
• A Podfile.lock file that changes every time it is fetch

and it really wasn’t very good. Let us explain this to you with a real example.

Previously, I was managing many external package dependencies such as Firebase to Socia, one of its very big projects, with Cocoa Pods. And my project had all the files I listed above. And when I met spm and saw that all of its packages were suitable for spm, I decided to make this transition. Below is a commit that shows the changes I made. You can decide 🙂

socia now managed with spm · devmehmetates/Socia@de909f8

My switch to spme has been a huge relief and an incredible reduction in the repo size of my project. Yes CocoaPods is still a good solution you might need. But if you don’t need it, you have to choose SPM.

Now we can learn to use SPM and how to write a Swift package. It’s absolutely incredibly easy on those two counts. Trust me 🔨

Your current packages look like below on xcode. From here you can add packages, delete packages, that is, you can fully manage your packages.

To delete a package, simply click on your package and press the “-” icon.

To add it, you need to press the + key in the same way, then call a package prepared with a url.

That’s how easy it is to add a Swift package to your project. Then you can import the package and use it as you want in your project. Now let’s get to the fun part. Let’s create an Swift package :)

Open Xcode and select Swift Package option below.

Afterwards, we make the developments related to our package under the source folder in the project that is opened.

Then we publish our package on a platform such as github. In this way, our package can now be used by both other people and ourselves.

If the package repository is private, only users with package access via Xcode can use the package.

GitHub - devmehmetates/StickyAsyncImageSwiftUI

Result

In this article we learned how to get rid of CocoaPods using SPM and what it gives us, How we can use it in our Swift packages project and how to create a package. This is a really simple but effective topic. 😍

Thanks For Reading 👀

Good Swift Packages

• Swift Algorithms 🧡, I highly recommend checking out this package.
• Tiny Constraints
• Alamofire
• SnapKit
• KingFisher
• Firebase, also this article can help for this issue.
• Trendyol iOS Components
• Lottie
• SwiftyJSON
• Skeleton View

Resources

Swift Package Manager by Swift.

First of all, let’s look at what the builder pattern is and what it does for us. Creating simple objects is easy. For example, let’s consider a user object with only one property. 📖

// Defination
final class User: Identifiable {
    var username: UUID
    
    init(username: UUID) {
        self.username = username
    }
}


// Example Usage
User(username: UUID())

As you can see, we can create and use it quite simply. What if this class was a car object and branched out to its subclasses?

// Definations
final class Car {
    var engine: Engine
    var wheels: [Wheel]
    var body: Body

    init(engine: Engine, wheels: [Wheel], body: Body) {
        self.engine = engine
        self.wheels = wheels
        self.body = body
    }
}

final class Engine {
    var horsepower: Int
    var cylinderCount: Int

    init(horsepower: Int, cylinderCount: Int) {
        self.horsepower = horsepower
        self.cylinderCount = cylinderCount
    }
}

final class Wheel {
    var size: Int
    var type: String

    init(size: Int, type: String) {
        self.size = size
        self.type = type
    }
}

final class Body {
    var color: String
    var type: String

    init(color: String, type: String) {
        self.color = color
        self.type = type
    }
}

// Example Usage
Car(engine: .init(horsepower: 100, cylinderCount: 4),
    wheels: [.init(size: 20, type: "Low Profile"),
             .init(size: 20, type: "Low Profile"),
             .init(size: 20, type: "Low Profile"),
             .init(size: 20, type: "Low Profile")],
    body: .init(color: "red", type: "Sport")
)

You can see that things are getting more and more complicated. And this is a situation that unfortunately reduces legibility and reduces maintainability after a while. And also remember, you have to reflect these properties in the constructor anyway. What about the Builder Pattern? What if we used the Builder Pattern. What would we gain?💪🏼

• By separating the object creation steps, it makes the object creation process more understandable and readable.
• It facilitates the creation of objects with different properties. Builder classes provide customized build methods for a particular object type, so you can easily build objects with different properties.
• It makes the object creation process more modular. The Builder interface separates the object creation steps into smaller and more manageable parts. In this way, you can customize the object creation process as you wish and have the option to add or remove different steps.
• Provides flexibility in the object creation process. With the Builder design pattern, you can make the object creation process more flexible.
• Using different Builder classes, you can create objects with different properties and customize the object creation process the way you want.
• Increases code reusability. The Builder design pattern uses the same interface for building different objects. In this way, it increases the reusability of the code and prevents unnecessary code duplication.

So what are we waiting for? Let’s do this. When we look at the object, our vehicle is waiting for the engine, wheels and a body from us. With the Builder pattern, we can provide them flexibly.

protocol CarBuilderProtocol {
    func setEngine(horsepower: Int, cylinderCount: Int) -> CarBuilderProtocol
    func setWheel(size: Int, type: String) -> CarBuilderProtocol
    func setBody(color: String, type: String) -> CarBuilderProtocol
    func build() -> Car
}

final class CarBuilder: CarBuilderProtocol {
    var engine: Engine?
    var wheels: [Wheel] = []
    var body: Body?

    @discardableResult
    func setEngine(horsepower: Int, cylinderCount: Int) -> CarBuilderProtocol {
        engine = Engine(horsepower: horsepower, cylinderCount: cylinderCount)
        return self
    }

    @discardableResult
    func setWheel(size: Int, type: String) -> CarBuilderProtocol {
        wheels.append(Wheel(size: size, type: type))
        return self
    }

    @discardableResult
    func setBody(color: String, type: String) -> CarBuilderProtocol {
        body = Body(color: color, type: type)
        return self
    }

    func build() -> Car {
        return Car(engine: engine ?? Engine(horsepower: 0, cylinderCount: 0), wheels: wheels, body: body ?? Body(color: "Undefined", type: "Undefined"))
    }
}

No protocol is required here, but since Swift is a P.O.P language, I chose to write it this way.

What has changed now? Now we are generating car objects through the builder object. This gives us tremendous flexibility for every feature. Like what, let’s see.

// The car object can now be created without any attributes.
CarBuilder()
    .build()
// Can only be created by giving the engine.
CarBuilder()
    .setEngine(horsepower: 400, cylinderCount: 8)
    .build()
// It can also be created by just giving the body.
CarBuilder()
    .setBody(color: "Black", type: "SUV")
    .build()
// Or you can set all the features.
CarBuilder()
    .setEngine(horsepower: 300, cylinderCount: 6)
    .setBody(color: "Black", type: "SUV")
    .setWheel(size: 22, type: "Off-Road")
    .setWheel(size: 22, type: "Off-Road")
    .setWheel(size: 22, type: "Off-Road")
    .setWheel(size: 22, type: "Off-Road")
    .build()

So how much can we improve? We have ready-made cars and do we want to use them? How about a director class, for example.🌞

final class CarDirector {
    var builder: CarBuilderProtocol

    init(builder: CarBuilderProtocol) {
        self.builder = builder
    }

    func constructSportsCar() -> Car {
        return builder.setEngine(horsepower: 400, cylinderCount: 8)
            .setWheel(size: 19, type: "Low Profile")
            .setWheel(size: 19, type: "Low Profile")
            .setWheel(size: 19, type: "Low Profile")
            .setWheel(size: 19, type: "Low Profile")
            .setBody(color: "Red", type: "Sports")
            .build()
    }

    func constructSUV() -> Car {
        return builder.setEngine(horsepower: 300, cylinderCount: 6)
            .setWheel(size: 22, type: "Off-Road")
            .setWheel(size: 22, type: "Off-Road")
            .setWheel(size: 22, type: "Off-Road")
            .setWheel(size: 22, type: "Off-Road")
            .setBody(color: "Black", type: "SUV")
            .build()
    }
}

The Director class is fed with an imported builder class. Thus, any builder with the appropriate protocol can be used. For example, our builder is constantly adding wheels. Instead, we can create a controlled builder and update the setWhell function by adding the wheel if the number of wheels is 4 or less. And that works perfectly in our director class 🤩

Our job becomes easier when we also prepare our ready-made templates using Director. For example, you can connect it to a service and easily create objects that you use all the time. 😎

// Returns a suv car for us.
CarDirector(builder: CarBuilder())
    .constructSUV()

// Returns a sports car for us.
CarDirector(builder: CarBuilder())
    .constructSportsCar()

Result

The Builder pattern, like any busy but beautiful thing, may not be desirable in the first place and may not make a spectacular change instantly. However, it provides great flexibility and strong manageability in a long-term project.

Happy coding everyone. With Swift of course. 🧡

Resources

• Builder Pattern By Swiftbysundell

Also

Thanks also to Volkan Sönmez, who informed and supported me about the subject.

Builder Pattern in Swift was originally published in IBTech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Health problems are very popular nowadays. And developing technologies are trying to support us in this regard. Apple has also not left its ecosystem incomplete in this regard. With the module called HealthKit they have developed, we can use the sensors on the iPhone — iWatch and make health assessments. Let’s learn the basics of this kit.

Before we begin, we have a topic about personal data security, which is one of the things Apple does best. We need to get permission from the user by stating that we need some data.

There are a few simple steps you need to take to do this. After that, everything is very easy.

The first step is to add healthkit under the Signing & Capabilities menu.

Then adding these 3 values ​​to the info plist and giving your message to the user.

After that it ends in code. We get this screen with the code block below.

struct HealthKitView: View {
    var healthStore: HKHealthStore = HKHealthStore()
    
    init() {
        request()
    }
    
    private func request() {
        let typesToRead: Set<HKObjectType> = [HKObjectType.quantityType(forIdentifier: .stepCount)!, HKObjectType.quantityType(forIdentifier: .distanceWalkingRunning)!, HKObjectType.quantityType(forIdentifier: .heartRate)!]

        let typesToWrite: Set<HKSampleType> = [HKObjectType.quantityType(forIdentifier: .stepCount)!, HKObjectType.quantityType(forIdentifier: .distanceWalkingRunning)!]
        
        healthStore.requestAuthorization(toShare: typesToWrite, read: typesToRead) { (success, error) in
            if success {
               // Success
            } else {
                // Error handle
            }
        }
    }
}

We got our permissions. Now let’s explore some of the healthKit capabilities.

• Tracking Physical Activity

One of the most popular uses for HealthKit is tracking physical activity. HealthKit can monitor your steps, distance, and even your workouts. This data can be used to help you set goals and track your progress. You can also use third-party apps, such as MyFitnessPal or Strava, to track your workouts and sync the data with HealthKit.

For example, let’s read the step count data;

let stepsCount = HKQuantityType.quantityType(forIdentifier: .stepCount)!
let startDate = Calendar.current.date(byAdding: .day, value: -7, to: Date())
let predicate = HKQuery.predicateForSamples(withStart: startDate, end: Date(), options: .strictStartDate)

let query = HKSampleQuery(sampleType: stepsCount, predicate: predicate, limit: Int(HKObjectQueryNoLimit), sortDescriptors: nil) { (query, results, error) in
    guard let samples = results as? [HKQuantitySample] else {
        return
    }
    
    let totalSteps = samples.reduce(0, {$0 + $1.quantity.doubleValue(for: HKUnit.count())})
    print("Last 7 days step count: \(totalSteps)")
}
healthStore.execute(query)

• Monitoring Vital Signs

HealthKit can also be used to monitor vital signs, such as your heart rate and blood pressure. With the help of third-party devices, such as blood pressure monitors or heart rate monitors, you can easily track this data and share it with your doctor or other healthcare professionals.

For example, let’s write a screen that prints your beautiful heartbeats on the screen;

import UIKit
import HealthKit

class ViewController: UIViewController {
    
    let healthStore = HKHealthStore()
    var heartRateQuery: HKObserverQuery?
    
    @IBOutlet weak var heartRateLabel: UILabel!
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        // Check if HealthKit is available on this device
        guard HKHealthStore.isHealthDataAvailable() else {
            print("HealthKit is not available on this device")
            return
        }
        
        // Set the types of data we want to read from HealthKit
        let readDataTypes: Set<HKObjectType> = [
            HKObjectType.quantityType(forIdentifier: .heartRate)!
        ]
        
        // Request authorization to read the data types
        healthStore.requestAuthorization(toShare: nil, read: readDataTypes) { (success, error) in
            if let error = error {
                print("Error requesting authorization: \(error.localizedDescription)")
                return
            }
            
            // Start the heart rate observer query
            self.startHeartRateObserverQuery()
        }
    }
    
    func startHeartRateObserverQuery() {
        // Set up the heart rate observer query
        let heartRateType = HKObjectType.quantityType(forIdentifier: .heartRate)!
        heartRateQuery = HKObserverQuery(sampleType: heartRateType, predicate: nil) { (query, completionHandler, error) in
            if let error = error {
                print("Error: \(error.localizedDescription)")
                return
            }
            
            // Get the most recent heart rate sample
            let sortDescriptor = NSSortDescriptor(key: HKSampleSortIdentifierStartDate, ascending: false)
            let heartRateSampleQuery = HKSampleQuery(sampleType: heartRateType, predicate: nil, limit: 1, sortDescriptors: [sortDescriptor]) { (query, samples, error) in
                if let error = error {
                    print("Error: \(error.localizedDescription)")
                    return
                }
                
                // Update the UI with the heart rate value
                if let heartRateSample = samples?.first as? HKQuantitySample {
                    let heartRateUnit = HKUnit.count().unitDivided(by: HKUnit.minute())
                    let heartRate = Int(heartRateSample.quantity.doubleValue(for: heartRateUnit))
                    DispatchQueue.main.async {
                        self.heartRateLabel.text = "\(heartRate) bpm"
                    }
                }
            }
            
            // Execute the heart rate sample query
            self.healthStore.execute(heartRateSampleQuery)
            
            // Call the completion handler
            completionHandler()
        }
        
        // Add the heart rate observer query to the health store
        healthStore.execute(heartRateQuery!)
    }
    
    deinit {
        // Stop the heart rate observer query
        healthStore.stop(heartRateQuery!)
    }
    
}

• Monitoring Sleep

Getting enough sleep is essential for good health, and HealthKit can help you track your sleep patterns. You can monitor how long you sleep each night, the quality of your sleep, and even your bedtime routine. This data can help you identify areas where you need to improve your sleep habits.

You can choose to track your sleep and keep the nights a little shorter :)

import HealthKit

let healthStore = HKHealthStore()

// Request authorization to access sleep data
let sleepType = HKObjectType.categoryType(forIdentifier: HKCategoryTypeIdentifier.sleepAnalysis)!
healthStore.requestAuthorization(toShare: nil, read: [sleepType]) { (success, error) in
    if success {
        // Query for sleep data
        let sortDescriptor = NSSortDescriptor(key: HKSampleSortIdentifierEndDate, ascending: false)
        let query = HKSampleQuery(sampleType: sleepType, predicate: nil, limit: 30, sortDescriptors: [sortDescriptor]) { (query, samples, error) in
            guard let samples = samples as? [HKCategorySample], error == nil else {
                print("Failed to fetch sleep data: \(error!.localizedDescription)")
                return
            }
            for sample in samples {
                let startDate = sample.startDate
                let endDate = sample.endDate
                print("Sleep start: \(startDate), end: \(endDate)")
            }
        }
        healthStore.execute(query)
    } else {
        print("Authorization to access sleep data was denied.")
    }
}

In conclusion, HealthKit is a powerful tool that can help you take control of your health and wellbeing. Whether you want to monitor your daily activity, track your vital signs, manage your medications, or monitor your sleep, HealthKit has you covered. With its user-friendly interface and seamless integration with third-party devices, HealthKit makes it easy to stay on top of your health goals. So why not give it a try and see how it can improve your life? Remember, your health is your wealth, and HealthKit is here to help you achieve it.

Have a healthy weekend everyone ❤

HealthKit Basics in Swift was originally published in IBTech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hello everybody. I’m trying to get back to the articles after a little break. Today I’m going to talk to you about how we can transition to a framework that I love and that I think will have a big share in the future of iOS development.

One framework I’m talking about is, of course, SwiftUI. With the development speed of today’s technologies and the increasing iOS deployment targets, SwiftUI is becoming more accessible for us developers every day. But how ready are we for it? It’s good to stay up to date, so let’s get started.

Components

SwiftUI has its own unique components. In cases where it is insufficient, it allows the use of UIKit and provides a complete result. As an example, we can give the most basic component LABEL as an example.

• In UIKit, a red label is defined as follows;

let label = UILabel()
label.text = "Center"
label.textColor = .red

• In SwiftUI, that’s all.

Text("Center")
    .foregroundColor(.red)

Configuration

• UIKit components are classes. And there are properties belonging to classes. As seen below, it has many variables such as label, text, text Color, font etc.

• You can’t see this in SwiftUI. Because SwiftUI manages them through modifiers. Each view is wrapped in modifiers when it receives its properties such as foregroundColor. You can think of it as having a “Modified Text” object.

So in summary when configuring classes in UIKit. We modify structures in SwiftUI.

label.textColor = .red // It's still the label class.

Text("Text") // It's now a modified struct.
  .foregroundColor(.red) 

Reactive Programming

It contains the basic elements of SwiftUI Combine and with it reactive programming features. Combine can also be used with UIKit, but we generally do not see its use since iOS 13 requires a deployment target. This is one of the advantages of SwiftUI. Let’s try something using a common view model.

import Combine
import Foundation

final class ViewModel: ObservableObject {
    @Published var text: String = "Some Text"
    
    init() {
        DispatchQueue.main.asyncAfter(deadline: .now() + 3) { [weak self] in
            self?.text = "Some text after 3 second"
        }
    }
}

• You can do a very simple bind operation in UIKit as follows.

import Combine
import UIKit

final class UIKitLayoutViewController: UIViewController {
    @IBOutlet var mainLabel: UILabel!
    @ObservedObject private var viewModel = ViewModel()
    private var subscriptions = Set<AnyCancellable>()
    
    override func viewDidLoad() {
        super.viewDidLoad()
        viewModel.$text.sink { textValue in
            self.mainLabel.text = textValue.description
        }.store(in: &subscriptions)
    }
}

• The SwiftUI equivalent of this will be just that;

import SwiftUI

struct SwiftUILayout: View {
    @ObservedObject private var viewModel: ViewModel = ViewModel()
    
    var body: some View {
        Text(viewModel.text)
    }
}

Layout

UIKit offers us 2 options for layout. We determine the placement of the objects on the screen by providing CONSTRAINTS from the code either via the Storyboard or programmatically. I will prefer the commonly used Storyboards in this article.

How do I center a text?

• On UIKit you add a text to the storyboard as seen below. You then give the text the CenterX, and CenterY constraints. Thus, the text is printed on the screen centered.

• In SwiftUI, you just need to add a Text object.

How can I place a text at the top right with 10 px space?

• In UIKit, it will be enough to add top and trailing constraints to text and set top value to 0 and trailing value to 10.

• In SwiftUI, on the other hand, we will need to use Stack structures. A Vstack and an HStack are defined and the desired location is determined with spacers. Then .padding is used to set 10px spacing.

These are really easy cases. Let’s make this a little harder.

How to create a view that lists 10 items on the screen, 4 of which are blue, 4 are red, and the remaining 2 are yellow?

• The UIKit equivalent of this is a tableView. And to do that (we’re a little bit luckier if storyboard is used here) we need to write as much code as below.

• You should also create a cell in the storyboard and connect it to the viewController.

• The SwiftUI counterpart, on the other hand, is really quite simple.

Note: By the way, some people here might say: There is a Compositional Layout, why didn’t we use it?

The event here is the deployment target that is blocking you. If this is going to be iOS 13 above, I think we would prefer to write SwiftUI for such simple structures.

Thus, we have seen how there is a connection between SwiftUI and UIKit. This is how I will proceed by making comparisons, I’m thinking of making a series where we can see the positive and negative aspects of both SwiftUI and UIKit. I hope I can maintain this continuity.

Happy reading, Swift Full Coding 🧡.

SwiftUI Basics for UIKit Developers was originally published in IBTech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Herkese selamlar. Umarım herkesin sağlığı ve keyfi yerindedir. Bugün sizlere geçen yıl atmış olduğum bu;

Mehmet ATEŞ on Twitter: "365 gün boyunca iOS kodlayarak 2022'yi maksimum şekilde değerlendirme kararı aldım. Bu tweeti seri halinde devam ettirerek her gün yaptıklarımı paylaşacağım. Tam 1 sene sonra bu tweete bakıp ne diyeceğimi merak ediyorum :)Repo👇🏼https://t.co/VUGmAvGYyE / Twitter"

365 gün boyunca iOS kodlayarak 2022'yi maksimum şekilde değerlendirme kararı aldım. Bu tweeti seri halinde devam ettirerek her gün yaptıklarımı paylaşacağım. Tam 1 sene sonra bu tweete bakıp ne diyeceğimi merak ediyorum :)Repo👇🏼https://t.co/VUGmAvGYyE

tweet ile başlamış olduğum 365 günlük bir challenge süresince neler yaşadığımı ve bunu nasıl başardığımı anlatmak istiyorum. O halde hadi gelin bu uzun maratonun başından sonuna neler oldu göz atalım 🌞

2021 Eylül ayından bir MacBook alarak iOS developer olma yolunda bir karar aldım. Eskiden Flutter Developer olarak çalıştığım için bana yakın olan kısım SwiftUI’dı ve hızlıca bir kaç eğitimle SwiftUI yazmaya başladım. Bu süreçte bir çok küçük proje ve göz bebeğim olan Health Care’i hem bitirme tezi hemde SwiftUI projesi olarak yazdım.

GitHub - devmehmetates/Health-Care-Public: Health Care gives tips to people about his/her life to be better.

Sürecim iyiydi fakat plansızdım. Bu nedenle ne kadar öğrensem de düzensizlik sebebiyle ne kadar ilerlediğimi bilmiyordum. Daha sonrasında Yusuf Demirci ile yaptığım bir görüşme hayatımın rotasını çok büyük ölçüde değiştirdi. Bana hatalarımı gösterip nerelerde ilerlemem gerektiğini gösterdi, yani ilk mentorüm oldu. Yaptığımız bir başka görüşmenin sonucunda(Bu görüşme tam olarak 30 aralıkta yapıldı 👀) yusuf abininde önerileri üzerine 1 yıl boyunca kod yazmaya ve her gün bunu paylaşmaya karar verdim. Yukarı da bahsettiğim tweet’i attım ve işe koyuldum.

Roadmap’im şu şekildeydi;

• 100 gün boyunca HackingWithSwift’in UIKit kursunu bitir ve hem Swift hem de UIKit için taze bir başlangıç yap. Kendini 0 gibi düşün. Detayları atlama.
• Sonraki 100 gün boyunca yine HackingWithSwift’in SwiftUI kursunu bitir. Bununla birlikte hem arada geçen süre zarfında Swift’ini geliştir ve tekrar et, hemde iş olanaklarını tamamen değerlendirmek için daha fazla deneyim kazan.
• Geriye kalan 165 gün kendini projelerine ada ve iş başvurularına başla. Böylece mülakat tecrübesi kazan ve bu deneyimlerinle kendini geliştir.

Ve bunların hepsini gerçekleştirmeyi başardım ❤️‍🔥 Gelelim bu süreç boyunca neler yaptığıma.

GitHub - devmehmetates/365-day-of-code: A 200-day repository of Swift - UIKit - SwiftUI hosting around 100 projects.

adında bir repo açıp 200 gün boyunca yaptığım tüm projeleri ve yazdığım tüm markdown dosyalarını bu projede topladım. Toplamda 50'ye yakın UIKit, 30'dan fazla da SwiftUI projesi içeriyor.

Ve sadece bununla kalmadım. Elimde tam 165 gün daha vardı. Bunu da değerlendirmem gerekiyordu.

Ve bana harika deneyimler kazandıran bu uygulamarı, hatta çok daha fazlasını yaptım. Her uygulamanın bana farklı bir şey öğretmesini ve çeşitlilik açısından farklı konulardan olduğunu repoları incelerseniz çok rahat fark edeceksiniz.

Bu uygulamaların tamamı SwiftUI ve bu benim iş dünyasına girişimi oldukça geciktiren bir durum oldu. Çünkü yatırımımı UIKit’e yapmamıştım. Ve tam bunu nasıl çözeceğimi düşünürken kodluyoruz ekibinin yapmış olduğu bir Twitter space’ine katıldım. Bir mentorlük başvurusu yaptım ya Beyza Ince ile mentorlük programına başladım.

Bu benim için hayatımın 2. kırılma noktası oldu diyebilirim. Çünkü gerçekten düzenli bir programlamla UIKit tecrübesi ediniyorken, bunu sektörün içinden gerçekten bilgili birinin desteği ile yapıyor olabilmek gerçekten benim için çok büyük bir şanstı. Mentorlük programı boyunca

GitHub - devmehmetates/Dude-Money: An application that allows sharing accounts between friends.

projesini geliştirdim ve harika reviewlar aldım. Bununla yetinmeyip mentorümün desteği ile

• Implementing the Viper Design Pattern in iOS
• Retain Cycle in Swift

bu harika iki makaleyi de yazarak kendimi geliştirmeye devam ettim. Bu makaleler bana teknik becerilerin yanında kendimi daha iyi nasıl ifade ederim, kendimi nasıl en basit şekilde açıklarım sorularının cevabı oldu.

Tüm bu süreçlerin asıl amacı “daha iyi bir kariyer sahibi olabilmek” olduğu için planladığım gibi başvurularımı yapmaya başladım ve bir çok kez reddedildim. Bu benim bazen moralimi inanılmaz bozsa da, beni pes ettirmeye yetmedi. Bu konuma geldiğim an kendi kendime “Bu benim işim değil bir hobim, bunun üzerinden para kazabilmem bunu iş yapıyor olsa da sevdiğim için bunu yapıyorum.” diyerek bu olumsuz düşüncelerden sıyrılmaya çalıştım.

Ve ilk olarak Mobillium’da öğretici bir staj deneyimi yakaladım. Ve bunun hemen ardından QNB Finansbank’da iOS developer olarak işe başladım.

Özetleyecek olursam eğer iOS developer olmak istiyorsanız, ihtiyacınız olan 2 şey var;

• Kod yazmaya yetebilecek bir MacBook
• Ve hiç bir zaman kaybetmeyeceğiniz bir inanç.

Bunlara sahip olursanız ve azimli şekilde çalışırsanız kesinlikle başaracaksanız. Geç olsun ve ya erken, elbet başaracaksınız.

Eğer iOS developer olmak gibi bir planınız varsa benim tavsiyem;

• En başından sonuna kadar kendinize sağlam bi plan yapın ve buna uyun. (Benim planımı da kullanabilirsiniz)
• Belirli aralıklarla birilerinden destek alın. (Bu her şey yolunda gitse bile yapmanız gereken, sizi onaylayacak ya da uyaracak deneyimli birinden istediğiniz ufak bir review olabilir.)
• Çok değil öz çalışın. (Size zaman kazandıracak konu kesinlikle planlamanız. Planlamanız ne kadar iyiyse hedefleriniz o kadar kısa sürede size ulaşır.) (Not: Bu benim tam olarak doğru yapamadığım bir şey. Bu yüzden kaybettiğim neredeyse 2 aylık bir süre!)

Benim yaptıklarım ama yapmanızı önermediğim şeyler;

• Bazı eğitimler benim hiç işime yaramıyor fakat ben yine de planımda olduğu için yaptım. Bunları yapmamak size zaman kazandıracaktır.
• Çok çalıştım. Bu beni gerçekten yıpratan bir durumdu. Verimli olmasına rağmen gerçekten bazen çok bunaldığım anlar oldu. Bu da pes etmenize sebep olabilir. (Burada bahsettiğim gün içinde 12–13 saat aktif kod yazmanın yıpratıcılığı. 365 gün düzenli kod yazmak oldukça keyifliydi.)
• Mükemmeliyetçi olmayın. Öğrenme döneminde olduğumuz için yeni ve güzel şeyler keşfediyoruz ve bunu uyguluyoruz. Bunu çok sık yapmak projenin ilerleyiş hızını çok fazla yavaşlatıyor. Projeye başlayın ve bitirin. Yeni bir projede yeni öğrendiklerinizi kullanın. Böylece hem daha fazla proje sahibi olursunuz hem de elinizde ilerleyişinizin somut bir kanıtı olur.

Kapanışa gelelim. Asla pes etmeyin. Bu medium yazısını genel bir motivasyon ve moral kaynağı olarak kullanabilmeniz için hazırladım. Amacım deneyimlerimi aktarıp yaptıklarım ve sonuçlarını göstermekti. Bir kaç kişiye bile bir faydası olursa çok mutlu olurum.

Herkese Bol Kodlu Mutlu Seneler 🎄

SwiftUI is a great framework that has made things a lot easier since it came into our lives. To use it in the most effective and sustainable way, we must follow a certain pattern. Our topic is design patterns for SwiftUI 💙

It will be a good article series that we will examine 3 design patterns together. Our first stop is MVVM. Let’s get to know MVVM first.

A design pattern recommended by Apple for SwiftUI that works really well with Combine. Consisting of 3 layers, this design pattern consists of:

• Model: Entities we know very well.
• View: Again, the UI we’re very, very familiar with.
• ViewModel: It’s the layer that matters to us that’s available to us with MVVM. The part where both business and logic operations are done.

Now that we have the summary information, let’s look at the relationship between these 3 layers.

Let’s focus on the view model, which is important to MVVM. For a simple request, it does the following in order:

• It is triggered by the View.
• Triggers the service for the request.
• The service sends a request to the API and receives an error or response.
• It transmits the response or result it receives to the view model.
• If the received response is an error, the view model returns an error response to the screen and completes the request.
• If a successful response is received, it parses the model and processes the response.
• Passes the rendered model back to the view as requested by the view.

So how does it work a logic?

• It is triggered by the View.
• It does what it wants in itself.
• Reports the result of the operation to the view.

This is MVVM in its simplest form. Let’s see this in a real project, with real requests, real logic. I wrote an application for this.

Important Note

In order to access the contents in the project, you need to define an api key anywhere in the project as follows. You can get the key here.

struct AppEnvironments {
    static let apiKey: String = "Your Key"
}

GitHub - devmehmetates/MedExp-MVVM: This application was created to answer the question of how we can implement the MVVM design pattern in a testable way with SwiftUI.

Let’s take a closer look and explore the beauties of both MVVM and SwiftUI together. Unit Tests included :)

We have 3 schemes in the application. These;

• Home Screen: Our discovery screen, filling up with multiple requests. The first screen of the application.
• Search Screen: A search screen where you can search for movies and TV shows any way you want.
• Detail Screen: A screen where you can review the contents of movies or series.

We can start with the Home Screen feed.

As you can see, a view consisting of 1 header tabbar and 6 horizontal scrolls. Header tabbar is filled with top 10 items of popular tv content. So it contains 6 requests in total. Network manager throws the requests for us and sends the response or error to the view model.

This network manager I wrote only allows me to send requests and receive responses in accordance with the API I use. Now let’s come to the view model where we use the request function.

• The first place we will concentrate is protocol. It has a dictionary containing our Media Sections, a boolean indicating the page state, and a function to update the page for the sections. It simply means that we will use them in the view and test them. Also, another thing we need to pay attention to is another protocol that our protocol is connected to.
• Since the successful response results of the requests are the same, I wrote a protocol to avoid code duplication.

• We saw that this hooks into our view model. So our ViewModel is actually an observable object. And it publishes the 2 objects it contains in the protocol.
• The second point we need to focus on is exactly here. Because here, when one of the two objects changes, the view is informed about it. It does this by observing the view model.
• In order to do this, it needs to define it as observed in the view. Otherwise it doesn’t make any sense.

• For example, we can see that the loading state directly affects the content of the page. Just look at lines 16 to 20.

Well, we understand the requests. We already have a few more examples to reinforce. Does ViewModel have another task here? YES! All of the above actions happened automatically when the viewmodel was init. Did we mention triggering?

You will see that there is a method defined as Interface properties above. This method will increase the number of pages to load new movies as our horizontal media scrolls scroll sideways and call the function that will make a new request and do this. It’s too long a sentence 😅.

If we think a little bit, we can easily understand that it is an operation that is triggered by the view and takes place in the view model, as it is a situation that needs to be done as you scroll.

There is a nicer place where we can understand this. It’s also Search View. Let’s take a look at it.

Here we see the view trigger much more clearly. Every time our search key changes, the request is made again and the page is updated. And the only good thing that provides this is Observable annotation. Its structure is as follows;

The search key is constantly monitored by the view, and in fact, every hit we make on the keyboard changes that search key. In other words, the search key always changes in the view model and is pressed on the screen again because it is being watched.

Of course, one of SwiftUI’s magic modifiers, the searchable, should also be thanked for doing so :) They may sound complex or very simple. The only truth will be to experience. So let’s do a challenge with you.

The view model of the detail view, which is a view with a very complex structure, is not that clean. Can you refactor this? I did all the things I wanted you to experience in another branch. Let me tell you what you need to do.

refactoring on home view model, update home view and network manager ... · devmehmetates/MedExp-MVVM@7b702e9

First review this commit. You will see that the Homeview model is similar to the DetailViewModel and how I made it clean. Implement this in detail view.

Now fork the project and try doing this challenge. You must create and publish new objects. Maybe you don’t publish and see what happens. Share your refactor on twitter by tagging me 💙. So we can see lots of different codes.

Everything went well, let’s get to the test. You’ll see that we’re going to need some change here. Because Unit tests “are functions triggered?” It clarifies the question in our minds. Results are the task of integration tests. So where do we make changes?

Unfortunately, our project is not very testable in its current state. But we can make it testable. (This required a lot of changes. Please review the differences by switching between branches.)

I’ll just talk about the changes and tests we made for the HomeViewModel. Let’s start.

In HomeViewmodel, we could do our operations directly without defining an object with the singleton property of NetworkManager before. But when it came to mocking, this put us in a snag and made our code untestable. Therefore, I connected the network manager to the homeviewmodel with a protocol and mocked the network manager using the protocol.

Let me explain to you why I did this. We already know that when the HomeViewModel functions run, it throws a request. While doing this, it used to create a Network manager instantly, access its function and then destroy it. That is, the part I had to test was a momentary existence and disappearing with extinction.

With this change, HomeViewModel now has a network manager object and performs all operations on it. In this way, I can create a mock in my tests and perform operations on it. If you look carefully at the tests, it was enough for me to check that the network manager was triggered in all of them. Because the HomeViewModel’s job is to bring us the data.

All this time we talked about MVVM and tests. Want to learn a little about SwiftUI? Let’s look at performance improvements with SwiftUI

I move the cards back and forth. And you notice that some of the images are constantly being reloaded. This is a feature that reduces instant memory usage. And we use it in LazyVStack, LazyHStack, List etc components. On this page, you can experience that the same feature is used in sections by scrolling up and down.

The best optimization I did unconditionally was to install a lazy push system in nagivation. Instantly init the given page destination with SwiftUI NavigationLink. Even if the entire page is lazy, there are 32 instantly init DetailViewModels on this page. We prevented all view models from being created by wrapping this with lazynavigate and creating the view as soon as it is opened. You can access it at the link below.

performance optimization · devmehmetates/MedExp-MVVM@094d58a

Another great feature that SwiftUI provides is redacted. It will automatically make the page look like a placeholder and make it different until your data is loaded.

Everything looks perfect. So could it be better? Let’s decide this together. With Part 2, let’s write a new application with viper design pattern and see what has changed. I will update here when I add the article.

Also my SPM Packages I use in this project :)

• StickyAsyncImageSwiftUI
• SwiftUIAnimatedRingCharts

Don’t forget to follow me to be informed about all my developments and new articles. Happy coding 💙🧡

MVVM Design Pattern For SwiftUI was originally published in IBTech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Memories. Indispensable parts of our technological devices. How well do we manage them as developers? Let’s learn what Retain Cycle is, which is a part of this topic today, and how we can manage it.

Our first topic is ARC

We just said retain cycle, what’s the point of ARC? A.R.C, namely Automatic Reference Counting, is a kind of memory cleaning tool that Apple has presented to us. It cleans up our redundant references and frees us up a good memory. If we write the kind of code that can use it, of course.

If we write the appropriate code, there is no problem anyway. We couldn’t write, or we didn’t know. So what will we do 😱? Let’s see.

I have written a small project for you so that you can experience this beautifully. Please feel free to fork the project and experience it with me.

GitHub - devmehmetates/RetainCycleUIKit

All we have to do is run the project first and go through the pages a few times. You won’t be able to do anything else anyway ☺️.

• For example, go to the last page and then back to the first page. Then click on the button(Debug Memory Graph) shown below.

• Your application will stop. And your Xcode will look like this. See where I’ve yellow-marked below. We are now on the first page, but there are precisely 4 view models in memory.

• For a better understanding, press the button(Continue) I marked in red and let the application continue. Then repeat the first navigate operation 2 more times. And click the Debug Memory Graph button again.

• Our number has reached 10! So why 10 do you think? Our first page in existence has never died. But the 3 pages we created by going forward died every time we came back. We repeated the process 3 times in total and since we have 3 pages, we have created 9 view models. Of course, the view model of our first page that never died. Thus, a total of 10 view models are currently kept in memory. Nightmare.

So far, I hope you understand everything. If you don’t understand, repeat the steps and continue until you do. So let’s continue. What caused this?

The above code is common to all view controllers. They all init a view model.

All view models derive from a single class and require a view reference to itself in the common view model. This means that for us.

View controller has view model and view model has view Controller 🤯. And yes! Now you know what retain cycle.

Okay, but there is a way out of this, right? Because this is really scary. Of course there is. With only a one-word type designation. Let’s learn the bride types first and then get rid of this scourge.

Reference types are divided into 3. Shall we meet them?

• Strong: I am a strong reference 💪🏼. Whether a class holds me or not, I keep that class. And I won’t be lost until you destroy me. (Currently, we have two classes of this type.)
• Weak: Hi I’m weak reference 🥲. If a class doesn’t hold me, I don’t exist. I live with it, I die with it.
• Unowned: Hi, I’m unowned 🤐. I expect a class to hold me. But if you want to use me, make sure I go before the class holding me. If you don’t I will crash your app 😵.

Which one do you think we should use? Our type is strong anyway so we need to use it. Weak or Unowned? Let’s try both in our case.

Let’s start with the Weak. Open the CommonViewModel as below and set the view to weak.

Run the application again and go to the last page 3 times in the same way and come back. Then open the Debug Memory Graph.

Fantastic. We are currently on the first page and only one view model is in memory, just as we wanted. Also there are 9 outputs in the debug logs.

Hi, Am i dead? Yes :( //Page 3
Hi, Am i dead? Yes :( //Page 2
Hi, Am i dead? Yes :( //Page 1
Hi, Am i dead? Yes :( //Page 3
Hi, Am i dead? Yes :( //Page 2
Hi, Am i dead? Yes :( //Page 1
Hi, Am i dead? Yes :( //Page 3
Hi, Am i dead? Yes :( //Page 2
Hi, Am i dead? Yes :( //Page 1

So how did this happen? Our View models have a deinit function that will do this print every time it disappears. So it only works when they die. Since we defined it as weak, view now holds the view model. And so when the view dies, the view model also dies. Well, it’s great.

Now let’s try the same for unowned. The result will be the same. But let’s change one more thing and understand the situation better. Let’s write a deinit function inside the whole view controller.

Like this. And then let’s go to the last page and back to the first page. Repeat this time only once.

This is how we will see the Debug console. As you can see, the view I gave as unowned dies before the viewmodel, so the application runs smoothly without any problems.

How about a little reinforcement? 🧐

We have 2 more branches to understand the subject better. You can switch to them as follows. (Or you can make changes from a git-client of your choice and examine the code.)

First, let’s move on to our bonus branch. What did we change? You can view them all here, but I’ll summarize.

common viewModel now really common · devmehmetates/RetainCycleUIKit@db3f585

What I did was create a view model on root and distribute it to other views. And the view model could never be created again because the root page never died. In this way, even though I did not specify weak or unowned on the view model, the retain cycle did not occur.

Let’s take a look at bonus2, too. The only thing I did here was to create the view model I shared in page1, not root. Again all the changes are here.

common view model init place changed · devmehmetates/RetainCycleUIKit@718f022

So what did that change? Creating and sharing a view model in Page1 has reduced the number of retain cycles that occur, but it will continue to occur as long as I don’t use weak. Because page1 can die and therefore the view model is unfortunately freed in memory.

In summary, weak or unowned are very important types that we should use in such cases. But it is also very important that we use it in the right place and in the right way. This is something we can get by experiencing a lot of things 🦸🏼.

Closing

We discussed the subject of retain cycle, which is a very complex subject to explain as well as to understand. I hope everything is clear in your mind. See you on future issues. Happy coding, with Swift 🧡.

Resource(s)

• Apple ARC Document

Retain Cycle in Swift was originally published in IBTech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Design patterns! In the software world, they are indispensable for us to be able to work on sustainable code bases that prevent us from writing code on our own. What about Viper? It’s a popular design pattern we use to develop iOS apps. So, let’s get to know it better and embark on a long-term adventure.

View, What else could it be? The layer that contains the User Interface elements and can only communicate with the Presenter.

Interactor, This layer connects us to real life and again only communicates with the presenter.

Presenter, Viper’s apple of the eye. The layer where everything happens. In short, our bridge connecting all layers.

Entity (Optional), Our models. Seriously only models. Our structs or classes.

Router, Viper’s bigbang. Our brave layer is in charge of the creation of the module and all layers (including itself).

We met our layers. Yes, yes they are also very pleased to meet you. So we are ready to answer this.

Why should I or should I not use Viper?

No slander or praise here. There are only facts.

Let’s start with the positives.

• Viper is incredibly testable.
• Viper provides the code layout very well.
• Readability is very high.

Let’s look at the downsides.

• Viper is very bulky. Too many layers too much time!
• It is complex. You can get lost in folders. Or you find the exact path.

Check out these items now.

• You want to release an app quickly. Really fast. For example with SwiftUI. It would be better not to use it.
• You have embarked on a huge project with UIKit. It needs to be tested. Definitely use it.

Understanding the VIPER

Viper is a headache if you’ve never done protocol-oriented programming. But once you get used to it, it goes away. This article is for exactly that. Let’s roll up our sleeves and get started.

I wrote an application for this, while you are reading the article, you can examine it and follow how the code works.

GitHub - devmehmetates/Viper-Example

I think our first job is to complete the view layer that we always do. Here I created a simple list view using the compositional layout of the UICollectionView. Even doing this I will need the Presenter but for now let’s do it in the view controller.

View

The code you see below is definitely not suitable for Viper ❌

The above code gives the same output. Cells have been successfully created and a base has been prepared. Now let’s pass this code to Viper by keeping the view fixed. As I mentioned earlier, Viper uses P.O.P quite actively. Therefore, we define all view operations in the presenter in the interface of the view. The purpose of this is to be able to access from the presenter. Let’s take a look at the edited version.

Viper solution ✅

You are looking at a huge piece of code and you may not understand what would have changed. First of all, make sure that this code gives the same output. We currently have a presenter that does not appear in the background, and this can be confusing. But worry not! Everything will be clear soon.

• The first change, of course, protocol. We added 2 functions and defined in ViewController. What we need to do now is to call it in the presenter wherever we need it. This is currently presenter.notifyViewDidLoad()
• The second change is the numberOf functions. These functions may vary by server or local services. So this number should be passed to the view by the server. This way, if there is a change, the view can be aware of it.
• The last change is the setTitle function. The reason for transferring this to the presenter is actually the same. Because we can set this by the services.

As you can see, what we’re actually doing is separating all logical operations. And at the same time, we have written code for the future. Although this slows it down at first, it will speed up a lot in the future. And remember. The view is not finished yet. Now let’s write a service and create our Interactor layer.

Interactor, Service, and Entity

Since these are related to each other, it would be best to process them together. Interactor connects with the service and processes the model for us. We will have a very simple model and a service tasked with reading it.

As you can see, we have a fairly simple model and registration system. It has functions for both reading and writing. To get the point across, think of it this way, this is the layer where we communicate for backend operations. We fired exactly one request and we’re getting an array back.

As you can see, nothing complicated. We first recorded our data and then read it. Thus, Interactor fulfilled its own responsibility. Now let’s come to where everything connects, namely the Presenter.

Important note: You can ignore line 16 here. Its only purpose is to create a data for you on the first run of your application. If you want, fork the application, run it once and delete this line. The result will be the same.

Presenter

We’ve really come to the layer where almost everything happens. This layer should now look like this.

Slow down here!! This layer is the most important layer for the viper, and we have questions to ask. These are the questions we will ask why. Let’s explain our layer slowly.

See the protocol. It has all the functions we use on the view controller. It is defined in the interface setup and it is clear what they do. Perfect!

Take a look at the NotifyViewDidLoad function. “view?” We see the expressions. These are actually the functions in the interface of the viewController that we made at the beginning. And they are triggered in the presenter and work great. Everything seems to be explained. Now let’s move on to our questions :)

• Why are variables private? The reason is that the variables represent our classes. And it wants us to perform viper logic operations on the presenter. If we leave it to public access, we can directly access the router or interactor through the ViewControler. We shouldn’t be able to do this.
• Why is the view weak while the others are strong? The reason is the retain cycle. The presenter is defined strongly on the view controller. If we also define view as strong on the presenter, these two classes will never leave each other. And that’s a lousy experience for our memory management. What about the others? Do you think this applies to the interactor? Presenter is not even defined. If we keep it weak, the interactor will not be able to find a branch to hold on to and will disappear :(
• Well, I understand the classes, but why is datas private? Remember it’s there for presenter logic. This is related to our first question but not exactly the same. If we open this data as public, we are more likely to “inadvertently” perform logic operations on the View Controller. Like getting the first data :)

I think we got through the hardest part of the job. If you are confused about the retain cycle, I suggest you look into it. Now then, we can create our final layer and make our final edits.

Router

This is where the whole page starts. It will create all the layers and give a view for us. It should look like this for now.

Come on, what is this? Why is the protocol empty? Why do we keep it empty? In fact, it’s completely ready for use when we need it, for the reason. And remember, the presenter is created through interfaces. Classic init operations and a fallback viewController.

But, then the router is ok too. Where and how will I use it? I prepared a tab bar controller for you. Of course, it was created with viper too. We have to do something in the tab bar controller. Like initializing the ViewController?

Don’t get confused here. Just focus on line 18. We saw our router. We have run our function. And we started a Viper Flow. Now all the codes we wrote are active.

Final Touches

We have done a lot of operations, but we still haven’t processed our data into the view. Now it’s time to define our view. There are only 2 steps we need to do for this.

• The first is to get the data by index in the presenter.
• The second is to use this data in the cell configuration.

protocol HomePresenterInterface: AnyObject {
...
   func getDataByIndex(_ index: Int) -> BaseModel?
...
}

Let’s add this function to our protocol. So we can get a base model by index. Xcode should be mad at us the moment we add this.

Let’s complete the function without further angering Xcode.

func getDataByIndex(_ index: Int) -> BaseModel? {
   datas?[index]
}

Good, now let’s come to the view part.

cell.configureLabels(with: presenter?.getDataByIndex(indexPath.row))

As you can see it is one line and works flawlessly. Now let’s open our application. We should be seeing our data.

Fantastic! Thus, we have completed our application. Of course, if we wrote Viper, not if we didn’t write tests for our app. Come on, you’re not tired. Let’s also write our unit tests and it’s all over.

Unit Tests

We’re going to do a few really cool things for this part. I want you to review this link. I think you can install it easily. It’s pretty simple. If you have successfully completed the installation, let’s include our project and continue. Before that, let me explain why we do this.

We copy the classes to be tested with the mock concept, and thanks to the generator we have set up, we can perform the test operations in seconds with the help of protocols. So let’s do it.

Are we suddenly stunned? Don’t worry, this is a file that you will create automatically. So it was created by the mock generator linked above.

If you don’t understand how it’s done this way :)

Now let’s talk about why we create it and how we will use it. Take a look at the interactor file to remember. There is only one variable in the protocol. And in the mock file, the variables required for testing this are kept. It’s normal to be confused here. Now, when I create a unit test and elaborate on it, you will understand it very clearly.

Here you may notice that other classes have mock classes. Except for presenter only. We named it Viper’s apple because we do everything here. We named it Viper’s apple because we do everything here.

Now understand this phrase. By giving our mock classes to the router, we enabled the layers defined in the presenter to be mocked. In this way, the view class triggered via the presenter will be Mock and we will be able to test it. Because the purpose of unit tests is to check if a function triggers a class.

Super, now let’s review our test. First, the presenter function is called and the view mock class is triggered. so the variable in our mock class changes and our test is successful. Let’s take a closer look at this function.

func testNotifyViewDidLoad() {
    homePresenter.notifyViewDidLoad()
    XCTAssertTrue(homeView.invokedSetupView)
    XCTAssertTrue(homeView.invokedSetTitle)
}

In our first line, we trigger a function from the presenter. This function is exactly like below:

func notifyViewDidLoad() {
    view?.setupView()
    view?.setTitle(with: "Home")
    fetchDatas()
}

As you can see, our function is triggered by 2 functions defined in view. Here are the functions in our mock class! For this reason, we go and check that the variables in our mock class are true so that we can make sure it is triggered. This is our target. To see it much more clearly and understand the event, you can update the function yourself as follows and renew the test.

func testNotifyViewDidLoad() {
    XCTAssertFalse(homeView.invokedSetupView)
    XCTAssertFalse(homeView.invokedSetTitle)   
    homePresenter.notifyViewDidLoad()
    XCTAssertTrue(homeView.invokedSetupView)
    XCTAssertTrue(homeView.invokedSetTitle)
}

The test will still be successful

Closing

And you entered the world of viper with fast steps. Fork the project so that this entire article comes to mind. Then play around and try to discover the changes.

There are a few situations I want you to experience.

• To better understand the concept of weak on the presenter, add and delete weak. Keep track of references and objects with Breakpoint.
• Edit the Interactor, Entity, and Service. The stage is yours. Can you print a data from the Internet like this? It would be nice to have things sortable :)
• Create a sorting algorithm. This will make it clear how you use the presenter.

You did all this. And you want to make sure it’s correct. Don’t worry, of course I’ve thought about this as well. Check out the branches! You will see a branch named advanced. Go checkout and check your solutions.

Note

In the advanced branch, the application will appear in this state. The data comes and is updated entirely over the internet. There is so much you can improve even more. You can try :)

Resources

An article that I definitely recommend and take as an example.

I would also like to thank my mentor who supported me while preparing this article 🥹

Implementing the Viper Design Pattern in iOS was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.