Weak references to break cycles in Swift - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to declare a weak reference to avoid a strong reference cycle.

Swift

class Person {
    var name: String
    weak var friend: Person? // [1]
    init(name: String) {
        self.name = name
    }
}

Drag options to blanks, or click blank then click option'

Aweak

Bstrong

Cunowned

Dvar

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'strong' instead of 'weak' causes a strong reference cycle.

Forgetting to mark the property as optional when using 'weak'.

Using weak before the property declares a weak reference, which helps break strong reference cycles.

2fill in blank

medium

Complete the code to declare an unowned reference to avoid a strong reference cycle when the referenced object is expected to always exist.

Swift

class Customer {
    var name: String
    [1] var card: CreditCard?
    init(name: String) {
        self.name = name
    }
}

Drag options to blanks, or click blank then click option'

Aweak

Bunowned

Cstrong

Dlazy

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'weak' when the reference should be non-optional.

Using 'strong' which causes a strong reference cycle.

Use unowned when the reference is expected to always have a value and you want to avoid a strong reference cycle.

3fill in blank

hard

Fix the error in the closure capture list to avoid a strong reference cycle.

Swift

class HTMLElement {
    let name: String
    let text: String?
    lazy var asHTML: () -> String = { [[1] self] in
        if let text = self.text {
            return "<\(self.name)>\(text)</\(self.name)>"
        } else {
            return "<\(self.name) />"
        }
    }
    init(name: String, text: String? = nil) {
        self.name = name
        self.text = text
    }
}

Drag options to blanks, or click blank then click option'

Aweak

Bstrong

Cunowned

Dlazy

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'strong' causes a strong reference cycle.

Using 'weak' requires optional unwrapping inside the closure.

Using [unowned self] in the closure capture list avoids a strong reference cycle while assuming self will not be nil.

4fill in blank

hard

Fill both blanks to create a dictionary comprehension that stores weak references to Person objects.

Swift

var people: [String: [1] Person] = [:]

func addPerson(name: String, person: Person) {
    people[name] = [2] person
}

Drag options to blanks, or click blank then click option'

AWeakReference

Bweak

CStrongReference

Dunowned

Attempts:

3 left

💡 Hint

Common Mistakes

Trying to use 'weak' directly in dictionary value type causes errors.

Using 'unowned' incorrectly in this context.

Using a wrapper type like WeakReference allows storing weak references in collections like dictionaries.

5fill in blank

hard

Fill all three blanks to complete the WeakReference wrapper class that holds a weak reference to an object.

Swift

class WeakReference<T: AnyObject> {
    [1] var value: T?
    init(value: T) {
        self.[2] = value
    }
    deinit {
        print("WeakReference deinitialized")
    }
}

let person = Person(name: "Alice")
let weakRef = WeakReference(value: [3])

Drag options to blanks, or click blank then click option'

Aweak

Bvalue

Cperson

Dunowned

Attempts:

3 left

💡 Hint

Common Mistakes

Declaring the property as strong causes retain cycles.

Using 'unowned' here can cause crashes if the object is deallocated.

The property value is declared weak to avoid strong reference cycles. The initializer assigns the passed person to value.

Practice

1. What is the main purpose of using weak references in Swift?

easy

A. To increase the performance of the program by caching values

B. To prevent strong reference cycles and allow objects to be deallocated

C. To make variables constant and unchangeable

D. To create multiple copies of an object automatically

Solution

1. Step 1: Understand what strong reference cycles are

   Strong reference cycles happen when two objects hold strong references to each other, preventing deallocation.

2. Step 2: Role of weak references

   Weak references do not increase the reference count, so they help break these cycles and allow memory to be freed.

3. Final Answer:

   To prevent strong reference cycles and allow objects to be deallocated -> Option B

4. Quick Check:

   Weak references prevent cycles = C [OK]

Hint: Weak references avoid memory cycles by not owning objects [OK]

Common Mistakes:

• Thinking weak makes variables constant
• Confusing weak with performance optimization
• Assuming weak creates copies

2. Which of the following is the correct syntax to declare a weak reference to an instance of class Person in Swift?

easy

A. weak var friend: Person?

B. weak let friend: Person?

C. weak var friend: Person

D. var weak friend: Person?

Solution

1. Step 1: Understand weak reference syntax

   Weak references must be declared with weak var and must be optional because the referenced object can be nil.

2. Step 2: Check each option

   weak var friend: Person? uses weak var friend: Person?, which is correct syntax.

3. Final Answer:

   weak var friend: Person? -> Option A

4. Quick Check:

   Weak references use 'weak var' and optional type = A [OK]

Hint: Weak references are always optional vars [OK]

Common Mistakes:

• Using 'let' with weak
• Not making the type optional
• Placing 'weak' after 'var'

3. Consider the following Swift code snippet:

class Owner {
    var pet: Pet?
}

class Pet {
    weak var owner: Owner?
}

let owner = Owner()
let pet = Pet()
owner.pet = pet
pet.owner = owner

print(owner.pet!.owner! === owner)

What is the output of this code?

medium

A. nil

B. false

C. true

D. Compilation error

Solution

1. Step 1: Understand the references

   The Owner has a strong reference to Pet, and Pet has a weak reference back to Owner.

2. Step 2: Evaluate the print statement

   The expression owner.pet!.owner! === owner checks if the pet's owner is the same instance as owner. Since pet.owner weakly references owner, this is true.

3. Final Answer:

   true -> Option C

4. Quick Check:

   Weak reference points back correctly = true [OK]

Hint: Weak references still point to original object if alive [OK]

Common Mistakes:

• Thinking weak reference becomes nil immediately
• Confusing identity check with equality
• Expecting compilation error due to weak

4. Given the following code, why does it cause a strong reference cycle?

class A {
    var b: B?
}

class B {
    var a: A?
}

let a = A()
let b = B()
a.b = b
b.a = a

How can you fix this cycle?

medium

A. Change a in class B to a weak reference

B. Change b in class A to a weak reference

C. Make both references strong

D. Use unowned for both references

Solution

1. Step 1: Identify the cycle

   Class A holds a strong reference to B, and B holds a strong reference back to A, causing a cycle.

2. Step 2: Break the cycle with weak reference

   Changing the reference from B to A to weak var a: A? breaks the cycle because B no longer strongly owns A.

3. Final Answer:

   Change a in class B to a weak reference -> Option A

4. Quick Check:

   Break cycle by making one side weak = D [OK]

Hint: Make one side weak to break cycles [OK]

Common Mistakes:

• Making both references weak (loses ownership)
• Making the wrong reference weak
• Using unowned incorrectly causing crashes

5. You have two classes, Teacher and Student, where each Teacher has many Students and each Student has one Teacher. How should you declare the references to avoid strong reference cycles?

hard

A. Teacher holds weak references to Students; Student holds a strong reference to Teacher

B. Both hold weak references

C. Both hold strong references

D. Teacher holds strong references to Students; Student holds a weak reference to Teacher

Solution

1. Step 1: Analyze ownership

   A Teacher owns many Students, so it should hold strong references to them.

2. Step 2: Avoid cycle by weak reference

   Each Student should hold a weak reference back to its Teacher to avoid a strong cycle.

3. Final Answer:

   Teacher holds strong references to Students; Student holds a weak reference to Teacher -> Option D

4. Quick Check:

   Owner strong, back weak = B [OK]

Hint: Owner holds strong, back reference is weak [OK]

Common Mistakes:

• Making owner reference weak
• Making both references strong causing cycles
• Making both references weak losing ownership