Este proyecto sirve para cualquier especialista que necesite llevar un registro de pacientes, a saber: sus visitas, datos personales, pruebas, etc., es decir, todo lo referente a una historia clínica.
Mantiene información actualizada visualizando en primer lugar lo que el especialista necesita para trabajar, en este caso, como se puede ver en el vídeo, los “evolutivos” de un paciente, y los datos asociados a su historia.
Al ser una aplicación AJAX se pueden hacer cambios muy rápidamente, cosa que se agradece cuando se necesita agilizar el proceso de atención de una persona en un despacho.
Veamos el vídeo:
La aplicación dispone de un usuario y password para mantener la privacidad, una vez dentro el especialista puede gestionar los pacientes añadiendo datos como, nombre y apellidos, una fotografía, fecha de nacimiento,etc., y por supuesto, la información adicional que sea necesaria, el cliente en este caso me pidió poder editar:
La aplicación puede modificarse a placer o incluir cualquier detalle adicional, está pensada para trabajar con módulos que se van añadiendo y se comunican entre sí.
Como algo opcional, el calendario está diseñado para operar cambios en las citas del especialista arrastrando y soltando, en el escritorio podemos ver los últimos pacientes que hemos citado, los que hemos visto más recientemente, los que tenemos más graves, las tareas pendientes, eventos de nuestra agenda, etc.

Guía de uso del Modelo de Datos de iOS:
Podéis ver que el editor trae un soporte para la vista de un bonito Diagrama de Entidad/Relación de nuestra BD.//Crear y configurar una instancia de una entidad Event - (void) createEvent { Event *event = (Event *) [NSEntityDescription insertNewObjectForEntityForName: @"Event" inManagedObjectContext: managedObjectContext]; //Crear un tipo de dato coordenada para mapas de google, así nos acostumbramos a usarlos: CLLocationCoordinate2D coordinate = CLLocationCoordinate2DMake(37.123123, -3.321321); //Ahora lo tenemos muy fácil ,sólo tenemos que usar los setters y getters generados por XCode: [event setLatitude:[NSNumberWithFloat:coordinate.latitude]]; [event setLongitude:[NSNumberWithFloat:coordinate.longitude]]; [event setCreationDate:[NSDate date]]; //"date" es la fecha de hoy [event setTitle:@"Mi primer evento"]; }
y eso sería todo el código, ahora pasamos a grabar los datos para hacerlos persistentes
NSError *error; if ([managedObjectContext save:&error]){ //prestar especial atención al ampersand... //referencia de memoria! //Gestión del error aquí }
Podemos intentar capturar errores con una captura de excepciones (@try { } @catch (NSException *exception) { } @finally { } ) pero esto no es recomendable, además de que debemos recordar la cadena de respondedores, aquí se aplica el mismo cuento y tendríamos que ir hacia arriba en la lógica de la programación para capturar la verdadera excepción de la pila de llamadas…cosa que es bastante tediosa, por eso es mejor pensar las cosas bien y hacerlas mejor jeje, con la práctica todo se consigue ;)
Fetch Request -> execute!

Si queremos recuperar el objeto no tenemos más que usar, como se hace en php y mysql una petición tipo “fetch”, es decir, con NSFetchRequest especificamos la entidad, aquí tenéis un ejemplo completo.
En resumidas cuentas, hay que crear un objeto NSFetchRequest, reutilizamos el objeto de la descripción de una entidad y asociamos esta al primero con setEntity:
NSFetchRequest *request = [[NSFetchRequest alloc] init]; //cuidado que esto no se libera. lo hace sólo...:O NSEntityDescription *entity = [NSEntityDescription entityForName:@"Event" inManagedObjectContext: managedObjectContext]; [request setEntity:entity]; //Para realizar un ORDER BY fecha típico usamos un descriptor de ordenación: NSSortDescriptor *sortDescriptor = [[NSSortDescriptor alloc] initWithKey: @"creationDate" ascending:NO]; NSArray *sortDescriptors = [[NSArray alloc] initWithObjects:sortDescriptor, nil]; [request setSortDescriptors:sortDescriptors]; //ahora sí, liberamos los descriptores [sortDescriptor release]; [sortDescriptors release]; //Con todo configurado, vamos a ejecutar la consulta y // guardar el resultado en una matriz modificable: NSError *error1; //Atención al parámetro "mutableCopy"!! NSMutableArray *results = [[managedObjectContext executeFetchRequest:request &error1] mutableCopy]; if ( results == nil ){ //Manejar el error! } //Para borrar necesitamos un NSError igual que cuando guardamos con save NSError *error2; [managedObjectContext deleteObject:objetoEventoParaBorrar]; if (
Recordamos del curso de servicios web que escribir XML y código de un servicio web no es tarea de humanos, para eso existen frameworks que harán el trabajo duro por nosostros, Fremont es la parte cliente, en Objective C, para la parte del servidor tenemos los transformadores que ya vimos, BPEL, etc.
Gracias al uso de un servidor asociado a Google App Engine, crearemos un conjunto de servicios usando Google Web Toolkit 2.3.0 , que una vez probados en red local podremos desplegar en el servidor Java de GAE asociado a nuestra cuenta de usuario.
Pasos para la creación de un servidor de datos por medio de servicios web con Eclipse:

resp.setContentType("text/html"); PrintWriter out = resp.getWriter(); out.println("< !DOCTYPE HTML PUBLIC \"-W3C//DTD....."); //etc
Una vez que hayamos creado nuestras inicializaciones de datos de nuestro modelo (instanciado las clases oportunas), debemos guardarlos usando un gestor de Persistencia, lo que viene a ser una clase de JDOHelper.getPersistenceManagerFactory(“transactions-optional”); que por medio de la función makePersistent(clase_instanciada) se almacenará (después debemos hacer un close(), claro jeje)
Como ya hemos visto antes el funcionamiento de la persistencia de datos en iOS con un Modelo de Datos, pasaré directamente al análisis de un XML, aunque esto debería hacerse automáticamente con un framework como Fremont, lo importante es que os quedéis con que las clases que permiten estas tareas son NSURL, NS/Mutable\URLRequest,y NSURLConnection. Estas descargan los datos y podemos realizar el análisis sintáctico con varios tipos de "parser", SAX: envío de notificaciones a medida que el analizador sintáctico va leyendo la cadena XML recibida por NSURL, o bien DOM: es un analizador que lee toda la cadena XML y construye su representación completa. Para utilizar estos analizadores debemos incluir al proyecto el fichero libxml2 de las librerías del SDK (tanto SAX como DOM), o bien NSXMLParser (sólo SAX). Aunque existen alternativas como TBXML, TouchXML, KissXML, TinyXML, GDataXML, etc. --> ver comparativa >>
NSXMLParser *parser = [[NSXMLParser alloc] initWithData:xmlData]; //recibidos por NSURL
[parser setDelegate:self];
A partir de aquí, se trata de usar los eventos del delegado (eventos de NSXMLParserDelegate) que son: didStartElement -> empieza un elemento, didEndelement, didStartDocument, etc. de forma que al principio del documento inicializamos los datos (un array modificable, por ejemplo), y cada vez que encuentra un elemento de tipo titulo pues añade un elemento al array y luego al terminar un elemento de tipo evento, pues añade el array de propiedades de un evento al array de eventos...fácil...Importante implementar también la función:
- (void)parser:(NSXMLParser *) parser parseErrorOccurred: (NSError *)parseError;

La utilización de caché tanto para datos persistentes como para datos dinámicos es importante a la hora de realizar aplicaciones para móviles ya que está muy penalizado el uso de conexiones a Internet, es más rentable llegar a un equilibrio de carga de datos entre el servicio web y los usuarios de los dispositivos, por eso os presento las dos tareas a realizar en un proyecto serio...
En esta dirección encontraréis un framework sorprendente para realizar tareas con análisis sintácticos de XML, descarga de datos a través de urls, caché, etc.
Es una maravilla ver como funcionan los ejemplos, hay uno,especial de caché en el que se dispone una serie de descargas de imágenes y a cada una de ellas se le asocia un puesto en una clase cola-de-espera que tiene asociada una barra de progreso por lo que va actualizando el estado conforme se van descargando los datos...impresionante :)
Lo que podéis hacer es utilizar una caché para guardar la información en un modelo de datos, durante unos días en el iDevice, pasados esos días, vuelve a sincronizarse con el servicio de Google App Engine y reescribimos toda la estructura de datos del programa con nueva información, así nos ahorramos realizar peticiones al servidor continuamente, lo que ralentizaría mucho la carga y si la aplicación es muy usada puede generar un cuello de botella que ha de evitarse.
Para hacer esto nos viene bien los datos de configuración de un usuario, lo veremos en la próxima entrega del curso de aplicaciones para iOS, aquí mismo.
Recordar que podéis utilizar recursos como http://wiki.gnustep.org y http://stackoverflow.com/ para solucionar vuestras dudas tanto con Objective C como con Java Google App Engine y GWT.
En cualquier caso, los ejercicios de esta entrega están claros cuáles son: desplegar una aplicación en GAE con GWT y pasar los datos a un modelo de datos de XCode (SQlite)...hay cientos de tutoriales en internet sin embargo si tenéis cualquier duda, mandadme el fichero y lo intentaré corregir.
<< Volver al curso de programación de aplicaciones de iOS | Siguiente lección: Configuración y traducción de una aplicación de iOS >>
En el año 2007 se realizó la programación de esta web se hizo con el prototipo 0.1.2.7 de zenphp, las plantillas XHTML + CSS son validadas por la herramienta de la W3C.
Mediante la ayuda de la administración interna es posible editar el contenido de la base de datos que se muestra en el cliente.
Se realizan validaciones para formularios en AJAX, en cuanto a la administración, además se permite la creación rápida de categorías para platos, y otros parámetros avanzados, etc.
Las plantillas XHTML + CSS se crearon por Agencia Q4 en el 2007.
Los distintos dominios comparten la misma base de datos y un sistema de aplicaciones web hace que la informacion fluya a través de los distintos artículos haciendo uso de un algoritmo sencillo de etiquetas (tags) que conectan los contenidos que tienen relación entre sí. Las tecnologías usadas son propias de las webs 2.0, menús animados, transiciones de imágenes, validaciones en formularios, lightbox 2.0,etc. La administración se hace desde un único sitio y es para una base de datos compartida entre dominios así como el servidor de imágenes, esto hace que se carguen más rápidamente las páginas debido al procesamiento en paralelo, i.e., la descarga de todos los contenidos de la web simultánea por el navegador.
Ver vídeo en youtube con explicaciones
El diseño de la web se hizo por Agencia Q4.