Welcome to “Mobile: Architectural Best Practices in Action” — a series where we embark on a journey through the intricate world of mobile application development. In this series, we won’t just talk theory; we’ll roll up our sleeves and dive into real-world scenarios, use cases, and challenges that developers often face.

What to Expect:

In each instalment, we’ll pick a specific user story, a scenario, or a use case that reflects the complex landscape of mobile app development. But we won’t stop at merely identifying the challenge — we’ll approach it with an architectural mindset, dissecting the problem and crafting a robust solution.

Why Architectural Mindset Matters:

Why do we bother with an architectural mindset? Because in the dynamic and fast-paced world of mobile development, it’s not just about getting the app to work; it’s about crafting a solution that stands the test of time, scales gracefully, and remains maintainable as your app evolves.

Diving into the Design:

We’ll talk about design patterns, styles, and best practices. But here’s the deal — we won’t always take the easy road. We’re going to chat about why we choose one design over another, even if it seems a bit tougher. It’s about making smart choices for great results.

Join the Conversation:

This series isn’t just about me sharing insights; it’s a conversation. I invite you to engage, ask questions, and share your own experiences. Let’s learn together as we resolve the complexity of mobile architectural design.

With that, let us get into our 2nd user story.

Checkout the previous one here.

User Story 2

Ask is for implementing the upcoming feature similar to Instagram stories, on existing chat application’s like Teams, Telegram, etc. we would be needing to create infrastructure for fetching and viewing user-specific stories. Although the exact UI design is pending finalisation, mobile-dependent APIs are available for retrieving user stories in JSON format, also supports SSE for new updates on the stories.

Acceptance Criteria:

Fallback to Local Content: In cases where remote content cannot be fetched due to network issues or API unavailability, the system should gracefully fall back to fetching and presenting content from the local database, also make network call if only there is updated data.

Efficient Data Sync Mechanism: Implement an efficient data synchronisation mechanism to keep the local content up-to-date, reflecting changes made remotely when connectivity is restored.

Transparent Handling of Failures: The user should not experience disruptions or errors when transitioning from remote to local content. Any failures during remote fetching should be handled transparently, providing a smooth transition to local content.

Develop as Individual Module: Develop the Stories Data components as independent module, the presentation/ui module should not be aware of the implementation details on this data components.

Unit Testing: Should be able to mock the data easily, should be able to unit test every component involved in the user stories feature.

Approach

let’s break down and analyze the given requirement

Objective: Develop infrastructure components for the app to fetch the User Stories and display them on the UI.

Components Responsibilities:

1. Fetch User Stories from Web ➔ Should be able to fetch the latest user stories json from end point, fetching all the stories respective to the particular user.
2. Fetch User Stories from Local DB ➔ Should support for saving the stories to local DB, and fetch them always from local, if the data is not changed on the remote web side.
3. Maintain consistent data between web and local.

Existing Infrastructure:

• There’s an API endpoint /me/userStories exist which returns the user stories json.
• The above api is paginated, supports default page of 20
• There is SSE support endpoint available on the app receiving updates on the stories.
• Since the feature is on existing app, there will be NetworkHandler, or equivalent classes which uses URLSession, already handling the token exchange, some similar classes handling the databases operations like coredata or sql.

Key Considerations:

1. UI is not finalised yet, which means we have to design the infrastructure independent of the presentation layer.
2. Since there is logic of relying on local data first and then remote web data if the data has updated, we need a single source of truth for Presentation layer always rely on, the data expiry and updation should be taken care from the Infrastcuture side.
3. Fetching of stories is asynchronous, either local or remote, there should option for presentation layer to inform which thread the data should respond, so it can handle the UI updation smooth.

Now lets relate this work with Clean Architecture layers, Presentation, Domain and Data layers, based on the requirement it is pretty clear the UI is not final we would not be working on the UI, rather we would be focusing on the Domain and Data layer, and more precisely we will be focusing on the Data layer.

We need to develop the data layer infrastucture for stories data, the presentation layer should be un aware of the these data layer details, rather should only be aware of the domain details, this exactly fits Repository Pattern which works closely with the Clean Architecture.

Repository pattern is a software design pattern that provides an abstraction of data, so that your application can work with a simple abstraction that has an interface. Using this pattern can help achieve loose coupling and can keep domain objects like Core Data / Room / Realm

It also makes code more testable as it allows us to inject as a dependency a mock repository that implements that defined interface.

lets not get into deeper on the what is repository pattern, rather we will implement the User Stories Data layer using Repository Pattern.

Lets declare what the presentation layer will be interacting with, the domain layer interfaces/protocols which is basically the Use cases, and Value Types

protocol FetchUserStoriesUsecase {
    func fetchStories(userId: String,
                    pageInfo: Int) async -> Result<[UserStory], FetchUserStoriesError>
}

protocol ViewUserStoriesUsecase {
    func fetchFullStoryDetails(userId: String, 
                               storyId: String) async -> Result<UserStoryDetails, ViewUserStoriesError>
}

protocol SyncUserStoriesUsecase {
    func syncUserStories(userStories: Data) async -> Result<Bool, SyncUserStoriesError>
}

There are 3 use cases,

1. FetchUserStoriesUsecase: When we land on the particular screen fetching all the stories.
2. ViewUserStoriesUsecase: When user click on particular story, go ahead and mark the user story as viewed, which would use remote client to update.
3. SyncUserStoriesUsecase: Syncing the user stories from remote to mobile client and vice versa, currently the syncing part from mobile client to remote is updating the viewed part of the story, and from the remote part is fetch the latest and updated stories whenever we receive the SSE from the backend api.

Also we can see in the above declaration that the value types (UserStory, UserStoryDetails, FetchUserStoriesError, ViewUserStoriesError)

Now lets declare the interfaces/protocols what the domain layer would be interacting with, the data later interfaces/protocols, which is basically the Repositories.

protocol StoriesRepository {
    func fetchStories(userId: String,
                    pageInfo: Int) async -> Result<[UserStory], StoriesRepositoryError>
    func fetchFullStoryDetails(userId: String,
                     storyId: String) async -> Result<UserStoryDetails, StoriesRepositoryError>
    func markViewed(storyId: String) async -> Result<Bool, StoriesRepositoryError>
}

The interface of the StoriesRepository is pretty simple, we need to support both the use cases, fetching all stories, and fetching full details on the particular story.

Lets have quick look on how the above protocols looks on the over app architecture.

This is how we integrate the User Stories feature interfaces with Clean Architecture. As illustrated in the Clean Architecture graph, the application consists of different layers. The cardinal rule is to avoid dependencies from inner layers to outer layers. Dependencies can only exist from outer layers inward, specifically from Presentation -> Domain <- Data layers.

Before delving into the implementation, let’s explore what existing assets we can leverage from the app:

• NetworkHandler: available, either fetched from the new Modular architecture in CoreKit (Infrastructure Module) or directly from the legacy App code. These services simply need to be utilized, adhering to Protocol/Interface segregation.
• DatabaseHandler: Similar to the network service, if the app already supports offline storage, there’s likely an existing database. It could be obtained from the new Modular architecture in CoreKit (Infrastructure Module) or from the legacy App code using CoreData. Again, the key is to use it via Protocol/Interface segregation.

The significance of this lies in the implementation of the Stories feature within the clean architecture, regardless of whether the existing app follows clean architecture, any modular architecture, or is an older single-module app codebase. If the app adheres to clean or modular architecture, injecting the NetworkHandler and DatabaseHandler protocols into the Repositories becomes straightforward. In cases where the app doesn’t follow modular architecture, legacy code for network and database-related APIs can still be employed, applying the same principle of breaking direct dependency using Protocol/Interface segregation.

We can refer the previous blog for using the legacy networkService for new User Address, User Orders Feature

protocol DataBaseHandler {
    func fetchObjects<DBObject: NSManagedObject>(usedId: String) async throws -> [DBObject]
}

