Usually, any component we want to unit test has one or more dependencies. To test an expected behavior, we need to fake some input somehow. Assume we need to store a user preference in some persistence store. For now, assume it will be User Defaults. We will use abstraction so the high-level business logic and low-level details do not depend on each other. Instead, they both depend on abstraction. Here, the logic to store the user preference is high-level logic. And the actual storing of User details is the low-level details.

The basics of dependency Inversion

We just mentioned both the higher-level logic and the low-level details should depend on abstraction. We have some details in our Introduction of Dependency Inversion on Swift talk. Also, in our Swift Dependency Inversion through Protocol talk, we share how to achieve Dependency Inversion in Swift. Finally, in the Dependency Injection in Swift talk, we demonstrated the details of dependency Injection. Feel free to visit those for a crystal idea of dependency inversion and injection.

Persistence store case study

We will use the persistence store storage as our case study for this blog post. Our goal is to store some user preferences in some persistence stores like User Defaults. Now, we will do TDD here. And by doing that, we will clarify the Test Doubles in Swift.

We will have three different user preferences. We will be storing those values in User Defaults.

public enum Preference {
    case notNow
    case never
    case save(Credential)
}

Credential is a simple struct with username and password.

public struct Credential {
    public let username: String
    public let password: String
}

Let us start TDD for this case study and explore the Swift test Doubles like Spy, Stub, Dummy, Fake, and Mock.

Implementation through abstraction

Here is the abstraction, protocol, to separate the high-level business login from the low-level details.

protocol PreferenceStorable{
    func save(_ data: Data, for key: String) -> Error?
}

We will have a controller who will be making the business decisions. We can call it StorageController. StorageController will have one instance of type PreferenceStorable. Through this instance, the controller will save the preference. The User Defaults will confirm PreferenceStorable and implement the low-level details (save requirement).

Swift Test Doubles Code Implementation

On the TestDoubles GitHub repo, we have closed Pull requests demonstrating the usage of each test double. We can go through the pull request and select the next or previous button to see the evaluation of the code in TDD.

Spy

The very first thing we want to test is the initialization of the StorageController does not initiate the saving. Then, we will confirm the save of StorageController actually storing the preference. These two scenarios tell us we need to verify the saved value. That sounds like a Spy.

The concept of Spy is straightforward. Spy will only store values, nothing else. We will use this stored value of the Spy to validate the assumption through assertion. Here is an implementation of Spy. Note that return is a method-only requirement. The nil return does not have any relation with the Spy, SpyPreferenceStorage.

class SpyPreferenceStorage: PreferenceStorable {
    private(set) var preferences = [String: Data]()

    func save(_ data: Data, for key: String) -> Error? {
        preferences[key] = data
        return nil
    }
}

So, the required tests will be as follows.

class TestDoublesTests: XCTestCase {
    func test_init_doesnotStorePreference() {
        let (_, spy) = makeSUT()

        XCTAssertTrue(spy.preferences.isEmpty)
    }

    func test_savePreference_storesPref() {
        let (sut, spy) = makeSUT()
        XCTAssertTrue(spy.preferences.isEmpty)

        sut.save(preference: .never)

        XCTAssertFalse(spy.preferences.isEmpty)
    }

    // MARK: - Helper
    private func makeSUT() -> (sut: StorageController, spy: SpyPreferenceStorage) {
        let spy = SpyPreferenceStorage()
        let sut = StorageController(presistenceStore: spy)
        return (sut, spy)
    }
}

The resulting code for the SpyPreferenceStorage will be the following.

struct StorageController {
    let presistenceStore: PreferenceStorable

    func save(preference: Preference){
        let encoder = JSONEncoder()
        guard let data = try? encoder.encode(preference) else { return }
        _ = presistenceStore.save(data, for: Self.PreferenceStoreKey)
    }
}

extension StorageController{
    static var PreferenceStoreKey: String {"PreferenceStoreKey"}
}

Stub

Now, once can confirm the value is stored now let us turn our attention to error handling. The StorageController should be able to handle errors properly. If there is no error then the StorageController should not propagate any error. And if an error occurs the StorageController should propagate that exact error to the caller. So it seems like we need to mimic the erroneous state of the system to validate the error-handling behavior of the StorageController. This is the job for Stub.

Stub returns a predefined response. When we need one component to return some specific value we use a stub. Here is an example of Stub.

struct StubPreferenceStorage: PreferenceStorable {
    let error: Error?

    func save(_ data: Data, for key: String) -> Error? { error }
}

On our StubPreferenceStorage stub we will set the error on init time. If we want some specific error then we will set that error on the init time. Otherwise, we can set the error to nil on init time to reflect a no error state of the system. Let us have a look at the test_save_throwsError_onErroneousStoring test which simulates an erroneous state. On the other hand, the test_save_throwsNoError_onSuccessfulStoring simulates no error state.

final class ResponseAfterStoringTests: XCTestCase {
    func test_save_throwsError_onErroneousStoring() {
        let expectedError = NSError(domain: "any error", code: -100)
        let (sut, _) = makeSUT(expectedError)

        do {
            try sut.save(preference: .never)
            XCTFail("Expected error but got none")
        } catch {
            XCTAssertEqual(error as NSError, expectedError)
        }
    }

    func test_save_throwsNoError_onSuccessfulStoring() {
        let noError: Error? = nil
        let (sut, _) = makeSUT(with: noError)

        do {
            try sut.save(preference: .never)
        } catch {
            XCTFail("Expected no error but got an \(error)")
        }
    }

    // MARK: - Helper
    private func makeSUT(_ error: Error?) -> (sut: StorageController, stub: StubPreferenceStorage){
        let stub = StubPreferenceStorage(error: error)
        let sut = StorageController(presistenceStore: stub)
        return (sut, stub)
    }
}

Here we are setting the StubPreferenceStorage with an NSError. This error will be returned on the save(_ data: Data, for key: String) call. Now let us update our production code StorageController to return any error if occurs.

public struct StorageController {
    private let presistenceStore: PreferenceStorable
    
    public init(presistenceStore: PreferenceStorable) {
        self.presistenceStore = presistenceStore
    }

    public func save(preference: Preference) throws{
        let encoder = JSONEncoder()
        guard let data = try? encoder.encode(preference) else { return }

        if let error = presistenceStore.save(data, for: Self.PreferenceStoreKey) {
            throw error
        }
    }
}

extension StorageController{
    public static var PreferenceStoreKey: String {"PreferenceStoreKey"}
}

As you can see once we have an error in presistenceStore.save we are throwing that error. So using stub we can define the presistenceStore erroneous state which helps us to confirm the production code error handling behavior.

Dummy

Till now we were only concerned with the presistenceStore: PreferenceStorable. But there is still another hidden dependency on the StorageController. The JSONEncoder that we are initiating on save method. If some error occurs during the encoding time we have no way to return that error to the caller. So let us move our focus on that part of the code.

If we want to stub any error during the encoding process we need to inject this dependency, JSONEncoder. So let us take an encoder on the init method. As a result, the StorageController will look like the following.

public struct StorageController {
    private let presistenceStore: PreferenceStorable
    private let encoder: JSONEncoder

    public init(presistenceStore: PreferenceStorable, encoder: JSONEncoder) {
        self.presistenceStore = presistenceStore
        self.encoder = encoder
    }

    public func save(preference: Preference) throws{
        let data: Data
        do{
            data = try encoder.encode(preference)
        }catch{
            throw error
        }

        if let error = presistenceStore.save(data, for: Self.PreferenceStoreKey) {
            throw error
        }
    }
}

Now returning the error state during the encoding process of the JSONEncoder is a stub job. But what role the presistenceStore now will take? The response of save now does not matter. This sounds like a Dummy.

The Dummy is a filler. Dummy always returns a response, that does not have any impact on that specific test scenario. So here is a dummy look at the PreferenceStorable.

class DummyPreferenceStorage: PreferenceStorable {
    func save(_ data: Data, for key: String) -> Error? { nil }
}

On the save method of the DummyPreferenceStorage, we are not concerned about the return param. We just need a PreferenceStorable to initiate the StorageController like following.

let sut = StorageController(presistenceStore: DummyPreferenceStorage(), 
                                    encoder: StubFailableJsonEncoder(error: anyEncodingError))

The implementation of Dummy is visible on the corresponding pull request.

Fake

Among all test doubles, the Fake is different from its kind. Fake has its brain. So, a Fake will return results based on the business logic in it.

One usage can be the dictionary-based implementation of the PreferenceStorable rather than the actual UserDefaults. So UserDefaults has two methods to set and retrieve the data. func set(_ value: Any?, forKey defaultName: String) and func value(forKey key: String) -> Any?. Let us invert the dependency. Rather than depending on UserDefaults let us make our system depend on abstraction, protocol.

protocol UserDefaultsStorage {
    func set(_ value: Any?, forKey defaultName: String)
    func value(forKey key: String) -> Any?
}

The UserDefaultsStorage encapsulate the methods that are required for setting and retrieving the value. So the UserDefaults confirmation will be like the following.

extension UserDefaults: UserDefaultsStorage{}

And now, this should be enough to get going. But if we program against the abstraction, then we will use the UserDefaultsStorage instead of UserDefaults. That way, we can use another test double which can store the value in a dictionary rather than directly saving it to UserDefaults.

class FakeStorage: UserDefaultsStorage{
    var dictionary = [String: Any]()
    
    func set(_ value: Any?, forKey defaultName: String) {
        dictionary[defaultName] = value
    }
    
    func value(forKey key: String) -> Any? {
        dictionary[key]
    }
}

In the above code set and value methods use a dictionary to store and return the value. This is pure business logic to store the value in a non-persistence store rather than a persistence store, ie UserDefaults. So this is a Fake test double as it is using its business logic to store and deliver the stored result from within a Dictionary.

Mock

Mock always looks like Spy. But there is a distinct difference between Spy and Mock. On Spy, we just capture the values. The assertion happens in the corresponding test. On the other hand, in a mock, we do the verification in the mock itself.

In the mock, we expose verifications so that the test can assert the expected behavior. Following is an example of Mock.

class MockPUTAPI: PUTAPI{
    private var isCalled = false
    private var completion: ((Result)-> Void)?
    
    func put(preference: Preference, completion: @escaping (Result)-> Void) {
        isCalled = true
        self.completion = completion
    }
    
    var verifyCall: Bool{
        isCalled == true
    }
    
    var verifyCompletionSetup: Bool{
        completion != nil
    }
}

The verifyCall and verifyCompletionSetup does not explicitly expose the underlying value, but rather just confirms if they are set to an expected value. So now the corresponding tests will just assert these verifications.

