www.jugpadova.it: Category Tips & Tricks

Hello Android Tutorial su Debian Testing

Dario Santamaria — Sun, 17 Oct 2010 13:54:00 -0500

Questo tutorial ha lo scopo di guidarvi passo passo nella creazione e installazione di un’applicazione (Hello Android) all’interno di un dispositivo Android disponendo di un PC con distribuzione Debian Testing.

Di che cosa abbiamo bisogno:

Un IDE per sviluppare la nostra app – Eclipse
Android SDK – presso Google
Un plugin per l’IDE (ADT) per poter creare il nostro package .apk
Uno smartphone Android – Motorola Flipout

Intanto segnalo il fatto che si potrebbe utilizzare come IDE Netbeans (ne sono un utilizzatore convinto), ma il problema è che nei repositories Debian siamo attualmente fermi alla versione 6.0.1 che non supporta l’attuale plugin nbandroid :-(

Iniziamo a configurare la nostra distro per ottenere il risultato desiderato: creare un package .apk da inviare al nostro smartphone.

1. Eclipse IDE

Diamo da riga di comando:

$ apt-get install eclipse

e verranno installati in automatico tutti i pacchetti necessari (tra cui eclipse-jdt eclipse-pde eclipse-platform eclipse-platform-data eclipse-plugin-cvs eclipse-rcp).

2. Android SDK

Preleviamo da developer.android.com il pacchetto .tgz per la nostra piattaforma:

$ wget http://dl.google.com/android/android-sdk_r07-linux_x86.tgz

ed estraiamolo nella home del nostro debian user:

$ tar xvzf android-sdk_r07-linux_x86.tgz

3. Android Development Tools (ADT) Plugin per Eclipse

Eclipse dà la possibilità di inserire nell’IDE un URL attraverso il quale trovare ed installare i plugins. In particolare per installare l’ADT Plugin basta avviare l’IDE e selezionare dal menu:

Window → Preferences

Su questa finestra:

dalla lista a sinistra apriamo la sezione Install/Update
selezioniamo Available Software Sites
clicchiamo sul bottone Add a destra
inseriamo l’indirizzo dove reperire il plugin: https://dl-ssl.google.com/android/eclipse/
e infine clicchiamo su OK

Ora andiamo sul menu:

Help → Install New Software

Su questa finestra dal menu a tendina Work with: selezionate il repository appena inserito. Sotto scegliete Android Development Tools e proseguite nelle successive schermate (tra queste ci sarà anche l’accettazione della licenza).

A questo punto l’IDE chiede di essere riavviato. Dopo ciò, bisogna configurare il plugin in modo che sfrutti l’Android SDK installato al punto 2. Andiamo su:

Window → Preferences

Troveremo sulla lista a sinistra una nuova voce: Android. Selezioniamola e clicchiamo sul bottone Browse a destra inserendo la posizione dell’Android SDK del punto 2 (/home/stylee/android-sdk-linux_x86).

Se qualcosa dovesse andare storto, vi riporto il link alla guida esaustiva per l’installazione e configurazione del plugin.

4. Configurazione dell’Android SDK tramite il tool the Android SDK and AVD Manager

Il plugin è configurato all’interno dell’IDE. Ora dobbiamo configurare l’ambiente dell’ Android SDK per definire quale sarà il nostro dispositivo su cui svilupperemo l’applicazione. Il tool da utilizzare è lanciabile direttamente dall’interno di Eclipse con il bottone sul pannello pricipale:

Nel caso particolare, per produrre un package installabile sul mio Motorola FlipOut, dovrò installare le API 7 per Android v2.1 (menu Available Packages sulla sinistra):

Dopo le API bisogna creare un Android Virtual Device sul quale verrà testata la nostra app (tramite emulatore). Selezioniamo la voce Virtual Devices sulla sinistra. Il mio FlipOut ha 2Gb di scheda di memoria SD, Android 2.1 e risoluzione QVGA.

5. Hello Android

Creiamo un nuovo progetto con il wizard sulla barra principale di Eclipse:

Compilate i vari campi a vostro piacimento, seguendo le linee guida:

Aprite nell’editor la classe it.santasoft.helloandroid.HelloAndroid e modificate in questo modo:

package it.santasoft.helloandroid;

import android.app.Activity;
import android.os.Bundle;
import android.widget.TextView;

public class HelloAndroid extends Activity {
    /** Called when the activity is first created. */
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        TextView tv = new TextView(this);
        tv.setText("Hello JUGPadova! From my Android Device");
        setContentView(tv);
    }
}

Ora che abbiamo sistemato il codice, passiamo alla compilazione premendo il tasto sul pannello dell’IDE

Run → As Android Application

