Previously on Implementing DDD, We briefly mentioned that we have so much Models, Domain Models, View Models, Plain Models, Data Models and seems like Models is just a generic word…

And how adding more context feels beneficial over time.

Why are we writing about DDD again?

Answering the “Where” about writing your logic

Well… Quoting before in the Architecture Homicide series, I stand firmly by this quote

"Software Design is all about knowing where to put what"

Being Domain-Driven and being exposed to its concept gives you a better idea about where things should be, being an iOS Software Engineer, the question of “Is this Business or Presentation Logic” is very biased towards putting more logic into Presentation Layer.

Which ends up making your Domain Logic more empty… when it should be the other way around, and this tends to shine when you need to reuse a piece of logic, only to find it being too coupled to its current implementation, so you end up being lazy and just pick the “copy-pasta-driven development”

Tightens the gap between the Tech & Business

Well… all our code, dandy refactoring, shiny new stuff are there to serve one purpose, which is… providing, solving, benefitting our Business, and to do so, you need to understand more about the problems, live them, and breathe them…

Well probably you wouldn’t be able to, but sometimes you are lucky enough to have what we call…

The Domain Expert

We also touched base a bit previously on the Domain Expert, saying things among the lines of someone who has deep knowledge and experience within a specific subdomain of a business rather than the entire industry.
While they may not know every detail of the broader business landscape, but they understand the intricacies of their specialized area like the back of their hand.

Example: Real Estate Agents

A real estate agent who focuses on specific neighborhoods or towns knows everything about the pricing trends, local regulations, and buyer-seller behavior in that area. However, they might not be familiar with real estate practices in another city or country. This specialization allows them to provide highly accurate insights and make better business decisions within their domain.

But what about us? Software Engineer Folks?

Well, Product/Project Managers often act as domain experts, translating business needs into tech requirements. But hey! we can be Domain Experts ourselves too!

When we deeply understand the product, customer pain points, and the problem space beyond just code.

Heck, sometimes you’re that long-standing person in the team, you’ve seen the codebase being re-written twice, face rigorous changes, people coming & leaving, making you the expert around the codebase

But, you can be that one expert as well who owns let’s say the Payment Service, you’re aware of interchange fees, chargeback rates, and fraud detection strategies, Idempotent APIs & real-life problems that are not immediately clear to others who lack experience.

This makes you a far more valuable individual than one who just implements payment APIs without context.

The Ubiquitous Language

At first glance, Ubiquitous Language might seem like a fancy term for “common language.” But in Domain-Driven Design (DDD), it’s much more—it’s a shared vocabulary that aligns everyone, from developers to business stakeholders, ensuring clarity and consistency when discussing the domain.

So Why the fanciness, Why is it so Important?

Well… excuse the french, but in a company with different departments, engineering, product, marketing, design, data… they all talk about the product, right?

but each often speak different dialects, different linguistics of the same language.

For example, speaking of our normal end user of the system (any system).

• Marketing calls it “a lead.”

• Product calls it “a potential customer.”

• Engineering calls it “a user.”

• Data science calls it “an entity with attributes X, Y, and Z.”

Without alignment, miscommunication happens:

• Marketing says: “We need to track leads.”

• Engineering builds: “A system that tracks sign-ups.”

• Marketing: “No, we meant people who showed interest but didn’t sign up yet.”

• Engineering: “Wait, that’s different?”

You see where the problem is, right?

This gap leads to wrong assumptions, wasted development cycles, and business misalignment. Ubiquitous Language ensures that when we say a term, everyone understands exactly what it means.

Which takes us to a very important part…

DDD is never about just how you write code, DDD is like Agile, it starts way back before any line of code is written, it starts at the problem first, understanding it, aligning over our grasp of it, if you deal with it as a purely technical book, it would fail you.

When “User” Becomes a Problem

Ahh… the “User” model… every iOS codebase has one of those

“User” is one of those vague, overused words that mean different things in different contexts. Consider a Food Delivery App:

• A pilot delivering food is a user.

• A customer waiting for food is a user.

• A restaurant owner managing orders is a user.

• A moderator handling complaints is a user.

If we define all of that under one big umbrella and give it a name “User”, then boy we’re basically on a recipe for a bloater

Isolating Contexts Helps

Instead of just “User,” we define context-specific roles:

• Customer – Places orders

• Courier – Delivers orders

• RestaurantOwner – Manages a restaurant

• Admin – Moderates disputes

This opens up our system to an interesting way of developing, type-driven development, where in short, the type Customer is only allowed to do specific sort of actions, which are only available to Customer, while for example, a customer can’t manage a restaurant

But this takes me to another question actually…

Not necessarily. In Authentication & Permissions, or sometimes “Identity”, “User” often refers to a system-wide entity with login credentials, sometimes access level to do a certain tasks. But in Domain Modeling, it’s better to give meaningful names to roles and entities, not only for the sake of avoiding confusions, but this allows us to rationale better about the context of this entity.

For example:

• User (Identity Service) → A system account.

• Customer, Courier, Admin (Domain Layer) → Roles with different behaviors.

This separation avoids ambiguity while maintaining the flexibility of a unified authentication system.

Isolating Contexts & Creating Them

One of the core ideas in DDD is that a business is not one monolithic model, but rather multiple bounded contexts with their own language and rules.

Example: A Marketplace App

• The Buying Context uses terms like Cart, Order, Checkout.

• The Selling Context uses terms like Listing, Inventory, Earnings.

• The Delivery Context uses terms like Courier, ETA, Drop-off Location.

These contexts might talk to each other, but they don’t share the same meaning for every entity. An “Order” in the Buyer Context is a purchase, while an “Order” in the Courier Context is a delivery task.

Conclusion

We touched-base about Bounded Contexts a bit, but starting from the next blog, we will be more focused over having a simple project where we start learning more about the book in flexible manner

That’s a question to ponder about, so until next post!

This time, I reeeeeally wanted to re-inforce my learning from “Implementing Domain-Driven Design” book as a way of documenting my learning journey with the book!

So, let’s get started already! 😆

Brief about DDD Introduction

First let’s discuss what’s Domain-Driven Design, Domain Expertise and then move from there to the Development part, our part!

What’s a Domain

So, what’s a domain?

Nope, not this

A domain, is a problem, like in CAFU, FUEL delivery, that’s our Core Domain, where each of our work one way or another revolves around, affects, branches out of it

Subdomain? What’s that again?

So yea, we did mention that a domain represents a problem, but as you might have guessed, a Subdomain is like part of that domain, hence the “Sub” part prefixing the word 🤷‍♂️

Okay, but still, why is that a thing you might ask?

“because a lot of software developers think it’s clever to bake everything possible into one system.”
— Vaughn Vernon “Implementing Domain-Design”

Well… yea, exactly, seems familiar to the SRP a bit, but breaking domains down into subdomains make the problem you wanna solve more manageable, and simpler, but to do so, this requires severe understanding of the problem/domain you’re trying to solve/improve, and usually requires an expert, a Domain Expert!

Who’s the Expert? The Domain Expert!

being Domain-Driven, is all about living and breathing FUEL Delivery, knowing the customer’s pains, knowing the pilot’s pains, knowing very well what problems a customer may face, and what he thinks about when he faces them, and hence, be able to solve problems that are related to your domain

Familarizing yourself with the processes around delivering fuel, and hence become a Domain Expert

A domain expert may not specifically be us programmers/engineers, we have the product team for that, we have the founder, or probably someone we may have never met, however, having that person in your team and absorbing his knowledge about it, massively allows you to understand the domain and take better technical decisions

Why is this important?

When we start working, we need this guy. This is a person whom we depend on while developing, planning, and designing because at the cornerstone of our work, it’s very important to think about the problem and learn its edges and angles, so when we start developing (providing a solution), we make sure we solve the problem correctly

And when we try doing TDD or BDD, our domain knowledge allows us to formulate better acceptance criteria, which may translate to better test cases or better behavior with better integration tests, better challenging to the requirements, better suggestions and designs that really clicks with our users in terms of UX

Enough, We’re here for MODELS!

So, coming from this brief background, as this will serve future blog entries, let’s go back to square 1

MVC, we get the View, we get the Controller, but why or what the heck is a model, and why is it called “THAT”?

This was actually discussed in Head First: Design Patterns, MVC section

The book goes by explaining the fact that no one liked the word “model”, because it didn’t make sense

A Model for what? is it the feature? is it the View? Is it some logic, or what???

What exactly is a Model?

A Model is best described as, a "simplification", an interpretation of an abstracted real "thing", often you'd hear it at first as a "blueprint" for something that would solve a problem at hand, without caring much for details outside what it means

For example, the MVC recommended by Apple, regardless of the communication directions or patterns it suggested (be it notifications or delegates), it described logic. If you watch the first 3 videos of CS193P on YouTube, you will indeed find that the ‘M’ here is a place for logic, purely logic

Does that make it a “Logic” Model? maybe, does that make it a helper Model? Maybe

But in the terminology of design, this can go as the following names

• Domain Model

• Usecase

• Interactor

• Logic Controller

But what should we call it?

What to call a model?

According to Vaughn Vernon's "Implementing Domain-Driven Design," it's essential to differentiate between the execution of business logic and the domain model itself.

A domain model should:

1. Be focused on representing business concepts.

2. Be independent of specific application logic.

3. Capture the essence of the problem domain.

In contrast, application logic (e.g., workflows, orchestration) belongs to application services, which interact with the domain model to achieve business goals.

Key Takeaways

Understanding the distinction between domain models and application services allows us to:

• Keep our domain logic clean and focused.

• Ensure our application is flexible and easier to maintain.

• Align our code with real-world business needs.

I’m seriously surprised I’ve followed through. But hey, whenever the magical words Software Design, Optimization, Time-saving, and Automation get thrown into the mix, my gears start turning. We’re about to merge everything we love—Command Patterns, reuse, composability, and… Siri—for a healthy dose of engineering craziness.

In our previous post on the Command Pattern, we explored how the pattern looks in both MVC and MVVM, using UIKit and SwiftUI. We discussed how it helps us avoid the dreaded “Massive View Controller,” and how easy it is to shape everything like Legos to create reusable, composable building blocks. Perfect for containing your precious business logic in a tidy package.

Siri as a New UI (Looking at It from the Right Angle)

Today, we’re highlighting how Siri can become a new UI if you think about it from the right angle. With iOS 16, Siri can be managed via AppIntents—more flexible than ever—and the same code can also be used with the Shortcuts app.

If you were to say, “Hey Siri, use my app to fuel my car,” you could hook into your internal business logic that’s already wrapped inside a Command Pattern. That means Siri is basically another entry point to a well-structured domain. Let’s see how.

AppShortcutsProvider: Teaching Siri What to listen to

Below is a snippet of how you can register shortcuts with Siri. You create an AppShortcutsProvider, define the phrases users might say, and supply an Intent for Siri to call.

@available(iOS 16.0, *)
class SiriShortcutsProvider: AppShortcutsProvider {
    static var appShortcuts: [AppShortcut] {
        AppShortcut(
            intent: OrderFuelIntent(),
            phrases: [
                "Fuel my car",
                "Fuel my car at \(.$location)"
            ],
            shortTitle: "Order Fuel",
            systemImageName: "fuelpump"
        )
    }
}

OrderFuelIntent

struct OrderFuelIntent: AppIntent {
// ...
    static var title: LocalizedStringResource = "Order Fuel"
    static var description = IntentDescription(
        "Quickly make a Fuel Order with Previously Used Vehicles and Fuel Settings based on latest Order at Home or Work",
        categoryName: "Fuel Ordering",
        searchKeywords: ["fuel", "order"]
    )

    @Parameter(
        title: "Location",
        requestValueDialog: "Where should the order be?",
        optionsProvider: SiriIntentLocationOptionsProvider()
    )
    var location: Location
// ...
}

Here, location is a parameter that Siri will prompt for when needed. Once you’ve set up the necessary data, your perform function is where the magic happens.

Adding the Location Enum

Below, you can see how we define the Location enum so Siri knows what “Home” or “Work” actually means in your domain model:

@available(iOS 16.0, *)
enum Location: String, CaseIterable {
    case home = "Home"
    case work = "Work"
}

// MARK: AppEnum

@available(iOS 16.0, *)
extension Location: AppEnum {
    public static var typeDisplayRepresentation: TypeDisplayRepresentation {
        TypeDisplayRepresentation(name: "Order Location")
    }

    public static var caseDisplayRepresentations: [Location: DisplayRepresentation] {
        [
            .home: DisplayRepresentation(title: "Home"),
            .work: DisplayRepresentation(title: "Work"),
        ]
    }
}

@available(iOS 16.0, *)
extension Location {
    func mapToDomainModel() -> AddressType {
        switch self {
        case .home:
            return .home
        case .work:
            return .work
        }
    }
}

Closer look at the perform() function

Wait a minute…, when you look at the perform function

    func perform() async throws -> some IntentResult & ProvidesDialog {
        // Logic Execution here
    }

It doesn’t have any parameters, it executes logic based on the struct’s parameters… this looks familiar

This looks like our AsyncUsecase from previously on Patterns!

struct FetchPaymentMethodsUsecase: AsyncUsecase { 
    func execute() async -> Result<[PaymentMethod], BusinessError> {
        // 1. Fetch payment methods
        // 2. Fetch wallet
        // 3. Preselect a favorite
        // 4. Disable unsupported methods
        // 5. Add Apple Pay (if supported)
    }
}

When you call execute(), this use case already knows what to do. Siri’s perform() method is basically the same structure—it even returns a type that’s constrained to IntentResult.

Putting It All Together with Siri

When you think about it this way… perform can be a gathering ground for all the usecases to formulate new functionality!

func perform() async throws -> some IntentResult & ProvidesDialog {
    // Step 1: Update session with the selected delivery address
    await UpdateUserAddressUsecase(newAddress: location.asDomainModel())
        .execute()

    // Step 2: Fetch the fuel type for the selected vehicle (98, 95, Diesel, or EV)
    let fuelType = try await GetFuelTypeForVehicleUsecase()
        .execute()
        .mapError { SiriIntentError(reason: $0.errorMessage).whileLogging() }
        .get()

    // Step 3: Fetch the selected vehicle
    // session is a means of Dependency Injection to mark user's selected preferences
    guard let vehicle = session.selectedVehicles.first else {
        throw SiriIntentError(reason: "Couldn't find your selected vehicle")
    }

    // Step 4: Fetch the payment method
    guard let paymentMethod = payment.session.availablePaymentMethods
        .first(where: { $0 is SiriPayable }) else {
        throw SiriIntentError(reason: "Couldn't find a Siri compatible method to pay with")
    }

    // Step 5: Set up the order with a full tank of fuel
    let fuelQuantity: Quantity = .fullTank
    let product = CAFUProduct(fuel: fuelType, quantity: fuelQuantity)
    session.order.products = [product]

    // Step 6: Get the nearest available time slot for fuel delivery
    let timeslot = try await NearestTimeSlotUseCase(variantId: fuelType.variantId)
        .execute()
        .mapError { SiriIntentError(reason: $0.errorMessage).whileLogging() }
        .get()

    product.timeSlot = timeslot
    payment.select(paymentMethod: paymentMethod)

    // Step 7: Create a new order
    try await CreateOrderUsecase()
        .execute()

    // Step 8: Display to the user the order summary
    try await requestConfirmation(
        result: .result(
            view: OrderSummaryView()
        ),
        confirmationActionName: .order,
        showPrompt: false
    )

    // Step 9: Place the order after confirmation
    try await PlaceOrderUsecase()
        .execute()

    // Return success message
    let confirmationMessage = "Awesome! Your fuel order has been placed."
    return .result(dialog: IntentDialog(stringLiteral: confirmationMessage))
}

Notable Observations

1. We rely on multiple use cases (Commands) such as UpdateUserAddress, GetFuelTypeForVehicleUsecase, etc.

2. Each use case has a single execute() method which encapsulates a distinct piece of business logic.

3. Siri calls perform(), which, in turn, calls our chain of commands. This is the definition of modular and reusable code.

How does it look like?

Now About Testing 🧪

One of the biggest advantages of using the Command Pattern (and a clean architecture approach) is how testable it all becomes. Here’s how you can tackle testing at various levels:

1. Testing Each Use Case

• Unit Tests: For each use case (e.g., GetFuelTypeForVehicleUsecase, UpdateUserAddressUsecase), you can write straightforward unit tests that verify the business logic in isolation.

  • Mock Dependencies: If your use case depends on a repository or a network service, inject a mock or fake. This ensures you test the logic without hitting a real backend.

  • Error Cases: Test how each use case handles different failure scenarios (e.g., “No internet,” “Invalid vehicle ID,” etc.).

func testGetFuelTypeForVehicle() async throws {
    // Given
    let vehicle = Vehicle.stub(...)
    let sut = GetFuelTypeForVehicleUsecase(vehicle: vehicle, repository: MockFuelRepository())

    // When
    let result = await sut.execute()

    // Then
    switch result {
    case .success(let fuelType):
        XCTAssertEqual(fuelType, .gas98)
    case .failure(let error):
        XCTFail("Expected success, got \(error) instead")
    }
}

2. Testing the Siri Integration

• Integration Tests: Since Siri’s perform() acts as an entry point that orchestrates multiple use cases, you can run an integration test to confirm that everything plays nicely together.

  • Mock the Siri Environment: Apple doesn’t provide a direct unit test harness for SiriKit or AppIntents in Xcode. However, you can abstract away the domain logic from the Siri layer. Then, test the domain logic in a normal Xcode test target.

  • Automated UI Testing (Optional): If you want to test the voice-driven flow, you might consider an automated test setup (like UI tests), but that can get tricky. Usually, verifying your domain logic + making sure your Siri Intents are valid with the “Shortcuts” integration is enough.

3. Testing the Flow with Dependency Injection

• Dependency Injection: Notice in the example code, we keep referencing session or payment. In production, these might be singletons or injected services. For tests, you can provide test doubles—like TestSession or MockPaymentService—to control the data.

• Verifying Side Effects: If CreateOrderUsecase triggers a network call or updates a database, you can check your mock objects to see if the correct methods were called with the right parameters.

Conclusion

The Command Pattern is powerful. By encapsulating each piece of business logic into its own “command,” we avoid cluttering our UI or Siri integration with domain knowledge. Siri (thanks to AppIntents) is just another consumer of our well-structured domain. That means:

• Easier maintenance: We only need to manage business logic in one place.

• Better testing: Each Command/Usecase can be tested independently.

• Less code duplication: The same commands are called whether you’re interacting via the app’s UI or Siri.

The Problem: Massive View Controllers (MVC’s Evil Twin)

Before 2019, many of us were deep in the trenches of the infamous Architecture Wars, battling over patterns like MVC, MVVM, and VIPER. At the heart of it all was the struggle to properly separate concerns in our codebase.

We weren’t mad at MVC itself; we were frustrated by how easily it evolved into Massive View Controllers.

Let’s break it down. The humble UIViewController often became an all-you-can-eat buffet of logic, responsible for tasks like:

1. Navigation logic

2. UI updates

3. Presentation logic

4. Business logic

5. Network requests

6. Caching mechanisms

Before we knew it, our view controllers ballooned to over 1,000 lines of code. 🥲

Was It Really MVC’s Fault?

Nope! As Dave delves into brilliantly in this article, the issue wasn’t the MVC pattern itself. It was our interpretation of where things should live.

Apple always recommended breaking things down:

• Models: Split them into smaller reusable units.

• View Controllers: Divide and conquer! Use child view controllers.

• Views: Decompose complex layouts into smaller, reusable pieces.

With SwiftUI, Apple continues to encourage breaking things down further, promoting better modularity.

When we follow that, we avoid falling into the same rabbit-hole over and over again

But today, I want to focus on tackling logic, or the "M" in any MVx pattern. Enter: Command Pattern.

The Command Pattern: A Fresh Perspective

At its core, the Command Pattern is about encapsulating logic into small, focused units. Think of it as a class (or struct) with a single responsibility: an execute() method.

Here’s an example:

struct FetchPaymentMethods: AsyncUsecase { 
    func execute() async -> Result<[PaymentMethod], BusinessError> { 
        // 1. Fetch payment methods
        // 2. Fetch wallet
        // 3. Preselect a favorite
        // 4. Disable unsupported methods
        // 5. Add Apple Pay (if supported)
    }
}

This does a few things immediately:

1. Keeps the view controller or SwiftUI view clean.

2. Follows the Single Responsibility Principle (SRP). 🚀

3. Improves readability and maintainability.

If this logic grows too complex, you can further break it down into smaller commands:

struct FetchPaymentMethods: AsyncUsecase { 
    func execute() async -> Result<[PaymentMethod], BusinessError> { 
        await [
            FetchWallet(),
            PreselectFavorite(),
            DisableUnsupportedMethods(),
            AddApplePayIfSupported()
        ].asyncForEach { await $0.execute() }
    }
}

Why Use the Command Pattern?

Modular Expansion: Need to add a new step? No problem—just add a new command. Old implementations remain untouched.

Composability: Combine multiple commands to create complex workflows. For instance, placing an order might look like this:

struct PlaceOrder: AsyncUsecase {
    func execute() async -> Result<Void, BusinessError> {
        await [
            ApplyPromoCode(),
            UpdatePaymentMethod(),
            ValidateCheckout()
        ].asyncForEach { await $0.execute() }
    }
}

Testability: Each command is a small, isolated unit—perfect for writing focused unit tests.

Reusability: Commands are decoupled from the UI, making them reusable across different platforms, whether you’re building for iOS, macOS, or even CLI apps. 😄

A Word on SwiftUI

While this pattern shines in UIKit, it’s equally valuable in SwiftUI. With SwiftUI’s declarative nature, logic can creep into views if you’re not careful. Using the Command Pattern ensures your business logic remains in its rightful place—clean, testable, and reusable.

Example Time

So, now that we’re almost done, let’s give some examples about how can we make this possible

UIKit: Where the Model is the one in Command

In MVC, the Model is responsible for managing the app’s data. By incorporating the Command Pattern, we can offload specific business logic into dedicated commands, keeping the Model lean and maintainable.

// Command to encapsulate the business logic
struct FetchPaymentMethodsUsecase: AsyncUsecase {
    func execute() async -> Result<[PaymentMethod], BusinessError> {
        // 1. Fetch payment methods
        // 2. Process wallet logic
        // 3. Preselect favorite payment method
        // 4. Disable unsupported methods
        // 5. Add Apple Pay if available
    }
}

// Model using the command
final class PaymentModel {
    private var paymentMethods: [PaymentMethod] = []
    private var error: BusinessError?
    // Model communicates his output via Callbacks
    // This acts as a contract of communication and what to expect from the Model
    // Defining this is super important to reason about, as it defines how we can test our models
    var onPaymentMethodsUpdate: (([PaymentMethod]) @MainActor @Sendable -> Void) 
    var onError: ((BusinessError) @MainActor @Sendable -> Void) 

    init(…) { … }

    func fetchPaymentMethods() async {
        let result = await FetchPaymentMethodsUsecase().execute()
        // Further Business Logic may happen here, 
        // like composing different Usecases together
    }
}

// ViewController (Controller in MVC)
class PaymentViewController: UIViewController {
    private let paymentModel: PaymentModel

    init(…) { 
       paymentModel = init(onPaymentMethodsUpdate: {…}, onError: {…})
       super.init(…)
    }

    override func viewDidLoad() {
        super.viewDidLoad()
        Task { await paymentModel.fetchPaymentMethods() }
    }

    private func displayPaymentMethods() { 
       // Here we can map/translate/render our Business Data Models towards UI representations
    }
}

SwiftUI: Where the Model is still the one in Command

In MVVM, the ViewModel acts as the mediator between the view and model. The Command Pattern fits naturally here, allowing the ViewModel to delegate logic cleanly.

// Command remains the same
struct FetchPaymentMethodsUsecase: AsyncUsecase {
    func execute() async -> Result<[PaymentMethod], BusinessError> {
        // Business logic as before
    }
}

