Esta página fue traducida automáticamente del portugués y puede contener errores. La versión en portugués es la canónica.
Roadmap
El rumbo del proyecto y, tan importante como eso, qué CrossFly deliberadamente no provee — para que calibres las expectativas antes de apostar por el framework.
En maduración
- Objetivo Web (TeaVM/WebGL) — renderiza la UI, pero muchas funciones de dispositivo son stub (ver Web).
- Áreas marcadas como esqueleto en el core — el Bluetooth BLE/GATT tiene el modelado definitivo, pero
el transporte de radio vive en los launchers de plataforma;
FilePickereIWebViewtienen partes sin implementación concreta en algunos objetivos;dev.cf.synces placeholder.
Lo que el framework NO provee (a propósito)
No es una carencia — es una elección de diseño. No cuentes con encontrar (y por qué):
| No hay | Usa en su lugar |
|---|---|
Binding reactivo (setState/observables) |
mutación + repaint() (estado) |
| Inyección de dependencias (Dagger/Spring) | service locator/constructor (arquitectura) |
| Cliente HTTP de alto nivel | java.net/OkHttp (red) |
| Ruteo con nombres | pila de Window + constructor (navegación) |
| Persistencia ligera (“preferencias”) | SQLite / archivos (archivos) |
| i18n de textos (catálogo de strings) | externalízalo tú mismo (i18n) |
| Auth lista para usar | impleméntala sobre biometría/red |
Por qué esto ayuda
Conocer los límites evita buscar una API que no existe — y muestra dónde tú montas la capa (estado, DI, HTTP, rutas), con el framework proveyendo los bloques.
Ver también
- Changelog / What’s new · Contribuir
- Concepto: Estado y flujo de datos
¿Te resultó útil esta página?¡Gracias por tu opinión!