I just tried rebuilding from scratch and I’ve imported/created/experiancing the same glitch.
I also went back to my original version and its doing it now. It wasn’t before. The spreadsheets stayed where they were put.
The original app was simply a list of 30 options with details under each heading for the category. Dividing them up into three was a new improvement.
I have to go to work now. I’ll check back later and have another go later today.
Thanks for reaching out. Im pretty depressed now after its been going so well. Learning all this from scratch in the last month has been a challenge and just when I thought I had a handle on it, it stumps me with something I just cant work around… Thanks again! 
When you select one of your collection item on your main screen, you view the Detail screen for that specific row. When you change the layout for that detail screen, it changes for all items. That is because Detail screens linked to their source table. Each of the three selections takes you to a row in the same table. Imagine if you had 10k rows in your main collection. Would you rather have to design 10k screens or design 1 screen. Hope that makes sense.
Now to solve your problem there are several approaches:
- You could have a custom workflow action that takes you to different New screens based on the collection item chosen.
- You could add several components to the same screen and conditionally show the appropriate one based on the chosen collection item.
- However, the best approach in my opinion is to create a relation from the main table to the sub table. This works best if all of your secondary data is in the same sub table.
The best approach depends on your data structure. We would need to have a better understanding of your data is structured.
If you have multiple sub tables and they all share a similar data structure, I would seriously consider merging the data into one table and add a category column. That will help in creating a relation from the main table to the sub table so you can use the third option, which would be easiest to maintain in the long run.
If you have separate sub tables and you prefer to stick with that, then I would consider the first and second options. The second one will be easier, but can get messy. The first option is easy too, but requires a better handle on workflows and how glide works in general.
3 Likes
Hey Jeff,
Thanks for the tips - most of what you are saying is going right over my head. Im sure I am building the worlds simplest app. This is a table version of what Im trying to achieve.
I have indeed build 30 pages/spreadsheets of separate info and uploaded every single one of them. Im not smart enough to use parts of spreadsheets yet. Literally every cell in this table is a separate spreadsheet. Thats cool. Im new so Im struggling to understand why changing one spreadsheet changes everything in that layer.
I can build my welcome/opening page - no problems. I can do quite fancy things (for my level of competanence) and am happy with what I have. As soon as I start loading the second level, every spreadsheet in that level becomes the lastest one uploaded. My original app that was 30 options with the rlelvant info worked well but I decided that it needed a better layout once I had the hang of how to build one of these things. When I started having issues with the new 3 level layout, I went back to the old one and the first layer stays but the second layer (and there’s only two) are now all the same spreadsheet. When I change the source document, it changes everything in that layer to it. Layer one stays the same always on all versions of this app. Ive made five in total now and they are all doing it.
Rereading your post, Im completly in the dark about workflows. Is that the missing ingrediant? My basic playing says that if I insert a collection of lists and then direct the source to be a certain completely independent table, then that should be all good. I can attached the right spread sheet to the right part of the table, my issue is that it doesn’t stay there…
That sounds concerning to me if it’s indeed 30 spreadsheets/tables. Wouldn’t it just need 3 tables? Or do you mean 30 rows on a certain table?
Yeah you are setting yourself up to require yourself
to design 30 different screens, instead of maybe 3 or so where the content is all data driven. Kind of a maintenance nightmare if you have to add new data or if you deside to change the look and feel of your app down the road.
Detail Screens are attached to their respective table by default (although you can use a Show New Screen action to get a new screen attached to the same table when necessary). Making your content data driven with relations linking respective data between tables will go a long way to making your app easier to maintain.
Like I mentioned before, detail screen layouts are attached to their respective table. Your top level screen should be sourced from a single table, and based on what you have described, I assume it is. When you view the details for any of those to level items, you are viewing the details for the specific row in that top level table. That detail screen layout is attached to that top level table, so the design of the detail screen is consistent and the same for each top level item you view. Again, imagine if you had 10k rows of items. Would you rather design 10k screens or just one…
You keep having problems because you set you layout for one of the items in that main table, then go changing it for the next item. All items share the same layout, so you are basically changing the same screen over and over. Ideally everything would be data driven and you data determines what is displayed on the screen.
I think one thing that may be tripping you up is that the old classic apps had the option of Independent screen configurations, which allowed you to have detail screens with independent designs if the option was selected. That option is no longer available as it probably wasn’t the best and slightly error prone, but there are other options today that I outlined in my previous post.
Really depends. I tend to avoid the workflow option if necessary, but it really depends on the case. I prefer to merger similar content, or in your case each layer, in single tables and then rely on relations to connect everything together. Others may rely on visibility conditions to control which content is displayed on the screen. If each item is drastically different, then workflows may be the best option. It really depends on the situation as there isn’t a one size fits all.
I think a data restructure is worth considering. Lets look at your table and kind of ignore Welcome and Learn More for now. Specifically, Experiences and Plan seem to be largely referring to locations. I think you could easily get away with 3 tables for all levels. For example, you may structure your tables like this.
Level 1
| RowID | Option |
|---|---|
| 1 | Experience |
| 2 | Plan |
Level 2
| RowID | Level1 ID | Option | Description |
|---|---|---|---|
| 1 | 1 | Waterfalls | A description describing this attraction |
| 2 | 1 | Walks | A description describing this attraction |
| 3 | 1 | Sunset Points | A description describing this attraction |
| 4 | 2 | Cafes | A description describing this attraction |
| 5 | 2 | Toilets | A description describing this very important necessity |
| 6 | 2 | Water | A description describing this very important necessity |
Level 3
| RowID | Level2 ID | Option | Image | Location |
|---|---|---|---|---|
| 1 | 1 | Waterfall1 |  |
over there |
| 2 | 1 | Waterfall2 |  |
near here |
| 3 | 2 | Walk1 |  |
the park |
| 4 | 3 | Walk2 |  |
the beach |
| 5 | 3 | Cafe1 |  |
in town |
| 6 | 2 | Cafe2 |  |
next town over |
| 7 | 3 | Toilet1 |  |
bathroom |
| 8 | 2 | Toilet2 |  |
outhouse out back |
Using the ID’s you can create relations from one table to the next. On each screen you can create a collection for the next level sourced from the relation.
As for Welcome and Learn More, they may require a slightly different approach or different tables, but your main top level screen could also have multiple collections or buttons or whatever you want. What I mean is that you could have one collection just filtered to show Welcome. Another to just show Experience and Plan. And one more just for Learn More. They could also be buttons or something else that is esthetically pleasing. Kind of up to you. If you do have 3 separate collections on the main screen, then you have the option of changing the click action on two of them to be ‘Show New Screen’ instead of ‘Show Detail Screen’. This would kind of give you an independent screen layout for the detail screen where you would design what is seen for the second level.
I think it just requires a bit of trial and error until you understand it.
2 Likes
Wow, lots to take in. Appreciate your detailed reply. This seems different from what the Glide videos say to do so it might take me a while to get my head around all this.
So,
I take all my data and create either a giant spreadsheet or maybe three…
And somehow, is there a way of simply using part of the data (selecting certain rows) to show on certain pages/levels? This is the bit I can’t get my head around. Say I put in a collection in the form of a list in layout on the left hand screen. What source am I getting it to draw from on the right hand side? How do I get it to show row 6,7 & 8 and nothing else?
My welcome page is simply some words and a photo with three options that tourists are always asking about: Where are the things we came to see? (these things are confusing and not where the signs say they are) Where are the things we didn’t think to bring? (water, food, loos, wifi) And what are those animals, stories, and murals about?
The app isn’t interactive. The idea is that you just download when you find a patch of Wi-fi and then be able to find things from the info provided.
I didn’t think it would be this complicated!
Thanks for your advice. I’m trying to make sense of it with app number 6 now! :))
Hi ThinDihn,
Maybe I do only need 3 spreadsheets or 30 rows on one spreadsheet, but I have no idea how to get the app to show certain lines of data in certain places. Can you describe how you would do it?
Do you mean that instead of 30 separate spreadsheets… I can still have all my items on one spreadsheet but each item in a separate TAB? Is that what Im missing?
I would recommend that you review the below section of the docs, including watching the video at the start. I think it might help.
1 Like
@Kara_Froggatt Talking about this video?
1 Like
OK, thank you both! Now Im getting some inkling - So I should make two spreadsheets? A parent spreadsheet with my three main categories (tourist needs) and then a separate one with all my children (attractions/info)?
In my child spreadsheet I make a new column that will attach each child to its parent
So in my child spreadsheet, I have
Waterfall, walks and lookouts have a column that has the data “Experience”
Water, toilets, and maps have a column that has the data “Planning”
Animals, murals and history have a column that has the data “Learn More”.
So far so good?
What is this column called?
Then I create my front page with my three options using the parent spreadsheet.
I open the Experiences part to create a list of experience choices.
How do I show only the columns with Experiances in them? or will that be obvious when I do this with the new spreadsheets?
From the choice of waterfalls in my first child layer I want to give detail about five of them - so a detail screen with five grandchildren (to continue the analogy) I also have five walks and more lookouts to give details on, all under Experiences.
The videos gloss over or move too fast for me to see how they are selecting the rows and not the whole spreadsheet. Is this one of the show visibility functions that I am yet to explore? Is there a video that shows this part in more detail?
Really appreciate waking up to new info and ideas this morning. I’m sorry I’m not picking it up very fast. Im an old lady who grew up with the only technology a black & white TV and a single phone attached to the wall! Thank you for your patience and continued support
1 Like
Trying to rephrase your notes and questions here and answer them.
- Parent and Child Spreadsheets:
- I should create two spreadsheets:
- A parent spreadsheet with my three main categories (Tourist Needs): Experience, Planning, and Learn More.
- A child spreadsheet with all the specific attractions/info (e.g., waterfalls, walks, toilets, animals, etc.).
- Linking Child to Parent:
- In the child spreadsheet, I’ll add a new column to connect each attraction to its parent category. For example:
- Waterfalls, walks, and lookouts will have a column with the value Experience.
- Water, toilets, and maps will have a column with the value Planning.
- Animals, murals, and history will have a column with the value Learn More.
- Question: What should I call this column?
- Front Page Setup:
- On the front page, I’ll use the parent spreadsheet to display the three main options (Experience, Planning, Learn More).
- When I click on Experience, it should show a list of related attractions (e.g., waterfalls, walks, lookouts).
- Question: How do I make sure only the Experience items are shown? Will this be automatic with the new setup?
- Adding Details (Grandchild Level):
- For each attraction (e.g., waterfalls), I want to add more details. For example, under Waterfalls, I’d like to provide details about five specific waterfalls.
- Similarly, I’ll add details for walks, lookouts, and other attractions under Experience.
- Selecting Rows vs. Whole Spreadsheet:
- In the videos, it’s hard to see how they select specific rows instead of the whole spreadsheet.
- Question: Is this done using a “show visibility” function? Is there a video that explains this part in more detail?
I would use the rowID from the Parent table here, not the bare value “Experience”, “Planning” or “Learn More”. This is because you might want to change the parent level names later, and by doing so you have to change the values in the child table as well to keep the relation. If you use a rowID, that takes care of itself.
I’ll just call it “Parent ID”.
It should be automatic once you create a relation from the parent table to the child table using Parent’s RowiD > Child’s Parent ID. Make it a multiple match, and use the relation for a collection component.
I would add a 3rd table for this and keep the same method of setup as above (Child ID as a column in the Grandchild level, multiple relation to connect).
Not sure what this is about and why you need it. Can you elaborate?
2 Likes
This appears to be the crucial part that has not been obvious to me so far in my journey. I understand completely that everything is data driven from a row of information. I have worked hard to make sure I have the right info in the right places but after a month of attempting to build this app - I have only just now become aware of this.
I’m now guessing this screen is the key to getting my app to do what I want it to.
Is there a video on how all this works? What is it called? What can you tell me about it that I should know at a super basic level - remember I’m not as tecnicomolgigal as you are!
My guess is that if I build a child spreadsheet of all 20 children options, link them to one of the three parents and then use this box to somehow say show “experiences” the app will then only show experiences children under the experiences button? Repeat at the next level to show only the grandchildren of the original parents. (The things in things video should go to the third level - it implies to the uninitiated that the principal will replicate in each level and it doesn’t. Its another concept entirely)
So
3 parents: Experiences/Plan & Learn More
20 Children: walks, tracks, toilets, cafes, murals, history
50 Grandchildren: individual walks, individual tracks, individual cafes individual etc
I am now also assuming that the individual waterfalls will be the children of waterfalls who are the children of experiences… and so on?
Can someone direct me to how to use this new-to-me part of the system please?
Really appreciate the time you are all taking to walk me through this. Ill be quite chuffed if I ever get to the end and get this working!
If you are relying on relations as the source of your child collection, then you don’t need a visibility condition.
Visibility will control the visibility of an entire component. Filters will control which content is displayed inside of a component, such as a collection. However, you shouldn’t need either because the collection should be sourced from the relation you have in the parent table.
When you click on a parent item to view it’s details, add a collection and source it from the relation you created in the parent table.
1 Like
Thanks, Jeff,
I’ll try to build it again this afternoon.
I still can’t see how adding a new column will make it work?
How does Glide know I want xyz falls under waterfalls under experiences?
Is the three-table thing right? Parents, children, grandchildren? I don’t want to build new spreadsheets if they arent what’s needed.
Then a new column in children and grandchildren that links to each parent using the row id (?) of the level/parent above?
Is there a video for this?
Thanks for replying so quickly!
Let’s not worry about the third level yet.
Glide knows because a relation in the parent table linking to the related items in the child table will only be populated with related child rows. Sourcing a collection from the relation will only show those related rows.
Should be, but like I said, just worry about the first parent to child first.
No it should be the other way around the relation column should be in the parent table linking to the child table.
Each child row should have the RowID of its respective parent.
2 Likes