// Model using the command
final class PaymentModel {
    private var paymentMethods: [PaymentMethod] = []
    private var error: BusinessError?
    // Model communicates his output via Callbacks
    // This acts as a contract of communication and what to expect from the Model
    // Defining this is super important to reason about, as it defines how we can test our models
    var onPaymentMethodsUpdate: (([PaymentMethod]) @MainActor @Sendable -> Void) 
    var onError: ((BusinessError) @MainActor @Sendable -> Void) 

    init(…) { … }

    func fetchPaymentMethods() async {
        let result = await FetchPaymentMethodsCommand().execute()
        // Further Business Logic may happen here, 
        // like composing different Usecases together
    }
}

// ViewModel in MVVM
class PaymentViewModel: ObservableObject {
    @Published var paymentMethods: [PaymentMethodUI] = []
    @Published var error: PresentableError?

    private let model: PaymentModel

    init(…) { … }

    func fetchPaymentMethods() async {
        let result = await FetchPaymentMethodsUsecase().execute()
        // Further Business Logic may happen here, 
        // like composing different Usecases together
    }
}

// View in SwiftUI (MVVM)
struct PaymentView: View {
    @StateObject private var viewModel = PaymentViewModel()

    var body: some View {
        List(viewModel.paymentMethods) { method in
            Text(method.title)
        }.task { 
            await viewModel.fetchPaymentMethods()
        }.alert(item: $viewModel.error) { … }
    }
}

Key Takeaways

1. In MVC, the Command Pattern helps encapsulate business logic in the Model, keeping the ViewController clean and focused on its primary responsibilities.

2. In MVVM, the Command Pattern allows the ViewModel to manage logic, enabling clear communication between the View and Model.

By using the Command Pattern with either architecture, you enhance modularity, testability, and maintainability.

Final Thoughts

SwiftUI might feel like a fresh start, but without discipline, the same old traps of massive files and tangled logic await us. By adopting patterns like Command, we can keep our apps clean, maintainable, and a joy to work on.

What do you think? Have you used the Command Pattern in your projects? Let’s discuss in the comments below! 🚀

Today is a bit of a quick one, its about a productivity tip you can imply if you work a lot with terminals, so without furtherado, let's hop into it!

Problem

So we're all familiar with our vanilla macOS terminal, and familiar with the frustration of its readability, basicness, and... the 'shortcuts' we're so used to on Xcode that is... simply not there... ☹️

Perhaps you've also seen articles that reference oh-my-zsh, which offers you tons of plugins and can be paired with iTerm2, but the only thing is... it takes too much time to set up, and can break your environment... 🫣

Enters Warp

Warp is an awesome terminal, I used to spend time on my terminal adding auto-complete plugins, fig, smart cd & ls, memorize some commands in a side note

But the amount of time saved through its AI or plugins is so big!

Out of the box you get exciting stuff like syntax highlighting, smart suggestions from AI, and your little AI helper when things go wrong (which is not there for a manual customized approach)

My personal favorite?

It's hard to decide between being able to run multiple commands and edits at the same time (and get notified at the end)

or when facing a weird error, one can just ask warp 🤔

That's a Wrap!

Well, it might have been a short one, but this tool has lots of good features which you can def. check here

Hello, Folks!
Finally, this series is seeing its ending so I can move to other series!

Well... you might have noticed that async-await does indeed make code much more readable, and easier to handle. and the fact of allowing the compiler to help you define Race Conditions and Non-Thread-safe code via 'Sendable', Nonsendable, Actors, and Structured Concurrency... makes adopting async-await a very common goal for many tech teams these days... and today is a lesson I wanted to share with you what I've learned recently...

but before we start with our learning, I just wanna say...

Alright, Detectives, I've just binged-watched 6 seasons of Brooklyn 99, and today am Jake Peralta, and today, we are investigating...

Defined Errors and how they can screw your design... title of your bug report

Problem?

The throws keyword in this statement

func fetchRecentWalletTransactions() async throws -> [Transaction] { ... }

Now, don't get me wrong; after all, this is not an async-await series, nor am I asking you to ignore errors (it's an Error Handling Series after all 😬)

But as innocent, and tiny and so inline with the best practices of Clean Code & Swift Documentation, this keyword, can do you bad in terms of software design and maintainability of your layers...

Why is it a problem?

How many errors can I throw from this method alone?

enum WalletTransactionFetchError: Error { 
    case walletAccountNotSetup
    case walletUnavailable(reason: String)
    case walletOnHold
    case noTransactions
}

Well, Yep, seems like a good start... but is that all?

You can throw anything that conforms to Error, and for now, that's ok, or so it seemed

Due to not being specific, we lost being specific about what's going wrong, and supplying to our dependents what actually happened, so they have to do some guesswork, and that's where we lost the way, so now we're here, in the crime scene (the codebase), and trying to identify our characters...

The Crime Scene

1. The method itself (Prime Suspect)

2. The invokers (Victims)

3. Expectations between layers (Witnesses)

Suspect: Method Implementation

Mostly here, there won't be much trouble found..., upon fetching, you found that there is an issue, and you begin to map it to the above enum cases, however, worst case scenario, you can say, .walletUnavailable with a reason, right?

Victim: Invoker

Like any RPG or a story with multiple protagonists, each has their own side of the story, and let me tell you something, the Invoker is not HAPPY, about it...

I mean, you had one job! Fetching the transactions...

class TransactionWidgetViewModel { 
    ...
    func onAppear() async { 
        do {
            async try transactionsUsecase.fetchRecentWalletTransactions()
        } catch let error WalletTransactionFetchError { 
            // some handling
        } catch { 
            // Default handling
        }
    }
}

Now, this went quickly from 'handling the fetch error', to 'guess what broke'

The problem here is... if there are multiple error types, that means the method we built above may be doing two things or more... which may be a sign of SRP violation...

Similarly, the default handling is another place we would like to avoid...

because if our code reached this point, that means there is an invalid state, the application is currently in, and to quickly recover from it, we map it into a something went wrong error...

Lastly, if we were to handle each case, and if there is a new case that popped up which require its own handling, we might also break the OCP, which is another word for a...

Witnesses: Expectations

Remember the Error Flow episode?

We were mentioning how each layer would expect an error of some sort from its dependency, or layer... but now that the only thing we get is any Error, we gotta try to see if its the error we're expecting, or just wrap it inside a 'something went wrong', or an object with more metadata to describe it better later on (or not... since its a bit risky and some guess-work is involved)

so... in a nutshell, if we were to summarize all the above in one image... this one does a pretty good job at it 👇

Solving the case: A Fix

Alright, now that we have an idea of what's wrong, let's check an approach that addresses it

func fetchRecentWalletTransactions() async -> Result<[Transaction], WalletTransactionFetchError> { ... }

A simple, non-fancy, and weird-looking solution would be to return to Result<Success, Failure>

The reason for this is I can specify why this method can fail and the scenarios that follow it up... so the invokers can react accordingly

The Invoker's Story

func onAppear() async { 
    let result = async transactionUsecase.fetchRecentWalletTransactions()
    switch result { 
        case let .success(...):
            ...
        case let .failure(error):
            handle(fetchError: error)
    }
}

func handle(fetchError: WalletTransactionFetchError) { ... }

It seems kinda familiar to how we used to handle errors when we depended on callbacks, and the syntax was kinda boring...

Conclusion

Now that we have learned Defined Errors and their importance, It's high time I start working on that blog about monitoring the errors and how important this is as a practice 👏

1. Refactoring an anticipated change is always easier than sudden ones

Make a configuration file, make it hold all your constants, and reuse them over the codebase; this makes your life easier

2. Base Layers are good... when needed.

put in the base layer the main thing and build on it, so if you want to change

the change affects everything rather than go over many things and change

3. Less Over-Engineering, More YAGNI

Comments here and there was something I used to do, which is a sign of poor code

if the code is not comprehensible and self-explanatory, then it needs refining

4. Stop and Think, Is it reusable and testable?

sometimes you want to add something over and over again, but you need to make sure this thing is testable

5. The Hare who lost to the turtle

Step by step, one of my faults was trying to learn advanced topics to make use of it and build better projects

I was doing it rigorously and well, I still do because I love learning

One day you would see me learning about animations the other learning how to break the array with a race condition and trying to make a deadlock on purpose just to know what is bad.

this is not good sometimes, because you are disturbed, I can do it, I can focus on multiple things at a time and learn everything I see but some people can't and I love learning and teaching what I do with this blog, so things always sink in fast!

Aaand me from the future disapproves... 😃 well... one was a teenager back then so not judging 😄

6. avoid the Hot names

this was from my Sensei, @YoloAbdo

yea, it sounds cool to say I know how to avoid a cyclic dependency (deadlock); it's cool to say that I made an open-source project

but sometimes cool messes up priorities, and you might learn something that's not important at your knowledge level and leave more important things

7. MVC doesn't apply for code only, it can apply for a storyboard too

(MVC is Massive View Controller)

My senior told me that he faced a problem before that made the Xcode unable to even open the project...

which was having tons of screens in one storyboard, which was the main.storyboard (back then)

this resulted in too much information for the XCode to handle (and also the hardware of the MacBook)

so the key to solving it was to utilize the power of xib files and "divide and conquer."

8. Tapping into Alamofire's internals

Don't import something you don't need or do something you can do without importing it (YAGNI)
-- Says My Senior

When I told him I use Alamofire, he told me to forget Alamofire and build my own network layer; this made me tap into Alamofire and get some key things about how it works and what it does, also turning Abdo's layer into native components and removing Alamofire made lots of things clear

9. Sometimes code is not everything

you have to make sure that your code serves other things other than functionality, like a good UX and good design is also important; UX is the most important part of your app, so handle it with care

10. Think twice and Code once

Sometimes you need to make sure you write best practices and avoid anti-patterns

you would think that it would take time, but actually, clean code well-planned code saves time and meet deadlines rather than your normal clean Ratatouille

11. Always leave on good terms

that's My Friend Ahmed Itman who told me to always leave on good terms even if it was a liability to you so that people would want to work with you

12. Expect nothing, and you will never be disappointed

Don't devaluate yourself for a chance, if a chance doesn't come, it's not the end of the world, however, devaluating yourself for something, will always backfire

All of this was thanks to the amazing Senior, Mr. Sameh Aly, who taught me all of this and took me under his shoulders. Thank you very much, Sir!
Hope to work with you again!

Long time no see 😄

And last I checked 🧐, I have an unfinished series...

But, truth be told, it's a complex topic with lots of details, but I also intend on finishing it, so don't worry, all in due time 😄

Problem

So, what's up today? Today is a very good day to discuss one of the bloaters we all know very well, The big guy, AppDelegate, it starts small, and a couple of integrations later, it's almost unreadable anymore

I know I had some AppDelegates that I really didn't like at all, sometimes it was refactored to a Facade, and sometimes it was left with comments and MARKs all over the file to make it easier to navigate. However, there is still this kind of background pain from going into this file, and then... it clicked!

What if I told you that patterns can be combined?

What are we trying to achieve?

Refactoring is always about asking the right questions. What am I trying to get after being done with this part of the code?

Something that is easier to read, and maintain, so I need to separate some stuff

So how to separate it?

But... How?

Let's break down the AppDelegate for a second

The AppDelegate is made for a couple of things... like notifying us when a lifecycle event occurred, a notification was received, a deep link triggered our app, and so on.

And unfortunately for us, these methods get bloated with code. Surely we can add private methods to ease our burden, but what if we broke down the app delegate itself? Cut it into different reusable parts, that instead of "it" handling everything for us, it provides its APIs, and different implementors get called, as if it were... a Plug-in?

Abstracting the AppDelegate

Since we're trying to break it down, it makes sense that each implementer adheres to the same protocol. So, let's say ->

