Advanced Swift test (Advanced)

Sample questions

5 sample questions from the Advanced Swift test, with the answers. Samples are taken out of the live test, so you will not meet these when you sit it.

1. Which of the following examples best demonstrates the application of dependency injection in an app architecture scenario?

   1. Using a singleton network service directly within a view model without passing it as a parameter.
   2. Injecting a concrete implementation of a network service into a view model during initialization.
   3. Passing a protocol type instead of a concrete implementation to a view model.
   4. Creating a network service inside a view model using a factory method.

   Answer: B. Injecting a concrete implementation of a network service into a view model during initialization.

   Dependency injection involves providing an object with its dependencies rather than having it create them internally. In this case, injecting a network service into a view model aligns with the principle of dependency injection, as it allows for easier testing and decoupling of components. The other options either do not represent dependency injection or are unrelated to the concept.

2. In a realistic project scenario, which of the following approaches is best for managing memory ownership and preventing retain cycles when dealing with outlets and delegates in Swift?

   1. Use closures with capturing lists to manage memory ownership in all cases.
   2. Avoid using any references and rely solely on ARC for memory management.
   3. Use weak or unowned references for outlets and delegates to avoid strong reference cycles.
   4. Use strong references for all outlets and delegates to ensure they are not deallocated prematurely.

   Answer: C. Use weak or unowned references for outlets and delegates to avoid strong reference cycles.

   In a realistic project scenario, using weak or unowned references for outlets and delegates is a best practice to prevent strong reference cycles, which can lead to memory leaks. Other options may not directly address memory ownership or may introduce other issues.

3. In the following Swift code, what is true about the closure and retain cycle? `class VC { var onTap: (() -> Void)? func setup() { onTap = { [weak self] in self?.reload() } } func reload() {} }`

   1. The closure holds `self` weakly, preventing a retain cycle.
   2. The closure does not capture `self`, so no cycle is formed.
   3. The closure holds `self` weakly, but the cycle is still present due to the property.
   4. The closure holds `self` strongly, creating a retain cycle.

   Answer: A. The closure holds `self` weakly, preventing a retain cycle.

   In the given code, the closure uses `[weak self]` to capture `self`, which makes it a weak reference. This ensures that the closure does not strongly retain `self`, thus preventing a retain cycle. `weak` references are optional and become `nil` when the object is deallocated, which is why this code is safe and does not create a cycle.

4. Consider a SwiftUI view that holds a closure which references 'self' strongly. This closure is assigned to a property in the view, and 'self' holds a strong reference to the closure. This creates a retain cycle. How can this retain cycle be fixed?

   1. The retain cycle is fixed by changing the closure capture list to [unowned self] and using self!.someMethod()
   2. The retain cycle is fixed by removing the closure and using a delegate pattern instead
   3. The retain cycle is fixed by changing the closure capture list to [weak self] and using self?->someMethod()
   4. The retain cycle is fixed by adding a deinit method to the view and calling someMethod() inside it

   Answer: C. The retain cycle is fixed by changing the closure capture list to [weak self] and using self?->someMethod()

   A retain cycle occurs when two objects hold strong references to each other, preventing them from being deallocated. In this scenario, the closure inside the view holds a strong reference to 'self' (the view), and 'self' holds a strong reference to the closure. This creates a cycle. By using [weak self] in the closure capture list, we break the strong reference cycle. However, we need to check if 'self' is still valid before accessing it, hence using 'self?->someMethod()'. This prevents the retain cycle and ensures proper memory management.

5. Which type of reference in Swift is used to avoid strong reference cycles and automatically becomes nil when the object is deallocated?

   1. strong
   2. weak
   3. nil
   4. unowned

   Answer: B. weak

   In Swift, a weak reference is used to avoid strong reference cycles. It does not increase the reference count of the object it points to, and it automatically becomes nil when the object is deallocated. This makes it suitable for cases where an object is owned by another object, but should not prevent the other object from being deallocated. Unowned references are used when there is a guarantee that the object being referenced will not be deallocated before the reference is used, but they do not increase the reference count either.