Bronze Challenge Chapter 9 - should I create two arrays?

Basically I´m setting the “section value” for the indexPath in the addNewItem function, and it is working for one section, but as soon as ramdomly a new section is needed I´m receiving this error:

attempt to insert row 1 into section 1, but there are only 1 rows in section 1 after the update

Then, I realized that “indexPath`s row” is not accordingly with the index section, now I´m wondering if I should create a two different arrays, one per each section, I thing that´s the easiest way to tackle this, but I don´t like it any way,

Any idea or improvement, you can check my code here: https://github.com/fbnxx/LootLogger-Challenges

The “two arrays” approach is what I wound up doing, but I didn’t really like it much either. If you imagine a more fully featured LootLogger where you can edit the values, it makes it awkward to have items separated into different arrays based on value. Change the value, and depending on what you change it to you might have to move the item to a different array, or you might not. It seems like a kludge, and not at all an elegant solution.

I ended up filtering the array by section before any operation, that way I always get the rigth index :slight_smile: I think it´s good for now.

moreThan50Section and otherSection are constants.

I thought about doing something like that, but because filter returns a new array I thought it wouldn’t work. I forgot that an array of class instances contains references to the instances, not the actual instances themselves, so the new array created by filter can be used to access the same Items as the original. I’ll have to update my implementation.

This will also make it fairly easy to do the bonus challenge to implement a filter button.

Thanks for posting that!

1 Like

Now I´m wondering what happend when reordering, because it`s possible to transfer from one section to another, I think it should be blocked that option, but well that is not part of the challenge, just in case, this is my reordering:

I did block moving items from one section to the other. It’s not mentioned in the challenge, but it seemed right to me to enforce the separation by value. Of course my original “two arrays” implementation made it necessary to block those moves, but when I update it I will continue to block moving between sections.

Am I missing something? I just added the following to itemStore to produce two sections:

@discardableResult func createItem() -> Item {
let newItem = Item(random: true)

    if newItem.valueInDollars > 50 {
        
        allItems[0].append(newItem)
    } else {
        allItems[1].append(newItem)
    }
    
    return newItem
}

And added this to itemsViewController to support two sections:

override func numberOfSections(in tableView: UITableView) -> Int {
return itemStore.allItems.count
}

let headerTitles = ["Expensive Items", "Cheap Items"]
   
override func tableView(_ tableView: UITableView, titleForHeaderInSection section: Int) -> String? {
    
       if section < headerTitles.count {
        
        return headerTitles[section]
       } else {
       
       return nil
       
       }
}

By the way I like blocking the ability to move between sections. I should add that to my Gold Challenge solution.

I migth be wrong, but I was trying to follow the MVC pattern, and I thougth that section is not part of the Model layer, let`s say that the info comes from a API, in that case we cannot alterate the Model even if we want it :stuck_out_tongue:

The view isn’t telling the model layer what the sections are, the controller is telling the view what the sections are based on the model layer data. I even created some new model layer code to hold information about the sections. I created a Section structure to hold the title, minimum value, and maximum value for a section, then created a SectionStore class to hold all the Sections (similar to the ItemStore class). The controller uses that info to make decisions about the data being provided to the view.

It’s the job of the model layer to hold whatever data needs to be held - you 're free to modify that as the program evolves & new data needs to be tracked (like sections).