It could cause an error. The way I handle it is this.
1) You have a UIImageView in the cell.
2) Assign it a "tag" that's unique. imageView.tag = <some unique id>
3) Since cells are re-used, you need reset the tag in prepareForReuse
and make sure to set it in the cellForIndexPath.
4) In the image cache, first check to see if the image exists there.
a) If not, then you go detach the thread to get the data. When it
comes back it puts the data back into the main cache.
b) If so, set the image
5) Look at the visible cells of the table and if any imageView has
your tag in it - set the image. If not, its in the cache for when the
cell comes back into view.
That's from the top of my head and I'm sure there are other ways that
are similar, but use different methods from the tag, but I like the
tag for this purpose.
On May 13, 2009, at 1:45 PM, Eric E. Dolecki wrote:
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/alex%40webis.net
This email sent to a...@webis.net
Alex Kac - President and Founder
Web Information Solutions, Inc.
"The optimist proclaims that we live in the best of all possible
worlds; and the pessimist fears this is true."
-- James Clabell
_______________________________________________
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
