This page was machine-translated from Portuguese and may contain errors. The Portuguese version is canonical.
Roadmap
The project’s direction and, just as important, what CrossFly deliberately doesn’t provide — so you can calibrate expectations before betting on the framework.
Maturing
- Web target (TeaVM/WebGL) — renders the UI, but many device features are stubs (see Web).
- Areas marked as skeleton in the core — Bluetooth BLE/GATT has the definitive modeling, but
the radio transport lives in the platform launchers;
FilePickerandIWebViewhave parts with no concrete implementation on some targets;dev.cf.syncis a placeholder.
What the framework does NOT provide (on purpose)
It’s not a gap — it’s a design choice. Don’t expect to find (and why):
| Not available | Use instead |
|---|---|
Reactive binding (setState/observables) |
mutation + repaint() (state) |
| Dependency injection (Dagger/Spring) | service locator/constructor (architecture) |
| High-level HTTP client | java.net/OkHttp (networking) |
| Named routing | Window stack + constructor (navigation) |
| Lightweight persistence (“preferences”) | SQLite / files (files) |
| Text i18n (string catalog) | externalize it yourself (i18n) |
| Ready-made auth | implement on top of biometrics/networking |
Why this helps
Knowing the limits avoids hunting for an API that doesn’t exist — and it shows where you build the layer (state, DI, HTTP, routes), with the framework providing the blocks.
See also
Was this page helpful?Thanks for the feedback!