Just sharing my experience: I have something like 50 rows and 4 touch listeners per row. Performance is fine for that many rows at least.
I assume my listeners are cleaned up automatically, I have not noticed any leaks at least. But you got me a bit worried
IMHO its easier just to add a listener on an object instead of checking the location of the objects on touch. But in any case you can probably use a tableViewListener, I’m using that to detect sliding:
The performance shouldn’t be hurt at all. Given the following 100 rows, 4 touchable objects per row, I would assume that would me 4 functions total, one for each of the four touchable items. Functions take up very little in the way of memory, so no impact there (and you probably already have the code in place to handle the touches anyway, Next, handlers themselves are just a function pointer on the object itself. When a touch happens, we look to see if there is a display object where you touched and look up its touch handler if it has one and executes it.
Worst case scenario is trying to remove the touch handler (which doesn’t need to happen since you can’t interact with a touch handler on an object that’s offscreen or gone anyway and like I said, its just a pointer in the object itself) where it would have to iterate over a table looking for it’s signature (event type, function pointer). How long does it take to run this block of code (remember 400 total handlers in the table)
for i = 1, 400 do
if myEvent.function = listofhandlers[i].function and myEvent.type = listofhandlers[i].type then
table.remove(listofhandlers[i])
break
end
end
Probably would happen in less than a frame’s cycle of work. Adding the event just tacks it on the to the end of the table which is rather quick.
This is how Corona’s event system works. I like to say “Don’t fight the system” and trying to calculate a position in the row to figure out where your touching is going to be just as code/resource costly as doing the touch events.