public protocol ApplicationPlugin {
    func application(
        _ application: UIApplication,
        willFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool
    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool
    func application(
        _ application: UIApplication,
        continue userActivity: NSUserActivity,
        restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void) -> Bool

    func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey: Any]) -> Bool

    func applicationProtectedDataWillBecomeUnavailable(_ application: UIApplication)
    func applicationProtectedDataDidBecomeAvailable(_ application: UIApplication)

    func applicationWillTerminate(_ application: UIApplication)
    func applicationDidReceiveMemoryWarning(_ application: UIApplication)

    func application(_ application: UIApplication, didReceiveRemoteNotification userInfo: [AnyHashable: Any])
    func application(_ application: UIApplication, didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data)
    func application(_ application: UIApplication, didFailToRegisterForRemoteNotificationsWithError error: Error)
}

This move allowed us to have multiple implementations, each to their own concern of that event, but they have to adhere to the way the AppDelegate works. In other words, if we have to support Firebase, Deeplinks, Push Notifications, and Google Maps

Instead of having one gigantic AppDelegate, we would have mini App Delegates but specific to these, something like this...

class AppearancePlugin: ApplicationPlugin { ... }
class UtilsPlugin: ApplicationPlugin { ... }
class FirebasePlugin: ApplicationPlugin { ... }
class NotificationPlugin: ApplicationPlugin { ... }
class GMSPlugin: ApplicationPlugin { ... }

Starting to make sense, eh? 😁

Gluing parts together

Ok, Ramy, the concept is ok, but how do you tell the AppDelegate to call your plugins or break itself?

Well, that's the neat part... you don't

You actually change the perception of AppDelegate with our own

Huh?

See, any iOS App (and any other language or framework that has the concept of an entry-point) needs to see this annotation to know which class is the delegate that it needs to send lifecycle updates

And that's what we're going to do, so...

Creating the Plugins host

Since the vanilla AppDelegate is incompetent in hosting our Plugins, we'll give it some superpowers.

open class ApplicationPluggableDelegate: UIResponder, UIApplicationDelegate {
    public var window: UIWindow?

    /// List of application plugins for binding to `AppDelegate` events
    public private(set) lazy var pluginInstances: [ApplicationPlugin] = plugins()

    override public init() {
        super.init()

        // Load lazy property early
        _ = pluginInstances
    }

    /// List of application plugins for binding to `AppDelegate` events
    open func plugins() -> [ApplicationPlugin] { [] } // Override
}

And now that the PluggableDelegate is defined, we're going to implement each method and make it call the plugins so they can do their work.

extension ApplicationPluggableDelegate {
    open func application(
        _ application: UIApplication,
        willFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]? = nil)
        -> Bool {
        // Ensure all delegates called even if condition fails early
        pluginInstances.reduce(true) {
            $0 && $1.application(application, willFinishLaunchingWithOptions: launchOptions)
        }
    }

    public func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey: Any] = [:]) -> Bool {
        pluginInstances.reduce(true) {
            $0 && $1.application(app, open: url, options: options)
        }
    }

// ... (they're kind of a lot, so feel free to copy the approach from the Github link)
}

Building the Plugins

Now, for the fun part, to not barrage the post with lots of code, let's focus on a tiny piece that is easy to digest, the part where you define the Appearances for your core UIKit/SwiftUI parts, like Tabbars & NavigationBars (...etc.)

import UIKit.UIApplication

// MARK: - AppearancePlugin

struct AppearancePlugin { }

// MARK: ApplicationPlugin

extension AppearancePlugin: ApplicationPlugin {
    func application(_: UIApplication, didFinishLaunchingWithOptions _: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
        addTabBarAppearances()
        addNavigationBarAppearance()
        return true
    }
}

private extension AppearancePlugin {
    func addTabBarAppearances() {
        UITabBar.appearance().unselectedItemTintColor = .greysSpaceGrey
        UITabBar.appearance().tintColor = .primaryBluberry
        UITabBar.appearance().shadowImage = UIImage()
        UITabBar.appearance().backgroundImage = UIImage()
    }

    func addNavigationBarAppearance() {
        UINavigationBarAppearance().configureWithTransparentBackground()
    }
}

See, in this part, usually, the appearance logic would be encapsulated inside private methods in a larger file (which is a common way of implementing the AppDelegate), but here, we're more focused on the appearance, which makes it easier to read and understand mentally.

AppDelegate: Hosting the Plugins

Now for the wrap-up and the part which looks like a Command pattern combined with a flavor of Composite pattern...

@main
class AppDelegate: ApplicationPluggableDelegate {
    override func plugins() -> [ApplicationPlugin] {
        [
            ServicesPlugin(),
            AppearancesPlugin(),
            UtilsPlugin(),
            FirebasePlugin(),
            GoogleMapsPlugin(),
            NotificationsPlugin()
        ]
    }
}

This is the actual interface of what the AppDelegate does. Any logic involved is separated across two parts, the PluggableDelegate & the Plugin itself.

So, in a nutshell, this is what is happening from a higher-level perspective.

Improvement: #2 Interface Segregation

So, you may think that we have reached an acceptable level of improvement, which is true, btw. Our goal from the start was to separate things using a couple of patterns to the degree that makes dealing with the logic even easier, but there is indeed one improvement we can make, segregation if I may say

Categorizing is a good rule of thumb for segregation

Let's clear things out first. Let's agree that an AppDelegate like we said above, is a receptor of any events, but since events can be categorized, so does our protocol. For example, our protocol handles 3 parts, Lifecycle events, Deeplinking Events, and Push Notifications Events

Which, in the end, gives us conformation to the ISP (Interface Segregation Principle)

Good Rule of 👍 is, whenever there's some methods to categorize, is an indicator that you can apply the ISP.

And if I were to use Firebase Messaging. In that case, I'd only be interested in just the Remote Notifications delegate methods, similarly for Deeplinking Events which are not "necessarily" coupled to Lifecycle, so segregating the delegate methods in our tiny protocol gives us the ability to be more flexible with our 3rd party integrations and allow ourselves to write more clean and concise code, now doesn't that sound "cool"?

My manager would disagree since we hit the goal already and should focus on something more important to the business, and we can iterate when needed (be wiser than me 😂)

Segregating Notification Methods

So, let's see this on diagrams first, so it paves the way for easier understanding.

So, this is how this segregation made our diagram look like this ☝️

Disclaimer, I am not very adept at UML diagraming, barely have a grasp over all the arrow types and such, but I figured this may be simpler and easier to explain with, so let me know if you think so, or should I really learn UML arrow types & legends if that would help 🙏

As you can see, now we have our ApplicationPlugin Protocol broken and segregated into 3 different protocols, and now we can compose them, even more to make for a flexible design

Implementation time

Let's start by defining and default implementing our RemoteNotification Protocols

public protocol ApplicationNotificationPlugin: AnyObject, ApplicationPlugin {
    func application(_ application: UIApplication, didReceiveRemoteNotification userInfo: [AnyHashable: Any])
    func application(_ application: UIApplication, didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data)
    func application(_ application: UIApplication, didFailToRegisterForRemoteNotificationsWithError error: Error)
}

// Then we define a default implementation so Plugins later on can pick which method to implement according to its needs
public extension ApplicationNotificationPlugin {
    func application(_: UIApplication, didReceiveRemoteNotification _: [AnyHashable: Any]) { }
    func application(_: UIApplication, didRegisterForRemoteNotificationsWithDeviceToken _: Data) { }
    func application(_: UIApplication, didFailToRegisterForRemoteNotificationsWithError _: Error) { }
}

Then, back to our backend of the AppDelegate, let's instruct it on how to utilize the NotificationCenter's delegate methods

extension ApplicationPluggableDelegate: UNUserNotificationCenterDelegate {
    public func application(_ application: UIApplication, didReceiveRemoteNotification userInfo: [AnyHashable : Any], fetchCompletionHandler completionHandler: @escaping (UIBackgroundFetchResult) -> Void) {
        // Hmmm, how to call the plugins?
    }

    public func application(_ application: UIApplication, didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data) {
        // Hmmm, how to call the plugins?
    }

    public func application(_ application: UIApplication, didFailToRegisterForRemoteNotificationsWithError error: Error) {
        // Hmmm, how to call the plugins?
    }
}

Now that the PluggableDelegate knows about the UNUserNotificationCenterDelegate, it can channel those events to its children's plugins. A good way of doing this is .compactMap { ... }

A neat functional trick where u can filter & typecast a sequence without much hassle, and in 1 shot

public func application(_ application: UIApplication, didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data) {
        pluginInstances.compactMap { $0 as? ApplicationNotificationPlugin }.forEach {
            $0.application(application, didRegisterForRemoteNotificationsWithDeviceToken: deviceToken)
        }
    }

Now, similarly, we can follow the same approach with other types of segregation

But, where is the fun in that, when you, my dear reader, can do that yourself, and make sure you understood the above concepts, and I can get back to GOW: Ragnarok?

Conclusion

Quick Recap

So, this article, was a tough one, ngl. This is because you're not seeing a specific Design Pattern in action. If I counted correctly, you're seeing around 5 patterns combined, each taking an idea from the other until we reach the part where we end up with something easy to read, edit and extend, and probably that's what you'd want to gain from design patterns in general.

Quick Breakdown

But, to make it easier to grasp, some of the very obvious patterns (apart from the Delegate, of course) are the Command & Composite Patterns, which are the secret sauce of this recipe; however, more patterns were also inspired, like Builder patterns and the Factory, which you can find in the array of plugins, and the abstraction layer between each type; lastly, the strategy itself of which Plugin to run, which was the final segregation we've made.

What are we building?

Today, we are going to build a payment method selection screen, and like last time, we have a “Why” here, on why are we building a payment method screen

1. Having various payment methods with different implementations can have different types of errors, and hence, different handlings
2. The variations also allow us to think differently about how to display those methods since not all methods can be displayed the same
3. Also, each type of method has its own way of business logic, which might result in different ways of handling errors per screen, so we're going to look into that as well
4. Lastly, it’s a good opportunity to integrate with Apple Pay

And, here is a glimpse of the final screen (since I enjoy this part when watching a tutorial tbh 😃)

Note: We’ll be focusing only on fetching our methods, and handling Apple Pay’s states

A Refresher of Uncle Bob’s Clean Architecture

So, basically speaking we’re going to have our architecture layered into 4 layers The View’s -> The Presentation’s -> The business’s -> The data’s

Or, something like this

Similar to how each layer is supposed to handle its responsibilities (in other words, the happy path), they also need to learn how they can handle their errors…

🤔 But what kind of errors should they handle?

💡 Let’s break this into two categories

1. Layer-specific errors

2. Types of errors in general

Types of errors

Let’s break this one into 2 categories.

1. Layer-specific errors
(like Network errors where connectivity may be lost)
2. General types of errors
(Like an error that can be ignored (cancelled error))

General Types of Errors

Ignorable Errors

Similar to the last post, we had Apple throwing us an error when the user cancels Apple Sign In

Recoverable Errors

For example, when a token expires, you can still recover from that backend error by refreshing your token first, then continue on with the original request

Unhandleable Errors

Which are kinds of errors that can not be handled in the current layer, but can be handled in another layer, for example, you can’t fetch data from a repository, but the business layer may choose to omit this data or reformulate the response (aka, work its way around it) so its no longer an error (more on that later in this post)

Default Errors

This is the last line of defense, the worst has happened, you can’t handle the error, and now we gonna need to tell the user there is something wrong

Layer-specific Errors

Some layers may have a set of common errors, like Datasources, the most common one would be, I couldn’t fetch the data (with mentioning a reason, optionally), while others require being more specific when throwing an error Like trying to check your profile, and whoops! no profile created

To Error or not to error?

The thing about layer-specific errors is, sometimes, an error would be treated as an error in some use cases, and sometimes it would be treated as a normal behavior without a need to make a fuss of it

🤔 Dude…?

Yep, bare with me, so for example, let’s say you’re trying to pay for something, and in the system, you can pay with your wallet, but guess what? You didn’t create a wallet for yourself in this system, so when paying, you can still pay with other methods and no need to tell you there is an error, right?

But, let’s say you’re visiting your wallet page for the first time, and there is no wallet, that’s when the error makes sense, where you don’t have a wallet error makes sense to be dealt with

Ok, too much reading, let’s start

Getting Started

