Interfaz de usuario Android: Layouts básicos 2

AbsoluteLayout

Este contenedor posiciona los elementos de forma absoluta. Lo que quiere decir que  indicaremos la posición (x,y) de las vistas que insertemos dentro de este. Esto hace que sea más complicado de mantener y menos flexible que los demás tipos de contenedores. Por eso ha quedado obsoleto y no se recomienda su uso.

TableLayout

Este contenedor permite dividir el espacio disponible en forma de tabla, definiendo las columnas  y especificando el lugar donde se posicionarán sus vistas hijas en la tabla. Al igual que pasa con muchas de los atributos vistos, la definición de la tabla se asemeja a como la definiríamos en HTML. Pero a diferencia de como se define una tabla en HTML, ahora solo crearemos filas (elemento TableRow) y cada vista que coloquemos en ellas se corresponderá con una columna. Evidentemente en cada fila podremos insertar las vistas que queramos, independientemente de que en otra fila hayamos insertado más o menos. Por lo tanto para saber el total de columnas que tiene  el contenedor miraremos la fila que tiene más columnas.

Interfaz de usuario Android: Layouts básicos 1

LinearLayout

Contenedor que posiciona sus vistas (Views) una detrás de otra. Configurable para que  esta colocación sea horizontal (uno detrás de otro) o vertical (uno debajo de otro). Por lo tanto su atributo más importante es: android:orientation:”horizontal|vertical”.  Las vistas empezarán a colocarse en la esquina superior izquierda de la pantalla. Actualmente es uno de los contenedores más utilizados.

Hay 3 atributos muy importantes que tendrán las vistas que se encuentren dentro de un contenedor de tipo LinearLayout y que nos ayudarán a su colocación (de las vistas):
A) Los atributos android:layout_width y android:layout_height explicados en un tutorial anterior.
B) El atributo android:layout_weight (valor por defecto 0) indica que proporción del espacio restante en el contenedor será adjudicado a una vista. Por lo tanto permite dar a las vistas de un LinearLayot unas dimensiones proporcionales entre ellas. Esto quiere decir que si al atributo android:layout_weight de una vista le asignamos el valor “1” y al mismo atributo de otra vista le asignamos “2”, esta última ocupará el doble del espacio libre que la primera.
Hay que tener en cuenta que el resultado de modificar este atributo depende del valor del atributo del contenedor  android:orientation. Ya que si el valor es “vertical” las vistas crecerán en altura para adquirir el espacio extra proporcional. Sin embargo si el valor de la orientación del contenedor es “horizontal”, las vistas crecerán en anchura.

El archivo AndroidManifest.xml

En el tutorial anterior la estructura de directorios que tiene un proyecto Android. Y comentamos la importancia de dichos directorios y de los archivos que incluyen. Vamos a presentar el archivo más importante de cada proyecto y que deberá de estar presente en la raíz del proyecto: AndroidManifest.xml.
Dicho archivo es generado automáticamente y modificable gráficamente o  programando. Y por lo tanto es importante conocerlo. Ya que el archivo presenta información esencial sobre la aplicación al sistema operativo Android. Información necesaria para que pueda ejecutar la aplicación.

Principales tareas que realiza AndroidManifest.xml:

- Utiliza el nombre de paquete Java como identificador único de la aplicación.
- Describe los componentes de la aplicación: Actividades, servicios, proveedores de contenido... Para ello utiliza el nombre de las clases que implementan cada uno de estos componentes y publica sus capacidades. Esto permite al sistema operativo conocer que componentes tiene y bajo que condiciones pueden ser lanzados.
- Especifica que permisos tiene la aplicación para acceder a partes protegidas del API que proporciona el sistema Android.
- Declara la mínima versión del sistema operativo en el que funcionará la aplicación.
- Indica las librerías que utiliza el proyecto y por lo tanto tienen que ser empaquetadas al crear la aplicación.
- Permite declarar  una clase 'Instrumentation' que sirve para monitorizar la interacción de la aplicación con el sistema. Esta declaración solo estará presente mientras se desarrolla y prueba la aplicación. Ya que será borrada antes de que la aplicación se vaya a publicar.

Estructura de un proyecto Android

Cuando creamos un nuevo proyecto para Android, ya sea desde eclipse o desde el nuevo Android Studio, se nos crearán una serie de directorios necesarios para posteriormente generar/compilar la aplicación.Vamos a repasar brevemente esa estructura de directorios y nos centraremos en uno de los directorios más importantes a la hora de crear una aplicación: el directorio de recursos.

Conceptos básicos de Android

Hay 4 bloques/componentes que debemos conocer y que pueden estar presentes, a la vez, en una aplicación Android:

1. Actividad

Cada actividad esta implementada como una simple clase Java que extiende (hereda) de la clase Activity de Android. Una actividad se encargará de mostrar una interfaz de usuario o pantalla gráfica, compuesta de vistas (cada unos de los elementos de la pantalla), y de tratar los eventos sobre estas vistas. Por cada pantalla que necesite una aplicación definiremos una actividad. Por ejemplo una actividad para listar contactos, otra para ver el detalle del contacto elegido y otra para enviar mensajes.
Cuando volvemos atrás en la aplicación, la interfaz es pausada y puesta en una pila. Con lo estamos devolviendo el control a la actividad que controlaba la anterior interfaz. Por lo tanto podemos definir las actividades como los controladores en la arquitectura MVC que utiliza Android.
En el fichero AndroidManifest.xml deberemos especificar todas las actividades de la aplicación, y cual va a ser la que se iniciará con la aplicación.

