Intro Android

Las herramientas para desarrollar en Android están inmaduras, algunos dicen que hay que aprovechar los recursos y para eso hay que trabajar a un nivel más bajo. En nuestra opinión es una excusa, no es cierto que ambos hechos estén relacionados. 

No somos expertos en Android pero como tenemos claros los conceptos de las tecnologías:
1) entendemos lo que pasa cuando hay ausencia de esos conceptos importantes, como el binding (NO HAY BINDING por default)
2) cuesta menos adaptarnos a una tecnología nueva. 

Ideas importantes para trabajar con Android

1) UI - layout: descripción de las vistas, navegación, mostrar datos del dominio, manejo de eventos.
2) Comunicación con el server - distribuir info (tener una base local y otra remota). La app se va a estar ejecutando en su mayoría en el celular, en lugar de Wicket o Grails donde la comunicación hacia el servidor estaba de alguna manera garantizada. Con celulares volvemos a la idea de las app pesadas:
  • porque la usabilidad es mucho más importante
  • porque el Google Play o el App Store facilitó muchísimo la instalación/actualización de las aplicaciones
3) Hay push notification que cambia el modo de comunicarse: el server por iniciativa propia le manda info al cliente 

Arquitectura móvil

La arquitectura para mobile es muy compleja: para poder hacer una app declarativa necesito mucho tiempo para entender todas las herramientas que tengo que usar, por eso en esta primera clase nos vamos a concentrar con el estándar de facto. Otros temas que tengo que tener en cuenta:
  • hay potenciales problemas de compatibilidad entre teléfonos y de SDK (depende qué versión)
  • una app optimizada para una pantalla de 4" no es lo mismo que para una pantalla de 5". Además algunas son más largas y otras más anchas. Y generalmente no podemos segmentar nuestra aplicación a un mercado particular: tiene que andar para todos los teléfonos.

Creando nuestra primera aplicación móvil

- Creo Master/Detail
Object Kind: Materia
Object Kind Plural: Materias

Corremos la app definiendo un virtual device. Lo corremos:
  • en la tablet
  • en un teléfono (handset)
y se ven distintos: en la tablet se muestra el maestro y el detalle en la misma pantalla.

¿Cuál es la teoría detrás de esto?
1) Activity <=> Pantalla o página.
2) Intent <=> intento. La navegación está manejada por los intents, no puedo hacer que una activity vaya a otra activity. No es válido 

new Activity(5, true).open()

sino que creás un intent para 
  • levantar la calculadora
  • la agenda
  • y la cámara.
Los activities son polimórficos.

new Intent(this, MateriaDetailActivity.class)

otra opción es tener un 
new Intent(action como un String)

Esto permite que el teléfono te pregunte cómo querés contactar a una persona: si querés mandarle un mail, mensaje, etc. En una galería de fotos, share permite que lo subas al Facebook, a Picasa, etc. Lo malo es que:
  • todo lo que tengo que recibir en la pantalla siguiente tiene que viajar por el intent (datos primitivos, nada de objetos de dominio, ¿eh?). Vuelven los ids a full.
  • es obligatorio pasar una interfaz o una clase, entonces tenés que preguntar por instanceOf.
Lo bueno es que:
los intents crean activities nuevas que son independientes entre sí, esto permite que si me quedo sin memoria mate viejas activities sin perjuicio de lo que estoy haciendo ahora para volverlas a crear después (si fui de pantalla 1 a 2, de 2 a 3, etc. etc. y estoy en la pantalla 7, Android mata de las pantallas 1 a 5, y después las vuelve a crear, pero eso es complejidad extra porque tengo que programarlo yo: onPause() y onResume(), onDestroy() y onCreate()).  Cada vez que uso una variable de instancia tengo que estar seguro que esa variable esté disponible.

Ver el ciclo de vida:

http://developer.android.com/reference/android/app/Activity.html


El estado de una actividad va disparando eventos que tengo que atrapar:  onCreate(recibe un Bundle que tengo que haber guardado en el onDestroy).

Ej: estás corriendo una app, vas a la pantalla 3 y te llaman por teléfono, se agrega en el Stack la activity del teléfono. Después te mandan un mensajito. Todo puede ocurrir en el mismo Task, donde se van apilando las ventanas (se mezclan las de mi app con las del teléfono). Esto es complejo cuando vos tenés que mantener el back.

Esto no ocurre en iphone donde la app maneja su propio stack.

Fragments

TODO: Pasarlo a una segunda clase de Android
Para poder reutilizar las ventanas Aparece el concepto de Fragment (nuevo para Android) <=> pedazo de ventana reutilizable. 

MateriaListFragment -> lista de materias
MateriaDetailFragment -> detalle de una materia
Entonces:
1) Para tablet: carga el fragment list + fragment detail
2) Para handset: carga el fragment list, y al clickear arma un Intent que deriva al fragment de Detail.

GoogleMapFragment: podés poner el mapa de google en cualquiera de tus activities. 

- Layout: definido visualmente y/o a través de un xml
- También tenemos un strings.xml que permite internacionalizar el contenido de lo que se muestra
- width 1 y 3 para list y detail permite configurar un 25% y un 75% de la pantalla.
- los paneles se pueden configurar: Linear, o bien Relative (abajo de este control, al costado del otro)

archivo manifest.xml
- define los intents que se pueden recibir (el IDE los va agregando a mano)
- también definimos el mínimo de SDK y el target
- en Wicket creo yo el botón, en Android lo crea un xml 
- cuando abro una app busca el último estado de esa app en el stack.