So is it safe to approach threads like they were timers? You start a thread,
and it calls back to it's selector method when it's complete
(detachNewThreadSelector:toTarget:withObject)?
Now - what if a thread completes and the cell is currently out of view (it
was scrolled) - do the internals take care of that, or could it cause an
error?
On Wed, May 13, 2009 at 2:32 PM, Luke the Hiesterman <luket...@apple.com>wrote:
> It would be possible to implement one thread that would handle all image
> download requests, or you could just spin a new thread for each image
> download. The latter is simpler to code, so I'd lean toward that. There's a
> limit somewhere on the number of threads in one process, but it's unlikely
> you'll run into that limit, so I wouldn't worry about it.
>
> As far as relating threads back to a cell, you simply pass in a reference
> (pointer) to the cell as an argument when you start the thread, that way the
> thread knows what cell it's acting on.
>
> Luke
>
>
> On May 13, 2009, at 11:27 AM, Eric E. Dolecki wrote:
>
> 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/luketheh%40apple.com
>>
>> This email sent to luket...@apple.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
