As i mentioned, you can't return zero in numberOfSectionsinTableView. You will get an exception
*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'numberOfSectionsInTableView: must return at least one section' When the data is not ready you still return 1, but return zero in numberofRows.. This seems to work at least... -mohan On Wed, Jan 14, 2009 at 1:03 PM, Luke the Hiesterman <[email protected]>wrote: > The way to invalidate data in the tableView when you free it would be to > reloadData. So, get rid of whatever you're getting rid of, build your new, > truncated list of items, and then call [tableView reloadData] so you put > only the data you've kept around in the table. Also, if you're worried about > a race condition, you could set a flag before you begin freeing things, so > that if any data is requested while you're in the process of freeing but you > haven't yet called reloadData, you will do the right thing. > > Luke > > > On Jan 14, 2009, at 12:57 PM, Mohan Parthasarathy wrote: > > Yes, that's what i meant. Just to confirm.. It is safe to assume that > numberOfSectionsInTableView will be first function called ? I am thinking of > this sequence.. > > 1) The code receives low memory warning and frees up the data that the > tableView is currently displaying > 2) CellForRowAtIndexPath is called now for Nth Row. > > (2) in my code would reference the data that has been freed in step (1). Is > it possible to invalidate the tableView Data also while freeing memory at > step (1) ? > > thanks > mohan > > > On Wed, Jan 14, 2009 at 12:32 PM, Luke the Hiesterman > <[email protected]>wrote: > >> I assume you meant numberOfSectionsInTableView:....anyway, a good strategy >> might be to just go ahead and return 0 initially, and then whenever you have >> successfully pulled your data from the network, do [tableView reloadData] >> and then you can return the appropriate numbers at that time, since they >> will be ready. >> >> Luke >> >> >> On Jan 14, 2009, at 12:24 PM, Mohan Parthasarathy wrote: >> >> Hi, >>> >>> I am using a UITableViewController and the data for the table view is >>> generated dynamically (fetched from the network). The data is normally >>> fetched based on some search. But when the Controller is loaded and i >>> don't >>> have the data ready, i want to return something back sane and later >>> reload >>> the data when it becomes ready. What is the best way to do this ? >>> >>> -numberOfSectionsinRow : Is it safe to assume that this function is >>> called >>> always *first* before constructing the table ? At least i want to be able >>> to >>> initiate the fetch (if it is not already done before) here. >>> -As i can't return 0 for numberOfSectionsInRow, i still have to return 1 >>> there and in numberOfRowsInSection, return zero till the data becomes >>> available >>> >>> The problem is that i need to initiate the fetch somewhere during the >>> table >>> construction and i don't want to put hooks into all of the tableView >>> delegate methods. As the data for the tableview is dynamic, i need to >>> tell >>> the framework not to call the other delegate methods till i return >>> something >>> valid in numberOfSectionsInRow/numberOfRowsInSection. Is this a safe >>> assumption ? >>> >>> thanks >>> mohan >>> _______________________________________________ >>> >>> Cocoa-dev mailing list ([email protected]) >>> >>> Please do not post admin requests or moderator comments to the list. >>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com >>> >>> Help/Unsubscribe/Update your Subscription: >>> http://lists.apple.com/mailman/options/cocoa-dev/luketheh%40apple.com >>> >>> This email sent to [email protected] >>> >> >> > > _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