func test_init_doesNotInitiateRemoteCall() {
        let (_, mockAPI) = makeSUT()
        
        XCTAssertFalse(mockAPI.verifyCall)
        XCTAssertFalse(mockAPI.verifyCompletionSetup)
    }
    
func test_put_initiateRemoteCall() {
        let (sut, mockAPI) = makeSUT()
        
        sut.executePUTRequest(for: URL(string: "any-url")!, with: .never){_ in}
        
        XCTAssertTrue(mockAPI.verifyCall)
        XCTAssertTrue(mockAPI.verifyCompletionSetup)
    }

All the not-shown entities can be found on GitHub.

Conclusion

Swift Test Doubles such as Spy, Stub, Fake, and Mock gives us the ability to make our test deterministic. But knowing them is not just enough. We also need to know what difference they pose compared to one another. Also when to use which one? All these questions can not be answered in a single blog post. So we will be resuming our test doubles talks in the next talk. Till then take care.

The post Swift Test Doubles Spy Stub Dummy Fake Mock appeared first on mobidevtalk.

To move further, we also need to go through the different types of Distribution schemas like Development distribution, App Store distribution, and Ad Hoc distribution. After that, we will map those distributions with the regular distribution concepts like Alpha and Beta distribution.

Purchase of the subscription

This is the phase when we want to distribute our developed app to the customer. The iOS app distribution is not free. To distribute an iOS app, it is necessary to purchase an Apple developer program subscription, which costs $99 yearly. On the Apple developer program, we can find more details. There will be some email confirmation after the subscription purchase.

Mapping App Store, App Store Connect, and Developer portal

Usually, we distribute our app through the App Store. But to get that app to the App Store, we need to have an entry of that app on the App Store Connect. And to get to the App Store Connect, we need to create some entitlement on the Apple developer portal. That means we will create app identifiers, certificates, device lists, and provisioning profiles on the Apple developer portal. Once we have the provisioning profile, we can upload the app binary to the App Store Connect. After that, we need to submit our app for review. And once it gets reviewed, we can distribute the app to the users.

Let us now move to a more granular level.

How Alpha and Beta distribution are mapped in iOS app distribution

First, let us talk a bit more about different types of iOS app distribution. We can say there are mainly two types of distribution based on build variance. One is Development distribution, and the other is Production distribution.

In the case of Development distribution, we need to run our undergoing development app on some devices that we can/will not plug into our Mac. An example can be the verification of a hotfix. The hotfix can not be merged into the production code without the tester’s approval. In this situation, Development distribution helps a lot.

Another one is Production distribution. Production distribution can be of three types. They are App Store Distribution, Ad Hoc Distribution, and Enterprise Distribution. App Store Distribution is the standard distribution of our iOS app to the general people through the App Store. We distribute the iOS app to a limited number of customers on Ad Hoc distribution. Finally, on the Enterprise Distribution, we distribute the iOS app to the employees of an organization.

We often use the terms Alpha and Beta versions of an iOS app. Let us see how they map with the above distribution types.

In general, Alpha testing is done by the development team. It is very common to ad testers or QA guys in the Alpha testing. Alpha testing is regarded as the very first level of testing of an iOS app. As a result, the Development distribution of an iOS app is the Alpha distribution for that iOS app. We might use the dev environment APIs here on the Alpha/Development distribution.

On the other hand, Beta testing is done by some specific groups, not conducted by the Development team. Multiple small groups are invited to the Beta iOS app testing. The diverse groups give the development team a wide range of perspectives. One important thing is that the Beta iOS app is very close to the actual release. As a result, production APIs are used here. Thus, the Beta distribution is the Ad Hoc distribution of an iOS app.

Let us have an overview of different types of distribution in a single image.

Code to Apple developer portal

In this flow, most of our app distribution process will be addressed. Here are the concepts for this flow.

• Identifiers
• Devices
• Certificates
• Profiles

Identifiers, App ID

There are various types of IDs available on the Apple dev portal. But we will only concentrate on App IDs. This App ID will uniquely identify the app. App ID is required to avail of different Apple services. Another important thing is that the Provisioning Profile, which we will discuss shortly, will use this App ID to identify the app.

The standard format of App ID uses a reverse domain name notion. An example can be com.mobidevtalk.blog where blog the app name mobidevtalk is the company/organization name com is the domain type of that organization.

The certificates, provisioning profiles, and the app’s bundle identifier all use App ID. So please think before picking a name for our app. 🤔

There is sometimes a tendency to use a wildcard app ID. This has a name format like com.mobidevtalk.*. The only use case of this wildcard app ID is to support multiple apps sharing the same bundle seed ID. However, using the wildcard app ID has huge limitations. Wildcard ID can not used in the Apple Push Notification, Purchase, etc. We can use the wildcard for temporal cases. But for permanent cases, we need to use the proper app ID.

Device(s)

Apple only allows registered devices to run the beta version of an app. If we want to run our debug app, directly build and run the app from our Mac, we need to register the device. For ad hoc distribution, registration is also required. We can not run our app on devices without registering them in the Apple dev portal. Thats it!

The Xcode will automatically register the device for development if we allow the automatic signing of our app in the Xcode and then connect a device with our Mac. But we will need to register devices over the air. Moreover, we will not always use automatic signing.

How can we register devices, iPhones, iPads, Macs, etc.? There are three ways such as automatic, half-manual, and full-manual.

The automatic way works only on the Apple platform. That means using TestFlight from Apple for the OTA(Over-the-air) distribution. Here is the workflow.

• Push the app builds to the App Store Connect
• Invite the people, either adding them as internal or external tester on the App Store Connect
• The invitee needs to open the invitation link, sent to his email, on the iPhone/iPad/Mac
• A new App will be downloaded called TestFlight from the App Store
• From Now on the invitee can download the app directly through TestFlight, even the old versions

Interestingly, TestFlight way to the distribution does not decrease the total number of devices in the Apple Dev Portal. We will continue this talk in future talks regarding the Xcode Cloud part of our CI/CD blog post.

Now, let us talk about the half-manual way of adding the devices. This is true for most Beta App Testing Platforms like Firebase, TestFairy, HockeyApp, and App Center. All of them except Firebase will provide a Device Management feature to collect the UUIDs of the testers. On the other hand, Firebase will provide a dynamic link to the tester. All of those platforms ultimately let the tester download their app from where the UUID of the tester’s device will be collected and sent to the corresponding Beta App Testing platform. After that, the developer will collect those UUIDs from there. Then, the developer will add those UUIDs to the Apple Developer portal.

On Manual device registration, we need to ask the tester to send the UUID of his iPhone/iPad. And then add it to the Device section of the Apple developer portal by the developer.

Remember, you can add a limited number of devices.

Keep in mind that people in your organization will come and leave. If you are registering an organization-owned device, please ensure the appropriate name for it. Perhaps add a suffix before the device name. So, anyone can understand those names and remove that device entry if required. Once an employee leaves the organization, you must remove his iDevice entry from the Device and Profile section of the Apple developer portal. Thus, he will lose access to the builds using the latest provisioning profile.

Certificates

Certificates are the most important and most confusing part of iOS app distribution. These Certificates digitally sign the iOS apps.

Now, why digitally sign our iOS app? Because Apple wants to make sure every time an app is run on an iPhone/iPad/Mac, that app is digitally signed by a known authority. So, how does Apple know that authority? The developer creates a CSR(Certificate Signing Request) file on his Mac. He uses his keychain. He will provide the email with other information. Then, the developer uploads the CSR file to the Apple Developer. He has to have access to the Apple Developer portal. That’s how Apple knows the authority.

The following diagram shows the general process of Certificate creation.

Types of Certificates

Based on the distribution type we will have two different types of certificates. One is a Development Certificates, and another is a Distribution Certificates. Development certificates are used to run the iOS app on the developer’s iPhone/iPad/Mac. On the other hand, Distribution certificates are used to run the app on the customer’s iPhone/iPad/Mac. The customer can be internal or external.

Both types of certificates are created the same way.

Development Certificates

Ideally, one developer should create his Development certificate. How can he share his Development certificate on his other Mac? He needs to export that Development certificate from the existing Mac and then import it into the other Mac. What if we use this process to share a Development certificate among teammates? Then, this is a very wrong process. Again, ideally, each developer should create his development certificate. On a team, they should have access to the Company/Organization’s Apple Developer Program as individual developers.

Distribution Certificates

Distribution certificates are used to distribute the iOS app to the customers. Ideally, all the production-type distributions, such as Ad Hoc and App Store distributions, use identical distribution certificates. Unlike the Development Certificate, one team member manages the Distribution Certificate. Yes, he is a bottleneck. But that’s how Apple designs the Distribution Certificates. Fastlane, an automation tool, has an elegant way of resolving this issue. We will see this in detail in some future blog posts.

Here is an insight into different types of certificates.

Provisioning Profile

The Provisioning Profile is a container. I like to think of the Provisioning Profile as a container or a bag. So in this bag, Provisioning Profile, two things/concepts are at least kept. What are those two things? Well, Certificates, list of authorized devices (iPhone/iPad) list. Both the Development and Ad Hoc Provisioning Profiles contain these two. But on an App Store provisioning profile, there is no device list. Most of the time, the Provisioning Profile also carries an app identifier.

Combining all together

Let us combine all the basic concepts(Certificates, Identifiers, Devices, and Profiles) in a single place. The takeaway here is the Developer provisioning profile will contain a Developer Certificate. Similarly, an Ad Hoc provisioning profile will hold its Ad Hoc certificate. Finally, the App Store profile will carry its App Store certificate. Only the App Store provisioning profile will not contain any device list, as this one is used to upload the build for the App Store.

Conclusion

Knowing the basic concepts like Certificates, Identifiers, Devices, and Profiles will give us the confidence to use those properly. Not understanding how these concepts are glued together creates confusion and frustration. A simple go-through will reduce the frustration always. So please revisit this blog before these basic concepts get dusted. See you in the next blog. ✌️ ✋

The post Certificates Identifiers Devices Profiles in iOS app distribution appeared first on mobidevtalk.

We have some talks over Protocol on our Swift Protocol Hub page. Where we evaluate the protocol usage on Swift. And on the last blog post, we talk about Swift Generic & Protocol where we talk about both Protocol and Generic. For any kind of confusion and deeper knowledge, we should visit those blog posts.

Background

• What is associatedtype
• Why & how confirming a protocol with associatedType turns into typealias?
• Why associatedtype rather than generic type
• When to choose the generic and when to choose the associated type on Protocol

associatedtype

