How do I architect an iOS app when multiple view models must know when the model has changed?

Question

I'm using MVVM and I have an app with a UITabBarController, the Main tab of which is a list of publications and the other is a Search screen where they can search for publications. Searching returns a list of publications.

Imagine that Publication A is the first item in the list on the Main tab. Now let's say the user goes to the Search tab, performs a search, and Publication A is in the search results. If the user taps Publication A, it will be marked as read and shaded certain color in the search results list. If the user goes back to the Main tab, Publication A should also be shaded to indicate it has been read.

There are plenty of MVVM tutorials on the subject but they all seem to assume one Model, one View, and one ViewModel. I believe what I need is to understand how to wire up a single Model to two Views, and two ViewModels. I have found several threads here in Software Engineering (like this one) but no real guidance or answers.

Can somebody please point me in the right direction? Thanks.

Answer 1

One way to do what you want is to post a notification when the model changes. Any ViewModel that wants to know about the change can listen for the notification and update when it is received.

Answer 2

You can save id and read-status in a file and check that anytime you want to sync. Don't forget to update the list from anywhere.

Answer 3

You can achieve this in many ways. For example:

- Reference types

• You can use reference types (aka class). Reference type objects are single objects when you pass them around. So if you overwrite them properly as you fetch them again and again from server, you good to go.

- Local Cache

• You can use a local cache system. (like core data). So you will build a mini database on the app locally and instead of just communicating with server, you will synchronizing your local storage with the data you send to and you fetch from the server. Some of them could be some information that you don't send to server at all. So the flow will be:

  • Send to/Fetch from server

  • Update local storage

  • Update UI from local storage (NOT Server Data) anytime local storage changed or any other time needed.

• As @The Rock mentioned, you can cache only tiny data you needed. For this case, you just need the id of the Publication and read status. So any time you want to show read status of a publication, just check that if it's id is exist in the readArray you saved earlier in some file.

- Observer pattern

• As @user1118321 mentioned, you can apply Observer Design Pattern. So anytime read status changes, you will just post a notification containing the id of the publication (and new status if needed). So anyone observing on the id can be notified and do needed actions.

- Singleton pattern

• You can use Singleton pattern witch creates a shared object once and only once and whenever you try to access that or initialize one, it will be the exact same object. So it's variables stays same in all places you call it. But using singleton has it's own downsides like any other programming pattern and must be cared.

There are some other standard and creative ways you can do to achieve this but these are the most known and straightforward methods.

Remember you can apply multiple of these methods at the same time if you need some more extra functionalities.

Hope it helps.