iOS Which takes more memory?

[spinedoc77]

My program currently has a list of items in a table which expand to a detailed view. It's not a huge list, about 20-50 items currently which expand to a detailed view with a couple of text paragraphs and a small image on each.

I'm trying it 2 ways and was curious which of these 2 ways would be more efficient. In the first way I'm just saving the information to arrays into a table, then I'm linking each row when pressed to a new view, the only issue with this is I'm having to make a lot of views.

The other way I've been trying is making a plist file and having nested tables, the issue so far is that the 2nd nested table gives me a small cell to put my information in, I'm sure there is a way to expand the cell to fill the screen size but I haven't gotten there yet, it's also a bit unwieldy to manage the information in the plist file.

I haven't gotten into storing data yet, eg coredata or sql, and it's a simple enough program where I don't think I'll need it yet so I was kind of avoiding that. My concern currently is memory footprint, I didn't know if having so many views would eat up memory, or does only the current view take up memory? I would much prefer the mutliple views way as it's easier to set up, but there is more to manage.

 

[mr.iso]

I'd go with the first option. Creating views isn't anything you should worry about.

What you're describing sounds like you're using a UINavigationView, in that case, when you pop the view off the stack to go back to the tableview, that memory is released.

Don't alloc/init all those detail views upfront though, that is a huge waste of cycles and memory. Only alloc/init the relevant detail view when the cell is pressed, then push it on the stack, and don't to forget to release it after the push unless you're using a method that returns an autoreleased object.

If you do it this way, only one detail view will ever be in memory at a time.

 

[spinedoc77]

Thanks. I actually spent the evening investing into doing it from plists, it just seemed like a lot less code to write and a lot less views clogging up my project.

Does anyone know when to start to worry that the plist is getting too large? I know I'm going to have to start digging into coredata sometime soon, but I'm hoping to hold it off a bit longer as I learn all the other stuff. So far I've got about 50 dictionaries in my plist, each one holds 3 strings and 1 image, the strings can be several paragraphs of text each.

 

[troop231]

Thanks. I actually spent the evening investing into doing it from plists, it just seemed like a lot less code to write and a lot less views clogging up my project.

Does anyone know when to start to worry that the plist is getting too large? I know I'm going to have to start digging into coredata sometime soon, but I'm hoping to hold it off a bit longer as I learn all the other stuff. So far I've got about 50 dictionaries in my plist, each one holds 3 strings and 1 image, the strings can be several paragraphs of text each.

In one of my apps I have a plist with over 800 rows in it, and it holds up just fine