associatedtype is an associated type on a Protocol. Associated means connected to. So when a type needs to be connected with a Generic protocol we use the associatedtype. Basically associatedtype is a placeholder type for a protocol. This placeholder type will be replaced by the concrete type at the time of implementing the protocol. Let us go through an example.

protocol Energy{
    associatedtype EnergyBar
    
    func consume(unit: EnergyBar)
    func loss()
}

On the above the EnergyBar is the associatedtype. This EnergyBar is used on the consume method as a parameter. As we want to make our Energy protocol as a generic one we have to make the type generic. That’s why we are using the associatedtype on this protocol. Now let us have an example of replacing that associatedtype or EnergyBar with a concrete type.

To have the concrete implementation of associatedtype we will take two entirely different characters. Popeye and Superman. We already know it is the Spinach that boosts Popeye with energy. So Spinach is the EnergyBar for Popeye. On the other hand, Superman doesn’t get that much of a bug out on the case of losing energy, but when he does he has to make sure there is a radiation source like Sun around him. So the SunRay is the EnergyBar for SuperMan.

Let us start the implementation. So the EnergyConsumption will have two ways; eating and radiation.

enum EnergyConsumption{
    case eat
    case radiation
}

Let define Spinach.

struct Spinach{
    let consumptionType = EnergyConsumption.eat
    
    let iron = 2.71
    let magnesium = 79
    let calcium = 99
}

extension Spinach: CustomStringConvertible{
    var description: String{
        return "\(iron) mg, \(magnesium) mg, \(calcium) mg"
    }
}

And we have a description of Spinach by confirming the CustomStringConvertible.

Now let us define SunRay. SunRay will have a different wavelength of light/radiation.

struct Wavelengths{
    let name: String
    let start: Float
    let end: Float
}

extension Wavelengths: CustomStringConvertible{
    var description: String{
        return "\(name): \(start)-\(end)"
    }
}

struct SunRay{
    let consumptionType = EnergyConsumption.radiation
    
    let visibleWavelengths = Wavelengths(name: "visibleLight", start: 0.4, end: 0.8)
    let ultravioletWavelengths = Wavelengths(name: "ultravioletLight", start: 0.2, end: 0.3)
    let infraredWavelengths = Wavelengths(name: "infraredRadiation", start: 0.9, end: 1.0)
}

extension SunRay: CustomStringConvertible{
    var description: String{
        return "wavelengths[micrometre]\n\(visibleWavelengths.description)\n\(ultravioletWavelengths.description)\n\(infraredWavelengths.description)"
    }
}

Again we are conforming the CustomStringConvertible to have a description.

Why & how confirming a protocol with associatedType turns into typealias?

Now it is time to conforming our Energy protocol on the Popeye and SuperMan struct.

struct Popeye: Energy{
    typealias EnergyBar = Spinach

    func consume(unit: Spinach) {
        "Energy is increased by \(unit.description)"
    }
    
    func loss() {
        "Energy lost"
    }
}

But why is typealias EnergyBar = Spinach rather than associatedtype EnergyBar = Spinach? What is the play between typealias & associatedtype? Let us talk about this in short.

So at the time of defining the generic protocol Energy, we have to inform the compiler about the type of unit parameter on the func consume(unit) method. Otherwise, the compiler will give us a compile-time error. Now we can not fix the type of that parameter to a concrete type yet. As we do not know what will be the type of that parameter unless the protocol is confirmed. So we say that EnergyBar is an associate type for the protocol Energy.

But things get a different perspective when we want to confirm the protocol. Now we need to say to the compiler that this time we are using the Spinach in place for Energy. So the Spinach will be the Energy. In other words, we are renaming the Energy to Spinach. And that action of renaming the type is done by typealias on Swift.

Protocol is the boundary/fence of a garden in the real world where the gardener will operate. The protocol sets the boundary of the operating area. And the associatedtype is the tools he will use at the time of gardening. One day the gardener can have a shovel. Another day he can have a fork. Whatever he uses, the shovel or the fork, it is another name of the tools.

Back to our original example. Swift is a modern language. It can infer the type. We can exclude the typealias keyword once we have enough context for the type. Now the following example we are excluding the typealias EnergyBar = SunRay.

struct SuperMan: Energy{
    func consume(unit: SunRay) {
        unit.description
    }
    
    func loss() {
        "SuperMan in now a human"
    }
}

Why associatedtype rather than generic type

This is an interesting question. Why we will use the associatedtype when we can use the generic type for a method even on a Protocol. Or more importantly when to use generic and when to use associatedtype on the protocol. To begin the discussion let us have an example of a couple of generic type-based methods on a protocol.

protocol EnergyOperator{
    func boostEnergy< T >(unit: T)
    func decreaseEnergy< T >(unit: T)
}

Here we are defining the EnergyOperator protocol, which has two generic methods under it. The boostEnergy and the decreaseEnergy both take generic type, T, as their param. The protocol confirming entity needs to define the solid types for those generic params. Let Popeye confirms the EnergyOperator.

extension Popeye: EnergyOperator{
    func boostEnergy(unit: SpinachUnit) {
        "Energy is now boosted by 1 Can full of Spinach it has \(unit) on per-unit"
    }
    
    func decreaseEnergy(unit: EnergyLoosingUnit) {
        "Popeye's energy is decreased by \(unit)"
    }
}

popeye.boostEnergy(unit: Spinach())
popeye.decreaseEnergy(unit: "Fighting")

popeye.boostEnergy(unit: Spinach())

Now here is the interesting part. For the boostEnergy and the decreaseEnergy methods they required two different data types. boostEnergy is using the Spinach datatype and decreaseEnergy is using the String datatype. But if we would have used associatedtype then they both should be having the same data type.

When to choose the generic type and when to choose the associated type on Protocol

Here is the most important question of this blog post. When we will choose the generic type and when to choose the associated type once we decide our protocol should be generic. Well, the very basic rule applies here. According to the need obviously. What the requirements need. We just need to notice the following to make the right decision for a generic protocol.

• We need to use associatedtype when all the methods under a generic protocol need to use the same datatype.
• The generic will be used when the methods under a protocol are required different data type for them individually.

Simple, right? Hmm. Now let us move to another discussion. What if we need to use the where clause on Protocol and even when we need to use those types of clauses? Also, what does the Self with capital S means when it comes to Protocol. Well, they need another blog post. This one is already a big one. So see you in the next blog post.

End talk

The definition of associate stands for a connection. Which draws the same meaning here in Swift also. We saw the association of a value with the case on enum which is called associated-values. And here on this blog post, we see the association of type with a protocol called associatedtype. Understanding the core meaning helps a lot to clarify the concept behind it. Hope we all got the message. See you in the next blog post. Till then take care.

Reference

• Code for this blog post @GitHub
• Swift Protocol Hub
• Swift Generic & Protocol
• Documentation of Swift
• Generics in Swift
• Swift Generic Manifesto
• Generic in Swift
• GENERIC PROTOCOLS & THEIR SHORTCOMINGS
• Swift Associated Type Design Patterns

The post associatedtype on Protocol, making Protocol Generic appeared first on mobidevtalk.

Here on this blog post, Swift Generic & Protocol, we will start with Generic Stack & Generic Queue. Then we will advance to a generic protocol-based solution for those Stack & Queue.

Background

• Generic Stack
• Generic Queue
• Protocol with Generic
• Out of bound crash
• Generic Stack with Generic protocol
• Generic Queue with Generic protocol
• Summary

The protocol is amazing stuff on Swift world. Here we can always have a visit to our protocol hub page where all the talks related to the protocol are listed. And on our last talk, we have some very basic about generic. Now it is time to mix them up.

Stack and Queue are two of the most common linear data structures. For this blog post, we will use the Stack and Queue to have some data operations. And obviously, we will use the Generic approach for a better solution. For more info on Stack and Queue.

We can move directly to the Out of bound crash section if we already have the basic idea about Stack and Queue.

Generic Stack

Let us have a generic Stack, generic in a scene that we will be able to use this stack for different types.

A quick note about the stack. Data operation on Stack is done through LIFO. Insertion is called push and deletion is called pop.

struct DS_Stack< Element >{
    private var items = [Element]()
    
    mutating func push(item: Element){
        items.append(item)
    }
    
    mutating func pop() -> Element{
        return items.removeLast()
    }
}

Here we use the Element keyword rather than the more common T for a generic type. Because Element has a better match for our current use case. Here is the basic talk over the generic syntax, if we need it.

Let us have Int and String Stack example.

var intStack = DS_Stack()
intStack.push(item: 200)
intStack.push(item: 2)

intStack.pop()

var stringStack = DS_Stack()
stringStack.push(item: "mobidevtalk")
stringStack.push(item: ".com")

stringStack.pop()

We will see 2 and .com was popped from the intStack and stringStack receptively.

Generic Queue

Now it is time for a generic Queue. Queue follows the FIFO approach for data operation. Insertion is called enqueue and deletion is called dequeue.

struct DS_Queue< Element >{
    private var items = [Element]()
    
    mutating func enqueue(item: Element){
        items.append(item)
    }
    
    mutating func dequeue() -> Element{
        return items.removeFirst()
    }
}

Example with Int and String as follows:

var intQueue = DS_Queue()
intQueue.enqueue(item: 200)
intQueue.enqueue(item: 2)

intQueue.dequeue()

var stringQueue = DS_Queue()
stringQueue.enqueue(item: "mobidevtalk")
stringQueue.enqueue(item: ".com")

stringQueue.dequeue()

So this time we will see 200 and mobidevtalk being removed as Queue follows the FIFO approach.

On the Stack and Queue we are actually mutating the struct because of the requirements of the current time. More on mutating the value type.

Out of bound crash

What if for both Stack and Queue we want to remove more elements than they have. So trying to removing the third element of a two-element Stack or Queue will generate a crash. Why? Because there is no element on that index. Let us fix that. We want to tell our users that they are trying to remove data from an empty data structure. Let us define the Error.

enum OperatingError: Error{
    case outOfBound
    case empty
}

If we are wondering why to use an enum for Error definition we can always visit the Error handling blog for some more details.

We will also have a description for the OperatingError. By confirming CustomStringConvertible we can have that.

extension OperatingError: CustomStringConvertible{
    var description: String{
        switch self {
        case .outOfBound:
            return "Oops! There is nothing to remove"
        case .empty:
            return "Empty Stack"
        }
    }
}

The CustomStringConvertible the protocol provides a customization point for describing. More on CustomStringConvertible.

Protocol with Generic

We have a basic understanding of Stack and Queue from the above sections. Now we should move to a more advanced data operating procedure. So the target is to generalize the data operation. And for that, we gonna use Protocol. But How?

