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
_______________________________________________
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
