Portal de juegos flash en PHP

Arkatia es el portal sobre el que he estado trabajando recientemente, para un cliente de Valencia: Taykron  Games , que me proporcionó el diseño en imágenes de lo que quería, con el que nuestro querido amigo Joan Carles nos hizo la maqueta en XHTML+CSS +Jscript (algunas cosas en JQuery) y en mi caso ,me encargo de toda la parte de la programación y, diseño de estructuras de datos, base de datos, arquitectura de la información, jerarquía y roles, etc.: Las tareas de un ingeniero jeje, aunque en este caso también he hecho, entre otras, el diseño , maquetación y programación del backend o administración interna.

 

La estructura de clases de esta aplicación web consiste en un modelo vista controlador (MVC) para  juegos, concursos, jugadores ,etc., que están en continúa intercomunicación,i.e., todo centralizado desde una clase principal que gestiona las acciones de los controladores que llaman a las vistas, rellenando los datos proporcionados por el modelo de datos, asociado a tablas de la base de datos.

Los algoritmos de relación entre entidades se ejecutan a través de filtros de metadatos y se mantienen actualizados con metaprogramas y tareas automatizadas y mantenimiento, las búsquedas sin embargo se ejecutan mediante un híbrido entre los filtros like y match, jugando con los números de resultados para la toma de decisiones,difieren un poco frente a la búsqueda de entidades -similares- en que se usa una referencia citada por medio de categorías específicas.

Se construye el sitio web cumpliendo normativas básicas de XHTML válido -W3C – , compatible los navegadores más usados , opciones avanzadas y efectos en JavaScript, optimizado para posicionamiento (SEO), etiquetas opengraph, etc

Las páginas del sitio web se generan en unos milisegundos y se usan dominios y subdominios alternativos para aumentar la velocidad de carga mediante peticiones en paralelo ,esto es algo importante y mientras más se usa la web más fácil es de que sea cargarda en un instante mediante el uso de la caché del servidor y del navegador, sobre todo tratándose de este tema en el que los juegos flash pueden pesar bastante; de hecho la administración dispone de opciones a medida como la carga externa de datos desde una URL proporcionada.

 

Aunque el proyecto ha pasado a la fase final y entrega del mismo, sigue estando en desarrollo y continua mejora.

Características de administración:

  • Asistencia a la metaprogramación
  • Gestión de banners
  • Gestión de usuarios
  • Gestión de concursos
  • Visualización de estadísticas básicas
  • Edición de páginas dinámicas
  • Gestión de configuración del sitio

La parte cliente tiene:

  • Buscador basado en metadatos con diferentes algoritmos
  • Gestión inteligente de SEO (posicionamiento)
  • XHTML validado por la W3C
  • Uso de etiquetas para redes sociales y botones para compartir en estas
  • Sistema de plantillas para gestionar temas distintos
  • Interacción de usuarios siguiendo reglas básicas de publicación

En desarrollo:

  • Sistema de niveles y premios
  • otros

 

Cómo crear tu propio framework PHP especializado en un tema: Inventaria

Si alguna vez os habéis preguntado qué framework o qué gestor de contenidos utilizar, y no habéis llegado a ninguna conclusión quizás es porque lo que realmente necesitéis lo podéis hacer vosotros mismos con un poco de esfuerzo…y digo esto porque lo que necesitamos últimamente en la comunidad de programadores es gente que haga las cosas bien, gente como Pedro Luis, que nos regala el código de una web que tuvo que realizar en su trabajo. Pedro es Ingeniero Informático y le gusta hacer las cosas como un ingeniero debe hacerlas, con base y fundamento jeje

Nuestro amigo ha subido a su directorio lo que véis en el vídeo, el proyecto Inventaria, un motor de sitio web para organizar departamentos de un colegio, la tecnología que utiliza en su pequeño y humilde pero potente framework es: jQuery, PHP, mySQL y XHTML+CSS. Está pensada para que se pueda escalar fácilmente, añadiendo nuevas clases que harán de controladores y vistas…sí, le falta el modelo para completar el círculo del patrón MVC pero, quién necesita realmente un modelo cuando tienes el gestor de plantilla Smarty?… puede hacer el controlador y la comunicación con este sistema de plantillas de modelo al mismo tiempo? efectivamente, y así es como nuestro querido amigo Pedro lo ha pensado y ahora, sigamos viendo algo de código.

