MVVM: binding the View with the ViewModel with closures, unowned or weak self?

Question

I'm implementing a simple Master-Detail app where the Master viewController manages a table view which shows the results of a call to a REST service. The Detail viewController manages a view where I show more information about the item selected in the Master. Common scenario.

I'm trying to apply MVVM pattern. In the Master viewController, I create and initialize its viewModel this way:

lazy private var viewModel: ListViewModel = {
    return ListViewModel()
}()

override func viewDidLoad() {
    super.viewDidLoad()

    initViewModel()
}

private func initViewModel() {
    viewModel.onModelChange = { [weak self] () in
        DispatchQueue.main.async {
            self?.tableView.reloadData()
        }
    }

    viewModel.fetchData()
}

My question is: in the closure provided to the viewModel, should self be weak or unowned instead? I found an example implementing an scenario similar to mine that was setting it to weak, and another one setting it to unowned, so I'm not completely clear.

Your `viewModel` will never exist without the `self` (view controller). Thus, self will never be nil, you can safely use `unowned`. — Au Ris, May 20 '18 at 11:05

Tony Lin · Answer 1 · 2018-05-20T08:34:07.567

3

Unowned is used when you 100% sure the object won't be deallocated.

weak you then need to take care of its reference count issues.

viewModel.onModelChange = { [weak self] () in
    guard let strongSelf = self else { return }
    strongSelf.tableView.reloadData()
}

I generally do it like this. You then hold a strong reference of self to avoid it being allocated during the block is running.

edited May 20 '18 at 08:34

answered May 20 '18 at 08:26

Tony Lin

922
6
25

if you use [weak self], then self?.tableView.reloadData() is more enough – Moayad Al kouz May 20 '18 at 08:49
@MoayadAlkouz there will be a problem if you have multiple actions in the block. You never know when the self suddenly get niled. – Tony Lin May 20 '18 at 11:05

score 3 · Accepted Answer · answered May 20 '18 at 10:58

3

[unowned self]. This tells your model not to hold a strong reference to ViewController

Apple document states it clearly that:

“Like weak references, an unowned reference does not keep a strong hold on the instance it refers to. Unlike a weak reference, however, an unowned reference is assumed to always have a value”.

In your case, there is always be ViewController. So benefit of unowned reference is it’s nonoptional. No unwrap required each time it is used

answered May 20 '18 at 10:58

Abdelahad Darwish

5,969
1
17
35

1

Thanks. As said in a comment below my question also, I think that this would work for my particular scenario, since my "Master" view controller is the root one and its view model won't exist longer than itself. – AppsDev May 20 '18 at 11:39

score 2 · Answer 3 · answered May 20 '18 at 08:22

2

The difference between unowned and weak is that weak is declared as an Optional while unowned isn't. If you know that self will not be nil use unowned, if you don't know: Use weak

answered May 20 '18 at 08:22

barbarity

2,420
1
21
29

MVVM: binding the View with the ViewModel with closures, unowned or weak self?

3 Answers3