Well, I'm in early stages of design. Just playing around, no specification yet, so I'm not too worried. I'm throwing ideas around.
Well I'm trying to do the same thing here. I store the rule for expansion of dates, let's say: repeats weekly, tuesdays and thursdays, starts on date x, ends never, etc... Since I'm not storing every instance, it's impossible and impractical, there is an infinity, I need to "expand" these dates to show as table cells when needed... Anyway, I thought it through again and it really isn't that impractical, because, let's say I have twenty different repeating events that never end. There will be periodicity when they occur and I won't need to recalculate the number of rows for each section. Sorry. On Thu, Dec 17, 2009 at 10:47 PM, Luke Hiesterman <[email protected]>wrote: > It sounds like you have a design problem if you want potentially large > numbers of sections but it isn't easy to calculate the size of said > sections. What are you really trying to do? > > Luke > > Sent from my iPhone. > > > On Dec 17, 2009, at 8:01 PM, Karolis Ramanauskas <[email protected]> > wrote: > > Luke helped me with this a little bit, but, after experimenting, it seams >> there is more to it. >> >> I guess there is still something I do not understand about this. Yes, I >> can >> set a huge number of rows. But I want them to be grouped into sections. >> However, UITableView wants to know exactly how many rows are in each >> section >> on load time, even for invisible sections. So, if I have a rule that >> describes recurring events in my model, that means I would have to expand >> these and calculate, number of rows per section on load. If I have, let's >> say, 10,000 sections (to imitate the never-ending list) this may be a >> costly >> calculation. I assume there is no way around this, but limiting the number >> of sections to a lot lower numbers... >> >> Peace. >> _______________________________________________ >> >> 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]
