New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement indexPathForObject: on NITableViewModel and NICollectionViewModel. #451

Merged
merged 2 commits into from Oct 21, 2013

Conversation

Projects
None yet
2 participants
@stephanemoore
Collaborator

stephanemoore commented Oct 12, 2013

Implement indexPathForObject: on NITableViewModel and NICollectionViewModel so that index paths of objects in the model can be retrieved outside of table/collection view cell interaction.

@stephanemoore

This comment has been minimized.

Show comment
Hide comment
@stephanemoore

stephanemoore Oct 12, 2013

Collaborator

For background:
I think there are legitimate cases where it would be useful if the table and collection view models implemented indexPathForObject:. Consider a contrived scenario with a cell containing two text fields that bring up a modal prompt when the user taps on them to edit; once the user dismisses the modal prompt we may wish to reload the particular index path of the cell to avoid reloading the entire table/collection view. In such a scenario the user interaction will not generate any events that identify the index path in the model that the user was interacting with; however, the cell is aware of the cell object that it was updated with and, with indexPathForObject:, should be able to determine the index path of itself. One could attempt to use -[UITableView indexPathForCell:] or -[UICollectionView indexPathForCell:] to ascertain the index paths but I do not consider those to be robust options. Thoughts?

Collaborator

stephanemoore commented Oct 12, 2013

For background:
I think there are legitimate cases where it would be useful if the table and collection view models implemented indexPathForObject:. Consider a contrived scenario with a cell containing two text fields that bring up a modal prompt when the user taps on them to edit; once the user dismisses the modal prompt we may wish to reload the particular index path of the cell to avoid reloading the entire table/collection view. In such a scenario the user interaction will not generate any events that identify the index path in the model that the user was interacting with; however, the cell is aware of the cell object that it was updated with and, with indexPathForObject:, should be able to determine the index path of itself. One could attempt to use -[UITableView indexPathForCell:] or -[UICollectionView indexPathForCell:] to ascertain the index paths but I do not consider those to be robust options. Thoughts?

@jverkoey

This comment has been minimized.

Show comment
Hide comment
@jverkoey

jverkoey Oct 12, 2013

Owner

This method is definitely implemented in more than a couple other places, so definitely agreed on the need for this functionality. Seems like a reasonable addition especially with the notes regarding the performance of this function :)

Owner

jverkoey commented Oct 12, 2013

This method is definitely implemented in more than a couple other places, so definitely agreed on the need for this functionality. Seems like a reasonable addition especially with the notes regarding the performance of this function :)

@@ -55,6 +55,9 @@
- (id)objectAtIndexPath:(NSIndexPath *)indexPath;
// This method is not appropriate for performance critical codepaths.
- (NSIndexPath *)indexPathForObject:(id)object;

This comment has been minimized.

@jverkoey

jverkoey Oct 13, 2013

Owner

Need function docs for docs.nimbuskit.info.

@jverkoey

jverkoey Oct 13, 2013

Owner

Need function docs for docs.nimbuskit.info.

This comment has been minimized.

@stephanemoore

stephanemoore Oct 14, 2013

Collaborator

New commit adds fn docs.
(wasn't sure if I should squash the commits or not)

@stephanemoore

stephanemoore Oct 14, 2013

Collaborator

New commit adds fn docs.
(wasn't sure if I should squash the commits or not)

@jverkoey

This comment has been minimized.

Show comment
Hide comment
@jverkoey

jverkoey Oct 15, 2013

Owner

LGTM!

Owner

jverkoey commented Oct 15, 2013

LGTM!

@stephanemoore

This comment has been minimized.

Show comment
Hide comment
@stephanemoore

stephanemoore Oct 16, 2013

Collaborator

Can haz merge?

Collaborator

stephanemoore commented Oct 16, 2013

Can haz merge?

@stephanemoore

This comment has been minimized.

Show comment
Hide comment
@stephanemoore

stephanemoore Oct 21, 2013

Collaborator

Harro?

Collaborator

stephanemoore commented Oct 21, 2013

Harro?

jverkoey added a commit that referenced this pull request Oct 21, 2013

Merge pull request #451 from jverkoey/indexPathForObject
Implement indexPathForObject: on NITableViewModel and NICollectionViewModel.

@jverkoey jverkoey merged commit f24179b into master Oct 21, 2013

@jverkoey

This comment has been minimized.

Show comment
Hide comment
@jverkoey

jverkoey Oct 21, 2013

Owner

Sorry that took so long! In the future if I LGTM like that and don't end up merging you can go ahead and merge it :)

Owner

jverkoey commented Oct 21, 2013

Sorry that took so long! In the future if I LGTM like that and don't end up merging you can go ahead and merge it :)

@jverkoey jverkoey deleted the indexPathForObject branch Oct 21, 2013

@stephanemoore

This comment has been minimized.

Show comment
Hide comment
@stephanemoore

stephanemoore Oct 21, 2013

Collaborator

Roger that!

Collaborator

stephanemoore commented Oct 21, 2013

Roger that!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment