Here’s one I didn’t expect. When a user has entered no records, and there is nothing to show in the inline list, then the Add button doesn’t show on the screen (nor do any of the other elements).
Here is the screen if I add a blank record using the data editor (obviously this isn’t optimal when adding new users).
From the user’s perspective, it’s true it’s a little annoying.
From the builder perspective – at least that’s how I see it – the tab in details style is sourced to a table and specifically to the 1st row of the table (EDIT: The 1st row downloaded to the user’s device, which might not technically be the very 1st row if row owners is set). If the table is empty, then the 1st row is empty, then components don’t display.
Another related aspect worth noting, and I don’t really understand it, is when the 1st is not empty but a lookup column returns something empty. I believe in this case (and maybe others), though the row isn’t empty, the display area sees the table as empty.
Well, so the way I worked around it is by setting the background table for the details screen to the users’s table and filtered by logged in user.
I would think components not tied to a record (like a button) should show in any case.
Definitely not intuitive.
For scenarios like this, I tend to create a single row table that acts as a driver for the tab. It gives the screen a row that it can attach to and you can place any additional columns related to that specific tab in that table.
I know some people will use the user profile table like you did, but then you are in the same position if you ever apply row owners to the user table and a user is not signed in. Probably not your case, but something to keep in mind.
For me, a separate driver table just works better in the long run. Also, if my Add Row button uses a custom form, then it’s really easy to use Show Detail Screen or Show New Screen actions against that same single row table, instead of cluttering up the user table with extra columns. And, as bonus benefit of using the Show Detail Screen action instead of the Show New Screen action for the custom form, the custom form can then be reused throughout the app because the layout becomes attached to the table via the details layout of that table.
I always have a single-row table (which I call a ‘control record’) where I put columns to define certain actions by client; so when I copy the app, I simply change the settings in that record to match the new client’s name and required behaviors. However, things that need to be set custom on a user level still need to be in the user’s record, and can be accessed from anywhere in the app. That is why I prefer the user table/row – and you are correct that my users always must log on.
what are the conditions for this floating button? it should show if you don’t have any
Just to further clarify what I’m getting at, let’s say I have 5 tables of multiple rows of data. In my app, I want to have 5 tabs at the bottom of the screen. Depending on the circumstances, I may create 5 additional single row work tables (for a total of 10 tables in my app). Those single row work tables will be the source tables for each of my tabs rather than the tables that contain the data. Each tab, they will have a details style layout with an inline list that refers to the real data tables. That way you never have a detail screen that’s unattached from a row.
These would be separate tables from your user table or control record table. The tables I’m talking about are simply to drive the tab itself and nothing more, unless you wanted to expand upon it and also use it for custom form values.
No conditions. And I agree - only the inline list should not show if there are no record. All other components without any visibility conditions should show (texts not tied to fields, buttons, other inline lists, etc.)
I understand what you’re getting at. That would be neat also if we could control things about the tabs using those single row tables – like the Icon / Visibility / Track clicks, etc.
