@primoz That would be really awesome if you found a clean way to do this…and if your solution is low impact to the existing code, perhaps we could get CL to merge your improvement back into the master branch…
@primoz - indeed it would be much better to implement this capability in the widget code itself. For me, what I shared above was an exercise in Corona SDK programming and an attempt to make do with what we have today. I would love to see a solution implemented inside the widget. Look forward to seeing your mods if you share them here. Maybe we can work together and make it G2 ready. Thanks!!!
Just to clarify the G1 widgets I made were made because of issues I had with the existing widgets. The table view however did not have the functionality discussed here. I was just stating that in G1 a lot of properties and objects were accessible and could be manipulated without modifying the widget source code. I have seen that some things are no longer accessible in G2 so they have either been hidden or moved. Due to this I don’t know if it can be done outside the widget source so it might be better to add the functionality in the widget source itself.
I will take a look at it and see what I can come up with.
Stay tuned.
This is what I came up with without changing the widget source.
I have modified your test project.
It needs to be generalized and isolated into a separate module.
Will add the transitions later.
WARNING! This kind of coding is very susceptible to changes in the underlying library. Therefore I strongly suggest keeping the tableView.lua source included in your project to make sure it doesn’t break in the next build. It would actually be wise to include the widget.lua as well as it gets called from the tableView. It works with the current version though so you may remove it and change the tableView.new back to widget.newTableView but you have been warned.
Updated on page 2
@primoz - thank you so much for your contribution!!! This is exactly what I was hoping for when I started this thread. That other devs would jump in, improve code and show us all better ways to achieve results. I think we all need more threads like this one. Thank you very much. Will checkout your version right away. Have a good weekend.
Erm, Sorry to say but your version also seems to be affected by the Corona SDK bug that I was talking about above. The one that leaves gaps when you do multiple row deletes. See attached screenshot. Hopefully Corona Labs will fix this bug soon so we can get this thing going again.
Thanks for your effort in any case.
Are you deleting lines in code or did you get this just by opening and closing categories?
As I’ve said the tableView source has not been changed so any bugs that are in it are still there you should delete rows differently to avoid the bug. You can check the code where I close a category and see how. You can take that code and make a row delete function or fix it tableView source. I will try to fix it post the updated version with transitions. There was also a bug in my code which I missed the first time. Update soon.
It seems to me the best approach would be to fix the tableView and make it possible to change the row height at runtime. Deleting/adding rows will probably be always subject to flickering, also management of the IDs in master-detail views will be fairly complicated
I was thinking about that, but that would mean you would have to insert another tableview for the details or handle detail lines by yourself which I don’t think is very good. I have tracked down the delete row bug in managed in such a way that it should not flicker as I am not deleting all the rows just the rows that need to be deleted and inserting the details on expand in the right position. I am close but I still have some issues I have to sort out.
Update.
Fixed the multiple row delete bug (in tableView source) fixed some bugs and added transitions.
Play with it to see if you find any strange behavior or bugs.
Most grids have onExpand, onCollapse events - you can use to display details, but also info cards, charts. My comment was more in the general direction of the tableView. In any case - if you make it work nicely by deleting /inserting rows that would be great too.
Yup. I was just opening & closing categories.
The issue with the multiple tableView:deleteRow() calls causing this gap in tableView display is directly caused by the inefficient way tableView:deleteRow() is currently coded. First off it is applying the transition.to off to left to the row being deleted. Not everyone will want their rows to go off to the left, some might prefer transition up, right or just go pooff etc. So I think if I was re-writing the tableView:deleteRow() method I would make the transition style optional & selectable.
Secondly it is going through a rigorous for loop going through all remaining rows of the tableView and moving them up by one. The onScreen rows are moved visually and offscreen ones are moved in terms of indexes. There has to be a better way of doing this. New inserts are handled very nicely with the lazy loading. We need something along the same lines
Lastly, when you call multiple tableView:deleteRow()s in a close progression, this fires off multiple instances of this method running in an asynchronous manner. Since they don’t watch out for each other and yet they use same internal variables you end up getting the gap in the middle issue. If you delay your tableView:deleteRow() calls by as little as 400 milliseconds the issue goes away but deleting rows one after the other with a time delay in between gives you a huge eye-sore.
Anyways, I’m totally on board with Atanas’s suggestion. While we can make do somehow with a makeshift collapse/expand solution for now this would ideally be implemented right inside the widget. To do that the widget also needs to recognize the Category rows and the child rows under them in relation with the category rows a little different than it is now. Right now there is no relationship at all.
While I’m typing I see there are new posts and an updated sample. Thanks much for that. I’ll go and give it a spin and see how it looks now. Appreciate all your insight and input.
@primoz, it is looking much better! I took a quick look at your tableView fix and it seems like you have targeted exactly what I was talking about. Will give this a bigger shakedown later in the day with more records. Thanks much for your contribution.
Yes the bug was due to multiple transitions running on the same rows that were supposed to move up.
See how quick it was for you to fix it yet the official fix will probably take another couple months to arrive if at all… 
Thanks so much!
What no bugs or issues? 
Looked great when I tried it shortly. I will try it with ~ 500 records sometime later this week. Thanks much for your help.
Let me know if you need assistance or you need this to be put in a separate module includable module.
Will do. Thank you very much for the offer. For the time being this was just an experiment in UI design. Not using the collapsing tableView in an app for real but will definitely consider it now that we have a viable sample.
thank you that’s what i’m looking for