La aplicación o framework que sirve como esqueleto para gvSIG es _fwAndami (framework Andami). Tiene varias funciones:

• Lanzar la aplicación.
• Cargar los plugins y sus respectivas extensiones.
• Gestionar las traducciones.

Ofrecer servicios a los plugins para la gestión y carga de dependencias, manejo de ventanas, algunas utilidades para lanzar tareas en background, etc.

Las librerías comunes a toda la aplicación se encuentran en el directorio lib, y podemos destacar log4j (registro de incidencias), xerces (gestión de xml), castor (se emplea para leer el xml del proyecto), gvsig-i18n (traducciones), beans (componentes gráficos comunes), iver-utiles (clases útiles genéricas).

Dentro de Andami podemos encontrar una serie de clases que nos pueden ser de utilidad para nuestras extensiones. Por ejemplo:

La clase com.iver.andami.Launcher.java es el punto de entrada a la aplicación, y a pesar de ser bastante compleja, a veces no queda más remedio que poner algún punto de ruptura dentro de ella para buscar porqué una determinada extensión lanza alguna excepción inesperada.

A la hora de trabajar con nuestras propias extensiones, seguro que necesitamos emplear muchas veces la clase com.iver.andami.PluginServices. Como su propio nombre indica, es una clase que da servicio a los plugins, ofreciendo métodos estáticos como:

• getMainFrame() => la ventana principal de la aplicación
• getMDIManager() => a través de esta clase, tenemos acceso a la ventana activa (PluginServices.getMDIManager().getActiveWindow()), cosa que emplearemos contínuamente en los métodos isEnabled e isVisible de todas las extensiones. También se emplea para añadir una nueva ventana, y alguna cosita más.
• getDlgPreferences() => Obtienes el diálogo común de preferencias, donde se registran todas las configuraciones de los plugins.
• getArguments() => Recuperas los argumentos por línea de comandos. Por ejemplo, es muy útil para abrir un proyecto por línea de comandos.
• getExtension(Class) => Con esta llamada puedes obtener una instancia de la extensión que ejecuta esa clase. Si la llamada se hace en el método initialize(), tendrás que estar seguro de que la extensión ya ha sido inicializada (cuidado con las dependencias).
• getText(Object, String) => Se usa para trabajar con los textos traducidos. A partir del plugin y una clave, obtienes la cadena en el idioma actual.
• registerKeyStroke(KeyStroke) => Sirve para fijar las teclas de acceso rápido globales.

Existen más métodos, pero los más habituales son los que hemos descrito.

Andami también es el responsable de gestionar un tema por defecto con los botones y aspecto genérico de la aplicación, lanzar la imágen de bienvenida de la aplicación (SplashWindow), y otras tareas que no vamos a detallar ahora porque normalmente no necesitarás tocar código de ahí.

Las ventanas en Andami se tratan como entidades genéricas. Es decir, que a priori, no hay una clase Swing en la que se apoye. El motivo es si algún día se decide cambiar el aspecto de la aplicación por completo.

El plugin que instancia realmente las ventanas es el proyecto libCorePlugin. En este plugin se definen las extensiones que enlazan la definición de menues, botones y ventanas con entidades reales Swing. En nuestro caso, optamos por utilizar la clase JInternalFrame como base para las ventanas de gvSIG. Al ser una aplicación MDI (Multiple Document Interface) parecía lo más adecuado.

Las ventanas en Andami se definen gracias al interfaz IWindow. Este interfaz es muy sencillo, solo obliga a implementar el método getWindowInfo(), que devuelve una clase WindowInfo donde se especifica el tamaño de la ventana, el título, y una serie de constantes que indican si la ventana será modal o no, resizable, o de tipo “paleta” (un tipo especial muy útil por ejemplo para mostrar información, o un conjunto de botones o herramientas (se dibuja siempre encima del resto de ventanas)).

Para ver cómo se añade una ventana dentro de Andami, lo mejor es ver un ejemplo:

PluginServices.getMDIManager().addWindow(symbolPanel);

donde symbolPanel es

public class PanelEditSymbol extends JPanel implements IWindow {

Vemos que las ventanas en gvSIG son en realidad subclases de JPanel que implementan el interfaz IWindow.

Cuando no queremos que se cree una ventana cada vez, sino que queremos reutilizar la ventana que hemos creado alguna otra vez, utilizamos el interfaz ISingletonWindow. Este interfaz añade un método (getWindowModel()) que se utiliza para no crear una ventana si ésta ya ha sido creada previamente. Por ejemplo, a la hora de pedir información, no queremos crear nuevas ventanas, solo volver a mostrar la que ya se había creado con anterioridad (para no tener que cerrar una ventana por cada click).

dlg = (DlgProvin) PluginServices.getMDIManager().addWindow(dlg);
for (int i=bs.nextSetBit(0); i >=0; i=bs.nextSetBit(i+1))
{
  long idRec = i;
  String nom = ds.getFieldValue(idRec, idField).toString();
  dlg.setProvinName(nom);
}

donde DlgProvin se define como:

public class DlgProvin extends JPanel implements IWindow, SingletonWindow {

y los métodos getWindowInfo

public WindowInfo getWindowInfo() {
  if (wi==null)
  {
      wi = new WindowInfo(WindowInfo.PALETTE);
      wi.setWidth(this.getPreferredSize().width);
      wi.setHeight(this.getPreferredSize().height);
      wi.setTitle("Provin Info");
  }
  return wi;

y getWindowModel:

public Object getWindowModel() {
  return "MyProvinDialog";
}

Actualmente, las ventanas en gvSIG se definen en libCorePlugin (la descripción en WindowInfo se utiliza para crear ventanas JinternalFrame). A veces puede ser útil saber que la ventana con la que trabajas es una JinternalFrame, pero también hay que tener cuidado con eso, ya que en futuras versiones (no está planificado ni a corto ni a largo plazo, pero es una posibilidad) se podría cambiar el tipo de ventana creada en libCorePlugin. Si necesitas ver con más detalle cómo se crean las ventanas, distinguir entre SingletonWindow y el resto, etc..., puedes poner un punto de interrupción en la clase com.iver.core.mdiManager.NewSkin.java, en la función addWindow.