@J805 Thanks for the info. I just tried your tip but unfortunately, I still have the problem with my specific project. Do you have any other ideas? What would be an example of if I have something overlapping?
@J805 Thanks Jason. I Tried adjusting the page height but still no luck. When you say “one group on top of the other instead of below each other” could you clarify what that would look like? I have attached an image of how my groups are set in my elements tree.
If you could share the editor with me then I can have a better look. Send me a PM to get my email that you can add as a collaborator so I can take a quick look.
Ok, here you go. Check out this screen shot. Right now you have overlapping elements, what you need is to stack them on top of each other instead. See image attached:
You can also show and hide each element with set states, I didn’t check to see if you were doing that or not yet. No need to “show this” and “hide this”.
That works! OMG THANK YOU SO MUCH! Seriously can’t say enough how much I appreciate it. I may need to hit you up on some of your No Code Training soon. Thanks again. Wow thank you.
@zachenson I am also working on a mobile app project and was curious about what values you ended up setting the main index width & height to? Seems like multiple people are using all kinds of different combinations. Also, in my app, I have almost 10+ screens that are triggered by setting a custom state. My app looks like your original setup in your first post before it was refactored into the stacking method mentioned by @J805. All of my elements are overlapped also. The active state makes that view visible. If I followed the above recommendations would I just have 1 giant index page with every element stacked?
Yup. Basically you would have a very long page. It won’t look long to the user if you have everything set to collapse when hidden and nothing is overlapping.
Hi @zacharyreed I ended up going to 320px wide and the height does not matter. I use a system where I have master groups that are subject to the page. Any time I need a new master group thats significantly longer or shorter than my existing, I add it to the bottom and extend total page height. It’s a bit of a bummer because any floating elements anchored to the bottom I have to move every time I extend the page. Aside from that though it works great. We use 320px wide to account for iPhone 5’s and then our design ratios are based off of https://material.io . I was initially building to 390px wide and found it screwed a lot of stuff up. I am working on adding a system now for a desktop app where when the screen gets wider than an iPad a left anchored floating group appears and our bottom menu goes away.
We also built the app for the app stores and I initially used a wrapper but now am considering rebuilding the app features with BDK Native.
Feel free to check out our app at https://c19so.com (Currently you need to view it from a mobile device though.) I took @J805’s advice though and kept everything in one page instead of building a mobile and desktop version. Great advice, responsive is challenging but much better than managing 2 pages.
Just as another pro tip. You can make the original groups larger than you need and put in spacers that collapse the heights of them. Then, when you need to add something in between, you can just make the spacer smaller without having to adjust the height of the page.
Just give yourself more room to play with from the beginning to avoid having to always adjust the page height.
Thanks @J805 & @zachenson this is really helpful information. I have it in my agenda to refactor this week, can’t wait to try out these fixes to get my mobile app working and looking more like a mobile app.
Could you show an example of the spacers you mentioned? I am about to start refactoring my app and it would be helpful to see how you recommend seting up a groups