I've just printed out the API docs on NSThread and need to start reading up
on it.
I assume that's the API I'd want to use. Now, does each image fetch need to
be it's own thread (I'm thinking yes). Is there a limit to how many can be
going at once? Is the iPhone multi-threaded? I have to figure out how to
relate each thread back to it's intended cell's UIImageView.image I guess.
Every time I do something new and cool with this table view, I find
something else I need to do - so this is pretty exciting and it's a good way
to learn core concepts as I learn all this stuff. Thanks all for the
feedback!!!
Now I have to try to figure out threads and how it relates to these cell
images...
E.
On Wed, May 13, 2009 at 2:19 PM, Bradley S. O'Hearne <
br...@bighillsoftware.com> wrote:
> Take heart, Eric. Threads aren't all that bad -- coding is simple, hardest
> part is debugging (should your code executing in the new thread is doing
> something unadvisable), but if you keep it simple, it should be fairly
> straightforward.
>
> Good luck,
>
> Brad
>
>
> On May 13, 2009, at 10:36 AM, Eric E. Dolecki wrote:
>
> I have zero experience with threads, and while that does sound good, I
>> don't
>> know how to do that yet.
>> Eric
>>
>> On Wed, May 13, 2009 at 1:06 PM, Alex Kac <a...@webis.net> wrote:
>>
>> To fix the stutter, use a blank image for when the image doesn't exist -
>>> do the NSData dataWithContentsOfURL in another thread so that when it
>>> finishes it posts a notification which then the cell will listen to and
>>> refresh with the data cached. Its a bit more involved and you have to do
>>> of
>>> course deal with threads, but its so much smoother.
>>>
>>>
>>> On May 13, 2009, at 8:23 AM, Eric E. Dolecki wrote:
>>>
>>> Thank you everyone!!!! I have this working (locally in memory anyway)...
>>> I
>>>
>>>> had to tweak the method a little bit...
>>>>
>>>> - (UIImage*)imageNamed:(NSString*)imageNamed cache:(BOOL)cache
>>>>
>>>> {
>>>>
>>>> UIImage* retImage = [staticImageDictionary objectForKey:imageNamed];
>>>>
>>>> if (retImage == nil)
>>>>
>>>> {
>>>>
>>>> // Since my images are not local, fetch externally
>>>>
>>>> //retImage = [UIImage imageWithContentsOfFile:[[NSBundle mainBundle]
>>>>
>>>>
>>>> pathForResource:imageNamed ofType:nil]];
>>>>
>>>> retImage = [UIImage imageWithData:[NSData dataWithContentsOfURL:[NSURL
>>>>
>>>> URLWithString:imageNamed]]];
>>>>
>>>> if (cache)
>>>>
>>>> {
>>>>
>>>> if (staticImageDictionary == nil)
>>>>
>>>> staticImageDictionary = [NSMutableDictionary new];
>>>>
>>>> [staticImageDictionary setObject:retImage forKey:imageNamed];
>>>>
>>>> }
>>>>
>>>> }
>>>>
>>>> return retImage;
>>>>
>>>> }
>>>>
>>>> And how I am calling it:
>>>>
>>>> UIImage *ret = [self imageNamed:tmp cache:YES];
>>>>
>>>> holder.image = ret;
>>>>
>>>> Seems like it's working pretty well. Although there will always be some
>>>> initial stutter on long lists in the table, at least once you've used it
>>>> a
>>>> little things smooth out. If I need to, I'll just use the file system or
>>>> a
>>>> db. Thanks for all of the help here, I really appreciate it!
>>>>
>>>> Eric
>>>>
>>>>
>>>> On Wed, May 13, 2009 at 12:58 AM, Michael Vannorsdel <
>>>> mikev...@gmail.com
>>>>
>>>>> wrote:
>>>>>
>>>>
>>>> The UIImage is the object (inherits from NSObject), so yes you'd pass
>>>> the
>>>>
>>>>> pointer to it as the dict's object. And objectForKey: will pass back
>>>>> that
>>>>> pointer to the UIImage again.
>>>>>
>>>>>
>>>>> On May 12, 2009, at 10:00 PM, Eric E. Dolecki wrote:
>>>>>
>>>>> I like the cache without writing to the disk (for now anyway).
>>>>>
>>>>>
>>>>>> When you say the image object itself, I don't know exactly what you
>>>>>> mean...
>>>>>> if it's just a pointer to UIImage then I think I do know. So I could
>>>>>> pair
>>>>>> the pointer with the URL key, is that right?
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>
>>>>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>>>>
>>>>> 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/edolecki%40gmail.com
>>>>>
>>>>> This email sent to edole...@gmail.com
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> http://ericd.net
>>>> Interactive design and development
>>>> _______________________________________________
>>>>
>>>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>>>
>>>> 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/alex%40webis.net
>>>>
>>>> This email sent to a...@webis.net
>>>>
>>>>
>>> Alex Kac - President and Founder
>>> Web Information Solutions, Inc.
>>>
>>> "Patience is the companion of wisdom."
>>> --Anonymous
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> http://ericd.net
>> Interactive design and development
>> _______________________________________________
>>
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>
>> 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/brado%40bighillsoftware.com
>>
>> This email sent to br...@bighillsoftware.com
>>
>
>
--
http://ericd.net
Interactive design and development
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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 arch...@mail-archive.com