La estructura del sitio es algo que ya hemos visto en otros frameworks más famosos, primero tiene un index.php y por medio de un fichero .htaccess , redirige todas las peticiones menos multimedia a este script, que simplemente se conecta a la base de datos y renderiza la vista que la acción de la URL especifica, algo que todos conocemos:

//Extract Controller, Action and parameters from URL
  $query = $_SERVER['QUERY_STRING'];
  $request = explode('/', $query);
  $controller = (!empty($request[1])) ? $request[1] : 'main';
  $action = (!empty($request[2])) ? $request[2] : 'index';

y Pedro lo hace de forma muy inteligente y compactada, como véis es código que se entiende a la primera incluso las condiciones anidadas en una única línea. El motor o núcleo es tan sencillo que entra en esas menos de 100 líneas, un resultado de una acción se guarda directamente filtrado y procesado mediante el uso a la llamada de un controlador asociado creado en la variable $instance, que es la instancia de la clase perteneciente al controlador que la URL especifica…

 

include('controllers/'.$controller.'.php');
$instance = new $controller;
$result = call_user_func(array($instance, $action), $params);
$view = $result['view'];
$data = $result['data'];
 
render_view($view, $data);

aquí podéis ver que se carga el controlador, se crea la instancia de la clase y se procesa el resultado para llamar seguidamente al renderizador de la vista, que podría ser,al mismo tiempo cualquier otra clase, pero en este caso es smarty y cerramos el ciclo del patrón Modelo – Vista – Controlador de una de las maneras más simples que he visto en estos días jeje

Si profundizamos en el Controlador, veremos que implementa sólo dos, el encargado de la página principal y el que maneja las materias del departamento del colegio, y funciona casi como una capa por encima de la clase de la base de datos, es decir, hace las consultas de listados, modificaciones, inserciones o borrados fáciles sólo pensando un poquito.

Para instalarlo sólo hay que crear una base de datos ,poner los valores de configuración en index.php e install.php, que por simplicidad ni siquiera se ha creado un config.php jaja, y lanzamos este install.php, tras lo que podemos cargar la web en el navegador.

Para probar este software directamente en mi PC me he bajado el maravilloso paquete de MoWeS (Servidor Apache2+mysql5+php5+image-magick+phpmyadmin en 23MB), he descomprimido Inventaria en el directorio www/inv de MoWeS, después he creado una base de datos con juego de caracteres UTF8 con una instrucción sencilla en phpmyadmin:

 

CREATE DATABASE `inventaria` DEFAULT CHARACTER SET utf8 COLLATE utf8_bin;

y he puestos los datos de configuración en index.php e install.php

  $host = 'localhost';
  $dbname = 'inventaria';
  $dbuser = 'root';
  $dbpass = '';

para lanzar localhost/inv/install.php ,lo que me devuelve:

Creating departments data table...OK
Creating materials data table...OK
Creating constraints...OK
Creating departments data
---------------------------
Creating Religión table...OK
Creating Plástica table...OK
Creating Ciencias Sociales table...OK
Creating Tecnología table...OK
Creating Francés table...OK
Creating Latín table...OK
Creating Música table...OK
Creating Gestión Administrativa table...OK
Creating Física y Química table...OK
Creating Educación Física table...OK
Creating Biología y Geología table...OK
Creating Filosofía table...OK
Creating Orientación table...OK
Creating Matemáticas table...OK
Creating Lengua table...OK
Creating Inglés table...OK

con lo cual, ya tenemos todo, ya podemos entrar en localhost/inv/. Si queremos cambiar el directorio inv por cualquier otro sólo tendríamos que cambiar las referencias en las plantillas de inv al nuevo nombre, por ejemplo, “inventaria”.
A partir de aquí ,es tarea del lector avanzar el proyecto y enfocarlo hacia una web que trate de manzanas, cómics, o por qué no? una tienda o cualquier otra cosa!
Ya no tenéis excusa para hacer las cosas bien desde cero, tenéis el conocimiento en vuestras manos, usadlo sabiamente :)

Mención especial a Pedro por compartir con nosotros su código, gracias!

