3 posts tagged with "android"

TeaQL Java can support an Android application with local SQLite, a Kotlin desktop application, a standalone CLI, and a Java web service because its architecture separates the domain contract from the application container and physical database execution. The key is the direction of dependencies: business operations depend on runtime interfaces, while platform integrations implement those interfaces.

Java's standard module system, JPMS, makes part of that separation explicit and enforceable on the JVM module path. Generated metadata reduces the need for reflective discovery. Execution contexts carry policy and capabilities. SQL adapters connect the common runtime to different database APIs.

The Java application examples show the application forms. This article examines the mechanisms that make them possible, and distinguishes current runtime architecture from older example versions.

We refactored the TeaQL Java runtime (teaql-java) to achieve three goals:

1. JPMS module boundaries — seal internal packages, expose only what generated code needs
2. Spring Boot independence — run without Spring Boot using a plain main() function
3. Rust alignment — dual-layer audit logging, compile-time query enforcement, RequestPolicy

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.