I am working on an app that displays a schedule. I have no problem displaying the lists of items. My question relates to displaying information on a new tableview that relates to the selection from the last tableview. All while not having to make several hundred tableviews (big list of info).
So in short how do I tell iPhone to remember what was just selected so it can display info from a database based on what was just selected?
Any ideas?
You save the selection, make your database call with whatever information you need from the selection. Then you update the table or whatever view you have to display the result of the database call.
If you give me more details about the structure and purpose of your application I can flesh out my answer if you need more help.
It sounds like your trying to store your data in the tableViewController. That's a big mistake. Your view controllers should only store temporary data needed for the immediate operation of the interface.
Instead, you need to create a data model that holds all your apps data. It can be something as simple as custom class with an array inside of it or as complicated as a large Core Data graph. Regardless of complexity, the key concept is that all the data is written two, logically processed inside and read out of the data model. No other part of the app directly manipulates the data. With this design, view controller do not have to be aware of each other. They simply ask the data model what information they need to display.
A key feature of a data model is that it has no awareness of how data received or how it is displayed or sent. A well constructed data model will work equally well with a GUI or a command line or any other human or computer interface.
In your case, you need to start by ignoring how the data will be displayed and instead ask what is the logical relationship inside the data that you need to display in two different tables.
For example, suppose your data is a simple list of names. The user needs to create a subset of that list and then perform some operation upon the subset. You would write you data model to store and return the list of names. Then you have a property for a sublist. Then you would have a method defined in the model that would transfer selected names from the list to the sublist.
In your UI, you would have one table whose controller would load the list into the table and would record which rows the user selected. Then the controller would call the data model method that moves the names into the sublist. The only thing that controller knows is how to ask for the list and how to tell the data model which names where chosen. It has no idea what other use will be made of the data.
The second controller only knows about the sublist property of the data model and how to tell the data model which name in the sublist the user selected. When it opens its tableview, it populates the table with the names in the sublist but has knowledge of what the other view did.
If you have a detail view, then the pattern repeats. The data model records what name has been selected by whatever interface. The detail view controller knows only how to ask for the data model for the selected name and any data attached to that.
This design makes each view controller independent of all the others. The view controllers do not even need to know the others even exist save for navigation.
This design makes the app modular and easy to maintain and extend. Your data is always in one place and has one object dedicated to guarding it and manipulating it. If something goes wrong with the data, you know exactly where to look.