Un equipo informático de tamaño reducido, alimentado por batería, con conectividad inalámbrica y pensado para usarse en movimiento.

Cada una de estas cuatro características impone una restricción real al software que vamos a escribir durante el curso.

• →Tamaño: de maleta portátil a bolsillo en una década.
• →Pantalla: monocroma, blanco y negro o verde suave.
• →Funciones: llamar, SMS; con el tiempo, calculadora, alarma, snake.
• →Icono: Nokia 3310 (2000) — duradero, autónomo, indestructible.

La gran demanda de desarrolladores Android del mercado es la razón por la que este curso se centra en Android nativo.

Dispositivos muy distintos entre sí → apps responsive. El acceso a funcionalidades depende también de la versión de API.

Programar para móvil no es programar para escritorio con una pantalla más pequeña: es programar bajo restricciones que en un PC no existen.

• →Arquitectura ARM, optimizada para consumo, no para potencia bruta.
• →Throttling térmico: si el dispositivo se calienta, el sistema reduce la frecuencia del procesador.

Un cálculo intensivo sostenido acaba siendo más lento, no más rápido. Consecuencia: el trabajo pesado va fuera del hilo principal y, cuando es posible, se delega al servidor.

• →RAM limitada y compartida entre todas las apps abiertas.
• →El sistema puede matar tu app en segundo plano para liberar memoria, sin avisar.

Esta es la razón de ser del ciclo de vida que veremos en el tema 2: una app móvil debe poder morir y resucitar sin que el usuario pierda datos.

• →El recurso más escaso: pantalla, CPU, GPS, wifi, bluetooth, todo consume.
• →Doze y restricciones de background: el sistema penaliza el consumo en segundo plano.

Consecuencia: no se hacen sondeos periódicos al servidor "por si acaso"; se usan notificaciones push y trabajo diferido.

• →Espacio limitado y compartido con fotos, vídeos y otras apps.
• →El usuario puede quedarse sin espacio en cualquier momento.

• →Intermitente por definición: túneles, ascensores, cambio de wifi a datos móviles.
• →Ancho de banda y latencia variables; los datos móviles pueden tener coste.

La red no es fiable. Toda operación de red necesita gestión de error y, preferiblemente, caché local (unidad 4).

A diferencia de un PC, un móvil sabe dónde está, cómo está orientado y qué le rodea.

Hablaremos de estos sensores en la unidad 6.

No es una elección técnica sin consecuencias: afecta a lenguajes, herramientas, rendimiento y al coste de mantener la app en cinco años.

Cambiar de tecnología a medio camino es un proceso costoso: puede durar meses o años. La IA reduce parte de esa complejidad, pero trae consigo mantenimiento de código ajeno y más tiempo de testing.

Escribir una sola vez, ejecutar en muchos sitios. Cada framework lo intenta de una forma distinta.

Reutilización inmediata del código web, pero rendimiento y acceso al hardware son los más limitados de las tres familias.

• 1¿Cuántas plataformas hay que cubrir?
• 2¿Qué exigencia de rendimiento tiene la app?
• 3¿Cuánto hardware específico usa?
• 4¿Qué sabe hacer el equipo?
• 5¿Qué ciclo de vida tiene el producto?
• 6¿Cuál es el presupuesto real?

• →Sin capas intermedias que oculten sensores, permisos, ciclo de vida y servicios.
• →Kotlin es la recomendación oficial de Google desde 2019, sintaxis cercana a Java.
• →Herramientas gratuitas en Windows, macOS y Linux.
• →Base sólida para aprender después cualquier framework multiplataforma.

No es una recomendación universal: saber argumentar tu elección forma parte del criterio de evaluación 1b.

El emulador necesita virtualización por hardware (Intel VT-x, AMD-V o SVM Mode). Si está desactivada, el emulador no arranca o va inutilizablemente lento.

Android Studio muestra el porcentaje de dispositivos cubierto por cada nivel de API. minSdk 24 (Android 7.0) cubre casi todo el parque actual.

Coexistencia de muchas versiones de Android y modelos de dispositivo en el mercado a la vez.

Las bibliotecas AndroidX (Jetpack) existen para esto: una API única que resuelve internamente las diferencias entre versiones.

Device Manager → Create Device. Las imágenes con Google Play incluyen servicios de Google; x86_64 es mucho más rápido que ARM en PC.

Conclusión práctica: el emulador sirve para desarrollar y cubrir variedad; el dispositivo real es imprescindible para validar rendimiento y hardware. Se usan los dos.

• 1Ajustes → Información del teléfono, pulsar 7 veces en Número de compilación.
• 2Ajustes → Opciones de desarrollador → activar Depuración por USB.
• 3Conectar por cable y aceptar el diálogo de autorización.
• 4Comprobar con adb devices que aparece en la lista.

• →La idea en una frase: «Una app que permite a [quién] hacer [qué] para [para qué]».
• →Personas usuarias concretas, no «todo el mundo».
• →3–4 funcionalidades imprescindibles, no diez.
• →Pantallas, bocetos y datos que maneja la app.

Si alguna casilla queda vacía, la idea todavía no sirve para el proyecto: hay que estirarla o cambiarla. Vale más descubrirlo ahora que en febrero.

El móvil no es un PC pequeño

Es una plataforma con restricciones propias — y esas restricciones son el punto de partida de todo lo que programaremos este curso.