8 min read
User input and element visibility
Forms: how people add and edit data
A form is the main way the people using your app put information into it. In the Trips app we have been building, someone who wants to plan a new trip goes to a screen with a form and fills in the details: title, description, start date, and so on. When they tap Submit, Adalo saves a new record in the Trips collection.
When you add a form, you set two things. First, which collection it writes to. Second, whether it is a create form or an edit form. A create form starts empty and makes a brand new record. An edit form is tied to an existing record and pre-fills every field with the current values, so the person only changes what needs changing.
Each box on the form is a field, and each field saves into one property of the collection. By default Adalo puts every property on the form except relationships. You can drag fields to reorder them, and the trash icon removes a field you do not want people to fill in.
Some values should not be typed by hand. In the "Set Automatically" area you fix those instead. For a new trip, you would set the creator to the Logged In User and the privacy to a default automatically, so the person only sees the fields that are genuinely theirs to fill in. Finally, give the Submit button clear text and, very commonly, add an action that sends the person back to the screen they came from.
Showing a component only when a rule is true
By default every component on a screen is always visible. Often that is not what you want. You might want a "Add activity" button to appear only for the person who created the trip, or a warning to show only when a date is missing. Adalo lets you attach that logic to any component.
To change a component's visibility:
- Select the component on the screen.
- Click the More menu (the three dots) at the top right of the left panel and choose Change Visibility.
- Switch it from Always Visible to Sometimes Visible.
- Build the rule that decides when it appears.
For example, in the Trips app you could add a small hourglass icon to each trip and set it to show only when the trip's start date falls between today and one week from today. The icon then quietly marks the trips that are happening soon.
Tip
A visibility rule with no matching data simply hides the component; it does not break the screen. That makes visibility safe to experiment with. Set a button to Sometimes Visible, preview the app as different users, and check it appears for exactly the right people.
Filters and conditions
Filters and conditions look similar and both run on If-Then logic: if something is true, then do this. The difference is what they act on.
A filter narrows a group of records. You start with many records and keep only the ones that pass the rule, for example showing only trips marked Public. You add one anywhere you see the "+Add Filter" or "+Add Another Filter" button, and they live on components that display groups: lists, counts, dropdowns, charts, and more.
A condition decides whether one single thing should happen. It is what a visibility rule uses, and it is also available under an action's Advanced settings, so an action can run only sometimes. A condition is really a filter aimed at one record instead of a group.
The operators you can use depend on the property's type:
| Property type | Typical operators |
|---|---|
| Text | is equal to, is not equal to, contains |
| Number | is equal to, greater than, less than, is between |
| Date | is after, is before, is between |
| Relationship | contains, does not contain (one-to-many only) |
Two things are worth remembering. Text "is equal to" is strict and case sensitive, so "Day" is not equal to "day"; "contains" is looser and often better for search. And relationships can only be compared when they are one-to-many, never many-to-many.
A worked example: a creator-only button
On the trip details screen, only the person who created the trip should be able to add activities to it. Everyone else can see the trip, but the "Add activity" button should be hidden from them.
- Put the "Add activity" button on the trip details screen.
- Select it, open the More menu, and choose Change Visibility.
- Set it to Sometimes Visible.
- Build the condition: Logged In User is equal to this Trip's Creator.
Now the button appears for the trip's creator and no one else, even though every visitor loads the same screen. The same pattern handles a "Book Now" button that should appear only once the trip actually has menu items: set it to Sometimes Visible with the condition that the trip's Menu Items relationship contains at least one record. Until the creator adds a menu item, there is nothing to book, so the button stays hidden.
Prefer to see it explained? Here is the recorded Code for Albania lecture on this topic.
Check yourself
- What is the difference between a create form and an edit form, and what does an edit form do to its fields when it opens?
- You want a delete button to show only for the person who created a record. Is that a filter or a condition, and roughly what rule would you build?
- Why can you compare a one-to-many relationship with an operator but not a many-to-many one?
Where this lesson comes from
Built from
- Future of Mobile Development: Lesson 3 deck (forms, visibility, filters and conditions)
- Lecture Summary 3 (bilingual): collecting data from users and element visibility
alphaPlan courses are built from taught programmes rather than invented for the web. Where a claim rests on an outside standard or a reported case, it is named above so you can check it rather than take our word for it.
This course was developed by alphaPlan Center from programs delivered in partnership with the American Corners network.
Found something unclear, outdated or improvable? Suggest an improvement