E s c u e l a T é c n i c a S u p e r i o r d e I n g e n i e r í a I n f o r m á t i c a . U P V .

CarlosSerranoGalianaProyectoFinaldeCarreradirigidoporJoanFonsiCors.

Enero 2010

DesarrollodeunaaplicacióniPhoneparainteractuarconunaviviendadomótica.

2

Tabladecontenido1.Introducción...........................................................................................................41.1.Motivación ........................................................................................................................................................ 41.2.Contextoytecnología................................................................................................................................... 41.2.1.Domótica ........................................................................................................................................................41.2.2.TerminaliPhone..........................................................................................................................................5

1.3.Propósitosyobjetivos ................................................................................................................................. 6

2.Entornotecnológico...............................................................................................72.1.Desarrolloparadispositivosmóviles.................................................................................................... 72.2.iPhoneOS .......................................................................................................................................................... 82.2.1.ArquitecturadecapasdeliPhoneOS .................................................................................................82.2.2.DesarrolloparaiPhoneOS .....................................................................................................................9

2.3.Herramientasdedesarrollo:iPhoneSDK..........................................................................................112.3.1.Xcode ............................................................................................................................................................. 132.3.2.InterfaceBuilder ...................................................................................................................................... 142.3.3.Instruments ................................................................................................................................................ 15

3.Casodeestudio:Análisis. .....................................................................................173.1.Objetivosyrequisitosdelaaplicación. ..............................................................................................173.1.1.Objetivobásicodelaaplicación. ....................................................................................................... 173.1.2.Especificaciones,requisitosyfuncionalidades............................................................................ 17

3.2.Casosdeuso ...................................................................................................................................................183.3.Diagramadeclases......................................................................................................................................204.Diseño..................................................................................................................224.1.Diagramadeclasesampliado. ................................................................................................................224.1.1.Clasesdemodelizacióndeinformación. ........................................................................................ 234.1.2.Clasescontroladoresdevistas............................................................................................................ 254.1.3.ClasederecorridodelXML .................................................................................................................. 274.1.4.Clasedelegadodelaaplicación......................................................................................................... 28

4.2.Cargadedatos:EsquemaXML ...............................................................................................................284.3.Interacciónconlasviviendasfísicas....................................................................................................314.4.Interfazgráfica ..............................................................................................................................................325.Prototipoyimplementación.................................................................................335.1.Elprototipo:Unaviviendaeficiente. ...................................................................................................335.1.1.Tiposdeelementosdomóticos. .......................................................................................................... 345.1.2.Elementosdomóticosydistribución................................................................................................ 34

5.2.Interfacesdeusuario..................................................................................................................................365.3.Cargadelprototipo.DefiniciónenXML .............................................................................................405.4.Descripcióndelaimplementación .......................................................................................................42

6.Problemasencontradosydesarrollosfuturos. .....................................................496.1.Dificultadessurgidas ..................................................................................................................................496.1.1.Lacreaciónyalmacenamientodelainformación .................................................................... 496.1.2.Elementosdevariostipos..................................................................................................................... 50

6.2.Posiblesmejorasydesarrollosfuturos ..............................................................................................516.2.1.Informaciónalmacenadaenbasesdedatos................................................................................ 516.2.2.Informacióndeestadodeloselementos........................................................................................ 526.2.3.Interfazgráficaalternativa ................................................................................................................ 52

3

6.2.4.Pantalladeconfiguración.................................................................................................................... 54

7.ANEXO1.Pordóndeempezar ..............................................................................55

4

1.Introducción

Elpresentedocumentoconstituye lamemoriadelProyectoFinaldeCarrerarealizadoporCarlosSerranoGaliana,alumnodelaantiguaFacultad de Informática de la Universidad Politécnica de Valencia(nuevaEscuelaTécnicaSuperiordeIngenieríaInformática).

El PFC desarrollado tiene como título “Desarrollo de unaaplicación iPhone para interactuar con una vivienda domótica” y hasidodirigidoporJoanFonsiCors,profesoradheridoalDepartamentodeSistemasInformáticosyComputación.

1.1.Motivación

LaseleccióndeesteproyectocomomiPFCvienederivadademisintereses personales tantopor la tecnología involucrada comopor larelaciónconelmundodeladomótica.

Poseo un terminal iPhone y siento una gran curiosidad por sutecnologíaysusposibilidadestécnicas.Asímismo,tuvelaoportunidadde realizar un Erasmus Intensive Programme sobre inteligenciaambientalquemeintrodujoeneláreadeladomótica.

Aunando estos dos intereses, compartidos por mi director deproyecto, nació la propuesta de este PFC, con el que pretendoiniciarme en el desarrollo de aplicaciones para dispositivos móviles,obtener una visión del iPhone desde la posición del desarrollador yahondarenlasmotivacionesyposibilidadesdeladomótica.

1.2.Contextoytecnología

1.2.1.Domótica

La Wikipedia define la domótica como el conjunto de sistemascapaces de automatizar una vivienda, aportando servicios de gestiónenergética,seguridad,bienestarycomunicación.Ladomóticanoessinounaramamásdelacienciaydelatecnologíaalserviciodelhombre,

5

quepretendenfacilitarohacermáscómodasuvidadiaria.Desdehaceañossevienenrealizandoprogresosenesteárea,proponiendonuevastecnologías y implantando estándares para que, poco a poco, seconviertaenunarealidadextendidaalámbitocotidiano.

En el presente proyecto, se ha hecho uso de la experiencia deldirectorenesteámbito.Sehautilizadounamaquetadeunaviviendaeficiente desarrollada con el estándar europeo para domótica,EIB/KNX, como escenario de simulación de una vivienda rural, y lagestióndelamismadesdeunaaplicaciónservidordesarrolladaenunlaboratoriodeinvestigacióndelDSIC.

1.2.2.TerminaliPhone

El iPhone es un dispositivo móvil desarrollado por lamultinacionalAppleque combina tresproductos enuno: un teléfonomóvil,unreproductordemúsicayvídeoyundispositivodeaccesoaInternet.Elterminal,porsucuidadodiseño,susencillezdemanejo,suscaracterísticastécnicas(incluidasupantallatáctil)ysusinnumerablesfuncionalidades se ha convertido rápidamente en un referente en elmercadotecnológico.

Así mismo, el desarrollo deaplicaciones para este terminalestá a la orden del día. Un kit dedesarrollo software (SDK) propiode la marca permite a unprogramador crear aplicacionesque corran bajo el sistemaoperativo iPhoneOSqueutilizaeldispositivo. La propia casapermite comercializar a través desu tienda online (App Store) las

aplicacionesdesarrolladasporterceros,loquedotadeundinamismoyunaprofundidadalmercadoquelohacenmuyinteresante.

En concreto, la programación para esta terminal se realizautilizando el entorno de desarrollo Xcode y el lenguaje deprogramaciónObjective‐C.

6

1.3.Propósitosyobjetivos

Elproyectoconsisteeneldesarrollodeunaaplicacióndecontrolpara vivienda domótica para un dispositivo móvil, pero con ladificultadyposibilidadesañadidasqueofrecelaprogramaciónparaelterminalmóviliPhonedeApple.

Enesteproyectosedesarrollaráunainfraestructuraquepermitacrear interfacesdeusuarioparacontrolar sistemasdomóticos, en losque la interfaz permitirá ubicar los servicios y dispositivos de la(s)vivienda(s), así comoutilizarlosydefinir lasdiferentesubicacionesosectoresdelaviviendaparaaccederaestosrecursos.

El usuario debe poder pues, crear los entornos (viviendas)domóticos, con losdiferenteselementosydistribuciónqueconsidereoportunos,yutilizarlaaplicaciónparalanavegaciónintuitiva,sencillay completa que permita el uso de los diferentes dispositivos yservicios.

No obstante, cabe destacar que este proyecto no se centra en larealización de la aplicación en sí, si no que se lleva a cabo con lafinalidad de aprender a desarrollar aplicaciones para dispositivosmóviles y explorar lasposibilidadesy característicasde la tecnologíaiPhone y iPhone OS. La aplicación desarrollada sirve pues comoprototipo y primer paso para el desarrollo de aplicacionesrelacionadasconladomóticaparadispositivosmóvilesiPhone.

7

2.Entornotecnológico

2.1.Desarrolloparadispositivosmóviles.

Los dispositivosmóviles han evolucionado enormemente en losúltimos tiempos, desde PDAs hasta Smart Phones, estamos siendotestigos del boom de las tecnologías móviles. Esta evolución hapermitidoyprovocadoelcrecimientoexponencialde lasaplicacionesdesarrolladasespecíficamenteparaestossectores,yelmercadodelasmismas. Sin embargo, se trata deun sectormuy específico, conunasposibilidadesylimitacionespropias.

El desarrollo de aplicacionesparadispositivosmóviles suponeunreto para cualquier programadoracostumbrado a la programación deaplicaciones de escritorio, o inclusode aplicacionesweb. Las diferenciasentre las capacidades técnicas sonabismales,yestosuponeunaseriedefactores a tener en cuenta a la hora

de plantearse el desarrollo de una aplicación móvil. Lo másimportantesson:

Memoriayprocesamiento

Es imprescindible tener en cuenta las limitaciones de losdispositivos móviles en estos aspectos. No disponemos de losmismos recursos que nos encontraríamos en un ordenadortradicional, y por tanto a la hora de la programación hay quetener cuidado de no sobrepasar las capacidades técnicas denuestro terminal. Las aplicaciones móviles tienden a ser mássencillas y con procesos más concretos que sus homólogas deescritorio. Una palabra define a la perfección este concepto:optimizar.

Interfaz

El tamaño de los dispositivos y de las pantallas de losterminalesmóvileshadeserunfactorconsideradoalahoradediseñarlainterfazdenuestraaplicación.Unentornocompletoybien desarrollado para un escritorio puede ser totalmente

8

