Hi, Do we have to have a warning about using deck view with no photos? I like to use deck view withhout photos as you can get so much info in a small space, ideal on the phone. Would also be very good if another line of data could be added to the view. Cheers.
@Lynn Hi Lynn, deck views were originally intended for displaying rows with images, which was why you saw the warning. However it’s true that as more use cases evolve, more people are using deck views for rows without photos.
Down with the warning! Down with the warning! … LOL
@praveen Re smooth scroll, when you just swing your finger, and watch all the data scroll by, it gets choppy and blank while it loads the new data anyway…
Also, Lynn has a valid point, and I would also love to use deck view for the more information, and probably access to the action bar… (Ideally I would love a tableview with an option to show an action bar… in which case the table view would be two lines high, showing some basic data and the action bar…
@Lynn I totally hijacked your thread!
The choppiness you see now on the table view is only on iOS in the app (but not on Mobile safari and not on Android). That is an artifact of an older embedded browser technology that iOS has. We need to migrate away from it to a newer tech they have, but that doesn’t yet support some offline features we need. Anyway, that is independent of this other issue.
All the same, I agree on adding more functionality for the deck view — it is probably the ideal/preferred view on a phone.
+1 to bring back some sort of long press accordion view
@Grant_Stead What’s long press accordion view anyways? Have you seen it in a Batman movie?! Or there is really such a thing in real world? LOL
lol, I’ve heard tale that a long time ago appsheet had a table view, and when you tapped on the row the item would expand to review more details about that record. I was thinking that it would be cool to have something like that tied to a long press. 1 tap, and you enter into the details view
like normal, long press and the item shows you just a few more details…
The problem with the long-press inline expansion was that it messed up the height of each row. As a result, it became impossible to do efficient smooth scrolling.
You guys probably don’t know this but if there is a table with 10,000 rows, we don’t actually render all of them. We only render what can fit on the screen, plus a little more — and then dynamically react to scrolling to render more. This requires very efficient cmputation of row height — i.e . it ony works if rows all have the same height. If they have variable height, then it becomes inefficient and scrolling becomes slow.
It was actually a feature I liked a lot and argued in favor of keeping. Maybe we should revisit.