# The layered architecture > The mental map of CrossFly — app → ui → core → gl → libGDX — and why this separation exists. Source: https://crossfly.dev/docs/concepts/architecture — CrossFly documentation. Full docs as one file: https://crossfly.dev/llms-full.txt # The layered architecture To understand any part of CrossFly, it helps to have the map of the whole. At its core, **CrossFly is a libGDX `ApplicationListener`** — a single entry point that libGDX calls to create, resize, and render the application. Around this, the framework organizes itself into layers.

uses

app — your code
(Windows, components, logic)

ui — everything is a Component
(widgets, layouts, styles)

core / kernel
(bootstrap, input, lifecycle, config)

gl — per-primitive renderers
(translates drawing → draw calls)

libGDX + OpenGL

services — sqlite, device, map
(UI-independent modules)
## What each layer does - **app** — your code: `Window` subclasses (screens), components, business rules. This is where you live. - **ui** — the UI library: **everything derives from `Component`** (widgets, containers, styles, layouts). See [Everything is a Component](/docs/concepts/everything-is-a-component). - **core / kernel** — connects the application to the world: `Main` (the `ApplicationListener`) does the bootstrap, delivers input, fires the lifecycle, and loads device configuration. See [The lifecycle](/docs/concepts/lifecycle). - **gl** — translates high-level drawing (`Paint`) into OpenGL *draw calls*, with one renderer per primitive. See [The rendering pipeline](/docs/concepts/rendering-pipeline). - **services** — SQLite, device, map, etc.: modules **independent of the UI**, used by the app on demand. ## Why this separation matters - You program **almost always in the `ui` layer** (composing `Component`s). The layers below are an implementation detail — you rarely touch `gl` or talk directly to libGDX. - The framework is **single-threaded on the paint thread** (see [The paint thread](/docs/concepts/the-paint-thread)): the `Main` always calls `create()`/`render()`/`resize()` on that thread, and all UI happens on it. - The **services don't depend on the UI** — you can use SQLite or the device without building a screen, and the UI doesn't "know" about these modules until you call them. ## The control flow, at a high level 1. libGDX creates the `Main` and calls `create()` on the paint thread. 2. `Main` does the bootstrap (platform, runtime, config) and instantiates the **main window by reflection**, calling its `onShow()`. 3. On each frame, libGDX calls `render()`; the `EventsProcessor` paints the **window stack** (the topmost one on top) — but **only when there is a render request** (`repaint()`), not continuously. 4. Input and `resize` arrive through the `Main` callbacks, always on the paint thread. > This is the mental map, not the package catalog. For the list of packages and classes per layer, see the > technical reference. ## See also - Next: [Everything is a Component](/docs/concepts/everything-is-a-component) · [The lifecycle](/docs/concepts/lifecycle)