What exactly is the job of NSIndexPath,
What I understand is, IndexPath variable is used to refer the cell which we want to display ?:o ?
But what value does it store ? I mean.,
What is the internal process that happen to setup an indexPath variable
It is used as a vector for referencing arrays within arrays. For example you can represent a path to array[a][b][c] using an IndexPath. Internally it is used for iPhone list views, for example a list view that allows you to select a country, then gives you an option of regions, followed by a list of cities in the said region. The indexpath to the city you selected would include the path to it through the country and region.
Specifically for UITableViews, NSIndexPath plays a slightly more expanded role. UIKit adds the row and section properties to an instance of NSIndexPath, and a class method + indexPathForRow:inSection:.
Therefore if you want to select or delete a specific row in a table, you would need to pass an instance of NSIndexPath to that table. To create that, you would use indexPathForRow:inSection to create an NSIndexPath instance.
If you have an existing NSIndexPath that you want to get info about and it's from a table view, then use its row and section properties to get the data.
If you encounter index paths outside of the table view, be careful regarding the specifics of its use. Either way, in general, it is a reference to a specific element in arrays of arrays.
In iOS the NSIndexPath objects are always of length 2. They're used for example to index a table view cell. The first index in a NSIndexPath object is called the section, the second is the row. An index path object with section 0 and row 0 indicates the first row in the first section.
Thats all you need to know when dealing with index paths on iOS.
Apple's class reference documentation is useful only for people who HAVE the mental model instantiated into their cognitive processes. When someone asks a question such as the original post, even if they are unable to fully articulate their confusion, the class reference documentation is some of the most wonderful non-information ever published. I too am struggling to figure out how---in the words of another SO answer---to fill in "// compute some index path" (knowing only an integer offset of the cell... I want to select my nth item), and am looking for the same level of conceptual overview as the original post, so I thought I'd explain the dilemma a bit.
I'm not 100% sure what you're asking, but there is more information here.
Related
I have an UITableView which includes a few cells with tasks (label). I also have an array of type string which includes a few tasks which are displayed in the tableView. Now I want to check if an string from the array matches with an string from any cell. If it matches I wanna find out the indexPath of the matching cell.
You're thinking about this wrong. You need to slap yourself on the side of the head and say Model-View-Controller loudly several times.
Cells don't have strings. They are just views. In a certain sense, cells don't even exist! That's a very real thing: in, say, a 100-row table, only about 12 cells may exist at any one time. So there are no cells to look in.
The strings are in your model, not your view. Stop thinking about the table and think about where the information about the data that goes into your table is stored. That is where you want to look for the string. And when you find it, you will know the index path, because that's how your model is structured.
In my app, I am using some .net asmx services (as backend) to get some data and populating it on my views. In one of the modules, i need to edit and save the data which am getting from the services.In that am getting several rowkeyvalues and accordingly am creating those many row cells in my tableview, which consists two UItextfields as well, which displays some unique code and comments.
Now if I have to edit and save some fields, I need to map each one of those rowkeys to each row cell and after that am creating object which is basically the wsdl proxy class which I have generated using Sudzc and pass each dataset and serialize it to XML and POST it through SOAP.
The real problem here, am not getting how to map each unique rowkeys to each row cell and create unique dataset(which mainly contains other fields as well including rowkey) for each row and pass it to proxy object (WSDL stubs).
Not sure I understand your problem, but there are 2 ways I can think of to map a row cell to something.
1. Each UITableViewCell is a subclass of UIView, and so it has a "tag" attribute, which is an int.
You can set this and check it's value.
2. When a user taps a row, the tableView:didSelectRowAtIndexPath: is called. IndexPath.row is an int that gives the absolute row postiion within it's section (and if only one section, then in the whole table).
Usually, in cellForRowAtIndexPath: you fetch your backing data corresponding to the IndexPath.row and populate the cell. You could also set the cell's tag at that point.
This ties together the row, the cell and the data.
Hope that helps.
-Mike
I have a tableView controller with two sections. The first section has a couple of input fields and is not really displaying core data. The second section displays items from a database saved with Core Data.
I have an NSFetchedResultsController and I serve up data for cellForRowAtIndexPath and didSelectRowAtIndexPath as follows. For section = 0, I manually serve up the appropriate input fields, and for section = 1 I want to use [fetchedResultsController objectAtIndexPath:indexPath]. () However, since the fetched results controller only knows about one section, this doesn't work.
I know I can create a new IndexPath with section = 0, and then feed that to the NSFetchedResultsController. Is that the preferred solution or is there another way to 'tell' the NSFetchedResultsController what to expect?
The only way to do this is to translate the NSIndexPath objects passed into the various UITableViewDataSource/UITableViewDelegate methods into index paths appropriate for your NSFetchedResultsController. I'd recommend adding a method to your class that does this.
The return values from this method will match the section numbers the NSFetchedResultsController uses. Also, if in the future you end up needing a second header section for whatever reason, it's easy enough to adjust your method to do that.
Why would you need to tell it anything? In the delegate methods, just offset the section index by one and you should be fine.
You can create your own NSIndexPath instance to pass into the NSFetchedResultsController to resolve this issue.
Update
If you want to have two sections then yes that is the right answer. However I would consider putting your input fields into the table header instead of a section. That would be a cleaner answer in my opinion.
I have a table where there will often be two cells with the same title. I'm zooming in on a map whenever a cell in the table is clicked, so using the title as a unique identifier is out of the question. I already have a unique identifier, but I need to find a way to store it in a UITableViewCell object.
I have been considering two options, both of which are poor, IMO.
1) store the unique ID as the text inside the text of the detailTextLabel property.
2) build a custom UITableViewCell class.
I'm new to objective C, and I would essentially like to know if theres a third option that isnt as inefficient as #1, but not as involved as #2.
Thanks
Use the cell's tag property (works only if your identifier is an integer).
That said, cells already have a unique identifier (albeit not necessarily constant) and that is their indexPath, i.e. their position in the table. You should generally not use the cells to store any data directly. Instead, store the data in a model object and maintain the connection between model data and view via the indexPath.
This is especially important when dealing with table views as cell views get reused or deallocated as soon as a cell is scrolled off the screen.
Is there a simple way to get array of all index paths for the cells in a UITableView?
Since you are the one that told the table view how many sections and rows per section you had, you can use that same data - or in fact even call the same methods on your data source to ask that question from elsewhere.