protocol NetworkHandler {
    func fetchData<Json: Decodable>(urlRequest: URLRequest) async throws -> Json
}

The simplified protocol/interface signatures above will be used inside the Stories Data Layer to implement the StoriesRepository, as mentioned earlier. The actual implementation of these protocols can come from either the legacy codebase or a modular and clean architecture.

With this, let’s examine how the implementation of the User Stories feature interfaces with Clean Architecture.

At a high level, this is how the design of the Stories Data layer looks. Let’s iterate through each acceptance criterion and assess whether our architecture accommodates it or not

Fallback to Local Content: The StoriesRepositoryImp has access to both LocalStoriesDataRepository and WebStoriesDataRepository. The internal implementation of StoriesRepositoryImp should be responsible for validating local data first and deciding whether to make a web call. It can also handle the use case of relying on local data if it exists in the event of a failed network web API call.

Efficient Data Sync Mechanism: We support Server Sent Events (SSE). Since SSE is limited to receiving UTF encoded text, the mobile client will receive events whenever there are new stories updated or when a user views stories on other devices or platforms. The SyncUserStoriesUsecase implementation will receive these events which will contain the updated stories json, which the use case passes it to StoriesRepository to update the data layer

Transparent Handling of Failures: Errors specific to the module and domain level are visible. This means that we will log as well as send all types of error information to the root, allowing the presentation layer to act accordingly.

Develop as Individual Module: The StoriesRepository, the source of truth for user stories data in the app, is developed as a separate module within the data layer of the clean architecture. Following clean architecture principles, the presentation layer has a dependency on the domain layer, specifically the Fetch/View/Sync UserStoriesUsecases. They are not aware of the repositories at all.

Unit Testing: Let’s check feasibility unit testing from the data layer to the domain and presentation.

Data Layer

• LocalStoriesDataRepositoryImp: Has injected dependencies of DatabaseHandle. We can inject a mock class or value type confirming to DatabaseHandle for unit testing without making a DB call.
• WebStoriesDataRepositoryImp: Similar to the above, it has a constructor dependency injected for NetworkHandle. We can inject a mock class or value confirming to NetworkHandle for unit testing without making an actual network call.
• StoriesRepositoryImp: This has only one type (StoriesRepository) of dependency, which is taken as two properties in the init constructor injected dependency. We can mock StoriesRepository and inject it to unit test the StoriesRepositoryImp.

Domain Layer

• FetchUserStoriesUsecase, ViewStoriesUsecase, SyncUserStoriesUsecase: All three use cases depend on the StoriesRepository, declared in the Domain Module itself. We can constructor inject it and unit test the above use cases. SyncUserStoriesUsecase may depend on the interface or service providing the SSE to it, and we can similarly mock it for unit testing.

Presentation Layer

• Nothing is implemented yet, but we have built the `UserStories` data infrastructure. All the ViewModels will depend on the StoriesUsecases from the domain module. The ViewModels can easily inject the mock implementation of these use cases and unit test the view business logic.”

It appears that we’ve successfully met all the acceptance criteria. We approached the design of the new feature following the clean architecture blueprint, separating the data layer from the UI. All components are now testable using mocks. We’ve disentangled tight couplings, enhanced unit testing capabilities, and strengthened modularity.

As mentioned earlier, our exploration doesn’t conclude here. In the upcoming blog, we will delve into another real-world scenario, employing architectural best practices to address distinct challenges. As we progress in our exploration of mobile architecture, anticipate additional hands-on examples, practical insights, and strategies for developing resilient and scalable solutions.

Mobile App Architectural Best Practices in Action [User Story 2] was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

Welcome to “Mobile: Architectural Best Practices in Action” — a series where we embark on a journey through the intricate world of mobile application development. In this series, we won’t just talk theory; we’ll roll up our sleeves and dive into real-world scenarios, use cases, and challenges that developers often face.

What to Expect:

In each instalment, we’ll pick a specific user story, a scenario, or a use case that reflects the complex landscape of mobile app development. But we won’t stop at merely identifying the challenge — we’ll approach it with an architectural mindset, dissecting the problem and crafting a robust solution.

Why Architectural Mindset Matters:

Why do we bother with an architectural mindset? Because in the dynamic and fast-paced world of mobile development, it’s not just about getting the app to work; it’s about crafting a solution that stands the test of time, scales gracefully, and remains maintainable as your app evolves.

Diving into the Design:

We’ll talk about design patterns, styles, and best practices. But here’s the deal — we won’t always take the easy road. We’re going to chat about why we choose one design over another, even if it seems a bit tougher. It’s about making smart choices for great results.

Join the Conversation:

This series isn’t just about me sharing insights; it’s a conversation. I invite you to engage, ask questions, and share your own experiences. Let’s learn together as we resolve the complexity of mobile architectural design.

With that let us get into our first user story.

User Story 1

We need to develop new UI components for the app, which will be part of the existing User Profile Screen.

• Account User Orders UI: Lists all recent user orders.
• Account User Address UI: Lists all user addresses.

Now, there’s a AccountService class extensively used in the mobile app. It's a legacy class, developed a while ago, singleton, and internally handles authentication, token exchange, and fetches data locally in case of offline mode. Here's a simplified version of the class:

final class AccountService {
    
    static let shared: AccountService = AccountService()
    private init () {}
 
    func fetchData(requestParam: UserRequestParam) async -> (Data?, AccountServiceError?) {
        // The internal logic for fetching the data for the url
        // using network classes like urlsession, datatask
        return (Data(), nil)
    }
}

Approach

let’s break down and analyze the given requirement

Objective: Develop new UI components for the app to enhance the existing User Profile Screen.

Components to Develop:

1. Account User Orders ➔ UI Display a list of all recent user orders.
2. Account User Address UI ➔ Display a list of all user addresses.

Existing Infrastructure:

• There’s an AccountService class already in use within the mobile app.
• It’s a legacy class, developed some time ago.
• The class is implemented as a singleton.
• It handles crucial functionalities:
• Authentication & Token exchange
• Local data fetching (for offline mode)

Key Considerations:

1. Legacy Status: Since AccountService is acknowledged as a legacy class, indicating that it can be or soon a later replaced.
2. Singleton Pattern: The class is implemented as a singleton. Singletons, easy to use, but it gives us challenges such as tight coupling and reduced testability.
3. Functionality: The fetchData function is asynchronous, suggesting that it likely performs network operations. The AccountService handles local data fetching, indicating offline support.
4. Scope of UI Components:The new UI components are meant to be integrated into the existing User Profile Screen.

Now, let’s create UserOrderListView and UserAddressListView – the two new UI components that will use the existing legacy service, AccountService.

Not a big fan of singleton, feel it is an anti pattern. Singletons can be ok. But if you are not careful, they aren’t just an anti-pattern.

Also for our feature and timeline, we don’t have bandwidth to develop new modular AccountService from scratch, we have to use the existing one.

An easy and tempting approach is to start the implementation by using AccountService.shared inside UserOrderListView or, if we are following MVVM, inside UserOrderListViewModel.

class UserOrderListViewModel {
    
    func fetchOrders(userId: String) async -> [OrderViewData] {
        let (orders, error) = await AccountService.shared.fetchData(requestParam: UserRequestParam(orderDetails))
        // Here the logic of converting data to type
        // Handling error
        return []
    }
}

class UserAddressListViewModel {
    
    func fetchAddress(userId: String) async -> [AddressViewData] {
        let (address, error) = await AccountService.shared.fetchData(requestParam: UserRequestParam(addresses))
        // Here the logic of converting data to type
        // Handling error
        return []
    }
}

While this approach works, it comes with disadvantages:

Tight Coupling: Yea it looks like we have coupled the AccountService directly to the view models, since it was readily available, but we know the AccountService is legacy class, it will get deprecated after sometime, depends how much refactoring fund is available :P, what if we have new AccountService which is not singleton later stage, then we have get into these view models and make changes, cause low confidence on product, which will again cost development and testing.

Unit testing: Say if we have to unit test the view models, which might reach to the network for fetching the user related information, which is time consuming, not required to unit test behaviour of the viewModel, then if we have to mock the AccountService singleton, which was kind not that hectic on Objective C, but in swift it lot difficult or we have to use 3rd party lib for mocking singleton in swift.

Modularity: What if we are developing the new screens (`UserOrderListView` and `UserAddressListView`) in new module/framework, then the new framework has the direct dependency on the existing module which contains AccountService, which we dont want it, because the purpose of new module is ti keep it independant and easily shippable to other apps, if we have direct dependecy on the AccountService Module, we are forced to ship this new framework along with AccountService Module.

Ok, thats a lot of issues, on this easy fix, lets try extending the 2 seperate functions for fetching orders and addresses

extension AccountService {
    func fetchOrder(userId: String) async -> Result<[UserOrders], UserOrdersError> {
        let (orders, error) = await AccountService.shared.fetchData(requestParam: UserRequestParam(userId))
                // Here the logic of converting data to type
                // Handling error
        return Result.success([])
    }
}

extension AccountService {
    func fetchAddresses(userId: String) async -> Result<[UserAddresses], UserAddressesError> {
        let (address, error) = await AccountService.shared.fetchData(requestParam: UserRequestParam(userId))
                // Here the logic of converting data to type
                // Handling error
        return Result.success([])
    }
}

Now, we have two separate functions for two different use cases, still part of the same AccountService singleton.

As we can see in Clean Architecture graph, we have different layers in the application. The main rule is not to have dependencies from inner layers to outers layers. There can only be dependencies from outer layer inward.

After grouping all layers we have: Presentation, Domain and Data layers.

Following a protocol-oriented approach, we can remove the dependency on AccountService from UserOrderListViewModel and UserAddressListViewModel, also I would remove the import and impressions related to AccountService from the UserOrderListViewModel & UserAddressListViewModel

class UserOrderListViewModel {
    private let orderService: FetchUserOrder
    init(orderService: FetchUserOrder) {
        self.orderService = orderService
    }

    func fetchOrders(userId: String) async -> [OrderViewData] {

    }
}

class UserAddressListViewModel {   
    private let addressService: FetchUserAddressess
    init(addressService: FetchUserAddressess) {
        self.addressService = addressService
    }

    func fetchAddress(userId: String) async -> [AddressViewData] {

    }
}

Thats fine, we have removed the impressions of AccountService Singleton, but we have not implemented how to get the user order list or user address. And we can see there are use case declared and injected to the respective viewmodel, FetchUserOrder use case for fetching user orders, FetchUserAddressess usecase for fetching user address.

Ok, now UserOrderListViewModel should use `FetchUserOrder` protocol interface to fetch user orders and UserAddressListViewModel should use `FetchUserAddressess` protocol interface to fetch user addresses, lets go and declare the functions on the protocols.

protocol FetchUserOrder {
    func fetchOrder(userId: String) async -> Result<[UserOrders], UserOrdersError>
}

protocol FetchUserAddressess {
    func fetchAddresses(userId: String) async -> Result<[UserAddresses], UserAddressesError>
}

Now lets use these functions inside the ViewModels to get the respective details, the view models will look like this

class UserOrderListViewModel {

    private let orderService: FetchUserOrder

    func fetchOrders(userId: String) async -> [OrderViewData] {
        let ordersResult = await orderService.fetchOrder(userId: "userId")
        // Here the logic of converting data to type
        // Handling error
        return []
    }
}

class UserAddressListViewModel {
    
    private let addressService: FetchUserAddressess
    init(addressService: FetchUserAddressess) {
        self.addressService = addressService
    }
    
    func fetchAddress(userId: String) async -> [AddressViewData] {
        let addressesResult = await addressService.fetchAddresses(userId: "userId")
        // Here the logic of converting data to type
        // Handling error
        return []
    }
}

Cool, we have things sorted from the newly created view models, we don’t have tight coupling with AccountService singleton, and we can inject the LocalMocks confirming to FetchUserOrder and FetchUserAddresses to unit test UserOrderListViewModel & UserAddressListViewModel.

But who is going to get the details, since we have no new service for user related details, have to use the existing AccountService singleton, if we scroll up we can see we have extended the singleton AccountService with 2 functions

fetchOrder(userId: String) and fetchAddress(userdId: String)

Now we can connect the FetchUserOrder protocol to fetchOrder(userId: String) and FetchUserAddressess protocol to fetchAddress(userdId: String), which means we can make the AccountService singleton to confirm to FetchUserOrder and FetchUserAddressess, since it implements both the methods.

extension AccountService: FetchUserOrder {
    func fetchOrder(userId: String) async -> Result<[UserOrders], UserOrdersError> {
        let (orders, error) = await AccountService.shared.fetchData(requestParam: UserRequestParam(userId))
                // Here the logic of converting data to type
                // Handling error
        return Result.success([])
    }
}

extension AccountService: FetchUserAddressess {
    func fetchAddresses(userId: String) async -> Result<[UserAddresses], UserAddressesError> {
        let (address, error) = await AccountService.shared.fetchData(requestParam: UserRequestParam(userId))
                // Here the logic of converting data to type
                // Handling error
        return Result.success([])
    }
}

Now this same singleton should be injected in the ViewModels when getting created, which could be taking place in the Coordinator or App Main Module.

Now the above has solved Tight Coupling, Unit testing, Modularity problem, as you see we don’t have direct association with singleton AccountService, we can easily unit test the ViewModels injecting the mock for FetchUserOrder, FetchUserAddress, and we can reuse the same UserAddressListViewModel to different app, if this is extracted out as Module, by injecting the app specific implementation.

we’ve taken a close look at the challenges presented by the existing AccountService singleton. By adopting a protocol-oriented approach and embracing dependency injection, we've untangled tight couplings, improved unit testing capabilities, and fortified modularity.

Our exploration doesn’t end here. In the next blog, we’ll dive into another real-world scenario, applying architectural best practices to solve unique challenges. As we continue our journey through mobile architecture, expect more hands-on examples, practical insights, and strategies for crafting resilient and scalable solutions.

Mobile: Architectural Best Practices in Action [User Story 1] was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

We usually classify them into 5 areas.

• Implementation Semantics
• Api Semantics
• Testability
• Documentation
• Code Style.

If we represent the each area with technical importance vs the time spent, this is how it looks, also it quite evident that we spend most of time reviewing the implementation compared to technically less important items like code style and documentation.

API Semantics

API semantics refers to the meaning and behavior of an API (Application Programming Interface), which is a set of protocols, classes & modules for building software applications. When reviewing the semantics of an API, you would typically consider the following:

Purpose
What is the purpose of the API and what does it do?

Inputs & Outputs
What are the inputs and outputs of the API? Are they well-defined and appropriate for the intended use case?

Error Handling
How does the API handle errors? Are the error messages clear and informative?

Data Models:
Are the data models used by the API well-defined and appropriate for the intended use case?

Implementation Semantics

Implementation semantics refers to the specific implementation of a piece of code, as opposed to the API semantics which define how the code is intended to be used. When reviewing the implementation semantics of a piece of code, you might consider the following:

Code Structure:
Does the code use encapsulation and modularisation to achieve separation of concerns? Are the components loosely coupled as much as possible.

Code Efficiency:
Is the code efficient in terms of runtime and memory usage? Are there any opportunities to optimize the code?

Code Correctness:
Does the code do what it is intended to do? Are there any bugs or issues that need to be addressed?

Code Maintainability:
Is the code easy to modify and maintain over time? Are there any potential issues that could make the code more difficult to work with in the future?

Code Security:
Does the code follow best practices for security? Are there any potential vulnerabilities that need to be addressed?

Code Reusablity:
Does the code use reusable components, functions, and services?

Testablity