Verrà compilato il nostro package e lanciato l’emulatore definito precedentemente nella sezione Android Virtual Devices. Munitevi di pazienza e attendete qualche minuto che l’emulatore si avvii… e vedrete il risultato sperato.

Per maggiori informazioni e per alcuni approfondimenti sull’app HelloAndroid visitate questo link su developer.android.com

6. Installazione del package .apk sul dispositivo Android

Individuiamo il pacchetto Hello Android.apk all’interno dell’alberatura del nostro progetto compilato in Eclipse:

Hello Android → bin → it → Hello Android.apk

Sul nostro dispositivo Android andiamo ad installare dall’Android Market uno dei tanti Apps Installer che ci permettono di gestire pacchetti .apk all’interno della scheda di memoria SD esterna. Io utilizzo appInstaller di Gregory House.

Spegniamo il nostro dispositivo Android, estraiamo la scheda di memoria, inseriamola sul nostro PC e trasferiamo nella directory radice il package Hello android.apk; smontiamo la scheda, reinseriamo nel dispositivo e accendiamo.

Per questioni di sicurezza è disabilitata di default l’opzione di poter installare applicazioni al di fuori dell’Android Market, perciò per il nostro scopo navighiamo nel menu del nostro dispositivo e abilitiamo l’opzione

Impostazioni → Applicazioni → Origini Sconosciute

Avviamo l’applicazione appInstaller e scegliamo il nostro package Hello, Android. E finalmente otteniamo

Altro metodo molto veloce (testato di persona) se sul nostro Debian PC abbiamo installato il web server apache e siamo in una rete wifi domestica è il seguente.

Copiamo il nostro Hello Android.apk sulla root del webserver Apache – /var/www di default
Verifichiamo quale sia l’indirizzo IP del Debian PC connesso alla rete wifi domestica – supponiamo 192.168.2.51
Attiviamo il wifi sul dispositivo Android
Apriamo il browser del nostro smartphone all’indirizzo: http://192.168.2.51/Hello%20Android.apk
Dopo che il browser ha finito di scaricare il pacchetto comparirà una notifica: toccate la riga della notifica e vi verrà chiesto se volete installare il pacchetto.

(il %20 sostituisce lo spazio negli URL).

Debugging tests of a Maven project in NetBeans

Lucio Benfante — Wed, 20 Feb 2008 11:30:00 -0600

Occasionally I experienced some problems in debugging test classes using NetBeans with Maven projects. Simply, the debugger started but didn’t attach to the running tests.

Eventually I discovered the reason!

I used to configure the surefire plugin with:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <configuration>
        <skip>false</skip>
        <useFile>true</useFile>
        <forkMode>once</forkMode> <!-- always, once or never -->
        <!-- <reportFormat>plain</reportFormat> -->
        <argLine>-Xmx512M</argLine>
    </configuration>
</plugin>

The problem is the argLine parameter. It will override the parameters the Mevenide plugin will pass for debugging tests. So, I commented it in my configuration:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <configuration>
        <skip>false</skip>
        <useFile>true</useFile>
        <forkMode>once</forkMode> <!-- always, once or never -->
        <!-- <reportFormat>plain</reportFormat> -->
        <!--argLine>-Xmx512M</argLine--> <!-- don't use if you want to debug tests in NetBeans -->
    </configuration>
</plugin>

...and now I can debug my tests!

Iterating on non-iterable classes

Lucio Benfante — Fri, 27 Jul 2007 06:42:00 -0500

(You’ll find all the code of this post in Benfante’s Utilities mini-library)

One of the futures I ‘m reappraising is the JDK 5 enhanced for statement.

I still consider it too limited, but it’s very comfortable in the simplest (and maybe common) cases.

But…what if the elements on which you want to iterate are not managed by an Iterable class?

For example, this happens with the XOM library, where the Element.getChildElements returns an instance of the Elements class, wich is neither a Collection, or an Iterable class. So, for iterating on children elements, you have to use the basic for statement:

for (int i=0; i < elements.size(); i++) {
  Element element = elements.get(i);
  // etc...
}

I would like to write simply:

for (Element element: elements) {
  // etc...
}

So I wrote an Iterabletor class that builds a proxy around a class, enhancing it with the Iterable interface.

Now You can write:

Iterable<Element> iterable =
  new Iterabletor<Element>(elements).getIterable();

for (Element element: iterable) {
  // etc...
}

Take a look at how I realaized this.

First, the Iterabletor class:

package com.benfante.utils.iterabletor;

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;
import java.util.Iterator;

/**
 * A class for add iterability to another class
 * 
 * @author lucio
 */
public class Iterabletor<T> implements InvocationHandler {

    private final Object obj;
    private Class<? extends Iterator> iteratorClass;

    /**
     * Prepare for iterability the passed object using a XOMIterator.
     *
     * @param The object on which iterate.
     */
    @SuppressWarnings(value = "unchecked")
    public Iterabletor(Object obj) {
        this.obj = obj;
        this.iteratorClass = XOMIterator.class;
    }

    /**
     * Prepare for iterability the passed object using the passed iterator class.
     *
     * @param The object on which iterate.
     */
    public Iterabletor(Object obj, Class<? extends Iterator> iteratorClass) {
        this.obj = obj;
        this.iteratorClass = iteratorClass;
    }

    @SuppressWarnings(value = "unchecked")
    public synchronized Iterable<T> getIterable() {
        Class<?> objClass = obj.getClass();
        Class<?>[] oldInterfaces = objClass.getInterfaces();
        Class<?>[] newInterfaces = new Class<?>[oldInterfaces.length + 1];
        System.arraycopy(oldInterfaces, 0, newInterfaces, 0, oldInterfaces.length);
        newInterfaces[newInterfaces.length - 1] = Iterable.class;
        return (Iterable<T>) Proxy.newProxyInstance(objClass.getClassLoader(),
                newInterfaces,
                this);
    }

    @SuppressWarnings(value = "unchecked")
    private Iterator<T> iterator() {
        try {
            return (Iterator<T>) iteratorClass
                .getConstructor(Object.class).newInstance(obj);
        } catch (Exception e) {
            throw new UnsupportedOperationException("No contructor(object)", e);
        }
    }

    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        if (method.getName().equals("iterator")) {
            return this.iterator();
        } else {
            try {
                return method.invoke(obj, args);
            } catch (InvocationTargetException ite) {
                throw ite.getCause();
            }
        }
    }
}

The default Iterator is XOMIterator (you can imagine why this name :) ), which reflect on the “collection”, calling the get(int) and size() methods:

package com.benfante.utils.iterabletor;

import java.util.Iterator;
import org.apache.log4j.Logger;

/**
 * An Iterator for XOM-like collection classes
 * ...i.e. classes with get(int) and size() methods.
 * 
 * @author lucio
 */
public class XOMIterator<T> implements Iterator<T> {

    private static final Logger logger = Logger.getLogger(XOMIterator.class);
    private Object obj;
    private int index;

    public XOMIterator(Object obj) {
        this.obj = obj;
    }

    public boolean hasNext() {
        try {
            int count = ((java.lang.Integer) obj.getClass()
                    .getMethod("size", new Class[0])
                    .invoke(obj)).intValue();
            return index < count;
        } catch (Exception ex) {
            logger.error("No size() method in the target object ("
                    + obj.getClass().getName() + ")", ex);
            throw
                    new UnsupportedOperationException(
                    "No size() method in the target object ("
                    + obj.getClass().getName() + ")", ex);
        }
    }

    @SuppressWarnings(value = "unchecked")
    public T next() {
        try {
            return (T) obj.getClass()
                    .getMethod("get", new Class<?>[]{int.class})
                    .invoke(obj, new Integer(index++));
        } catch (Exception ex) {
            logger.error("No get(int) method in the target object ("
                    + obj.getClass().getName() + ")", ex);
            throw
                    new UnsupportedOperationException(
                    "No get(int) method in the target object ("
                    + obj.getClass().getName() + ")", ex);
        }
    }

    public void remove() {
        throw new UnsupportedOperationException("Not supported.");
    }
}

Of course, You can use a different Iterator:

Iterator<MyElement> iterable =
    new Iterabletor<MyElement>(element, MyIterator.class)
        .getIterable();

JDBC url for oracle RAC

Enrico Giurin — Wed, 11 Apr 2007 20:07:00 -0500

If you have to connect to oracle RAC (Real Application Cluster) using JDBC with thin driver, the classic url:

jdbc:oracle:thin:@<HOST>:1521:<SID>

doesn’t work and you get the error ORA – 12505.
Instead, you must use this url:

jdbc:oracle:thin:@(DESCRIPTION=(LOAD_BALANCE=on)
(ADDRESS=(PROTOCOL=TCP)(HOST=host1) (PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=host2) (PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=service)))

If you have an oracle client, like toad, check the tsnames.ora for the correct values of SERVICE_NAME and host.

Tomcat 5.5.20 and JavaMail Sessions

Lucio Benfante — Tue, 13 Mar 2007 07:40:00 -0500

You’ll find an article in italian on the same topic in my personal blog.

In Tomcat you can define a JNDI Resource for a JavaMail session putting the following code in you Context definition:

<Resource name="mail/Session" auth="Container"
            type="javax.mail.Session"
            mail.smtp.host="localhost"/>

And in you web.xml:

<resource-ref>
  <res-ref-name>mail/Session</res-ref-name>
  <res-type>javax.mail.Session</res-type>
  <res-auth>Container</res-auth>
