Native App Groups

Need help Mobile
1

Hi, I’m building my first app as a native app and I can’t get my head around the best way to group things as it all has to be on one page. Currently I’ve started creating a long page with parent groups acting as pages and sized to the height of a normal phone screen.

Then my intention is to set all invisible besides the one the user should see. Am I doing it right, or am I missing a trick here as I feel like I’m overcomplicating it?

Links to resources and videos are also really helpful.

Here’s a picture of what I’m currently working with. All be it in early stages.

image
image1060×867 46.2 KB

2

Gareth, just so you have the proper terminology in terms of communicating it to others, you aren’t building a native mobile app (unless you meant to post to the flutterflow forum :))

A few things:

Firstly use the responsive version in the editor (see arrow in image) - It seems that may not be set up for your page.

image

Second, for making each screen visible, do as follows:

  • Give each screen / group a state called view (easiest to use a number, but text can work as well).

  • add a state called view to the page itself.

  • Then for each screen / group set it not to appear on page load and collapse when hidden
    image

  • set conditionals for each group /screen to be visible only when page’s view is This group’s view

  • Finally to switch between screens just change the view state of the page to the value representing the screen you want to show (standardize this using a custom event).

3

I don’t get why you use states ?

Do it as this , each group is invisible as code-escape says , and add conditional to them get data from page URL (Path segmented as list ) item#2 is page_1 . Lets say you click button1 that shows that group . WF will be go to page (arbitrary text - page_1) and lets say you will open a tab in side page_1 . Go to page arbitrary text page_1/page_2 , get data from page URL segmented as list item#3 is page_2 this element is visible . Note: You will always go to the same page

4

What you do when you open 3rd page from history tab ? , What do you do about SEO ?

5

I’m responding to the OP’s question in the context of “I’m building my first app.” and therefore providing a simpler approach. (I can’t even follow yours)

I don’t know what you mean by 3rd page history tab in general and this is for a mobile app.

SEO - pages behind logins aren’t important and this isnt a landing page (which ideally would never be made in Bubble). and again focusing on the meta stuff for a first-timer.

6

It is an SPA , let’s say your profile group and main group is in the same page. When user goes to profile , it will show in browse history . States won’t solve that . I am giving the optimal way

Very misleading comment

BTW don’t get me wrong Im not trying to pick up a fight here , I understand you are trying to help a beginner but midway he will realize he needs SEO stuff , so midway he will change all of his go to page workflows and visibility conditions if he uses your way.

7

It’s not hard to change visibility conditions, I do it a bunch of times a week, and it only takes a few minutes.

How so? Are you saying that SEO on a guest blocked page is important?

I think I know Bubble a bit (certification notwithstanding) and yet I can’t follow your approach so I assume that a beginner certainly can’t.

I don’t know what this comment means. First, again, its a mobile app, there is no history. Second, my approach won’t show the profile in browse history (url isn’t changing) so what do you keep referring to? Third, who cares if profile shows up in history? (if its a screen user shouldn’t see then we will handle that laters)

8

A product owner can be flexible on that , signup blocked or not, contact page blocked or not all has to be flexible .

Depends on your product

He means SPA by saying native app if he is not wrong .

If you don’t use my way than I suggest start doing , copy and paste my comment to chatgpt and ask it to explain it simply it should simplfy it

9

Hi @code-escapee, just in case it helps, I’ve got a website building background and know a little bit of html, css, JS. I manage a website for a living. I also have a design side in my past, doing UX/UI design for web and mobile using Figma and Adobe XD and improving websites etc. Basically I’ve got quite a wide variety of digital marketing skills.

Anyway, referring to your initial reply, thanks for the step by step. I thought it was classed as a native app as I ticked the box which says this is a native app? If not, my bad.

Secondly, I’ve clicked responsive but I have the whole of the first screen in a group called Welcome Screen which is a fixed layout. When it was other container layouts it would align to the top left and stacked. Do I need to change something?

When I’m creating each screen/group, do I need design each one similar to a completely different webpage? Or only specific elements that are going to be changing on the screen?

The conditional part and view states makes a lot of sense (still got to test states) and I’ve seen videos on this.

Thanks so much for the in depth but high level response. Super helpful and I’m keen to get terminology right as it’s really important, so feel free to call me out on my terminology mistakes.

10

Can you remind me where this checkbox is?

I would not make it a fixed layout. I’d give it minimum and maximum on the outer container (a group that holds ALL the screens). Keep in mind mobile screens vary in pixel size and you want to be able to have the full screen appear on the entire window on a phone - not to get cut off or have dead space.
The stacked isnt a issue.