So our happy scenario involves opening this screen and fetching our methods, and they all succeed, but we’re not here for happy scenarios, are we?

The Flow

The Data Layer

So, in the data layer, we got sources for these data, like the network & cache & databases, but for now, we are going to skip the sources, and talk directly about the repository layer

💡 Note: I talked about Network briefly here in the TDD series

The Wallet

protocol WalletRepositoryProtocol {
  func fetchWallet() async throws -> Wallet
}

1. We expect a wallet (duhh)
2. It can throw an error (yea yea, error handling series, what a surprise 🙄)
3. It's async (cuz it takes time to call an imaginary wallet endpoint)

so, let's start by addressing our Error flow first

enum WalletRepositoryError: RepositoryError {
    case noWalletFound
    case banned
    case inReview(_ state: ReviewState)
}

extension WalletRepositoryError {
    enum ReviewState {
      case pending
      case beingProcessed
    }
}

So, there can be no wallet, it could be banned, or it could be in review state with some more info about where it is now in the process, so as a Repository, I need to know what errors that can happen, so it's possible for me to handle them or not, and it's up to the next layer (the caller), to decide if he's interested in the errors I couldn't handle or not

Let's peek into the UseCase for the payment methods

fileprivate func addWalletIfPossible(_ methods: inout [PaymentMethod]) async {
    if flags.wallet {
      do {
        methods.append(try await walletRepository.fetchWallet())
      } catch let error as WalletRepositoryError {
        LoggersManager.error(error)
      } catch {
        LoggersManager.error(message: "Unknown error caught: \(error)")
      }
    }
  }

So, the Usecase here is interested in knowing whether the Wallet succeeded or not, and in case of failure, it would just log the error without failing the whole request made by the user

💡 Note: Notice that in the above example, since we're providing the user with his payment methods only, failing to fetch the wallet here means that we're not returning it as a payment method, while in a different example like a Wallet page, there must be a wallet or an error to tell the user he needs to create a wallet, and that's where the extra details of the error come in handy

Apple Pay

Now, Apple Pay is a bit different than your normal, usecase - repo - network call, it's a service of its own, and wrapping it would help us a lot in terms of reusing it, and also define how to handle its errors

So in here, we're going to define 2 things, ApplePay as a Payment Method, and ApplePay Service, which is a wrapper around ApplePay's API itself

💡 Note: Aside from being able to testing, having a wrapper allows us to bridge its errors, allowing us to handle its failures even better isA

protocol ApplePayServiceProtocol {
    func fetchApplePay() throws -> ApplePayProtocol
}

enum ApplePayError: Error {
    case serviceNotAvailable
}

I believe this is what I need to handle from the ApplePayService for now, and all that is left is how the UI would deal with ApplePay, like if its status needsSetup or is it available for use, because later on, that would decide the flow if the user picked it as a payment method

func fetchApplePay() throws -> ApplePayProtocol {
        guard PKPaymentAuthorizationController.canMakePayments() else { throw ApplePayError.serviceNotAvailable }
        let isItSetup = PKPaymentAuthorizationController.canMakePayments(usingNetworks: supportedNetworks)
        return ApplePay(status: isItSetup ? .needsSetup : .available)
    }

So, now that our repositories & services has been defined, let's jump into the business layer, and see how these 2 layers would interact with each other, BUT, first let's check where we are on the diagrams so it's easy to follow along.

The Domain

Now that an error made it into the domain layer (the use case), it's up to this class to decide what to do with it

🤭 And no, fortunately we're not bounding anyone's soul here

But, let's first think about what do we need, we have 3 sources for payment methods

1. The Wallet
2. The Payment Cards
3. Apple Pay

So, we're going to depend on these 3 sources in our UseCase and its our job there to decide what to do if they fail

override func process() async throws -> [PaymentMethod] {
    var methods: [PaymentMethod] = []

    await addWalletIfPossible(to: &methods)
    await addPaymentCardsIfPossible(to: &methods)
    await addApplePayIfPossible(to: &methods)

    guard !methods.isEmpty else { throw PaymentUsecaseError.noPaymentMethodsFound }

    return methods
  }

So, we're basically adding our methods if possible, but we're not really interested in failing the request unless its empty

🤔 Can't we return an empty array & be done with it?

💡 We can, there is no shame in it, but there are 4 reasons for this

1. similarly to the backend response when you're asking for an array of resources, the better practice is to send a 404, not a 200 and an empty array
2. similar to real life, if you're asking your local shopkeeper for some Avocados, and there is no avocados, he won't give you an empty bag, he would tell you they're not there
3. I believe being explict is key, so instead of returning empty array or a false boolean to indicate that you couldn't find or do something, it's better to throw an error where you can give more details (Check Uncle Bob's Chapter 7: Error Handling)
4. This is an Error Handling series, so we're trying to make a point here

Now, since our Usecase has its goal sorted out 👏, it's time to move to...

The Presentation

So, in the view model, we're interested in couple of things, having our State defined in a way that makes effort for the View minimal to display

  struct State {
    var wallet: WalletPaymentMethodUIModel?
    var paymentCards: [PaymentCardMethodUIModel] = []
    var applePay: ApplePayPaymentMethodUIModel?

    var isEmpty: Bool = true

    var error: PresentationError?
    var message: SuccessMessage?
  }

It allows the view to ask for Payment methods

func fetchPaymentMethods() {
    Task {
        do {
            updateState(try await PaymentUsecase().execute())
        } catch { ... }
    }
}

And lastly, it handles the errors and updates the state accordingly

func fetchPaymentMethods() {
    ...
    do { ... } 
    catch PaymentUsecaseError.noPaymentMethodsFound {
        state.isEmpty = true
    } catch is UnknownBusinessError {
        state.error = .default
    } catch {
        state.error = .default
    }
}

Now that our state is configured, the flow should move to the view

By the time any errors make it past the Presentation, the view can do minimal effort to display it, telling our users exactly what went wrong, but what if that error demanded us to change our current flow? for example, what if the user is no longer authenticated and must re-login?

That's a question for our next blog post, Error Handlers!

Conclusion

We now know that Error Handling is not all about some do catch blocks, sometimes it takes more effort and more design on paper to learn how to deliver something mature enough to help in delivering the best experience to the user, and even when things go south, it's still possible to give a reason for that

And like always, feel free to check out that git repo that hosts the code to this proejct Error Flow Code

Been a long time, I know (guilty as charged), it’s been a rough month, and I barely had time to set things up, so today (thank god) is the day we finally continue talking about Error Handling!

TL;DR

You can directly go to this branch and just read the code from there

Plan setting time

Let’s first agree that 3rd party modules are not always controllable, so to get over this, we wrap it into our wrappers and build upon these wrappers, and in some cases, we map it into our implementations.

💡 You may find wrappers are sort of like Facades, but we don’t want to use confusing smart words now do we? (Actually, we do, so you might wanna google what a Facade is in case you don’t 😁)

So…

What are we building today?

Today, we’re building a simple Sign In with Apple app

But! before we start there are a couple of disclaimers

• UI was mainly built by DSKit, I haven’t done much except play around with it
• No actual Sign-in takes place, so don’t expect that we’re going to authenticate you somewhere, or do anything with your credentials 😊

The Problem

So, why the Sign In with Apple?

It has lots of potential for today’s topic, where you may find yourself kinda coupled to putting its logic inside the ViewController or View just because it needs a presentationContextProvider or the delegate

So why not wrap that delegate inside our workflow?

💡 For this post (probably like every other post), we're going to use MVVM, but this time we're going to utilize a bit of Combine

Wrapping Time

Defining our Wrapper (Facade)

Since all we want from Apple Sign-in is getting to know when it succeeded, and when it failed, along with the success response, and the error resulted, for the sake of this post, I'll be interested in the error only (well, since it's a topic around Error Handling, so... yep 🤷‍♂️)

So, let's create our API contract!

public protocol AppleAuthUIDelegateProtocol: ASAuthorizationControllerDelegate {
  var onSuccess: VoidCallback { get set }
  var onError: Callback<ASAuthorizationError> { get set }
}

💡 Whatever comes after this is just a conformer, so I can fake this to drive something I want to see/test specifically

💡 You may notice that we mentioned that we're wrapping the UIDelegate and called it a Facade, so what's going on?

As it seems that we're doing 3 different things, but they're all the same

• We're wrapping Apple's Delegate for the Apple Sign In
• We're facade-ing it, so it's simpler
• And the delegate hasn't changed, so nothing changed here

public final class AppleAuthUIDelegate: NSObject, AppleAuthUIDelegateProtocol {
  public var onSuccess: VoidCallback
  public var onError: Callback<ASAuthorizationError>

  public init(onSuccess: @escaping VoidCallback, onError: @escaping Callback<ASAuthorizationError>) {
    self.onSuccess = onSuccess
    self.onError = onError
  }

  public func authorizationController(controller _: ASAuthorizationController, didCompleteWithAuthorization _: ASAuthorization) {
    onSuccess()
  }

  public func authorizationController(controller _: ASAuthorizationController, didCompleteWithError error: Error) {
    guard let error = error as? ASAuthorizationError else {
      onError(.init(.unknown))
      return
    }

    onError(error)
  }
}

Reusing Apple Sign-In's Presentation Logic

Sure, we can put all that logic inside a LoginViewModel, no problem, but what if you wanted to reuse it, and export it into its own module, segregating sure does like a good idea

class AppleSignInViewModel {
  ...
  // 👇 UI Delegate added with a couple of handlers
  private lazy var uiDelegate: AppleAuthUIDelegateProtocol = AppleAuthUIDelegate(
    onSuccess: onSuccessHandler,
    onError: onErrorHandler)

  private lazy var onSuccessHandler: VoidCallback = { [weak self] in
    guard let self = self else { return }
    ...
  }

  private lazy var onErrorHandler: Callback<ASAuthorizationError> = { [weak self] error in
    guard let self = self else { return }
    ...
  }
 ...
}

So, now that we have our ui delegate & a couple of handlers to catch the delegate methods results, we can start defining how we're going to handle the errors

let's quickly define some struct that represents our UI state for AppleSignIn, so far, its easy enough to wrap inside an enum, so let's do so

extension AppleSignInViewModel {
  enum State {
    case idle
    case success
    case failure(errorMessage: String)
  }
}

Now back to the onErrorHandler so it can propagate the failure state to the LoginViewModel and then to the View

...
  private lazy var onErrorHandler: Callback<ASAuthorizationError> = { [weak self] error in
    guard let self = self else { return }
    self.state = .failure(errorMessage: error.localizedDescription)
  }
...

Now, let's try our Error Pipeline

And Voil..., wait a minute... why does localizedDescription look so cryptic?

Defining our own Error

You may have noticed that Apple sends ASAuthorizationError, and its .localizedDescription is not very, um... localized? but also, to our own code, it's not a 1st party error, and controlling it is a bit tricky if dealt with directly, so defining it in our own context is a good idea

🤔 Apple's own error not being a 1st party error? does he realize that we're building on their own platform?

💡 Yep, while you're indeed building above Apple's Foundation & UIKit, but not above AuthenticationServices adapting ASAuthorizationError into your own Error gives you a couple of things, more control, the ability to specify the localizedDescription

So, let's define our AppleSignInError

public struct AppleSignInError: PresentationError {
  public let title: String
  public let description: String?
  public let type: PresentationMethod
  public let icon: UIImage?

  public init(title: String, description: String? = nil, type: PresentationMethod = .indicator, icon: UIImage? = nil) {
    self.title = title
    self.description = description
    self.type = type
    self.icon = icon
  }
}

👀 We will talk more about PresentationError in a later post and what role it plays

Now that we have our AppleSignInError, let's add some adaption code from ASAuthorizationError -> AppleSignInError

extension AppleSignInError {
  init(_ authError: ASAuthorizationError) {
    switch authError.code {
    case .unknown:
      self = .init(title: "Something went wrong", description: "with an unknown reason")
    default:
      self = .init(title: "Sign in failed")
    }
  }
}

And now we can ignore firing an error from the ViewModel if it doesn't make sense from a presentation POV, like a canceled error for example 😄