By defining a DataOperator the protocol we will centralize the operations like inserting, deleting. Moreover, we will also add some status checks. Like the total count of elements. Also, we can add some description of the specific data structure.

protocol DataOperator: CustomStringConvertible{
    associatedtype Component
    
    mutating func insert(item: Component)
    mutating func remove() throws -> Component
    func numberOfComponent() throws -> Int
}

The CustomStringConvertible has a property called description. We want our DataOperator confirming types to provide a description of their Data structure.

Now let us talk about the associatedtype keyword. On Internet the associatedtype is a confusing word to understand when it comes to protocol and generic. We already talked about the associatedtype in Protocol, reach out to that post for more details. But for now, we will have the very basics of associatedtype.

associatedtype is a placeholder for type. What type? Any type. It cloud be Int String or some custom type. The practice of using the associatedtype is to define a placeholder type which will be replaced later on by some Concrete type on build time.

To make any protocol generic we need to make the operating type on that protocol generic. And that’s where associatedtype plays its role.

The insert and remove will mutate the underneath struct so the mutating keyword is used.

Generic Stack with Generic protocol

When we use the associatedtype with a protocol, that protocol becomes a more generic one. So Now let us use our generic protocol, DataOperator, in action. We gonna define Stack which will be generic itself and will also be able to use the generic protocol.

struct Stack< Element >: DataOperator{
    var description: String{
        "Stack is a linear Data structure. Follows the LIFO(Last In First Out) patterns. Only one tracker called Top."
    }
    
    private var items = [Element]()
    
    private mutating func push(item: Element){
        items.append(item)
    }
    
    private mutating func pop() -> Element{
        return items.removeLast()
    }
    
    typealias Component = Element
    
    mutating func insert(item: Element) {
        push(item: item)
    }
    
    mutating func remove() throws -> Element {
        if items.count == 0 {
            throw OperatingError.outOfBound
        }else{
            return pop()
        }
    }
    
    func numberOfComponent() throws -> Int {
        let count = items.count
        if count == 0 {
            throw OperatingError.empty
        }else{
            return count
        }
    }
}

We make the underneath data and its operation, items push pop, private. So those can not be accessed by others outside of the struct. At the same time, we are using the signature methods of DataOperator to make the data operation and status update.

On the typealias Component = Element we are defining the associated type as Element. So after this statement all the Component on the DataOperator in Stack will be replaced by Element. More interestingly when we will use the Int or String or any custom type of Stack the Element will be replaced by that concrete type.

Now we are throwing Error when the count is equal to zero both on remove and numberOfComponent. If we need some help on Error handling and its mechanism like the do try catch don’t tense. We have that cover on the Error Handling through try variance blog post.

Here comes the stack instance. This time we will use the Int based Stack. So the Element on the Stack and eventually the Component on the DataOperator will be replaced with the concrete type Int.

var stack = Stack< Int >()
stack.description

So we will have the stack description. Now it is time for the empty error state.

do {
    try stack.numberOfComponent()
} catch OperatingError.empty {
    OperatingError.empty.description
}

Empty Stack will be printed as we yet not inserted any of the elements. So let insert some.

stack.insert(item: 10)
stack.insert(item: 30)

Now, what about some removal. What if we want to remove more elements than the stack have.

for _ in 1..<4 {
    do {
        try stack.remove()
    } catch OperatingError.outOfBound {
        OperatingError.outOfBound.description
    }
}

Aha, we don't have the crash. We have the Oops! There is nothing to remove message been printed out. Savvy 🤓. Again if we need help on do try-catch.

Generic Queue with Generic protocol

So now it's time for some generic queue with the generic protocol. This will be nearly a copy on the stack other than the operation will be based on queue style.

struct Queue< Element >: DataOperator{
    var description: String{
        "Queue is a linear Data structure. Follows the FIFO(First In First Out) patterns. Uses two tracker. Font for insertion. Rear for deletion"
    }
    
    private var items = [Element]()
    
    private mutating func enqueue(item: Element){
        items.append(item)
    }
    
    private mutating func dequeue() -> Element{
        return items.removeFirst()
    }
    
    typealias Component = Element
    
    mutating func insert(item: Element) {
        enqueue(item: item)
    }
    
    mutating func remove() throws -> Element {
        if items.count == 0 {
            throw OperatingError.outOfBound
        }else{
            return dequeue()
        }
    }
    
    func numberOfComponent() throws -> Int {
        let count = items.count
        if count == 0 {
            throw OperatingError.empty
        }else{
            return count
        }
    }
}

Let us have a String queue and have the same operation as the stack.

var queue = Queue< String >()
queue.description

do {
    try queue.numberOfComponent()
} catch OperatingError.empty {
    OperatingError.empty.description
}

queue.insert(item: "mobidevtalk")
queue.insert(item: ".com")

for _ in 1..<4 {
    do {
        try queue.remove()
    } catch OperatingError.outOfBound {
        OperatingError.outOfBound.description
    }
}

Summary

Let us have a look at how the associatedtype got replaced by the more concrete type like Int. The following image is for Stack. The same will be for Queue.

The above picture tells the story of Swift's generic solution through the protocol. All the source code used on this blog post is available on GitHub.

End Talk

Here on this blog post, Swift Generic & Protocol talk, We make the protocol generic when we use associatedtype. By defining the associatedtype on a protocol we remove the dependency from any specific/fixed type from that protocol. The protocol becomes more generic to embrace any type.

But we can't say we cover all the Generic & Protocol combination-related talk. This one was the tip of the iceberg. A long way to go. So stay tuned. Take care.

Reference

• Source code
• Protocol Hub Page
• Swift Generic introduction
• Error Handling through try variance
• Adopting Common Protocols
• Protocol-oriented programming & generics
• Generic on Swift Doc

The post Swift Generic & Protocol appeared first on mobidevtalk.

As always we consider, you already have some reading on the protocol from the apple provided book or through any other medium. Because we will not cover the basic part of protocol on the blog posts. We are focusing on the protocol used on the real problems. Talking about the real problems, we will have some little to medium size use case-based problems to ease our learning of protocol. So let get started.

Background

• At a glance
• Inheritance, Initiator of coupling
• Composition, breaker of chains
• Protocol, Swift way of thinking
• Introduction of Dependency Inversion on Swift
• Swift Dependency Inversion through Protocol
• Dependency Injection in Swift

At a glance

Now on Swift Protocol Hub we will be introduced with the following talks.

Let have some small review on each of the posts.

Inheritance, Initiator of coupling

One the first part of our protocol journey, Inheritance, Initiator of coupling, we talk about how we initiate the inheritance on the code base for removing the code duplicity. We also talked about the benefit of inheritance we can have. But moreover how this simple benefit can lead us to a very tightly coupled code, which slows us down to adapt to the ever-changing requirements.

Composition, breaker of chains

In the second talk, Composition, breaker of chains, we move our focus to composition. Which enables us to adopt the requirements changes far more quickly and easily than the typical inheritance. We build a Justice league(theoretically of course 😉) and resolve the issues we had with inheritance way. We talk about multiple inheritances and finish that talk with the pros and cons of composition.

Protocol, Swift way of thinking

This talk, Protocol, Swift way of thinking, can be the center of protocol-based talking on mobidevtalk. Because here we talk about the core concepts of protocol usage. So things like why we need to use protocol and why it is the best choice on Swift are discussed here. This time we bring the Avengers(again theoretically 🤓) to provide us the protocol-oriented programming concepts. Basically, this blog post is the very first step of protocol first thinking patterns on this blog site.

Introduction of Dependency Inversion on Swift

From this talk, Introduction of Dependency Inversion on Swift, we start to shift our focus more on the problem that protocol resolves. In that direction, the very first concept is dependency inversion. Here we talk about what is actually dependency inversion. Through the diagram of code example, we had an in-depth discussion over dependency inversion. Basically, this blog post is the go first when we need to know, how the protocol functions on Swift to have a swift way of coding.

Swift Dependency Inversion through Protocol

This talk, Swift Dependency Inversion through Protocol, is the star of the day. Because this part is the practical implementation of dependency inversion on Swift through the protocol. This blog post not only talks about the how-when of the protocol used for gaining dependency inversion but also the best possible way for achieving that.

Dependency Injection in Swift

Face it, Dependency injection is an alien for us. A very simple concept surrounded by some very unknown myths. But Dependency Injection need not be like that. Surely you will believe the same way after you read Dependency Injection in Swift. In this blog post, we first remove those myths and express the simple picture of dependency injection. Then gradually we start to implement the same concept on our swift code base. We discussed how the protocol can come in handy on dependency injection. We talked about the benefits and drawbacks of dependency inversion. In the end, we finish the talk with some tricks and tips to achieve dependency inversion on Swift.

associatedtype in Protocol

associatedtype is not always been very clear to us all. But in reality, associatedtype is not a very big deal. We just need four mins reading. That is it. Once we have a clear concept of the associatedtype we can move further to understand a lot more complex errors, which usually occurs when dealing with the generic protocol. So this blog post is an introductory one for a bigger concept, Generic Protocol.

End Talk

Whether it is inheritance or composition, there is no single way to go. Programming is all about choosing the balance. The right amount of balance is the sweet spot. But to find that sweet spot we need to have the necessary knowledge on each end. The knowledge about the pros and cons for each end will ease a lot for finding the proper balance. Swift Protocol Hub discusses the highlights of the post that gonna make us a bit more knowledgeable on the protocol domain and its related concepts. Hope you enjoy it. Take care.

Reference

• Swift Book from Apple

The post Swift Protocol Hub appeared first on mobidevtalk.

As Apple already had some awesome details on Generic and its related concepts on different section on Apple doc on Generic. So going through those will definitely be a redundant talk.

However on this blog post we will touch the basic concepts of generic on Swift as an introduction talk through a very basic case study implementation. This time our case study will be Palindrome. Let us get started.

For a bit more advance level we can check out our Swift Generic & Protocol blog post.

Background

Our target is to build a simple playground project which can verify if an input is a Palindrome or not. On this case study we will add one by one requirement to make our solution generic. This should be the regular practice on implementing generic solution. On the evolution of the case study we will talk or share the reference of generic concepts if any needed.

• What is Palindrome
• The Test Observer snippet
• Detecting a String Palindrome
• TDD approach
• Continuing with string palindrome
• How about a Palindrome of Int
• Can we have Double Palindrome
• Converting into a more Generic solution for detecting Palindrome
• Summarizing the generic evolution for the problem
• Best practice for implementing generic solution

On the playground project we will use the TDD approach to verify our tinny solution. We need not to fear on that, because it will be pretty simple and understandable. Big thanks to Sundell for his awesome snippets for Test on Playground. We will write a TestObserver to run our test on playground. Details code are available on GitHub.