Test coverage: Is the code adequately covered by tests? Are there any areas that are not adequately tested? Ensure that the test cases cover a wide range of possible inputs and scenarios, including both valid and invalid inputs.

Independent:
Check that the test cases are independent from one another and do not depend on the execution order

Easy to Understand:
Verify that the test cases are easy to understand and maintain.

Completeness:
Make sure that the test cases are thorough and complete, covering all relevant functionality and edge cases.

Organized:
Check that the test cases are properly organized and grouped, with appropriate separation between different types of tests.

Documentation

Documentation: Is the code adequately documented? Are there any areas that could benefit from additional documentation?

On a personal note, I prefer the class/function/api/variable names should speak more about the functionality itself. but still on few cases we definitely need documentation when exposing the library api.

Code Style

Use clear and concise code:
Write code that is clear and concise, rather than overly complex or unnecessarily verbose. This will make it easier for others to understand and maintain the code.

Follow naming conventions:
Follow naming conventions for variables, functions, and other code elements, as this will make it easier for others to understand and work with the code.

Keep lines of code short:
Try to keep lines of code short, as this will make it easier to read and understand the code.
Is the code well-formatted and easy to read? Are there any style guidelines in place that are being followed or violated?

Additional Thoughts

Ensure your feedback justifies your stance

When reviewing code, don’t simply suggest what needs to be fixed or improved upon — explain why the developer should make that change.

During development, you’ll mostly deal with problems that can be solved with multiple solutions. The comments you include in the code are a product of your knowledge and experience; you might prefer tackling an issue in a specific way, which may be different from the code author’s approach. Therefore, you should articulate your coding choices to explain your reasoning.

There are two benefits to this approach. First, the code’s author will know why they should make a particular change, which will help them tackle similar problems in the future. Second, since you already justified your comments, they won’t need to follow up with you about the reasoning behind your comment, saving both of you time.

Don’t review more than 200–400 lines of code at a time

Reviewing more than 400 lines of code (LoC) can have an adverse impact on your ability to find bugs, and in fact, most are found in the first 200 lines. This limitation affected industry practices after Cisco identified it in a comprehensive study on code review.

The study found that, once developers reviewed more than 200 lines, their ability to identify defects waned (see the chart below).

It’s important to keep in mind that a code review is not just about finding problems, but also about identifying opportunities to improve the code and make it more maintainable in the long run.

The Code Review Best Practise was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

Unit testing is a type of automated testing meant to verify whether a small and isolated piece of the codebase the so-called “unit” behaves as the developer intended. An individual unit test is known as a “test case” — consists of a piece of code that exercises the production code in some way, and then verifies whether the result matches what was expected.

Why Unit Testing?

• Unit tests help to fix bugs early in the development cycle and save costs.
• Reduces fragility — making changes in the existing code breaks another working part of code or flow, this can be reduced and identified during the development stage using proper unit testing.
• Good unit tests serve as project documentation, a code snippet on tests explain more on how to use the class or function rather than a paragraph of documentation.
• Unit tests help with code re-use. Migrate both your code and your tests to your new project. Tweak the code until the tests run again.

Tips for writing test

There are 3 tips that I usually follow when writing tests in Swift.

1. Design your code for testability
2. Clear API Boundaries
3. Avoid getting tied to Implementation Details

Note: Examples I have used swift, but it’s not specific to swift, it’s more on functional programming tips for designing & coding for unit testing.

Design your code for testability

What makes a code easy to test?

Well according to me, when we are not doing a lot of mocks or hacks or complex setups just to test a single API behaviour then it's easy to test. something like you gives ActivitiesPayloadResponse struct to ActivitiesViewModel and gets back the viewData from it, it could be activities total count test case or unread activity titles.

But, we don’t have every class or function simple as giving input data and verifying the output, there are places where we need to do mocks and setups, but let us try to keep it minimal. On other hand, think of someone reviewing our test, he should not spend more than 30 secs to understand it.

3 core principles for Designing Code for Testability

Unified Input and Unified Output

In the functional programming world, there is a term called pure functions, pure function is a functions which takes inputs and returns an output with no side effects, the same input should generate the same expected output every time, no matter how many times you call it.

Keep the State Local

We tend to use singleton in most places because it's easy to use and apple itself is using it in many places, singleton can be nice for sharing API's and for convenience, but it also leads to a dangerous pattern of sharing state.

Dependancy Injection

Always try to inject the dependant objects which are being used inside our class functions, which means we want to avoid accessing those objects in our implementations as a shared instance or creating and accessing local instance.

That's enough of the theory, let's get practical, I cannot sell this topic without experimenting with it.

Let’s see all the above principles with an example class called FileLoader, credits to John Sundell picked these intuitive examples from one of his talks.

That's a FileLoader pretty decent class, it loads the file with the given fileName from the main bundle if exist else throws an error, also it caches the file, which is actually good, so we don't load from main bundle every time. Now let's apply the Design of Code for Testability to the above class and check if it's good for unit testing.

Unified Input/Output

The FileLoader takes fileName as input, and returns File if the file with filename exists in the main bundle, else throws. But if you see the implementation there are 3 possible outcomes from the function.

• The happy case where a file exist, returns the File loading it or from the cache.
• Throws foundationKit error if the file is corrupted when converting the file to Data
• We throw NSError if the file doesn’t contain the main bundle.

Definitely, the output is not unified here, this is not satisfying the Unified Input/ Output principle

Keep the State Local

The FileLoader contains shared instance or singleton dependency as you can see Bundle.main and shared FileLoader, we are not keeping the state local. As is clearly evident that the function is not obeying the Keep the State Local principle.

Dependency Injection

The FileLoader depends on 2 objects here, one is the cache and the other in the Bundle, and as you can see none of them is injected as dependency, it is accessed locally or using a singleton, which will kind of makes us difficult to test.

That's interesting right our decent FileLoader class is no more decent for unit testing, so let see how can we make it obey the Code for Testability

Applying Code for Testability Principles

Let us take it one by one, will try to make the FileLoader obey Unified Input/Output principle.

Here if you see, there is a dedicated error type for FileLoader, where it returns FileLoaderError.invalidFileName for invalid fileName error and FileLoaderError.invalidFileData for corrupted file data, whereas previously we were returning the NSError or the Error is thrown from the try Data(contentURL:), this way have modified the code take unified Input (FileName String) and unified Output (File or FileLoaderError).

Next let's try to remove the shared instance, do we really need
static let shared = FileLoader()

Many times we use it because it is easy to access and use, if we think, we might not need a singleton here instead every class that needs it can create and get the file loading operations, or it can be passed as a reference to the classes where it is required.

The last one the Dependancy Injection, as pointed out earlier we have 2 dependency objects (Cache and Bundle) used by FileLoader.

With this change, we are passing the dependant objects as an initial parameter so this will be super helpful when we are writing unit test for the same, this doesn’t have to be the object itself, it can be 2 protocols if required and also since we are supporting default parameters, the users of FileLoader other than Unit Testing need not worry about injected parameters, they can still create just as FileLoader().

We did very minimal changes to code, now kind of the FileLoader has changed from Hard to Test → Easy to Test. Now that I claim it's easy to Test you guys trust me? Not required let's write some tests for FileLoader and see is it really easy to Test.

We will try to test caching behaviour of our FileLoader couple of ideal behaviours coming to mind are

• Save file to cache when loading the file first time from bundle
• Retrieve a file from the cache when the file already exists in the cache.

There can be many cases, just picking these to explain stuff related dependency injection of cache.

• The 1st test case is for unit testing if the file loaded by FileLoader is saved into cache or not. Because our FileLoader’s one of the cool features is, it caches the files once loaded from Main Bundle.
• The 2nd test case is for unit testing if the file accessed by FileLoader is retrieved from cache or not, say we have dependant cache containing the same file already and injected to FileLoader, now if the file is accessed by FileLoader it should return the file from Cache instead of loading from the main bundle.

Clear API Boundaries