inviable para un terminal móvil. La sencillez en el diseño y laintuición del uso son requisitos para este tipo de aplicaciones.Por otra parte, algunos terminales como el iPhone brindannuevas posibilidades como las pantallas multitáctiles o losacelerómetros.

Almacenamiento

Pese a los avances en este aspecto en losúltimos tiempos,los dispositivos móviles todavía tienen una restricción notableen cuanto a espacio de almacenamiento disponible. Hay quecuidar en el desarrollo la cantidad de información a almacenaren el terminal, y buscar siempre posibles alternativas parareducirestasnecesidades.

2.2.iPhoneOS

iPhone OS comprende el sistema operativo y las tecnologíasutilizadasparacorreraplicacionesnativasenlosdispositivosiPhoneyiPod Couch.Muy relacionado conMac OS X, iPhone OS fue diseñadopara cumplir con las necesidades de un entorno móvil, donde lasnecesidadesdelusuariosonligeramentediferentes.

2.2.1.ArquitecturadecapasdeliPhoneOS

EniPhoneOS,laarquitecturadesistemasubyacenteymuchasdelastecnologíassonsimilaresalasencontradasenMacOSX.Elkernelen iPhone OS está basado en una variante de la misma base que elkernel de Mac OS X. Por encima de este kernel están las capas deserviciosutilizadasparaimplementaraplicacionesenlaplataforma.

Estaestructuradecapasexpandelasposibilidadesalimplementarcódigo. Por ejemplo, las capas CoreOS y Core Services contienen lasinterfaces fundamentales para IPhone OS, incluyendo aquellasutilizadasparaaccederaficheros,tiposdedatosdebajonivel,socketsdered,etc.EstasinterfacesestánbasadasenCyincluyentecnologíascomoCoreFoundation, SQLiteyaccesoahilosPOSIXy socketsUNIXentreotros.

9

Conforme nos desplazamos a niveles superiores, podemosencontrar tecnologías más avanzadas que utilizan una mezcla deinterfaces basadas en C y Objective‐C. Por ejemplo, la capa Mediacontiene las tecnologías fundamentalesutilizadasparadar soportealdibujo2Dy3D,audioyvídeo.Estacapaincluyelastecnologíasbasadasen C OpenGL, Quartz y Core Audio. También contiene el motor deanimaciónCoreAnimation.

En la capa Cocoa Touch, la mayoría de las tecnologías utilizanObjective‐C. Los frameworks en estos niveles proporcionan lainfraestructura fundamental utilizada por cualquier aplicación. Porejemplo, el Framework Foundation proporciona soporte deorientación a objetos paracolecciones, gestión de ficheros,operacionesde redymuchomás.ElFramework UIKit proporciona lainfraestructura visual para nuestrasaplicaciones, incluidas clases paraventanas, vistas, controles y loscontroladores que gestionan estosobjetos.Otrosframeworksaesteniveldanaccesoalainformacióndecontactoseimágenesdelusuario,acelerómetroyotrascaracterísticashardwaredeldispositivo.

El punto de partida para cualquier proyecto es la capa CocoaTouch y el Framework UIKit en particular. Cuando se plantea quétecnologías adicionales utilizar, se recomienda empezar por losframeworks de nivel más alto e ir descendiendo por las capasconforme sea necesario. Los frameworks de más alto nivel hacensencillo dar soporte a comportamientos del sistema estándar, con elmínimoesfuerzoporpartedeldesarrollador.

Podemos encontrarmás información sobre la tecnología iPhoneOSenelsiguienteenlace.

2.2.2.DesarrolloparaiPhoneOS

LaaplicacionescreadasporelprogramadorresideenelHomedelusuario,juntoaotrasaplicacionesdelsistemacomoPhotos,WeatheroClock. Una vez la aplicación es lanzada, aparte del kernel y algunosdemonios de bajo nivel, la aplicación es la única corriendo en el

10

sistema.Mientrasseejecuta,laaplicaciónocupalapantallacompletayesel focodeatencióndelusuario.CuandoelusuarioaprietaelbotónHome,laaplicaciónfinalizayelsistemavuelvealapantallaHome.Sepuedetomarventajadelhardwareintegradocomolosacelerómetrosolagestióndegráficosparaejecutarnuestropropiocódigo.

LamaneraconlaquelosusuariosinteractúanconlosdispositivosiPhone y iPod Couch es fundamentalmente diferente a como los

usuariosinteractúanconMacOSX,yportantola manera de desarrollar las aplicacionestambiéndebeserlo.EnunaaplicacióniPhone,no hay concepto de ventanas de documentospara mostrar contenido. En su lugar, toda lainformación de la aplicación es mostrada enuna única ventana. Esto ha llevado a lacreación de nuevas vistas y controles quepermitan presentar la información de laaplicación de forma organizada. Además,algunos de los elementos más estándarespueden comportarse de una maneraligeramente diferente. Estas diferencias sontransparentes, pero requieren en ocasiones

replantearselaformadeorganizarypresentarelcontenidodenuestraaplicación.

El modelo de manejo de eventos en iPhone OS representa unadesviacióndelalasaplicacionestradicionalesdeescritorio.Enlugardedependerdeeventosdetecladooratón,iPhoneOSintroducelaideadeeventos táctiles (touch events). Un touch event puede ocurrir encualquier momento y en combinación con uno o más eventosadicionales. Los toques pueden ser usados desde para detectarinteracciones simples con el contenido, como seleccionar o arrastrarítems, o hasta complejos gestos como los realizados para hacerfuncionesdezoom.

Más allá de considerar la estructura básica de la aplicación, hayque pensar en cómo van a utilizarla los usuarios. Las aplicacionesiPhonedebenserlimpiasycentradasenloquelosusuariosnecesitanencadamomento.Caberecordarquemuchosdelosusuariosdeestosdispositivosnecesitanaccederainformaciónrápidamenteynoperdermucho tiempo navegando entre capas y capas de la aplicación. Undiseño simple que destaque la información esencial que necesita elusuarioesimportante.

11

Como ya hemos mencionado, los frameworks que se utilizan aliniciar el desarrollo de una aplicación son Foundation y UIKit, queproveen los servicios básicos utilizados por todas las aplicacionesiPhone.Conformeserefinalaaplicación,sepuedenirutilizandootrosframeworksqueofrezcanlosserviciosquenecesitamos.

En la web de desarrolladores de apple podemos encontrarmásinformación sobre Foundation Framework Reference y sobre UIKitFrameworkReference.

2.3.Herramientasdedesarrollo:iPhoneSDK

El iPhone Software Developement kit es un paquete paradesarrolladores,preparadoporAppleydistribuidogratuitamentecontodo lonecesarioparaque cualquierprogramadorpuedadesarrollarsuspropiasaplicacionesparaiPhoneOS.

El iPhone SDK viene con todas las interfaces, herramientas yrecursos necesarios para desarrollar aplicaciones iPhone desdecualquierordenadorMacintosh.

Apple distribuye la mayoría de sus interfaces de sistema enpaquetes especiales llamados frameworks. Un Framework es undirectorioque contieneuna librería compartidadinámicamentey losrecursos (tales como ficheros de cabecera, imágenes, aplicaciones deayuda, etc.) necesarios para apoyar esa librería. Para utilizarframeworks,seenlazanenelproyectode laaplicacióncomoseharíacon cualquier librería común. Enlazándolos al proyecto obtenemosaccesoatodaslascaracterísticasdelFrameworkytambiénpermitealasherramientasdedesarrollosaberdóndeencontrar los ficherosdelascabecerasyotrosrecursos.

Aparte de frameworks, Apple también distribuye algunastecnologíasenformadelibreríascompartidasestándar.ComoiPhoneOS está basado en UNIX, muchas de las tecnologías que forman losnivelesmásbajosdel sistemaoperativosonderivadasde tecnologíasopen‐source. Las interfaces para estas tecnologías están por tantodisponiblesenlaslibreríasestándarylosdirectoriosdeinterfaz.

Algunos de los componentes claves del Software DevelopementKitserían:

12

XcodeTools

ProporcionalasherramientasparapermitireldesarrollodeaplicacionesiPhone,incluyendolossiguienteselementos:

Xcode

Entorno de desarrollo integrado que gestiona losproyectos de aplicaciones y permite editar, compilar,lanzar y depurar el código. Xcode está integrado conmuchas otras herramientas y es la aplicación de usoprincipalduranteeldesarrollo.

InterfaceBuilder

Una herramienta que se utiliza para montar lainterfazdeusuariovisualmente.Losobjetosde interfazque se crean son guardados en un fichero con formatoespecial y cargados en la aplicación en tiempo deejecución.

Instruments

Unaaplicacióndeanálisisdecomportamientoydedebugging. Se puede utilizar para reunir informaciónsobre el comportamiento en tiempo de ejecución de laaplicaciónyidentificarpotencialesproblemas.

iPhoneSimulator

Una aplicación para Mac OS X que simula la pila detecnología iPhone, permitiendo probar las aplicaciones iPhonelocalmenteenunordenadorMacintosh.

iPhoneReferenceLibrary

ElSDKincluyedocumentacióndereferenciaparaiPhoneOSpor defecto y se pueden descargar versiones más completas,incluyendoejemplosdecódigo.

AunqueelSDKproporcionaelsoftwarenecesarioparadesarrollaraplicaciones, Xcode y Instruments también permiten interactuardirectamente con un dispositivo adjunto para ejecutar y depurar elcódigo en el terminal físico. El desarrollo en un dispositivo físicorequiere registrarse en el programa de pago de Apple iPhoneDeveloperProgramyconfigurarelterminarparaestospropósitos.

13

MásinformaciónsobreeliPhoneDeveloperProgram.

2.3.1.Xcode

El centro de la experiencia de desarrollo es la aplicación Xcode.Xcode es un entorno integrado de desarrollo que provee todas lasherramientasnecesariasparacrearygestionarlosproyectosiPhoneysus ficheros fuente, compilar el código en un ejecutable, lanzar ydepurar el código bien en el simulador iPhone o en un dispositivo.Xcode incorpora un gran número de características para hacer másfácileldesarrollodeaplicacionesiPhone,comoson:

Un sistema de gestión de proyectos para definir productossoftware.

Un sistema de edición de código que incluye característicascomo el coloreado de sintaxis, autocompletado de código yindexado.

Un visor de documentación avanzado con sistema debúsqueda.

CompiladoresGCCparaC,C++,Objective-C,Objective-C++yObjective-C2.0.

DepuraciónaniveldefuenteutilizandoGDB.

Compilaciónpredictivaqueaceleraelproceso.

Soporte para snapshots de proyectos, que permiten unaformaligeradegestionarelcódigofuente.

Herramientasdeanálisisdelasaplicaciones.

Paracrearunanuevaaplicación iPhoneseempiezaporcrearunnuevo proyecto en Xcode. Un proyecto gestiona toda la informaciónasociada con la aplicación, incluyendo los ficheros fuente, laconfiguración de compilación y todos los elementos para juntar laspiezas.ElcorazóndecadaproyectoXcodeeslaventanadelproyecto.Estaventanaproporcionaacceso rápidoa todos loselementosclavesdenuestraaplicación.Enlalistadegruposyficherossegestionanlosficherosdenuestroproyecto, incluyendoelcódigofuente.Enlabarra

14

de herramientas, se accede a los comandos y herramientas máscomunes.Enelpaneldedetalles,sepuedeconfigurarunespacioparatrabajarenelproyecto.

CuandosecompilaunaaplicaciónparaXcode,tieneslaposibilidad

deelegircompilarlaparaelsimuladoriPhoneoparaundispositivo.Elsimuladorproporcionaunentornolocalparatestearlasaplicacionesyasegurarsedequesecomportandemaneraesperada.Unavezseestásatisfecho con el comportamiento, se puede compilar la aplicación ylanzarlaenuniPhoneo iPodtouchconectadoalordenador.Correr laaplicación en un dispositivo físico proporciona un entorno de testdefinitivo,yXcodepermitedepurarlaaplicacióncorriendoenél.

2.3.2.InterfaceBuilder

Interface Builder es la herramienta a utilizar para diseñarvisualmente la interfaz de usuario de nuestra aplicación. UtilizandoInterface Builder, podemos montar la ventana de nuestra aplicaciónarrastrandoysoltandocomponentespreconfigurados.Seincluyenunaseriedecontrolescomoswitches,textfieldsobuttons.

Una vez se han colocado los componentes en la superficie denuestraventana,podemosposicionarlosanuestroparecer,configurarsusatributosutilizandoel inspector,yestablecer las relacionesentreesos objetos y nuestro código. Cuando la interfaz está terminada, seguardaenunficheronib,formatopropioparalasinterfaces.

15

LosficherosnibquesecreanenInterfaceBuildercontienentodala información que el Framework UIKit necesita para recrear losobjetos en tiempo de ejecución de la aplicación. Al cargar un ficheronib durante la ejecución esto crea una instancia de todos los objetosalmacenados en el mismo, con la configuración que le dimos en elInterface Builder. También utiliza la información de conexionesespecificadasparacrear lasconexionesentre las instanciascreadasycualquier objeto existente en nuestra aplicación. Estas conexionesproporcionananuestrocódigopunterosalosobjetosdelficheronib,ytambién se la proporcionan a los propios objetos para comunicaraccionesdeusuarioalcódigo.

En general, utilizar Interface Builder ahorra mucho tiempo encuantoacrearlainterfazdeusuariodelaaplicación.InterfaceBuilderelimina el código necesario para crear, configurar y posicionar losobjetos que conformannuestra interface. Por ser un editor visual, seconsigueobtenerentiempodedesarrollounavisiónexactadelaspectoque tendrá la interfaz en tiempode ejecución, lo que lo convierte enunapotenteyconvenienteherramientadurantenuestrodesarrollo.

2.3.3.Instruments

ElentornodeInstrumentspermiteanalizarelcomportamientodenuestrasaplicacionesiPhonemientrascorrenenelsimuladoroenundispositivo. Instruments recoge información de la aplicación en

16

ejecuciónylapresentagráficamenteenuntimeline.Sepuedeobtenerinformaciónsobreelusodememoria,actividaddedisco,actividadderedocomportamientográfico.Eltimelinepuedemostrartodotipodeinformaciónsimultáneamente,pararelacionarlosdatosobtenidos.

Además de esta vista del timeline, Instruments proporcionaherramientas para analizar el comportamiento de nuestra aplicacióneneltiempo.Porejemplo,podemossalvarlainformacióndemúltiplesejecucionesparavereldesarrollodel comportamiento, compararlooayudarnosaevaluarlanecesidadderevisaralgunodeestosaspectos.

17

3.Casodeestudio:Análisis.

Comoyahemosmencionado,lafinalidaddelarealizacióndeesteproyecto no es el desarrollo de una aplicación concreta, sino elaprendizajedeldesarrollodeaplicacionesparadispositivosmóviles,yla exploración de la tecnología iPhone y iPhone OS. Así pues, elcontenido exacto se fue definiendo mientras se avanzaba en elaprendizajeyenlasprimerasversionesdelprototipo.

Sisetrazaronunaslíneasmaestrasparaelprototipoadesarrollar,asícomounaseriedefuncionalidadesorequisitosquepodíanllegaraimplementarse.Acontinuaciónsepresentaelanálisiscorrespondientealprototipoquefinalmentesehadesarrollado.

3.1.Objetivosyrequisitosdelaaplicación.

3.1.1.Objetivobásicodelaaplicación.

SepretendeeldesarrollodeunaaplicaciónparaelterminalmóviliPhone de Apple que permita la navegación entre los dispositivos oelementosdeunaviviendadomóticapreviamentedefinidaymodelada,asícomolautilizaciónoactivacióndedichosrecursosatravésdeunaconexiónvíaInternetconunservidor.

3.1.2.Especificaciones,requisitosyfuncionalidades.

Laaplicacióndeberápermitirunanavegaciónsencilla,cómodaeintuitiva entre los diferentes elementos domóticos incluidos enlas viviendas que hayan sido previamente modeladas yconfiguradas. Se decide utilizar listados jerarquizados parapresentarlainformación.

Laaplicacióndeberápermitirlacargaodefinicióndediferentesmodelosdeviviendasoentornosdomóticos.Endichadefinición,se deberán poder especificar indefinidos niveles de agrupación(deahoraenadelantellamadossectores),quepodráncontenera

18

su vez indefinidos elementos domóticos de cualquier tipo, asícomootrossectores.

Sedefinirándostiposdeelementosdomóticos:losdispositivosylosservicios.Undispositivocorresponderáaunelementofísicoutilizable, mientras que un servicio corresponderá a cualquierfuncióndomóticaquenocorresponda físicamenteconunúnicoelemento.

Losdispositivosyserviciospodránserdeunúnicoovariostiposdiferentes previamente definidos. En cualquier caso se deberápoder acceder al uso de cualquiera de las funcionalidadesdefinidasparadichostipos.

La aplicación debe de poder comunicarse a través de Internetconunservidorquegestionelaactivaciónousodelosdiferentesdispositivos definidos, de manera que la activación en laaplicaciónsupongauncambiorealenlaviviendamodelada.

3.2.Casosdeuso

LoscasosdeusosonunmodeloenmarcadoenellenguajegráficoUML (Lenguaje Unificado de Modelado) que nos permite, una vezcapturados los requisitos, representar gráficamente cómo deberíainteractuarlaaplicaciónconlosusuarios.

Por lo tanto, los casos de uso están formados por actores(usuarios), por los propios casos de uso (funcionalidades) y por undiagramadecasodeuso(relacionesentrelosusuariosylaaplicación).

Entre los diferentes elementos de un diagrama de casos de usopueden presentarse diferentes tipos de relación, de los que hemosutilizado:

<<comunicate>>defineunarelaciónentreunactoryuncasodeuso.Generalmentelarelaciónúnicamenteseindicaconunalíneacontinua.

<<include>>defineunarelacióndedependenciaentredoscasosde uso en el que un caso de usoA incluye a un caso de usoB,realizandouna instanciadeAtodosloseventosdescritosenB.

19

<<extend>>defineunarelacióndedependenciaentredoscasosdeusoenelqueuncasodeusoBesunaespecializacióndeuncasodeusoA,esdecir,unarelaciónequivalenteaunainclusiónmásunacondición.

En nuestro proyecto, presentamos un diagrama de casos de usosencillo, en el que se observan las principales interacciones que elusuariovaarealizarconlaaplicación.

Cabe destacar de nuevo que en las aplicaciones orientadas adispositivosmóvilessebuscalasencillez,lacomodidadylarapidezdeinteracciónentreelusuarioylafuncionalidad.Esporesoqueloscasosde uso son tan sencillos como se pueda imaginar, para facilitar lapolítica “on‐the‐go” de este tipo de aplicaciones, que busca que elusuariononecesitecentrarsuatencióneneldispositivomásqueunossegundosparaobtenerlafuncionalidaddeseada.

Vamosa ver a continuaciónunadescripciónde los casosdeusopresentadoseneldiagrama:

Explorarvivienda(s)domótica(s)

Cualquier usuario que lance la aplicación estarácomenzandoaexplorar lasviviendasdomóticasquehayansidocargadas (ver caso de uso correspondiente). A través de unsistema de navegación entre tablas jerarquizadas, el usuariopodrá explorar el contenido de las viviendas e ir viendo elcontenidodecadasectordemaneraordenadayclasificada.

Cargarvivienda(s)domótica(s)

20

Al lanzarse la aplicación, como hemos dicho, el usuariocomienza a explorar las viviendas domóticas que la aplicaciónhayacargado(verapartadodecargadeinformacióndentrodelafase de diseño). Esta carga se produce de manera automáticacadavezquesecomienzaaexplorarlasviviendas.Secargatodala información amemoria y la aplicación trabaja con ella hastaque se cierra. Es por esto que la carga de la información serealizacuandosecomienzaaexplorar,perounaúnicavez.

