De manera nativa, el Framework de .NET nos ofrece la posibilidad de serializar la información en tres formatos: Binario, Soap, Xml.

La serialización en formato binario consiste en convertir la información a bytes y se utiliza comúnmente para los escenarios donde la información es transferida por la red hacia un sistema destino, el cual recibe dicha información y realiza el proceso inverso de la serialización = Deserializacion para construir el objeto (información) que fue transferido.
La serialización en formato Soap consiste en convertir los datos en un “documento estándar” en el cual se incluirá además de los datos a serializar, una serie de información adicional que será utilizada por el sistemas destino para construir el objeto original. Esta serialización es la que se utiliza en escenarios con Web Services.
Finalmente la serialización en formato Xml, consiste en transformar la información en un documento Xml que será interpretado por el sistema destino.

Los formatos de serialización Binario y Soap están contenidos en el namespace System.Runtime.Serialization, mientras que el Xml esta en el namespace System.Xml.Serialization.

Para ejemplificar cada escenario, supóngase que en nuestra aplicación se utiliza una entidad llamada Empleado definida como se muestra a continuación:

public class Empleado
{
    private int identificacion;
    private string nombre;
    private string apellido;
    private int edad;
    private string telefono;
    private DateTime fechaIngreso;
    private int diasLaborados;

    public int Identificacion
    {
        get
        {
            return identificacion;
        }
        set
        {
            identificacion = value;
        }
    }
    public string Nombre
    {
        get { return nombre; }
        set { nombre = value; }
    }

    public string Apellido
    {
        get { return apellido; }
        set { apellido = value; }
    }
    public int Edad
    {
        get { return edad; }
        set { edad = value; }
    }
    public DateTime FechaIngreso
    {
        get
        {
            return fechaIngreso;
        }
        set
        {
            fechaIngreso = value;
            DiasLaborados = (DateTime.Now.Subtract(fechaIngreso).Days);
        }
    }
    public string Telefono
    {
        get { return telefono; }
        set { telefono = value; }
    } 
    public int DiasLaborados
    {
        get
        {
            return diasLaborados;
        }
        set
        {
            diasLaborados = value;
        }
    }

}

Serialización en formato Binario
Como se mencionó anteriormente, éste método se utiliza generalmente para intercambiar información con otros sistemas a través de la red. Sin embargo para agilidad en la ilustración de su funcionamiento, los datos serializados en este post, se enviarán a un archivo de texto para visualizar su contenido. Esta serialización tiene la desventaja que solo funcionará entre aplicaciones .NET, es decir, que tanto la aplicación que serializa como la aplicación que deserializa deben ser aplicaciones desarrolladas bajo la plataforma .NET.

El primer paso para serializar un objeto en .NET, es incluir el atributo Serializable en la definición de nuestra clase así:

[Serializable]
public class Empleado
{…]

Esto le indicará al runtime de .NET que este objeto estará habilitado para ser serializado cuando se requiera, de lo contrario, se generará una excepción del tipo System.Runtime.Serialization.SerializationException.

Luego de esto, implementar la serialización binaria es tan sencillo como invocar el método Serialize de la clase BinaryFormatter que encontramos en el namespace System.Runtime.Serialization. Este método recibe como parámetros un Stream y el objeto que deseamos serializar, por ejemplo:

Si abrimos el archivo datoSerializado.txt, obtenemos:

Como se ve en la figura, la información obtenida después del proceso de serialización contiene una serie de caracteres especiales. Esto es porque en realidad estamos serializando en formato binario y el bloc de notas no esta en capacidad de interpretar este tipo de información. Sin embargo, en la vida real, se supone que ese stream es enviado a través de la red y recibido por una aplicación destino, la cual utilizará el método Deserialize del objeto BinaryReader para obtener el objeto Empleado que fue enviado inicialmente, así:

Lo cual da como resultado lo siguiente:

Profundizando un poco más en el como el runtime de .NET serializa los datos, debemos saber que en tiempo de ejecución el runtime convierte en bytes cada uno de los miembros del objeto sin importar el tipo o nivel de acceso (public, private, protected, etc). Esto en algunas ocasiones puede no ser lo que deseemos hacer, sino mas bien omitir algunos campos que consideramos no son necesarios al momento de serializar. En nuestro ejemplo especifico, para que queremos serializar el campo díasLaborados si puede ser calculado en tiempo de ejecución?. Esto implica un costo que podemos evitar ya que a mayor cantidad de miembros a serializar, mayor cantidad de información tendrá que ser transferida por red o almacenada en disco.

Para modificar el comportamiento de la serialización binaria, podemos utilizar el atributo NonSerialized en cada uno de los miembros que deseamos omitir, así:

[NonSerialized]
private int diasLaborados;

Con esto logramos que el resultado de la serialización sea el siguiente:

Donde se puede ver que ya no existe ninguna información referente al miembro diasLaborados. Sin embargo, al momento de ejecutar la aplicación destino y deserializar el objeto, obtenemos lo siguiente:

 
Donde podemos observar que no se está calculando el valor del campo diasLaborados. Esto se debe a que el proceso de deserialización lo que hace es “recrear” el estado del objeto serializado y como el campo diasLaborados no está incluido en la información serializada, es omitido en el proceso de deserialización.

Por fortuna, existe la interfaz IDeserializationCallback, la cual incluye el método OnDeserialization que es llamado una vez termina el proceso de deserialización del objeto. Implementar esta interfaz solucionará nuestro problema ya que en dicho método podemos calcular el valor del miembro diasLaborados y así garantizamos que siempre que se realice una deserialización del objeto, se tendrá el estado completo del mismo. Para implementar la interfaz, se hace lo siguiente sobre el objeto Empleado:

[Serializable]
public class Empleado:IDeserializationCallback
{
     //Definicon de miembros

     #region IDeserializationCallback Members

        public void OnDeserialization(object sender)
        {
            DiasLaborados = (DateTime.Now.Subtract(fechaIngreso).Days);
        }

        #endregion

}

Así, ejecutando nuevamente el código que se encarga de realizar la deserialización tenemos:
 

Serialización en formato SOAP.

La serialización en formato SOAP, consiste en utilizar un formateador especial que genera un documento SOAP con la información del objeto que deseamos serializar. Este formato de serialización es el utilizado en los servicios Web por su gran interoperabilidad entre sistemas ya que me permite tener los sistemas desarrollados bajo diferentes plataformas e incluso ejecutándose en diferentes plataformas (Linux, Windows, etc). Sin embargo, una de las desventajas que tiene este formato de serialización es que genera una gran cantidad de información al serializar nuestro objeto (debido a que se debe cumplir con el estándar de los documentos SOAP). Por este motivo, es necesario analizar que tipo de serialización utilizar en nuestra aplicación. Así entonces tenemos que la serialización binaria es la más eficiente pero sólo nos sirve para escenarios donde las aplicaciones están desarrolladas en .NET. Si por el contrario, necesitamos compartir nuestros datos con aplicaciones desarrolladas en otros lenguajes y además cumplir con el estándar SOAP, utilizaremos el formato SOAP y finalmente si lo que necesitamos es compartir información con aplicaciones desarrolladas en otros lenguajes pero no es necesario cumplir con ningún estándar, podemos utilizar el formato XML.

Para serializar en formato SOAP, sólo se debe utilizar el formateador SoapFormatter que se encuentra en el namespace System.Runtime.Serialization.Formatters.Soap, así:

Después de serializar obtenemos el siguiente resultado:

 
Como se ve en la figura, el comportamiento de la serialización en formato SOAP también se ve afectada por el uso del atributo NonSerialized

Serialización en formato XML.

La serialización en formato XML consiste en transformar el objeto en un documento XML, donde por defecto, el nodo raíz será el tipo de dato que estemos serializando y sus miembros serán elementos de ese nodo raíz.
La implementación de la serialización XML difiere un poco de las presentadas anteriormente ya que no se utiliza un formateador sino que se hace utilizando la clase XmlSerializer que se encuentra en el namespace System.Xml.Serialization. Esta clase recibe como parámetro el tipo de dato que deseamos serializar. Por ejemplo:

 
De esta manera le estamos indicando al objeto XmlSerializer que deseamos serializar un objeto de tipo Empleado, el cual al momento de invocar el método Serialize, genera un documento XML como el siguiente:

Como se puede ver en la figura anterior, el miembro diasLaborados fue serializado. Esto es porque la serialización XML no se ve afectada por el atributo NonSerialized. Sin embargo, la interface IDeserializationCallback si aplica para el proceso de la deserialización del objeto.

Para modificar el comportamiento de la serialización XML, se debe usar el atributo XmlIgnore sobre el miembro que deseamos omitir, así:

[XmlIgnore]
        public int DiasLaborados
        {
            get
            {
                return diasLaborados;
            }
            set
            {
                diasLaborados = value;
            }
        }

Es de notar que el atributo se ha utilizado sobre la propiedad DiasLaborados y no sobre el miembro diasLaborados. Esto es porque la serialización XML serializa únicamente los miembros públicos del objeto, por lo cual si usamos el atributo XmlIgnore sobre el miembro privado diasLaborados, el XmlSerializer igual seguiría generando el elemento DiasLaborados en el documento XML.

En el namespace System.Xml.Serialization, existen varios atributos que permiten modificar el comportamiento de la serialización XML y así obtener diferentes estructuras del documento XML generado. Uno de los atributos más usado es el XmlAttribute el cual se usa sobre cualquier miembro público y sirve para indicarle al runtime que dicho miembro lo genere como un atributo del nodo raíz y no como un elemento. Por ejemplo:

[XmlAttribute]
        public int Identificacion
        {
            get
            {
                return identificacion;
            }
            set
            {
                identificacion = value;
            }
        }
Luego de serializar nuevamente el objeto con el código ilustrado anteriormente, obtenemos:

Donde se ve claramente que el miembro Identificación es un atributo del nodo Empleado y no un elemento de dicho nodo como se había generado en el ejemplo previo.

Una de las tareas mas habituales a la hora de proteger información, es sin duda alguna el cifrado de datos. Mediante esta técnica podemos incrementar el nivel de seguridad de los datos que maneja nuestra aplicación, estableciendo un control sobre quien puede leer y/o modificar dicha información.

Hay que tener presente que la criptografía no evita el que las personas que no deben, accedan a la información que tratamos de proteger, sino que evita el entendimiento de la misma, que a la final es lo que nos importa ya que de “nada” le sirve al atacante acceder a las contraseñas de los usuarios de mi sistema si estas contienen un conjunto de caracteres “incoherentes”.

