Hi all, sorry if the answer is easy but couldn’t find answer in the forum.
I’ve got two tabs, each with a single inline list. In each inline list, I want to create 50-100 identical screens and data (ex. list of products, list of people, list of cities, etc), each with identical inline lists as well.
How do I duplicate the initial screen and data in an inline list dozens of times?
Thanks in advance!
If I’m understanding correctly, you started using Independent Screen Configuration, which I didn’t think was a good fit for your use case. If you turn off independent screen configuration, the every item in the list will share the same details layout (which is tied to that particular table). If you leave Independent Screen Configuration turned on, then you will have to design each and every detail for each and every list item. There is no way to copy that same layout across all list items, unless you turn off the Independent option.
To get a better under understanding of what you are attempting to do, you may have to include some screenshots and describe your app flow.
Hi @Jeff_Hager thanks for your reply and for linking that other thread. Yes, you were right, it was the Independent screen configuration. And as I’m still fairly new to Glide, the process in which I’ve been learning Glide (other than you and the rest of the helpful community) has been to just tinker around with the tabs, screens, and data deleting something here and adding something there to see how everything connects to each other. So I forgot that I had deleted and added some fields in one screen vs another (doh!). Although I think I did figure out a workaround. Basically I can keep ISC off while I build out the basic structure of my 50-100 items in a new app, then once I’ve done as much as I can, then flip on ISC for each one. It might not be the most efficient way but for now, it’s a streamlined way to accomplish what I need.
Anyway thanks again for your assistance. Much appreciated
Just be aware that if the data for each list item is related, then it’s better to not use ISC. You wouldn’t want to have to go into the editor every time you add a new list item. It should automatically adapt to new data without having to edit the app every time.
Again, I don’t know anything about your app or flow, so I can only guess. Normally, ISC only makes sense if you have a handful of static list items that don’t change often…or ever. Usually it’s for driving a menu where each detail screen serves a completely different purpose from any of the other list items.
Just want to make sure you don’t spend a bunch of time designing screens independently, or going down a path that may bite you later…such as changing or adding one additional component and having to do it 100 times as opposed to only doing it once.
Thanks again for your help @Jeff_Hager I previously mentioned I owe you a beer, at this point I owe you a keg or a whole liquor store. Your comment above that I put in quotes is my use case as they all lead to a different, unique Calendly link, which will be tied to an attraction in each city. Last night, I actually spent several hours studying how you did your old app and your advice regarding using relations as I now understand that is the most efficient way. My initial shortcut strategy of leaving ISC off while setting up my list items, screens and data failed because once I turned it on, most of it disappeared. Luckily I only tested it on a few items vs 50-100 before realizing the error in my ways. Unfortunately I’ve got a meeting with a potential partner tomorrow so my Frankenstein prototype does work for now to showcase the potential and I can spend more time afterwards organizing it in a more efficient way after.
Yes, TOTALLY agree. That reality dawned on me yesterday. However, I will say, for a Glide noob such as myself, ISC did allow me to stay in a creative flow state along with my partner to flesh out our ideas of how it should look and feel. But the faster I can learn how to really use relations to accomplish similar results, the better.
Thanks!
Yeah, relations are your friend and will allow you to connect the details of one city, to related data in another table that only relates that that one city. Same with any links or calendly links. That should all be data driven. That way you design the details screen once and it pulls the proper data from that row or any relations to fill your components.
Thanks @Jeff_Hager Just to confirm, if set up correctly, would it be possible to have one tile layout go directly to another tile layout using relations? I think that’s where I got stuck last night as I was able to replicate your workflow, but setting it up as a tile layout was challenging. For example, in your sample app, I was able to convert the multi-select tables to tile layouts but the initial screen was a list from what I can remember?
Clicking on a list item will normally take you to the details layout of that list item. If you have a relation in that table, then you can add an inline list to the details screen and have it reference the relation. Tiles are no different from Cards or Lists, or any of the other Styles other than appearance and maybe some specific functionality for each one. Only the Details style is unique and points on only a single row, but there is nothing stopping you from adding inline lists on that details screen that uses the tiles style and points to other sheets. So to answer your question, yes you could in theory go from tiles to tiles to tiles indefinitely if you wanted to. The only time it gets tricky is when your relation points to the same table. Because of that I like to keep data separated if if serves a different purpose. Detail Layouts become tied to the table at any level below the top tab level or link to screen level.