Verdetalledispositivooservicio

Durante la navegación el usuario puede seleccionar undispositivo o servicio (y en el futuro cualquier elementodomótico que se implementara) para observar su detalle (atravésdelacargadesuinterfazqueveremosenelapartadodediseño). Esto mostrará toda la información relevante yproporcionarálaposibilidaddehacerusodesusfuncionalidadesasociadas.Encasodeelementosdevariostipos(porejemplounabombilla que se pueda apagar/encender o regular), sepresentará la posibilidad de acceder a tantas vistas de controlcomoseanecesariounavezsehayaseleccionadoelelemento.

Utilizardispositivooservicio

Unavezelusuarioseencuentreenlapantalladedetalledeunelementodomótico,éstamostrará loscontrolesasociadosaltipo correspondiente del elemento, permitiendo al usuarioaccionar o hacer uso de las funcionalidades asociadas ha dichoelemento según el tipo que corresponda (ver apartado dediseño).

Comunicarconservidorvivienda

Cada vez que el usuario proceda a utilizar un elementodomótico,estaacciónresultaráenunacomunicacióndirectaconel servidor de la vivienda definido, a través de una señal víaInternetqueprocedaarealizarlafuncióndeseadaenlavivienda.

3.3.Diagramadeclases

Haremos uso de los diagramas de clases, un tipo de diagramaestáticodeUMLquenospermitirádescribiryvisualizarlasclasesquecomponenelsistemaylasrelacionesqueexistenentreellas.

21

Se define una clase como una unidad básica que encapsula lainformación de un objeto, y semuestran atributos ymétodos de lasmismas.

Así pues, ydesdeunpuntodevistadel análisisde la aplicación,

sólo hemos incluido las clases que almacenan información sobreobjetos,ynoaquellasclasesquehansidonecesariasparalagestióndelainformación(controladoresdevistas,delegadodelaaplicación,XMLParser…). Obtendremos más información sobre estas clases y lasfunciones que proporcionan a la aplicación en apartados posterioresde la presente memoria, limitándonos en este diagrama a las clasescontempladas en la fase de análisis, sin además especificar laspropiedadesdelasmismas.

22

4.Diseño

Vamos a ver a continuación las características del diseño de laaplicación. Para ello, presentaremos un diagrama de clases de laaplicación desarrollada en detalle, con todos las clases y relacionesdefinidasenesteproyecto, comorefinacióndelpresentadoen la fasede análisis. Realizaremos una descripción de las funcionalidades decada clase, así como de sus propiedades. Veremos también ladefinicióndelesquemaXMLutilizadoparalacargadeinformaciónenla aplicación, y porúltimodetalles de la interfaz gráficadesarrolladaparacumplirconlasespecificacionespropuestasenlafasedeanálisis.

4.1.Diagramadeclasesampliado.

Acontinuaciónvamosaverunaampliacióndeldiagramadeclasespresentadoenelapartadodeanálisis.

En el diagrama de clases de la fase de análisis presentamosúnicamente las clases necesarias para modelizar la informaciónmanejadaenlaaplicación,sinentrarendetalleensufuncionamientoofinalidady limitándonosaesteconcepto.Ademásdeéstas,existenenelproyectomuchasotrasclasesutilizadasparaotrosmenesteres,talescomo los controladores de vistas, la clase de recorrido del XML o eldelegadodelaaplicación.

Enlasclasespresentadasnosehanimplementadoningúnmétododeltipo“set”o“get”,quenospermitendarvaloralosatributosdeunainstanciadeunaclaseorecuperarlo,yaqueéstossonimplementadosdemaneraautomáticaaldefinirlosatributoscomopropiedades.Estosmétodos,pese anohaber sidonecesario implementarlos, sí han sidoutilizados y cabe destacar que por defecto se han definido todos losatributosdelasdiferentesclasescomopropiedadesconlafinalidaddepoderutilizarlosgettersysettersencualquiermomento.

@property(nonatomic, retain) NSString *nombre;

@synthesize nombre;

23

Además, en el diagrama de clases presentado, por motivos deespacio, no se han incluido las relaciones entre la clase“iDomoControllerAppDelegate” y el resto, ya que queda relacionadocon todasellas,asícomoalgunasotrasrelaciones,que iremosviendoendetalleacontinuación.Veamoseldiagrama.

4.1.1.Clasesdemodelizacióndeinformación.

Las clases “Sector”, “Elemento domótico”, “Dispositivo” y“Servicio”, todas heredadas de la clase interna de Foundation“NSObject”, son las diseñadas con la finalidad de modelizar lainformación en nuestro proyecto. Con ellas podemos almacenar ytrabajarconnuestrosentornosdomóticos.Veamosendetallecadaunadeellas.

24

Sector

La clase Sector representa toda unidad de agrupación deelementos domóticos. Así pues, un sector podría ser unahabitación, una planta o incluso una vivienda. Un sector puedecontenerotrossectoresy/oelementosdomóticostalescomolosdispositivoso losservicios.Estasrelacionesdeasociaciónde laclase Sector consigo misma y con los diferentes elementosdomóticossepuedeapreciareneldiagrama.

Un sector poseerá como atributos unnombre, una lista delos sectores que están contenidos en esta agrupación, una listadelosdispositivosquecontieneyotralistaconlosserviciosqueagrupa.

Sehadefinidounmétodode inicializaciónpara losobjetosde laclaseSectorque,recibiendotodala informaciónsobresusatributos,creeyinicialicelainstancia.

ElementoDomótico

La clase Elemento Domótico es una superclase de la queheredan las clases servicio y dispositivo. Pese a quehabitualmentenoseinstanciaránobjetosdeestaclase,nossirvepara agrupar todos los elementos domóticos que podamosutilizarenunfuturo,yparaestructurarelcódigodemaneraqueno sea necesario repetir definiciones de atributos y métodoscomunesaestasotrasclases.

UnElementoDomótico(yportantocualquieradesusclaseshijos)poseerácomoatributosunnombreyunalistaconlostiposdedichoelemento.

Se ha definido también un método de inicialización paraesta clase, que dado un nombre y una lista de tipos, cree yinicialiceelobjeto.

Servicio

Un servicio es una subclase de un Elemento Domótico. Seentiende por servicio cualquier función domótica que puedeestar presente en una vivienda y no corresponda directamenteconlaactivacióndeunúnicoelementofísico.

25

Tal y como finalmente se ha decidido el funcionamiento yfuncionalidades de la aplicación, no posee ningún atributo nimétodo propio, pero el hecho de existir una clase para estosobjetos nos permite concretar de manera aislada sucomportamiento y facilita desarrollos futuros sobre la base deestaaplicación.

Dispositivo

UndispositivoesunasubclasedeunElementoDomótico.Seentiendepordispositivocualquierelementofísicoquetengaunafuncionalidad controlable asociada, como por ejemplo unabombillaqueseenciendeyseapaga.

Al igualque losservicios,sehacreadounaclaseespecíficapara su tratamiento que por el momento no tiene atributos ométodospropios.

4.1.2.Clasescontroladoresdevistas

En nuestro proyecto se han definido 6 clases que actúan comocontroladores de vistas. Estas clases son las que nos permitengestionarlasdiferentesinterfacesgráficasdefinidas,tantoelcontenidoque semuestra, como la capa de negocio con la que la interfaz debecomunicar al usuario. Diferenciamos entre dos subtipos. Primero lasclases heredadas de la clase interna del UIKit “UIViewController”,dondeenmarcamoslascuatroclasesdefinidascomocontroladoresdelascuatro interfacesdedispositivos.Segundo lasclasesheredadasdelaclaseinternadelUIKit“UITableViewController”,dondeenmarcamoslas dos clases definidas como controladores de la interfaz denavegación.Veamoslosdetallesdecadacontrolador.

RootViewController

Clasecreadacomocontroladordelainterfazdenavegaciónparalagestióndelavistaprincipal,enlaqueserepresentenlasviviendas cargadas en nuestra aplicación. Como atributo seestablecelarelaciónconlaclaseSectoresViewControllerycomométodosencontramosrefinamientosde losmétodospropiosdesu clase padre, propios de la gestión de una interfaz de tiponavegación. Entre ellos encontramos métodos como los quedefinenloquesucedecuandoterminadecargarselainterfaz,el

26

númerode filasde cada secciónde la tabla, el contenidode lasceldasoloquesucedecuandoelusuarioseleccionaunadeellas.

SectoresViewController

Esta clase esmuy similar a la anterior, ya que también seutilizacomocontroladordelainterfazdenavegación.Estaclase,en concreto, gestionará la navegación a nivel de sectores,mientrasquelaanteriorsereservabaparaelniveldeviviendas.Seestableceestadiferenciaparapoderdiferenciarentreambosypermitirunamayorflexibilidadencomportamientoyaparienciadelaaplicaciónparaestosdosniveles.

Estaclaseserelacionadirectamentecontodaslasclasesdemodelización de la información presentadas, así como con loscuatrocontroladoresdevistasdeinterfaz,relaciónquenoseharepresentado por claridad en el diseño. Los métodosimplementados son aproximadamente los mismos que en laanteriorclase,peroconcomportamientosdiferentes.

Dispositivo_BinarioViewController

Clase controlador de vista que hereda de la clase internaUIViewController. Utilizada para controlar la interfaz deelementos domóticos de tipo binario y gestionar la interaccióndeéstaconlacapadenegocio.

Los atributos definidos corresponden mayormente a loselementosgráficosdelainterfaz,parapermitir lagestióndesdela clase de los mismos. Entre los métodos encontramos elmétodo de inicialización y el que gestiona la activación delswitchdelainterfazparaconstruirlaseñalamandaralservidor.

Dispositivo_RegulableViewController

Clase controlador de vista que hereda de la clase internaUIViewController. Utilizada para controlar la interfaz deelementosdomóticosdetiporegulableygestionarlainteraccióndeéstaconlacapadenegocio.

Los atributos definidos corresponden mayormente a loselementosgráficosdelainterfaz,parapermitir lagestióndesdelaclasedelosmismos.Vemosentrelosmétodoselquegestionalasaccionesatomarcuandosemodificael“slider”delainterfaz,asícomoelqueseencargadeconstruirlaseñaldeenvíocuandosepulsaelbotóncorrespondiente.

27

Dispositivo_BidireccionalViewController

Clase controlador de vista que hereda de la clase internaUIViewController. Utilizada para controlar la interfaz deelementos domóticos de tipo bidireccional y gestionar lainteraccióndeéstaconlacapadenegocio.

Los atributos definidos corresponden mayormente a loselementosgráficosdelainterfaz,parapermitir lagestióndesdelaclasedelosmismos.Sedefinenmétodosparatomaraccionesparacadaunode losposiblesbotonespulsados,gestionando laseñal a enviar al servidor según se seleccione una de lasdireccionesolaparadadelelemento.

Dispositivo_UmbralViewController

Clase controlador de vista que hereda de la clase internaUIViewController. Utilizada para controlar la interfaz deelementos domóticos de tipo umbral o de valor y gestionar lainteraccióndeéstaconlacapadenegocio.

Los atributos definidos corresponden mayormente a loselementosgráficosdelainterfaz,parapermitir lagestióndesdela clase de los mismos. Como método principal destacar lagestión del valor introducido para enviar al servidor la señalcorrespondiente.

4.1.3.ClasederecorridodelXML

LaclaseXMLParseres laclasedefinidaparael recorridoycargade la información almacenada en el fichero XML de carga (verapartadosalrespecto).Estaclaseseinstanciadesdeeldelegadodelaaplicaciónallanzarelprograma,yseencargaderecorrerelficheroeircreando las estructuras necesarias (clases de modelización deinformación) para almacenar la información que después pueda serpresentadaytratada.

Hereda de la clase interna NSObject y los atributos y métodosdefinidos en ella son los necesarios para cumplir con la finalidadexpuesta.

28

4.1.4.Clasedelegadodelaaplicación

Estaclase,queheredatambiéndelaclaseinternaNSObject,eslaclase principal de la aplicación. iDomoControllerAppDelegate actúacomo delegado de la aplicación en su ejecución, lo que significa quegestionadesdequese lanzahastaquesecierrael flujodelprograma.Sepodríacompararconlatradicionalclasemain,quesibienexisteenesteproyecto,únicamentedapasoaldelegado,queesquienrealmentegestionalaejecución.

Estaclase,peseaquenoseha representadoeneldiagramaporclaridad, tiene relaciones con casi todas las clases diseñadas. Desdemultitud de ellas se crean instancias del delegado para ejecutar losmétodosenéldefinidos,yeselmismodelegadoelquecrealainstanciadel XMLParser que permite la carga de la información. Además,también centraliza la formación y envío de señales al servidor quepermiten que la aplicación interactúe con los entornos domóticosfísicos.

4.2.Cargadedatos:EsquemaXML

Anteelproblemadeelalmacenamientoycargadeinformaciónenlaaplicaciónsebarajarondiferentesposibilidades.

La primera consistía en cargar la información relativa a lasviviendas a partir de un fichero que previamente debe haber sidoalmacenadoenel terminal.Fuetambiénlaprimeraenserdesechada,pues almacenar un fichero en el terminal físico supone un gasto deespacioinnecesario,Además,obviamentehabríaquegenerarprimeroelarchivoycargarloenlaterminal,loquepuedeserunimpedimentoalahoradecargarnuevasviviendasomodificarlasexistentes.

La segunda opción barajada fue crear una base de datos, queiPhoneOSsoportaatravésdeSQLLite.Tambiénfuedesechada,puestoque si bien es una manera ordenada de almacenar y cargar lainformación, seguimos teniendo el problema de cómo un usuariopodríadefinirunanuevacargadedatos.

Estas dos primeras opciones podrían haber sido válidas si sehubieradesarrolladolaaplicacióndemodoqueelusuariodefinierasuvivienda a través de la interfaz de la propia aplicación. No obstante,

29

estonoerapartede la finalidaddelproyecto, ademásdeque sibienpodría ser una buena manera de hacer cambios sobre viviendas yacreadas, definir una nueva vivienda al completo podría serinterminable,ycomoyahemosmencionadoenotrospuntos,sebuscalasencillezyrapidezdeinteracciónentreelusuarioylaaplicación.

Asípues,llegamosalatercerayúltimaopción,quefuefinalmenteimplementada:LacargadedatosatravésdeunficheroXML.

Esta opciónno tiene inconveniente alguno. Para hacer usode laaplicación debemos tener conexión vía Internet con el servidor denuestra vivienda domótica, con lo que podemos utilizar éste mismopara almacenar el ficheroXML con los datos de la vivienda a cargar.Estonos eximede almacenarninguna información en el terminal, yaque ésta se encuentra en la red y se carga cada vez que se lanza laaplicación, con lo que se puede modificar fácilmente el XML parareflejar por ejemplo un nuevo dispositivo, o para definir nuevossectoresoviviendas.

Elmododefuncionamientoeselsiguiente:SeimplementaunXMLParser, es decir, una clase que gestiona cómo se recorrerá el ficheroXMLacargar.Sedefineunarutadondeestáalmacenadoelfichero(quepuedeser,porejemplo,larutadelservidorconelquesecomunicalaaplicación para interactuar con la vivienda), y en la carga de laaplicación se le solicita al XML Parser que lo cargue y lo recorra, demodoqueseanlosmétodosdefinidosenlapropiaclaselosquerecojantodoloqueelParserleaalrecorrerelfichero.

Así pues, se diseña una estructura para el fichero XML que sedesee utilizar como fuente de datos para la aplicación. Vamos acontinuaciónadefinirloselementosdelaestructura:

Elementosdomóticos

Dispositivos o servicios. Se definen con la etiqueta<Dispositivo> o <Servicio> respectivamente. En su interior, sedebeindicarelnombre,indicadoconlaetiqueta<Nombre>,y1omástiposdeelementosdomóticos,consucesivasaparicionesdela etiqueta <Tipo> y el código numérico asociado al tipo ennuestraaplicación.

<Dispositivo>

<Nombre>DispositivoA</Nombre>

30

<Tipo>3</Tipo>

<Tipo>2</Tipo>

<Tipo>1</Tipo>

</Dispositivo>

SectoroVivienda

Se definen con la etiqueta <Sector> o <Vivienda>respectivamente. Si biendiferenciamos entre ambos conceptos,cabe recordar que una vivienda no es más que un sector deprimer nivel, que almacena el resto de sectores y que tambiénpuede contener elementos domóticos. Así pues, dentro de un<Sector> o <Vivienda> debemos definir primeramente su<Nombre>,yacontinuación,siprocede,podemosdefinirtantoselementos <Servicio>, <Dispositivo> y <Sector> comocorresponda. Es importante respetar este orden, para que elParsersepadistinguiraquésectorperteneceloselementosqueestamosindicandoentodomomento.

<Sector>

<Nombre>Sector3</Nombre>

<Dispositivo>

..

</Dispositivo>

<Servicio>

..

</Servicio>

<Sector>

<Nombre>Sector3.1</Nombre>

<Dispositivo>

..

</Dispositivo>

</Sector>

31

</Sector>

Viviendas

Essimplementeel tagque identificaelprincipiode la listade viviendas. En su interior podemos encontrar diferentesviviendasdefinidas,yaque laaplicaciónpermite la cargadeunnúmeroindefinidodeelementos<Vivienda>.

<Viviendas>

<Vivienda>

<Nombre>Vivienda1</Nombre>

..

</Vivienda>

<Vivienda>

<Nombre>Vivienda2</Nombre>

..

</Vivienda>

</Viviendas>

4.3.Interacciónconlasviviendasfísicas.

Esta aplicación está pensada como una interfaz móvil deinteracciónentreelusuarioquedeseacontrolarsuviviendaoentornodomóticodesdecualquierlugaryelservidordedichaviviendaqueeselquegestionalaefectuaciónfísicadeesasmodificaciones.

Asípues, la aplicación sedeberá comunicar conel servidorparaque sea éste el que ejecute las acciones. En nuestro caso, y tal comoveremos en el apartado de descripción del prototipo implementado,noscomunicaremosconunservidorsituadoenelDSICquecontrolalamaqueta de una vivienda domótica. Cabe destacar en esta fase dediseño que la comunicación se realizará a través de órdenes httpgraciasalserviciopostimplementadoenelmismo.

32

Lainteracciónconlaviviendafísicarequierelaformacióndeunaseñal, que en este caso se trata de la creación de una cadena urlconcretasegúndispositivoyacción,yelenvíodedichaurlalservidoratravésdeunposthttp.

Las señales a enviar en esteproyecto tenían comocaracterísticaquesediferenciabansegúntipodeelementodomótico,yincluíanenlarutaelnombredelelemento,asícomounacodificacióndelaacciónarealizar.Poresto,losmétodosdeformaciónyenvíodeestasseñalessehanimplementadoaniveldedelegadodeaplicación,mientrasqueencadacontroladordevistasdecadatipodeelemento,esdondesecrealainstanciadeldelegado,sellamaalmétododeconstruccióndeseñalyaldeenvío, segúncorrespondacon laacciónrealizadaporelusuarioenlainterfaz(yportanto,capturadaporestecontrolador).

Eneldelegadodelaaplicaciónesdondesedefinenlosmétodosdeconstruccióndeseñales(unoporcadatipodeelementodomótico,yaque como hemos dicho las señales se forman de manera diferente),teniendoencuentacomoparámetrosnombreyacciónarealizarparala señal a construir. También es aquí donde encontramos elmétodoquegestionaelenvíodelaseñalalservidor.Estemétodorecibecomoparámetro la cadena de conexión que previamente ha sido formadacon la casuística indicada, la convierte en un objeto del tipo NSURL,creaunaseñaldeposthttpyutilizandolaconectividadquegestionaelpropio iPhone OS, fuerza el envío de la señal. Este post http serágestionado por el servidor, que efectuará las acciones asociadas almismo, ejecutando físicamente lo que el usuario ha solicitado en eldispositivo.

4.4.Interfazgráfica

Hayquetenerencuentaquealfinal,eslainterfazgráficaloqueelusuario ve de la aplicación. Dada la importancia de la claridad,simplicidad y sencillez de uso en la aplicaciones móviles, esprecisamenteenestafasedeldiseñodondehayquetenerloencuenta.Asípues,sedefineunaúnicainterfaz(ydecimosinterfazpuestoqueelconcepto vista es diferente en iPhone Os, donde una interfaz puedetenerdiferentesvistas)paralanavegaciónporlasviviendascargadas.Sedefinetambiénunainterfazporcadatipodeelementodomótico,ennuestro caso4 interfaces que corresponden a los tiposde elementosdefinidos(verprototipo).

33

5.Prototipoyimplementación

Vamosacentrarnosenesteapartadoenelprototipodeaplicaciónpara terminal iPhone que se ha desarrollado como parte de esteproyecto.Vamosavercómosehanllevadoacaboaspectosdeldiseñodeaplicaciónycómoenconcretoseefectúantodaslasaccionesquesehandefinidoenanterioresapartados.

5.1.Elprototipo:Unaviviendaeficiente.

En el laboratorio del DSIC dirigido por el director de esteproyecto, Joan Fons i Cors, han construido una maqueta querepresenta una vivienda eficiente y un servidor que gestiona lainteracciónconlamismaatravésdecomunicacionespostporhttp.Esprecisamenteesteentornoelquesehautilizadoenesteproyectoparaeldesarrollodeunprototipoconlosrequisitosyeldiseñodetalladosenlapresentememoria.

34

5.1.1.Tiposdeelementosdomóticos.

Se definen cuatro tipos de elementos domóticos (ya seandispositivos o servicios) en nuestra vivienda eficiente, quepresentamosacontinuación(verapartadodeinterfacesdeusuario):

Binario

Los elementos de tipo binario son los más sencillos quevamos a encontrar. Tienen dos estados (on/off,encendido/apagado,activado/desactivado…)ydeahíelnombredelosmismos.Porejemplounabombilla.

Regulable

Sonelementos regulablesaquellosqueson susceptiblesdeser controlados de manera regulada para cualquiera de susaspectos. Por ejemplo, consideramos regulable una bombillacuya intensidad se puede controlar representando la mismacomounporcentaje.

Bidireccional

Son elementos que tienen dos posibles interaccionesopuestas (y opcionalmente un tercer estado de reposo). Porejemplounacortinaquepuedasubirseybajarse,oundepósitoquesepuedallenarovaciar.

Devalor

Cualquierelementoconelquesepuedainteractuarconunvalor,enunconceptomásamplioqueloselementosregulables,ynonecesariamenteconvaloresdeporcentajeonuméricos.Seríaun ejemplo un climatizador que aceptara como input latemperaturaaconseguir.

5.1.2.Elementosdomóticosydistribución.

Acontinuaciónvamosaprofundizarencómoesnuestraviviendaeficiente. Se trata, como ya hemos introducido, de unamaqueta querepresenta una vivienda con una serie de elementos domóticosdiseñados con la eficiencia energética y la comodidad que ofrece ladomóticacomopremisas.

35

Vamosarevisartodosloselementosdomóticosdelosqueconstanuestraviviendaeficiente,asícomosudistribuciónenlamisma.

Nombre TipoElemento

Sector Descripción

FloodingSecurity

Serviciobinario

Vivienda Serviciodedicadoalcontroldeinundaciones.

WaterSupply

Serviciobinario

Vivienda Servicioquecontrolalaprovisióndeagua

corriente.HomeSecurity

Serviciobinario

Vivienda Activacióndeelementostalescomoverjas,detectores,alarmas..

HomeMessaging

Serviciodevalor

Vivienda Usoscomodisplaysdemensajes.

Buzzer Dispositivobinario

Vivienda Alarmaozumbador.

GeneralLight

Dispositivobinario

Vivienda Luzgeneraldelavivienda.

VisualNotification

Dispositivobinario

Vivienda Dispositivodenotificación.

ClimatedRoom

Serviciobinario

Dormitorio Climatizacióndeldormitorio.Controla

temperatura.RoomLighting

Dispositivobinario

Dormitorio Iluminacióndeldormitorio.

AirConditioned

Dispositivobinario

Dormitorio Controlaelaparatodeaireacondicionado.

KitchenLightByPresence

Serviciobinario

Cocina Encendidoautomáticodeiluminaciónencocina.

LightByLight

Intensity

Serviciobinario

Cocina Iluminaciónsegúniluminaciónnatural.

KitchenLighting

Dispositivobinario

Cocina Iluminaciónmanualdecocina.

Louver Dispositivobidireccional

Salón Persianadelsalón.

GradualLighting

Dispositivobinarioyregulable

Salón Luzregulabledelsalón.

36

5.2.Interfacesdeusuario

A continuación vamos a describir lasinterfaces de usuario diseñadas yimplementadas con el Interface Builder paranuestro prototipo, que son la interfaz denavegación y las cuatro interfacescorrespondientes a los cuatro tipos deelementosdomóticos.

Navegación

El diseño de la interfaz de navegación lo proporciona elpropioInterfaceBuilderalutilizarunatablapararepresentarlosdatos. Como parte de una Navigation Based Application(aplicación basada en navegación) se añade una barra denavegación(NavigationBar)enlapartesuperior,cuyocontenidoes configurable. Se puede observar que se ha configurado eltítulo de la misma, así como la aparición de un botón pararegresaralaanteriorpantalladelanavegación.

37

Estainterfazpermitepuesnavegarportodosloselementosdomóticos y sectores de nuestra vivienda, de manera rápida eintuitiva. Además, al mostrar el contenido de un sector, sediferenciaentreotrossectores,dispositivosyservicios,paraunamayorclaridad.

Elementobinario

El diseño de la interfaz para elementos domóticos de tipobinario (recordemos que eran aquellos con dos estados),presenta un botón deslizante que permite al usuario con unsencillo gesto cambiar el estado del elemento. Esta interaccióndel usuario provoca el envío de la señal correspondiente alservidor para que se produzca le cambio. Dicha señal, y demaneraprovisional,semuestraenelinferiordelainterfaz.

38

Elementoregulable

El diseño de la interfaz para elementos domóticos de tiporegulable presenta un elemento gráfico muy característico, el“slider” (barra de deslizamiento), que nos permite mostrar unelementoconelqueelusuariopuedeinteractuarparaindicarunvalordentrodeunrango.Seañadetambiénunbotónparaenviarlaseñalconelvalorseleccionadocuandoestélisto.

Nóteseenlaparteinferiordelaimagenqueésteesunodeloscasosenlosqueunelementodomóticoesdemásdeuntipodiferente. Por eso aparece en la interfaz una barra con tantasdivisiones como de diferentes tipos sea el elemento,seleccionables para cargar la interfaz correspondiente a dichotipoyasípermitircualquierinteracciónposibleconelelemento.

39

Elementobidireccional

El diseño de la interfaz para elementos bidireccionalescuentacontresbotones.Dosbotonescorresponderíanalasdosdirecciones o estados contrapuestos que caracterizan este tipodeelementos,mientrasqueel tercerbotónserviríaparaentrarenuntercerestado,dereposo,siexistieralaposibilidad.

En nuestro prototipo el reposo de este tipo de elementosdomóticos estaba programado en el servidor con untemporizador tras activar una de las dos direcciones, noexistiendolaposibilidaddemandarunaseñaldeparada,conlocuallafuncionalidaddelbotóndeparadanoseimplementó.Noobstante,pensandoenlaflexibilidaddelproyectodesarrolladoyen posibles ampliaciones o reutilizaciones, se diseñó el botónparapoderimplementarsufuncionalidadsicorresponde.

40

Elementodevalor

Eldiseñodelainterfazparaelementosdevalorconstacomoel resto de las interfaces de una etiqueta con el nombre delelemento domótico que estamos manipulando. Así mismo,contiene una entrada de texto, que permite que el usuariointroduzca cualquier valor deseado a través del teclado queIPhone OS despliega automáticamente cuando el usuario pulsadentro del cuadro de texto. Por último, y pese a que se podríaimplementar el envío de la señal a través de la teclacorrespondientedeltecladodesplegado,heoptadoporañadirelmismo botón que en las otras interfaces por coherencia, quecomoenlosotroscasos,envíaelvalorestablecido(enestecasounacadena)alservidor.

5.3.Cargadelprototipo.DefiniciónenXML

Comoyase introdujoenelapartadodediseño, lacargadedatosen la aplicación se realiza mediante la lectura de un fichero XML

41

alojadoenlared.DefinimostambiénlaestructuraquedebíacumplirelXMLparaserleídoporlaaplicación.VamosaveracontinuaciónenelcasoconcretodenuestraviviendaeficientecómohasidodefinidoeseXML.

<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>

42

<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 interpretación de este XML es gestionado por laclaseXMLParser,queyahemosintroducidoyqueveremoscondetalleenelsiguientepunto.

5.4.Descripcióndelaimplementación

Vamosaver,deunamanerageneral,comosehaestructuradolaimplementacióndelproyecto.Apartede las interfacesdiseñadasconel Interface Builder, se han programado una serie de clases que nos

43

sirven tanto para modelar la información que maneja la aplicacióncomo para controlar el contenido visible por el usuario en dichasinterfaces.Sehanprogramadolassiguientesclases:

Clasesdeobjetosmodelados

Las clases “Sector”, “Dispositivo” y “Servicio” son las tresclasesimplementadasparaalmacenarygestionarlainformaciónde los diferentes elementos que componen las viviendas ennuestraaplicación.Cadaelementodomóticoosectordenuestrasviviendasesunainstanciadeunadeestasclases.

Enlafasedediseñovimoslosatributosymétodosdefinidosenestasclases,quepermitenlaestructuracióndelainformaciónatratarenlaaplicación.

Como ejemplos de la implementación podemos ver porejemploelficherodecabeceradelaclase“Sector”.Observamosladefinicióndeatributosydemétodos.Tratándosedeunsector,definimos su nombre y referencias a dispositivos, servicios yotrossectorescontenidos.Encuantoalosmétodos,únicamentesedefinelainicializacióndelsector.

#import <Foundation/Foundation.h> @interface Sector : NSObject { NSString *nombre; NSMutableArray *dispositivos; NSMutableArray *sectores; NSMutableArray *servicios; } @property(nonatomic, retain) NSString *nombre; @property(nonatomic, retain) NSMutableArray *dispositivos; @property(nonatomic, retain) NSMutableArray *sectores; @property(nonatomic, retain) NSMutableArray *servicios; -(id)initWithName:(NSString *)n dispositivos:(NSMutableArray *)disp sectores:(NSMutableArray *)sect servicios:(NSMutableArray *)serv; @end

Acontinuación,comoejemplodeimplementacióndeunodelosmétodos, la implementacióndelmétodode inicializacióndeun servicio, donde vemos que se inicializan los atributos delmismo.

44

#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 ViewController”, así como las clases “Dispositivo Binario ViewController”,“DispositivoRegulableViewController”,“DispositivoBidireccional View Controller” y ”Dispositivo Umbral ViewController” han sido programadas como controladores de las 5interfaces que se han definido. Estas clases nos permiteninteractuarcondichas interfaces,yportanto,conelusuario.Segestionaenellaselcontenidoeinformaciónqueapareceencadamomentoen lapantalladeldispositivo, así como loquesucedecuandoelusuariointeractúaconéldecualquiermodo.

Vemos a continuación la cabecera de la clase controladoradedispositivosbidireccionales.

#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;

45

@property (nonatomic, retain) IBOutlet UIButton *dir1; @property (nonatomic, retain) IBOutlet UIButton *dir2; @property (nonatomic, retain) IBOutlet UIButton *stop; @property (nonatomic, retain) IBOutlet UITextView *aux; @property (nonatomic, retain) Dispositivo *dispositivo_seleccionado; -(IBAction)seleccionado_dir1:(id)sender; -(IBAction)seleccionado_dir2:(id)sender; -(IBAction)seleccionado_stop:(id)sender; @end

En este fragmento de código vemos la declaración de laspropiedades de la clase. Recalcar que el tipo IBOutlet nospermitedefinirpropiedadesaniveldecodificaciónquedespuéspuedenser,atravésdelInterfaceBuilder,asociadasaobjetosenel diseño. De este modo, se puede codificar acciones ypropiedades de los objetos diseñados en el IB que soninstanciadosentiempodeejecución.

Enladeclaracióndelosmétodos, observamos tresmétodos que correspondena las tres posiblesinteracciones que puederealizar el usuario con unelemento de tipobidireccional. Nótesetambién que el prefijoIBAction establece elmétodo,deformaanálogaalo visto en las propiedades,comointerconectableconelInterface Builder. Así, seestablecen las relacionesentre la interacción delusuarioylasaccionesarealizarenelInterfaceBuilder,pudiendoimplementaraniveldecodificacióndichasacciones.

A continuación vemos la implementación de uno de estosmétodos, en concreto el quegestiona las accionesderivadasdeque el usuario seleccione el botón de una de las direccionessobreunelementobidireccional.

46

-(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]; }

Seobserva,comoyaseespecificóen la fasedediseño,queestos métodos incluidos en los controladores son los que, alrecibir el evento que realiza el usuario sobre el terminal,instancianaldelegadodelaaplicaciónyconstruyenlaseñalylaenvíanalservidor,produciendoelefectodeseadoenlaviviendafísica.

ClaseXMLParser

La clase “XMLParser” se encarga de gestionar el recorridodelficheroXML,asícomolainterpretaciónymapeadodelmismoenestructurasdefinidasennuestroproyecto(clases).

Ya sabemos que se lanza el parseado del fichero XMLsituado enuna rutadefinida, se varecorriendoycadaelementoqueseencuentra (etiqueta, valor, fin deetiqueta…) es interpretado. Seprogramanlasaccionesatomarencaso de encontrar cada uno deestos elementos de modo que unavez finalice la lectura del XMLobtengamosunaseriedeinstanciasde las clases que hemos definido,organizadas en vectores dereferencias que permiten“almacenar” la estructura denuestra vivienda o viviendas singastodeespacioendisco.

Losmétodos han sido implementados conmucho cuidadoparaque,cumpliendoconlaestructuradefinidaparalacargadeficherosXML,sepermitacualquiernúmerodeniveles(sectoresanidados), cualquier número de elementos domóticos y de

47

cualquiertipo.Veamosunejemplodelaimplementacióndeunodeestosmétodos.

- (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; } }

48

Delegadodelaaplicación.

Existeunaclaseprincipalen losproyectospara iPhoneOS,llamadaeneste caso “iDomoControllerAppDelegate”,queactúa,como su nombre indica, como delegado de la aplicación. Estaclaserecibeloseventosgeneralesdelaaplicacióncuandoestaseinicia. Así pues podemos encontrar métodos que responden aeventos tales como la finalización del lanzamiento de laaplicación, lo que nos permite manejar exactamente en todomomento el flujo de nuestra aplicación, y, entre otras cosas, loquedebesucederantesdequeelusuariovealaprimerainterfazcargada. Es precisamente aquí donde podemos programar elrecorridodelficheroxml.

Veamos algunos de los métodos implementados en estaclase,elmétododeconstruccióndeunaseñalparaunelementodetipobinario,yelmétodoencargadodeenviardichaseñal.

-(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 implementación lo especificadoen fase de diseño en cuanto a la construcción de la señal. Unaposibleseñalenviadaalservidorennuestroprototiposería:

http://cerebrito.dsic.upv.es/web/services/unsecureWebUI?operation=enable&PERVMLSERVICENAME=Buzzer

49

6.Problemasencontradosydesarrollosfuturos.

6.1.Dificultadessurgidas

Vamosaverahoraalgunosde lospuntosquemayordificultadoreflexióncrearondurantelarealizacióndeesteproyecto,yaseaporsudificultad, por los problemas creados o por lo comprometido de unadecisión.

6.1.1.Lacreaciónyalmacenamientodelainformación

Nuestraaplicacióntratadeproporcionarunaherramientaparaelusuario interesado en interactuar con su vivienda o elementosdomóticos.Estohacequeelhechodeconfigurar,definir,crearocargarla información sobre esa vivienda o elemento sea un punto crucial atenerencuenta.

Varias opciones fueron apareciendo sobre este tema. En unprincipio,conunamentalidadquetraselpasodeltiempoacabéviendocomototalmentedesenfocada,penséque locorrectoesque lapropiaaplicaciónpresentaraunaspantallasdeediciónparapoderircreando,editandoyborrandocadaunodeloselementosqueelusuariodeseara.Este concepto, tan instaurado en la costumbre de desarrollaraplicacionesdeescritorio,noteníacabidaen laprogramacióndeunaaplicacióncomoestaparaunterminalmóvil.Vuelvoadestacar,quelaclavedeunaaplicaciónparaundispositivomóvil,yenconcretoparaeliPhone, está en la sencillez y claridad de lamisma. Para empezar elhardware no está diseñado para trabajar con él durante un largoperiodo de tiempo,mirando una pantalla de apenas unas pulgadas ytratandodeescribirenunteclado“minúsculo”.Peromásalládeesto,loverdaderamenteimportanteesqueelusuarionodeseapasarhorasconfigurandoelaccesoaloqueverdaderamenteleinteresa,elcontroldesuvivienda.

Por otra parte, era un claro requisito fundamental poder definiraquellosusceptibledesercontroladopor laaplicación.Barajé la ideade almacenar en un fichero binario en el terminal el contenido de lavivienda, que previamente tendría que ser definido… ¡dentro de laaplicación! No tenía sentido. Estaba ante el mismo problema, o aún

50

peor, tendría que definir la vivienda dentro del código, con lo quecualquiercambiosupondríamodificarlapropiaaplicación.Inviable.

Fue entonces cuando opté por la decisión que se haimplementado, almacenar ese fichero en el exterior y leerlo desde laaplicación. Y qué mejor manera que utilizar el lenguaje XML yalmacenar el fichero en un servidor. Ya hemos visto como hemosdefinido laestructuraautilizaren ladefinicióndenuestraviviendaycómoselee,serecorreyseinterpretasucontenido.Unacargarápida,efectiva, sin necesidad de almacenar la información en el terminal,flexibleyescalable…problemaresuelto.

6.1.2.Elementosdevariostipos

En unmomento dado, los requisitos iniciales se ampliaron y secontempló la posibilidad de que un mismo elemento pudierapertenecer a más de un tipo. Esto tiene mucho sentido, ya que porejemplounabombillaregulable,puedesercontroladaconunafunciónde apagado y encendido (tipo binario) o puede ser controlada suintensidad progresivamente (tipo regulable). Como este, podríanpresentarsemuchosotroscasos.

A nivel de capa de negocio y de datos no supuso demasiadoproblema. Se adaptó el desarrolloparaque sepermitiera tanto en ladefinición XML, como en la definición de los elementos domóticos(clases)ysegestionaraadecuadamente.Elproblemallegóalahoraderepresentarlovisualmente,eneldiseñodelasinterfaces.

Laaplicaciónestábasadaenlanavegación,loquequieredecirqueexiste una pila de navegación, donde se pueden apilar o desapilarcontroladoresdevistas,quesonlasclasesquegestionancadaunadelas interfaces. Así, cuando se selecciona un elemento, se apila en la“navigation stack” el controlador correspondiente al tipo delmismo.Asímismo,cadainterfaz,quepuedetenernvistas,tieneunavistapordefecto, que se define en el Interface Builder. También se puedenapilarvistasdemodoquecuandouncontroladorestáelprimeroenlapiladenavegación,eslavistaqueestálaprimeraenlapiladevistaslaquesevisualiza.

La idea era crear un “tab bar”, que es un objeto de interfaz quemuestra una barra con diferentes pestañas y que nos permitiríaseleccionar,unavezcargadauna interfazdeunelemento,el restode

51

interfaces de dicho elemento correspondientes a sus tipos. Fue aquídondesurgieronlosproblemas.PrimeroqueAppledesaconsejaelusode este tipo de objetos dentro de aplicaciones de navegación, porproblemas en el manejo de las pilas. El segundo, es que al haberdefinido una interfaz por cada elemento, el objeto tab bar, que seincluyeeneldiseñodeunainterfazysegestionadesdeuncontrolador,nopodíaestarcargadoentodomomento,puestoqueparacambiardeun tipo a otro hacía falta apilar un nuevo controlador, y se pierde elcontrolsobreelanterior.Todoestelíohizocasiimposiblecumplirconeste requisito. Finalmente y de forma provisional, conseguíimplementar el tabbar comoalgo “pintado” encimade cada vista encadamomentoquesecargabalamisma,peroresultóserunamaneraengorrosísimademanejar,suciadeprogramarynoconseguíqueestadificultadfueratransparenteparaelusuarioyaquequedabanresiduosdeestelíodeinterfaces,vistas,controladoresypilasqueseproducía,peseaqueseconsiguióquefuncionara.

Esprobablequeelhechodehaberoptadopordefinirunainterfazpor cada tipo de elemento domótico sea un punto crítico en esteaspecto. Si en lugar de 4 interfaces diferentes se hubiera creado unaúnicainterfazcon4vistasdiferentes,sípodríamoshaberinsertadoenlainterfazuntabbar,gestionadoporunúnicocontrolador,quefueramanejando la pila de vistas una vez se carga cualquier elemento decualquiertipo.

6.2.Posiblesmejorasydesarrollosfuturos

Además de el cambio de interfaces por vistas nombrado en elpuntoanterior,durante larealizacióndelproyectohan idosurgiendoideasdeposiblesmejoras,modificacionesodesarrollosfuturosquesepodríanllevaracaboparamejorarlo,modificarlooampliarlo.Vamosaveralgunodeellos.

6.2.1.Informaciónalmacenadaenbasesdedatos

52

No considero esto una mejor, sino unavariación o simplemente una alternativa aldesarrollo planteado. La información sobre lasviviendas,podríaalmacenarseenunabasededatosimplementada en el propio terminal. IPhone OSsoporta elmotor de bases de datos SQLite, lo quepermitiríaalmacenarlainformacióncargadaenuna

base de datos, pudiendo por ejemplo implementar métodos yinterfacesparahacermodificaciones,ounhistóricodeviviendasparapoderirhaciendo“cargas”desdeficherosxmlunaúnicavez.

6.2.2.Informacióndeestadodeloselementos

EnesteproyectohemosdiseñadoydesarrolladolainteraccióndelusuarioconsuviviendaatravésdeunservidorquerecibepeticionesPOST http para modificar el estado de un determinado elementodomótico. Sin embargo, no obtenemos ninguna información alrespecto.Porejemplo,alseleccionarundispositivodetipobinario,senos presenta la interfaz correspondiente, con el botón deslizante enestado “off”. Esto sehacepordefecto, ydepoder consultar el estadodelelementopodríamossituarloenelestadoquerealmenteestuvieseen esemomento. Además, cuando nosotrosmandamos una señal decambiodeestado,noobtenemosinformaciónsobresidichocambiosehallevadoacaboono.Asípues,lorepresentadoenlainterfazyloqueenlarealidadsucedepuedeestardesacompasado,cosaqueresultaríaincomodoyconfusoparaelusuario.

Esta modificación requeriría, además de los cambios deprogramación correspondientes en nuestra aplicación, que el propioservidortuvieraunametodología implementadaparaestasconsultas,ya fuera devolviendo una respuesta con dicha información tras unapeticiónhttpodecualquierotraforma.

6.2.3.Interfazgráficaalternativa

En las primeras reuniones que definieron a grandes rasgos elcontenidodelpresenteproyectoentreeldirectoryyo,sepusosobrelamesa la posibilidad de desarrollar una interfaz gráfica querepresentara la vivienda eficiente de nuestro prototipo, y que

53

permitieraalusuariointeractuarconlamismadeunamaneraaúnmásintuitiva,utilizandounaimagenenlugardetextoparamostrartodoelcontenidodenuestroviviendo.

Lasventajasestánclaras.Aúnmáscomodidad.Elusuariopodríasimplemente tocar con sudedo encimadel dispositivodeseado, o deuna habitación (sector) para ver respectivamente la interfaz delelemento seleccionado o un listado como los que en el desarrolloactualseutilizan.

Sinembargo,estaideapuedetenertambiénalgunosproblemas.El

primero es que esto no permitiría o dificultaría la existencia desectoresanidados,yaquesisepresentaunaimagendeunavivienda,yestatieneunsector“2ªplanta”,queasuveztieneotrashabitacionesyelementos,tendríamosqueincluirennuestraimagendelaviviendaunaccesoaesasegunda imagen,ysecomplicamássipensamosenmásniveles.

Elsegundoproblema,muchomásgravetodavíaqueesteprimero,es que esto no permitiría el uso de la aplicación para cualquiervivienda, ya que digitalizar una vivienda supondría la definición deestaimagen(nosólolaimagenensí,sinotodalaconfiguracióndelasáreasdelamismaconlaqueelusuariopuedeinteractuar).Seperderíaasí toda la flexibilidadde laaplicación, limitándolaasuusoparaunaviviendaoentornopreviamentefijadoydesarrollado.

54

Loconsideropuesunaposibleampliación,quehabríaquesopesary razonar previamente para solventar los problemas derivadosexpuestos.Además,sepodríaaprovecharelacelerómetroqueposeeelterminaliPhoneparacombinarlarepresentaciónactualdetextoconlarepresentación propuesta de imagen. Por ejemplo, si el usuariomantieneeldispositivoenposiciónvertical,navegaríaporlaaplicacióntal cual se hace en el presente desarrollo, mientras que si tumba eldispositivosituándoloenhorizontal,pasaríaaobtenerunanavegaciónconimagen.Sinduda,muyatractivo.

6.2.4.Pantalladeconfiguración

He hablado en múltiples ocasiones de la importancia de laflexibilidadde laaplicación.Sinembargo,enelpresentedesarrollo lacomunicaciónconelservidoresdeundeterminadomodo,yesolimitala utilidad de la aplicación. Sería muy interesante que se pudieranconfigurar algunos de estos parámetros, tales como la dirección delservidor con el que nos vamos a comunicar para interactuar con loselementos,olarutadondeseencuentraelxmlacargar.Estopermitiríala posibilidad de que con la aplicación se pudieran controlar no sólodiferentesentornosdomóticos,sino inclusoentornoscontroladospordiferentesservidores.

Se podría diseñar una interfaz de configuración que se pudieracargar desde la pantalla principal (donde se listan las viviendascargadas)paraconfigurarestosparámetros.Seplanteatambiéncomounaposibleampliación.

55

7.ANEXO1.Pordóndeempezar

Empezar no sólo es el primer paso, sino que suele ser el máscomplicado.EnelcasodedesarrolloparaiPhoneOS,sobretodosinoseestáhabituadoaldesarrolloparaentornosMacodispositivosmóviles,estopuedeseraúnmayor.

Elprimerpaso,esiralawebdedesarrolloparaIPhonedeApple(http://developer.apple.com/iphone/index.action) y registrarse conunacuentadedesarrollador.Elregistrogratuitonosdaaccesoatodaslasherramientasydocumentaciónexistentes.Elregistrodepagocomodesarrollador nos permitiría probar nuestras aplicaciones enterminalesiPhoneypublicarlasenlaAppStore,peroestoyaseescapadelonecesario.

Enesamismaweb,encontraremosunmontóndedocumentación,pero antes de comenzar a leer, debemos descargarnos el SDK(Software Developement Kit) que nos proporciona Apple. Como yavimos en los primeros apartados de estamemoria, incluye todas lasherramientasnecesariasparaeldesarrollodeaplicacionesparaiPhoneOS.

Hasta aquí los pasos básicos indispensables. Crear aplicacionespara iPhone OS es relativamente simple con las plantillas queincorporadasenelXcode,perocrearaplicacionesquehacenalgoútilyque tengan un aspecto agradable requieren mucho más tiempo delectura de documentación. Recomendaría revisar la documentaciónpropuestaporAppleenestamismaweb,quenosdaunaideageneraldecómosefundamentaiPhoneOs(sibienlalecturadeestamemoriapodríavalercomounbuenpuntodepartida).

Tras esta primera fase de lectura y como se suele decirhabitualmente, la práctica hace al maestro. Mi recomendación esbuscar webs con ejemplos y tutoriales, y comenzar a “trastear” conellos, tratando de reproducirlos, y así, poco a poco, ir descubriendotodoslosmecanismos,complejidadesyposibilidadesquenosbrindalaprogramaciónparaiPhone.Recomiendoentreotras:

http://cocoadevcentral.com/d/learn_objectivec/

http://www.iphonesoftware.es/

http://icodeblog.com/

56

http://www.iphonesdkarticles.com/

También recomiendoel cursodeprogramaciónpara iPhonequese llevó a cabo en la universidad Stanford, y quepodemos encontraríntegramentegrabadoenlared.

Por último, no conviene olvidar que existen múltiples foros deprogramación y en concreto dedicados al desarrollo de aplicacionespara iPhone OS que podemos encontrar muy fácilmente y que nosproporcionaránunaayudainestimablecuandotodolodemásfalle.Unabúsqueda en cualquier navegador web nos devolverá decenas deresultadosinteresantesalrespecto.