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 re-invent the wheel or spend hours trying to create this functionality 4 weeks into my education here at the 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, and 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, which allows my tasks to re-categorize — or in this instance: re-prioritize.

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 so serve as a future reminder even after starting the said task. A handy feature would be to move the specific task object in my “starting tasks” list and move it 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. And 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 if 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/move, I also needed to remove a task from its source index row and section to its desired index row and section.

In english speak, it would go like this:

1) grab the current index path
2) create new index path using count of nextSectionArray and next section (currentIP.section +1)

3) store the specific task in a variable I want to pull out from the appropriate section arrays, and index row.

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 2)

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 fool-proofed for all scenarios, such as moving objects in arrays that are nil.