-
-
Notifications
You must be signed in to change notification settings - Fork 669
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Android app crashes when Table contains too many cells #1392
Comments
Current Gtk and Cocoa implementations instantiate views only for the rows which are currently being displayed on screen. As the user scrolls through the table, they then reuse existing views (which scrolled out of view) after updating their content instead of creating new ones. This allows efficient resource usage and smooth performance even for a very large number of rows (~ 10,000). It looks like Android supports something similar with RecyclerView. Using it would require subclassing to implement our own "table row" class with swappable content. I think it should be possible to use this together with a |
Yes, RecyclerView should work: Currently, you can only implement subclasses in Android by extending the Android template. But @freakboy3742 does not like this approach, so we first need to extend rubicon.java so it supports subclassing |
An update on the current thinking about the Table widget: What is needed here is a completely different approach - one that leans into Toga's stated goal of providing platform-appropriate representations for data, not literal interpretations like the current Android table. "Excel-style" tabular data isn't something you see very often on phone apps. There's a very good reason the default Android (or iOS, for that matter) API doesn't have a "Table" widget, despite it being a very common desktop widget: traditional table presentation isn't a format well suited to the mobile form factor. So - we should take a different approach. Instead of trying to force a "traditional" table into the mobile experience, we should have a different way of presenting tabular data on mobile. The best candidate: a Detailed list with navigation pages. When you add a Table to your layout, you would get a scrollable DetailedList that displays the 2 columns of data from the table, plus (optimally) an icon. By default, the icon and "primary" title will be the first column, and the "secondary" title will be the second column; but this should be configurable on the Table widget to select any column as the source of the primary, secondary, and icon. When a user selects an item from the DetailedList, the app would navigate to a secondary page that shows all the detail from that line of the table. That navigation would have a "back" button in the header to go back to the previous page; any actions would also be exposed on the "detail" page (it may also be desirable to expose actions as swipe actions on the main DetailedList table view). The configuration of primary, secondary and icon would be ignored on desktop platforms, and only used on mobile platforms. This general approach would also allow the definition of Tree widgets - the same general approach would be used, but the navigation would be multiple pages, with each step in the navigation presenting an additional DetailedList of the sub-options, until you reach a leaf node in the tree. The use of primary/secondary/icon definitions would also allow for a Tree widget on Winforms. The current limitation there is that trees can only have 1 column of data on Winforms. A clearly defined "primary" would specify the column that will be visible from the data source. |
I converted my taApplister from using a tablebto using a DetailedList with secondary screen. This is the result: @freakboy3742 Is this what you had in mind? As for how to specify the columns for title and subtitle: Couldn't we just use the first and second accessor items? Then, by re-arranging the data and the accessors, the user could choose which colums to display in the DetailedList |
There's a couple of minor details I might quibble about (e.g., the OK button at the bottom, rather than a back navigation arrow in the top bar), but yes - that looks broadly like what I had in mind. As for what to display - yes, "first and second accessors" would definitely be a reasonable default. However, rearranging the columns won't always be viable - think of the case where on a macOS/GTK/Windows table, there's a column that makes the most sense as the last column, but it's important enough that it needs to be promoted to the subtitle for iOS/Android. My inclination is that Table would end up with a set of parameters to configure the title, subtitle and icon columns; these arguments would be ignored on desktop, but used to pick the appropriate column on mobile. This is essentially the same as what DetailedList does - pick which attributes of data will be used out of a data source - and should use the same format, if possible. |
Is there already an API to set a back navigation arrow in the top bar to the left of the title? |
There's no API for that; but adding a "NavigationView" to manage a "stack" of content is on the todo list - and would be the prerequisite for doing tree/table views on mobile. |
On Android, the app crashes when there is a Table that contains too many cells
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The code should check if the max amount of cells would be exceeded (how much is this??)
If yes, the table should not be created and
an exception should be raised (is that what we want?)
Logcat
Environment:
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: