Emacs es algo adictivo sin duda… a tal punto que a veces prefiero programar todo desde la línea de comandos en vez de usar un IDE como Eclipse o Netbans. En esta entrada, que sin duda es de esas que me sirve solo a mi y a unos pocos más, se detalla el proceso de compilación e instalación de aplicaciones para Android sin usar más que el SDK y una línea de comandos. Esta guía es aplicable para cualquier sistema operativo, pero yo lo haré en mi equipo que corre Funtoo Linux.

0. Configuración del entorno de trabajo

Lo primero es tener el SDK instalado, lo cual está explicado aquí: Introducción a la programación con Android. Una vez hayamos instalado y configurado el SDK (incluyendo la adición del directorio tools al path del sistema) y tengamos un proyecto que compilar podemos iniciar el proceso de compilación. Es posible también crear el proyecto desde la línea de comandos así:

Donde -t 1 es el id de la plataforma para la que vamos a desarrollar la aplicación (el target). Se puede usar el comando android list targets para ver el listado de targets disponibles. -p indica la ruta de creación del proyecto y -a el nombre de la actividad inicial.

1. Compilación

Es posible usar Ant para compilar y empaquetar todo automáticamente… pero me gusta hacer cada cosa y saber qué está pasando por debajo. Así que haremos todo manualmente. El siguiente comando generará el archivo R.java (si no sabes de lo que hablo: Introducción a la programación con Android):

• p = package
• -m -j src indicar el directorio de los archivos fuente
• -M indicar la ubicación del manifiesto
• -S indicar la ubicación del directorio de recursos
• -I $ANDROID_DIR/android.jar añade el paquete android.jar al classpath del proyecto. Importante: en mi caso $ANDROID_DIR apunta a /opt/android/platforms/android-4/ y en el path del sistema se encuentra incluido /opt/android/platforms/android-4/tools/ Es importante tener en cuenta que NO se usa la base del SDK como antiguamente se hacía, sino el correspondiente directorio bajo platforms.

Ahora sí vamos a generar los archivos .class (por supuesto, es necesario tener el JDK de Java instalado):

