target and proposed destination path

[gamemasta0]

I love what you have done so far, but I have a tableview that has sections and rows that I do not want a cell to move to. To solve this problem in the normal implementation of a UITableView move I would implement: - (NSIndexPath *)tableView:(UITableView *)tableView targetIndexPathForMoveFromRowAtIndexPath:(NSIndexPath *)sourceIndexPath toProposedIndexPath:(NSIndexPath *)proposedDestinationIndexPath;
There doesn't seem to be any way to rule out index paths in your current implementation and I tried looking to see where I would do it but a lot of your code is beyond my experience with objective-c. Any pointers as to how I would implement this? Or perhaps you could implement it. But until then, unfortunately, I cannot use this beautiful implementation of moving rows.

[shusta]

I didn't want to support that targetIndexPathBlahBlah method because it had the potential to be, well, arbitrarily complicated. For example, I haven't a clue how I would handle something like

return [NSIndexPath indexPathForRow:( proposedDestinationIndexPath.row % 3 ) inSection:0];

But what are you trying to do? There are a couple of common scenarios that I might be able to add. Like a keepWithinSection flag to prevent dragging from one section to another. Or a -dragDelegate:canDragRowFromSourceIndexPath:toDestinationIndexPath: delegate method (return YES if allowed to move there). Would either be useful?

[gamemasta0]

I would think both could be useful but more useful in my case would be -dragDelegate:canDragRowFromSourceIndexPath:toDestinationIndexPath:
It would accomplish just what I need. Essentially, my situation is: I have an array of items in section 0 with an additional cell to add to the array. and then other sections that cannot be edited but contain relevant information. That is why I want to restrict movement to indexpaths only to section 0 and a row less than the end of the array.

[shusta]

(Now that I think about it a bit more, the real problem with -targetIndexPath is that it redirects drag destinations. That's what makes it tricky.)

Sure I could probably add a -canDragRowFromSourceIndexPath:toDestinationIndexPath: delegate method. I don't have time to write it immediately but I'll take a crack at it when my workload lightens a bit.

[gamemasta0]

Alright, well thank you and I look forward to the update whenever it arrives

[jklundell]

A workaround that I'm contemplating: in keepDraggedCellVisible, I thought I might add an optional delegate call that would return a value to override the default contentRect. Not as convenient as canDrag..., but not too hard to implement, and fully general as long as the permitted target area is contiguous.

Following up. I moved contentRect to its own function, and subclassed it. Worked fine.

[shusta]

UITableView's content rect? I'm not clear what you mean.

-- Daniel Shusta

On Jul 1, 2012, at 1:23 AM, Jonathan Lundell reply@reply.github.com wrote:

A workaround that I'm contemplating: in keepDraggedCellVisible, I thought I might add an optional delegate call that would return a value to override the default contentRect. Not as convenient as canDrag..., but not too hard to implement, and fully general as long as the permitted target area is contiguous.

Following up. I moved contentRect to its own function, and subclassed it. Worked fine.

---

Reply to this email directly or view it on GitHub:
#1 (comment)

[jklundell]

I wasn't very clear. In keepDraggedCellVisible, a local variable contentRect is set to the tableview's content. I changed that to call a function that returns that value. So there's no functional change, except that the subclass can override that function and restrict the move to a subset of the tableview.

It's not a completely general solution. It works for me because the tableview I care about is always completely visible (no scrolling), and I can simply return the rect of the section that I'm restricting the move to.

[timothyarmes]

The fix to this issue seems trivial - I've just submitted a pull request that seems to we working perfectly to me.

[jklundell]

I ran into a crash with the latest version (23 August 2012). I have a two-section table: data in section 0, and a cell with a + in section 1 that invokes an add-entry sequence. When the user drags a data cell to section 1 (which I don't want to support), we get a crash. The reason: the dragged cell is deleted from section 0 of the table, but the datasource doesn't agree.

The fix was straightforward. No doubt it could be cleaner, but I wanted minimal intrusion for now. We let the delegate veto (by replacement or veto) cells in the covered-cells array.

- (void)shuffleCellsOutOfWayOfDraggedCellIfNeeded {
    /*
        This used to be easy until we started dealing with variable row sizes.

        Now we compare the dragged cell's center with the center of the whole covered rect to determine whether to shuffle.
     */
    NSArray *arrayOfCoveredIndexPaths = [self.tableView indexPathsForRowsInRect:self.draggedCell.frame];
/// PATCH BEGIN
    if ([self.tableView.delegate respondsToSelector:@selector(tableView:targetIndexPathForMoveFromRowAtIndexPath:toProposedIndexPath:)]) {
        NSMutableArray *newArrayOfCoveredIndexPaths = [NSMutableArray array];
        for (NSIndexPath *indexPath in arrayOfCoveredIndexPaths) {
            NSIndexPath *newIndexPath = [self.tableView.delegate tableView:self.tableView targetIndexPathForMoveFromRowAtIndexPath:self.indexPathBelowDraggedCell toProposedIndexPath:indexPath];
            if (newIndexPath)
                [newArrayOfCoveredIndexPaths addObject:newIndexPath];
        }
        arrayOfCoveredIndexPaths = newArrayOfCoveredIndexPaths;
    }
/// PATCH END

Please apply.