When we usually write a test, we tend to write a couple of types, 1 is a unit test where we verify if the API works correctly or not, validating the output against the given input, the other test is where we actually integrate modules and do an integration test.

Many times it is difficult to identify the clear boundary between unit and integration tests. If we look at Michael Feathers (Author of Working Effectively with Legacy Code) definition of Unit Testing.

A test is not a unit test if:

• It talks to the database
• It communicates across the network
• It touches the file system
• It can’t run at the same time as any of your other unit tests
• You have to do special things to your environment (such as editing config files) to run it

Ok, Ok, Thats fine, but why?

Here is what his explanation are.

First, speed. When it comes to unit testing best practices, speed is the most important of them. Relying on things like the database or the network slows tests down.

Then, we have determinism. A unit test must be deterministic. That is to say, if it’s failing, it has to continue to fail until someone changes the code under test. The opposite is also true: if a test is currently passing, it shouldn’t start failing without changes to the code it tests. If a test relies on other tests or external dependencies, it might change its status for reasons other than a code change in the system under test.

Finally, we have the scope of the feedback. An ideal unit test covers a specific and small portion of the code. When that test fails, it’s almost guaranteed that the problem happened on that specific portion of the code. That is to say, a proper unit test is a fantastic tool for obtaining super precise feedback.

If on the other hand, a test relies on the database, the file system, and another test, the problem could be in any one of those places.

As shown in the above picture, there are 2 modules User Profile Module (UI related to UserProfile) and User DB Repo (Database Module) which are been tested individually with inputs and validated using asserts.

When we are unit testing the UserProfile Module, definitely we would not be using the UserDBRepo instead we mock the UserDBRepo interface in UserProfile Module and unit test, which way we are not making DB or file system calls.
Again when unit testing the UserDBRepo Module, we would be injecting in-memory mock DBHandle which handles DB CRUD operations, using which we can unit test all possible APIs for UserDBRepo Interface.

But when it comes to testing UserProfile Module using UserDBRepo, this is usually not a unit test it is an integration test, and it's not that we should not write these tests at all, it would be good to write these tests, but often these tests are slow and not reliable, when the project grows, these integration test will consume a lot to time to build and run the entire test suite, and sometimes if the test fails, we are not sure which module has caused the failure.

Avoid getting tied to Implementation Details

Testing behaviour means testing what code does. Testing implementation means testing how code works. So which one we should be testing?

Testing Behaviour OR Testing Implementation

Unit Testing On Behaviour

When you write tests for behaviour, you can refactor your code (the implementation) in confidence without breaking the tests, the tests only break when behaviour has changed (unintentionally — which means you’ve introduced a bug or intentionally code has new changes, which means tests need to be updated to the new behaviour).
These types of tests are extremely valuable because a broken test means your code is broken.
Testing behaviour guarantees your code works as expected (for the behaviour you have tested).

Unit Testing on Implementation

When you write tests for implementation, tests break when you change code, even if the behaviour didn’t change.
These types of tests aren’t very valuable because a broken test doesn’t mean your code is broken and a passing test doesn’t mean your code works as expected.

Testing implementation only guarantees your code was written as it was tested.

Applying Unit Testing on Behaviour of function/class instead of Implementation.

Ok let us see this with an example, let consider simple class ImageViewController

That’s our ImageViewController, it has a dependant ImageLoader which loads the remote web images, and the ImageViewController sets the downloaded image to its imageView.
Now let's see what is the implementation steps looks like

• Step 1 ImageViewController creation
• Step 2 Call loadRemoteImage from ImageLoader via reloadImageView for downloading images from remote web URL.

If we write the test for the above implementation steps?

Ok, we have mocked the ImageLoader to MockedImageLoader, yea that's there because we are loading the image from a network call, so understandable. We now inject the same to ImageViewController and call reloadImageView, later we check if the mockImage given to MockedImageLoader is loaded into loadedImages set or not. That's fair, that's exactly what has been implemented.

That seems like a unit test, but are we really testing what the ImageViewController suppose to do? Oh! No! the ImageViewController suppose to load the image from the remote URL and display it in the imageView. But we are rather unit testing logic of ImageLoader is loading given image or not, that's because we wrote the test with the implementation details in mind, that's why we ended testing the ImageLoader rather than the ImageViewController itself.

Now lets us try to write a test for ImageViewController reloadImageView behaviour.
Let us tweak our ImageLoader a little so we can write the unit test for the ImageViewController behaviour.

Now will see the unit test for verify the ImageViewController’s reloadImageView behaviour.

Interesting right?

We have not mocked the ImageLoader, yea we don’t need to, we are verifying the outcome of reloadImageView which is checking if ImageView.image is what sent via mockImage, and one more advantage is we don’t need to update the unit test, even though we modify the implementation of ImageViewController and ImageLoader, until the behaviour of ImageViewController reloadImageView is same.

That's a very simple example of writing a unit test to class/functions behaviour instead of implementation.

Design Code for Unit Testing was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

Looking for an understanding on VSCollectionKit, here you go!!!!!

VSCollectionKit is a library for building applications views/screens in a consistent and understandable way, with advantages like composition, independent and testing.

VSCollectionView a handy framework supporting functionality of a UICollectionView or UICollectionViewController in a much simpler way. VSCollectionKit also avoids a lot of collectionView related code hassle and duplicates.

Lets see what we get using this kit for developing the application views

Composition: VSCollectionKit breaks down larger features into smaller components that can be isolated modules and be easily combined to form a full feature.

Mobility: Using VSCollectionKit, we can develop a component to be independent ie., the component doesn’t know anything about the user using it. This gives us a confident of using it in multiple places of same project hassle free.

Testing: Using VSCollectionKit, each and every component can be tested individually. As it makes smaller independent components to become a bigger complex viewcontrollers, there will be less or NIL integrity issues (fixing in one place which causes a bug in a different place).

Here is an example that helps you to understand better. The screenshots of the Test app developed using VSCollectionKit presented below.

VSCollectionKit Components

VSCollectionKit consist of VSCollectionViewController which is a subclass of UIViewController with UICollectionView.

VSCollectionViewController works in association with 5 other parts like

1. VSCollectionViewDataSource
2. VSCollectionViewData
3. VSCollectionViewDelegate
4. VSCollectionViewLayoutProvider
5. VSCollectionViewSectionHandller

Though the component names justify their functionality, a brief description are explained below for our strong foundations.

1. VSCollectionViewDataSource is a subclass of NSObject confirming to UICollectionViewDataSource mainly involved in handling or supplying data to our collectionView. It takes VSCollectionViewData and applies inserting and updating the changes to the current UICollectionView.
2. VSCollectionViewData is a struct that mostly contains the details about our data to be displayed on CollectionView. It contains an array of sections confirming to SectionModel protocol. Also, updates array containing details about the changes in data which is getting applied to a collection via VSCollectionViewDataSource.

3. VSCollectionViewDelegate is a subclass of NSObject confirming to UICollectionViewDelegate. This class mainly involves handling delegate events of collectionView. Please note that we are not using this delegate for determining the size of cell or supplementary view.

4. VSCollectionViewLayoutProvider is a component which is responsible for supplying the layout information to the collectionView. VSCollectionKit uses UICollectionViewCompostionalLayout for cell and supplementaryview size information.

5. VSCollectionViewSectionHandller would supply the cell information, layout information and helps in handling events from the collectionView via VSCollectionViewSectionHandller.

That's the theoretical view of VSCollectionKit and their components!!!!

How to use VSCollectionKit?

VSCollectionViewSectionHandller handles adding and removing of SectionHandler for the VSCollectionViewController. We can have n number of sections supported by collectionview via VSCollectionViewSectionHandller’s addSectionHandler(handler: SectionHandler) function.

The protocol declaration of SectionHandler is below.

Probably you caught them right!! Yes the collectionview related functions falls in the individual SectionHandler.It seems to be less complexed because it contains only the necessary functions to be implemented, if we still need more we can always go and extent it from components like VSCollectionViewDataSource and VSCollectionViewDelegate.

