lunes, 31 de enero de 2011

Como usar XStream en Java


XStream es una interesante y simple libreria para serializar objetos a XML y viceversa.


Caracteristicas de XStream
  • Fácil de usar. Cuenta una fachada de alto nivel que simplifica los casos más comunes de uso.
  • No requiere homologaciones “mappings”. La mayoría de los objetos se puede serilizar sin necesidad de crear archivos de homologación o “mapping”.
  • Rendimiento. Velocidad y bajo consumo de memoria son parte esencial del diseño, lo que hace que XStream sea adecuada sistemas con grandes objetos o alta demanda de envío de mensajes.
  • XML Limpio. XStream usa “reflection” y crea archivos XML facilmente entendibles por humanos y más compactos que usando la serialización nativa de Java.
  • No requiere modificar los objetos. Se serializan los campos internos, incluyendo privados y finales. Las clases internas y no publicas son soportadas. No se requiere que las clases tengan un constructor por defecto (sin parametros).
  • Soporte completo para objetos complejos. Las referencias duplicadas (duplicate references) encontradas en el objeto se mantienen. Soporta referencias duplicadas (circular references).
  • Integración con otras API de XML. Implementado un interfaz, Xstream puede serializar directamente hacia/desde cualquier estructura de arbol (tree structure) no sólo XML.
  • Estratégias de conversión personalizables. Las estrategias de conversión se pueden registrar permitiendo personalizar como los tipos son representados en XML.
  • Mensajes de error. Cuando una excepción, por XML mal formado, es encontrada se provee un diagnostico detallado para ayudar a encontrar y solucionar el problema.
  • Formato se salida alterno. El diseño modular permite otros formatos de salida. Xstream tiene actualmente soporte para JSON.


Manos a la obra:
Pueden consultar el tutorial de dos minutos en el cual me estoy basando para este post, con algunos detalles adicionales.

Estoy omitiendo los constructores y métodos para ahorrar espacio ;-)
Supongamos que tenemos los siguientes POJOs (Plain Old Java Object) :

ejemplo 1 - pojos
public class PhoneNumber {
  private int code;
  private String number;
  // ... constructores y métodos 
}
public class Person {
  private String firstname;
  private String lastname;
  private PhoneNumber phone;
  private PhoneNumber fax;
  // ... constructores y métodos
}

El siguiente es un ejemplo de como serializar un objeto tipo Person:

ejemplo 2 - usando XStream
XStream xstream = new XStream();
//[1] alias opcionales
xstream.alias("person", Person.class);

Person joe = new Person("Joe", "Walnes");
joe.setPhone(new PhoneNumber(123, "1234-456"));
joe.setFax(new PhoneNumber(123, "9999-999"));
String xml = xstream.toXML(joe);

ejemplo 2.1 - contenido de la variable xml

    Joe
    Walnes
    
      123
      1234-456
    
    
      123
      9999-999
    
  

Para convertir de XML a un objeto java:

ejemplo 2.2 - xml a java.
//usamos la variable xml del ejemplo 2
Person newJoe = (Person)xstream.fromXML(xml);

En el siguiente post hablaré sobre las Anotaciones en XStream.


[Notas]
1 Sino agregamos los alias opcionales el código aun funcionará pero los etiquetas de los elementos contendrán el nombre completo de cada clase (fully qualified name).

Jetty Vs Tomcat

Una interesante comparación entre Tomcat y Jetty

viernes, 28 de enero de 2011

Como sincronizar gmail con un smartphone

El otro día estaba pensando sobre como sincronizar mi celular con mi cuenta de google, para tener un respaldo de mis contactos, tener mi agenda al día con google calendar y leer mis correos desde el celular, es decir estar en línea aun cuando estoy lejos de la oficina o la casa.

Buscando un poco en Internet encontré varias alternativas para acceder desde el celular y me llamó la atención google sync el cual es bastante simple de configurar siguiendo estas instrucciones.

Esta guía funciona con un Sory Ericsson Satio (Idou) pero si alguien tiene otro dispositivo de diferente y/o de otro fabricante puede consulta el siguiente enlace.

Requerimientos:
  1. Celular con plan de datos (conexión a Internet), en mi caso un SE Satio.
  2. Una aplicación con soporte para el protocolo Microsoft® Exchange ActiveSync® ya que es el que usa Google Sync. En mi caso la usaré la aplicación RoadSync pre-instalada en el celular.
  3. Una cuenta en gmail.
Procedimiento:
  1.  Iniciamos RoadSync y configuramos los parámetros de acuerdo a las siguientes instrucciones.
  2. En RoadSync tenemos la opción de sincronizar: correo electrónico, calendario, contactos y tareas, lastimosamente de acuerdo a la documentación de Google sync actualmente no está soportado sincronizar las tareas así que solo puedo activar las otras tres opciones.
  3. Tenemos la opción de programar la sincronización en un horario fijo (por ejemplo el horario de oficina), cada cierto tiempo o dejarla manual. Aquí cada quien elige lo que más le convenga.

miércoles, 26 de enero de 2011

Aplicación para twitter Beispanama

Recientemente me enteré que un colega y amigo creó y liberó el código e una pequeña aplicación para Twitter para que los fanáticos del béisbol en Panamá podamos mostrar nuestro apoyo a nuestro equipo favorito.

Felicito a @demogar por su trabajo e iniciativa de liberar el código para que otros podamos aprender de El.

Vale la pena mencionar que la aplicación fue publicada en un sitio de noticias local, más información aquí.

Beispanama fue diseñada y desarrollada por @demogar.
Código liberado en GitHub y Bitbucket bajo licencia WTFPL.
Made in Panama, ¡carajo!.

viernes, 21 de enero de 2011

http://admios.blogspot.com/2011/01/18-digit-case-safe-id-on-salesforcecom.html

Today while doing a small test to check a Salesforce's API client I noticed that several objects returned by the API, has IDs of 18 characters which I found strange since they are supposed to be 15 letters and numbers, according to the API's documentation.

For reference, an excerpt of the official documentation of salesforce:
ID Field Type

With rare exceptions, all objects in the API have a field of type ID that is named Id and contains a unique identifier for each record in the object. It is analogous to a primary key in relational databases...

ID fields in the Salesforce.com user interface contain 15-character, base-62, case-sensitive strings. Each of the 15 characters can be a numeric digit (0-9), a lowercase letter (a-z), or an uppercase letter (A-Z). Two unique IDs may only be different by a change in case.

With the aim of understanding why the ID returned by the API contain more than 15 characters did a little research and found the following:
Because there are applications like Access which do not recognize that 50130000000014c is a different ID from 50130000000014C, an 18-digit, case-safe version of the ID is returned by all API calls. The 18 character IDs have been formed by adding a suffix to each ID in the Force.com API. 18-character IDs can be safely compared for uniqueness by case-insensitive applications, and can be used in all API calls when creating, editing, or deleting data.

If you need to convert the 18-character ID to a 15-character version, truncate the last three characters. Salesforce.com recommends that you use the 18-character ID.

Conclusion.
So in essence, to prevent problems for those situations when case sensitive differences are not detected the API is returning 18-digits case-safe version of the ID.

Hope this is useful to any of you.
My original post