And if we need some memory recall about snippets, then surely we can have a look on our snippets talk. Thats a small talk containing all the necessary things related with Snippets on Xcode. Video is also included to ease the different steps.

What is Palindrome

It is an interesting concept. But rather a simple one. Palindrome sequence is same on both forward and backward reading. We often say wow. This wow is a simple palindrome. As it is same on forward and backward read. Other examples are noon, madam, refer, mom etc. Guessing we can find a lot through simple google search on Palindrome, so moving on the case study implementation now.

The Test Observer snippet

To continuing our playground project we will use the following Snippets to run our test. Again thanks to Sundell.

class TestObserver: NSObject, XCTestObservation {
    func testCase(_ testCase: XCTestCase,
                  didFailWithDescription description: String,
                  inFile filePath: String?,
                  atLine lineNumber: Int) {
        assertionFailure(description, line: UInt(lineNumber))
    }
}

let testObserver = TestObserver()
XCTestObservationCenter.shared.addTestObserver(testObserver)
<#TestSuite#>.defaultTestSuite.run()

Detecting a String Palindrome

On the very start let us build a simple solution to detect if an input string is a Palindrome or not. We will write some test codes for verifying our solution.

Now what should be our first test case. Hmmm. Let say if a string is not a palindrome then we will say its not a palindrome, right? Simple. 🤓

As it goes on the TDD, let us first have a fail test case. So we will write:

func test_nonPalindrome_string_false() {
        let input = "nonPalindrome"
        XCTAssertFalse(input.isPalindrome, "\(input) is not be a Palindrome")
    }

As we can see the nonPalindrome is no way a palindrome. So we should have a false return on isPalindrome. But we have an error: Value of type 'String' has no member 'isPalindrome'. Hmm failed case. Let us define the minimal code to pass the test.

extension String{
    var isPalindrome: Bool {
        return false
    }
}

Now we have a isPalindrome which passes our test. But wait! Returning false not gonna work on future. Ya ya we know, but it’s the TDD way.

TDD approach

For the each test case repeat the following:

• Write a fail test
• Write minimal code to pass that test
• Refactor the code

Then we will move to the next test case and follow the above approaches. And will continue on this way until all the test cases are passed. On some future time we will have details talk on TDD.

Continuing with string palindrome

Now for our next test case we will have a valid palindrome and for that the isPalindrome should return true.

func test_palindrome_string_true() {
        let input = "wow"
        XCTAssertTrue(input.isPalindrome, "\(input) is a Palindrome")
    }

Guess what, we have a fail test case. isPalindrome is returning false, where it should return true. Minimal code to fix that, right:

Replace the value of isPalindrome with return self == String(self.reversed()) where in previously it was returning false. So the isPalindrome on the String extension becomes as following:

extension String{
    var isPalindrome: Bool {
        return self == String(self.reversed())
    }
}

Re run the tests and everything pass. Now let us have some other tests to verify our solution.

func test_nonPalindrome_text_false() {
        let input = "This is a non-palindrome text"
        XCTAssertFalse(input.isPalindrome, "Should have return false for: \n \(input)")
    }
    
    func test_palindrome_text_true() {
        let input = "wow wow"
        XCTAssertTrue(input.isPalindrome, "Should have return true for: \(input)")
    }
    
    func test_nonPalindrome_textWithSpace_false() {
        let input = "wow wow "
        XCTAssertFalse(input.isPalindrome, "Should have return true for: \(input)")
    }
    
    func test_nonPalindrome_mixCase_false() {
        let input = "Wow wow"
        XCTAssertFalse(input.isPalindrome, "Should return false as there is a capital W on the\n \(input)")
    }
    
    func test_palindrome_mixCase_true() {
        let input = "Wow woW"
        XCTAssertTrue(input.isPalindrome, "Even case is mixed but this is a palindrome text:\n \(input)")
    }

Think we have cover for String type now. Let us move to other type such as Int.

How about a Palindrome of Int

Now heres come the new requirement. We need to support Int also. So what will be some example of Int palindrome? 121, 44, 12321 etc.

Our first test case is 100 which is not a palindrome.

func test_nonPalindrome_Int_false(){
        let input = 100
        XCTAssertFalse(input.isPalindrome, "\(input) is not a palindrome Int")
    }

Same way the test fails as isPalindrome is not defined for Int. Let us fix that.

Here we will go for a very simple implementation for palindrome in Int. We will just convert the Int to String and use the String type’s isPalindrome to verify.

extension Int{
    var isPalindrome: Bool{
        return String(self).isPalindrome
    }
}

Our primary goal of this talk is to build the generic environment rather than solving the palindrome problem. So let us stick with the solution and continue with it.

Now after having this test code we can see the test case100 is passing. Let us add a Palindrome Int then.

func test_palindrome_Int_true() {
        let input = 121
        XCTAssertTrue(input.isPalindrome, "\(input) is a palindrome Int")
    }

Ok this one also pass and finally we have a Int palindrome test.

How about some more test on Int.

    func test_longPalindrome_Int_true() {
        let input = 0000000000
        XCTAssertTrue(input.isPalindrome, "Long sequence on Zero should be a palindrome")
    }
    
    func test_nonPalindrome_negativeInt_false() {
        let input = -111
        XCTAssertFalse(input.isPalindrome, "\(input) should not be a palindrome")
    }

Hmm things are passing and we are good. Moving to Double palindrome.

Can we have Double Palindrome

Ok now how about Double palindrome. Palindrome on Double happens to be not only same sequence before and after the period ., but also the sequence should themself be palindrome like Int palindrome. So 131.131 is a palindrome. On the other hand 12.121 is not a palindrome. Even though the numbers without period/dot is a palindrome.

Time for some double palindrome test.

    func test_nonPalindrome_double_false() {
        let input = 12.01
        XCTAssertFalse(input.isPalindrome, "\(input) should not be a Palindrome Double")
    }
    
    func test_Palindrome_double_true() {
        let input = 12.21
        XCTAssertTrue(input.isPalindrome, "\(input) should be a Palindrome Double")
    }
    
    func test_Palindrome_double_true_aroundPeriod() {
        let input = 12.121
        XCTAssertFalse(input.isPalindrome, "Even though the 12121 is a palindrome, but \(input) must be palindrome around period")
    }

As we already guess for now the double isPalindrome is as following:

extension Double{
    var isPalindrome: Bool{
        return String(self).isPalindrome
    }
}

Converting into a more Generic solution for detecting Palindrome

Now we already have the big picture. So now let us have a introduction to a more Generic solution on our Swift code.

We gonna have a generic solution based on the way we just compare the String format of a type(Int, Double) with the reverse String format to validate the Palindrome sequence. For doing so we have to make sure that the type is confirming the LosslessStringConvertible protocol. Otherwise the conversion to String will fail on compile time. So our generic solution as follows:

func palindrome(input: T) -> Bool{
    let stringFormatted = String(input)
    return stringFormatted == String(stringFormatted.reversed())
}

As a result we can have the test as following:

func test_String() {
        let palindromeString = "wow wow"
        XCTAssertTrue(palindrome(input: palindromeString), "Should be a palindrome String")
        
        let nonPalindromeString = "nonPalindrome"
        XCTAssertFalse(palindrome(input: nonPalindromeString), "Should not be a palindrome string")
        
    }
    
    func test_Int() {
        let palindromeInt = 121
        XCTAssertTrue(palindrome(input: palindromeInt), "Should be a Int Palindrome")
        
        let nonPalindromeInt = 100
        XCTAssertFalse(palindrome(input: nonPalindromeInt), "Should not be a Palindrome Int")
    }
    
    func test_Double() {
        let palindromeDouble = 12.21
        XCTAssertTrue(palindrome(input: palindromeDouble), "Should be a Double Palindrome")
        
        let nonPalindromeDouble = 12.121
        XCTAssertFalse(palindrome(input: nonPalindromeDouble), "Should not be a Palindrome Double")
    }

Summarizing the generic evolution for the problem

Maybe the overall solution and the case study is pretty easy and strait forward. But this was meant to be an introductory post on Generic. So let us have some basic discussion aka easy-peasy talk with the generic solution. We will continue the discussion with some very basic question. Now we had the Generic method which is as follow:

func palindrome(input: T) -> Bool

What is the T?

So T defines a generic type, the type can be Int Double String or any other type. On run time the Generic type T will be replaced with the actual type.

Commute can be a similar example of generic type ,T , if we want to relate the generic concept with the real life. So when we say a 10 mins commute, the commute does not say anything about the commute type like walking biking or commuting through car bus. This just say a 10 mins commute. We implement the commute on run time or in real life when we start the commute through any of the commute type.

Now what if there is multiple Generic type. Convention is to use U or any other you like to use.

does T inherits from LosslessStringConvertible?

Second question does T inherits from LosslessStringConvertible? Well on Swift world we would use the term confirms to LosslessStringConvertible rather than the inherits. Because LosslessStringConvertible is a protocol. Ok but whats with the inheritance and protocol confirmation? Hmm let us have some shared links. Here you will get the inheritance talk. And here you will get the protocol confirmation talk. Both of these two are a series of continuous blog post where we discussed why composition over inheritance is better and how to achieve composition? Feel free to pay a visit on those blog post on your free time.

what does the T: LosslessStringConvertible mean?

Now in plain word T: LosslessStringConvertible means T can be any type but that type need to confirm LosslessStringConvertible protocol. Thats why the Float can not call the generic function as Float does not confirms the LosslessStringConvertible protocol.

Do the angle brackets < > has some value on generic?

It is a generic way of representing generic definition. Those two angle brackets tells the reader and the compiler that we have a generic type with its requirements.

Do we read input: T the same way as we do on other functions

Yes, that is what input: T mean. It says input is a T type of instance when it is compiled. And on run time the T is replaced with the actual type.

Why do we need the T to confirm LosslessStringConvertible

Because we are converting the Generic type to String when we are writing String(input), where input: T.

Best practice for implementing generic solution

Though this was a pretty easy talk on Generic introduction on Swift, but this can a good place to know when we should go for generic solution.

Let us consider another solution of this same problem through Swift extensibility feature. Let us extend LosslessStringConvertible to have the same functionality. So the final pice of code.

extension LosslessStringConvertible{
    var palindrome: Bool{
        let stringForm = String(self)
        return stringForm == String(stringForm.reversed())
    }
}

Now this version is very concise. So which one is the right approach?

If we use the approach of extending the LosslessStringConvertible protocol then all the types that confirms LosslessStringConvertible now have the palindrome var. Do our use case suggest that? If not the the generic function approach is the solution.

So let us finish this blog post by having some guidelines on best practice for implementing generic solution:

• Generic solution is must when type safety is a major priority.
• Generic solution is good for implementing algorithm.
• When ever there is code duplication we can count generic on that case.
• Most importantly we can avoid the ugly type casting.
• And finally to restrict ourself from using Any.

Generic vs Any

On this Introduction of Swift Generic talk we have not cover a very important topic. The topic of when to choose Any over Generic or vice versa. Perhaps that needs a separated talk. On some future talk we will highlight the points for reducing the use of Any on our beloved code base.

End talk

It takes time and patient to set our mind for using Generic. This Swift Generic introduction blog post is the very first one of a series where we will try to achieve this goal. Let stay tune. The next one will not be so easy-peasy. The source code of this talk is shared on Github.

Reference

• Swift Generic & Protocol
• Snippets
• Playground source code @GitHub
• Apple doc on Generic
• Swift Generic (expanded)
• Swift snippets
• Test on Playground by Sundell
• Playground tips & tricks by Sundell

The post Swift Generic introduction appeared first on mobidevtalk.

Well if you use some other cool stuff like AppCode, then this blog post may not add value to your craftsmanship. Otherwise let us dive deep 🌊.

Another very useful shortcut for me is the slowing down the Simulator’s animation. By toggling the animation I can see the transformation in a far more greater details. There are also some shortcuts for scaling the simulator. These various Simulator Shortcuts are also the topic of this blog post.

At the end of this blog we can have the Xcode and Simulator shortcuts in different format to make life a lot easier.

Background

• Build & Run Shortcuts
• Playground
• Scheme & Destination based Shortcuts
• Breakpoint
• Intra File Navigation
• Inter File Navigation
• Editor shortcuts
• Moving Focus to different editor
• Find & Replace
• Tab & Window selection
• Simulator Shortcuts
• Adding shortcuts on Xcode
• Adding Refactor Renaming shortcuts
• Xcode Shortcuts Conflict resolving
• How to use this blog post
• Give me my free Xcode shortcut resources
• Reference

Before we start we have to understand that the number of Xcode shortcuts are not short at all. There are thousands of shortcuts people use regularly. On this blog post I will share mine.

Some very obvious & popular shortcuts like

• toggling comment ⌘ / or Command /
• opening the Xcode preference ⌘ , or Command ,

will not be discussed here. Because either shortcuts like toggle comment is very well known or shortcuts like opening the Xcode preference is not regularly used.

We can watch the various Xcode & Simulator shortcuts in action on our youtube playlist.

Build & Run Shortcuts

I believe we all use those shortcuts.

Playground

There are two useful playground shortcuts. Specially after you disable the auto run option.

This two shortcuts are customized by me. It is my preference. You can add your based on your preference. Later on this blog post we have Adding shortcuts on Xcode section, visit the section for more details on adding shortcuts on Xcode.

Scheme & Destination based Shortcuts

Now this Xcode shortcuts are not very common among us. But once you start to using those I am sure you can’t stop using these shortcuts.

Multiple scheme is a requirements now a days. We usually have two to three scheme like staging, production and release. All of those target individual endpoints for data fetching plus the other configuration setup. To support localization you also may have one or two schema. So now that you have multiple scheme how would you like them to run? Each time by clicking the schema from the list by a mouse or trackpad?

And what about the device or simulator selection? Agin will you use the mouse or trackpad?

Oh come on there is a far more better way than this. Let start using the shortcuts for Xcode Scheme and destination selection.

Let us have look on the Schema & Destination based shortcuts in action.

Breakpoint

There are many of the breakpoints. But the most used are as following.

Let’s see those in action.

Intra File Navigation

Now this one is a bit huge. It is far more faster movement once you have the mastery on the intra file or in file navigation.

Let us watch the Intra file navigation in action.

Inter File Navigation

Now let us have a look on the inter file navigation.

In action.

Editor shortcuts

The editor shortcuts as follows.

In action.

Moving Focus to different editor

Suppose we have some editors open. But clicking is no doubt a time consuming task. So let us introduce ourself with editor focusing in Xcode.

In action.

Find & Replace

Find is one of the most common used shortcuts. The Find and Replace was a very useful one before Xcode’s refactoring was available 😜. Also the Refactoring in current scope and all through the project are also super useful shortcuts.

Tab & Window selection

Selection between different tab and window selection shortcuts as follows.

Simulator Shortcuts

We not only have the Xcode Shortcuts only but we also some simulator shortcuts. which definitely add more value on the iOS day to day Cheat Sheet. Let us have some simulator shortcuts.

Now we can say the Xcode and Simulator Shortcut Cheat Sheet

Let us watch the simulator shortcuts on action.

Adding shortcuts on Xcode

Move to Xcode -> Preferences... -> Key Bindings. Here you can add or update the Xcode shortcuts. The Customized section have all the customize shortcuts that we previously defined. Also best not to have any ConflictsShortcuts. On the next section we will watch to add a custom shortcut and man that’s an important one. It’s none other than the Renaming shortcut scoped on the whole project 😉.

Adding Refactor Renaming shortcuts

The refactoring to rename a property, is given a separated section on this blog post because of the importance it has on our daily use. Xcode took some time to revel the Swift refactoring. But still it is one of the most use feature. Currently we do not have a default shortcut for Renaming a property. So let us add that shortcut and watch it on action. Let us have a better understanding through a video.

Xcode Shortcuts Conflict resolving

Now as we start to add some shortcuts as by our preference, Xcode will start to notify us if we make some conflicting shortcuts. However those shortcuts may not only be conflicting with already defined Xcode shortcuts, but also with System shortcuts.

Anyway the solution is simple. We need to remove one of the conflicting shortcut. On Xcode press the command , ⌘ , to open the Xcode preference. Go to Key Bindings . Then select the Conflicts section. Now you will have the conflicting shortcuts list. The Red marker are conflicting shortcuts with-ing Xcode. And the Yellow are the conflicting shortcuts with the system.

For inter Xcode shortcut conflict just select the one that you want to remove. Tap/click on the - negative sign to remove that shortcut. Simple right.

On the other hand for conflicting shortcuts with system shortcut we need to remove those from System Preference. Open the System Preference, tap/click on the Keyboard and select the Shortcuts section. Now just deselect those which are conflict with Xcode. We need to remember that those system shortcuts now will not be active after we deselect those. So cut your coat according you needs. Let see the System level conflict resolving in action.

How to use this blog post

There are couple of ways to use this blog post as your benefit. The very first and easy way is to bookmark this page, which I not gonna recommended. Because this blog post may not be something you need to visit on some timely manner.

There is another way, a better way. I can send you the related docs which includes a pdf and a Page Document and an epub formatted book.

Now you can use the pdf as reference by printing or keeping somewhere from where you can access more quickly.

Better way is to add the epub book on your Books.app application and use it as the reference for finding the Shortcuts of Xcode and Simulator.

The best way I believe, will also need your effort. You can pick the specific shortcut table and make it a pdf or an image and can keep it as your wallpaper on your working space. Once you become expert on that shortcut, then move to the next table of shortcuts and follow the same way until you become also an expert on that part also. Continue until you think you are good enough. On the mean time you can also add your preferred shortcuts on the way.

When I started to use Xcode and Simulator shortcuts, I didn’t have this resources. I believe it is a very good resource to have. Now you can have it. Use the Xcode Shortcuts resource as a Cheat Sheet for iOS development to boost ur level.

Give me my free Xcode shortcut resources

I will need your email id for sending the resources. I can confirm I don’t like unnecessary emails on my mail box, so I confirm I won’t send anything unnecessary.

If you already filled the email, you can still have the resources again. Just fill the email and continue to confirm section. On the confirming section you will have the download link. Never mind to submit your email more than once to get those resources. Though you will get the resource on your mail once, after that you need to download it form the mail confirmation section.

Welcome to Xcode Shortcuts paradigm, the iOS dev Cheat Sheet.

End talk

The Xcode Shortcuts is one of the coolest Cheat Sheet we can have on our disposal. Let us deposit those Xcode Shortcuts more often so that it makes a boost on our iOS career, you know this is the Cheat Sheet. See you around.

Reference

• Xcode & Simulator shortcuts playlist on youtube
• More on NSHipster about some cool gesture use
• Initial inspired from swifteducation

The post Xcode Shortcuts the iOS Cheat Sheet appeared first on mobidevtalk.

Background

• At a glance
• Love for Enum
• Love for Enum, continuing…
• enum case study: Tic tac toe, through enum
• mutating enum struct on Swift
• End talk

At a glance

Below is the related post on enum on this blog.

Let us review all of them in short one by one.

Love for Enum

On our very first blog over enum, Love for Enum, we have the basic introduction with enum. So topic like rawValue, hashValue, associated value were discussed there. More importantly we discussed about the use case for each of those bases concepts of enum. And finally we answered one of the most commonly asked question: Why we can’t use associated value with hashValue together on enum. Even if you posses the basic knowledge about enum on Swift, though I will request you to visit that blog post at least once. Because those topic/concepts may seems very trivial on an overwatch position they are not. They are the building block of enum.

Love for Enum, continuing…

On our second blog post over enum, Love for Enum, continuing…, we moved on a bit more advanced topic. Such as generic usage on enum, Error definition through enum, why not to mutate enum, recursiveness of enum. Also the allCases and the frozenness of enum. This blog post moves us into a bit more advance level as we will start for a big jump on our next blog post on enum. A blog post about the case study on enum.

enum case study: Tic tac toe, through enum

Here comes the big part. Now we will implement the learned knowledge from the previous two blog post. We will build a case study which suits the enum nearly perfectly. On the building of Tic tac toe through enum we will get an insight of enum usage on real life. We briefly explain the cause of choosing different features of enum. Here we will get the fun of using Swift switch in action. Also the different version of Swift enum init. On the Tic tac toe, through enum blog post most of time we choose enum as our primary data container.

To develop this blog post we use the TDD approach. So when we have the source code, which is hosted publicly on GitHub, we will see a lot of test cases. On some future time we will cover the TDD.

mutating enum struct on Swift

This blog post is not directly connected to enum, rather it is more connect with the value type. Here on this blog post we will learn how we can mutate the value type. Even more is it ok do such mutation for value type. Whats the stand view of value type on this type of mutation.

End talk

There are some topics those are not discussed on the enum blog post series. Topic such as Swift enum codable and Swift struct & enum relation are not touched. May be on some future time we will.

The official Swift doc largely covers the topics of enum on Swift. But to cover some real life implementation of enum we talked a lot on this blog. Proper usage of enum can drastically change our capability on Swift. So keep digging for more enum treasure. Take care.

The post Swift Enum Hub appeared first on mobidevtalk.