An example on how we can use VSCollectionKit to display grid of photos from local.

As you know, the VSCollectionViewController understands data by VSCollectionData, so our example is quite simple showing list of photos in CollectionView. We would be converting the list of image urls to VSCollectionData’s SectionModel and CellModel.

Snippet of the above brief.

Having a thought on how we are providing the cell and layout information? Let’s think it together! We need to create a class confirming to protocol SectionHandler, which is where we would be implementing the necessary functions to supply the cell and layout information to the collection view.

The final touch of how are we applying the data to collectionView shown below.

We need to override var sectionHandlerTypes: [String : SectionHandler.Type] and add all the sectionHandlers Types which we would be using in our collectionView, provided each sectionControllers should confirm to protocol SectionHandler as shown above.

How to Use VSCollectionKit in a Project

Include the below line in the project carthage file

git "https://github.com/Vinodh-G/VSCollectionKit.git" >= 1.3

and then call carthage update from the project folder where it is used.

There is a News Sample App developed using the same VSCollectionKit Carthage dependency, it uses VSCollectionKit for all the screens of the app.

The VSCollectionKit github link is https://github.com/Vinodh-G/VSCollectionKit

The sample app can be found here(In Progress):
https://github.com/Vinodh-G/NewsApp

@Architecture @Designpattern @Composition

Generic programming is a way of writing a reusable functions & types in a flexible way

Its a feature of swift, much of swift standard libaray build with generic code.

lets understand it solving the existing problem

The above function swaps the two Int using pass by reference, now if I need to write a function which does swaping of strings, I would be writing one more function like shown below

As you can see the implementation body of both functions are same, the only difference is in the type of parameters.

Now lets see how Generics solves the above duplicity of code

Thats how our generic function to swap two values will look like,

• <T> just after the function name indicating this is a generic function which take parameters of type T
• Function arguments list contains the Type as T instead Int, Double or String, which would be replaced with actual type

The below code shows how the above generic function swapTwoValues used for swapping Strings, Int values.

So thats quick Intro of Generics, Generic Function.

Topics we would be covering reading further

• Generic Types
• Type Constraint to Generic Functions/Types
• Associated Types

Generic Types

As expected, yea!! you can write generic types in swift, the most common types we use day to day the Array, Dictionary are Generic Types

lets dig into the code without any further theory

The above structure IntStackwhich uses an array to push and pop the Int items to stack, the `push() & pop()` functions are mutating because they are modifying the structure items array.

Now lets see if I need a generic type which can push and pop not only Int item types but also other types.

There is not much difference isn't it?

Struct Name is appended with generics syntax <Element> where Element is a Type which would be replaced with actual Types (Int, Double, Strings, etc)

Element used as place holder in three places

• The property items which is initialized with array of values of type Element
• The push() function is taking a parameter of type Element
• Return value of funtion pop() is of type Element

The above code shows how we have used the Generic Stackpushing and popping items of type String and Int.

Extending Generic Type

The above snippet is an extention of value type Stack with topItem as computed property in it, topItem is of type Element will return nil if stack is empty else the last item.

Type Constraint to Generic Functions/Types

In swift we can enforce certain type constraint on the types that can be used with generic functions and types

Didn't get ?

May be lets read the below line and try mapping it again.

We can define a generic function or type with a rule saying,

• Type used should always confirm to a particular protocol or protocol composition
• Type used should be inherited from a particular class

For example, In Swift’s Dictionarydictionary’s keys must always confirm to protocol Hashable else it cannot be used as key in Dictionary

Lets see a generic function with type constraint

<T:Equatable> the syntax indicate that the generic function will take types only confirming to protocol Equatable

By default all Data types String, Int, Double, etc are confirming to protocol Hashable which confirms Equatable protocol , so the above code works with out any issue.

Lets not wait to see a generic type with type constraint, will create a NavigationControllerStack for pushing and popping viewcontrollers which is of class UIViewControllers or its subclasses

Thats how the NavigationControllerStack looks like, the syntax <Element:UIViewController> after the class name indicates that, this class will take Element only if they are inherited from UIViewController.

In the above code snippet, we create a ContactsViewController instance which is inherited from UIViewcontroller and Push to the NavigationControllerStack , same way PeopleViewController instance which is inherited from UIViewcontroller is Pushed.

Associated Types in Generics

Here we will see how we can use generics in protocols. Unlike classes, structs, enums, protocols supports generics in different way, the swift terminology calls it as Associated Types

An associated type in protocol says

“I dont know what exact type this is, some concrete class/struct/enum that adopts me will fill in the details.”

The above snippet shows the declaration of Containment protocol , Containment declares an `associatedtype` called Item which protocol doesn't know what exact type it is, the class or struct who implements Containment will know about it.

The Container protocol defines two required capabilities that any container must provide:

• It should be able access the top item in the container through function topItem() at returns a Item type
• It should be able to access a count of the items in the container through a count property that returns an Int value.

Will use the the above Containment Protocol in our Stack value type

The protocol Containment with associated type Item which was as place holder filed by our Stack struct as Element

Means the protocol funtion topItem() returns the item of type Element which was Item in protocols declaration.

Thats about the basics of Generics and related topics, If interested further feel free to check out the TRIE Data stucture Implemented using Generics.

ARC is a compile time feature XCode provides us for automated memory management. It stands for Automatic Reference Counting. In simple terms, ARC frees objects only if the strong reference count goes to ‘zero’

According to ARC Memory management, an object can be one of referencestrong, weak or unowned type with a variable, will be discussing more about them further, for now, if the object doesn't have any key word before let statement then by default it will be with strong reference.

let name = String() // name variable has a strong reference to instance of String

Lets understand with code,

The above snippet declares a class called Employee with name, empid & title as the ivars, At line number 19 we create a instance jack of class Employee passing all the employee details, so jack variable has a strong reference to object.

According to ARC memory management object with at least one strong reference will not be free/deallocated.

At line 20 we nil the reference to the object jack which in turn deallocates or frees the object which it was referring to, thats how the deinit() funtion of class Employee is called before it frees the object, and as we see the log Employee: Jack removed.

Let’s add the reference to the variable jack before niling it out.

"Where did the deinit log “Employee: Jack removed” go ?" we made jack = nil right? why did’nt it logged ? Now thats ARC memory management, the jack object was not deallocated even though we made it nil, because the variable jackReference at line number 20 has a strong reference to an instance were jack was pointing to, so the strong reference count of object were jack was pointing too was not zero hence not deallocated or freed, if we make jackReference = nil then we will see the log of deinit Employee: Jack removed.

That’s the verify brief ARC intro.

Now coming to actual problem, Strong/Retain Cycle

As we know each time we declare a class property by default it has a strong reference to object which it is pointing to unless we specify something, so when can a strong cycle appear?

Cases were ObjectA has a strong reference with ObjectB and ObjectB, in turn, has a strong reference to ObjectA

Let’s understand with a code as usual

Let’s make use for our Employee class itself, and let's declare one more class MacBook

So that’s how the classes look, Employee has 4 ivars or properties with strong reference name, empid, title & macBook so the first 3 properties are of type String, the macBook is of type class MacBook, it is defined below Employee class in the snippet, same way the MacBook has 2 properties serialNumber & assignee as we can see the property assignee is of type class Employee.

Now let’s see how the strong cycle occurs

What!! where is the strong cycle? I created the instance employee line 33, created an instance of mac at line 34, assigned employee?.macBook = mac then I nil both employee and mac you know both got removed as I can see in the log, so were is the strong cycle?

Actually, the strong cycle is not created yet, in employee we made the property macBook to point to an instance mac which is a strong reference relation with mac, but as we can see in the MacBook class there is property called assinee which we didn't set to employee yet, let's add mac.assinee = employee before we nil both employee and mac.