Can you clarify? TLDR a screen can be anything. If it’s part of a form or signup process, you’d probably make it look similar - you can just clone the first screen of the form and then change the labels and input values in the cloned version). Otherwise a screen can literally be anything you want it to be…

11

On the page properties, ‘This page is a native app’
image

This is what the manual says about it:

*"
This page is a native app:
Check this box to build a native app and if you want this page to be the app submitted to the app stores. Clicking this checkbox displays a popup listing tips for building a native app. Note: This feature is in beta."

I tried clicking it, and here’s what the popup says:

image
image784×383 30.3 KB

And it also then shows an error:
image

I think in-short, it was designed to guide app-builders on some best practices for mobile app building, that aren’t as necessary anymore. I would say this checkbox doesn’t really do anything other than provide info and a warning about workflows involving pages…

3 Likes
12

Hi,

See @msgiblin comment below to find this.

Ok no problem, I can do this. How do I stop it from left aligning so I have free rule to place wherever I like?

By this I mean do I design multiple versions of the screens as stacked groups and make them visible/invisible when they’re applicable. Or do I just design like different elements such as bars and buttons as groups, and then stack them and make them visible/invisible when applicable. Let me know if I explained that well enough.

13

Hi, thanks for commenting. So would you recommend not using that tick box and doing things as pages instead of stacked groups?
Thanks

14

Yes, I’d say the checkbox isn’t necessary.

Pages vs Stacked Groups - this is oft debated and there are good points for both approaches. These are more commonly referred to as MPA (Multi Page App) vs SPA (Single Page App). I’d recommending searching the forum for these acronyms and reading what other users have done and say about each approach.

For my own use case, the app I’m building Im going Multipage to make indexing for SEO easier. I have often thought if i dod have to go SPA it may not be as massive of a change if i convert each page to a reusable element, and stack those.

15

That makes sense. I want it to be a mobile app and stored on the app store so SEO doesn’t matter as much on the app build does it?

16

If you don’t intend on it to be accessed via the web, Google searches, etc and entirely just a wrapped Mobile app, you are correct, SEO at the page level wouldnt matter.

1 Like
17

That’s good then. I might build with pages then as it’s easier to visualise. Especially if I can still add it onto the app store too.

18

But you will later on lose the speed , web users and mobile web users

1 Like
19

The editor when building pages or reusable elements is exactly the same. Build you different ‘pages’ as reusable elements and just keep in mind when building the reusable element you are basically building a single page.

This is advisable for SPA because of the speed between navigating from one ‘page’ to the next ‘page’ as the experience is more in-line with what users expect from Native Apps.

Best thing about building a webapp is you have both a web version and if you elect to a wrapped ‘native’ app on the app store. Nothing wrong with getting a little extra visibility via organic search results via Google, however, if the time required to make it work properly is more than you anticipate the benefits of SEO, then no real reason for SEO.

Don’t bother with the checkbox, it does nothing. Build your ‘pages’ as reusable elements and when complete place the reusable element into a container group on a page.

If you don’t anticipate any need to have functions like sending an email with a direct link to a specific ‘page’ in the app, then using custom states to make specific ‘pages’ visible via conditionals is fine.

If you want to be able to do things like have links to specific pages and/or want some form of on page SEO using the URL then use the URL path list for making specific ‘pages’ visible via conditionals.

When setting up the container element, do not make any of them visible on page load and only use a single condition that will make it visible. Attempt to use an option set for the different conditionals that are required, and for me personally I make that option set mirror the ‘pages’. So, if I have a page for product search and another page for dashboard, I’d have in the option set values for each. Then on the container groups that contain the reusable element for those pages, I can set the content type to the option set, set the value of the datasource to the appropriate option set value, put a condition to make the group visible when (either custom state or URL path list item) value is the group’s option set value. This makes it super simple to setup a single container and then copy/paste it to change the datasource and ensure they will be visible or not when appropriate. This also helps with your workflow actions to either change the custom state value or URL path list item.

You want your users to feel like they are not being navigated to a completely different app, so make sure your color scheme, styles, font families used etc. are the same, but there is no reason to try and make each look the same from the perspective of layout, as your layout is determined by the functions and the UX/UI you want.

If you are new to Bubble and the responsive system is difficult to comprehend, I highly recommend looking into some of the free resources from Bubble as well as youtube tutorials for learning some of the basic concepts needed to get your page design exactly as you need it.

1 Like
20

Good to know, thank you :slight_smile: