2 posts tagged with "mobile"

Historical note: This article documents an earlier TeaQL generation target. Early versions emitted backend templates, UI pages, mobile clients, and service scaffolding directly into application workspaces. Modern TeaQL has moved to a clearer boundary: generation produces versioned libraries, deterministic business APIs, query DSLs, and runtime capabilities that applications consume as artifacts. This is more friendly to AI-assisted coding and DevOps because AI agents can focus on business workflows, integrations, tests, and product behavior, while generated capabilities are reviewed, tested, published, upgraded, and rolled back through normal dependency and release pipelines.

In 2020, mobile generation became a first-class backend and frontend concern.

The code changes touched Taro templates, mobile backend service templates, WeChat app service templates, IAM service templates, display mode helpers, tree services, generated view pages, and React view groups. The generator was learning to emit an app that could run across web admin and mobile-miniapp channels.

Taro and Mobile App Templates​

The Taro templates introduced a generated mobile frontend target:

• app entry generation
• service center generation
• mobile object pages
• image and image-list support
• generated app path handling

The templates also guarded generation based on model features, so mobile code was emitted only when the domain model declared the right capability.

Mobile Backend Service Layer​

Mobile UI generation required backend support, so the Java templates added:

• mobile app backend tasks
• miniapp service view pages
• list and detail service methods
• display mode detection
• generated view-home-page behavior

This kept the mobile app from becoming a separate manual project. The backend view layer and frontend app layer evolved together.

IAM Generation​

The generator added IAM-related service templates:

• base IAM service
• WeChat mini-program handler
• WeChat mobile handler
• login method support
• key-pair verification
• avatar and phone update flows

Authentication and identity handling were becoming part of the generated application contract, not an afterthought bolted onto each project.

Tree and View Group Support​

The generated UI also gained tree services and view group customization.

That made navigation and object presentation more model-aware. The generator could produce different views for different user entry points while keeping the same domain backend underneath.

Historical note: This article documents an earlier TeaQL generation target. Early versions emitted backend templates, UI pages, mobile clients, and service scaffolding directly into application workspaces. Modern TeaQL has moved to a clearer boundary: generation produces versioned libraries, deterministic business APIs, query DSLs, and runtime capabilities that applications consume as artifacts. This is more friendly to AI-assisted coding and DevOps because AI agents can focus on business workflows, integrations, tests, and product behavior, while generated capabilities are reviewed, tested, published, upgraded, and rolled back through normal dependency and release pipelines.

After the Java backend templates stabilized, the generator began producing client-side code.

The code diff shows new Android framework templates, Swift POJO templates, SwiftyJSON mapping helpers, remote manager templates, and sample HTTP request generation. This was not just adding another output language. It changed the generator from a backend scaffold into a multi-target system.

Android Application Skeleton​

The Android templates introduced generated application structure:

• activity framework files
• entry page fragments
• manifest templates
• generated string resources
• menu and naming convention helpers

The generated Android app did not need every screen to be handwritten. The same domain model could drive initial navigation, labels, and object entry pages.

Swift Object Generation​

Swift support added another important boundary: generated domain objects could exist outside Java.

The Swift templates produced:

• struct-based model objects
• custom string conversion
• JSON object mapping
• reference-list handling
• nil-safe member access

That forced the metadata layer to become less Java-specific. Field names, reference names, and type mapping had to work across languages.

Remote Manager Pattern​

The remote manager templates connected mobile clients back to generated backend services.

Instead of treating the mobile app as a separate hand-coded consumer, the generator began producing both sides of the contract: server manager methods and client access code. That reduced drift between API shape and client expectations.

Why This Stage Mattered​

The practical feature was mobile scaffolding. The architectural feature was bigger: one domain model could emit multiple runtime surfaces.

That idea later became essential for generating backend APIs, admin UI, mini-program code, search DSLs, and typed query APIs from the same model vocabulary.