Questions regarding UITableView, MVC, Design Patterns etc

Disclaimer: I’m coming from the Android ( :astonished: ) world where we use an MVVM architecture and rely pretty heavily on a Unidirectional Data Flow (UDF) pattern.

In doing this chapter and the challenges and working with TableView, there’s a few things that seem kind of odd to me coming from that world … For example, take the controller method that is called when the Add button is clicked:

    func addNewItem(_ sender: UIButton) {
        let newItem = itemStore.createItem()
        if let index = itemStore.allItems.firstIndex(of: newItem) {
            let indexPath = IndexPath(row: index, section: 0)
            tableView.insertRows(at: [indexPath], with: .automatic)


Here, two things are happening … First, a new item is added to the underlying data store. Second, we add a new row to the TableView … When I was first doing this, it raised a :triangular_flag_on_post: … I have to remember to keep the view (the UITableView) in sync with the data source myself. Put more abstractly: If the data source changes, then I have to remember to also change the view to match. This is a bit different from what I’m used to. In the Android/UDF world, we would never update one view component (add a new row to a TableView) in the event handler of another component (the IBAction of the Add Button’s click event). Over time this becomes very difficult to maintain, as more and more elements fire more and more events that are handled, and keeping track of how, when, and where ui updates are happening becomes a tangled mess. Instead the event (in this case a button click) would just result in an update to the data layer (here, the ItemStore), and in response, the new/updated data would then flow back down to the view (probably via some sort of observable stream like Rx, or I think Apple has a new thing called Combine?), and then the view would react to receiving the new data by updating it’s display to match.

Is the UDF pattern used regularly in the iOS/MVC world, or is there some other pattern that is used to manage the flow of events and data?

I realize that this is probably a much more advanced topic, and not really the intention of this chapter. But I was curious about how it works (at least at a high level), “in the real world”.

What you raise are all good points.

However, BNR books are not really designed to teach how to reduce or eliminate the direct dependencies between components in a program. Their books primarily focus on introducing the reader to the UI components so that they learn how to use those components in the shortest time possible.

It is up to the readers to explore advanced techniques, such as those you mention, and decide whether those techniques are worth incorporating into the programs they create.

But there is also this: I predict that, when the subject of writing energy-efficient programs becomes a hot topic, a thin layer of code that looks messy but that does the job accurately and reliably using the least amount of energy will no longer be frowned upon. :slight_smile: :slight_smile: :slight_smile: