SYMBIAN OS C++

QU ES SYMBIAN?

www.uma.es

CONTENIDO
Qu es Symbian OS? Plataformas de Interfaz de Usuario Notacin Objetos Activos j Arquitectura Cliente-Servidor Gestin de memoria Servidor de ficheros Servidor de Sockets Ficheros y estructura de una aplicacin Configuracin del SDK g Dilogos

www.uma.es

Qu es Symbian?
Symbian es un sistema operativo de 32 bits diseado para los telfonos mviles 2G, 2.5G y 3G. 3G Symbian OS est diseado para ejecutar aplicaciones en un entorno con recursos reducidos La fiabilidad es clave para que conseguir la confianza de los usuario de los dispositivos La gestin de recursos y el framework de g cleanup proporcionan robustez y escalabilidad. Fue diseado para su uso en pequeos dispositivos alimentados con b t li t d bateras con amplias li capacidades de comunicaciones.

www.uma.es

Qu es Symbian?
Entre las claves que determinaron su diseo cabe destacar:
Rendimiento Diseado para optimizar el Rendimiento: tiempo de vida de la bateria bateria. Multitarea Multitarea: Telefona, mensajera y comunicaciones son componentes fundamentales. Software orientado a objetos y arquitectura altamente modular modular. Gestin de memoria optimizada para sistemas empotrados (ejecutables de pequeo tamao y cdigos basados en ROM) g )
www.uma.es

Qu es Symbian?
Reducidos requerimientos de memoria en tiempo de ejecucin. ejecucin Las aplicaciones Symbian OS estn principalmente orientadas al manejo de eventos en lugar de tener mltiples hilos de ejecucin. ejecucin El multithreading es posible, pero generalmente se evita su uso en l aplicaciones l t it las li i debido a que se generan varios kilobytes de sobrecarga por th d b thread.

www.uma.es

SYMBIAN OS C++
PLATAFORMAS DE INTERFAZ DE USUARIO

www.uma.es

Plataformas de Interfaz de Usuario

Cada una de estas plataformas suministra libreras de interfaz grfica de usuario y aplicaciones que se superponen al SO Symbian. Symbian Las principales plataformas de desarrollo existentes e istentes son: Nokia serie 60 Nokia serie 80 communicator UIQ Foma
www.uma.es

IDEs
CodeWarrior Development Tools por Symbian OS OS. Microsoft Visual C++ Professional Borland C++ Mobile Edition Carbide
Carbide C++, plugin para Eclipse Carbide vs, puglin para Visual Studio

Lnea de comandos

www.uma.es

SYMBIAN OS C++
NOTACIN

www.uma.es

Notacin
Los nombres de funciones, clases, definicin de tipos estructuras y mtodos tipos, deben empezar con maysculas maysculas. No usar espacios Evitar el uso _ excepto en las macros y en los identificadores de recursos.

www.uma.es

Notacin
Todas las variables automticas deben empezar en minsculas TInt size Las variables miembro deben empezar por i i TInt iSize(1024) Las constantes deben empezar por K const TInt Ksize = 1024;

www.uma.es

Clases
Prefijos:
C Clases alojadas en el heap, derivan de la C, clase base CB l b CBase. CBase R Clases que contienen manejadores de R, recursos T tipos T, M clases que contienen funciones virtuales y M, l i i i l no tienen variables miembros (interfaces interfaces) Las clases con funciones miembro estticas no l f i i b i tienen prefijos.
www.uma.es

Funciones
Los parmetros empieza por a L parmetros deben aparecen tanto en la Los d b l declaracin como en la definicin. Usar el atributo const para indicar que el mtodo no altera el estado del parmetro. parmetro El nombre de la funcin debe acabar en L si la funcin puede emitir una excepcin.

www.uma.es

Funciones
La funcin debe acabar en C si pone algn objeto en el cleanup stack y lo deja all.
Despus de llamar a una funcin de este tipo se debe hacer un pop del elemento.

Si la funcin acaba en D indica que el mtodo se encarga de la destruir el objeto en c estin cuestin.

www.uma.es

Tipos Enumerados
Enum deberan aparecer dentro de una clase Las enumeraciones son tipos, por lo tanto deben p ,p empezar por T Los miembros enumerados debes empezar por E
class CClaseBase: public CBase { enum TTipoEnumerado { ETipoUno, ETipoDos }; }
www.uma.es

SYMBIAN OS C++
OBJETOS ACTIVOS

www.uma.es

MANEJO DE EVENTOS
Symbian es un sistema operativo optimizado para el manejo de eventos en contraposicin a los eventos, sistemas operativos tradicionales que estn optimizados para el manejo de procesos y threads. Dos de las herramientas ms importantes de Symbian OS para el manejo de eventos son: Objetos activos Arquitectura cliente-servidor clientej g q Los objetos activos, al igual que los threads, son planificados en base a la prioridad de estos.

www.uma.es

MANEJO DE OBJETOS ACTIVOS

Para crear un objeto activo este debe derivar de la clase CActive. Como mnimo debe implementar 3 funciones: CActive::RunL() es sobreescrita para el CActive::RunL(), manejo de los eventos; CActive::DoCancel() es llamada cuando se CActive::DoCancel(), cancela una peticin. No debera se llamada direcamente. Usar Cancel(); Cancel() () CActive::RunError(), es llamado por el Active Scheduler si la funcin RunL() emite () una excepcin; ; RequestL (como mnimo una) q ( )
www.uma.es

MANEJO DE OBJETOS ACTIVOS

class CRetrieveHttp : public CActive { public: static CRetrieveHttp* NewL(MRetrieveHttpCallbacks& aCallback); static CR i CRetrieveHttp* N LC(MR i H * NewLC(MRetrieveHttpCallbacks& i H C llb k & aCallback); ~CRetrieveSmtp(); void RunL() ; void DoCancel() ; void R id RequestL(); tL() private: void C id ConstructL(); t tL() CRetrieveSmtp(MRetrieveHttpCallbacks& aCallback) ; } ;
www.uma.es

MANEJO DE OBJETOS ACTIVOS

RequestL funcin a travs de la cual se le hace RequestL: algn tipo de peticin al objeto activo. activo void CRetriever::RequestL(HBufC* aAddress) { .. // Activacin del objeto activo SetActive() ; }
www.uma.es

OBJETOS ACTIVOS
A diferencia de los threads si un objeto activo empieza a ejecutarse lo hace hasta que termina su funcin R L() f i RunL(), aunque otro objeto activo d RunL() t bj t ti de mayor prioridad sea activado!!!. Qu se consigue con esto?
No se necesita el uso de semforos, secciones crticas u otro tipo de mtodos de sincronizacin para proteger la ejecucin de los diferentes objetivos activos de un thread. La funcin RunL() es una operacin atmica. Es ms eficiente. Se evitan los cambios de contextos que supondran las sucesivas conmutaciones entre objetos activos. Por este motivo en Symbian las aplicaciones y los servidores slo necesitan un thread.

www.uma.es

MANEJO DE OBJETOS ACTIVOS

www.uma.es

MANEJO DE OBJETOS ACTIVOS

Un thread representa una unidad de ejecucin. ejecucin Un thread en Symbian se puede entender como un manejador de eventos en el cual una entidad denominada Active Scheduler se encarga de manejar las peticiones asncronas que emiten los objetos activos.
Se encarga de planificar el orden de atencin a las peticiones.

Hay una sola entidad Active Scheduler por thread.

www.uma.es

OBJETOS ACTIVOS E Especificar en la construccin las prioridad ifi l i l i id d del objeto Incluir en el constructor la llamada al planificardor CActiveScheduler::Add() Incluir en el destructor la llamada Cancel() para cerrar el manejador.

www.uma.es

MANEJO DE OBJETOS ACTIVOS

La funcin SetActive() lanza la funcin RunL del objeto activo CRetriever CRetriever. La funcin RunL() es la que se encarga de atender las peticiones que se realizan al objeto activo activo. Maneja la ejecucin de una peticin segn proceda d
Puede lanzar de nuevo la misma peticin, una nueva peticin o fi li l serie d peticiones. ti i finalizar la i de ti i

La funcin DoCancel() maneja la cancelacin de la i i l peticin.

www.uma.es

OBJETOS ACTIVOS
void CRetrieveHttp::CRetrieveHttp(): CActive (CActive::EPriorityStandard) { } CRetrieveHttp::~CRetrieveHttp() { Cancel(); Cancel() }

www.uma.es

MANEJO DE OBJETOS ACTIVOS

En la segunda parte del constructor ConstrucL() g p () se debe registrar el objeto activo en el Active Scheduler. Scheduler.
void CRetrieveHttp::ConstructL() //segunda fase del constructor { // se registra en el active scheduler CActiveScheduler::Add(this) ; }
www.uma.es

SYMBIAN OS C++
ARQUITECTURA CLIENTE CLIENTESERVIDOR

www.uma.es

SERVIDORES Los servidores se encargan de las gestin asncrona de los recursos compartidos Algunos servidores destacados:
Servidor de ficheros Servidor de ventana Servidor de telefona

Mltiples clientes pueden acceder d d simultneamente a un mismo servidor.

www.uma.es

SERVIDORS
Las arquitectura clientecliente-servidor permite:
Compartir los recursos del sistema entre los distintos clientes. Aislamiento de los servidores Asincronismo

www.uma.es

SERVIDORES
Servidor de ventana
RWsSession& wsSess; wsSess iEikonEnv >WsSession() wsSess=iEikonEnv->WsSession()

Servidor Comm
RcommServ commServ(); commServ.Connect(); commServ Connect(); Rcomm comm; Comm.Open(commServ, portName, accessMode);

Servidor de ficheros
RFs fSession; fSession.Connect(); Rfile file; File.Open(..)

Servidor de Socket
RSocketServ socketServ; socketServ.Connect(); Rsocket tcpSocket; Rsocket.Open(.);

Servidor Etel
RTelServer etelServ; etelServ.Connect(); Rphone phone; Phone.Open (etelServ, name)

Servidor de Agenta
RAgendaServ agendaServ; agendaServ.Connect(); CAgnModel agenda; Agenda.SetServer(agendaServ);

www.uma.es

SYMBIAN OS C++
GESTIN DE MEMORIA

www.uma.es

Introduccin
Las aplicaciones son diseadas para ejecutarse durante largos periodos de tiempo tiempo. Fallos en la asignacin de memoria son ms comunes que en los ordenadores de escritorio escritorio. Los mecanismos convencionales de gestin de excepciones d C++ no son recomendados debido i de d d d bid a que supone una sobrecarga considerable del cdigo. di
Slo estn soportados en la ltima versin de Symbian (9.0) (9 0) por motivos de portabilidad d l cdigo existente. ti d t bilid d del di it t

www.uma.es

if (miObjeto=new COtroObjeto()) == NULL) { SeHaProducidoUnError(); }

Mtodos convencionales para el chequeo de errores

Requieren lneas extras de cdigo Si un constructor f ll d t t falla durante l asignacin d t la i i de recursos no hay forma de devolver un cdigo de error porque l constructores no ti los t t tienen valor d l de retorno.

www.uma.es

Manejo de excepciones C++ proporciona una serie de mecanismos de manejo de excepciones (try catch (try, catch, throw) pero Symbian no hace uso de ellos Symbian proporciona su propio sistema p para el manejo de excepciones j p
La macro TRAP y su variante, TRAPD estas TRAPD, macros son usada para capturar e informar de los errores potenciales (trap harness trap harness) User::Lea e() t User::Lea ::Leave() termina l f i actual Leave(), i la funcin t l

www.uma.es

Manejo de excepciones en Symbian

Todas las funciones que puedan emitir una excepcin deben tener el subfijo L.
Esto permite a los programadores ejecutar dichas funciones dentro de un trap harness. () error=Prueba(); if (error!=KErrNone) { //manejo del error } En Symbian sera as: TRAPD (error, PruebaL()); if (error!=KErrNone) { //manejo del error }

www.uma.es

CLEANUP STACK Si una funcin emite una excepcin el control es devuelto inmediatamente al TRAP. TRAP Esto implica que cualquier variable automtica dentro de funciones llamadas dentro de un TRAP es destruida. E t puede ser un problema si l variable Esto d bl i la i bl automtica es un puntero a un objeto alojado en el heap (memory leak)

www.uma.es

Manejo de memoria Aplicaciones diseadas para ejecutarse durante largos periodos de tiempo
Sin reiniciar el sistema, sin interrupciones

L fallos debidos a asignacin de memoria Los f ll d bid i i d i y de recursos son ms comunes que es los ordenadores d d
Programacin eficiente
No usar la memoria RAM de forma innecesaria Liberar los recursos tan pronto como podamos Manejar las situaciones en las que se agota la j l i i l l memoria Volver a un estado estable tras una situacin de este tipo
www.uma.es

Stack y Heap Stack

L objetos son borrados automticamente Los bj t b d t ti t Valor por defecto 8Kb

Heap
Objetos borrados por el programador usando delete El tamao depende del dispositivo, dispositivo normalmente disponemos de mas de 0,5Mb

www.uma.es

CLEANUP STACK TRAPD (error, PruebaL()); L ) void PruebaL() L { CObjeto* objeto1 = new (ELeave) j CObjeto; CObjeto* objeto2 = new (ELeave) CObjeto; delete objeto1; //!!!MAL!!! delete bj t 2 d l t objeto2; }
www.uma.es

CLEANUP STACK
void ejemploL() { //objeto tipo T declarado en el stack Tbuf<10> buf; Tb f 10 b f //objeto tipo C: debe ser alojado en el heap. Cejemplo Cejemplo* miEjemplo = new (Eleave) Cejemplo; //si no hacemos nada que pueda emitir una excepcin no hay problema miEjemplo->iInt = 5; //PROBLEMA miEjemplo->funcionL(); } delete miEjemplo;

La forma correcta de actuar sera:

CleanupStack::PushL(miEjemplo); miEjemplo->funcionL(); CleanupStack::Pop();

www.uma.es

Leaving
Las funciones de este tipo son usadas generar una excepcin y propagar el valor de un error hasta un punto en el pueda ser tratada por un TRAP TRAP.
User::LeaveIfError(); User::LeaveNoMemory(); User::LeaveIfNull()

Para crear objetos en el heap usar la expresin: New (ELeave)

Si no existe memoria se genera una excepcin. Si la asignacin de memoria tiene xito no es necesario l i i d i ti it i comprobar el valor del puntero.

www.uma.es

Construccin en dos fases

CObjeto::CObjeto (Tint aVal) { iVal=aVal; iV l V l iMiembro= new (Eleave CSimple(aVal); (Eleave) }

Si se produce una excepcin durante la construccin la memoria ya ha sido asignada para CObjeto. i h id i d CObj Debido a la excepcin el punturo a Cobjeto no es vlido (parcialmente construido) (parcialmente construido) i l t t id Sin un puntero vlido la memoria no puede ser correctamente liberada

www.uma.es

Construccin en dos fases

Asignacin de la componentes del p inicializacin en el Symbian OS esto se ConstructL(): ConstructL(): memoria para todos los objeto despus de la j p constructor de C++. En lleva a cabo en el mtodo

void CObjeto::ConstructL() ConstructL() { iSimple = new (ELeave) CSimple; }

El constructor de C++ debera contener nicamente cdigo que no fuera susceptible de emitir excepciones.

www.uma.es

Construccin en dos fases CObjeto* CCompound:: NewLC () { CCbjeto* self = new (Eleave) j ( ) CObjeto(); CleanupStack::PushL(self); //segunda fase g self->ConstructL(); return self; t lf; }
www.uma.es

VARIABLES Y MEMORIA
stack cada thread tiene su propio stack. stack, L variables automticas se l li La i bl t ti localizan en el l stack. Cuando un mtodo es llamado sus parmetros son tambin localizados en el stack. stack
Debido a que el stack tiene un tamao bastante limitado (especialmente en Symbian), es ( p y ), recomendable usar llamadas a funciones con punteros o referencias a objetos para disminuir la necesidad de almacenar copias de los objetos en el stack.
www.uma.es

VARIABLES Y MEMORIA
El tiempo de vida de la variables localizadas en el stack se especifica de forma que cuando el bloque de programa finalice todas las variables automticas declaradas en ese bloque sean borradas automticamente. Si las variables tienen una clase que tiene un destructor entonces este es llamado antes de que el objeto sea retirado del stack.

Cada thread en Symbian OS tiene un heap (area d memoria d d t d l objetos ( de i donde todos los bj t creados dinmicamente son almacenados).
www.uma.es

VARIABLES Y MEMORIA
Cuando el objeto ya no sea necesario la memoria consumida por este debe ser liberada con la orden delete. El heap es tpicamente mucho mayor que el tamao del stack. Los objetos de gran tamao se deberan locali ar en el heap en localizar lugar de en el stack. Se deben usar punteros para localizar los objetos y borrar los objetos cuando nos son necesarios ya que a diferencia del stack el heap no se limpia automticamente. automticamente
www.uma.es

VARIABLES Y MEMORIA
Symbian OS proporciona una serie de mtodos para limpiar el heap (Cleanup Cleanup Stack). Stack Cuando los objetos del heap no van a ser p p j usados ms los punteros son empujados fuera del cleanup stack y los objetos apuntados son borrados borrados.

www.uma.es

SYMBIAN OS C++
DESCRIPTORES

www.uma.es

DESCRIPTORES
En Symbian OS hay nueve tipos de descriptores descriptores. La cuatro clases superiores son clases bases abstractas, de forma que no pueden ser instanciadas. instanciadas Las cinco clases de la parte inferior son implementaciones de las clases base. E it t d Existen tres descriptores b ff y d d i t buffer dos descriptores i t puntero. puntero Los punteros son usados para apuntar a los datos l d t en memoria mientras que l b ff i i t los buffers almacenan los datos como parte de su propia estructura. t t

www.uma.es

DESCRIPTORES

www.uma.es

DESCRIPTORES
TBufC<> HBufC y TBuf<> son instancias de TBufC<>, HBufC, buffers en memoria que almacenan el dato y su longitud. Disponen d un t l it d Di de tamao d memoria de i reservado en el momento de su construccin. La longitud del dato puede variar entre zero y el tamao reservado. TPtr tiene la misma funcionalidad que los buffers, q , pero no almacenan el dato que ellos representan, hacen referencia a un buffer externo. TPtrC es un puntero a un array d t TPt C t de tamao fij fijo, por esto motivo no proporciona mtodos para modificar los datos.

www.uma.es

DESCRIPTORES
TPtrC se usa normalmente para apuntar a arrays constantes o a buffers modificables, por ejemplo , p j p mtodos como TDesC::Mid() usan descriptores TDesC::Mid() para apuntar a una porcin del dato original TPtr se usa para alterar un buffer localizado en cualquier lugar de la memoria Los descriptores del tipo buffer establecen su mximo tamao en el momento de su construccin y no permiten que aumentar su tamao. HBufC es i fC el nico descriptor que proporciona el mtodo ReAlloc. ReAlloc Este mtodo crea un nuevo descriptor descriptor, copia el dato en el y borra la instancia original

www.uma.es

DESCRIPTORES: Ejemplos de Uso

Para declarar un literal que almacena una cadena constante en el programa binario se usa la macro _LIT. _LIT El siguiente ejemplo crea un literal con los siguientes caracteres hello0: hello0 :
_LIT(KHello,hello); _LIT(KHello,hello);

Para declarar un descriptor como una variable automtica localizada en el stack stack:
TB f<5> helloStack(KHello); TBuf<5> h ll St k(KH ll )

www.uma.es

DESCRIPTORES: Ejemplos de Uso

Para la declaracin de un buffer localizado en el heap existen varias alternativas: Ejemplo:
HBufC* helloHeap=HBufC::NewLC(KHello().Length()); //copia los caracteres y la longitud *helloHeap=KHello;

..
//retira y destruye el ltimo objeto puesto en el cleanup // //stack CleanupStack::PopAndDestroy();

www.uma.es

DESCRIPTORES: Ejemplos de Uso

Primero se hace un casting del literal KHello a la clase TDesC a travs del operador () (). TDesC tiene un mtodo Length() para obtener el nmero de caracteres del string string. HBufC dispone de un constructor denominado NewLC N LC que construye un d t descriptor b ff en el i t buffer l heap con la longitud indicada y devuelve un puntero a l t l.

www.uma.es

DESCRIPTORES: Ejemplos de Uso

Muchas clases proporcionan mtodos constructores para asignar memoria y construir el objeto, en lugar de usar new new. Estos mtodos se denominan tpicamente NewL o NewLC NewLC. L indica q e el mtodo genera un lea e que n leave (evento) si falla la asignacin o construccin. t i LC indica lo mismo, pero adems coloca el objeto construido en la parte superior del cleanup stactk.
www.uma.es

DESCRIPTORES: Ejemplos de Uso

HBufC Descriptor de un buffer localizado en el heap Son usados para almacenar cadenas constantes o d t datos cuando l l it d d estos no es d la longitud de t conocida hasta el tiempo de ejecucin. Para modificar el contenido de un descriptor localizado en el heap se usa la funcin Des() que proporciona un puntero modificable al buffer de datos.

www.uma.es

DESCRIPTORES: Ejemplos de Uso

Los descriptores localizados en el heap pueden ser construidos de dos formas: Usando las funciones miembros estticas New(), New() NewL() o NewLC() Usando las funciones Alloc() AllocL() o Alloc(), AllocLC() d un d All LC() de descriptor existente i t it t

www.uma.es

DESCRIPTORES
HBufC* helloWorldHeap = HBufC::NewLC NewLC(Ks().Length() + g Kt().Length()); TPtr helloWorldAppend(helloWorldHeap->Des() Des()); pp helloWorldAppend = Ks; helloWorldAppend.Append Append(Kt);

www.uma.es

SYMBIAN OS C++
SERVIDOR DE FICHEROS

www.uma.es

Servidor de ficheros (F32)

El servidor de ficheros (F32) ofrece un API para (F32) sus clientes que permite a los programadores manipular unidades, directorios, ficheros y leer y escribir datos en los ficheros. Las principales clases de inters son: RF RFs RFile TFileName

www.uma.es

FICHEROS: RFs
La clase RFs representa una sesin con el servidor de ficheros. Se necesita establecer una sesin para cualquier operacin relacionada con fi h i l i d ficheros. Al establecer una sesin se pueden usar clases como RFile RFile, RDir o CDir Todas estas clases vienen definidas en el CDir. fichero f32file.h. 32file. Ejemplo de uso:
Connect(). Establece la conexin con el servidor de ficheros. DefaultPath(). Devuelve el path por defecto del sistema. p p SessionPath(). Establece el path de la sesin. Close(). Cierra la sesin con el servidor de ficheros.
RFs fsSession; ; User::LeaveIfError(fsSession.Connect()); ... fsSession.Close();

www.uma.es

FICHEROS: RFile
El objeto RFile representa un fichero. Para abrir un fichero se dispone de cuatro funciones:
Open(): Abre un fichero existente. Create(): Crea un nuevo fichero para escritura. Replace(): Borra un fichero existente y crea uno nuevo para escritura. Temp(): Abre un fichero temporal y le asigna un p p nombre. b

Una vez el fichero est abierto se puede leer a travs del mtodo Read () usando una variable del tipo TDes8 o escribir el contenido de un TDesC8. Existen varios modos de acceso: lectura compartida, escritura exclusiva o escritura compartida.
www.uma.es

FICHEROS:TFileName
Almacena el nombre de un fichero. TFileName es simplemente un descriptor del tipo TBuf<256> TBuf<256>. Un nombre de fichero, incluyendo la unidad, y los directorios no puede superar los 256 caracteres de longitud. Un nombre de fichero contiene cuatro partes:
Unidad Path (lista de directorios entre barras invertidas) Nombre del fichero Extensin
C:\\symbian\\documentos\\fichero txt C:\\symbian\\documentos\\fichero.txt

TFileName es un objeto grande (524 bytes), por este motivo nunca se debera alojar en el stack. j
www.uma.es

Comunicacin basada en sockets

www.uma.es

Sockets en Symbian
Basados en el concepto de sockets BSD usados en UNIX Los sockets pueden ser usados sobre TCP/IP TCP/IP, sobre I DA y sobre b IrDA b Blueetooth. Blueetooth Arquitectura clienteq servidor ESOCK proporciona las APIs RSocketServ y RSocket. RSocket

www.uma.es

Sockets en Symbian

La clase RSocketServ representa una sesin con el servidor de sockets sockets. A travs de la clase RSocketServ se pueden realizar consultas al servidor de sockets sobre el nmero de protocolos que soporta o informacin sobre un protocolo en particular particular.

www.uma.es

Sockets en Symbian
Si un aplicacin necesita realizar una conexin con sockets primero debe tener una instancia al objeto RSocketServ y establecer una conexin con el servidor de sockets.
Ejemplo:

RSocketServ socketServer; RSocket socket; TInt err=socketServer.Connect();

www.uma.es

Sockets en Symbian
La clase RSocket representa una subsesin dentro de una sesin establecida con el servidor de sockets a travs de un instancia de RSocketServ
aServer referencia a una sesin abierta con el servidor de sockets de Symbian OS addrFamily,especifica la familia de direcciones
KAfInet (in_sock.h). Sockets de Internet. KIrdaAddrFamily (in_sock.h). Sockets Infrarrojos. KBTAddrFamily (bt_sock.h). Sockets bluetooth. y( )

www.uma.es

Sockets en Symbian
sockType, tipo de socket:
KSockStream (es sock h) Orientados a conexin (es_sock.h). conexin. KSockDatagram (es_sock.h). No orientados a conexin. KSockSeqPack (es_sock.h). No usado actualmente. KSockRaw (es sock.h). Raw. (es_sock.h).

Protocolo:
KProtocolInetIcmp (in sock h) (in_sock.h) KProtocolInetTcp (in_sock.h) KProtocolInetUdp (i (in_sock.h) k h) KProtocolInetIp (in_sock.h)

www.uma.es

RSocketServ ss; Rsocket socket; TRequestStatus status; //Conexin con el servidor de sockets ss.Connect(); //Apertura de un Socket TCP socket.Open(ss, KAfInet, KSockStream, KProtocolInetTcp); _LIT(Kaddr, 192.168.2.1); LIT(Kaddr, 192.168.2.1 ); const TInt KPort = 21; TInetAddr destAddr; destAddr.Input(Kaddr); destAddr.SetPort(Kport); //conexin socket.Connect(destAddr,status); User::WaitForRequest(status);

www.uma.es

www.uma.es

TBuf8<256> buffer; TSockXfrLength recvlen; //peticin de lectura socket.RecvOneOrMore(buffer,0,status,recvlen); s ck t R cvOn OrM r (buff r 0 st tus r cvl n); User::WaitForRequest(status); //peticin de envo socket.Send(buffer, 0, status); User::WaitForRequest(status); //final de la conexin socket.Close(); ss. os (); ss.Close();
www.uma.es

SOCKETS: Ejemplo de uso

Conexin del socket servidor. Asignacin de una direccin y un puerto. puerto
TSockAddr sockAddr; sockAddr.SetPort(80); socket.Bind(sockAddr); k t Bi d( kAdd )

Escucha de conexiones entrantes:

//tamao de la cola de escucha. const TUint KSizeOfListenQueue = 1;

www.uma.es

SOCKETS: Ejemplo de Uso

//Se mantiene a la escucha de conexiones soc t.L st n(KS z OfL st nQu u ); socket.Listen(KSizeOfListenQueue); //Crea un socket en blanco serviceSocket.Open(socketServer); Aceptacin de una conexin entrante socket.Accept(serviceSocket,status); socket Accept(serviceSocket status); User::WaitForRequest(status);

Como segundo parmetro se le pasa la variable status en la cual queda registrada cualquier tipo de incidencia que tenga lugar durante la ejecucin de la peticin realizada al servidor de sockets.

www.uma.es

SOCKETS: Ejemplo de Uso

Conexin del socket cliente a travs del mtodo
void Connect(TSockAddr& anAddr,TRequestStatus& aStatus);

La clase RHostResolver es usada para resolver los nombres de los hosts. U Una vez establecida l conexin entre d t bl id la i t dos dispositivos se lleva a cabo la transferencia de los datos: d t
Envo de datos:
RSocket::Send(); RSocket::Send(); RSocket::SendT(); RSocket::SendT();

www.uma.es

SOCKETS: Ejemplo de Uso

Recepcin de datos:
RSocket::Recv(); RSocket::Recv(); (); () RSocket::Read(); RSocket::Read(); RSocket::RecvOneOrMore(); RSocket::RecvOneOrMore(); RSocket::RecvFrom(); RSocket::RecvFrom();

Una vez finalizada las transferencia de datos los sockets deben ser cerrados usando el mtodo Close() Close(). () Previamente se recomienda usar el mtodo CancelAll() para que cualquier accin asncrona pendiente sea correctamente cancelada.

www.uma.es

SOCKETS: Ejemplo de Uso

Las funciones Connect() Accept() Write() y Connect(), Accept(), Read(), Read() son funciones asncronas que normalmente son manejadas usando objetos l t j d d bj t activos. Para esto es necesario que las clases que se encargan del manejo de los sockets deriven de la clase CActive CActive. Despus de la llamada a una de estas funciones se debe activar el objeto a travs del mtodo SetActive(), d f SetActive() S tA ti () de forma que una vez completada l l t d la peticin asncrona realizada al servidor se ejecute el mtodo RunL() dentro del cual se comprobar el resultado de estas peticiones.

www.uma.es

SOCKETS: Ejemplo de Uso

void CTcpIp::RunL() { TBool finished = EFalse ; switch (iState) { case EIdle: break ; case EResolving: if (iStatus == KErrNone) { TInetAddr address ; address = iHostAddress().iAddr; address.SetPort address SetPort (80) ;

www.uma.es

SOCKETS: Ejemplo de Uso

// Se intenta abrir el socket if (iSocket Open(iSockServer KAfInet, (iSocket.Open(iSockServer, KAfInet KSockStream, KProtocolInetTcp)==KErrNone) { iState =EFailed ; finished = ETrue ; }else{ iState = EConnecting ; iSocket.Connect(address, iStatus) ; } } else{ iState = EFailed ; finished = ETrue ; } break ;
www.uma.es

SOCKETS: Ejemplo de Uso

case EConnecting: // Socket abierto con xito. Se inicia el envo de //datos //d t // se actualiza avanza hasta el estado ESending if (iStatus == KErrNone) { iSocket.Write(iRequest, iStatus) ; q iState = ESending ; } else{ iState EFailed iSt t = EF il d ; finished = ETrue ; } break ;

www.uma.es

SOCKETS: Ejemplo de Uso

case ESending: // Datos enviados, se inicia la recepcin p if (iStatus == KErrNone) { iSocket.RecvOneOrMore(iResponseChunk, 0, iStatus, iResponseChunkSizePkg) ; iState EReceiving ; iSt t = ER i i }else {iState = EFailed ; finished = ETrue ;} break ;

www.uma.es

SOCKETS: Ejemplo de Uso

............ ............ if (finished) DoCancel() ; else SetActive() ; }

www.uma.es

SYMBIAN OS C++
FICHEROS Y ESTRUCTURA DE UNA APLICACIN

www.uma.es

Ficheros de la aplicacin
.mmp Contiene los archivos necesarios para la mmp: compilacin. Especifica toda la informacin del p p proyecto. mmp, q p q El fichero .mmp, que es equivalente a un makefile. .hrh: contiene las enumeraciones usadas en los archivos .rss, .h y .cpp rss, cpp. pp
El contenido tpico de este fichero es la lista de comandos definidas en los mens de aplicacin, en la barra d t b de tareas,

www.uma.es

Ficheros de la aplicacin
.rss es el fichero de recursos. Contiene la rss: definicin de todas las cadenas estticas botones estticas, botones, mens, listas,usados en el interfaz de usuario de la aplicacin. .rsc fichero de recursos binario generado en la rsc: compilacin. compilacin .rsg: fichero de cabeceras generado en la rsg compilacin. il i Eikon.rh: Fichero de cabeceras que definen las Eikon.rh estructuras Uikon estndars para los recursos.

www.uma.es

Ejemplo: Tcp.mmp
TARGET TcpEx.app TARGETTYPE app UID 0x100039CE 0x101F6163 TARGETPATH \system\apps\TcpEx SOURCEPATH . SOURCE TcpEx_Main.cpp p pp SOURCE TcpEx_Application.cpp SOURCE TcpEx_Document.cpp SOURCE TcpEx_AppUi.cpp SOURCE TcpEx_AppView.cpp SOURCE TcpExActive.cpp USERINCLUDE . SYSTEMINCLUDE \ \epoc32\include 32\i l d RESOURCE TcpEx.rss LIBRARY euser.lib apparc.lib cone.lib eikcore.lib eikcoctl.lib inetprotutil.lib bafl lib esock lib insock.lib inetprotutil lib bafl.lib esock.lib insock lib

www.uma.es

Ejemplo: Tcp.mmp
TARGET: TARGET Nombre de la aplicacin que se genera. TARGETTYPE: TARGETTYPE Tipo de la aplicacin. UID: UID El primer nmero es comn a todas las aplicaciones con interfaz de usuario grfico (GUI). El segundo nmero debera ser solicitado a Symbian si se tiene intencin de comercializar la aplicacin, para realizar las pruebas se puede coger un nmero al alzar. TARGETPATH: TARGETPATH Especifica la ubicacin en la cual ser generado el archivo TcpEx.app. SOURCEPATH: SOURCEPATH Espeficifica la localizacin de los ficheros fuentes del d l proyecto. SOURCE: SOURCE Especifica los ficheros fuentes del proyecto. USERINCLUDE y SYSTEMINCLUDE especifican los directorios de bsqueda para l fi h b d los ficheros d l sistema y d l usuario. del i del i RESOURCE: RESOURCE Especifica el nombre del fichero de recursos. LIBRARY: LIBRARY Especifica las libreras para el linkado. CAPABILITY: CAPABILITY: Especifica las capacidades de las que hace uso la aplicacin.

www.uma.es

mmp
SECUREID. SECUREID Usado para especificar el directorio al cual puede acceder la aplicacin. EPOCSTACKSIZE. EPOCSTACKSIZE Tamao del stack

www.uma.es

Estructura de la aplicacin
Una aplicacin con interfaz de usuario grfico (GUI) consta de cuatro clases Clase aplicacin aplicacin:
Define las propiedades de la aplicacin y crea la clase documento.

Clase documento documento:

Representa el modelo de datos para la aplicacin. Si la aplicacin est basada en ficheros la clase documento es p responsable de almacenar y restablecer los datos de la aplicacin. Incluso si la aplicacin no est basada en ficheros debe te e una clase de e te ti fi he tener l e este tipo, an cuando d esta clase no tenga que hacer nada ms aparte de crear el interfaz de usuario de la aplicacin (app UI). p ( pp )
www.uma.es

Estructura de la aplicacin
Interfaz de usuario de la aplicacin (app UI): UI):
El app UI es completamente invisible. pp p Construccin de la clase de vista. Proporciona las funciones necesarias para el manejo de los comandos generados, por ejemplo, desde el men.

Cl Clase de vista para la aplicacin: d it l li i

Se trata de un control cuyo objetivo es visualizar los datos de la aplicacin en la pantalla y permitir que el usuario interacte con ellos. En el caso ms simple esta clase proporciona los mtodos necesarios para dibujar dib j en l pantalla, pero l mayora proporciona la ll la i funciones para el manejo de eventos de entrada.

www.uma.es