</resource-ref>

Then you can use it in you code:

Context initCtx = new InitialContext();
Session session =
    (Session) envCtx.lookup("java:comp/env/mail/Session");

Using Tomcat 5.5.20 (and 5.5.17, and 5.5.23…and maybe other versions) the last statement will produce a ClassNotFoundException: org.apache.naming.factory.MailSessionFactory. The cause is obviously that class is missing from the common/lib/naming-factory.jar distributed by Tomcat. I don’t know if it was a (repeated) problem in building Tomcat. Luckly the source code of that class is still present in the source distribution of Tomcat. Simply it isn’t included in the build process if you don’t have the JavaMail and the JavaBeans Activation Framework in the build classpath. So I re-built the naming-factory.jar file and substituted in common/lib.

You can rebuild your own JAR, or download my new naming-factory.jar.

I discovered this problem (bug?) installing LifeRay 4.1.2 using the WAR distribution. On the contrary the LifeRay-Tomcat bundle contains the correct naming-factory.jar yet. The LifeRay error in this case is more obscure. It reports a javax.naming.NameNotFoundException: Name mail is not bound in this Context! Of course the JNDI Resource is correctly configured. This happens because LifeRay try to guess the JNDI name of the resource, that changes for the different application servers. So that exception comes from one of the attempts, and the real problem is lost and hidden. So, if you’ll see a such message, don’t spend time re-re-re-configuring your JNDI resources…but patch Tomcat!

Ma voi le wrappate le liste?

Paolo Dona' — Wed, 06 Dec 2006 08:45:00 -0600

Ciao, in un progetto su cui sto lavorando sto provando un approccio che non avevo mai usato in passato per le liste di oggetti java, immaginate che di avere una lista tipo:

List<SomeObject> list = new ArrayList<SomeObject>();

Se volessi estrarre dalla lista tutti gli elementi aventi un certo campo valorizzato ad un dato valore, ovvero fare un filtro, farei:

class SomeObject {
  public static List<SomeObject> filterByField(List<SomeObject> input, String value) {
    // ciclo la lista input e restituisco una lista nuova con gli oggetti che hanno field=value 
  }
}

usato così:

List<SomeObject> all = new ArrayList<SomeObject>();
List<SomeObject> filtered = SomeObject.filterByField(all, "someValue");

Il fatto però di avere metodi statici ‘helper’ dentro SomeObject per aggiungere funzionalità ad una lista non mi piace molto… ho provato invece a wrappare List e a spostare il metodo filerByValue da SomeObject alla nuova classe SomeObjects:

class SomeObjects extends ArrayList<SomeObject> {
   public SomeObjects filterByField(String value){
     // filtro ciclando gli elementi in this e restituisco una nuova istanza di SomeObjects
   }
}

Il codice di utilizzo quindi diventa:

SomeObjects all = new SomeObjects();
SomeObjects filtered = all.filterByField("someValue");

Che mi pare molto più pulito e leggible, che ve ne pare?

So che non è un gran cambiamento, ma ho un parametro in meno per ogni filterByXXX che desidero aggiungere e ogni metodo è nel posto che gli compete, ovvero i medoti per filtrare una lista stanno nella lista e non come metodi helper dell’oggetto contenuto.

Un’altro punto dove questo approccio è utile è nei Dao che wrappano funzionalità di IBatis o Hibernate, dove si trova spesso codice di questo tipo per prevenire il ritorno di liste nulle:

List<SomeObject> result = new ArrayList<SomeObject>();
result.addAll( ...queryForList("your query", param));
return result;

Con i wrapper possiamo scrivere un costruttore ad hoc, che prende una lista in input e fa addAll(...) solo se è diversa da null:

public class SomeObjects extends ArrayList<SomeObject> {

    public SomeObjects () {}

    public SomeObjects (Collection<SomeObject> c) {
       if (c!=null) addAll(c);
    }
}

E il codice di utilizzo diventa magicamente:

return new SomeObjects(...queryForList("your query", param));

Fatemi sapere che ne pensate, io mi sto trovando bene con questo approccio.

_ Paolo Donà si occupa di sviluppo web in Java e Ruby, sviluppo progetti su commessa e formazione/training. Potete contattarlo via mail o leggere il suo blog aziendale o personale. _

Mi domando...davvero so <code>null</code>(a)?

Lucio Benfante — Fri, 03 Nov 2006 17:00:00 -0600

“La vera saggezza sta in colui che sa di non sapere! Perchè io so di sapere più di te, che pensi di sapere.” (Socrate) Allora i programmatori Java dovrebbero essere molto saggi, perchè dovrebbero essere convinti di (non) conoscere null molto bene. Ma siamo così sicuri?

Domanda 1: Di che tipo è il litteral null?