Agree. I had to use CSS to hide the back button and instead put in a Save button of sorts but even then users could start to edit the profile and then quit the app and their changes would save.
I’ve done the exact same thing, but now I’m trying to make a template — and can’t use CSS if I want it to be accepted. Hopefully the ability to edit from that screen is in the pipeline.
@shchc @Robert_Petitto I’ve started to do a lot of “custom forms” that use temporary columns. (It hasn’t been necessary, but I’ve been setting up these temp columns as user specific columns, because the icon is blue in the data editor and it makes it easier for me to tell that these are my temporary columns.) I’ve done these custom forms largely to avoid the weirdness of the form pop up modal with the android back button, and I prefer to use a floating form button as the submit, compared to the the default submit button at the top right of the screen. When going to this screen, I usually set up a combo action to first pre-fill any temp columns that need to be filled first (but can still be edited by the user), then execute the link to screen action to open the screen. You could do the same thing by duplicating all of the editable user profile columns to act as temporary columns, have an edit button with a set column action and a link to screen action, let the user make their changes, then have a save button with a set column action to write all of those temp column values back to the normal profile columns. One advantage of this is a little more flexibility in performing realtime calculations if needed, and along with the new hint component, the ability to set up more robust error checking of data. Yeah, you lose the ‘required’ field ability compared to a form or edit screen, but you can also hide or show the save button depending on if all requirements are met to submit/save.
One awesome advantage I discovered last night for my app is that I always had the need to save a Lesson Name. That lesson name also has an associated rate attached to it. Unfortunately, I had to get the rate through a relation once the form was submitted, but if that related rate would ever chang, then it would screw up any old lessons that were charged under the old rate. That’s because a choice component can’t write multiple values to multiple columns, so I had to either store the lesson name or rate. I chose name. Now with the solution above, I can use a relation against those temp columns in real time to always get the lesson rate once the lesson name is selected. This allows me to show the rate in real time before my “custom form” is submitted. This also allows me to have that date available to permanently write the Lesson Name as well as the Rate to the sheet through an Add Row action. Now I won’t have to use a relation to get the associated rate. It will be written and saved permanently.
In the end, this still gives users a chance to back out of any changes. They can skip hitting the Save action button and just got the back button without committing to any of the changes.
I do this all the time and never thought to do it with the user profile columns. Nice workaround!
Your last paragraph about lesson rates is something I just stumbled upon as well. Depending on the situation, you can eliminate array formulas via math columns of those temp columns and then writing them to the actual columns via add row.
These are really cool ideas… Going to have to do some playing!
Would definitely add a little efficiency to not have the app attempt to calculate every time the app is loaded. That’s my main goal right now. I have a lot of computed columns and large sets of data that are starting to slow loading times down. I’ve been trying to find new ways to streamline parts of my app because there are a lot of computed glide columns processing a lot of data and it takes a few seconds for that to happen when the app is opened initially.
That makes a lot of sense then in one of my apps. I have 12 Rollup columns over a few thousand rows and the app is VERY slow to open.
Yeah, it’s kind of weird, but makes sense at the same time. My app opens fine, because the first tab has minimal data. But the lessons tab is quite slow. My lessons sheet has about 3000 rows. Instead of pointing the lessons tab to the lessons sheet, I’m instead using the coaches sheet as the tab source, which is substantially smaller. I’m trying to experiment with having a relation that only displays today’s (or the most recent days) lessons. To do this, I need a relation from the coaches sheet to the lessons sheet based on coach email, then a rollup to get the latest lesson date, then a template to join coach-date, then another relation to join to an existing similar template in the lesson sheet. I also have a rollup to get a total count of lessons for the day. Ultimately it’s still really slow because the the initial relation to get the latest date still needs to process all of that lesson data, and at the same time, the computed columns in the lesson sheet must still be calculating. My big user has the 3000 rows. When she initially loads the screen, it first takes 5 to 10 seconds to open the tab, then when it opens, the total rollup count shows 3000+ for the count. A few seconds later, it updates with only the days count which is usually no more than 10. My only guess is that for a moment, the coach-date template columns only have the coach email in them, so the second relation finds all 3000 rows as a match. Once the coach-date templates update from a blank date to the latest date in the coaches sheet, and the lesson date in the lessons sheet, then the relation updates and the to only show the latest day’s lessons and the rollup shows the correct amount. It’s weird to explain, but seeing that makes me think that the computed columns only compute when they are needed, and then if you have a lot of them on a lot of data, it takes a few seconds to process. Once everything is loaded and computed in cache, then it seems to work just fine. It’s just the initial loading that’s slow. I’m trying to think of more efficient ways to handle this. One thing I’m on the fence on is using row owners, so I can do a rollup on the entire sheet instead of having to first create a relation based on coach email, followed by a rollup on that relation. Maybe it wouldn’t make a difference, but if it does make a difference, I’m still debating if I want to do that, because I’m trying to think of potential cases where I would want multiple coaches to see each other’s lessons if they teach the same student.
I really should just archive the old lesson data because it’s mostly from one coach over the course of 2 years and would help reduce data to speed things up, but on the other hand, it’s good test data to find ways to deal with this much data.
Nice, I’m a believer in having several paths lead to the same place (within reason). This makes the profile page less of a UX dead end.
That’s pretty much my standard MO, except for the bit about using a custom action to pre-fill temp fields. Hadn’t considered that - but will definitely be adopting it!
Hey all - am I the only one having this issue? I added multiple components to the user profile screen (just to see if one of them worked compared to the others) and they all end up at the bottom. I’ve verified this on an android device, an apple device and using an installed webapp (see below in white):
…the picture below is from the editor and the spacing appears normal. Am I doing something wrong here or is this a bug?
It appears to be a bug. Multiple users with same problem.
Try using the view details action. Link to screen is not workable. Using view details, you need to have tabs and I make those tabs hidden
That’s a great suggestion but I’m pretty sure that a new feature isn’t supposed to need a work-around…
So nobody has those issues?
If there is enough content to fill the screen, does it still push stuff to the bottom of the screen? You could probably add a rich text component full of empty characters at the end of the components list, so that it pushes everything back up.
As for the link to screen issue, is it changing the screen underneath the menu overlay modal?
Hey @Jeff_Hager - thank you for the suggestion. I tried adding rich text with a few rows of blank spaces but it didn’t move the text back up. I tried it with dashes (one per line, simply to create the needed spacing) and it worked! …until I needed to hide the component. The same with the Hint component. I added two of those and the spacing was perfect, both on the app AND in the tablet / desktop view. But, again, when I hid them, the spacing reverted back
Try using empty characters from https://emptycharacter.com/
Try copying the text in the gray box below. You can’t see it, but it’s full of empty characters followed by 2 spaces and a carriage return. I use this a lot for adding extra space at the bottom of a screen. Especially with floating buttons that can float on top of other content. Then you don’t have to hide the component. Browsers will usually render a bunch of spaces as one space, so it’s better to do it this way.
This is great Jeff - thank you! There’s still a little bit of wiggle room but the components are now all pushed up to the top of the screen!!