Enero

2010

DesarrollodeunaaplicaciniPhone parainteractuarconunavivienda domtica.

CarlosSerranoGaliana
ProyectoFinaldeCarreradirigidoporJoanFonsiCors.

EscuelaTcnicaSuperiordeIngenieraInformtica.UPV.

 Tabladecontenido
1.Introduccin...........................................................................................................4 1.1.Motivacin ........................................................................................................................................................ 4 1.2.Contextoytecnologa................................................................................................................................... 4 1.2.1.Domtica ........................................................................................................................................................4 1.2.2.TerminaliPhone..........................................................................................................................................5 1.3.Propsitosyobjetivos ................................................................................................................................. 6 2.Entornotecnolgico ...............................................................................................7 2.1.Desarrolloparadispositivosmviles.................................................................................................... 7 2.2.iPhoneOS .......................................................................................................................................................... 8 2.2.1.ArquitecturadecapasdeliPhoneOS .................................................................................................8 2.2.2.DesarrolloparaiPhoneOS .....................................................................................................................9 2.3.Herramientasdedesarrollo:iPhoneSDK..........................................................................................11 2.3.1.Xcode ............................................................................................................................................................. 13 2.3.2.InterfaceBuilder ...................................................................................................................................... 14 2.3.3.Instruments ................................................................................................................................................ 15 3.Casodeestudio:Anlisis. .....................................................................................17 3.1.Objetivosyrequisitosdelaaplicacin. ..............................................................................................17 3.1.1.Objetivobsicodelaaplicacin. ....................................................................................................... 17 3.1.2.Especificaciones,requisitosyfuncionalidades............................................................................ 17 3.2.Casosdeuso ...................................................................................................................................................18 3.3.Diagramadeclases......................................................................................................................................20 4.Diseo..................................................................................................................22 4.1.Diagramadeclasesampliado. ................................................................................................................22 4.1.1.Clasesdemodelizacindeinformacin. ........................................................................................ 23 4.1.2.Clasescontroladoresdevistas............................................................................................................ 25 4.1.3.ClasederecorridodelXML .................................................................................................................. 27 4.1.4.Clasedelegadodelaaplicacin......................................................................................................... 28 4.2.Cargadedatos:EsquemaXML ...............................................................................................................28 4.3.Interaccinconlasviviendasfsicas....................................................................................................31 4.4.Interfazgrfica ..............................................................................................................................................32 5.Prototipoyimplementacin.................................................................................33 5.1.Elprototipo:Unaviviendaeficiente. ...................................................................................................33 5.1.1.Tiposdeelementosdomticos. .......................................................................................................... 34 5.1.2.Elementosdomticosydistribucin................................................................................................ 34 5.2.Interfacesdeusuario..................................................................................................................................36 5.3.Cargadelprototipo.DefinicinenXML .............................................................................................40 5.4.Descripcindelaimplementacin .......................................................................................................42 6.Problemasencontradosydesarrollosfuturos. .....................................................49 6.1.Dificultadessurgidas ..................................................................................................................................49 6.1.1.Lacreacinyalmacenamientodelainformacin .................................................................... 49 6.1.2.Elementosdevariostipos..................................................................................................................... 50 6.2.Posiblesmejorasydesarrollosfuturos ..............................................................................................51 6.2.1.Informacinalmacenadaenbasesdedatos................................................................................ 51 6.2.2.Informacindeestadodeloselementos........................................................................................ 52 6.2.3.Interfazgrficaalternativa ................................................................................................................ 52 2

6.2.4.Pantalladeconfiguracin.................................................................................................................... 54

7.ANEXO1.Pordndeempezar ..............................................................................55

1.Introduccin
El presente documento constituye la memoria del Proyecto Final deCarrerarealizadoporCarlosSerranoGaliana,alumnodelaantigua Facultad de Informtica de la Universidad Politcnica de Valencia (nuevaEscuelaTcnicaSuperiordeIngenieraInformtica). El PFC desarrollado tiene como ttulo Desarrollo de una aplicacin iPhone para interactuar con una vivienda domtica y ha sidodirigidoporJoanFonsiCors,profesoradheridoalDepartamento deSistemasInformticosyComputacin.

1.1.Motivacin
LaseleccindeesteproyectocomomiPFCvienederivadademis intereses personales tanto por la tecnologa involucrada como por la relacinconelmundodeladomtica. Poseo un terminal iPhone y siento una gran curiosidad por su tecnologaysusposibilidadestcnicas.Asmismo,tuvelaoportunidad de realizar un Erasmus Intensive Programme sobre inteligencia ambientalquemeintrodujoenelreadeladomtica. Aunando estos dos intereses, compartidos por mi director de proyecto, naci la propuesta de este PFC, con el que pretendo iniciarme en el desarrollo de aplicaciones para dispositivos mviles, obtener una visin del iPhone desde la posicin del desarrollador y ahondarenlasmotivacionesyposibilidadesdeladomtica.

1.2.Contextoytecnologa
1.2.1.Domtica La Wikipedia define la domtica como el conjunto de sistemas capaces de automatizar una vivienda, aportando servicios de gestin energtica,seguridad,bienestarycomunicacin.Ladomticanoessi nounaramamsdelacienciaydelatecnologaalserviciodelhombre,
4

quepretendenfacilitarohacermscmodasuvidadiaria.Desdehace aossevienenrealizandoprogresosenesterea,proponiendonuevas tecnologas y implantando estndares para que, poco a poco, se conviertaenunarealidadextendidaalmbitocotidiano. En el presente proyecto, se ha hecho uso de la experiencia del directorenestembito.Sehautilizadounamaquetadeunavivienda eficiente desarrollada con el estndar europeo para domtica, EIB/KNX, como escenario de simulacin de una vivienda rural, y la gestindelamismadesdeunaaplicacinservidordesarrolladaenun laboratoriodeinvestigacindelDSIC. 1.2.2.TerminaliPhone El iPhone es un dispositivo mvil desarrollado por la multinacional Apple que combina tres productos en uno: un telfono mvil,unreproductordemsicayvdeoyundispositivodeaccesoa Internet.Elterminal,porsucuidadodiseo,susencillezdemanejo,sus caractersticastcnicas(incluidasupantallatctil)ysusinnumerables funcionalidades se ha convertido rpidamente en un referente en el mercadotecnolgico. As mismo, el desarrollo de aplicaciones para este terminal est a la orden del da. Un kit de desarrollo software (SDK) propio de la marca permite a un programador crear aplicaciones que corran bajo el sistema operativoiPhoneOSqueutilizael dispositivo. La propia casa permite comercializar a travs de su tienda online (App Store) las aplicacionesdesarrolladasporterceros,loquedotadeundinamismoy unaprofundidadalmercadoquelohacenmuyinteresante. En concreto, la programacin para esta terminal se realiza utilizando el entorno de desarrollo Xcode y el lenguaje de programacinObjectiveC.

1.3.Propsitosyobjetivos
Elproyectoconsisteeneldesarrollodeunaaplicacindecontrol para vivienda domtica para un dispositivo mvil, pero con la dificultadyposibilidadesaadidasqueofrecelaprogramacinparael terminalmviliPhonedeApple. Enesteproyectosedesarrollarunainfraestructuraquepermita crear interfaces de usuario para controlar sistemas domticos, en los que la interfaz permitir ubicar los servicios y dispositivos de la(s) vivienda(s), as como utilizarlos y definir las diferentes ubicaciones o sectoresdelaviviendaparaaccederaestosrecursos. El usuario debe poder pues, crear los entornos (viviendas) domticos, con los diferentes elementos y distribucin que considere oportunos,yutilizarlaaplicacinparalanavegacinintuitiva,sencilla y completa que permita el uso de los diferentes dispositivos y servicios. No obstante, cabe destacar que este proyecto no se centra en la realizacin de la aplicacin en s, si no que se lleva a cabo con la finalidad de aprender a desarrollar aplicaciones para dispositivos mviles y explorar las posibilidades y caractersticas de la tecnologa iPhone y iPhone OS. La aplicacin desarrollada sirve pues como prototipo y primer paso para el desarrollo de aplicaciones relacionadasconladomticaparadispositivosmvilesiPhone.

2.Entornotecnolgico

2.1.Desarrolloparadispositivosmviles.
Los dispositivos mviles han evolucionado enormemente en los ltimos tiempos, desde PDAs hasta Smart Phones, estamos siendo testigos del boom de las tecnologas mviles. Esta evolucin ha permitido y provocado el crecimiento exponencial de las aplicaciones desarrolladasespecficamenteparaestossectores,yelmercadodelas mismas. Sin embargo, se trata de un sector muy especfico, con unas posibilidadesylimitacionespropias. El desarrollo de aplicaciones para dispositivos mviles supone un reto para cualquier programador acostumbrado a la programacin de aplicaciones de escritorio, o incluso de aplicaciones web. Las diferencias entre las capacidades tcnicas son abismales,yestosuponeunaseriede factores a tener en cuenta a la hora de plantearse el desarrollo de una aplicacin mvil. Lo ms importantesson: Memoriayprocesamiento Es imprescindible tener en cuenta las limitaciones de los dispositivos mviles en estos aspectos. No disponemos de los mismos recursos que nos encontraramos en un ordenador tradicional, y por tanto a la hora de la programacin hay que tener cuidado de no sobrepasar las capacidades tcnicas de nuestro terminal. Las aplicaciones mviles tienden a ser ms sencillas y con procesos ms concretos que sus homlogas de escritorio. Una palabra define a la perfeccin este concepto: optimizar. Interfaz El tamao de los dispositivos y de las pantallas de los terminalesmvileshadeserunfactorconsideradoalahorade disearlainterfazdenuestraaplicacin.Unentornocompletoy bien desarrollado para un escritorio puede ser totalmente
7

inviable para un terminal mvil. La sencillez en el diseo y la intuicin del uso son requisitos para este tipo de aplicaciones. Por otra parte, algunos terminales como el iPhone brindan nuevas posibilidades como las pantallas multitctiles o los acelermetros. Almacenamiento Pese a los avances en este aspecto en los ltimos tiempos, los dispositivos mviles todava tienen una restriccin notable en cuanto a espacio de almacenamiento disponible. Hay que cuidar en el desarrollo la cantidad de informacin a almacenar en el terminal, y buscar siempre posibles alternativas para reducirestasnecesidades.

2.2.iPhoneOS
iPhone OS comprende el sistema operativo y las tecnologas utilizadasparacorreraplicacionesnativasenlosdispositivosiPhoney iPod Couch. Muy relacionado con Mac OS X, iPhone OS fue diseado para cumplir con las necesidades de un entorno mvil, donde las necesidadesdelusuariosonligeramentediferentes. 2.2.1.ArquitecturadecapasdeliPhoneOS EniPhoneOS,laarquitecturadesistemasubyacenteymuchasde lastecnologassonsimilaresalasencontradasenMacOSX.Elkernel en iPhone OS est basado en una variante de la misma base que el kernel de Mac OS X. Por encima de este kernel estn las capas de serviciosutilizadasparaimplementaraplicacionesenlaplataforma. Estaestructuradecapasexpandelasposibilidadesalimplementar cdigo. Por ejemplo, las capas Core OS y Core Services contienen las interfaces fundamentales para IPhone OS, incluyendo aquellas utilizadasparaaccederaficheros,tiposdedatosdebajonivel,sockets dered,etc.EstasinterfacesestnbasadasenCyincluyentecnologas como Core Foundation, SQLite y acceso a hilos POSIX y sockets UNIX entreotros.

Conforme nos desplazamos a niveles superiores, podemos encontrar tecnologas ms avanzadas que utilizan una mezcla de interfaces basadas en C y ObjectiveC. Por ejemplo, la capa Media contiene las tecnologas fundamentales utilizadas para dar soporte al dibujo2Dy3D,audioyvdeo.Estacapaincluyelastecnologasbasadas en C OpenGL, Quartz y Core Audio. Tambin contiene el motor de animacinCoreAnimation. En la capa Cocoa Touch, la mayora de las tecnologas utilizan ObjectiveC. Los frameworks en estos niveles proporcionan la infraestructura fundamental utilizada por cualquier aplicacin. Por ejemplo, el Framework Foundation proporciona soporte de orientacin a objetos para colecciones, gestin de ficheros, operaciones de red y mucho ms. El Framework UIKit proporciona la infraestructura visual para nuestras aplicaciones, incluidas clases para ventanas, vistas, controles y los controladores que gestionan estos objetos.Otrosframeworksaesteniveldanaccesoalainformacinde contactoseimgenesdelusuario,acelermetroyotrascaractersticas hardwaredeldispositivo. El punto de partida para cualquier proyecto es la capa Cocoa Touch y el Framework UIKit en particular. Cuando se plantea qu tecnologas adicionales utilizar, se recomienda empezar por los frameworks de nivel ms alto e ir descendiendo por las capas conforme sea necesario. Los frameworks de ms alto nivel hacen sencillo dar soporte a comportamientos del sistema estndar, con el mnimoesfuerzoporpartedeldesarrollador. Podemos encontrar ms informacin sobre la tecnologa iPhone OSenelsiguienteenlace. 2.2.2.DesarrolloparaiPhoneOS LaaplicacionescreadasporelprogramadorresideenelHomedel usuario,juntoaotrasaplicacionesdelsistemacomoPhotos,Weathero Clock. Una vez la aplicacin es lanzada, aparte del kernel y algunos demonios de bajo nivel, la aplicacin es la nica corriendo en el

sistema.Mientrasseejecuta,laaplicacinocupalapantallacompletay esel focodeatencindelusuario.Cuandoelusuarioaprietaelbotn Home,laaplicacinfinalizayelsistemavuelvealapantallaHome.Se puedetomarventajadelhardwareintegradocomolosacelermetroso lagestindegrficosparaejecutarnuestropropiocdigo. Lamaneraconlaquelosusuariosinteractanconlosdispositivos iPhone y iPod Couch es fundamentalmente diferente a como los usuariosinteractanconMacOSX,yportanto la manera de desarrollar las aplicaciones tambindebeserlo.EnunaaplicaciniPhone, no hay concepto de ventanas de documentos para mostrar contenido. En su lugar, toda la informacin de la aplicacin es mostrada en una nica ventana. Esto ha llevado a la creacin de nuevas vistas y controles que permitan presentar la informacin de la aplicacin de forma organizada. Adems, algunos de los elementos ms estndares pueden comportarse de una manera ligeramente diferente. Estas diferencias son transparentes, pero requieren en ocasiones replantearselaformadeorganizarypresentarelcontenidodenuestra aplicacin. El modelo de manejo de eventos en iPhone OS representa una desviacindelalasaplicacionestradicionalesdeescritorio.Enlugarde dependerdeeventosdetecladooratn,iPhoneOSintroducelaideade eventos tctiles (touch events). Un touch event puede ocurrir en cualquier momento y en combinacin con uno o ms eventos adicionales. Los toques pueden ser usados desde para detectar interacciones simples con el contenido, como seleccionar o arrastrar tems, o hasta complejos gestos como los realizados para hacer funcionesdezoom. Ms all de considerar la estructura bsica de la aplicacin, hay que pensar en cmo van a utilizarla los usuarios. Las aplicaciones iPhonedebenserlimpiasycentradasenloquelosusuariosnecesitan encadamomento.Caberecordarquemuchosdelosusuariosdeestos dispositivosnecesitanaccederainformacinrpidamenteynoperder mucho tiempo navegando entre capas y capas de la aplicacin. Un diseo simple que destaque la informacin esencial que necesita el usuarioesimportante.

10

Como ya hemos mencionado, los frameworks que se utilizan al iniciar el desarrollo de una aplicacin son Foundation y UIKit, que proveen los servicios bsicos utilizados por todas las aplicaciones iPhone.Conformeserefinalaaplicacin,sepuedenirutilizandootros frameworksqueofrezcanlosserviciosquenecesitamos. En la web de desarrolladores de apple podemos encontrar ms informacin sobre Foundation Framework Reference y sobre UIKit FrameworkReference.

2.3.Herramientasdedesarrollo:iPhoneSDK
El iPhone Software Developement kit es un paquete para desarrolladores,preparadoporAppleydistribuidogratuitamentecon todo lo necesario para que cualquier programador pueda desarrollar suspropiasaplicacionesparaiPhoneOS. El iPhone SDK viene con todas las interfaces, herramientas y recursos necesarios para desarrollar aplicaciones iPhone desde cualquierordenadorMacintosh. Apple distribuye la mayora de sus interfaces de sistema en paquetes especiales llamados frameworks. Un Framework es un directorio que contiene una librera compartida dinmicamente y los recursos (tales como ficheros de cabecera, imgenes, aplicaciones de ayuda, etc.) necesarios para apoyar esa librera. Para utilizar frameworks, se enlazan en el proyecto de la aplicacin como se hara con cualquier librera comn. Enlazndolos al proyecto obtenemos accesoatodaslascaractersticasdelFrameworkytambinpermitea las herramientas de desarrollo saber dnde encontrar los ficheros de lascabecerasyotrosrecursos. Aparte de frameworks, Apple tambin distribuye algunas tecnologasenformadelibrerascompartidasestndar.ComoiPhone OS est basado en UNIX, muchas de las tecnologas que forman los niveles ms bajos del sistema operativo son derivadas de tecnologas opensource. Las interfaces para estas tecnologas estn por tanto disponiblesenlaslibrerasestndarylosdirectoriosdeinterfaz. Algunos de los componentes claves del Software Developement Kitseran:

11

 XcodeTools Proporcionalasherramientasparapermitireldesarrollode aplicacionesiPhone,incluyendolossiguienteselementos: Xcode Entorno de desarrollo integrado que gestiona los proyectos de aplicaciones y permite editar, compilar, lanzar y depurar el cdigo. Xcode est integrado con muchas otras herramientas y es la aplicacin de uso principalduranteeldesarrollo. InterfaceBuilder Una herramienta que se utiliza para montar la interfaz de usuario visualmente. Los objetos de interfaz que se crean son guardados en un fichero con formato especial y cargados en la aplicacin en tiempo de ejecucin. Instruments Unaaplicacindeanlisisdecomportamientoyde debugging. Se puede utilizar para reunir informacin sobre el comportamiento en tiempo de ejecucin de la aplicacinyidentificarpotencialesproblemas. iPhoneSimulator Una aplicacin para Mac OS X que simula la pila de tecnologa iPhone, permitiendo probar las aplicaciones iPhone localmenteenunordenadorMacintosh. iPhoneReferenceLibrary ElSDKincluyedocumentacindereferenciaparaiPhoneOS por defecto y se pueden descargar versiones ms completas, incluyendoejemplosdecdigo. AunqueelSDKproporcionaelsoftwarenecesarioparadesarrollar aplicaciones, Xcode y Instruments tambin permiten interactuar directamente con un dispositivo adjunto para ejecutar y depurar el cdigo en el terminal fsico. El desarrollo en un dispositivo fsico requiere registrarse en el programa de pago de Apple iPhone DeveloperProgramyconfigurarelterminarparaestospropsitos.

12

MsinformacinsobreeliPhoneDeveloperProgram. 2.3.1.Xcode El centro de la experiencia de desarrollo es la aplicacin Xcode. Xcode es un entorno integrado de desarrollo que provee todas las herramientasnecesariasparacrearygestionarlosproyectosiPhoney sus ficheros fuente, compilar el cdigo en un ejecutable, lanzar y depurar el cdigo bien en el simulador iPhone o en un dispositivo. Xcode incorpora un gran nmero de caractersticas para hacer ms fcileldesarrollodeaplicacionesiPhone,comoson: Un sistema de gestin de proyectos para definir productos software. Un sistema de edicin de cdigo que incluye caractersticas como el coloreado de sintaxis, autocompletado de cdigo y indexado. Un visor de documentacin avanzado con sistema de bsqueda. Compiladores GCC para C, C++, Objective-C, Objective-C++ yObjective-C2.0. DepuracinaniveldefuenteutilizandoGDB. Compilacinpredictivaqueaceleraelproceso. Soporte para snapshots de proyectos, que permiten una formaligeradegestionarelcdigofuente. Herramientasdeanlisisdelasaplicaciones. Para crear una nueva aplicacin iPhone se empieza por crear un nuevo proyecto en Xcode. Un proyecto gestiona toda la informacin asociada con la aplicacin, incluyendo los ficheros fuente, la configuracin de compilacin y todos los elementos para juntar las piezas.ElcorazndecadaproyectoXcodeeslaventanadelproyecto. Esta ventana proporciona acceso rpido a todos los elementos claves denuestraaplicacin.Enlalistadegruposyficherossegestionanlos ficherosdenuestroproyecto,incluyendoelcdigofuente.Enlabarra
13

de herramientas, se accede a los comandos y herramientas ms comunes.Enelpaneldedetalles,sepuedeconfigurarunespaciopara trabajarenelproyecto.

CuandosecompilaunaaplicacinparaXcode,tieneslaposibilidad deelegircompilarlaparaelsimuladoriPhoneoparaundispositivo.El simuladorproporcionaunentornolocalparatestearlasaplicacionesy asegurarsedequesecomportandemaneraesperada.Unavezseest satisfecho con el comportamiento, se puede compilar la aplicacin y lanzarlaenuniPhoneoiPodtouchconectadoalordenador.Correrla aplicacin en un dispositivo fsico proporciona un entorno de test definitivo,yXcodepermitedepurarlaaplicacincorriendoenl. 2.3.2.InterfaceBuilder Interface Builder es la herramienta a utilizar para disear visualmente la interfaz de usuario de nuestra aplicacin. Utilizando Interface Builder, podemos montar la ventana de nuestra aplicacin arrastrandoysoltandocomponentespreconfigurados.Seincluyenuna seriedecontrolescomoswitches,textfieldsobuttons. Una vez se han colocado los componentes en la superficie de nuestraventana,podemosposicionarlosanuestroparecer,configurar sus atributos utilizando el inspector, y establecer las relaciones entre esos objetos y nuestro cdigo. Cuando la interfaz est terminada, se guardaenunficheronib,formatopropioparalasinterfaces.
14

 LosficherosnibquesecreanenInterfaceBuildercontienentoda la informacin que el Framework UIKit necesita para recrear los objetos en tiempo de ejecucin de la aplicacin. Al cargar un fichero nib durante la ejecucin esto crea una instancia de todos los objetos almacenados en el mismo, con la configuracin que le dimos en el Interface Builder. Tambin utiliza la informacin de conexiones especificadas para crear las conexiones entre las instancias creadas y cualquier objeto existente en nuestra aplicacin. Estas conexiones proporcionananuestrocdigopunterosalosobjetosdelficheronib,y tambin se la proporcionan a los propios objetos para comunicar accionesdeusuarioalcdigo. En general, utilizar Interface Builder ahorra mucho tiempo en cuantoacrearlainterfazdeusuariodelaaplicacin.InterfaceBuilder elimina el cdigo necesario para crear, configurar y posicionar los objetos que conforman nuestra interface. Por ser un editor visual, se consigueobtenerentiempodedesarrollounavisinexactadelaspecto que tendr la interfaz en tiempo de ejecucin, lo que lo convierte en unapotenteyconvenienteherramientadurantenuestrodesarrollo. 2.3.3.Instruments ElentornodeInstrumentspermiteanalizarelcomportamientode nuestrasaplicacionesiPhonemientrascorrenenelsimuladoroenun dispositivo. Instruments recoge informacin de la aplicacin en
15

ejecucinylapresentagrficamenteenuntimeline.Sepuedeobtener informacinsobreelusodememoria,actividaddedisco,actividadde redocomportamientogrfico.Eltimelinepuedemostrartodotipode informacinsimultneamente,pararelacionarlosdatosobtenidos. Adems de esta vista del timeline, Instruments proporciona herramientas para analizar el comportamiento de nuestra aplicacin eneltiempo.Porejemplo,podemossalvarlainformacindemltiples ejecuciones para ver el desarrollo del comportamiento, compararlo o ayudarnosaevaluarlanecesidadderevisaralgunodeestosaspectos.

16

3.Casodeestudio:Anlisis.
Comoyahemosmencionado,lafinalidaddelarealizacindeeste proyecto no es el desarrollo de una aplicacin concreta, sino el aprendizajedeldesarrollodeaplicacionesparadispositivosmviles,y la exploracin de la tecnologa iPhone y iPhone OS. As pues, el contenido exacto se fue definiendo mientras se avanzaba en el aprendizajeyenlasprimerasversionesdelprototipo. Sisetrazaronunaslneasmaestrasparaelprototipoadesarrollar, ascomounaseriedefuncionalidadesorequisitosquepodanllegara implementarse.Acontinuacinsepresentaelanlisiscorrespondiente alprototipoquefinalmentesehadesarrollado.

3.1.Objetivosyrequisitosdelaaplicacin.
3.1.1.Objetivobsicodelaaplicacin. Sepretendeeldesarrollodeunaaplicacinparaelterminalmvil iPhone de Apple que permita la navegacin entre los dispositivos o elementosdeunaviviendadomticapreviamentedefinidaymodelada, ascomolautilizacinoactivacindedichosrecursosatravsdeuna conexinvaInternetconunservidor. 3.1.2.Especificaciones,requisitosyfuncionalidades. Laaplicacindeberpermitirunanavegacinsencilla,cmodae intuitiva entre los diferentes elementos domticos incluidos en las viviendas que hayan sido previamente modeladas y configuradas. Se decide utilizar listados jerarquizados para presentarlainformacin. Laaplicacindeberpermitirlacargaodefinicindediferentes modelosdeviviendasoentornosdomticos.Endichadefinicin, se debern poder especificar indefinidos niveles de agrupacin (deahoraenadelantellamadossectores),quepodrncontenera

17

su vez indefinidos elementos domticos de cualquier tipo, as comootrossectores. Sedefinirndostiposdeelementosdomticos:losdispositivosy losservicios.Undispositivocorresponderaunelementofsico utilizable, mientras que un servicio corresponder a cualquier funcin domtica que no corresponda fsicamente con un nico elemento. Losdispositivosyserviciospodrnserdeunnicoovariostipos diferentes previamente definidos. En cualquier caso se deber poder acceder al uso de cualquiera de las funcionalidades definidasparadichostipos. La aplicacin debe de poder comunicarse a travs de Internet conunservidorquegestionelaactivacinousodelosdiferentes dispositivos definidos, de manera que la activacin en la aplicacinsupongauncambiorealenlaviviendamodelada.

3.2.Casosdeuso
Loscasosdeusosonunmodeloenmarcadoenellenguajegrfico UML (Lenguaje Unificado de Modelado) que nos permite, una vez capturados los requisitos, representar grficamente cmo debera interactuarlaaplicacinconlosusuarios. Por lo tanto, los casos de uso estn formados por actores (usuarios), por los propios casos de uso (funcionalidades) y por un diagramadecasodeuso(relacionesentrelosusuariosylaaplicacin). Entre los diferentes elementos de un diagrama de casos de uso pueden presentarse diferentes tipos de relacin, de los que hemos utilizado: <<comunicate>>defineunarelacinentreunactoryuncasode uso.Generalmentelarelacinnicamenteseindicaconunalnea continua. <<include>>defineunarelacindedependenciaentredoscasos de uso en el que un caso de uso A incluye a un caso de uso B, realizandouna instanciadeAtodosloseventosdescritosenB.

18

 <<extend>>defineunarelacindedependenciaentredoscasos de uso en el que un caso de uso B es una especializacin de un casodeusoA,esdecir,unarelacinequivalenteaunainclusin msunacondicin. En nuestro proyecto, presentamos un diagrama de casos de uso sencillo, en el que se observan las principales interacciones que el usuariovaarealizarconlaaplicacin.

Cabe destacar de nuevo que en las aplicaciones orientadas a dispositivosmvilessebuscalasencillez,lacomodidadylarapidezde interaccinentreelusuarioylafuncionalidad.Esporesoqueloscasos de uso son tan sencillos como se pueda imaginar, para facilitar la poltica onthego de este tipo de aplicaciones, que busca que el usuariononecesitecentrarsuatencineneldispositivomsqueunos segundosparaobtenerlafuncionalidaddeseada. Vamos a ver a continuacin una descripcin de los casos de uso presentadoseneldiagrama: Explorarvivienda(s)domtica(s) Cualquier usuario que lance la aplicacin estar comenzando a explorar las viviendas domticas que hayan sido cargadas (ver caso de uso correspondiente). A travs de un sistema de navegacin entre tablas jerarquizadas, el usuario podr explorar el contenido de las viviendas e ir viendo el contenidodecadasectordemaneraordenadayclasificada. Cargarvivienda(s)domtica(s)

19

Al lanzarse la aplicacin, como hemos dicho, el usuario comienza a explorar las viviendas domticas que la aplicacin hayacargado(verapartadodecargadeinformacindentrodela fase de diseo). Esta carga se produce de manera automtica cadavezquesecomienzaaexplorarlasviviendas.Secargatoda la informacin a memoria y la aplicacin trabaja con ella hasta que se cierra. Es por esto que la carga de la informacin se realizacuandosecomienzaaexplorar,perounanicavez. Verdetalledispositivooservicio Durante la navegacin el usuario puede seleccionar un dispositivo o servicio (y en el futuro cualquier elemento domtico que se implementara) para observar su detalle (a travsdelacargadesuinterfazqueveremosenelapartadode diseo). Esto mostrar toda la informacin relevante y proporcionarlaposibilidaddehacerusodesusfuncionalidades asociadas.Encasodeelementosdevariostipos(porejemplouna bombilla que se pueda apagar/encender o regular), se presentar la posibilidad de acceder a tantas vistas de control comoseanecesariounavezsehayaseleccionadoelelemento. Utilizardispositivooservicio Unavezelusuarioseencuentreenlapantalladedetallede un elemento domtico, sta mostrar los controles asociados al tipo correspondiente del elemento, permitiendo al usuario accionar o hacer uso de las funcionalidades asociadas ha dicho elemento segn el tipo que corresponda (ver apartado de diseo). Comunicarconservidorvivienda Cada vez que el usuario proceda a utilizar un elemento domtico,estaaccinresultarenunacomunicacindirectacon el servidor de la vivienda definido, a travs de una seal va Internetqueprocedaarealizarlafuncindeseadaenlavivienda.

3.3.Diagramadeclases

Haremos uso de los diagramas de clases, un tipo de diagrama estticodeUMLquenospermitirdescribiryvisualizarlasclasesque componenelsistemaylasrelacionesqueexistenentreellas.

20

Se define una clase como una unidad bsica que encapsula la informacin de un objeto, y se muestran atributos y mtodos de las mismas.

As pues, y desde un punto de vista del anlisis de la aplicacin, slo hemos incluido las clases que almacenan informacin sobre objetos,ynoaquellasclasesquehansidonecesariasparalagestinde lainformacin(controladoresdevistas,delegadodelaaplicacin,XML Parser). Obtendremos ms informacin sobre estas clases y las funciones que proporcionan a la aplicacin en apartados posteriores de la presente memoria, limitndonos en este diagrama a las clases contempladas en la fase de anlisis, sin adems especificar las propiedadesdelasmismas.

21

4.Diseo
Vamos a ver a continuacin las caractersticas del diseo de la aplicacin. Para ello, presentaremos un diagrama de clases de la aplicacin desarrollada en detalle, con todos las clases y relaciones definidas en este proyecto, como refinacin del presentado en la fase de anlisis. Realizaremos una descripcin de las funcionalidades de cada clase, as como de sus propiedades. Veremos tambin la definicindelesquemaXMLutilizadoparalacargadeinformacinen la aplicacin, y por ltimo detalles de la interfaz grfica desarrollada paracumplirconlasespecificacionespropuestasenlafasedeanlisis.

4.1.Diagramadeclasesampliado.
Acontinuacinvamosaverunaampliacindeldiagramadeclases presentadoenelapartadodeanlisis. En el diagrama de clases de la fase de anlisis presentamos nicamente las clases necesarias para modelizar la informacin manejadaenlaaplicacin,sinentrarendetalleensufuncionamientoo finalidadylimitndonosaesteconcepto.Ademsdestas,existenen elproyectomuchasotrasclasesutilizadasparaotrosmenesteres,tales como los controladores de vistas, la clase de recorrido del XML o el delegadodelaaplicacin. Enlasclasespresentadasnosehanimplementadoningnmtodo deltiposetoget,quenospermitendarvaloralosatributosdeuna instanciadeunaclaseorecuperarlo,yaquestossonimplementados demaneraautomticaaldefinirlosatributoscomopropiedades.Estos mtodos, pese a no haber sido necesario implementarlos, s han sido utilizados y cabe destacar que por defecto se han definido todos los atributosdelasdiferentesclasescomopropiedadesconlafinalidadde poderutilizarlosgettersysettersencualquiermomento.
@property(nonatomic, retain) NSString *nombre; @synthesize nombre;

22

Adems, en el diagrama de clases presentado, por motivos de espacio, no se han incluido las relaciones entre la clase iDomoControllerAppDelegate y el resto, ya que queda relacionado con todas ellas, as como algunas otras relaciones, que iremos viendo endetalleacontinuacin.Veamoseldiagrama.

4.1.1.Clasesdemodelizacindeinformacin. Las clases Sector, Elemento domtico, Dispositivo y Servicio, todas heredadas de la clase interna de Foundation NSObject, son las diseadas con la finalidad de modelizar la informacin en nuestro proyecto. Con ellas podemos almacenar y trabajarconnuestrosentornosdomticos.Veamosendetallecadauna deellas.
23

 Sector La clase Sector representa toda unidad de agrupacin de elementos domticos. As pues, un sector podra ser una habitacin, una planta o incluso una vivienda. Un sector puede contenerotrossectoresy/oelementosdomticostalescomolos dispositivos o los servicios. Estas relaciones de asociacin de la clase Sector consigo misma y con los diferentes elementos domticossepuedeapreciareneldiagrama. Un sector poseer como atributos un nombre, una lista de los sectores que estn contenidos en esta agrupacin, una lista delosdispositivosquecontieneyotralistaconlosserviciosque agrupa. Sehadefinido unmtododeinicializacinparalosobjetos delaclaseSectorque,recibiendotodalainformacinsobresus atributos,creeyinicialicelainstancia. ElementoDomtico La clase Elemento Domtico es una superclase de la que heredan las clases servicio y dispositivo. Pese a que habitualmentenoseinstanciarnobjetosdeestaclase,nossirve para agrupar todos los elementos domticos que podamos utilizarenunfuturo,yparaestructurarelcdigodemaneraque no sea necesario repetir definiciones de atributos y mtodos comunesaestasotrasclases. UnElementoDomtico(yportantocualquieradesusclases hijos)poseercomoatributosunnombreyunalistaconlostipos dedichoelemento. Se ha definido tambin un mtodo de inicializacin para esta clase, que dado un nombre y una lista de tipos, cree y inicialiceelobjeto. Servicio Un servicio es una subclase de un Elemento Domtico. Se entiende por servicio cualquier funcin domtica que puede estar presente en una vivienda y no corresponda directamente conlaactivacindeunnicoelementofsico.

24

Tal y como finalmente se ha decidido el funcionamiento y funcionalidades de la aplicacin, no posee ningn atributo ni mtodo propio, pero el hecho de existir una clase para estos objetos nos permite concretar de manera aislada su comportamiento y facilita desarrollos futuros sobre la base de estaaplicacin. Dispositivo UndispositivoesunasubclasedeunElementoDomtico.Se entiendepordispositivocualquierelementofsicoquetengauna funcionalidad controlable asociada, como por ejemplo una bombillaqueseenciendeyseapaga. Al igual que los servicios, se ha creado una clase especfica para su tratamiento que por el momento no tiene atributos o mtodospropios. 4.1.2.Clasescontroladoresdevistas En nuestro proyecto se han definido 6 clases que actan como controladores de vistas. Estas clases son las que nos permiten gestionarlasdiferentesinterfacesgrficasdefinidas,tantoelcontenido que se muestra, como la capa de negocio con la que la interfaz debe comunicar al usuario. Diferenciamos entre dos subtipos. Primero las clases heredadas de la clase interna del UIKit UIViewController, dondeenmarcamoslascuatroclasesdefinidascomocontroladoresde las cuatro interfaces de dispositivos. Segundo las clases heredadas de laclaseinternadelUIKitUITableViewController,dondeenmarcamos las dos clases definidas como controladores de la interfaz de navegacin.Veamoslosdetallesdecadacontrolador. RootViewController Clasecreadacomocontroladordelainterfazdenavegacin paralagestindelavistaprincipal,enlaqueserepresentenlas viviendas cargadas en nuestra aplicacin. Como atributo se establecelarelacinconlaclaseSectoresViewControllerycomo mtodosencontramosrefinamientosdelosmtodospropiosde su clase padre, propios de la gestin de una interfaz de tipo navegacin. Entre ellos encontramos mtodos como los que definenloquesucedecuandoterminadecargarselainterfaz,el
25

nmero de filas de cada seccin de la tabla, el contenido de las celdasoloquesucedecuandoelusuarioseleccionaunadeellas. SectoresViewController Esta clase es muy similar a la anterior, ya que tambin se utilizacomocontroladordelainterfazdenavegacin.Estaclase, en concreto, gestionar la navegacin a nivel de sectores, mientrasquelaanteriorsereservabaparaelniveldeviviendas. Seestableceestadiferenciaparapoderdiferenciarentreambosy permitirunamayorflexibilidadencomportamientoyapariencia delaaplicacinparaestosdosniveles. Estaclaseserelacionadirectamentecontodaslasclasesde modelizacin de la informacin presentadas, as como con los cuatrocontroladoresdevistasdeinterfaz,relacinquenoseha representado por claridad en el diseo. Los mtodos implementados son aproximadamente los mismos que en la anteriorclase,peroconcomportamientosdiferentes. Dispositivo_BinarioViewController Clase controlador de vista que hereda de la clase interna UIViewController. Utilizada para controlar la interfaz de elementos domticos de tipo binario y gestionar la interaccin destaconlacapadenegocio. Los atributos definidos corresponden mayormente a los elementosgrficosdelainterfaz,parapermitirlagestindesde la clase de los mismos. Entre los mtodos encontramos el mtodo de inicializacin y el que gestiona la activacin del switchdelainterfazparaconstruirlasealamandaralservidor. Dispositivo_RegulableViewController Clase controlador de vista que hereda de la clase interna UIViewController. Utilizada para controlar la interfaz de elementosdomticosdetiporegulableygestionarlainteraccin destaconlacapadenegocio. Los atributos definidos corresponden mayormente a los elementosgrficosdelainterfaz,parapermitirlagestindesde laclasedelosmismos.Vemosentrelosmtodoselquegestiona lasaccionesatomarcuandosemodificaelsliderdelainterfaz, ascomoelqueseencargadeconstruirlasealdeenvocuando sepulsaelbotncorrespondiente.
26

 Dispositivo_BidireccionalViewController Clase controlador de vista que hereda de la clase interna UIViewController. Utilizada para controlar la interfaz de elementos domticos de tipo bidireccional y gestionar la interaccindestaconlacapadenegocio. Los atributos definidos corresponden mayormente a los elementosgrficosdelainterfaz,parapermitirlagestindesde laclasedelosmismos.Sedefinenmtodosparatomaracciones para cada uno de los posibles botones pulsados, gestionando la seal a enviar al servidor segn se seleccione una de las direccionesolaparadadelelemento. Dispositivo_UmbralViewController Clase controlador de vista que hereda de la clase interna UIViewController. Utilizada para controlar la interfaz de elementos domticos de tipo umbral o de valor y gestionar la interaccindestaconlacapadenegocio. Los atributos definidos corresponden mayormente a los elementosgrficosdelainterfaz,parapermitirlagestindesde la clase de los mismos. Como mtodo principal destacar la gestin del valor introducido para enviar al servidor la seal correspondiente. 4.1.3.ClasederecorridodelXML La clase XMLParser es la clase definida para el recorrido y carga de la informacin almacenada en el fichero XML de carga (ver apartadosalrespecto).Estaclaseseinstanciadesdeeldelegadodela aplicacinallanzarelprograma,yseencargaderecorrerelficheroeir creando las estructuras necesarias (clases de modelizacin de informacin) para almacenar la informacin que despus pueda ser presentadaytratada. Hereda de la clase interna NSObject y los atributos y mtodos definidos en ella son los necesarios para cumplir con la finalidad expuesta.

27

4.1.4.Clasedelegadodelaaplicacin Estaclase,queheredatambindelaclaseinternaNSObject,esla clase principal de la aplicacin. iDomoControllerAppDelegate acta como delegado de la aplicacin en su ejecucin, lo que significa que gestionadesdequeselanzahastaquesecierraelflujodelprograma. Sepodracompararconlatradicionalclasemain,quesibienexisteen esteproyecto,nicamentedapasoaldelegado,queesquienrealmente gestionalaejecucin. Esta clase, pese a que no se ha representado en el diagrama por claridad, tiene relaciones con casi todas las clases diseadas. Desde multitud de ellas se crean instancias del delegado para ejecutar los mtodosenldefinidos,yeselmismodelegadoelquecrealainstancia del XMLParser que permite la carga de la informacin. Adems, tambin centraliza la formacin y envo de seales al servidor que permiten que la aplicacin interacte con los entornos domticos fsicos.

4.2.Cargadedatos:EsquemaXML
Anteelproblemadeelalmacenamientoycargadeinformacinen laaplicacinsebarajarondiferentesposibilidades. La primera consista en cargar la informacin relativa a las viviendas a partir de un fichero que previamente debe haber sido almacenadoenelterminal.Fuetambinlaprimeraenserdesechada, pues almacenar un fichero en el terminal fsico supone un gasto de espacioinnecesario,Adems,obviamentehabraquegenerarprimero elarchivoycargarloenlaterminal,loquepuedeserunimpedimentoa lahoradecargarnuevasviviendasomodificarlasexistentes. La segunda opcin barajada fue crear una base de datos, que iPhoneOSsoportaatravsdeSQLLite.Tambinfuedesechada,puesto que si bien es una manera ordenada de almacenar y cargar la informacin, seguimos teniendo el problema de cmo un usuario podradefinirunanuevacargadedatos. Estas dos primeras opciones podran haber sido vlidas si se hubieradesarrolladolaaplicacindemodoqueelusuariodefinierasu vivienda a travs de la interfaz de la propia aplicacin. No obstante,
28

esto no era parte de la finalidad del proyecto, adems de que si bien podra ser una buena manera de hacer cambios sobre viviendas ya creadas, definir una nueva vivienda al completo podra ser interminable,ycomoyahemosmencionadoenotrospuntos,sebusca lasencillezyrapidezdeinteraccinentreelusuarioylaaplicacin. Aspues,llegamosalatercerayltimaopcin,quefuefinalmente implementada:LacargadedatosatravsdeunficheroXML. Esta opcin no tiene inconveniente alguno. Para hacer uso de la aplicacin debemos tener conexin va Internet con el servidor de nuestra vivienda domtica, con lo que podemos utilizar ste mismo para almacenar el fichero XML con los datos de la vivienda a cargar. Esto nos exime de almacenar ninguna informacin en el terminal, ya que sta se encuentra en la red y se carga cada vez que se lanza la aplicacin, con lo que se puede modificar fcilmente el XML para reflejar por ejemplo un nuevo dispositivo, o para definir nuevos sectoresoviviendas. Elmododefuncionamientoeselsiguiente:SeimplementaunXML Parser, es decir, una clase que gestiona cmo se recorrer el fichero XMLacargar.Sedefineunarutadondeestalmacenadoelfichero(que puedeser,porejemplo,larutadelservidorconelquesecomunicala aplicacin para interactuar con la vivienda), y en la carga de la aplicacin se le solicita al XML Parser que lo cargue y lo recorra, de modoqueseanlosmtodosdefinidosenlapropiaclaselosquerecojan todoloqueelParserleaalrecorrerelfichero. As pues, se disea una estructura para el fichero XML que se desee utilizar como fuente de datos para la aplicacin. Vamos a continuacinadefinirloselementosdelaestructura: Elementosdomticos Dispositivos o servicios. Se definen con la etiqueta <Dispositivo> o <Servicio> respectivamente. En su interior, se debeindicarelnombre,indicadoconlaetiqueta<Nombre>,y1o mstiposdeelementosdomticos,consucesivasaparicionesde la etiqueta <Tipo> y el cdigo numrico asociado al tipo en nuestraaplicacin. <Dispositivo> <Nombre>DispositivoA</Nombre>
29

<Tipo>3</Tipo> <Tipo>2</Tipo> <Tipo>1</Tipo>

</Dispositivo>

SectoroVivienda Se definen con la etiqueta <Sector> o <Vivienda> respectivamente. Si bien diferenciamos entre ambos conceptos, cabe recordar que una vivienda no es ms que un sector de primer nivel, que almacena el resto de sectores y que tambin puede contener elementos domticos. As pues, dentro de un <Sector> o <Vivienda> debemos definir primeramente su <Nombre>,yacontinuacin,siprocede,podemosdefinirtantos elementos <Servicio>, <Dispositivo> y <Sector> como corresponda. Es importante respetar este orden, para que el Parsersepadistinguiraqusectorperteneceloselementosque estamosindicandoentodomomento. <Sector> <Nombre>Sector3</Nombre> <Dispositivo> ..

</Dispositivo> <Servicio> ..

</Servicio> <Sector> <Nombre>Sector3.1</Nombre> <Dispositivo> ..

</Dispositivo>

</Sector>
30

</Sector> Viviendas Es simplemente el tag que identifica el principio de la lista de viviendas. En su interior podemos encontrar diferentes viviendas definidas, ya que la aplicacin permite la carga de un nmeroindefinidodeelementos<Vivienda>. <Viviendas> <Vivienda> <Nombre>Vivienda1</Nombre> ..

</Vivienda> <Vivienda> <Nombre>Vivienda2</Nombre> ..

</Vivienda>

</Viviendas>

4.3.Interaccinconlasviviendasfsicas.
Esta aplicacin est pensada como una interfaz mvil de interaccinentreelusuarioquedeseacontrolarsuviviendaoentorno domticodesdecualquierlugaryelservidordedichaviviendaquees elquegestionalaefectuacinfsicadeesasmodificaciones. As pues, la aplicacin se deber comunicar con el servidor para que sea ste el que ejecute las acciones. En nuestro caso, y tal como veremos en el apartado de descripcin del prototipo implementado, noscomunicaremosconunservidorsituadoenelDSICquecontrolala maqueta de una vivienda domtica. Cabe destacar en esta fase de diseo que la comunicacin se realizar a travs de rdenes http graciasalserviciopostimplementadoenelmismo.

31

Lainteraccinconlaviviendafsicarequierelaformacindeuna seal, que en este caso se trata de la creacin de una cadena url concretasegndispositivoyaccin,yelenvodedichaurlalservidora travsdeunposthttp. Las seales a enviar en este proyecto tenan como caracterstica quesediferenciabansegntipodeelementodomtico,yincluanenla rutaelnombredelelemento,ascomounacodificacindelaaccina realizar.Poresto,losmtodosdeformacinyenvodeestassealesse hanimplementadoaniveldedelegadodeaplicacin,mientrasqueen cadacontroladordevistasdecadatipodeelemento,esdondesecrea lainstanciadeldelegado,sellamaalmtododeconstruccindesealy al de envo, segn corresponda con la accin realizada por el usuario enlainterfaz(yportanto,capturadaporestecontrolador). Eneldelegadodelaaplicacinesdondesedefinenlosmtodosde construccindeseales(unoporcadatipodeelementodomtico,ya que como hemos dicho las seales se forman de manera diferente), teniendoencuentacomoparmetrosnombreyaccinarealizarpara la seal a construir. Tambin es aqu donde encontramos el mtodo quegestionaelenvodelasealalservidor.Estemtodorecibecomo parmetro la cadena de conexin que previamente ha sido formada con la casustica indicada, la convierte en un objeto del tipo NSURL, creaunasealdeposthttpyutilizandolaconectividadquegestionael propio iPhone OS, fuerza el envo de la seal. Este post http ser gestionado por el servidor, que efectuar las acciones asociadas al mismo, ejecutando fsicamente lo que el usuario ha solicitado en el dispositivo.

4.4.Interfazgrfica
Hayquetenerencuentaquealfinal,eslainterfazgrficaloqueel usuario ve de la aplicacin. Dada la importancia de la claridad, simplicidad y sencillez de uso en la aplicaciones mviles, es precisamenteenestafasedeldiseodondehayquetenerloencuenta. Aspues,sedefineunanicainterfaz(ydecimosinterfazpuestoqueel concepto vista es diferente en iPhone Os, donde una interfaz puede tenerdiferentesvistas)paralanavegacinporlasviviendascargadas. Sedefinetambinunainterfazporcadatipodeelementodomtico,en nuestro caso 4 interfaces que corresponden a los tipos de elementos definidos(verprototipo).
32

5.Prototipoyimplementacin
Vamosacentrarnosenesteapartadoenelprototipodeaplicacin para terminal iPhone que se ha desarrollado como parte de este proyecto.Vamosavercmosehanllevadoacaboaspectosdeldiseo deaplicacinycmoenconcretoseefectantodaslasaccionesquese handefinidoenanterioresapartados.

5.1.Elprototipo:Unaviviendaeficiente.
En el laboratorio del DSIC dirigido por el director de este proyecto, Joan Fons i Cors, han construido una maqueta que representa una vivienda eficiente y un servidor que gestiona la interaccinconlamismaatravsdecomunicacionespostporhttp.Es precisamenteesteentornoelquesehautilizadoenesteproyectopara eldesarrollodeunprototipoconlosrequisitosyeldiseodetallados enlapresentememoria.

33

5.1.1.Tiposdeelementosdomticos. Se definen cuatro tipos de elementos domticos (ya sean dispositivos o servicios) en nuestra vivienda eficiente, que presentamosacontinuacin(verapartadodeinterfacesdeusuario): Binario Los elementos de tipo binario son los ms sencillos que vamos a encontrar. Tienen dos estados (on/off, encendido/apagado,activado/desactivado)ydeahelnombre delosmismos.Porejemplounabombilla. Regulable Son elementos regulables aquellos que son susceptibles de ser controlados de manera regulada para cualquiera de sus aspectos. Por ejemplo, consideramos regulable una bombilla cuya intensidad se puede controlar representando la misma comounporcentaje. Bidireccional Son elementos que tienen dos posibles interacciones opuestas (y opcionalmente un tercer estado de reposo). Por ejemplo una cortina que pueda subirse y bajarse, o un depsito quesepuedallenarovaciar. Devalor Cualquierelementoconelquesepuedainteractuarconun valor,enunconceptomsamplioqueloselementosregulables,y nonecesariamenteconvaloresdeporcentajeonumricos.Sera un ejemplo un climatizador que aceptara como input la temperaturaaconseguir. 5.1.2.Elementosdomticosydistribucin. Acontinuacinvamosaprofundizarencmoesnuestravivienda eficiente. Se trata, como ya hemos introducido, de una maqueta que representa una vivienda con una serie de elementos domticos diseados con la eficiencia energtica y la comodidad que ofrece la domticacomopremisas.
34

Vamosarevisartodosloselementosdomticosdelosqueconsta nuestraviviendaeficiente,ascomosudistribucinenlamisma. Nombre Flooding Security Water Supply Home Security Home Messaging Buzzer General Light Visual Notification Climated Room Room Lighting Air Conditioned Kitchen LightBy Presence LightBy Light Intensity Kitchen Lighting Louver Gradual Lighting
35

Tipo Elemento Servicio binario Servicio binario Servicio binario Serviciode valor Dispositivo binario Dispositivo binario Dispositivo binario Servicio binario Dispositivo binario Dispositivo binario Servicio binario Servicio binario Dispositivo binario Dispositivo bidireccional Dispositivo binarioy regulable

Sector Vivienda Vivienda Vivienda Vivienda Vivienda Vivienda Vivienda Dormitorio

Descripcin Serviciodedicadoal controldeinundaciones. Servicioquecontrolala provisindeagua corriente. Activacindeelementos talescomoverjas, detectores,alarmas.. Usoscomodisplaysde mensajes. Alarmaozumbador. Luzgeneraldelavivienda. Dispositivodenotificacin.

Climatizacindel dormitorio.Controla temperatura. Dormitorio Iluminacindel dormitorio. Dormitorio Controlaelaparatodeaire acondicionado. Cocina Encendidoautomticode iluminacinencocina. Cocina Cocina Saln Saln Iluminacinsegn iluminacinnatural. Iluminacinmanualde cocina. Persianadelsaln. Luzregulabledelsaln.

5.2.Interfacesdeusuario
A continuacin vamos a describir las interfaces de usuario diseadas y implementadas con el Interface Builder para nuestro prototipo, que son la interfaz de navegacin y las cuatro interfaces correspondientes a los cuatro tipos de elementosdomticos. Navegacin El diseo de la interfaz de navegacin lo proporciona el propioInterfaceBuilderalutilizarunatablapararepresentarlos datos. Como parte de una Navigation Based Application (aplicacin basada en navegacin) se aade una barra de navegacin(NavigationBar)enlapartesuperior,cuyocontenido es configurable. Se puede observar que se ha configurado el ttulo de la misma, as como la aparicin de un botn para regresaralaanteriorpantalladelanavegacin.

36

Estainterfazpermitepuesnavegarportodosloselementos domticos y sectores de nuestra vivienda, de manera rpida e intuitiva. Adems, al mostrar el contenido de un sector, se diferenciaentreotrossectores,dispositivosyservicios,parauna mayorclaridad. Elementobinario El diseo de la interfaz para elementos domticos de tipo binario (recordemos que eran aquellos con dos estados), presenta un botn deslizante que permite al usuario con un sencillo gesto cambiar el estado del elemento. Esta interaccin del usuario provoca el envo de la seal correspondiente al servidor para que se produzca le cambio. Dicha seal, y de maneraprovisional,semuestraenelinferiordelainterfaz.

37

 Elementoregulable El diseo de la interfaz para elementos domticos de tipo regulable presenta un elemento grfico muy caracterstico, el slider (barra de deslizamiento), que nos permite mostrar un elementoconelqueelusuariopuedeinteractuarparaindicarun valordentrodeunrango.Seaadetambinunbotnparaenviar lasealconelvalorseleccionadocuandoestlisto. Nteseenlaparteinferiordelaimagenquesteesunode loscasosenlosqueunelementodomticoesdemsdeuntipo diferente. Por eso aparece en la interfaz una barra con tantas divisiones como de diferentes tipos sea el elemento, seleccionables para cargar la interfaz correspondiente a dicho tipoyaspermitircualquierinteraccinposibleconelelemento.

38

 Elementobidireccional El diseo de la interfaz para elementos bidireccionales cuentacontresbotones.Dosbotonescorresponderanalasdos direcciones o estados contrapuestos que caracterizan este tipo de elementos, mientras que el tercer botn servira para entrar enuntercerestado,dereposo,siexistieralaposibilidad. En nuestro prototipo el reposo de este tipo de elementos domticos estaba programado en el servidor con un temporizador tras activar una de las dos direcciones, no existiendolaposibilidaddemandarunasealdeparada,conlo cuallafuncionalidaddelbotndeparadanoseimplement.No obstante,pensandoenlaflexibilidaddelproyectodesarrolladoy en posibles ampliaciones o reutilizaciones, se dise el botn parapoderimplementarsufuncionalidadsicorresponde.

39

 Elementodevalor Eldiseodelainterfazparaelementosdevalorconstacomo el resto de las interfaces de una etiqueta con el nombre del elemento domtico que estamos manipulando. As mismo, contiene una entrada de texto, que permite que el usuario introduzca cualquier valor deseado a travs del teclado que IPhone OS despliega automticamente cuando el usuario pulsa dentro del cuadro de texto. Por ltimo, y pese a que se podra implementar el envo de la seal a travs de la tecla correspondientedeltecladodesplegado,heoptadoporaadirel mismo botn que en las otras interfaces por coherencia, que comoenlosotroscasos,envaelvalorestablecido(enestecaso unacadena)alservidor.

5.3.Cargadelprototipo.DefinicinenXML
Comoyaseintrodujoenelapartadodediseo,lacargadedatos en la aplicacin se realiza mediante la lectura de un fichero XML
40

alojadoenlared.Definimostambinlaestructuraquedebacumplirel XMLparaserledoporlaaplicacin.Vamosaveracontinuacinenel casoconcretodenuestraviviendaeficientecmohasidodefinidoese XML.

<Viviendas> <Vivienda> <Nombre>Vivienda eficiente</Nombre> <Servicio> <Nombre>FloodingSecurity</Nombre> <Tipo>1</Tipo> </Servicio> <Servicio> <Nombre>WaterSupply</Nombre> <Tipo>1</Tipo> </Servicio> <Servicio> <Nombre>HomeSecurity</Nombre> <Tipo>1</Tipo> </Servicio> <Servicio> <Nombre>HomeMessaging</Nombre> <Tipo>4</Tipo> </Servicio> <Dispositivo> <Nombre>Buzzer</Nombre> <Tipo>1</Tipo> </Dispositivo> <Dispositivo> <Nombre>GeneralLight</Nombre> <Tipo>1</Tipo> </Dispositivo> <Dispositivo> <Nombre>VisualNotification</Nombre> <Tipo>1</Tipo> </Dispositivo> <Sector> <Nombre>Dormitorio</Nombre> <Servicio> <Nombre>ClimatedRoom</Nombre> <Tipo>1</Tipo> </Servicio> <Dispositivo> <Nombre>RoomLighting</Nombre> <Tipo>1</Tipo> </Dispositivo> <Dispositivo>

41

<Nombre>AirConditioned</Nombre> <Tipo>1</Tipo> </Dispositivo> </Sector> <Sector> <Nombre>Cocina</Nombre> <Servicio> <Nombre>KitchenLightByPresence</Nombre> <Tipo>1</Tipo> </Servicio> <Servicio> <Nombre>LightByLightIntensity</Nombre> <Tipo>1</Tipo> </Servicio> <Dispositivo> <Nombre>KitchenLighting</Nombre> <Tipo>1</Tipo> </Dispositivo> </Sector> <Sector> <Nombre>Salon</Nombre> <Dispositivo> <Nombre>Louver</Nombre> <Tipo>3</Tipo> </Dispositivo> <Dispositivo> <Nombre>GradualLighting</Nombre> <Tipo>2</Tipo> <Tipo>1</Tipo> </Dispositivo> </Sector> </Vivienda> </Viviendas>

El recorrido y interpretacin de este XML es gestionado por la claseXMLParser,queyahemosintroducidoyqueveremoscondetalle enelsiguientepunto.

5.4.Descripcindelaimplementacin
Vamosaver,deunamanerageneral,comosehaestructuradola implementacin del proyecto. A parte de las interfaces diseadas con el Interface Builder, se han programado una serie de clases que nos
42

sirven tanto para modelar la informacin que maneja la aplicacin como para controlar el contenido visible por el usuario en dichas interfaces.Sehanprogramadolassiguientesclases: Clasesdeobjetosmodelados Las clases Sector, Dispositivo y Servicio son las tres clasesimplementadasparaalmacenarygestionarlainformacin de los diferentes elementos que componen las viviendas en nuestraaplicacin.Cadaelementodomticoosectordenuestras viviendasesunainstanciadeunadeestasclases. Enlafasedediseovimoslosatributosymtodosdefinidos enestasclases,quepermitenlaestructuracindelainformacin atratarenlaaplicacin. Como ejemplos de la implementacin podemos ver por ejemploelficherodecabeceradelaclaseSector.Observamos ladefinicindeatributosydemtodos.Tratndosedeunsector, definimos su nombre y referencias a dispositivos, servicios y otrossectorescontenidos.Encuantoalosmtodos,nicamente sedefinelainicializacindelsector.
#import <Foundation/Foundation.h> @interface Sector : NSObject { NSString *nombre; NSMutableArray *dispositivos; NSMutableArray *sectores; NSMutableArray *servicios; } @property(nonatomic, @property(nonatomic, @property(nonatomic, @property(nonatomic, retain) retain) retain) retain) NSString *nombre; NSMutableArray *dispositivos; NSMutableArray *sectores; NSMutableArray *servicios;

-(id)initWithName:(NSString *)n dispositivos:(NSMutableArray *)disp sectores:(NSMutableArray *)sect servicios:(NSMutableArray *)serv; @end

Acontinuacin,comoejemplodeimplementacindeunode los mtodos, la implementacin del mtodo de inicializacin de un servicio, donde vemos que se inicializan los atributos del mismo.
43

#import "Servicio.h" @implementation Servicio @synthesize nombre, tipo, tipos; -(id)initWithName:(NSString *)n tipos:(NSMutableArray *)kind_list{ self.nombre = n; self.tipos = [[NSMutableArray alloc] init]; for (int i=0; i<[kind_list count]; i++) { [self.tipos addObject:[kind_list objectAtIndex:i]]; } return self; } @end

Clasescontroladoresdeinterfaces Las clases Root View Controller y Sectores View Controller, as como las clases Dispositivo Binario View Controller,DispositivoRegulableViewController,Dispositivo Bidireccional View Controller y Dispositivo Umbral View Controller han sido programadas como controladores de las 5 interfaces que se han definido. Estas clases nos permiten interactuarcondichasinterfaces,yportanto,conelusuario.Se gestionaenellaselcontenidoeinformacinqueapareceencada momento en la pantalla del dispositivo, as como lo que sucede cuandoelusuariointeractaconldecualquiermodo. Vemos a continuacin la cabecera de la clase controladora dedispositivosbidireccionales.
#import <UIKit/UIKit.h> #import "Dispositivo.h" @interface Dispositivo_BidireccionalViewController : UIViewController { IBOutlet UILabel *nombre_dispositivo; IBOutlet UIButton *dir1; IBOutlet UIButton *dir2; IBOutlet UIButton *stop; IBOutlet UITextView *aux; Dispositivo *dispositivo_seleccionado; } @property (nonatomic, retain) IBOutlet UILabel *nombre_dispositivo;

44

@property (nonatomic, retain) @property (nonatomic, retain) @property (nonatomic, retain) @property (nonatomic, retain) @property (nonatomic, retain) *dispositivo_seleccionado;

IBOutlet UIButton *dir1; IBOutlet UIButton *dir2; IBOutlet UIButton *stop; IBOutlet UITextView *aux; Dispositivo

-(IBAction)seleccionado_dir1:(id)sender; -(IBAction)seleccionado_dir2:(id)sender; -(IBAction)seleccionado_stop:(id)sender; @end

En este fragmento de cdigo vemos la declaracin de las propiedades de la clase. Recalcar que el tipo IBOutlet nos permitedefinirpropiedadesaniveldecodificacinquedespus puedenser,atravsdelInterfaceBuilder,asociadasaobjetosen el diseo. De este modo, se puede codificar acciones y propiedades de los objetos diseados en el IB que son instanciadosentiempodeejecucin. Enladeclaracindelos mtodos, observamos tres mtodos que corresponden a las tres posibles interacciones que puede realizar el usuario con un elemento de tipo bidireccional. Ntese tambin que el prefijo IBAction establece el mtodo,deformaanlogaa lo visto en las propiedades, comointerconectableconel Interface Builder. As, se establecen las relaciones entre la interaccin del usuarioylasaccionesarealizarenelInterfaceBuilder,pudiendo implementaraniveldecodificacindichasacciones. A continuacin vemos la implementacin de uno de estos mtodos, en concreto el que gestiona las acciones derivadas de que el usuario seleccione el botn de una de las direcciones sobreunelementobidireccional.

45

-(IBAction)seleccionado_dir1:(id)sender{ iDomoControllerAppDelegate *appDelegate = (iDomoControllerAppDelegate *)[[UIApplication sharedApplication] delegate]; NSString *cadena = [appDelegate ConstruirSenyal_bidireccional:self.nombre_dispositivo.text operation:@"enable"]; aux.text = cadena; [appDelegate MandarSenyal:cadena]; }

Se observa, como ya se especific en la fase de diseo, que estos mtodos incluidos en los controladores son los que, al recibir el evento que realiza el usuario sobre el terminal, instancianaldelegadodelaaplicacinyconstruyenlasealyla envanalservidor,produciendoelefectodeseadoenlavivienda fsica. ClaseXMLParser La clase XMLParser se encarga de gestionar el recorrido delficheroXML,ascomolainterpretacinymapeadodelmismo enestructurasdefinidasennuestroproyecto(clases). Ya sabemos que se lanza el parseado del fichero XML situado en una ruta definida, se va recorriendoycadaelementoquese encuentra (etiqueta, valor, fin de etiqueta) es interpretado. Se programanlasaccionesatomaren caso de encontrar cada uno de estos elementos de modo que una vez finalice la lectura del XML obtengamosunaseriedeinstancias de las clases que hemos definido, organizadas en vectores de referencias que permiten almacenar la estructura de nuestra vivienda o viviendas sin gastodeespacioendisco. Los mtodos han sido implementados con mucho cuidado paraque,cumpliendoconlaestructuradefinidaparalacargade ficherosXML,sepermitacualquiernmerodeniveles(sectores anidados), cualquier nmero de elementos domticos y de
46

cualquiertipo.Veamosunejemplodelaimplementacindeuno deestosmtodos.
- (void)parser:(NSXMLParser *)parser didStartElement:(NSString *)elementName namespaceURI:(NSString *)namespaceURI qualifiedName: (NSString *)qualifiedName attributes:(NSDictionary *) attributeDict { if([elementName isEqualToString:@"Viviendas"]) { appDelegate.viviendas = [[NSMutableArray alloc] init]; } else if([elementName isEqualToString:@"Vivienda"]) { unaVivienda = [[Sector alloc] initWithName:@"prueba" dispositivos:[[NSMutableArray alloc] init] sectores:[[NSMutableArray alloc]init] servicios:[[NSMutableArray alloc]init]]; sectores_activos = [[NSMutableArray alloc] initWithObjects:unaVivienda,nil]; [unaVivienda release]; unaVivienda = nil; currentTag = @"Vivienda"; } else if([elementName isEqualToString:@"Sector"]){ unSector = [[Sector alloc] initWithName:@"prueba" dispositivos:[[NSMutableArray alloc] init] sectores:[[NSMutableArray alloc] init] servicios:[[NSMutableArray alloc] init]]; [sectores_activos addObject:unSector]; currentTag = @"Sector"; [unSector release]; unSector = nil; } else if([elementName isEqualToString:@"Dispositivo"]){ unDispositivo = [[Dispositivo alloc] initWithName:@"prueba" tipos:[[NSMutableArray alloc] init]]; [[[sectores_activos lastObject] dispositivos]addObject:unDispositivo]; currentTag = @"Dispositivo"; [unDispositivo release]; unDispositivo = nil; } else if([elementName isEqualToString:@"Servicio"]){ unServicio = [[Servicio alloc] initWithName:@"prueba" tipos:[[NSMutableArray alloc] init]]; [[[sectores_activos lastObject] servicios]addObject:unServicio]; currentTag = @"Servicio"; [unServicio release]; unServicio = nil; } }

47

 Delegadodelaaplicacin. ExisteunaclaseprincipalenlosproyectosparaiPhoneOS, llamada en este caso iDomoControllerAppDelegate, que acta, como su nombre indica, como delegado de la aplicacin. Esta claserecibeloseventosgeneralesdelaaplicacincuandoestase inicia. As pues podemos encontrar mtodos que responden a eventos tales como la finalizacin del lanzamiento de la aplicacin, lo que nos permite manejar exactamente en todo momento el flujo de nuestra aplicacin, y, entre otras cosas, lo quedebesucederantesdequeelusuariovealaprimerainterfaz cargada. Es precisamente aqu donde podemos programar el recorridodelficheroxml. Veamos algunos de los mtodos implementados en esta clase,elmtododeconstruccindeunasealparaunelemento detipobinario,yelmtodoencargadodeenviardichaseal.
-(NSString *)ConstruirSenyal_binaria:(NSString *)nombre operation:(NSString *)operacion{ NSString *aux=self.http_prefijo; aux = [aux stringByAppendingString:@"operation="]; aux = [aux stringByAppendingString:operacion]; aux = [aux stringByAppendingString:@"&PERVMLSERVICENAME="]; aux = [aux stringByAppendingString:nombre]; return aux; } -(void)MandarSenyal:(NSString *)cadena{ NSURL *url = [[NSURL alloc] initWithString:cadena]; NSMutableURLRequest *theRequest = [[NSMutableURLRequest alloc] initWithURL:url]; [theRequest setHTTPMethod:@"POST"]; NSURLConnection *theConnection = [[NSURLConnection alloc] initWithRequest:theRequest delegate:nil]; [theConnection start]; }

Se puede observar en esta implementacin lo especificado en fase de diseo en cuanto a la construccin de la seal. Una posiblesealenviadaalservidorennuestroprototiposera: http://cerebrito.dsic.upv.es/web/services/unsecureWebUI?ope ration=enable&PERVMLSERVICENAME=Buzzer

48

6.Problemasencontradosydesarrollosfuturos.

6.1.Dificultadessurgidas
Vamos a ver ahora algunos de los puntos que mayor dificultad o reflexincrearondurantelarealizacindeesteproyecto,yaseaporsu dificultad, por los problemas creados o por lo comprometido de una decisin. 6.1.1.Lacreacinyalmacenamientodelainformacin Nuestraaplicacintratadeproporcionarunaherramientaparael usuario interesado en interactuar con su vivienda o elementos domticos.Estohacequeelhechodeconfigurar,definir,crearocargar la informacin sobre esa vivienda o elemento sea un punto crucial a tenerencuenta. Varias opciones fueron apareciendo sobre este tema. En un principio,conunamentalidadquetraselpasodeltiempoacabviendo como totalmente desenfocada, pens que lo correcto es que la propia aplicacinpresentaraunaspantallasdeedicinparapoderircreando, editandoyborrandocadaunodeloselementosqueelusuariodeseara. Este concepto, tan instaurado en la costumbre de desarrollar aplicaciones de escritorio, no tena cabida en la programacin de una aplicacincomoestaparaunterminalmvil.Vuelvoadestacar,quela clavedeunaaplicacinparaundispositivomvil,yenconcretoparael iPhone, est en la sencillez y claridad de la misma. Para empezar el hardware no est diseado para trabajar con l durante un largo periodo de tiempo, mirando una pantalla de apenas unas pulgadas y tratandodeescribirenuntecladominsculo.Peromsalldeesto, loverdaderamenteimportanteesqueelusuarionodeseapasarhoras configurandoelaccesoaloqueverdaderamenteleinteresa,elcontrol desuvivienda. Por otra parte, era un claro requisito fundamental poder definir aquello susceptible de ser controlado por la aplicacin. Baraj la idea de almacenar en un fichero binario en el terminal el contenido de la vivienda, que previamente tendra que ser definido dentro de la aplicacin! No tena sentido. Estaba ante el mismo problema, o an
49

peor, tendra que definir la vivienda dentro del cdigo, con lo que cualquiercambiosupondramodificarlapropiaaplicacin.Inviable. Fue entonces cuando opt por la decisin que se ha implementado, almacenar ese fichero en el exterior y leerlo desde la aplicacin. Y qu mejor manera que utilizar el lenguaje XML y almacenar el fichero en un servidor. Ya hemos visto como hemos definidolaestructuraautilizarenla definicindenuestravivienday cmoselee,serecorreyseinterpretasucontenido.Unacargarpida, efectiva, sin necesidad de almacenar la informacin en el terminal, flexibleyescalableproblemaresuelto. 6.1.2.Elementosdevariostipos En un momento dado, los requisitos iniciales se ampliaron y se contempl la posibilidad de que un mismo elemento pudiera pertenecer a ms de un tipo. Esto tiene mucho sentido, ya que por ejemplounabombillaregulable,puedesercontroladaconunafuncin de apagado y encendido (tipo binario) o puede ser controlada su intensidad progresivamente (tipo regulable). Como este, podran presentarsemuchosotroscasos. A nivel de capa de negocio y de datos no supuso demasiado problema. Se adapt el desarrollo para que se permitiera tanto en la definicin XML, como en la definicin de los elementos domticos (clases)ysegestionaraadecuadamente.Elproblemallegalahorade representarlovisualmente,eneldiseodelasinterfaces. Laaplicacinestbasadaenlanavegacin,loquequieredecirque existe una pila de navegacin, donde se pueden apilar o desapilar controladoresdevistas,quesonlasclasesquegestionancadaunade las interfaces. As, cuando se selecciona un elemento, se apila en la navigation stack el controlador correspondiente al tipo del mismo. Asmismo,cadainterfaz,quepuedetenernvistas,tieneunavistapor defecto, que se define en el Interface Builder. Tambin se pueden apilarvistasdemodoquecuandouncontroladorestelprimeroenla piladenavegacin,eslavistaqueestlaprimeraenlapiladevistasla quesevisualiza. La idea era crear un tab bar, que es un objeto de interfaz que muestra una barra con diferentes pestaas y que nos permitira seleccionar, una vez cargada una interfaz de un elemento, el resto de
50

interfaces de dicho elemento correspondientes a sus tipos. Fue aqu dondesurgieronlosproblemas.PrimeroqueAppledesaconsejaeluso de este tipo de objetos dentro de aplicaciones de navegacin, por problemas en el manejo de las pilas. El segundo, es que al haber definido una interfaz por cada elemento, el objeto tab bar, que se incluyeeneldiseodeunainterfazysegestionadesdeuncontrolador, nopodaestarcargadoentodomomento,puestoqueparacambiarde un tipo a otro haca falta apilar un nuevo controlador, y se pierde el controlsobreelanterior.Todoestelohizocasiimposiblecumplircon este requisito. Finalmente y de forma provisional, consegu implementar el tab bar como algo pintado encima de cada vista en cadamomentoquesecargabalamisma,peroresultserunamanera engorrossimademanejar,suciadeprogramarynoconseguqueesta dificultadfueratransparenteparaelusuarioyaquequedabanresiduos deestelodeinterfaces,vistas,controladoresypilasqueseproduca, peseaqueseconsiguiquefuncionara. Esprobablequeelhechodehaberoptadopordefinirunainterfaz por cada tipo de elemento domtico sea un punto crtico en este aspecto. Si en lugar de 4 interfaces diferentes se hubiera creado una nicainterfazcon4vistasdiferentes,spodramoshaberinsertadoen lainterfazuntabbar,gestionadoporunnicocontrolador,quefuera manejando la pila de vistas una vez se carga cualquier elemento de cualquiertipo.

6.2.Posiblesmejorasydesarrollosfuturos
Adems de el cambio de interfaces por vistas nombrado en el punto anterior, durante la realizacin del proyecto han ido surgiendo ideasdeposiblesmejoras,modificacionesodesarrollosfuturosquese podranllevaracaboparamejorarlo,modificarlooampliarlo.Vamosa veralgunodeellos. 6.2.1.Informacinalmacenadaenbasesdedatos

51

No considero esto una mejor, sino una variacin o simplemente una alternativa al desarrollo planteado. La informacin sobre las viviendas,podraalmacenarseenunabasededatos implementada en el propio terminal. IPhone OS soporta el motor de bases de datos SQLite, lo que permitiraalmacenarlainformacincargadaenuna base de datos, pudiendo por ejemplo implementar mtodos y interfacesparahacermodificaciones,ounhistricodeviviendaspara poderirhaciendocargasdesdeficherosxmlunanicavez. 6.2.2.Informacindeestadodeloselementos Enesteproyectohemosdiseadoydesarrolladolainteraccindel usuarioconsuviviendaatravsdeunservidorquerecibepeticiones POST http para modificar el estado de un determinado elemento domtico. Sin embargo, no obtenemos ninguna informacin al respecto.Porejemplo,alseleccionarundispositivodetipobinario,se nos presenta la interfaz correspondiente, con el botn deslizante en estado off. Esto se hace por defecto, y de poder consultar el estado delelementopodramossituarloenelestadoquerealmenteestuviese en ese momento. Adems, cuando nosotros mandamos una seal de cambiodeestado,noobtenemosinformacinsobresidichocambiose hallevadoacaboono.Aspues,lorepresentadoenlainterfazyloque enlarealidadsucedepuedeestardesacompasado,cosaqueresultara incomodoyconfusoparaelusuario. Esta modificacin requerira, adems de los cambios de programacin correspondientes en nuestra aplicacin, que el propio servidortuvieraunametodologaimplementadaparaestasconsultas, ya fuera devolviendo una respuesta con dicha informacin tras una peticinhttpodecualquierotraforma. 6.2.3.Interfazgrficaalternativa En las primeras reuniones que definieron a grandes rasgos el contenidodelpresenteproyectoentreeldirectoryyo,sepusosobrela mesa la posibilidad de desarrollar una interfaz grfica que representara la vivienda eficiente de nuestro prototipo, y que
52

permitieraalusuariointeractuarconlamismadeunamaneraanms intuitiva,utilizandounaimagenenlugardetextoparamostrartodoel contenidodenuestroviviendo. Las ventajas estn claras. An ms comodidad. El usuario podra simplemente tocar con su dedo encima del dispositivo deseado, o de una habitacin (sector) para ver respectivamente la interfaz del elemento seleccionado o un listado como los que en el desarrollo actualseutilizan.

Sinembargo,estaideapuedetenertambinalgunosproblemas.El primero es que esto no permitira o dificultara la existencia de sectoresanidados,yaquesisepresentaunaimagendeunavivienda,y estatieneunsector2planta,queasuveztieneotrashabitacionesy elementos,tendramosqueincluirennuestraimagendelaviviendaun acceso a esa segunda imagen, y se complica ms si pensamos en ms niveles. Elsegundoproblema,muchomsgravetodavaqueesteprimero, es que esto no permitira el uso de la aplicacin para cualquier vivienda, ya que digitalizar una vivienda supondra la definicin de estaimagen(noslolaimagenens,sinotodalaconfiguracindelas reasdelamismaconlaqueelusuariopuedeinteractuar).Seperdera as toda la flexibilidad de la aplicacin, limitndola a su uso para una viviendaoentornopreviamentefijadoydesarrollado.
53

Loconsideropuesunaposibleampliacin,quehabraquesopesar y razonar previamente para solventar los problemas derivados expuestos.Adems,sepodraaprovecharelacelermetroqueposeeel terminaliPhoneparacombinarlarepresentacinactualdetextoconla representacin propuesta de imagen. Por ejemplo, si el usuario mantieneeldispositivoenposicinvertical,navegaraporlaaplicacin tal cual se hace en el presente desarrollo, mientras que si tumba el dispositivositundoloenhorizontal,pasaraaobtenerunanavegacin conimagen.Sinduda,muyatractivo. 6.2.4.Pantalladeconfiguracin He hablado en mltiples ocasiones de la importancia de la flexibilidaddelaaplicacin.Sinembargo,enelpresentedesarrollola comunicacinconelservidoresdeundeterminadomodo,yesolimita la utilidad de la aplicacin. Sera muy interesante que se pudieran configurar algunos de estos parmetros, tales como la direccin del servidor con el que nos vamos a comunicar para interactuar con los elementos,olarutadondeseencuentraelxmlacargar.Estopermitira la posibilidad de que con la aplicacin se pudieran controlar no slo diferentesentornosdomticos,sinoinclusoentornoscontroladospor diferentesservidores. Se podra disear una interfaz de configuracin que se pudiera cargar desde la pantalla principal (donde se listan las viviendas cargadas)paraconfigurarestosparmetros.Seplanteatambincomo unaposibleampliacin.

54

7.ANEXO1.Pordndeempezar
Empezar no slo es el primer paso, sino que suele ser el ms complicado.EnelcasodedesarrolloparaiPhoneOS,sobretodosinose esthabituadoaldesarrolloparaentornosMacodispositivosmviles, estopuedeseranmayor. Elprimerpaso,esiralawebdedesarrolloparaIPhonedeApple (http://developer.apple.com/iphone/index.action) y registrarse con unacuentadedesarrollador.Elregistrogratuitonosdaaccesoatodas lasherramientasydocumentacinexistentes.Elregistrodepagocomo desarrollador nos permitira probar nuestras aplicaciones en terminalesiPhoneypublicarlasenlaAppStore,peroestoyaseescapa delonecesario. Enesamismaweb,encontraremosunmontndedocumentacin, pero antes de comenzar a leer, debemos descargarnos el SDK (Software Developement Kit) que nos proporciona Apple. Como ya vimos en los primeros apartados de esta memoria, incluye todas las herramientasnecesariasparaeldesarrollodeaplicacionesparaiPhone OS. Hasta aqu los pasos bsicos indispensables. Crear aplicaciones para iPhone OS es relativamente simple con las plantillas que incorporadasenelXcode,perocrearaplicacionesquehacenalgotily que tengan un aspecto agradable requieren mucho ms tiempo de lectura de documentacin. Recomendara revisar la documentacin propuestaporAppleenestamismaweb,quenosdaunaideageneral decmosefundamentaiPhoneOs(sibienlalecturadeestamemoria podravalercomounbuenpuntodepartida). Tras esta primera fase de lectura y como se suele decir habitualmente, la prctica hace al maestro. Mi recomendacin es buscar webs con ejemplos y tutoriales, y comenzar a trastear con ellos, tratando de reproducirlos, y as, poco a poco, ir descubriendo todoslosmecanismos,complejidadesyposibilidadesquenosbrindala programacinparaiPhone.Recomiendoentreotras: http://cocoadevcentral.com/d/learn_objectivec/ http://www.iphonesoftware.es/ http://icodeblog.com/
55

 http://www.iphonesdkarticles.com/ Tambin recomiendo el curso de programacin para iPhone que se llev a cabo en la universidad Stanford, y que podemos encontrar ntegramentegrabadoenlared. Por ltimo, no conviene olvidar que existen mltiples foros de programacin y en concreto dedicados al desarrollo de aplicaciones para iPhone OS que podemos encontrar muy fcilmente y que nos proporcionarnunaayudainestimablecuandotodolodemsfalle.Una bsqueda en cualquier navegador web nos devolver decenas de resultadosinteresantesalrespecto.

56