Ruta · registro de hitos
Cada hito suma una pieza al proyecto Android e iOS. El criterio se revisa por escrito antes de avanzar.
6 semanas · 6 hitos · 1 proyecto final
01
Criterio Compila en Android e iOS; el README documenta los pasos.
02
Criterio Contraste AA en textos y foco visible en controles.
03
Criterio Errores visibles y sin pérdida de datos al rotar.
04
Criterio Estados documentados y reintento manual funcional.
05
Criterio Arranque menor a 3 s en dispositivo medio.
06
Criterio 80% de entregables y revisión escrita con tres prioridades.
Ruta / 03
Cada semana cierra con un entregable revisado sobre una rúbrica de cuatro niveles. Los criterios de aceptación se publican antes de empezar, no después de la devolución.
| N.º | Entregable y criterio | Peso |
|---|---|---|
| 01 | Entorno y repositorio. La app compila y corre en Android e iOS; README con pasos reproducibles. | 8% |
| 02 | Pantalla de inicio. Componentes reutilizables y estados de carga, vacío y error visibles. | 10% |
| 03 | Navegación. Tres pantallas conectadas; gesto de volver nativo sin fugas de estado. | 10% |
| 04 | Formulario validado. Validación en cliente, mensajes en español y teclado por tipo de campo. | 10% |
| 05 | Consumo de API. Servicio aislado con timeout y reintento; sin llamadas en la vista. | 12% |
| 06 | Estado persistente. El estado sobrevive al cierre y no duplica registros. | 10% |
| 07 | Lista con imágenes. Caché, placeholder y sin saltos de layout al cargar. | 10% |
| 08 | Permisos y avisos. Permiso pedido en contexto; la denegación no bloquea el flujo. | 8% |
| 09 | Pruebas y linter. Tres pruebas unitarias verdes y análisis estático sin errores. | 10% |
| 10 | Build y ficha de tienda. Build firmado, capturas y notas de versión documentadas. | 12% |
Rúbrica: 4 completo · 3 con observaciones · 2 parcial · 1 no entregado. El certificado se emite al completar el 80% de los entregables y el proyecto final. Ver cómo se revisa.
04 / Revisión y evidencia
Cada entrega vuelve con comentarios anclados a líneas de código y una nota breve con tres prioridades de mejora. Este es el formato que usamos, aplicado a una pantalla de pago.
El estado vive en el widget. Mueve _items y _total a un controlador propio para poder probarlos sin montar la vista.
Dos fuentes de verdad. El total se recalcula en el build y otra vez en el evento de compra. Deja una sola función y llama a la otra desde ahí.
Falta el caso de error. Si la pasarela rechaza el pago, la pantalla no ofrece salida. Agrega el estado y su criterio de aceptación.
Bien resuelto: bloquear el botón durante el envío evita el doble cobro. Se queda tal cual.
05 / Cierre
Cupo de 24 personas por cohorte, con fecha confirmada y revisión escrita de cada entregable. Si la ruta encaja con tu equipo, escribinos.
También podés escribir a contacto@brotherempire.com