Esto básicamente genera archivos .class en el directorio bin. Si la aplicación usara librerías de terceros, se debería agregar el parámetro -classpath=libs/*.jar

Puesto que los archivos .class están generados para la JVM, es necesario convertirlos a archivos para la Dalvik VM:

Ahora empaquetamos los recursos:

Ahora empaquetamos usando los bytecodes de Dalvik que creamos (classes.dex) para generar el paquete final:

Finalmente podemos instalarlo tal como escribí en Manipulación de smartphones con Android desde la consola de Linux:

Links interesantes: How to build Android application package (.apk) from the command line using the SDK tools + continuously integrated using CruiseControl y Developing Android without Eclipse or Ant

Este es un pequeño tip mediante el cual les mostraré cómo capturar la pantalla de un smartphone corriendo Android. Para ello haremos uso del Dalvik Debug Monitor, que se incluye con el SDK de Android. Para instalar el SDK debes seguir los pasos que explico en esta entrada. Además, es necesario configurar la conexión USB del smartphone; si usas Linux deberás seguir estos pasos.

Una vez tengamos instalado y configurado el SDK, basta con conectar el móvil, abrir la herramienta ddms (que se encuentra dentro del directorio tools del SDK), y veremos algo como esto:

Ahora basta con seleccionar nuestro dispositivo en el panel izquierdo y presionar Ctrl+S (o ir al menu Device -> Screen capture…).  Veremos una ventana con la captura y tenemos la opción de guardar la imagen como PNG, por ejemplo:

¡Eso es todo ! Si tiene alguna duda o sugerencia, no dude en comentar.

Nota: Existe una aplicación creada por Koush que se ejecuta desde el Android y que permite hacer esto (más información aquí). El problema es que necesita privilegios de root en el smartphone

En esta entrada aprenderemos a manipular dispositivos móviles que tengan Android instalado a través de la consola en Linux. Esto es útil al momento de instalar aplicaciones, navegar entre los directorios del equipo, depurar las base de datos, etc. Además, no hay ningún fabricante de móviles (al menos que yo conozca) que proporcione herramientas para controlar los dispositivos desde Linux. En mi caso, tengo un HTC Tattoo el cual solo puede ser manipulado desde Windows usando HTC Sync

Con el HTC Tattoo y la mayoría de los smartphones con Android es posible usar la opción de almacenamiento en Linux sin ningún tipo de configuración especial. Simplemente se conecta el equipo, se ejecuta la aplicación Connect to PC y se selecciona Disk Drive con lo cual podremos acceder a la memoria SD. Pero, para realizar operaciones avanzadas necesitaremos seguir estos pasos:

1. Instalar el SDK de Android

La instalación y configuración de Android se explica en la anterior entrada: Introducción a la programación con Android.

2. Configurar el path del SDK

Para trabajar cómodamente con los comandos que nos proporciona el SDK, ejecutaremos el siguiente comando (reemplazando la ruta del SDK por la tuya):

echo "export PATH=$PATH:/ruta/del/sdk/tools"
source ~/.bashrc

3. Instalar la máquina virtual de Java

Recomiendo usar los instaladores de la página de Sun. También puedes hacerlo desde los repositorios de tu distro.

4. Crear una regla en udev

Debemos ahora crear una regla en udev para que al momento de conectar el dispositivo lo podamos usar con el SDK de Android. Así que creamos y editamos como root el archivo /etc/udev/rules.d/99-android.rules y dentro ponemos:

SUBSYSTEM=="usb", ATTRS{idVendor}=="0bb4", SYMLINK+="android_adb", MODE="0666"

Note que estoy usando el idVendor 0bb4 que es el correspondiente al HTC Tattoo. Para conocer el de su smartphone, debe conectarlo y usar el comando lsusb.

5. Conectarse al dispositivo

Conectamos el smartphone (sí, tenía que estar desconectado ), y seleccionamos la opción HTC Sync… por supuesto, vamos a obtener un error que dice que no encontró el HTC Sync en el PC… lo bueno es que con esto se activa el modo depuración del USB, el cual nos permitirá conectarnos desde la terminal de Linux. Primero debemos mirar si se reconoce el dispositivo ejecutando este comando:

Si todo sale bien, veremos algo como esto:

HT9A3LG11652 es el nombre de mi dispositivo; este nombre nos permitirá referenciarlo al momento de ejecutar comandos sobre el desde CLI de Linux. Veamos qué podemos hacer ahora que tenemos el smartphone conectado…

adb -s HT9A3LG11652 shell #ejecutar una shell
adb -s HT9A3LG11652 push archivo_local archivo_destino #copiar un archivo al smartphone
adb -s HT9A3LG11652 pull archivo_remoto archivo_local #copiar un archivo desde el smartphone
adb -s HT9A3LG11652 shell rm -r /system/sd/archivo #borrar archivos del smartphone
adb -s HT9A3LG11652 install nombre_aplicacion.apk #instalar aplicaciones
adb -s HT9A3LG11652 uninstall nombre.paquete #desinstalar aplicaciones

Eso es todo por ahora… cualquier duda, comentario o sugerencia es bienvenido. ¡Hasta la próxima!

Esta pequeña entrada servirá como base para las siguientes, en las que iré poniendo mis experiencias con Android, un estupendo sistema operativo para dispositivos móviles basado en Linux, y que nos proporciona un completo SDK para desarrollar nuestras propias aplicaciones de una manera rápida y divertida.

Aprenderemos a instalar/configurar el SDK y el plugin para Eclipse.  Haremos el típico Hola Mundo, y explicaré un poco sobre la metodología de programación para esta plataforma (que es sobre Java). ¡Manos a la obra!

1. Instalar y configurar el SDK de android

Vamos a la página del Android SDK y descargamos la versión para nuestro sistema operativo. Yo uso Gentoo Linux, pero los pasos son prácticamente idénticos en Windows y en Mac. La última versión al escribir esta entrada es android-sdk_r05. Una vez que hayamos descargado el archivo, lo descomprimimos, entramos a la carpeta que se crea y ejecutamos (en Linux):

En Windows:

Veremos algo como esto:

Hacemos clic en Available packages y desplegamos el árbol que aparece bajo Sites, Packages and Archives para instalar el API sobre la(s) que deseamos trabajar, y una vez la(s) hayamos seleccionado hacemos clic en Install Selected. En este caso he seleccionado el API 7 (para la versión 2.1 de Android), la documentación del API 7, los ejemplos del API 7 y el SDK del API 4 (para la versión 1.6 de Android). Es importante elegir las APIs adecuadas teniendo el cuenta el tipo de dispositivo para el que estamos desarrollando la aplicación. Escogí en este caso el API 4 puesto que el equipo sobre el que pruebo los programas (HTC Tattoo) viene con Android 1.6 (Donut) [más información sobre las versiones y sus codenames]. Por supuesto, si desarrollas con el API 4 tus programas tienen un 98% de probabilidades de correr sobre las versiones más recientes de Android sin modificación alguna.

Una vez haya terminado de descargar e instalar las APIs podemos crear un dispositivo virtual sobre el que probaremos nuestras aplicaciones. Hacemos clic en Virtual Devices al lado izquierdo, luego sobre el botón New… y configuramos el dispositivo:

Como puede apreciar en la imagen de arriba, debe poner un nombre al dispositivo, seleccionar el API sobre el que va a trabajar, darle un tamaño a la memoria ROM, escoger un tipo de pantalla y algunas configuraciones avanzadas que no se tratarán en este tutorial. Una vez tengamos esto, hacemos clic en Create AVD y si todo sale bien veremos algo como esto:

2. Instalar y configurar el plugin para Eclipse

Para este paso, necesitaremos Eclipse 3.5 (Galileo, recomendado) o 3.4. Abrimos eclipse, vamos a la Window -> Install New Software…

Hacemos clic en el botón Add… para añadir el repositorio de Android (https://dl-ssl.google.com/android/eclipse/):

Clic en OK y ahora seleccionamos los plugins a instalar, y seguimos el proceso de instalación:

Una vez instalado, reiniciamos Eclipse y veremos que se han añadido algunos iconos extra en la barra de herramientas, y que además podemos crear proyectos para Android

3. Hola Mundo en Android

Ahora vamos a crear un nuevo proyecto y aprender un poco más sobre cómo funcionan las aplicaciones para Android.  Hacemos clic en el botón de creación de proyectos Android (o File… -> New Project -> Android Proyect):

Veremos el asistente de creación de proyectos para Android en donde debemos especificar: el nombre del proyecto (HolaParce), el API para el que vamos a desarrollar (1.6 en este caso), el nombre de la aplicación (Hola Parce en este caso), el nombre del paquete (se recomienda que sea un paquete nombrado con el estándar de Java, es decir, un dominio invertido), seleccionamos Create Activity y le damos un nombre (que cumpla las especificaciones de un nombre de clase en Java), y por último seleccionamos la versión mínima del API que deberán tener los dispositivos que corran nuestro aplicativo:

¡Clic en Finish y listo! Ahora podemos probar la aplicación… hacemos clic derecho sobre el Proyecto, seleccionamos Run as… -> Android Application. Se cargará el emulador y después de un par de minutos podremos ver nuestra aplicación:

4. Entendiendo el funcionamiento básico de las aplicaciones en Android

Las aplicaciones en Android funcionan bajo el esquema de “Actividades”. Una actividad presenta una interfaz gráfica (escrita en XML) que permite al usuario interactuar con la aplicación. Cada aplicación tiene varias actividades que se van mostrando al usuario según este las vaya necesitando. Una actividad llama a otra cuando sea necesario, y cada una de las actividades que se vayan mostrando se almacenan en una pila; es decir, cada vez que la aplicación lo requiera inserta una nueva actividad en la pila y, cuando esta ya no se necesite, se hace un push sobre esta lo cual deja en descubierto la actividad que estaba debajo. Importante leer esto para tener claro cada uno de los aspectos fundamentales de las aplicaciones Android.

Ahora, veremos detalladamente qué ocurrió en los pasos que seguimos arriba. Por ejemplo, al crear el proyecto se generan algunos archivos automáticamente. Veamos que hace cada uno de ellos…

Dentro del directorio res se han creado algunos subdirectorios:

• drawable-hdpi, drawable-mdpi, drawable-ldpi en donde se almacenan las imágenes que va a utilizar nuestra aplicación. La diferencia entre ellas es que debemos colocar las imágenes que aparecerán según el tipo de pantalla del dispositivo. En drawable-hdpi se colocarán las imágenes para dispositivos con alta resolución (High) y en drawable-ldpi (Low) pondremos las imágenes para dispositivos con pantallas pequeñas.
• values contiene inicialmente el archivo strings.xml, que es donde declaramos las cadenas de texto que usará nuestra aplicación. No es obligatorio definir todas las cadenas de texto allí, pero es bastante recomendable hacerlo. En este caso simplemente contiene la definición de una cadena de texto (llamada hello), que es la que se muestra al ejecutar la aplicación:

  <?xml version="1.0" encoding="utf-8"?>
  <resources>
   <string name="hello">Hello World, HolaParce!</string>
   <string name="app_name">Hola Parce</string>
  </resources>
  

• layout contiene los archivos XML que representan interfaces gráficas. Si echamos un vistazo al archivo generado (main.xml) veremos algo como esto:

  <?xml version="1.0" encoding="utf-8"?>
  <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
   android:orientation="vertical"
   android:layout_width="fill_parent"
   android:layout_height="fill_parent"
   >
  <TextView
   android:layout_width="fill_parent"
   android:layout_height="wrap_content"
   android:text="@string/hello"
   />
  </LinearLayout>
  

  De aquí podemos resaltar varias cosas:

  • Los layouts son XML estrictos, así que deben comenzar con el encabezado <?xml version="1.0" encoding="utf-8"?> y todas las etiquetas abiertas deben ser debidamente cerradas.
  • Los LinearLayout representan contenedores de widgets (algo similar al JPanel de swing en Java). Es decir, es la manera de organizar cada grupo de elementos de la interfaz gráfica.
  • En este caso, dentro del contenedor solo tenemos un TextView (que sería algo así como un JLabel de swing en Java).
  • Sea cual sea el elemento que pongamos en el layout, debemos especificar su anchura (android:layout_width) y altura (android:layout_height). Para cada parámetro podemos usar el valor fill_parent o wrap_content. fill_parent hará que el widget ocupe todo el tamaño posible, mientras que wrap_content hará que ocupe el menos posible.
  • El parámetro android:text permite asignar un texto al TextView. En este caso se usa @string/hello que indica que se usará una variable llamada hello. Esta variable puede ser encontrada en el archivo strings.xml dentro del directorio values. También podríamos especificar el texto directamente, por ejemplo: android:text="Hola parcero!"
• Como tal vez se dio cuenta, es posible editar los archivos XML gráficamente o con el editor de textos de Eclipse.

Dentro del directorio gen se encuentra un archivo llamado R.java. Este archivo NO debemos modificarlo ya que es Eclipse quien se encargar de poner el código allí dentro. Este archivo sirve básicamente para enlazar las cosas que hagamos en XML con la programación en Java. Por ejemplo, se crea una referencia a la variable hello creada en el archivo strings.xml. Esto permite que podamos referenciar dicha variable desde Java (esto se explica con más detalle abajo).

Bajo el directorio src se creó un paquete y dentro de él un archivo en Java que es nuestra primera actividad (fíjese cómo la clase creada extiende la clase Activity del paquete android.app):

package net.casidiablo.holaparce;
import android.app.Activity;
import android.os.Bundle;
public class HolaParce extends Activity {
/** Called when the activity is first created. */
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
    }
}

Veamos en detalle cada línea:

• Línea 1 define el nombre del paquete.
• Líneas 2 y 3 importamos las clases que necesitamos para correr la actividad.
• En la línea 4 podemos ver que la clase exitiende a Activity.
• En la línea 7 redefinimos el método onCreate de la clase Activity, el cual es ejecutado al momento de iniciar la aplicación. Note que no es necesario tener un método main; en Android se define una actividad principal que será ejecutada al iniciar la aplicación (más adelante veremos donde se configura esto).
• En la línea 9 se usa el método setContentView que define cual de las interfaces gráficas creadas en el directorio layout serán usadas. Como parámetro usamos la variable R.layout.main. Esto es algo confuso al principio así que lea atentamente: R, como vimos anteriormente, es una clase generada por Eclipse automáticamente cada vez que creamos nuevos componentes para la aplicación; dentro de ella se crean clases estáticas con variables enteras que representan cada uno de estos componentes (main.xml es entonces una variable entera llamada main, dentro de la clase estática layout, que a su vez se encuentra dentro de la clase R.java). Por ejemplo, para usar la variable hello desde Java, tendríamos que usar una referencia de tipo R.values.hello.

Por último, tenemos el archivo AndroidManifest.xml. Todas las aplicaciones deben tener este archivo y no debe ser renombrado. En él se especifican las opciones generales del programa, como el paquete principal, la actividad que deberá ejecutarse al iniciar la aplicación (y deben incluirse allí TODAS las actividades que se van usar), el icono a usar, los permisos, etc.

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
 package="net.casidiablo.holaparce"
 android:versionCode="1"
 android:versionName="1.0">
 <application android:icon="@drawable/icon" android:label="@string/app_name">
 <activity android:name=".HolaParce"
 android:label="@string/app_name">
 <intent-filter>
 <action android:name="android.intent.action.MAIN" />
 <category android:name="android.intent.category.LAUNCHER" />
 </intent-filter>
 </activity>
</application>
 <uses-sdk android:minSdkVersion="4" />
</manifest>

5. Operaciones avanzadas: acceder al dispositivo por consola y obtener una shell

Como sabemos, Android está basado en Linux, y como tal posee una interfaz de linea de comandos que podemos acceder usando las herramientas del sdk. Esto lo podemos hacer tanto para dispositivos virtuales, como el de este ejemplo, como para dispositivos reales. En este caso lo haremos con el dispositivo virtual que creamos para el ejemplo. Es tan sencillo como ejecutar esto en consola (en Linux):

Lo que hacemos con el comando anterior es indicarle al adb que queremos abrir una shell del dispositivo con serial emulator5554. Para ver los dispositivos conectados actualmente y sus seriales usamos el comando adb devices. Si todo va bien veríamos algo como esto:

Desde dicha shell podemos hacer bastantes cosas, pero la más interesante para mi, es poder usar el SQLite3 para acceder a las bases de datos de las aplicaciones que creemos, lo cual nos permite una depuración mucho más rápida.

Eso es todo… espero les haya gustado. Cualquier comentario, duda o sugerencia no duden en comentarla.

6. Links interesantes y fuentes de información

• Sitio oficial de Android para desarrolladores (esta es prácticamente todo lo que vas a necesitar)
• xda-developers, comunidad de desarrolladores de Android y Windows Mobile

Esta pequeña entrada la pongo porque me pareció bastante curioso… se trata de un vino oficial de Debian que, por cierto, se ve delicioso. Según me cuentan, el vino lo presentaron en el Debconf que se hizo en extremadura españa.

Aunque la foto de la derecha me deja algo desconcertado… ¿por qué le toman la foto al lado de un Mac Book? En fin… puedes adquirir tu propio vino por 5.8 euros más costes de envío (supongo).

Gracias a petox que me lo envió por correo Más información: http://wiki.debian.org/DebianWine

En esta ocasión vamos a aprender usar el System Tray desde una aplicación hecha en Java. El System Tray o área de notificaciones, es el espacio en el escritorio en donde ‘residen’ aplicaciones que el sistema está ejecutando, pero que no tienen en foco de lo que estamos haciendo.

Antes se usaban librerías nativas + JNI para lograr esto, pero desde hace un tiempo se incluyeron en el API de Java 6 las clases SystemTray y TrayIcon (dentro del paquete java.awt) lo cual nos facilita mucho las cosas.

0. Entendiendo las clases SystemTray y TrayIcon + Prerrequisitos

Antes que nada, debes tener instalada una versión reciente del JDK6. La clase java.awt.SystemTray representa el System Tray del escritorio. Para manipular dicha clase es necesario obtener un objeto estático de esta usando el método SystemTray.getSystemTray() (es decir, no es posible crear instancias de dicha clase). Además, es necesario verificar que el uso de esta clase sea soportada en el sistema donde se ejecuta. Esto lo hacemos usando el método estático SystemTray.isSupported(). Si no hay soporte, este método retornará false. Si haces un llamado al método getSystemTray y tu sistema no está soportado, se lanzará la excepción java.lang.UnsupportedOperationException.

La instancia de SystemTray contiene uno o más TrayIcons, los cuales son añadidos usando el método add(java.awt.TrayIcon), y son eliminados con el método remove(java.awt.TrayIcon).

1. Ejemplo de uso

import java.awt.*;
import java.awt.event.*;
public class EjemploSystemTray {
    public EjemploSystemTray() {
        //se declara el objeto tipo icono
        final TrayIcon iconoSystemTray;
        //se verifica que el SystemTray sea soportado
        if (SystemTray.isSupported()) {
            //se obtiene una instancia estática de la clase SystemTray
            SystemTray tray = SystemTray.getSystemTray();
            //esta es la imagen de icono
            Image imagenIcono = Toolkit.getDefaultToolkit().getImage("icono.png");
            //este listener nos permite capturar cualquier tipo de evento
            //que se haga con el mouse sobre el icono
            MouseListener mouseListener = new MouseListener() {
                public void mouseClicked(MouseEvent e) {
                    System.out.println("Icono del System Tray - Mouse clicked!");
                }
                public void mouseEntered(MouseEvent e) {
                    System.out.println("Icono del System Tray - Mouse entered!");
                }
                public void mouseExited(MouseEvent e) {
                    System.out.println("Icono del System Tray - Mouse exited!");
                }
                public void mousePressed(MouseEvent e) {
                    System.out.println("Icono del System Tray - Mouse pressed!");
                }
                public void mouseReleased(MouseEvent e) {
                    System.out.println("Icono del System Tray - Mouse released!");
                }
            };
            //este listener se asociara con un item del menu contextual
            //que aparece al hacer click derecho sobre el icono
            ActionListener escuchadorSalir = new ActionListener() {
                public void actionPerformed(ActionEvent e) {
                    System.out.println("Saliendo...");
                    System.exit(0);
                }
            };
            //menu que aparece al hacer click derecho
            PopupMenu popup = new PopupMenu();
            MenuItem item = new MenuItem("Exit");
            item.addActionListener(escuchadorSalir);
            popup.add(item);
            //iniciamos el objeto TrayIcon
            iconoSystemTray = new TrayIcon(imagenIcono, "Prueba System Tray", popup);
            //este tipo de listener captura el doble click sobre el icono
            ActionListener accionMostrarMensaje = new ActionListener() {
                public void actionPerformed(ActionEvent e) {
                    iconoSystemTray.displayMessage("Titulo mensaje",
                            "Este es el contenido del mensaje!",
                            TrayIcon.MessageType.INFO);
                }
            };

            iconoSystemTray.setImageAutoSize(true);
            iconoSystemTray.addActionListener(accionMostrarMensaje);
            iconoSystemTray.addMouseListener(mouseListener);

            //se debe capturar una excepción en caso que falle la adicion de un icono
            try {
                tray.add(iconoSystemTray);
            } catch (AWTException e) {
                System.err.println("No es posible agregar el icono al System Tray");
            }
        }
        else
            System.err.println("Tu sistema no soporta el System Tray");
    }
    public static void main(String[] args) {
        new EjemploSystemTray();
    }
}

Así se ve en Linux (usando Gnome) y en Windows7:

Del ejemplo anterior veamos las líneas más importantes:

• Línea 8: verificamos que tengamos soporte.
• Línea 10: obtenemos una instancia de la clase SystemTray.
• Línea 46: creamos el icono que vamos a añadir.
• Línea 50: invocación del método displayMessage para mostrar globos de notificación.
• Línea 62: añadimos el icono al systray.

2. ¿Cómo usar Swing en vez de AWT?

Si te fijaste bien, el SystemTray es una clase que pertenece al paquete AWT… por alguna razón no se tuvo en cuenta Swing en todo esto. Es por ello que no podemos usar directamente JPopupMenu en vez de PopupMenu. Además, JPopupMenu tampoco es una subclase de PopupMenu por lo cual no podemos usar polimorfismo

Afortunadamente hay algunos trucos para hacerlo funcionar con Swing que nos proporciona varias ventajas: la apariencia del menú sería igual en cualquier sistema operativo, podemos añadir iconos a los items, etc.

El truco más sencillo del cual tengo conocimiento lo leí en el blog de Artem Ananiev, en un post llamado Using JPopupMenu in TrayIcon. He preparado entonces otro ejemplo sencillo en donde se muestra cómo lograr esto:

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
public class EjemploSystemTraySwing {
    public EjemploSystemTraySwing() {
        //se declara el objeto tipo icono
        final TrayIcon iconoSystemTray;
        //se verifica que el SystemTray sea soportado
        if (SystemTray.isSupported()) {
            //se obtiene una instancia estática de la clase SystemTray
            SystemTray tray = SystemTray.getSystemTray();
            //esta es la imagen de icono
            Image imagenIcono = Toolkit.getDefaultToolkit().getImage("icono.png");
            //este listener se asociara con un item del menu contextual
            //que aparece al hacer click derecho sobre el icono
            ActionListener escuchadorSalir = new ActionListener() {
                public void actionPerformed(ActionEvent e) {
                    System.out.println("Saliendo...");
                    System.exit(0);
                }
            };
            //menu que aparece al hacer click derecho
            final JPopupMenu popup = new JPopupMenu();

            //aniadir un menu con icono (swing)
            JMenuItem carita = new JMenuItem("casidiablo.net",  new ImageIcon("carita.png"));
            popup.add(carita);
            popup.addSeparator();

            //aniadir el item de salir
            JMenuItem item = new JMenuItem("Exit", new ImageIcon("salir.png"));
            item.addActionListener(escuchadorSalir);
            popup.add(item);
            //iniciamos el objeto TrayIcon
            iconoSystemTray = new TrayIcon(imagenIcono, "Prueba System Tray", null);
            iconoSystemTray.setImageAutoSize(true);
            //iconoSystemTray.addMouseListener(mouseListener);
            iconoSystemTray.addMouseListener(new MouseAdapter() {
                public void mouseReleased(MouseEvent e) {
                    if (e.isPopupTrigger()) {
                        popup.setLocation(e.getX(), e.getY()-50);
                        popup.setInvoker(popup);
                        popup.setVisible(true);
                    }
                }
            });
            //se debe capturar una excepción en caso que falle la adicion de un icono
            try {
                tray.add(iconoSystemTray);
            } catch (AWTException e) {
                System.err.println("No es posible agregar el icono al System Tray");
            }
        }
        else
            System.err.println("Tu sistema no soporta el System Tray");
    }
    public static void main(String[] args) {
        new EjemploSystemTraySwing();
    }
}

El resultado es algo como lo que aparece en la primera imagen que acompaña esta entrada. Importante tener en cuenta las líneas resaltadas (40 a 44) que es donde se hace la magia Como siempre, puedes descargar el código y probar tú mismo:

Descargar ZIP con ejemplos

A continuación voy a poner algunos snippets de código de shell script que me han sido siempre útiles cuando escribo algún script. La mayoríá funcinoan en cualquier shell de Unix, aunque algunos requieren que sean ejecutados por Bash.

Evitar que usuarios sin privilegios ejecuten el script

Algunos scripts realizan tareas administrativas por lo cual podríamos querer que solo el usuario root ejecute el script. En ese caso podemos usar algo como esto:

#!/bin/bash
if [[ $EUID -ne 0 ]]; then
echo "Este script debe ser ejecutado por el usuario root" 1>&2
    exit 1
fi

Permitir la ejecución del script solo a un usuario específico

De manera similar al código anterior, podríamos querer que solo un usuario específico ejecute el script. Lo hacemos así:

#!/bin/bash
AUTHORIZED_USER="usuario_permitido"
if [ $USER != $AUTHORIZED_USER ]; then
    echo "Este script debe ser ejecutado por el usuario $AUTHORIZED_USER" 1>&2
    exit 1
fi

Verificar que un servicio/proceso se está ejecutando

Si queremos saber si existen procesos de algún servicio o programa ejecutándose podríamos usar este script (en este caso verifica que el demonio de Apache esté corriendo):

#!/bin/sh
SERVICE='httpd'
if ps ax | grep -v grep | grep $SERVICE > /dev/null
then
    echo "El servicio $SERVICE esta ejecutandose"
else
    echo "Chanfle! El servicio $SERVICE esta detenido"
fi

Verificar que una variable esté asignada/tenga datos

Hay bastantes maneras de hacer esto en shell script… la que considero más sencilla y concisa es esta:

#!/bin/bash
FOO=
: ${FOO:?"No existe la variable FOO o no tiene datos"}
echo "esto nunca se va a imprimir"

El anterior script verifica si una variable existe y tiene datos; si esto no se cumple, el script se cierra. Podemos usar esta variación en donde solo comprobamos que la variable exista, sin importar si tiene datos o no:

#!/bin/bash
FOO=
: ${FOO?"No existe la variable FOO"}
echo "esto si se va a imprimir"

Crear un archivo de bloqueo

A veces debemos asegurarnos que el script no se ejecute dos o más veces simultáneas. Para ello podemos hacer uso de los archivos de bloqueo. Esta es una versión sencilla de un script que nos permite hacer esto:

#!/bin/bash
lockfile=/var/lock/loquesea.lock
if [ ! -e $lockfile ]; then
   touch $lockfile
   echo "hago muchas cosas importantes aqui"
   rm $lockfile
else
   echo "ya hay otro proceso corriendo"
fi

En este caso, se verifica que el archivo loquesea.lock exista. En caso de que exista, el script NO ejecuta sus tareas. Si no existe, crea el archivo, ejecuta las tareas que deba ejecutar y lo elimina.

Pero, esto no es del todo fiable. ¿Qué pasaría si mientras nuestro script se está ejecutando es cerrado abruptamente (con Ctrl^c por ejemplo)? En ese caso el archivo de bloqueo no se borraría, y por lo tanto, no nos permitiría ejecutar el script de nuevo.

Para cubrir esos casos, podríamos hacer uso del comando trap que nos permite ejecutar comandos en caso que nuestro script termine de manera inesperada. Esta es una versión más avanzada que además guarda dentro del archivo de bloqueo el PID del script que lo ejecuta:

#!/bin/bash
lockfile=/var/lock/loquesea.lock
if ( set -o noclobber; echo "$$" > "$lockfile") 2> /dev/null;
then
    trap 'rm -f "$lockfile"; exit $?' INT TERM EXIT
    echo "hago muchas cosas aqui tranquilamente"
    rm -f "$lockfile"
    trap - INT TERM EXIT
else
    echo "Ya hay otro proceso de este script ejecutandose"
    echo "corriendo con el PID: $(cat $lockfile)"
fi

Entendamos un poco mejor el comando trap. La sintaxis del mismo es básicamente esta: trap comando signal [signal ...]; donde signal es la señal de terminación que quieres atrapar. Si quieres ver una lista de los signals disponibles puedes ejecutar el comando kill -l. Para el caso anterior se usaron los signals INT (captura la terminación producida por un Ctrl^c), TERM (terminación producida por el comando kill) y EXIT (terminación normal de un script, bien sea porque ya no hay más líneas que ejecutar o porque se encuentra con el comando exit).

Menú de opciones

Para hacer un menú en donde permitimos al usuario seleccionar una serie de opciones podemos usar el siguiente esquema:

#!/bin/bash
clear
while :
do
 echo " Escoja una opcion "
 echo "1. quien soy?"
 echo "2. cuanto espacio tengo"
 echo "3. que es esto?"
 echo "4. Salir"
 echo -n "Seleccione una opcion [1 - 4]"
 read opcion
 case $opcion in
  1) echo "este eres:";
     whoami;;
  2) echo "tienes esto";
     df;;
  3) uname -r;;
  4) echo "chao pues parcero";
     exit 1;;
  *) echo "$opc es una opcion invalida. Es tan dificil?";
     echo "Presiona una tecla para continuar...";
     read foo;;
esac
done

Pedir confirmación antes de ejecutar un script

A veces es útil hacer que el usuario confirme la ejecución de un lote de sentencias, es decir, el típico mensaje que pide al usuario escribir yes o no. Esto lo podemos hacer así:

#!/bin/bash
while true; do
    echo
    read -p "esta seguro de hacer lo que sea que vaya a hacer " yn
    case $yn in
        yes ) break;;
        no ) exit;;
        * ) echo "por favor responda yes o no";;
    esac
done
echo "si se ejecuta esto es que aceptaste"

Fuentes de información

• StackOverflow - La más valiosa sin duda alguna
• Writing Robust Bash Shell Scripts
• nixCraft

A veces es necesario trabajar con el sistema de archivos UFS (el que viene por defecto en FreeBSD, OpenBSD, NetBSD, etc.) desde Linux. En este pequeño artículo explicaré cómo configurar el kernel de tal manera que quede habilitado el soporte de lectura y escritura de UFS. Me enfocaré en FreeBSD, que es donde hice las pruebas.

Tengamos en cuenta además que el esquema de particiones de FreeBSD es distinto al de Linux. Este solo necesita una ‘partición’ primaria (llamadas slices en BSD) para administrar las particiones que utilizará el sistema, y cada una de esas particiones tiene un esquema de nombres en particular. Puesto que dicho esquema algunas veces no es soportado por nuestro kernel, activaremos también esta opción (de lo contrario solo podremos montar la raiz del sistema FreeBSD mas no sus particiones).

0. Preparando el kernel

Tal vez ya tengas soporte para UFS, pero para esta entrada asumiré que no es así.

Así que, vamos a la configuración del kernel (en este momento estoy usando Linux kernel 2.6.32):

Ahora, vamos a activar estas opciones:

Verás algo como esto:

Importante: el soporte para escritura en UFS2 está en desarrollo y puede ser peligroso. Úsalo bajo tu propio riesgo

Ahora, habilitaremos el soporte para FreeBSD disklabel:

Verás algo como esto:

Bien, con estas opciones habilitadas solo nos queda compilar e instalar el kernel:

1. Buscando los nombres de las particiones

Cuando estamos trabajando con FreeBSD, los nombres que se asignan a las particiones son del tipo: /dev/ad0s3a. Pero, como estamos trabajando con Linux, en realidad seguiremos usando nombres del tipo /dev/sda* o /dev/hda*. Así que, gracias al soporte para FreeBSD Disklabel que hemos habilitado, podemos trabajar con los nombres convencionales:

Verás algo como esto:

2. Montando las particiones UFS

Para montar una partición UFS ejecutaremos el siguiente comando (supongamos que /dev/sda7 es una de las particiones *BSD):

Por supuesto, podemos añadir una entrada al archivo /etc/fstab para que la partición se monte automáticamente al iniciar el sistema operativo:

¡Eso es todo! Si tienes algún problema o sugerencia no dudes en comentar.

Some times it’s necessary to work with UFS (the default filesystem on FreeBSD, OpenBSD, NetBSD, etc.) from your linux box. Here I’ll explain how to do so by configuring your kernel in order to enable UFS read/write support. We’ll focus on FreeBSD.

Also, as you should know, FreeBSD uses its own hard disk partition scheme on your PC. It requires only one entry in the primary partition table of your disk and manages it similarly to DOS extended partitions, putting in its first sector a new partition table in BSD disklabel format. So we’ll enable support for reading these disklabels; otherwise we just will be able to mount the root ‘slice’ of FreeBSD but not the partitions ‘inside’.

0. Preparing your kernel

You may already have support for UFS and BSD disklabel format, but I’ll assume that you have built your kernel by your self and/or don’t have those options enabled.

So, let’s get into the menu configuration of your kernel (I’m using Linux kernel 2.6.32):

Now, we are going to activate these options:

It’ll look like this:

Important: write support for UFS2 is on development and could be dangerous. Use it at your own risk

Now, we’ll enable the FreeBSD disklabel support:

It’ll look like this:

OK… with these options enabled we just need to compile our kernel and install it:

1. Looking for partitions names

When working with FreeBSD, the disks device names are like this: /dev/ad0s3a. But, as we are working with Linux, we’ll have the traditional /dev/sda* or /dev/hda* names. So, thanks to the FreeBSD Disklabel support that we’ve just added, we can do this in order to know the devices names:

You’ll get something like this:

2. Mounting UFS

In order to mount a UFS partition you’ll need to type this (suppose /dev/sda7 is one of the *BSD partitions):

Of course, you can add an entry to your /etc/fstab file so the partition get mounted each time you boot your system:

That’s it. Let me know if you have any problem. And sorry for my English, I’m just learning

Al instalar sistemas operativos adicionales a los que tenemos generalmente nos dan la opción de instalar un boot loader en el MBR. Esto sobre escribe nuestro anterior boot loader (GRUB o Lilo en la mayoría de los casos), así que es preferible no tocar el MBR.

En este pequeño tip les mostraré cómo configurar GRUB para iniciar aquel hermoso sistema FreeBSD que acabas de instalar junto a tu Linux. La verdad es muy sencillo, lo único que debes hacer es añadir lo siguiente al archivo /boot/grub/menu.lst:

Una breve explicación:

• title FreeBSD 8.0 : Crea un nuevo ítem en el menú y le pone el título ‘FreeBSD 8.0′ (en realidad puedes colocar lo que quieras).
• root (hd0,a) : Seleccionamos la partición raíz donde se encuentra FreeBSD. En el ejemplo hd0 es el primer disco duro (hda en Linux). En GRUB hda es hd0. Así, por ejemplo, hda2 (segunda partición del primer disco) es hd0,1 en Grub. Además, recuerda que FreeBSD usa nombres del tipo a, b, c para representar los nombres de las particiones. Si tuvieras instalado FreeBSD en la tercera partición entonces tendrías que usar: root (hd0,2,a)
• kernel /boot/loader : Se usa para cargar la imagen de boot principal. FreeBSD usa /boot/loader para cargar el resto del kernel y OS.

Actualización: entrada para GRUB2

Si estás usando GRUB2 entonces deberás modificar tu archivo /boot/grub/grub.cfg y añadir esto:

Fuente: Lista de correo FreeBSD | Foros FreeBSD