Moving table view cells across sections in a to-do list app.

Over the past week, I’ve been working on a small to-do list app that categorizes your personal tasks based on type and category.

One of the bigger challenges I had while building my to-do list app was moving tasks around across different sections. And while Apple has its own proprietary method for managing and reordering its cells via an optional button, I wanted my cells to move based on button presses instead, specifically with the popular SWTableViewCell CocoaPod.

It’s amazing how much is available through CocoaPods and open source code in general. No need to reinvent the wheel or spend hours trying to create this functionality four weeks into my education here at Flatiron. All I had to do was install the pod, import the files into my program, and call the methods provided for me.

A couple days ago, I showed one of our instructors, Tom, my working (sort of) version of my to-do list. He suggested that since my tasks are sectioned off by their type or priority, it would be pretty neat to integrate up and down buttons in my left-swipe utility buttons. That would allow my tasks to recategorize—or in this instance, reprioritize.

For example, if I added a task to the start section such as “brainstorming killer app ideas with Team iOS 0615,” perhaps I’d like it to serve as a future reminder even after starting the task. A handy feature would be to move the specific task object in my “starting tasks” list over to the “continue tasks” list. Initially it seemed easy, but as I started working on the method responsible for button presses with the left swipe, my app kept crashing on button press.

Eventually, I realized I was spending all my efforts moving a cell around from section to section without ever updating my data model of arrays holding each and every specific type of task.

I create instances of category objects on a button press, and that will eventually be a specified property of a task object that gets instantiated on the “save” button press. After some team debugging with the great instructors at Flatiron, I was guided in the right direction to remedy the problem.

- (void)swipeableTableViewCell:(SWTableViewCell *)cell
didTriggerLeftUtilityButtonWithIndex:(NSInteger)index {
  switch (index);
}

The method above is for creating button actions based on the utility button pressed. I had to program not only for the table view cells to update on delete or move, I also needed to remove a task from its source index row and section and move it to its desired index row and section.

In English, it would go like this:

1. Grab the current index path.
2. Create a new index path using the count of nextSectionArray and the next section (currentIndexPath.section + 1).
3. Store the specific task I want to pull out of the appropriate section arrays and index row in a variable.
4. Remove the specific task from the original array.
5. Add the specific task to an array corresponding to the new index path created in step two.

In code:

NSIndexPath *currentIndexPath = [self.tableView indexPathForCell:cell];
NSIndexPath *desiredIndexPath = [NSIndexPath indexPathForRow:(nextSectionArray.count - 1)
                                                   inSection:(currentIndexPath.section + 1)];
 
NSMutableArray *thisSectionArray = self.dataStore.listOfSections[currentIndexPath.section];
NSMutableArray *nextSectionArray = self.dataStore.listOfSections[currentIndexPath.section + 1];
 
[thisSectionArray removeObject:taskToMove];
[nextSectionArray addObject:taskToMove];
 
[self.tableView reloadData];

And it worked! The task is now able to traverse through different sections—and not crash the app.

The lesson I got out of this specific problem was that if you’re planning to move things, particularly objects contained in different sections and nested in two-dimensional arrays, make sure your data models are updated and foolproof for all scenarios, such as moving objects in arrays that are nil.