Interfaz de usuario Android: Conceptos

Introducción

En el patrón  MVC definiremos, a groso modo, la vista como la visualización del modelo. Más específicamente, la vista es la porción de una aplicación responsable del renderizado  de los elementos visuales y de enviar la interacción del usuario con dicho elementos a otro componente de la arquitectura. La vista es también llamada coloquialmente como interfaz de usuario. Y como Android sigue este patrón, en el que se pretende separar los datos de la lógica, lo correcto es utilizar el mecanismo que proporciona Android para definir la interfaz de usuario: ficheros de diseño basados en XML.
Cada uno de estos ficheros se crearán en el directorio res/layout/ de nuestro proyecto. Y cada uno de ellos se corresponderá con una 'pantalla' gráfica de la aplicación.
Todos los elementos gráficos que se renderizarán en una 'pantalla' son subclases de una clase llamada View, por lo tanto, a partir de ahora a dichos elementos gráficos (campos de texto, botones, imágenes) que formarán la interfaz de usuario les llamaremos vistas.

Lista de tareas simple con Symfony 2: Parte 5

Continuación de la página Insertar Tarea

1. Validación del formulario

La validación del formulario se realiza en la entidad asociada, Tarea en nuestro caso, ya que será la que recibirá directamente los datos del formulario y será la que valide sus restricciones.

 /*src/Tarea/ListadoBundle/Entity/Tarea.php*/  
 ….  
  public static function loadValidatorMetadata(ClassMetadata $metadata) {  
     $metadata->addPropertyConstraint('descripcion', new Assert\NotBlank(array(  
       'message' => 'This value should not be blank.'  
     )));  
     $metadata->addPropertyConstraint('descripcion', new Assert\MinLength(12,array(  
       'message' => 'This value is too short. It should have {{ limit }} character or more.'  
     )));  
     $metadata->addPropertyConstraint('fechaRealizar', new Assert\Date(array(  
       'message' => 'This value is not a valid date.'  
     )));  
   }  

En está función estática se añadirán las restricciones sobre cada campo del formulario y sus mensajes de error. Está función será la encargada de comprobar si son válidos los datos enviados junto al formulario y será llamada desde el controlador. Dicho controlador la llamará internamente mediante $form->isValid(). Por lo tanto una vez se envíe el formulario se validará (validación en el servidor).

Lista de tareas simple con Symfony 2: Parte 4

Página Insertar Tarea

Primero de todo vamos a crear una nueva entrada en la configuración de enrutamiento:

 #src/Tarea/ListadoBundle/resources/config/routing.yml  
 ...  
 insertar:  
   pattern: /insertar  
   defaults: { _controller: TareaListadoBundle:Tarea:create }  
   requirements:  { _method: "GET|POST" }  

Podemos ver que la acción se llamará cuando la url del navegador se corresponda con localhost/../insertar y que vamos a usar el mismo controlador (TareaController) pero esta vez llamando al método create.
Es importante especificar que la página podrá ser llamada mediante GET para acceder al formulario y mediante POST, cuando el formulario envíe datos al servidor. Por lo tanto hay que especificar ambos métodos en los requisitos.

A continuación vamos a crear el formulario de inserción de una tarea. Symfony 2 viene incluye un componente para formularios muy potente que facilita la tediosa tarea de tratar con formularios. Y recuerda que, como ocurre con todos los componentes de Symfony2, lo puedes utilizar fuera de Symfony2 en tus propios proyectos.

Lista de tareas simple con Symfony 2: Parte 3

Vista de la página principal

Podríamos recurrir a un método muy común utilizado con PHP  que consiste en  incluir un 'header' y un 'footer' en cada una de las plantillas con las partes que se repiten en todas las páginas/vistas. Sin embargo es recomendado utilizar el motor de plantillas Twig que incorpora Symfony2. Y aprovechar la posibilidad que proporciona de heredar plantillas.

Vamos a ver una breve introducción a algunos conceptos Twig:

A) Sintaxis en TWIG:

- {{.....}} es utilizado para imprimir una variable o expresión en la plantilla.
- {%....%} es utilizado para controlar la lógica de la plantilla. Por lo tanto dentro insertaremos las condiciones y o los bucles for, foreach...
- {#...#} es utilizado para insertar comentarios. Equivalente al comentario multilinea de /**/ de PHP.

Lista de tareas simple con Symfony 2: Parte 2

Vamos a continuar con la creación de la página principal de nuestra lista de tareas.

Controlador de la página principal

Después de definir la entidad, crear su tabla correspondiente en la base de  datos y de añadir algunos datos de prueba, ya podemos implementar nuestro controlador. Para ello vamos a asociar la ruta de la que será nuestra página principal, con el controlador que se va a encargar de tratar con el modelo y renderizar la vista. Por lo que vamos a modificar el fichero ListaCompraBundle/Resources/config/routing.yml .

Por norma, el nombre de un controlador (clase) llevará el sufijo Controller  y nombre de la acción (método de la clase) llevará el sufijo Action.

El controlador encargado de tratar el patrón de ruta '/' va a ser ListadoController.php y  el método, que invocará el controlador, encargado de ejecutar la acción va a ser indexAction. Además le indicaremos que el acceso a dicha ruta se realizará mediante peticiones GET.

 #src/Tarea/ListadoBundle/Resources/config/routing.yml  
 homepage:  
   pattern: /  
   defaults: { _controller: TareaListadoBundle:Tarea:index }  
   requirements:  { _method: "GET" }