The one idea to hold in your head

A MAM app looks and feels like a real native app — tabs along the bottom, a slide-out menu on the side, screens full of content. But under the hood it’s simpler than it looks: the whole thing comes down to one pattern, repeated everywhere:

A button is a labelled thing the user taps. A content class is the code that decides what happens when they tap it — usually, what screen to render. Tabs and menus are just ordered lists of buttons.

Once that clicks, the rest of the platform stops looking like a pile of unrelated settings pages — you start seeing one idea, repeated at different scales. This article walks through that idea so admins building an app and developers extending one are reading from the same map.

Here’s why it matters: MAM is a no-code builder, so you never write screen code — you assemble screens out of pre-built blocks. It’s the same trick that makes WooCommerce flexible. WooCommerce doesn’t hard-code your store; it gives you products you stamp out and configure. MAM gives you buttons you stamp out and configure — deliberately, “the WooCommerce of mobile apps.” Once you know what the blocks are, and how the navigation chrome around them is put together, you have most of what you need to understand why your app behaves the way it does.

The four pieces

1. Buttons — the atom

Everything an admin creates in the builder is a button. That word is broader than it sounds. A “button” is any configured app element: a login control, a map, an in-app web view, a category list, a phone-call shortcut, a decorative spacer. Each button carries a display title, an icon, a visibility flag, and a bag of per-button settings.

Buttons live in Mobile App Manager → Buttons. Each one is created once and can then be referenced from anywhere in the app — a tab, a menu, a home-screen layout. Creating a button does not place it anywhere; placement is a separate step.

Buttons are stored per role, in a serialized option family called local-app-button-array* (one variant per role: default, subscriber, administrator, anonymous, and any custom roles). The order of buttons in that array is meaningful — it mirrors the order an admin sees in the builder.

2. Content classes — the engine behind the button

Every button has a content type, and behind each content type is a content class — a single PHP file in mam-main that knows how to do two jobs:

1. In the admin, declare what settings that kind of button needs (a Web URL button needs a URL; a Map button needs a marker source and a zoom level), and render the edit form for them.
2. On the device, produce the data the app actually receives when that button is tapped — its payload, the bundle of data that becomes a screen.

There are about twenty built-in content classes today. A representative slice:

Each one represents one type of mobile UI element. (The Placeholder is a nice illustration of how far the model reaches: even “nothing here yet” is just another content type a button can have.) Adding a new content class is exactly how a developer gives admins a new kind of building block to assemble screens with.

The relationship is one content class to many button instances: a single Web URL content class powers every Web URL button anyone ever creates, each instance differing only by its saved settings. Three “Web URL” buttons pointing at three different pages are three buttons sharing one content class — the same way three products in a store can share one product type.

3. The tab bar — the persistent bottom strip

The tab bar is the row of (up to five) buttons pinned across the bottom of every screen. It is the app’s primary navigation, and on most apps it is where the Home shortcut lives.

The tab bar is not a separate kind of object — it is just a small ordered list that selects existing buttons and gives each a tab slot, an icon, and a per-role visibility toggle. You configure it in Mobile App Manager → Navigation → Tab Bar. Tab bar settings are per role, so different user roles can see different tabs.

4. The left menu — the slide-out drawer

The left menu is the slide-out drawer of buttons, the same way a hamburger menu works in most apps. Like the tab bar, it is an ordered list that references buttons you have already created, configured under Mobile App Manager → Navigation → Left Menu. It can hold far more entries than the five-slot tab bar, and it can include visual separators to group related items.

Between them, the tab bar and the left menu are the two pieces of navigation chrome that wrap every screen. Both are just lists of buttons.

How a tap becomes a screen

This is the part that ties all four pieces together. Your iOS and Android apps don’t actually contain your app’s screens — they contain a generic renderer. Everything specific to your app — every tab, button, and screen — arrives as a JSON payload from your WordPress site, in a single request.