We are going with the protocol feast. Our last five blog post is all about protocol; what we can achieve through protocol on Swift. But on the last blog post we have a detail talk on Dependency Inversion Principle, DIP, on Swift. It is a good starting point if we need some solid ground to start from. The Swift Protocol Hub contains all the related posts with protocol. Be sure to check that out.

Background

• What is Dependency Injection
• Fundamental Difference between Dependency Injection & Dependency Inversion
• Types of Dependency Injection
• Protocol usage on Dependency Injection
• Discussion on Dependency Injection
• Benefit
• Drawback
• Tricks and tips

Dependency Injection

First let us have some idea about Dependency Injection. Then we will move to Dependency Injection on Swift realm. To be honest Dependency Injection is a pretty simple concept. But the lack of knowledge makes it align to us.

We can think Dependency Injection as the process of suppling a property of an Instance outside of its scope. In other words, setting a property of a class/struct/enum from outside. Let see through an example.

struct SuperHero{
    var superPower: String?
}

On the above SuperHero has a dependency on superPower. Now we will inject this dependency from outside scope of SuperHero, like following:

var hero = SuperHero()
hero.superPower = "N/A"

As we can see we are injecting the property value outside of SuperHero scope. Now you must be frustrating saying, What!!! for this easy-peasy concept we are going through a blog post.

And you are not so wrong. It is definitely a very easy concept. But proper usage of Dependency Injection will make your code decoupled. Which ultimately makes life easier when changes arrive. So stay tunes. We have some talks to talk.

Fundamental Difference between Dependency Injection & Dependency Inversion

Whenever we talk about Dependency Injection we often talk about Dependency Inversion, but this two are fundamentally two different concept.

Dependency Inversion is the alteration of Compile Time Dependency or Source Code Dependency against the Run Time Dependency. For more info we can always visit the introductory blog post about Dependency Inversion on Swift.

So basically Dependency Inversion is the way of achieving the following statement.

High level policies should not depend on low level details. They both should depend on abstraction.

– Generic term

On Swift we use protocol to achieve that abstraction. And thats where the confusion occurs among Dependency Inversion and Dependency Injection. Because, as we will learn shortly that, protocol is also used for achieving Dependency Injection on Swift.

Now Dependency Injection is like setting a property of class/enum/struct on its simplest term. But it is not like setting each and every property with Injection. There need to be some criteria about when to set those property from outside, we will talk about those on this blog post also.

So on a conclusion it should clear by now that, Dependency Inversion and Dependency Injection are always two different concept, they share the only two thing in common, the Dependency keyword and the use of protocol. Thats it.

Types of Dependency Injection

There are basically three types of Dependency Injection.

• Construction injection
• Property injection
• Method injection

Construction Injection

When Injection of a property is done on init time.

SuperHero(superPower: "Speed")

On the above example the property superPower of SuperHero is being initialized on the struct’s construction/init time. As we are injecting the value of the superPower property on construction time, that’s why it is called Construction injection. The term Construction is used as the similar term of initialization.

Property Injection

This type of injection is very common. When we assign a property value after the instance has been initialized. So it is like assigning internal property.

var hero = SuperHero()
hero.superPower = "N/A"

Method Injection

On method injection we will inject the methods from outside. Now how thats possible? Remember the protocol? When we have the implementation of a protocol on our class/struct/enum, we can mock or fake that implementation through another implementation of that protocol.

We are more concern about this type of Injection on our current blog. Let us have some details talk over this topic.

Protocol usage on Dependency Injection

Let us consider a superstitious situation. Say Iron Man is preparing for some new job. For this regard he need to build up his resume. As he is very busy with his current job, he is thinking about some third party solution on building his resume.

Iron Man will provide the necessary infos for the resume and the third party will provide him the resume format. Now the info-gathering and the resume-format is now a dependency for Iron Man.

On the current section we will inject this two dependency through protocol.

Building the capability model

So first we will build some models by which the capability can be represented.

enum Scale: String{
    case noob = "Below basic"
    case basic = "Basic"
    case intermediate = "Skillful"
    case advance = "Very Skillful"
    case superAdvance = "Super Skillful"
}

enum Capability: CustomStringConvertible{
    case strength(Scale)
    case speed(Scale)
    case fly(Scale)
    
    var description: String{
        switch self {
        case .strength(let scale):
            return "\(scale.rawValue) level of Strength"
        case .speed(let scale):
            return "\(scale.rawValue) level of Speed"
        case .fly(let scale):
            return "\(scale.rawValue) level of Flying"
        }
    }
}

Scale is a model which represent the skill level. Scale has String as rawValue. Then the Capability is a enum reprinting different capabilities. It takes Scale as associated value.

Defining Recruiter protocol

Now if we define the info-submission and resume-formatting inside the IronMan model, then we will couple the code with two separated concern. Moreover we will not be able to update the resume-formatting if we want to choose another type of formatting. The best option here is to put those two in a protocol. So that we can have polymorphism later down the road.

protocol Recruiter{
    func submitInfo(name: String, superHeroName: String, capabilities: [Capability])
    func formattedInfo() -> String?
}

The submitInfo stands for the info-submission and the formattedInfo stands for the resume-formatting.

IronMan

Now let us declare the man of the show, IronMan.

struct IronMan{
    private let name = "Tony Stark"
    private let aka = "Iron Man"
    private let capabilities: [Capability] = [.strength(.advance), .fly(.superAdvance)]
    
    let recruiter: Recruiter
    
    func submitResume(){
        recruiter.submitInfo(name: name, superHeroName: aka, capabilities: capabilities)
    }
    
    func resume() -> String{
        return recruiter.formattedInfo() ?? ""
    }
}

The submitResume() method will submit the infos to the Recruiter and then the resume() will get the formatted resume from the Recruiter.

Recruiter implementation

Let us define a recruiting agent.

class Agent: Recruiter{
    private var resume: String?
    
    func submitInfo(name: String, superHeroName: String, capabilities: [Capability]) {
        let capabilityString = capabilities.reduce(into: "Capabilities includes:", { $0 += " " + $1.description + "," })
        resume = "Name: \(name)\nAKA: \(superHeroName)\n\(capabilityString)"
    }
    
    func formattedInfo() -> String? {
        return resume
    }
}

So the Agent can build a simple resume and can return it back. Now if IronMan want to use his service then following code will do just that.

let ironManThroughAgent = IronMan(recruiter : Agent())
ironManThroughAgent.submitResume()
print(ironManThroughAgent.resume())

Through the Agent the resume is like following.

Name: Tony Stark
AKA: Iron Man
Capabilities includes: Very Skillful level of Strength, Super Skillful level of Flying,

Thats ok but not good enough to convince IronMan. So the IronMan search for another implementation of Recruiter. This time an Agency.

Agency of Recruiter

Let us define an Agency for Recruiter.

class Agency: Recruiter{
    private var resume: String?
    
    func submitInfo(name: String, superHeroName: String, capabilities: [Capability]) {
        let splittedName = name.split(separator: " ")

        let fullName = "First name: " + (splittedName.first ?? "") + (splittedName.count > 1 ? "\(splittedName.dropFirst(1).reduce(into: "\nLast name", { $0 += " " + $1 }))" : "")
        
        let capabilityString = capabilities.reduce(into: "Capabilities:", { $0 += "\n" + $1.description })
        
        resume = "Commonly Know as: \(superHeroName)\n\(fullName)\n\(capabilityString)"
    }
    
    func formattedInfo() -> String? {
        return resume
    }
}

Now IronMan can have his resume as follows.

let ironManThroughAgency = IronMan(recruiter : Agency())
ironManThroughAgency.submitResume()
print(ironManThroughAgency.resume())

Which results in the following way.

Commonly Know as: Iron Man
First name: Tony
Last name Stark
Capabilities:
Very Skillful level of Strength
Super Skillful level of Flying

Now that is a ok version of resume for IronMan. Let us move to the discussion on hows and whys of Dependency Injection through this case study.

Discussion on Dependency Injection

On the above case study we had two dependencies, one is the info-submit and the other resume-formatting. We inject those two dependencies through a protocol. First we use the Agent class. Then we inject another implementation of Recruiter when we use Agency. If we had not use the protocol then we would not be able to use two different implementation, in other words different dependencies.

This type of protocol based dependency injection comes really really handy when we want to mock some implementation on Test. The protocol based dependency injection is a must for TDD, Test Driven Development. On future we will have details talk on TDD, there we will cover the protocol based dependency injection for TDD.

Benefit

What benefit does Dependency Injection gives us? Followings.

• Decoupled code
• Mocking on TDD
• Multiple implementation or polymorphism
• Elimination of Singletons

Drawback

If we overuse the Dependency Injection then it will result in a fuzzy code. Sometimes improper naming causes huge confusion when Dependency Injection is in place.

Tricks and tips for Dependency Injection

We are at the end of this blog post. Before finishing I want share some insights about Dependency Injection. As always the balance of doing or not doing is the most important thing. It is not always possible to predict the changes. So when you find a change area try to think if Dependency Injection can help you on that case.

One another thing, we can use the default value on construction time when we want the default value always but sometimes the injected value. Say we want to have the Agency as default Recruiter then we can write the init of IronMan as following.

init(recruiter: Recruiter = Agency()) {
        self.recruiter = recruiter
    }

So now the IronMan() will init the instance with Agency as the Recruiter.

End Talk

Dependency Injection talk can not be finished without showing the implementation of Dependency Injection on test. On Swift protocol is a huge benefit when we can implement the Dependency Injection on the realm of TDD. Stay tunes we will load the TDD talk soon.

Resources

• Source code for this blog post is hosted on GitHub
• DI in details
• DI with Protocols
• Nuts and Bolts of DI
• DI Is NOT The Same As The DIP
• Iron Man of Marvel

The post Dependency Injection in Swift appeared first on mobidevtalk.

The Swift Protocol Hub contains all the related posts with protocol. Be sure to check that out.

Background

• What is Dependency Inversion
• Why we need the Dependency Inversion
• Generic process for achieving Dependency Inversion through protocol
• Explanation of DIP on UITableViewDataSource
• A case study on Dependency Inversion principle
• How and where to smell for implementing DIP On Swift
• Best practices on Swift for DIP through protocol
• Resources

Dependency Inversion

As we said on our last blog post that, the process of reversing the run time dependency with respect to the compile time dependency is called the Dependency Inversion.

Say we have two different module, A and B. A is dependent on f() which is defined in B. So for A, A is dependent on B both on run and compile time.
Now consider, if we introduce a protocol p which will hold the declaration of f(). And B implements that protocol thus defining the f(). On this time if A uses the p.f(), then the dependency is inverted and Dependency inversion is achieve. Because on compile time A is dependent on P, which is reverse of the run time dependency to B.

