09-18-2010 03:04 PM
I'm writing a business data app which downloads a large XML (~1mb) each night. Its a summary of all applicable data from a DB. The user will be able to drill down through the XML do display a more detailed summary broken out by a dynamic set of factors. My question is where does application speed come in when dealing with a large screen stack? The screens have a title with the parent node's name attribute and all children are shown in a rich list with title, summary, and an icon to denote if this is the "bottom" node or if this node has child nodes that will push a new screen. It resembles the look of the new Social Feeds RSS app. Some "bottom" nodes will have buttons to view related summaries. A click-happy user has the potential to have 30+ screens in the stack. I want users to be able to use the esc button to go back one screen, recalling their original drill path, but I also don't want the application to appear sluggish when going back. What would be the best way to structure this? Does having that many screens up cause a huge drain on memory? Is there a trade off between speed and utility, like retaining only so many screens? It is written only for OS 6 devices since it's an internal app.