Sounds to me like you might want to rethink your design. You haven't
told me what you're trying to achieve with all your timers, but if
you're updating some value in the cell based on its timer, why not
have just one timer that updates all the values?
If the timer is specific to its very own table view cell, you might
not have to worry about cells going out of scope: you could just
subclass the UITableViewCell and invalidate the timer in the
prepareForReuse method.
Best,
Hank
On Sep 16, 2009, at 10:44 PM, Luther Baker wrote:
Thank you Hank .... that is just what I needed to see. I must've
glossed over the docs you reference below.
But something just occurred to me with respect to your point
regarding UITableViewCells, userinfo and NSIndexPath. If I associate
an NSIndexPath* with a timer and I insert 10 timers - each into the
top position of a UITableView; then at each insert, all previous
NSTimers.userInfo.nsIndexPath values become incorrect. In fact,
every timer will have an NSIndexPath with row=0 & section=0 if I'm
inserting them all into the top. The problem is that userInfo
properties will be static while the underlying rows in the table can
keep changing.
And, if, on insert, a UITableView simply bitblts the cells shifting
down ... I'm not sure I'll get a chance to update the timers with
their new NSIndexPath?
Is there a class or delegate method that gets invoked for every
visible cell when the cell's shift down? I need to store something
in userInfo that tells me or helps me definitively find the correct
Cell to update ...
Thanks,
-Luther
On Wed, Sep 16, 2009 at 8:08 PM, Hank Heijink (Mailinglists) <hank.l...@runbox.com
> wrote:
On Sep 16, 2009, at 8:24 PM, Luther Baker wrote:
I'd like to fire a simple callback every .1 of second (yes, my
stopwatch
style app). But in that callback, I need access to a corresponding
UITableViewCell. Unfortunately, I don't see a way to choose a
selector with
a UITableViewCell argument for the oneliner:
[NSTimer scheduledTimerWithTimeInterval:<#(NSTimeInterval)ti#>
target:<#(id)aTarget#> selector:<#(SEL)aSelector#> userInfo:<#(id)
userInfo#>
repeats:<#(BOOL)yesOrNo#>
Yep, that's what the userInfo parameter is for. It's an id, so you
can pass your UITableViewCell there, and get it back in the method
you pass in the selector argument by calling the -userInfo method on
the NSTimer instance (see below).
[...snip approach using NSInvocation...]
but this approach requires roughly 7 extra lines of code every time I
configure a cell for display (creating things like NSMethodSignature,
NSInvocation, setters, etc). It isn't enormous but suddenly, my
generally
small cellForRowAtIndexPath is getting pretty long. I'm wondering if I
should be careful. Things like scrolling etc might blast through
this and
I'd prefer to keep the method fairly light if, there was in fact a
way to
use the simpler one liner to invoke a callback with an arg.
Passing UITableViewCells around is risky business: if the cell
scrolls off the screen, you're pointing to a cell in the reuse pool
(provided you stick to the standard paradigm), which will most
likely lead to trouble, depending on what you're doing. You might be
better off passing an NSIndexPath, and then asking for -[UITableView
cellForRowAtIndexPath:], which will return nil if the cell is not
visible.
Again. I certainly appreciate any informal feedback/suggestions. Maybe
userInfo would apply for what I'm doing here? I thought userInfo
would be
stored in the NSTimer and unfortunately, the single callback that
everything
is firing to doesn't take the NSTimer as an arg so I think that
means I'd be
tracking NSTimers external to the callback loop ... and I'd just
rather
avoid that.
Are you sure your method has the right signature? If you pass a
selector that doesn't accept arguments, everything will work, but
see the following from the documentation of NSTimer:
The selector must have the following signature:
- (void)timerFireMethod:(NSTimer*)theTimer
The timer passes itself as the argument to this method.
Hope this helps,
Hank
_______________________________________________
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