Why didn’t the log print now?? we made both employee and mac nil, so? so here we made a crime of making strong reference cycle between employee and mac

• employee object has a strong reference to property macBook which is pointing to mac
• mac object has a property assinee with a strong reference pointing employee

Thus they both became a retain cycle, means employee will be retained by mac and mac will be retained by employee so they both don't get freed or deallocated.

How can we resolve this? there comes the saviour weak reference

A weak reference is a reference that does not keep a strong hold on the instance it refers to and so does not stop ARC from deallocating the referenced instance. This behaviour prevents the reference from becoming part of a strong reference cycle. You indicate a weak reference by placing the weak keyword before a property or variable declaration.

That’s what apple document speaks about weak reference, let’s try breaking the above retain cycle with the weak keyword.

Let employee still have a strong reference with macBook we will make the assinee property of MacBook weak by just adding the keyword weak before the var as shown below.

Did you notice anything? yea there is a key word weak before,var assinee:Employee and now you can see the both employee and macbook object/instance is deallocated as confirmed in the console Employee : Jack removed, & Mackbook : JHSF8S32 removed is logged.

So we did break the retain cycle with the weak reference type.

So what about unowned ? when is that used?

A unowned reference does not keep a strong hold on the instance it refers to.

That statement seems repeating? isn’t it the same definition even weak reference we read? Yes!! Like weak reference when a variable or property declared with unowned key word before, doesn't hold the strong reference to the object which it is pointing to.

So you mean to tell, we can break the above Employee and MacBook retain cycle with unowned reference as well? Yes!!

Then why do we need the unowned keyword ? there should be some condition were we should use unowned not weak and vise versa, lets see what apple doc tells about it.

“Like a weak reference, an unowned reference does not keep a strong hold on the instance it refers to. however, an unowned reference is used when the other instance has the same lifetime or a longer lifetime.”

Lets tweak the above statement little for our understanding

“weak reference is used where there is possibility for that reference to become nil at some point during its lifetime. an unowned reference is used where there is no possibility for that reference becoming nil at any point until the self-object exist”

Seems still confused, if it is let’s resolve that reading further with code example.

You indicate unowned reference by placing the unowned keyword before a property or variable declaration.

Let’s use our previous Employee class and one more class say,ICard each an every employee will have one iCard and each iCard would be pointing to one employee

Now that’s our employee class, which has 3 properties name, title & iCard were iCard is of class type ICard which is defined as shown below

As expected as we know there is retain cycle between employee and,icard the iCard variable of Employee class has strong reference to ICard and same way employee variable of ICard has strong reference to Employee

We know the trick to break the retain cycle lets go and add weak keyword before the employee variable of ICard class

Ohh!! no seems my compiler is not happy about it, it says ‘weak’ variable should have optional type ‘Employee?’ Ohh that's a good suggestion but I cannot make my employee variable in ICard class as optional by adding ?, because the ICard class is valid only if it has a valid employee, every instance of ICard should have a valid employee associated with it, so making it optional is not the solution.

Ok, we let’s use unowned key , as we read earlier this also used to break the retain cycle.

Ok we lets use unowned key , as we read earlier this also used to break the retain cycle.

Wow my compiler was happy, it didn’t shout at me this time, and see line 71 I created an instance of Employee jack , line 73 I create an instance of ICard passing the jack as an argument, line 74 I assigned jack.iCard = iCard, and I nill both the objects, with out any surprise or retain cycle the Employee and ICard has been removed as we can see from the logs

Got little when to use unowned ? or weak?

Ok back to our previous example Employee and MacBook , why didn't we use assinee as unowned, in code : Employe and MacBook Definition because in that use case there is a chance the assignee might become nil when jack takes new laptop, in that case, the assignee variable of MacBook would be nil until it points to the new employee it is assigned to.

So that’s not the only retain/strong cycle problem, it just doesn’t occur between class instances, there are chances of creating a retain cycle while using closures, If not sure about what is closures I recommend read closure before continuing further.

Let’s create PhotosViewController responsible for displaying the photos, and one more class PhotosViewModel which is responsible for getting the photos to our PhotosViewController

That’s our,PhotosViewModel at the top we have declared a closure type DidGetPhotos which takes one parameter photos which is array, As mentioned earlier this class is responsible for getting the photos to the PhotosViewController through didGetPhotos closure.

Now let’s see our PhotosViewController

Let’s read the PhotsViewController line by line

line 102 we create declare and initialize a photosViewModel object of type PhotosViewModel, so thats the object responsible for getting photos

line 104 we defined a loadPhotos() function in which we assign a didGetPhotos closure to our photosViewModel, so this is the place we get a callback from our ViewModel getting all the photos. and inside the closure we call the function updatePhotosInView() to display the photos given by photosViewModel

Does this have a Retain cycle? let’s check it out, as usual, let’s create an instance of PhotosViewContoller and nil it out, verify that it logs inside deinit(), its deallocated or freed.

Where is our deinit() log? we created an instance we called loadPhotos() and we set the photosViewController to nil, ideally, it should have deallocated right? before finding an answer let’s read below fact about closure

In swift accessing a self inside a closure makes the closure have strong reference to self.

Did it mean closure will retain self if it is used inside closure ?? Yes

let’s picturise

Ohh Yea!!, seems there is retain cycle, photoViewController has a strong reference to photosViewModel, photosViewModel has a strong reference to didGetPhotos() closure, and we accessed the self inside the closure in line 106 loadPhotos() function.

Let’s break it with a trick we learned before (weak, unowned) , so will go ahead a make the didGetPhotos property weak?, no, you cannot, the compiler will shout at me, can we do something inside the closure ??

Yes absolutely!! , we have to break the cycle from closure, as we know the closure captures reference right, so we need to tell the didGetPhotos closure inside the PhotoViewController to capture the self with weak reference.

let’s check the code now how it looks?

Ohh yeah there you go, seems the photoViewContoller is deallocated now, as you can see the log Deinited the PhotosViewController, what did we do?

Observe line number 105 we captured the self as weak reference by providing [weak self] before the closure parameters, as you see we pass that as an array , I mean we pass those captured values in an array [], means we can capture more than one reference inside the closure.

That’s all I have now about Retain/Strong Cycles, feel free to drop a comment if there is anything, hope will come next time with some new problems and techniques.

SOLID is a mnemonic acronym named by Robert C. Martin used in Software Programming, It represents 5 principles of Object Oriented Programming.

• Single Responsibility Principle
• Open Closed
• Liskov’s Subsititution
• Interface Segregation
• Dependency Inversion

These principle solve bad architecture problems like

Delicacy — A change in one place breaks unexpected parts, its difficult to trace if there is no good test coverage.

Immobility — A component is difficult to reuse in another project or use in multiple places of same project, because it has to many dependencies.

Irritable — Takes a lot of effort for change, because it affects several parts.

These SOLID principle are not strict rules, but just guidelines to improve the quality of the your architecture.

Lets dig in the principles one by one

Single Responsibility Principle

Each an every class you create/change should have only one responsibility

Let us see an example explaining it, I have to develop a messenger app screen to get the list of past conversations. So I have a ConversationInteractor which gets me the array of previous conversations.

How many responsibility does this class have ?

• Gets the conversation data form the API
• Parse and create conversation structs or objects from API response
• Saves the conversation array to Database either core data or something.

If we have to implement NSURLSession for getting Json Data from API, and JSONSerialization to parse and Core Data Stack for saving to Database, this class becomes huge monster class.

we can solve this problem moving the each responsibility down to different classes

I have created separate classes for each responsibility which ConversationInteractor was handling, this is how our classes looks now.

As we can see now we have split the responsibility of the bigger task into 3 classes (ConversationInteractor, RemoteService, ConversationDBOperation) which makes easy for us to deal with particular class rather than the giant ConversationInteractor

