Desarrollo Mobile

Origen

Celulares: el mercado de los smartphones hoy es masivo. Desde el 2000 tenemos Java en los celulares, pero al principio se usaba sólo en juegos. Los desarrolladores pensaban en aplicaciones .com, no se pensaba en el celular como un dispositivo para correr una aplicación empresarial. En los celulares lo importante fue que el SysOp de los aparatos vinieran con VM. 


Apple fue el primero en liberar una SDK para aplicaciones mobiles. Luego vino Google con Android.

Motorola, Samsung, Sony --> tomaron el kernel de Android y generaron su propia versión.
El Sistema Operativo es gratuito, y hay una comunidad open-source que desarrolla apps sobre ese SysOp.

¿Qué necesitamos que una plataforma mobile tenga?

  • Diseño de la interfaz: es más complicado que un diseño web, el tamaño es variable dependiendo de cada dispositivo: tenés teléfonos con 720x720, otro con 1280x768, etc.
  • Experiencia del usuario
  • Diseño de los componentes. Cada componente trabaja con dependencias, mostramos el diagrama con la arquitectura de Android

User experience (UX)

Esto define cómo se manejan las app:
  • trackball vs. touch
  • cómo se vas de una app a otra
  • botón de Home para dejar la app en background
  • botones Back
¿Qué pasa si diseño una app en la SDK de Android y la deployo en una Blackberry? al usuario le molestaría cambiar la manera en que lo usa. Hay guidelines de Blackberry, otras para Android, etc. Moraleja: no se puede pasar una aplicación de un dispositivo a otro. Hay que educar al usuario al respecto.

Diseño de componentes

Cada componente trabaja con dependencias, mostramos el diagrama con la arquitectura de Android

Hay 4 capas:

1) Linux Kernel: drivers de memoria, de keypad, de la cámera, manejo de batería (power management).
2) Libraries: SQLite (BD), Open GL (librería de gráficos), SGL, WebKit, etc. + Android Runtime (Core Libraries, Dalvik VM)
3) Application Framework: Window Manager, Telephony Manager, View System, Resource Manager, etc.
4) Applications: Home, Contacts, Phone, Browser, nuestra app

Android es una application o task que puede tener n actividades (pantallas) renderizadas + la lógica bindeada. Si queremos en nuestra app correr una cámara, basta con "hablar" con el componente del nivel que corresponda (más bajo o más alto nivel). Cada actividad trabaja en un thread separado.

Desafíos en mobile

Backward compatibility

Siempre es un problema discontinuar funcionalidades de hardware y de sistema operativo, antes de Android 4 teníamos un menú o tab activity, había que implementar las acciones más comunes a través del desarrollo. Después de Android 4 nace el action bar como una especie de "Acciones Favoritas".

Todo esto tiene consecuencias:

  • en la experiencia de usuario que se modifica
  • en el desarrollo de app, si estás en un dispositivo anterior a 4.0 el usuario puede pedir que reproduzcas ese comportamiento.
  • si bien la lógica de negocio es común a todos los dispositivos, la vista tiene que adaptarse para cada caso.
lo que muestra que es una tecnología que recién está comenzando a madurar.

Testing

¿Qué pasa con los tests? ¿Podemos automatizar los tests?
¿El caso de uso involucra la UI? Sí, entonces debería mockearla.
O testeo sólo la UI.
O testeo negocio y UI por separado.
Es costoso eso.
Off-topic: Selenium permite automatizar los tests. Robotium es la versión para Android. Forma de testear: compran un paquete como Robotium /Selenium y lo customizan o compran horas de Testers (o QA), es decir que se hace manualmente.

Los tests de mi proyecto Java corren en una VM de Java.
Los tests de mi proyecto Android tienen que correr en Dalvik, ahí es donde todo se rompe, porque yo no tengo instalado el sysop de mi celu. Entonces otra opción es convertir mi proyecto a java y correrle los tests ahí, la macana es que tengo que tomar más sopa para que eso pase.

Primer ejemplo: Naturaleza de un proyecto Android

¿Qué tiene un proyecto Android? Tiene una naturaleza propia:
  • Android Framework
  • Libraries
hay que enseñarle a Eclipse a que todo lo que hacía para Java lo haga para Android.

Defino una clase ConversorActivity que extiende de Activity. Esa clase define ciertos eventos, que el usuario activa. Vemos:
  •  el método onCreate: 
  • Vemos también el main.xml que define la vista:
1) mediante drag & drop visual de componentes
2) mediante un editor xml que valida que esté correctamente formado (vía dtd)
3) mediante código java

Tanto 1 como 2 como 3 se pueden generar abstracciones nuevas,
con 3 sólo tengo que saber diseñar con las reglas de Java,
con 2 tengo que lograr que nuevos tags generen varias líneas de Java en la generación posterior.
con 1 necesito aprender RelativeLayout y extenderlo para poder hacer un drag & drop visual sobre el container.

Ejemplos: ClearableEditText: texto que tenga una cruz para borrarle el contenido, o un texto con botón para validar el ingreso según un origen de datos. Extract style para los estilos en base a las propiedades de un control en un main.xml. Esto ayuda mucho a separar templates para los diseñadores.

Cómo interactuar con los diseñadores

1) png + fonts + colores de fondo
2) te pasan un css (participa en el proyecto)

Viviendo sin binding

a) Corremos el ejemplo 1 del Conversor, en el Simulador.
No tiene binding!!!
kilometers apunta a un label (TextView)
editText apunta a un EditText

public void onClick() {
    kilometers.setText(String.valueOf(Integer.valueOf(editText.getText().toString()) * 1.60934));
}
Funciona, pero es... un poco engorroso

b) Lo pasamos a un método public void convertir y hacemos el binding del botón desde el xml. Convertir setea kilometers. Pero no hay model. Antipattern: Magic Push Button, tengo todo centralizado en la vista.

c) Volvemos al Model-View-Controller. Usamos la clase Conversor y mostramos Android binding -> está en Beta.

Activity usa un Model que extiende de ViewModel.

Otra cosa que puede hacer más feliz al programador Android es Scala -> funcional. ¿Por qué está bueno funcional? Porque la UI se basa en eventos.
Otra opción: JRuby, RUOTO (Ruby for Android)
Otra opción: Titanium, código Nativo IOS y genera una vista web (HTML, Javascript, CSS), al no ser nativa no anda del todo bien.

Tipos de aplicaciones

¿En qué conviene desarrollar?
  • Juegos: nativos tiene sentido
  • Google+ tiene sentido porque es excelente... entonces tiene sentido hacer algo nativo si sale copado, pero eso tiene un costo.
  • Una app de facebook o de diario: puede ser web, la pregunta que me tengo que hacer es: ¿necesito más? si la respuesta es no, web es una buena opción.

Resumen actualizado de la clase

https://docs.google.com/document/d/1n7jcQU4cK9NxguftnFWpmbClzX5wuDSdq6ISm6rOLxQ/edit