Crear una aplicación productiva y social para iOs con interfaz web

En este artículo cuento mi experiencia de creación de la aplicación de iOs TimeBox ,desde el estudio de mercado, diseño, y elaboración de la interfaz gráfica  hasta la programación, creación de la base de datos y la aplicación web para redes sociales.

Lo primero que debemos hacer es tener claro qué tipo de aplicación queremos crear, para eso hay que tener una buena idea, y si la tenéis pero la aplicación ya está hecha, entonces comprar/bajaros todas las aplicaciones que han implementado vuestra idea y estudiarlas para encontrar en qué fallan, cómo las podéis mejorar y combinar, es decir, encontrad una motivación para programar, porque esto es duro amigos jeje (más…)

Portal AJAX con el CMS PHP CodeIgniter y ExtJS

Recientemente he tenido que revisar un portal realizado con el gestor de contenidos ( CMS ) y framework PHP: CodeIgniter, como base y ExtJS como framework JavaScript para proporcionar los servicios de datos por medio del prototipo JSON. Dividiré el análisis en tres partes: Framework JavaScript, Base de datos y Aplicaciones PHP.

Framework JavaScript: Ext JS

Había encontrado algunos problemas, por ejemplo, si entramos en la web con un dominio sin las tres uves dobles, al estar configurado para el dominio con ellas, los ficheros fuente no eran bien referenciados y había errores por todas partes. Estos bugs se corrigieron fácilmente, pero hay que entender o bien por experiencia, por intuición o por inteligencia, de dónde vienen dichos problemas para poder solucionarlos.

El sistema a analizar tiene un directorio privado, sin embargo se ha de crear una lógica de roles de usuario y ficheros de acceso restringido o bien con PHP o bien con .htaccess para que ningún usuario no autorizado a una zona pueda acceder a la información privada que reside en regiones que no le pertenecen.

El primer error que encontré en el diseño de la aplicación no

estaba en la base de datos, ya que el diseño de entidad relación está correcto, dentro de lo que cabe , y he visto verdaderas barbaridades por ahí…como decía, el primer error es la propia interfaz de usuario, mirad este vídeo:

Comentarios:

Para empezar apenas hay espacio en la ventana al no poder quitarnos de encima los componentes que estorban para rellenar datos, hace falta añadir controles con los que ocultar las zonas laterales, como se hace con la zona inferior. Los botones de menú no se ocultan al pinchar sobre una opción y no se muestran mensajes de “cargando” ni información pertinente, de hecho si ocurre algún error este es ininteligible. El chat no funcionaba, aún así se está sincronizando contínuamente por lo que el ancho de banda que consume es considerable. Internamente no hay una verdadera lógica de programación para los roles de administrador representada en JavaScript, es decir, se mezclan los prototipos de todos los usuarios:usuario invitado, cliente, admin,etc. por lo que cualquier usuario que conociera las url o fuera un poco inteligente podría encontrar un mecanismo de operar con la base de datos de la web usando la ingeniería inversa y consultas en los scripts de JSON que además ya vienen en ficheros .js.

Más allá de mi opinión

Sobre si la decisión de usar Ext JS u otro framework JavaScript como JQuery la dejo a elección del programador porque realmente depende de cómo de cómodo te sientas escrbiendo las piezas del puzzle del portal, en este caso está bastante bien porque se utiliza Firebug para depurar PHP con una consola de estado de Ext JS. Aunque es un poco raro mezclar opensource con freesource, es una buena manera de construir un portal complejo, eso sí, siempre que tengamos claro qué es lo que queremos construir…

Un ejemplo de implementación

Veamos un ejemplo de cómo por medio de una vista del modelo MVC de CodeIgniter, construimos contenido JavaScript para alimentar una acción lanzada desde el portal, la bienvenida:
var Center = Ext.extend(Ext.util.Observable, {
constructor	: function(ui) {
this.ui = ui;
 
this.panel = new Ext.TabPanel({
	title		: 'Center',
        region		: 'center',
	activeTab	: 0,
	autoDestroy	: false,
	items: [
	{
	  title:'Bienvenido',
	  closable	: false,
	  bodyStyle	:'font-family:sans-serif;font-size:12px;',
	  html		:'[contenido]'
    }]
});
}
});

