Aller au contenu principal

Macro Design

As macros grow, maintainability becomes as important as reliability. Advanced automation works best when the macro is designed as a system instead of a long chain of actions.

Design Around States, Not Taps​

New users often think in actions:

  • tap this
  • swipe that
  • wait 2 seconds

Advanced users think in states:

  • on login screen
  • inside reward list
  • waiting for loading to finish
  • action completed successfully

When you model the macro around states, branching and recovery become much easier.

Build Reusable Units​

If the same flow appears multiple times, extract it into a function or helper pattern.

Examples:

  • close popup if present
  • wait and click a target
  • scroll until text appears
  • validate the current page
function waitAndClick(target, timeout)
    Screen:wait(target, timeout)
    Screen:click(target)
end

waitAndClick("start.jpg", 5000)
waitAndClick("confirm.jpg", 5000)

Separate Configuration From Logic​

Avoid hardcoding everything inside one long script.

Good candidates for configuration:

  • region coordinates
  • target template names
  • timeouts
  • retry counts
  • user choices from dialogs

That makes the logic easier to reuse and easier to retune later.

Use IDs Consistently in Dialog-Based Flows​

If a macro depends on dialog input, use stable ids and keep them documented.

For example:

  • 1 = account name
  • 2 = retry enabled
  • 3 = selected run mode

This reduces confusion when the dialog changes over time.

Prefer Small, Verified Functions​

A 200-line macro can still be maintainable if it is built from small verified units.

A good internal rule:

  • one function should do one clear job
  • each function should have one success condition
  • each function should fail clearly if the state is wrong

Create a Known Recovery Point​

Long-running macros should know how to return to a known state.

Examples:

  • go back to home screen
  • reopen a feature entry point
  • dismiss temporary overlays
  • reset the current page before retrying

Without a recovery point, retries often just repeat the wrong action on the wrong screen.

Keep Block Macros Readable Too​

This design advice also applies to the Macro Builder:

  • group related logic together
  • keep setup at the top
  • use variables for shared values
  • isolate repeated steps into clearer sections
  • avoid very large unstructured stacks of blocks

For large automations, a practical structure is:

  1. Prepare environment
  2. Collect user or stored configuration
  3. Navigate to the target state
  4. Execute the main loop
  5. Verify success
  6. Recover or stop cleanly on failure