When the app loads (or refreshes), it calls one endpoint, and mam-main runs a pipeline that assembles that payload:

  Mobile app                    WordPress (mam-main)
  ──────────                    ────────────────────
  "give me the app"  ──────▶    1. Who is this user? (resolve role)
                                2. Load this role's settings + buttons
                                3. For each button to render:
                                     find its content class
                                     ask the class for its app data
                                4. Assemble tab bar, left menu, screens
       app JSON      ◀──────    5. Send the finished payload back

Step 3 is the one that matters most. For each button that needs to appear, the pipeline looks up its content class and asks, in effect, “what should the app show for you?” The content class answers with a chunk of data, and that chunk becomes a rendered screen (or a navigation element, or an action) on the device.

So the chain, read end to end, is:

role → button array → each button’s content class → screen data → rendered app.

The same chain explains why some things are per-role: the very first step picks which role’s button array to load, so a subscriber and an anonymous visitor can be handed entirely different apps from the same site.

Tabs, buttons, and screens are different layers — keep them separate

It’s easy to blur these layers together, so it’s worth keeping them straight — they’re deliberately distinct:

• A button is a definition. It exists whether or not anyone can see it.
• A placement (a tab slot, a menu entry, a home-screen layout slot) is a reference to a button. The same button can be placed in more than one location, and the same button definition is reused — you don’t redefine it per placement.
• A screen is what a content class renders when its button is activated.

The Home tab is a good illustration. The bottom tab bar usually has a “Home” tab, but that tab is not the home screen — it is a small navigation button (the “Home for tab bar” content class) whose only job is to navigate to the home screen. The home screen itself is a separate layout. One is the doorway; the other is the room.

The same pattern recurs one level down. A list screen (a WP Post Category button, say) can carry a tab bar of its own — Map, Favorites, Phone, Website, Email — plus a configurable layout for the detail page you reach when you tap a list item. Those detail-screen tab bars are the same idea again: more buttons and more settings, attached to a screen instead of to the app’s root navigation. Some of those tab-bar actions are static (Share, Open URL, Phone Call) and work purely from your configuration; others are dynamic (Edit Listing, Approve, Send Notification) and need a small amount of developer code to fill in their action and gate them by context.

What this means in practice

If you’re an admin, this model turns straight into a workflow. To add something to your app, you:

1. Create a button and choose its content type (this picks the content class, and therefore what settings you’ll be asked for).
2. Configure that button’s settings.
3. Place it — on the tab bar, in the left menu, or in a home-screen layout.
4. Optionally restrict which roles see it.

If a button doesn’t show up, the model tells you where to look: is it visible? Is it placed? Is it placed for the role you’re previewing? Those are the three layers, in order.

If you’re a developer, this same model tells you where new capabilities belong. A genuinely new kind of screen element is a new content class. Enriching or gating an existing button at request time is done through the pipeline’s hooks rather than by editing screen code. You’ll almost never write UI — you contribute data to the payload, and the generic renderer on the device draws it.

How this connects to the rest of the platform

This structure is the spine that the rest of the MAM Suite hangs off of:

• Sibling plugins (contact form, geodirectory, special offers, reviews, and so on) mostly work by contributing buttons and content into this same pipeline, rather than by shipping their own screens. They extend the app through the same hooks the core uses.
• The settings cascade is what lets a single button definition be overridden per role and per instance without duplicating it.
• The phone-data pipeline is the request-time machinery that actually walks the button arrays and calls each content class. It is the “how a tap becomes a screen” diagram above, in code.

If you remember nothing else: tabs and menus are lists of buttons; each button is backed by a content class; the content class renders one screen. Every other concept in the codex is a refinement of that sentence.

Related

• Content classes overview — the full catalogue of built-in content classes and the interface each one implements
• Recipe: Add a button — the admin workflow for creating and placing a button
• Recipe: Configure the tab bar — composing the bottom navigation strip
• Button array storage — how button definitions are persisted per role
• Settings cascade overview — how per-role and per-button overrides work