Is this possible with the 2.0 tableView widget? Because I couldn’t find anything about it in the docs and it seems a bit unnecessary to have to use the animation when deleting the row?
Thanks
Is this possible with the 2.0 tableView widget? Because I couldn’t find anything about it in the docs and it seems a bit unnecessary to have to use the animation when deleting the row?
Thanks
Not possible in its current iteration. I agree with you in that it would be great to be able to control the animation direction or turn it off entirely.
I think this is required. Animation that can’t be control is annoying.
Not possible in its current iteration. I agree with you in that it would be great to be able to control the animation direction or turn it off entirely.
I think this is required. Animation that can’t be control is annoying.
Is this still not possible? Would be great if the animation is not obligatory but rather optional, if even present - because you can handle the animation yourself if that is what you prefer by animating the row left prior to deleting it. Doesn’t make sense to let it be obligatory.
This is one of those things thats “Nice to have”. Our widgets are there to provide basic functionality. We open sourced them so that if you want something beyond basic functionality you can add it yourself.
Rob
No… This is one of those things that would be “Nice not to have”… I don’t know who requested having an animation every time you delete a row, but for us who don’t want it we are now stuck with an obligatory animation regardless of what we want to achieve, with no way of opting out. The most logical thing would be NOT to have an animation, and if someone ever wanted an animation they could just do it themselves manually with transitions and onComplete listeners, just like all the other tableViews we’ve seen in the past. Having an obligatory animation that doesn’t even fit your app regardless of what you want to do makes no sense.
I did look at the open source version but it is 1 years old… That would mean having to deal with 1 years of bugfixes that have since actually been fixed.
Edit: Btw just adding this option to the widgets isn’t that much to ask for… It’s just 10 minutes of work and it’ll do the world for tableView users… Just loop the animation in an if and add a flag to deleteRow or something… Or please update the widget github repo so we can do it ourselves, although I think that update might take a little longer than just updating the code in the lib.
The last update to the widget library was on June 17. https://github.com/coronalabs/framework-widget
The other option is to file a feature request at and get it voted up. If there is sufficient interest then engineering will consider it.
I just looked at the source. The transition is going to be required because you have to collapse up the space. The transitions do not specify a time, so it’s defaulting to 500ms. They also have an easing on them. I’ll ask, but no promises.
Rob
That would be great. It would be perfect if the collapse could be done without animations and a delays as it’s annoying to have to endure the delays and animations if you don’t want them. The collapse could just be done immediately without the use of transitions and then whoever wants to animate them upwards could just apply a transition.from on all the visible rows from y=row.y+rowheight or something and the same effect could be accomplished without compromising it for everyone else.
Problem with feature requests and downloading the lib separately is we’d have to update the lib from there on out forever and wouldn’t be able to use the quick fixes added in the dailies and whatnot, and the feature request we both know a detail like this would never get enough upvotes to grab the engineers’ attention. So if just a quick fix for this could be added in the pre-included widget lib it would be awesome.
Thanks for the quick responses Rob really appreciate it!
Edit: Just as a pointer the collapse done in the previous widget 1.0 library was done without transitions and whenever we want to add an effect to the deletions and collapses and whatnots we just do it ourselves using transitions and animations and it makes things much easier and convenient and much more dynamic to do whatever concepts you choose. It makes the tableView much much more versatile and configurable.
Is this still not possible? Would be great if the animation is not obligatory but rather optional, if even present - because you can handle the animation yourself if that is what you prefer by animating the row left prior to deleting it. Doesn’t make sense to let it be obligatory.
This is one of those things thats “Nice to have”. Our widgets are there to provide basic functionality. We open sourced them so that if you want something beyond basic functionality you can add it yourself.
Rob
No… This is one of those things that would be “Nice not to have”… I don’t know who requested having an animation every time you delete a row, but for us who don’t want it we are now stuck with an obligatory animation regardless of what we want to achieve, with no way of opting out. The most logical thing would be NOT to have an animation, and if someone ever wanted an animation they could just do it themselves manually with transitions and onComplete listeners, just like all the other tableViews we’ve seen in the past. Having an obligatory animation that doesn’t even fit your app regardless of what you want to do makes no sense.
I did look at the open source version but it is 1 years old… That would mean having to deal with 1 years of bugfixes that have since actually been fixed.
Edit: Btw just adding this option to the widgets isn’t that much to ask for… It’s just 10 minutes of work and it’ll do the world for tableView users… Just loop the animation in an if and add a flag to deleteRow or something… Or please update the widget github repo so we can do it ourselves, although I think that update might take a little longer than just updating the code in the lib.
The last update to the widget library was on June 17. https://github.com/coronalabs/framework-widget
The other option is to file a feature request at and get it voted up. If there is sufficient interest then engineering will consider it.
I just looked at the source. The transition is going to be required because you have to collapse up the space. The transitions do not specify a time, so it’s defaulting to 500ms. They also have an easing on them. I’ll ask, but no promises.
Rob
That would be great. It would be perfect if the collapse could be done without animations and a delays as it’s annoying to have to endure the delays and animations if you don’t want them. The collapse could just be done immediately without the use of transitions and then whoever wants to animate them upwards could just apply a transition.from on all the visible rows from y=row.y+rowheight or something and the same effect could be accomplished without compromising it for everyone else.
Problem with feature requests and downloading the lib separately is we’d have to update the lib from there on out forever and wouldn’t be able to use the quick fixes added in the dailies and whatnot, and the feature request we both know a detail like this would never get enough upvotes to grab the engineers’ attention. So if just a quick fix for this could be added in the pre-included widget lib it would be awesome.
Thanks for the quick responses Rob really appreciate it!
Edit: Just as a pointer the collapse done in the previous widget 1.0 library was done without transitions and whenever we want to add an effect to the deletions and collapses and whatnots we just do it ourselves using transitions and animations and it makes things much easier and convenient and much more dynamic to do whatever concepts you choose. It makes the tableView much much more versatile and configurable.
Folks: I just ran into this today while deleting rows from a TableView and was surprised to see that there’s no way to remove the horizontal animation. Of course you can delete all rows and re-render, but then you get a bad case of the flickers.
It looks like the horizontal animation is at line 1320 of this file: https://github.com/coronalabs/framework-widget/blob/master/widgetLibrary/widget_tableview.lua#L1707
transition.to( self.\_rows[rowIndex].\_view, { x = - ( self.\_rows[rowIndex].\_view.contentWidth \* 0.5 ), transition = easing.inQuad, onComplete = removeRow } )
Can Corona make it is possible to pass a parameter to the transition to specify a time and override the 500ms default?
I’m not being lazy here: I could trivially change the above file. But if I go that path I’m going to be out of sync with bug fixes in the daily builds – there were a dozen fixes to scrollview and tableview on 10/29, for instance, but the repository wasn’t updated until 11/25…
Hi corona273@,
Let me put in a request for this. For clarity, this would likely need to be a boolean passed along with “deleteRow()”? Or would a more ideal solution be to provide a number (integer) for the transition time (with 0 being, of course, no animation)?
http://docs.coronalabs.com/api/type/TableViewWidget/deleteRow.html
Brent
Brent: Thanks again for your help with these points. I don’t speak for <ksan> and <skatan> and the other developers in this thread, but either would work for me; I simply want to turn off any animation and have the rows be deleted immediately.
So I prefer whichever solution leads to a quicker fix in a daily build! If both approaches are equally speedy, then providing an integer for the transition time with 0 being no animation seems preferable. Thanks again!
Hi @corona273,
The engineers report that this feature is already done, internally, and it will be released in an upcoming daily build. I’m not sure exactly when, but hopefully not too far off. The concept will be that you can pass a table of options to the row deletion API with various parameters that allow behavior control.
Brent
Hey Brent! Thanks tons for that. I think the best would be to be able to choose the animation time, since that would provide even more customisation for whoever isn’t satisfied with the default animation speed to be able to tweak it and make it faster/slower depending on what they want, or remove it of course altogether
Thanks again!!
Edit: Ah just saw your reply. That solution sounds even better. Can’t wait to try it out!