In case of a confusion we can alway visit our last blog post and review the explanation of run and compile time decencies.

Why we need the Dependency Inversion

The basic question has not been answered yet. Why do we need dependency Inversion?

The reason is to achieve loosely coupled code base. And we understand that, the loosely coupled code is far more flexible to requirement changes.

That leads to another question. How Dependency Inversion makes the flexible code?

By implementing dependency inversion principle we create an abstraction between two interacting module. Both of those two interacting module depends on the abstraction. In Swift we achieve the abstraction through protocol.
Now the individual module can evolved separately based on the requirement changes without affecting the counterpart module. The reason is both module only knows the protocol not the other part. So one module is unaware of the adding, updating or even removing of other module. Thats how Dependency inversion makes the code more flexible with requirement change.

Generic process for achieving Dependency Inversion through protocol

Ok so now we know dependency inversion is a necessity for agile code. We already have a clue on how to achieve that dependency inversion through abstraction. More specifically on Swift, protocol is the key for dependency inversion.

On general we hide the implementation details through abstraction to gain loosely coupled code. There is a common term used regularly to describe the dependency inversion principle:

High level policies should not depend on low level details. They both should depend on abstraction.

-Generic term

We need an explanation for the above statement. Usually high level policies means the logic part of a module and the low level details means the implementation part of that module. Now an example will clarify the issue.

We will pick one from the UIKit itself. Perhaps we use this specific dependency inversion most often without knowing its existence. Well, it is none other than the UITableViewDataSource. Amazing right? On reality every delegation is a case of DIP. We use the Dependency Inversion principle on Swift whenever we are initiating and implementing the protocol, may be without understanding. That blur part is the target of this blog post. We want to focus on the usage the Dependency Inversion Principle on Swift through protocol on a concern mind on this blog post. Hopefully after this blog post we will be able to use the protocol effectively to achieving Dependency Inversion Principle to the proper way.

Explanation of DIP on UITableViewDataSource

Now let us concentrate our discussion on the hows and whys of UITableViewDataSource. So what happens by conforming the UITableViewDataSource delegate. We have to implement two methods tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int and tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell. Both of this two method are actually asking us about the higher level logic like what will be the total number of rows and how the cell will be defined.

See how the Dependency inversion principle is operational on UITableView. All the implementation details, like rendering or like gesture handling, are kept hidden from the higher level logic. Based on the higher level logic, that we defined on those two methods, the lower level implementation will be laid out. But interestingly they both are dependent on the abstraction or on the protocol. In other words, both the higher level logic and the lower level details are dependent on the abstraction/ protocol. Let us have a diagram of this specific dependency implementation.

As we can see the the Higher level logic[Code base] has a run time dependency on UIKit but it has no compile time dependency on UIKit. Rather the Higher level logic[Code base] has a compile time dependency over a protocol, UITableViewDataSource.

Now let us have a small talk over the benefit of this type on dependency inversion principle. Let say the latest release of the iOS has some different rendering mechanism than the previous one. Guess what? We do not need to think about it. Even the C++ lib that is doing the render may be thrown away by apple, but we are still good. 🤓

Amazing right.

Now let us build one case study for ourself to implement the Dependency Inversion principle from scratch. 💪

A case study on Dependency Inversion Principle

Let say we are building a profiling module for a game. For the profiling module let us have some use cases:

• We need to profile the different characters with their basic infos and also their capabilities
• Now talk about their capabilities, they will definitely differ among those characters
• Also the basic infos will differ
• Moreover there is the possibility of adding more character on the game on some future time

We want to build our profiling module so that it can handles all the above scenario.

Now let us consider, which part is dependent on which part. Say we will display the Characters profile on ProfileScene. So ProfileScene should have the instances of those characters. But if we do that then ProfileScene has the run and compile time dependency on those Characters. A better approach will be to break that dependency by introducing an abstraction, protocol. Say we named that protocol Profilable. So now if we store the Profilable instances on our ProfileScene rather than the concrete type, then the compile time dependency of ProfileScene is inverted than its run time dependency. Thus giving us the benefit of updating the concrete type or even the ProfileScene. Moreover we can add other character once they confirm the Profilable protocol. Let us have some code now.

Profilable model

Let us define the Profilable protocol.

struct BasicInfo{
    enum Gender: String {
        case Male
        case Female
    }
    
    let fullName: String
    let gender: Gender
}

enum Species{
    case God
    case Mutated
    case Human
}

protocol Profilable{
    var infos: BasicInfo { get }
    var Species: Species { get }
    
    func remarks() -> String
}

The BasicInfo and the Species are the helper data structure. By the way if we need any help regarding enum we cal always visit the enum talk for more details.

DC comics character

Let add some DC comic character. These characters are already been added on our inheritance talk. For this talk will extend those types to confirm the Profilable protocol.

extension Batman: Profilable{
    var infos: BasicInfo {
        return BasicInfo(fullName: "\(originalName) aka: \(name)", gender: .Male)
    }
    
    var Species: Species {
        return .Human
    }
    
    func remarks() -> String {
        return profile ?? speciality()
    }
}

extension WonderWoman: Profilable{
    var infos: BasicInfo {
        return BasicInfo(fullName: "\(originalName) aka: \(name)", gender: .Female)
    }
    
    var Species: Species {
        return .God
    }
    
    func remarks() -> String {
        return "Zeus daughter. \(profile ?? speciality())"
    }
}

Pretty simple right? Now Batman and WonderWoman confirming the Profilable protocol and defining the required var and method.

Marvel Character

Now it is time to add some more characters but this time from Marvel. Again we already added those Avengers on our Protocol, Swift way of thinking talk. Let us extend those Avengers and confirm to Profilable protocol.

extension IronMan: Profilable{
    var infos: BasicInfo {
        return BasicInfo(fullName: "Tony Stark aka: \(name)", gender: .Male)
    }
    
    var Species: Species {
        return .Human
    }
    
    func remarks() -> String {
        return "Founding member of Avengers. \(speciality)"
    }
}

extension CaptainAmerica: Profilable{
    var infos: BasicInfo {
        return BasicInfo(fullName: "Steve Rogers aka: \(name)", gender: .Male)
    }
    
    var Species: Species {
        return .Mutated
    }
    
    func remarks() -> String {
        return "True born leader. \(speciality)"
    }
}

extension Hulk: Profilable{
    var infos: BasicInfo {
        return BasicInfo(fullName: "Bruce Banner aka: \(name)", gender: .Male)
    }
    
    var Species: Species {
        return .Mutated
    }
    
    func remarks() -> String {
        return speciality
    }
}

extension Thor: Profilable{
    var infos: BasicInfo {
        return BasicInfo(fullName: "Thor Odinson aka: \(name)", gender: .Male)
    }
    
    var Species: Species {
        return .God
    }
    
    func remarks() -> String {
        return speciality
    }
}

Again nothing fancy. Providing the implementation of Profilable. Now let us add up those characters to make the final ProfileScene.

ProfileScene

On our final code section we will have two separated array of Profilable, one for the JusticeLeague and another for the Avengers. And finally we will return a String containing all those character with some minor formation.

struct ProfileScene{
    let justiceLeague: [Profilable] = [Batman(), WonderWoman()]
    let avengers: [Profilable] = [IronMan(), CaptainAmerica(), Hulk(), Thor()]
    
    func profileListing() -> String{
        let justiceLeagueProfile =  justiceLeague.reduce(into: "Justice League:\n") { (initial, profilable) in
            initial += "\nFull name: \(profilable.infos.fullName) \nGender: \(profilable.infos.gender) \nRemarks: \(profilable.remarks())\n"
        }
        
        let avengersProfile =  avengers.reduce(into: "Avengers:\n") { (initial, profilable) in
            initial += "\nFull name: \(profilable.infos.fullName) \nGender: \(profilable.infos.gender) \nRemarks: \(profilable.remarks())\n"
        }
        
        return justiceLeagueProfile + "\n\n" + avengersProfile
    }
}

Now when we run the profileListing() function, print(ProfileScene().profileListing()), we will get an easy locking profiling of all the characters. Oh for the Higher Order Function, HOF, we can look for the HOF talk. Let us take some insights from the above case study.

Insights of the code study

On the above case study we saw how and when to implement the DIP on Swift through Protocol. Here the different characters are the higher level logic. And the profileListing part being the lower level details. These two higher lever logic and lower level details depend on the abstraction. As a result we were able to add more character later down the road. These abstraction gives us the opportunity to develop two part separately.

How and where to smell for implementing DIP On Swift

• When there is interaction between two separated module. Like Business logic and View.
• The simple code update takes a longer time because of the tightly coupled code.
• A simple change request will impact a lot of code base.
• Two module are integrated with each other in such a way that they cross each other boundary.
• When It is known that one module will have the future changes, then it will be a good idea to access that module through DIP from the initial stage.

But the above statement are nothing but vapor unless we know cons of DIP. So Let us jump on the best practices.

Best practices on Swift for DIP through protocol

• The very first and perhaps the most important suggestion is to know, if the Dependency Inversion is a YAGNI or not? YAGNI stands for you ain't gonna need it. Overuse of Dependency Inversion will populate the code base with unnecessary abstraction, which will definitely reduce the readability of the code.
• Start with a concrete type rather than a Protocol when you are uncertain about the future change request.
• Initiate the Dependency Inversion through Protocol when you can see or certainly predict the area of change request.
• The default mode should be YAGNI.
• When working with View interaction it is always helpful to work with Dependency Inversion, because View get modified so ofter.
• When working with Business logic, not tiny business logic, it can also be helpful to use the Dependency Inversion. But again remember the YAGNI.
• Any inclusion of third party lib can be introduce to the code through Dependency Inversion, the reason is that third party lib can be thrown away and also we can mock that third party lib on testing time.

Conclusion

Again there is no Silver bullet. The best we can do, is to educate ourself on the different solutions that are available for us on our specific problem. We need to knows the pros and cons for each of them. Dependency Inversion Principle also fall on this category. We have to balance the YAGNI and DIP. I believe this blog post will give you the solid ground to perambulate further more on this topic.

One other topic regularly comes up with Dependency Inversion Principle is Dependency Injection. Oh boy there are some real confusion among them. We just published a blog post on Dependency Injection. Let us have a look.

See you around.

Resources

• Swift Dependency Inversion through Protocol source code
• DIP by Uncle Bob
• Swift compiler and standard library design
• The sequence is drawn on sequencediagram

The post Swift Dependency Inversion through Protocol appeared first on mobidevtalk.