En [contenido] debemos colocar el contenido del componente, por ejemplo, un iframe o cualquier otro elemento html que queramos…

Por ejemplo, para añadir  una pestaña con lo que se debe mostrar de un cliente una opción es la siguiente:

MisClientes = Ext.extend(Ext.Panel,{
    // Prototype Defaults
    propA: 1,
	title: 'Mis Clientes',
	closable	: true,
	iconCls: 'icon-mis-clientes-tab',
 
    initComponent: function(){
        // Called during component initialization
this.fields =[
{name:'cliente', type:'string'},
{name:'nombre', type:'string'},
{name:'email', type:'string'}
];
this.storeGrid = new Ext.data.Store({
 reader:new Ext.data.JsonReader({
  idProperty:'cliente',
  totalProperty:'totalCount',
  root:'rows',
  fields: this.fields
 }),
proxy:new Ext.data.HttpProxy(
 {url: BASE_URL +
  'asignarEntrenador/load_clientes_asig'}),
 baseParams:{entrenador:USER_LOGGED},
 remoteSort:true
});
//...etc.

De esta forma hemos encapsulado toda la información de un cliente junto con los widgets que lo representan ,en un único objeto, sin embargo todo el trabajo no acaba ahí, hay que escribir también los prototipos de respuesta para cada una de las acciones, que devolverán otros widgets, elementos de sincronización, alimentadores de datos o datastores, etc. A partir de aquí hay que sumergirse en el mundo del framework Ext JS, y…
Para terminar con el análisis de la sección del framework JavaScript, las plantillas que este utiliza se han guardado separadas del motor PHP (framework CodeIgniter), esto es buena idea porque se puede actualizar fácilmente y además podríamos crear un subdominio para aligerar la carga de la web de forma que realizara las peticiones de todo el contenido JS en paralelo desde el navegador.

Base de datos

Hablando de la base de datos, como había comentado antes, no está nada mal, aquí vemos el diagrama de entidad/relación, los usuarios son la tabla principal del sistema y alrededor de ella se construye todo el conjunto de entidades que abordan las necesidades del cliente, el administrador ,etc.

Correcciones a aplicar sobre la base de datos: se debe modificar el campo usuario de la tabla de usuarios para que sea único, algunos tipos de datos son demasiado grandes para la información que almacenan, hay que tener en cuenta que cuando el número de usuarios crece y con esto también los datos asociados, la sinergía de nuestro servidor de base de datos depende tanto del número de transacciones como del volumen de estas y si estamos usando un framework que realiza una petición de todos los datos de un usuario para mostrarlos con datos asociados por cada prototipo de entidad, el volumen de estos datos genera un considerable tamaño de ancho de banda que puede ralentizar la aplicación. Para esto se construyen consultas que se guardan como vistas y otras consultas avanzadas como las que se pueden realizar con PL/SQL.

En principio la base de datos no necesitaba más cambios, sólo quedaba analizar si estaba preparada para la expansión, es decir, si era escalable, para probarlo, me ví en la tesitura de añadir una tabla que almacenara información relacionada con archivos compartidos entre usuarios de distintos privilegios, y en este caso no tuve ningún problema con la base de datos sino con el siguiente punto ,ya que la lógica de programación no estaba terminada, no había diferenciación fuerte entre roles y aquí fué donde me llevé la gran sorpresa de toda la jerarquía.

Framework PHP : CodeIgniter

El lector seguramente ,como programador sabrá que los tipados fuertes (objetos) siempre son adecuados para embeber información de un usuario, de modo que con una simple lectura de una propiedad de la instancia de la clase usuario->tipo sabremos qué tipo de usuario es…claro, la cosa se complica al tener que replicar la información en un framework como Ext JS, sabemos que podemos encriptar la información pero finalmente,para acometer una acción delicada debemos realizar la comprobación del nivel de privilegios de un usuario por duplicado: en el framework JS y en el framework PHP.

Llegados al punto en que la jerarquía MVC se abría ante mí, todo parecía el paraíso, hay modelos,

class Usuarios extends Model {
    public function __construct()
    {
        parent::Model(); // Call the Model constructor
		$this->table_usuarios = 'usuarios';
		$this->table_usuarios_tipo = 'usuarios_tipo';
		$this->table_session = 'dasm_sessions';
		//$this->load->library('firephp');
    }
 
	//TODO: Comprobar que es un admin
	function crear(){
//etc.

qué es eso “TODO: Comprobar que es un admin”?…sigamos analizando, hay controladores…bien!

class User extends Controller {
 
    public function __construct()
    {
        parent::Controller();
		if (function_exists('force_ssl')) force_ssl();
		$this->load->library('session'); 
 //iniciar libreria de sesiones
		$this->load->library('firephp'); //FIREBUG
		$this->firephp->log("force shhl");
    }
	public function index(){
		$this->login();
	}
 
    public function login()
    {
        if ($this->my_usession->logged_in)
        {
	 $this->firephp->log("login");
//....

es un poco extraño, -me digo para mí- , ahora es todo coser y cantar, pero no…me parece que el programador se acaba de ventilar toda la jerarquía de roles…además, no hay vistas asociadas,ni controladores en los hooks de C.I., pánico…todas las acciones se realizan por real decreto de…llamadas incoherentes dentro de ficheros javascript?…ok, he muerto, ahora he de renacer a la realidad…¿cómo arreglaríais este desastre organizativo?,

Opción básica A: operar sobre la chapuza a sabiendas de que cada vez se enredará más y más el código

Opción B sólo para los valientes: intentar arreglar toda la jerarquía de clases, añadir los hooks, la lógica de roles y rezar para que no haya ninguna incoherencia…en peores batallas hemos estado

Opción C: la gran elegida por el público y aclamada por todos los directores de proyecto solidarios con la causa del programador medio : rehacer el sistema, esta vez BIEN HECHO.

Conclusiones: ¿Cómo no habría sido un fracaso este proyecto antes de llegar a mis manos?

  • Empezando por el diseño del wireframe completo: diseñar la interfaz de usuario aplicación
  • Analizando las tareas a realizar con diagramas de casos de uso donde se vean reflejadas las acciones de cada rol de usuario
  • Construyendo el diagrama de clases en UML o en papel, me da igual pero dibujar, pintad, y luego desarrollar, eso es lo primero, proyectar lo que queremos , si queremos un pato proyectaremos un fantástico sistema de patos y eso es lo que obtendremos, si no sabemos lo que queremos, lo más probable es que el patito feo odiado por toda la familia tampoco lo quiera pagar el cliente
Y quizás, usar otra tecnología…¿Google? :’D

Conexión de la interfaz con el código fuente: XCode + Interface Builder | Objective C

Conexión de la interfaz con el código: aplicaciones de iOS

Un poco de teoría: Diseño de la aplicación

Guía de estilo para la interfaz de usuario: PDF.

MVC & Eventos

  • El patrón de ingeniería del software Modelo-Vista-Controlador actúa en base a clases que tienen la forma: el Modelo define las estructuras de datos, la Vista las ventanas, widgets, etc. que interactúan por medio de los Controladores que unifica los dos anteriores y en sus acciones determina cómo manejar los eventos.
  • Estos eventos pueden ser de varios tipos: un gesto (o gesture: secuencia de eventos desde que el usuario toca la pantalla hasta que deja de hacerlo), toque (touch: el dedo está en la pantalla) y el clásico click o tap que es cuando el usuario toca la pantalla por un instante. A los eventos se les captura por medio de una cadena de clases UIResponder,

    que responden una a una, esto se logra con la herencia (subclases de UIView, UIControl,etc.)

    siendo la primera de las instancias que responden la que interactúa con el usuario. Lo que se hace una vez despachado el evento por el primer Responder es redirigirlo al siguiente respondedor a mano con la función “nextResponder”.
  • Podemos controlar los eventos de tipo Touch, siendo estos pertenecientes a una vista sobrecargando la función “touchesBegan”, capturando así el inicio de la interacción:
    – (
    void) touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {
    NSUInteger
    numTaps = [[touches anyObject tapCount;
    NSUInteger
    numTouches = [touches count;
    }

    Podéis seguir investigando con métodos como touchesMoved, touchesEnded y touchesCancelled. Con locationInView obtenemos la posición del touch.
    Más información >
  • Tipos de gestos: swipe (sigue la acción del usuario en un eje determinado, puede implicar dragging o arrastrar y soltar -UIPanGestureRecognizer-) -> UISwipeGestureRecognizer, tapping (cualquier número de toques) -> UITapGestureRecognizer, pinching (acercar o alejar dedos para zoom por ejemplo),  rotating (mover dedos en direcciones opuestas) -> UIRotationGestureRecognizer y long press (tocar y mantener) -> UILongPressGestureRecognizer. Todas estas clases reconocedoras son utilizables por medio de la declaración de una clase (entre paréntesis) asociada a la ventana UIWindow (que está asociada a una UIApplication al mismo tiempo) y hace posible la gestión de estos eventos:
    Los posibles estados con sus transiciones:
    Evidentemente ,un gesto contínuo lanzará varios eventos para poder hacer un seguimiento del mismo, mientras que uno discreto sólo tendrá un evento.
  • Los eventos de movimiento están encapsulados por el objeto CMAccelerometerData que guarda en una estructura la aceleración sobre cada uno de los ejes espaciales. CMGyroData guarda datos sobre la velocidad y CMDeviceMotion encapsula varias medidas, incluyendo la postura, rotación y aceleración. El acelerómetro se ha de configurar antes de usarse, con la clase UIAccelerometer definimos los parámetros.
  • La orientación se obtiene con la clase UIDevice invocando el método beginGeneratingDeviceOrientationNotifications, hay un begin y un end para gestionar la secuencia.
  • El tipo de eventos que necesitan recoger información de los sensores del giroscopio y el acelerómetro deben ser los primeros en responder por lo que usamos la función canBecomeFirstResponder de una vista y si tenemos permiso entonces activamos con beginReceivingRemoteControlEvent,y desactivándolo cuando no se use la vista con resignFirstResponder.
  • Éste es el ciclo de vida de una aplicación, podemos ver como se enmarca la gestión de eventos justo en mitad del loop de eventos:

Recordemos MVC

  • El modelo encapsula el estado de la aplicación, contiene los datos, notifica de cambios, etc. La vista representa en pantalla los modelos, pide actualizaciones de estos, envía gestos al controlador, permite al controlador seleccionar una vista, etc. Y el Controlador define el marco de la aplicación, selecciona una vista para la respuesta a una petición, etc.

    ahora la versión de Cocoa:
    si combinamos el MVC con la aplicación, el modelo de datos y las vistas de cocoa junto con los controladores, esto es lo que obtenemos:
    Con este patrón podemos separar el código en función de lo que hace.
  • Como hemos visto, los controladores no deciden totalmente lo que hacer con las vistas sino que son estas las que les dicen cuáles pueden utilizar, lo cual no es totalmente un patrón MVC sino Modelo-Vista-Presentación, aquí tenéis el esquema real del funcionamiento actual de una aplicación en iOS:

    que se puede ver así representado :
      

    Leer más acerca de la diferencia entre MVC y MVP »

Conexión del constructor de interfaces (I.B.) con las vistas: los controladores de las vistas y los modelos

Controladores de las Vistas

Sabemos que una instancia de una clase controlador tiene la lógica que une los datos de un modelo de una aplicación con las entidades visuales usadas para presentarlos al usuario en el dispositivo. En iOS ,los controladores de las vistas o View Controllers, son objetos que heredan de la clase genérica de Objective C llamada UIViewController. Gracias a los controladores de las vistas definimos el comportamiento de las interfaces de usuario, podemos encontrar tres tipos de controladores de vistas:

  • Custom View Controller: para representar a “nuestra manera” la información, es algo más personalizado; se usa en listas de elementos, presentaciones de estos, propiedades, etc. ( ejemplos: de un UITableViewCell -> UIViewController)
  • Container View Controller: sirven para embeber dentro a otros controladores de vistas, definiendo relaciones de navegación entre ellos, suelen utilizarse de forma automatizada los que trae el sistema por defecto (ejemplos: UITabBarController, UINavigationController), establecen relaciones entre controladores
  • Modal View Controller: describen las relaciones entre controladores y cómo modifican la representación de los datos, puede ser utilizado por cualquier controlador (en realidad es un modo de funcionamiento, la ventana modal, que no permite continuar con el resto de la aplicación hasta que se ha cerrado la vista/ventana modal)

Por dónde empezar

  • Hemos visto que los eventos se gestionan en mitad del ciclo de vida de una aplicación, lo que pasa antes y después se puede controlar por medio del denominado “Application Delegate”, que no es otra cosa que los eventos que ocurren antes ,durante y después del inicio de una aplicación. XCode genera por defecto los archivos {nombre_proyecto}AppDelegate.h y .m que contienen el código que se ejecuta cuando la aplicación se lanza y finaliza, aprovecharemos estas funciones para cargar datos, inicializar componentes, etc. Luego sólo cargar la aplicación, este es el esquema de funcionamiento de iOS:
    una vez cargada, puede pasar al estado en segundo plano, de modo que quedaría así:
    si,ahora es cuando deberíamos programar los eventos de la clase {loquesea}ApplicationDelegate para  descargar memoria o realizar tareas de sincronización mientras trabaja en segundo plano…ya hablaremos de eso más adelante en el capítulo de multitarea…podéis leer más acerca de la implementación de funciones en el marco común de comportamiento de la aplicación aquí. Ahora debemos reemplazar el esquema de ciclo de aplicación que vimos antes en los eventos por el nuevo esquema en segundo plano:
    y si aún no os queda muy claro, podéis echar un vistazo a este esquema:
    sacado de cocoanetics: understanding iOS 4 Backgrounding and delegate messaging

Creación de interfaces con el Interface Builder

Conceptos básicos

  • Las interfaces se guardan en ficheros .XIB que es un XML y puede editarse a mano aunque para eso está el editor visual :)  Cuando se compilan se genera un NIB que puede usarse para inicializar una vista.
  • La manera en que utilizamos los widgets, ventanas, vistas y demás objetos en el código es a través de un outlet (llamado IBOutlet en el código), tenemos que definir una variable con este apóstrofe y luego el tipo que sea, normalmente se llaman UI___ por lo que es fácil distinguir las clases de la interfaz. Al posponer la palabra clave IBOutlet a una variable no modifica ni su contenido ni su comportamiento, pero avisa al compilador y al I.B. de que puede ser conectada a un objeto de interfaz incluído en el XIB asociado a dicha clase
  • Para definir acciones, es decir, funciones que se puedan activar a través de un evento generado por un elemento de la interfaz (de una vista), utilizamos las bien denominadas IBAction en el código, en este caso el prefijo que se utiliza para definir una función es como un tipo de dato, por lo que si afecta a la declaración de una función ( y no se pueden utilizar dos tipos seguidos en la declaración, recordemos Objective C ) . IBAction indica al editor de interfaces que la función se utiliza por objetos para eventos concretos, como pueda ser, pulsar un botón o cualquier otro…

Interface Builder: ¿qué es?

  • Editor que provee de una paleta de objetos para el interfaz de programación con Objective C
  • Objetos asociados: cada .xib tiene una clase asociada, este objeto dentro de la ventana de edición de interfaz se llama “File’s owner”, y si recordamos lo que era el first responder, pues este objeto representa al que el usuario tiene asociado para interaccionar, lo mismo pasa con View, que es la vista principal de la clase. Para realizar las asociaciones usamos el botón derecho del ratón y arrastrando y soltando asignamos los outlets y actions que hayamos definido en el código ( Ver ejemplo de asociación )

    …simple
  • Gracias a la ventana de la biblioteca de objetos podremos arrastrar y soltar los widgets, vistas, etc. que necesitemos y por medio del inspector editamos los atributos de estos, podemos escribir una clase que luego sea la que controle un objeto (aquí la definimos)

Ejercicio:

Escribe un proyecto nuevo View-Based, abre la vista principal y crea una label, desde el código crea una asociación con un atributo -> propiedad con el prefijo IBOutlet, asóciala en el I.B. y luego en el evento de recién cargada la aplicación (appdelegate -> didlaunch with options) accede a dicho objeto de la interfaz para establecer el texto “Hola mundo”, algo sencillo, puedo corregírtela si me la envías en el formulario de contacto.

<< Volver al curso de programación de aplicaciones de iOS

Siguiente: Persistencia de datos en iOS y Google Web Toolkit (Google App Engine) >>

Programación rápida y avanzada con SilverStripe

SilverStripe es un gestor de contenidos (o CMS: Content Managed System) avanzado de código abierto, especialmente diseñado para que los diseñadores puedan trabajar en colaboración directa con los programadores funcionando independientemente el uno del otro pero relacionados por mecanismos automáticos simplificados que pueden extenderse ilimitadamente.
Podemos probar una demo del producto aquí y descargarlo aquí.

Está escrito en lenguaje PHP y es compatible con servidores IIS, Apache, etc.

A mi modo de ver las cosas me resulta muy parecido a Django, ya que hace uso del patrón de ingeniería del software: MVC (modelo-vista-controlador)

y los elementos de la base de datos y de la administración se generan automáticamente a partir del código, de hecho existe un script que lee las clases que hemos escrito en búsqueda de la variable de base de datos donde se especifican los campos y sus tipos, de forma que actualiza la estructura de aquella para que se puedan realizar altas/bajas/modificaciones con sólo añadir una línea en el código de la parte de administración de una sección del contenido de una página, después se crea una plantilla y se utilizan dichos campos con sólo llamar a la variable con el nombre del campo especificado.

Para conocer los entresijos de la programación con SilverStripe, los creadores han dispuesto un subdominio de ayuda con tutoriales que van desde las tareas de código más simples hasta las más avanzadas, por ejemplo, en mi caso he utilizado este manual para crear una homepage distinta a la que trae por defecto y ha funcionado a la primera…una gozada,podemos crear todos los tipos de páginas que queramos con sus secciones, por ejemplo una sección de productos sería una página donde sus elementos de base de datos son un conjunto…lo que se llama un data object (que hereda de sitetree) generando un data collation, aquí en la imagen vemos una sección de noticias con artículos donde se define una clase contenedora de artículos a la que se le permite tener “hijos”, otra clase para los artículos y se relacionan entre sí

Como características curiosas, trae un gestor de comentarios para cada página y un generador de RSS…, pero lo más curioso es que el CMS se divide en 6 partes bien diferenciadas o directorios principales:

  1. en assets se guardan los ficheros subidos,
  2. en cms se encuentra el backend o administrador de contenidos,
  3. en mysite se colocarían nuestras clases, código PHP y JavaScript
  4. en sapphire podemos encontrar el frontend o cliente
  5. en themes se encuentran las plantillas XHTML+CSS, la caché ,etc.
  6. en el directorio principal, cualquiera de los otros directorios que no sea uno de los anteriores ,se trata de un plugin, módulo o extensión del cms que especifica las acciones tanto para el frontend como para el backend

Código

Este trozo de código especifica la clase para los artículos de una sección de noticias:

class ArticlePage extends Page {
static $db = array(
'Date' => 'Date',
'Author' => 'Text'
);
static $has_one = array(
);
 
function getCMSFields() {
$fields = parent::getCMSFields();
 
$fields->addFieldToTab('Root.Content.Main', new DateField('Date'), 'Content');
$fields->addFieldToTab('Root.Content.Main', new TextField('Author'), 'Content');
 
return $fields;
 
}
}
 
class ArticlePage_Controller extends Page_Controller {
 
}

El modelo ArticlePage hereda de Page y tiene un controlador ,pero además necesita un decorador, en el caso en que no se especifique se utiliza el asociado al padre Page. (Ver listado de tipos de datos)

Para la gestión de los campos en la administración se utiliza la función getCMSFields() heredada de Page y se le añaden nuevos campos, aparecería algo así como resultado:

Veamos un ejemplo sencillo de código fuente de GoogleSiteMaps incluído en la versión 2.4.1 que es probado aparece el siguiente trozo de código:

 
class GoogleSitemapDecorator extends SiteTreeDecorator {
 
function extraStatics() {
return array(
'db' => array(
"Priority" => "Varchar(5)",
)
);
}
//...

esta clase se usa para “decorar” ,es decir, para especificar al controlador con qué vista va a pintar los datos del modelo de datos tanto para el front como para el backend, además se está especificando un array para la generación de los campos de la base de datos desde el exterior…

Para tener una introducción más completa, aquí hay un vídeo que os puede interesar:

SilverStripe 2.4 Site Editing Overview from SilverStripe on Vimeo.

Página 1 de 212
footer
jbelon © | sitemap.xml