Which takes more memory?

Discussion in 'iOS Programming' started by spinedoc77, Oct 19, 2011.

  1. spinedoc77 macrumors G3


    Jun 11, 2009
    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.
  2. mr.iso macrumors member

    Dec 29, 2003
    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.
  3. spinedoc77 thread starter macrumors G3


    Jun 11, 2009
    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.
  4. troop231 macrumors 603

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

Share This Page