private lazy var onErrorHandler: Callback<ASAuthorizationError> = { [weak self] error in
    guard let self = self else { return }
    guard error.code != .canceled else { return }
    self.state = .failure(.init(error))
  }

Wrapping it up

Now, if we ran our project again and tried to cancel, we no longer get an error when we cancel the sign-in process using Apple

Conclusion

We've cut a lot of ground today, not only did we discuss Facading and wrapping 3rd party code into our own code, but we set a strong foundation for the coming post which is going to take a good turn in defining Error Handling responsibility among different layers in Clean Architecture

You can follow the project here on GitHub

Aaand, It's a wrap!

You open up Xcode, try to reproduce the issue, and you can’t seem to find what he’s talking about? You try to trace the code, try to “manually” test harder, but to no avail?

Then it hits ya, you ask a friend, and he asks, “Did you check the logs?”, and you be like…

What?

Logs

Like a dear diary, with their colorful way of expressing how your day went, the same thing in Software Development, the only difference is, they sound robotic, they’re labeled with file names, line numbers, sometimes method names They’re colored somehow, but when the color is red, you know it’s going to be a looong day So why are they important? Well, they are some sorts of hints to when an issue takes place

Story Time!

Like our previous post, the marketing team decided to launch a campaign on Facebook, and suddenly all the products they’re referring to in the ads are not accessible through the ad, you spend some time trying to replicate the issue, but the deeplinking does work on your machine, what seems to be the problem? Turns out Bob, the marketing guy, had a typo in the deeplink URL he used, and that wasn’t obvious when debugging, it took a while figuring this out, but the campaign is saved, and you live to fight another bug, but what would it be like if you had “Logs”?

Another Dimension where you had Logs

So, day 1 in the campaign, Bob presses the confirm button, users start to interact with the ad, and 1 day later, the issue is later reported to your manager, and you learn of it As a smart engineer, you already had logs installed, you find a bunch of red-colored messages saying… coudln't unwrap yourapp:/product_details?id=123 as a URL for handling it. and you managed to discover that there is an issue with the deeplink you’re receiving from the marketing guy, you ask them to edit it to the correct format, and the day is saved

Dr. Strange

Back to your own dimension after work, you went to do your laundry and you met Dr. Strange there

Turns out, all that multiverse madness didn’t give him enough time to do his laundry and now he have a chance to, you both strike a conversation and somehow, you got to let him show you how did you do in other realities, you find that in one reality you had logs installed and that helped ya solve the bug quickly without much stress that you had today, now you want to install one too, and that’s what we will do today!

Time to add a diary system

So, let’s first define some structure and focus on a system we already have in place, the print statement, it would be nice if we could add more info to it, like severity, its place in the code, maybe some emojis since the console doesn’t support colors, so let’s define one

public final class SystemLogger {
    public static let main: SystemLogger = .init()
    private init() {}

    public func info(_ message: String,
                               metaData: [String: Encodable]? = nil,
                               file: String = #file,
                               function: String = #function,
                               line: UInt = #line) {
        #if DEBUG
            print(message.withPrefix("ℹ️ "), "Details: \(file), \(function), \(line)")
        #endif
    }

    ...
}

Well, now we have more control, and it makes sense that the logger be accessible through a singleton, but only problem is, we only have access to those logs during development 🤔 Turns out we can add another Logger that we can utilize, like SwiftyBeaver, so we go on, and replicate what we did…

public final class SwiftyBeaverLogger {
    public static let main: SwiftyBeaverLogger = .init()
    private init() {}

    public func info(_ message: String,
                               metaData: [String: Encodable]? = nil,
                               file: String = #file,
                               function: String = #function,
                               line: UInt = #line) {
        ...
    }

    ...
}

During working with our two new loggers, you found that you wanted to log to both at the same time, after putting in some thoughts, you noticed that both implementations are too close to Strategy pattern, where they just differ in how they do their work, so you decide to add a protocol, to be later used inside a Manager class where you call it and the manager invokes all the strategies (Loggers)

