Skip to content
CrossFly is 100% open sourceFollow us on GitHub
CrossFlyCrossFly
Get started

This page was machine-translated from Portuguese and may contain errors. The Portuguese version is canonical.

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.
  • 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.
  • gl — translates high-level drawing (Paint) into OpenGL draw calls, with one renderer per primitive. See The 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 Components). 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): 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

Was this page helpful?