iOS GROUPED TableViews + other questions.

[wizard]

Hi Guys;

First let me say I'm new here so I hope not to offend.

1st.
With the current publicly available SDK is there a way to use plist data to directly build an app that uses Grouped TableViews? I've put together a relatively simple App based on the drilldown example which worked really well. Unfortunately what I realized it that at least one view would be much nicer in the form of a Grouped TableView. So i'm wondering if there is an example floating about that is as straight forward as the drilldown is for simple TableViews?

2nd.
If that is the not the case, is the next rev of the SDK addressing this? That is a facility/technique that works like simple drilldown but optimized for grouped tableviews?

3rd.
If all the above are negative anybody have any suggestions with respect to producing a Grouped table driven from a plist file? The App I'm concerned with right now makes use of a large plist filed with static data. Since I only scrapped the original code Sunday night I've only played with a couple of ideas. One largely based on some of Apples other sample code.

Thanks
Dave

 

[PhoneyDeveloper]

I'm not really sure what you're asking. Depending on what's in your plist file it could be very simple to build a grouped tableview that displays the data. I'm not aware of any examples for this.

Are you planning on displaying static data or will the contents of the plist change?

I have built my own data structure which is basically an array of arrays of dictionaries that is displayed in a grouped tableview. It could be written out to a plist but that's not how my app works. It does drill down but not really based on the data in the data structure.

Each dictionary represents a row. Its parent array represents a section. And the parent array of that represents the whole tableview.

The array of arrays of dictionaries makes the display code for the tableview very simple.

 

[Niiro13]

Yes. In fact, I looked at the SQLite example and it gave me a headache. So I always use plists instead. Seems to work fine even with tons of data. This includes from plain tableviews to grouped to dynamic data to static data.

 

[wizard]

Maybe I can clear things up a bit

Sorry about the long delay but the only reliable net access I have right now is my iPhone or the library. I'm at the library right now as I wasn't going ot respond to this on iPhone

I'm not really sure what you're asking. Depending on what's in your plist file it could be very simple to build a grouped tableview that displays the data. I'm not aware of any examples for this.

Examples or approaches are what I was looking for. Fortunately I've come up with a workable solution for the data I'm working with. Works OK even if there is more overhead than I'd like. I was able to deal with some corner cases earlier to day that results in the code not crashing anymore. Unfortunately the problem with the code was in the behavior of some of Apples code, sometimes you get silent failures and some times you get exceptions.

Are you planning on displaying static data or will the contents of the plist change?

At this time static data. I have ideas floating about for many small utilities that would be of a reference type suitable for engineers, technicians and trades peoples. So I'm looking for a general solution that I can leverage across a number of apps. Basically I'm just adding data to the dictionaries that currently have my data in them to identify groups and data elements for specific groups.

For the current data set it seems to work well, on the simulator, but I do have concerns about performance on a real device. The primary concern is that the current table view calls to get sections, headers and rows are call more often than I would have imagined. Right now I filter the listContent every time. But hey made a lot of progress since the original posting.

I have built my own data structure which is basically an array of arrays of dictionaries that is displayed in a grouped tableview. It could be written out to a plist but that's not how my app works. It does drill down but not really based on the data in the data structure.

Right now I have a Python script that massages my data into a plist. This is actually great as I've been able to try out a couple of approaches. Right now the Python is a hack but the goal is to make it a general solution for generating Grouped Table View data.

Each dictionary represents a row. Its parent array represents a section. And the parent array of that represents the whole tableview.

Interesting. That unfortunately is far from the approach I've taken. My dictionaries have a key identifying its type. So when the Table View needs to know "numberOfRowsInSection" in section I scan through a derived array of listContent and look for dicts marked with the row information for the section in question.

The array of arrays of dictionaries makes the display code for the tableview very simple.

Sounds good but is it flexible? That is what I'm looking for. That is minimizing changes to code while at the same time providing flexibility. I actually was trying to implement an Array of Array approach but was having difficulty mapping the approach on to a plist. That could have been a mental block night but this approach gelled real quick.

Here is an approach I've taken:

-(NSString *)tableView:(UITableView *)tableView titleForHeaderInSection:(NSInteger)section
{
    NSMutableString *headerString = [NSMutableString stringWithString:@""];
    NSMutableArray *returnStringArray = [NSMutableArray arrayWithCapacity:6];
    NSEnumerator *enumerator = [listContent objectEnumerator];
    NSDictionary *temp = [NSDictionary dictionary];
    //id temp;
    while (temp = [enumerator nextObject])
    {
        if (temp != [NSNull null])
        {
            NSMutableString *typeString = [temp objectForKey:@"type"];
            if ( [typeString isEqualToString: @"GroupSpecifier"])
            {
                headerString = [temp objectForKey:@"title"];
                [returnStringArray addObject:headerString];
            }
        }  
    }
    if ([returnStringArray count] <=1)
    {
        return nil;
    }
    else
    {
        return [returnStringArray objectAtIndex:section];  
    }

}

Hopefully that renders right. This obviously digs out the Header text for each marked dictionary marked as a GroupSpecifier. What it does is simply makes use of the drill down example but in my case the the Level3ViewController is the final level. At least for this app idea it is.

Dave

 

[hchung]

If you're going to be doing a reference app, you're going to have a pretty big plist I imagine.

I highly suggest that you use SQLite or maybe your own flat file format in order to store your data since it would be less likely to run you out of memory than NSDictionary's dictionaryWithContentsOfFile:, which I'm guessing you're using for plists?

 

[PhoneyDeveloper]

Sounds like you have plists on the brain. You would be better off writing your code so that it can use any backing store format, plist or sqlite db. If you have a DataSource class that returns the data in the format that your tableview wants it then you can write a PlistDataSource and a SQLiteDataSource class that can be used interchangeably.

Any data that you're storing in a plist can just as easily be stored in a sqlite db and it will be simple to write code to import from one to the other. If you've got more than a few hundred rows of data then sqlite will give better performance. If it's fewer rows than that it probably doesn't matter.

Here's my titleForHeaderInSection method. I store the title in the first dictionary in the array of arrays of dictionaries.

- (NSString *)tableView:(UITableView *)aTableView titleForHeaderInSection:(NSInteger)section 
{
	// ok to return nil for header section
	NSArray*	sectionArray = [mSectionsList objectAtIndex:section];
	NSString*	title = [[sectionArray objectAtIndex:0] objectForKey:kSectionTitleKey];

	return title;
}

Also, I think your method could be significantly shortened if you use [NSArray valueForKey].

 

[wizard]

Sounds like you have plists on the brain.

Yes probably true but for this app plist are all I need.

You would be better off writing your code so that it can use any backing store format, plist or sqlite db. If you have a DataSource class that returns the data in the format that your tableview wants it then you can write a PlistDataSource and a SQLiteDataSource class that can be used interchangeably.

For future projects that may be the case. Right now I'm not dealing with a lot of data. Further the data is static and there is no intention to change, sort or do anything with the presentation.

Any data that you're storing in a plist can just as easily be stored in a sqlite db and it will be simple to write code to import from one to the other. If you've got more than a few hundred rows of data then sqlite will give better performance. If it's fewer rows than that it probably doesn't matter.

I'm pretty sure I'm Ok. Everything i've done so far has been on the simulator so I can only guess about the performance.

Here's my titleForHeaderInSection method. I store the title in the first dictionary in the array of arrays of dictionaries.

- (NSString *)tableView:(UITableView *)aTableView titleForHeaderInSection:(NSInteger)section 
{
	// ok to return nil for header section
	NSArray*	sectionArray = [mSectionsList objectAtIndex:section];
	NSString*	title = [[sectionArray objectAtIndex:0] objectForKey:kSectionTitleKey];

	return title;
}

Also, I think your method could be significantly shortened if you use [NSArray valueForKey].

Thanks for whacking me over the head, one glance and all sorts of light bulbs popped on in my mind. So Again thanks!

I was able to restructure my data, in the plist, to support this real quick. I'm not sure why I had the brain fart about the original structure of the plist but that has disappeared. Also the array of arrays approach really does make things a lot simpler.

Now all I need to do is find more time to work on this stuff!

Thanks
Dave

 

[thelarry867539]

Example?

Could someone please provide and example file, I find that is the easiest way to learn.

I would greatly appreciate it.

Thank you,
Eric C.