views:

278

answers:

2

I'm going to do some sophisticated things in the delegate's methods during scrolling. I'll also implement the dynamic preloading of contents, so that it's theoretically possible to scroll through a few hundret thousand images. But I fear, that every time I do the preloading action for the next big chunk in scrolling direction, the delegate will wait for the data source to deliver the data, and the whole scroll view will be freezed for that moment.

The problem is, that I need always access to the subviews of the scroll view. I'm new to the platform and I don't know if I would still have access when I open up another thread for that preloading actions? Or would the scrollview not wait for the delegate to get things done?

I'm in the planing phase, so haven't implementet much jet.

+1  A: 

I don't have a specific answer, to your specific question. I just want to make sure you are aware of the ~25MB limit of RAM for your app. I can't give links on this, because even though Apple knows the limit, they aren't telling.

tmadsen
I know about that memory limit. That's why I only load the visible portion + some buffer portion during scrolling. As the user scrolls down, I release objects from the top, but recycle views. Analogical to that, for scrolling up.
Thanks
Apple doesn't "know the limit". It depends on what other apps are running—iPod, for example—and probably how fragmented system RAM is. There is no "hard" upper limit; if there were we'd just experiment and figure it out.
Adam Ernst
+3  A: 

You can only use UI classes from the main thread. So what you should do is to compute as much as possible in a background thread (I believe you can load your images in a background thread too), and then use performSelectorOnMainThread:withObject:waitUntilDone: to manipulate UI classes on the main thread.

See http://stackoverflow.com/questions/805410/how-do-i-update-the-ui-in-the-middle-of-this-thread for the another instance of your question

Andrey Tarantsov