public protocol LogEngine {
    func info(message: String,
              metaData: [String: Encodable]?,
              file: String = #file,
              function: String = #function,
              line: UInt = #line)
    func warn(message: String,
              metaData: [String: Encodable]?,
              file: String = #file,
              function: String = #function,
              line: UInt = #line)
    func error(message: String,
              metaData: [String: Encodable]?,
              file: String = #file,
              function: String = #function,
              line: UInt = #line)
}

You conform the Loggers to the LogEngine protocol

public final class SystemLogger: LogEngine { ... }
public final class SwiftyBeaverLogger: LogEngine { ... }
And add the `LoggersManager`
public enum LoggersManager {
    private static var engines: [LogEngine] {
        [SystemLogger.main,
        SwiftyBeaverLogger.main]
    }

    public static func info(message: String,
              metaData: [String: Encodable]?,
              file: String = #file,
              function: String = #function,
              line: UInt = #line) {
        engines.forEach { 
            $0.info(
                message: message,
                  metaData: metaData,
                  file: file,
                  function: function,
                  line: line)
 }
    }

    public static func warn(message: String,
              metaData: [String: Encodable]?,
              file: String = #file,
              function: String = #function,
              line: UInt = #line) {
        engines.forEach { 
            $0.warn(
                message: message,
                  metaData: metaData,
                  file: file,
                  function: function,
                  line: line)
         }
    }

    public static func error(message: String,
              metaData: [String: Encodable]?,
              file: String = #file,
              function: String = #function,
              line: UInt = #line) {
        engines.forEach { 
            $0.error(
                message: message,
                  metaData: metaData,
                  file: file,
                  function: function,
                  line: line)
        }
    }
}

So back to our previous example, we can now do some edits

func handle(deeplink: String) {
  guard let deeplinkUrl = URL(string: deeplink) else { 
//    debugPrint("coudln't unwrap \(deeplink) as a URL for handling it.")
    LoggersManager.error("coudln't unwrap \(deeplink) as a URL for handling it.")
    return
  }
  ...
}

And now, we have something like this

Conclusion

You decide to persuade Dr. Strange to watch other dimensions and, actually, you found another one where issues are monitored, and reported way before it may reach the users (or Bob’s mischievous-evilly-cursed-little-fingers), next time we will discuss the importance of having Error Monitoring tools like Sentry, and how you can use them to not just monitor errors and logs, but also gain more insights on the user’s environment which will help in having better Error Handling

It’s been a while, and I really missed writing a blog early in the morning! Now that I have some sort of free time, I wanted to discuss some techniques in Error handling over the coming days that I learned, and well, thought it would be interesting to share! 😄

I wanted to start with something that may not be obvious all the time, especially when you prefer to be safe away from crashes, which is unwrapping optional variables

The Problem 💥

func handle(deeplink: String) {
  guard let deeplinkUrl = URL(string: deeplink) else { return }
  ...
}

In the current context of the above method, you need to make sure that the URL is unwrapped after receiving the deeplink, and if the deeplink is invalid for whatever reason, we won’t continue executing the method

Seems… kinda normal, right?

Nope, it’s not always okay to early return silently, while it may not affect the program’s execution or create any bug (not always)… It may be a sign of something went wrong, without firing any alarms, like a bug hiding in plain sight, like a...

Silent Bullet 🔫

Silent Bullets are parts of your code that fail without firing any warnings, and the pattern where you unwrap a variable without handling the case where its indeed nil may create weird behaviors, and we, the developers, should be notified when something like this goes wrong

Remedy 🌿

Logging such behavior should be what you do in such case, to give you a second pair of eyes when something goes wrong, be it a technical issue, bad usage from another team, or a glitch in the matrix

For the scope of this post, we will stop at just printing this issue, in the next post we will talk more about Logs and why you need them, then walk you through a better approach than just printing it

func handle(deeplink: String) {
  guard let deeplinkUrl = URL(string: deeplink) else { 
    debugPrint("coudln't unwrap \(deeplink) as a URL for handling it.")
    return
  }
  ...
}

Conclusion

Not always unwrapping optional parameters may be a good thing, when reviewing/writing unwrapping code, ask yourself, is it normal for my use case that this variable may become nil by design? Or if it became nil that indicates a problem? 🤔

Happy Coding!

What it means to be downsized

It’s bad, you always read about it from time to time, you feel people in LinkedIn, you may interact with people who got them from other companies, and it’s all good until you find yourself in a position where you suddenly have to say goodbye two days after you do some technical planning to a feature with your teammates

It’s sudden

No one expects to wake up one day to find himself at risk of losing his job, especially when things are not clear who is staying and who’s going, we work full-time in the hopes of having job security and other benefits like work-life balance, but there is always a lesson

Panic and grief

When we first learned that there will be downsizing, everything went from very good to panic mode, and until things settled, and we learned who was going, we basically turned to grief, like being in a war where you find that you’re not dead by the end of it, but you can’t live on, knowing that your friends won’t come back, and that’s where grief started

Reflection

I always asked, what would I do if I was laid off? Would I be able to keep my composure? Think straight? Everyone has his responsibilities towards his family/himself y'know?

And unfortunately, I couldn’t find an answer, however, there was something to tell myself

“In the moments of crisis, panic does nothing, harness it, let it serve you” — Kratos, God of War Ragnarok Trailer

My Sifu (Kung fu Master) always tell us in training to never do two things

1. Back away from your enemy/opponent
2. Give your back to an enemy/opponent

And those are the key to anything in life, hardships happen, that’s normal, but panicking does nothing, instead of panicking, use fear/anger to become hungrier than ever, and fight your way to the top again

Never back away and despair and let life get the best of you, you’re your only salvation, so don’t give up on yourself and ask “what am I gonna do?”

And this is my message to all my friends at SWVL that were laid off today, stay strong, we were and are a family, you are strong and smart, so don't let this get the best of you, it's a storm that will pass

Hello, Hello 👋 It's been a while since I last added something to my humble blog 😄

This time, I am not teaching, but rather documenting my learnings, hoping that I become ready for FAANG-level thinking or hopefully helping whoever reads this. I am starting pretty simple here to get my hands going with the writing, so let's dive deep!

Let's start with the "Why"

What's with the nerdy approach? Why start with theories when you can jump straight to the problems?

Because you're not going to be interviewed to solve a weird problem that is hard to be read and understand, let alone solve, you're here to communicate how your brain ticks, and if its ticking is good at solving problems or it will bail out if it hit a roadblock and start calling for help?

So instead of calling it 'nerdy' or 'academic', I like to call it strategic, so let's see our options

First things first

My first thing to focus on is some pointers I did fail at in couple of interviews I had in the past when it came to Problem Solving

I messed up at two things...

1. How to break the problem down into small problems
2. Communicate my thoughts to my interviewers

But solving the problems was never the deal breakers

When I returned to my mentor and asked him where did I go wrong, and shouldn't be intensive study of System Designs and Architecture be sufficient...

To me, they were... 😂

but his answer was really insightful, they're both two skills that feed each other, but they're completely different when training them

and his advice was to learn about data structure first, read about it a bit and understand them, then start solving your way to the hard problems, solving only 1 easy problem a day until you can find yourself comfortable

So, I curated some rough headlines I would study and write about so it can enforce the learning

Sources we need first for a solid foundation on what we need to solve problems

And... TADA! 🎉

1. Learn about Data structure, and what are they?, in a basic and simple manner
2. Learn about complexity and measuring it, memory-wise & processing-wise
3. Learn about Big O Notion
4. Learn about Logarithm
5. Start dissecting the Data Structures into categories of...
   1. Array
   2. Linked Lists
   3. Hash Tables (or Dictionaries)
   4. Stacks & Queues
   5. Strings
   6. Graphs
   7. Trees

In the next blog post, we will start with what are Data structure

Hey hey, so we’re back for a quick one today, which is navigation, let’s start it with a good question 🙋‍♂️

Did you try implementing last blog post’s challenge of doing it on your own?

Well, fear not, because we’re here to fix that!

Enters Navigation

Last time we talked was about displaying alerts, since we have a private access to the current visible Controller, we can do navigation access on it, all while encapsulating it, but first, let’s imagine how our tests would be, so you can also learn the thought process

Imagining the Code in Tests

func testGivenUserLogsInSuccessfully_WhenSuccessHappens_ThenHeShouldBeNavigatedToHomeScreen() {
    // Given
    let email = "valid_email@gmail.com"
    let password = "Somevalid1Password"

    // When
    sut.login(email: email, password: password)

    // Then
    XCTAssertTrue(
      router.actions.contains(
        .present(
          HomeViewController.self,
          presentationStyle: .fullScreen
        )
      )
    )
  }

So what I want at the end is something that tells me, hey, the type of the controller u passed is HomeViewController, and the presentation style is fullScreenPresentation

💡 For those reading outside iOS background, the fullScreen presentation is needed here as there are two types of presenting a screen, so we specify that here to avoid returning back to the login screen without a need, hence reinforcing our navigation logic

Now that we have an imagination in place of how our APIs would look like, let’s try to implement them

Making it real

private extension LoginViewModel {
  func validate(_ email: String, _ password: String) {
    ...
    router.alertWithAction(
      title: "Validation Errors",
      message: errors.map { $0.text }.joined(separator: "\n"),
      alertStyle: .actionSheet,
      actions: [
        (title: "Ok", style: .default, action: { [weak self] in
          self?.state.send(.idle) <- Added
        })
      ]
    )
  }
}

First, let’s reset our state to idle once the user dismissed the alert sheet, this way we can have a better state handling

Sneak peak into the future of this Series

Second, in our login method, we can edit the implementation to go to a pre-built ViewController called HomeViewController where we will later on build an mini part of an E-Commerce app, so that we can later on test Common E-Commerce logic

public func login(email: String, password: String) {
    validate(email, password)

    guard state.value.errors.isEmpty else { return }

    ServiceLocator.main.network.call(
      api: AuthEndpoint.login(email: email, password: password),
      model: AccessToken.self
    ).sink(receiveCompletion: { onComplete in
      guard case let .failure(error) = onComplete else { return }
      self.state.send(.failure([error.toOError()]))
    }, receiveValue: { [weak self] token in
      guard let self = self else { return }
      try? ServiceLocator.main.cache.save(value: token, for: .accessToken)

    // Addition starts
      self.router.present(
        HomeViewController(),
        presentationStyle: .fullScreen
      )
    // Addition ends
    }).store(in: &cancellables)
  }

You will notice the pattern that we’re trying to reach now, we are testing if Home screen was pushed to the UI after a successful login

Note: We don’t call an actual API, WE’RE THE API 😎 Just kidding, indeed we don’t have an API, but that’s the power of Fake, where we can later on have our API installed in a backend server, and we can replace the contract with ease 🎉

Green Checkmarks

What comes next is seeing the green check marks ticking into our tests, and a safety net if something broke

Conclusion

What we did today was a good way of integration testing, as you can see we are testing if the user gets routed correctly as per the business, when logging in, there might be a case that I decided to not do in the current project since it’s too simple and lots of setup is needed to make it possible which is automatically routing the user to Home after he logs in correctly If you’re looking for pointers on how to do this, here are some steps you can follow and some ideas

1. Programmatically launch Home or Login if the user already logged in once by finding the Access Token in the Cache/Storage
2. Introduce the concept of Coordinator, which programmatically (not in the Interface builder) determines which screen is required to be present

I think it’s time to close down this series 🥲

Anyway, I’ve been thinking on writing a series on The Composable Architecture (TCA), and it’s time to introduce a video series about building a chat app using it 😆

It’s been exciting dealing with TCA so far and how it makes it easy to work with SwiftUI

So next stop is returning to the good old Redux series

It's been a long time! Really happy that I have time to write about TDD again, and with an interesting topic from which we can know if our users had seen an alert, popups, or simply seen a message (toast) appearing to him

The Point?

How is this important, you ask?

Well, Imagine that our user is trying to log in but he is giving us an invalid email without him noticing, it would be nice to either show a message to him, saying that he missed a '@' in the email field

But what if after a couple of iterations over our app, and somewhere in version '1.4.3', this broke, and users no longer get a hint about why their email is not getting accepted, especially for an old user of our app, it might get irritating

However, if a test covers this; before we even launch any new version, this issue would be well on our issue tracker.

So this post we will cover how to cover such cases with a unit test coverage, and I think it would be interesting in showing how do I handle issues in my project in another post

Without further ado, let's get rolling 😎

Revisiting the project after some changes

Remember that last demo video I put on the previous post of this series?

Well, I did promise you guys that I will make improvements to the refactoring and I did,

It now utilizes my open-source OrdiKit which is a fast way for me to put files I use from time to time, or just wanna test an idea or probably launch a project, it utilizes SwiftUI and UIKit

I don't want to spend much time on what went on in the Refactoring, but there is an interesting part I believe, which is called ServiceLocator

It's a pattern from Game Development and is a bit strange in iOS development as it uses Singletons

Before you throw any knives in the comments, let's take a step back and see why is this put here

If we think about Network and Cache, normally these are 2 dependencies where the app depends on

They shouldn't be repeated or recreated, in fact, that would create a problem if am tracking the progress of some network calls, or am storing 2 stuff simultaneously on the disk

So it makes sense to have this as a single instance inside the ServiceLocator.

Other than that, we're ready to go test our side-effects in form of alerts

If we return to our Testing file TDDTests/Login/LoginTests

We can add a test function like so…

func test_GivenInvalidEmail_WhenLogin_UserSeesAnAlert() {
    // Given
    let email = ""
    let password = "Somevalid1Password"

    // When
    sut.login(email: email, password: password)

    // Then
    XCTAssertEqual(
      router.routingAction,
      RoutingAction.alert(ValidationError.empty(.email).errorDescription)
    )
  }

You will find that we want to have a new dependency called router, ideally the router would have its own state or action, so we can check if that action corresponds to what we want to verify, in our case, when the user forgets to pass his email, in such case we would want to show an alert (just for sake of simplicity for now), that he can’t leave his email blank

As of now, we don’t have such functionality so let’s start adding it to our production code

public typealias AlertAction = (title: String, style: UIAlertAction.Style, action: () -> Void)

public protocol RouterProtocol: AnyObject {
  func present(_ view: UIViewController)
  func startActivityIndicator()
  func stopActivityIndicator()
  func dismiss()
  func pop(animated: Bool)
  func popToRoot()
  func popTo(vc: UIViewController)
  func push(_ view: UIViewController)
  func alertWithAction(
    title: String?,
    message: String?,
    alertStyle: UIAlertController.Style,
    actions: [AlertAction]
  )
}

This is how our Routing functionality is going to provide, now let’s wait here and think what is going on

What we want, is an encapsulated access to our ViewController from the presentation layer, in our case, the LoginViewModel this encapsulation provides us with scoping to just the navigation functionality, so I can control the ViewController’s navigation from here, without having any access on the ViewController itself, let’s see how with extra details, by defining our Router Implementor

public final class Router: RouterProtocol {
  private weak var presentedView: UIViewController!

  init(_ view: UIViewController) {
    presentedView = view
  }

  public func present(_ view: UIViewController) {
    presentedView?.present(view, animated: true, completion: nil)
  }

  public func dismiss() {
    presentedView?.dismiss(animated: true, completion: nil)
  }

  public func pop(animated: Bool) {
    _ = presentedView?.navigationController?.popViewController(animated: animated)
  }

  public func popToRoot() {
    _ = presentedView?.navigationController?.popToRootViewController(animated: true)
  }

  public func popTo(vc: UIViewController) {
    _ = presentedView?.navigationController?.popToViewController(vc, animated: true)
  }

  public func push(_ view: UIViewController) {
    presentedView?
      .navigationController?
      .pushViewController(view, animated: true)
  }

  public func alertWithAction(
    title: String?,
    message: String?,
    alertStyle: UIAlertController.Style,
    actions: [AlertAction]
  ) {
    let alert = UIAlertController(title: title, message: message, preferredStyle: alertStyle)
    actions.map { action in
      UIAlertAction(title: action.title, style: action.style, handler: { (_) in
        action.action()
      })
    }.forEach {
      alert.addAction($0)
    }

    presentedView?.present(alert, animated: true)
  }
}

Notice the private access modifier before the controller? Exactly what we’re looking for

Giving our ViewModel The Power of Navigation

If we get back to our ViewModel, we can now hand it a router by dependency injection, and have it show the view an alert when needed

...
  var cancellables = Set<AnyCancellable>()
  var router: RouterProtocol

  init(router: RouterProtocol) {
    self.router = router
  }
...
func validate(_ email: String, _ password: String) {
    ...
    guard !errors.isEmpty else { return }
    state.send(.failure(errors))
    router.alertWithAction(
      title: "Validtion Errors",
      message: errors.map { $0.text }.joined(separator: "\n"),
      alertStyle: .actionSheet,
      actions: [
        (title: "Ok", style: .default, action: { })
      ]
    )
  }

If we ran and tested our code…

Voilà

Faking our Router until we make it

Now comes our testing code’s turn

First, we need to create a FakeRouter that gives us information about the navigation state In order for us to have access to our navigation stack, we need to define a state enum, which holds the actions given to the router

enum RoutingAction: Equatable {
  case present(_ vc: UIViewController.Type)
  case push(_ vc: UIViewController.Type)
  case dismiss
  case pop
  case popToRoot
  case popToVC
  case popTo(_ vc: UIViewController.Type)
  case alertWithAction((title: String, message: String))

  static public func ==(lhs: RoutingAction, rhs: RoutingAction) -> Bool {
    switch (lhs, rhs) {
      case let (.popTo(a), .popTo(b)): return a == b
      case let (.present(a), .present(b)): return a == b
      case let (.push(a), .push(b)): return a == b
      case let (.alertWithAction(a), .alertWithAction(b)):
        return a.title == b.title && a.message == b.message
      case (.dismiss, .dismiss),
        (.pop, .pop),
        (.popToRoot, .popToRoot),
        (.popToVC, .popToVC):
        return true
      default:
        return false
    }
  }
}

This way, we can have an in-memory storage that we can use it later on, to test against whether the user did present a view, did push to a view, or simply gave an alert

And to wrap it up so we can continue on with testing…

final class FakeRouter: RouterProtocol {
  var actions: [RoutingAction] = []
  var alertActions: [AlertAction] = []

  func popToRoot() {
    actions.append(.popToRoot)
  }

  func popTo(vc: UIViewController) {
    actions.append(.popToVC)
  }

  func push(_ view: UIViewController) {
    actions.append(.push(type(of: view)))
  }

  func present(_ view: UIViewController) {
    actions.append(.present(type(of: view)))
  }

  func dismiss() {
    self.actions.append(.dismiss)
  }

  func alertWithAction(
    title: String?,
    message: String?,
    alertStyle: UIAlertController.Style,
    actions: [AlertAction]
  ) {
    self.actions.append(.alertWithAction((title ?? "", message ?? "")))
    self.alertActions.append(contentsOf: actions)
  }

  func pop(animated: Bool) {
    self.actions.append(.pop)
  }
}

Notice how we append the type to the actions array?, similar to our FakeCache, we just register it until the test has run, so we can later on test against if it indeed has a certain action that we expect it to be, or not.

Back to our tests, now we need to supply our SUT with a FakeRouter so we can test it

Wrapping it up

class LoginViewModelTests: XCTestCase {

  var network: FakeNetworkManager!
  var cache: FakeCache!
  var router: FakeRouter! // <- Changed
  var sut: LoginViewModel!

  override func setUp() {
    super.setUp()
    network = .init()
    cache = .init()
    router = .init() // <- Changed

    ServiceLocator.main = .init(network: network, cache: cache)

    sut = .init(router: router) // <- Changed
  }

  override func tearDown() {
    super.tearDown()
    network = nil
    cache = nil
    router = nil // <- Changed
    sut = nil
  }

Now that our LoginViewModel knows how to use our FakeRouter, let’s fix some of our test code below

func test_GivenInvalidEmail_WhenLogin_UserSeesAnAlert() {
    // Given
    let email = ""
    let password = "Somevalid1Password"

    // When
    sut.login(email: email, password: password)

    // Then
    XCTAssertEqual(
      router.actions,
      [
        RoutingAction.alertWithAction((
          title: "Validation Errors",
          message: "Email can't be empty"
        ))
      ]
    )
  }

And that’s it!

Conclusion

Now that we have a way of testing our Alerts, Popups, and Messages… or simply what I like to call them, Async Views, where a view cuts through the flow for the user to take an action then return to the normal flow We can now go to our next stop which is testing the our navigation flow, which by now you can guess how it really can be easy

Tell you what, how about you try to implement this on your own? You will be amazed by how easy it is now to test your navigation, and next stop we will go over it quickly and talk about something really important, which by now, the ViewModel became somewhat big, so let’s talk about how we can dissect it even further, so we can avoid going from ‘MVC’ to ‘MVVM’ (aka, massive view controller, to massive view model) 😉

And if you’re an eager one and wants to know our progress on Github, feel free to see the code here

What to expect?

Robin speaks about how waking up early at 5 AM, and investing that time into learning and doing complicated tasks is a good idea, and why successful people like Jeff Bezos, Elon Musk, Steve Jobs, and many more have had great, on-going success that may have exceeded their lifetime

Concepts are taken from 5 AM Club

1. Pick who you choose to be around very carefully
2. Appreciate the little things you’ve, you never know what was yesterday a “taken for granted”, to be “good ol’ days”
3. Waking up @ 5 AM is not just healthy, it’s phenomenal
4. 5 AM work sometimes can shortcut days of work in mere hours or sometimes minutes
5. Success comes from tiny details
6. Avoiding distractions and focusing on what’s important
7. Labeling and prioritizing important things to do is an important skill (yet, not the most obvious)
8. Life is short, focus on leaving a good memory of a life well-spent

My summary

How to reach your goals & how your environment affects that

During the early chapters, Robin explains how important your inner circle is, explaining the effect of your environment on you, from befriending negative people to people who inspire you & encourage you to become better

If you want to become something, befriend people who already have it

Key to fulfillment & Wealth

True wealth and fulfillment comes from uplifting and positively affecting other people’s lives, in the rush of today’s technology, appreciating little things becomes common, hence becoming accustomed to them, labeling them as ‘Ordinary’, hence feeling dissatisfied even if you have everything one would wish for

The secret ‘5 AM Club’

Waking up every day @ 5 AM not only is healthy, but a good investment in your mind that can easily be translated into physical wealth and an extra bonus of Wisdom

Fixation on goals save time, energy & money (and vice versa)

Our brains tend to feel in control and really great when we have simple, trackable goals in front of us, all our brain resources are put into it, and hence, we gain a sense of assurance However, when we are surrounded by lots of distractions and multiple, unrelated goals, chaos happens, because our brains don’t feel in control anymore, and we fall into prioritization hell, shorter focus life-span and eventually get burnt out at a higher rate (mostly by not noticing that we haven’t had a break in a long time due to all the things we need to finish)

Productivity is not just a great mental & physical state

We often think that productivity is related to sleeping well and/or being present or active, however, there are other factors to it, for instance, human is not just an IQ or a BMI, there comes also how you’re doing emotionally and spiritually So make sure you take care of those besides setting your schedule and sticking to it 😄

True Potential gain lies outside your comfort zone

Like muscles, challenging them with working out can lead to them growing and improving, similarly with your mind and personalities

It turns out that the human brain has a great potential for something called neuronal plasticity, or in other words, being highly malleable. It appears that challenging our brains — for example, by learning a new skill — leads to actual changes in the adult brain. — A Harvard’s Health Blog

Waking up early is not enough

Waking up at 5 AM may not be enough, either as a goal, or an achievement, however, what you do when you wake up, is what matters the most to you and your future goals Robin took the approach of breaking down the first hour into 3 parts

The 3 Pockets

The 3 Pockets is basically a 20/20/20 Rule of chunking your first hour into 3 activities of 20 minutes each.

Robin advises to chunk it like this

• The 1st 20 mins could be invested into exercising
• The 2nd 20 mins could be invested into meditation
• The 3rd 20 mins could be invested into learning

Action Time! 👏

I have two problems to tackle, so I planned a system to get over it

Sleeping early

I mean, c’mon we’re programmers, we tend to tick late @ night, right? Nope, that’s a lie from my subconscious to steal another episode or do something I’ll end up regretting 4 hrs later after being completely tired and no longer able to maintain opening my eyes

So, I am doing something simple to not overcomplicate it

1. Begin Wind down routine at 9:00
preparing some warm drink, brushing teeth, etc…
2. By 9:30, my phone goes into a parental mode where only select apps are allowed
   1. [Balance]
   2. [Sleep Cycle]
3. I meditate to release any tension or stress while remembering what to be grateful about

   Fighting the ‘Just 5 more mins’

4. Making sure I don’t break my sleep cycles ([read more about it here])
5. As soon as I am conscious that I woke up, immediately remove any blanket and run my hand over my face as If I was washing it
6. Keep my phone away (I usually fail here and end up cold in winter after I noticed that I didn’t get out of bed, rather woke up to sync myself with Twitter’s feed or Facebook’s 😆)

Conclusion

All in all, this happened to be my first book to ever finish, as much as I’m excited, as much as I really loved sharing and grooming my thoughts about it

If you wanted to get the book, you can find it here on Amazon, however, just a disclaimer so I put this off my chest, any link to any book in this series is an affiliate link

What is this about?

In early 2021, I took part in a productivity course by none other than Ali Abdaal, the guy was really charismatic and really organized, and he was my favorite YouTuber that year, and he recommended lots of techniques that were foundational to me in this year

Not only did he share his notes-taking techniques, but also shared some books that I managed to read

So, in the upcoming series of books reviews, I’ll share my notes, but in the end, I’ll also share my Obsidian vault, which generally illustrates indexed & searchable notes that are also linked together

So, what’s the plan, Cap’ain?

I think I have around 26 Books read by now, and what we can do is share them every week just to get started, each categorized between Mindsets, Financial Literacy, Trading, Investing, Negotiations, Entrepreneurship, and Emotional Intelligence

So, am going to have 5 Lists along with this one, so you can either look up something without necessary being tracked down into a specific category, however, since some books may fall into more than one category, I think it would be a good idea to dissect the review as per the note’s category, hence shorter articles to read quick & at the same time, the book itself may have its own series between its categories

Alright, but do we have a timeline or a roadmap for this?

Oh, we do, and you can see it here 😉👇

How to read this? Each sub-node contains a category, each category contains a book which I already read and summarized, so the process for those 26 books is to release 1-2 summaries per week, I’ll share notes about this book, some of my notes and at the end, a poll of which category should we do next

Where to go from here?

Let’s not waste time, and start our discussion about the first book together, called The 5 AM Club

I’d spend a couple of hours studying, planning, and understanding a problem, just to solve it in minutes.

The Time Machine

What If I told you that, there is a ball of crystal that when u do strange and funny hand moves saying non-sense in front of it and suddenly a cloud of (usually) purple floats magically from below it to say what bugs are you going to face early on, how bad your ad-hoc design inside the code is, how miserable the company is going to be... once you get to the 3rd month and how the first 3 months are going to be so happy and proudful, only to find people waiting for you to move this button from here to there? (replace here and there with a login wall and you will automatically get the point ;))

What am talking about is not really Disney (whispers: I was indeed imagining them)

What am talking about is...

Draw.io!

or your sketchbook, or your iPad where u can draw

but since up there we mentioned that Software Design is an art, so we should get sketchin'!

Let's tackle down an Authentication Flow that does the following

It integrates with our BE through, Email and Password Phone and Password Continue as a guest FaceID and QR Code Scanning Facebook, Twitter, Pinterest, LinkedIn, Github, Apple, Google, Reddit, and every authentication provider there is to integrate with

Of course, if you had something required like this, you should leave the job since neither r u a bank to be this secure, nor are you a god damn hub of getting people together from all around the world, what you are right now is someone who is about to learn how the hell do we detect which design pattern to use for this task and how can you assign 3 engineers (including urself of course) to finish it, in a timely manner of under... 3 days would be a good estimate I think (guess what, first 2 days are in the foundation, 0.85 days in the implementation and 0.15 days in testing what u did ;) (btw this is not TDD, it would take shorter than this if it was TDD or BDD) (also BDD makes more sense in mobile)

If we go back to the reference of what we want to do basically, is one button may trigger something, another button may trigger a different flow, a 3rd one may trigger something completely different than the other 3

but it all boils down to one big funnel, which is...

Logging the user in!

What if I told you is what we are talking about is a game of strategies? which strategy will we use, to get the guy into our app in the quickest way possible?

Strategy Pattern: Did someone say Strategy Pattern?

Shout out to my Sensei right here, Abdoelrhman 🙌 for making it a possibility to learn that pattern 🙏

Let's start with the why by answering how many SOLID principles are done through this pattern in this use case?

but first, let's do that on a sketch, shall we?

Give those diagrams 2 looks, 1 quick look, another is deep and zoom into the annotations I wrote to clarify the bits and pieces

Tip: If you see this, you may find that this is just a piece of the puzzle, and that's exactly what is needed here, you don't have to draw the whole picture in 1 go, just a step by step, slow and steady wins the race (YAGNI, remember?)

Now, ask yourself, how can I do this and instead of worrying and letting your emotions get over you, build one now, you can get back to these if you want, but always remember, you are talking at a very high level now, no details are allowed, just pure simple rectangles and arrows that represent communications, ownership, responsibilities and a direction of where everything is going and how the data flows (regardless of whether u use delegates, callbacks, Observables, AnyPublisher or Subjects, or KVO, or just pure notifications (1 quick note here, do not reference the previous layer in a deeper layer, the deeper you go, the more independent you should be, and hence more reusable (or Modular)))

Did that? GREAT JOB! get yourself a cookie 🍪

now what if I tell you right now, absolutely right now, that if you want to open-source this whole thing, and have your name is written behind the largest authentication pod/package/library/framework that combines all of these and give the end-user (us programmers) just one method to use and that is "authenticate()" (am assuming usage of Promises here :P) then you can just take the whole authentication module, and put it on Github 😉, and whatever goes on Github goes on any future project for you to finish that 3 days task in... 3 mins? (an exaggeration, but unless you are a UI ninja known as the Yellow Flash, or UI is already built, then it may be doable)

Because it's modular

And being modular allows for being testable

So how will we test this?

Remember Liskov?

She said that a system may behave the same way if I replace one component with another

and since we want to test behavior, not syntax, which part of this diagram do you think we can replace with a fake/mock/stub (every part does something different but for sake of simplicity, just consider them all as one, and that none of them is going to call any backend of-what-so-ever)

So, in Unit Testing, let's fake that AuthProvider, and make it trigger certain behavior through fake flags and assertions thru spies

I’d spend a couple of hours studying, planning, and understanding a problem, just to solve it in minutes.

Why asking for people that know MVVM is a red flag in job posts and what should be written instead from my humble POV?

Sure in a team of people who work with a specific stack is logical to invite people who are good at it, but MVVM shouldn’t be your main concern, you want to invite people who are dependable in that stack or any other, so where the red flag might be u say?

It’s in how revered MVVM is around the whole project if the project is big and may contain different combined features like Social media and e-commerce (This is famous btw since u want to build a community around what u r selling)

Using MVVM with a reactive paradigm would be very great in Social media since you’ll need streams and real-time logic in place

However, the same might not be the case with e-commerce unless u r doing Auctions that includes real-time changes for example

But if u notice, we haven’t really talked about anything but presentation up till now, which is…. A design pattern to solve an issue ;)

So what issues do MVC, MVP, MVVM, or whatever u may find suitable?

Start with the class diagrams

Understand the flow

Understand the communication

Learn the slightest details and understand why we do this, that way

Why for instance, must not, under any circumstances, a ViewModel be directly linked with the previous layer? (May it the view, or an intermediary layer between them)

Why do we have dotted lines that represent a weak or an indirect reference to the previous layer?

Why the flow must be unidirectional?

Why implementing an offline-first is tricky and how your design might foresee future issues?

In the next section, we will learn those