This principle helps you to keep your classes as clean as possible, and we have a advantage of testing each and every API separately, with previous implementation we would not be able to test `fetchRemoteConversationJsonData()`, `convertJsonToConversation(data:Any)`and `saveToDatabase(conversations:[Any])` because they were private functions inside ConversationInteractor. Now it seems we can test each an every pieces (`ConversationInteractor`, `RemoteService`, `ConversationDBOperation`) separately.

As we can see all the 3 classes are connected via a protocol, which can be easily decoupled, we would be covering this topic in detail further.

Open Close Principle

Classes and Modules should be open for extension but closed for modification

Strive to write code that doesn't have to change every time the requirements change.

To understand this principle easily lets take a basic example of calculating the area of geometry shape.

Lets say we have requirement to calculate area of rectangle, so the rectangle and related area calculator class looks like shown below

Now the requirement has come to calculate area of not only Rectangle even for Circle, so our AreaCalculator class will look something like.

This will work but what if tomorrow one more requirement comes to calculate the area of Triangle, area function inside AreaCalculator class keeps growing with if else conditions, according to Open Close Principle we should not modify the existing class rather extent it.

One way of solving this problem is create a protocol (which is similar to Interface in Java) called GeometricShape and declare area protocol method, implement the GeometricShape protocols inside Rectangle or Circle or any other geometric shape class, if it is confusing still may be checking the code below may clear it.

so if there is requirement tomorrow to calculate the area of even Triangle, we should be able to achieve it without modifying the existing AreaCalculator struct just by extending the GeometricShape Protocol for Triangle, This obeys the SOLID Open Close Principle.

Thats a very common example for understanding the principle of not modifying the working class, lets see some real world example for Open Close Principle, very common example which we use on most of case when showing some data on UITableView, say we have requirement to show list of products and ads in the ListView or TableView, the ViewController or ActivityController would look something like as shown below.

Looks like something similar to our old AreaCalculator problem right, say suppose if we need to display new type cell called SuggestionCell, we need to go and change the existing ListViewController handling the new type of cell, this ListViewController is not obeying the OCP.

Now let’s apply OCP to our ListViewController, the class should be opened for extension and closed for modification, which means we should not modify the ListViewController but should be able to support new types of cells.

Let’s create protocol SectionHandler which has method related to creating a UITableViewCell and sectionType property, SectionContainer which handles all the types of SectionHandlers.

If we checkout the above snippet, can see the SectionContainer picks respective SectionHandler based on the cellModel type and calls tableView related method asking for UITableViewCell, which means we should be having the SectionHandlers w.r.t. the use case, here in our case its ProductSectionHandler and AdSectionHandler, both confirming to SectionHandler protocol.

Okay its kind of confusing right, now let’s see our original `ListViewController `which is obeying to OCP, so we can understand it better.

Oh yea we don’t have if else statement in the `tableView:cellForRow indexPath function, how is the ListViewController created? well checkout below.

Now kind of convinced? No!! ok prove me if we add new SuggestionCell to list how it will look, ok let’s see below.

Kind of agreeing now? we didn’t change the existing class ListViewController for supporting new SuggestionCell, we just created the new SuggestionSectionHandler class confirming to SectionHandler for supporting the new SuggestionCell.

Pictorial representation of Open Close Principle in brief shot.

Liskov’s Subsitution Principle

Child classes should never break the parent class type definitions

It means, we must make sure that new derived classes should extend the base classes without changing the base class behaviour

As simple as, a subclass should override the parent class methods in a way that doesn’t break the functionality of base class from client point of view.

Lets see this with an example, we have two classes Rectangle and Square since Square is also a form of Rectangle, so Square is subclass of Rectangle

Here in the above block Square inherits the width and height property from Rectangle and overrides the width and height property to return the same height and width since it is Square.

Since our requirement is to calculate the area of Rectangle and Square, we will to use the AreaCalculator class.

Lets go a head and write Unit test cases to calculate the area of Rectangle and Square

In above both test cases should pass since we have used instance of Rectangle to find area of rectangle and instance of Square to find area of square, now lets go a head and create a test case in which we will try to substitute object of Rectangle with object of Square, since Square inherits from Rectangle we should be able to find area of rectangle with Square instance.

In the above test case we have used instance of Square class to find the area of rectangle, since square inherits from Rectangle, but its very unfortunate that the above test case fails, the AreaCalculator returns the value of 16, were as the expected area was 12, this violates the Liskov’s Principle of Derived class (Square) breaking the parent class (Rectangle) functionality of calculating the area.

We can solve this problem breaking the inheritance

The solution seems similar to Open Close Principle, so based on above example we can conclude that violating Liskov’s Principle violates Open Close Principle as well.

The Interface Segregation Principle

Make fine grained interface that are client specific

This principle solves FAT interface problems of Object Oriented Programming

A interface is called FAT when it has to many methods which contains more information than we really want.

Lets understand Fat Interface in Protocols with an example, we have a GestureProtocol with the method didTap: which a View would be using it to handle the Gesture

After sometime as usual the requirement came to handle more gesture like didDoubleTap: and didLongPress: so our GestureProtocol becomes

Again as usual not all the Views in our app requires all the gestures some View would require only didTap: gesture in that case our UserDetailView class which would need only didTap: gesture would look like

We can solve the problem using little protocols instead of a big ones, the below code snippet shows segregation of Gesture protocols into small ones

Other way we can solve this problem in swift 3.0 is using @objc key before the protocol declarations and protocol methods, which in turn gives us a options to declare a protocol method as optional, who ever wants can implement, the below code snippet shows the same.

Now let’s dig into Fat Interface in Classes with an example, we have view in our app which displays the user profile photo, the two classes User and UserProfileImageView classes looks like shown below.

Observing closely the above snippet, the UserProfileImageView’s loadProfileFor(user:User) function requires only the profileImageURL details, but unfortunately we are injecting too many informations in it, we can solve this problem using UserProfileViewDetails protocol which just has the information required by UserProfileImageView’s loadProfileFor(user:User), the below code will explain you detail.

Now the UserProfileImageView’s loadProfileFor(user:UserProfileViewDetails) which is the client has only the profileImageURL information with it to display the User Profile Image, which agrees with the Interface Segregation Principle.

The Dependency Inversion Principle

High level modules should not depend on low level modules both should depend on Abstractions

Lets Consider the class ConversationDataContoller which we used in Single Responsibility Principle

here the CoreDataController is a low level module, its easy to reuse in other projects, the problem is with high level module ConversationDataController, its tightly coupled with CoreDataController.

Lets discuss this in detail, as I have mentioned earlier the ConversationDataController is used in the Messenger App to get the previous conversations json, parse it, and save to Core Data Database, so it can use the previous conversations to display it offline as well in the Messenger App, now new requirement from a client or product team came like can we use the same ConversationDataContoller from Messenger App into another App, with little change something like use File System Archiving instead of Core Data for saving the previous conversations.

In that case we cannot use the ConversationDataContoller into another app easily because it is tightly coupled with CoreDataController or in other words it has a dependecy in low level module CoreDataController.

We can solve this dependency using a Database Protocol. In this way ConversationDataController can use abstract protocol without caring for type of database used, lets see how the ConversationDataController will look after applying this.

Now you can reuse the ConversationDataController without any hazzle or hectic into another App which uses File Sytem Archiving for database, just by including the FileSystemArchiving class as shown below.

Quick Summary

• Each an every class should have only one responsibility
• Should not modify the existing class for change requirement, rather extent the class
• Extending or Inheriting a child/derived class should not break any parent or base class functionality
• The Interface or class API’s to client should have minimum information required by the client
• Class A should not depend on Class B or vice versa, both should be losely coupled

Use SOLID principles as your weapon in the war of coding :)

Reference :

• https://www.codeproject.com/Articles/703634/SOLID-architecture-principles-using-simple-Csharp
• https://realm.io/news/donn-felker-solid-part-4/
• https://marcosantadev.com/solid-principles-applied-swift/

https://github.com/Vinodh-G/UIImageView-AsyncLoad