Por ejemplo, digamos que se tiene la cadena “894658987″ la cual representa el número de la tarjeta de crédito de un usuario de mi sistema. Al ser esto un dato crítico, considero que debería mantenerlo cifrado en mi base de datos para evitar que un atacante tenga acceso a esta información en caso de que logre vulnerar mi servidor de base de datos. Para esto, se aplica un algoritmo de cifrado mediante el cual se obtiene una cadena “incoherente” para todo aquel que no haga el proceso de descifrado. Para este caso, la cadena cifrada sería algo como Y=?)(/&%ttr6%.

La única manera de obtener la cadena original es aplicando el proceso de descifrado con el mismo algoritmo que se utilizó para cifrar la cadena. La ventaja de todo esto, es que no cualquiera puede descifrar la cadena ya que en los algoritmos criptográficos utilizan llaves (equivalentes a una contraseña) para cifrar y se descifrar y además se garantiza que solo con la llave correcta se puede descifrar. Esto es algo parecido a los procesos de autenticación por contraseña, donde la seguridad está basada en la privacidad de la contraseña. Del mismo modo, la seguridad del cifrado radica en la privacidad de la llave porque todo el que la tenga, podrá acceder a la cadena original.

Pero que es una llave?. Una llave no es más que un conjunto de bytes que cumplen ciertas condiciones según el algoritmo. Uno de los aspectos más importantes de las llaves es su longitud. La longitud de una llave se mide generalmente en bits y se determina según el algoritmo de cifrado utilizado. Por ejemplo el algoritmo DES utiliza llaves de 56 bits. Gran parte de la seguridad de las llaves radica en su longitud debido a que entre más pequeña sea, más fácil será obtener la combinación de bytes mediante fuerza bruta. Por esta razón, quizás la longitud de las llaves utilizadas, sea un factor para elegir el algoritmo de cifrado a utilizar en nuestra aplicación.

Otro de los factores que influye a la hora de elegir el algoritmo adecuado, es el tipo de criptografía que se utiliza: Publica (Asimétrica) o Privada (Simétrica). Ambas son técnicas que difieren en cómo se utiliza la o las llaves de cifrado. A continuación se dará una breve explicación sobre cada una.

Cifrado Simétrico (Privado) 

El cifrado simétrico, utiliza una llave para cifrar y descifrar el mensaje, es decir, se utiliza exactamente la misma llave tanto para cifrar como para descifrar. Esto implica que la llave deberá ser compartida entre todos los que deben acceder a los datos cifrados, lo cual implica un riesgo de seguridad ya que si por ejemplo se transfiere la llave por la red (correo electrónico por ejemplo), existe la posibilidad de que una persona no deseada tenga acceso a la llave y pueda acceder a la información confidencial cifrada.

El proceso consiste entonces en emplear uno de los algoritmos de cifrado simétrico existentes (DES, AES, 3DES, etc) con una llave especifica. Después de aplicar el algoritmo se obtendrá la cadena cifrada que podrá ser transmitida por la red o almacenada en algún lugar específico. Luego cuando sea necesario conocer la cadena original, el destinatario (aplicación, servidor, persona, etc.) deberá usar el mismo algoritmo y la misma llave que se utilizaron para cifrar el mensaje. Únicamente, aquellos remitentes que tengan la llave, podrán descifrar el mensaje.

Cifrado Asimétrico (Público) 

La técnica de cifrado asimétrico no es una mejora de la técnica anterior, es más, no es posible decir que el cifrado asimétrico es mejor que el simétrico ni viceversa. La técnica de cifrado asimétrico, nació para atacar nuevas necesidades.

A lo que voy es que uno de los puntos que ataca el cifrado asimétrico es el hecho de tener que compartir la llave secreta y está pensado para facilitar la comunicación entre un remitente y un destinatario sin necesidad de correr un riesgo a la hora de compartir la llave.

 El cifrado asimétrico usa un total de dos llaves para cifrar los mensajes. Una llave privada y una llave pública. Como sus nombres lo indican, la llave privada es personal y no deberá ser divulgada bajo ninguna circunstancia (ni siquiera a los destinatarios con los que deseo comunicarme), mientras que la llave publica podrá ser publicada y divulgada.

El secreto de esta técnica radica en que todo lo que se cifre con la llave privada, solo podrá ser descifrado con la llave pública y todo lo que se cifre con la llave pública sólo podrá ser descifrado con la llave privada. Esto implica entonces que lo que yo cifre con mi llave privada, podrá ser interpretado por todo aquel que tenga mi llave pública (que en teoría es todo el mundo porque es pública y generalmente se comparte en un servidor Web por ejemplo). De este modo el destinatario solo estaría seguro (en teoría) que el mensaje enviado lo escribí yo y digo que en teoría porque eso no sería cierto en caso de que mi llave privada la tenga otra persona.

En sentido contrario, si el remitente usa la llave publica del destinatario, se podrá garantizar que el mensaje sólo podrá ser descifrado por el destinatario ya que sólo él tiene su propia llave privada. Esto evita entonces el riesgo que implica el tener que compartir una llave que es privada como se tiene que hacer en el cifrado simétrico ya que lo que se comparte en este caso en una llave publica que no hay ningún peligro de que se conozca.

Lo que hay que tener presente en esta técnica, es que si yo deseo comunicarme con un destinatario siempre debo usar la llave pública del destinatario para garantizar que solo él podrá entender el mensaje. Si yo firmara el mensaje con mi llave privada, lo podría descifrar todo el que tenga mi llave pública, lo cual no garantizaría privacidad de los datos sino que le garantizaría al destinatario que yo fui quien escribí el mensaje (esta es la base de las firmas digitales).

El algoritmo adecuado para usar en nuestras aplicaciones va de acuerdo a las necesidades de cada quien. Si se pretende cifrar información que solo será descifrada por la misma aplicación o por otras pocas, es buena idea usar el cifrado simétrico ya que es más rápido y requiere menos procesamiento. Por otro lado, si la información que se cifra es para compartirla por la red o hacia múltiples destinatarios, será buena idea usar cifrado asimétrico para evitar los riesgos de compartir la llave privada.

Visitenlo, es totalmente gratis y es un proyecto que tiene mucho futuro porque según me enteré, tienen bastantes cosas por ofrecer.

Suerte !!!

Una de las tecnologías que se puede utilizar para desarrollar aplicaciones es la que nos brinda sun con su edición reducida de java J2ME (Java 2 Micro Edition).

El J2ME, es un subconjunto de packages, clases, interfaces, etc. del java que se conoce normalmente para desarrollar aplicaciones de escritorio o web, y tiene un tamaño bastante pequeño lo cual permite ejecutarse en dispositivos con capacidad limitada de procesamiento y/o almacenamiento.

Como lo mencione en un post anterior, para desarrollar aplicaciones móviles en J2ME debemos tener en cuenta los perfiles y las configuraciones. Por parte de las configuraciones tenemos las opciones CLDC o CDC y por parte de los perfiles contamos con el MIDP.

Una configuración puede entenderse como un agrupamiento de paquetes y clases. Así, se tendrá una base común para todos los dispositivos que soporten determinada configuración. La configuración CLDC (Connected Limited Device Configuration) es la configuración que menos clases tiene, ya que está pensada para dispositivos con una capacidad de procesamiento y de memoria bastante bajos, como por ejemplo los celulares y PDA. La configuración CDC Connected Device Configuration está pensada para dispositivos con mejores capacidades de procesamiento como televisores, controles remotos, etc.

Por lo anterior, sobra decir que la configuración que se debe utilizar para desarrollar aplicaciones para dispositivos como PDA y celulares es la CLDC, la cual usa una versión reducida de la maquina virtual conocida como KVM (Kilo Virtual Machine, el “kilo” se debe a su diminuto peso).

Por otro lado, los perfiles son clases de alto nivel que complementan a las configuraciones, con el fin de dotar al dispositivo de un entorno de ejecución completo para las aplicaciones. Para dispositivos como celulares y PDAS se debe usar el perfil MIDP (Mobile Information Device Profile), que contiene gran parte de clases de Interfaz de usuario.

En la actualidad contamos con varias versiones de cada configuración y perfil. Así, para la configuración CLDC tenemos la versión 1.0 y la versión 1.1, siendo la principal diferencia entre ellas, el que la versión 1.0 no trabaja con valores de punto flotante, mientras la segunda sí. Esto se traduce en que CLDC 1.0 no admite valores de punto flotante, es decir, que los teléfonos que tengan la versión 1.0 de la configuración CLDC no pueden trabajar con tipos de datos como double, float. Por esta razón, si nuestra aplicación necesita trabajar con datos numéricos que contengan decimales, el primer requisito que debemos tener en cuenta para el dispositivo que ejecutara la aplicación es que tenga la versión 1.1 de CLDC.

Por el lado del perfil MIDP, contamos actualmente con 3 versiones 1.0, 2.0 y 2.1, siendo la más utilizada ahora la 2.0 ya que la 2.1 solo la traen los teléfonos de última generación.

El primer paso a dar a la hora de comenzar con el desarrollo de una aplicación móvil, es elegir la plataforma de desarrollo. Personalmente me he inclinado por Netbeans ya que ofrece una gran facilidad a la hora de diseñar la parte visual de nuestra aplicación. También he escuchado que eclipse ha progresado bastante en cuanto a eso pero nunca lo he probado, por lo que a continuación indicaré a grandes rasgos que se necesita para desarrollar una aplicación j2ME en Netbeans.

Netbeans cuenta con varias “distribuciones”, según el tipo de aplicación que tengamos pensado desarrollar. Para desarrollar aplicaciones móviles, necesitamos descargar la versión “All” que podremos encontrar en la página http://www.netbeans.org/downloads/index.html. Esta es la versión ideal ya que trae incorporado todo lo necesario para el desarrollo de aplicaciones móviles. Sin embargo, si y ase cuenta con una versión diferente de netbeans instalada, se puede descargar la última versión del Wireless Toolkit para adicionarle el soporte para j2me.

El primer requisito para instalar Netbeans, es tener instalado el JDk en la maquina, el cual se puede descargar gratuitamente de la pagina de sun. Es recomendable tener la última versión del JDK, incluyendo los updates ya que así podremos acceder a las correcciones de bugs detectadas y/o nuevas funcionalidades.

Una vez instalado el Netbeans, solo tenemos que abrir el IDE, hacer clic en File > New Project y seleccionar la opción MIDP Application que se encuentra en la categoría Mobility, tal y como se muestra a continuación.

Luego debemos seleccionar la versión del MIDP y del CLDC que deseamos utilizar en nuestro proyecto. Es importante tener en cuenta este dato antes de comenzar el proyecto ya que una mala elección de estas versiones podría dejar inutilizable la aplicación en los dispositivos reales.

En este paso, también debemos elegir el dispositivo (device) con el que queremos ejecutar la aplicación. Esta opción es para indicarle a Netbeans que cada que nosotros ejecutemos nuestra aplicación con el comando ejecutar de netbeans, abra automáticamente el emulador del dispositivo seleccionado. Esta elección no afecta para nada la aplicación final ni implica que la aplicación solo podrá ejecutarse en dicho dispositivo, únicamente es una elección para emular el comportamiento de la misma en tiempo de desarrollo.

Por defecto, Netbeans trae instalados unos emuladores básicos con los que podemos probar el funcionamiento de nuestras aplicaciones. Sin embargo, cada fabricante de dispositivos, provee emuladores más específicos para poder emular la ejecución de la aplicación en un entorno más real. Así por ejemplo si la aplicación está siendo desarrollada para celulares Nokia 6100, tenemos la posibilidad de descargar un emulador de dicha plataforma para tener una ejecución mucho más realista.

Aquí vamos entendiendo que eso de la portabilidad de java no deja de ser pura teoría, porque la misma aplicación puede comportarse de manera diferente en distintos dispositivos. Para que necesito yo una aplicación que se pueda instalar y ejecutar en cualquier dispositivo con CLDC 1.1, si funcionalmente es inservible en algunos? A lo que me refiero es a que es probable que la aplicación si instale en todos los dispositivos CLDC 1.1, pero que solo funcione correctamente en los Nokia.

Esto se debe, porque además de la configuración y el perfil que soporte cada dispositivo, debemos tener en cuenta los JSR (Java Specification Request) con los que este equipado, y peor aún, cada fabricante de dispositivos puede implementar de manera diferente los JSR.

 Los JSR son un conjunto de clases que complementan las librerías bases ofrecidas por la configuración. Para que quede más claro, recordemos que todos los dispositivos que soporten la misma versión de CLDC van a tener las mismas librerías o clases bases. Pero si somos realistas, cada teléfono es diferente, algunos pueden tener bluetooth, otros pueden tener capacidad de acceso a Internet mientras que otros no. Cada JSR ataca funcionalidades especificas, por lo que podremos encontrar un jsr que se encarga de la funcionalidad del bluetooth, otro JSR que se encarga de las peticiones HTTP y SOAP (clientes de servicios web), etc.

Por lo anterior, es necesario verificar que librerías adicionales estamos utilizando (JSR) estamos utilizando ya que eso será un requisito mas para el dispositivo que ejecute la aplicación. Por ejemplo, si la aplicación móvil consume un web service, estamos utilizando el JSR 172 y será requisito indispensable que el dispositivo cuente con la implementación de dicho jsr ya que de lo contrario la aplicación no funcionara correctamente.

A manera de conclusión entonces, tenemos que las aplicaciones móviles desarrolladas en Java no son tan portables como dice la teoría ya que el correcto funcionamiento de la misma en diferentes teléfonos depende de las librerías que implemente cada celular.

Por ejemplo, supongamos que en la aplicación se implementa un control Tabla con la funcionalidad de scroll horizontal y vertical, el cual se utiliza para mostrar información tabulada. Es posible (y casi certero) que la misma tabla funcione correctamente en unos dispositivos mientras que en otros no funcione el scroll vertical y en otros no funcione ningún tipo de scroll. Esto se debe a que como lo comente anteriormente, cada fabricante puede implementar de manera diferente cada API de java. En este caso especifico, pudiera deberse a que los fabricantes de los dispositivos implementan de manera diferente el método encargado del LAYOUT o “distribución de controles en pantalla”.

Por tal motivo es recomendable:

1. Entender, que en pocas ocasiones la misma aplicación sirve en diferentes tipos de dispositivos.

2. Analizar que versión de CLDC y MIDP se va a utilizar, teniendo en cuenta que eso será requisito para el dispositivo en que se ejecutara la aplicación.

3. Analizar que JSR se están utilizando para incluirlos como requisito del dispositivo que ejecuten.

4. Probar la aplicación inicialmente en el emulador genérico de Netbeans, luego descargar el emulador del dispositivo específico en el que se ejecutara l aplicación (Nokia, Motorola, Blackberry, Sony Ericsson, etc.)

5 Finalmente desplegar la aplicación a los dispositivos reales, estando dispuesto a sorpresitas poco deseadas, porque recuerda, con J2ME, Write Anywhere, Run Once.

Suerte !!!

La clase Stream, es una clase abstracta, por lo que no es posible utilizarla directamente ya que no se puede crear instancias. Lo que se debe hacer es utilizar una de sus clases derivadas que se especializan en el tratamiento de streams para diferentes destinos como por ejemplo FileStream (para el manejo de archivos), Memorystream (para el manejo de datos en memoria), etc.

La primera opción para escribir y/o leer datos de una archivo de texto es utilizar la clase FileStream. Esta clase se encuentra en el namespace System.IO y es una clase derivada de la clase Stream.

El FileStream actúa como un intermediario entre el sistema de archivos y nuestra aplicación, permitiendo realizar de una manera limpia y sencilla operaciones de escritura y lectura en archivos. Para utilizar el FileStream, lo primero que se debe hacer es crear una instancia que apunte al archivo deseado. Para esto se tiene la opción de utilizar alguno de los constructores ofrecidos, tal y como se muestra a continuación:

Como se ve en la figura anterior, es un constructor bastante tedioso de utilizar porque recibe una cantidad considerable de parámetros. Para contrarestar esto, tenemos la posibilidad de utilizar alguno de los métodos ofrecidos por la clase utilitaria File, que nos permite obtener un FileStream con parámetros específicos de acuerdo al método utilizado para obtenerlo. A continuación se muestra un ejemplo:

En el ejemplo anterior se utilizó el método Create el cual crea el archivo en la ruta especificada y en caso de que el archivo exista, es sobrescrito. Estos métodos ofrecidos por la clase File, facilitan el desarrollo de aplicaciones con manejo de archivos y permite una mejor lectura de código.

Para escribir datos en un archivo de texto, se utilizan los métodos Write y WriteByte. El primero recibe como parámetro un vector de bytes que representa la información a almacenar, mientras el segundo recibe como parámetro un solo byte para ser escrito. Elegir cual de los dos métodos utilizar depende del escenario, ya que cuando se va a escribir gran cantidad de información, no es recomendable escribir byte a byte porque se ejecutaría muchas veces el mismo ciclo sino que por el contrario, es conveniente escribir varios bytes a la vez.

A continuación se muestra un ejemplo de la operación de escritura con ambos métodos:

Se puede observar como se utiliza la clase Encoding para formatear la cadena en UTF8 y obtener el array de bytes que se debe escribir en el archivo. De la misma manera se puede codificar el texto a escribir en otro formato como por ejemplo ASCII, Unicode, etc.

Es importante mencionar que todo stream se debe cerrar al finalizar la operación que se realiza sobre el, ya que de lo contrario el archivo quedaría bloqueado y no se liberarían recursos del sistema operativo. Adicionalmente, el método Flush, se utiliza para indicarle a la clase FileStream, que escriba en el archivo físico lo que se ha escrito con el método WriteByte o con el método Write hasta el momento ya que de lo contrario, dichos cambios se verían reflejados únicamente cuando se cierre el Stream. Este método seria útil cuando queremos que se escriba el texto en el archivo y no deseamos cerrar el Stream porque necesitamos seguir haciendo operaciones de escritura, además de ser una buena práctica siempre utilizarlo aun cuando parezca ser innecesario.

La implementación de la misma funcionalidad con el otro método, seria como se muestra a continuación.

Como se ve en el ejemplo anterior, con estos métodos, el programador tiene un control muy preciso sobre la información que desea escribir en el archivo, tanto, que hasta puede llegar a ser engorroso en algunas ocasiones.

Afortunadamente, la plataforma .NET ofrece otras maneras de administrar Streams para hacerle la vida más fácil al desarrollador. Una de esas maneras es utilizar la clase StreamWriter para escribir en archivos y StreamReader para leer desde archivos. Es necesario tener en cuenta que estas clases están orientadas a obtener caracteres como salida a diferencia de las clases que heredan de Stream que están orientadas a obtener bytes.

Con la clase StreamWriter, solo nos debemos preocupar por utilizar el método Write o WriteLine para escribir datos en un archivo de texto. Estos métodos reciben tipos de datos nativos del lenguaje como por ejemplo int, bool, decimal, float, string, char, etc. Y utiliza el codificador indicado cuando se instancia la clase para codificar los caracteres de salida al archivo de texto. En caso de utilizar un constructor que no especifique algún Encoding, por defecto esta clase opera con el UTF8.

Como se ve en el ejemplo anterior, las líneas de código son mucho mas sencillas que las vistas en el ejemplo del FileStream. Esto es porque la clase StreamWriter es una clase especializadas para el trabajo de Stream hacia archivos de texto y nos evita el trabajo de tener que obtener la representación en bytes del valor que queramos escribir.

La diferencia entre el método Write y WriteLine, es que el segundo inserta un salto de línea al final de los datos ingresados, haciendo que la próxima vez que se quiera insertar, se hará en la siguiente línea.

Aunque la clase StreamWriter no hereda de la clase Stream, si utiliza en su implementación un Stream en el cual escribe o lee secuencias de caracteres. Por eso, esta clase en su interior, se encarga de crear y utilizar el Stream necesario para apuntar al archivo de texto representado por la ruta que se utilizo en el constructor del ejemplo. Sin embargo, esta clase también tiene otro constructor donde se le puede pasar un Stream que tengamos creado en lugar de la ruta, como se ve a continuación:

El complemento del objeto StreamWriter es el objeto StreamReader, cuyo principal objetivo es facilitarnos las tareas de lectura de cadenas de caracteres. Con este objeto, nos podemos despreocupar de esas tareas de bajo nivel para poder obtener un código mucho mas limpio y fácilmente legible.

En el ejemplo se ve como fácilmente se puede leer información de un archivo de texto utilizando el método ReadLine del objeto StreamReader. Este método, simplemente lee la línea siguiente teniendo en cuenta la posición actual del puntero del archivo.

Es importante aclarar que utilizando los streams vistos hasta el momento se pueden leer y escribir en archivos de texto cadenas de caracteres, es decir, texto plano. Esto implica que la información escrita en los archivos podrá ser vista y entendida por cualquier persona, ya que se guarda tal y como se encuentra en un principio.

Lo anterior puede llegar a ser un problema en los casos en que se elige utilizar archivos de texto como repositorio de datos de una aplicación (aunque esto es poco recomendable, habrán casos en los pueda llegar a ser necesario), y digo que es un problema porque podría haber información que no queremos que cualquier persona la pueda ver y mucho menos entender, sino que quisiéramos que dicha información estuviera almacenada de forma segura.

Una posible opción para esto es almacenando la información en formato binario, es decir, que la información estará almacenada no en formato de texto plano sino en su representación binaria (1s y 0s), lo cual permite tener mas privacidad (OJO, solo mas privacidad, no mucha privacidad ni seguridad. Si el punto fuera como obtener una forma segura de almacenar información tendríamos que mirar los temas de cifrado y hashing). En .NET, el objeto que nos facilita trabajar con Stream de datos binarios es el BinaryWriter y el BinaryReader, los cuales supongo pueden deducir como se utilizan según lo visto anteriormente.

El primero permite escribir datos en un archivo de texto en formato binario mediante el método Write(), el cual.tiene varias sobrecargas entre los cuales acepta varios tipos de dato como por ejemplo int, long, bool, double, decimal, char, string. El segundo permite recuperar información almacenada en formato binario por medio del método indicado. Como así que por medio del método indicado?. Lo que sucede con el BinaryReader es que no tiene un método Read genérico, sino que tiene un Read para cada tipo de dato que puede ser escrito, por ejemplo ReadInt32, ReadBoolean, ReadChar, etc. Esto nos obliga a conocer la estructura del archivo con el que estamos trabajando para poder leer el tipo de dato correcto en la posición correcta.

A continuación se muestra un pequeño ejemplo sobre como utilizar el BinaryReader y el BinaryWriter.

En el ejemplo anterior se observa como se puede escribir varios tipos de dato con el mismo método Write del objeto BinaryWriter ya que tiene varias sobrecargas.

A continuación se muestra como se vería la información en el caso de intentar visualizarla con un editor de texto:

Para leer información binaria se utiliza el objeto BinaryReader y se utiliza “El método indicado”.

En el ejemplo anterior se observa como se utiliza el método de lectura según el tipo de dato que desee leer, lo cual implica que con anterioridad se conozca la estructura del archivo. En este caso, nótese que se leyó exactamente en el mismo orden en el que se escribió la información con el BinaryWriter.

El siguiente es el resultado de la ejecución del código anterior:

Con un tipo de dato especifico?. Si así es, porque a diferencia de las colecciones no genéricas en las que se pueden agregar cualquier tipo de elementos y todos son convertidos a System.Object, en este tipo de colecciones solo es posible almacenar elementos de un tipo de dato específico.

Cuando comencé a leer sobre esta nueva característica ofrecida por el Framework 2.0, me preguntaba si el nombre verdaderamente correspondía a la definición de estas colecciones, ya que no entendía el porque llamarlas genéricas si solo era posible almacenar datos del mismo tipo. Por el contrario, parecían ser más genéricas las otras colecciones (las del namespace System.Collections) ya que me permitían almacenar cualquier tipo de dato.

Pero finalmente y después de leer varios artículos y códigos de ejemplo, comprendí el porque del nombre generics y espero poder transmitirlo en este post.

Definitivamente, una colección genérica solo puede almacenar datos de un tipo, pero dicho tipo de dato es definido por nosotros mismos al momento de declararla e instanciarla. Es decir, no hay una clase para diferenciar las colecciones que operan con enteros de las que operan con cadenas de texto ni de las que operan objetos de tipo Empleado (por ejemplo). Absolutamente todas están definidas en la misma clase, lo único que las diferencia es la manera en que se instancia y se declara cada una de ellas. Ese es el secreto del ser genérica. Para entender mejor el concepto de la colección genérica, veamos el siguiente ejemplo:

En el ejemplo se observa la implementación de la colección genérica List, que es la versión genérica del ArrayList tratado en un post anterior. Se puede deducir que la primera colección permitirá almacenar únicamente datos de tipo int, que la segunda almacenara solo cadenas de texto y que la última almacenara objetos de tipo TablaDatos, el cual es un tipo definido en una clase aparte. En las definición de las tres colecciones se utilizo la clase List, es decir, que hay una clase “genérica” capaz de trabajar con el tipo de dato que indiquemos al momento de inicializarla. (Realmente no es cualquier tipo de dato, sino los tipos de datos soportados por la clase).

La diferencia para inicializar una clase genérica de una clase no genérica, es que en la primera se debe utilizar una parámetro adicional después del nombre de la clase y entre los caracteres < y >. Este parámetro debe ser un tipo de datos, que indica el tipo de datos con el que la colección deberá operar.

Así como esta la colecciones List<T>, que es la versión genérica del ArrayList, también existen las colecciones genéricas Stack<T>, Queue<T> y Dictionary<T>, entre otras que son las versiones genéricas de las clases Snack, Queue y HashTable respectivamente.

Un ejemplo de la clase genérica de Stack seria:

Se puede ver como se define una pila en la que únicamente se pueden almacenar datos de tipo entero, lo cual me permite obtener datos de la colección y tratarlos directamente como enteros sin necesidad de hacer algún tipo de cast, lo cual no seria posible con las colecciones no genéricas ya que el elemento es almacenado como un System.Object.

El hecho de que las colecciones genéricas operen con un tipo de dato definido en el momento de su declaración, las hace mucho más eficientes, ya que evita tener que realizar boxing, unboxing y casting de objetos. Adicionalmente los desarrolladores, obtienen un mayor grado de control sobre la información almacenada en la colección ya que en caso de intentar ingresar un objeto de un tipo de dato diferente al establecido en la inicialización de la colección, se arroja una excepción.

Además de esta ventaja que nos brindan las colecciones genéricas, tenemos la posibilidad de crear nuestras propias clases y métodos genérico cuyo comportamiento estará ligado al tipo de dato que se utilice al utilizarlo tal y como sucede con las colecciones. Para lograr esto debemos hacer uso de los “type parameters”, los cuales permiten establecer un parámetro cuyo tipo se desconocerá hasta que se indique en la declaración.

Para comprender mejor el funcionamiento de los “type parameters” que nos permiten crear clases genéricas, he desarrollado una aplicación de muestra que consiste en una clase impresora “genérica”, que es capaz de almacenar en una cola, objetos de un tipo específico (del tipo que se define al momento de definir un objeto de esta clase). Adicionalmente expone un método “imprimir” que se encarga de imprimir en pantalla cada uno de los valores contenidos en la cola. A continuación presento los fragmentos principales del código.

En esta primera imagen, se observa como se ha definido una clase Impresora genérica. Note que en este caso se utiliza la letra T para representar el “type parameter”, sin embargo es posible utilizar cualquier letra o palabra. Mediante este parámetro estamos indicando que al momento de definir e instanciar un objeto de tipo Impresora, se debe pasar como parámetro entre < y > el tipo de datos con el que se desea trabajar.

En el constructor de esta clase, se puede ver como la Queue genérica que tiene la clase Impresora como atributo toma su mismo tipo de dato, es decir, si al crear la clase Impresora indicamos el tipo de dato int, la Queue también tomara el tipo de dato int.

En esta segunda imagen se observa una propiedad que retorna una cola genérica, pero el type parameter para indicar que es una Queue genérica es el mismo utilizado en nuestra clase Impresora, lo cual indica que retornara una Queue del tipo de dato utilizado en la clase.

Finalmente se observa el método imprimir, cuyo objetivo es indicar el tipo de Queue que se esta imprimiendo y además mostrar cada uno de los elementos que contiene.

Como paso final, para comprobar el funcionamiento de la clase Impresora, se crea un objeto de tipo Impresora de enteros, así:

Otra de las ventajas que nos brinda la utilización de Generics, es que los “type parameters” se traducen en tiempo de compilación, lo cual implica que es posible darnos cuenta en el momento que desarrollamos nuestra aplicación, el tipo de datos con el que se esta trabajando en cada instancia de la clase Impresora, como se ve a continuación:

Finalmente, se observa el resultado de la ejecución de la aplicación en consola:

En conclusión, debemos utilizar las colecciones genéricas tanto como sea posible en lugar de utilizar las colecciones no genéricas, ya que las primeras incrementan el rendimiento de la aplicación ya que evita un sin numero de casting, boxing y unboxing lo que permite realizar un mejor manejo de la memoria y procesamiento.

Además podemos crear propias clases y/o métodos genéricos para aumentar la flexibilidad y la posibilidad de reutilizar nuestro código.

]]> http://developmania.wordpress.com/2008/10/07/colecciones-de-datos-en-cnet-parte-v-colecciones-genricas/feed/ 10 fzapataramirez clip_image002 clip_image004 clip_image006 clip_image008 clip_image010 clip_image012 clip_image014 http://developmania.wordpress.com/2008/09/14/colecciones-de-datos-en-cnet-parte-iv-hashtable/ http://developmania.wordpress.com/2008/09/14/colecciones-de-datos-en-cnet-parte-iv-hashtable/#comments Sun, 14 Sep 2008 14:21:28 +0000 fzapataramirez http://developmania.wordpress.com/2008/09/14/colecciones-de-datos-en-cnet-parte-iv-hashtable/ ]]> Una tabla hash o Hash Table, es una colección que permite almacenar pares de objetos, donde el primero es conocido como llave (key) y el segundo es conocido como valor (value). De esta manera, para agregar “un” elemento a la colección, siempre se debe pasar como argumento estos dos objetos.

Una de las ventajas que presenta ésta colección frente a las colecciones mencionadas anteriormente (Parte I: Vectores, Parte II: ArrayList, Parte III: Stack y Queue), es el poco tiempo que tarda en realizar la búsqueda de un elemento determinado, debido a que utiliza el hash de las llaves (keys) para ordenar los elementos, permitiendo así, tener una ubicación única para cada uno.

Un Hash consiste en pocas palabras, en un código único generado por una función Hash, la cual genera una salida única para entradas diferentes y además, produce la misma salida para entradas iguales. Por estas características de una función Hash, no pueden haber llaves iguales en la tabla Hash ya que esto produciría el mismo Hash y no seria posible diferenciar unívocamente los elementos de la colección.

El comportamiento de la HashTable se puede comparar a una tabla de una base de datos relacional, donde cada tabla generalmente (en este caso obligatoriamente) tiene una llave primaria por medio de la cual se diferencia cada registro de los demás y que además su valor debe ser único en toda la tabla. De la misma manera se comporta la HashTable ya que los elementos son ordenados según su Hash.

Cuando sea necesario obtener uno de los elementos contenidos en la HashTable, se debe utilizar la llave o key con la que fue almacenada, como se muestra a continuación:

Siempre que se referencia la HashTable utilizando una Key, será retornado el valor correspondiente a dicha clave en un objeto de tipo Object, por lo que es importante convertir el dato obtenido al tipo de dato adecuado para evitar generar excepciones.
Lo anterior, permite tener en la colección pares de llaves y valor que pertenezcan a tipos de datos diferentes, es decir, nada nos obliga a que todos los elementos del HashTable sean del mismo tipo. Incluso las llaves (keys) y los valores (values), pueden ser de tipos de datos diferentes entre si. Sin embargo, no es muy recomendable utilizar la HashTable de esta manera, ya que eso implicaría conocer exactamente que elementos están incluidos en la HashTable e implicaría tener mucho mas cuidado a la hora de extraer los datos, lo cual impediría que la aplicación sea flexible y escalable.

En el ejemplo anterior se ve como se puede ingresar llaves y valores de diferentes tipos de datos. Además se puede ver como es posible ingresar un valor de tipo null, lo cual no es posible hacerlo en una de las llaves ya que se generaría la excepción ArgumentNullException.

Utilizando la sintaxis “[key]” (por ejemplo: tabla["llave texto"]) sobre una tabla Hash, es posible actualizar el valor contenido o en caso de que la llave utilizada no exista en la tabla, se inserta este nuevo elemento.

La clase HashTable pertenece al espacio de nombres System.Collections e implementa las colecciones IEnumerable, ICollection, entre otras. Debido a esto, es posible utilizar la instrucción foreach para leer datos de una HashTable. Sin embargo, en cada iteracion de esta instrucción, se debe operar con un objeto de tipo DictionaryEntry que contendrá un par llave/valor.

Algunos de los métodos mas utilizados de la clase HashTable son:

Add: permite agregar un nuevo par llave/valor a la colección.

Remove: permite quitar un par llave/valor de la colección

ContainsKey: permite saber si la colección contiene un par cuya clave sea la que se le pasa como parámetro.

ContainsValue: permite saber si la colección contiene un par cuyo valor sea el que se le pasa como parámetro.

En algunas ocasiones, es importante tener un control sobre el orden en que los elementos son ingresados y obtenidos de la colección. Por esta razón existen las colecciones Stack y Queue. Como se menciono anteriormente, en estas colecciones NO es posible acceder aleatoriamente mediante índices a sus elementos, sino que es necesario utilizar un método encargado de extraer un elemento a la vez. Pero cual elemento?. Precisamente en la respuesta a esa pregunta radica la diferencia entre estas dos colecciones.

La pila (Stack), es una colección en la que todo nuevo elemento se ingresa al final de la misma, y únicamente es posible extraer el ultimo elemento de la colección. Por este comportamiento, el Stack es conocido como una colección LIFO (Last Input Fisrt Output) ya que siempre el ultimo elemento ingresado a la colección, será el primero en salir. Quizás la mejor manera de recordar el comportamiento de un Stack, es asociándolo con una “pila” de platos en donde cada plato esta encima del otro y en caso de querer ingresar un plato a la pila, lo que se debe hacer es ponerlo encima del ultimo plato. Luego cuando se quiere sacar un plato de la pila, solo podemos coger el ultimo plato.

La cola (Queue), tiene el comportamiento contrario a la pila. Todo nuevo elemento se agrega al principio de la colección y solo se puede extraer el ultimo elemento. Por esta razón, la cola se conoce como una colección FIFO (Fisrt Input First Output) ya que el primer elemento que ingresa a la cola es el primer elemento que sale. Para recordar este comportamiento se puede asociar la Queue con la fila que se debe hacer en un banco para realizar una consignación. En ese caso, el cajero atiende en el orden en que llegan las personas a la cola.

Las colecciones Stack y Queue se encuentran en el espacio de nombres System.Collections como todas las colecciones no genéricas.

Para implementar cada una de ellas se debe utilizar la clase Stack y Queue respectivamente y utilizar sus métodos que ofrecen la posibilidad de agregar elementos a la colección y extraer elementos según el comportamiento de la colección que se este utilizando.

Como se ve en la figura anterior, para agregar elementos a una pila se debe utilizar el método Push que recibe como parámetro un Object. Mientras que en la cola se debe utilizar el método Enqueue (encolar). Ambos métodos, incrementan automáticamente la capacidad de la colección.

Para obtener un elemento de la colección, contamos con dos opciones diferentes:

1. Obtener el elemento indicado según el comportamiento de la colección sin quitarlo de la colección. Esto se logra mediante el método Peek de cada colección.

2. Obtener un elemento de la colección, quitándolo de la misma. Esto se logra mediante el método Pop de la pila (Stack) o el método Dequeue de la cola (Queue).

Ejemplo del Stack:

Resultado:

Ejemplo del Queue:

Este par de colecciones deben ser usadas cuando nos interesa tener control sobre el orden en que los elementos son obtenidos de las mismas. La pila se debe usar cuando queremos obtener los elementos en el orden inverso al cual fueron ingresados. Mientras que la cola debe ser utilizada cuando queremos obtener los elementos en el mismo orden que fueron ingresados.

]]> http://developmania.wordpress.com/2008/08/29/colecciones-de-datos-en-cnet-parte-iii-stack-queue/feed/ 11 fzapataramirez image image image image image http://developmania.wordpress.com/2008/08/23/colecciones-de-datos-en-cnet-parte-ii-arraylist/ http://developmania.wordpress.com/2008/08/23/colecciones-de-datos-en-cnet-parte-ii-arraylist/#comments Sat, 23 Aug 2008 21:01:35 +0000 fzapataramirez http://developmania.wordpress.com/2008/08/23/colecciones-de-datos-en-cnet-parte-ii-arraylist/ ]]> Esta es una clase que representa una lista de datos. Es bastante parecida a la colección explicada anteriormente, con la diferencia que el ArrayList puede aumentar o disminuir su tamaño dinámicamente de una manera eficiente.

Con un array de datos no era posible aumentar la capacidad del vector ya que dicho parámetro es especificado en el momento de crear la instancia del objeto. El ArrayList a diferencia, brinda la posibilidad de aumentar o disminuir su tamaño dinámicamente según sea necesario.

Para crear una instancia de este objeto, se debe utilizar la clase ArrayList incluida en el espacio de nombre System.Collections como se muestra a continuación.

ArrayList arrayList=new ArrayList();

El constructor de la clase ArrayList acepta también un parámetro tipo entero que indica la capacidad inicial del objeto que se esta creando.

Si es necesario agregar un objeto a la colección, se debe utilizar el método Add, el cual inserta el nuevo elemento en la última posición, o el método Insert el cual lo inserta en la posición indicada.

Todos los objetos almacenados en un Arraylist son tratados como objetos, por lo tanto es posible agregar todo tipo de datos, es decir, se puede agregar enteros, cadenas de texto, objetos de clases propias, etc. Y a diferencia de los array vistos en la parte I, no todos los elementos deben ser del mismo tipo de dato. Esto en algunas ocasiones puede ser una ventaja ya que permite almacenar gran variedad de información en una sola colección, sin embargo, por razones de rendimiento (cast, boxing, unboxing), hay ocasiones en las que es preferible utilizar las colecciones genéricas que serán tratadas mas adelante.

Si es necesario quitar elementos de la colección, se debe usar el método remove, removeAt o RemoveRange, los cuales eliminan el objeto pasado como parámetro, o un elemento en una posición especifica, o un grupo de elementos respectivamente.

Las propiedades mas utilizadas de esta colección son : Count y Capacity. La primera sirve para conocer la cantidad actual de elementos que contiene la colección. La segunda indica la capacidad máxima actual de la colección para almacenar elementos. Es necesario tener presente que la capacidad de la colección, aumenta en caso de ser necesario al insertar un elemento, con lo que se garantiza el redimensionamiento automático.

La capacidad de una colección nunca podrá ser menor a la cantidad total de elementos contenidos, por lo que si se modifica manualmente la propiedad Capacity y se le asigna un valor menor que el valor devuelto por la propiedad Count, obtendremos una excepción de tipo ArgumentOutOfRangeExcepetion .

A continuación se muestra un ejemplo del uso de estas propiedades:

Para acceder a los elementos contenidos por la colección se puede hacer mediante el uso de índices o mediante la instrucción foreach.

Determinar que tipo de colección usar en un caso especifico, es tarea del desarrollado y se debe evaluar las condiciones para determinar la manera mas eficiente de administrar los recursos. Si es un escenario donde no conocemos el tamaño que tendrá la colección y si además será muy probable que el tamaño varíe, entonces será recomendable bajo todas las demás circunstancias usar un ArrayList en lugar de un array debido a que el ArrayList brinda la posibilidad de redimensionarlo automáticamente. Sin embargo, para escenarios donde se conoce de antemano la cantidad total de elementos a almacenar y si todos son del mismo tipo, se debe usar el array convencional ya que los objetos son almacenados en su tipo de datos nativo y no es necesario hacer conversiones.

La plataforma .NET ofrece una gran variedad de colecciones que debemos conocer y saber utilizar para emplear la mas indicada en nuestras aplicaciones y obtener así el mejor rendimiento posible tanto en procesamiento como en manejo de memoria. A continuación se explican algunas de las colecciones incluidas en el lenguaje C#.NET.

La clase Array, contenida en el namespace System, provee toda la funcionalidad necesaria en las colecciones para manipular los datos. Esta es una clase abstracta, por lo cual no es posible crear instancias de la misma, sino que sirve como clase base (de la que otras clases heredan) para las demás clases que representan colecciones en .NET

La colección mas sencilla que utiliza como clase base System.Array, es lo que se conoce comúnmente como vector. Para definir un vector, debemos tener claro que tipo de dato queremos que nuestro vector almacene y la cantidad de valores que deseamos almacenar ya que son requisitos indispensables para la definición y creación de vectores.
En C#, un vector se define con un par de corchetes [] después del tipo de dato, como se muestra a continuación.

Sin embargo, para hacer uso de nuestro vector, debemos primero crear la instancia declarando cuantas posiciones máximas tendrá, como se muestra a continuación:

Luego de esto, podremos almacenar tantos datos del mismo tipo como posiciones tenga el vector. Por ejemplo en la variable booleanos se podrá almacenar hasta 3 variables de tipo bool y en la variable texto se podrá almacenar hasta 100 variables de tipo string.
Es importante tener en cuenta que la primera posición de un vector es la posición 0, por lo cual si la longitud es de 5, las posiciones van desde la 0 hasta la 4.

Para almacenar información en un vector, solo debemos hacer referencia a la posición del vector donde deseamos almacenarla y utilizar el operador de asignación (=).

En el ejemplo anterior, se han almacenado 4 cadenas de texto (strings) en el vector texto declarado e instanciado anteriormente. Cada string se ha almacenado en una posición del vector diferente. En caso de almacenar un string en una posición donde ya se había almacenado anteriormente algo, el valor antiguo será sobrescrito por el nuevo valor.

A continuación se almacena en cada posición restante del vector una cadena de texto mediante un operador de control de flujo (for). Este operador es posible utilizarlo con todas las colecciones en .NET ya que todas son enumerables debido a que implementan la interface IEnumerable.

Un vector puede tener mas de una dimensión según sea necesario. Un vector de dos dimensiones es considerado una matriz de datos.
Para definir un vector de mas de una dimensión, se utiliza el carácter ‘,’ en los corchetes de la definición del mismo.

int [] a =new int[2]; //Una dimensión

int [ , ] a = new int [2,3]; //Dos dimensiones

int [ , , ]a = new int[2,3,4]; //Tres dimensiones

Las propiedades mas importantes que exponen los vectores se presentan a continuación:

Length: Indica la longitud total del vector (En todas las dimensiones).

Rank: Indica el numero total de dimensiones del vector.

Para obtener la longitud total de un determinada dimensión, se debe utilizar el método GetLength que recibe como parámetro un entero indicando el índice de la dimensión de la cual se desea conocer la longitud (La primera dimensión tiene como índice 0).

Aunque es posible crear vectores de mas de una dimensión, no es recomendable utilizar mucho esta técnica en las aplicaciones ya que la complejidad de nuestro algoritmo se incrementa considerablemente, teniendo en cuenta que el numero de iteraciones necesarias para recorrer todas las posiciones del vector aumenta de manera exponencial en función del numero de dimensiones. Generalmente el numero máximo de dimensiones que se utiliza en un vector es 2 cuando se necesita trabajar con matrices de datos.

A continuación se muestra un ejemplo de una matriz de datos:

Otra de las colecciones que se pueden crear con los vectores es un jagged array o en español un array de arrays. Se puede pensar en un jagged array como un vector de una dimensión, donde en cada posición en lugar de almacenar un tipo de dato especifico, almacena otro vector.

En esta imagen se ilustra gráficamente como se vería un jagged  array. En este ejemplo, se tiene un vector exterior de 4 posiciones y en cada una de las posiciones almacena un vector también de 4 posiciones. No es obligación que todos los vectores sean de la misma longitud.

Para declarar un array de arrays en C#, se debe utilizar la siguiente sintaxis:

int [][] jagged;

Para instanciar un jagged array se debe indicar el numero de posiciones que tendrá el vector contenedor, como se hace con un vector normal de una dimensión.

int [][] jagged = new int[3][];

En el ejemplo anterior se ha definido un array de tres posiciones, donde se almacenara en cada una de ellas, un array de enteros (indicado por el segundo par de corchetes). Luego de inicializar el vector contenedor, podremos crear los vectores internos como se muestra a continuación:

Igualmente se puede crear un array de arrays de varias dimensiones, donde cada vector almacenado tendrá 2, 3 o mas dimensiones según sea necesario.

Sin embargo, la complejidad en este caso aumenta bastante y se debe buscar siempre obtener el mejor rendimiento posible en nuestras aplicaciones, por lo tanto estas colecciones complejas deben ser utilizadas únicamente cuando sea necesario y cuando ninguna de las colecciones disponibles en la plataforma .NET es suficiente para almacenar la información.

En un próximo post explicare otra colección básica.

Suerte !!!.